エージェント設計と委譲 — 結局どうすればいいか
12本の原典を統合する。中心にあるのは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 が自分で手順とツール使用を決める | 低い |
判断の順序:
1. 単発の LLM 呼び出しで足りるか
→ 足りるなら、それ以上やらない
2. retrieval と in-context example で足りるか
→ 足りるなら workflow にもしない
3. 手順が事前に決まっているか
→ 決まっているなら workflow（予測可能で安い）
4. 手順が実行時にしか決まらないか
→ 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 が互いを上書きする
- 依存関係が多い作業
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 | 開発サーバの起動。毎セッションのトークンを節約する |
毎セッションの立ち上がり手順:
1. pwd で作業ディレクトリを確認
2. git ログと progress ファイルを読む
3. 未完了で最優先の機能を1つ選ぶ
4. init.sh で開発サーバを起動
5. 新しい作業の前に 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 が落ちても、事実の記録は失われない。
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 はより長く自律的に働き、自分の誤りを自分で捕まえられる。コードを書く前にテストを生成させると特に効果的。
タスクの分類の直感を養う
非同期で回せるタスク（周辺機能、プロトタイピング）と、同期監督が要るタスク（コアのビジネスロジック、重要な修正）を見分ける。
8. 手順にまとめる
1. エージェントにしない選択肢を先に潰す
単発呼び出し → retrieval → workflow → agent の順に検討
2. コストの倍率を見積もる
エージェント 4× / multi-agent 15× / evaluator 付き 20×
価値がこれを正当化するか
3. 委譲先を選ぶ
結果だけ要る → subagent
互いに反論させたい → agent team
同じ手順を多数に適用 → workflow
4. 長時間走らせるなら構造で失敗モードを潰す
laziness → 完了条件と検証ループ
self-preferential bias → 別 context の verifier
goal drift → 目的をファイルに
5. セッションを跨ぐなら4つの成果物を用意する
feature list / git / progress / init.sh
規律は「1回に1機能」
6. 統率機構を作り込む前に、git やファイルシステムで代用できないか見る
7. harness と skill を、モデルリリースのたびに削る対象として棚卸しする9. 効くと言われて実は限定的なもの
claude-think-tool は自分自身を非推奨にした（原典が 2025-12-15 に「extended thinking を使え」と明記）。
ただし記録として残る知見が1つある。ツールを与えるだけでは効かず、プロンプトとセットで初めて効いた。
| 条件 | τ-Bench（airline）pass¹ |
|---|---|
| ベースライン | 0.370 |
| think ツールのみ | 0.404（わずか） |
| think ツール + 最適化プロンプト | 0.570 |
これは think ツールに限った話ではない。 機構を足しただけでは効かず、それをいつどう使うかをモデルに伝えて初めて効くという一般則として読める。同じ構造が agent-teams（spawn プロンプトに文脈を書く）、sub-agents（description が委譲判断を決める）、skills（description が発火を決める）にも現れる。