マルチエージェント設計で本当に助けになった記事

最近、チームでエージェントシステムを設計しています。単体のエージェントはある程度カンが掴めたのですが、複数を連携させようとすると、想像以上に悩みが増えました。

どんな構造でオーケストレーションする？通信は？メモリはどう管理する？

そんな中、Rohit Ghumareの記事を見つけたのですが、気になっていたことがほぼすべて整理されていたので共有します。自分の経験も交えて書きました。

なぜマルチエージェントなのか

以前の投稿でも書きましたが、マルチエージェントが常に正解とは限りません。ただ、去年一年間シングルエージェントのコンテキスト管理で失敗し続けました。

問題はシンプルです。シングルエージェントではコンテキストウィンドウがすぐに埋まり、文脈を忘れてしまう。さらに、複数ドメインを同時に扱うと判断精度が落ちます。

マルチエージェントならこれを解決できますが、代わりに調整のオーバーヘッドが発生します。このオーバーヘッドをどう管理するかが核心であり、記事ではその方法を具体的に扱っています。

3つのオーケストレーションパターン

この部分が最も実用的でした。「何がカッコいいか」ではなく、**「いつ何を使うか」**という基準で整理されているからです。

スーパーバイザーパターン (Supervisor)

管理エージェントがタスクを分解し、ワーカーに割り当て、結果を統合する構造。

• 適している場合: タスクがサブタスクに明確に分かれるとき、追跡が必要なとき
• 適正規模: ワーカー3〜8個
• 注意点: すべての判断がスーパーバイザーを経由するため、ボトルネックになり得る

スウォームパターン (Swarm)

中央管理者なしで、エージェント同士がP2Pで直接通信して自律的に組織化。

• 適している場合: 多角的な視点が必要なとき、リアルタイムの応答性が重要なとき
• 注意点: 重複作業、無限ループ、準最適な収束のリスク。デバッグが困難

階層型パターン (Hierarchical)

スーパーバイザーパターンの再帰的拡張。最上位 → 中間管理者 → ワーカーの多層構造。

• 適している場合: エージェント10個以上、戦略と戦術を分離する必要があるとき
• 注意点: 調整レイヤーごとにトークンコストが急増

個人的にはスーパーバイザーパターンが最も安定していると感じています。ただし、ワーカー配分の効率性とエラーハンドリングが非常に重要です。これを怠ると、管理エージェント自体が障害点になります。

エージェント間の通信方式

オーケストレーションパターンが構造を決めるなら、通信方式はエージェント間で情報が実際にどう流れるかを決めます。

• 共有状態 (Shared State): すべてのエージェントが1つの状態オブジェクトを読み書き。実装がシンプルでデバッグしやすい。ほとんどの場合ここから始めれば十分
• メッセージパッシング (Message Passing): イベントバスを介した非同期通信。エージェント間の結合を疎にしたいとき
• ハンドオフ (Handoff): エージェント間の明示的なバトンタッチとコンテキスト引き渡し。固定順序のパイプラインに適している

マルチエージェントのメモリアーキテクチャ

核心の問題はシンプルです。*状態をどう共有しつつ衝突を防ぐか。*記事ではこれを3つのパターンで解説しています。

セッションベースメモリ (Session-Based)

各エージェントが隔離されたローカル状態で作業し、完了時に共有メモリにマージ。

• 適している場合: 並列ワーカーが互いに干渉せず独立して作業する必要があるとき
• 仕組み: セッション開始時に共有状態のスナップショットを取得してローカルで作業 → セッション終了時に差分のみマージ
• 利点: ワーカー間の衝突なしに並列処理が可能

ウィンドウメモリ (Window Memory)

スライディングウィンドウで最新N件のやり取りのみを保持し、古いものは要約して圧縮。

• 適している場合: 長い会話でコンテキストを維持しつつトークンを管理したいとき
• 仕組み: ウィンドウ超過時に最も古い1/3を要約に圧縮
• 利点: 無限に膨張する状態の問題を解決

エピソディックメモリ (Episodic Memory)

特定のエージェント組み合わせの過去の協業履歴と結果を保存し、学習に活用。

• 適している場合: 頻繁に協業するエージェントが過去の経験をもとに改善すべきとき
• 仕組み: どのエージェントの組み合わせがどのタスクで成功/失敗したかを記録
• 利点: 「前回この組み合わせでうまくいったから、もう一度使おう」という判断が可能

本番運用での考慮事項

トークンコスト

• スーパーバイザー + ワーカー4個基準: 分解1K + ワーカー12K + 統合2K = 約15Kトークン
• 同じタスクをシングルエージェントで処理すると約4K。調整コストはほぼ4倍
• 最適化: スーパーバイザー指示のキャッシング、ワーカー出力は構造化データで、必要なときだけ呼び出し

レイテンシ

• LLM呼び出し1回あたり2〜5秒、エージェント4個を直列で12秒、並列なら3〜4秒
• 独立したタスクは必ず並列化

エラー伝播の防止

• タイムアウト: すべてのレイヤーで必須
• サーキットブレーカー: N回連続失敗でそのエージェントの呼び出しを停止
• グレースフルデグラデーション: 一部のエージェントなしでもコア機能が動作
• 状態の隔離: ワーカーの失敗が共有状態を汚染しないこと

観測できなければ修正もできません。モニタリングは初日から必須です。

避けるべきアンチパターン

• 過剰オーケストレーション: 独立して動けるエージェントを無理に連携させる
• 万能エージェント: 1つのエージェントに全部やらせたらマルチの意味がない
• コスト無視: トークンモニタリングなしでデプロイして、請求書を見て驚く
• フォールバックなし: すべてのエージェントが常に稼働している前提

まとめ

記事の結論が最も印象的でした。

エージェントを1つ作る → 限界点を特定する → その地点に2つ目のエージェントを追加する → 必要ならスーパーバイザーを置く → 繰り返す。

最初は階層型で壮大に設計しましたが、結局スーパーバイザー + ワーカー3個にシンプル化しました。まずは2つのエージェントが安定して協業するシステムから作るのが正解だと思います。

マルチエージェントを検討中の方は、ぜひ原文を読んでみてください。

原文: Building Effective Multi-Agent Systems