Claude Opus 4.8 の使い方｜1M context 既定と API 設計変更点

Claude Opus 4.8 とは — 1M context 既定化と max output 128k で何が変わるか

Anthropic 公式の Claude Opus 4.8 公開ニュース と whats-new-claude-4-8 ドキュメント によれば、Claude Opus 4.8 は Claude API・Amazon Bedrock・Vertex AI の 3 プラットフォームで 1M token context window が既定値になりました。Microsoft Foundry のみ 200k が既定で、1M を使う場合は明示的な指定が必要です。max output は 128k tokens、prompt cache の最小キャッシュ可能長は従来比で 1,024 tokens に低下 しており、より細かい差分のキャッシュ活用が可能になっています。

adaptive thinking が改善されたため、同じ effort 設定でも 必要なターンのみ思考トークンを発火 する挙動に変わりました。今までは effort=high で常に長めの思考が走っていたケースでも、Opus 4.8 では入力タスクの複雑度に応じて思考量が動的に調整されます。high-resolution image input も追加され、長辺 2576px までの画像をそのまま入力できるほか、task budgets / advisor tool / computer use の各機能がサポート対象に含まれます。なお temperature / top_p / top_k を非既定値で送ると 400 エラー で弾かれる仕様は Opus 4.7 と同じで、サンプリング系パラメータをいじっている実装は注意してください。1M context を超える領域では long-context pricing が適用される可能性があるため、実運用前に プラットフォーム release notes で課金条件を必ず確認してください。

1M context 既定化が長文脈エージェントに与える影響

長文脈系エージェント(コード解析・長文要約・ドキュメント横断 RAG)の設計者にとって、1M context 既定化は チャンク戦略の再設計 を促す変更です。これまで「200k context に収めるためにチャンク分割・要約・RAG リランクで圧縮する」前提だった設計を「1M に直接流し込んで一括処理する」設計に置き換えると、精度面でも実装面でも単純化できる場面が一気に増えます。

ただし long-context pricing の課金単価は短文脈より高く設定される領域があるため、コスト試算は実利用想定で必ず再計算 してください。prompt cache を 1,024 tokens 単位で細かく効かせる戦略と組み合わせれば、長文脈の本体コストを抑えつつ繰り返しクエリの単価を下げられます。設計上は「長文脈は 1M、繰り返しは細粒度キャッシュ」という二段構えが現実解です。

Mid-conversation system messages — 長時間セッションで指示を差し替える新作法

mid-conversation system messages のドキュメント によれば、Opus 4.8 から messages 配列の user turn の後 に role: "system" を挿入できるようになりました。配置ルールがあり、system turn は assistant turn の直後には置けず、必ず user turn の後に挟む形になります。messages 先頭の system プロンプトはそのまま維持され、追加分が会話途中の指示更新として作用します。

最大のメリットは prompt cache hit を維持したまま指示を切り替えられる 点です。従来は途中で system プロンプトを変えると先頭からのキャッシュが効かなくなり、長時間セッションでは「同じ system プロンプトを最後まで貫く」設計が事実上の前提でした。Opus 4.8 では mid-conversation system message を挿入した区間以降だけがキャッシュ無効化の対象となり、初期 system プロンプトと初期ユーザーターンのキャッシュは温存されます。

設計パターン — 段階適用とトーンガイド更新

具体的な活用パターンとして、第一に 多段ワークフロー間の担当指示差し替え が挙げられます。たとえば「調査 → 設計 → 実装 → レビュー」と進む長セッションで、各フェーズの開始時に「次は実装フェーズです。コードブロック必須、自然言語の解説は最小限に」といった担当指示を差し込めば、フェーズごとに最適化された出力を得られます。

第二は トーンガイドの段階適用 で、初期は探索的・カジュアルなトーンで会話を進め、結論をまとめる段階で「ここから先は箇条書きと数値で簡潔に」と切り替えるパターンです。第三は 安全制約の動的強化 で、敏感なトピックに会話が入った段階で「ここから先は医療・法律分野は専門家相談を必ず案内すること」と制約を上書きできます。いずれも従来は「全部入りの長大な system プロンプト」で対応していた領域で、設計の自由度が一段上がりました。

stop_details の refusal 設計 — cyber / bio / null をルーティング分岐に組む

handling-stop-reasons の refusal categories セクション で、stop_details.category フィールドが正式ドキュメント化されました。値は cyber / bio / null の 3 種で、加えて人間可読の explanation フィールドが返ります。これまで stop_reason: "refusal" のみで分岐していた実装は、カテゴリ別の粒度でルーティング できるようになります。

設計パターンとしては、cyber refusal を セキュリティレビュー用フロー に流し、別エンジン(より厳格なポリシーガード付きモデル)で再評価する設計が一例です。bio refusal は 専門家確認フロー に飛ばし、医療・生命科学領域のヒューマンレビュアーに渡す設計が現実的でしょう。null(その他)は 一般 fallback として汎用的な拒否メッセージとサポート問い合わせ導線で返す形が標準解になります。

既存実装の移行 — refusal 一括分岐からの脱却

既存の stop_reason: "refusal" のみで分岐していた実装は、stop_details.category を読んで分岐先を増やす移行で対応できます。null は既存と同じ動作にフォールバックさせ、cyber / bio が来た時だけ専用フローに分岐する追加実装で、リスクを抑えながら段階導入が可能です。explanation フィールドはログとモニタリング画面に出すと、本番運用時の refusal 原因分析が一段やりやすくなります。

Claude Opus 4.7 → 4.8 移行手順 — 4.6 fast mode deprecation と adaptive thinking 改善

実装側の移行は次の 3 ステップで完了します。

1. モデル ID を claude-opus-4-8 に切り替え — context window 既定が 1M に上がる前提で「リクエスト側で context window を 200k に固定していた処理」を見直します。Microsoft Foundry を使っているシステムは 200k 既定のままなので、プラットフォーム別の分岐を整理してください。
2. effort 設定を一度見直し — adaptive thinking 改善で thinking トークン消費の挙動が変わったため、effort=high で重い処理を回している場合、Opus 4.8 では同等の品質を effort=medium で出せる可能性があり、コスト削減チャンスです。代表的なリクエストでベンチマークを取り直してから本番反映するのが安全です。
3. Opus 4.6 fast mode の利用箇所を移行 — Opus 4.6 fast mode は deprecated 表記となり、Anthropic アナウンスではおおむね 30 日後の廃止予定です。移行先は Opus 4.7 か、Opus 4.8 fast mode(research preview)のどちらかを選びます。

加えて CLAUDE_CODE_OPUS_4_6_FAST_MODE_OVERRIDE 環境変数は 2026-06-01 削除予定とアナウンスされており、ビルドスクリプトでこの環境変数を使っている箇所は早めに撤去してください。削除以降は環境変数を読んでも無効化され、サイレントに新規モデルに切り替わるリスクがあります。

prompt cache の最小キャッシュ可能長低下を活用する

prompt cache の最小キャッシュ可能長が 1,024 tokens に下がった点は地味ですが効きます。これまで「キャッシュするにはまとまった長さが必要」だった制約が緩み、会話中盤の差分プロンプト や 動的に組み立てたツール定義 など、小さい単位でもキャッシュヒットを取りに行く設計が成立します。

mid-conversation system messages と組み合わせると、長時間セッションでもキャッシュ効率を維持したまま指示を更新できる設計が現実的になりました。エージェント側で「キャッシュを切らないように指示を更新する」運用ルールを 1 本書いておけば、長セッションでの累積コストが目に見えて下がります。

Claude Code v2.1.154 同期リリース — Opus 4.8 既定化と Dynamic Workflows の変更点

Claude Code v2.1.154 リリースノート によれば、新規セッションの既定モデルが Opus 4.8 に切り替わりました。Max プランでは Opus 4.8 fast mode が既定で、/effort xhigh も既定で有効です。複雑タスクのデフォルトクオリティが底上げされ、/effort を明示しない場合の出力品質が一段上がります。

最大の新機能は Dynamic Workflows (/workflows) で、複数ステップのエージェントプランを定義・実行できます。/workflow new でステップを宣言し、/workflows run <name> で実行する形で、これまで手動で claude -p をパイプしていた多段処理を一本化できます。Lean system prompt が既定となり、プロンプト先頭の固定オーバーヘッドが削減されたほか、Plugin の defaultEnabled: false 宣言や /plugin Discover タブのピン留めなど、エコシステム周辺の整備も同時に進みました。

スクリプトが追随すべき後方互換破壊点

社内スクリプトを書いている方が要注意なのは /simplify の挙動再変更 です。v2.1.152 で別コマンドのラッパーに変わっていた /simplify が、v2.1.154 で 独自挙動に再変更 されています。/simplify をスクリプト内で呼んでいる場合、想定挙動と一致するか必ず再確認してください。

/effort スライダーの表記が「Faster/Smarter」に刷新された点はユーザー体験のみへの影響で、API 互換性には影響しません。安全修正として rm -rf $HOME 末尾スラッシュ時のブロック修正、$TMPDIR 整合修正も入っており、危険コマンド自動拒否の堅牢性が一段上がっています。

出典

• Claude Opus 4.8 公開ニュース(Anthropic)
• Opus 4.8 機能差分(whats-new-claude-4-8)
• mid-conversation system messages 仕様
• stop_details 仕様(handling-stop-reasons#refusal-categories)
• プラットフォーム release notes
• Claude Code v2.1.154 リリースノート(GitHub)