デベロッパー

Gemini CLI DevOps 拡張機能を使用して、わずか数分でコードをリリース

Tue, 19 May 2026 02:30:00 +0000

※この投稿は米国時間 2026 年 5 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

Antigravity や Claude Code のような AI コーディングツールを使うと、実用的なウェブアプリを記録的な速さで構築できます。しかし、デプロイとなると話は別です。これまでの私なら、Dockerfile、IAM バインディング、YAML の設定に午後の残りの時間をすべて費やしていたでしょう。結局は、多くの開発者と同じ近道、つまり、デプロイしないことを選択したはずです。アプリは私のノートパソコンに残り続け、私の仕事がリリースされることはないでしょう。

これは、インナーループ（コードの記述やテストといった高速なローカルサイクル）とアウターループ（コンテナ化、CI / CD パイプライン、本番環境インフラストラクチャ）の間にある典型的な緊張関係です。ほとんどの開発者はどちらか一方では生産性を発揮しますが、もう一方では発揮できません。このギャップがプロジェクトの停滞につながります。

CI / CD 用の Gemini CLI 拡張機能は、このギャップを埋めます。単一のターミナルインターフェースから、迅速なデプロイと完全なパイプライン生成の両方を処理できます。その方法をご紹介しましょう。

Cosmic Guestbook アプリを構築する

このワークフローを実演するには、アプリが必要です。空のディレクトリから開始して、エージェントを使用し、Cosmic Guestbook というまったく新しいプロジェクトを「バイブコーディング」しましょう。

フルスタックアーキテクチャ（React フロントエンドと Node.js Express バックエンド API）を構築します。これを手動でスキャフォールディングする代わりに、アプリをすぐに作成するようエージェントに依頼します。

code_block: <ListValue: [StructValue([('code', '"Build a \'Cosmic Guestbook\' web app. I need a dynamic Node.js Express backend and a React frontend utilizing Vite. Make the frontend look like a beautiful, glassmorphic sci-fi interface."（「Cosmic Guestbook」というウェブアプリを構築して。動的な Node.js Express バックエンドと、Vite を利用した React フロントエンドが必要。フロントエンドは、美しいグラスモーフィズムの SF 風インターフェースにして。）'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2ddf26a0>)])]>

エージェントはすぐに、server.js を含む backend/ ディレクトリと、完全にスタイル設定された React アプリを含む frontend/ ディレクトリをスキャフォールディングします。これで、ノートパソコン上で動作する 2 層構造のウェブアプリが完成しました。

拡張機能をインストールする

しかし、ノートパソコン上のコードはリリースされません。このゲストブックをオンラインにするには、選択した環境に CI / CD 拡張機能を導入する必要があります。どのような設定であっても、まず gcloud CLI がインストールされていることを確認し、アプリケーションのデフォルト認証情報を使用して認証します（gcloud auth application-default login）。

次に、使用する開発環境に拡張機能をインストールします。

Gemini CLI の場合

ターミナルで次のコマンドを直接実行します。

code_block: <ListValue: [StructValue([('code', 'gemini extensions install https://github.com/gemini-cli-extensions/cicd'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2ddf2130>)])]>

Claude Code の場合

マーケットプレイスを追加し、ターミナルからプラグインを直接インストールします。

code_block: <ListValue: [StructValue([('code', '# 1. Marketplace を追加する\r\nclaude plugin marketplace add https://github.com/gemini-cli-extensions/cicd.git\r\n\r\n# 2. プラグインをインストールする\r\nclaude plugin install cicd'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2ddf23a0>)])]>

Antigravity、および npx skills でサポートされているエージェントの場合

拡張機能の MCP サーバーをカスタム MCP として有効にし、スキルをワークスペースに追加します。

code_block: <ListValue: [StructValue([('code', '# スキルを追加する\r\nnpx skills add https://github.com/gemini-cli-extensions/cicd --global --all --agent antigravity'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2ddf2cd0>)])]>

仕組み

CI / CD 拡張機能は、これらすべてのエージェント環境で、インテントを安全かつプロダクションレディなインフラストラクチャに変換するよう設計された、強力な 3 層構造システムです。

スキル: google-cicd-deploy や google-cicd-pipeline-design などの専門的な AI スキルが拡張機能内で定義されています。これらは、AI エージェント（Gemini CLI、Claude Code、Antigravity）に思考方法を指示し、コードの分析、適切な質問、適切なエラー処理を支援します。
CI / CD MCP サーバー: バックグラウンドでは、Go ベースの専用 Model Context Protocol（MCP）サーバーが実行されています。このサーバーは、シークレットのスキャンから Cloud Run サービスのプロビジョニングまで、エージェントが Google Cloud を実際に操作するために必要な一連のツールを提供します。
ローカルナレッジベース: 最も正確な回答ができるよう、システムには、検証済みのアーキテクチャパターンを格納した、事前インデックス化済みの検索拡張生成（RAG）データベースが含まれています。これにより、エージェントは信頼できる情報源に基づいて設計上の判断を下すことができます。

選択した AI アシスタントが、これらのツールとパターンをオーケストレートし、一貫性のあるデプロイライフサイクルを実現します。

インナーループ

プロトタイプを構築したり、新機能をテストしたりする場合、大規模なマルチ環境 CI / CD パイプラインは必要ありません。必要なのは、Webhook をテストしたり、関係者にデモを見せたりするための公開 URL だけです。これがインナーループです。インナーループは高速である必要があります。

従来のアプローチでは、Dockerfile を手動で記述し、コンテナレジストリを使って認証を行い、イメージをビルドして push し、最後にデプロイします。CI / CD 拡張機能を使用すると、これが単一の自然言語プロンプト（gemini "Deploy this application to Google Cloud using the google-cicd-deploy skill"（google-cicd-deploy スキルを使用して、このアプリケーションを Google Cloud にデプロイして））に変わります。Claude Code を使用している場合は、claude -p "Deploy this application..." を使用してまったく同じようにプロンプトを入力できます。Antigravity では、デプロイリクエストを入力するだけです。

このプロンプトを実行すると、AI エージェントがローカルのワークスペースを分析して、最適なデプロイ方法を判断します。

ステップ 1: デプロイ前のセキュリティスキャン

シークレットの漏洩は、ソフトウェアにおいて最も一般的でコストのかかるセキュリティ障害の一つです。GitGuardian の The State of Secrets Sprawl 2025 レポートによると、1 年間で 2,380 万件の新しい認証情報が公開 GitHub 上にさらされ、2022 年に漏洩したシークレットの 70% が現在もなお有効であることが判明しています。ローカルテスト中にハードコードしたデータベースパスワードを削除し忘れたまま push してしまうなど、このような事態はあっという間に生じます。

この拡張機能は、問題になる前にこれを検出します。コードがマシンから送信される前に、ワークスペース全体に対してシークレットチェックが実行されます。ソース内に Stripe API キーやデータベース認証情報が見つかった場合、エージェントはデプロイを停止して警告を表示します。シークレットが誤ってクラウドに送信されることはありません。

ローカルホストで開発中にデータベースパスワードや Stripe API キーを誤って commit してしまっても、アシスタントがそれを検知してデプロイを阻止します。これこそが、実際の真のシフトレフトセキュリティです。

ステップ 2: アプリケーションの分析とコンテナ化

次に、エージェントは package.json または go.mod をチェックして、使用しているフレームワークを判別し、Google Cloud Storage（静的サイトの場合）と Cloud Run（動的サービスの場合）のどちらを使用するかを自動的に決定します。

Dockerfile がない動的サービスを構築する場合、拡張機能は Google Cloud の Buildpack を利用して、その場でコンテナ化します。

ステップ 3: 明確化とデプロイ

会話エージェントは、求められているアプリの構成をやみくもに推測するわけではありません。Google Cloud 環境に変更を加える前に、アシスタントはフローを一時停止し、分析中に判明した内容に基づいて優先順位付けの質問をします。

Cosmic Guestbook では、サービスを公開するかどうかやリージョンを指定しませんでした。アシスタントは一時停止し、その点について尋ねてきました。

「分析を完了し、Cloud Run への統合デプロイに向けてアプリケーションの準備を整えました。Node.js Buildpack では単一のエントリポイントが必要であるため、React フロントエンドを構築し、Express バックエンドがそれを静的に提供できるようにするカスタムビルドスクリプトを含むルート package.json を作成しました。

また、シークレットスキャンも正常に完了しました。機密性の高い認証情報は検出されませんでした。

Cloud Run のソースデプロイオプション（Buildpack）を使用してデプロイする前に、デプロイパラメータをいくつか明確にする必要があります。

リージョン / ロケーション: gcloud のデフォルト設定ではロケーションが指定されません。どの Google Cloud リージョン（例: us-central1、europe-west1）にデプロイしますか？
アクセス: このアプリケーションは一般公開しますか、それとも非公開にしますか？
サービス名: cosmic-guestbook というサービス名にすることを提案します。いかがでしょうか？」

このように会話が一時停止することで、高速なインナーループであっても、クラウドアーキテクチャを完全に制御し続けることができます。詳細を確認した後、エージェントはコードをライブ環境に push し、公開 URL を返します。

code_block: <ListValue: [StructValue([('code', '# 最終的な出力:\r\nYour application is now live and publicly accessible at the following URL:\r\nhttps://cosmic-guestbook-xxxxxxxx-uc.a.run.app'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2ddf2f70>)])]>

バックグラウンドでは、デプロイは cloudrun.deploy_to_cloud_run_from_source を使用して自動的に処理されます。

アウターループ

火曜日の午後にプロトタイプを作成するなら、おおざっぱなデプロイプロンプトで十分ですが、ノートパソコンから本番環境システムを運用することはできません。最終的には、自動テスト、ソース管理の統合、正式な継続的デプロイといったアウターループの厳格さが必要となります。

cloudbuild.yaml ファイルの作成や、必要なインフラストラクチャ（Artifact Registry リポジトリや Developer Connect を介した GitHub 接続など）のプロビジョニングは、非常に面倒でエラーが発生しやすい作業として知られています。google-cicd-pipeline-design スキルを使用すると、AI エージェントがパーソナルプラットフォームエンジニアリングコンサルタントとして機能します。

YAML をゼロから記述する代わりに、会話をします。エージェントは、テスト戦略とデプロイ先について質問し、必要な Google Cloud インフラストラクチャを自律的にプロビジョニングします。

ステップ 1: アーキテクチャの設計とフィードバック

このプロセスは、会話型インターフェースで直接開始します。

code_block: <ListValue: [StructValue([('code', '# エージェントにプロンプトを入力し、設計プロセスを開始する\r\ngemini "Design a CI/CD pipeline using the google-cicd-pipeline-design skill"\r\n# または\r\nclaude -p "Design a CI/CD pipeline using the google-cicd-pipeline-design skill"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2ddf2370>)])]>

アシスタントはブラックボックスの中で動作しているわけではありません。ナレッジベースから一般的な CI / CD パターンを取得し、最も関連性の高いナレッジに基づいて、確認用の具体的なプランを YAML で提案します。

ステップ 2: インフラストラクチャのプロビジョニング

プランを承認すると、アシスタントは必要なインフラストラクチャの手順を順番に実行します。たとえば、まずコンテナのレジストリを作成します。

code_block: <ListValue: [StructValue([('code', '// レジストリをプロビジョニングする MCP 呼び出しの例\r\n{\r\n "name": "create_artifact_repository",\r\n "arguments": {\r\n "repository_id": "demo-app-repo",\r\n "location": "us-central1",\r\n "format": "DOCKER"\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2ddf2880>)])]>

その後、Cloud Build がソースコードを読み取れるよう、Git 接続を設定する場合もあります。

ステップ 3: パイプラインの生成とトリガー

最後に、エージェントはパイプラインステージ（テスト、構築、デプロイ）を定義する実際の cloudbuild.yaml ファイルを生成します。以下は、リポジトリから生成された構成のスニペットです。初期ビルドステップが強調表示されています。

code_block: <ListValue: [StructValue([('code', 'steps:\r\n # ステップ 1: ツール（linter など）をインストールし、キャッシュをクリアする\r\n - name: \'golang:1.24\'\r\n id: \'Install Tools\'\r\n entrypoint: \'sh\'\r\n args:\r\n - \'-c\'\r\n - |\r\n set -e\r\n export PATH=/workspace/bin:$$PATH\r\n echo "Installing golangci-lint..."\r\n go install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.64.8\r\n echo "Cleaning module cache..."\r\n go clean -modcache\r\n env:\r\n - \'GOPATH=/workspace\'\r\n dir: \'devops-mcp-server\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2ddf25b0>)])]>

パイプラインを定義したら、それを自動的に実行する方法が必要です。エージェントは、Cloud Build トリガーを作成して処理を終えます。このトリガーは GitHub リポジトリと Cloud Build を結び付ける役割を果たし、main ブランチへの push が行われるたびに cloudbuild.yaml のステップが自動的に実行されるようにします。

code_block: <ListValue: [StructValue([('code', '// トリガーを設定する MCP 呼び出しの例\r\n{\r\n "name": "create_build_trigger",\r\n "arguments": {\r\n "trigger_name": "main-branch-deploy",\r\n "filename": "cloudbuild.yaml",\r\n "branch_pattern": "^main$"\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2ddf2820>)])]>

セキュリティと管理

AI を活用したインフラストラクチャ生成は素晴らしいことに思えますが、安全かどうか疑問に思うのはしごく当然です。

この拡張機能は、ローカルアプリケーションのデフォルト認証情報（ADC）の権限の範囲内で厳密に動作します。ユーザーができないことは、エージェントもできません。Model Context Protocol（MCP）を使用しているため、Artifact Registry の作成から Cloud Build トリガーの変更まで、エージェントが行うすべてのアクションは、厳密に型指定された検証可能なツールを介して実行されます。

提案されたパイプラインのステップが気に入らない場合は、エージェントに変更を指示します。インフラストラクチャの「編集長」は常にあなたです。ローカルの ADC と、生成されたパイプラインで使用するサービスアカウントの両方で、最小権限の原則を遵守することを強くおすすめします。

開発と運用の融合

コードを書きたいという思いとコードをリリースしなければならないという現実の間の葛藤が、ついに解消されつつあります。アプリをインターネット上に公開するには、YAML 形式に関する深い専門知識が不可欠だった時代は過ぎ去りました。

会話型 AI は、おおざっぱなインナーループと自動化されたアウターループの両方のボイラープレートを処理することで、開発者が本当に重要なビジネスロジックに集中できるようにします。

次のステップ

この融合を実際に体験してみたい方は、以下の手順に沿って進めてください。

ツールを入手する: Gemini CLI 用の CI / CD 拡張機能をインストールします。
インナーループをデプロイする: 既存のサイドプロジェクトを使用（または、選択したエージェントに Cosmic Guestbook のような新しいプロジェクトのスキャフォールディングを依頼）し、Google Cloud にデプロイするようプロンプトを入力すると、Cloud Run または Cloud Storage で即座に動作を確認できます。
アウターループを自動化する: 本番環境に移行する準備ができているリポジトリに対して設計コマンドを実行し、エージェントが cloudbuild.yaml を生成してインフラストラクチャをプロビジョニングする様子を確認します。

構成ファイルとの格闘はやめて、リリースを始めましょう。皆様が何を構築したのか、LinkedIn、X、Bluesky でぜひ教えてください。

- デベロッパーリレーションズ担当ディレクター、Karl Weinmeister

AI を活用したコード移行の先駆け: Google が TensorFlow から JAX への移行を 6 倍高速化した方法

Thu, 14 May 2026 02:10:00 +0000

※この投稿は米国時間 2026 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

AI コーディングエージェントは、ソフトウェア業界全体で急速に普及しつつあり、デベロッパーが日常的にコードを記述、テスト、デバッグする方法を根本的に変えています。このツールは、ローカルで完結するタスクに優れた機能性を発揮しますが、大規模で体系的なコードベースの移行に適用するには、まったく新しいアプローチを必要とします。

Google には、多くの移行ワークフローに AI を組み込み、このような課題に対処してきた実績があります。たとえば、x86 から ARM への移行では Google Axion プロセッサでワークロードを有効にし、int32（32 ビット整数）識別子から int64（64 ビット整数）識別子への移行によって ID の枯渇を防ぎ、JUnit3 から JUnit4 への移行でテストを簡素化し、Joda-Time から java.time への移行で最新の時刻ライブラリを使用可能にしました。しかし、AI モデルの移行には新次元の複雑さがともない、AI による移行支援のためのさらに高度な手法が必要となります。

本番環境グレードの ML モデルを 1 つのフレームワークから別のフレームワークに変換する（たとえば、TensorFlow（TF）から JAX に変換する）ことは、単純な構文の更新ではありません。数千行のコードを解きほぐし、複数ファイルにまたがる複雑な状態管理を実現し、正確な数学的等価性を維持しなければならない、長期的な展望を必要とするタスクです。これは、汎用の単一エージェントによるコーディングアシスタントには過大な重圧となります。長いワークフローでは頻繁にコンテキストが失われ、API を巻き込んだハルシネーションが起きたり、リポジトリ全体でビルド可能なコード生成が行われなくなったりします。

この業界全体の問題に対し、Google AI / インフラストラクチャチームは、世界に先駆けて新しいアプローチを開発しました。このアプローチは、モデルの移行を 6 倍速くするという、先日の Google Cloud Next の基調講演で Sundar が強調したマイルストーンを達成するものとなりました。この投稿では、Google がどのように専用マルチエージェント AI システムをデプロイして、Google 最大規模の本番環境モデルを TF から JAX に移行したのかについて、ご紹介します。

TF から JAX への移行を加速

Google の多くのチームでは（業界全体にも言えることですが）、未来に向けたスケーラブルな ML は JAX を基盤として構築されています。関数型でステートレスなパラダイムを中心に設計された JAX は、最新の Tensor Processing Unit（TPU）インフラストラクチャと XLA コンパイル向けに最適化されており、最新 AI スタックの強固な基盤となるものです。

これは未来への進歩であると同時に、非常に大きな課題も提示しています。TensorFlow は、オブジェクト指向でステートフルレイヤの初期化と静的実行グラフを特徴とするフレームワークであり、現在、何千もの本番環境モデルが、この TF を基盤に構築されています。これらのモデルを JAX に手動で移行するには、レイヤの相互作用や状態管理の明示的な方法を根本的に見直す必要があります。このような移行は、それだけで大規模な組織全体における数百（場合によっては数千）のソフトウェアエンジニアリング（SWE）年数を必要とします。組織にとっては、この時間を新しいアーキテクチャの調査やプロダクトイノベーションの推進に費やす方がはるかに有益です。

この課題を AI で克服する取り組みは、Google AI / インフラストラクチャチームの野心的な実験として始まりましたが、今では社内全体の複雑なエンジニアリングの問題に対処可能な再現性のあるブループリントにまで進化しています。

単一エージェントコーディングからの脱却

エージェントによるコード変換は、初期の実験では単純なモデルへの有効性が確認されました。しかし、現実的な Google 規模の移行に直面したとき、つまり、複数のファイルにまたがる数千行のコードの複雑な本番環境グレードのモデルを扱うとき、汎用的な単一エージェントでは困難を極めました。高次元の構造ルールと現実のこまごまとした実行上の問題の折り合いがつかず、重要なファイルを上書きしたり、必要な機能をとばしたりと、さまざまな障害が発生しました。このような大規模な移行によくある課題を克服するために、Google は以下で構成される高度に専門化されたマルチエージェントアーキテクチャを開発しました。

Planner エージェント: 決定論的なコンパイラベースの静的分析を使用して、コードベースの依存関係全体をツリー構造にマッピングします。その後、他のエージェントと連携して移行を個別の段階的プランに分割し、「リーフノード」（依存関係のない未移行レイヤ）から上に向かって論理的に移行が行われるようにします。
Orchestrator エージェント: このエージェントはプロジェクトマネージャーとして機能します。プランステップを管理しやすいチャンクに動的にグループ化してコンテキストウィンドウの対象を絞り、必要なドメイン知識を注入します。ステップがビルドされない場合は障害復旧を適用します。
Coder エージェント: 推論と行動の役割を担う主力エージェントです。社内の IDE ツールに直接統合され、ファイルの読み取り、コードの記述、ビルドの実行、単体テストの実施が可能です。「テストと修正」のループで動作し、コンパイル可能で検証可能なコンポーネントをターゲット言語で生成するまで自己修正を繰り返せる点が最大の特長です。

図: 複雑なコードを移行するためのマルチエージェント AI システム。レガシーモデルコードを JAX に移行するマルチエージェントシステムの仕組みを表したプロセス図で、Gemini Nano Banana 2 で生成。

スケーラブルな検証と柔軟な Playbook

生成 AI モデルの性能は、提供されるコンテキストの質に左右されます。移行元と移行先のアーキテクチャが 1 対 1 でマッピングされることはほとんどないため、Google はスケーラブルで階層的な一連の Playbook を策定しました。

これらの Playbook は、一般的なリポジトリの手順から、手動移行の成功事例から抽出された非常に具体的な「模範例」まで多岐にわたります。クライアント固有の Playbook（たとえば、YouTube 独自のランキングモデルインフラストラクチャ向けに調整されたもの）を Orchestrator にフィードすることで、一般的なハルシネーションが回避され、組織内のコーディング基準が厳守されます。この Playbook の構成は特定のフレームワークに依存しないため、任意の 2 つのプログラミング言語やフレームワーク間の移行をガイドするように調整することができます。

さらに、生成されたコードが実際にプロダクションレディであることを確認するために、以下の厳格な品質指標も設定されています。

定量的検証: コードの正確性をユニットごとに数学的に検証します。TF から JAX への移行の場合、勾配上昇法のアルゴリズムを使用して元の TF レイヤと新しい JAX レイヤの間の最大誤差を検出し、関数的な同等性を数学的に検証します。
定性的評価: 移行されたコードを、一連の定性的基準に照らして評価します。TF から JAX への移行の場合、盲検監査の LLM Judge をデプロイして、移行後のコードをフレームワークに依存しないアーキテクチャチェックリストに照らして採点します。これにより、ドメイン固有の重要なロジックを確実に把握することができます。

移行のスピードを革新

このマルチエージェントシステムをデプロイすることで、ソフトウェア移行の経済的効率性は劇的に向上します。

実際の複雑な YouTube モデル（数千行のコード、数百のレイヤ、複雑なメトリック依存関係を含む）で評価したところ、マルチエージェントシステムは手動での移行よりも 6.4 倍から 8 倍の高速化を実現しました。従来は数か月分のソフトウェアエンジニアリング（SWE）作業が必要だったものが、わずか数週間の AI によるコード生成と、その後の専門家（人間）によるレビューで完了できるようになったのです。

ボイラープレートの効果的な処理、ターゲット言語のイディオム特定、依存関係のマッピング、単体テストの生成が自動的に行われ、エンジニアは手動のコード変換担当者ではなく、レビュアーやアーキテクトとしての役割を担えるようになります。

AI を活用する時代の展望

AI は技術革新のペースを変革しています。大規模な移行を推進する力は AI で加速する必要があります。組織はそれなしでは、手動の作業に追われ、最新のブレークスルーを取り入れたり、システムのセキュリティ、信頼性、パフォーマンスを維持したりすることが難しく、そのギャップはますます広がっていきます。

ML 実装を 1 つの ML フレームワークから別の ML フレームワークに移行する Google の取り組みは、決定論的静的分析、厳格なテストループ、特殊なマルチエージェントアーキテクチャを組み合わせることで、業界でも特に複雑なソフトウェアエンジニアリングの課題を安全に自動化できることを示しています。プロセスの詳細については、こちらの技術論文をご覧ください。

^{この取り組みは、Google 全体でのコラボレーションの成果です。主な貢献者である Stoyan Nikolov、Niyati Parameswaran、Bernhard Konrad、Moritz Gronbach、Niket Kumar、Ann Yan、Varun Singh、Yaning Liang、Antoine Baudoux、Xevi Miró Bruix、Daniele Codecasa、Madhura Dudhgaonkar、Elian Dumitru、Alex Ivanov、Christopher Milne-O’Grady、Ahmed Omran、Ivan Petrychenko、Assaf Raman、Stefan Schnabl、Yurun Shen、Maxim Tabachnyk、Niranjan Tulpule、Amin Vahdat、Jeff Zhou に感謝いたします。}

- ドメイン応用 ML / AI / インフラストラクチャプロダクト責任者、Jamie Rogers

- Google Fellow 兼 AI およびインフラストラクチャ担当バイスプレジデント、Parthasarathy Ranganathan

Next ’26: Google Cloud と Wiz が AI 時代のセキュリティを再定義

Mon, 11 May 2026 02:00:00 +0000

aside_block: <ListValue: [StructValue([('title', 'Next ’26 で本日発表した最新情報'), ('body', <wagtail.rich_text.RichText object at 0x7fdf2e3985b0>), ('btn_text', ''), ('href', ''), ('image', None)])]>

※この投稿は米国時間 2026 年 4 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

AI の時代には、セキュリティも新たな時代へと進む必要があります。組織は、AI の可能性を活用すると同時に、その悪用に対抗するという二重の課題に直面しています。Google Cloud は、こうした変化への適応と成長を支援します。

Google Cloud の最新調査によると、攻撃者は AI を利用して、攻撃の速度、規模、巧妙さを高めています。一方、M-Trends 2026 によると、脅威アクター間の連携強化により、初期アクセスからセカンダリ脅威アクターへの引き継ぎに要する時間は、過去 3 年間で 8 時間から 22 秒へと短縮されたことが示されています。

本日開催の Google Cloud Next では、ますます巧妙化する脅威への防御をマシンスピードで実現し、AI とマルチクラウド環境を保護しながら、大規模なクラウドワークロードを安全に運用するための Google Cloud の取り組みをご紹介します。

エージェント型防御の提供

チップからモデルまでをカバーする Google のフルスタック AI アプローチにより、優れた統合性とスピードを実現し、顧客保護を強化するための競争優位性をもたらします。さらに、グローバル規模の脅威モニタリングと Mandiant の最前線の専門家による分析情報に加え、Google DeepMind の最先端のインサイトや技術的ブレークスルーを活用し、お客様のプラットフォームのセキュリティ強化を支援します。

本日 Google は、Google Security Operations に、AI のスピードでの防御を支援する 3 つの新しいエージェントを発表しました。

現在プレビュー提供中の Threat Hunting エージェントは、従来の防御を回避する新たな攻撃パターンや、ステルス性の高い攻撃者の挙動を、チームが先回りして検出できるようにします。
現在プレビュー提供中の Detection Engineering エージェントは、カバレッジギャップを特定し、脅威シナリオに応じた新たな検出機能を生成します。手間のかかる作業を削減し、検出機能の作成を手作業中心の運用から自動化されたプロセスへと刷新します。
近日プレビュー提供予定の Third-Party Context エージェントは、サードパーティコンテンツから得られるコンテキストデータを活用し、ワークフローを強化します。

Threat Hunting エージェントで脅威ハンティングを開始

Triage and Investigation エージェントは、過去 1 年間で 500 万件以上のアラートを処理し、通常 30 分かかる手動分析を、Gemini の活用により 60 秒へ短縮しました。

「運用レジリエンスとサイバーセキュリティは、BBVA におけるお客様からの信頼を支える基盤です。Triage and Investigation エージェントのような高度な AI を導入することで、新たな形で運用を拡張できるようになります」と、BBVA のセキュリティテクノロジー責任者である Diego Martinez Blanco 氏は述べています。

また同氏は、「初期対応に伴う負荷の高い作業を担い、誤検知を取り除くことで、人による判断が必要な問題に優先的に対応できます。さらに、エージェントが判断根拠を明確に示すことで、チームは推奨事項を理解し、より複雑な調査にリソースを集中できるようになります」とも述べています。

Google Security Operations 向けリモート Google Cloud Model Context Protocol (MCP) サーバー対応が一般提供となり、独自のセキュリティエージェントを構築できるようになりました。さらに利便性を高めるため、プレビュー提供中の Google Security Operations のチャットインターフェースから、MCP サーバークライアントへ直接アクセスすることも可能です。

Google Cloud のエージェント型防御を活用し、インテリジェンス主導かつ AI による拡張を取り入れた最新のセキュリティ運用を進める組織は、高い ROI を実現できます。 Christopher Kissel 氏、IDC リサーチ担当バイスプレジデント

Threat Hunting エージェントが作成した検出結果レポート

セキュリティチームは、Google Security Operations のエージェント型自動化を活用することで、対応業務を自動化できます。さらに、チームの手動トリアージからエージェント型防御への移行を進めるため、Google Threat Intelligence にダークウェブインテリジェンスを導入しました。こちらは現在プレビュー提供中です。内部テストによると、この機能は 1 日あたり数百万件の外部イベントを 98% の精度で分析し、真に重要な脅威を優先的に特定できます。

「IDC は、AI を活用したコンテキストと自動化により、組織が平均検出時間と平均対応時間の大幅な短縮、誤検知の減少、アナリストの生産性向上など、定量的に把握できる運用成果を得ていることを明らかにしています。こうした運用上の改善は、業務中断期間の短縮、インシデント関連コストの削減、セキュリティポスチャーや意思決定に対する経営層の信頼感向上など、重要なビジネス成果につながります」と、IDC のリサーチ担当バイスプレジデントである Christopher Kissel 氏は述べています。「Google Cloud のエージェント型防御を活用し、インテリジェンス主導かつ AI による拡張を取り入れた最新のセキュリティ運用を進める組織は、高い ROI を実現できます。」

Google Security Operations の新しいパートナー連携ワークフロー

本日さらに、Google Security Operations 向けの充実した新しいパートナーインテグレーションも発表します。導入後すぐに利用できる高精度なセキュリティワークフローを提供する、Google Cloud Security 統合エコシステムの最新パートナーには、Darktrace、Gigamon、SAP などが含まれます。

あらゆるインフラストラクチャで、AI とクラウドアプリケーションを保護

AI とクラウドアプリケーションは、複数のプラットフォームやモデルにまたがって構築されています。これらをエンドツーエンドで保護するため、構築環境や方法にかかわらず、リスクをより簡単かつ迅速に軽減できるようにします。こうした保護機能は、アマゾンウェブサービス（AWS）、Google Cloud、Microsoft Azure、Oracle Cloud などの主要なクラウド環境に加え、OpenAI などの SaaS（Software as a Service）環境、さらにセルフホスト型の環境にも対応しています。

さらに、Wiz が Google Cloud の一員となったことで、お客様が構築し運用するアプリを保護する機能が拡大し、一段と強化されました。Wiz は、AI を迅速かつ安全な導入を可能にするとともに、AI 開発ライフサイクルの保護も強化します。

Wiz は、RSA Conference で AI-Application Protection Platform（AI-APP）を発表しました。AI アプリケーション向けに、高度な可視化、リスクポスチャーの把握、ランタイム分析が可能になります。また、Wiz Security Agents と Wiz Workflows も発表し、リスクや脅威をマシンスピードで特定し、迅速に対応できるようになりました。

Google は、あらゆるクラウド、プラットフォーム、AI 環境でお客様を保護する体制を一段と強化します。その一環として、Wiz は、Databricks に加えて、AWS Agentcore、Gemini Enterprise Agent Platform、Microsoft Azure Copilot Studio、Salesforce Agentforce などの新しいエージェントスタジオにも対応します。チームがどのプラットフォームを選んで構築しても、お客様は全体の可視性の確保が可能です。

Wiz は Google Cloud Apigee、Cloudflare AI Security for Apps、Vercel プラットフォームなど、クラウドの外側レイヤーとのインテグレーションによってセキュリティエコシステムとの連携を継続し、Wiz Security Graph の適用範囲をさらに拡張しています。また、Google は、Wiz Defend のセキュリティ検出機能と Google Security Operations および Mandiant Threat Defense との連携方法のアップデートにより、アナリストが脅威情報の自動転送をより容易に設定できるようになりました。

さらに、Wiz は、AI ネイティブな開発ライフサイクルを保護し、チームがより迅速かつ安全にイノベーションを進められる新機能も発表しました。

バイブコーディングアプリケーションを保護: Wiz は、5 月に一般提供予定の新しいインテグレーションを発表しました。これにより、Wiz のセキュリティスキャンを Lovable プラットフォーム内で直接実行できるようになります。Wiz が検出した脆弱性、シークレット、設定ミスは、Lovable の組み込みセキュリティビュー上に表示され、チームがすでに開発を進めている環境でそのまま確認することができます。
AI 生成コードの保護: Wiz は、AI 生成コードに含まれるリスクを、生成された瞬間に取り除きます。インライン AI セキュリティフックは、IDE やエージェントワークフローに直接統合され、プロンプトを評価するとともに、AI 生成出力を即座にスキャンします。これにより、コードがコミットされる前にセキュリティガードレールを組み込むことができます。
エージェントベースの修復: Wiz Skills は、コーディングエージェントや AI ネイティブ IDE に、コードからクラウドまでの包括的なコンテキストと、Wiz Security Graph による検証済みの攻撃対象領域に関する検出結果を提供します。この機能により、チームは、デベロッパー個人の IDE 上でも、バージョン管理システム内のリポジトリや pull リクエスト単位でも、エージェント主導の自動修復ワークフローを実行することができます。
シャドー AI の排除: Wiz の動的な AI-Bill of Materials（AI-BOM）は、環境全体に存在するすべての AI フレームワーク、モデル、IDE 拡張機能を自動的にインベントリ化します。これにより、スタック全体でどのツールがコード生成に使われているかを完全に可視化し、Gemini Code Assist や GitHub Copilot などの承認済みツールを管理すると同時に、未承認のシャドー AI プラグインを検出することができます。

Wiz の発表について詳しくは、こちらをご覧ください。

AI エージェントとエージェント型ウェブの保護

クラウドと AI ワークロードを保護するだけでなく、Google Cloud の安全性を重視して設計された基盤は、エージェント、不正対策、ウェブ領域に至るまで、AI 時代のスピードでイノベーションを加速します。

Gemini Enterprise Agent Platform によるエージェントの保護とガバナンスGoogle は本日、エージェントの構築、オーケストレーション、ガバナンス、最適化を支援する、Gemini Enterprise Agent Platform を発表しました。主な内容は次のとおりです。

Agent Identity により、アクセス管理と AI ガバナンスを大規模に実現できます。新機能では、エージェントごとに固有の ID を付与し、特定の認証フローや、ユーザーから範囲を限定して委任された権限のもとで、自律的に動作できるようになります。
Agent Gateway は、すべてのエージェント間接続およびエージェントとツール間の接続に対して、ポリシー適用を実現します。エンタープライズ向けエージェントトラフィックを管理するとともに、MCP や Agent2Agent（A2A）などのエージェントプロトコルに対応し、あらゆるエージェント間インタラクションを検査して保護します。
モデルとエージェントのインタラクションを保護するランタイム保護機能 Model Armor は、Agent Gateway、Agent Runtime、Langchain との統合をプレビュー提供します。Firebase との統合は一般提供となります。デベロッパーはコードを変更することなく、エージェントのトラフィックやインタラクションに対して、インラインでのポリシー適用と無害化処理を行うことができます。これらのインテグレーションにより、プロンプトインジェクション、ツールポイズニング、センシティブデータ漏洩などのランタイムリスクに対する Model Armor の保護範囲が、Google Cloud の各種サービスと AI 製品群全体に広がります。

Google Cloud Fraud Defense と Chrome Enterprise でエージェント型ウェブを保護本日、Google は reCAPTCHA をさらに進化させる新サービスとして、Google Cloud Fraud Defense をリリースしました。本サービスは一般提供されています。この包括的なプラットフォームは、ボット、人間、エージェントが正当な利用主体であり、適切な権限を持っているかどうかを見極められるよう設計されています。さらに、Fraud Defense は Google のエコシステム保護と同等のスケールおよびシグナルを活用し、人間ユーザーと AI エージェント向けの新機能をまもなくプレビュー提供します。これにより、アカウント作成やログインから、支払いやチェックアウトに至るまで、デジタルコマースジャーニー全体の安全性を強化します。

AI の安全性を確保するという Google の取り組みは、AI とのインタラクションに不可欠なエンドポイントであるブラウザにも広がっています。Chrome Enterprise は、企業データを守りながら AI を安全に活用するために必要な可視性とコントロールを提供し、AI 時代に向けた包括的なデータ保護を実現します。

現在プレビュー提供中の AI 拡張機能向け脅威検出機能は、高度な拡張機能テレメトリーを可視化し、セキュリティチームが AI エージェントの異常な挙動を検出し、迅速に対応できるようにします。
まもなく一般提供される新しいシャドー AI レポート機能は、従業員による未承認のウェブベース AI や SaaS アプリケーションの利用を検知することで、シャドー AI の利用実態を可視化できます。

Trusted Cloud の新機能

Google は、お客様の環境を保護するため、クラウドプラットフォーム全体で新たなセキュリティコントロールの提供を続けるとともに、ID、データ、ネットワーク領域にわたる機能強化を進めています。今回は、以下のアップデートをご紹介します。

最新の IAM による権限管理の簡素化最小権限を迅速かつシンプルに実現するため、事前定義ロールのカタログを簡素化し、管理者、編集者、閲覧者などの使いやすいロールに整理しました。あわせて、IAM role picker や機密性の高い操作に対する再認証機能なども提供します。

データセキュリティクラウドプラットフォームのデータセキュリティポートフォリオ向けに、最もセンシティブなデータを保護し、AI による変革を加速する複数の新機能を提供します。

Confidential Computing: NVIDIA とのパートナーシップにより、Google は本日、Confidential Computing の G4 VM 向けサポートを発表しました。Google Compute Engine（GCE）の Confidential G4 VM は、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載し、グローバルでプレビュー提供されます。これにより、機密性の高いさまざまな AI ワークロードにおいて、機密性と完全性を強化します。さらに、Intel とのパートナーシップのもと、Google は C4 Confidential VMs のプレビュー提供も開始します。第 6 世代 Intel Xeon プロセッサに Intel TDX を採用し、業界をリードするコンピューティング密度とパフォーマンスを実現するとともに、さまざまな AI および分析ワークロードを保護します。
Cloud Key Management Services（KMS）: 新たに Confidential External Key Manager（cEKM）をプレビュー提供します。任意のリージョンで外部鍵をホストして保護しながら、機密環境内で検証可能な統制を維持できる柔軟な運用が可能になります。
ポスト量子暗号（PQC）: 新たに KMS Quantum Safe Key Imports をプレビュー提供します。これにより、耐量子アルゴリズムを用いた、お客様独自の鍵を持ち込めるようになります。
Secret Manager: パスワード漏洩防止とプロンプトインジェクションのリスク緩和に向け、Secret Manager と Agent Development Kit のネイティブ統合を一般提供します。

ネットワークセキュリティGoogle Cloud のクロスクラウドネットワークセキュリティ製品群に、複数の新機能を追加します。

Cloud NGFW: 巧みに検知を回避するゼロデイ脅威への防御強化に向け、Cloud NGFWの高度なマルウェアサンドボックスを、今年後半にプレビュー提供します。この機能は、Palo Alto Networks Advanced Wildfire を基盤としており、70,000 社を超える Palo Alto Networks の顧客から得られたデータを基にトレーニングし、既知か未知を問わずマルウェアの 99% を阻止します。
Cloud Armor: Thales Imperva を活用した新しい Cloud Armor マネージドルールをプレビュー提供します。レイヤ 7 のアプリケーション攻撃やゼロデイ CVE（React2Shell など）を検出できます。

SCC で Google Cloud のセキュリティを強化Google Cloud ネイティブのセキュリティソリューションである Security Command Center（SCC）は、Google Cloud 上の従来のアプリケーションと AI アプリケーションの両方を保護するために、クラウドセキュリティのベースラインを確立します。

AI エージェント、モデル、MCP サーバーは、継続的な検出と包括的なリスク分析により、脅威、脆弱性、設定ミスを特定することで保護されます。
SCC は、Google Cloud ワークロードのシャドー AI を把握するために、ランタイムの詳細な可視化を強化します。近日プレビュー提供予定の SCC では、エージェント、Cloud Run または GKE 上でホストされる MCP サーバー、GKE 上で稼働する推論エンドポイントなど、非管理下のエージェント型ワークロードを自動検出し、SCC 上でポスチャー検出結果として表示されます。
強化された Security Command Center Standard ティアは、データセキュリティポスチャー管理、コンプライアンス管理、脆弱性管理、リスク分析を備えています。これにより、Google Cloud のすべてのお客様は追加費用なしで、導入初日から強力なセキュリティ、コンプライアンス、リスク対応体制を確立できます。

次のステップ

Google をセキュリティチームの一員に迎えることで、インテリジェンス主導の AI ネイティブな防御力、安全性を重視して設計されたオープンクラウドの柔軟性、そして自社チームの延長として頼れる、業界屈指の現場経験を持つエキスパートを得られます。

こうした新たなイノベーションと、これから先を守る方法については、セキュリティスポットライトをご覧ください。また、Next ’26 の発表内容についてさらに詳しく知るには、ライブ配信またはオンデマンドで視聴できる多数のセキュリティ関連ブレイクアウトセッションもぜひご覧ください。

- Francis deSouza、Google Cloud COO 兼セキュリティプロダクト担当プレジデント

DevOps × AI Agent Hackathon 2026: AI エージェントを「つくる、まわす、とどける」夏

Fri, 08 May 2026 02:00:00 +0000

生成 AI の活用は、チャットで「答える」段階から、「自律的に実行する」へと急速に進化しています。エンジニアの皆さんも、業務のなかでその変化を肌で感じているのではないでしょうか。

そうした潮流のなかで、グーグル・クラウド・ジャパン合同会社は、ファインディ株式会社主催の、「DevOps × AI Agent Hackathon 2026」に協賛します。賞金総額 200 万円、最終ピッチの舞台は Google 渋谷オフィス（渋谷ストリーム）。エントリー受付がスタートしました。

参加はこちらから

企画から運用までを一気通貫で体験する「つくる、まわす、とどける」3 つのコンセプト

DevOps × AI Agent Hackathon 2026 は、Gemini Enterprise Agent Platform、Gemini などを必須技術として、AI エージェントの企画から開発、デプロイ、運用までを一貫して体験できるハッカソンです。単なるプロトタイピングにとどまらず、実運用を見据えた DevOps のプロセス全体をカバーします。

このハッカソンの背骨にしているのが、3 つの動詞です。

つくる。Google の AI、Gemini を中核に、実務で役立つ独創的な AI エージェントを設計・実装します。アイデアの面白さだけでなく、エージェントとしての必然性、自律的に判断しタスクを実行する設計まで踏み込んで評価します。

まわす。CI/CD など DevOps のフローを構築し、AI を継続的に改善するサイクルを参加者自身が回します。机上の理論ではなく、実装して動かしてみる。これが意外と、ハッカソンでは新鮮な経験になるはずです。

とどける。Google Cloud へのデプロイを通じて、スケーラブルな環境で本番品質のプロダクトをユーザーに届けます。動くものをつくる、ではなく、届くものをつくる。そこまでをゴールに置いています。

チームビルディング、Bootcamp、審査員フィードバック ― 学びを底上げする 3 つの仕掛け

「いきなり AI エージェントの実運用まで」と聞くとハードルが高そうに感じるかもしれません。そう感じた方も心配いりません。学びを支える仕組みを 3 つ用意しています。

1 つ目はチームビルディングイベントの開催。チーム開発を経験したい個人参加者向けに、2026 年 6 月 7 日（日）にチームビルディングイベントが実施されます。個人、チームでのワークショップを通して、アイデアの発散からチームづくりまでをサポートします。「気になるけれど 1 人だと不安」という方は、ここを最初の一歩にしてみてください。

2 つ目は Bootcamp。グーグル・クラウド・ジャパンは、6 月 1 日（月）〜 6 月 12 日（金）まで「Agentic AI Bootcamp 2026」と題し、実践的なオンラインハンズオンセミナーを開催します。（無料受講・事前申込制）。Agent Development Kit (ADK)、Gemini Enterprise Agent Platform、Cloud Run、Gemini API など、ハッカソン本番で使う技術をハンズオンで身につけ、参加者全員のベースラインを引き上げます。

登録はこちらから

3 つ目は審査員によるフィードバック。AI エージェント開発およびその周辺領域で実績を持つエンジニアが、提出作品に具体的なフィードバックを行います。さらに、9 月開催予定のアフターイベント（オンライン）では、惜しくも入賞には至らなかったものの、優れた着想や技術が光る「審査員の推し作品」を取り上げ、その魅力や工夫をたたえます。

ハッカソンに挑むみなさんへ

AI エージェントは、エンジニアにとっての遊び道具にも、業務の主役にもなり得るテクノロジーです。AI エージェントが業務の中心へと進んでいくいまこそ、企画から運用まで一気通貫で挑める場が必要だと考えています。このハッカソンが、腕試しの場であり、新しい仲間と出会う場であり、そしてキャリアのなかで記憶に残る夏になることを願っています。「つくる、まわす、とどける」という 3 つの動詞を、皆さんならどう実装するのか。本ハッカソンを通じて、AI エージェントを本番環境へ展開するまでの一連のイメージを、皆さんが具体的につかんでいただければと思います。

エージェントを強化する: Google 公式 Skills リポジトリを発表

Mon, 27 Apr 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 4 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

AI モデルの性能向上に伴い、Firebase や Gemini API、BigQuery、GKE などの Google Cloud プロダクトを活用した開発にエージェント型 AI ツールを取り入れる技術者が増えています。では、こうしたテクノロジーに関する正確かつ最新の情報を、モデルにどのように与えればよいのでしょうか。

その方法の一つが、AI エージェントを、グラウンディングされたリアルタイム情報源に接続することです。たとえば Google は、デベロッパー向けドキュメント用の Model Context Protocol（MCP）サーバーを提供しています。ただし、MCP サーバーを過度に利用すると、「コンテキストの肥大化」と呼ばれる問題が生じることがあります。大量のコンテキストがコンテキストウィンドウに読み込まれることで、モデルが混乱し、トークンコストもかさんでしまうのです。

そこで必要になるのが、エージェントに追加の、しかも凝縮された専門知識を持たせる仕組みです。それを実現するのが Agent Skills（エージェントスキル）です。

スキルとは、「エージェントに新たな機能と専門知識を与えるための、シンプルでオープンな形式」です。特定のテクノロジーやタスクについて、エージェント向けに最適化された簡潔なドキュメントだと考えると分かりやすいでしょう。スキルは Markdown で記述され、参照ファイル、コードスニペット、そのほかのアセットを含めることができます。エージェントは必要なときにだけスキル情報を読み込むため、コンテキストの肥大化を抑えられます。

そして、Google Cloud Next 2026 の初日に、Google 公式の Agent Skills リポジトリの公開を発表いたしました。

github.com/google/skills

このリポジトリは、Google Cloud テクノロジーに特化した 13 のスキルからスタートします。

対応プロダクト: AlloyDB、BigQuery、Cloud Run、Cloud SQL、Firebase、Gemini API、Google Kubernetes Engine（GKE）
Well-Architected の柱うち 3 つに対応したスキル: セキュリティ、信頼性、コスト最適化
Google Cloud のオンボーディング、認証、ネットワークオブザーバビリティ向けの「レシピ」スキル

npx skills install github.com/google/skills を実行すると、Antigravity、Gemini CLI、サードパーティのエージェントなど、任意のエージェントにこれらのスキルをインストールできます。

このリポジトリには、今後数週間から数か月にかけて、さらに多くのスキルを追加していく予定です。続報をお待ちください。

それでは、さっそく構築を始めましょう。

- Google Cloud、シニアスタッフデベロッパーアドボケイト Megan O'Keefe

次世代のエージェントを推進する Gemini Enterprise Agent Platform を発表

Wed, 22 Apr 2026 03:49:00 +0000

※この投稿は米国時間 2026 年 4 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

生成 AI の黎明期において、安全で信頼性の高いビジネスツールを構築するには、膨大なエンジニアリングリソースと、試行錯誤に対する高い許容度が必要でした。私たちは、AI 開発プラットフォームである Vertex AI を通じて、こうした課題の解決を支援してきました。しかし現在、新たな段階の複雑さが課題となっています。AI エージェントが複数のシステム間で相互作用する中で、セキュリティやガバナンスのガードレールが十分に整備されないまま運用が行われているのが現状です。

AI エージェントがチームの一員として独立性と信頼性を持って行動できる真の自律的エンタープライズへと進化するためには、信頼性を維持できる強固な基盤が必要です。

新機能のご紹介：本日、AI エージェントの構築、スケーリング、ガバナンス、最適化を支援する、新しい包括的なプラットフォーム Gemini Enterprise Agent Platform を発表します。本プラットフォームは、Vertex AI の進化形であり、多くのお客様から高く評価されているモデルの選択、構築、エージェントの構築機能に加え、エージェントの統合、DevOps、オーケストレーション、セキュリティに関する新機能を統合しています。

Gemini Enterprise Agent Platform は、技術チームが製品、サービス、運用を変革する AI エージェントを構築するためのワンストップの拠点となります。これらのエージェントは、Gemini Enterprise appを通じて従業員にシームレスに提供され、IT 運用と緊密に統合することで、拡張する際にも、制御、ガバナンス、セキュリティの確保を支援します。

このプラットフォームは Model Garden を通じて、200 以上の主要なモデルへのアクセスを提供します。Gemini 3.1 Pro、Gemini 3.1 Flash Image、Lyria 3 を含む最新のファーストパーティ製モデルに加え、Gemma 4 などのオープンモデル、また、Anthropic の Claude Opus、Sonnet、Haiku といったサードパーティ製モデルもサポートしており、お客様は業務要件に合わせて最適なモデルを柔軟に選択できます。

今後、次世代のエージェント開発を推進するため、すべての Vertex AI のサービスとロードマップの拡充は、スタンドアロンのサービスとしてではなく、Gemini Enterprise Agent Platform を通じて一元的に提供されます。

Gemini Enterprise Agent Platform がビジネスにもたらす価値：Gemini Enterprise Agent Platform は、個々の AI タスクの管理から、信頼に基づいたビジネス成果の創出への移行を支援します。

構築：新しい Agent Studio のローコードで直感的なインターフェースから、アップグレードされた Agent Development Kit（ADK）のコードファーストのロジックまで、業務に最適な環境を選択できます。AI ネイティブなコーディング機能により、開発ライフサイクル全体を簡素化し、本番グレードのエージェントの迅速なリリースを支援します。
拡張：再設計された Agent Runtime により、本番環境への円滑なデプロイを実現します。数日間にわたって状態を維持する長時間実行型のエージェントをサポートし、永続的かつ長期的なコンテキストを保持する Memory Bank によって支えられています。
ガバナンス：Agent Identity、Agent Registry、Agent Gateway により、一元的な管理体制を確立します。これらの機能により、Gemini Enterprise Agent Platform 上で構築されたエージェントから、パートナーエコシステムのエージェントまで、すべてのエージェントが追跡可能な ID を持ち、エンタープライズグレードのガードレール内で動作することを支援します。
最適化：Agent Simulation、Agent Evaluation、Agent Observability により、品質を保証します。これらのツールは、完全な実行トレースとエージェントの推論に対するリアルタイムな可視性を提供し、エージェントが常に目標を達成できるよう支援します。

Gemini Enterprise Agent Platform を使い始めましょう：Google Cloud コンソールの Gemini Enterprise Agent Platform にアクセスして、新機能をお試しいただき、今すぐ構築を開始できます。

最新リリースの詳細や、Gemini Enterprise Agent Platform があらゆる段階で信頼できる本番環境対応エージェントの実現をどのように支援するかについては、以下をご覧ください。

お客様が Gemini Enterprise Agent Platform で実現していること

「Burns & McDonnell では Gemini Enterprise Agent Platform を使用し、組織の知識を企業全体に適用する方法を変革しています。ADK を活用することで、数十年にわたるプロジェクトデータをリアルタイムで実用的なインテリジェンスに変換する AI エージェントを構築しています。Gemini Enterprise Agent Platform は、確定的なビジネスルールと確率的な推論を組み合わせることで、このイノベーションを責任ある形でスケーリングできます。これにより、AI は単なる生産性向上ツールではなく、信頼できる運用機能となります。Gemini Enterprise Agent Platform により、私たちは単に知識を管理するのではなく、経験を活性化させることで、より迅速で自信を持った意思決定を推進しています。」Burns & McDonnell、チーフイノベーションオフィサー、Matt Olson 氏

「Color Health では、エンドツーエンドのケアを提供する Virtual Cancer Clinic を Gemini Enterprise Agent Platform で強化しています。Color Assistant を Agent Development Kit（ADK）で構築し、Agent Runtime を介してスケーリングすることで、より多くの女性が乳がん検診を受けられるよう支援しています。Color Assistant は、ユーザーに検診の適格性を確認するよう促し、臨床医に繋ぎ、予約をサポートします。このエージェントの強みはそのスケーラビリティにあり、より多くの人々にリーチし、個々のリスクや適格性にリアルタイムで対応することを可能にします。」

Color、AI プラットフォーム責任者、PhD.、Jayodita Sanghvi 氏

「Comcast の Xfinity Assistant を Agent Development Kit（ADK）で再構築したことで、単純なスクリプト型の自動化を超え、パーソナライズされたトラブルシューティングやセルフサービスサポートを顧客に提供する、対話型の生成インテリジェンスへと進化しました。Agent Runtime は Gemini を介した安全でグラウンディングされたやり取りを確実にしつつ、デジタルコンテインメントを向上させる高度なマルチエージェントアーキテクチャの展開を加速しています。私たちは、顧客の問題を初回で解決して再度の問い合わせを減らすだけでなく、顧客体験を大規模に再定義しています。」

Comcast、コネクティビティ＆プラットフォーム、チーフテクニカルオフィサー、Rick Rioboli 氏

「Geotab では、AI Agent Center of Excellence の急速な加速に Gemini Enterprise Agent Platform を活用しています。Google の Agent Development Kit（ADK）は、単一のガバナンスされた本番環境への経路のもとで、さまざまなフレームワークを運用できる柔軟性を提供します。同時に、構築、テスト、デプロイのサイクルを大幅に短縮する卓越した開発者体験を提供しています。Geotab にとって ADK は、エージェンティック AI ソリューションを企業全体で迅速かつ安全に拡張するための基盤です。」

Geotab、データ＆アナリティクス担当副社長、Mike Branch 氏

「ぐるなびでは Gemini Enterprise Agent Platform を活用し、AI 飲食店探索アプリ『UMAME!』を開発しており、ユーザーのコンテキストを深く理解するために Memory Bank を活用しています。従来のプロンプトベースのシステムとは異なり、エージェントはユーザーの過去の行動や好みを記憶し、最適な選択肢を積極的に提示します。これにより手動検索の手間が不要となり、ユーザー満足度を 30% 以上向上させるシームレスな体験を生み出します。私たちは、このメモリ機能が新しい食体験の未来にとって不可欠な機能であると考えています。」

株式会社ぐるなび、CTO、岩本俊明氏

「L'Oréal において Beauty Tech は単なるサポート機能ではなく、世界を動かす美を創造するための強力な原動力です。この目標を実現するため、L'Oréal は Google Cloud を基盤とした独自の Beauty Tech Agentic Platform を構築しています。Agent Development Kit（ADK）を活用し、決定論的なワークフローの自動化から、自律的な成果志向のエージェント運用への根本的な転換を推進しています。エージェントは、孤立した存在ではなく、Model Context Protocol（MCP）を通じて Beauty Tech Data Platform や主要な業務アプリケーションを含む、信頼できる企業の実体に安全に接続されています。Google Cloud は、人間による監視を中心に据えながら、このプラットフォームをグローバルに拡張するために必要なレジリエンス、マルチ LLM の柔軟性、エンタープライズグレードの信頼フレームワークを提供してくれます。」

L'Oréal、グループ CIO、Etienne BERTIN 氏

「Payhawk では、Gemini Enterprise Agent Platform を使用して AI エージェントを単純なタスク実行者から真の財務アシスタントへと変革しています。Memory Bank を活用することで、ステートレスな対話から長期的なコンテキストの保持へと移行しました。私たちのエージェントは専任のチームメンバーのように、ユーザー固有の制約や履歴を自律的に記憶します。例えば、Financial Controller Agent はユーザーの習慣を記憶して経費を自動提出するため、提出までにかかる時間を 50% 以上削減しています。この変化により、エージェントはプロンプトに反応するだけでなく、過去の行動に基づいてニーズを予測できるようになります。」

Payhawk、プリンシパルアプライド AI エンジニア、Diyan Bogdanov 氏

「PayPal では、Gemini Enterprise Agent Platform を使用してエージェントを迅速に構築し、本番環境にデプロイしています。具体的には、Agent Development Kit（ADK）と視覚的なツールを使用してエージェントの相互作用を検査し、マルチエージェントワークフローを管理しています。これにより、インテントと支払い権限のフローの段階的な可視性が得られます。Gemini Enterprise Agent Platform 上の Agent Payment Protocol（AP2）は、信頼できるエージェント決済のための重要な基盤となり、私たちのエコシステムが安全なエージェントベースのコマース体験を迅速に提供できるよう支援します。」

PayPal、AI プリンシパルエンジニア、Nitin Sharma 氏

AI エージェントの構築

開発者からビジネスユーザー、さらにはその中間に位置するあらゆるユーザーが、AI エージェントを大規模に構築し、デプロイできるよう支援することで、迅速かつ容易な AI エージェント作成を支援します。

よりスマートなエージェントを、より迅速に構築

ADK の大幅なアップグレード：Gemini モデルでは、ADK を通じて毎月 6 兆以上のトークンが処理されています。エージェントをサブエージェントのネットワークとして組織化することで、より高度な推論機能を実現します。この新しいグラフベースのフレームワークにより、エージェントが連携して複雑な問題を解決するための、明確で信頼性の高いロジックを定義できます。
セキュリティバイデザインのワークスペース：コアシステムから分離され、bash コマンドの実行やファイルの安全な管理を許可する、強化されたサンドボックス環境をエージェントに提供します。
マルチモーダルストリーミング：ライブ音声や映像キューに対するマルチモーダルサポートにより、リアルタイムの対話において人間に近い安定性をもたらします。

エージェントをエンタープライズに接続

あらゆるシステムへの安全なアクセス：Native Ecosystem Integrations によるプラグアンドプレイアーキテクチャを使用し、カスタムコーディングなしでエージェントを社内データやツールに接続します。
バックグラウンド運用の自動化：バッチ＆イベント駆動型エージェントにより、BigQuery や Pub/Sub のデータを活性化させます。これにより、コンテンツ評価やデータ分析などの大規模な非同期タスクをバックグラウンドで実行できます。

アイデアから本番環境へ数時間で

AI ドリブン開発の実現：エージェントが Google の包括的なエージェント機能群にアクセスするためのプログラマティックインターフェースを提供し、ユーザーに代わって本番環境対応エージェントの構築、評価、デプロイを行えるようにします。
Agent Studio で直接エージェント構築が可能に：Agent Studio 内で、シンプルなプロンプトの作成から複雑なエージェントのデプロイまでをシームレスに移行できるようになりました。高度なカスタマイズが必要になった場合は、ロジックを直接 ADK にエクスポートし、フルコード環境で開発を継続できます。
構築済みのエージェントによる迅速な開始：Agent Garden で厳選されたエージェントテンプレートにアクセスできます。これにはコードのモダナイゼーション、財務分析、経済調査、請求書処理などが含まれており、マルチエージェントシステムの即時構築要素として活用できます。

AI エージェントの拡張

概念実証（PoC）からライブ環境へ移行するには、実際の業務におけるパフォーマンス、状態管理、セキュリティ要件に対応できるプラットフォームが必要です。

高性能なエージェント実行の推進

最新の Agent Runtime：刷新された Agent Runtime は、1 秒未満のコールドスタートを実現し、新しいエージェントを数秒でプロビジョニングできます。
数日間にわたるワークフローのサポート：数日間にわたって自律的に実行される長時間実行型エージェントをデプロイできるようになりました。これにより、営業のプロスペクティングシーケンスの管理など、長期的な持続性を必要とする複雑な多段階ワークフローや深い推論タスクをエージェントが管理できるようになります。
セキュリティバイデザイン環境での自律アクション：Agent Sandbox は、モデルが生成したコードを安全に実行し、ホストシステムにリスクを与えることなくブラウザベースの自動化などのコンピュータユースタスクを実行するための強化された環境を提供します。
エージェント間のオーケストレーション：エージェントが複雑で、生成型、および確定的な運用パターンのサポートを含め、互いにシームレスにタスクを委譲できるようにします。これにより、コンプライアンスなどの重要なフローにおいて、エージェントは常に規定の経路に従います。

一時的なセッションデータを超えた、高精度なコンテキストの実現

インタラクションのパーソナライズ：Agent Memory Bank は、会話から長期的な記憶を動的に生成し、管理します。新しい Memory Profiles を使用することで、エージェントは低レイテンシで高精度な詳細情報を想起でき、コンテキストが失われることはありません。
AI の対話と既存レコードの連携：Agent Sessions を使用して履歴を保存、管理します。Custom Session IDs により、独自の識別子を使用してセッションを追跡し、社内データベースや CRM レコードに直接マッピングできます。
リアルタイムで人間のような対話を実現：Bidirectional Streaming 向けの WebSocket プロトコルを使用することで、顧客や従業員とのリアルタイムのやり取りにおいてエージェントの応答性を高め、遅延なく音声や映像を処理できるよう支援します。

AI エージェントのガバナンス

Gemini Enterprise Agent Platform 上で構築されたものからパートナーエコシステムから提供されたものまで、組織内のあらゆるエージェントにエンタープライズグレードの厳格さを適用する、セキュリティバイデザインアーキテクチャでガバナンスを実現します。

ID およびアクセス管理に関する信頼できる企業の実体を通じて、すべてのエージェントを一元管理します。

すべてのエージェントに検証可能な ID を付与：Agent Identity は、すべてのエージェントに固有の暗号化 ID を付与することで、エージェントのセキュリティ体制を向上させます。これにより、エージェントが行うすべての操作について、定義された認可ポリシーに紐付いた、明確で監査可能なトレースを作成します。
承認済みツールの一元ライブラリを維持：新しい Agent Registry は、信頼できる企業の実体を提供します。すべての社内エージェント、ツール、スキルをインデックス化することで、検索を簡素化し、ガバナンスおよび承認された資産のみをユーザーが利用できるようにします。
単一の制御ポイントからエージェント群を管理：Agent Gateway は、エージェントエコシステムにおける管制塔のような役割を果たします。あらゆる環境におけるエージェントとツールの間に安全で統合された接続性を提供すると同時に、一貫したセキュリティポリシーとプロンプトインジェクションやデータ漏洩から保護する Model Armor の適用を徹底します。

AI を活用したインサイトを活用し、ビジネスに影響が出る前に潜在的リスクや不審な挙動を検知

不審な挙動をリアルタイムで検知：Agent Anomaly Detection は、統計モデルと LLM-as-a-judge フレームワークを使用して、異常な推論にフラグを立てます。これは Agent Threat Detection と連携して、リバースシェルや既知の不正な IP アドレスへの接続といった悪意のある活動を可視化します。
脆弱性の自動発見：Security Command Center を基盤とした新しい Agent Security ダッシュボードが、脅威検知とリスク分析を統合します。これにより、チームはエージェントとモデル間の関係のマッピング、アセット検出の自動化、基盤となるオペレーティングシステムや言語パッケージの脆弱性スキャンを行えるようになります。

AI エージェントの最適化

Gemini Enterprise Agent Platform は、AI のパフォーマンスを把握するために必要な可視性を提供し、ロジックの改善や継続的な学習を容易にします。

リリース前のエージェントのテスト

リアルな会話をシミュレート：Agent Simulation を使用し、制御された環境下で、人間のような合成ユーザーインタラクションや仮想化されたツールに対してエージェントをテストします。エージェントは、多段階の会話全体にわたるタスクの成功率と安全性に基づいて自動的にスコアリングされます。

本番環境での監視と改善

ライブパフォーマンスの追跡：Agent Evaluation を使用し、単一の応答だけでなく会話全体のロジックを評価できるマルチターン自動評価機能を用いて、実際のトラフィックに対してエージェントを継続的にスコアリングします。すぐに利用可能なダッシュボードと Agent Observability により、複雑な推論を視覚的にトレースし、問題が発生した際にデバッグできます。
エージェントの改善を自動化：ログを手動で調査する代わりに、Agent Optimizer が実際の失敗を自動的にクラスタリングし、精度を向上させるための洗練されたシステム指示を提案します。

詳細なテクニカルガイドおよびアップデートの完全なリストは、更新されたドキュメントとリリースノートでご確認いただけます。Gemini Enterprise Agent Platform は、実験段階から本番規模でのインパクトへと移行するための、エンタープライズエージェント開発の新しい標準です。

BigQuery、Pub/Sub、ADK を使用したイベントドリブンデータエージェントの構築

Tue, 21 Apr 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 4 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

リアルタイムの自律エージェントの必要性

データは、それに基づいて行動できる能力があってこそ価値を発揮します。現代の企業では、イベントが発生してから数時間、あるいは数分後に対応しても、手遅れになることがよくあります。金融詐欺や流動的なサプライチェーンの混乱に対処する場合も、一分一秒が重要になります。

しかし、多くのシステムは依然として、処理の遅いスケジュールされたバッチジョブや、変更を pull し続ける脆弱なマイクロサービスに依存しています。問題が表面化したときには、手遅れになっていることがよくあります。そのため、人間の調査担当者は、ログやデータベースクエリを掘り下げて情報をかき集め、それらをつなぎ合わせる作業に追われることになります。時間がかかり、骨の折れるプロセスで、スケーラビリティもありません。

イベントドリブンデータエージェントの登場

時間のかかるパイプラインや手動のトリアージを待つ代わりに、データプラットフォームが異常を検出するとすぐにアラートを push し、自律型 AI エージェントが調査して解決してくれるとしたらどうでしょうか。

これがイベントドリブンデータエージェント アーキテクチャのメリットです。BigQuery の継続的クエリ、Pub/Sub、Vertex AI Agent Engine 上の ADK エージェントを組み合わせることで、イベントをリアルタイムでトリアージして自律的に調査するパイプラインを構築できます。エージェントは高度な推論を使用してコンテキストを収集し、データを分析して、問題をその場で解決するか、人間参加型の介入が必要な場合は担当者にエスカレーションします。

ハイブリッドアーキテクチャ: 仕組み

このイベントドリブンパイプラインは、次の 3 つの主要な構成要素を活用します。

検出: BigQuery の継続的クエリは、ライブデータストリームをモニタリングし、ルールベースのエンジンを使用して異常を検出します。
ルーティング: Pub/Sub は、単一メッセージ変換（SMT）を使用してペイロードを AI エージェントが期待する正確な形式に再形成し、これらのイベントを確実に配信します。これにより、エージェントパイプラインがトリガーされ、調査が開始されます。
解決: Vertex AI エージェント（ADK で構築）がイベントを受信し、カスタムツールを使用して調査し、意思決定をログに記録します。

各コンポーネントについて詳しく見ていきましょう。具体例として、不正な金融取引をリアルタイムで検出および調査するという、シンプルなユースケースをご紹介します。

パート 1: BigQuery の継続的クエリ

BigQuery の継続的クエリでは、標準 SQL を使用してリアルタイムのイベントストリームをネイティブに構築できます。これらは、継続的に実行される永続的な SQL クエリです。受信データを分析し、SQL の結果を Pub/Sub などの宛先に即座にエクスポートします。

BigQuery でストリーミングイベントを pull 型からネイティブな push 型へと移行することで、標準 SQL を使用してデータウェアハウス内で複雑な異常（ユーザーが指定した期間内に 2 つの異なる国で取引を行うなど）を検出できます。データを別のストリーミング分析エンジンに移動する必要はありません。

この変革は、BigQuery 継続的クエリのステートフルデータ処理の公開プレビュー版のリリースによって実現しました。これにより、ストリーム間の JOIN、ウィンドウ集計、タンブリングウィンドウのネイティブサポートが導入されます。BigQuery で分散したデータストリームを関連付け、移動平均や総計などの複雑な指標を直接計算できるようにすることで、あらゆる SQL ユーザーがストリーム処理を行えるよう、その民主化を推進しています。その結果、イベントの発生を検知して即座に対応するリアルタイムの「アクションシステム」を構築するために、専門の外部ツールや高度なデータサイエンスの専門知識は必要なくなります。このアプローチは、LLM トークンの費用管理にも役立ちます。ステートフル SQL を使用して特定の異常をフィルタリングすることで、エージェントが元データに圧倒されることなく、まさに必要なコンテキストのみを処理できるようになります。

この実装は簡単です。標準 SQL クエリと EXPORT DATA ステートメントを組み合わせることで、一致する行が発生した瞬間に、その行を Pub/Sub トピックに直接ルーティングできます。

code_block: <ListValue: [StructValue([('code', 'EXPORT DATA OPTIONS (\r\n format = "CLOUD_PUBSUB",\r\n uri = "https://pubsub.googleapis.com/projects/YOUR_PROJECT_ID/topics/cymbal-bank-escalations-topic"\r\n) AS (\r\n WITH TransactionHeuristics AS (\r\n SELECT\r\n *,\r\n _CHANGE_TIMESTAMP AS bq_changed_ts,\r\n FROM APPENDS(TABLE `cymbal_bank.retail_transactions`, CURRENT_TIMESTAMP() - INTERVAL 10 MINUTE)\r\n )\r\n SELECT\r\n TO_JSON_STRING(STRUCT(\r\n window_end,\r\n user_id,\r\n COUNT(*) AS tx_count,\r\n SUM(amount) AS total_window_spend,\r\n MAX_BY(merchant_name, amount) AS highest_value_merchant,\r\n MAX_BY(merchant_category_code, amount) AS highest_value_mcc,\r\n 100 AS final_risk_score,\r\n STRUCT(\r\n APPROX_COUNT_DISTINCT(location_country) > 1 AS is_impossible_travel,\r\n LOGICAL_OR(NOT is_trusted_device) AS has_security_mismatch\r\n ) AS logic_signals\r\n )) AS data\r\n FROM TUMBLE(TABLE TransactionHeuristics, "bq_changed_ts", INTERVAL 2 MINUTE)\r\n GROUP BY window_start, window_end, user_id\r\n HAVING APPROX_COUNT_DISTINCT(location_country) > 1\r\n);'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2e031eb0>)])]>

パート 2: Pub/Sub と単一メッセージ変換（SMT）

Pub/Sub でスキーマのギャップを埋める。継続的クエリからエクスポートされたイベントデータは、Pub/Sub トピックに直接送信されます。この元データを AI エージェントが使用できるようにするには、エージェントが想定するスキーマに合わせてペイロードを変換する必要があります。

専用の Cloud Functions などをデプロイしてこれらのメッセージを再フォーマットする代わりに、単一メッセージ変換（SMT）を使用して Pub/Sub サブスクリプション内だけで完結させることができます。SMT を使用すると、軽量なインライン JavaScript ユーザー定義関数（UDF）を Pub/Sub 内で直接実行して、ペイロードをその場でマッピング、再形成、クリーンアップできます。

たとえば、BigQuery ペイロードをインターセプトし、Agent Engine が想定する正確なクエリ形式を抽出する JavaScript スニペットを記述した transform.yaml を定義できます。

code_block: <ListValue: [StructValue([('code', 'function process(res) {\r\n let bq_payload = JSON.parse(res.message.data);\r\n res.message.data = JSON.stringify({"query": bq_payload});\r\n return res;\r\n}'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2e031610>)])]>

ルーティングパイプラインを構成するには、Pub/Sub push サブスクリプションを作成します。このサブスクリプションは、変換されたすべての BigQuery イベントを AI エージェントの Webhook エンドポイントへ、自動的に直接 push します。

code_block: <ListValue: [StructValue([('code', 'gcloud pubsub subscriptions create cymbal-bank-escalations-sub \\\r\n --topic=projects/$PROJECT_ID/topics/cymbal-bank-escalations-topic \\\r\n --message-transforms-file=setup/transform.yaml \\\r\n --push-endpoint="https://YOUR_AGENT_WEBHOOK_URL" \r\n --push-no-wrapper \\\r\n --ack-deadline=600 \\\r\n --push-auth-service-account="adk-agent-sa@$PROJECT_ID.iam.gserviceaccount.com"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2e031130>)])]>

上記の push-endpoint パラメータに注目してください。この Webhook URL は、アーキテクチャの最後の部分である AI エージェント自体によって生成されます。

パート 3: ADK と Vertex AI Agent Engine

エージェントが Vertex AI Agent Engine にデプロイされると、プラットフォームは、これらの受信イベントを受け取るために特別に設計された安全な streamQuery エンドポイントを自動的にプロビジョニングします。

これはオペレーションの頭脳です。異常が検出され、Pub/Sub 経由でルーティングされると、Vertex AI にデプロイされた ADK エージェントがメッセージによってトリガーされます。

推論ループを実装するには、ツールを備えたエージェントを定義してデプロイします。

code_block: <ListValue: [StructValue([('code', 'investigation_agent = Agent(\r\n model="gemini-2.5-flash",\r\n name="fraud_investigation_agent",\r\n description="Expert fraud analyst agent that autonomously investigates alerts...",\r\n instruction=(\r\n "You are an expert fraud investigator for Cymbal Bank. "\r\n "Your goal is to investigate financial transaction alerts, "\r\n "determine if they are fraudulent, and take appropriate action. "\r\n "Use the BigQuery toolset to analyze data in the transactions table.."\r\n "Use the Google Search toolset to search for the merchant..."\r\n "Conslidate your findings and use the escalate_to_human tool if required..."\r\n ),\r\n tools=[\r\n bigquery_toolset,\r\n google_search,\r\n ],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2e031580>)])]>

具体的な指示とこのカスタムツールセットを装備したエージェントは、外部のコンテキストを積極的に収集することでアラートを自律的に調査します。BigQuery にクエリを実行してユーザーの取引履歴を取得したり、領収書などの非構造化データを分析したり、Google 検索で調査結果をグラウンディングして販売者の評判を確認したりできます。最終的には、その取引を FALSE_POSITIVE として分類するか、ESCALATION_NEEDED としてフラグを立てます。

人間参加型のメリット

このアプローチは、アーキテクチャのスケーラビリティの中核をなすものです。ノイズを効果的にフィルタリングすることで、運用上のオーバーヘッドを大幅に削減し、調査担当者が最も複雑なケースにのみ時間を費やせるようにします。ADK は豊富なツールとインテグレーションを提供しているため、エージェントはイベントを幅広いエンタープライズシステムにエスカレーションできます。これにより、人間参加型（Human-in-the-loop）のエンゲージメントを実現できるほか、人間監視型（Human-on-the-loop）オブザーバビリティを使用してパイプラインをエンドツーエンドで自動化することもできます。

すべてを 1 つに: エージェント分析

パイプラインが稼働したら、作業は構築からモニタリングに移行します。従来型のソフトウェアとは異なり、自律エージェントはバックグラウンドで永続的に実行されます。バックグラウンドで動作するため、何を行っているか、どのくらいの時間がかかっているか、どのくらいの費用がかかっているかを詳細に把握できることが重要です。

デプロイ時に BigQuery Agent Analytics プラグインを初期化することで、ADK はすべてのトレースデータ、ツールの使用状況、実行レイテンシを BigQuery に直接自動的に記録します。

このトレースデータをエージェントが出力した構造化された意思決定と結合することで、高度な分析が可能になります。これにより、動的なダッシュボードを構築し、カスタムアラートを設定して、AI ワークフォースをリアルタイムでモニタリングできるようになります。エージェント分析プラグインの使用方法について詳しくは、こちらの Codelab をご覧ください。

まとめ

リアルタイムデータストリーミングとエージェント型 AI の融合により、運用上のアラートの処理方法が変わろうとしています。

BigQuery の継続的クエリを使用してリアルタイムで検出する。
Pub/Sub SMT を使用して変換とルーティングを行う。
Vertex AI Agent Engine を使用して調査し、解決する。
BigQuery Agent Analytics プラグインを使用して分析する。

このアーキテクチャにより、ガバナンスが効いたスケーラブルなサーバーレスの Google Cloud 環境内で、異常が発生した瞬間に対応できる、プロアクティブで自律的なワークフォースを構築できます。

実際に使ってみる準備はできましたか？

Codelab では、この Cymbal Bank パイプラインをゼロから構築する方法を段階的に説明しています。

- Google、デベロッパーアドボケイト、Rachael Deacon-Smith

- BigQuery プロダクトマネージャー、Nick Orlove

Google Cloud のアプリケーションロードバランサへの移行: 実践ガイド

Tue, 21 Apr 2026 01:10:00 +0000

※この投稿は米国時間 2026 年 4 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

既存のアプリケーションロードバランサインフラストラクチャをオンプレミスのハードウェアソリューションから Cloud Load Balancing に移行すると、スケーラビリティと費用効率が大幅に向上し、Google Cloud エコシステム内での緊密な統合が実現します。しかし、多くの場合、「現在のロードバランサ構成はどうなるのか」という根本的な疑問も生じます。

既存のオンプレミスロードバランサの構成には、トラフィック操作のためのビジネスクリティカルなロジックが何年分も蓄積されていることがよくあります。こうした既存の機能は完全に移行できます。加えて、この移行は、トラフィック管理をモダナイズして簡素化する絶好の機会にもなります。

このガイドでは、既存のロードバランサを Google Cloud のアプリケーションロードバランサに移行するための実践的なアプローチを紹介します。このアプローチでは、一般的な機能に対応するために、宣言型構成と革新的なイベントドリブン型 Service Extensions エッジコンピューティング機能の両方を活用します。

シンプルで段階的な移行アプローチ

命令型のスクリプトベースシステムからクラウドネイティブな宣言型ファーストモデルへの移行には、体系的な計画が必要です。そこで、4 つのフェーズからなるシンプルなアプローチをおすすめします。

フェーズ 1: 調査とマッピング

移行を開始する前に、現状を把握する必要があります。現在のロードバランサの構成を分析して分類しましょう。各ルールの意図は何ですか？単純な HTTP から HTTPS へのリダイレクトを行っていますか？HTTP ヘッダーの操作（追加または削除）に関与していますか？それとも、複雑なカスタム認証ロジックを扱っていますか？

ほとんどの構成は、次の 2 つの主なカテゴリに分類されます。

一般的なパターン: リダイレクト、URL の書き換え、基本的なヘッダー操作、IP ベースのアクセス制御リスト（ACL）など、ほとんどのウェブアプリケーションに共通するロジック。
カスタムビジネスロジック: カスタムの独自トークン認証、高度なヘッダーの抽出 / 置換、HTTP 属性に基づく動的なバックエンド選択、HTTP レスポンス本文の操作など、アプリケーションに固有の複雑なロジック。

フェーズ 2: Google Cloud における同等機能の選択

ルールを分類したら、次はそれらを適切な Google Cloud 機能にマッピングします。これは 1 対 1 の置き換えではなく、戦略的な選択となります。

オプション 1: 宣言型の方法（ルールの約 80%）一般的なパターンの大部分については、通常はアプリケーションロードバランサに組み込まれている宣言型機能を活用することが最適なアプローチです。スクリプトの代わりに、構成ファイルで望ましい状態を定義します。これにより、管理、バージョン管理、スケーリングが容易になります。

宣言型機能マッピングの一般的なパターン:

リダイレクト / 書き換え -> アプリケーションロードバランサの URL マップ
ACL / スロットリング -> Google Cloud Armor のセキュリティポリシー
セッションの永続性 -> バックエンドサービス構成

オプション 2: プログラムによる方法（複雑なカスタムルールの場合）複雑なカスタムビジネスロジックを扱う場合、プログラムによる同等の方法として Service Extensions があります。これは、Rust、C++、Go で記述したカスタムコードをロードバランサのデータパスに直接挿入できる強力なエッジコンピューティング機能です。このアプローチにより、最新のマネージド型高パフォーマンスフレームワークで柔軟性を確保できます。

このフローチャートは、各構成に適した Google Cloud の機能を判断するためにお役立てください。

フェーズ 3: テストと検証

構成に適した方法を選択したら、本番環境のセットアップを反映したステージング環境に新しいアプリケーションロードバランサ構成をデプロイする準備が整います。移行対象のロジックに特に注意しながら、アプリケーションのすべての機能を徹底的にテストします。自動テストと手動 QA を組み合わせて、リダイレクトやセキュリティポリシー、そしてカスタムの Service Extensions ロジックが想定どおりに動作することを検証します。

フェーズ 4: 段階的なカットオーバー（カナリアデプロイ）

すべてのトラフィックについて切り替えを一度に行うのではなく、段階的な移行戦略を実施します。最初は、本番環境トラフィックの少ない割合（5～10% など）を新しい Google Cloud ロードバランサにルーティングします。この初期段階では、レイテンシ、エラー率、アプリケーションのパフォーマンスなどの主要な指標を必ずモニタリングしてください。確信が持てたら、アプリケーションロードバランサにルーティングするトラフィックの割合を徐々に増やしていきます。重大な問題が発生した場合に備えて、以前のインフラストラクチャに戻すための明確なロールバック計画も常に用意しておきましょう。

スムーズな移行のためのベストプラクティス

Google の実践経験に基づき、ロードバランサの移行計画を立てる際に役立つ推奨事項を以下にまとめます。

先に分析してから移行する: 既存の構成を徹底的に分析することが最も重要なステップです。不要になったロジックの「リフト＆シフト」を行わないようにします。
宣言型を優先する: デフォルトとして、Google Cloud のマネージド型、宣言型の機能（URL マップ、Cloud Armor）を常に先に使用します。これらの機能は、よりシンプルでスケーラブルであり、メンテナンスも少なくて済みます。
Service Extensions は戦略的に使用する: Service Extensions は、宣言型機能では処理できない複雑なカスタムビジネスロジックのために取っておきます。
すべてをモニタリングする: 移行中は、既存のロードバランサと Google Cloud ロードバランサの両方を継続的にモニタリングします。トラフィック量、レイテンシ、エラー率などの主要な指標を注視して、問題が発生した場合は即座に検出して対処します。
チームのトレーニングを行う: Cloud Load Balancing のコンセプトについて、チームにトレーニングを提供します。これにより、チームは新しいインフラストラクチャを効果的に運用、維持できるようになります。

既存のオンプレミスロードバランサインフラストラクチャからの移行は、単なる技術的なタスクではなく、アプリケーション配信をモダナイズする機会です。現在のロードバランシングの構成と機能を、宣言型のアプリケーションロードバランサ機能またはプログラムによる Service Extensions のいずれかに入念にマッピングすることで、スケーラビリティ、復元力、費用対効果に優れたインフラストラクチャを構築し、将来の需要に対応できます。

移行を始めるには、アプリケーションロードバランサと Service Extensions の特徴や高度な機能を確認して、アプリケーションに適した設計を考案します。詳細なガイダンスや複雑なユースケースについては、Google Cloud チームにお問い合わせください。

- Google Cloud、カスタマーエンジニア、Gopinath Balakrishnan

- Google Cloud、カスタマーエンジニア、Xiaozang Li

データレイヤの有効化によるプロダクションレディな AI の実現

Fri, 17 Apr 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 4 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

生成 AI を使用したアプリケーションやシステムとそれらがもたらす新たな機会について議論する際、データはエコシステム内で代替不可能なコンポーネントとして位置づけられます。具体的には、企業が日々収集、保持、使用しているデータが該当します。このデータは、アプリケーション、分析、ナレッジベースなどの支柱として機能します。データの保存と操作にはデータベースが使用されます。AI を活用したイニシアチブや新しいアプリケーションのほとんどは、このデータレイヤを使用することになります。

では、AI システムでデータを使用するにはどうすればよいでしょうか。Google データベースでデータを準備して AI モデルに使用する方法を解説するラボをいくつかご紹介します。

セマンティック検索: データベース内のテキストエンベディング

はじめに、セマンティック検索用のデータを準備して最初のテストを実行し、セマンティック検索の結果に基づいて生成 AI モデルの回答をグラウンディングすることで回答を強化します。グラウンディングデータは、RAG（検索拡張生成）の基盤となります。その後、最新のインデックス作成手法を使用してエンベディングをインデックス化することで、検索のパフォーマンスを向上させることができます。

そのための選択肢の一つとなるのが Google AlloyDB データベースです。AlloyDB は AI モデルと直接統合されており、要求の高いワークロードにも対応できます。次のラボでは、AlloyDB クラスタの作成、サンプルデータの読み込み、エンベディングの生成から、それらのエンベディングを使用して生成 AI モデルから拡張回答を生成するまでのすべての手順を説明します。

aside_block: <ListValue: [StructValue([('title', 'ラボに移動'), ('body', <wagtail.rich_text.RichText object at 0x7fdf3867b730>), ('btn_text', ''), ('href', ''), ('image', None)])]>

AI の統合は AlloyDB に限定されません。すべての Google Cloud データベースに AI が統合されており、セマンティック検索用のエンベディングの生成や利用が可能です。たとえば、Cloud SQL を使用している場合は、既存の PostgreSQL または MySQL インスタンス内で直接、セマンティック検索用のエンベディングを生成して使用することもできます。

次の 2 つのラボは上で紹介したラボとよく似ていますが、Google AlloyDB for PostgreSQL の代わりに Cloud SQL for PostgreSQL と Cloud SQL for MySQL を使用し、モデルの回答のグラウンディングエンジンとしてセマンティック検索を使用します。SQL 言語やデータベースエンジンの違いにより、一部の手順は異なりますが、主な考え方は同じです。つまり、データを使用してモデルの回答をグラウンディングし、出力を改善します。

aside_block: <ListValue: [StructValue([('title', 'ラボに移動'), ('body', <wagtail.rich_text.RichText object at 0x7fdf3867b550>), ('btn_text', ''), ('href', ''), ('image', None)])]>

テキストデータを使用したセマンティック検索は、回答の信頼性と有用性を高めるための基礎となる重要な機能の一つですが、Google の生成 AI モデルが提供できる機能はそれだけにとどまりません。次に、マルチモーダル検索を紹介します。

マルチモーダルエンベディング: 検索に画像を取り入れる

現実の世界では、当然のことながら視覚を含むすべての感覚を使って周囲の世界を評価します。Google のマルチモーダルエンベディングモデルは、理解のレイヤをさらに追加し、テキストだけでなく画像にもエンベディングを使用することで検索を改善します。

次のラボでは、AlloyDB に格納され、Google Cloud Storage の画像で補完された商品のカタログを使用します。このラボでは、テキストの説明と画像の両方をセマンティック検索に使用します。テキストと画像を相互に補完または置換させることで画像入力に基づく検索を自然に回答に組み込む方法を示します。

aside_block: <ListValue: [StructValue([('title', 'ラボに移動'), ('body', <wagtail.rich_text.RichText object at 0x7fdf3867bac0>), ('btn_text', ''), ('href', ''), ('image', None)])]>

RAG と検索に利用できるツール全般について理解するにはデータを準備して最初の一歩を踏み出すことが重要ですが、Google はデータの準備なしで AI との直接的な統合によってデータ分析を行う機能を提供しています。

AlloyDB AI 関数と再ランキング

Google AlloyDB データベースは、データの準備なしで一部の AI 機能を使用できる追加の AI 統合を備えています。たとえば、AI.IF 関数を使えばセマンティック検索を即座に実行できます。この関数は、自然言語クエリを使用して感情の評価や列のデータの比較を行い、クエリ条件でフィルタリングされた結果を返します。また、検索出力にランキング関数を適用して、最終的な結果を改善することもできます。以下のラボで新しい機能を試して、ご自身のユースケースに役立つかどうか感想を聞かせてください。

aside_block: <ListValue: [StructValue([('title', 'ラボに移動'), ('body', <wagtail.rich_text.RichText object at 0x7fdf3867b220>), ('btn_text', ''), ('href', ''), ('image', None)])]>

ところで、SQL にあまり詳しくない人や、データベースのデータ構造に慣れていない人はどうすればよいでしょうか。そうした人に対応するのが AlloyDB NL2SQL です。

AlloyDB AI の自然言語を使用して SQL を生成する

AlloyDB の「alloydb_ai_nl」拡張機能を使用すると、すぐに利用できるデフォルトのメタデータに基づいて SQL クエリを生成できるだけでなく、自動またはカスタムのコンテキストを構築して、クエリ生成機能を最大限に活用できます。

NL2SQL 関数は、テーブルの実際のデータサンプルに基づいて、データ構造、テーブル間の関係、メタデータを記述するレイヤを追加できます。データ自体を損なうことなく、AI モデルが最適なクエリを構築する方法を理解するのに必要な情報を提供します。次のラボでは、新しい機能の使用を開始し、データスキーマに基づいて最初のクエリを生成する方法を説明します。

aside_block: <ListValue: [StructValue([('title', 'ラボに移動'), ('body', <wagtail.rich_text.RichText object at 0x7fdf3867bc10>), ('btn_text', ''), ('href', ''), ('image', None)])]>

テストから本番環境へ

これらのラボは、Google の Google Cloud でのプロダクションレディな AI プログラムの「データ基盤から高度な RAG へ」モジュールの一部です。Google Cloud のサービスとツールが提供する AI 機能を導入するのに役立つ他のモジュールもご確認ください。これらのモジュールが、最新のテクノロジーの可能性を最大限に活用した高品質なアプリケーションの構築に役立つことを願っています。

また、AlloyDB と Cloud SQL のリリースノートにもご注目ください。エンジニアリングチームは、新機能と改善に取り組んでいます。無料試用をお楽しみください。

- データベース、Cloud アドボケイト、Gleb Otochkin

Envoy: エージェント型 AI ネットワーキングのための将来を見据えた基盤

Fri, 17 Apr 2026 01:30:00 +0000

※この投稿は米国時間 2026 年 4 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

昨今のエージェント型 AI 環境では、ネットワークに新たな責任が課せられています。

従来のアプリケーションスタックでは、ネットワークは主にサービス間でリクエストを移動するものでした。しかし、最近のホワイトペーパー Cloud Infrastructure in the Agent-Native Era で説明されているように、エージェントシステムでは、モデル呼び出し、ツール呼び出し、エージェント間のやり取り、エージェントができることを定義するポリシーの決定の間にネットワークが位置します。多様なフレームワーク上に構築されることが多いエージェントが急速に普及しているため、すべてのエージェントパスにわたってガバナンスとセキュリティを一貫して大規模に適用する必要があります。これを実現するには、適用レイヤがアプリケーションレベルから基盤となるインフラストラクチャに移行する必要があります。つまり、ネットワークはもはや盲目的なトランスポートレイヤとして機能することはできず、より多くのことを理解し、より適切に適用を行い、より迅速に適応する必要があります。この移行において役立つのが Envoy です。

Envoy は、高パフォーマンスの分散プロキシおよびユニバーサルデータプレーンとして、大規模なスケーリングに対応するように構築されています。Google Cloud を含む要求の厳しいエンタープライズ環境で信頼されており、単一サービスのデプロイから、上り（内向き）、下り（外向き）、サイドカーの各パターンを使用した複雑なサービスメッシュまで、あらゆるものをサポートします。Envoy は、優れた拡張性、堅牢なポリシー統合、運用上の成熟度により、プロトコルが急速に変化し、制御が不十分な場合のコストが高くなる時代に特に適しています。エージェント型 AI を構築するチームにとって、Envoy は単なるコンセプトではなく、実用的でプロダクションレディな基盤です。

エージェント型 AI がネットワーキングの問題を変える

エージェントワークロードは依然としてトランスポートとして HTTP を使用することが多いですが、従来の HTTP 仲介役が依存する前提の一部には従いません。Model Context Protocol（MCP）や Agent2agent（A2A）などのプロトコルは、HTTP 上で JSON-RPC または gRPC を使用し、標準の HTTP リクエスト / レスポンスセマンティクスに加えて、クライアントとサーバーがそれぞれの機能を交換する MCP 初期化などのプロトコルレベルのフェーズを追加します。仲介役が適応する必要がある、エージェントシステムの主な側面は次のとおりです。

企業ガバナンスの多様な要件。主な課題は、安全性、セキュリティ、データプライバシー、規制遵守に関する、企業にとって譲れない幅広い要件を満たすことです。これらのニーズは、標準的なネットワークポリシーの枠を超えることが多く、内部システムとの緊密な統合、カスタムロジック、新しい組織ルールや外部規制に迅速に適応する能力が必要になります。そのため、企業が独自のガバナンスモデルを組み込める、拡張性の高いフレームワークが求められます。
ポリシー属性は、ヘッダーではなくメッセージ本文内に存在する。パスやヘッダーなどのポリシー入力に簡単にアクセスできる従来のウェブトラフィックとは異なり、エージェントプロトコルでは、重要な属性（モデル名、ツール呼び出し、リソース ID など）が JSON-RPC または gRPC ペイロードの奥深くに埋もれていることがよくあります。このため、仲介役はメッセージの内容を解析して理解し、コンテキストに応じたポリシーを適用できる必要があります。
多様で進化するプロトコルの特性に対応する。エージェントのプロトコルは一様ではありません。Streamable HTTP を使用する MCP のような一部のプロトコルでは、（Mcp-Session-Id などを使用した）分散プロキシ全体でのセッション管理が必要となるステートフルなインタラクションが導入されることもあります。このような多様な動作をサポートする必要性と、将来のプロトコルのイノベーションにより、本質的に適応性と拡張性に優れたネットワーキング基盤の必要性が高まっています。

これらの要因により、企業は単なる接続性以上のものを必要としています。ネットワークは、前述した重要なガバナンスのニーズを満たす中心的な役割を果たす必要があります。これには、プロトコルとエージェントの動作の急速な進化に対応しながら、一元化されたセキュリティ、包括的な監査可能性、きめ細かいポリシーの適用、動的なガードレールなどの機能を提供することが含まれます。簡単に言えば、エージェント型 AI はネットワークを単なるトランジットパスから重要な制御ポイントに変えます。

Envoy がこの移行に対応できる理由

Envoy は、以下の 3 つの理由から、エージェント型 AI ネットワーキングに最適です。

実証済み。Envoy は、セキュリティが重要な大規模環境で企業がすでに利用しており、新世代のトラフィック管理とポリシー適用を支える信頼できるプラットフォームとなっています。
拡張可能。Envoy は、ネイティブフィルタ、Rust モジュール、WebAssembly（Wasm）モジュール、外部処理パターンを通じて拡張できます。これにより、プラットフォームチームは、エコシステムが変化するたびにネットワーキングレイヤを再構築することなく、新しいプロトコルを採用できるようになります。
今すぐ運用に役立つ。Envoy はすでに、コントロールプレーンのゲートウェイ、適用ポイント、オブザーバビリティレイヤ、統合サーフェスとして機能しています。そのため、標準が定着するのを待たずに今すぐ移行する必要がある組織にとって、実用的な選択肢となります。

Envoy は、以下の中核的な強みを基盤として、エージェントネットワーキングに特有のニーズを満たすアーキテクチャの進歩を遂げています。

1. Envoy はエージェントトラフィックを理解する

エージェントネットワーキングの最初の要件はシンプルです。ゲートウェイはエージェントが実際に何をしようとしているのかを理解する必要があるということです。

ただし、これはそれほど簡単ではありません。MCP、A2A、OpenAI スタイルの API などのプロトコルでは、重要なポリシーシグナルがリクエスト本文内に存在することがあります。従来の HTTP プロキシは、本文を不透明なバイトストリームとして扱うように最適化されています。この設計は効率的ですが、プロキシで適用できることが制限されます。JSON メッセージを使用するプロトコルの場合、プロキシはポリシーの適用に必要な属性値を見つけるために、リクエスト本文全体をバッファリングする必要がある場合があります。特に、それらの属性が JSON メッセージの末尾にある場合はその必要性が高まります。使用されたトークンに基づくレート制限など、生成 AI プロトコルに固有のビジネスロジックでも、サーバーのレスポンスの解析が必要になる場合があります。

これに対処するために、Envoy は、HTTP で伝送されるプロトコルメッセージをデフレーミングし、有用な属性をフィルタチェーンの残りの部分に公開します。生成 AI プロトコルの拡張性モデルは、次の 2 つの目標を指針としています。

RBAC（ロールベースアクセス制御）やトレーサーなど、生成 AI プロトコルにそのまま対応する既存の HTTP 拡張機能を簡単に再利用できる。
デベロッパーが HTTP や JSON エンベロープを処理する必要がなく、生成 AI のビジネスロジックに集中できるように、生成 AI 固有の拡張機能用のデフレーミングされたメッセージに簡単にアクセスできる。

これらの目標に基づき、生成 AI プロトコルの新しい拡張機能は、依然として HTTP 拡張機能として構築され、HTTP フィルタチェーンで構成されます。これにより、OAuth や mTLS 認証などの HTTP ネイティブのビジネスロジックと生成 AI プロトコルのロジックを 1 つのチェーンで混在させる柔軟性が得られます。デフレーミング拡張機能は、HTTP で伝送されるプロトコルメッセージを解析し、抽出された属性、さらには解析されたメッセージ全体を含むアンビエントコンテキストを、既知のフィルタ状態とメタデータ値を介してダウンストリームの拡張機能に提供します。

Envoy では、すべてのポリシーコンポーネントが JSON エンベロープやプロトコル固有のメッセージ形式を独自に解析することを強制するのではなく、これらの属性を構造化されたメタデータとして利用できるようにします。ゲートウェイがプロトコルメッセージをデフレーミングすると、ext_authz や RBAC などの既存の Envoy 拡張機能がプロトコルプロパティを読み取り、MCP のツール名、A2A のメッセージ属性、OpenAI のモデル名などのプロトコル固有の属性を使用してポリシーを評価できます。

アクセスログには、モニタリングと監査を強化するためのメッセージ属性を含めることができます。プロトコル属性は Common Expression Language（CEL）ランタイムでも使用できるため、RBAC や複合拡張機能で複雑なポリシー式を簡単に作成できます。

バッファリングとメモリ管理Envoy は、HTTP リクエストをプロキシする際にできるだけ少ないメモリを使用するように設計されています。しかし、エージェントプロトコルの解析には、特に拡張機能でメッセージ全体をメモリに格納する必要がある場合、変動する量のバッファ領域が必要になることがあります。特に、信頼できないトラフィックが存在する場合は、拡張機能でより大きなバッファを使用できる柔軟性と、メモリ枯渇からの適切な保護のバランスを取る必要があります。

これを実現するために、Envoy ではリクエストごとにバッファサイズを制限できるようになりました。リクエストデータを保持するバッファもオーバーロードマネージャーと統合されているため、アイドルタイムアウトの短縮や、長期間にわたって最も多くのメモリを消費するリクエストのリセットなど、メモリ不足時のあらゆる保護アクションが可能になります。これらの変更により、Envoy はリソース効率を損なうことなく、生成 AI プロトコルのゲートウェイおよびポリシー適用ポイントとして機能できるようになっています。

2. Envoy は重要な事項に関するポリシーを適用する

トラフィックを理解することは、ゲートウェイがそれに基づいて動作できる場合にのみ役立ちます。

エージェントシステムでは、ポリシーはエージェントがアクセスできるサービスだけでなく、エージェントが呼び出せるツール、使用できるモデル、提示する ID、消費できる量、追加の制御が必要な出力の種類も規定するものです。これらは、単純なレイヤ 4 またはパスベースの制御よりも価値の高い決定であり、エージェントが企業に代わって行動することを許可する場合に、企業が重視する種類の制御です。

この点において Envoy は、トランスポートレベルのセキュリティとアプリケーション対応のポリシー適用を組み合わせることができるため、優れています。チームは、mTLS と SPIFFE ID でワークロードを認証し、RBAC、外部認証、外部処理、アクセスロギング、CEL ベースのポリシー式を使用してプロトコル固有のルールを適用できます。

この機能は、プラットフォームチームがエージェントの開発と適用を切り離せるため、非常に重要です。デベロッパーは有用なエージェントの構築に集中でき、オペレーターはツール、モデル、プロトコルが変化し続けても、ネットワークレイヤで一貫したゼロトラスト体制を維持できます。このゼロトラストの分離の好例は、「エージェントの背後にユーザーがいる」重要なシナリオ、つまり AI エージェントが人間のユーザーに代わってタスクを実行する必要がある場合です。従来、ユーザーの認証情報をアプリケーションに直接渡すことは、重大なセキュリティリスクをもたらします。エージェントが侵害されたり、プロンプトインジェクションによって操作されたりした場合、攻撃者は認証情報を抜き取ったり、不正使用したりできるためです。ID 管理を Envoy にオフロードすることで、プロキシはインフラストラクチャレイヤでユーザー委任トークンをアウトバウンドリクエストに自動的に挿入できます。エージェントが機密性の高い認証情報を直接保持することはないため、侵害されたエージェントがトークンを不正使用したり漏洩させたりするリスクは完全に排除され、アクションはユーザーの実際の権限に厳密にバインドされたままになります。

ケーススタディ: エージェントを特定の GitHub MCP ツールに制限するGitHub の問題をトリアージするエージェントを考えてみましょう。

GitHub MCP サーバーは数十のツールを公開している可能性がありますが、エージェントに必要なのは、list_issues、get_issue、get_issue_comments など、ごく一部の読み取り専用のツールのみである場合があります。ほとんどの企業にとって、この違いは重要です。有用なエージェントが、無制限のエージェントに自動的に変わるべきではありません。

MCP サーバーの前に Envoy を配置することで、ゲートウェイは mTLS handshake 中に SPIFFE を使用してエージェントの ID を検証し、デフレーミングフィルタを介して MCP メッセージを解析し、リクエストされたメソッドとツール名を抽出して、その特定のエージェント ID に対して承認されたツール呼び出しのみを許可するポリシーを適用できます。RBAC は、MCP デフレーミングフィルタによって作成されたメタデータを使用して、MCP メッセージ内のメソッドとツール名をチェックします。

code_block: <ListValue: [StructValue([('code', 'envoy.filters.http.rbac:\r\n "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBACPerRoute\r\n rbac:\r\n rules:\r\n policies:\r\n github-issue-reader-policy:\r\n permissions:\r\n - and_rules:\r\n rules:\r\n - sourced_metadata:\r\n metadata_matcher:\r\n filter: envoy.http.filters.mcp\r\n path: [{ key: "method" }]\r\n value: { string_match: { exact: "tools/call" } }\r\n - sourced_metadata:\r\n metadata_matcher:\r\n filter: envoy.http.filters.mcp\r\n path: [{ key: "params" }, { key: "name" }]\r\n value:\r\n or_match:\r\n value_matchers:\r\n - string_match: { exact: "list_issues" }\r\n - string_match: { exact: "get_issue" }\r\n - string_match: { exact: "get_issue_comments" }\r\n principals:\r\n - authenticated:\r\n principal_name:\r\n exact: "spiffe://cluster.local/ns/github-agents/sa/issue-triage-agent"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf384eac10>)])]>

この真の価値は、ポリシーがトラフィックに近い場所で、一元的に、エージェントの実際の動作に合った条件で適用されるという点です。

静的ルールの枠を超えて: 外部認証

RBAC ルールを使用して表現できない複雑なコンプライアンスポリシーは、ext_authz プロトコルを使用して外部認証サービスに実装できます。Envoy は、ext_authz RPC のコンテキストで、HTTP ヘッダーとともに MCP メッセージ属性を提供します。また、ピア証明書からエージェントの SPIFFE ID を転送することもできます。

code_block: <ListValue: [StructValue([('code', 'http_filters:\r\n - name: envoy.filters.http.ext_authz\r\n typed_config:\r\n "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz\r\n grpc_service:\r\n envoy_grpc:\r\n cluster_name: auth_service_cluster\r\n include_peer_certificate: true\r\n metadata_context_namespaces:\r\n - envoy.http.filters.mcp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf384eaf40>)])]>

これにより、エージェントや MCP サーバーがポリシーレイヤを認識する必要なく、エージェント ID、MCP メソッド、ツール名、その他のプロトコル属性の完全な組み合わせに基づいて、外部サービスが認証の決定を行うことができます。

プロトコルネイティブのエラーレスポンス

Envoy がリクエストを拒否した場合、返されるエラーは呼び出し元のエージェントにとって意味のあるものである必要があります。MCP トラフィックの場合、Envoy は local_reply_config を使用して、HTTP エラーコードを適切な JSON-RPC エラーレスポンスにマッピングできます。たとえば、403 Forbidden は、isError: true および人間が読めるメッセージを含む JSON-RPC レスポンスにマッピングできます。これにより、エージェントは不透明な HTTP ステータスコードではなく、プロトコルに適した拒否を受け取ることができます。

3. Envoy はステートフルなエージェントのインタラクションを大規模にサポートする

エージェントトラフィックのすべてがステートレスであるわけではありません。MCP の Streamable HTTP など、一部のプロトコルはセッション指向の動作に依存する場合があります。特に、トラフィックが複数のゲートウェイインスタンスを通過してスケーラビリティと復元力を実現する場合、仲介役にとって新たな課題が生じます。MCP セッションは、そのセッションを確立したサーバーにエージェントを効果的にバインドします。すべての仲介役は、受信 MCP 接続を正しいサーバーに転送するために、このことを認識する必要があります。

1 つのバックエンドでセッションが確立された場合、その会話における後のリクエストは正しい宛先に到達する必要があります。単一プロキシのデプロイでは簡単そうに聞こえますが、水平方向にスケールされたシステムでは、複数の Envoy インスタンスが同じエージェントからの異なるリクエストを処理する場合があり、より複雑になります。

パススルーゲートウェイ

よりシンプルなパススルーモードでは、Envoy はダウンストリーム接続ごとに 1 つのアップストリーム接続を確立します。主な用途は、外部 MCP サーバーに対するクライアントの認可、RBAC、レート制限、認証など、一元化されたポリシーの適用です。仲介役の間で転送されるセッション状態には、最初の HTTP 接続でセッションを確立したサーバーのアドレスのみが含まれる必要があります。これにより、セッション関連のすべてのリクエストがそのサーバーに送信されます。

異なる Envoy インスタンス間でのセッション状態の転送は、MCP サーバーから提供された MCP セッション ID に、エンコードされたセッション状態を追加することで実現されます。Envoy は、リクエストを宛先 MCP サーバーに転送する前に、セッション ID からセッション状態の接尾辞を削除します。このセッションの永続性は、Envoy の envoy.http.stateful_session.envelope 拡張機能を構成することで有効になります。

集約ゲートウェイ

集約モードでは、Envoy は複数のバックエンド MCP サーバーの機能、ツール、リソースを集約することで、単一の MCP サーバーとして機能します。これにより、ポリシーが適用されるだけでなく、エージェントの構成が簡素化され、複数の MCP サーバーのポリシー適用が統合されます。

このモードでのセッション管理はより複雑になります。セッション状態に、ツールとリソースから、それらをアドバタイズしたサーバーアドレスとセッション ID へのマッピングも含まれる必要があるためです。Envoy がエージェントに提供するセッション ID は、ツールやリソースが認識される前に作成され、マッピングはその後、Envoy とバックエンド MCP サーバー間の MCP 初期化フェーズが完了した後に確立される必要があります。

現在 Envoy で実装されているアプローチの一つは、ツールやリソースの名前と、その配信元サーバーの識別子およびセッション ID を組み合わせるというものです。通常、正確なツール名やリソース名はエージェントにとって意味がなく、この追加の来歴情報を伝えることができます。変更されていないツール名やリソース名が必要な場合は、マッピングのない Envoy インスタンスを使用し、特定のツールを呼び出す前に tools/list コマンドを発行してマッピングを再作成するというアプローチもあります。このアプローチは、レイテンシと引き換えに、MCP セッションの外部グローバルストアをデプロイする複雑さが伴います。現在、ユーザーからのフィードバックに基づいて計画中です。

これは、Envoy が単純なトラフィック転送にとどまらないことを意味するため重要です。これにより、Envoy は、実際のエージェントワークフロー（複数のリクエスト、ツール、バックエンドにわたるものを含む）の信頼できる仲介役として機能できます。

4. Envoy はエージェントの検出をサポートする

Envoy は、既知の AgentCard エンドポイントを介した A2A プロトコルとエージェントの検出のサポートを追加しています。エージェント機能が記載された JSON ドキュメントである AgentCard は、スキル、認証要件、サービスエンドポイントをアドバタイズすることで、検出とマルチエージェントの調整を可能にします。AgentCard は、直接レスポンス構成を介して静的にプロビジョニングすることも、xDS API または ext_proc API を介して一元化されたエージェントレジストリサーバーから取得することもできます。A2A の実装とエージェントの検出の詳細は、今後のブログ投稿で公開する予定です。

5. Envoy はエージェントネットワーキングの課題に対する包括的なソリューション

Envoy は、要求の厳しいデプロイで MCP プロトコルのポリシー適用が可能になった基盤と同じ基盤を基に、OpenAI と、エージェントプロトコルの RESTful HTTP API へのコード変換のサポートを追加しています。このコード変換機能により、生成 AI エージェントと既存の RESTful アプリケーションの統合が簡素化されます。また、OpenAPI ベースのアプリケーションがすぐにサポートされ、動的モジュールまたは Wasm 拡張機能を通じてカスタムオプションを利用できます。Envoy は、コード変換に加えて、割り当て管理などの高度なポリシー適用、生成 AI システムの OpenTelemetry セマンティック規則に準拠した包括的なテレメトリー、安全なエージェント運用を実現する統合ガードレールなど、本番環境への対応に不可欠な領域で強化されています。

安全なエージェントのためのガードレール

投資対象となる次の重要な分野は、すべてのエージェントトラフィックのガードレールの一元管理と適用です。現在、ポリシー適用ポイントを外部のガードレールと統合するには、特注の実装が必要ですが、この問題領域は標準化の機が熟しています。

コントロールプレーンがこれを運用可能にする

ゲートウェイは、ソリューション全体の一部にすぎません。このポリシー管理とロールアウトを大規模に実現するにあたり、xDS プロトコル（ユニバーサルデータプレーン API とも呼ばれる）を使用してデータプレーンを動的に構成するために別のコントロールプレーンが必要になります。

そこで重要になるのがコントロールプレーンです。Cloud Service Mesh は、Envoy AI Gateway や kube-agentic-networking などのオープンソースプロジェクトとともに、Envoy をデータプレーンとして使用しながら、オペレーターがエージェントワークロードのポリシーをより高いレベルで定義、管理できるようにします。

この組み合わせは強力です。Envoy はトラフィックパスに適用機能と拡張性を提供し、コントロールプレーンはチームがその機能を一貫してデプロイするために必要な運用モデルを提供します。

このソリューションが重要な理由

エージェントシステムや生成 AI プロトコル（MCP、A2A、OpenAI など）への移行に伴い、ネットワーク仲介役の進化が求められています。Envoy が主に対応する複雑な課題は次のとおりです。

プロトコルの詳細な検査。プロトコルデフレーミング拡張機能は、HTTP リクエストの本文からポリシーに関連する属性（ツール名、モデル名、リソースパス）を抽出し、従来のプロキシでは不透明なバイトストリームしか確認できなかった状況で正確なポリシー適用を可能にします。
きめ細かいポリシーの適用。これらの内部属性を公開することで、RBAC や ext_authz などの既存の Envoy 拡張機能は、プロトコル固有の基準に基づいてポリシーを評価できます。これにより、ネットワークオペレーターは、統一されたゼロトラストのセキュリティポスチャーを適用し、エージェントが特定のツールやリソースのアクセスポリシーに準拠するようにできます。
ステートフルなトランスポート管理。Envoy は、MCP で使用される Streamable HTTP トランスポートのセッション状態の管理をサポートしており、仲介役のフリート全体でも、パススルーゲートウェイモードと集約ゲートウェイモードの両方で堅牢なデプロイを可能にします。

エージェント型 AI プロトコルはまだ初期段階にあり、プロトコルの状況は今後も進化し続けます。まさにそのために、ネットワーキングレイヤには適応性が必要なのです。新しいエージェントフレームワーク、トランスポートパターン、ツールプロトコルが普及するたびに、企業がセキュリティとトラフィックのインフラストラクチャを再構築する必要はありません。制御を犠牲にすることなく変化を吸収できる基盤が必要です。

Envoy は、本番環境での実証済みの成熟度、高度な拡張性、エージェントワークロードのプロトコル認識の向上という、一度に持ち合わせることが難しい 3 つの特性を兼ね備えています。Envoy をエージェントゲートウェイとして活用することで、組織はセキュリティとポリシーの適用をエージェント開発コードから切り離すことができます。

これにより、Envoy は AI トラフィックを処理するプロキシ以上の存在になり、エージェント型 AI ネットワーキングの未来を見据えた基盤となります。

^{このブログ記事の共同執筆者である、Google のソフトウェアエンジニア Boteng Yao、Google のソフトウェアエンジニア Tianyu Xia、Google のシニアプロダクトマネージャー Sisira Narayana に感謝します。}

- Google、スタッフソフトウェアエンジニア、Yan Avlasov

- Tetrate、プロダクトおよびプロダクトマーケティングマネージャー、Erica Hughberg 氏

Google ADK、MCP、Cloud Run を使用して専門家向けコンテンツ用のマルチエージェントシステムを構築する - パート 1

Thu, 09 Apr 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 3 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

私のチームのミッションは、コードの作成から Google Cloud で安全な AI ワークロードを実行するまで、デベロッパーの取り組みを加速させることです。デベロッパーの成功を支援するため、Google はデベロッパーが最も切実に求めている質問を特定し、簡単に実装できるわかりやすいソリューションを提供するデモを構築することに重点を置いています。

最近、新しい Developer Knowledge MCP サーバーがリリースされたとき、私にはひらめきが湧きました。そこで、Google Agent Development Kit（ADK）を使用して設計されたマルチエージェントシステムである Dev Signal を構築し、Reddit から技術的な質問を特定し、公式ドキュメントを使用して調査し、詳細な技術ブログ記事の下書きを作成しました。Dev Signal には、Nano Banana Pro を使用したカスタムビジュアルも備わっています。エージェントが私の好みのスタイルやブログ記事の書き方を記憶できるように、長期記憶レイヤも統合しました。

コーディングアシスタントである Gemini CLI をデベロッパーナレッジ MCP サーバーに接続することで、このシステム全体をわずか 2 日で構築して Google Cloud Run にデプロイしました。

ここでは、長期記憶を備えた複雑なマルチエージェントシステムを設計する方法、ローカルおよびリモートの MCP サーバーを利用してツールを標準化する方法、安全な Cloud Run デプロイのための詳細な Terraform スクリプトを作成する方法など、さまざまな方法をご紹介します。

今すぐコードを見てご自分のペースで調べる場合は、こちらからリポジトリをクローニングできます。

学習内容

4 回に分けてお届けするこのブログシリーズでは、このプロジェクトをどのように実現したのか、その手順を段階的にご紹介します。各ブログ投稿では、Dev Signal の構築とデプロイの過程を説明します。

パート 1: エージェント機能を構築するためのツール – まず、プロジェクト環境をセットアップし、Model Context Protocol（MCP）を使用してエージェントにツールを装備します。トレンドの発見に Reddit を、技術的なグラウンディングに Google Cloud ドキュメントを、画像生成にカスタム Nano Banana Pro ツールを使用する方法を学びます。
パート 2: 長期記憶を備えたマルチエージェントアーキテクチャ – ルートオーケストレーターと専門エージェントチームを実装して、システムの「頭脳」を構築します。また、Vertex AI Memory Bank を統合することで、エージェントがセッション全体でユーザーの好みを学習して保持できるようになります。
パート 3: エージェントをローカルでテストする – クラウドに移行する前に、エージェントのコンポーネントを同期し、ワークステーションでエージェントのパフォーマンスを検証します。専用のテストランナーを使用して、検出、調査、マルチモーダル作成のライフサイクル全体をシミュレートします。特に、ローカルエージェントをクラウドベースの Vertex AI Memory Bank に直接接続して、長期記憶の永続性を検証することに重点を置きます。
パート 4: Cloud Run へのデプロイと本番環境への移行 – 最後に、再現可能なインフラストラクチャを実現するため、Terraform を使用して Google Cloud Run にサービスをデプロイします。また、高品質で安全な本番環境システムに必要な次のステップについても説明します。

Dev Signal の概要

Dev Signal は、ノイズをフィルタして価値を生み出すように設計されたインテリジェントなモニタリングエージェントです。Dev Signal は次のように動作します。

発見: Reddit を調査して、エンゲージメントの高い技術的な質問を見つけます。
グラウンディング: 正確性を確保するために、Google Cloud の公式ドキュメントを使用して回答を調査します。
作成: 調査結果に基づいて、プロフェッショナルな技術ブログ投稿の下書きを作成します。
マルチモーダル生成: これらの投稿のカスタムインフォグラフィックヘッダーを生成します。
長期記憶: Vertex AI Memory Bank を使用して、さまざまなセッションにわたってフィードバックを記憶します。

前提条件

始める前に、以下がインストールされていることを確認してください。

Python 3.12 以降

uv（Python パッケージ管理システム）: curl -LsSf https://astral.sh/uv/install.sh | sh
Google Cloud SDK（gcloud CLI）（インストールおよび認証済み）
Terraform（Iinfrastructure as Code 用）
Node.js と npm（Reddit MCP ツールに必要）

次も必要です。

課金を有効にした Google Cloud プロジェクト。
有効な API: Vertex AI、Cloud Run、Secret Manager、Artifact Registry。
Reddit API 認証情報（クライアント ID、シークレット）- Reddit デベロッパーポータルから入手できます。
Developer Knowledge API Key（Google Cloud ドキュメント検索用）- 入手方法については、こちらをご覧ください。

プロジェクトのセットアップ

Dev Signal システムは、Remigiusz Samborski 氏と Vlad Kolesnikov 氏による Agent Factory のエピソードで説明されている自動化されたアーキテクトワークフローに従って、まず Agent Starter Pack を実行して構築されました。この基盤により、エージェントロジック、サーバーコード、ユーティリティ、ツール間の関心を分離するために使用される、プロジェクトのモジュール式ディレクトリ構造が用意されました。

Starter Pack は、プロフェッショナルなインフラストラクチャ、CI / CD パイプライン、オブザーバビリティツールの作成を数秒で自動化するため、強力な出発点となります。これにより、基盤となるプラットフォームのセキュリティとスケーラビリティを確保しながら、エージェント独自のインテリジェンスに十分集中できるようになります。Gemini CLI と Antigravity の AI アシスタンスを使用して、生成されたボイラープレートを基に構築することで、開発プロセスが大幅に加速されます。

Agent Starter Pack のアーキテクチャの概要:

1. プロジェクトを初期化する

プロジェクト用の新しいディレクトリを作成し、初期化します。ここでは、非常に高速な Python パッケージ管理システムである uv を使用します。

code_block: <ListValue: [StructValue([('code', 'uv init dev-signal'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2dd78040>)])]>

2. フォルダ構造

このプロジェクトは次の構造に従います。これらのファイルにデータを段階的に入力していきます。

code_block: <ListValue: [StructValue([('code', 'dev-signal/\r\n├── dev_signal_agent/\r\n│ ├── __init__.py\r\n│ ├── agent.py # Agent logic & orchestration\r\n│ ├── fast_api_app.py # Application server & memory connection\r\n│ ├── app_utils/ # Env Config\r\n│ │ └── env.py\r\n│ └── tools/ # External capabilities\r\n│ ├── __init__.py\r\n│ ├── mcp_config.py # Tool configuration (Reddit, Docs)\r\n│ └── nano_banana_mcp/# Custom local image generation tool\r\n│ ├── __init__.py\r\n│ ├── main.py\r\n│ ├── nano_banana_pro.py\r\n│ ├── media_models.py\r\n│ ├── storage_utils.py\r\n│ └── requirements.txt\r\n├── deployment/\r\n│ └── terraform/ # Infrastructure as Code\r\n├── .env # Local secrets (API keys)\r\n├── Makefile # Shortcuts for building/deploying\r\n├── Dockerfile # Container definition\r\n└── pyproject.toml # Dependencies'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2dd78d90>)])]>

3. 依存関係を定義する

必要な依存関係を使用して pyproject.toml を更新します。エージェントフレームワークには google-adk を、モデルのインタラクションには google-genai を使用します。

code_block: <ListValue: [StructValue([('code', '[project]\r\nname = "dev-signal"\r\nversion = "0.1.0"\r\ndescription = "A multi-agent system for monitoring and content creation."\r\nreadme = "README.md"\r\nrequires-python = ">=3.12, <3.14"\r\ndependencies = [\r\n "google-adk>=0.1.0",\r\n \xa0"google-genai>=1.0.0",\r\n "mcp>=1.0.0",\r\n \xa0"python-dotenv>=1.0.0",\r\n "fastapi>=0.110.0",\r\n "uvicorn>=0.29.0",\r\n "google-cloud-logging>=3.0.0",\r\n "google-cloud-aiplatform>=1.38.0",\r\n \xa0"fastmcp>=2.13.0",\r\n "google-cloud-storage>=3.6.0",\r\n "google-auth>=2.0.0",\r\n "google-cloud-secret-manager>=2.26.0",\r\n]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2dd78a00>)])]>

uv sync を実行してすべてインストールします。

エージェントコード用の新しいディレクトリを作成します。

code_block: <ListValue: [StructValue([('code', 'mkdir dev_signal_agent\r\ncd dev_signal_agent'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2dd78820>)])]>

エージェント機能の構築: MCP ツール

エージェントは外部とやり取りする必要があります。これを標準化するために、Model Context Protocol（MCP）を使用します。Model Context Protocol（MCP）は、AI エージェントを外部のデータやツールに接続するための普遍的な基準です。カスタム API ラッパーを記述する代わりに、標準の MCP サーバーを使用します。これにより、共通のインターフェースを使用して、API（Reddit）、ナレッジベース（Google Cloud ドキュメント）、さらにはローカルスクリプト（Nano Banana Pro を使用した画像生成）にも接続できます。エージェントツール用の新しいディレクトリを作成します。

code_block: <ListValue: [StructValue([('code', 'mkdir tools\r\ncd tools'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2dd78b80>)])]>

ツールの構成

ツールセットは dev_signal_agent/tools/mcp_config.py で定義します。

このファイルでは、3 つの主要なツールの接続パラメータを定義します。

Reddit: ローカル stdio サブプロセス経由で接続されます。
デベロッパーナレッジ: リモート HTTP エンドポイント経由で接続されます。
Nano Banana: ローカル stdio サブプロセス（Google のカスタム Python スクリプト）経由で接続されます。

Reddit 検索（発見ツール）

Reddit MCP サーバーは Reddit API へのブリッジとして機能し、複雑な API ラッパーを記述しなくても、トレンドとなっている投稿をエージェントが発見してエンゲージメントを分析できるようにします。移植性を確保するために、コードでは「検索またはフェッチ」戦略が使用されています。まずローカルインストールをチェックし、見つからない場合は npx を使用してサーバーをオンデマンドでダウンロードして実行します。

ネットワーク接続の代わりに、エージェントはサーバーをローカルサブプロセスとして起動し、標準入出力（stdio）を介して通信します。Google ADK 内の McpToolset クラスは、これらの接続を標準化する普遍的なラッパーとして機能し、エージェントが共通のインターフェースを使用して、コミュニティリソースからカスタムスクリプト（Nano Banana 画像生成ツールなど）まで、さまざまなツールとやり取りできるようにします。環境変数を介して API 認証情報を安全に渡すことで、システムはこれらの「プラグアンドプレイ」モジュールが AI と外部プラットフォーム間のシームレスなブリッジとして機能することを保証します。

次のコードを dev_signal_agent/tools/mcp_config.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import os\r\nimport shutil\r\nfrom mcp import StdioServerParameters\r\nfrom google.adk.tools import McpToolset\r\nfrom google.adk.tools.mcp_tool import StreamableHTTPConnectionParams, StdioConnectionParams\r\n\r\ndef get_reddit_mcp_toolset(client_id: str = "", client_secret: str = "", user_agent: str = ""):\r\n """\r\n Connects to the Reddit MCP server.\r\n This server runs as a local subprocess (stdio) and proxies requests to the Reddit API.\r\n """\r\n # Check if \'reddit-mcp\' is installed globally, otherwise use npx to run it\r\n cmd = "reddit-mcp" if shutil.which("reddit-mcp") else "npx"\r\n args = [] if shutil.which("reddit-mcp") else ["-y", "--quiet", "reddit-mcp"]\r\n \r\n # Inject secrets into the environment of the subprocess only\r\n env = {\r\n **os.environ, \r\n "DOTENV_CONFIG_SILENT": "true", \r\n "LANG": "en_US.UTF-8"\r\n }\r\n\r\n if client_id: env["REDDIT_CLIENT_ID"] = client_id\r\n if client_secret: env["REDDIT_CLIENT_SECRET"] = client_secret\r\n if user_agent: env["REDDIT_USER_AGENT"] = user_agent\r\n\r\n return McpToolset(\r\n connection_params=StdioConnectionParams(\r\n server_params=StdioServerParameters(\r\n command=cmd, \r\n args=args, \r\n env=env # Pass injected secrets directly to the subprocess\r\n ),\r\n timeout=120.0\r\n )\r\n )'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2dd78e50>)])]>

Google Cloud ドキュメント（ナレッジツール）

Developer Knowledge MCP サーバーは、エージェントが Google Cloud の公式ドキュメントのコーパス全体を検索できるようにすることで、エージェントのグラウンディングを提供します。これは、ローカルの Reddit サーバーとは異なり、Google がホストするマネージドサービスであり、インターネット経由でリモートエンドポイントとしてアクセスされます。セマンティッククエリ用の google_developer_documentation_search や、完全なマークダウンコンテンツを取得するための google_developer_documentation_fetch などの特殊なツールが公開されており、エージェントが技術的な主張を行うたびに、最新の確かな事実によって裏付けられるようになっています。

注: Gemini CLI や Antigravity などのコーディングアシスタントツールをデベロッパーナレッジ MCP サーバーに接続して、最新の便利な Google Cloud ドキュメントをアシスタントに提供することもできます。このブログ記事を書くときも使っています。

接続するために、エージェントは McpToolset クラスと StreamableHTTPConnectionParams を使用し、ローカルプロセスを起動する代わりにウェブ URL を指定します。リクエストヘッダーで渡される DK_API_KEY（API キーを作成）を使用して安全に認証し、エージェントが単一の標準化されたインターフェースを通じて、公式ドキュメント、コミュニティの感情、より広範なウェブコンテキスト全体で「包括的な調査スイープ」を実行できるようにします。

次のコードを dev_signal_agent/tools/mcp_config.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'def get_dk_mcp_toolset(api_key: str = ""):\r\n """\r\n Connects to Developer Knowledge (Google Cloud Docs).\r\n This is a remote MCP server accessed via HTTP.\r\n """\r\n headers = {}\r\n if api_key:\r\n headers["X-Goog-Api-Key"] = api_key\r\n else:\r\n # Fallback to os.environ for local testing if not passed via API\r\n headers["X-Goog-Api-Key"] = os.getenv("DK_API_KEY", "")\r\n\r\n return McpToolset(\r\n connection_params=StreamableHTTPConnectionParams(\r\n url="https://developerknowledge.googleapis.com/mcp",\r\n headers=headers\r\n )\r\n )'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2dd78c40>)])]>

画像生成ツール（Nano Banana MCP）

Reddit とドキュメントには外部 MCP サーバーを使用しましたが、特定の Python ロジックをラップする独自のカスタム MCP サーバーを構築することもできます。この例では、Gemini 3 Pro Image（Nano Banana Pro とも呼ばれます）を搭載した画像生成ツールを作成します。これは、任意の Python 関数を、任意のエージェントが理解できるツールに標準化できることを示しています。

画像生成の仕組み:

FastMCP: fastmcp ライブラリを使用してサーバーの作成を大幅に簡素化し、数行のコードで Python 関数をツールとして登録できるようにします。
Gemini のインテグレーション: サーバーは Google GenAI SDK を使用して gemini-3-pro-image-preview モデルを呼び出し、エージェントの説明的なプロンプトを未加工の画像バイトに変換します。
GCS へのアップロードとホスティング: エージェントインターフェースでは通常、画像を表示するために URL が必要となるため、サーバーは生成されたバイトを Google Cloud Storage（GCS）に自動的にアップロードし、公開リンクを返します。

このローカルツールを接続するには、StdioConnectionParams を使用します。これは、サーバーが標準入出力を介して通信するローカルサブプロセスとして実行されるためです。この転送方法は、サーバーのエントリポイントで定義する transport="stdio" 構成に直接一致し、カスタムのローカルスクリプトのシームレスな接続を保証します。

次のコードは、dev_signal_agent/tools/mcp_config.py で MCP 接続を定義します。uv run を使用して、すべての依存関係が正しくインストールされている、隔離された環境でサーバーが起動するようにします。

次のコードを dev_signal_agent/tools/mcp_config.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'def get_nano_banana_mcp_toolset():\r\n """\r\n Connects to our local \'Nano Banana\' image generator.\r\n This demonstrates how to wrap a local Python script as an MCP tool.\r\n """\r\n path = os.path.join("dev_signal_agent", "tools", "nano_banana_mcp", "main.py")\r\n bucket = os.getenv("AI_ASSETS_BUCKET") \r\n return McpToolset(\r\n connection_params=StdioConnectionParams(\r\n server_params=StdioServerParameters(\r\n command="uv", \r\n args=["run", path], \r\n env={**os.environ, "AI_ASSETS_BUCKET": bucket}\r\n ),\r\n timeout=600.0 # Image generation can take time\r\n )\r\n )'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2d49ca30>)])]>

Nano Banana Pro サーバーロジックの実装

次に、このサーバーの実際のロジックを実装します。この実装は、Remigiusz Samborski 氏による Agent Factory デモのコードに基づいています。Remi の元のコードには、MCP サーバーを Cloud Run にデプロイする手順が記載されていますが、ここでは開発とテストを迅速に行うために、ローカルサブプロセスとして実行します。

まず、新しいサーバー用のディレクトリを作成します。

code_block: <ListValue: [StructValue([('code', 'mkdir -p dev_signal_agent/tools/nano_banana_mcp\r\ncd dev_signal_agent/tools/nano_banana_mcp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2d49c9d0>)])]>

サーバーエントリポイント（`main.py`）

このファイルは、MCP サーバーを初期化して起動する「頭脳」として機能します。

FastMCP の初期化: FastMCP ライブラリを使用して、「MediaGenerators」という名前のサーバーを作成し、generate_image 関数をツールとして登録します。
安全なロギング: _initialize_console_logging 関数が重要な役割を果たします。この関数はすべてのログを sys.stderr に強制的に出力します。これは、MCP の「stdio」転送がエージェントとツールの間の通信に sys.stdout を使用するためです。stdout に送信される標準ログは、そのプロトコルを破損させます。
実行: mcp.run(transport="stdio") 行は、サーバーをローカルサブプロセスとして起動し、標準入力経由でエージェントからのリクエストをリッスンできるようにします。

次のコードを dev_signal_agent/tools/nano_banana_mcp/main.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import logging\r\nimport os\r\nimport sys\r\nfrom fastmcp import FastMCP\r\nfrom dotenv import load_dotenv\r\nfrom nano_banana_pro import generate_image\r\n\r\ndef _initialize_console_logging(min_level: int = logging.INFO):\r\n # Ensure logs go to STDERR so they don\'t break the MCP stdio protocol\r\n handler = logging.StreamHandler(sys.stderr)\r\n logging.basicConfig(level=min_level, handlers=[handler], force=True)\r\n\r\ntools = [generate_image]\r\nmcp = FastMCP(name="MediaGenerators", tools=tools)\r\n\r\nif __name__ == "__main__":\r\n load_dotenv()\r\n _initialize_console_logging()\r\n mcp.run(transport="stdio")'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2d49c940>)])]>

生成ロジック（`nano_banana_pro.py）`

ここでは、Gemini を使用して実際に画像が生成されます。

GenAI クライアント: Google の生成モデルとやり取りするために、genai.Client() を初期化します。
モデルの選択: 具体的には gemini-3-pro-image-preview モデルを対象とします。response_modalities を「IMAGE」に設定して、テキストだけでなくピクセルも必要であることをモデルに伝えます。
堅牢性: コードには、一時的な生成エラーを処理するための MAX_RETRIES ループ（5 に設定）が含まれており、エージェントが有効な画像を複数回取得できるようにしています。
バイト処理: モデルが画像を生成すると、未加工のインラインデータとして届きます。これらのバイトを抽出し、ヘルパーを呼び出してクラウドに移動します。
URI 変換: 最後に、内部の gs:// パスを、ブラウザからアクセス可能な https:// URL に置き換え、ユーザーが実際に画像を見られるようにします。

次のコードを dev_signal_agent/tools/nano_banana_mcp/nano_banana_pro.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import logging\r\nfrom typing import Literal, Optional\r\nfrom google import genai\r\nfrom google.genai import types\r\nfrom media_models import MediaAsset\r\nfrom storage_utils import upload_data_to_gcs\r\n\r\nAUTHORIZED_URI = "https://storage.mtls.cloud.google.com/"\r\nMAX_RETRIES = 5\r\n\r\nasync def generate_image(\r\n prompt: str,\r\n aspect_ratio: Literal["16:9", "9:16"] = "16:9",\r\n) -> MediaAsset:\r\n """Generates an image using Gemini 3 Image model."""\r\n genai_client = genai.Client()\r\n content = types.Content(parts=[types.Part.from_text(text=prompt)], role="user")\r\n \r\n logging.info(f"Starting image generation for prompt: {prompt[:50]}...")\r\n asset = MediaAsset(uri="")\r\n \r\n for _ in range(MAX_RETRIES):\r\n response = genai_client.models.generate_content(\r\n model="gemini-3-pro-image-preview",\r\n contents=[content],\r\n config=types.GenerateContentConfig(\r\n response_modalities=["IMAGE"],\r\n image_config=types.ImageConfig(aspect_ratio=aspect_ratio)\r\n )\r\n )\r\n if response and response.parts:\r\n for part in response.parts:\r\n if part.inline_data and part.inline_data.data:\r\n # Upload the raw bytes to GCS\r\n gcs_uri = await upload_data_to_gcs(\r\n "mcp-tools",\r\n part.inline_data.data,\r\n part.inline_data.mime_type\r\n )\r\n asset = MediaAsset(uri=gcs_uri)\r\n break\r\n if asset.uri: break\r\n\r\n if not asset.uri:\r\n asset.error = "No image was generated."\r\n else:\r\n # Convert gs:// URI to an HTTP accessible URL if needed\r\n asset.uri = asset.uri.replace(\'gs://\', AUTHORIZED_URI)\r\n logging.info(f"Image URL: {asset.uri}")\r\n \r\n return asset'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2d49cf10>)])]>

GCS アップロードヘルパー（`storage_utils.py）`

エージェントは画像を表示するためにリンクを必要とするため、このユーティリティは Google Cloud Storage（GCS）でホスティングを処理します。

バケットの動的な選択: 環境変数でバケット名を探し、AI_ASSETS_BUCKET から LOGS_BUCKET_NAME にフォールバックして、データの保存場所が常に確保されるようにします。
一意のファイル名: 未加工の画像データの MD5 ハッシュを使用して、一意のファイル名を作成します。これにより、ファイル名の競合を防ぐことができ、同じ画像の重複アップロードを回避する簡単な方法として機能します。
クラウドアップロード: blob.upload_from_string メソッドは、未加工の画像バイトを GCS バケットに直接 push します。

次のコードを dev_signal_agent/tools/nano_banana_mcp/storage_utils.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import hashlib\r\nimport mimetypes\r\nimport os\r\nfrom google.cloud.storage import Client, Blob\r\nfrom dotenv import load_dotenv\r\n\r\nload_dotenv()\r\nstorage_client = Client()\r\nai_bucket_name = os.environ.get("AI_ASSETS_BUCKET") or os.environ.get("LOGS_BUCKET_NAME")\r\nai_bucket = storage_client.bucket(ai_bucket_name)\r\n\r\nasync def upload_data_to_gcs(agent_id: str, data: bytes, mime_type: str) -> str:\r\n file_name = hashlib.md5(data).hexdigest()\r\n ext = mimetypes.guess_extension(mime_type) or ""\r\n blob_name = f"assets/{agent_id}/{file_name}{ext}"\r\n blob = Blob(bucket=ai_bucket, name=blob_name)\r\n blob.upload_from_string(data, content_type=mime_type, client=storage_client)\r\n return f"gs://{ai_bucket_name}/{blob_name}"'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2d49c850>)])]>

データモデル（`media_models.py`）

このファイルにより、データが厳格な構造（スキーマ）に従うことが保証されます。

構造化された出力: Pydantic BaseModel を使用することで、ツールが常に uri（リンク）とオプションの error メッセージを含む一貫した JSON オブジェクトを返すことを保証します。これにより、AI エージェントがツールの結果を理解して処理することがはるかに容易になります。

次のコードを dev_signal_agent/tools/nano_banana_mcp/media_models.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'from typing import Optional\r\nfrom pydantic import BaseModel\r\n\r\nclass MediaAsset(BaseModel):\r\n uri: str\r\n error: Optional[str] = None'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2d49c400>)])]>

ツールの依存関係（`requirements.txt）`

コードの実行には uv を使用しますが、requirements.txt ファイルは、Nano Banana サーバーが機能するために uv がインストールする必要がある特定の依存関係を定義するため、依然として不可欠です。これにより、隔離された環境をサーバーの起動前にセットアップするために必要な「材料」が提供されます。

このファイルには、このツールに必要な 3 つのコアライブラリがリストされています。

google-cloud-storage: 生成された画像をクラウドでホストするために使用されます。
google-genai: Gemini 3 Pro の画像生成のロジックを提供します。
fastmcp: Python スクリプトを標準化された MCP ツールに変えるフレームワークです。

次のコードを dev_signal_agent/tools/nano_banana_mcp/requirements.txt に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'google-cloud-storage==3.6.*\r\ngoogle-genai==1.52.*\r\nfastmcp==2.13.*'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2d49cc10>)])]>

まとめ

シリーズのパート 1 では、Model Context Protocol（MCP）を通じて外部統合を標準化することにより、エージェントのコア機能を確立することに焦点を当てました。高速な依存関係管理のために uv を使用してプロジェクトを初期化し、トレンド発見のための Reddit、技術的なグラウンディングのための Google Cloud ドキュメント、マルチモーダル画像生成のためのカスタム「Nano Banana」MCP サーバーという 3 つの重要なツールセットを構成しました。Google ADK の McpToolset を利用することで、複雑な API ロジックをシンプルなプラグアンドプレイモジュールに抽象化し、ツールが共通のインターフェースを共有してインテリジェンスから統合を切り離せるようにしました。

技術的基盤について詳しく確認するには、Developer Knowledge MCP サーバーでナレッジグラウンディングの詳細を確認するか、Google ADK GitHub リポジトリでフレームワークのコア機能について調べることができます。

ツールセットが完全に構成され、使用できる状態になったので、パート 2 に進みましょう。パート 2 では、マルチエージェントアーキテクチャを構築し、Vertex AI Memory Bank を統合してこれらの機能をオーケストレートします。さらに詳しく調べる場合は、GitHub リポジトリでシリーズ全体の詳細なコードを確認できます。

この記事に対して、レビューとフィードバックを提供してくださった Remigiusz Samborski 氏に心より感謝いたします。

このようなコンテンツをさらにご覧になりたい場合は、LinkedIn と X で私をフォローしてください。

- AI / プロダクト / DevRel 責任者、Shir Meir Lador

LLM 推論の効率的フロンティアに到達するための 5 つの手法

Wed, 08 Apr 2026 02:10:00 +0000

※この投稿は米国時間 2026 年 3 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

モデル推論に費やした費用の分だけ、レイテンシとスループットのグラフ上で良いポジションが得られます。上の図には、ハードウェアから可能な限り最大のパフォーマンスを引き出した、最適な構成の曲線が示されています。この曲線は、金融のポートフォリオ理論から借用したもので、効率的フロンティアと呼ばれます。

ハードウェアの予算が固定されていると仮定すると、レイテンシとスループットをトレードオフできます。ただし、フロンティア曲線自体が移動しない限り、一方を改善するには他方を犠牲にする必要があります。根本的に異なる 2 つのダイナミクスが作用しており、これは本番環境で LLM を実行するすべての人にとって重要なインサイトです。

最初のダイナミクスはフロンティアに到達することです。これには、現在利用可能なあらゆる手法を適用することが含まれます。この部分は、自分で制御できます。継続的なバッチ処理、アテンションの分割、インテリジェントルーティング、投機的デコーディング、量子化はすべて、現在存在する手法です。これらの手法を使用していない場合、運用がフロンティアを下回り、パフォーマンスを最大限に引き出すことができません。

2 つ目のダイナミクスは、フロンティア自体が常に外側に移動していることです。この部分は、ほとんどの場合、自分で制御できません。研究者は新しいアルゴリズムを発表し、ハードウェアベンダーは新しいアーキテクチャを出荷し、オープンソースプロジェクトは成熟します。ブレイクスルーが起こるたびに、物理的に達成可能なことが再定義され、曲線が拡大されるため、昨日の最適な構成が今日の非効率になります。

プラットフォームエンジニアの仕事は、フロンティアにできるだけ近い位置を維持しながら、新しい進歩がもたらされるたびにそれを吸収できる十分な柔軟性を持つインフラストラクチャを構築することです。この記事では、そのためのツールをご紹介します。

推論に効率的フロンティアがある理由

すべての LLM リクエストには 2 つの計算フェーズがあり、それぞれ異なるハードウェアリソースでボトルネックが発生する可能性があります。

1. プレフィル（コンピューティングバウンド）: このフェーズでは、GPU が入力プロンプト全体を一度に処理して、アテンション機構の Key-Value（KV）キャッシュを構築します。命令は並列でバッチ処理されるため、GPU のコンピューティングコア（テンソルコア）の使用率が高くなります。このフェーズは高速かつ効率的です。プロセッサは、大規模な行列乗算を実行するために必要なすべてのデータをすぐに利用できます。プロンプトが長くなると、単純に計算量が増えます。

2. デコード（メモリ帯域幅バウンド）: このフェーズでは、新しいトークンが一度に 1 つずつ自己回帰的に生成されます。1 つのトークンのみを生成する場合、GPU は作業をバッチ処理できません。モデル全体の重みと増大する KV キャッシュを高帯域幅メモリ（HBM）からコンピューティングコアにフェッチする必要があります。その後、GPU はその 1 つのトークンを計算し、次のトークンに対して再び同じ処理を行うのを待ちます。

この不一致こそが、フロンティアが存在する根本的な理由です。トレードオフなしに、単一のシステムを同時に両方のフェーズ向けに最適化することはできません。

推論の 2 つの軸

LLM 推論の効率的フロンティアでは、リスクとリターンの代わりに、ハードウェア予算が固定されているという前提で、別の基本的なトレードオフが測定されます。

軸	測定される主な指標	ハードウェアの制約
レイテンシ（X 軸）	最初のトークンまでの時間（TTFT）+ トークン間の時間（TBT）	コンピューティング（プレフィル）とメモリ帯域幅（デコード）
スループット（Y 軸）	すべての同時ユーザーの 1 秒あたりの合計トークン数	バッチサイズ × メモリ容量

費用は、レイテンシとスループットのグラフ自体を購入する制約です。ハードウェアの予算を増やすか、業界が画期的な新しいアルゴリズムを発明すると、フロンティア曲線全体が外側にシフトします。特定の予算とソフトウェアスタックで、最適ではない状態からそのフロンティアに向かって移行するための現在のベストプラクティスを適用できます。

フロンティアに到達する: 制御可能な 5 つの手法

現在、本番環境における大部分の推論システムの運用は、フロンティアを下回っています。優れた手法は存在するものの、そのような手法をまだ採用していないために、パフォーマンスが向上していないのです。このセクションで説明する手法はすべて、現在利用可能なものです。これらの手法を適用しない場合、運用が曲線を下回ることになります。

1. モデル階層間のセマンティックルーティング

すべてのクエリに 4,000 億パラメータのモデルが必要なわけではありません。単純な分類、要約、書式設定のタスクは、トークンあたりの費用が桁違いに安い、より小さな量子化モデルにルーティングできます。ゲートウェイエッジの軽量分類器がクエリの複雑さを分析し、それに応じてルーティングします。難しい推論にはフロンティアクラスのモデル、それ以外には小規模モデルを使用します。

セマンティックルーティングにより、システムは理論上の最大スループットに劇的に近づき、簡単なタスクでの無駄なサイクルが回避されます。集約された出力の品質が犠牲になることはありません。

2. プレフィルとデコードの分離

プレフィルフェーズとデコードフェーズを異なるハードウェアに物理的に分離することは、現在利用可能な、アーキテクチャ上最も重要な最適化の一つです。

プレフィルフェーズには、コンピューティング能力の高い GPU が必要です。デコードフェーズには、高帯域幅メモリが必要です。両方のフェーズを同じ GPU に強制的に割り当てると、一方のリソースが常に十分に活用されない状態になります。

両方のフェーズをそれぞれ理論上のハードウェア上限に近づけるには、専用のプレフィルクラスタとデコードクラスタを実行します。これらのクラスタを、圧縮された KV キャッシュの状態のみを同じ GPU に転送する高速ネットワークで接続すると、一方のリソースが常に十分に活用されない状態になります。

3. 量子化: 精度と速度のトレードオフ

モデルの重みを FP16 から INT8 または INT4 形式に減らすと、メモリ使用量を半分または 4 分の 1 に削減できます。デコードフェーズにはメモリ帯域幅の制限があるため、4 ビットの重みは 16 ビットの重みよりも最大 4 倍速く読み取ることができます。このアプローチにより、TBT が直接改善されます。

単純な量子化ではモデル出力の品質が低下するため、品質とのトレードオフが生じます。Activation-aware Weight Quantization（AWQ）や GPTQ などの最新の手法では、重要な重みの品質を維持しながら、他の重みを積極的に圧縮して、INT4 の速度で FP16 に近い品質を実現します。

4. コンテキストルーティング: ほとんどのチームが見落としている最大の要素

数十個のモデルレプリカを使用した本番環境でのデプロイでは、ルーティングレイヤが、現在最大の競争優位性を獲得できるかどうかの分かれ目となっています。

2026 年は、接頭辞のキャッシュ保存が基盤となっています。10 人のユーザーが 100 ページの RAG ドキュメントについてまったく同じ質問をしたり、同一の膨大なシステムプロンプトを使用したりする場合、コンピューティング負荷の高いプレフィルフェーズを 10 回実行すべきではありません。KV キャッシュを一度計算して保存し、他の 9 人のユーザーが再利用できるようにする必要があります。このアプローチにより、TTFT を最大 85% 短縮し、コンピューティング費用を大幅に削減できます。

ただし、注意点があります。標準の L4 ロードバランサはリクエストをランダムに分散します。ユーザー 2 のリクエストがユーザー 1 のリクエストとは異なる GPU に到達した場合、接頭辞のキャッシュは役に立たず、システムはキャッシュをゼロから再計算する必要があります。

コンテキスト認識型 L7 ルーティングが差別化要因となるのはこのためです。インテリジェントルーターは、受信したプロンプトの接頭辞を検査し、そのコンテキストをキャッシュにすでに保持している特定の Pod に意図的にリクエストをルーティングします。冗長な作業にコンピューティング能力を無駄に費やすことがなくなり、レイテンシとスループットをハードウェアの物理的な上限に即座に近づけることができます。

5. 投機的デコーディング

重要な点として、デコードフェーズでは、メモリ帯域幅にボトルネックがあるため、テンソルコアはほとんどアイドル状態です。投機的デコーディングは、この無駄な計算能力を利用します。

小規模で高速な「ドラフト」モデルが、複数の候補トークンを低コストで生成します。その後、大規模なターゲットモデルが、すべての候補を単一のフォワードパスで検証します。これは、シーケンシャルメモリバウンドのオペレーションではなく、並列コンピューティングバウンドのオペレーションです。ドラフトモデルが候補を正しく予測した場合、1 トークンのメモリコストで 4～5 トークンを生成したことになります。

このアプローチにより直接、メモリ帯域幅によって設定された TBT の下限よりも短い TBT を達成できます。レイテンシの影響を受けやすいワークロードに投機的デコーディングを使用していない場合、利用可能な最も効果的な最適化の一つを活用できていないことになります。

ドラフトモデルを追加すると、運用が多少複雑になり、コンピューティング費用がわずかに増加する可能性がありますが、ドラフトモデルはメインモデルに比べて比較的小さなものです。これとレイテンシをトレードオフする価値はあります。

なお、一部の新しいモデルでは自己投機的デコーディングが導入されており、2 つ目のモデルを管理するオーバーヘッドがなくなります。これらのモデルは、将来の追加トークンを同時に予測するようにトレーニングされた特殊な内部レイヤ（多くの場合、予測ヘッドと呼ばれる）を使用します。これらのモデルは一般に、非常に有意義なトークンヒット率を達成します。

ケーススタディ: Vertex AI がフロンティアに近づいた方法

Vertex AI エンジニアリングチームは、標準の Kubernetes Gateway API を基盤として構築された GKE Inference Gateway を採用したときに、フロンティアに近づきました。Inference Gateway はレイヤ 7 でリクエストをインターセプトし、2 つの重要なインテリジェンスレイヤを追加しました。

負荷認識ルーティング: モデルサーバーの Prometheus エンドポイントからリアルタイムの指標（KV キャッシュ使用率やキューの深さなど）を直接スクレイピングしました。このプロセスでは、リクエストを最も迅速に処理できる Pod にルーティングします。
コンテンツ認識ルーティング: リクエストの接頭辞を検査し、そのコンテキストを KV キャッシュにすでに保持している Pod にトラフィックをルーティングしました。このプロセスでは、コストのかかる再計算を回避できます。

本番環境のワークロードをこのインテリジェントなルーティングアーキテクチャに移行したところ、ネットワークレイヤの最適化が、大規模なパフォーマンス向上を実現する鍵であることが、Vertex AI チームによって証明されました。本番環境のトラフィックで検証した結果は、以下のとおりです。

Qwen3-Coder（コンテキストの多いコーディングエージェントワークロード）で TTFT が 35% 短縮
DeepSeek V3.1（バースト性の高いチャットワークロード）の P95 テールレイテンシが 2 分の 1（52%）に改善
接頭辞キャッシュヒット率が 2 倍（35% から 70% に最適化）

まとめ

LLM 推論には効率的フロンティアがあります。効率的フロンティアとは、特定のコンピューティング予算に対してレイテンシとスループットの最適なバランスが取れた絶対的な境界を表します。

効率的フロンティアに到達することは、自分で制御できます。現在、継続的なバッチ処理、アテンションの分割、インテリジェント L7 ルーティング、投機的デコーディング、量子化、プレフィルとデコードの分離といった手法が存在します。GKE Inference Gateway のケーススタディでは、ハードウェア、モデル、クラスタサイズを変更せずに、ルーティングのみで、TTFT が 35% 短縮され、キャッシュ効率が 2 倍になったことが示されています。フルスタックを適用しない場合、運用は曲線を下回り、トークンごとに過剰な料金を支払うことになります。

フロンティア自体が外側に移動し続けています。この部分は、自分で制御できません。研究者は新しいアルゴリズムを発表し、ハードウェアベンダーは新しいアーキテクチャを出荷し、オープンソースのサービングフレームワークはこれらのアルゴリズムとアーキテクチャを統合します。18 か月前には最先端の最適化だったものが、今では基本的な必須事項となっています。次にどのようなブレークスルーが起こるかを予測するのではなく、ブレークスルーが起こったときにそれを吸収できる柔軟なインフラストラクチャを構築することが、あなたの仕事です。

推論エコノミクスで成功する組織は、GPU を最も多く保有している組織ではなく、現在のフロンティアとのギャップを体系的に埋めながら、明日のフロンティアに備える組織です。

これらの最適化手法をご自身の LLM 推論ワークロードに適用したことがある方は、その体験談をぜひお聞かせください。構築したものを LinkedIn、X、Bluesky で共有していただければ幸いです。

- デベロッパーリレーションズ担当ディレクター、Karl Weinmeister

AI リテラシーの新しい形: 学生デベロッパーを対象とした調査結果

Tue, 07 Apr 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 3 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

AI により、学生デベロッパーはかつてないレベルで作業を効率化し、難しい問題を解決したり、野心的なプロジェクトに取り組んだりできるようになりました。一方、この新技術の登場によって、技術専攻の学生たちは学習について本質的な問いに向き合うようになってきています。

それは、AI をどの程度、何に使用すべきか、という問題です。

Google の DORA 2025 レポートによると、現在、日々の業務で AI を使用している技術者は 90% に達しています。こうした状況の中で、次世代が AI ツールとどう付き合っているのかを理解することがこれまでになく重要になっています。カリフォルニア大学バークレー校の学生を対象とした Google の調査では、学業における不正行為や知的作業の省略といった懸念を覆す結果が明らかになりました。学生は AI を近道としてではなく、学習パートナーとして捉え、タスクによって意図的に使用したり、使用を控えたりしています。

AI がソフトウェア開発の基盤となるにつれ、AI ツールを導入するかどうかよりも、懸命な活用方法が焦点になってきています。カリフォルニア大学バークレー校の学生たちは、その答えの一つを示してくれます。それは、彼らのもつ好奇心や、慎重さ、学習に対する純粋な意欲を、AI は支えることはできても、取って代わることはできない、ということです。

調査

カリフォルニア大学バークレー校の 4 人の学生チーム（Andrew Harlan、Mindy Tsai、Kenny Ly Hong、Karissa Wong）が、学業での AI の利用状況を把握するため、コンピュータサイエンス、電気工学、デザイン、データサイエンス専攻の学生を対象に調査を実施しました。この調査には、混合手法を使用しています。

また、同校の別のチーム（Edward Fraser、Jessie Deng、Eileen Thai）が、デベロッパー歴 1～5 年の人々を対象に、アイトラッキング技術を使って AI コーディングアシスタントの使用状況を観察しました。両チームとも専任メンターの支援のもと調査を進め、混合手法調査については Google 社員の Harini Sampath、Becky Sohn、Derek DeBellis が、アイトラッキング調査についてはカリフォルニア大学バークレー校の John Chuang 教授（博士）が助言を行っています。

これらの調査から、学生が AI を活用すると同時に、真の専門知識を身につけるためにどのような方法をとっているのか、3 つの重要な結果が明らかになりました。学生の間で見られるパターンは、実際に開発職に就いている人々を対象にした DORA の調査結果とよく似通っています。

調査結果その 1: 24 時間 365 日、いつでも頼れる先生

AI は近道ではなく家庭教師

調査で AI との関係性について尋ねられた学生は皆一様に、学びの場ならではの言葉を使いました。AI のことを、アシスタントや生産性向上ツールではなく、「家庭教師」や「先生」と呼んでいたのです。

「AI は教師のような存在です。内容の濃い資料を解説してもらったり、データベースにあらかじめ記述されているコードを部分的に説明してもらったりするなど、プロジェクトの基礎的な部分について理解を深めるためにとても役立っています。」

「[AI を] お抱えの家庭教師として利用しています。授業や講義の特定のトピックの [理解を深める] ために。コンピュータサイエンスだけでなく、あらゆる授業で使っています。」

ここで重要なのは、学生が AI に依存せず、計画的に使用しているということです。AI に課題を完成させるのではなく、自分の理解度を踏まえて AI を使用し、知識の抜けを特定したり、不確かな概念を明らかにしたり、学習プロセスをリードしてもらったりしています。回答の中には、講義で取り上げられた複数の学術論文を要約してもらい、どれを深く読みこむべきかを判断するといった使い方や、コードでエラーが発生する理由を AI に説明してもらう、といったものがありました。

ある学生は、学習プロセスに次のように組み込んでいます。

「教授の説明がわからなかったときは AI に尋ねます。たとえば、ある概念や、コードの機能について説明してもらったりします。また、ラボのどこから手をつけたらよいかわからないときは、AI にプロンプトで尋ねます。それからコードを書き始め、修正すべき点を尋ねるといった具合です。」

学習障がいのある学生にとっては、常に利用できるという点が、不利な状況を克服するために役立っています。

「私は学習障がいがあるため、問題を理解するのに人より時間がかかります。AI にはすごく助けられています。24 時間 365 日、いつでも付いていてくれるサブ教師のような存在です。」

AI を使えば、学校の営業時間に縛られることなく、いつでも理解を掘り下げられます。AI のおかげで脳の処理能力に余裕が生まれ、より高度な思考が可能となります。

「実際にコーディングする時間は減り、全体のアイデアを練るのに時間をかけられるようになりました。今では、手動でコードを生成する代わりに、ロジックとコンセプトの検討や、アイデアの創出に時間を費やしています。」

こうしたコメントから、AI が最終的な作品を仕上げるためではなく、探索ツールとして利用されている様子が浮かび上がります。これは、DORA の調査結果と一致しています。調査によると、AI がルーチンワークを引き受けることで、デベロッパーはユーザーへの価値提供に専念できるようになっています。

調査結果その 2: 過度な依存に対する積極的な抵抗

学びのプロセスを守るために、境界線を設ける

学生たちは、AI を学習ツールとして活用する一方で、AI への過依存への不安を率直に表現しました。

「AI がなくなったら、自分で解決方法を探すのに苦労してしまうかもしれません。」

エッセイ執筆中の脳活動を脳波検査で測定した最近の研究では、AI の利用者は、検索エンジンやツールを使用しない人に比べ、認知エンゲージメントのパターンが弱いことがわかりました。また、AI のヘビーユーザーが、アシスタントを使わずにエッセイを書いてみたところ、以前に書いた作品についての記憶があまりなく、自分の作品であるという意識も低いことがわかりました。このことを、論文の著者は「認知の負債」と表現しています。1

一方で、ポジティブな兆候が明らかになりました。学生たちは、この認知上のリスクをただ受け入れるのではなく、意図的に境界線を設けて対応しています。

機械工学専攻のある学生は、電子機器を何年も使用するうちに、以下のように能力ベースの AI 使用ルールを確立したといいます。

「サーボや超音波などの基本的センサーなら自分でコーディングできますが、複雑なセンサーで、かつ、機能を厳密に把握する必要性がないときは、AI を使用します」と回答し、次のように説明しています。「何かがうまくいかないとき、その理由を理解できても、問題を解決するための直接的な言語を知らない場合があります。AI は、そのような状況で役立ちます。」

この学生は、最近携わったプロジェクト（触って操作できるストーリーテリングツールの構築）において、基本的なコンセプトを理解した後、カウントおよび比較のシステム構築のために助けを求めたとのことです。「AI は、基本構造のセットアップに大変役立ちましたが、その後、微調整のコーディングは自力でやる必要がありました。」また、作業の振り分けについては、次のように明確な意見を述べています。「自分でも引き続き、コードを書いています。技術者のように丸投げするわけではなく、AI と共同で作業を進め、私が司令塔となって AI にやってほしいことを指示します。ただやみくもにリクエストしても、まったく役に立ちません。」

学生が AI を利用する際には、明確な利用ルールを設けているケースが多く見られました。

「AI にはたまに、完全な答えではなく方向性だけを示すように頼みます。」

過度な依存を避けるため、学生は以下のような具体策を編み出しています。

高度なモデルの利用を避ける:

「料金制の AI ツールを使用するつもりはありません。AI モデルを使いすぎてしまう恐れがありますから。」

AI の使用、不使用を交互に繰り返す:

「for ループの処理など、一部の処理はまた自分で書くようになりました。」

「バイブコーディング」を警戒する:

「AI ツールがデベロッパーの生産性を高めるために役立つことは間違いありません。ただし、バイブコーディングに慣れてしまわないよう、十分な注意が必要です。AI が生成するコードを理解して検証し、適切な方法で使用するということが大前提です。」

こうした懸念は、学生たちが認知について意識的に考えているということを示しています。彼らは、一番楽な方法が最も学習効果が高いわけではないと認識しています。これは DORA の調査結果とも一致しています。調査によると、AI の導入率が 90% にのぼるにもかかわらず、利用者の約 30% が AI が生成したコードをほとんど（あるいはまったく）信用していないと答えています。AI を効果的に使用するには、単に導入するだけでなく、厳しい評価と検証の方法を習得することが求められます。

調査結果その 3: AI の使いどころを心得ている

アイトラッキングデータからわかったこと

アイトラッキング技術を使用した調査では、人の動作の面から検証を行いました。1～5 年の経験を持つデベロッパーを対象に、AI コーディングアシスタントとやり取りする様子を観察したところ、タスクの種類によって AI の利用に大きな違いがあることがわかりました。

思考と深い理解が必要なタスク: AI への視覚的注目が 1% 未満
機械的なタスク（ボイラープレートコードなど）: AI への視覚的注目が 19%

高度な作業においては、たとえ AI の提案が正確で時間の節約につながるような場合でも、敢えて無視されていることがわかりました。深い理解が必要なときは、AI は認知上の負担となります。熟練デベロッパーは、AI をオフにすべきときを心得ています。

すべてを任せるのではなく、意図的に取り入れる

学生への聞き取り調査からも、学生が AI を用途に応じて使い分けている様子が伺えます。

「私は普段、とっかかりとなるアイデアを得るために AI を使っています。」

「AI の使用が許可されていることは知ってましたが、学習と試行錯誤のプロセスを大事にしました。創造性の余地も必要です。」

カスタマイズが肝

現在、ほとんどの AI コーディングアシスタントは、インライン提案のオン / オフを切り替えたり、オンデマンド専用モードに設定したり、提案頻度を調整したりできます。これらの設定を試して、タスクとその認知要件に応じて AI を使い分けることで、ルーチンワークでは助けてもらいつつ、自分で深く考えたい仕事の邪魔をされないようにすることができます。

この調査結果が業界において意味すること

AI を利用した開発の未来を形作っていくのは、今の学生たちです

調査に協力してくれた学生たちは、時代の一歩先をいっており、すでに AI リテラシーを身につけています。用途に応じた使い分けや、出力の検証方法を心得ており、自らの理解力を維持するためにときには敢えて手動で作業するといった対策をとっています。AI 導入を検討中の方にとって、こうした学生の経験は、進むべき方向を探るヒントとなります。

さまざまなカスタマイズ設定を試す: 作業の妨げとならず、助けとなるような設定を見つけましょう。
ワークフローに検証プロセスを取り入れる: AI の提案を無批判に受け入れないようにしましょう。
自分の聖域を確保する: スピードよりも深い理解が重要となる高度な問題には、AI の助けを借りずに自分で取り組むようにしましょう。

業界の専門家が AI の導入をどのように進めているかについて詳しくは、2025 年 DORA レポート: AI 支援によるソフトウェア開発の現状をダウンロードしてご覧ください。カリフォルニア大学バークレー校の研究者との共同研究による論文全文もあわせてお読みいただけます。

^{1. Kosmyna, Nataliya, et al. "Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task." arXiv, 10 June 2025, doi:10.48550/arXiv.2506.08872.（参照日付: 2026 年 1 月 28 日）}

- Andrew Harlan 博士（独立系 UX リサーチャー兼クリエイティブテクノロジスト）

- Steve Fadden 博士（Google、UX リサーチ担当リード）

分散 AI エージェントの構築

Thu, 02 Apr 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 3 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

率直に言って、1 回だけ動作する AI エージェントを構築するのは簡単です。しかし、本番環境で確実に動作する AI エージェントを構築し、既存の React や Node.js アプリケーションと統合する場合は、まったく別の話です。

（説明は省略して、コードに直接移動したい場合は、GitHub のコース作成エージェントのアーキテクチャをご覧ください。）

身近な例で考えてみましょう。トピックを調査し、コンテンツを生成して、それを評価するという複雑なワークフローがあるとします。このワークフローを、1 つの巨大な Python スクリプトまたは大きなプロンプトに詰め込んだとしましょう。ローカルマシンでは正常に動作しましたが、スマートな外観のフロントエンドに接続しようとすると、厄介なことになります。レイテンシが急上昇し、デバッグが困難で、スケールするためにモノリス全体の複製が必要となります。

一方、AI に対応するために、アプリケーション全体を書き換える必要がないとしたらどうでしょうか。プラグを差し込むだけで使えるとしたら？

この投稿では、オーケストレーターパターンという優れた方法について説明します。具体的には、すべてを請け負う強力なエージェントを 1 つだけ作るのではなく、複数の特化した分散マイクロサービスから成るチームを構築します。このアプローチにより、モノリスの書き換えに悩まされることなく、強力な AI 機能を既存のフロントエンドアプリケーションに直接統合することが可能となります。

そのために、Google の Agent Development Kit（ADK）を使ってエージェントを構築し、Agent-to-Agent（A2A）プロトコルによって複数のエージェントを接続して相互通信し、Cloud Run 上でスケーラブルなマイクロサービスとしてデプロイします。

分散エージェントを使用する理由（フロントエンドチームに感謝される理由）

すでに完成された状態の Next.js アプリケーションがあるとします。これに、「コース作成ツール」という機能を追加したいとしましょう。

そのためにモノリスエージェントを構築すると、フロントエンドは、長時間かかる単一プロセスがすべて完了するまで待たされることになります。調査部分が滞ると、リクエスト全体がタイムアウトになります。また、個々のエージェントを必要に応じてスケールするといったこともできません。たとえば、評価エージェントがより多くの処理能力を必要とする場合、評価エージェントだけでなく、すべてのエージェントをスケールアップすることになります。

これに対し、分散オーケストレーターパターンを使用すれば、スケーラビリティと柔軟性が得られます。

シームレスなインテグレーション: フロントエンドは 1 つのエンドポイント（オーケストレーター）と通信し、オーケストレーターがバックグラウンドで複雑な処理を管理します。
個別にスケーリング: 評価ステップに時間がかかる場合は、そのサービスだけを 100 インスタンスにスケールアップし、調査サービスは小規模のままにできます。
モジュール式: 高パフォーマンスのネットワーキング部分を Go で、データサイエンス部分を Python で記述できます。これらの通信には HTTP を使用します。

全体的な設計: コース作成アプリ

では、コース作成システムを構築しましょう。以下の 3 つのスペシャリストに分けて考えます。

調査担当: 情報を掘り起こすスペシャリスト。
評価担当: 品質を保証する QA スペシャリスト。
オーケストレーター: 作業間の調整を行い、フロントエンドと通信するマネージャー。

ステップ 1: スペシャリスト（リサーチャー）の配備

まず、調査の担当者が必要です。ADK を使って、Google 検索の部分のみを担当するエージェントを構築しましょう。

code_block: <ListValue: [StructValue([('code', '# researcher/app/agent.py\r\nfrom google.adk.agents import Agent\r\nfrom google.adk.tools import google_search\r\n\r\nresearcher = Agent(\r\n name="researcher",\r\n model="gemini-2.5-flash",\r\n description="Gathers information on a topic using Google Search.",\r\n instruction="""\r\n You are an expert researcher. Your goal is to find comprehensive information.\r\n Use the `google_search` tool to find relevant information.\r\n Summarize your findings clearly.\r\n """,\r\n tools=[google_search],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2eda1040>)])]>

ご覧のように、とても簡単です。このエージェントは、コースやフロントエンドについては関知しません。調査のみを行います。

ステップ 2: 評価担当者（構造化されたデータ出力）

エージェントからの長ったらしい説明はいりません。コード側で判断しやすいよう、合格（pass）または不合格（fail）の厳密な評価が必要です。Pydantic を使って、このデータ規定を適用しましょう。

code_block: <ListValue: [StructValue([('code', '# judge/app/agent.py\r\nfrom pydantic import BaseModel, Field\r\nfrom typing import Literal\r\n\r\nclass JudgeFeedback(BaseModel):\r\n status: Literal["pass", "fail"] = Field(\r\n description="Whether the research is sufficient (\'pass\') or needs more work (\'fail\')."\r\n )\r\n feedback: str = Field(\r\n description="Detailed feedback on what is missing."\r\n )\r\n\r\njudge = Agent(\r\n name="judge",\r\n model="gemini-2.5-flash",\r\n description="Evaluates research findings.",\r\n instruction="""\r\n You are a strict editor. Evaluate the findings.\r\n If they are missing key info, output status=\'fail\' and provide feedback.\r\n """,\r\n output_schema=JudgeFeedback, # Enforce the contract!\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2eda1a90>)])]>

これで、評価担当者が JSON で話すようになり、アプリケーションロジックはそれを信頼できます。

ステップ 3: 共通言語（A2A プロトコル）

ここでマジックを使いましょう。A2A プロトコルを使って、これらのエージェントをウェブサービスとしてラップします。エージェントの共通言語のようなものとお考えください。エージェントは機能を説明し（agent.json）、標準の HTTP で通信します。

code_block: <ListValue: [StructValue([('code', '# researcher/app/server.py\r\nfrom fastapi import FastAPI\r\nfrom a2a.server.apps import A2AFastAPIApplication\r\nfrom app.agent import app as adk_app\r\n\r\n# ... setup runner ...\r\n\r\n# Create the A2A App wrapper\r\na2a_app = A2AFastAPIApplication(agent_card=agent_card, http_handler=request_handler)\r\n\r\napp = FastAPI(lifespan=lifespan)\r\n\r\n# Register routes: /.well-known/agent.json and /rpc\r\na2a_app.add_routes_to_app(app)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2eda1bb0>)])]>

これで、リサーチャー（ポート 8000 で実行されるマイクロサービス）を配備できました。このサービスを、オーケストレーターなど、あらゆるものから呼び出すことが可能です。

ステップ 4: オーケストレーターパターン

では、すべてを組み合わせましょう。オーケストレーターは、請負業者のようなものです。つまり、自分で調査を行わず、リサーチャーを雇います。自分で判断を下さず、評価担当者に尋ねます。

重要な点は、フロントエンドはこのエージェントのみを識別できればよいということです。

code_block: <ListValue: [StructValue([('code', '# orchestrator/app/agent.py\r\nfrom google.adk.agents import LoopAgent, SequentialAgent\r\nfrom google.adk.agents.remote_a2a_agent import RemoteA2aAgent\r\n\r\n# Connect to the remote Researcher service\r\nresearcher = RemoteA2aAgent(\r\n name="researcher",\r\n agent_card="http://researcher-service:8000/.well-known/agent.json",\r\n description="Gathers information on a topic."\r\n)\r\n\r\n# Connect to the remote Judge service\r\njudge = RemoteA2aAgent(\r\n name="judge",\r\n agent_card="http://judge-service:8000/.well-known/agent.json",\r\n description="Evaluates research findings."\r\n)\r\n\r\n# The Orchestrator manages the loop\r\nresearch_loop = LoopAgent(\r\n name="research_loop",\r\n sub_agents=[researcher, judge, escalation_checker],\r\n max_iterations=3,\r\n)\r\n\r\n# The full pipeline\r\nroot_agent = SequentialAgent(\r\n name="course_creation_pipeline",\r\n sub_agents=[research_loop, content_builder],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fdf2eda14f0>)])]>

オーケストレーターが複雑な処理（再試行、ループ、状態管理）を担当するため、フロントエンドはクリーンかつシンプルに保たれます。

デプロイ:「食料品店」モデル

このシステムを Cloud Run にデプロイすることを、私は「食料品店」モデルと呼んでいます。チェックアウトの列（リサーチャーのタスク）が長くなっても、新しい店舗を建設する必要はありません。レジを増やせばいいだけです。Cloud Run は、調査の負荷増大に対応するために調査サービスのみをスケールし、評価サービスはそのまま保たれます。

注意事項、セキュリティ上の配慮

もちろん、大いなる力には大きな責任が伴います（そして、セキュリティチェックが必要となります）。

認証: このデモでは、エージェントはオープンな HTTP を介して通信しています。本番環境では、このアクセスを制限する必要があります。mTLS、OIDC、または API キーを使用して、オーケストレーターのみがリサーチャーと通信できるようにします。
レイテンシ: ホップごとに時間が追加されます。オーケストレーターパターンは、詳細レベルの頻繁なインタラクションではなく、ざっくりとしたタスク（「このトピックを調査して」など）に使用するようにしましょう。
エラー処理: ネットワークにはエラーがつきものです。オーケストレーターには、タイムアウトと再試行を適切に処理できるような堅牢性が必要です。

構築を始めるにあたって

あらゆる作業を請け負う 1 つの巨大なエージェントを構築するのはやめましょう。オーケストレーターパターンと分散マイクロサービスを使用することで、スケーラブルで保守が容易な AI システムを構築できるだけでなく、既存のアプリとスムーズに連携できるというメリットも得られます。

コードについては、GitHub のコース作成エージェントのアーキテクチャで詳細をご確認ください。

準備ができたら、Cloud Run、ADK、A2A を使ってさっそくエージェントチームを結成しましょう。

- AI デベロッパーリレーションズエンジニア、Amit Maraj

マルチクラスタ GKE Inference Gateway のご紹介: 世界中で AI ワークロードをスケール

Wed, 25 Mar 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 3 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

AI の世界は急速に変化しており、モデルのサービングを大規模かつ確実に行う必要性も高まっています。このたび、マルチクラスタ GKE Inference Gateway のプレビュー版がリリースされましたのでお知らせいたします。これにより、複数の Google Kubernetes Engine（GKE）クラスタにわたり（異なる Google Cloud リージョンにまたがる場合も含め）、AI / ML 推論ワークロードのスケーラビリティ、復元力、効率性を強化できます。

GKE Gateway API の拡張機能として構築されたマルチクラスタ Inference Gateway は、マルチクラスタ Gateway の機能を活用して、特に要求の厳しい AI アプリケーション向けに、モデル対応のインテリジェントなロードバランシングを提供します。

AI 推論にマルチクラスタを使用する理由

AI モデルの複雑性が増し、ユーザーのグローバル化が進むにつれて、単一クラスタのデプロイでは次のような課題に直面する可能性があります。

可用性のリスク: リージョンの停止やクラスタのメンテナンスがサービスに影響を及ぼす可能性があります。
スケーラビリティの上限: 単一のクラスタまたはリージョン内で、ハードウェアの上限（GPU / TPU）に達してしまいます。
リソースのサイロ化: あるクラスタで十分に活用されていないアクセラレータ容量を別のクラスタで使用できません。
レイテンシ: サービスを提供しているクラスタから離れているユーザーはレイテンシが高くなる可能性があります。

マルチクラスタ GKE Inference Gateway は、これらの課題に正面から取り組み、次のようなさまざまな機能とメリットを提供します。

信頼性とフォールトトレランスの強化: 異なるリージョン間を含め、複数の GKE クラスタにわたってトラフィックをインテリジェントにルーティングします。1 つのクラスタまたはリージョンで問題が発生した場合、トラフィックは自動的に再ルーティングされ、ダウンタイムが最小限に抑えられます。
スケーラビリティの向上とリソース使用量の最適化: さまざまなクラスタから GPU / TPU リソースをプールして活用できます。単一クラスタの容量を超えてバーストすることで需要の急増に対応し、利用可能なアクセラレータをフリート全体で効率的に活用できます。
グローバルに最適化されたモデル対応のルーティング: Inference Gateway は、高度なシグナルを使用してスマートなルーティング判断を下すことができます。GCPBackendPolicy を使用して、リアルタイムのカスタム指標（モデルサーバーの KV キャッシュ使用率指標など）に基づいてロードバランシングを構成できるので、最適なバックエンドインスタンスにリクエストが送信されるようになります。処理中リクエストの制限など、他のモードもサポートされています。
運用の簡素化: モデルを複数の「ターゲットクラスタ」で実行しながら、専用の GKE「構成クラスタ」で 1 つの Inference Gateway 構成を使用して、グローバルに分散された AI サービスへのトラフィックを管理できます。

仕組み

GKE Inference Gateway には、InferencePool と InferenceObjective という 2 つの基本リソースがあります。InferencePool は、同じコンピューティングハードウェア（GPU や TPU など）とモデル構成を共有する Pod のリソースグループとして機能し、スケーラブルで高可用性のサービングを実現します。InferenceObjective は、特定のモデル名を定義し、サービングの優先順位を割り当てます。これにより、Inference Gateway はトラフィックをインテリジェントにルーティングし、レイテンシの影響を受けやすいタスクと緊急性の低いワークロードを多重化できます。

このリリースでは、Kubernetes カスタムリソースを使用して、分散推論サービスが管理されます。各「ターゲットクラスタ」の InferencePool リソースは、モデルサーバーのバックエンドをグループ化します。これらのバックエンドはエクスポートされ、「構成クラスタ」で GCPInferencePoolImport リソースとして表示されます。構成クラスタ内の標準の Gateway リソースと HTTPRoute リソースは、エントリポイントとルーティングルールを定義し、トラフィックをこれらのインポートされたプールに転送します。CUSTOM_METRICS や IN_FLIGHT リクエストの使用など、きめ細かいロードバランシングの動作は、GCPInferencePoolImport にアタッチされた GCPBackendPolicy リソースを使用して構成されます。

このアーキテクチャにより、グローバルな低レイテンシのサービング、障害復旧、容量のバースト、異種ハードウェアの効率的な使用などのユースケースが可能になります。

GKE Inference Gateway のコアコンセプトについて詳しくは、ガイドをご覧ください。

使ってみる

AI 推論サービングワークロードをより多くの場所とより多くのユーザーにスケールする際に、マルチクラスタ GKE Inference Gateway をぜひお試しください。詳細と利用方法については、次のドキュメントをご覧ください。

- シニアプロダクトマネージャー、Arman Rye

- シニアスタッフソフトウェアエンジニア、Andres Guedez

Vertex AI で復元力の高い LLM アプリケーションを構築し、429 エラーを減らす

Mon, 23 Mar 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 3 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。

Vertex AI で大規模言語モデル（LLM）を活用したアプリケーションを構築するのは楽しいことですが、429 エラーが発生すると、イライラの原因になることがあります。これらのエラーは、リクエストの受信速度が、その時点でサービスが処理できる量を上回っていることを示しています。

昨年、Google はこれらの 429 エラーの処理に関するガイドを公開しました。この記事では、Vertex AI の使用量モデルについて詳しく掘り下げ、リクエストフローを管理するためのアーキテクチャのベストプラクティスについて説明します。これにより、スムーズで復元力が高く、真にスケーラブルな AI アプリケーションを構築できます。

適切な使用量オプションの選択

Vertex AI は、さまざまなタイプとボリュームの API トラフィックに対応するように設計された、幅広い使用量モデルが用意されています。429 エラーを最小限に抑えるための主な戦略は、アプリケーション固有のトラフィックパターンに最も適した使用量モデルを選択することです。

デフォルトオプション: Vertex AI の Gemini におけるデフォルトオプションは、Standard 従量制（Paygo）です。Standard 従量制（Paygo）トラフィックの場合、Vertex AI は使用量ティアシステムを使用します。この動的なアプローチでは、共有プールからリソースが割り当てられ、組織の過去の費用に基づいて使用量ティアとベースラインスループット（TPM）が決まります。このベースラインにより、一般的なワークロードの予測可能なパフォーマンスの下限が決まるものの、アプリケーションは引き続きベストエフォートベースでそれ以上のパフォーマンスを発揮できます。

予測不可能で、Standard Paygo よりも高い信頼性を必要とする、重要なユーザー向けトラフィックをアプリケーションが生成する場合は、Priority Paygo が適しています。リクエストに優先度ヘッダーを追加することで、そのトラフィックを優先すべきであることを示し、スロットリングされる可能性を減らします。

リアルタイムトラフィックの量が常に多いアプリケーションの場合、共有 PayGo プールから分離できる使用量オプションはプロビジョンドスループット（PT）だけであり、PayGo における競合が激しい場合でもエクスペリエンスが安定します。PT では、保証されたスループットを予約して料金を支払うことで、重要なトラフィックがスムーズに流れるようにします。Vertex AI での PT について詳しくは、こちらのガイドをご覧ください。

費用対効果の高いオプション: Vertex AI には、レイテンシの影響を受けにくいトラフィック向けに、費用対効果の高いオプションが用意されています。Flex PayGo は、レイテンシが許容されるトラフィックに適しており、リクエストを低料金で処理します。オフライン分析や一括データ拡充などの大規模な非同期ジョブは、Batch で処理するのが最適です。このサービスは、スケーリングや再試行を含むワークフロー全体をより長い期間（約 24 時間）にわたって管理し、メインのアプリケーションをこの高い負荷から保護します。

複雑なアプリケーションとハイブリッドアプローチ: 複雑なアプリケーションでは、ハイブリッドアプローチがよく利用されます。PT は最も重要なリアルタイムトラフィック、Priority Paygo は変動するトラフィック、Standard Paygo は一般的なリクエスト、Batch / Flex はレイテンシが許容されるオフラインのリクエストフローに使用されます。

Vertex AI で 429 エラーを減らす 5 つの方法

1. スマート再試行の実装

アプリケーションで 429（リソース不足）や 503（サービス利用不可）などの一時的なオーバーロードエラーが発生した場合、すぐに再試行することは推奨されません。ベストプラクティスとして、ジッターを伴う指数バックオフと呼ばれる再試行戦略を実装できます。指数バックオフとは、再試行の間隔が指数関数的に長くなり、通常は事前定義された上限まで長くなることを意味します。これにより、サービスが過負荷状態から回復する時間を確保できます。

SDK とライブラリ: Google Gen AI SDK には、クライアントパラメータの HttpRetryOptions を使用して構成できるネイティブの再試行動作が含まれています。ただし、Tenacity（Python 用）などの専用ライブラリを活用したり、カスタムソリューションを構築したりすることもできます。詳しくは、こちらのブログ投稿をご覧ください。
エージェントワークフロー: エージェントを開発するために、Agent Development Kit（ADK）には Reflect and Retry プラグインが用意されています。このプラグインは、429 エラーを自動的にインターセプトすることで、AI ワークフローに復元力を組み込みます。
インフラストラクチャとゲートウェイ: Apigee によるサーキットブレーキングも、復元力を高めるためのもう一つの堅牢なオプションです。これにより、トラフィックの分散を管理し、正常な障害処理を実装できます。

2. グローバルモデルルーティングの活用

Vertex AI のインフラストラクチャは複数のリージョンに分散されています。デフォルトでは、特定のリージョンエンドポイントをターゲットにした場合、リクエストはそのリージョンから処理されます。これは、その単一リージョンの容量に基づいてアプリケーションの可用性が決まることを意味します。そして、グローバルエンドポイントが、可用性と復元力を高めるための効果的なツールとなります。グローバルエンドポイントは、1 つのリージョンに限定されるのではなく、可用性がより高い可能性のあるリージョンフリート全体にトラフィックをルーティングし、潜在的なエラー率を低減します。

3. コンテキストキャッシュによるペイロードの削減

Vertex AI の負荷を軽減する効果的な方法として、繰り返しクエリの呼び出しを避けることができます。多くの本番環境アプリケーション、特に chatbot やサポートシステムでは、似たような質問が頻繁に寄せられます。それらの質問を再処理する代わりに、コンテキストキャッシュを実装できます。コンテキストキャッシュ保存を使用すると、Gemini は事前に計算されたキャッシュトークンを再利用するため、API トラフィックとスループットを削減できます。これにより、費用を節約できるだけでなく、プロンプト内の繰り返しコンテンツのレイテンシも短縮されます。

4. プロンプトの最適化

各リクエストのトークン数を減らすと、TPM の使用量と費用が直接削減されます。

Flash-Lite による要約: Gemini Pro などのモデルに長い会話履歴を送信する前に、Gemini 2.5 Flash-Lite などの軽量モデルを使用してコンテキストを要約します。
エージェントメモリ最適化: エージェントワークロードでは、Vertex AI Agent Engine Memory Bank を活用できます。メモリーの抽出と統合などの機能により、会話から意味のある事実を抽出できるため、エージェントは未加工のチャット履歴がなくてもコンテキストアウェアな状態を維持できます。
プロンプトの衛生: プロンプトを確認し、詳細すぎる JSON スキーマの説明（モデルがすでに精通している場合）を減らし、過剰な空白や冗長な書式設定を削除します。

5. トラフィックのシェイプ

リクエストの急激なバーストは、429 エラーの主な原因です。平均トラフィックレートが低くても、急激に増加するとリソースに負荷がかかる可能性があります。目標は、トラフィックを平滑化し、長期間にわたってリクエストを分散することです。

使ってみる

ご紹介したパターンを実際に使用される場合は、 GitHub の Vertex AI サンプルを確認するか、Google Cloud 初心者向けガイドの Vertex AI クイックスタートを使用して次のプロジェクトをすぐに開始するか、Agent Development Kit（ADK）で次の AI エージェントの構築を開始してください。

- Google Cloud シニアプロダクトマネージャー、Richard Liu

- Cloud AI テクニカルエバンジェリスト、Pedro Melendez

Ollama、GKE の GPU 共有、vCluster を使って、費用対効果の高い AI を実現する

Tue, 17 Mar 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 3 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

組織が AI ワークロードをスケールすると、主に 2 つの課題が浮上します。1 つは、使用率の低い GPU に費用がかさむということ、もう 1 つは、複数チームの分離環境を管理運用するのが複雑であるということです。経験則として、GPU 全体を 1 つの Pod に割り当てるのは非効率です。また一方で、チームごとに個別のクラスタを管理すると、運用上の負担が大きくなるという問題があります。

この投稿では、Google Kubernetes Engine（GKE）の GPU タイムシェアリングと、マルチテナンシー用の vCluster を組み合わせて、この両方の問題を解決する方法を紹介します。具体的には、分離した複数の仮想環境に Ollama をデプロイしてオープンモデル（Mistral など）を提供し、これらの環境で 1 つの物理的な GPU インフラストラクチャを共有します。

アーキテクチャ: 共有ハードウェア上の仮想クラスタ

このアーキテクチャでは、GKE Autopilot を活用して物理インフラストラクチャを抽象化しています。ワークロードをデプロイすると、Autopilot が GPU やドライバなどの必要なハードウェアをオンデマンドでプロビジョニングしてくれるため、ノードの管理は不要です。

これにより複数のチームがそれぞれ分離された環境内で、API、Ollama インスタンスや、場合によっては異なるモデルを使用しながら、これらをすべて費用対効果の高い同じ共有 GPU ノードで実行することが可能となります。たとえば、チーム A（法務調査など）とチーム B（カスタマーサポートなど）が、GPU リソースを共有しながら、別々の環境で作業できます。

vCluster では、既存の Kubernetes クラスタ上に仮想 Kubernetes クラスタを作成できます。vCluster はさまざまなテナンシーモードをサポートしています。たとえば、この図に示されている共有ノードモデルでは、各仮想クラスタが独自の分離したコントロールプレーンを取得しながら、基盤となるワーカーノードを共有しています。個々の仮想クラスタには、そのクラスタへのフルアクセスを持つ管理者がアクセスでき、他のチームとの干渉は発生しません。このモデルでは、ホストクラスタ機能も適宜利用できるほか、各仮想クラスタ内に独自のコントローラや CRD をデプロイできます。

vCluster では、次のいずれかのテナンシーモードを使用できます。

共有ノード: このモードでは、複数の仮想クラスタが同じ物理 Kubernetes ノードでワークロードを実行できます。この構成は、リソース使用率の最大化が最優先のシナリオに最適です。特に、社内の開発環境、CI / CD パイプラインや、コスト重視のユースケースに適しています。
プライベートノード: このモードでは、ホストクラスタのワーカーノードを共有せず、個々の vCluster にそれぞれワーカーノードを追加します。これらのプライベートノードはその vCluster のワーカーノードとして機能し、同じホストクラスタ内の他の vCluster には共有されません。
自動ノード: ノードとリソースの要件に基づいて、ワーカーノードを自動的にプロビジョニングして追加するように vCluster を構成します。自動ノードを使用するには、vCluster Platform をインストールし、それに vCluster を接続する必要があります。
スタンドアロン: これは、コントロールプレーンとノードに関してアーキテクチャが異なるモードです。スタンドアロンモードでは、ホストクラスタは不要です。他の Kubernetes ディストリビューションと同様、vCluster はノードに直接デプロイされます。スタンドアロンの vCluster は、ベアメタルノードや VM など、あらゆるタイプのノードで実行できます。コントロールプレーンやワーカーノードの共有ホストクラスタがないため、ワークロードを最も厳格に分離できます。

デプロイ

デプロイ手順に沿って進めるには、次のものがインストールされていることを確認してください。

ステップ 1: GKE Autopilot クラスタを設定して作成する

GKE Standard とは異なり、ノード数を計算したり、ノードプールを手動で構成したりする必要はありません。自動的にクラスタが作成されて、認証情報が取得されます。

環境変数を設定し、GKE Autopilot クラスタを作成します。

export PROJECT_ID=YOUR_PROJECT_ID

export REGION=YOUR_REGION_ID

# GKE Autopilot クラスタを作成する

gcloud container clusters create-auto vcluster-gpu-sharing \

--region=$REGION --project $PROJECT_ID
YOUR_PROJECT_ID と YOUR_REGION_ID は、使用する Google Cloud プロジェクトとリージョンに置き換えます。
ローカルの kubectl を構成するために、認証情報を取得します。

gcloud container clusters get-credentials vcluster-gpu-sharing \

--region $REGION --project $PROJECT_ID

ステップ 2: 仮想クラスタ（vCluster）を作成する

Autopilot クラスタを実行すると、テナントに対して分離環境を作成できるようになります。ここでは、demo1 と demo2 の 2 つの vCluster を作成します。構成には vcluster.yaml マニフェストファイルが必要です。

GKE Autopilot を使用する場合、最初の vCluster の作成には数分かかることがあります。これは、独自のコントロールプレーンの Pod が稼働するのを待機するためです。Autopilot はこの新しいワークロードに対して基盤となるノードを動的にプロビジョニングするため、インフラストラクチャが初期化されるまで少々遅延が発生します。

code_block: <ListValue: [StructValue([('code', '# Create the vcluster configuration file\r\ncat <<EOF > vcluster.yaml\r\n# Place your vCluster configuration here. \r\n# For GPU workloads on GKE Autopilot, this typically involves \r\n# enabling node synchronization so the vCluster can see the \r\n# underlying GPU nodes provided by Autopilot.\r\nsync:\r\n fromHost:\r\n ingressClasses:\r\n enabled: true\r\n nodes:\r\n enabled: true\r\n toHost:\r\n ingresses:\r\n enabled: true\r\nEOF\r\n\r\n# Create the first virtual cluster\r\nvcluster create demo1 -n demo1 -f vcluster.yaml\r\n\r\n# Create the second virtual cluster\r\nvcluster create demo2 -n demo2 -f vcluster.yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf385bb820>)])]>

注: vCluster を別の vCluster 内に作成しようとしているというエラー警告が表示された場合は、[no] を選択して、正しいホストコンテキストに切り替えてください。

ステップ 3: Ollama を仮想クラスタにデプロイする

まず、Ollama のデプロイマニフェストを作成します。このマニフェストによって Ollama をデプロイし、Kubernetes Service を使用してポート 11434 で公開します。

Ollama のデプロイマニフェストを作成します。このマニフェストによって Ollama をデプロイし、Kubernetes Service を使用してポート 11434 で公開します。GPU タイムシェアリングを使用するノードを選択します。

# Ollama のデプロイマニフェストを作成する

cat <<EOF > ollama.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

name: ollama

namespace: default

spec:

replicas: 1

selector:

matchLabels:

app: ollama

template:

metadata:

labels:

app: ollama

spec:

nodeSelector:

# GPU タイムシェアリングを使用するノードを選択する。

# 基盤の GPU を一定数のコンテナで共有することを

# 許可するノードを選択する。

# Nvidia L4 GPU を搭載したノードを選択する。

cloud.google.com/gke-gpu-sharing-strategy: "time-sharing"

cloud.google.com/gke-max-shared-clients-per-gpu: "5"

cloud.google.com/gke-accelerator: nvidia-l4

containers:

- name: ollama

image: ollama/ollama:latest

ports:

- containerPort: 11434

resources:

limits:

nvidia.com/gpu: 1

---

apiVersion: v1

kind: Service

metadata:

name: ollama

namespace: default

spec:

selector:

app: ollama

ports:

- port: 11434

targetPort: 11434

type: ClusterIP

EOF
vCluster がアクティブになったら、コンテキストを切り替えて demo1 内で作業します。

# 仮想クラスタ demo1 に接続する

vcluster connect demo1 -n demo1
仮想環境に Ollama をデプロイします。

# デプロイマニフェストを適用する

kubectl apply -f ollama.yaml
仮想クラスタ内にいても、GPU をリクエストする Pod を作成すると、このリクエストはホストに同期されます。GKE Autopilot はこのリクエストを検出し、ワークロードを実行するノードに必要な GPU ハードウェアを自動的にアタッチします。

ステップ 4: モデルの pull とテスト

サーバーが実行されたら、仮想クラスタのコンテキスト内で、モデルの pull とテストを実行します。

# Pod 内で pull コマンドを実行する

kubectl exec -it <pod-name> -- ollama pull mistral
API を検証します。

# Ollama サービスをポート転送する

kubectl port-forward svc/ollama 8080:11434

# 新しいウィンドウでチャットリクエストを送信する

curl -s http://localhost:8080/api/chat \

-H "Content-Type: application/json" \

-d '{ "model": "mistral", "stream": false, "messages": [ {"role": "user", "content": "Explain GKE Autopilot"} ] }' | jq -r '.message.content'

ステップ 5: Ollama を vCluster demo2 にデプロイする

同じ手順を繰り返して、Ollama をデプロイし、モデルを 2 つ目の仮想クラスタに pull します。

code_block: <ListValue: [StructValue([('code', '# 仮想クラスタに接続する\r\nvcluster connect demo2 -n demo2\r\n\u200b\r\n# デプロイマニフェストを適用する\r\nkubectl apply -f ollama.yaml\r\n\u200b\r\n# Pod 内で pull コマンドを実行する\r\nkubectl exec -it <pod-name> -- ollama pull mistral\r\n\u200b\r\n# Ollama サービスをポート転送する\r\nkubectl port-forward svc/ollama 8080:11434\r\n\u200b\r\n# 新しいウィンドウでチャットリクエストを送信する\r\ncurl -s http://localhost:8080/api/chat \\\r\n-H "Content-Type: application/json" \\\r\n-d \'{ "model": "mistral", "stream": false, "messages": [ {"role": "user", "content": "Explain GKE Autopilot"} ] }\' | jq -r \'.message.content\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdf385bb970>)])]>

基盤となるインフラストラクチャを検証する

それでは、ホストクラスタのコンテキストに戻って、何が起こっているかを確認しましょう。

プロビジョニングされたノードの数と、Ollama Pod が実行されている場所を確認します。

# 利用可能なコンテキストを一覧表示する

kubectx

# ホストクラスタのコンテキストに切り替える

kubectx gke_$PROJECT_ID_$REGION_vcluster-gpu-sharing

# ノードを一覧表示する

Kubectl nodes
2 つのノードが表示されるはずです。1 つは vCluster コンポーネントを実行しています。もう 1 つは、L4 GPU を使用して Ollama インスタンスを実行しています。出力は次のようになります（ノード名は異なります）。

# kubectl get nodes の出力

$ kubectl get nodes

NAME STATUS ROLES AGE VERSION

gk3-vcluster-gpu-sharing-nap-1w88cyly-895203e4-xbqk Ready <none> 7h8m v1.33.5-gke.2072000

gk3-vcluster-gpu-sharing-pool-2-0a984fed-7mff Ready <none> 4d v1.33.5-gke.2072000
Ollama Pod が実行されている場所を確認します。

# Ollama Pod を実行しているノードを確認する

kubectl get pods -n demo1 -o wide

kubectl get pods -n demo2 -o wide
両方の Ollama Pod が同じノードで実行されていることに注目してください。このノードは GKE Autopilot によってプロビジョニングされ、L4 GPU と GPU 共有を使用するように構成されています。

まとめ

この例では、GKE Autopilot を使用することで、GPU ノードプールやタイムシェアリングを手動で構成せずに済んでいます。Autopilot によってリソースが動的に提供される一方で、vCluster によって、チーム A の法務調査データとチーム B のカスタマーサポートの bot が完全に分離されています。この実装方法により、AI ワークロードのスケーリングにおいて堅牢でメンテナンスの少ないプラットフォームを実現できます。

- シニアクラウドデベロッパーアドボケイト、Abdel Sghiouar

- vCluster デベロッパーリレーションズ、 Saiyam Pathak

プロダクションレディな AI エージェントに関するデベロッパーガイド

Tue, 17 Mar 2026 00:00:00 +0000

※この投稿は米国時間 2026 年 2 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。

この 1 年間で、デベロッパーコミュニティに変化が生じました。AI エージェントは、「興味深い研究コンセプト」から「チームが実際に構築しているもの」へと進化したのです。プロトタイプは機能しています。デモが示す可能性には目を見張るものがあります。ところが、ここで難題が持ち上がります。AI エージェントをどのようにリリースすればよいのでしょうか？

この問いは多面的です。エージェントは従来のソフトウェアのようには動作しません。推論し、行動し、適応するという性質から、エージェントにはテスト、メモリ、オーケストレーション、セキュリティに対して異なるアプローチが求められます。決定的なコードで有効だったパターンをそのまま適用することはできません。

開発者がこれらの課題を解決できるよう、Google はエージェントのライフサイクル全体を網羅したガイド集を公開しました。これらのリソースは、Kaggle の 5 日間 AI エージェント集中講座で初めて公開されました。そこで非常に高い人気と有用性が確認されたことから、より多くのユーザーに向けて公開する運びとなりました。

これらのガイドでは、実用的なフレームワークとコードサンプルが提供されており、自身のプロジェクトに合わせて柔軟に適用できます。以下では、エージェントのアーキテクチャから本番環境へのデプロイまで、主要なコンセプトを順を追って説明します。それに基づき、どのテーマについてより深掘りすべきかを判断してください。

エージェントとは

エージェントの中核をなすものは、推論、行動、経時的な改善を行う自律的なエンティティです。エージェントの頭脳は大規模言語モデルです。これは、タスクを理解し、回答を生成し、コンテキストに基づいて意思決定を行う認知エンジンです。エージェントは静的なツールとは異なり、動作する中で適応します。思考、行動、観察という再帰的なループに基づいて機能します。各サイクルでエージェントは進歩し、その過程でアプローチを洗練させます。

この中核の周囲にあるのがオーケストレーションレイヤであり、これは通信とデータフローを管理する神経系の役割を果たします。専門的なツールや外部サービスを調整する指揮者のようなものです。これには、即座に思い出すための短期記憶（セッションの状態）、過去のインタラクションを保持するための長期記憶（メモリサービス）、情報検索（RAG）、外部の世界でアクションを実行するためのモジュール（ツールの使用）などが含まれます。セキュリティフレームワークにより、エージェントが安全に、意図された境界内で動作することが保証されます。このアーキテクチャの目的は、インテリジェントで有用かつ信頼できるアシスタントを作成することです。

これらの基本コンセプトの詳細については、エージェントの概要に関するガイドをご覧ください。

ツールと相互運用性

エージェントが真に有用であるためには、ツール、データソース、他のエージェントとやり取りできる必要があります。2 つの新しいプロトコルが、そうした接続に対する標準化されたアプローチを提供します。

Anthropic の Model Context Protocol（MCP）により、エージェントは外部のデータソースやステートレスツールに標準化された方法で接続できます。デベロッパーは、サービスごとにカスタム統合を構築する代わりに、MCP の標準化されたインターフェースを使用して開発を簡素化し、相互運用性を向上させることができます。

Google の Agent2Agent プロトコル（A2A）はさらに一歩踏み込み、基盤となるフレームワークにかかわらずエージェント間の直接通信を可能にします。A2A を使用するエージェントは、安全かつ構造化されたメッセージの交換を通じて、互いの能力を把握し、やり取りの方法を交渉し、連携してタスクを処理します。

これらのプロトコルを組み合わせることで、ツール、データ、他のエージェントとの接続を通じてより広範なエコシステム内で動作するエージェントの基盤が構築されます。ツールと MCP による相互運用性に関するガイドでは、実装例とともにこれら 2 つのプロトコルについて詳しく説明しています。

コンテキストエンジニアリング

LLM がエージェントの脳であるとすれば、コンテキストエンジニアリングは、適切な情報を適切なタイミングで LLM に提供する手法です。これには、プロンプト設計、検索メカニズム、ツールの選択、会話履歴など、エージェントが各リクエストを理解して応答する方法を形作るすべてのものが含まれます。

コンテキストエンジニアリングにより、汎用モデルがパーソナライズされたアシスタントに変わります。コンテキストエンジニアリングは、どのメモリを取得するか、どのツールを提供するか、各インタラクションをどのように構成するかを決定します。効果的なコンテキストエンジニアリングにより、複数のセッションをまたいで一貫性を保持する有用なエージェントが作成されます。コンテキストエンジニアリングが実装されない場合、エージェントは記憶を忘却したり、同じことを繰り返したり、的外れな回答を返したりすることになります。

コンテキストエンジニアリングガイドでは、コンテキストエンジニアリングのフレームワークと実装のための実用的な手法について説明しています。

テストと評価

自律エージェントには、品質保証に対する新しいアプローチが必要です。エージェントが独自の判断を下す場合、その成否は正しい出力を生成できるかという点だけでなく、プロセス全体にわたって正しい判断ができているかという点にもかかっています。

エージェントを評価するにあたっては、最終的な回答の正しさだけでなく、エージェントが結果に至るまでに行う一連の意思決定と行動の軌跡に重点が置かれます。2 つのエージェントがまったく異なる経路で同じ結論に達する可能性があり、その経路を理解することが重要です。優れた評価では、ツールの選択、推論の質、エラー回復、エージェントが明確化のための質問をすべきときに質問したかどうかを調べます。

実用的な評価アプローチには、個々のコンポーネントの単体テスト、複数ステップの意思決定シーケンスの軌跡分析、サンドボックスからカナリア、本番環境への段階的な公開が含まれます。各ステージでは、より多くのユーザーに公開する前に、エージェントの動作のさまざまな側面を検証します。

評価フレームワークとテスト方法の詳細については、エージェントの品質ガイドをご覧ください。

エージェントの本番環境へのデプロイ

プロトタイプから本番環境に移行するには、エージェント固有のニーズに合わせて設計されたインフラストラクチャが必要です。状態を維持し、ツールを動的に使用し、自律的に動作するシステムを実現するには、従来型のデプロイパターンに適応性を持たせることが求められます。

本番環境のエージェントには、インタラクション全体でコンテキストを維持するためのセッション管理、長期記憶のための永続的なメモリシステム、適切な認証と権限によるツール統合、エージェントの意思決定とアクションを追跡するためのリアルタイムのロギングが必要です。

ほとんどのチームは、内部テスト用のサンドボックス、限定的な実環境でのテスト用のカナリア、完全なロールアウト用の本番環境という段階でデプロイします。各ステージでパフォーマンスを検証し、アクセスを拡大する前に問題を検出します。

プロトタイプから本番環境へのガイドでは、プロダクションレディなエージェントインフラストラクチャを構築するためのアーキテクチャに関するガイダンスとコードサンプルを提供しています。

出発点

どこから始めるべきかは、お客様の取り組みの段階によって異なります。エージェントの概要ガイドでは基本的なコンセプトを説明し、ツールと MCP による相互運用性やコンテキストエンジニアリングのガイドでは構築の実践的な課題を取り上げます。検証とリリースを行う準備ができた段階では、エージェントの品質とプロトタイプから本番環境へのガイドが役立ちます。

エージェントの分野は急速に進化していますが、一人で解決する必要はありません。現在の課題に合ったリソースを選んで、構築を始めましょう。

- テクニカルソリューションマネージャー、Kanchana Patlolla

- Google、シニアスタッフ ML エンジニア兼生成 AI 集中講座創設者、Anant Nawalgaria

RAG 対応生成 AI アプリケーションのプライベートネットワーク接続の設計

Fri, 13 Mar 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 3 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud は柔軟性に優れており、企業が AI ワークロード向けに安全で信頼性の高いアーキテクチャを構築することを可能にします。この投稿では、検索拡張生成（RAG）対応生成 AI アプリケーションのプライベート接続のリファレンスアーキテクチャについて説明します。このアーキテクチャは、システム全体で通信にプライベート IP アドレスを使用する必要があるようなシナリオで、通信がインターネットを通過してはならないような場合に適しています。

RAG の効力

RAG は、大規模言語モデル（LLM）の出力を最適化するために使用されるパワフルな手法であり、LLM の出力を、元のトレーニングデータ以外の特定の信頼できるナレッジベースにグラウンディングできます。アプリケーションから RAG を使って、ドキュメント、データソース、データベースから関連情報をリアルタイムで取得することができます。ここで取得したコンテキストは、ユーザーのクエリとともにモデルに提供されます。これにより、AI の回答を正確で検証可能なものにするとともに、業務内容との関連性を高めます。この仕組みによって、回答の質が向上し、ハルシネーションが減少します。

このアプローチは、生成 AI においてモデルの既存の知識のみに依存することなく、指定された信頼できる情報源を使用できるため、モデル自体を再トレーニングやファインチューニングしなくて済むという点で利便性に優れています。

設計パターンの例

RAG アプリケーションのプライベート接続向けにネットワークを設定するということを念頭におきながら、このようなリージョン設計のパターンを見ていきましょう。

このネットワークは、外部ネットワーク（オンプレミスおよび他のクラウド）と Google Cloud 環境で構成されています。Google Cloud 環境は、ルーティングプロジェクト、RAG 用の共有 VPC ホストプロジェクト、3 つの特化したサービスプロジェクト（データ取り込み、サービング、フロントエンド）で構成されています。

この設計では、次のサービスを使用してエンドツーエンドのソリューションを提供します。

Cloud Interconnect または Cloud VPN: オンプレミスまたは他のクラウドからルーティング VPC ネットワークに安全に接続する
Network Connectivity Center: VPC スポークおよびハイブリッドスポークを介して、ルーティング VPC ネットワークと RAG VPC ネットワーク間の接続を管理するオーケストレーションフレームワーク
Cloud Router: ルーティングプロジェクト内で、外部ネットワークと Google Cloud 間の動的な BGP ルート交換を行う
Private Service Connect: ルーティング VPC ネットワークにプライベートエンドポイントを提供し、パブリックインターネットを経由せずに Cloud Storage バケットにアクセスしてデータを取り込めるようにする
共有 VPC: 複数のサービスプロジェクトで、共通の一元的な VPC ネットワークを使用できるようにするホストプロジェクトアーキテクチャ
Google Cloud Armor とアプリケーション ロードバランサ: フロントエンドサービスプロジェクトに配置され、ユーザーインタラクションに対してセキュリティとトラフィック管理を提供する
VPC Service Controls: すべてのリソースの周囲にマネージドセキュリティ境界を作成し、データ漏洩のリスクを軽減する

トラフィックフロー

RAG の挿入フロー

上の図の緑色の点線が RAG の挿入フロー（データエンジニアからベクトルストレージへとデータが移動する仕組み）を表しています。

外部ネットワークからのデータが、Cloud Interconnect または Cloud VPN 経由で渡されます。
ルーティングプロジェクト内の Private Service Connect エンドポイントを使って Cloud Storage バケットにアクセスします。
データ取り込みサービスプロジェクト内のデータ取り込みサブシステムが Cloud Storage バケットからの元データを処理します。
AI モデルがチャンクからベクトルを作成し、データ取り込みサブシステムに返します。データ取り込みサブシステムはこれを受け、サービングサービスプロジェクトの RAG データストアに書き込みます。

推論フロー

上の図のオレンジ色の点線が推論フロー（お客様またはユーザーのリクエスト）を表しています。

リクエストは、Cloud Interconnect または Cloud VPN 経由でルーティング VPC ネットワークに渡され、その後、VPC スポーク経由で RAG VPC ネットワークに渡されます。
リクエストは、Cloud Armor で保護されたアプリケーションロードバランサ に到達し、許可されるとフロントエンドサブシステムに渡されます。
フロントエンドサブシステムはリクエストをサービングサブシステムに転送します。サービングサブシステムは、RAG データストアのデータでプロンプトを拡張し、AI モデルを介して回答を生成します。
上記によってグラウンディングされた回答が、リクエスト元に同じパスで返されます。

管理とルーティング

上の図の青い点線は、Network Connectivity Center のハイブリッドスポークと VPC スポークが、ルーティングネットワークと RAG VPC ネットワーク間のコントロールプレーンとルートオーケストレーションを管理する様子を表しています。これにより、外部ネットワークから学習したルートが環境全体に適切に伝播されます。

IAM 権限、VPC Service Controls、デプロイに関する考慮事項などについて詳しくは、アーキテクチャドキュメント「RAG 対応生成 AI アプリケーションのプライベート接続」をお読みください。

次のステップ

クロスクラウドネットワークの詳細や、RAG を使用した生成 AI に関する以下のガイドをご覧ください。

ご質問やご意見がございましたら、Linkedin 経由で筆者までご連絡ください。

- デベロッパーリレーションズエンジニア、Ammett Williams

エージェント型 chatbot に高速で信頼性の高い長期メモリを提供

Thu, 12 Mar 2026 00:00:00 +0000

※この投稿は米国時間 2026 年 2 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

会話エージェントを大規模展開する際は、データレイヤの設計が成否を左右することが少なくありません。数百万人規模のユーザーを支えるには、会話の継続性が欠かせません。つまり、応答性の高いチャットを維持しつつ、バックエンドのモデルが必要とするコンテキストも保ち続ける能力です。

この記事では、Google Cloud のソリューションを用いて、AI の 2 つのデータ課題（リアルタイムチャットのコンテキスト更新を高速化すること、長期履歴の検索を効率化すること）をどう解決するかをご紹介します。また、Redis、Bigtable、BigQuery を組み合わせるポリグロットなアプローチにより、直近のやり取りから数か月前のアーカイブまで、エージェントが細部と文脈の連続性を保てるようにする方法も解説します。

短期、中期、長期の履歴に対応するポリグロットストレージアプローチ

ポリグロットアプローチとは

ポリグロットアプローチとは、単一のデータベースに集約するのではなく、用途に特化した複数のデータサービスを組み合わせ、データのライフサイクルに応じて使い分ける多層型のストレージ戦略です。これにより、たとえば、高速化のためのインメモリキャッシュ、大規模データを扱うための NoSQL、非構造データを置くための Blob ストレージ、分析のためのデータウェアハウスといったように、それぞれの強みを活かしながら、データの「鮮度」や量に応じて効率的に処理できます。

短期、中期、長期メモリに対する Google Cloud での定義例

会話の継続性を保つため、Google Cloud 上では次のように組み合わせて、このポリグロットアプローチを実装できます。すなわち、ミリ秒未満で「ホット」なコンテキストを取得する用途には Memorystore for Redis を、永続的な履歴を蓄積するペタバイト規模の記録基盤には Cloud Bigtable を、長期アーカイブや分析的な洞察には BigQuery を用います。また、画像や音声などの非構造マルチメディアは Cloud Storage で扱い、Pub/Sub と Dataflow による非同期パイプラインで連携させます。

1. 短期メモリ: Memorystore for Redis

ユーザーは、新しいチャットを開始する場合でも、以前の会話を続ける場合でも、チャット履歴が瞬時に読み込まれることを期待しています。会話のコンテキストについては、Memorystore for Redis が主要なキャッシュとして機能します。フルマネージドのインメモリデータストアである Redis は、自然な会話の流れを維持するために必要なサブミリ秒レベルの低レイテンシを提供します。チャットセッションはメッセージが順次追加されていくリスト構造のため、履歴は Redis リストを使って保存します。ネイティブの RPUSH コマンドを使えば、アプリケーションは最新のメッセージだけを追加すればよく、Memcached のような単純なストアで発生しがちな「読み取り → 更新 → 書き込み」というネットワーク負荷の大きい処理を避けることができます。

2. 中期メモリ: Cloud Bigtable

会話が時間とともに増えていくにつれ、エージェント型アプリケーションは、増え続けるチャット履歴をより大規模に、かつ長期的に保存できる設計を考える必要があります。そこで、Bigtable が、永続性を備えた中期ストアとして、また全チャット履歴の正式な記録として機能します。Bigtable は、高速で書き込みが集中するワークロード向けに設計されたペタバイト級の NoSQL データベースで、数百万件の同時チャットを取り込む用途に適しています。大量のデータを扱いつつも、ガベージコレクションポリシーを設定すれば、アクティブなクラスタを必要最小限に保てます。たとえば、高性能ティアには直近 60 日分だけ残すといった運用が可能です。検索を高速化するため、キーは user_id#session_id#reverse_timestamp というパターンで設計します。これにより、同一セッションのメッセージが近接して格納され、範囲スキャンで直近のメッセージを効率よく取り出せるため、履歴の再読み込みがスムーズになります。

3. 長期メモリと分析: BigQuery

アーカイブと分析のため、データは BigQuery に移されます。BigQuery は、このシステムにおける長期メモリの役割を担います。Bigtable が稼働中のアプリケーション向け処理に最適化されているのに対し、BigQuery は大規模な複雑 SQL クエリを実行するために設計された Google のサーバーレス型データウェアハウスです。これにより、チームは単なるログ保存にとどまらず、そこから分析的なインサイトを引き出せるようになります。最終的には、この運用データがフィードバックループとして機能し、ユーザー向けコンポーネントのパフォーマンスに影響を与えることなく、エージェントやユーザー体験の改善につながります。

4. アーティファクトストレージ: Cloud Storage（GCS）

ユーザーが分析のためにアップロードしたものでも、生成モデルが生成したものでも、画像や音声などの非構造データ（マルチメディアファイル）は、非構造アーティファクトの保管に適した Cloud Storage に格納します。ここではポインタ戦略を採用します。Redis や Bigtable のレコード側には、実体データそのものではなく、オブジェクトを指し示す URI（例: gs://bucket/file）を保持します。セキュリティ面では、アプリケーションが署名付き URL を使ってファイルを配信し、バケットを公開することなく、クライアントに期限付きのアクセス権だけを付与します。

データの流れを最適化するハイブリッド同期 / 非同期戦略

以下のシーケンス図で示すとおり、このハイブリッド同期 / 非同期戦略では、前述のストレージ群を組み合わせることで、高速で整合性のある処理と耐久性のある永続化を両立させます。

次の図は、ユーザーのメッセージと、それに対応するエージェントの応答が、アーキテクチャ内をどのように流れていくかを示しています。

次の図は、ユーザーが特定のセッションのチャット履歴を取得する際に、データがアーキテクチャ全体をどのように流れるかを示しています。

今すぐ構築を開始

堅牢な永続化レイヤを備えたエージェントを構築する準備はできていますか？

エージェントをすばやく構築: Vertex AI Agent Builder を使って、エージェント型ワークフローのプロトタイピングを始めましょう。
キャッシュを構成する: レイテンシと可用性の要件に合わせて、最適な Memorystore for Redis の構成を決定します。
堅牢な Bigtable スキーマを設計する: スキーマ設計のベストプラクティスを確認しましょう。
分析へつなぐ: Bigtable の Change Stream から BigQuery へのテンプレートを活用し、ライブチャットログを実用的なビジネスインサイトへと変換します。
分析でデータを活用する: Looker Conversational Analytics を使って、ビジネスインテリジェンスに基づいたプロダクトの意思決定を行いましょう。

- AI ソリューションアクセラレーションアーキテクト Aishwarya Prabhat

- プリンシパルアーキテクト Yun Pang

デベロッパー

Gemini CLI DevOps 拡張機能を使用して、わずか数分でコードをリリース

Cosmic Guestbook アプリを構築する

拡張機能をインストールする

仕組み

インナーループ

アウターループ

セキュリティと管理

開発と運用の融合

次のステップ

AI を活用したコード移行の先駆け: Google が TensorFlow から JAX への移行を 6 倍高速化した方法

TF から JAX への移行を加速

単一エージェント コーディングからの脱却

スケーラブルな検証と柔軟な Playbook

移行のスピードを革新

AI を活用する時代の展望

Next ’26: Google Cloud と Wiz が AI 時代のセキュリティを再定義

エージェント型防御の提供

あらゆるインフラストラクチャで、AI とクラウド アプリケーションを保護

AI エージェントとエージェント型ウェブの保護

Trusted Cloud の新機能

次のステップ

DevOps × AI Agent Hackathon 2026: AI エージェントを「つくる、まわす、とどける」夏

企画から運用までを一気通貫で体験する「つくる、まわす、とどける」3 つのコンセプト

チームビルディング、Bootcamp、審査員フィードバック ― 学びを底上げする 3 つの仕掛け

ハッカソンに挑むみなさんへ

エージェントを強化する: Google 公式 Skills リポジトリを発表

次世代のエージェントを推進する Gemini Enterprise Agent Platform を発表

お客様が Gemini Enterprise Agent Platform で実現していること

AI エージェントの構築

AI エージェントの拡張

AI エージェントのガバナンス

AI エージェントの最適化

BigQuery、Pub/Sub、ADK を使用したイベント ドリブン データ エージェントの構築

リアルタイムの自律エージェントの必要性

イベント ドリブン データ エージェントの登場

ハイブリッド アーキテクチャ: 仕組み

パート 1: BigQuery の継続的クエリ

パート 2: Pub/Sub と単一メッセージ変換（SMT）

パート 3: ADK と Vertex AI Agent Engine

すべてを 1 つに: エージェント分析

まとめ

実際に使ってみる準備はできましたか？

Google Cloud のアプリケーション ロードバランサへの移行: 実践ガイド

シンプルで段階的な移行アプローチ

スムーズな移行のためのベスト プラクティス

データレイヤの有効化によるプロダクション レディな AI の実現

セマンティック検索: データベース内のテキスト エンベディング

マルチモーダル エンベディング: 検索に画像を取り入れる

AlloyDB AI 関数と再ランキング

AlloyDB AI の自然言語を使用して SQL を生成する

テストから本番環境へ

Envoy: エージェント型 AI ネットワーキングのための将来を見据えた基盤

エージェント型 AI がネットワーキングの問題を変える

Envoy がこの移行に対応できる理由

1. Envoy はエージェント トラフィックを理解する

2. Envoy は重要な事項に関するポリシーを適用する

3. Envoy はステートフルなエージェントのインタラクションを大規模にサポートする

4. Envoy はエージェントの検出をサポートする

5. Envoy はエージェント ネットワーキングの課題に対する包括的なソリューション

コントロール プレーンがこれを運用可能にする

このソリューションが重要な理由

Google ADK、MCP、Cloud Run を使用して専門家向けコンテンツ用のマルチ エージェント システムを構築する - パート 1

学習内容

Dev Signal の概要

前提条件

プロジェクトのセットアップ

1. プロジェクトを初期化する

2. フォルダ構造

3. 依存関係を定義する

エージェント機能の構築: MCP ツール

ツールの構成

Reddit 検索（発見ツール）

Google Cloud ドキュメント（ナレッジツール）

画像生成ツール（Nano Banana MCP）

Nano Banana Pro サーバー ロジックの実装

サーバー エントリポイント（main.py）

生成ロジック（nano_banana_pro.py）

GCS アップロード ヘルパー（storage_utils.py）

データモデル（media_models.py）

単一エージェントコーディングからの脱却

あらゆるインフラストラクチャで、AI とクラウドアプリケーションを保護

BigQuery、Pub/Sub、ADK を使用したイベントドリブンデータエージェントの構築

イベントドリブンデータエージェントの登場

ハイブリッドアーキテクチャ: 仕組み

Google Cloud のアプリケーションロードバランサへの移行: 実践ガイド

スムーズな移行のためのベストプラクティス

データレイヤの有効化によるプロダクションレディな AI の実現

セマンティック検索: データベース内のテキストエンベディング

マルチモーダルエンベディング: 検索に画像を取り入れる

1. Envoy はエージェントトラフィックを理解する

5. Envoy はエージェントネットワーキングの課題に対する包括的なソリューション

コントロールプレーンがこれを運用可能にする

Google ADK、MCP、Cloud Run を使用して専門家向けコンテンツ用のマルチエージェントシステムを構築する - パート 1

Nano Banana Pro サーバーロジックの実装

サーバーエントリポイント（`main.py`）

生成ロジック（`nano_banana_pro.py）`

GCS アップロードヘルパー（`storage_utils.py）`

データモデル（`media_models.py`）

ツールの依存関係（`requirements.txt）`

分散エージェントを使用する理由（フロントエンドチームに感謝される理由）

ステップ 4: オーケストレーターパターン

プロダクションレディな AI エージェントに関するデベロッパーガイド

RAG 対応生成 AI アプリケーションのプライベートネットワーク接続の設計

トラフィックフロー

短期、中期、長期の履歴に対応するポリグロットストレージアプローチ

ポリグロットアプローチとは