Anthropic の 5 パターンで Claude Code エージェント設計を分類する
はじめに
マルチエージェント設計の議論で「これは Orchestrator パターン？ それとも Agent Teams？」と意見が割れた経験はありませんか。Anthropic 公式の 5 つの協調パターン（Generator-Verifier / Orchestrator-Subagent / Agent Teams / Message Bus / Shared State）を Claude Code 視点で解説し、サブエージェント設計やエージェントオーケストレーションの共通語彙として使えるかたちに整理します。協調パターンを指す共通の語彙がないと、設計レビューはすぐに各人の経験談の応酬になります。
2026 年 4 月、Anthropic が公式ブログ「Multi-agent coordination patterns」で 5 つの協調パターンを公開しました。この記事では Anthropic の 5 パターンを公式定義に忠実に解説し、本ブログの既存マルチエージェント実装 23 本から抽出した中核 7 記事を 5 パターンにマッピングします。さらに 4 軸（タスク構造・レイテンシ・スケール・観測性）の決定木、ハイブリッド設計の実例、アンチパターンと推奨ガードまでを一気通貫で扱います。
対象読者は、Claude Code でマルチエージェント構成（サブエージェントまたは Agent Teams）を 1 つ以上組んだことがある中〜上級エンジニアです。
なぜ Anthropic の「5 パターン」を学ぶ必要があるのか？
マルチエージェントのトークン消費の現実
Anthropic 公式の数値は比較対象が異なる 2 系統です。
- vs シングルエージェント:「Multi-agent implementations typically use 3-10x more tokens than single-agent approaches」（出典: Building multi-agent systems: When and how to use them）
- vs チャット対話:「multi-agent systems use about 15× more tokens than chats」（出典: How we built our multi-agent research system）
トークン消費は「コンテキスト重複・協調メッセージ・ハンドオフ要約（子から親への結果引き渡し時の要約）」の 3 要因から積み上がります。Anthropic 自身が「適切なツールを持つシングルエージェントは多くの開発者が想像する以上のことを成し遂げられる」と釘を刺しており、雰囲気での多エージェント化は明確に否定されています。
パターン語彙が「設計議論の共通言語」になる
Anthropic はシンプルさの原則を強調し、5 パターンの中では Orchestrator-Subagent を最初の選択肢として推奨しています（「we recommend starting with orchestrator-subagent. It handles the widest range of problems with the least coordination overhead」）。
5 パターンは「設計のメニュー」であると同時に「議論の共通語彙」として機能します。本記事は (1) 既存マルチエージェント記事 23 本から抽出した中核 7 記事の 5 パターンマッピング、(2) 4 軸決定木、(3) Orchestrator + Shared State のハイブリッド設計実例、(4) アンチパターン × 推奨ガードの統合表、の 4 点を提供します。
5 つの協調パターンとは？
5 パターンの正式名称・順序・定義は公式記事「Multi-agent coordination patterns」（claude.com/blog）に基づきます。順序は原典通りに並べます。
Generator-Verifier はどんなパターンですか？
Anthropic は本パターンを「Generator が出力を生成し、Verifier が明示的な基準に照らして評価する。修正のためのフィードバックループを持つ」と整理しています（公式記事より要約: A generator produces output that a verifier evaluates against explicit criteria, with feedback loops for revision）。原典は「This is the simplest multi-agent pattern and among the most deployed.」と最もデプロイされている形だと位置づけています。
強み: 品質基準が明示できる領域での品質ゲートとして極めて有効です。同じモデルでも役割を分けるだけで自分採点より客観性が高まります。
落とし穴: 検証役の品質は評価基準の質に完全に依存するため、基準なしで「良いか見て」とだけ伝えると印鑑型レビュアー（基準なしに承認だけする無責任なレビュアー、いわゆるハンコレビュー）になります（公式原文: "The verifier is only as good as its criteria"）。適用条件は「出力品質が重要かつ評価基準を明示化できる場合」に限られ、コード生成 + テスト実行、ファクトチェック、コンプライアンス審査などが典型です。
Orchestrator-Subagent はどんなパターンですか？
Anthropic は本パターンを「リードエージェントが作業を計画し、境界が明確なタスクを専門サブエージェントに委任する」と整理しています（公式記事より要約: A lead agent plans work and delegates bounded tasks to specialized subagents）。原典は「Hierarchy defines this pattern.」と階層構造を本パターンの本質に置いています。
強み: 協調オーバヘッドが最小で最も広い問題範囲をカバーし、Orchestrator が中央集中で観測・トレースを担うためデバッグも容易です。子は独立コンテキストで並列実行され、親のコンテキストウィンドウ（一度に扱えるトークン量の上限）を浪費しません。
落とし穴: Orchestrator が情報ボトルネックとなり、明示的に並列実行されない限り逐次実行がスループットを制限します（公式原文: "Acts as information bottleneck; sequential execution limits throughput unless explicitly parallelized"）。担当範囲を明示しないと子同士で重複作業が起きる問題は、Anthropic Research システムでも観測されています。
代表的ユースケースは大規模コードベース検索・PR の自動コードレビュー・明確に分割可能なリサーチで、Anthropic は最初に試すデフォルトとして本パターンを推奨しています。
Agent Teams はどんなパターンですか？
Anthropic は本パターンを「複数の永続ワーカーエージェントが、共有キューからタスクを自律的に取得して完了する」と整理しています（公式記事より要約: Multiple persistent worker agents autonomously claim and complete tasks from a shared queue）。原典は「When work decomposes into parallel subtasks that can proceed independently for extended periods, orchestrator-subagent can become unnecessarily constraining.」と、長時間独立して並行処理できるサブタスクが多い場合の選択肢に位置づけています。
Subagent との決定的な違いは Claude Code 公式ドキュメントが明記しています。
Subagents only report results back to the main agent and never talk to each other. In agent teams, teammates share a task list, claim work, and communicate directly with each other.
強み: ワーカーが永続するためドメイン知識を蓄積でき、ピア通信で親を経由せず、多数のワーカーが真に並列稼働します。並列実行と並行処理の両面でスループットが上がります。
落とし穴: 独立した作業分割が前提となり、同時書き込みと重複作業が主な失敗モードです（公式原文: "Requires independent work partitions; concurrent writes and duplicate work are major failure modes"）。
Anthropic Engineering ブログ「Building a C compiler with a team of parallel Claudes」（Nicholas Carlini）は、Agent Teams の大規模実証として 16 エージェントが約 2,000 Claude Code セッション・約 $20,000 のコスト・100,000 行の Rust 製 C コンパイラを生成したと報告しています（Docker コンテナ + Git + lock-file で協調）。なおこれは研究プロジェクトの実証であり、プロダクション運用への一般化には個別検証が必要です。Claude Code の Agent Teams は実験的機能（CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 で有効化、v2.1.32 以上）で、TeamCreate（チーム作成 API）と SendMessage（teammate 間メッセージ API）の使い分けが運用の核です。公式は「Start with 3-5 teammates」「5-6 tasks per teammate」を推奨しています。
Message Bus はどんなパターンですか？
Anthropic は本パターンを「エージェントが中央のルーティング層を介してイベントトピック（特定種別のイベントの発行・購読の単位）を publish/subscribe（発行/購読）する」と整理しています（公式記事より要約: Agents publish and subscribe to event topics through a central routing layer）。原典は「As agent count increases and interaction patterns grow complex, direct coordination becomes difficult to manage.」と、エージェント数や相互作用が増えて直接協調が困難なケース向けに位置づけています。
強み: 発行側と購読側が互いを知らなくてよいため疎結合で、新しい購読者を追加しても既存パイプラインに影響しません。fan-out（1 イベントを複数 subscriber へ並列配送する形）で水平拡張が可能です。
落とし穴: 誤分類イベントによるサイレント障害が起きやすく、逐次オーケストレーターの判断をトレースする場合よりデバッグが困難になります（公式原文: "Silent failures (misclassified events); debugging is harder than tracing sequential orchestrator decisions"）。代表的ユースケースはセキュリティ運用での段階的アラート処理・イベント駆動 ETL・マーケットデータ処理です。
Shared State はどんなパターンですか？
Anthropic は本パターンを「エージェントが、全員が直接読み書きできる永続ストアを介して協調する」と整理しています（公式記事より要約: Agents coordinate through a persistent store all can read and write directly）。原典は「Orchestrators, team leads, and message routers in the previous patterns all centrally manage information flow.」と前パターン群の中央集中を取り払う位置づけだと述べています。
強み: 仲介者がないため単一障害点がなく、各エージェントが自分のペースで非同期協調できます。誰かの発見がほかの探索方針を即座に変える「創発的な情報統合」が起きるのが特徴です。
落とし穴: 終了条件を設けないと反応的なループや重複作業に陥ります（公式原文: "Reactive loops and duplicate work without termination conditions"）。書き込み競合対策には楽観ロック（書き込み時にバージョン番号で衝突検出）やトランザクションが必要です。代表的ユースケースは学際的リサーチ統合・長時間の累積タスク・whiteboard.md による段階的知識共有などです。
どのパターンをいつ使うべきか？
4 軸決定木でパターンを選ぶ
パターン選定の判断軸はタスク構造（独立 / 相互依存）、レイテンシ（リアルタイム / バッチ）、スケール（少数 / 多数）、観測性（必須 / 任意）の 4 軸です。決定木で組み合わせると選定が可視化されます。
ただしこの決定木は「最初に検討する候補」を示すもので、実プロダクションでは複数パターンの組み合わせ（ハイブリッド）が一般的です。次の H2 で扱います。
4 軸 × 5 パターン × 代表ユースケース
| 軸 / 代表ユースケース | Generator-Verifier | Orchestrator-Subagent | Agent Teams | Message Bus | Shared State |
|---|---|---|---|---|---|
| タスク構造 | 独立（生成 / 検証） | 独立 | 独立（同時書き込みなし前提） | 独立（イベント単位） | 相互依存 |
| レイテンシ | リアルタイム可 | リアルタイム可 | バッチ向き | バッチ向き | 任意 |
| スケール | 2 体（ペア） | 少数（3〜10） | 多数（10〜20+） | 多数 | 多数 |
| 観測性 | 高 | 高（中央集中） | 中（要設計） | 低（DLQ 必須） | 中（履歴依存） |
| 代表ユースケース | コード生成 + テスト | PR レビュー / リサーチ | 大規模リファクタ | イベント駆動 ETL | 学際的リサーチ |
既存マルチエージェント実装はどのパターンに該当するか？
23 本から中核 7 記事を抽出した基準
23 本から「主たる協調パターンが識別できる」「実装エビデンス（コード例・運用ログ・実測データ）がある」「5 パターンへの該当度が主たる（3 つ星）または副次的（2 つ星）以上」「各パターンを最低 1 記事カバー」の 4 条件で 7 本を選定しました。
23 記事の一覧（クリックで展開）
- dev-flow 系（5 本）:
claude-code-dev-flow-multi-agent-1/2/3/extra/claude-code-dev-flow-with-github-issue - editorial 系（4 本）:
claude-code-editorial-team-1week/claude-code-editorial-team-ecosystem-1/2/claude-code-editorial-ai-debate - マルチ AI 連携系（7 本）:
claude-code-gemini-cli-orchestration-guide/claude-code-grok-gemini-multi-ai-orchestration/claude-gemini-collaborative-dev/claude-gemini-interplay-insights-1/2/3/extra - ローカル AI レビュー系（3 本）:
local-ai-code-review-design/pitfalls/operations - クロスモデル / 個別ツール系（4 本）:
gemini-gal-persona-code-review/rubber-duck-copilot-cli-cross-model-review/codex-claude-code-copilot-2026/zenn-ai-pipeline-1month-retrospective
選定された 7 本を以下のヒートマップで分析します。
中核 7 記事 × 5 パターンのヒートマップ
凡例: ◎ = 主たるパターン、◯ = 副次的、△ = 部分的、空欄 = 該当なし。表の各行は以下の中核 7 記事を指します。
- Claude Code 開発フロー実践ガイド (1/3) マルチエージェント戦略編
- 1 週間で 12 人の編集チームを構築 — Claude Code エージェント奮闘記
- AI 編集チームを JIT で動かす (1/2) — トークン 70％ 削減
- Rubber Duck で学習バイアスを補完する — Copilot CLI クロスモデルレビュー
- Claude Code × Gemini 協調開発実録 (1/3) — 321 件の指摘
- Claude Code × Gemini 協調開発実録 (3/3) — シフトレフト 4 本柱
- Codex・Claude Code・Copilot を適材適所で使い分ける実践ガイド
| 記事 | Generator-Verifier | Orchestrator-Subagent | Agent Teams | Message Bus | Shared State |
|---|---|---|---|---|---|
| 1 | ◎ | ◯ | |||
| 2 | ◯ | ◎ | △ | ||
| 3 | ◎ | ◎ | |||
| 4 | ◎ | ||||
| 5 | ◎ | ||||
| 6 | ◎ | ||||
| 7 | ◯ | ◎ |
ヒートマップから読み取れる傾向は、Generator-Verifier がクロスモデルレビュー系の主力、Orchestrator-Subagent が段階的進化のスタート地点（dev-flow 系）、Agent Teams が大規模・長期タスク、Shared State が whiteboard.md 設計として確立、そして Message Bus は実装エビデンスがない「空き地」 であることです。
各記事の該当根拠
Generator-Verifier 系の 3 記事は、いずれもクロスモデル検証や Verifier 基準明示の実装エビデンスを含みます。rubber-duck-copilot-cli-cross-model-review は Claude（Opus / Sonnet / Haiku のいずれか）を Generator、GPT-5.4 を Verifier として 3 チェックポイントで自動割り込みする設計です。claude-gemini-interplay-insights-1 は Claude（Generator）と Gemini（Verifier）の協調を 70 PR・321 件の指摘で実測し、優先度分布（P0 6.2％ / P1 85.9％ / P2 7.8％）と対応カテゴリ（テスト 100％ / UI 98.6％ / 命名 95.7％）まで定量化しています。claude-gemini-interplay-insights-3 は「Verifier の基準を明示せよ」をシフトレフト 4 本柱（CLAUDE.md / SKILL.md / Sub-Agent / verify.sh）として実装しています。
Orchestrator-Subagent 系の 3 記事は、Orchestrator が dispatch して結果を統合する典型形を実装しています。claude-code-dev-flow-multi-agent-1 は 7 ステップ開発フローで 5 種のレビューエージェント（architect / qa / ui-ux / performance / security）を並列化し、「2 条件以上満たすときに Agent Team へ昇格」という判定基準も明文化しています。claude-code-editorial-team-ecosystem-1 は JIT コンテキストロード（必要なセクションを必要なときだけ読み込む方式）で token を 70％ 削減した Orchestrator-Subagent + Shared State のハイブリッド実装の代表例です。codex-claude-code-copilot-2026 は 3 ツール（Claude Code / Codex / Copilot）の adversarial-review を含む並行運用設計です。
Agent Teams 系の代表 1 記事は claude-code-editorial-team-1week で、12 人体制の編集チームを 1 週間運用した記録です。TeamCreate / SendMessage の使い分けと、サブエージェントから Agent Teams への昇格判断が実装されています。
純粋形では足りない場面とは？
Anthropic はハイブリッドを前提としている
公式記事は次のように述べます。
Production systems often combine patterns. A common hybrid uses orchestrator-subagent for the overall workflow with shared state for a collaboration-heavy subtask.
5 パターンは「どれか 1 つだけ選ぶメニュー」ではなく「組み合わせ可能な設計プリミティブ」として理解する必要があります。
「AI 編集チームを JIT で動かす (1/2) — トークン 70％ 削減」のハイブリッド構成
Anthropic が「common hybrid」として挙げる「orchestrator-subagent for the overall workflow with shared state for a collaboration-heavy subtask」に対応する実装例として、本ブログの「AI 編集チームを JIT で動かす (1/2) — トークン 70％ 削減」の設計を取り上げます。これは Orchestrator + Shared State のハイブリッドです。
ポイントは 3 点です。全体ワークフローは Orchestrator-Subagent でユーザーリクエストを Orchestrator が dispatch し、協調重視のサブタスクは Shared State で researcher / writer / reviewer が whiteboard.md を介して findings を共有、JIT コンテキストロードで各サブエージェントは必要なときだけ関連セクションを読みます。JIT コンテキストロードの本格解説は次の記事を参照してください。
純粋な Orchestrator-Subagent の伝言ゲーム問題と、純粋な Shared State の収束しないリスクを、ハイブリッドが相互補完します。子同士が直接 findings を参照でき情報ボトルネックが解消され、Orchestrator が全体進行を握ることで終了条件を強制できます。
「ただの並行作業化」失敗パターン
ハイブリッド設計でも Shared State 的な情報共有レイヤーが欠けると「役割分担はしてくれるが、各エージェントがほかの進捗を把握していないため孤立した作業になる」失敗がコミュニティでも頻繁に報告されています。ガードは共有ストアの設計（whiteboard.md / catalog.md など共通の場所）、書き込み境界の明示（セクション所有権の分割）、同期点の設計（完了前にほかのサブエージェントの進捗を確認）の 3 点です。
アンチパターンと推奨ガード
アンチパターン × 該当パターン × 推奨ガードの統合表
| アンチパターン | 該当パターン | 推奨ガード |
|---|---|---|
| Verifier の基準あいまい（rubber-stamp 化） | Generator-Verifier | 明示的 rubric の埋め込み、別モデル Verifier |
| 反復ループの収束失敗（oscillation） | Generator-Verifier | 反復回数上限 + フォールバック戦略 |
| 情報ボトルネック | Orchestrator-Subagent | 結果統合フォーマット事前定義、子の数を抑制 |
| 単一障害点 | Orchestrator-Subagent / Message Bus | Shared State へのハイブリッド化検討 |
| 担当範囲未明示の重複作業 | Orchestrator-Subagent / Agent Teams | scope を必ず明示、子の役割を fan-out（親が複数の子へ並列にタスクを散らす形）前に固定 |
| 同時書き込み競合 | Agent Teams / Shared State | 楽観ロック（書き込み時にバージョンチェックで衝突検出）、ファイル所有権の事前定義 |
| Silent failures（誤分類イベント） | Message Bus | DLQ（Dead Letter Queue: 失敗イベントの退避先）+ 分散トレーシング（複数サービスを跨いだ呼び出しの可視化）、イベントスキーマの強型定義 |
| 反応ループ無限化 | Shared State | 終了条件・収束しきい値の設定 |
Generator-Verifier の反復制限とフォールバック
Anthropic 公式は反復ループ無限化を防ぐため「A maximum iteration limit with a fallback strategy (escalate to a human, return the best attempt with caveats) prevents this from becoming an infinite loop」を推奨しています。実装上は次のように落とし込めます。
// Generator が処理する作業単位。フィードバックは反復時に追加される
interface Task {
description: string;
feedback?: string;
}
// Verifier の判定結果。不合格時は具体的なフィードバックを返す
interface VerifierResult {
accepted: boolean;
feedback?: string;
}
// 最終戻り値。収束しなかった場合は caveats（注意書き）を添える
interface FinalResult {
output: string | null;
caveats?: string;
}
async function generatorVerifierLoop(
task: Task,
maxIterations = 3, // 反復上限。これを超えたらフォールバックする
): Promise<FinalResult> {
let attempt = 0;
let output: string | null = null;
let currentTask = task;
// 反復回数の上限まで Generate → Verify → Feedback を繰り返す
while (attempt < maxIterations) {
// Generator: タスクと前回出力を受けて新しい出力を生成
output = await generator(currentTask, output);
// Verifier: 明示的な基準に照らして合否判定
const result: VerifierResult = await verifier(output);
// 合格なら即座に終了（これが正常系の終了パス）
if (result.accepted) return { output };
// 不合格ならフィードバックをタスクに付与して次の反復へ
// ※ mutate ではなくスプレッド構文で新しいオブジェクトを作る
currentTask = { ...currentTask, feedback: result.feedback };
attempt++;
}
// フォールバック: 上限に達したらベストエフォート結果を caveats つきで返す
// 実運用では人間にエスカレートする選択肢もある
return { output, caveats: 'Did not fully converge after max iterations' };
}
なお、Generator-Verifier には「生成と検証が分離可能なスキルである」という前提もあります。コード生成 + テスト実行のように検証側に「実行可能なルーブリック」を持たせられる領域では効果的ですが、純粋に主観的な評価では機能しにくい点に注意してください。
Agent Teams のタスク分解失敗とコンテキスト管理破綻
Agent Teams のコミュニティ実装でもっとも頻出する失敗は「タスク分解不備」です。Anthropic 公式も「Two teammates editing the same file leads to overwrites」と独立分割の重要性を強調しており、ファイル所有権の事前定義は必須準備工程です。
加えて、単一の CLAUDE.md のみを使うと teammate 全員が同じ内容を読み込み、役割分担の意味が希薄化します。共通コンテキスト（全員が読む CLAUDE.md）と役割別コンテキスト（teammate ごとに独立した agents/<role>.md）の 2 階層化が定石です。
アンチパターン全般や批判的観点でリスクを洗い出すフィードバックループの実例として、編集 AI ディベートの記事も参考になります。
まとめ
5 つの協調パターンを「設計語彙」として身につけると、マルチエージェント設計の議論が変わります。「これは Orchestrator？」「Agent Teams？」と意見が割れていた場面で、タスク構造・レイテンシ・スケール・観測性という具体的な判断軸で会話できるようになります。
本記事では Anthropic 公式の 5 パターンを、本ブログの既存マルチエージェント実装 23 本から抽出した中核 7 記事にマッピングしました。Generator-Verifier はクロスモデルレビュー系で主力、Orchestrator-Subagent はスタート地点、Agent Teams は大規模・長期タスク、Shared State は whiteboard.md 設計として実装済みです。
一方で Message Bus は本ブログの「空き地」 です。次の一手としては、セキュリティ運用やイベント駆動 ETL のシナリオで Message Bus PoC を組み、Anthropic 公式が言う「Silent failures」をどう可視化するか、5 パターンの最後のピースを埋める記事を構想中です。AI エージェント向け軽量 Message Bus 設計の参考実装として、コミュニティの先行例も紹介します。
冒頭で「これは Orchestrator？ それとも Agent Teams？」という議論の例え話をしました。今、あなたの手元には Anthropic 公式の 5 パターンと 4 軸決定木があります。次の設計レビューでは設計議論の前提を揃えてみてください。
最後までお読みいただきありがとうございました。本記事が、あなたのマルチエージェント設計の次の一手を選ぶ判断材料になれば幸いです。
参考リンク
Discussion