コストとインテリジェンスの最適化

ワークロードがプロトタイプから本番環境へ移行すると、コストは第一級の設計制約になります。最も高性能なモデルは大規模運用では高価すぎることがあり、最も安価なモデルは品質面で不足することがあります。コストをうまく管理するということは、各コストレバーが出力品質にどう影響するかを理解することを意味します。品質とトレードオフになるレバーもあれば、そうでないレバーもあるからです。Claude Platformでは、そのトレードオフを直接制御できます。リクエストごとにモデル、effortレベル、アーキテクチャを選択できるため、ワークロードをコスト対インテリジェンスのフロンティア上のほぼどこにでも配置できます。

レバーには2種類あります。

• 無償の改善（Free wins） は品質に触れることなく支出を削減します。プロンプトキャッシング、トークンの衛生管理、実行中のモデルに対するプロンプト監査、最大24時間待てる作業に対する50%割引のバッチ処理、そして最後の防波堤としてのワークスペース支出制限です。
• トレードオフ（Tradeoffs） はコストとインテリジェンスを交換します。モデル選択、effort、出力上限とタスク予算、マルチモデルアーキテクチャです。

各レバーには実測結果と、それが効果を発揮する条件のルールが付いています。Anthropicの測定では、プロンプトキャッシングが圧倒的に最大のレバーでした。このガイドのベンチマークではエージェントループのコストを2.5〜3.7分の1に削減し、小規模なトリアージエージェントの請求額を83%、入力トリミングを加えると88%削減しました。マルチモデルのレバーはより限定的で、2つ目のモデルが効果を発揮したのはアドバイザーとオーケストレーターという2つの形態でした。



ここから始める

自分の状況に合う行を見つけてください。

これらの結果はAnthropic社内のもの（参照ベンチマーク）であり、方向性を示すもので保証ではありません。4ステップの方法で自分のワークロードで測定してください。



品質を落とさずに支出を削減する

プロンプトキャッシング、トークンの衛生管理、バッチ処理、現在のモデルに対するプロンプト監査は、いずれも出力品質を下げることなく支払額を下げます。2つの注意点があります。バッチ処理は割引と引き換えにレイテンシを犠牲にします。また、トークン衛生管理のレバーであるコンテキスト編集は、このセクションで測定した実行では節約額よりもコストのほうが大きくなりました。



繰り返されるコンテキストをキャッシュする

他のどのレバーよりも先に「prompt caching」（プロンプトキャッシング）を有効にしてください（プロンプトキャッシングを参照）。エージェントタスクの各ターンは、増え続ける会話全体、つまりシステムプロンプト、ツール定義、それまでのすべてのターンを再送信するからです。40ターンのタスクは最初のターンを40回送信するため、タスクコストはターン数のおよそ2乗で増加します。キャッシングは再送信を止めるわけではありませんが、各再送信のコストは約10分の1になり、処理も速くなります。プレフィックスは入力価格の10分の1であるキャッシュ読み取り料金で課金され、各ターンは新しい部分に対してのみ1.25倍のキャッシュ書き込み料金を支払います。

Anthropicが測定した実行全体で、キャッシュ読み取りは常にタスクコストの最大の単一要素であり、キャッシングはほとんどのモデル選択の判断よりも価値があります。AnthropicはWideSearch¹とDeepResearch Bench II⁷の実行を、キャッシングありとなしで価格評価しました。

キャッシュのデフォルト有効期間は5分で、エージェントループのターン間隔は数秒なので、割引は毎ターンほとんどのトークンに適用されます。チャートの実行では81%〜90%のヒット率を達成しました。短いループは再読み取りが少ないため、節約額はエピソードの深さによって変わりますが、測定したすべてのモデルとベンチマークでキャッシングは最大の単一レバーであり続けました。

ループがターン間で人間を待つ場合は、1時間のキャッシュ期間を使用してください。書き込みコストは高くなります（入力価格の1.25倍ではなく2倍）が、最初にミスを1回防いだ時点で元が取れます。ミスが発生するとプレフィックス全体が正規料金で再送信され、再度書き込まれるからです。

セットアップにはほとんど手間がかかりません。自動キャッシングがブレークポイントを配置してくれます。そうでなければ、Claude Codeに同梱されているClaude APIスキルが、1つのプロンプトから既存の統合にキャッシングを追加できます。以下の抜粋は、これらの測定を生成したハーネスにスキルがキャッシングを追加している様子を示しています。

$ claude
> /claude-api add prompt caching to this integration

Done. Prompt caching is now wired into the harness. Two changes:

- build_system() now adds cache_control: {"type": "ephemeral"} to the
  system block. Since the API renders tools -> system -> messages, this
  one breakpoint caches the entire static prefix -- the full tool array
  plus the system prompt.
- apply_moving_cache_breakpoints() strips any stale markers, then marks
  the last content block of the two most recent user turns. The older
  marker is the read point matching the prefix the previous request
  cached; the newer one extends the cache for the next request.

That's 3 breakpoints total, under the limit of 4.
...

これらのブレークポイント配置は、明示的なキャッシュブレークポイントの標準パターンに従っています。

タスク中にキャッシュを壊す可能性のある設定が3つあります。リクエスト間でeffortを変更するとキャッシュされたプレフィックスが無効になるため、コンパクションの境界など、いずれにせよ再キャッシュする場所でのみ変更してください。タスク予算を途中で変更しても同じことが起こるため、最初のリクエストで一度だけ設定してください。コンテキスト編集の各パスは、クリアした地点からプレフィックスを無効にし、次のリクエストはそれ以降のすべてを再キャッシュするコストを支払うため、小さなバッチを何度も行うのではなく、少数の大きなバッチでクリアしてください。3つの変更はすべて自然な区切りで行い、その後キャッシュ読み取りが減っていないことを確認してください。減っている場合は、キャッシュ診断でプレフィックスがどこで分岐したかがわかります。



入力トークンとコンテキストトークンを削る

ほとんどのエージェントリクエストには、回答に影響を与えないトークンが含まれています。それらを削っても出力品質には何のコストもかかりませんが、ここで挙げるすべてのレバーが測定時に費用を節約したわけではありません。確認すべき場所は2つあります。

• 入力トリミング。 web fetchツールの動的フィルタリングは取得したページからボイラープレートを除外し、画像のリサイズはビジョン入力を適切なサイズにし、遅延読み込み付きのツール検索は必要なときにのみツール定義を読み込みます。プログラマティックツール呼び出しにより、Claudeはコードから複数のツール呼び出しを実行でき、フィルタリングされた結果のみがコンテキストに入ります。そのドキュメントでは、エージェント検索ベンチマークで入力トークンが24%減少し、スコアが向上したと報告されています。ツールコンテキストの管理では、ツール検索、プログラマティックツール呼び出し、プロンプトキャッシング、コンテキスト編集を比較しています。
• コンテキストのライフサイクル。 コンテキスト編集は古いツール結果をクリアし、しきい値付きの自動コンパクションは長いループが履歴全体を持ち越すのを防ぎます。

これらのレバーはキャッシュや互いに相互作用するため、正味の効果で判断し、キャッシュ診断を使用して各変更後もキャッシュされたプレフィックスが維持されていることを確認してください。Anthropicは、公開リポジトリからのスクリーンショット付きの実際のバグレポート20件を処理するissueトリアージエージェント（および2つ目のパネルでは同じジョブのより長いバリアント）に対して、レバーを1つずつ有効にしました。

キャッシングがほぼすべての仕事をし、トリミングで合計88%になりました。各棒は1回の実行なので、$0.10の差はノイズですが、ここに示した差はノイズではありません。コンパクションはそれをトリガーするのに十分な長さのセッションが必要です。20件のissueの実行では、入力をトリミングした後は50,000トークンの下限に一度も達しませんでしたが、2つ目のパネルの長いバリアントでは1回発動し、請求額をさらに38%削減しました。

コンテキスト編集は、ここで唯一無償ではないレバーです。クリアの各パスはキャッシュされた会話を書き換えるため、プロンプトキャッシングに逆行します。この実行では、コンテキスト編集は節約額よりもコストのほうが大きくなりました。コンテキストウィンドウに空きを作るために使用し、少数の大きなバッチでクリアしてください。



待てる作業をバッチ処理する

Batch APIは、結果が24時間以内の任意の時点で届くことと引き換えに、キャッシュされたものを含むリクエストのすべてのトークンを50%割引します。誰も待っていないリクエストはすべてバッチ経由でルーティングし、残りはインタラクティブな経路を維持してください。バッチ処理は、無人のエージェント作業（評価実行、バックフィル、トークントリミングの測定で使用したissueトリアージエージェントの定期実行のようなスケジュールジョブ）において、キャッシングに次いで2番目に大きな無償のレバーです。このページのインタラクティブ性以外のすべてと組み合わせられますが、設計上インタラクティブであるClaude Managed Agentsセッションでは利用できません（Claude Managed Agentsの料金を参照）。



現在のモデルに対してプロンプトを監査する

モデルの世代ごとにプロンプトへの反応が異なるため、プロンプトにはもう使用していないモデル向けに書かれたテキストが蓄積していきます。よくあるケースは、古いモデルを補うために追加された過度に具体的な指示です。「2回検証せよ」「最大限徹底的に」、必須のステップバイステップ手順、手作りの推論スクラッチパッドなどです。新しいモデルはこれらを文字通りに従い、余分なツールラウンドと余分な記述を生成するため、精度の向上なしに請求額が上がります。現在実行しているモデルに対してプロンプトを監査し、モデルを変更するたびに再度監査することは、無償の改善です。

監査はコマンド1つです。Claude Codeに同梱されているClaude APIスキルにはprompt-auditコマンドがあり、プロジェクトのプロンプトとリクエストコードを読み取り、別のモデル向けに書かれたものを報告します。この短縮した抜粋は、それらのパターンを含むサポートデスクのプロンプトとリクエストコードに対して実行した様子を示しています。

$ claude
> /claude-api prompt-audit

10 findings. The three that matter most:

1. budget_tokens returns a 400 on Opus 5 (support_agent.py:10). This code
   does not run against its own target model. Everything else here is
   quality; this one is an outage.
2. The prompt contains two live contradictions. Line 15 says confirm before
   every refund, line 17 says process every eligible refund immediately.
   Line 19 asks for a complete recap *and* a three-sentence maximum.
3. The reasoning scaffold and the 6-step script fight the model rather than
   steer it. <scratchpad> + "reason step by step" is now a request
   parameter, not prose; the mandatory 6-step procedure plus "investigate
   fully even when the ticket looks simple" forces four tool calls on a
   "where's my package" ticket.
...
-After any refund or escalation, verify twice before submitting: re-fetch
-the order, re-check every figure in your reply against the fresh lookup,
-and review the reply a second time for errors.
+Before submitting a refund or an escalation, re-fetch the order and confirm
+every figure in your reply matches the fresh lookup.

コマンドはその後、編集をdiffとして提案し（1つのハンクを表示）、意図的にそのまま残したもの（返金期間、トーンの要件、品質基準）を列挙します。レビューするのは書き直しではなくパッチです。

効果は測定可能です。サポートデスク評価¹⁴では、Claude Opus 4.8向けに書かれたプロンプトは、Claude Opus 5では精度の変化なしにチケットあたり36%多くコストがかかりました。同じプロンプトに監査を実行すると、Opus 5は未監査版より安く（14%）、かつより正確に（チケットの97%、92%から上昇、ノイズの範囲外の向上）なりました。Claude Sonnet 4.6からClaude Sonnet 5への移行では、監査により同じ精度で14%削減されました。

2種類の古いテキストには異なるコストがあります。新しいモデルが文字通りに従いすぎる指示は費用がかかります。「2回検証せよ」を削除するとOpus 5のチケットあたりコストが3分の1削減され、「最大限徹底的に」を削除してもほぼ同程度でした。モデルにもう合わないテキストは代わりに精度を犠牲にします。廃止済みの思考設定、矛盾するルール、モデル自身の思考と衝突する手作りのスクラッチパッドは、それぞれ削除するとOpus 5で7〜11ポイント回復しました。

同じパターンはツールの説明やスキルにも現れ、そこでも削除する価値があります。



コストとインテリジェンスをトレードオフする

これらのレバーは、単一モデルがコストとインテリジェンスの間のどこに位置するかを設定します。モデル選択、effort、より高い設定での失敗の再実行、そしてモデルが動作する予算と上限です。まず現在のモデルでeffortスイープから始めてください（effortを調整する）。コストと能力の低い順から高い順に、現在のモデルはClaude Haiku 4.5、Claude Sonnet 5、Claude Opus 5、Claude Fable 5（フロンティアモデル）です。モデル概要に全ラインナップと価格があります。



完了タスクあたりのコストでモデルを比較する

価格表はトークン単位で書かれており、トークン単位ではフロンティアモデルは高価に見えます。Claude Fable 5のトークン単価はClaude Sonnet 5の数倍です。しかし、支払うのは完了したタスクに対してなので、完了タスクあたりのコストでモデルを比較してください。より高性能なモデルは、より少ない作業でタスクを完了します。ターン数が少なく、検索が少なく、自身のコンテキストの再読み取りが少なく、後戻りが少なくなります。トークン単価のプレミアムは、すべてをより少なく行うことで常に相殺されます。

Anthropicはこれを、モデル間の差が出るほど難しい研究レポートベンチマークであるDeepResearch Bench II⁷で直接測定しました。

low effortのフロンティアモデルは、トークン単価の差にもかかわらず、中位ティアのモデルより正確で、タスクあたり約10%安価でした。ただし、常に勝つわけではありません。このページのSWE-bench Pro³サブセット（両モデルがほぼ飽和しており、スコアは公開リーダーボードと比較できません）では、Claude Opus 5単体がClaude Fable 5単体と同等（91.7%対91.3%、実行間ノイズの範囲内）で、コストは約60%でした。DeepResearch Bench IIのタスクのようなより難しい作業では、Fableの優位性が再び現れます。

ほとんどのエージェントワークロードでは、Claude Opus 5から始めてください。トークン単価はFable 5の半分、Sonnet 5の2.5倍で、そのコーディングサブセットではFableの精度に匹敵しました。反対側では、Claude Haiku 4.5はGPQA Diamond⁹の質問にOpus 5の質問あたりコストの約10分の1で回答し、精度はOpusの92%に対して63%で、長いコーディングタスクではさらに大きく後れを取りました。検証可能な出力を持つ大量の作業に適しており、長いエージェントループには適していません。

ランキングはワークロードによって逆転し、どちらに転ぶかを教えてくれる価格表はありません。Claude Opus 5とeffortを下げたフロンティアモデルを含め、すべての候補を自分のトラフィックで完了タスクあたりのコストで価格評価してください。

中央値ではなく、ワークロードのテール（裾）を価格評価してください。典型的なタスクではなく、最も難しい10分の1のタスクでモデルを比較してください。典型的なタスクではすべてのモデルが似たように見え、最も安いものが最良に見えますが、請求額は安いモデルが失敗するタスクによって決まります。失敗したタスクもトークンが課金され、次に再試行が課金され、さらに失敗が下流で引き起こすコストがかかるからです。テールは、何も失敗しない場合でもお金が流れる場所です。20問のWideSearch¹実行では、2つの問題が支出の43%を占めました。

マルチモデル戦略は、残りにフロンティア料金を支払うことなく、そのテールにフロンティアのインテリジェンスを費やすために存在します。



effortを調整する

effortは、モデルをタスクに合わせて調整する最も直接的な方法です。effortパラメータは、モデルがどれだけ思考、ツール呼び出し、自己検証を行うかを制御し、デフォルト（high）は要求の厳しいタスクに適しています。コストはそのすべての活動に比例して増加しますが、精度はタスクが必要とする部分にのみ比例します。モデルの上限以下では、最高のeffortレベルはタスクが決して使わない深さに対して支払うことになります。

研究およびナレッジワークのベンチマーク（WideSearch¹、DeepWideSearch⁶、BrowseComp⁴、GDPval²、すべてClaude Fable 5）では、コストに対する精度の曲線はほぼ平坦です。lowはタスクあたりコストの3分の1から半分の削減と引き換えに1〜3ポイントを失い、mediumはデフォルトのコストの70%〜85%でデフォルトの精度に匹敵し、デフォルトは4つのいずれでもmediumに対して測定可能な何も得られませんでした。DeepWideSearchでは、lowはClaude Sonnet 5ワーカーを持つオーケストレーターにも20%低いコストで匹敵しました。effortを下げることがアーキテクチャの変更に勝ったのです。

低い設定はより速くもあり、レイテンシが制約である場合に重要です。これらの実行では、DeepWideSearchでlowは問題あたり4.5分かかり、デフォルトでは7.9分でした。入力がどの単一コンテキストウィンドウにも収まらないコーパスベンチマークでは、Fable 5はlow、medium、デフォルトでエピソードあたりそれぞれ7.9、9.1、11.4時間かかりました。

長期的なコーディングはもう一方の形です。SWE-bench Pro³では、Claude Opus 5はmediumで半分のコストと引き換えに約2ポイント、lowで4分の1のコストと引き換えに約8ポイントを失いました。これは本物のトレードオフであり、より高いeffortでの失敗の再実行によって節約に戻すことができます。このチャートは、研究およびナレッジワークのベンチマークとSWE-bench Proについて、コストに対する精度をプロットしています。

2つの帰結が導かれます。第一に、2つ目のモデルを追加する前に、自分のワークロードでこの曲線を描いてください。これらの社内測定では、デフォルトの単一モデルより安く見えたマルチモデル構成は、同じモデルをより低いeffortで使うよりもコストがかかりました。第二に、この曲線はあらゆるマルチモデル戦略が上回らなければならない単一モデルのベースラインであるため、自分のワークロードでの測定のステップ2ではeffortレベル全体でベースラインを取ります。

精度が本当に推論の深さに比例する、モデルの上限に達するワークロードでは、低いeffortは精度を犠牲にします。各レポートがサブトピックごとの深い推論に報いるDeepResearch Bench II⁷では、effortの各ステップがルーブリックスコアで約2.4ポイントをもたらしました。その曲線には無償のコスト削減はありません。

タスクの説明だけでは、どちらの種類のワークロードを持っているかはわかりません。自分のトラフィックのサンプルで2〜3のeffortレベルをスイープし、曲線から答えを読み取ってください。各レベルは別々のセッションでテストしてください。セッション途中でeffortを変更するとキャッシュが無効になり（繰り返されるコンテキストをキャッシュするを参照）、比較が歪みます。パラメータの詳細については、Effortを参照してください。



より高いeffortで失敗を再実行する

タスクの結果が検証可能な場合、effort曲線上で最も安価なポリシーは固定設定ではありません。すべてのタスクを低い設定で実行し、失敗したものだけをより高い設定で再実行します。

Anthropicは、effortを調整するのSWE-bench Pro³サブセットでのeffort実行から、このポリシーをタスクごとに計算しました。Claude Opus 5をlowで使うと、タスクの16%が失敗しました。それらをデフォルトで再実行すると、約93%が1件あたり約$0.70で合格し、すべてをデフォルトで実行した場合の91.7%・$1.39と比較して、失敗した安価な試行を含めても半分のコストで同じ合格率でした。代わりにmediumから始めると、約94%を約$0.95で解決しました。小さな向上のほとんどは2回目の試行によるものです（デフォルト自身の失敗をデフォルトで再実行しても、より多くの費用でほぼ同じスコアになります）。したがって、このポリシーは向上のためではなく節約のために使用してください。

2つの条件が適用されます。第一に、失敗シグナルが必要です（ここではベンチマーク自身のテスト）。悪い作業を合格させるチェッカーは、それらの失敗を通過させてしまいます。第二に、初回パスの失敗はすべて2回分の実時間がかかるため、節約は失敗時のレイテンシで支払われます。



予算と出力上限を設定する

ほとんどのエージェントタスク実行は安価ですが、少数は検索、再検証、過剰なテストに中央値コストの何倍も費やします。タスク予算はそのテールを対象とします。モデルはタスク全体のライブトークンカウントダウンを見て自己調整し、価値の低い検索を削り、冗長な検証をスキップし、迷走する代わりにまとめに入ります。

Anthropicは、予算を厳しくしていったときのSWE-bench Pro³での合格率とタスクあたりコストを、Claude Fable 5で測定しました。

余裕のある予算は18%のコスト節約と引き換えに合格率を約2.7ポイント失い、許容される最も厳しい予算は47%の節約と引き換えに4.4ポイントを失いました。ここで予算がもたらしたのは効率であり、精度ではありません。

3つの制御は3つの異なる仕事をします。タスク予算はモデルがそれを見るため、費用を節約します。max_tokensは何も節約しない安全上限です。Claude Managed Agentsでは、セッション予算が両者の背後にあるドル建てのハードストップです。3つすべてを設定してください。タスク予算、高いmax_tokens、そして請求書に決して載せたくない実行のためのセッション上限を設定し、最後の防波堤としてワークスペース支出制限を設定します。

• タスク予算 はClaude Opus 5、Claude Fable 5、Claude Opus 4.8、Claude Opus 4.7でベータ版（ベータヘッダー task-budgets-2026-03-13）ですが、Claude Sonnet 5では利用できません。まずサポート表を確認してください。ループの90パーセンタイルのトークン使用量付近から始め、その後厳しくしていきます（予算の選択でその分布の収集方法を示しています）。現在の20,000トークンの下限を下回る予算は拒否され、非常に厳しい予算は拒否のような動作を引き起こす可能性があります。タスク途中の変更はキャッシュを無効にするため、予算は最初のリクエストで一度だけ設定してください。予算は助言的なものであり、モデルを停止させるのではなく誘導するものなので、自分のワークロードで遵守状況を検証してください。
• max_tokens は単一のレスポンスに上限を設けますが、モデルには見えないため、下げてもモデルは節約しません。その余地を必要としたターンは破棄され、それでも課金されます。社内のリポジトリタスクベンチマーク¹²では、16,384トークンの上限がClaude Opus 5の試行の15%、Claude Fable 5の試行の3分の1を終了させ、そのいずれも解決されませんでした。上限付きの実行は試行あたりの支出は少なかったものの、比例して解決数も少なかったため、解決タスクあたりのコストは64,000の場合と同じでした。その設定では何も切り捨てられず、両方の実行がスコア付けした問題でFableは36.6%ではなく54.6%のタスクを解決しました（参照12で説明されているSWE-bench Pro³サブセットの別のカットでは、90%ではなく92%）。上限に達した試行を再試行してもコストが増えるだけです。同じ上限では決して成功せず、より高い上限では無駄になった試行の分も支払うことになります。エージェント作業ではmax_tokensを64,000に設定し（xhighまたはmax effortでは最大値の128,000）、その大きさのレスポンスはストリーミングし、stop_reason: max_tokensを失敗として扱い、モデルが見ることのできるeffortとタスク予算で費用を節約してください。
• Claude Managed Agentsのセッション予算 はハードストップです。セッション予算は、トークン、検索、セッション時間の定価での1セッションに対するドル建て上限です。上限に達すると、セッションはstop_reason: budget_reachedで一時停止し、予算を引き上げると再開します。プラットフォームによって強制され、定価のあるあらゆるモデル（Claude Sonnet 5を含む）で機能し、助言的なタスク予算と組み合わせられます。デプロイメントは同じフィールドをすべての実行に適用します。

2つのmax_tokensチャートのうち1つ目は、各上限での試行あたりおよび解決タスクあたりのコストをプロットしています。

2つ目は、ターンごとの出力長を上限に対してプロットしています。



モデルを組み合わせる

マルチモデルアーキテクチャは、タスクの複雑さが十分に変動し、異なるステップが異なるモデルによって最もよく処理されるワークロードに適しています。トラフィックに、小さなモデルが確実に処理できる定型作業と、フロンティアの能力を必要とするより難しいステップが混在している場合、作業を分割することで、ほとんどのトークンを小さなモデルの料金で課金しながら、重要な場所にフロンティアのインテリジェンスを維持できます。難易度が均一であるか、1つの依存チェーンであるためにワークロードにその混在がない場合、通常は単一のよく調整されたモデルのほうが良い選択です。各戦略のセクションでは、2つのケースを見分けるためのルールを示します。

2つの戦略がほとんどのワークロードをカバーし、どちらのモデルがメインループを保持するかが異なります。



アドバイザー戦略：難しい判断をエスカレーションする

アドバイザー戦略では、低コストのエグゼキューターモデルがエージェントループを実行し、ほとんどのターンを処理します。アプローチの選択や失敗からの回復など、より深い判断が必要な決定に直面したとき、エグゼキューターは戦略的なガイダンスを得るために高知能のアドバイザーモデルを呼び出し、その後処理を続行します。ほとんどのトークンはエグゼキューターの料金で課金され、時折の相談のみがアドバイザーの料金で課金されます。

これを使用するには、リクエストにアドバイザーツールを追加します。このベータ機能は、戦略全体を1つの /v1/messages リクエスト内でサーバーサイドで実行します。エグゼキューターがツール呼び出しを発行し、Anthropicがアドバイザーの推論を実行し、エグゼキューターがそのアドバイスを受けて続行します。オーケストレーションコードを書く必要はありません。Claude Managed Agentsでは、エージェントの multiagent ロスターに advisor エントリを追加することでセッションにアドバイザーを与えます。セッションのプライマリスレッドは同じ方法でアドバイザーに相談します。Claude Codeもこれをサポートしています。アドバイザーツールで難しい判断をエスカレーションするを参照してください。

効果を決めるもの。 アドバイザーはエグゼキューターの呼び出しを通してのみタスクを見るため、どれだけ役立つかは2つの要素で決まります。

1つ目はモデル間のギャップです。アドバイザーはエグゼキューターに欠けている能力しか渡すことができません。GPQA Diamond⁹では、Claude Haiku 4.5エグゼキューターはClaude Opus 5アドバイザーから大きな恩恵を受け、Claude Sonnet 5エグゼキューターは数ポイント向上し、フロンティアエグゼキューターはほとんど何も得られませんでした。

2つ目は、そして脆弱な方ですが、エグゼキューターが実際に相談するかどうか（相談率）です。低いeffortのエグゼキューターは、自分が行き詰まっていることに気づかなくなることがあります。デフォルトのeffortではほとんどのタスクで相談するペアリングが、effortを下げるとほとんど相談しなくなり、その結果エグゼキューター単独よりも低いスコアになることがあります。相談率はタスクによっても異なります。DeepSWE¹⁰では、低effortのSonnet 5エグゼキューターは相談を続けて23ポイント向上しましたが、SWE-bench Pro³では同じエグゼキューターが相談をやめました。エグゼキューターが実際に相談する場合、ほぼ目標に到達します。次のチャートのペアリング全体で、アドバイザーはより強力なモデルとのギャップの60%から90%を埋めましたが、そのモデルへの支払いは相談時のみでした。これがコスト面でのメリットを可能にしています。

相談率はプロンプトに反応します。ツールの組み込み説明のみでは、エグゼキューターは特にコーディング作業で呼び出しが不足するため、アドバイザーツールのドキュメントでは、実質的な作業の前に1回、終了前に1回の呼び出しを求めるシステムプロンプトを提供しており、タスクあたり約2〜3回の呼び出しになります。次に測定したコーディングのペアリングはそのペースで実行され、すべてのタスクで約2回の相談が行われました。そのページでは、呼び出しが不足しているエグゼキューターを促す方法や、コストを制限するためにクライアントサイドで呼び出し回数に上限を設ける方法も説明しています。したがって、相談率を監視してください。プロンプトで促し、測定し、相談率が崩れた場合はエグゼキューターのeffortを元に戻してください。

コスト面で効果がある場合。 アドバイザーの料金で課金される数回の短い相談が、タスク全体でアドバイザーのモデルを実行することに置き換わる場合、アドバイザーはコストを節約します。これはアドバイザーのモデルの価格がエグゼキューターの価格を大きく上回る場合に最も効果的であるため、最もコスト効率の高い構成は、中位層のエグゼキューターの上にフロンティアアドバイザーを置くものです。アドバイスはエグゼキューターのトークンも節約するため、ペアリングは価格帯の最上位でも十分に通用します。正しいアプローチを教えられたエグゼキューターは行き止まりの探索が少なくなり、それが相談のコストを賄うことができます。

プレーンなAPIエージェントで実行した社内のエージェント型コーディングベンチマーク¹¹では、Claude Fable 5アドバイザーを伴うClaude Opus 5エグゼキューターが、測定された中で最も正確な構成でした。試行あたり$8.40で試行の85.7%を解決しました。これは各モデル自身のeffort設定を通る線の上に位置しますが、それらの最良のもの（デフォルト設定のOpus単独が$8.50で84.4%、medium のFable単独が$8.20で83.4%）を1〜2ポイント上回るだけであり、1回の実行ではノイズと区別できません。medium effortのFable単独は、ペアリングとほぼ同じ精度（85.7%に対して83.4%）にほぼ同じ金額（試行あたり$8.40に対して$8.20）で到達します。

Claude Codeのアドバイザーモードを通じた以前の測定でも同じ順序が得られました。この結果は節約としてではなく、自分のワークロードでテストすべき形として読んでください。価格帯の最上位では、アドバイザーはフロンティア価格でわずかな精度を買うものであり、コスト面でのメリットは、次のチャート読み取りのケースのように、能力ギャップがより広いペアリングに属します。レイテンシのコストは相談そのものです。このベンチマークではタスクあたり約2回の追加のフロンティアモデル呼び出しがあり、それぞれがタスクのクリティカルパス上にあります。

effortを上げる代わりに効果がある場合。 能力ギャップがより広く、ワークロードの精度がeffortに反応する場合、アドバイザーに相談する低effortのエグゼキューターは、エグゼキューター自身のeffortを上げるよりも安価なステップアップになり得ます。アドバイザーへの支払いはそれを必要とするタスクでのみ発生するためです。

Claude Managed Agents上でそのアドバイザーを使って実行した公開のチャート読み取りベンチマークであるChartography¹³では、Claude Fable 5アドバイザーを伴う low effortのClaude Opus 5エグゼキューターが、タスクあたり$0.60で67.5のスコアを記録しました。これはどちらのモデル自身のeffort設定を通る線よりも上です（Opus単独は low と medium の間で$0.38から$0.94で49から75になりました）。ただし、エグゼキューター自身の medium とデフォルト設定は、1.6倍と3.3倍の価格で依然として最高スコアを保持しています。

低effortのエグゼキューターはタスクの86%でアドバイザーに相談しました。これはSWE-bench Proのペアリングが満たせなかった条件です。この構成に依存する前に、自分のエージェントループで相談率を測定してください。

どのようなペアリングであっても、まずアドバイザーのモデル単独を低effortで価格評価してください。それが上回るべきベースラインです。モデルのリリースごとに再確認してください。リリースは能力ギャップと価格比の両方を動かすためです。

適している場合。 アドバイザー戦略は、ターンのほとんどが機械的であるものの優れた計画が重要なワークロードに適しています。コーディングエージェント、コンピュータ使用、マルチステップのリサーチパイプラインなどです。すべてのターンが本当にフロンティアの能力を必要とする場合、計画すべきものがない場合（シングルターンのQ&A）、またはエグゼキューターがすでにアドバイザーの能力に近い場合には適していません。



オーケストレーター戦略：大量の作業を委任する

オーケストレーター戦略では、フロンティアモデルがループを保持します。タスクを分解し、サブタスクを低コストのワーカーモデルにディスパッチし、その結果をマージします。トークンを大量に消費する探索はワーカーが吸収するため、オーケストレーター自身のトランスクリプトは短く保たれます。そのため、ほとんどのトークンはワーカーの料金で課金されますが、計画と統合は依然としてフロンティアモデルから得られます。

これを構築するには、Claude Managed Agentsのマルチエージェントオーケストレーションを使用します。コーディネーターエージェント（オーケストレーター）と、それぞれ独自のモデルを持つワーカーエージェントのロスターを構成します。Claude Fable 5コーディネーターとClaude Sonnet 5ワーカーを使った完全な動作例については、Claude Cookbookのレシピコーディネーターパターン：計画には大きなモデル、実行には小さなモデルを参照してください。

このパターンは、ワーカーが並列に実行できる場合に実時間を節約します。コーパスベンチマーク⁸では、コーディネーターがプラットフォームの文書化された上限である25の同時ワーカーを実行した場合、1エピソードに2時間強かかりましたが、単独では11.4時間でした。コストを節約したのは測定された2つの状況のみでした。単一のモデルが単独で処理できる作業では、同じモデルを低いeffortで使う方が毎回安価でした。

ケース1：定型作業におけるコストテールに対する保険。 単独で実行されるフロンティアモデルは、通常なら解決できる定型的な問題で時折スパイラルに陥ります。どれがそうなるかを事前に知ることはできないため、そのような少数の実行が請求額を支配します。定型作業を低コストのワーカーに渡すコーディネーターは、そのテールに上限を設けます。スパイラルが発生してもワーカーの料金で発生するためです。

Anthropicはこれを、意図的に簡単にしたBrowseComp⁴のスライス（単独モデルが確実に解決する10問、委任実行50回と単独実行70回）で測定しました。1つのClaude Sonnet 5ワーカーを伴うClaude Fable 5コーディネーターは、平均でFable単独の半分弱のコストで、90パーセンタイルでは約3分の1のコスト（$33に対して$12）でした。また、単独モデルの最も高価な1回の実行は$84で、しかも不正解でした。

委任は、作業のうち定型的で通常解決可能な部分で効果がありました。これはワーカーが難しい問題のためのものだという直感とは逆です。完全な、より難しいBrowseCompセットでは、経済性が逆転しました。トラフィックに定型タスクでの長いコストテールがある場合、これが最初に測定すべきオーケストレーターのケースです。

ケース2：1つのコンテキストウィンドウより大きい作業。 単独モデルは、それほど大きな入力を一度に1つのコンテキストウィンドウずつ逐次的に処理しなければならず、パスごとに自身の状態を再読み込みするコストを支払います。ワーカーはそれぞれ自分のパーティションを、並列に、ワーカーの料金で読みます。読み取りが多くても1つのコンテキストウィンドウに収まる作業は、委任の問題ではなくモデル選択の問題です。読み取りコストだけで見ると、オーケストレーターが優位になるのは、単一のコンテキストで作業を保持できない場合のみです。

Anthropicはこのケースのためのベンチマークを構築しました⁸。14の公開Pythonパッケージからなる2,160万トークンのコーパスに130の欠陥を埋め込んだもので、どのコンテキストウィンドウにも大きすぎます。請求額はコーパスの読み取りそのものであるため、effortを下げても役に立ちません。Claude Fable 5単独はすべてのeffort設定でエピソードあたり$720から$764のコストがかかり、動いたのは精度だけでした。コーディネーター構成はそれらのどの設定よりも60%以上安く、medium またはデフォルトのFableより2〜6ポイント低いスコアでしたが、Claude Sonnet 5単独のベースラインには完全に勝ちました。

トークンの会計がその理由を示しています。どちらの請求額も、ほとんどがキャッシュから提供されるコーパスの読み取りです。コーディネーター構成はエピソードあたり約5億7,000万のキャッシュ済みトークンを読み取り、これは単独モデルの約2億のほぼ3倍ですが、それでもコストは半分未満でした。その読み取りがClaude Fable 5ではなくClaude Sonnet 5のキャッシュ読み取り料金で課金されたためです。デフォルトeffortのFable 5は、コーディネーター構成の2.8倍のコストで依然として最高精度を保持しているため、ここでの委任は精度のほとんどを買うものであり、すべてではありません。

委任が効果を発揮しない場合。 オーケストレーターが何かを買えるのは、渡すべき大量の作業がある場合のみです。多くの独立した部分、理想的には1つのコンテキストウィンドウには多すぎる量です。作業が1つの依存チェーンである場合、または単一のコンテキストに収まる場合、オーケストレーターは、単一のモデルなら無料で得られる計画、引き渡し、マージのコストを支払います。測定されたそのようなすべてのケースで、コーディネーターのモデル単独を低いeffortで使う方が優位でした。

BrowseComp⁴は1つのベンチマーク内でその境界を示しています。委任は定型スライスでは効果があり、完全な、より難しいセットでは負けました。そこではフロンティアモデル単独が、22%から30%低いコストでコーディネーター構成の精度に到達しました。独立した外部の研究も同じパターンを報告しています⁵。作業が1つのチェーンである場合、長いコストテールなしに1つのコンテキストに収まる場合、または低いeffortの単一モデルがすでに基準を満たしている場合は、オーケストレーターを構築しないでください。



戦略を選択する

ほとんどのケースは1つの質問に帰着します。作業は独立した部分に分割されるのか、それとも依存するステップのチェーンを通じて到達する1つの答えなのか。戦略表は、2つの答えを2つの戦略にマッピングしています。

確信が持てない場合は、まだ何も構築しないでください。

1. まず現在のモデルでeffortをスイープしてください。これはこのページで最も安価な実験であり、ほとんどのワークロードはそこで終わります。
2. スイープでギャップが示された場合、より強力なモデル単独を低effortで価格評価してください。それがアドバイザーのペアリングが上回るべき数値であり、このページでそれを上回ったペアリングは、エグゼキューターが実際に相談したものでした。

このページのマルチモデルの結果は、同じモデルの低いeffortと、1つ下のモデルの単独実行に対して評価されました。それが自分のワークロードで実行すべき比較であり、最初のステップがeffortスイープである理由です。

アドバイザーを追加する場合、それは再アーキテクチャではなくツール定義です。



自分のワークロードで測定する

このページの数値は2026年7月と8月のもので、当時の定価に基づいており、モデルと価格が変わるにつれて変動します。エスカレーション率、タスクがどれだけきれいに分割されるか、トランスクリプトの長さもそれらを動かします。方法は同じままです。

1. 本番ログから実際のトラフィックと同様に重み付けしたいくつかのタスクを取り出し、それぞれに結果チェックを書きます。テストが通る、チケットがクローズされる、行数が正しい、などです。スコアの横にタスクあたりのコストを記録します。各レスポンスの usage にある4つのトークン数をそれぞれの料金で価格付けし、タスクのリクエスト全体で合計します（Usage and Cost APIが集計を報告します）。
2. デフォルトだけでなくeffortレベル全体でモデル層のベースラインを取り、支出に対してスコアをプロットします。マルチモデル構成は単一モデルの曲線全体を上回らなければなりません。
3. 曲線がeffortでは埋められないギャップを示す場合、適合するマルチモデル戦略を追加してスイートを再実行します。
4. 切り替え前にトラフィックのスライスで勝者をシャドウ実行し、その後もスイートを実行し続けます。

次の例は、Claude Opus 5の定価で1つのリクエストのステップ1のコストを計算します。

# 料金ページ記載の100万トークンあたりの価格。別のモデルの場合はこの2つを変更してください。
INPUT_PER_MTOK = 5.00  # Claude Opus 5
OUTPUT_PER_MTOK = 25.00

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
usage = response.usage
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # キャッシュ書き込みは入力価格の1.25倍（5分キャッシュ）、キャッシュ読み取りは0.1倍で課金されます。
    + (usage.cache_creation_input_tokens or 0) * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * INPUT_PER_MTOK * 0.10
    + usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
print(f"Request cost: ${cost:.6f}")

エージェントループでは、キャッシュ読み取りの項が通常4つの中で最大です。そうでない場合は、キャッシングが有効になっていることを確認してください。アドバイザーツールまたはコンパクションが有効な場合、一部のトークンは usage.iterations にのみ報告され、トップレベルの合計には報告されないため、代わりに usage.iterations を合計し、advisor_message エントリはアドバイザーモデルの料金で価格付けしてください。

次の表は、試すべき順序でレバーを一覧にしています。



参照したベンチマーク

すべての測定は、これらのベンチマークのAnthropic社内での実行です。特に記載がない限り、コストは2026年8月の定価での米ドルです。Claude Sonnet 5の数値は、入力と出力の100万トークンあたり$2と$10を使用しています。「notional USD」とラベル付けされたチャートは、請求書を報告するのではなく、各リクエストのトークン数をそれらの料金で価格付けしています。

1. WideSearch: Wong et al., "WideSearch: Benchmarking Agentic Broad Info-Seeking," arXiv:2508.07999, 2025. 多数行の表の完全性と正確性で評価される広範なウェブリサーチタスク。200問、構成ごとに3回実行。キャッシングとeffortのチャートは別々の実行から得られたため、問題ごとのコストはわずかに異なります。コスト集中のチャートは別の20問の実行で、問題ごとに3回実行し、リクエストごとの課金記録からコストを算出しています。
2. GDPval: OpenAI, "GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks," 2025. タスクのルーブリックに対して評価されるナレッジワークの成果物。公開されたゴールドセットの210タスクの実行で、タスクごとに1回の試行。Claudeモデルが評価するため、絶対スコアは公開された結果と異なる場合があります。
3. SWE-bench Pro: Scale AI, "SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?", 2025. Anthropicの評価ハーネスとの互換性のために選択された482問のサブセット。スコアは公開リーダーボードと比較できません。デフォルトeffortのClaude Opus 5は2回の実行の平均で、effortを下げた設定は1回の実行です。エスカレーションの数値はそれらの実行からタスクごとに得られます。まず low、次にその失敗に対してデフォルトを実行すると、実行のペアリング全体で約$0.70で92.5%〜93.6%を解決。まず medium の場合、約$0.95で93.8%〜94.2%。デフォルトを自身の失敗に対して再実行した場合、$1.58で94.0%。すべてをデフォルトで実行した場合、$1.39で90.9%〜92.5%。アドバイザーチャートのClaude Sonnet 5エグゼキューターのペアリングは、このサブセットでの同じ2026年8月のシリーズから得られています。SonnetとOpusのペアリングは2回（1回の実行と正確な再現）実行され、低effortのペアリングは1回です。タスク予算の数値は同じサブセットで予算ごとに1回の実行です。モデルを比較するのClaude Fable 5の数値は2026年7月の1回の実行で、タスク予算チャートの予算なしベースラインでもあります。予算付きのすべての実行は、ハーネスエラーなしで482問すべてを完了しました。
4. BrowseComp: Wei et al., "BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents," OpenAI, 2025. effortの数値は500問のカットを使用し、設定ごとに1〜3回実行。コスト保険のチャートは26問のスライスから確実に解決される10問を使用し、委任実行50回と単独実行70回（期待値で実行あたり$11.99に対して$6.45）。委任の数値には約20%の測定幅があります。
5. エージェントアーキテクチャのスケーリング: Kim et al., "Towards a Science of Scaling Agent Systems," arXiv:2512.08296, 2025. 独立した外部研究で、委任が効果を発揮しない場合に関する知見の方向性についてのみ引用しており、いかなる数値についても引用していません。
6. DeepWideSearch: "DeepWideSearch: Benchmarking Depth and Width in Agentic Information Seeking," arXiv:2510.20168, 2025. 220の質問が15のドメインにまたがり、それぞれが多数行の収集とマルチホップ検索を組み合わせています。ベンチマークの標準行セットで測定し、構成ごとに3回実行。
7. DeepResearch Bench II: Li et al., "DeepResearch Bench II: Diagnosing Deep Research Agents via Rubrics from Expert Report," arXiv:2601.08536, 2026. 22のドメインにわたる132のリサーチタスクが、専門家由来のバイナリルーブリックに対して評価されます。すべてのテーマにわたって層化された50タスクのサブセットで測定し、タスクごとに1回の試行、3回実行、どの構成も拒否しなかったタスクでスコア付け。Claude Opus 4.6がベンチマークのルーブリックプロトコルの下で判定します。オリジナルは異なる判定者を使用しており、Anthropicの判定者は自社のスタイルを好む可能性があります。これらの実行はClaude Opus 5より前のものであるため、モデルを比較するのチャートには含まれていません。Sonnet 5のコストは、キャッシングチャート（キャッシングありとなしの推論コスト）とそのチャート（キャッシングありの総コスト）でわずかに異なります。どちらも同じ実行から得られています。
8. コーパス欠陥スイープ: Anthropic社内、1つのコンテキストウィンドウより大きい作業向け。14の公開Pythonパッケージソースからなる2,160万トークンのコーパスに130の欠陥を埋め込み、決定論的に評価。プロトコルは実行前に固定され、社内でレビュー済み。構成ごとに3回実行。すべての構成はClaude Managed Agents上で実行されました。チャートに示されたチーム構成は2026年8月の実行で、Claude Fable 5コーディネーターがプラットフォーム内で、文書化された上限である25の同時Claude Sonnet 5ワーカーでスイープ全体を実行しました。その3つのエピソードはF1 0.842、0.805、0.810を$263、$299、$261で記録しました。単独構成は同じコーパスビルドでの2026年7月の実行です。絶対F1はこのコーパスビルドに固有のもので、ベンチマーク間で比較できません。構成の比較は同一条件です。
9. GPQA Diamond: Rein et al., "GPQA: A Graduate-Level Google-Proof Q&A Benchmark," 2023. 198問のDiamondサブセット、2026年8月に測定、構成ごとに2回実行、参照解答に対してモデルが評価、アドバイザートークンはリクエストごとに計測。プラットフォームの安全性チェックがSonnetとOpusのエグゼキューターで2つの生物学の質問を拒否しました。それらを除外しても、どの比較も1ポイント以上変わりません。
10. DeepSWE: Datacurve, "DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks," arXiv:2607.07946, 2026. 2026年8月に測定。プログラムベースの検証器を備えた5つの言語にわたる113のオリジナルタスク。ペアリングはそれぞれ2回実行でアドバイザートークンはリクエストごとに計測され、アドバイザーツールではなくクライアントサイドのアドバイザーループを使用しましたが、会計は同一です。単一モデルのeffortスイープはトークン数から価格付けした1回の実行で、キャッシュを考慮した近似です。タスクあたりのコストは実行の合計を113で割ったものです。
11. 社内エージェント型コーディングベンチマーク: Anthropic社内。リポジトリ自身のテストで評価される370のリポジトリタスク。APIの数値（Opus 5単独、Fable 5単独、およびペアリング）は2026年8月にデフォルトeffortで128,000トークンの出力上限で測定され、構成ごとに1回実行。デフォルト設定とペアリングではタスクごとに5回の試行、low と medium では1回。ペアリングは試行あたり平均約2回のアドバイザー相談を行いました。コストは試行あたりです。Claude Codeの数値は同じタスクの2026年7月の実行で、構成ごとに1回実行、コストは概算です。
12. 社内リポジトリタスクベンチマーク（上限測定）: 約130のリポジトリタスクからなる別のAnthropic社内セットで、2026年8月にプレーンなAPIエージェントループで実行、タスクごとに1回の試行。16,384トークンの数値はモデルごとに2回の実行の平均で、64,000トークンの数値は1回の実行です（Opus 5では124タスクをスコア付け、Claude Fable 5では108タスク。残りはモデルが実行される前に環境がスキップしました）。16,384の上限で終了したFableの試行の約半分は、64,000では解決済みで終了していました。128,000でのさらなるFableの実行は56.1%を記録し、64,000の実行とノイズの範囲内でした。SWE-bench Proの上限の数値は、参照3の482問セットから層化した100問のサブセットで、デフォルトeffortで上限ごとにClaude Fable 5を1回実行したもので、そのスコアとは比較できません。チャートのターンごとの分布は64,000でのOpusの実行と128,000でのFableの実行から得られているため、どちらも自身の上限で打ち切られていません。
13. Chartography: Surge AI, "Chartography," 2026. 公開された100問の完全なセットで、2026年8月にClaude Managed Agents上のAnthropicの実装で測定（標準クラウドサンドボックス、アドバイザー構成はManaged Agentsのアドバイザーを使用）。参照判定者の代わりにClaude Sonnet 4.6が評価し、ベンチマークはツール付きで実行されるため、スコアはここでの構成間では比較できますが、公開リーダーボードとは比較できません。構成ごとに2回実行し、プール。実行間のばらつきは4〜10ポイントでした。コストにはサンドボックス時間は含まれておらず、それは1%未満の追加でした。相談率の比較は、同じ構成をコンテナツールセットを使ってMessages APIで再実行したものから得られています。
14. サポートデスクのプロンプト監査評価: Anthropicが構築した44のサポートチケットのセットで決定論的に評価し、2026年8月に6つのシステムプロンプトの下で実行。それぞれが同じクリーンなプロンプトに、Claude Opus 4.8とClaude Sonnet 4.6向けに書かれたプロンプトによく見られるパターンを1つ追加しています。各チャートの点は3つのケース（古いモデル、同じプロンプトでの新しいモデル、監査後の新しいモデル）のいずれかで、6つのプロンプトと44のチケットで平均しています。Opus 5の精度向上の95%信頼区間は3〜8ポイントで、Sonnetの精度の差はノイズの範囲内です。



次のステップ