これはGoogle Cloud NEXT Writing Challengeへの投稿です
Google Cloud Next '26のDay 1では、ビジョンが示されました。Sundar Pichaiが「AI生成コード75%」を発表しました。Thomas Kurianは「パイロット時代は終わった」と宣言しました。Amin Vahdatは第8世代TPUを公開しました。これは、私のGoogle Cloud Next '26のカバレッジPart 2です。Part 1はこちら：The 75% Illusion.
Day 2では、指示書が提示されました。
正直に言うと、最初は製品の販売デモだと思っていました。ところが実際には、これまで見た中で最も正直なGoogle Cloudの技術的な設計図でした。あの基調講演を見ていると、プレゼンではなく、マスターアーキテクトの作業場に通されたような感覚でした。デモではなく、生きた運用の場です。
Richard Seroter最高エバンジェリストとEmma Twerskyデベロッパー・リレーションズ・エンジニアによって率いられたDeveloper Keynoteは、大げさな断定に頼りませんでした。やったことは、60分間の、途切れないライブコーディングの修羅場でした：「AIエージェントだけで」ラスベガスのマラソンを計画する。展開されたのは製品デモではなく、エージェント型ソフトウェアエンジニアリングの“運用上の現実”を示すマスタークラスでした。
基調講演は、エージェント開発ライフサイクルの各フェーズに対応する7つの個別デモを、順に解説しました。build（構築）、orchestrate（オーケストレーション）、remember（記憶）、debug（デバッグ）、deploy（デプロイ）、extend（拡張）、secure（セキュア）です。この記事では、それぞれのデモが明らかにしたこと――そして、今や開発者が自律システムを構築し、デプロイし、運用し続ける必要があるという意味――を分解していきます。
デモ：マラソンではない。オペレーティングシステムだ。
準備は意図的に平凡でした：マラソンを計画する。しかし、そのアーキテクチャはまったく別物でした：
- Planner（計画担当）エージェント：Google Maps、地理情報システム、レースディレクターのガイドラインを使って最適な走行ルートを決定します。
- Evaluator（評価担当）エージェント：それらのルートを、ビジネス要件と自治体の規制に照らして検証します。
- Simulator（シミュレーション担当）エージェント：無作為化された歩行者エージェントを使い、ルート上の群衆行動をモデル化します。
- サプライチェーン・エージェント（後から追加）：物流――給水所、携帯トイレ、医療テント――を担当します。これはノーコード・ツールだけで構築され、標準プロトコルを介してPlannerエージェントから呼び出されます。
3つのエージェント。2つのデプロイ環境（Agent RuntimeとGKE）。2つの開発パラダイム（コードファーストとノーコード）。それらをつなぐ1つのプロトコル。
これが、本番のエージェント型アーキテクチャです。単一の超エージェントではなく、互いを見つけ、作業を委任し、境界を越えて推論するために特化したエージェントの群れです。
デモ1：Agent Platformでエージェントを構築する
Plannerエージェントは、Gemini Enterprise Agent Platform内のビジュアル・インターフェースであるAgent Designerを使って構築されました。Emmaは自然言語でエージェントのふるまいを説明し、「Get Code」をクリックしました。そしてシステムは、Agent Development Kit（ADK）を用いてPythonコードを生成しました。**。
エージェントの“解剖”は学びになります。すべてのエージェントは3つのプリミティブで構成されます：
- Instructions（指示）：エージェントの役割と挙動を定義する自然言語
- Skills（スキル）：エージェントを外部API、データベース、スクリプトへ接続するための実行可能な拡張機能
- Tools（ツール）：エージェントが呼び出せる特定のAPI定義。たとえば、マネージドMCPサーバー経由でのGoogle Mapsなど
Googleが完全にマネージドするリモートMCPサーバー（Google Maps、BigQuery、Compute Engine、Kubernetes Engine）がデモされました。Apigeeは今やMCPブリッジとして機能し、既存のIAMとガバナンス制御を自動的に継承しながら、あらゆる標準APIを“発見可能な”エージェントツールへ翻訳します。
ここが重要なのは、ツールへのアクセスこそがエージェント案件の“静かな致命傷”になりがちだからです。多数のツールにまたがってAPIキー、レート制限、認証を管理するのは、脆いシステムを生みます。マネージドMCPサーバーは、その複雑さを外部化します。エージェントは必要なものを宣言するだけで、あとはプラットフォームが処理します。
重要なポイント：エージェント・プラットフォームは、instructions（指示）、skills（スキル）、tools（ツール）の3つのプリミティブを提供し、マネージドMCPサーバーがAPI統合の負担を完全に取り除きます。
デモ2：マルチエージェント・システムを作る
Evaluater（評価担当）エージェントは、Plannerのサブエージェントとしてデプロイされました。Simulator（シミュレーション担当）エージェントは、別のAgent Runtimeインスタンスで動作し、Agent2Agent（A2A）プロトコルを通じてPlannerと通信しました。
A2AはAgent Cards（エージェント・カード）を使います。これは、暗号学的に署名されたメタデータ文書で、各エージェントが何をできるか、どんな入力を受け付けるか、どう到達するかを宣言します。エージェント同士はAgent Registry（エージェント・レジストリ）を通じて互いを発見します。これはエージェントにとってのDNSのような役割で、レジストリに問い合わせ、必要な機能を持つエージェントを見つけ、その後は複雑なAPI契約なしにA2Aで通信します。
重要なのはアーキテクチャ面です。18種類のエージェント間コミュニケーション・プロトコルを体系的に分析したところ、Model Context Protocol（MCP）がツールアクセスを扱っていることが分かりました――データベース、API、サービスへの接続です。A2Aはピア協調を扱います――エージェント同士の交渉、委任、結果の受け渡しです。これらにより、二層の通信基盤が整います。ツール層はMCP、エージェント層はA2Aです。(Yuan et al., 2026)
この二つのプロトコルのスタックは、静かに“エージェント型インターネットのTCP/IP”になりつつあります。A2Aは、パイロットではなく本番で150の組織に到達しており、Salesforce、ServiceNow、SAP、Microsoftのスタック上に構築されたエージェント間で、実際のワークロードをルーティングしています。
基調講演ではさらに、Agent-to-UI（A2UI）も示されました。これは宣言的な標準で、エージェントがコードを描画するのではなく構造化データとしてUIを生成します。これによりフロントエンドのボトルネックが解消されます。PlannerエージェントがGemini Enterpriseアプリから呼び出されたとき、インターフェースは手作りコードではなくA2UIによって動的に生成されました。
重要なポイント： A2AとAgent Registryによって、エージェントは互いを発見し、交渉できます――エージェントの世界におけるDNSとHTTPです。
デモ3：メモリでエージェントを強化する
メモリは、ほとんどのエージェント・デモが動かなくなるポイントです。単一のセッションを扱い、その後はすべてを忘れてしまうからです。
Developer Keynoteは、この課題に正面から取り組み、次の点を区別しました：
- Sessions（セッション）：単一のやり取りの間に維持される短期的な状態（Agent Runtimeがネイティブに管理）
- Memory Bank（メモリバンク）：セッションや日をまたいで生き残る、長期かつ永続的なコンテキスト
PlannerエージェントはMemory Bankを使い、これまで計画したルートを思い出し、好みを学習しました。新しいマラソン依頼が届いたとき、エージェントはゼロから始めません。過去の判断を想起し、それに適応したのです。
しかし、自律エージェントが非構造化データに対して推論する必要があるとき、生のメモリだけでは不十分です。Plannerは、PDFの中に埋もれた自治体の規制を把握する必要がありました。解決策は、データエンジニアリング・エージェントが構築したRAGパイプラインでした。これはPDFを読み込み、Apache Spark向けのLightning Engineで分割（チャンク化）し、AlloyDBに保存し、さらにAlloyDBの自動埋め込み機能によって自動的にベクトル埋め込みへ変換します。Plannerエージェントは、AlloyDBのリモートMCPサーバーを通じて、この知識にアクセスしました。
返却形式: {"translated": "翻訳されたHTML"}GoogleのTPUハードウェアのライフサイクルアセスメントでは、運用時の電力による排出量が、生涯にわたる排出量の70%以上を占めることがわかりました。メモリ管理は、正しさだけでなくコストとサステナビリティのために重要です。冗長な計算は、不要なレイテンシであると同時に、不要なカーボンでもあるのです。 (Schneider et al., 2025)
要点: メモリバンクは長期的な想起を提供し、ナレッジカタログは非構造化データを、エージェントが直接使えるコンテキストへと変換します。
デモ4: 大規模におけるエージェントのデバッグ
何百ものエージェントが同時に動いていると、デバッグは指数関数的に難しくなります。分散したエージェントのフリートにデバッガを取り付けることはできません。
基調講演ではエージェントの可観測性が実演されました。これは、Agent Runtimeでデプロイされたエージェントについて、実行の完全なトレースを提供します。しかし、さらに印象的だったのはGemini Cloud Assist Investigationsです。トレース、ログ、エラーのデータを読み取るAIが、根本原因分析を行います。
開発者は（デモではVS Code内で）IDEからMCP接続を使い、自然言語でGemini Cloud Assistに問い合わせました。「なぜルート計画が失敗したのですか？」。AIはエージェントの可観測性トレースとGitHubの課題を取り込み、根本原因を特定し、修正案を提示し、さらに修正済みのコードを生成しました。すべて数分以内に。
これは「可観測性の逆転」です。人間がダッシュボードを解釈するのではなく、AIがシステムを解釈し、自然言語で人間に知見を伝えます。エージェントは「何が起きたか」を報告するだけではなく、「なぜ起きたか」を推論し、再発防止を提案します。
要点: 可観測性は今や双方向に機能します。システムは問題を報告するだけでなく、自分自身を診断するのです。
デモ5: 意図からインフラへ
シミュレータのエージェントは別のスタックで動かす必要がありました。Google Kubernetes Engine（GKE）に、Gemma 4（Googleのオープンモデル）を用いる構成です。元々はCloud Runでデプロイされていましたが、インフラ定義の移行が必要でした。
開発者はIDEを開き、MCP経由でGemini Cloud Assistを呼び出して、自然言語で「Cloud RunのマニフェストをGKEに変換して」と指示しました。Gemini Cloud Assistは、人間の意図とインフラの設定の間の翻訳者として働き、必要なKubernetes YAMLを生成し、変更を稼働中の環境へ適用しました。
クロスチームオーケストレーション（Croto）の研究では、複数エージェントのフレームワークは、エージェントが半ば独立して動き、洞察を交換する場合に、測定可能により良い結果を生むことが示されています。これはまさに、Googleがシミュレータを別のインフラで動かし、標準化されたプロトコルを通じてプランナーと通信したことで示したパターンです。 (Du et al., 2025)
要点: 「このワークロードをGKEに移して」が、今やYAMLで設定するものではなく、口にして指示するものになりました。
デモ6: ノーコードのエージェントとパラダイムをまたぐ相互運用性
最も戦略的に示唆に富むデモは、サプライチェーンのエージェントでした。水、食料、携帯用トイレのロジスティクス担当としてのコーディネータです。これはGemini EnterpriseアプリのAgent Designerだけで、つまりノーコードのビジュアルインターフェースだけで構築されました。そこでは業務ユーザーが、平易な言葉で望む自動化を説明します。
決定的な瞬間: ノーコードで作られたサプライチェーンのエージェントが、フルコードのプランナーエージェントと同じようにAgent Registryに登録され、プランナーがA2Aでそれを呼び出しました。プランナーは、サプライチェーンのエージェントがADKを使ってPythonで作られているのか、ビジュアルインターフェースで作られているのかを知る必要も、気にする必要もありません。必要なのはエージェントカードだけでした。
これは「開発者が作る」自動化と「ビジネスが作る」自動化の壁を崩します。どちらも、同じディレクトリに登録されたA2A対応のエージェントを生成すれば、その違いは無意味になります。エージェントのエコシステムは、出自ではなく、能力によって発見可能性が決まるフラットな名前空間になります。
要点: 開発者が作ったエージェントと、ビジネスが作ったエージェントの間に壁はもうありません。どちらも同じ言語を話します。
デモ7: エージェントメッシュのセキュリティ
最後のデモは、自律型エージェントが本番環境で実際の資格情報（クレデンシャル）を使って動作する場合に何が起きるかに焦点を当てました。
Agent Identityは、それぞれのエージェントに固有で追跡可能なアイデンティティを割り当てます。これは、複数のワークロードで共有され得る汎用のサービスアカウントとは異なります。Agent Gatewayは、エージェント間のプロキシとして機能し、IAMポリシーをエージェント間通信に適用して、アウトバウンドアクセスに対するガードレールを強制します。
デモでは、FinanceのMCPサーバーがデフォルトでロックされていることが示されました。プランナーエージェントは、ReadOnlyの条件付きで、Agent Gatewayに明示的なIAM Allowポリシーが追加されるまで、予算データにアクセスできませんでした。同様に、エージェントのアウトバウンドインターネットアクセスも、Egress Agent Policiesによって制御されました。
そしてWizが登場します。Googleが最近買収したセキュリティプラットフォームが、エージェントエコシステム全体（ソースコード、モデル、ツール接続、クラウドインフラ）をスキャンし、攻撃経路を示すセキュリティグラフを生成しました。Red Agent（AI搭載の「インテリジェントな攻撃者」）が脆弱性を継続的にプローブします。Green Agentは是正案を提案し、その是正案はCLIからClaude Codeのスキルを通じて直接適用されました。
GoogleのAgent Gatewayは、MCPとA2Aプロトコルの両方をネイティブに理解し、すべてのエージェント間通信に対して一元的なポリシー適用を提供します。これは境界防御（パリメータセキュリティ）ではありません。メッシュセキュリティです。つまり、すべてのエージェント接続が認証され、認可され、監査可能なのです。
要点: エージェントのセキュリティはもはやファイアウォールの話ではありません。すべてのエージェントがアイデンティティを持ち、そしてエージェント間の接続ごとにポリシーが伴うことが要点です。
開発者基調講演が実際に証明したもの
7つのデモは総合的に、個々の機能よりも重要な何かを示していました。それはツールチェーンが準備できているということです。
エージェント開発は2年間、「ハッカソンフェーズ」に費やされてきました。見事なデモだとしても、本番の負荷のもとでは崩れてしまいます。開発者基調講演は、このフェーズは終わったのだというGoogleの主張でした。いま、あなたは次のことができます:
- Agent Designerでプロトタイプを作り、ADKコードへ卒業する
- セッション、メモリ、可観測性が組み込まれた状態でAgent Runtimeへデプロイする
- 独自のグルーコードなしにA2Aでプラットフォーム間でエージェントを接続する
- AIによる根本原因分析で、分散したエージェントのフリートをデバッグする
- 自然言語で意図を説明してインフラを用意する
- ビジネスユーザーに、開発者が作ったシステムと共存するエージェントを作らせる
- エージェント固有のアイデンティティとゲートウェイのポリシーで、すべての接続をロックダウンする
マラソン形式のデモが「動かすこと」が目的だったわけではありません。部品同士が組み合わさることを示すのが目的でした。
今すぐ自分で試してみる
Googleは、このエコシステムを試すための無料アクセスを提供しています:
- Agent Development Kit（ADK）はオープンソースです。PythonまたはTypeScriptで、今すぐローカルのエージェントを作れます。
- Agent2Agent（A2A）プロトコルは、オープンな仕様とともにGitHubで利用可能です。ノートPCで2つのシンプルなエージェントを動かしてみてください。
- Next '26の10個の公式Codelabsは（以下のSourcesにリンク）、プランナーエージェントを作るところから、Agent Gatewayでそれをセキュアにするところまで、すべてを順を追って案内します。
このエコシステムはもはや机上の空論ではありません。今夜、adk init と入力して、エージェント同士が交渉する様子を見られます。
キーノートで未回答だったこと
キーノートはすべてを網羅しません。配信が終わった後、私の頭に残ったのは3つの疑問です：
- ベンダーロックインのリスク。 A2Aはオープンですが、管理されたMCPサーバー、Agent Runtime、Memory BankはGoogle Cloudに強く結び付いています。どれほど容易に、プロダクションのエージェントメッシュを別のクラウドへ移行できるのでしょうか？
- コストの可観測性。 エージェントはエージェントを呼び、さらにツールを呼びます。1回のマラソン級の計画セッションで、数十のサブタスクが発生するかもしれません。請求は誰にされ、エージェント呼び出しごとのコストをどのように追跡するのでしょうか？
- エージェントスプロール（増殖）のガバナンス。 すべての部門がノーコードのエージェントを作り、Agent Registryに登録できるなら、何が「信頼できる」と判断されるのでしょうか？ Agent Identityは出発点ではありますが、組織としてのガバナンスモデルはまだ定義されていません。
これらは批判ではありません。プラットフォームがハッカソンから本番へ移行するときに自然に生まれる次の疑問です。次のNext '27では答えが示されるだろうと私は思っています。
開発者への含意
このキーノートは、ここ18か月間ずっと醸成されてきた役割の転換を明確にしました。開発者はもはや主要なコード生産者ではなく、エージェントのトポロジーを定義し、コミュニケーションパターンを設計し、メモリ戦略を構成し、ガバナンスポリシーを設定し、創発的な振る舞いを監視するシステムアーキテクトになるのです。
エージェント型ソフトウェア工学に関する最近の研究では、この移行に向けた基盤となる柱が明らかになっています。関数レベルのコーディングではなくプロセスレベルのオーケストレーション、命令的な実装ではなく意図の仕様化、そして離散的なテストではなく継続的な検証です。(Yuanら、2026)
Agent Development Kitは、4つの言語すべてで現在安定しています。A2AプロトコルはLinux Foundationによって統治されており、150のプロダクション環境で稼働しています。プラットフォームはグローバルに利用可能で、実験用の無料のExpressティアが用意されています。
Developer Keynoteはコードを書くことが主題ではありませんでした。意図を定義し、エージェントをつなぎ、それらの相互作用を確保し、そしてその振る舞いを観測することが主題でした。これが新しい職務内容です。
あなたはどう思いますか？ A2Aプロトコルは、次に作るアプリケーションのアーキテクチャに対する考え方を変えることになるでしょうか？ すでにADKを試しましたか？
気になっています： マルチエージェントのアーキテクチャは、2026年に実際のプロジェクトで導入するつもりですか？それとも、まだ重すぎると感じるでしょうか？ ADKを試した方にとって、最大のつまずき（摩擦点）は何でしたか？コメント欄にあなたの経験を投稿してください。
出典
Google Cloud公式
- Developer Keynote Video — Google Cloud Next '26
- Day 1 Recap: Next '26 — Google Cloud Blog
- Next '26 Hands-On: 10 Codelabs — Google Cloud Blog
- What's New from Firebase at Cloud Next 2026 — Firebase Blog
業界分析
- Google Cloud Next 2026: AI Agents, A2A Protocol, Workspace Studio, and the Full-Stack Bet — The Next Web
- Google Cloud Next '26 Developer Keynote Report（日本語） — G-gen Tech Blog
- Wiz at Google Cloud Next: Machine-Speed AI Defense — Wiz Blog
学術論文
- Du, Z., Qian, C., Liu, W., ほか（2025）。"Multi-Agent Collaboration via Cross-Team Orchestration." Findings of ACL 2025.
- Yuan, D., Lyu, F., ほか（2026）。"Beyond Message Passing: A Semantic View of Agent Communication Protocols." arXiv:2604.02369.
- Schneider, T., ほか（2025）。"Life-Cycle Emissions of AI Hardware: A Cradle-To-Grave Approach and Generational Trends." arXiv:2502.01671.
