「マルチエージェント」を名乗るだけの作品が続出 Googleが数千の応募から見つけた“勝てる設計”4つのパターン：上位入賞作だけがやっていた

Googleは、AIエージェント開発コンテストの上位作に見られる4つの設計パターンを公開した。応募の多くが「マルチエージェントシステム」を掲げていたが、実態は単一のモデルがプロンプトをつなげているだけのものもあったという。

[＠IT]

　Googleは2026年9月2日（米国時間）、同社が実施したスタートアップ向けのAIエージェント開発コンテスト「Google for Startups AI Agents Challenge」について、3つの部門それぞれで上位に入った作品に見られる4つの設計パターンを公開した。コンテストには世界中から数千の開発者が参加し、審査員が3部門で採点した。

　応募作品で最も多かったのは「これはマルチエージェントシステムです」という主張だった。詳しく見ると、本当に高度なマルチエージェント構成のものがある一方で、単一のモデルがプロンプトの連鎖を処理しているだけで、それぞれにエージェントの名前が付いているだけのものもあったという。

　一方で、各部門の上位に入った作品には、設計判断に複数の共通点が見られたという。Googleは特定チームの話にならないよう、提出されたコードから名前を伏せて4つのパターンを以下のように紹介している。

マルチエージェントシステムの4つの設計パターン

1．自分用に作ったツールは他のエージェントにも提供できる

　多くの作品はMCP（Model Context Protocol）を一方向にしか使っていなかった。エージェントがデータを取るためにツールサーバを呼び出すという使い方だ。あるチームはこれを双方向に広げた。エージェントは内部で自前のMCPツール層を介してテレメトリー（遠隔計測データ）のデータベースを利用し、同じ推論機能を他のエージェントから呼べるMCPサーバとして外部に公開した。人間向けのチャット画面を作らなくても、別のエージェントが直接質問できる。

　これは内部側だけでも意味がある。素朴な作りのエージェントは、テレメトリーの保管先にSQL（Structured Query Language）を発行し、返ってきた全ての行をモデルのコンテキストに流し込む。本番のデータベースでこれを実行すると、1回のリクエストでトークンの予算を使い切る。MCPのツール層を挟めば、エージェントはデータをプログラムから検査、絞り込みできるツールを得て、テーブル全体ではなくジョブの実行計画や特定のスタックトレースだけを取り出せる。コンテキストは推論できる大きさに収まる。

　データベースへのアクセスを生の接続ではなくツール経由にすることが、外部公開を可能にする条件でもある。用途を限った範囲の答えだけを返すツールなら、制御下にない呼び出し元に渡しても安全だが、生のSQL接続ではそうはいかないからだ。エージェント自身の推論を1つのツールの内部処理として閉じ込めておけば、外部公開は同じツールの前にMCPサーバを立てるだけで済む。ターミナルやIDE（統合開発環境）で動くコーディングエージェントが、他のツールを呼ぶのと同じように性能分析のエージェントを直接呼び出し、特定のジョブについて尋ねられるようになる。

　見落としやすい注意点もある。制御下にない呼び出し元にサービスを提供する以上、そのサーバには実効性のあるアクセス制御が必要になる。到達できる者は誰でも推論層を直接呼べるからだ。

双方向にMCPを使うエージェントの構成（提供：Google）

2．同じイベントに複数のエージェントを並行して反応させる

　あるチームは、歩行の変化からリアルタイムで転倒リスクを検知し、薬剤相互作用データベースと照合した上で、対応可能な時間枠内に適切な担当者へメッセージを送信するリアルタイム監視／連絡システムを構築した。

　直線的なパイプラインだった初期版では、「センサー監視エージェント」が「コンプライアンスエージェント」を呼び、それが入居者への「通知エージェント」を呼び、さらに「出動要請エージェント」を呼ぶ。デモでは問題なく動いたが、対処できる時間内に適切な相手に通知することに失敗した。

　解決策は、4つのキュー（asyncio.Queue）で構成する非同期のイベントバスだった。キューはエージェントごとに1つずつ用意し、それぞれに専用のワーカーコルーチンがある。エージェントAがエージェントBを呼んで戻り値を待つのではなく、各エージェントは型付きのイベントを名前付きトピックに発行し、関心のあるトピックを購読する。

　歩行速度が15％以上低下すると「CLINICAL.ANOMALY_DETECTED」イベントが発行される。コンプライアンスエージェントは既にそのトピックで待機しているので、発火した瞬間に受け取り、薬物相互作用データベースと突き合わせ、終わり次第「CLINICAL.COMPLIANCE_REPORT_READY」イベントを発行する。ポーリング間隔を待つことも、上流からの明示的な引き継ぎを待つこともない。

　呼び出し連鎖では、全体の遅延が各エージェントの処理時間の合計になる。それぞれが次の処理を待つ間、スタックを開いたままにするからだ。トピックベースのバスなら、互いの出力に依存しない2つのエージェントは同じ瞬間に動く。数秒ごとにポーリングするもの、0.5秒かかるネットワーク呼び出しをするもの、最後に一度だけ動くものというように、動作の間隔が異なるエージェントを組み合わせるときにこの形が効く。

直線的なパイプラインとイベント駆動の並行処理の比較（提供：Google）

3．フォールバック先のモデルにも同じ基準を課す

　別のチームの臨床推論エージェントは「Gemini 3.1 Pro」で動いていたが、負荷がかかって503エラー（Service Unavailable）を返し始めた。他作品の多くは同じモデルへのリトライループを付けて済ませるところを、このチームはバックオフを伴う「Gemini 3.6 Flash」へのフォールバックを用意し、どちらのモデルの応答も全く同じ検証関数に通してから受け入れるようにした。検証内容は、「回答が実在する臨床ガイドラインを挙げているか、それらしく聞こえる医学的な言い回しに過ぎないか」を確かめる引用チェックだ。

　参考にすべき点はフォールバックの存在ではなく、検証をどこに置いたかにある。主系統用と待機系統用に検証を2つ複製すると、片方だけ更新して他方を忘れやすい。ここでは「validate_clinical_response()」という単一の関数があり、Pro側の経路もFlash側の経路も、結果をエージェントの外に出す前に必ずこの関数を呼ぶ。同じ基準を二度適用し忘れないようにするのではなく、一度しか適用しないことが構造上できないようにしている。

フォールバック時も同じ検証を通す構成（提供：Google）

4．高価なAIモデルを呼び出す前に段階的に振り分ける

　推論コストは、現在のAI運用で最も議論されている制約だ。あるチームが推論予算を消費している対象を測ったところ、難しい質問ではなく「注文品は今どこにあるのか」「予約を取り消したい」といった簡単な質問が、コストの高いAIモデルの呼び出しを実行していた。

　このチームはエージェントの前段に3層の分類器を置いた。まずローカルで実行する正規表現チェックにより、トークンを消費せずにナビゲーションに関する意図を捕捉する。判別しにくいものは、Temperature（出力のランダム性を決めるパラメーター）を0.1に設定した10トークン程度の安価なモデル呼び出しによって意図だけを分類する。両方を通り抜けたものだけが本格的な推論モデルに届く。

　チーム自身の計測では、最初の1層だけで受信メッセージの40％超を、モデル呼び出しが起こる前に処理できた。別の作品も同じ考え方を適用し、高速で安価なモデルが案件を受け付けて振り分け、深い推論が必要なものだけを低速で高価なモデルに引き上げていた。

段階的な振り分けを行う構成（提供：Google）

　Googleによると、これら4つのパターンが最も多く現れたのは「Agent Development Kit」（ADK）で構築し、「Agents CLI」から動かした作品だった。ADKが並行処理やフォールバック、他のエージェントへのツール提供を妨げないからだという。

　4つのパターンはいずれも大きなチームや新しいモデルを必要とせず、見落とされがちな健全なエンジニアリングの実践だとGoogleは位置付ける。これらは互いにうまく調和し、補完し合える。あるチームは、ルートエージェントが複数の専門エージェントを並行して呼び出し、その推論層全体を他のエージェントから直接呼べるMCPサーバとして公開する形で、パターン1とパターン2を組み合わせていた。

　Googleは、次回のコンテストでもこの4つのパターンに沿ったシステムを基準にするとしている。