マルチエージェント編成パターン
いつ分割すべきか、4 つの協調トポロジー、そして多くのタスクは分割不要である理由。
まず単一エージェント、やむを得ず分割
マルチエージェントは魅力的ですが、往々にして早計です。分割のたびに次が増えます：シリアライズ費用、協調プロトコル、継ぎ目の故障モード、そしてデバッグの難しさ。
次に当てはまるときだけ分割します：
- コンテキストが本当に溢れる。 数千行を探索する必要があるが、要るのは結論だけ。
- 並列化に実益がある。 独立したサブタスクで実時間が問題になる。
- 専門化が必須。 道具・権限・システムプロンプトが 1 スレッドで衝突する。
- 検証が独立していなければならない。 実行者の推論を見られない検査役が必要。
どれも当てはまらなければ単一のまま。「なんとなく整理されて見える」は理由になりません。
4 つのトポロジーと取舍
| パターン | 形 | 向く場面 | 主なリスク |
|---|---|---|---|
| 監督者 | ハブが委譲し集約 | 分解しやすいタスク | ハブがボトルネック＆文脈の詰まりに |
| パイプライン | 順次ステージで変換 | 抽出 → 変換 → レビュー | 誤りが下流で増幅 |
| 討論 | 2 者が議論し第三者が判定 | 影響の大きい意思決定 | コスト 3 倍。自信満々な誤答に収束しうる |
| スウォーム | 対等ノードが相互に委譲 | 探索的タスク | デバッグ難、停止困難 |
既定は監督者型 です。推論しやすく、計測も入れやすい。
ハブは記録ではなく結論を渡す
最も多い編成のバグは、監督者が全ワーカーの履歴を連結することです。コンテキストが膨張し、注意が無関係な詳細に分散します。
ワーカーごとに 返却契約 を定めます：
returns: { task_id, status, findings[], artifacts[], unresolved[] }
ハブが見るのは結論とポインタだけ。詳細が必要なら後で取りに行けばよく、常に全部を持ち歩くより安上がりです。
全エージェントに停止条件を
エージェントはループします。起動前に定義します：
- エージェントごとの最大イテレーション／ツール呼び出し回数
- 何をもって完了か（「なんとなく終わった」ではない）
- どの場合は再試行ではなく人に委ねるか
境界のない実行者は、上限のない請求書です。
継ぎ目の故障処理
分散システムには単一エージェントにない失敗があります。部分結果、途中タイムアウト、兄弟ノードの矛盾出力。
- タイムアウト：途中経過＋明示的な不完全マークを返す。タスクを黙って捨てない
- 矛盾：判定者または人に委ねる。ハブが適当に選ばない
- 反復失敗：4 回目の再試行ではなく、はっきり失敗させる
分散推論のデバッグ
マルチエージェントは静かに高く失敗します。最低限の計測：
- 全ワーカーとツール呼び出しに伝播する trace id
- エージェントごとに入出力を分離して記録
- エージェント単位のトークン原価
早いうちにリプレイ機能を用意しましょう。同一入力で特定ワーカーだけを再実行できれば、犯人探しが診断に変わります。
コストについて
並列エージェントは費用を急速に増幅します。横に広げる前に、「単一エージェント＋優れたコンテキスト管理」で何分の一かの費用で 9 割の効果が出ないか確認してください。たいてい出ます。