実際にmulti-agentシステムを数か月運用した経験から整理しています。各patternは「ないと壊れた」から追加されました。
AI Agentが1つあると便利です。そこで2つ目、3つ目を足すと、状況が崩れ始めます。
- Agent AとAgent Bが同じファイルを同時に編集する
- APIが1つ落ち、3つのAgentが同時に激しくretryし、請求が跳ねる
- Sub-agentが作業を終えて静かに消え、成功したのか失敗したのか誰も分からない
問題の中心はたいてい連携層にあり、AIそのものではありません。
以下の5つのpatternは、本番に近い環境で何度も検証したものです。AIチームを本当に一緒に働かせるための土台になります。
先に全体像：Multi-Agentシステムはどんな形か
典型的なmulti-agentシステムはこうなります。
🎯 指揮役 Orchestrator
│
┌───────┼───────┬─────────┐
▼ ▼ ▼ ▼
🔧 実行役 A 🔧 実行役 B 🔍 レビュアー 📁 共有ファイルシステム
│ │ │
└───────┴───────────┴──→ 📁 共有ファイルシステム重要なアーキテクチャ特性：
| 特性 | 説明 |
|---|---|
| 階層型管理 | 1つの指揮役が全体を統括する |
| statelessな実行役 | taskを受け取り、実行し、報告し、終了する |
| ファイルが通信 | すべての状態をファイルに置く |
| 横方向の会話禁止 | 実行役同士は直接連絡しない |
なぜこの形なのか。現在、多くのAIツールが提供するsub-agentはstatelessです。持続的な記憶も、他のagentと会話する能力もありません。ファイルシステムが唯一信頼できる連携機構です。
Pattern 1：ファイルBlackboard（File Blackboard）
すべてのAgentはメッセージではなくファイルで連絡する。ファイルシステムがmessage busになる。
問題
3つのAgentが連携する必要があります。しかし、それらは：
- 記憶がない：呼び出されるたびに新規状態
- 互いに隔離されている：内蔵の通信経路がない
- いつでも消え得る：sessionは突然切れる
解法：ファイルシステムをBlackboardとして使う
workspace/
status.md ← プロジェクト状態（指揮役だけが変更可能）
tasks/
task-001.md ← task封筒（実行役への指示）
task-002.md
artifacts/
task-001-out.md ← 実行役の成果物
task-002-out.md
checkpoints/
checkpoint.json ← クラッシュ復旧用アクセスルール
中心ルールは1つです。グローバル状態を書けるのは指揮役だけ。 実行役は自分に指定された出力場所にだけ書きます。
なぜファイルなのか
| 代替案 | 問題 |
|---|---|
| メモリ共有 | Agentが落ちると全部消える |
| メッセージキュー | 単一マシン環境では大げさ |
| データベース | 多くのAIツールはテキストファイルのほうが扱いやすい |
| Agent-to-Agent API | 現状ほぼ対応プラットフォームがない |
ファイルの利点は、確認できる（直接開ける）、耐久性がある（sessionが切れても残る）、バージョン管理できる（gitに入れれば履歴が残る）ことです。
Pattern 2：Task Envelope
Sub-agentに「Xをして」とだけ言わない。構造化されたtaskパッケージを渡す。
問題
Sub-agentをspawnして「このデータを分析して」と言うと、次のようなことが起きます。
- 間違った列を分析する
- 本当は5回で済むtool callを50回走らせる
- 終わった後に「分析完了」とだけ返し、要求した形式がない
解法：各taskを封筒に包む
## task：analyze-q1-data
- **目標**：Q1売上トレンドを要約する
- **受け入れ条件**：出力にトレンド方向、上位3つの要因、信頼度を含める
- **入力**：data/q1-revenue.csv（製品ライン別の四半期売上）
- **出力場所**：artifacts/analyze-q1-data.md
- **予算**：最大5回のtool call
- **停止条件**：データファイルが存在しない、または形式が不正な場合は停止して報告する封筒に入れるもの
| 欄位 | ないとどうなるか |
|---|---|
| 目標 | Agentが欲しいものを勝手に推測する |
| 受け入れ条件 | 出力品質を制御できない |
| 入力 | Agentが間違ったファイルを読む、またはディレクトリ全体を読む |
| 出力場所 | 結果がどこへ行ったか分からない |
| 予算 | Agentが無限に探索し、請求が膨らむ |
| 停止条件 | 問題に当たって止まり、報告もしない |
軽量版 vs 完全版
すべてのtaskに完全な封筒は不要です。単純なルール：
- 3ステップ以内で終わる → 口頭指示でよい
- 外部APIまたは複数ファイルがある → 軽量封筒（目標 + 入力 + 出力）
- 高リスクまたは高コスト → 完全封筒（予算と停止条件を含む）
Pattern 3：Circuit Breaker
APIごとの連続失敗回数を追跡する。3回で遮断し、待ってから1回だけprobeする。
問題
AgentがAPIを叩いて429（rate limit）に当たります。retryします。さらにretryします。同時に2つ目のAgentもretryし、2つとも同じAPIを叩き続け、rate limitをさらに悪化させます。3つ目のAgentがbackup providerへ切り替え、そちらも落ちます。
これがRetry Stormです。Multi-agentシステムで最速で予算を燃やす故障モードです。
解法：3状態のCircuit Breaker
| 状態 | 動作 | 遷移条件 |
|---|---|---|
| CLOSED（正常） | すべての呼び出しを通常実行 | 60秒内に3回連続失敗 → OPEN |
| OPEN（遮断） | 呼び出しは実行せず即失敗 | 5分待機 → HALF-OPEN |
| HALF-OPEN（試験） | 1回だけ通す | 成功 → CLOSED；失敗 → OPEN（cooldown倍増） |
どのエラーで遮断すべきか
エラーは同じではありません。
| エラー種別 | 遮断する？ | 理由 |
|---|---|---|
| 429（rate limit） | ✅ | 続けるほど悪化する |
| 503（service unavailable） | ✅ | 相手側が落ちている |
| network timeout | ✅ | 接続問題は次の1秒で直るとは限らない |
| 401（auth failure） | ❌ | 設定問題。待つのではなくtokenを直す |
| 400（bad request） | ❌ | bug。retryしても無駄 |
実際に踏んだ落とし穴
沈黙したProxy障害： API proxyが落ち、すべてのrequestが同じgeneric errorを返しました。エラーが一時的に見えたため、Agentはretryを続けました。
教訓： 同じエラーが連続して何度も出たら、status codeに関係なく遮断します。同一エラーの連続は、systemic failureです。
Pattern 4：人間へのEscalation（HITL Escalation）
いつ人に聞くべきかを知ることは、AIシステムで最重要能力の1つです。
3層Escalation制度
| 層 | リスク | Agentの行動 | 例 |
|---|---|---|---|
| 🟢 自主 | 低い、戻せる | 直接実行 | ファイルを読む、draftを書く、テストを走らせる |
| 🟡 通知 | 中程度、重要な節目 | 実行後に人へ通知 | codeをcommit、状態を更新 |
| 🔴 Gate | 高い、不可逆 | 止まって人の承認を待つ | productionへpush、message送信、データ削除 |
重要指標：Escalation率
理想的なEscalation率は 10-15% です。
- 低すぎる（< 5%）→ AIが高リスク作業を通知なしで実行している。危険。
- 高すぎる（> 30%）→ 人間がボトルネックになり、自動化の意味が薄れる。
- 10-15% → 大半は自動化し、重要なものだけ人が見る。
Escalation時の情報形式
Agentが人間へEscalationするとき、「不確かです」だけでは足りません。判断に必要な情報を揃えます。
## 判断が必要
**状況**：新バージョンをproduction環境へdeployしている
**問題**：テストはすべて通過したが、メモリ使用量に関するwarningが1つある
**選択肢**：
A. 通常どおりdeployする（このwarningは過去に問題を起こしていない）
B. warningを先に修正してからdeployする（推定遅延：2時間）
C. 先にstagingへdeployし、1日観察する
**推奨**：Aを選ぶ。理由は[理由]
**返信待ち……**Pattern 5：Model Selection
高いモデルは思考に、安いモデルは実行に使う。逆にするとお金を無駄にする。
二分ルール
Multi-agentのコスト管理で一番重要なルール：
- 判断力が必要（戦略 / 分析 / review）→ 高いモデル
- 判断力が不要（コードを書く / formatting / データ収集）→ 安いモデル
よくある構成
| 役割 | モデル階層 | 理由 |
|---|---|---|
| 指揮役 | 高い | 重要判断をすべて担当する。ここを節約すると全体で損をする |
| コードを書く | 安い | 出力はテストで検証できる |
| コードreview | 高い | 他者が漏らした問題を捕まえる必要がある |
| データ収集 | 安い | 機械的な収集 + formatting |
| データ分析 | 高い | 解釈、pattern発見、判断が必要 |
| テスト実行 | 安い | 結果はpass/fail。創造性は不要 |
| 形式変換 | 最安 | 純粋なデータ変換 |
節約の80/20ルール
4つの変更でmulti-agentコストの大部分を減らせます。
- モデル階層化（高いモデルが考え、安いモデルが実行）→ 最大効果
- 内容ではなくpathを渡す（agentに自分で読ませる）→ token節約
- 完了済みphaseを圧縮（1文要約だけ残す）→ token節約
- Task Envelopeに予算上限を入れる → 外れ値を防ぐ
まとめ：5つのPatternの関係
これらのpatternは独立ではありません。1つの運用体系を作ります。
| Pattern | 解く問題 | ないとどうなるか |
|---|---|---|
| File Blackboard | Agent間の連絡方法 | 状態衝突、データ喪失 |
| Task Envelope | taskを明確に渡す方法 | 出力品質が制御できず、予算が膨らむ |
| Circuit Breaker | API障害への対応 | Retry Storm、請求爆発 |
| HITL Escalation | いつ人に聞くか | 高リスク操作に人の監督がない |
| Model Selection | どのモデルを使うか | 全部高いと無駄、全部安いと品質が崩れる |
始め方
最小構成の順番：
- 共有ディレクトリを作る（
workspace/status.md+tasks/+artifacts/） - 最初のtaskを封筒に包む（完全版は不要。目標 + 入力 + 出力で十分）
- Circuit Breakerを追加する（JSONファイルでAPI失敗回数を追跡）
- どの操作に人間の承認が必要か決める（まずは「外部システムに影響するもの」から）
この4つができると、動くmulti-agent連携システムになります。
完全なpattern文書、コードテンプレート、さらに多くの実戦例はopen-source repoにまとめました。
👉 Orchestration Playbook on GitHub
MITライセンスです。自由に使えます。
関連記事
- Multi-Agent開発フロー
- AIチームでアルゴリズムを開発する
- Claude Code + Codex連携playbook
- OpenClaw Multi-Agentアーキテクチャ
- AI Agent自己修復
こぺんぎんの体験談
OpenClawで動くOpus / Sonnet / ChatGPTの3 agentシステムでは、この5つのpatternが失敗を踏んだ後に1つずつ育ちました。初期版では2つのagentが同じファイルを同時に編集し、状態が乱れました。API失敗時には3つのagentが一緒にretryし、請求がすぐ跳ねました。その後、共有状態をファイルシステムに寄せ、taskを封筒に包み、APIにCircuit Breakerを入れ、重要操作をhuman gateへ通すようにして、やっと全体が安定しました。モデル階層化（指揮は高いモデル、実行は安いモデル）は後半で入れたものですが、節約できたtokenは想像以上でした。
よくある質問
Q: AI AgentのOrchestrationとは何ですか？
Orchestrationとは、主Agent（指揮役）がtaskの割り当て、結果の回収、失敗処理を担当し、他のAgentは割り当てられた作業に集中する構成です。オーケストラの指揮者のように、それぞれが適切なタイミングで適切な役割を果たすようにします。
Q: なぜAI Agent同士が直接会話できないのですか？
現在の多くのAIツール（Claude Code、Codexなど）のsub-agentはstatelessです。生成され、taskを実行し、結果を返すと消えます。持続的な記憶も内蔵の通信機構もありません。そのため、ファイルシステムを使った間接的な連絡が必要です。
Q: Circuit BreakerはAIシステムで何をしますか？
Circuit BreakerはAPI呼び出しの連続失敗回数を追跡します。連続失敗が閾値に達したら一定時間呼び出しを止め、全Agentが同時にretryして起こすRetry Stormを防ぎます。これはmulti-agentシステムで最も予算を燃やしやすい故障モードです。
— Penchan