AI エージェント設計と委譲の判断 — 結局どうすればいいか
20本の原典を統合する。中心にあるのは2つの問い。そもそもエージェントにすべきか、そしてするなら誰に委譲するか。
1. まず「エージェントにしない」を検討する
すべての出発点。
When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. —
building-effective-agents可能な限り単純な解を見つけ、必要になったときにだけ複雑さを足せ。
エージェント的システムには2種類ある。混同すると設計を誤る。
| 定義 | 予測可能性 | |
|---|---|---|
| workflow | あらかじめ決めたコードパスで LLM とツールを組み合わせる | 高い |
| agent | LLM が自分で手順とツール使用を決める | 低い |
判断の順序:
- 単発の LLM 呼び出しで足りるか —— 足りるなら、それ以上やらない
- retrieval と in-context example で足りるか —— 足りるなら workflow にもしない
- 手順が事前に決まっているか —— 決まっているなら workflow（予測可能で安い）
- 手順が実行時にしか決まらないか —— agent。ただし自律性のぶんコストとレイテンシが上がる
エージェントが正当化されるのは「柔軟性とモデル駆動の意思決定が必要で、そのコストを払う価値がある」ときだけ。
2. multi-agent が効く理由は「賢さ」ではない
ここを取り違えると、効かない場面に multi-agent を持ち込む。
Multi-agent systems work mainly because they help spend enough tokens to solve the problem. —
multi-agent-research-systemmulti-agent システムが効くのは、主に問題を解くのに十分なトークンを費やせるようになるからである。
BrowseComp の性能分散の 80% がトークン使用量だけで説明された。 ツール呼び出し回数とモデル選択を足した3因子で 95%。
つまり multi-agent の価値の大半は「並列化によってより多くのトークンを問題に投じられること」。
コストの倍率:
| トークン | |
|---|---|
| チャット | 1× |
| エージェント | 約 4× |
| multi-agent | 約 15× |
| agent team（plan mode） | 約 7× |
| evaluator 付き harness | 20×（$9/20分 → $200/6時間） |
→ 価値がこのコストを正当化できるタスクにだけ使う。
逆に、効かない場面も明示されている:
- 逐次的なワークフロー — 各呼び出しが前の結果への推論に依存するなら、並列化の余地がない。
programmatic-tool-callingは τ²-bench で 8% 高くついたと報告している - 同一ファイルの編集 — teammate が互いを上書きする
- 依存関係が多い作業
building-multi-agent-systems は同じ倍率を別の測り方で出している。
In our testing, multi-agent implementations typically use 3-10x more tokens than single-agent approaches for equivalent tasks. —
building-multi-agent-systems我々のテストでは、同等のタスクに対して multi-agent 実装は単一エージェント手法の通常 3〜10倍のトークンを使う。
そして並列化の目的を取り違えるなと釘を刺す。§2 冒頭の「賢さではない」と同じ方向の指摘。
The primary benefit of parallelization is thoroughness, not speed. —
building-multi-agent-systems並列化の主たる利益は徹底性であって速度ではない。
分割は「仕事の種類」ではなく「context」で切る
効かない場面のリストに、もう一つ強いものが加わる。 分割の切り口そのものを間違えるパターンで、これは並列化の余地があっても失敗する。
The key insight is to adopt a context-centric view rather than a problem-centric view when decomposing work. —
building-multi-agent-systems鍵となる洞察は、仕事を分解するときに問題中心ではなく context 中心の見方を採ることである。
When agents are split by problem type, they engage in a “telephone game,” passing information back and forth with each handoff degrading fidelity. —
building-multi-agent-systems問題の種類でエージェントを分けると、エージェント同士が「伝言ゲーム」を演じ、情報を往復させ、引き継ぎのたびに忠実度が劣化する。
計画者・実装者・テスター・レビュアーで割る形が名指しで否定されている。同じ機能の計画と実装とテストは context を共有しすぎているので、担当を分けると引き継ぎのたびに劣化する。機能を担当するエージェントがそのテストも書く方が正しい。
これは §3 の決定木より手前にある判断で、そもそも分割線をどこに引くかの話。分割線が context の境界と一致していなければ、委譲先を正しく選んでも協調コストに食われる。
繋ぎ方は5通りあり、選択の軸はここでも context
分割線を決めた後に残るのが「どう繋ぐか」。multi-agent-coordination-patterns が5つのパターンを壊れ方で切り分けている。効く場面より、どこで壊れるかで選ぶほうが速い。
| パターン | 主な壊れ方 |
|---|---|
| Generator-verifier | 検証役の基準が曖昧だと判子を押すだけになる |
| Orchestrator-subagent | orchestrator が情報のボトルネックになる。明示的に並列化しないと速度の利益なしにコストだけ払う |
| Agent teams | teammate 同士が中間の発見を共有できない。共有資源で衝突する |
| Message bus | 追跡が難しい。ルータが取りこぼすと静かに失敗する（クラッシュしない） |
| Shared state | 反応ループ。終了条件を後回しにすると無限に循環する |
That principle applies here too. The patterns differ in how they manage context boundaries and information flow. —
multi-agent-coordination-patternsその原則（context 中心の分解）はここにも当てはまる。パターンが異なるのは、context の境界と情報の流れをどう管理するかである。
移行の合図が具体的で使える。orchestrator に条件分岐が溜まってきたら message bus へ。teammate が最終結果だけでなく互いに通信し始めたら shared state へ。
3. 委譲先の3択
選ぶ基準は2つだけ。「ワーカー同士が通信する必要があるか」と「計画を誰が持つか」。
| subagent | agent team | workflow | |
|---|---|---|---|
| 正体 | Claude が起こすワーカー | 監督下の peer セッション群 | ランタイムが実行するスクリプト |
| 次に何を走らせるか決めるのは | Claude、ターンごと | リード、ターンごと | スクリプト |
| 通信 | 親にのみ報告 | teammate 同士が直接 | — |
| 中間結果 | 親の context | 共有タスクリスト | スクリプト変数 |
| 規模 | 1ターンに数個 | 少数の長時間 peer | 1 run に数十〜数百 |
| 中断されたら | ターンをやり直す | teammate は走り続ける | 同一セッション内で再開可能 |
| コスト | 低 | 高 | 高 |
使い分けの決定木
| 状況 | 選ぶもの |
|---|---|
| 結果だけが要る、ワーカー同士の通信は不要 | subagent |
| ワーカーが互いの発見を共有し、反論し合う必要がある | agent team（対立仮説のデバッグ、並列レビュー） |
| 同じ手順を多数の項目に適用する / オーケストレーション自体を再利用したい | workflow |
| 現在のモデルが単独で確実にこなせる範囲内 | 委譲しない（harness を置くだけで 20倍になりうる） |
agent team が本領を発揮する形
agent-teams が挙げる例が、この機構の存在理由を最もよく示している。
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to each other to try to disprove each other’s theories, like a scientific debate.
5体のエージェントを立て、それぞれ別の仮説を調査させる。科学的な討論のように、互いの仮説を反証し合わせよ。
Sequential investigation suffers from anchoring: once one theory is explored, subsequent investigation is biased toward it. With multiple independent investigators actively trying to disprove each other, the theory that survives is much more likely to be the actual root cause.
逐次的な調査は anchoring（最初の仮説への固着）に陥る。ひとつの仮説を掘ると、以降の調査がそれに引きずられる。独立した複数の調査者が互いを積極的に反証しようとするなら、生き残った仮説が真の根本原因である見込みははるかに高い。
「並列だから速い」ではなく「独立だからアンカリングを避けられる」が本質。
4. 長時間・自律実行の設計
複数の原典が同じ型に収束している。
3つの失敗モードとその対処
| 失敗モード | 内容 | 構造的な対処 |
|---|---|---|
| agentic laziness | 部分的な進捗で「終わった」と宣言する | loop until done、検証ループ、/goal |
| self-preferential bias | 自分の結果を好む（特に検証を頼まれたとき） | 別 context の verifier（adversarial verification） |
| goal drift | 目的への忠実さが徐々に失われる。特に compaction 後 | 目的をファイルに保存する |
この3つはいずれも「1つの context で長く走らせる」ことに内在する。 プロンプトで直すのではなく、構造で潰す。
強力なレバー: 作る者と判定する者を分ける
3本の原典が独立に同じことを言っている。
Separating the agent doing the work from the agent judging it proves to be a strong lever —
harness-design-long-running-apps作業するエージェントと、それを評価するエージェントを分けることが、強力なレバーになる。
Separate, fresh-context verifier subagents tend to outperform self-critique. —
prompting-claude-fable-5まっさらな context を持つ検証用 subagent は、自己批判より良い結果を出す傾向がある。
a-harness-for-every-taskの adversarial verification パターン
ただし evaluator は無料ではない。 harness-design-long-running-apps は明言する。
The evaluator is not a fixed yes-or-no decision. It is worth the cost when the task sits beyond what the current model does reliably solo.
evaluator を置くかどうかは固定の yes/no ではない。現在のモデルが単独で確実にこなせる範囲を超えたタスクでこそ、コストに見合う。
セッションを跨ぐための4つの成果物
effective-harnesses-for-long-running-agents の設計。記憶を持たない交代制のエンジニアという比喩がそのまま設計指針になっている。
| 成果物 | 役割 |
|---|---|
feature_list.json | 作業範囲と passes フラグ。JSON なのは上書きされにくいから |
| git リポジトリ | 巻き戻しとチェックポイント |
claude-progress.txt | 何をやったかの自由記述 |
init.sh | 開発サーバの起動。毎セッションのトークンを節約する |
毎セッションの立ち上がり手順:
pwdで作業ディレクトリを確認- git ログと progress ファイルを読む
- 未完了で最優先の機能を1つ選ぶ
init.shで開発サーバを起動- 新しい作業の前に end-to-end テストを走らせる
規律は1つ: 1回に1機能だけ。
Rather than one-shotting implementations, agents work on only one feature at a time. This proved critical to addressing the agent’s tendency to do too much at once.
実装を一発で書き切らせるのではなく、エージェントには一度に1機能だけを担当させる。これはエージェントが一度にやりすぎる傾向に対処するうえで決定的だった。
5. 統率は薄くてよいことがある
building-c-compiler はこの前提を揺さぶる事例。
16エージェント・2週間・$20,000 で10万行の C コンパイラを作ったが、調整機構は「git のディレクトリにロックファイルを書く」だけだった。
I haven’t yet implemented any other method for communication between agents, nor do I enforce any process for managing high-level goals.
エージェント間のそれ以外の通信手段はまだ実装しておらず、上位目標を管理するプロセスも強制していない。
git の排他制御をそのまま調停に使う — 同じタスクを主張した2番目のエージェントは push に失敗して別のタスクへ移る。
教訓: 統率機構を作り込む前に、既存の仕組み（git、ファイルシステム）が調停に使えないか考える。
6. harness は資産であり負債でもある
3本の原典が、harness の作り込みに対して逆向きの圧力をかけている。 これは矛盾ではなく、時間軸の違い。
| 主張 | |
|---|---|
effective-harnesses-for-long-running-agents | 4つの成果物を作り込め |
managed-agents | harness はモデルが良くなるほど陳腐化する前提が埋め込まれている |
prompting-claude-fable-5 | 旧モデル向けの skill は Fable 5 には規範的すぎて品質を落とす |
Harnesses encode assumptions that go stale as models improve. —
managed-agentsharness は、モデルの改善とともに陳腐化していく前提を焼き込んでしまう。
結論: harness は書くが、モデルリリースのたびに削る対象として見直す。
managed-agents が示す構造的な対処は、brain（Claude と harness）/ hands（サンドボックスとツール）/ session（イベントログ）を分離し、それぞれが独立に落ちたり差し替えられたりできるようにすること。
特に重要な一行:
The session is not Claude’s context window.
セッションは Claude の context window ではない。
セッションは context window の外にある記録である。だから context が溢れても、harness が落ちても、事実の記録は失われない。
陳腐化は抽象論ではない — 実際に死重になった例
harnessing-claudes-intelligence は、上の表の managed-agents 行と同じ主張を具体例で裏づけている。長時間タスク向けのエージェントで、Sonnet 4.5 は context 上限が近いと察して早々に切り上げてしまった。対処として context をリセットする仕組みを足した。
The context resets we built to compensate had become dead weight in the agent harness. —
harnessing-claudes-intelligence埋め合わせのために作った context リセットは、agent harness の中で死重になっていた。
Opus 4.5 ではその挙動自体が消えていたので、リセットは効果が無いどころか性能の足枷になる。だから harness 設計の問いは足し算ではなく引き算になる。
Over time, the structure or boundaries in our applications should be pruned based the question: what can I stop doing? —
harnessing-claudes-intelligence時間とともに、アプリケーションの構造や境界は次の問いに基づいて刈り込まれるべきである。何をやめられるか？
実務への落とし方: モデルを上げたときに、まず「このモデルの弱点に対処するために書いた部分」を探して外してみる。§4 の失敗モード対処も、§1 の「エージェントにしない」判断も、書いた時点のモデルを前提にしている。
同じ結論から出てくる「そもそも持たない」という選択肢
building-with-claude-managed-agents はまったく同じ context anxiety の逸話を、逆向きの結論に使っている。harness が腐るなら、腐るものを自分で持たなければいい。
For most organizations, maintaining a harness is overhead that doesn’t differentiate their product. —
building-with-claude-managed-agentsほとんどの組織にとって、harness の保守は製品を差別化しないオーバーヘッドである。
差別化すべき場所として名指しされるのは context 管理とドメインの専門性の2つで、これは §6 冒頭の表が「作り込め」と言っている effective-harnesses-for-long-running-agents の4つの成果物とも整合する。作り込む価値があるのは context 側で、ループ側ではない。
同じ原典が挙げる構造的な理由も、harness の話に留まらない。harness と実行サンドボックスが同じコンテナに同居していることが、認証情報の危険・起動遅延・実行の消失という3つの問題の共通の根だとしている。分離すると3つ同時に効く（ツールを使わないセッションはコンテナを飛ばすので TTFT が p50 で約60%削減）。
検証役を製品にすると何が変わるか
§4 の「作る者と判定する者を分ける」に対応する製品側の答えが new-in-claude-managed-agents の outcomes。
A separate grader evaluates the output against your criteria in its own context window, so it isn’t influenced by the agent’s reasoning. —
new-in-claude-managed-agents別個の採点役が、自分自身の context window の中であなたの基準に照らして出力を評価するので、エージェントの推論に影響されない。
内部ベンチで標準の prompting ループに対し最大10ポイント、docx +8.4% / pptx +10.1%。注目すべきは最大の利得が最も難しい問題で出ること。building-multi-agent-systems の「早すぎる勝利」問題（検証役が1〜2個テストして合格を宣言する）への対処が、rubric を先に書かせることだと分かる。
7. 実践者が実際にやっていること
how-anthropic-teams-use-claude-code の10チームから、設計に関わる共通項。
技術者チーム: checkpoint を刻んで試し、ダメなら捨てる
Starting over often has a higher success rate than trying to fix Claude’s mistakes.
やり直すほうが、Claude の間違いを直そうとするより成功率が高いことが多い。
「スロットマシンのように扱う」— 状態をコミットし、30分走らせ、受け入れるか最初からやり直すか。
RL Engineering チームの数字が現実的: 一発で通るのは約3分の1。だから「まず one-shot を試し、通らなければ協調モードに切り替える」。
自己検証のループを作る
Set up Claude to verify its own work by running builds, tests, and lints automatically. This allows Claude to work longer autonomously and catch its own mistakes, especially effective when you ask Claude to generate tests before writing code.
ビルド・テスト・lint を自動で走らせ、Claude が自分の仕事を検証できるようにする。これにより Claude はより長く自律的に働き、自分の誤りを自分で捕まえられる。コードを書く前にテストを生成させると特に効果的。
タスクの分類の直感を養う
非同期で回せるタスク（周辺機能、プロトタイピング）と、同期監督が要るタスク（コアのビジネスロジック、重要な修正）を見分ける。
測ることが、そのまま取り組めることになる
claude.ai を2週間で約3倍速くした事例（how-we-made-claude-ai-faster）。Claude は超える数字を手にした瞬間に最適化を始めるので、最も効くのは測るものを増やすことで、勝ちは下がる一方の CI のラチェットで守った。ベンチマークは体感の遅延と相関することを先に証明させ、ぶれるもの・相関しないものは捨てた（間違った丘を登らせない）。
The loop was productive, but it wasn’t autonomous. Keeping it fast, safe, and on track was our job, and it had three parts.
ループは生産的だったが、自律ではなかった。速く、安全に、軌道に乗せておくのは私たちの仕事で、それには3つの部分があった。 — how-we-made-claude-ai-faster
野心（既定の Claude は範囲に慎重で見積もりを水増しするので、ガードレールに自信があるなら大胆さを促す）、好み（見える変更は前後の録画で人が判断）、方向（スレッドを1つのベンチマークか操作に狭く保つ）。すべての PR に自動レビューと人の承認、最適化の前に単体テスト、目に見えるものはフラグの裏に。
組織の側の準備
大規模なコード移行では、エージェントが変更を速く書くほど、ボトルネックは組織を動かす側に移る（preparing-for-code-modernization）。実行の前に、目標（uplift / transform / reimagine のどれか）、人を介さずに確かめられる条件で書いた証明書、変更ごとの人のレビューの深さを段階で決めた昇格の方針、前提（最小権限、変更を transcript と証拠に結びつける）を決め、小さな区画で端から端まで通してから広げる。同じ種類の指摘が繰り返されたら、1件ずつレビューせずにワークフローか証明書の原因を直す。
エージェントをチームに置くときは、役割を先に書き、実効の権限を起動した人の権限で縛り、使う人と鍛える人を分ける（恒久の memory に書けるのは管理者と編集者だけ。その標準を持つチームがエージェントを持つ）。作業は誰からも見える所に置く（asana-human-agent-teams）。
8. 手順にまとめる
- エージェントにしない選択肢を先に潰す
- 単発呼び出し → retrieval → workflow → agent の順に検討
- コストの倍率を見積もる
- エージェント 4× / multi-agent 15× / evaluator 付き 20×
- 価値がこれを正当化するか
- 委譲先を選ぶ
- 結果だけ要る → subagent
- 互いに反論させたい → agent team
- 同じ手順を多数に適用 → workflow
- 長時間走らせるなら構造で失敗モードを潰す
- laziness → 完了条件と検証ループ
- self-preferential bias → 別 context の verifier
- goal drift → 目的をファイルに
- セッションを跨ぐなら4つの成果物を用意する
- feature list / git / progress /
init.sh - 規律は「1回に1機能」
- feature list / git / progress /
- 統率機構を作り込む前に、git やファイルシステムで代用できないか見る
- harness と skill を、モデルリリースのたびに削る対象として棚卸しする
9. 効くと言われて実は限定的なもの
claude-think-tool は自分自身を非推奨にした（原典が その後の更新で「extended thinking を使え」と明記）。
ただし記録として残る知見が1つある。ツールを与えるだけでは効かず、プロンプトとセットで初めて効いた。
| 条件 | τ-Bench（airline）pass¹ |
|---|---|
| ベースライン | 0.370 |
| think ツールのみ | 0.404（わずか） |
| think ツール + 最適化プロンプト | 0.570 |
これは think ツールに限った話ではない。 機構を足しただけでは効かず、それをいつどう使うかをモデルに伝えて初めて効くという一般則として読める。同じ構造が agent-teams（spawn プロンプトに文脈を書く）、sub-agents（description が委譲判断を決める）、skills（description が発火を決める）にも現れる。