「マルチエージェント」という名前は設計じゃない——Googleが数千の応募から見つけた4つの本物パターン
「マルチエージェントです」は設計の話ではない
AIエージェントの開発が加速するにつれて、ある問題が可視化されてきた。「マルチエージェントシステムです」という主張の中に、実態を伴わないものが混ざりはじめているという問題だ。
Googleが2026年9月に公開した「Google for Startups AI Agents Challenge」の振り返り記事は、その問題をあけすけに指摘している。世界中から数千の開発者が参加したこのコンテストで最も多かった主張は、「これはマルチエージェントシステムです」というものだった。ところが審査員が詳しく見ると、単一のモデルがプロンプトの連鎖を処理しているだけで、それぞれにエージェントの名前が付いているだけのものもあったという。
これは批判のための話ではない。マルチエージェントという言葉自体が、いまだ定義が曖昧なまま実務の現場に降りてきている、という業界全体の状況を正直に映している。Googleがこの事実を公開したことの意義はそこにある。
一方で、各部門の上位に入った作品には、設計判断に複数の共通点があった。Googleはチームを特定しないよう匿名化した上で、その共通点を4つのパターンとして整理した。
4つのパターンの中身を具体的に見る
パターン1：MCPを双方向に使う
多くの応募作品は、MCP（Model Context Protocol）を一方向にしか使っていなかった。エージェントがデータを取得するためにツールサーバを呼び出す、というシンプルな使い方だ。
上位に入ったあるチームは、これを双方向に広げた。エージェントは内部でMCPツール層を介してテレメトリーのデータベースを利用しつつ、同じ推論機能を他のエージェントから呼べるMCPサーバとして外部にも公開した。人間向けのチャット画面を作らなくても、別のエージェントが直接そのエージェントの推論を呼び出せる。
なぜこれが重要か。素朴な実装では、テレメトリーのDBにSQLを発行して返ってきた全行をそのままモデルのコンテキストに流し込む。本番のデータベースでこれをやると、1回のリクエストでトークン予算を使い切ることになる。ツール層を挟めば、エージェントはテーブル全体ではなく「特定のスタックトレースだけ」「ジョブの実行計画だけ」を取り出せる。コンテキストが推論できる大きさに収まる、という話だ。
そして、ツール経由でアクセスしているからこそ外部公開もできる。用途を限った範囲の答えだけを返すツールなら制御外の呼び出し元に渡しても安全だが、生のSQL接続ではそうはいかない。なお、Googleは一点注意を添えている。「制御下にない呼び出し元にサービスを提供する以上、そのサーバには実効性のあるアクセス制御が必要になる」。この留保は後で改めて触れる。
パターン2：非同期イベントバスで並行処理する
あるチームが作ったのは、歩行の変化からリアルタイムで転倒リスクを検知し、薬剤相互作用DBと照合した上で、適切な担当者にメッセージを送る監視システムだ。
初期版は「センサー監視→コンプライアンス→通知→出動要請」という直線的なパイプラインだった。デモでは動いたが、対処できる時間内に適切な相手へ通知することに失敗した。直線パイプラインでは、全体の遅延が各エージェントの処理時間の合計になるからだ。
解決策は、4つのasyncio.Queueで構成する非同期イベントバスだった。各エージェントは型付きのイベントを名前付きトピックに発行し、関心のあるトピックを購読する。歩行速度が15%以上低下するとCLINICAL.ANOMALY_DETECTEDイベントが発行され、コンプライアンスエージェントはそのトピックで待機しているので即座に受け取り、薬物相互作用DBと突き合わせ、終わり次第CLINICAL.COMPLIANCE_REPORT_READYを発行する。ポーリング間隔を待つ必要も、上流からの明示的な引き継ぎを待つ必要もない。
互いの出力に依存しない2つのエージェントが、同じ瞬間に動ける。これが呼び出し連鎖との決定的な差だ。
パターン3：フォールバック先にも同じ検証を通す
臨床推論エージェントが「Gemini 3.1 Pro」で動いていたチームは、負荷がかかって503エラーが返り始めたとき、多くの他チームがやるような「同じモデルへのリトライループ」ではなく、バックオフを伴う「Gemini 3.6 Flash」へのフォールバックを用意した。
ポイントはフォールバックの存在ではなく、検証をどこに置いたかだ。このチームはvalidate_clinical_response()という単一の関数を作り、Pro側の経路もFlash側の経路も、結果をエージェントの外に出す前に必ずこの関数を通す構造にした。検証内容は「回答が実在する臨床ガイドラインを挙げているか、それらしく聞こえる医学的な言い回しに過ぎないか」という引用チェックだ。
「同じ基準を二度適用し忘れないようにする」のではなく、「一度しか適用しないことが構造上できないようにする」。この言い方の違いが、ソフトウェア設計としての本質を突いている。
パターン4：高価なモデルを呼ぶ前に段階的に振り分ける
あるチームが推論予算を消費している対象を測定したところ、難しい質問ではなく「注文品は今どこにあるのか」「予約を取り消したい」といった簡単な質問が、コストの高いAIモデルを呼び出していた。
解決策はエージェントの前段に3層の分類器を置くことだった。まずローカルで実行する正規表現チェックにより、トークンを消費せずにナビゲーション関連の意図を捕捉する。判別しにくいものは、Temperature 0.1に設定した10トークン程度の安価なモデル呼び出しで意図のみ分類する。両方を通り抜けたものだけが本格的な推論モデルに届く。
このチーム自身の計測では、最初の1層だけで受信メッセージの40%超を、モデル呼び出しが起こる前に処理できた。別の作品も同じ思想を適用し、高速で安価なモデルが案件を受け付けて振り分け、深い推論が必要なものだけを低速で高価なモデルに引き上げていた。
なぜこの4つが「勝てる」のか——構造から読む
Googleはこの4つについて、「大きなチームや新しいモデルを必要とせず、見落とされがちな健全なエンジニアリングの実践だ」と位置づけている。
ここからは見方だが、この4つに共通しているのは「AIだから特別な何か」ではなく、ソフトウェアエンジニアリングとして当然やるべきことだという点だ。データアクセスをツール経由に抽象化する、非同期処理で並行性を確保する、検証ロジックを単一箇所に集約する、コストのかかる処理の前にフィルターを置く——これらはAIエージェント固有の話ではない。
つまり、「マルチエージェントと名乗っているけど実態はプロンプト連鎖」という問題の根本は、AIの問題ではなくエンジニアリングの問題だ。AI特有の面白さに目が行くあまり、基礎的なシステム設計の原則を後回しにしているケースが多い、ということをこのコンテストは示している。
また、Googleは4つのパターンが互いに補完し合えると指摘している。実際、あるチームはパターン1とパターン2を組み合わせ、「ルートエージェントが複数の専門エージェントを並行して呼び出し、その推論層全体を他のエージェントから直接呼べるMCPサーバとして公開する」という構成を実現していた。パターンは積み重ねられる。
なお、Googleによるとこれら4つが最も多く現れたのは「Agent Development Kit（ADK）」で構築し「Agents CLI」から動かした作品だったという。ADKが並行処理、フォールバック、他エージェントへのツール提供を妨げない設計になっているからだとしている。
実務的な示唆：開発者と意思決定者はここを見る
このレポートの使い方として、「次に自分のシステムのどこを改善するか」の診断フレームとして読むのが現実的だと思う。
- トークン予算がすぐ枯渇するなら → パターン1。DBアクセスをツール経由に抽象化して、コンテキストに何が入るかをコントロールする
- 複数処理の遅延が積み重なって実用的な速度が出ないなら → パターン2。直線パイプラインをイベント駆動の並行処理に切り替える
- フォールバック時の品質が不安定なら → パターン3。検証関数を1か所に集約して、経路によって基準がブレない構造にする
- 推論コストが想定を超えているなら → パターン4。前段の分類器でモデル呼び出しそのものを減らす
意思決定者の立場でも、「このシステムはマルチエージェントですか？」という問いより、「フォールバック時の検証基準は同じですか？」「並行処理になっていますか？」と具体的に聞けるようになると、実態の把握精度が上がる。
もう一点。Googleはこの4つのパターンを次回コンテストでも基準として採用する予定だと述べている。これはある種のシグナルだ。Googleが「評価基準」として明示するということは、エコシステム全体の設計標準として波及していく可能性がある。自社のAIエージェントが外部に公開されたり、他社のシステムと連携したりする場面が増えてくれば、これらは「知っていると得」な話ではなく「知らないと困る」話になっていく。
今後の論点：次に何が問われるか
パターン1の末尾にあった注意書きを改めて引用したい。「制御下にない呼び出し元にサービスを提供する以上、そのサーバには実効性のあるアクセス制御が必要になる」。
これは技術的には当然の話だが、エージェント同士が互いを呼び合う構成が一般化していくと、誰がどのエージェントを呼べるのか、その認証と認可の設計が本格的な課題になってくる。MCPサーバを外部公開したとき、「到達できる者は誰でも推論層を直接呼べる」という事実は、セキュリティ設計をサボっていた場合に大きなリスクになる。
もう一つは、パターンを組み合わせたときの運用複雑性だ。非同期イベントバスとフォールバック機能を組み合わせ、さらにMCPサーバとして外部公開している場合、何か問題が起きたときのデバッグはかなり難しくなる。「健全なエンジニアリングの実践」と紹介されているパターンだが、それを組み合わせて本番環境で安定稼働させ続けるための可観測性（ログ、トレース、アラート）の設計は、次に問われるテーマだと見ている。
マルチエージェントの「設計」は、コンテスト段階ではパターンの話だ。本番稼働の段階では運用とセキュリティの話になる。その移行を乗り越えたチームだけが、「名乗るだけ」の段階を本当に抜け出せる。
参考元: 「マルチエージェント」を名乗るだけの作品が続出 Googleが数千の応募から見つけた"勝てる設計"4つのパターン（＠IT）
