2026年7月24日、AnthropicはClaude Opus 5を発表した。エージェント開発者にとってこの発表は「また新しいフラッグシップモデルが出た」という速報以上の意味を持つ。thinkingが既定でONになり、effortパラメータが5段階に拡張され、マルチエージェント調整そのものが公式の強化ポイントとして明記されたためだ。これまでOpus系を「一番強いが高いので温存するモデル」として扱っていたルーティング設計は、前提から見直す必要がある。
本記事は既刊「Claude Sonnet 5の位置付け｜Opus 4.8とのルーティング設計」の続編にあたる。法人導入判断や料金の一般解説ではなく、マルチエージェント／サブエージェント構成を組む開発者が「どの層にOpus 5を置き、Sonnet 5・軽量モデルとどう振り分けるか」という実務判断に絞って整理する。
参照した一次情報はAnthropic公式ドキュメント3本（What’s new in Claude Opus 5、Prompting Claude Opus 5、Effort）と、第三者ベンチマークのArtificial Analysis Intelligence Index。すべて2026年7月25日時点の内容に基づく。
発表24時間で公式ドキュメントに書かれていること
まず前提となる一次情報を表で整理する。数字はすべてAnthropic公式ドキュメントに基づく。
| 項目 | 内容 |
|---|---|
| 発表日 | 2026年7月24日（米国時間） |
| Claude API ID | claude-opus-5 |
| 公式の位置付け | 「複雑なエージェンティックコーディングとエンタープライズ用途向け」 |
| コンテキストウィンドウ | 1Mトークン（既定かつ最大。縮小版は存在しない） |
| 最大出力トークン | 128,000トークン |
| thinking | 既定でON（Opus 4.8は明示指定が必要だった） |
| effortパラメータ | 5段階（low / medium / high / xhigh / max）。既定はhigh |
| プロンプトキャッシュ最小長 | 512トークン（Opus 4.8は1,024トークン） |
| 価格 | 入力$5・出力$25（100万トークンあたり、Opus 4.8から据え置き） |
| Fast mode | 研究プレビュー。入力$10・出力$50（100万トークンあたり）。Claude API限定でBedrock・Google Cloud・Microsoft Foundryは非対応 |
| 提供状況 | Claude API全顧客、AWS Bedrock、Google Cloud、Microsoft Foundry。Opus 4.8は各プラットフォームで提供継続 |
第三者ベンチマークでは、Artificial Analysis Intelligence Index（2026年7月時点）でOpus 5（max）が61点を記録し、Claude Fable 5（max・60点）、GPT-5.6 Sol（max・59点）、Kimi K3（57点）、Opus 4.8（56点）を上回った。同社はOpus 5について「Fable 5と同等の知性をより低いコストで提供する」とも述べている。これはAnthropic公式のベンチマークではなく第三者評価である点は明記しておく。
ルーティング設計の前提が3つ変わった
公式ドキュメントを読む限り、ルーティング設計に直接影響するのは次の3点だ。
1. thinkingが既定でONになり、effortが「思考の深さ」の主要な制御弁になった
Opus 4.8では、thinking: {"type": "adaptive"}を明示しない限りthinkingなしで動いていた。Opus 5では同じリクエストがthinking有効で動く。モデル自身がターンごとに「いつ・どれだけ考えるか」を判断し、effortパラメータがその深さを調整する仕組みに変わった。結果として、max_tokensは「thinking＋応答テキストの合計」に対するハードリミットになる。thinkingなし前提でmax_tokensを絞っていた呼び出しは、応答が途中で切れる可能性がある。
2. 低effortでも品質が落ちにくくなった
公式ドキュメントは「low・medium effortでも、高いeffort設定に比べてごくわずかなトークン・レイテンシで高い品質を出す」と明記している。これはOpus 4.7〜4.8世代で「コーディング・エージェント用途はxhighが推奨開始点」だった経験則を塗り替える変化だ。effortを下げる判断が、単なる妥協ではなく積極的な選択肢になった。
3. マルチエージェント調整が公式の強化項目として明記された
公式ドキュメントは能力改善点の一つとして「サブエージェントのチームを効果的なwriter-verifierパターンでまとめ、エージェントが互いの作業を上書きするケースが少ない」multi-agent coordinationを挙げている。加えて「指示されなくても自分の作業を検証する」ため、旧世代向けに書いていた検証指示（「最後に検証ステップを入れる」「サブエージェントに検証させる」）はそのまま持ち越すと過剰検証を招くと明記されている。
層別モデル振り分け表 — 4つの役割にどう充てるか
上記3点を踏まえ、マルチエージェント構成を4つの役割に分解し、モデルとeffortの目安を1枚の表にまとめる。数値上の絶対解ではなく、公式ドキュメントの記述から導ける出発点として扱ってほしい。
| 層 | 役割 | 推奨モデル | effort目安 | 根拠 |
|---|---|---|---|---|
| オーケストレータ | タスクを分解し、どのサブエージェントに何を投げるか判断する司令塔 | Claude Opus 5 | high（既定）〜xhigh | 公式が「以前のモデルより積極的にサブエージェントへ委譲する」「writer-verifierパターンが有効に機能し、エージェント同士が作業を上書きし合うケースが少ない」とマルチエージェント調整を強化点として明記 |
| 実装（難所） | 複数ファイルにまたがる機能追加・大規模リファクタを最後まで作り切る | Claude Opus 5 | high〜xhigh | 公式が「スタブや未実装箇所を残さずタスクを完了しやすくなった」と明記する、最も差が出る領域 |
| 実装（定型） | ルーティンなコード生成・小規模編集 | Claude Sonnet 5 | medium〜high | Sonnet 5は既定high。品質とコストのバランスが良く、定型実装まで全てOpus 5に寄せるとコストが跳ねる（詳細は既刊「Claude Sonnet 5の位置付け」参照） |
| レビュー・検証（verifier） | writer側の出力チェック、生成コードのバグ検出 | Claude Opus 5 | low〜medium | 公式が「コードレビュー・バグ検出は低effortでも精度が落ちにくい」と明記。verifierを高effortで回す必要性は薄い |
| 大量処理・軽量サブタスク | 分類、要約、簡単な抽出、並列fan-out | 軽量モデル（Haiku系など。API IDは公式ドキュメントで最新を確認） | low | effortの公式ガイドが「low effort＝サブエージェントのような高頻度・低レイテンシ用途」と位置付けている |
Pythonでルーティング設定を組む場合、層ごとの設定を辞書に固定しておくとレビューしやすい。
# 動作環境: Python 3.11+, anthropic>=0.42.0
# 層ごとにモデルとeffortを固定するルーティング設定の例
# 本番環境で使用する前に、必ずテスト環境で動作確認してください。
ROUTING_TABLE = {
"orchestrator": {"model": "claude-opus-5", "effort": "high"},
"implementation_hard": {"model": "claude-opus-5", "effort": "xhigh"},
"implementation_routine": {"model": "claude-sonnet-5", "effort": "medium"},
"verifier": {"model": "claude-opus-5", "effort": "low"},
# 軽量モデルのAPI IDは公式ドキュメントで最新のものを確認してから設定する
"bulk_subtask": {"model": "<lightweight-model-id>", "effort": "low"},
}
def dispatch(task_layer: str, messages: list, max_tokens: int = 8192):
cfg = ROUTING_TABLE[task_layer]
return client.messages.create(
model=cfg["model"],
max_tokens=max_tokens,
output_config={"effort": cfg["effort"]},
messages=messages,
)
ポイントは、effortを層ごとに固定し、会話の途中で頻繁に変えないことだ。effortはリクエスト単位のパラメータで、値を変えるとプロンプトキャッシュのプレフィックスが無効になる。1つの会話・1つのサブエージェントセッション内ではeffortを一定に保ち、層をまたぐ場合だけ変える設計にしたほうがキャッシュ効率が良い。
writer-verifierパターンをOpus 5でどう組むか
writer-verifierパターンとは、一方のエージェント（writer）が成果物を作り、別のエージェント（verifier）がそれをチェックする構成だ。公式ドキュメントはOpus 5の強化点として、このパターンが「有効に機能し、エージェントが互いの作業を上書きするケースが少ない」と明記している。実装時に押さえておきたいのは次の3点。
- writerとverifierを同じモデル・同じeffortで揃える必要はない。上表の通り、writer（実装層）はhigh〜xhigh、verifier（レビュー層）はlow〜medium効果が薄れにくい。verifierのコストを絞ることが、パターン全体のコスト効率に直結する。
- 委譲基準を明示する。公式ドキュメントは「Opus 5は以前のモデルより委譲を積極的に行う」としたうえで、委譲は「真に独立し並列化できる大きなタスク」に限定し、「1つのサブエージェントで完結するタスクに複数体を使わない」よう促すプロンプト例を挙げている。委譲基準とサブエージェント数の上限をシステムプロンプトで明示しないと、小さなタスクにまでサブエージェントが乱立してコストと時間が膨らむ。
- 「検証させる」指示を重ねない。Opus 5は指示なしでも自分の作業を検証する。writer側のプロンプトに「最後に検証ステップを入れる」「サブエージェントに検証させる」という4.8時代の一文が残っていると、verifierとの二重チェックで無駄なトークンを消費する。
公式ドキュメントが示す委譲基準の一文を実務向けに要約すると、次のような指示になる。
# システムプロンプトの一部として使う委譲基準の例（公式ドキュメントの推奨内容を要約したもの）
# 本番環境で使用する前に、必ずテスト環境で動作確認してください。
DELEGATION_POLICY = """
サブエージェントへの委譲は、真に独立していて並列化できる大きなタスクに限定する。
自分で数回のツール呼び出しで終わる作業は委譲しない。
サブエージェントに自分の作業を検証・二重チェックさせない（writer-verifierの構成は別途設計する）。
1つのサブエージェントで完結する場合は、複数体を起動しない。起動数は最小限に保つ。
"""
移行の落とし穴 — 400エラー・max_tokens・検証指示の残骸
Opus 4.8からOpus 5に切り替える際、公式ドキュメントが「破壊的変更」と明記している箇所を中心に4つの失敗パターンを整理する。
失敗1：thinking無効のまま高effortに上げて400エラー
❌ thinking: {"type": "disabled"}を設定したまま、effortをxhighやmaxに上げる。
⭕ thinkingを無効にする場合はeffortをhigh以下に固定する。逆に高effortを使いたい場合はthinkingを有効のままにする。
なぜ重要か：Opus 5では、thinkingを無効化できるのはeffort high以下の場合に限られる。xhigh・maxとの併用はAPIが400エラーを返す。Opus 4.8ではthinkingの有効・無効はeffortと独立していたため、既存コードをそのまま流用すると気づかないままエラーになる。
失敗2：Opus 4.8時代のmax_tokensをそのまま流用する
❌ thinkingなし前提で決めていたmax_tokensの値を、コード変更なしでOpus 5に流用する。
⭕ thinking分を見込んでmax_tokensを引き上げる。公式ドキュメントは、xhigh・maxのようなeffortでサブエージェントやツール呼び出しをまたぐ場合、64,000トークン程度から調整を始めることを目安として挙げている。
なぜ重要か：max_tokensはthinkingと応答テキストの合計に対する上限になる。thinkingが既定でONになった結果、同じmax_tokens設定でも実際に使える応答テキストの余地は狭くなる。
失敗3：旧世代向けの検証指示プロンプトを残す
❌ 「最後に検証ステップを入れる」「サブエージェントに二重チェックさせる」といった4.8時代の指示をそのまま使い続ける。
⭕ Opus 5は指示なしでも自己検証する挙動を持つため、これらの指示は削除する。
なぜ重要か：公式ドキュメントは「これらの指示はOpus 5では過剰検証を招く」「削除すれば品質を落とさずに無駄なトークンを減らせる」と明記している。旧ハーネスのスキャフォールディングに埋め込まれた検証ステップも見直し対象になる。
失敗4：委譲基準を書かないままサブエージェントを解禁する
❌ 「必要に応じてサブエージェントを使ってよい」とだけ書き、委譲の基準や上限数を指定しない。
⭕ 委譲基準（独立して並列化できる大きなタスクに限定）と起動数の上限を明示する。
なぜ重要か：Opus 5は以前のモデルより積極的に委譲する傾向があると公式が述べている。基準がないと、小さなタスクにまでサブエージェントを起動してコストとレイテンシが増える。
コスト設計 — effort段階とキャッシュを組み合わせる
Opus 5の価格自体はOpus 4.8から据え置き（入力$5・出力$25、100万トークンあたり）だが、コスト構造を左右するレバーは価格ではなくeffortとキャッシュの組み合わせにある。
- effortを主要なコスト制御弁として使う。公式ドキュメントは「lowとmedium effortをコストとレイテンシの主要な制御手段として積極的に使い、品質が保たれる範囲では層ごとに下げる」ことを推奨している。前段の振り分け表のうち、verifier層と大量処理層は特にeffortを下げる余地が大きい。
- プロンプトキャッシュの最小長引き下げを、高頻度な短い呼び出しに活かす。Opus 5はキャッシュ可能な最小プロンプト長が512トークンに下がった（Opus 4.8は1,024トークン）。verifierやオーケストレータのように、短いシステムプロンプトを高頻度で呼び出す構成ほど、コード変更なしでキャッシュヒット率が上がる恩恵を受けやすい。
- effortは会話の途中で変えない。effortを変更するとキャッシュされたプレフィックスが無効になる。1つの会話・1つのセッション内ではeffortを固定し、層をまたぐ場合だけ別リクエストとして切り替える設計にする。
- Fast modeはコスト最適化ではなくレイテンシ最適化の手段として切り分ける。Fast mode（研究プレビュー）は入力$10・出力$50（100万トークンあたり）とOpus 5の標準価格より高く、Claude APIでのみ利用可能でBedrock・Google Cloud・Microsoft Foundryには提供されていない。対話的なUXでレイテンシを最優先する層にだけ検討対象とし、バッチ処理や大量処理層には使わない。
旧モデルからの移行を考える前提として「Fable 5の提供はいつまでか」も確認しておくと判断しやすくなります。
よくある質問
Q. Claude Opus 5とは何ですか？
A. 2026年7月24日にAnthropicが発表した最新のOpusモデル。API IDはclaude-opus-5で、1Mトークンのコンテキストウィンドウ（既定かつ最大）と128,000トークンの最大出力を持つ。価格はOpus 4.8から据え置きの入力$5・出力$25（100万トークンあたり）。
Q. Opus 4.8からOpus 5に切り替えると何が壊れる可能性がありますか？
A. 主に2点。thinkingが既定でONになるため、thinkingなし前提でmax_tokensを絞っていた呼び出しは応答が途中で切れる可能性がある。またthinking: {"type": "disabled"}はeffort high以下でしか受け付けられなくなり、xhigh・maxとの併用は400エラーになる。この2つはAnthropic公式が破壊的変更として明記している。
Q. マルチエージェント構成でeffortはどう選べばいいですか？
A. 公式は「既定のhighから始め、自分の評価データを見ながら層ごとに調整する」ことを推奨している。目安としては、オーケストレータと難所の実装はhigh〜xhigh、コードレビューや検証（verifier）はlow〜medium、分類や抽出などの軽量な大量処理はlowが出発点になる。
Q. writer-verifierパターンとは何ですか？
A. 一方のエージェント（writer）が成果物を作り、別のエージェント（verifier）がそれをチェックする構成。公式ドキュメントはOpus 5について「writer-verifierパターンが有効に機能し、エージェントが互いの作業を上書きするケースが少ない」とマルチエージェント調整の強化点として挙げている。
Q. Claude Opus 5とClaude Fable 5はどちらを使うべきですか？
A. Anthropicは「Fable 5と同等の知性をより低いコストで提供する」と位置付けており、第三者ベンチマークのArtificial Analysis Intelligence Indexでも両モデルは僅差のスコアを記録している（2026年7月時点、Opus 5が61点、Fable 5・maxが60点）。エージェンティックコーディングや長時間の自律タスクが中心ならOpus 5を軸に検討し、それ以外の用途はタスクごとに評価するのが安全だ。
Q. サブエージェントを使いすぎてコストが増えるのを防ぐには？
A. 公式ドキュメントは「Opus 5は以前のモデルより積極的に委譲する」と明記した上で、委譲基準（真に独立し並列化できる大きなタスクに限定する）とサブエージェントの起動数の上限を、プロンプトで明示的に指定することを推奨している。
参考・出典
- What’s new in Claude Opus 5 — Anthropic公式ドキュメント（参照日: 2026-07-25）
- Prompting Claude Opus 5 — Anthropic公式ドキュメント（参照日: 2026-07-25）
- Effort — Anthropic公式ドキュメント（参照日: 2026-07-25）
- Introducing Claude Opus 5 — Anthropic公式発表（2026年7月24日）
- Claude Opus 5 (max) – Intelligence, Performance & Price Analysis — Artificial Analysis（参照日: 2026-07-25）
- Anthropic launches Opus 5 — TechCrunch（2026年7月24日）
まとめ：今日から始める3つのアクション
- 今日やること：既存のルーティング設定を4層（オーケストレータ／実装／verifier／大量処理）に分解し、どの層が今もOpus 4.8時代のeffort・
max_tokensのままか洗い出す。 - 今週中：verifier層とレビュー用途のプロンプトから、「検証ステップを入れる」「サブエージェントに二重チェックさせる」という旧世代向けの指示を削除し、effortをlow〜mediumまで下げて品質が保たれるか評価する。
- 今月中：委譲基準とサブエージェントの起動数上限をシステムプロンプトに明文化し、オーケストレータ層をOpus 5・highに切り替えたうえでコストとレイテンシの変化を計測する。
あわせて読みたい：
- Claude Sonnet 5の位置付け｜Opus 4.8とのルーティング設計 — 本記事の前提となる既刊。Sonnet 5とOpus 4.8の使い分けを解説
- モデルルーティング設計ガイド2026｜タスク複雑度×コスト判断フロー — タスク複雑度に応じたルーティングの基本設計
- マルチエージェントの設計パターン3選｜失敗例と実装ガイド【2026】 — writer-verifier以外の設計パターンと失敗例
- 【2026年最新】Claude Agent SDK サブエージェント実装ガイド — サブエージェントの実装手順
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』累計3.1万部。
この記事を読んでエージェント構成の見直しイメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
