こんにちは！

2026年5月に、AnthropicからClaude Opus 4.8がリリースされました。

そして、2026年6月には Fable5 /Mythos5がリリースされました。
しかし都合により現在(2026/6/18)は利用できないため、実質 Claude Opus 4.8 が一般人がつかえるClaudeシリーズの最上位モデルということになります。

そこで、今回は長く付き合うことになるかもしれない Opus 4.8 について徹底解説したいとおもいます。

Opus4.8は従来の4.7の延長線上にあるアップデートですが、「ベンチマークが少し上がった」では片付けられない変化を含んでいます。

effortパラメータのデフォルトが変わり、Claude Codeには1回のワークフローで数十〜数百のサブエージェントを編成する

「Dynamic Workflows（動的ワークフロー）」が加わり（ただし同時に動作するのは最大16）、自分が書いたコードの欠陥を指摘せずに通過させる頻度を大きく減らす「誠実性（honesty）」の改善が入りました。

つまり、4.7時代に組んだ運用やプロンプトを、そのまま流用すると最適ではなくなる箇所がいくつもあります。

この記事は、Anthropicの公式ドキュメントと公式発表を主な根拠として、(1) モデルとしてのClaude Opus 4.8、(2) Claude Code CLI版での実践、(3) Claude Code Web版での実践、の三部構成で整理したものです。

本文には公式仕様から導いた運用上の解釈も含みますが、ベンチマーク等の数値は、Anthropic自身の評価か外部評価かを区別して記載しています。

長編のため、頭から通読する必要はありません。気になる章だけピックアップして読んでもらえれば十分です。出典は記事末にまとめてあります。

想定読者は、4.7から4.8への移行を検討しているエンジニア、Claude Codeをチームで運用しているリードエンジニア、企業導入を判断するテックリード、そしてCLI版とWeb版の使い分けに悩んでいる方です。

構成は前回のClaude Opus 4.7 完全ガイドを踏襲しています。4.7の基礎（アダプティブシンキングへの移行、サンプリングパラメータの廃止、1Mコンテキストなど）から押さえたい方は、先にそちらを読んでおくと本記事の差分がわかりやすくなります。

4.7からのアップデート、ざっくり

前回記事で扱ったOpus 4.7から、4.8では主に次の点が変わりました。詳細は各章で扱いますが、まず全体像をつかむために要点だけ並べます。

なお、Opus 4.7向けに書いたコードやプロンプトは、モデルIDの差し替えだけでそのまま動きます（破壊的なAPI変更なし）。

「動くが、設定を見直すと真価が出る」というのが4.8の性格です。

第1部：Claude Opus 4.8とは何か

1. 4.7から4.8への移行で変わるもの

まず結論から。Claude Opus 4.7向けに書いたコードは、モデルIDを差し替えるだけで4.8でそのまま動きます。

APIの破壊的変更はありません。

公式の移行ガイドも「There are no breaking API changes for code already running on Claude Opus 4.7」と明言しています。

# Opus 移行
model = "claude-opus-4-7"  # Before
model = "claude-opus-4-8"  # After

なお、これはOpus 4.7から移行する場合の話です。Opus 4.6以前から直接移行する場合は、サンプリングパラメータの非対応や固定思考バジェット（budget_tokens）の廃止など、4.7で導入された破壊的変更への対応も必要になります（詳細は第4章）。

ただし「動く」ことと「最適である」ことは別です。

移行時に見直しておきたいポイントは次の4つに集約されます。

特に注意したいのがeffortデフォルトの変化です。

Claude Code上では4.7のデフォルトがxhighだったのに対し、4.8ではhighになりました。何も設定しないとコーディングタスクでもhighで走るため、4.7と同じ深さの推論を期待しているなら明示的にxhighを指定する必要があります(詳細は第9章)。

移行チェックリスト(公式ガイドより)

• [ ] モデル名をclaude-opus-4-7からclaude-opus-4-8へ(またはエイリアスを更新)
• [ ] effort設定の再評価。デフォルトは全サーフェスでhigh。コーディング・高自律タスクはxhighを明示
• [ ] コンテキストウィンドウの互換用betaヘッダがあれば削除(API/Bedrock/Vertexで1Mがデフォルト、Foundryは200k)
• [ ] 指示更新のために会話履歴を組み直しているなら、mid-conversation system messageへの切り替えを検討(プロンプトキャッシュのヒットを保てる)
• [ ] 拒否応答の処理がstop_detailsを読むようになっているか確認
• [ ] 選んだeffortレベルでコストとレイテンシを再ベースライン

Claude Codeやエージェントを使っているなら、/claude-api migrate this project to claude-opus-4-8 でClaude APIスキルが移行を自動適用してくれます。

2. モデルとしてのClaude Opus 4.8

Claude Opus 4.8は、Anthropicの最上位(Opusティア)で最も高性能なモデルであり、4.7を土台にしています。基本仕様は以下の通りです。

ベンチマーク面では、Anthropicのローンチ記事に、同社自身の評価に加えて早期利用企業・評価提供者による結果が紹介されています。

Anthropic公式サイトに掲載されていることと、Anthropic自身が実施した評価であることは別物なので、帰属を分けて示します。

• Super-Agent Benchmark（外部の評価提供者による結果）:
  すべてのケースをエンドツーエンドで完了した唯一のモデルで、従来のOpusおよびGPT-5.5を、コスト同等で上回るとされる。
  
• Legal Agent Benchmark（外部の評価提供者による結果）
  記録上の最高スコアを達成し、all-pass基準で総合10%を初めて突破したとされる。
  
• 誠実性（honesty、Anthropic自身の評価）
  自分が書いたコードの欠陥を指摘せずに通過させる頻度が、Opus 4.7の約4分の1（early evaluations）。「見逃さなくなった」のではなく、見逃す確率が大きく下がった、という位置づけです。

価格は4.7と据え置きである点が重要です。性能向上を「同じコストで」受け取れる、というのが4.8の立て付けです。

3. 振る舞いの変化 — 4.7から4.8で何が変わったのか

公式の「What's new」では、4.7と比べた改善領域として次の3つが挙げられています。
これらはAPIの破壊的変更ではありませんが、プロンプトやスキャフォールディングの見直しにつながる可能性があります。

1. 長時間エージェンティック・コーディング(long-horizon agentic coding)
   long-contextの取り回しが改善し、コンパクション(文脈圧縮)の発生回数が減り、コンパクション後の復帰品質も上がった。長いエージェント実行トレースが、コンパクションを挟んでも脱線しにくくなっています。
   
2. 推論effortの較正(reasoning effort calibration)
   各effortレベルでの挙動が、より幅広いドメインで安定した。
   
3. ツール起動(tool triggering)
   タスクが必要としているツール呼び出しをスキップしてしまうケースが減った。4.7で一部ユーザーが報告していた問題です。

加えて、アダプティブシンキングが有効なとき、4.8は同じeffortレベルでも無駄な思考トークンを減らします。

ターンごとに「考えるべきか」を判断し、単純な参照や短いエージェントステップでは即答し、複雑な多段問題では考えてから答えます。bimodal(難易度がばらつく)ワークロードで効いてくる改善です。

4. 補足：Claude Code利用者も知っておきたいMessages API側の変更

Claude Code経由でしか使わない人でも、背後のMessages APIの挙動を知っておくと「なぜそうなるのか」が腑に落ちます。

4.7から引き継がれた制約と、4.8で新しく入った点を整理しておきましょう

4.7から引き継がれた制約(変更なし)

• サンプリングパラメータは非対応:temperature / top_p / top_k に非デフォルト値を渡すと400エラー。挙動の制御はプロンプトで行う。
• アダプティブシンキングが唯一の思考モード:thinking: {type: "enabled", budget_tokens: N}(固定思考バジェット)は400エラー。thinking: {type: "adaptive"}とeffortパラメータで思考の深さを制御する。

# Before (Opus 4.6 以前)
thinking = {"type": "enabled", "budget_tokens": 32000}

# After (Opus 4.7 以降)
thinking = {"type": "adaptive"}
output_config = {"effort": "high"}

4.8で新しく入った/見直された点

• mid-conversation system messages
  role: "system" のメッセージを、ユーザーターンの直後にmessages配列内へ置けるようになった(配置ルールあり)。長い会話の途中で、システムプロンプト全文を貼り直さずに指示を追記でき、それ以前のターンのプロンプトキャッシュのヒットを保てる。betaヘッダ不要。
  
• refusal stop details
  拒否応答に付くstop_detailsオブジェクト(4.7から利用可能だったもの)が公式に文書化された。モデルがリクエストを拒否したとき、既存のrefusal理由に加えて拒否のカテゴリを示すので、アプリ側で拒否の種類を判別しやすい。
  
• 最小キャッシュ可能プロンプト長が1,024トークンに低下
  4.7では短すぎてキャッシュできなかったプロンプトが、コード変更なしでキャッシュエントリを作れるようになった。
  
• effortレベルの再較正
  各effortレベルの裏側のトークン配分が4.7から変化。mediumはやや多めに、highはやや少なめに、xhighは大幅に多く思考する。4.7でレベルごとにコストやレイテンシをチューニングしていたなら、同じレベルで一度ベースラインを取り直してから調整すること。

5. 新機能

4.8のローンチに合わせて投入された主な新機能をまとめます。

注目はやはりdynamic workflowsです。

「数十万行のコード移行」のような、ひとつの会話文脈では編成しきれない規模のタスクを、スクリプトに落として並列実行できます。

Claude CodeでのこれはAnthropicが「very large-scale problems」と表現する領域への対応で、第11章で詳しく扱います。

またファストモードは、Opus 4.7／4.6のFast mode価格（入力$30・出力$150）から、Opus 4.8では入力$10・出力$50へと3分の1に引き下げられました（2.5倍速で動作）。レイテンシが効くインタラクティブ用途で現実的な選択肢になっています。Claude Code（/fast）での具体的な使い方とコスト上の注意は第9章で扱います。

第2部：Claude Code CLI版で使うOpus 4.8

6. Claude CodeにおけるOpus 4.8の前提

Claude CodeでOpus 4.8を使うには、いくつか前提があります。

• バージョン:Opus 4.8にはClaude Code v2.1.154以降が必要。古い版だとモデルピッカーに出ません。claude updateで更新してください。
  
• エイリアス解決:Anthropic APIではopusエイリアスがOpus 4.8に解決されます。一方、Claude Platform on AWSではopusはOpus 4.7に解決される点に注意。Bedrock / Vertex / FoundryではopusはOpus 4.6に解決されるため、新しいモデルはフルモデル名を明示するか、ANTHROPIC_DEFAULT_OPUS_MODELを設定して使います。
  
• デフォルトモデル:アカウント種別ごとのdefaultの解決先は下表の通り。

特定バージョンに固定したい場合は、エイリアスではなくフルモデル名(claude-opus-4-8)を使うか、対応する環境変数(ANTHROPIC_DEFAULT_OPUS_MODEL)を設定します。

7. Claude Codeの基本操作 — モデルとeffortの設定

モデルの設定は優先度の高い順に次の方法があります。

1. セッション中:/model <alias|name> で即時切り替え、引数なしの/modelでピッカーを開く
2. 起動時:claude --model <alias|name>
3. 環境変数:ANTHROPIC_MODEL=<alias|name>
4. 設定ファイル:modelフィールドで恒久設定

v2.1.153以降、/modelでの選択はユーザー設定のmodelフィールドに書き込まれ、新規セッションのデフォルトになります。ピッカーではEnterで「切り替え＋デフォルト保存」、sで「このセッションのみ」。

# Opusで起動
claude --model opus

# セッション中にSonnetへ切り替え
/model sonnet

// 設定ファイル例
{
    "model": "opus"
}

現在のモデルの確認は、ステータスライン(設定していれば)か/statusで行えます。

8. 日常運用のリズム — Claude Codeをふだんどう使うか

4.8は4.7以上に「自律的」なモデルです。公式のプロンプティングガイドが繰り返し強調しているのは、最初のユーザーターンに情報を集約せよという点です。

ambiguous or underspecified prompts conveyed progressively over multiple user turns tend to relatively reduce token efficiency and sometimes performance.(曖昧で、複数ターンに分けて段階的に伝えるプロンプトは、トークン効率を相対的に下げ、ときに性能も下げる)

4.8は自律性が高いぶん、最初に「タスク・意図・制約」を明確に渡すほど、人間の介入回数を減らしつつ性能とトークン効率の両方を最大化できます。インタラクティブなコーディングでは、4.8はユーザーターン後により多く推論する傾向があり、これが長丁場のコヒーレンス・指示追従・コーディング能力を上げる一方で、トークン消費も増やします。

実務的なリズムとしては

• 着手前に、意図・完了条件・触ってよい/いけないファイル・制約を初回プロンプトに書く
  
• 4.7時代に入れていた「3ツール呼び出しごとに進捗を要約せよ」のような進捗報告の足場(scaffolding)は、一度外した状態と比較してみる。4.8は長いトレースを通じて、より定期的で質の高い更新を自分で出すため、足場が不要なことが多い（ただし製品UIや監査上、一定間隔の進捗通知が必要なケースは残す）
  
• インタラクティブ用途では、auto modeのような自律機能を足し、ユーザー操作の回数を減らす

9. Effort Levelの使い分け

effortは、4.8においておそらく過去のどのOpusよりも重要な設定です。

公式が「Effort is likely to be more important for this model than for any prior Opus」と書いているほどで、アップグレード時には積極的に実験することが推奨されています。

Claude Codeで使えるeffortレベルと、Opus 4.8での推奨は次の通りです。

4.8はeffortレベルを厳密に守ります。特に低い側で顕著です。lowとmediumでは、モデルは「言われたこと」にスコープを限定し、それ以上のことには踏み込みません。レイテンシ・コストには良い反面、そこそこ複雑なタスクをlowで走らせると「考え不足(under-thinking)」のリスクがあります。

複雑な問題で浅い推論が見られたら、プロンプトで回避しようとするのではなく、effortをhighかxhighに上げるのが正攻法です。どうしてもレイテンシのためlowに留めたいなら、ピンポイントで指示を足します。

This task involves multi-step reasoning. Think carefully through the problem before responding.

xhighまたはmaxで走らせるときは、サブエージェントやツール呼び出しを跨いで思考・行動する余地を確保するため、max_tokensを大きめに。64kトークンから始めて調整するのが目安です。

Claude Code側の設定方法(優先度順:環境変数 > 設定 > モデルデフォルト):

• /effort:引数なしでスライダー、レベル名で直接指定、/effort autoでモデルデフォルトに戻す
• /model内:左右矢印キーでeffortスライダーを調整
• --effortフラグ:単一セッション向け
• CLAUDE_CODE_EFFORT_LEVEL環境変数(全方法に優先)
• 設定ファイルのeffortLevel(low/medium/high/xhigh。maxとultracodeはセッション限定で不可)
• スキル/サブエージェントのフロントマターのeffort

なおlow〜xhighはセッションを跨いで持続しますが、maxは(環境変数経由を除き)現在のセッション限定です。また、Opus 4.8を初めて使うとき、Claude Codeは以前に別モデルで設定したレベルがあっても、4.8のデフォルトであるhighを適用します。切り替え後は/effortで選び直してください。

一回限りの深い推論が欲しいときは、プロンプトのどこかにultrathinkという語を入れます。Claude Codeがこのキーワードを認識し、その場限りの推論強化指示を追加します(セッションのeffort設定は変わりません)。"think"や"think hard"などは通常のテキストとして扱われ、キーワードにはなりません。

Fast mode（ファストモード）— 同じ品質で速度を上げる

effortが「思考の深さ」を調整するのに対し、**Fast modeは「同じモデル・同じ品質のまま応答速度を上げる」**機能です。別モデルではなく、Opusを速度優先のAPI構成で動かすもので、ライブデバッグや高速イテレーションなど、コストよりレイテンシが効く場面向けです。

Claude Code CLIでは/fastでトグルします（/fastを打ってTab、または設定ファイルの"fastMode": true）。要点を整理します。

# Fast modeのオン／オフ（CLI）
/fast

注意点が2つあります。第一に、会話の途中でFast modeを有効化すると、その時点の会話文脈全体に対してFast modeの未キャッシュ入力単価が一度かかるため、深い会話で途中からオンにすると割高です。使うならセッション開始時からが安価です。第二に、Opus 4.6のFast modeは非推奨で、Opus 4.8ローンチの約30日後に削除予定です（削除後は標準速度・標準価格にフォールバック）。

Fast modeとeffortは併用できます。単純なタスクなら「Fast mode＋低effort」で速度を最大化、といった組み合わせも可能です。

10. 1Mコンテキストの正確な扱い方

Opus 4.8は1Mトークンのコンテキストウィンドウに対応していますが、「使えるかどうか」はプランによります。

ポイントは2つ。

1. Max / Team / Enterpriseでは、Opusが追加設定なしで自動的に1Mへアップグレードされます(Team StandardとTeam Premiumの両シートに適用)。opusplanを使う場合、プランモードのOpusフェーズもこのアップグレードを受けます。
2. Anthropic APIでは、Opus 4.8・Opus 4.7・Fable 5は常に1Mウィンドウで動作します。

1Mウィンドウは200Kトークンを超える分にもプレミアム課金がなく、標準価格です。エイリアスやフルモデル名に[1m]サフィックスを付けて明示することもできます。

/model opus[1m]
/model claude-opus-4-8[1m]

1Mを完全に無効化したいならCLAUDE_CODE_DISABLE_1M_CONTEXT=1を設定します(ピッカーから1Mバリアントが消えます)。

11. Dynamic Workflows（動的ワークフロー）とultracode

4.8世代でClaude Codeに加わった目玉がdynamic workflowsです。これは、Claudeが書いたJavaScriptスクリプトがサブエージェントを大規模に編成し、ランタイムがバックグラウンドで実行する仕組みです。会話文脈とは別の隔離環境で走るため、中間結果はスクリプト変数に保持され、Claudeのコンテキストには最終結果だけが返ります。

いつ使うか:ひとつの会話では編成しきれない数のエージェントが必要なとき、あるいはオーケストレーション自体を「読めて再実行できるスクリプト」として固定したいとき。公式が挙げる例は、コードベース全体のバグ掃討、500ファイルの移行、複数ソースを相互検証するリサーチ、複数の独立した観点から下書きしてから一つに絞る難しい計画、などです。

サブエージェント・スキル・エージェントチームとの違いは「誰が計画を保持するか」です。

ワークフローが優れているのは、単にエージェントを増やせるだけでなく、反復可能な品質パターンを仕込める点です。独立したエージェントに互いの発見を「敵対的にレビュー」させてから報告させたり、複数の観点で計画を起草して突き合わせたりできるため、単一パスより信頼できる結果が得られます。

起動方法は3通り:

• プロンプトにultracodeを含める(または「use a workflow」と自分の言葉で頼む)— そのタスク1件だけをワークフロー化。セッションのeffortは変わらない
• /effort ultracode — セッション中の実質的なタスクすべてに対し、Claudeが自動でワークフローを計画。xhighの推論effortと自動オーケストレーションの組み合わせ
• バンドル/保存済みワークフローを実行 — /deep-research <question>など

ultracode: audit every API endpoint under src/routes/ for missing auth checks

前提と制限:

• dynamic workflowsにはClaude Code v2.1.154以降が必要。全有料プランで利用可(Proは/configの「Dynamic workflows」行でオンにする)
• 公式が対応サーフェスとして挙げているのはCLI・Desktopアプリ・IDE拡張・claude -p(非対話モード)・Agent SDK。Claude Code on the web(Web版)は列挙されていない（第18章で後述）
• 同時実行は最大16エージェント(CPUコアが少ないマシンではより少なく)、1ランあたり総計1,000エージェントまで(暴走ループ防止)
• ワークフロー自体はファイルシステムやシェルに直接アクセスしない(読み書き・コマンド実行はエージェントが行い、スクリプトは編成に徹する)
• 同一セッション内では再開可能(完了済みエージェントはキャッシュ結果を返す)。Claude Codeを終了すると次セッションでは最初からやり直し

/effort ultracodeのultracodeは、APIのeffortレベルではありません。中身は「xhigh + ワークフローのオーケストレーション権限」で、後者はmid-conversation system messagesを通じて付与されます。

ワークフローは大量のエージェントを起動するため、会話で同じタスクをこなすより明確に多くのトークンを使います。大きなタスクの前には、1ディレクトリだけ・狭い問いだけ、といった「薄い切片」で一度回してコストを見積もるのが安全です。/workflowsビューで各エージェントのトークン消費を見ながら、いつでも停止できます(完了済みの仕事は失われません)。

12. Opus 4.8を最大限引き出すプロンプティング

4.8は既存の4.7向けプロンプトでも素のままよく動きますが、チューニングが要りやすい挙動を公式ガイドが列挙しています。

応答の長さ・冗長さ
4.8はタスクの複雑さに応じて長さを較正します(固定の冗長度ではない)。製品が一定のスタイルや長さに依存しているなら調整を。冗長さを抑えるなら:

Provide concise, focused responses. Skip non-essential context, and keep examples minimal.

否定形(〜するな)より、適切な簡潔さを示す肯定例のほうが効きます。

ツール使用の起動
4.8はツール呼び出しよりも推論を好む傾向があり、多くの場合これが良い結果になります。ツール使用を増やしたいときは、effortを上げるのが有効なレバー(high/xhighでエージェンティック検索・コーディングのツール使用が大きく増える)。それでも足りなければ、いつ・どうツールを使うべきかをプロンプトで明示します。

進捗更新
4.8は長いトレースを通じて、より定期的で質の高いユーザー向け更新を出します。「3ツール毎に要約せよ」のような足場を入れているなら外してみること。

より字義通りの指示追従:4.8はプロンプトを字義通り・明示的に解釈します(特に低effort時)。ある項目への指示を別項目に勝手に一般化せず、頼んでいないことを推測しません。長所は精度と無駄打ちの少なさ。指示を広く適用させたいなら、スコープを明示します。

Apply this formatting to every section, not just the first one.

トーン
4.8は直接的で意見を持ったスタイルに寄り、追従的な前置きが少なく、絵文字も控えめです。製品の声が温かみのある対話調なら、スタイルプロンプトを基準から見直します。

Use a warm, collaborative tone. Acknowledge the user's framing before answering.

サブエージェントの起動制御
4.8はデフォルトでサブエージェントを少なめに起動します。これはプロンプトで誘導可能なので、望ましい条件を明示します。

Do not spawn a subagent for work you can complete directly in a single response (e.g. refactoring a function you can already see).

Spawn multiple subagents in the same turn when fanning out across items or reading multiple files.

コードレビューのハーネス
4.8は過去モデルより明確にバグ発見が上手(社内評価でrecall・precisionとも向上)。ただし旧モデル向けにチューニングしたハーネスだと、最初はrecallが下がって見えることがあります。

これは能力後退ではなくハーネス効果で、「high-severityだけ報告せよ」「保守的に」といった指示を4.8が忠実に守り、基準未満と判断した発見を報告しないために起きます。発見段階では網羅性を優先させましょう。

Report every issue you find, including ones you are uncertain about or consider low-severity. Do not filter for importance or confidence at this stage - a separate verification step will do that. Your goal here is coverage: it is better to surface a finding that later gets filtered out than to silently drop a real bug. For each finding, include your confidence level and an estimated severity so a downstream filter can rank them.

フロントエンド・デザイン
4.8は強いデザイン感覚を持ち、放っておくとクリーム色の背景・セリフ体・テラコッタ系アクセントという「ハウススタイル」に寄ります。エディトリアルやポートフォリオには合いますが、ダッシュボードやフィンテックには不向き。

具体的な代替仕様を与えるか、作る前に複数案を提案させてユーザーに選ばせるのが確実です。

13. エンタープライズ運用

組織展開では、ユーザーが選べるモデルとeffortを制御する設定が要点になります。

• availableModels:managed/policy設定で、ユーザーが選べるモデルを制限。/model・--model・ANTHROPIC_MODEL・サブエージェント・フォールバックチェーンすべてに適用
• enforceAvailableModels:availableModelsの許可リストをDefaultオプションにも拡張(v2.1.175以降)
• model:セッション開始時の初期選択(強制ではない)

{
  "model": "claude-sonnet-4-5",
  "availableModels": ["claude-sonnet-4-5", "haiku"],
  "enforceAvailableModels": true,
  "env": {
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-5"
  }
}

availableModels単体は初期選択にすぎず、ユーザーはDefaultを選べてしまう点に注意。Defaultも許可リストに従わせるにはenforceAvailableModelsを、許可エイリアスの解決先バージョンを固定するにはenvブロックを併用します。

サードパーティ(Bedrock / Vertex / Foundry)では、ロールアウト前にモデルバージョンを固定しておくのが定石です。

export ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-4-8'   # Bedrock
export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-8[1m]'           # 1Mを有効化する場合

dynamic workflowsを組織全体で止めるには、managed settingsで"disableWorkflows": trueを設定するか、Claude Code admin settingsページのトグルを使います。無効化すると、バンドルワークフローコマンドが使えなくなり、ultracodeキーワードもトリガーしなくなります。

第3部：Claude Code Web版で使うOpus 4.8

14. Claude Code Web版とは何か

Claude Code on the web（以下「Web版」）は、claude.ai/code上でタスクをAnthropic管理のクラウドインフラで走らせる仕組みです。ブラウザを閉じてもセッションは継続し、Claudeモバイルアプリから監視できます。

現在、Claude Code on the web は Pro / Max / Team ユーザー、およびpremiumシートまたはChat + Claude CodeシートのEnterpriseユーザー向けにリサーチプレビューとして提供されています。

CLI版との一番の違いは「手元のマシンを占有しない」ことと「複数タスクを並列で投げられる」ことです。手元で別の作業をしながら、クラウドで移行作業を走らせる、といった使い方ができます。

15. Web版を使い始める — GitHub連携と環境設定

GitHub連携が標準的な利用方法で、コードのclone、ブランチのpush、PR作成に使われます（認証は2通り用意されています）。なお、GitHubに接続していないリポジトリも、ローカルbundleとしてクラウドへ送信できます。ただしその場合、GitHub認証がなければクラウド側からリモートへ結果をpushできません（GitLab・Bitbucketなどのbundle送信については第17章）。

環境(environment)は、ネットワークアクセス・環境変数・セッション開始前に走るセットアップスクリプトを制御します。

• セットアップスクリプト:新しいクラウドセッション開始時(Claude Code起動前)に走るBashスクリプト。依存パッケージのインストールやツール設定に使う。総実行時間は5分以内に収めると、環境キャッシュが構築される。完了後にファイルシステムがスナップショットされ、以降のセッションは依存やツールが揃った状態で高速起動する(セットアップ手順はスキップされる)
• ネットワークアクセス:デフォルトはTrusted(npm・PyPI・RubyGems・crates.ioなど主要レジストリを許可)。Noneにすると外部接続不可、Customで許可ドメインを追加できる
• Docker:利用可能。docker compose upでサービス起動。大きいイメージはセットアップスクリプトでdocker compose pullしておくとキャッシュに乗る
• 設定の引き継ぎ:クラウドで使う設定はリポジトリにコミットしておく。専用のシークレットストアはまだ無いため、機密情報を環境変数に入れる場合は、その環境を編集できる人に見える点に留意

CLAUDE_CODE_REMOTE環境変数はクラウドセッションでtrueになるので、ローカルとクラウドで処理を分けられます。

if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  # ローカルでのみ実行
fi

16. ターミナルとWeb版を行き来する

CLIとWebの行き来は、--remote(ターミナル→クラウドへ新規) と --teleport(クラウド→ターミナルへ引き込み) の2フラグが軸です。

--remote は新しいクラウドセッションを作ります。現在のディレクトリのGitHubリモートを、現在のブランチでcloneするので、ローカルにコミットがあるなら先にpushしておくこと(VMは手元ではなくGitHubからcloneする)。

claude --remote "Fix the authentication bug in src/auth/login.ts"

各--remoteは独立したクラウドセッションになるため、複数タスクを同時に走らせられます。

claude --remote "Fix the flaky test in auth.spec.ts"
claude --remote "Update the API documentation"
claude --remote "Refactor the logger to use structured output"

進行中のセッションは/tasksで監視します。

--teleport はクラウドセッションをターミナルに引き込みます。

• claude --teleport:対話的なセッションピッカー
• claude --teleport <session-id>:特定セッションを直接再開
• セッション内で/teleport(または/tp)
• /tasksからtキー

teleportの要件は、(1) 作業ディレクトリがクリーン(未コミット変更がない、なければstashを促される)、(2) 同じリポジトリのチェックアウトから実行(forkは不可)、(3) クラウドセッションのブランチがリモートにpush済み、の3点。またteleportはclaude.aiサブスク認証が必要で、APIキーやBedrock等で認証している場合は/loginでclaude.aiアカウントにサインインし直します。

CLIからのハンドオフは一方向です。--teleportでクラウド→ターミナルに引き込めますが、既存のターミナルセッションをWebへ「押し出す」ことはできません(--remoteは新規クラウドセッションを作るだけ)。ローカル→Webの送出は、Desktopアプリの「Continue in」メニューで行えます。

なお、--remote(クラウドセッション作成)と--remote-control(ローカルCLIセッションをWebから監視可能にする)は別物です。

17. Web版でのセッション運用

各クラウドセッションはclaude.ai上にトランスクリプトURLを持ち、CLAUDE_CODE_REMOTE_SESSION_ID環境変数から自分のIDを読めます。PR本文やコミットメッセージに辿れるリンクを埋め込むのに使えます。

echo "https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID/#cse_/session_}"

計画と実行を分けたいときの定番パターンは2つ:

• ローカルで計画、クラウドで実行:プランモードでアプローチを詰めてから、計画ドキュメントをクラウドに渡して実行させる
• クラウドで計画(ultraplan):Web上で計画を生成させ、ブラウザでセクションにコメントしてから、リモート実行かターミナルへの送り返しを選ぶ

claude --remote "Execute the migration plan in docs/migration-plan.md"

CIの失敗やレビューコメントへ自動で応答するAuto-fix pull requestsもWeb版の機能です。深いマルチエージェントのコードレビューを行うultrareviewも利用できます。

制限として押さえておくべき点

• レート制限
  Web版はアカウント内の他のClaude / Claude Code利用とレート制限を共有する。並列タスクを増やすと比例して消費する(クラウドVMへの別途の計算課金は無い)
  
• メモリ
  大規模ビルドやメモリ集約的なテストは失敗・強制終了されることがある。それを超える負荷は手元ハードで動かすRemote Controlを使う
  
• プラットフォーム
  リポジトリのcloneとPR作成にはGitHubが必要(Team/EnterpriseはGitHub Enterprise Serverに対応)。GitLab・Bitbucketなどはローカルバンドルでクラウドへ送れるが、結果をリモートにpushし返すことはできない

18. Web版でOpus 4.8を活かすコーディング作法

Web版は「投げて待つ」非同期スタイルが基本です。Opus 4.8の自律性の高さは、この使い方と特に相性が良い一方で、初回プロンプトの作り込みがより重要になります(途中でユーザー入力を挟みにくいため)。

• タスクを初回で完結させる
  意図・制約・完了条件・関連ファイルを最初に渡す。これは第8章のCLI向け助言と同じですが、Web版では人の介入余地が小さいぶん効きます
  
• xhighまたはhighを使う
  インタラクティブなコーディング製品では、自律機能(auto mode)を足し、ユーザー操作を減らすのが性能とトークン効率の両立につながる
  
• 並列で投げる
  独立した複数タスクは--remoteで同時に走らせ、/tasksで監視
  
• 大規模タスクの扱い
  数百ファイルの移行やコードベース全体の監査には、Dynamic Workflows／ultracodeが有効（第11章）。ただしWeb版内でのDynamic Workflows対応は公式ドキュメントに明記されていません（対応サーフェスとして列挙されているのはCLI・Desktop・IDE拡張・claude -p・Agent SDK）。確実に利用するなら、CLI・Desktop・IDE拡張で実行するか、Web版で作成した計画やセッションを--teleportでターミナルへ引き込んでから実行するのが安全です

サブエージェントはローカルと同じく動作し、.claude/agents/のサブエージェントは自動で拾われます。エージェントチームはデフォルト無効で、環境変数CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1で有効化できます。

まとめ

Claude Opus 4.8は、4.7と同じ価格で、長時間エージェンティック・コーディング、effortの較正、ツール起動、そして「自分が書いたコードの欠陥を指摘せずに通過させる頻度を大きく減らす」誠実性を改善したモデルです。実務で押さえるべき要点は次の5つに集約されます。

4.8は「設定を変えずに動く」モデルですが、「設定を見直すと真価が出る」モデルでもあります。まずは自社の代表的なコーディングタスクでhighとxhighを比較し、4.7向けに入れていた進捗報告の足場を見直すところから始めてみてください。

出典

本記事の情報は2026年6月1時点の公式ドキュメントに基づきます。仕様は変更される可能性があるため、最新情報は各出典をご確認ください。