［開発者向け］上位入賞したAIエージェントに共通する4つの設計パターン——Googleが選考から抽出した実装知見

はじめに

　Googleが2026年9月2日、「AI Agents Challenge」の上位提出物に共通していた4つの設計パターンを開発者向けブログで公開しました。本稿では、双方向MCP、イベント駆動の並行処理、同一基準のフォールバック、段階的ルーティングという4点を実装の観点から整理します。

参考記事

• タイトル: 4 engineering patterns behind the strongest AI Agents Challenge submissions
• 著者: Sergio Villani
• 発行元: Google (Google for Developers Blog)
• 発行日: 2026年9月2日
• URL: https://developers.googleblog.com/4-engineering-patterns-behind-the-strongest-ai-agents-challenge-submissions/

関連記事

あわせて読みたい

［開発者向け］マルチエージェントワークフローが失敗する本当の理由と、信頼性を高める3つの設計パターン はじめに 　GitHubが2026年2月24日に公開した技術ブログで、マルチエージェントワークフローの失敗原因とその対策が解説されました。本稿では、GitHubがCopilotや内部自...

あわせて読みたい

［ニュース解説］MCPが「ステートレス」設計に進化——最新仕様公開でClaudeの連携機能はどう変わるか はじめに 　Anthropic(Claude公式ブログ)が2026年7月28日、AIエージェントと外部ツールをつなぐ標準規格「Model Context Protocol(MCP)」の最新仕様「MCP 2026-07-28」...

あわせて読みたい

［開発者向け］Google「Agent Garden」全ユーザーに公開：AIエージェント開発を加速するサンプル集と自... はじめに 　Googleが2025年11月4日、AIエージェント開発を支援するプラットフォーム「Agent Garden」を全ユーザーに公開しました。従来はGoogle Cloudユーザー限定でし...

要点

• Googleは、Google for Startups AI Agents Challengeの上位提出物に繰り返し現れた4つの設計パターンを、チーム名を伏せた形で公開した
• パターン1は双方向MCPであり、自身のツール層としてMCPを内部利用しつつ、その推論そのものを他のエージェントが呼べるMCPサーバーとして外部公開する構成である
• パターン2はイベント駆動の並行処理であり、エージェント間の直接呼び出しをやめ、トピックに発行されたイベントへ複数のエージェントが同時に反応する構成である
• パターン3は同一基準のフォールバックであり、主モデルと代替モデルの応答を単一の検証関数に通すことで、品質基準の適用漏れを構造的に防ぐ設計である
• パターン4は段階的ルーティングであり、あるチームは正規表現による事前判定だけで受信メッセージの40%以上をモデル呼び出し前に処理したと報告している

詳細解説

「マルチエージェント」を名乗る提出物のあいだにあった差

　Googleによれば、今回のChallengeには世界中から多数のエージェントが提出され、3つのトラックで審査が行われました。説明として最も多かった主張は「マルチエージェントシステム」でしたが、実際には洗練された構成もあれば、単一のモデルがプロンプトの連鎖をたどるだけで各工程にエージェント名が付いているものもあったと振り返っています。

　上位に入った提出物に繰り返し現れたのは、名前の付け方ではなく、通信・並行性・フォールバック・コストという実装上の判断でした。マルチエージェント構成が期待どおりに動かない要因については、過去記事でも設計パターンの観点から整理していますので、あわせて参照いただければと思います。

パターン1: 自分のために作ったツールは他のエージェントにも渡せる

　多くの提出物は、MCP（Model Context Protocol、モデルと外部ツールをつなぐ標準的な接続仕様）を、エージェントがツールサーバーへデータを取りに行く一方向の使い方に限っていました。あるチームはこれを双方向に拡張し、テレメトリ（稼働状況などの計測データ）のデータベースを自前のMCPツール層経由で内部参照しつつ、その推論結果自体を他のエージェントから呼び出せるMCPサーバーとして公開しています。

　Googleは、内部側の設計だけでも独立した意味を持つと説明しています。素朴な実装ではSQLの結果を全行そのままコンテキストへ流し込むことになり、本番規模のデータベースでは単一のリクエストでトークン予算を使い切る原因になります。ツール層を挟めば、テーブル全体ではなくジョブの実行計画や特定のスタックトレースだけを取り出せます。生の接続ではなくツール経由に限定していたことが、外部公開を可能にした前提でもあると整理されています。

　外部公開が変えるのは、そのエージェントの位置づけです。ターミナルやIDEで動くコーディングエージェントが、他のツールを呼ぶのと同じ手順で性能分析エージェントに直接質問できるようになり、人間がダッシュボードを開いて答えを写し戻す必要がなくなります。チャットインターフェースが到達点であるのに対し、MCPサーバーは他のエージェントが上に積み上げられるインフラになり得る、というのがGoogleの整理です。ただし、管理下にない呼び出し元へ提供する以上、実効的なアクセス制御が前提になると補足されています。

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

　あるチームの初期実装は、センサー監視エージェントがコンプライアンスエージェントを呼び、さらに通知エージェント、派遣エージェントへと続く線形のパイプラインでした。デモとしては動きましたが、歩行の変化から転倒リスクを捉え、薬物相互作用データベースと突き合わせ、対応可能な時間内に通知を届けるという実際の要件では破綻したと説明されています。

　解決策は、エージェントごとに1つ、計4つの asyncio.Queue （Python標準の非同期処理ライブラリが提供するキュー）で構成した非同期イベントバスでした。各エージェントは戻り値を待つ直接呼び出しではなく、型付きのイベントを名前付きトピックへ発行し、関心のあるトピックを購読します。歩行速度が15%以上低下すると CLINICAL.ANOMALY_DETECTED が発行され、そのトピックで待機していたコンプライアンスエージェントが即座に受け取って照合し、完了時点で CLINICAL.COMPLIANCE_REPORT_READY を発行します。下流の通知・派遣エージェントも、購読トピックによって起動されます。

　違いは遅延の積み上がり方にあります。呼び出し連鎖では各エージェントが次を待つあいだスタックを開いたままにするため全体の遅延は単純な合計になりますが、トピックベースのバスでは互いの出力に依存しない2つが同じ瞬間に走ります。数秒ごとのポーリング、0.5秒程度のネットワーク呼び出し、最後に一度だけ動く処理といったテンポの違いが混在するほど効果が出るとされています。発行側が購読側の完了を待たない点が要点で、ここを直接呼び出しに戻すと、名前の上ではマルチエージェントでも実態は単一スレッドのシステムになると指摘されています。

パターン3: フォールバック先のモデルも同じ品質基準を通す

　別のチームの臨床推論エージェントは Gemini 3.1 Pro で動作していましたが、実負荷の下でProが503（サーバー側の一時的な過負荷を示すエラー）を返し始めました。同じモデルへのリトライを足して終わらせるのではなく、このチームは Gemini 3.6 Flash へのフォールバックをバックオフ（再試行間隔を段階的に広げる仕組み）付きで実装し、どちらの応答も同一の検証関数に通してから受け入れる構成にしています。検証は引用チェックで、回答が実在の臨床ガイドラインを挙げているかを判定します。

　要点は、フォールバックの有無ではなく検証をどこに置いたかです。主経路用と代替経路用に検証コードを複製すれば、片方だけを更新して他方を忘れる事故が起きます。この実装では validate_clinical_response() という単一の関数があり、Pro側もFlash側も結果を外へ出す前に必ずそれを呼ぶよう強制されています。同じ基準を2回適用し忘れないようにするのではなく、1回しか適用しないことを構造的に不可能にする設計です。フォールバック発火後のコードパスに主経路の検証が残っているかは、そのまま自社での確認項目になると思います。

パターン4: 高価な呼び出しの前に段階的に振り分ける

　推論コストは現在最も議論の多い制約の一つですが、Googleは今回の選考で実際に機能していた削減策として段階的ルーティングを挙げています。あるチームが推論予算の内訳を計測したところ、消費していたのは難しい質問ではなく、「注文はどこですか」といった簡単な要求で、これらが本当に曖昧な要求と同じフルのモデル呼び出しを通っていました。

　実装されたのは、エージェントの手前に置いた3層の分類器です。第1層はローカルの正規表現で、画面遷移を求めるだけの意図をトークン消費ゼロで捌きます。第2層は曖昧なケース向けに、意図分類だけを目的とした10トークン・temperature 0.1のGemini呼び出しを行い、そこを通過したものだけが本命の推論モデルに到達します。Googleによれば、チーム自身の計測で、第1層だけで受信メッセージの40%以上がモデル呼び出し前に処理されていました。temperature 0.1は分類結果のばらつきを抑える狙いだと考えられます。より大きなモデルが必要だと決めつける前に、自社のトラフィック分布を測ることが先だと思います。

ADKとAgents CLIという足場

　Googleは、これら4つのパターンが最も多く現れたのは、Agent Development Kit（ADK） と Agents CLI で構築された提出物だったと述べています。並行処理、フォールバック、他のエージェントへのツール提供という点で、フレームワーク側が邪魔をしないことが理由とされています。ADKはコードファーストのエージェント開発フレームワークで、Agents CLIは雛形生成から評価、Google Cloudへのデプロイまでを担う周辺のツール群です。元記事では、パターン1と3を組み合わせ、専門エージェントを並行展開したうえで推論層全体をMCPサーバーとして公開していたチームも紹介されています。

まとめ

　今回示された4つのパターンは、いずれも大きなチームや新しいモデルを必要としない基本的な設計判断です。通信の向き、並行性の持たせ方、フォールバック時の品質基準、モデル呼び出し前の振り分けという4点は、次の実装での確認項目として使えると思います。ADKを使った開発環境については、過去記事でも整理していますので、あわせてご覧ください。