Claude Opus 5.0 完全ガイド　モデル仕様とAPI・Claude Code運用ポイント

こんにちは！

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

Opus 4.8（5月28日リリース）からわずか2ヶ月での世代交代です。このあたりのスピード感、加速していますね。

さて、当ブログではClaude Opus 4.7 完全ガイド、Claude Opus 4.8 完全ガイドとOpusの世代を追いかけてきましたが、今回のOpus 5は過去2回の「4.x内のアップデート」とは立て付けが根本的に違います。

何が違うのか。まず、Opus 5は「最上位モデル」ではありません。

Anthropicのラインナップには2026年6月9日リリースのClaude Fable 5が最上位として存在し、Opus 5はその下位、Sonnet 5の上位という「中上位」ポジションで投入されました。

Opusという名前が「最上位ティア」を意味した時代は、Fable 5の登場で終わっています。

そのうえでAnthropicはOpus 5を「Fable 5のフロンティア級の賢さに、半額で迫るモデル」と位置づけ、一部ベンチマークではFable 5を上回るスコアさえ公表しています。

価格はOpus 4.8と同じ入力$5・出力$25。

つまり「最上位ではないが、実務ではこれが本命」という、いままでのOpusにはなかったキャラクターです。

しかも思い出してほしいのですが、Fable 5は6月12日に米国政府の指令で一時提供停止になり、7月1日に復帰するという波乱を経ています（経緯はFable 5・Mythos 5 提供停止の経緯で詳しく書きました）。

この事件の中心にあった「安全分類器」が、実はOpus 5にも搭載されました。

Opus 4.8にはなかったものが載ったわけで、これは移行時に必ず知っておくべき変化です（第7章で詳しく扱います）。

本稿は長編なので、頭から通読する必要はありません。気になる章だけ拾い読みしてください。出典は記事末にまとめてあります。

想定読者は、Opus 4.8からの移行を検討しているエンジニア、Fable 5とOpus 5のどちらを使うべきか判断したいテックリード、Claude Codeをチームで運用しているリードエンジニア、そしてAPI利用のコスト最適化を考えている方です。

目次

第1部　Claude Opus 5とは何か

• 1. Claude 5ファミリーの中でのOpus 5の位置づけ
• 2. Claude Opus 5の基本仕様
• 3. ベンチマークで見る「Fable 5超え」の中身
• 4. thinkingまわりで変わる2つのAPI破壊的変更
• 5. 移行チェックリスト（公式ガイドより）
• 6. 新機能・関連機能まとめ

第2部　APIで使うときの注意点

• 7. 4.8にはなかった安全分類器が搭載された
• 8. Effortの使い分け
• 9. エージェントに予算感覚を持たせるTask budgets（beta）
• 10. Opus 5を最大限引き出すプロンプティング

第3部　Claude Codeで使うOpus 5

• 11. Claude CodeでOpus 5を使う前提
• 12. Claude Codeのeffort設定は引き継ぎ挙動に注意
• 13. Fast modeの変更点
• 14. フラグされたらどうなるか、自動モデルフォールバックの仕組み
• 15. 1Mコンテキストとopusplan
• 16. 日常運用のリズム

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

前回記事で扱ったOpus 4.8から、Opus 5では主に次の点が変わりました。

詳細は各章で扱いますが、まず全体像です。

段階的改善ではなく「step-change（段差のある改善）」

公式ドキュメント自身が4.8比を「incrementalではなくstep-change」と表現しています。深い推論・長時間エージェンティックタスク・test-time compute scalingで最大の伸びです（第3章）。

thinkingがデフォルトON

4.8ではthinkingフィールド無しのリクエストは思考なしで動きましたが、Opus 5では同じリクエストが思考ありで動きます。max_tokensの見直しが必要です（第4章）。

thinking無効化はeffort `high`以下でのみ可能（破壊的変更）

thinking: {type: "disabled"}とeffort xhigh/maxの組み合わせは400エラーになります（第4章）。

effortの推奨スタート地点が変化

APIデフォルトは従来どおりhighのままです。公式ガイドの推奨が4.7/4.8の「コーディングはxhighで開始」から、Opus 5では「highで開始し、要求の厳しい作業のみxhighへ」に変わり、low/mediumの積極活用が明記されました（第8章）。

Web Fetchサーバーツール非対応

Opus 4.8で使えるWeb FetchツールはOpus 5では利用できません（Web検索とは別機能です）。利用中のAPI統合は代替設計が必要です（第5章）。

安全分類器が搭載された

4.8にはなかったモデル固有のサイバー・生物学分類器がOpus 5には載っています。介入頻度はFable 5より約85%少ないとされますが、4.8からの移行では新しい制約になります（第7章）。

ナレッジカットオフが2026年5月

Fable 5・Sonnet 5（いずれも2026年1月）より新しく、現行ラインナップで最も新しい知識を持ちます（第2章）。

新機能・関連機能

会話途中のツール変更（beta）、fallbacksパラメータの"default"モード（beta）、Task budgets（beta）、キャッシュ最小長が512トークンに低下、などがあります（第6章・第7章・第9章）。

価格は据え置き

入力$5・出力$25のまま。Fast modeも$10/$50でOpus 4.8と同額です（第2章）。

Priority Tier非対応

Opus 4.8では使えたPriority TierがOpus 5では未サポートです。コミットメントがある組織は容量計画に注意してください（第5章）。

なお、Opus 4.8向けのコードはモデルIDの差し替えだけで動くとは限りません。

thinkingデフォルトの変化と、thinking無効化の制限という2つの挙動変更があるため、移行チェックリスト（第5章）を一度通すことをおすすめします。

第1部　Claude Opus 5とは何か

1. Claude 5ファミリーの中でのOpus 5の位置づけ

まず、2026年6月からの2ヶ月弱でAnthropicのラインナップがどう変わったかを整理します。

この期間、Anthropicは4つのモデルを立て続けに投入しました。

• 6月9日 Claude Fable 5 / Claude Mythos 5 リリース（新設の最上位「Mythosクラス」。ベンチマーク解説）
• 6月12日 米商務省の輸出管理指令により両モデルの提供を全世界で停止（経緯の詳細）
• 6月26日 Mythos 5が審査済み米国組織限定で一部復帰
• 6月30日 輸出規制が解除。同日、Claude Sonnet 5リリース（導入価格$2/$10、2026年8月31日まで。以降$3/$15）
• 7月1日 Fable 5がclaude.ai・Claude Code等で全面復帰
• 7月24日 Claude Opus 5リリース。同日、Opus 4.7のFast modeが提供終了

この結果、現在のラインナップは上から Fable 5（$10/$50）、Opus 5（$5/$25）、Sonnet 5（$3/$15）、Haiku 4.5（$1/$5）という4層構造です。

Opus 5の公式な位置づけは「complex agentic coding and enterprise work（複雑なエージェンティックコーディングとエンタープライズ業務）向け」です。

AnthropicはこれをClaude Maxの新デフォルトモデル、Proプランで使える最上位モデルに据えました。

「日常の主力はOpus 5、真にフロンティアな仕事だけFable 5」という使い分けをAnthropic自身が推奨する構図です。

（出典はAnthropic公式モデル一覧。価格・カットオフは2026年7月27日時点）

見落とされがちですが重要なのがナレッジカットオフです。

Opus 5のreliable knowledge cutoffは2026年5月で、
Fable 5・Sonnet 5の2026年1月より4ヶ月新しく、現行ラインナップ最新です。

新しめのライブラリやAPIを扱う場面では、「上位」のFable 5より新しい知識を持っている可能性があります。

ただしカットオフの新しさが個別仕様の正確性を保証するわけではありません。後述のとおりOpus 5はWeb Fetchサーバーツール非対応（第5章）なので、最新情報の取り込みはWeb検索ツールや自前の取得で補い、公式ドキュメントとの照合は引き続き必要です。

LLM各社の料金体系の比較はLLM API価格まとめ、Fable 5のコスト問題についてはFable 5のコストと展望も参考にしてください。

Fable 5は「トークン消費が激しい」という利用者の不満が広く報じられており、Fortuneによれば、Opus 5がトークン効率を前面に出すのはこの不満への回答でもあります。

7月9日にリリースされたOpenAIのGPT-5.6も経済的なトークン消費を売りにしており、「賢さ」から「賢さとコストの釣り合い」へ競争軸が移っていることがわかります。

2. Claude Opus 5の基本仕様

4.8から引き継がれた仕様も多い一方、「1Mがデフォルトかつ最大で、そもそも小さいコンテキストのバリアントが存在しない」「thinkingがデフォルトON」の2点は世代の切り替わりを感じさせます。

なおclaude-opus-5はエバーグリーンなポインタではなく固定スナップショットです（Claude 4.6世代から続く日付なしID方式）。

3. ベンチマークで見る「Fable 5超え」の中身

Anthropicのローンチ発表は、複数のベンチマークで「Opus 5がFable 5を上回る」と主張しています。

当ブログの流儀に従い、誰が測った数値かを区別しながら見ていきます。

Frontier-Bench v0.1（Anthropicによる内部実行）

System Cardの評価サマリー表でOpus 5が43.3%と比較対象モデル中トップ。Fable 5の33.7%、Opus 4.8の18.7%を大きく上回り、4.8比では2倍超です。しかもタスクあたりコストは低いとされます。

ローンチ時の公式チャートにはeffortレベル別の複数値も示されているため、43.3%がOpus 5のeffort別ピーク値とは限りません。

ARC-AGI 3（ARC Prizeによる検証済み外部評価）

Opus 5はhigh effortで30.16%（公表時の丸め値30.2%）。次点とされるGPT-5.6 Solの7.8%の約3.9倍です（Anthropicの発表文は「3倍」と控えめに表現しています）。

Opus 4.8は1.5%とほぼゼロでした。なお評価期間が短かったため、Opus 5のmaxはARC-AGI 3では未評価です。

CursorBench 3.2（Cursorによる外部評価）

max時にOpus 5が70.0%、Fable 5が70.5%と0.5ポイント差。タスクあたり平均コストはOpus 5の$8.23に対しFable 5は$17.32と2倍超です。

ただしCursor自身が「小さなスコア差は統計的に有意でない可能性がある」と注記しています。

OSWorld 2.0（コンピュータ操作。Anthropic評価、System Card記載）

70.57%（5回実行の平均初回成功率）でOpus 4.8の55.7%から大幅改善。Fable 5のベスト結果を約3分の1のコストで上回るとされます。

Zapier AutomationBench（外部の評価提供者による結果）

合格率が次点モデルの約1.5倍です（同等のタスクあたりコストで）。

ライフサイエンス（Anthropic自身の評価）

有機化学タスクでOpus 4.8比+10.2ポイント、タンパク質予測で+7.7ポイント。AnthropicはOpus 5を「科学研究向けに最も高性能な一般提供モデル」と押し出しています。

注意点を2つ挙げます。

第一に、数値の帰属は3種類に分かれます。(a) Anthropicが自社で実行した評価（Frontier-Bench・OSWorld・ライフサイエンス）、(b) ベンチマーク提供者が実行・掲載した外部評価（ARC Prize・Cursor・Zapier）、(c) それらを報じた報道です。

(b)は自己申告ではありませんが、第三者コミュニティによる独立追試とも別物です。

第二に、「Fable 5超え」はすべてのベンチマークの話ではありません。

Anthropic自身、最高難度の長時間自律タスクではFable 5を推奨し続けており、サイバーセキュリティのエクスプロイト能力では「Mythos 5に及ばない」と明言しています。

ブラインド投票（Arena系）やLLMランキングでどう出るかは、独立評価が出揃ってからの答え合わせになります。

TechCrunchは、Anthropicが強調した特性として「自分の成果物を検証し、成功するまで丁寧にイテレーションする」点を挙げています。

早々に勝利宣言せず、検証して直す。これは後述するプロンプティングの変化（自己検証と重複する再検証指示を外す。第5章・第10章）と表裏一体の、Opus 5の性格を象徴する変化です。

4. thinkingまわりで変わる2つのAPI破壊的変更

Opus 4.7から4.8のときは「モデルID差し替えだけで動く」移行でした。

今回はAPIパラメータ上の破壊的変更が2つあります。加えて機能面では、前述のWeb FetchとPriority Tierの非対応という実質的な非互換もあります（第5章のチェックリストで扱います）。

変更その1、thinkingがデフォルトONになった

Opus 4.8ではthinkingフィールドを付けないリクエストは思考なしで動きました。

Opus 5では同じリクエストが思考ありで動きます（モデルがターンごとに思考の要否と深さを判断するアダプティブシンキング）。

ワイヤ上の値は変わっておらず、thinking: {type: "adaptive"}を明示しても同じ挙動です。

実務上の注意はmax_tokensです。

max_tokensは思考と本文の合計に対するハードリミットなので、4.8で思考なしで動かしていたワークロードをそのまま移すと、思考トークンが加わったぶん本文が途中で切れる（stop_reason: "max_tokens"）ことがあります。

thinkingなし前提で小さめのmax_tokensを設定していた箇所は見直してください。

変更その2、thinking無効化はeffort `high`以下のみになった

旧挙動を維持したい場合はthinking: {type: "disabled"}を渡せますが、Opus 5ではeffortレベルがhigh以下のときしか受け付けられません。

thinking: {type: "disabled"}とeffort xhigh/maxの組み合わせは400エラーになります。

4.8ではこの組み合わせが通っていたので、移行前に該当リクエストを洗い出しておく必要があります。

チェックはリクエスト単位で毎回行われるため、「会話の前半は通っていたのに、途中でeffortを上げた瞬間に400」ということも起こります。

# 4.8では通るが、Opus 5では400エラーになるリクエスト
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "disabled"},
    output_config={"effort": "xhigh"},   # disabled と xhigh の組み合わせが不可
    messages=[{"role": "user", "content": "..."}],
)

# 対処A thinkingフィールドを外す（デフォルトの思考ありに戻す）
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    output_config={"effort": "xhigh"},   # thinking はデフォルトON
    messages=[{"role": "user", "content": "..."}],
)

# 対処B thinking無効を維持して effort を high 以下へ
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "disabled"},
    output_config={"effort": "high"},    # high / medium / low なら可
    messages=[{"role": "user", "content": "..."}],
)

さらに公式ドキュメントは、thinkingを無効化した場合の副作用を明記しています。

思考なしのOpus 5は、まれにツール呼び出しをtool_useブロックではなく本文テキストとして書いてしまうことがあります。呼び出しは実行されず、エージェントループでは漏れたテキストが会話履歴に残って後続ターンにも影響します。

<thinking>等の内部XMLタグを可視出力に混ぜてしまうこともあります。

公式の推奨は「thinkingは有効のまま、コストは低effortで制御する」です。

ほとんどのタスクで「thinking有効かつlow effort」のほうが「thinking無効」より同等コストで良い結果になるとされています。どうしても無効化が必要な統合向けのプロンプト緩和策は第10章で扱います。

5. 移行チェックリスト（公式ガイドより）

公式移行ガイドのチェックリストを、実務の順序に並べ直したものです。

1. モデル名をclaude-opus-4-8からclaude-opus-5へ更新する
2. Web Fetchサーバーツールを使っているリクエストを洗い出す。Opus 5では利用できないため、Web検索ツール・クライアント側での取得・該当処理だけ別モデルへルーティング、等の代替を設計する
3. thinkingフィールド無しで運用していたワークロードを洗い出す（Opus 5では思考ありで動く）。max_tokensを見直すか、thinking: {type: "disabled"}とeffort high以下で旧挙動を維持する
4. thinking: {type: "disabled"}とeffort xhigh/maxを併用しているリクエストを修正する（400エラーになる）
5. effort設定を白紙から再評価する。旧モデルから持ち越さず、自分のevalsでeffortスイープを取り直す。low/mediumはコスト・レイテンシ制御として積極的に試し、maxは能力優先タスクで試す価値あり。xhigh/maxで走らせるならmax_tokensは64k以上から
6. キャッシュ境界付近のプロンプトを確認する（512トークン以上でキャッシュ可能に。4.8では1,024）
7. stop_reason: "refusal"のハンドリングを確認し、fallbacks: "default"（beta）の採用を検討する（第7章）
8. Priority Tierのコミットメントがある組織は容量計画を分けて立てる。Priority TierはOpus 5非対応で、Opus 4.8では引き続き利用可能
9. エージェンティックワークロードならTask budgets（beta）とmid-conversation tool changes（beta）を検討する（第9章・第6章）
10. 長さ・冗長性のプロンプトを再調整する。Opus 5は可視応答も成果物ドキュメントも長くなりがちで、effortを下げても短くならない（第10章）
11. 旧モデル向けの再検証指示（「最後に検証ステップを入れよ」「ダブルチェックせよ」「サブエージェントで検証せよ」等）を削除する。Opus 5は言われなくても自己検証するため、残すと過剰検証でトークンを浪費する。ただし、指定テストの実行・lint・型検査といったプロジェクト固有の受入条件は削除しない（第10章）
12. 自分のワークロードでコストとレイテンシを再ベースラインする

このうち5・10・11は「壊れないが最適でなくなる」系で、飛ばしてもエラーにはなりません。

ただし11（重複する再検証指示の削除）は公式が「品質を落とさずトークン削減」と明言している数少ない項目なので、優先度高めで対応する価値があります。

6. 新機能・関連機能まとめ

Opus 5で利用できる新機能・関連機能を整理します。

Opus 5と同時に追加された機能だけでなく、既存機能のOpus 5対応も含みます。詳細は該当章で扱います。

Mid-conversation tool changesは地味ながらエージェント開発者に効く変更です。

従来、ツールリストを変えるとキャッシュ済みプレフィックスが無効化されるため、セッションの最初に全ツールを渡しておくのが定石でした。

betaヘッダmid-conversation-tool-changes-2026-07-01を付けると、タスクの進行に応じてツールを段階的に公開したり退役させたりしても、それ以前のターンのキャッシュヒットが保てます。

4.8で入ったmid-conversation system messages（会話途中のシステムメッセージ追記）の続編と考えるとわかりやすい機能です。

第2部　APIで使うときの注意点

7. 4.8にはなかった安全分類器が搭載された

先に重要な事実を押さえてください。

Fable 5と同系のモデル固有安全分類器（サイバーセキュリティ・生物学）が、Opus 5にも搭載されました。

そしてOpus 4.8にはこの分類器は載っていません。

公式ドキュメントが分類器つきと明記しているのはFable 5とOpus 5だけです。フラグされたリクエストの逃がし先がOpus 4.8であること自体が、4.8に同じ分類器がないことの裏付けです。

なお4.8時代にも、プラットフォーム側のUsage Policyセーフガードの誤検知はありました。6月の記事で扱ったものがそれで、モデル固有分類器とは別の層の話です。

つまり4.8から移行するユーザーにとって、これは新たに加わる制約です。

「安全になった」という話ではなく、「分類器が付いてしまった。ただしFable 5ほど頻繁には介入しない」と読むのが正確です。

そのうえで、Fable 5の提供停止で業務が止まる経験をした直後という文脈では、Fable 5との違いにも実務上の意味があります。ポイントは4つあります。

(1) アライメント自体は歴代最良

Anthropicの自動挙動監査（automated behavioral audit）で、Opus 5のミスアライン挙動スコアは2.3（低いほど良い）。

Opus 4.8・Sonnet 5・Fable 5を含む近年のモデルで最良で、「最もアラインされたOpusであり、悪用に誘導されにくい」とAnthropicは主張しています（自己評価である点に留意してください）。

(2) 分類器の介入はFable 5比で約85%減（ゼロではない）

Fable 5はサイバーセキュリティ能力の高さゆえに強力な安全分類器を常時走らせており、これが正当なセキュリティ業務まで妨げるという不満がありました。

Opus 5では素のエクスプロイト能力をMythos 5より意図的に抑えたうえで、分類器の介入頻度を「Fable 5の約85%減」に抑えたとしています。

裏を返せば、4.8では起きなかったモデル分類器の介入が、Opus 5では一定頻度で起きるということです。

線引きとしては、ソースコードを対象とする脆弱性発見は許可する一方、バイナリを対象とした脆弱性スキャンやエクスプロイト生成はブロックする設計です。

防御的セキュリティのための特別枠であるProject Glasswing（Mythos 5の提供枠組み）についてはGlasswing解説記事を参照してください。

Cyber Verification Program（CVP）参加済みの企業・研究者は、制限が緩和された状態でOpus 5に即アクセスできます。

(3) フラグ時の自動フォールバック（API側）

分類器がリクエストをフラグしたとき、エラーで終わらせず別モデルに自動で流す選択肢が入りました。

fallbacksパラメータの新しい"default"モード（fallbacks: "default"）は、拒否カテゴリに応じてAnthropic推奨のフォールバックモデルを自動選択します。たとえばOpus 5のサイバー系拒否はOpus 4.8へ流れます。

従来の明示的なモデルリスト指定も引き続き可能で、"default"モードにはserver-side-fallback-2026-07-01ベータヘッダが必要です。

(4) データ保持の違い（公式ドキュメントで確認）

Anthropic公式の「API and data retention」ドキュメントは、30日データ保持が必須の「Covered Models」としてFable 5とMythos 5を明記しており、この2モデルはZDR（ゼロデータリテンション）では利用できません。Claude CodeのモデルピッカーにもZDR環境では出ません。

Opus 5はCovered Modelsに含まれておらず、ローンチ発表でも一般アクセスのOpus 5にモデル固有のデータ保持要件は課されていません。

したがってClaude APIでZDR契約を持つ組織は、ZDR適格な機能の範囲でOpus 5を利用できます。

ただしZDRは組織単位の契約で、Pro/Max等のコンシューマープラン自体は対象外です。Batch APIやコード実行などZDR対象外の機能もあるため、実際の適用範囲は契約条件と機能別のZDR適格性を確認してください。

まとめると、視点によって評価が分かれる変更です。

4.8ユーザーから見れば、分類器の搭載は純粋に制約の追加です。セキュリティ・生物学が絡むワークロードでは、4.8で通っていた処理が止まる可能性があります（4.8の継続利用も選択肢です。第16章）。

一方、Fable 5ユーザーから見れば、介入頻度は約85%少なく、モデル固有の30日保持要件がなく、サイバー系の拒否には自動フォールバックも用意されているぶん、明らかに扱いやすくなっています。

なお自動フォールバックはAPIではオプトインで、Opus 5の生物学カテゴリにはフォールバック先がない（第14章）等の制約はあります。将来の規制措置まで保証するものでもありません。

8. Effortの使い分け

effortはOpus 4.7以降、Opusを使いこなす最重要レバーであり続けています。

Opus 5では公式ガイドの推奨の書き方が変わりました。

誤解しやすいので先に整理すると、APIのデフォルトは4.7以降ずっとhighのまま変わっていません。変わったのは推奨スタート地点の記述です。

4.7/4.8の公式ガイドは「コーディング・エージェンティック用途はxhighで開始（Start with xhigh for coding and agentic use cases）」と明記していました。

Opus 5のガイドは「high（デフォルト）で開始し、evalsに基づいて調整せよ。要求の厳しいコーディング・エージェンティック作業ではxhighへステップアップ（Start with high, the default … step up to xhigh for demanding coding and agentic work）」という書き方になっています。

表にします。

書き方が変わった背景は、Opus 5の低effortの効率改善です。

公式は「lowとmediumが、上位設定のわずかなトークンとレイテンシで強い品質を出す」とし、「low/mediumをコストと応答時間の主要コントロールとして自由に（liberally）使え」とまで書いています。

4.8時代の「とりあえずxhigh」を無条件に持ち込むと、品質差が小さいのにトークンだけ倍増、ということになりかねません。

旧モデルからeffort設定を持ち越さず、自分のevalsでスイープを取り直すのが公式の明確な推奨です。

一方で上端のmaxは、追加effortを結果に変換する能力（test-time compute scaling）が歴代Opusで最も高いため、4.8時代より試す価値が上がっています。

CursorBenchでFable 5のピークに0.5ポイント差まで迫ったのもmax effort時の話です。

xhigh/maxで走らせるときは、思考とツール呼び出しの余地を確保するためmax_tokensを64k以上から始めて調整してください。

effortに関する固有の注意が2つあります。

effortは可視応答の長さを制御しない

Opus 5でeffortを下げると思考量は減りますが、ユーザー向け応答の長さは確実には短くなりません。応答を短くしたければプロンプトで明示します（第10章）。

effortは会話の途中で変えない

effortはレンダリングされるプロンプトに影響するため、リクエスト間で値を変えるとそれ以前のプレフィックスのプロンプトキャッシュが無効になります。キャッシュに依存する長いセッションでは、最初に決めた値を固定してください。

なお、thinking: {type: "disabled"}と併用できるのはhigh以下のみという制約（第4章）もeffort選択に影響します。

「思考は切りたいがeffortは上げたい」という構成はOpus 5では組めません。

9. エージェントに予算感覚を持たせるTask budgets（beta）

Opus 5でも利用できるbeta機能の中で、エージェント基盤の開発者にいちばん面白いのがTask budgetsです。

betaヘッダはtask-budgets-2026-03-13。対応はOpus 5 / Fable 5 / Mythos 5 / Opus 4.8 / 4.7で、Sonnet 5は非対応です。Opus 5固有の新機能ではなく、既存beta機能のOpus 5対応です。

output_config.task_budgetに{type: "tokens", total: N}を渡すと、思考・ツール呼び出し・ツール結果・出力を含むエージェンティックループ全体のトークン予算をモデルに伝えられます。

モデルはサーバー側で注入されるカウントダウンを見ながら、残り予算に応じて作業の優先順位を付け、予算が尽きる前に「発見の要約」「進捗の報告」といった形で優雅に着地します。

with client.beta.messages.stream(
    model="claude-opus-5",
    max_tokens=128000,
    output_config={
        "effort": "high",
        "task_budget": {"type": "tokens", "total": 64000},
    },
    messages=[{"role": "user", "content": "Review the codebase and propose a refactor plan."}],
    betas=["task-budgets-2026-03-13"],
) as stream:
    response = stream.get_final_message()

概念の整理をしておきます。

effortが「各ステップの推論の深さ」を制御するのに対し、task_budgetは「ループ全体の仕事量」を制御します。

深さのeffort、総量のtask budget、そして毎リクエストのハード上限がmax_tokensという三層構造です。

運用上の注意を4つ挙げます。

予算は助言（advisory）であり強制ではない

中断のほうが破壊的な作業の途中では超過することもあります。ハードキャップは従来どおりmax_tokensで掛けます。

最小値は20,000トークン

それ未満は400エラーになります。

小さすぎる予算は「拒否のような挙動」を引き起こす

数時間級のタスクに2万トークンの予算を渡すと、モデルはタスク自体を辞退したり、過剰にスコープを削ったり、途中で切り上げたりします。

予算設定後に不可解な拒否や早期終了を見たら、他のパラメータを疑う前にまず予算を増やしてください。

カウントダウンはモデルにしか見えない

APIレスポンスに残予算フィールドはありません。

クライアント側でremainingを毎ターン減らして送るとキャッシュを壊すうえ、二重カウントで実際より速く予算が減って見え、早じまいの原因になります。

基本は初回にtotalだけ設定してサーバー任せにします。remainingを使うのは、コンパクション（文脈圧縮）で履歴を書き換えたときに消費済みトークンを引き継ぐ場面だけです。

予算の決め方は「勘で決めない」が公式の推奨です。

まずtask_budgetなしで代表的なタスクを走らせ、ループ全体のusage.output_tokensとツール結果トークンの分布を測り、p99あたりから始めて調整します。

なおTask budgetsはClaude Code / Coworkでは使えません。Messages APIを直接叩くエージェント基盤向けの機能です（Claude Codeのワークフロー機能には類似の予算機構が別途あります）。

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

Opus 5は4.8向けプロンプトでも素のままよく動きます。

ただ、公式プロンプティングガイドが「調整が要りやすい」と明言する挙動が5つあります。すべてモデルが勝手にやってくれる方向に変わった結果、旧来の指示が過剰になるパターンです。

(1) 応答・成果物が長くなった

会話応答も、ディスクに書くレポートやMarkdown文書も、4.8より長くなりがちです。

前述のとおりeffortを下げても短くならないので、プロンプトで明示します。

Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.

長いシステムプロンプトでは、末尾近くに短いリマインダ（<tone_preference>Keep outputs reasonably concise.</tone_preference>のようなもの）を重ねるのが効くとされています。

文書の長さには「実質をカバーし、埋め草セクション・冗長な要約・ボイラープレートで水増ししない」という較正指示を入れます。

(2) 進捗ナレーションが増えた

エージェント作業中に「これから何をするか」を積極的に宣言し、メッセージあたりの出力も長めです。

頻度と形を明示的に指定するのが有効で、公式の例はこうです。

Before your first tool call, say in one sentence what you're about to do. While working, give a brief update only when you find something important or change direction. When you finish, lead with the outcome: your first sentence should answer "what happened" or "what did you find," with supporting detail after it for readers who want it.

逆にナレーションを増やしたい場合やスタイルを変えたい場合も、禁止形ではなく望む形の肯定例を示すほうが効きます。

(3) 自己検証・自己修正を勝手にやる

これがOpus 5最大の性格変化です。

「最後に検証ステップを入れよ」「ダブルチェックせよ」「サブエージェントで検証せよ」のような、モデルの自己検証と重複する再検証指示は削除が公式推奨です。

モデル自身の検証行動と重なって過剰検証になり、品質向上なしにコストだけ増えるからです。

ただし削除してよいのはこの種の重複指示だけです。

「変更後に指定のテストスイートを実行する」「lintと型検査を通す」といったプロジェクト固有の受入条件は、自己チェックの重複ではなく完了条件なので残します。

また、自分の前言の訂正を口に出しやすくなりました。ユーザー向け製品では「ユーザーのコード・結論・意思決定を変える誤りだけ簡潔に訂正し、影響のない言い間違いは黙って直せ」と絞る指示が紹介されています。

(4) タスクスコープを広げがち

頼んでいないステップを足したり、「本来こうあるべき」と判断してタスクを変形したりすることがあります。

狭いタスクではスコープを明示的に縛ります。

Deliver what was asked, at the scope intended. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it.

(5) サブエージェントへの委任が増えた

マルチエージェント基盤では、4.8より積極的にサブエージェントを起動します。

真に独立した大きな作業では強みですが、小タスクではコストと時間を掛け算で増やします。委任条件の明示か、スポーン数の決定論的な上限を推奨します。

「数回のツール呼び出しで終わる仕事を委任するな」「自分の検証にサブエージェントを使うな」という例文が公式に載っています。

ちなみに4.8のプロンプティングガイドは真逆で、「サブエージェントを増やす」誘導例を載せていました。

世代ごとにデフォルト挙動が振り子のように動くので、ハーネス側の誘導プロンプトは毎世代見直しが必要です。

このほか2つ、特筆したい強化があります。

コードレビュー用途

Opus 5は「1パスあたり高い率で本物のバグを見つけ、追加の指摘もほとんどが誤検知でない」とされます。

しかも低effortでも精度が保たれるため、「レビュー時に速いパス、後でより徹底したパス」という2段構成が組めます。

4.8時代と同じく、「high-severityのみ報告せよ」という指示は文字どおりに守って報告を減らすので、発見段階では全部報告させ、フィルタは別パスで行うのが定石です。

ビジョン（画像理解）

チャート・文書・図の理解と、UIやフロントエンドの視覚的再現が向上しています。

旧モデル向けに入れた画像まわりのワークアラウンドは再検証をおすすめします。

画像を反復的に解析・クロップ・確認できるツールを与えるほうが、thinkingを盛るよりコスト効率が良いとされています。

第3部　Claude Codeで使うOpus 5

11. Claude CodeでOpus 5を使う前提

Claude Codeをまだ使ったことがない方はClaude Code入門（CLI版とWeb版）からどうぞ。

ここでは運用者向けの前提を押さえます。

バージョン

Opus 5にはClaude Code v2.1.219以降が必要です（Sonnet 5はv2.1.197以降、Opus 4.8はv2.1.154以降）。claude updateで更新してください。

エイリアス解決

opusエイリアスの解決先が4.8時代から大きく前進しました。

Anthropic APIだけでなく、Claude Platform on AWS・Amazon Bedrock・Google CloudのAgent PlatformでもopusはOpus 5に解決されます（4.8時代はプロバイダごとにバラバラでした）。

例外はMicrosoft Foundryで、opusはOpus 4.6のまま。Foundryでは完全なモデル名指定かANTHROPIC_DEFAULT_OPUS_MODELで対応します。

`best`エイリアス

組織がFable 5にアクセスできるならFable 5、できなければ最新Opusに解決するbestが使えます。fableエイリアスの直接指定も可能です。

default（モデル未指定時）の解決先は次のとおりです。

ProプランのデフォルトがSonnet 5になった点に注意してください。

Fable 5はどのアカウント種別でもデフォルトにはなりません（/model fable等での明示選択が必要です）。

バージョン固定したい場合は、エイリアスではなくフルモデル名（claude-opus-5）か環境変数（ANTHROPIC_DEFAULT_OPUS_MODEL）を使う、という定石は従来どおりです。

12. Claude Codeのeffort設定は引き継ぎ挙動に注意

Claude Codeでのeffort操作方法（/effort・--effort・CLAUDE_CODE_EFFORT_LEVEL・設定ファイルのeffortLevel・スキルやサブエージェントのフロントマター）は4.8時代と同じです。

Opus 5で特に注意したいのが、effort設定の引き継ぎ挙動です。

Fable 5・Opus 4.8・4.7では、そのモデルを初めて使うとき、以前別モデルで設定したレベルがあってもモデルデフォルトが強制適用される仕様でした（4.8ガイドで注意喚起した挙動です）。

Opus 5にはこのホールドがなく、以前設定したレベルがそのまま引き継がれます。

つまり4.8でxhighを常用していた人がOpus 5に切り替えると、気づかないままxhighで走り続けます。

第8章のとおりOpus 5ではhighから始めて必要に応じて調整するのが公式推奨なので、切り替え直後に/effortで現在値を確認し、意図的に選び直すことをおすすめします。

現在のeffortはセッションヘッダの「with xxx effort」表示でも確認できます。

そのほかは従来どおりです。

maxはセッション限定（設定ファイルには保存不可）、ultracodeは「xhighと動的ワークフローのオーケストレーション」というClaude Code側の設定でモデルのeffortレベルではないこと、一回だけ深く考えさせたいときはプロンプトにultrathinkと書くこと、などは4.8ガイドの第9章・第11章を参照してください。

動的ワークフロー（Dynamic Workflows）自体の仕組みも4.8ガイドで詳説したとおりで、Opus 5で仕組みの変更はありません。

13. Fast modeの変更点

/fastで切り替えるFast mode（同じモデル・同じ品質のまま最大2.5倍速）は、v2.1.219以降でOpus 5がデフォルト対象になりました。

価格はOpus 5・Opus 4.8とも入力$10・出力$50で、4.8時代に値下げされた水準が維持されています（1Mウィンドウ全域でフラット）。

注意点は4.8時代から引き継ぎつつ、ひとつ動きがありました。

• Opus 4.7のFast modeは2026年7月24日（Opus 5ローンチ当日）に削除。しかもClaude Codeは4.7をFast mode対象として扱い続けるため、4.7セッションでFast modeがONのままだとAPIがリクエストを拒否します（標準速度へのフォールバックではなくエラー）。4.7でFast modeを使っていた場合はOpus 5か4.8に切り替えてください
• サブスクリプションプラン（Pro/Max/Team/Enterprise）ではusage credits経由のみ。プランの通常利用枠には含まれず、最初のトークンからFast mode単価
• 会話の途中でONにすると、その時点の会話文脈全体に未キャッシュ入力単価が一度かかるため、使うならセッション開始時から
• Bedrock / Google Cloud / Foundry / Claude Platform on AWSでは利用不可。VS Code拡張も非対応（CLIのみ）

14. フラグされたらどうなるか、自動モデルフォールバックの仕組み

第7章で述べたAPI側のfallbacksとは別に、Claude Code側にもカテゴリベースの自動フォールバックが入りました（v2.1.219以降）。

Fable 5とOpus 5はサイバーセキュリティ・生物学の安全分類器つきで動いており、リクエストがフラグされたときの挙動はこうなります。

この表からも分かるとおり、Opus 4.8に該当分類器がないからこそ、4.8がフォールバック先になっています。

フォールバック後のセッションはそのモデルのまま続くので、戻りたければ/modelで戻します。

運用上知っておくべき挙動を3つ挙げます。

セッションの最初のリクエストでいきなり発火することがある

初回リクエストにはCLAUDE.mdやgit statusなどのワークスペース文脈が載ります。

セキュリティ・生物学系の内容を含むリポジトリでは、何も変なことを頼んでいなくても分類器が反応します。

切り分けにはclaude --safe-mode（CLAUDE.md・スキル・MCP・フックを無効化して起動）が使えます。

自動で切り替えたくない場合は設定で変えられる

/configで「switch models when a message is flagged」をオフにします。

フラグ時にセッションが一時停止し、「フォールバックモデルへ切り替え」か「プロンプトを編集して現行モデルで再試行」を選べます。

ペネトレーションテスト・CTF・生物学隣接コードベースでは頻繁な発火が「仕様どおり」

アカウントにフラグが付いたわけではありません。

Fable級の能力がこの領域で必要な組織向けには、Anthropicのtrusted access programs（CVP等）が案内されています。

なお、Claude Codeの拒否まわりでは過去に紛らわしい不具合もありました。「usage policy violation」表示の対処はこちらの記事にまとめてあります。

15. 1Mコンテキストとopusplan

1Mコンテキストの扱いは4.8時代の枠組みを引き継ぎつつ、Opus 5では「1Mがデフォルトかつ最大」なのでさらに単純になりました。

• Anthropic APIでは、Opus 5（および4.7以降のOpus・Sonnet 5・Fable 5）は常に1Mウィンドウで動作
• Max / Team / Enterpriseプランでは、Opusが追加設定なしで自動的に1Mへアップグレード（サブスクリプションに含まれ、200k超のプレミアム課金なし）
• 完全に無効化するならCLAUDE_CODE_DISABLE_1M_CONTEXT=1

opusplan（プランモードはopus、実行はsonnetエイリアスに自動切り替えするエイリアス）は、Anthropic APIでは計画をOpus 5、実行をSonnet 5が担う構成になりました。

実際の組み合わせは第11章で説明したプロバイダーごとのエイリアス解決に従います。Claude Platform on AWSではOpus 5とSonnet 4.6、BedrockとGoogle Cloud Agent PlatformではOpus 5とSonnet 4.5、FoundryではOpus 4.6とSonnet 4.5になる点に注意してください。

Sonnet 5は「最もエージェンティックなSonnet」としてOpus級に迫る実行能力を謳っており、しかも8月31日までは導入価格$2/$10です。

「設計はOpus 5にじっくり考えさせ、コード生成はSonnet 5に流す」構成はコスト面で魅力があります。

Anthropic APIで実行側がSonnet 5になる場合、Sonnet 5は常時1Mウィンドウで、デフォルトでは約967kトークンで自動コンパクションが入ります（Claude Codeのモデル設定ドキュメント記載。CLAUDE_CODE_AUTO_COMPACT_WINDOWで閾値を変更可能です）。

16. 日常運用のリズム

第10章のプロンプティング変化は、Claude Codeの日常運用にそのまま効いてきます。

運用の型として3点にまとめます。

(1) CLAUDE.mdの検証指示を仕分けする

プロジェクトのCLAUDE.mdやスキルの検証まわりの指示を、2種類に分けてください。

ひとつは必須の受入条件（指定テストスイートの実行・lint・型検査・Definition of Done）。もうひとつはモデルの自己確認に重なるだけの指示（「完了前にダブルチェック」「最後にもう一度検証」）です。

Opus 5で削除してよいのは後者だけです。前者はプロジェクトの完了条件なので残します。

Opus 5は言われなくても自分の変更を確認するため、後者を残すと過剰検証でトークンを浪費します。

逆に、検証してほしくない場面（ドラフト段階の高速イテレーションなど）でこそ明示が必要になる、という逆転も起きています。

(2) 初回プロンプトへの情報集約は引き続き最重要

「完全なタスク仕様を最初に渡して、あとは走らせておくのが最良」という特性は4.8からさらに強化されています。

意図・完了条件・触ってよい範囲・制約を最初に書き切る運用は変わらず有効です。

一方、途中経過の報告は増える方向に変わったので、静かに走らせたければ第10章のナレーション抑制プロンプトをCLAUDE.mdに入れます。

(3) モデルの使い分けを再設計する

Opus 5の登場で、Claude Code内の現実的な使い分けはこうなりました。

「とりあえず全部Fable 5」はコスト的にも（Fable 5のコストと展望）、分類器の介入頻度的にも割に合わない場面が増えました。

Fable 5は最難関のタスクに絞り、日常の上限をOpus 5に置くのが、現時点のバランスだと考えています。

まだわかっていないこと・未確認事項

誠実性のため、現時点で確認できていないことを明示しておきます。

• Frontier-Benchのeffortレベル別チャートの各点（xhigh時は約44%とする読み取りが報道にあります）は画像形式でのみ示されており、テキスト形式では確認できていません。本稿の43.3%はSystem Cardの評価サマリー表に記載された値を採用しています
• 独立評価はまだ出揃っていません。Arena系ブラインド投票やArtificial Analysis等でのOpus 5の位置は、本稿執筆時点（リリース3日後）では確認できませんでした。8月のLLMランキングシリーズで答え合わせをする予定です
• Priority TierとWeb FetchのOpus 5対応時期はアナウンスされていません
• Fast mode・Task budgets・mid-conversation tool changes・fallbacksはいずれもbeta/リサーチプレビューであり、仕様・価格が変わる可能性があります

まとめ

一言でまとめると「Opus 5は最上位モデルではないのに、実務の本命になった」。これが今回のリリースの本質です。

実務で押さえるべき要点は次の5つに集約されます。

1. 移行は「ID差し替えだけ」ではない

thinkingがデフォルトONになり、thinking無効化はeffort high以下限定になりました（400エラー）。Web FetchとPriority Tierの非対応も含め、max_tokensと該当リクエストの監査が必要です。

2. effortは持ち越さず測り直す

デフォルトは変わらずhigh。公式の推奨スタート地点が「コーディングはxhigh」から「highで開始、要求の厳しい作業のみxhigh」に変わり、low/mediumの実用域が広がりました。Claude CodeではOpus 5だけ旧effort設定が引き継がれる点にも注意です。

3. 重複する再検証指示を消す

Opus 5は勝手に自己検証します。「ダブルチェックせよ」系の指示は過剰検証によるトークン浪費の原因になります。ただし必須テスト・lint等の受入条件は残します。

4. 安全分類器の搭載を理解して選ぶ

Opus 5には4.8にないモデル固有分類器（サイバー・生物学）が搭載されました。4.8からの移行では制約の追加であり、セキュリティ系ワークロードは4.8継続も選択肢です。Fable 5と比べれば介入は85%少なく、30日保持要件もなく、フォールバックもあるため、Fable 5からの乗り換え先としては扱いやすいモデルです。

5. 使い分けの再設計

日常はSonnet 5、主力はOpus 5（Maxのデフォルト）、最難関はFable 5。ナレッジカットオフ最新（2026年5月）はOpus 5だけの隠れた強みです。

Fable 5の停止事件からわずか6週間でこの布陣を整えてきたAnthropicの速度には驚かされます。

独立評価が出揃ったら、恒例のランキング記事で改めて検証します。

それでは、また次回、お会いしましょう！

出典

本記事の情報は2026年7月27日時点の公式ドキュメント・公式発表・報道に基づきます。

beta機能・リサーチプレビューの仕様は変更される可能性があるため、最新情報は各出典をご確認ください。