コーディングエージェントが途中で止まるとき、原因を「モデルが弱い」だけに帰結させるのは早計です。要件整理、設計、実装、レビュー、完了判断までを1つの会話コンテキストに積み上げると、割り込みのたびに論点がこぼれ、検収待ちや「あとで確認」が蒸発しやすくなります。
📑目次
Claude Code の Agent Teams は、独立コンテキストの teammate と peer 通信、共有 task list でこの過負荷を分散する実験的機能です。一方で multi-agent はトークンと調整コストを増やします。
Anthropic の multi-agent research では、次の点が示されています。
- lead + parallel subagents が single-agent Opus 4 を内部評価で 90.2% 上回った
- 通常チャットの約15倍のトークンになり得る点に注意が必要
本記事では、次の4点を公式仕様と独立比較で判断できる形に整理します。
- チームにするか
- どの協調パターンか
- どの役割にどのモデルか
- 何を仕組みで強制するか
Zenn の実践テンプレートは発見のきっかけとして扱い、事実の裏取りは Anthropic・Claude Code docs・価格比較・設計解説に寄せます。
単一エージェントが失速する理由と責務分割の原則
賢い Lead を1体置き、Worker を増やしても、分解・割当・検収・フォロー・人間対話が Lead に集中すれば、構造はあまり変わりません。報告と依頼の割り込みが重なると、次のような失速が起きやすくなります。
- 検収待ちが放置される
- 指示のフォローが消える
- 「あとで確認」した論点が会話の外に落ちる
原則は単純です。1体に複数の責務を持たせず、責務ごとに専用コンテキストを与えることです。分割先の例は次のとおりです。
- Manager（進行・優先度・ブロッカー管理）
- Strategist / Architect（方針と境界の確定）
- Research Worker（事実調査と根拠収集）
- Lead（人間窓口の入口と受け入れ出口に限定）
- Implementer と Reviewer（書いた本人が自分の変更を甘く見る構造を切る）
実装とレビューを同一モデル・同一視点に閉じないことは、品質の主因になります。プロンプトで「厳しく見て」と書いても、同じ会話履歴と癖を共有したままでは甘さが残りやすいため、固定の Supervisor / Reviewer レーンを用意する設計が現実的です。
読者向けの最初の判断は次です。
- いま詰まっている作業は「能力不足」か「責務の同居」か
- 後者なら、モデルを上げる前に境界を切る
Agent Teams とサブエージェント、5つの協調パターンから選ぶ
結論から言うと、並列探索や peer 議論が必要なら Agent Teams、結果だけ親に返せば足りるならサブエージェントです。Claude Code 公式 docs の対比を、運用判断用に要約すると次のようになります。
| 観点 | サブエージェント | Agent Teams |
|---|---|---|
| コンテキスト | 子は独立、結果は親へ要約 | 各 teammate が完全独立 |
| 通信 | 親への報告のみ | teammate 同士の直接メッセージ可 |
| 調整 | 親が管理 | 共有 task list で自己調整 |
| 向く仕事 | 焦点タスク・結果回収 | 議論・横断レイヤ・競合仮説 |
| トークン | 相対的に低い | teammate 数に比例して高い |
出典: Claude Code Agent Teams docs（2026年7月時点）
有効ユースケースと向かない例
公式が挙げる有効ユースケースは次のとおりです。
- 研究・レビュー
- 新モジュールの分担
- 競合仮説のデバッグ
- frontend / backend / tests の横断変更
逆に、次のような作業は single session かサブエージェント向きです。
- 逐次依存が強い作業
- 同一ファイルの同時編集
- 高依存チェーン
5つの協調パターン
Anthropic の multi-agent coordination patterns は、次の5つを整理しています。
- Generator-verifier（生成と検証の分離）
- Orchestrator-subagent（親が割当・回収）
- Agent teams（peer 協調）
- Message bus
- Shared-state
推奨の進め方は次のとおりです。
- まず Orchestrator-subagent から始める
- 課題が出たら別パターンへ移る
- 流行語で Agent Teams を選ばず、衝突検知・完了検知・コストの問題適合で選ぶ
日本語の早見としては、次の資料が「処理分散」と「認知協調」の差を短く示しています。
MindStudio は shared board 上で claim / in-progress / self-expand する peer 協調として Agent Teams を説明しています。親がすべて強制割当する階層とは違う制御面が必要だと分かります。
有効化とレビュー分離の選択肢
有効化は実験フラグです。settings.json または環境変数で CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 を設定します。既定オフで、既知の制限がある前提で試すのが安全です。
実装とレビューを別系統にしたい場合は、OpenAI Codex plugin for Claude Code のようなクロスツール連携も選択肢になります。Teams を増やす前に、レビューゲートだけを別エージェントへ渡す方が安いことも多いです。
役割別に Fable と GPT-5.6 を割り当てる判断基準
最上位モデルを全役割に当てないことが、コストと速度を守る要点です。窓口・難所・レビュー・量産で梯子を分けます。
Simon Willison が整理した価格の梯子（1M tokens in/out、2026-07-09 時点の投稿）は次のとおりです。
| モデル帯 | おおよその価格（in/out per 1M） | 役割配分の読み方 |
|---|---|---|
| GPT-5.6 Luna | $1 / $6 | 量産 Worker 候補。安さと速度を優先 |
| GPT-5.6 Terra | $2.50 / $15 | 中間帯。定型実装の厚み用 |
| GPT-5.6 Sol | $5 / $30 | 難所・レビュー一段上 |
| Claude Fable 5 | $10 / $50 | 人間窓口・計画・最終受け入れ |
出典: Simon Willison — GPT-5.6、MindStudio — Fable 5 orchestrator + GPT-5.6 worker（2026年7月時点）
価格比較とベンチの注意点
注意点は次の2つです。
- reasoning token 量の差が大きいため、単純なトークン単価比較は誤誘導になり得る
- ベンチは主張が割れる
ベンチの読み方は次のとおりです。
- OpenAI 側の Agents’ Last Exam では Sol が Fable adaptive を上回ると主張する
- SWE-Bench Pro では Fable 5 80% 対 Sol 64.6% という自己報告差もある
- 単一ベンチで全役割を決められない
- Simon 自身の early access 感でも、Sol は有能だが複雑な coding で Fable を明確に超えた印象ではない、と留保されている
役割タイプごとの配分例
役割タイプごとの配分例は次です。
| 役割タイプ | 求める性質 | 配分の考え方 | 例 |
|---|---|---|---|
| Lead / 人間窓口 | 曖昧さの翻訳・受け入れ | 高精度・低頻度 | Fable 5 |
| Worker（量産） | 安さ・速度 | 低単価 + 必須レビュー | GPT-5.6 Luna |
| Reviewer | 別視点・一段上 | 実装と別系統 | GPT-5.6 Sol（low effort） |
| 難所 / 中枢 | 深い推論 | 高 effort を限定投入 | GPT-5.6 Sol（xhigh） |
| Orchestrator 全般 | 計画と分解 | frontier を常時回さない | Fable で計画 / GPT で実行 |
判断基準と設計原則
判断基準はチェック形式にすると運用に落ちます。
- 失敗コストが高い席（人間窓口・最終受け入れ）→ 高精度・低頻度
- 回数が多い席（実装・調査）→ 安価高速 + 上位レビュー必須
- レビューは実装と別モデル系統を優先（同じ癖の共有を避ける）
- 長文リポジトリ追跡が弱い小型モデルは、Hard Task レーンへ最初から逃がす
MindStudio の独立論も同じ方向です。要点は次のとおりです。
- Fable を orchestrator（計画・分解・レビュー）に置く
- GPT-5.6 Sol を worker（高頻度実装）に分離する
- 全ステップを frontier に通すより推論コストを抑えられる、という主張
数値の「何倍」は環境差が大きいので再現保証にはせず、設計原則として使います。
設定を1ファイルで差し替え可能にしておくと、モデル陳腐化への耐性が上がります。Fable 5 の利用可能期間や SOP 整備の実務手順は、Claude Fable 5 で Agent SOP を構築するガイド も併読すると、役割定義の書き方を具体化しやすいです。
分担を仕組みで守る完了ゲートと導入手順
プロンプトの「役割を守れ」だけでは、忙しさのピークで境界が崩れます。連絡入口・必須添付・検証コマンドで境界を強制します。
仕組みの例は次です。
- 検証付きメッセージ入口（形式・必須項目を満たさない依頼は受け付けない）
- Supervisor を飛ばせない実装相談レーン
- 完了報告時に統合 HEAD で検証コマンドを自動実行し、失敗なら送信失敗にする
- 成果物と判断履歴をファイル / git に残し、会話ログだけに依存しない
- express レーンは、本質が1変更で完結する小依頼のみ Lead 直通。迷ったら通常レーン（Supervisor 付き）
テンプレ起動と dogfooding の示唆
実践テンプレート側では、次の起動型が見られます。
make bootstrapで Lead を起動して要件対話するmake bootstrap-teamで残りを立ち上げる
必要ツールの前提（git, make, bash, tmux, direnv, 各 CLI）は環境差があるため、自リポジトリでは最小セットから始めてください。GitHub 上の公開テンプレートは customizable-agent-teams です。
dogfooding の示唆として有効なのは、次の進め方です。
- 実装前の調査・設計・人間への質問に時間を使う
- 仕様穴を実装前に上げる
機能追加1本が数十 mid で終わった、といった一次実測は「再現保証」ではなく、責務分割が効いたときの wall-clock 感の参考に留めます。
無人実行や権限境界を同時に扱うなら、Claude Code と Codex のサンドボックス選び方 も合わせて読むと、Agent Teams の外側（OS 境界・承認疲れ）を整理しやすいです。
読者向け導入チェックリスト
- 問題は並列独立か、逐次依存か（後者なら Teams を無理に使わない）
- Agent Teams を試すなら実験フラグと既知制限を確認した
- Lead に残す責務を「人間対話と受け入れ」に限定できている
- Worker と Reviewer を別モデル / 別視点にした
- done の自己申告を信じず、検証コマンドゲートがある
- コスト上限（定額 usage / API 予算）に対し frontier 常駐を避けている
- モデル配分を1設定ファイルで差し替え可能にした
今日やるなら、チェックリストの先頭3項目だけで十分です。リポジトリを1つ選び、並列独立タスクかどうかを判定し、必要なら実験フラグを立て、Lead の責務を入口/出口に切り詰めてください。その次に検証ゲートを1本入れます。
よくある質問（FAQ）
Q1. Agent Teams は今すぐ本番で使うべきですか？
A. 公式に実験的で既定オフです。研究・レビュー・分割可能な大規模作業向きです。逐次依存や同一ファイル編集が中心なら、サブエージェントか単一セッションを優先してください。
Q2. 全部 Fable 5（または全部 Sol）にすればよくないですか？
A. 窓口や難所は高精度が効きますが、量産席まで frontier にするとコスト・速度・usage limit で破綻しやすいです。本題はレビュー分離と梯子配分です。
Q3. サブエージェントと Agent Teams の最短の選び方は？
A. 子同士の議論と共有 task list が必要なら Teams。親が結果だけ回収すれば足りるならサブエージェントです。
Q4. トークンコストはどれくらい増えますか？
A. Teams はインスタンス数に比例して増えます。Anthropic の research 記事は multi-agent が通常チャットの約15倍になり得ると注意しています。価値は wall-clock 短縮と品質構造で回収する前提で設計してください。
Q5. 自前テンプレなしで始められますか？
A. まず公式 Agent Teams で少人数 peer を試し、不足（役割固定・モデル梯子・完了ゲート）が見えたら Orchestrator-subagent や自前テンプレへ拡張するのが安全です。
関連記事:
- CodexプラグインでClaude Codeからレビュー委譲
- Claude Fable 5を活用したAgent SOP構築のタイミングと手順【Fable 5限定ガイド】
- Claudeエージェントの敵対的検証入門｜レビューとの違いとチェックリスト
まとめ
- 単一コンテキスト過負荷が失速の主因になりやすく、責務分割と専用コンテキストが先です。
- パターン選択は流行語ではなく問題適合です。公式5パターンと Teams vs サブエージェント表で決めます。
- モデルは役割の失敗コストと頻度で梯子配分し、価格・ベンチは独立ソースで補正して読みます。
- 次のアクションは、導入チェックリストの先頭3項目を今日のリポジトリで試し、検証ゲートを1つ入れることです。
関連する新しい記事:
- グラフとループの使い分け｜導入判断チェックリスト【2026】 – This published update adds current operational context for Agent Teamsの役割設計｜FableとGPT-5.6の使い分け【2026】.
- Claude CoworkのRecord a skillとは｜画面録画からスキル化する手順と注意点 – This published update adds current operational context for Agent Teamsの役割設計｜FableとGPT-5.6の使い分け【2026】.
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す