委譲の損益分岐（The Break-Even Point of Delegation）
委譲には倍率の値札が付いている。しかも費用は委譲の副作用ではなく、効き目の本体である — 委譲が効くのは、多くのトークンを問題に注ぎ込めるようになるからだ。だから問いは「分けられるか」ではなく、その仕事は倍率を払う価値があるかである。
問題
委譲の判断は「大きいタスクだから分けよう」という直感で行われがちである。ところが委譲の費用は直感より大きく跳ねる — エージェントは chat の約4倍、マルチエージェント構成は約15倍のトークンを使ったという自社計測がある（公式、Anthropic 自社データ・research 用途。出典は具体例節）。倍率が意識されないまま委譲が選ばれると、両側で間違える。小さな仕事を並列化して、固定費と倍率だけを払う。逆に、倍率を払う価値のある仕事を、費用を恐れて単一のコンテキストに押し込み、溢れさせる。
コンテキスト
適用する条件:
- 委譲するかどうかを選べる場面すべて。 「読み捨ての隔離」や並列化を使うかどうかの判断は、実質このパターンである
- 費用（トークン・クレジット・遅延）が実際に制約であるとき。 支出が気にならないなら、分岐を探す動機もない
適用しないケース — 値札を見るまでもない場面:
- 単一のコンテキストに収まらない仕事。 上限は費用では買えないので、値札に関係なく分けるしかない
- 全員が同じコンテキストを共有する必要がある仕事、工程間の依存が多い仕事。 公式 が「not a good fit」と名指ししている領域であり（出典は具体例節）、値札以前に、分けても効かない
損益分岐は選択肢があるときの道具である。どちらかしか選べないなら、見積もりは要らない。
隣接パターンとの境界:
- 読み捨ての隔離 — 隔離するという構造が同パターン、その値札が本パターン
- 思考深度をタスクに合わせる — 同パターンはどれだけ考えさせるかの値札、本パターンは誰にやらせるかの値札。交点はサブエージェント単位のモデルと深度の指定である（具体例節）
- セッション境界の設計 — コンテキストが溢れそうなとき、切るか委譲するかは代替関係にある。切る側の設計が同パターン、委譲する側の値札が本パターン
解決
委譲の費用は倍率で増え、便益は非対称性から来る。この2つは別の量なので、片方だけ見ると必ず間違える。図の2本の線がそれを表している。委譲の線は原点を通らない — 立ち上げ、タスクの記述、結果の統合という固定費が、仕事の大きさと無関係に掛かる。そして傾きは倍率で急である。つまり小さな仕事では、委譲は構造的に高くつく。分岐点より左に交点は無い。
なぜ委譲は効くのか。公式 の説明は直感に反する — マルチエージェントが効くのは主に「問題を解くのに十分なトークンを使えるようにするから」であり、ある評価では性能の分散の80%がトークン使用量だけで説明できた（公式、Anthropic 自社分析。出典は具体例節）。我々は委譲を「分業で賢くなる」と考えがちだが、この説明は「単に多く注ぎ込めるから良くなる」に近い。委譲は賢さを足す仕掛けではなく、予算を積む仕掛けである。
費用が効き目の本体だとすれば、費用を「委譲の副作用」として扱う見積もりは、根本から向きを間違えている。倍率は無駄ではなく、それこそが買っているものである。だから判断基準は一つに絞れる — その仕事は、倍率を払っただけの価値を返すか。公式 自身が経済的成立の条件をそう書いている（「the value of the task is high enough to pay for the increased performance」。出典は具体例節）。
図の右端が、この見積もりの外側である。単一コンテキストの上限は費用では買えない。上限を超える仕事は損益分岐の対象ではなく、値札に関係なく分けるしかない。
逆向きの限定も同じ 公式 にある — 全エージェントが同じコンテキストを共有する必要がある領域、依存の多い領域は「not a good fit」であり、コーディングは research より並列化できる仕事が少ない、と計測の当人が書いている（出典は具体例節）。倍率だけを引いてこの限定を落とすと、読者の大半（コーディング用途）を誤らせる。
最後に、損益分岐点の数値を本カタログは与えない。誰も測っていないからである。本パターンが与えるのは判断の枠組み — 固定費・倍率・非対称性・上限という4つの変数 — であり、自分の環境の値札を実際に見る手段は道具の側にある（具体例節）。
トレードオフ
利点
- 単一コンテキストの上限を超えられる。 上限は費用では買えないため、これは委譲でしか得られない。公式 もマルチエージェントが優れる領域として「information that exceeds single context windows」を挙げている（出典は具体例節）。
- 並列性と独立した視点が得られる。 重い並列化が効く仕事は 公式 が名指しする適地であり（出典は具体例節）、経緯を知らないコンテキストが複数立つこと自体の価値は「読み捨ての隔離」が扱っている。
代償
- 倍率。 約4倍・約15倍という数値がある — ただし Anthropic の自社計測・research 用途であり、Copilot の数値でも一般法則でもない（出典は具体例節）。Copilot 側の 公式 も、仕事の分割が LLM とのやり取りの回数を増やし、クレジット消費を増やしうると明記している（公式、Copilot CLI。出典は具体例節）。
- 固定費と統合コスト。 小さな仕事では委譲のほうが確実に高くつく。しかも統合には委譲先の出力の検証が含まれ、その検証をどう組むかは別のパターンの主題である（機械ゲートと意味ゲートの分離）。
GitHub Copilot での具体例
Copilot は単一の製品ではない。さらに本パターンの中核の数値は Copilot のものですらない — 別ベンダーの自社計測である。この節では、その計測を計測として限定つきで置き、Copilot 側の 公式 が費用についてどの面で何を言っているかを併置する。
倍率の出所 — Anthropic の自社計測（他ベンダーの計測としての併記）
出典: Anthropic — Multi-agent research system（取得日: 2026-07-16）公式（Anthropic 自社計測）:
There is a downside: in practice, these architectures burn through tokens fast. In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats. For economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance.
〔訳〕欠点がある — 実際には、これらのアーキテクチャは急速にトークンを消費する。我々のデータでは、エージェントは chat とのやり取りよりおよそ4倍多くのトークンを使い、マルチエージェントシステムは chat のおよそ15倍のトークンを使う。経済的に成立するには、マルチエージェントシステムは、増分の性能に見合うだけタスクの価値が高い仕事を必要とする。
エージェントは chat の約4倍、マルチエージェントは約15倍のトークンを使い、経済的に成り立つのはタスクの価値が増分の性能に見合うときだけである — 「損益分岐」という名前の意味を支える一文である。
この数値が語る範囲
原文は「In our data」— Anthropic の自社データであり、research 用途のシステムの話である。Copilot の数値ではない。一般法則でもない。 本ページが倍率を使うのは「委譲の費用は倍率で跳ねうる」という構造の実例としてであり、あなたの環境の倍率は、後述の手段で自分で見るしかない。
同じ資料は、効く理由を費用の側から説明している 公式:
Multi-agent systems work mainly because they help spend enough tokens to solve the problem. In our analysis, three factors explained 95% of the performance variance in the BrowseComp evaluation ... We found that token usage by itself explains 80% of the variance, with the number of tool calls and the model choice as the two other explanatory factors.
〔訳〕マルチエージェントシステムが効くのは主に、問題を解くのに十分なトークンを使うのを助けるからである。我々の分析では、BrowseComp 評価における性能分散の95%を3つの要因で説明できた……トークン使用量それ自体で分散の80%を説明でき、残る2つの説明要因はツール呼び出しの回数とモデルの選択であった。
トークン使用量だけで性能分散の80%が説明できた、という分析である。「解決」で述べた核心 — 費用は副作用ではなく効き目の本体 — はここから来ている。
適用しない領域も名指しされている 公式:
Further, some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today. For instance, most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time. We've found that multi-agent systems excel at valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools.
〔訳〕さらに、全エージェントが同じコンテキストを共有する必要がある領域や、エージェント間の依存が多い領域は、現状のマルチエージェントシステムには適さない。例えば、コーディングの仕事の多くは research より真に並列化できるタスクが少なく、LLM エージェントはまだリアルタイムで他のエージェントと協調・委譲することが得意ではない。マルチエージェントシステムが優れているのは、重い並列化を伴う価値の高いタスク、単一のコンテキストウィンドウを超える情報量、そして多数の複雑なツールとのやり取りであることが分かった。
コーディングの多くは research より真に並列化できるタスクが少ない、と倍率を計測した当人が書いている。本カタログの読者の多くはコーディング用途であり、この一文を落として倍率だけを引くことはできない。向くのは、重い並列化・単一コンテキストを超える情報量・多数の複雑なツールを扱う、価値の高いタスクである。
Copilot CLI — 値札は「やり取りの回数」で書かれている
出典: Running tasks in parallel with the /fleet command（取得日: 2026-07-16）公式:
GitHub AI Credits usage: When you submit a prompt in the CLI and Copilot interacts with the selected large language model (LLM) to generate a response, this consumes GitHub AI Credits. More interactions with the LLM result in a higher consumption of GitHub AI Credits.
〔訳〕GitHub AI Credits の使用: CLI でプロンプトを送信し、Copilot が選択された大規模言語モデル（LLM）と対話して応答を生成すると、これは GitHub AI Credits を消費する。LLM とのやり取りが増えるほど、GitHub AI Credits の消費は多くなる。
Each subagent can interact with the LLM independently of the main agent, so splitting work up into smaller tasks that are run by subagents may result in more LLM interactions than if the work was handled by the main agent. Using
/fleetin a prompt may therefore cause more GitHub AI Credits to be consumed.〔訳〕各サブエージェントはメインエージェントとは独立に LLM とやり取りできるため、仕事をサブエージェントが実行する小さなタスクに分割すると、メインエージェントが仕事を処理する場合より LLM とのやり取りが増えることがある。したがって、プロンプトで
/fleetを使うと、より多くの GitHub AI Credits が消費される可能性がある。
委譲の機構を提供している側の 公式 自身が、分割は消費を増やしうると明記している。ただし言い方が違う — Anthropic はトークンの倍率で、Copilot CLI はLLM とのやり取りの回数で書いている。別ベンダー・別の面の記述であり、倍率をこちらへ移植してはならないが、向きは同じである。
VS Code — 費用の一般形と、値札を見る手段
出典: Language models（Agents concepts）（取得日: 2026-07-16）公式:
Different models consume AI credits at different rates, based on the model and the number of tokens processed. More capable models cost more per token, while lighter models extend your usage further.
〔訳〕モデルが異なれば、そのモデルと処理するトークン数に応じて AI クレジットの消費率も異なる。高性能なモデルほどトークン単価が高く、軽量なモデルは利用可能な範囲を広げる。
費用の一般形はモデル単価 × 処理トークン数である。Anthropic の倍率（トークンが増える）も、CLI の回数（やり取りが増える）も、処理トークンが増える経路としてここに帰着する。
委譲の値札は、実際に見られる（出典: Subagents in Visual Studio Code、取得日: 2026-07-16）公式:
Hover over a subagent section in the chat response to see the AI credits used by that subagent. This gives you more transparency into the cost of delegated work.
〔訳〕チャットの応答内のサブエージェントのセクションにカーソルを合わせると、そのサブエージェントが使用した AI クレジットを確認できる。これにより、委譲した作業のコストがより透明になる。
サブエージェント単位でクレジット消費を確認できる。リクエスト単位・セッション単位の確認手段もある（出典: Optimize your AI usage、取得日: 2026-07-16）公式:
To view the cost for a single request, hover over the chat response to see the credit consumption for that turn.
〔訳〕単一のリクエストのコストを見るには、チャットの応答にカーソルを合わせると、そのターンのクレジット消費を確認できる。
To view the cumulative cost and token breakdown for the entire session, hover over or select the context window control in the chat input.
〔訳〕セッション全体の累積コストとトークンの内訳を見るには、チャット入力欄のコンテキストウィンドウのコントロールにカーソルを合わせるか選択する。
「解決」の最後に述べたとおり、損益分岐点の数値は誰も与えていない。自分の環境の分岐点は、これらの手段で自分の値札を見て引くしかない。
委譲の単価を設計する — 倍率と逆向きの力
出典: 上記 Optimize your AI usage 公式:
Use custom agents with a preferred model to route specific subtasks to specialized, cost-effective models. When you invoke a custom agent as a subagent, it uses its own configured model instead of the chat session's model.
〔訳〕特定のサブタスクを専門的で費用対効果の高いモデルへ振り分けるには、希望するモデルを設定したカスタムエージェントを使う。カスタムエージェントをサブエージェントとして呼び出すと、チャットセッションのモデルではなく、そのエージェント自身に設定されたモデルが使われる。
倍率が費用を上げる力だとすれば、これは下げる力である — 委譲先には自分で設定したモデルが使われるため、特定のサブタスクを安価なモデルへ振り分けておける。委譲は「量を増やす」だけでなく「単価を選ぶ」手段でもあり、両方を入れると損益の見積もりが立体になる。
「既定で低コスト」ではない
本カタログの初期メモには「サブエージェントは既定で低コストモデル」という記述があった。一次資料で確認できたのは上の逐語 — its own configured model（自分で設定したモデルを使う）— までであり、既定でどうなるかは確認できていないため書かない。安くなるのは、安いモデルを設定した場合である。
Copilot CLI では、この単価の設計がエージェント単位の設定として書ける（出典: CLI config dir reference、取得日: 2026-07-16）公式:
|
subagents.agents|object|{}| Per-agent model configuration, keyed by agent name. Each value is an object with optionalmodel(string),effortLevel(string), andcontextTier("default","long_context", or"inherit") fields. Set any field to"inherit"to use the parent session's value at dispatch time. … |〔訳〕
subagents.agentsは、エージェント名をキーとするエージェント単位のモデル設定であり、既定値は{}である。各値にはmodel・effortLevel・contextTier（"default"、"long_context"、"inherit"のいずれか）を任意で指定でき、フィールドを"inherit"にすると発行時に親セッションの値を使う。
モデルだけでなく思考深度（effortLevel）もエージェント単位で指定できる。誰にやらせるかの値札（本パターン）と、どれだけ考えさせるかの値札（「思考深度をタスクに合わせる」）が、同じ設定項目で交わる箇所である。
出所と面の対応
| 出所・面 | 費用について 公式 が言っていること |
|---|---|
| Anthropic（自社計測・research 用途） | エージェント約4倍・マルチエージェント約15倍。タスクの価値が増分に見合うことが成立条件 |
| Copilot CLI | 分割は LLM とのやり取りの回数を増やし、AI クレジット消費を増やしうる |
| VS Code | 費用＝モデル単価 × 処理トークン数。サブエージェント単位・リクエスト単位・セッション単位で消費を確認できる。委譲先のモデルは設定で選べる |
3つは矛盾しない — どれも「処理トークンが増える（または単価が変わる）経路」を別の側から述べている。ただしどの記述も、その出所と面の中でだけ正確である。
別名
| 呼称 | 出典 |
|---|---|
| 委譲の損益分岐 / The Break-Even Point of Delegation | 記述 — 本カタログの記述的呼称であり、一次資料に出典は無い |
委譲の機構には一次呼称がある — Subagent、custom agent（いずれも 一次。「読み捨ての隔離」の別名節を参照）。消費を見る手段にも公式の記述がある（具体例節）。しかし「委譲がいくらまでなら見合うか」という判断には、確認できた範囲で確立した呼称が無い。道具が与えるのは委譲する手段と値札を見る手段までであり、いくらなら払ってよいかは言わない。機構ではなく判断の側に、記述的な名前を与えた。
関連
- 読み捨ての隔離 — 隔離するかどうかの構造が同パターン、隔離にいくらかかるかが本パターン。同パターンの「境界には往復のコストがかかる」という代償に、本パターンは倍率と固定費という形を与える
- 思考深度をタスクに合わせる — 同パターンはどれだけ考えさせるかの値札、本パターンは誰にやらせるかの値札。交点はサブエージェント単位のモデルと深度の指定である（具体例節）
- セッション境界の設計 — コンテキストが溢れそうなとき、切るか委譲するかは代替関係にある。切ればコンテキストを失い、委譲すれば倍率と固定費を払う
- 機械ゲートと意味ゲートの分離 — 委譲の統合コストの中身は検証である。委譲先の出力を何で確かめるか — 機械で判定できる部分と人間の判断が要る部分の分け方 — が同パターン
- まず次に読むなら 思考深度をタスクに合わせる — 委譲の値札を見たら、次は思考の値札を見る番である