[セッションレポート] Build multi-agent systems that actually work（実際に機能するマルチエージェントシステムを構築する） の発表内容まとめ #GoogleCloudNext

はじめに

こんにちは、すらぼです。Google Cloud Next Las Vegas' 26 の 1日目（4月22日）に発表されたセッション "Build multi-agent systems that actually work" のセッションレポートになります。

---

ここよりセッション紹介

セッションの内容

• マルチエージェントへ移行するタイミング
• アーキテクチャの選び方

マルチエージェントへ移行するタイミング

まず、マルチエージェントシステムはシングルエージェントと比較してトークンコストが3から10倍になります。そのため、まずはシングルエージェントから始めることが重要で、本当に必要な場面を見極める必要があります。

その上で、以下の3つのシグナルを満たす場合が、導入の目安となります。

• コンテキスト汚染 (Context Pollution)
  • タスクに不要なデータがメインコンテキストを埋め尽くし、推論能力が低下する現象。
  • 対策は、サブエージェントを使用して50トークン程度のサマリを返すように指示すること
• 並列化可能なサブテキスト (Parallelizable Subtext)
  • コードレビューのように、それぞれ異なる基準でのチェックを並列実行すべきタスク
• 一貫性のない結果 (Inconsistent Results)
  • 同じエージェントが複数の専門的なタスクを処理しようとして結果にブレが生じる問題。
  • 対策は、エージェントごとにプロンプトを分離する。

アーキテクチャの選び方

これを踏まえて、5つのマルチエージェントの実装パターンと選び方を紹介します。

コンテキスト中心のタスク分割

前提となるエージェントの分離する軸の考え方は、エージェントの役割ではなく、「必要なコンテキスト（前提知識やデータ）が同じかどうか」を基準に分割するアプローチが有効です。

「課題ベース」で作業を分離した場合、コンテキストの受け渡しが必要となります。結果として引き継ぎを作る/受け取るコストが増大し、精度に影響が出ます。

「コンテキストベース」で分離することで、各エージェント内に必要な情報は全て保持できているため、コンテキストの不要な消耗をせず作業を遂行できます。

1. ジェネレーター・ベリファイアパターン (Generator-Verifier)

1つ目のパターンは生成者が結果を作成し、検証者が基準に基づいて合否を判定するループ構造です。サポートメールのドラフト作成やコード生成など水準を満たせばOKというタスクで有効。（ただし水準を言語化できる場合のみ）

逆に、基準が曖昧だったり、生成と同じくらい難しい場合は良し悪しの判断が難しく、無限ループに陥る可能性もあります。
加えて、早期に「検証成功」と見なしてしまうような問題にも注意が必要です。

2. オーケストレーター・サブエージェントパターン (Orchestrator-Subagent)

オーケストレーターがタスクを分割し、各サブエージェントに並行して作業を割り振る形式です。大半のユースケースで機能するため、最初に検討すべきパターンです。
実際、「マルチエージェント」と聞いたときに、多くの方がイメージするケースはこれかと思います。

得意なケース
大きなタスクを、それぞれ独立して有効な出力を出せる小さなタスクに綺麗に切り分けられる場合に最適です。

苦手なケース
一方が他方の情報を必要とする場合、ワーカー同士は直接やり取りができません。
そのためすべてオーケストレーターが中継しなければならず、ボトルネックや情報欠落の原因になります。

3. エージェントチームパターン (Agent Teams)

長期間・複数ステップにわたるタスクで、各ワーカーがコンテキストを維持しながら自律的に作業を進めるパターンです。大規模なコード移行などに適しています。

得意なケース
長時間の実行に特に向いており、以前の作業で発見した構造などを次のタスクに活かせるため、何度もゼロから探索し直すコスト（再探索）を省けます。

苦手なケース
ワーカー同士は独立して動くため、例えば2人のワーカーが同じファイルを同時に編集しようとすると競合が発生します。慎重なタスク分割や競合解決の仕組みが必要です。

4. メッセージバスパターン (Message Bus)

共有通信レイヤーを介してイベントを発行し、登録されたエージェントが処理を行う非同期モデルです。
セキュリティ運用など、アラートに対して「ネットワーク管理」「権限管理」などの領域特化のエージェントが対応の要否の判断から実施まで行うようなユースケースが考えられます。

得意なケース
既存の接続をいじることなく、新しい脅威に対応するエージェントを後から簡単に追加できるため、拡張性に優れています。

苦手なケース
疎結合であるがゆえに「誰が何をしたか」の因果関係を追跡するのが難しくなります。また、イベントが誤分類されたり破棄されたりすると、どのエージェントも処理せず、エラーも出ないまま見逃される危険があります。

5. 状態共有パターン (Shared State)

共有のデータベースやドキュメントを介して複数のエージェントが同時に読み書きし、情報を蓄積しながら連携するパターンです。調査研究やナレッジベース構築に向いています。

得意なケース
お互いの進行中の作業を即座に把握し、調査方針を動的に修正しながらナレッジベースを構築していくようなタスクに最適です。

苦手なケース
エージェントAの書き込みに対してエージェントBが反応して書き込み、それにまたAが反応して……というループに陥り、終わらなくなる危険性があります。これを防ぐために、時間予算や「収束したか」を判断する明確な終了条件が必要です

システムは時間とともにどう進化するか (Inflection Points)

システムの成長や課題の変化に合わせて、最適なアーキテクチャは変化していきます。各パターンの限界が見えた時（インフレクションポイント）に、次のパターンに移行します。この章ではその考え方の紹介をします。

1. オーケストレーターからエージェントチームへの移行 （Orchestrator-Subagent vs Agent Teams）

• 考えるポイント：サブエージェントのコンテキスト（前提知識）は、タスクをまたいで保持されるべきか？
• パターンの違い
  • オーケストレーター：タスク（例：バグ修正）ごとに新しいエージェントを立ち上げ、終わったら終了させます。
  • エージェントチーム：特定のサービス専属のワーカーを配置し、複数ステップの作業を通じてコンテキストを維持させます。
• 移行のサイン：エージェントの状態を維持するための「回避策（ワークアラウンド）」を作り始めたとき。
  • 具体例：例えばバグが特定のサービスに集中しているようなとき。新しいエージェントが毎回コードベースを再探索するのを防ぐため、プロンプトに「サービス仕様の要約」を渡し始めたら移行の合図です。

2. オーケストレーターからメッセージバスへの移行 （Orchestrator-Subagent vs Message Bus）

• 考えるポイント：ワークフローは「計画的」か、それとも「イベント駆動型」か？
• パターンの違い
  • オーケストレーター：リーダーがパスごとにエージェントを割り当てます。
  • メッセージバス：タイプに基づいてトピックが公開され、それを購読しているエージェントが処理を行います。
• 移行のサイン：オーケストレーターに「ルーティングのロジック」を追加し続けているとき。
  • 具体例：新しいインシデントタイプが増えるたびに、オーケストレーターのプロンプトに「この場合はこのエージェントに回す」という指示（ルーティングロジック）を継ぎ足しているなら、メッセージバスへ移行するべきです。

3. エージェントチームから状態共有への移行 (Agent Teams vs Shared State)

• 考えるポイント：各エージェントの作業は、他のエージェントと完全に独立しているか？
• パターンの違い:
  • エージェントチーム：各ワーカーは独立して作業し、実行中に発見を共有する方法がありません。
  • 状態共有：最初のワーカーが発見をストアに書き込み、他のワーカーは安全な処理を試みる前にそれを読み取ります。
• 移行のサイン：ワーカーが「最終結果」だけでなく、「途中の発見（中間結果）」を共有する必要が出てきたとき。
  • 具体例：依存関係のアップグレード中に一人が問題を発見した場合、他のワーカーも同じ問題を再発見してしまいます。この気づきを共有したくなったら、状態共有へ移行します

4. メッセージバスから状態共有への移行(Message Bus vs Shared State)

• 考えるポイント：イベントに対して反応・修正するか、それとも蓄積された状態の上に構築していくか？
• パターンの違い:
  • メッセージバス：イベントが引き金となって作業が開始されます。
  • 状態共有：調査が進むにつれて、エージェントがスコア（データベース）を照会し、更新していきます。
• 移行のサイン：エージェントがアクションを起こすためではなく、「発見（状態）を共有するため」にイベントを発行し始めたとき。
  • 具体例：セキュリティ運用の参照データは巨大であり、これをバスに流すと1箇所の変更で巨大なデータのコピーが毎回送信されてしまいます。データは共有ストアに置き、バスはアラート通知のみに使うのが正解です。

パターンに永遠はない

さまざまな移行パターンを紹介しましたが、最も意識すべきなのは「課題の変化によって最適なパターンも変わる」ということです。
最初に選んだパターンも、一度移行した後でも、取り組むべき課題が変わるにつれてパターンも最適化していく必要があります。

本セッションのまとめ

最後に、本セッションのまとめです。

• まずはシングルエージェントで取り組み、「コンテキスト汚染」「並列化」「専門化」の3つのシグナルを確認してからマルチエージェントに取り組む。
• マルチエージェントは3~10倍のトークンがかかること、無闇なエージェント追加はコストを増大させること。
• タスクの種類ではなく「コンテキストの境界」で仕事を切り分けること。
• 大半のケースでは、オーケストレーター・サブエージェントの適用から小さく始めるのが最適。
• 流行りではなく、システムの課題に合わせて、柔軟に別パターンに移行する。

---

セッション紹介ここまで

終わりに

マルチエージェントを実際に、かなりの規模で実践している組織での知見の共有ということで、学びが多くありました。
特に私は、そもそもマルチエージェントはエージェントチームしか知らず、オーケストレータパターンとの違いもよくわかっていませんでした。
ただ、その違いも「コンテキストを軸に考える」という観点で見るとどれも納得感が強く、大規模なAIワークロードを構築していく上では重要な考え方の詰まったセッションでした。

この記事が皆さんのお役に立てば幸いです。以上、すらぼでした。