デベロッパー

Google Cloud Storage MCP サーバーを活用した AI エージェントと非構造化データの連携

Fri, 12 Jun 2026 00:30:00 +0000

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

Google Cloud Storage（GCS）は、最新のエージェント技術スタックの基盤コンポーネントであり、大規模な非構造化データの保存先に適しています。企業がエージェントを本番環境にデプロイしていくのにともない、重要な関心事項は、データをコンテキストに変換し、そのコンテキストにアクセスするための安全かつ標準化されたインテグレーションの構築へと移っています。これがスマートストレージの中核です。受動的なオブジェクトを推論のための豊富なコンテキストに変え、非構造化データを本質的にエージェント対応にします。複雑な財務ワークフローの自動化であれ、数秒で行うシステム障害の診断であれ、AI が成功するかどうかは、エージェントがこのインテリジェンスをどれだけシームレスに活用し、スマートで重要度の高い意思決定を行えるかにかかっています。

このブログ投稿では、お客様が GCS を使用して構築したエージェントの例を 3 つご紹介した後、Model Context Protocol（MCP）を使用してエージェントを GCS に安全かつ確実に接続する方法について解説します。自動アノテーションやオブジェクトコンテキストといったスマートストレージ機能と組み合わせることで、GCS MCP サーバーはエージェントのデプロイプロセス全体を簡単かつシンプルなものにします。

Google Cloud Storage でのエージェントの実際の成功事例

MCP と Google のエージェント技術スタックを活用してビジネス上の複雑な問題を解決しているお客様から、驚くべきイノベーションが次々と生まれています。

Palo Alto Networks は、画面を認識する AI アシスタントの Strata Co-Pilot エージェントを構築しました。このエージェントは、手順をハイライト表示したり直接実行したりして、ネットワークセキュリティ管理者が複雑な構成フローを進められるよう支援します。また、Gemini Live API を利用しており、GCS MCP サーバー経由で GCS に接続し、「履歴メモリ」として活用しています。
Airwallex は、ユーザーコンテキストを理解し、質問に答え、ユーザーに代わってワークフローを実行する AI アシスタントを開発しました。たとえば、経費ポリシーのドキュメントをスマートに分析し、詳細な承認ワークフローを生成できます。これは、通常なら手作業で何時間もかかるタスクです。エージェントは、ドキュメントと抽出された情報を、それぞれ GCS と GCS メタデータを使用して保存します。

（Airwallex AI アシスタントのご紹介: グローバルな財務処理を簡単に実現するコンシェルジュ）

Snap のジョブ最適化エージェントは、何千ものジョブの、GCS に保存された Flink と Spark のジョブ仕様、メタデータ、過去の指標を分析し、最適化の機会を特定して費用の見積もりを生成し、構成を調整します。このエージェントを使用することにより、Snap はすでに調査時間を 30 分から 30 秒に短縮しています。

上述 3 つのエージェントのすべてにおいて、GCS MCP サーバーはデータ操作を処理するだけでなく、標準の RBAC とアクセスポリシーを適用しています。

MCP を使用してエージェントを GCS に接続

MCP は、エージェントをデータソースに接続するための標準規格として急速に普及してきましたが、多くの場合、カスタムサーバーをゼロから構築することは、業務の妨げとなる、時間のかかるプロセスとなり、イノベーションに集中できなくなります。この方法では、認証やエラー処理から GCS の進化する機能への対応まで、あらゆることを管理しなければならないため、開発のオーバーヘッドとリスクが大幅に増大します。この問題を解決するため、GCS は 2 つの強力な MCP サーバーオプション（リモートとローカル）を提供し、お客様が基盤部分をオフロードして価値の創出に集中できるようにします。

1. リモート MCP サーバー: フルマネージド エージェントを Cloud Storage MCP サーバーに接続するのに、インフラストラクチャをデプロイする必要は一切ありません。エージェント構成でマネージドエンドポイントを指定するだけで、GCS 上の非構造化データに即座にアクセスできるようになり、運用上のオーバーヘッドの負担なくエージェントワークロードを簡単にスケールできます。

Cloud Storage MCP サーバーはオープンな MCP 標準に準拠しているため、ADK などの主要なエージェントフレームワークとシームレスに連携し、MCP クライアントとも適合します。設定でカスタムコネクタを追加することにより、Google Antigravity や Anthropic の Claude などのクライアントを簡単に接続できます。Cloud Storage MCP エンドポイントを指定するだけで、すぐに構築を開始できます。複雑な構成ファイルはいりません。

エージェントをストレージに接続するには、堅牢なセキュリティとガバナンスが必要です。GCS MCP サーバーは、Google Cloud の標準的な ID、オブザーバビリティ、セキュリティのフレームワークに基づいて構築されています。

ID ファーストのセキュリティ: 認証はすべて、共有キーではなく、Identity and Access Management（IAM）を通じて処理されます。これにより、エージェントはユーザーが明示的に承認したデータ（バケットとオブジェクト）にのみアクセスできるようになります。
完全なオブザーバビリティ: エージェントのアクティビティを追跡できるよう、これらの MCP サーバーを介して行われたリクエストとアクションはすべて Cloud Audit Logs に記録されます。これにより、セキュリティチームはすべてのやり取りの記録を取得し、可視性を維持しながら簡単にアクセスできます。
MCP セキュリティ - コンテンツスキャン: 必要に応じて、Google のコンテンツセキュリティサービスである Google Cloud Model Armor を使用して MCP エンドポイントを構成できます。これにより、直接的および間接的なプロンプトインジェクション攻撃、MCP ツールポイズニング攻撃、悪意のある URL / SQL インジェクションなど、一般的な MCP 攻撃ベクトルに対するセキュリティ対策を講じることができるほか、機密データの漏洩を防ぐことができます。

Cloud Storage MCP サーバーは、ほとんどの本番環境のユースケースに適しています。ただし、他のすべてのリモートサーバーと同様に、MCP ツールを完全にカスタマイズする機能は使用できません。

2. ローカル MCP サーバー: カスタマイズを管理できるセルフマネージド リモートサーバーが標準的なデータアクセスを処理する一方、ローカル MCP はビジネスロジックに固有のカスタムツールを構築する必要がある場合に適しています。たとえば、エージェントで特殊なデータ変換を実行する必要がある場合（GCS からファイルを読み取るたびに個人情報（PII）を削除したり、別の内部システムからコンテキストを追加したりする場合など）、ローカル MCP サーバーを使用すると、そうした独自の機能を定義できます。

GCS ローカル MCP サーバーは、Google が管理するツールのオープンソース GitHub リポジトリであり、データへの信頼性の高いブリッジを提供します。以下に、カスタムツールを設計する際に留意すべきポイントをいくつかご紹介します。

モデルによる誤った呼び出しを最小限に抑えるため、正確かつ明確な説明を提供する
モデルが自身の間違いを理解して自己修正できるよう、モデルに適したエラー処理を実装する

GCS ローカル MCP は、データベース向け MCP ツールボックスの一部にもなっています。これは、GCS、BigQuery、AlloyDB、Spanner、Cloud SQL などの主要なデータサービス向けのコネクタなどを単一のオープンソースリポジトリにまとめたもので、データエコシステムのモニタリングや管理を容易にします。このツールボックスは、ボイラープレートコードを削減して開発を簡素化し、OAuth2 と OIDC によってセキュリティを強化し、OpenTelemetry を統合してエンドツーエンドのオブザーバビリティを実現します。

使ってみる

Snap のような既存プロセスを最適化する場合でも、Airwallex のようなワークフローの作成を自動化する場合でも、非構造化データはエージェントにとって最大の資産の一つです。

一般提供されている GCS リモート MCP サーバーについてご確認ください。
カスタムツールの構築を今すぐ始めるには、GCS ローカル MCP の GitHub リポジトリをご確認ください。データベース向け MCP ツールボックスの一部として使用することも可能です。
GCS データを活用したエージェントのユースケースについては、Google までお問い合わせください。

- Google Cloud、プロダクトマネージャー、Himanshu Kohli

- Google Cloud、プロダクトマネージャー、Manjul Sahay

TPU、GKE マネージド DRANET、マルチクラスタ推論ゲートウェイを使用したテスト

Wed, 10 Jun 2026 01:00:00 +0000

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

あるリージョンでワークロードに障害が発生しても、サービスを使用しなければならない場合、どうすればよいでしょう？これは、可用性や稼働時間に関してよく見られるケースです。Kubernetes エコシステムと動的リソース割り当て（DRA）や推論ゲートウェイなどの機能が最近強化されたことを受け、AI 推論ワークロードを使用した簡単なテストで、Google Cloud のこれらの機能を試してみることにしました。

このブログ投稿では、この設定について詳しくご説明します。また、こちらの Codelab（TPU、Cloud Storage FUSE、マネージド DRANET を使用してマルチクラスタ GKE Inference Gateway を構築する）で、詳細な構成をすぐに確認することもできます。

構成要素

このテストを構築するには、以下のプロダクト、機能、ツールを使用します。

Google Kubernetes Engine（GKE）マネージド DRANET: これは、Pod 間でリソースのリクエストや共有ができるマネージド機能です。GPU と TPU をサポートしています。このテストでは、2 つの異なるリージョンで TPU を使用し、マネージド DRANET を使用してネットワークを割り当てました。
マルチクラスタ GKE Inference Gateway: AI / ML 推論ワークロードを複数の GKE クラスタ間で負荷分散します。これはフェイルオーバーの状況で効果的です。今回のテストではこれを試します。このテストをサポートするタイプは、マルチクラスタクロスリージョン内部アプリケーションロードバランサ（gke-l7-cross-regional-internal-managed-mc）です。
Cloud Storage FUSE: データ、モデル、チェックポイント、ログを Cloud Storage に直接保存できるようにします。デプロイを高速化するために、オープンソースの Gemma モデルをこのストレージにダウンロードし、そこから取得するようにしました。
Virtual Private Cloud（VPC）: 分離された安全な通信を内部ロードバランサとコンピューティングノードに提供する、基盤となるグローバルネットワークです。
GKE フリート: フリートは、個別のリージョンクラスタを、統合された管理コントロールプレーン下にグループ化します。
TPU v6e: モデルのサービングに必要なハイパフォーマンスコンピューティングを提供する、Google のカスタム AI アクセラレータです。使われていた VM ファミリータイプは、2x2 スライスの ct6e-standard-4t でした。

設計パターンの例

目的は、異なるリージョンにある 2 つの GKE クラスタに LLM モデル（Gemma 3）をデプロイすることです。各クラスタは 4 つの TPU v6e チップを使用します。モデルは Cloud Storage に保存する必要があります。ワークロードは、マルチクラスタ対応の GKE Inference Gateway を使用して提供します。ユーザーに最も近いリージョンにトラフィックをルーティングする必要があります。また、いずれかのリージョンで障害が発生した場合は、もう一方のリージョンにフェイルオーバーする必要があります。

設定手順

2 つのリージョンでプロジェクトの TPU にアクセスするには、それらのリージョンで必要な割り当てを確保しておく必要があります。

最初の手順: 環境を設定する。

予約と同じゾーンに標準 VPC を作成し、ファイアウォールルールとサブネットを設定します。
プロキシ専用サブネットを作成します。これは、GKE Inference Gateway にアタッチした内部リージョンアプリケーションロードバランサで使用されます。
トラフィックとヘルスチェックを許可するファイアウォールルールを設定します。
ゲートウェイ用に両方のリージョンで静的内部 IP アドレスを予約します。
Cloud Storage FUSE バケットをプロビジョニングし、専用の IAM サービスアカウントを構成します。これを Kubernetes Workload Identity にバインドし、Pod がバケットを安全にマウントしてモデルの重みを直接読み取れるようにします。

次の手順: 標準の GKE クラスタとノードプールを作成する。

選択したリージョンに、構成済みの 2 つの独立した GKE クラスタをデプロイします。
クラスタの作成時に、Gateway API（--gateway-api=standard）と Cloud Storage FUSE CSI ドライバ（--addons GcsFuseCsiDriver）を有効にします。
両方のクラスタに、専用の TPU v6e ノードプール（ct6e-standard-4t）を作成します。
---accelerator-network-profile=auto フラグと --node-labels=cloud.google.com/gke-networking-dra-driver=true フラグを設定し、これらの TPU ノードプールでマネージド DRANET を有効にします。

次の手順: フリート登録を介してグローバルメッシュを確立する。

フリートの作成と登録の設定の手順に沿って、統合された GKE フリートに両方の GKE クラスタを登録します。
フリートでのマルチクラスタサービスディスカバリとマルチクラスタ Ingress を有効にします。
プライマリリージョンを構成ハブとして指定し、両リージョンにわたるルーティングルールのコントロールプレーンとして機能させます。

次の手順: AI ワークロードをデプロイする。

Kubernetes の一時ジョブを使用して、Gemma 3（gemma-3-27b-it）モデルの重みを Cloud Storage バケットに直接ダウンロードします。
割り当てモードが「All」に設定されたマネージド DRANET デバイスクラス（deviceClassName: netdev.google.com）を明示的にリクエストする、ResourceClaimTemplate を定義します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: resource.k8s.io/v1\r\nkind: ResourceClaimTemplate\r\nmetadata:\r\n name: all-netdev\r\n namespace: default\r\nspec:\r\n spec:\r\n devices:\r\n requests:\r\n - name: req-netdev\r\n exactly:\r\n deviceClassName: netdev.google.com\r\n allocationMode: All'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc24a3fbe20>)])]>

両リージョンの TPU ノードに推論サーバー（vLLM など）をデプロイします。Pod 仕様で 2x2 TPU トポロジのノードセレクタを使用し、4 つの TPU を正確にリクエストして、netdev クレームをマウントするようにします。これにより、Pod は標準のイーサネットとともに専用のアクセラレータネットワークを確実に利用できるようになります。

次の手順: マルチクラスタ推論ゲートウェイを構成します。

必要なカスタムリソース定義（CRD）をインストールし、Kubernetes が InferenceObjective などの特殊なルーティングオブジェクトを処理できるようにします。
KV キャッシュ使用量など、ハードウェアの使用状況を追跡する、AutoscalingMetric をデプロイします。
Helm を使用して、両方のリージョンから独立した AI デプロイを、単一の論理 InferencePool にグループ化します。
クロスリージョンゲートウェイとそれに関連付けられた HTTPRoute をデプロイし、受信するグローバルトラフィックを管理します。
ヘルスチェックとバックエンドポリシーをプールに適用し、ロードバランシングでカスタムハードウェア指標を使うようにします。

InferenceObjective を構成して、過負荷状態の TPU を回避し、可用性が最も高いリージョンにプロンプトをルーティングするよう、ゲートウェイに指示します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: gateway.networking.k8s.io/v1\r\nkind: Gateway\r\nmetadata:\r\n name: cross-region-gateway\r\n namespace: default\r\nspec:\r\n gatewayClassName: gke-l7-cross-regional-internal-managed-mc\r\n addresses:\r\n - type: networking.gke.io/named-address-with-region\r\n value: "regions/europe-west4/addresses/gemma-gateway-ip-europe-west4"\r\n - type: networking.gke.io/named-address-with-region\r\n value: "regions/us-east5/addresses/gemma-gateway-ip-us-east5"\r\n listeners:\r\n - name: http\r\n protocol: HTTP\r\n port: 80\r\n---\r\napiVersion: gateway.networking.k8s.io/v1\r\nkind: HTTPRoute\r\nmetadata:\r\n name: gemma-route\r\n namespace: default\r\nspec:\r\n parentRefs:\r\n - name: cross-region-gateway\r\n kind: Gateway\r\n rules:\r\n - backendRefs:\r\n - group: networking.gke.io\r\n kind: GCPInferencePoolImport\r\n name: gemma-pool\r\n port: 8000\r\n---\r\napiVersion: networking.gke.io/v1\r\nkind: HealthCheckPolicy\r\nmetadata:\r\n name: gemma-health-check\r\n namespace: default\r\nspec:\r\n targetRef:\r\n group: networking.gke.io\r\n kind: GCPInferencePoolImport\r\n name: gemma-pool\r\n default:\r\n config:\r\n type: HTTP\r\n httpHealthCheck:\r\n requestPath: /health\r\n port: 8000\r\n---\r\napiVersion: networking.gke.io/v1\r\nkind: GCPBackendPolicy\r\nmetadata:\r\n name: gemma-backend-policy\r\n namespace: default\r\nspec:\r\n targetRef:\r\n group: networking.gke.io\r\n kind: GCPInferencePoolImport\r\n name: gemma-pool\r\n default:\r\n timeoutSec: 100\r\n balancingMode: CUSTOM_METRICS\r\n trafficDuration: LONG\r\n customMetrics:\r\n - name: gke.named_metrics.tpu-cache\r\n dryRun: false\r\n maxUtilizationPercent: 60\r\n---\r\napiVersion: autoscaling.gke.io/v1beta1\r\nkind: AutoscalingMetric\r\nmetadata:\r\n name: tpu-cache\r\n namespace: default\r\nspec:\r\n selector:\r\n matchLabels:\r\n app: gemma-server\r\n endpoints:\r\n - port: 8000\r\n path: /metrics\r\n metrics:\r\n - name: vllm:kv_cache_usage_perc\r\n exportName: tpu-cache\r\n---\r\napiVersion: inference.networking.x-k8s.io/v1alpha2\r\nkind: InferenceObjective\r\nmetadata:\r\n name: gemma-objective\r\n namespace: default\r\nspec:\r\n priority: 10\r\n poolRef:\r\n name: gemma-pool\r\n group: "inference.networking.k8s.io"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc24a3fbbe0>)])]>

フェイルオーバーのテスト

プライマリリージョンの障害をシミュレートして、高可用性アーキテクチャを検証します。プライマリのデプロイがオフラインになると、ゲートウェイは障害を自動的に検出し、その後のすべてのユーザーリクエストをアクティブなセカンダリクラスタへシームレスに再ルーティングします。これにより、トラフィックをドロップすることなく継続的な可用性が確保されます。

次のステップ

上述の機能に関するハンズオン Codelab と詳細については、以下をご覧ください。

ハンズオン Codelab: TPU、Cloud Storage FUSE、マネージド DRANET を使用してマルチクラスタ GKE Inference Gateway を構築する
ドキュメント一式: DRANET
ドキュメント: AI Hypercomputer

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

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

Cloud Run での AI のコールドスタートに関するガイド

Thu, 04 Jun 2026 02:00:00 +0000

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

あるデベロッパーが Reddit で、複数のリージョンにまたがる Cloud Run で AI のコールドスタートを管理する「賢明な方法」はないかと質問しているのを見かけました。最大 20 秒にも及ぶ起動レイテンシに悩まされており、ユーザーが応答を待っている間にインフラストラクチャがスピンアップするという状況にもどかしさを感じていました。

そのディスカッションには、サーバーレス GPU をほぼ諦めかけていたデベロッパーも多数参加しており、中にはレイテンシを回避するためだけに GKE に戻す人もいました。そこで私は、AI のコールドスタートの仕組みを深く掘り下げ、その「賢明な方法」を見つけ出せるかどうか確かめてみることにしました。

Cloud Run で Gemma 4 などのモデルをホストする方法について調査していたところ、Google Cloud Next '26 で Oded Shahar（Cloud Run のシニアエンジニアリングマネージャー）とゲストスピーカーの Ajay Nair 氏（Elastic のプラットフォーム担当グローバルバイスプレジデント）と一緒に共同プレゼンテーションを行う機会に恵まれました。

そのセッション「Cloud Run でカスタムモデルを使用して AI アーキテクチャを構築する」で、Nair 氏は、Cloud Run の「ゼロへのスケーリング」という効率性を維持しながら、17 種類以上のモデルバリエーションで 1 日数百万件のリクエストの処理を可能にした、Elastic の本番環境で実証済みの戦略を共有しました。

Cloud Run でカスタムモデルを使用して AI アーキテクチャを構築する

Nair 氏は、その秘訣はモデルそのもののみならず、GPU を管理すべきインフラストラクチャとしてではなく、代替可能なコンピューティングとして扱うことにあると教えてくれました。

その時、コールドスタートのレイテンシを最小限に抑えることは、単にモデルだけの問題ではなく、それを高速でスケーラブルかつ安全に維持するためのインフラストラクチャのパターンやアーキテクチャに関する決定も重要であることに気付いたのです。

AI のコールドスタートの仕組み

公式の Google Cloud GPU パフォーマンスのベストプラクティスで説明されているように、AI のコールドスタートは、標準的なウェブマイクロサービスのコールドスタートとは異なります。単にコードを起動するだけでなく、ギガバイト単位の重みを専用の物理アクセラレータに転送させるからです。

これは、4 段階のレースだと考えてください。各段階（フェーズ）を最適化しなければ、ユーザーを失うことになってしまいます。

フェーズ 1: インフラストラクチャのプロビジョニング（約 5 秒）

Cloud Run は物理 GPU を割り当て、プリインストールされた NVIDIA ドライバを追加します。Google がドライバを管理するため、Dockerfile が膨らむことはありません。

フェーズ 2: ブロックレベルのコンテナイメージストリーミング（1 ～ 2 秒）

Cloud Run は「イメージストリーミング」を採用しており、起動に必要なブロックのみを取得します。15 GB の CUDA イメージでも、実際は小さな Node.js アプリと同じくらいの速さで起動できます。

フェーズ 3: エンジンの初期化（5 ～ 15 秒）

ここで、推論エンジン（vLLM、Ollama）がウォームアップします。これは CPU 負荷が高い処理であり、多くのユーザーが気付かないうちにスロットリングされる部分です。

フェーズ 4: モデルの読み込みと VRAM への転送

これが最後の難関です。モデルの重みをストレージから GPU メモリへと転送します。CPU が重要視される標準的なウェブアプリとは異なり、ここでは GPU メモリが主な制約要因となります。モデルの重みが GPU メモリに収まりきらない場合、より低速なシステム RAM にスワップされるため、パフォーマンスが大幅に低下します。

AI のコールドスタートを処理するためのベストプラクティス

「賢明」な本番環境を構築するために、GPU を使用した AI 推論に関する Google Cloud の公式ドキュメントを参考に、いくつかの重要なポイントをご紹介します。

フェーズ 4 の最適化

適切なデプロイオプションの選択

フェーズ 4 は、ギガバイト単位の重みをストレージから GPU メモリへと転送する「最後の難関」です。ストレージの選択によって、この転送の速度が決まります。

Cloud Storage（同時ダウンロード）- 最速: Google Cloud CLI（gcloud storage cp）を使用すると、モデルファイルを並列でダウンロードできます。ネットワークスループットを最大化し、転送時間を大幅に短縮できるため、大規模な重みに対して推奨される方法です。
Cloud Storage（FUSE）- 最も簡単: バケットをローカルファイルシステムとしてマウントすることで、「コード変更を不要」にします。ただし、最初のダウンロードを並列化しないため、大規模なモデルの重みに対してはかなり遅くなります。
コンテナイメージ - 10 GB 未満に最適: 小規模なモデルの場合、Cloud Run のイメージストリーミングを使用してイメージに重みを付けるのが効率的です。ただし、10 GB を超えるモデルの場合、インポートやストリーミングのオーバーヘッドがボトルネックとなる可能性があります。
インターネット: 避けるべきです。本番環境での推論において、最も時間がかかり、かつ最も予測困難な方法です。

モデルの形式とサイズ

フェーズ 4（モデルの読み込みと VRAM への転送）の時間の短縮につながる「裏技」が、モデルの形式とサイズの最適化です。このフェーズは、ギガバイト単位のデータを VRAM に転送できる速度によって制約されるため、より小さく効率的なファイルが重要となります。

4 ビット量子化: これはコールドスタートの究極の裏技です。重みが小さいほど、ストレージから引き出すギガバイト数が減るため、フェーズ 4 のダウンロードと転送のプロセスが直接高速化されます。
高速な形式: 起動時間を最小限に抑えるために、GGUF のような読み込み時間が短いモデル形式を選択します。最も高速なパフォーマンスを得るには、Python の「pickle」ファイルの使用を避け、ゼロコピー読み込みを実現する Safetensors を使用します。
VRAM の容量の確保: 量子化モデルを使用して、重みが GPU メモリ内に完全に収まるようにします。モデルが VRAM を超えると、システムは非常に低速な RAM にスワップするため、フェーズ 4 が行き詰まってしまいます。

フェーズ 3 と 4 の最適化: インフラストラクチャとネットワークの活用手段

これらのインフラストラクチャ設定は、起動プロセスの最も要求の厳しい部分を高速化するために必要なリソースを提供します。

起動時の CPU ブースト（フェーズ 3 を高速化）

この機能により、起動時の CPU 性能が一時的に 2 倍になります。1 vCPU インスタンスが、起動中およびサービス提供開始後の最初の 10 秒間、2 vCPU に増強されます。エンジンの初期化は CPU 負荷の高い処理であるため、フェーズ 3 ではこの機能が不可欠です。

ダイレクト VPC 下り（外向き）と PGA（フェーズ 4 を高速化）

プライベート Google アクセス（PGA）でダイレクト VPC 下り（外向き）を利用すると、モデルの重み付けトラフィックが Google の内部高速バックボーン上に留まります。これにより、ネットワークパスが最適化され、ギガバイト単位の重みを VRAM に転送する時間が短縮されます。

同時実行のチューニング（コールドスタートの回避）:

Cloud Run において、「同時実行」とは、プラットフォームがスケールアウトして新しいインスタンスを起動する前に、単一インスタンスが処理できるリクエストの最大数を指します。AI ワークロードの場合、この設定はモデルエンジンの内部並列処理フラグ（例: vLLM の --max-num-seqs や Ollama の OLLAMA_NUM_PARALLEL）と合わせて調整する必要があります。

Cloud Run の最適な同時実行数を算出するには、公式の Google Cloud の数式を使用します。

（モデルインスタンスの数 ∗モデルあたりの並列クエリ数）+（モデルインスタンスの数 ∗理想的なバッチサイズ）

例: インスタンスが 3 つのモデルインスタンスを GPU に読み込み、各モデルインスタンスが 4 つの並列クエリを処理でき、理想的なバッチサイズが 4 である場合、Cloud Run の最大同時リクエスト数を 24 に設定します:（3 × 4）+（3 × 4）

計算方法: 目標は、GPU を完全に飽和状態に保ちながら、ユーザーが長いキューで待機しないようにすることです。この例では、合計 24 の同時リクエストが 2 つの機能グループに分割されています。

アクティブな処理（12 リクエスト）:（3 インスタンス × 4 クエリ）で計算され、GPU が任意の時点でアクティブに処理できるリクエストの合計数を表します。
「次のバッチ」バッファ（12 のリクエスト）:（3 インスタンス × 4 バッチサイズ）で計算されます。これらは、コンテナ内で「待機中」のリクエストです。GPU が最初のバッチを完了すると、すぐにこれらの待機中のリクエストを処理します。

この値を VRAM の許容範囲内で最大（通常 10 ～ 20 ユーザー）にチューニングすることで、1 つのウォームインスタンスで多数のリクエストを処理できるようになり、新しいスケールアウトイベントやそれに伴うコールドスタートをトリガーせずに済みます。

スケーリング制御（しきい値の調整）

上記の式は最大容量を定義するものですが、Cloud Run が次のインスタンスを起動するタイミングを調整することもできます。Cloud Run のオートスケーラーは通常、60% の使用率を目標としていますが、時間がかかる AI のコールドスタートの場合、スケーリング制御を使用して、このしきい値を 80% または 90% に引き上げることができます。

同時実行目標数: この値を大きくすると、スケールアウトがトリガーされる前に、単一のウォームインスタンスにより多くのリクエストを「詰め込む」ことができます。
CPU 目標値: CPU 目標値を引き上げることで、初期化や高負荷の推論によって CPU 使用率が一時的に急上昇しただけで、プラットフォームが新しいインスタンスを起動するのを防ぐことができます。

スケーリングと信頼性に関する戦略

コールドスタートを完全に回避するか、あるいは積極的に管理するのが、コールドスタートへの最善の対処法である場合があります。

単一リージョンの「常時稼働」のトレードオフ

グローバルにデプロイする場合、すべてのリージョンで最小インスタンス数を 1 に設定すると費用がかさみます。代わりに、1 つのリージョンのみで「常時稼働」のサービスを行うことを検討してください。グローバルネットワークの遅延が 100 ミリ秒でも、ローカルのコールドスタートに 20 秒かかるよりは、はるかに優れたユーザーエクスペリエンスを提供できます。

15 分間の猶予期間: よく聞かれる質問に、「リクエストの後、インスタンスはどのくらいの間ウォーム状態を維持しますか？」というのがあります。Cloud Run は通常、インスタンスがアイドル状態（リクエストを処理していない状態）になってから 15 分間インスタンスの稼働を維持します。トラフィックが予測可能で、10 ～ 12 分ごとに発生する場合、「常時稼働」のサービスは必要ないかもしれません。プラットフォームのデフォルトのシャットダウンポリシーにより、次のユーザーにウォームインスタンスが無料で準備されます。

「先手を打った措置」戦略

時として、コールドスタートに対処する最善の方法は、先手を打った措置を講じることです。たとえば、ユーザーが「新しいチャット」をクリックしたり、テキスト領域にカーソルを合わせたりした時など、UI で次のリクエストを予測できる場合は、サービスに向けてすぐに軽量なヘルスチェックを送信できます。ユーザーがプロンプトの入力を終える頃には、コールドスタートの最初の 2 つのフェーズ（インフラストラクチャのプロビジョニングとコンテナイメージのストリーミング）は、バックグラウンドですでに完了しています。

上級者向けのヒント: 非推論エンドポイントを使用します。この「先手を打った措置」を可能な限り高速化するには、「hi」のようなダミープロンプトを送信するのではなく、常に非推論エンドポイントを使用します。

高速な理由: 非推論エンドポイント（vLLM の /v1/models や Ollama の /api/tags など）は、コンテナのウェブサーバーが起動した瞬間に処理されます。そのため、時間のかかる「フェーズ 4」のモデルの読み込みや VRAM への転送の完了を待つことなく、成功レスポンスを送信できます。
チャット履歴への干渉なし: これらのエンドポイントはモデルの補完ロジックをトリガーしないため、ユーザーの実際のチャット履歴に干渉したり、バックエンドで誤ってセッションの作成をトリガーしたりすることはありません。

推奨されるエンドポイント:

vLLM: GET /health または GET /v1/models
Ollama: GET /api/tags または GET /api/version

VRAM の起動プローブの調整

AI モデルは、ストレージから GPU メモリにギガバイト単位の重みを転送するのにかなりの時間を要します（フェーズ 4）。起動チェックが何度も失敗すると、Cloud Run はコンテナが破損していると判断して強制終了します。

これを回避するには、以下を行います。

失敗しきい値を引き上げる: 高い failureThreshold を使用します（例: 60 以上）。許容される合計起動時間は failureThreshold \times periodSeconds の積であるため、しきい値を 60、間隔を 5 秒にすると、5 分間というモデルを読み込むために十分な時間が確保されます。
最大 30 分を活用: 標準サービスでは起動時間が 4 分に制限されていますが、Cloud Run では負荷の高いワークロードに対して、最大 30 分（1,800 秒）の合計起動時間をサポートしています。
偽陽性の回避（Ollama 対策）: Ollama のようなエンジンを使う場合、サービスの開始直後、モデルが実際に VRAM に読み込まれる前に TCP ポートが開かれることがあるため、注意が必要です。コンテナのエントリポイントスクリプトで必ずモデルをプリロードし、モデルが確実に推論を実行できる状態になった時点で起動プローブが成功するようにしてください。

Elastic の戦略から得られる教訓

NEXT ‘26 のセッションにおいて、Ajay Nair 氏は、Elastic が GPU を管理すべきインフラストラクチャとしてではなく、代替可能なコンピューティングとして扱うことを可能にした 3 つのアーキテクチャに関する決定事項について強調しました。

コンパイル費用の回避: vLLM で enforce_eager=True を設定することで、わずかなスループットを犠牲にする代わりに、コールドスタートが数分ではなく 1 分未満で完了するようにしました。
スタンドアロンのチェックポイント: 各 LoRA バリエーションを事前にスタンドアロンのチェックポイントに統合することで、実行時のアダプタの切り替えに伴うレイテンシを回避しました。
1 つのワークロード、1 つのサービス: モデル、タスクアダプタ、トラフィックパターンによって定義される、それぞれ個別のスケーラブルなワークロードは、独自の Cloud Run サービスとしてデプロイされます。これにより、約 15 のモデルファミリーで 30 以上のサービスが生成され、一部のモデルはタスク（例: v5 の取得とクラスタリング）やクエリ / パッセージの役割によって分割されています。

準備ができたら

コールドスタートのプロセスを最適化できるかどうかが、趣味のプロジェクトとプロダクションレディなアプリケーションとの違いを決定付けます。この最適化の最大のメリットは、Cloud Run が NVIDIA ドライバと CUDA のインストールを処理し、インスタンスを約 5 秒で起動できることです。

詳細については、次の公式ドキュメントをご覧ください。

技術的な詳細については、Google Cloud Next '26 のセッションの録画をご覧になることを強くおすすめします。サーバーレスインフラストラクチャで高性能なオープンモデルをホストするための最も包括的なブループリントを確認できます。

開発をお楽しみください。

この記事に対して、レビューとフィードバックを提供してくださった、Cloud Run チームの Sara Ford と Shane Ouchi、Elastic の Zac Li 氏に心より感謝いたします。

- Google Cloud デベロッパーリレーションズ、AI エンジニアリング責任者、Shir Meir Lador

Gemini API キーと Google API キーの保護

Tue, 02 Jun 2026 02:30:00 +0000

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

現在、AI サービスは API キーに大きく依存しています。ユーザーが AI エージェントを実行するには、有料トークン、サブスクリプション、または有料アカウントを示す API キーを提示する必要があります。API キーは簡単に使用できますが、安全でない方法で使用することも同じくらい簡単です。キーが盗まれると、環境が侵害され、不正使用や悪用につながります。

ユーザーが講じるべき自衛策についてのチュートリアルを求めるスレッドが Reddit 内の r/googlecloud ページに投稿されているのを見たことをきっかけに、このブログ投稿を書くことにしました。この投稿では、Google が作成した API キーのリスクを軽減し、セキュリティを向上させるための簡単な手順をいくつかご紹介します。

Google API キーは、Gemini やその他の AI Google プロダクト、あるいは Google Cloud API にアクセスするのに使用されます。Gemini API キーは、バックグラウンドで使用される標準の Google API キーです。ここでは Google API キーのセキュリティに焦点を当てますが、これらの推奨事項の一部は、他の場所で作成された API キーやプロダクトトークンにも適用できます。

ステップ 1: 新しい API キーを生成する

どこから始めても、最終的には Google Cloud プロジェクトのいずれかで新しい API キーを作成することになります。Cloud コンソールの [API とサービス] メニューにある [認証情報] を使用することになるでしょう。

代わりに gcloud services api-keys create コマンドを使用することもできます。また、新しい Google Cloud API キーを作成できる他のインターフェースもあります。経路やインターフェースにかかわらず、次のことを行う必要があります。

他の目的に使用されていないスタンドアロンプロジェクトでキーを作成する。
新しい API キーの API アクセスとクライアントアプリケーションを制限する。

これらの手順により、キーの潜在的なリーチが制限され、問題が発生した場合のトラブルシューティング作業が大幅に簡素化されます。

API の制限

API の制限では、キーを使用してアクセスできるサービスを指定します。制限のないキーは作成しないでください。キーが盗まれると、攻撃者は利用可能なサービスにユーザーの費用でアクセスできてしまうからです。

そのキーが使用されるサービスのリストを常に制限して、キーが乗っ取りや漏洩の被害にあった場合の潜在的な損害（影響範囲）を軽減します。間接的な UI を使用して新しいキーを作成する場合は、注意が必要です。たとえば、Firebase で API キーを作成するときは、使用できる API の数を Datastore、Firestore、Cloud SQL Admin などの 24 個に制限します。

Firebase を使用してウェブサイトを保存する場合は、ほとんどの API を使用しないでしょう。AI Studio で使用する API キーを作成するときは、アクセスできる API を「Gemini API」のみに制限してください。

注意点:

デフォルトでは、新しい API キーは制限なしで作成されます。
選択したい API を検索しても見つからない場合は、使用している Google Cloud プロジェクトでその API が有効になっていない可能性があります。まず Cloud コンソールの [API ライブラリ] に移動し、名前で API を検索して、有効にします。
Cloud コンソールまたは gcloud CLI では、すべてのアクションを実行できます。他のインターフェース（Firebase など）では、API キーの一部のパラメータにアクセスできない場合があります。

アプリケーションの制限

API 制限がキーを使用できるサービスを制限するのと同様に、アプリケーションの制限はキーを使用できるアプリケーションを制限します。たとえば、Google AI Studio でのみ使用する API キーを作成する場合、アプリケーションの制限をウェブサイト https://aistudio.google.com/ に設定すると、Gemini を利用して大量のトークンを大規模に消費する自動化でキーが使用されるのを防ぐことができます。

次のいずれかのタイプの制限を 1 つ以上設定できます。

URL のリストを使用してウェブサイトやウェブアプリケーションの制限を設定する
IPv4 や IPv6 アドレスのリストまたはサブネットマスクを使用してサービスの制限を設定する
バンドル ID のリストを使用して iOS アプリケーションの制限を設定する
パッケージ名と証明書フィンガープリントのペアのリストを使用して Android アプリケーションの制限を設定する

キーに対して適用できるアプリケーションの制限は 1 種類のみです。アプリケーションの種類ごとに指定の API キーを作成します。アプリケーション種類ごとにキーを用意しておくと、キーの使用状況を把握し、侵害された可能性のあるキーを調査する際に役立ちます。

ステップ 2: API キーを保存する

ここで今一度確認したいことは、API キーはユーザーの ID とペアになっていないということです。API キーは誰でも利用できます。そのため、キーを安全に保管することは、ステップ 1 でのキーの使用の制限と同じくらい重要です。

ルールは簡単です。キーを簡単に見える場所に保存してはいけません。

アプリケーションで API キーを使用する場合は、Secret Manager または同様のシークレット管理サービスに保存します。Secret Manager を使用すると、API キーを Cloud Run 環境と GKE 環境に簡単に挿入できます。ただし、キーの保護を強化するために、コードでキーを読み取ることもできます。例については、ドキュメントをご覧ください。

外部アプリケーションで API キーを使用する場合、キーの入力を求められたら、アプリケーションがキーをどのように管理しているかを確認する追加の手順を踏んでください。キーがどのように保存され、リクエストでどのように使用されているかを調べる必要があります。ウェブアプリケーションの場合は、ブラウザのデベロッパーツールを使用してアプリケーションのトラフィックを検査し、キーが暗号化されていない通信チャネルで送信されていないことを確認します。たとえば、Google AI Studio は暗号化されたローカルストレージを使用し、TLS で暗号化されたチャネルを介してキーを送信します。

問題が発生した場合

キーが侵害された疑いがある場合、どうすべきでしょうか？クレジットカードの場合と同じように、単純な手順で対処します。まず、キーを削除します。Cloud コンソールで削除するか、gcloud services api-keys delete コマンドを使用して削除できます。実際は侵害されていなかったことがわかった場合は、30 日以内であれば削除を取り消すことができます。

どのキーが侵害されたかわからない場合はどうすればよいでしょうか？その場合は、次の 2 つのステップで調査する必要があります。

組織またはプロジェクト内のすべての API キーを検出する
このキーでアクセスできる API の API 使用量のグラフを確認する

すべての API キーを確認する

API キーのリソースを見つける方法は複数あります。Cloud コンソールの [アセットインベントリ] を使用し、ダッシュボードを [リソースの種類] でフィルタリングして apikeys.Key を確認できます。このリソース種類が表示されない場合は、[さらに表示…] を見つけてクリックし、リソース種類のリストを展開します。削除された API キーもリストに表示されます。

CLI を使用する場合で、特定のプロジェクトがわかっている場合は、gcloud services api-keys list コマンドを使用できます。

組織内のすべてのアクティブなキーを表示するには、gcloud asset search-all-resources コマンドを使用し、その JSON 出力をクエリして削除されたキーを除外する必要があります。

code_block: <ListValue: [StructValue([('code', 'gcloud asset search-all-resources \\\r\n --scope=\'organizations/123456789012\' \\\r\n --asset-types=\'apikeys.googleapis.com/Key\' \\\r\n --read-mask="name,displayName,versionedResources" \\\r\n --format=json \\\r\n --order-by=\'createTime\' \\\r\n| jq \'.[] | select(.versionedResources | all(.resource.data.deleteTime == null))\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc248368d90>)])]>

API の使用量を確認する

API キーの使用状況を追跡する方法があります。Cloud Monitoring の serviceruntime.googleapis.com/api/request_count 指標を使用することです。この指標は、さまざまなサービスが呼び出された回数を示します。特定の API キーのサービスリクエスト数を確認するには、指標の credential_id ラベルを使用し、API キーの一意の ID でフィルタリングする必要があります。指標のデータを確認するには、Metrics Explorer を使用するか、次の PromQL 式で Monitoring API を呼び出します。

code_block: <ListValue: [StructValue([('code', 'sum(\r\n rate({\r\n "__name__"="serviceruntime.googleapis.com/api/request_count",\r\n "monitored_resource"="consumed_api",\r\n "credential_id"="apikey:00000000-0000-0000-0000-000000000000"\r\n }[${__interval}])\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc248368f10>)])]>

service_name ラベルを使用して、API 名（例: mapstools.googleapis.com）でこの指標をさらにフィルタリングできます。

API キーの ID を確認するには、次のいずれかの方法を使用する必要があります。

Cloud コンソールを使用して [認証情報] ページを開き、目的の API キーを選択します。ブラウザで API キーページの URL を確認します。URL は https://console.cloud.google.com/apis/credentials/key/[KEY_ID]?project=[PROJECT_ID] のように表示されます。[KEY_ID] の部分をコピーします。
gcloud CLI を使用して、gcloud services api-keys list --format='value(displayName,uid)' コマンドを実行し、表示名でキーを見つけます。表示名の横にある UID をコピーします。

API 呼び出しが異常に多い場合は、通常、API キーが侵害され、悪意のあるユーザーによって API にアクセスするために使用されたことを示します。

ステップ 3: API キー管理のハイジーン

エンジニア、経験豊富なクラウドユーザー、あるいは単に試してみようという方であっても、環境が乗っ取られるのを防ぐためには、API キーの適切な管理が重要です。

すでに Google API キーを使用している場合は、今すぐ次の対応を行ってください。

所有しているすべての API キーを確認します。
使用しなくなったキーや認識できないキーをすべて削除します（30 日以内であれば復元できますので心配無用です）。
API キーがアクセスできる API を、使用する予定の API のみに制限します。可能であれば、API を使用できるクライアントもリストを使って制限します。
Google Cloud プロジェクトまたは組織を管理している場合は、API キーの管理に必要な作業を最小限に抑えるために apikeys.googleapis.com/Key 組織ポリシーを設定することを検討してください。
API キーを定期的にローテーション（更新）し、まったく同じ制限を共有するキーを新しく作成して置き換えることを検討してください。既存のキーが使用されているすべての場所を追跡して更新してからそのキーを削除するようにしてください。そうすることで、アプリケーションが予期せず破損したり、突然アクセスできなくなったりするのを防ぐことができます。

まとめ

API キーの保護は、クラウドエコシステムを保護するうえで重要なステップです。API とアプリケーションの厳格な制限の実装、安全な保管の利用、消費の積極的なモニタリングは、不正アクセスを防止する非常に効果的な方法です。これらの対策により、開発環境を悪用から保護し、予期しない請求を回避できます。

これらの手法を導入するのに役立つ、実用的なツールとリソースをいくつかご紹介します。

API についてさらに確認する: API キーの管理に関するベストプラクティスを確認し、「Google API を検索して選択する」のラボを実践します。
クイックチュートリアルを見る: Cloud Run シークレットの Secret Manager でのセキュアな管理に関する Google Cloud Tech の動画で、安全な保管のコンセプトが実際にどのように機能するかをご確認ください。
Codelab で実際に体験する: Codelab でPython または Spring Boot を使って Secret Manager を利用してみて、ガイド付き環境で認証情報を安全に取得する練習をします。

ドキュメントで詳細を確認する: 指標の選択、グラフの作成、アラートの設定を通じて API の使用状況を把握する方法をご確認ください。

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

Gemini Live Agent Challenge: 受賞者とハイライトを発表

Tue, 02 Jun 2026 02:00:00 +0000

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

Gemini Live Agent Challenge が無事に終了しました。このチャレンジでは、世界中のデベロッパーに従来の「テキストボックス」から脱却する次世代の AI エージェントの構築を呼びかけました。最初の発表から、151 か国 11,878 人の参加者と 1,536 件のプロジェクト応募まで、その結果は驚くべきものでした。

ミッションは、Gemini Live API、Agent Development Kit（ADK）、Google Cloud の堅牢なインフラストラクチャを使用して、マルチモーダル機能をシームレスに統合し、リアルタイムで「見る、聞く、話す、つくる」をサポートするエージェントを構築することでした。参加者は、ライブ対応のエージェント、クリエイティブストーリーテラー、UI ナビゲーターの 3 つのカテゴリで、インタラクティブ AI の限界に挑戦しました。

最優秀賞を受賞したビルダーの皆様、おめでとうございます。優勝チームは、技術的な正確さと大胆な想像力を組み合わせ、ユーザーがエージェントと対話して体験する方法を完全に一新しました。受賞者のうち 2 人の開発者は、Google Cloud Next 2026 の会場でも表彰されました。受賞エージェントの完全なリストとともに、受賞者の体験をご紹介します。

Google Cloud Next '26 で各部門の受賞者を発表

部門賞を受賞した Jeremiah Somoine 氏と Bryen Param 氏は、ラスベガスで開催される Google Cloud Next 2026 に招待され、より広範なデベロッパーコミュニティと自身の経験や知見を共有しました。受賞者 2 名は、展示会場のデベロッパーシアターでライトニングトークを行い、GDE および認定ラウンジのクリエイタースタジオポッドで独占インタビューを受けました。

イベント期間中、Bryen 氏は drone-copilot の開発における主なインスピレーションについて語りました。プロジェクトの原動力となったのは「モデルが現実世界とやり取りできたらどうなるだろうか？」という疑問だったと説明し、マルチモーダル機能が AI と物理環境のギャップを埋める方法を紹介しました。

現役大学生の Jeremiah 氏は、Sankofa の開発プロセスを振り返り、「技術的な制限に対する最善の対応は、創造力だった」と述べています。次世代の AI アプリケーションの構築を目指す他の学生たちへのアドバイスを求められたとき、彼はテクノロジーを実際に体験する機会があれば、すぐに始めることが重要だと強調しました。「学ぶには、実際にやってみるのが一番です」と語り、意欲的なデベロッパーに、とにかく飛び込んで構築を始めてみるよう促しています。

受賞者

最優秀賞: ORION - Operating Room Intelligent Orchestration Node 作成者: Aditya Shukla 氏

ORION（Operating Room Intelligent Orchestration Node）は、音声指示によるロボット手術の支援コパイロットです。外科医は、スクラブを破ることなく、自然に話してすぐに回答を得たり、ディスプレイにライブデータを表示したり、リアルタイムの視覚的支援を受けたりできます。

Orion - 音声指示による手術 AI アシスタント | Gemini Live Agent ハッカソン

ライブ対応エージェント部門の受賞者: drone-copilot 作成者: Bryen Param 氏

ドローンコパイロットは、ユーザーがジョイスティックや複雑なメニューを使用する代わりに、ドローンと自然なリアルタイムの会話ができるようにすることで、ハードウェアの操作方法を変革します。ユーザーは話すだけで、ドローンにナビゲーション、自律的な視覚検査、周囲の状況の説明を指示できます。ドローンはリアルタイムで音声応答し、アクションを確認します。

ドローンコパイロット: Gemini Live API を使用した音声制御ドローンと自律検査

クリエイティブストーリーテラー部門の受賞者: Sankofa 作成者: Jeremiah Somoine 氏

Sankofa は、マルチモーダル AI の「グリオ」（西アフリカの伝統的な語り部）として機能し、断片的な家族の歴史を没入感のある物語に変えます。ユーザーのわずかな詳細情報に基づいて、豊かな音声ナレーション、水彩画の画像、アンビエントサウンドスケープを織り交ぜて歴史物語を紡ぎ出します。ユーザーは、語り部とリアルタイムで音声会話をしながら、自分のルーツをさらに探ることができます。

Sankofa デモ動画

UI ナビゲーター部門の受賞者: Moonwalk 作成者: Enaiho Uwas Paul 氏、Aman Kumar Sah 氏

Moonwalk は、会話型のハンズフリーデスクトップアシスタントです。ユーザーは声だけでコンピュータを直感的に操作し、複雑なタスクを完了できます。個人の好みや過去のやり取りを記憶することで、インテリジェントなコパイロットとして機能し、マウスやキーボードをシームレスに制御して、フライトの予約やスプレッドシートの管理などの日常的なワークフローを実行します。ユーザーはただ座って話すだけです。

Moonwalk のデモ動画 #geminiliveagentchallenge

マルチモーダル統合とユーザーエクスペリエンス部門最優秀賞: Wand 作成者: David Li 氏

Wand は、ボイスファーストのポインタ対応ブラウザアシスタントです。自然な会話とハンドジェスチャーを組み合わせて、あらゆるウェブサイトをシームレスに操作できます。画面を指差して「この動画を再生して」や「ここを拡大して」などと話しかけるだけで、このライブ対応エージェントがクリック、検索、コマンドの実行を即座に行うお手伝いをします。マウスやキーボードに触れる必要はありません。

Wand -- ユーザーとともに見て、検索して、クリックするライブ対応エージェント

技術運用とエージェントアーキテクチャ部門の最優秀賞: JohnKeats.AI 作成者: Matthew Keats 氏

JohnKeats.AI は、ユーザーの言葉に積極的に耳を傾け、解決策を急いで提供することなく、ユーザーの気持ちに寄り添うことを目的としたボイスファーストの感情コンパニオンです。ピッチ、ペース、トーンなどの微妙な口調を処理することで、ユーザーの感情状態にリアルタイムで自然に反応し、深い思考で感情に寄り添う会話機能を提供します。

JohnKeats.AI — 黙るべき時を知るために構築された初の AI エージェント

イノベーションおよびソートリーダーシップ部門の最優秀賞: Rayan Memory 作成者: Yusuf Elnady 氏

Rayan Memory は、日々の学習内容を完全に探索可能な 3D の「記憶の宮殿」に変えることで、忘却という普遍的な問題に取り組んでいます。バックグラウンドエージェントが現実世界の音声を受動的に聞き取り、重要なアイデアを物理的なアーティファクトとして抽出します。ユーザーはテーマ別の仮想ルームを歩き回り、専用の AI コンパニオンと会話することで、正確な記憶を簡単に取り出すことができます。

Rayan - 3D の記憶の宮殿が聞き取り、記憶し、話しかける

特別賞: NagarDrishti 作成者: Nikita Dongre 氏、Omkar Dongre 氏

NagarDrishti は、運転中にハンズフリーの音声アシスタントを使用して、市民が安全に道路の穴や冠水を報告できるようにすることで、危険な道路状況に対処します。これらのリアルタイムレポートは、インタラクティブなダッシュボードに即座に表示されます。市の職員は自然言語を使用して、危険な場所を簡単に特定し、重要な修理を管理できます。

特別賞: Ekaette 作成者: Bassey John 氏

Ekaette は、通話とテキストメッセージの両方で動作する会話型のマルチモーダル AI アシスタントを使ってイライラする保留音を置き換えることでカスタマーサービスに革命を起こします。顧客は、通常の電話回線でエージェントと自然に会話しながら、WhatsApp を介してシームレスに写真を共有したり、製品オプションを確認したり、支払いを完了したりできます。

Ekaette - マルチモーダル AI 音声およびメッセージングアシスタント

特別賞: VibeCat 作成者: Sejun Kim 氏、Michael Chang 氏

VibeCat は、画面を継続的に監視し、コンテキストを理解して、ユーザーが尋ねる前に役立つアクションを提案する、プロアクティブな macOS デスクトップコンパニオンです。コマンドを待つのではなく、コードの欠落行の修正やターミナルコマンドの実行などを最初に提案し、ユーザーの許可を得てからタスクを完了します。

vibeCat - プロアクティブなデスクトップコンパニオン

特別賞: Call My Parts 作成者: Sugam Palav 氏、Nikhil Lohar 氏、Siddhant Panday 氏、Vishal Parekh 氏

Call My Parts は、中古車部品の調達という面倒で時間のかかるプロセスを自動化します。調査やベンダーへの連絡を代行してくれます。ユーザーは部品のリクエストを話すだけで、AI エージェントが自律的にベンダーのウェブサイトを検索し、サプライヤーに電話して価格と在庫を確認して、最適な選択肢をランク付けして読みやすいダッシュボードにまとめます。

Call My Parts AI Tool : ハッカソン Gemini Live 2026

特別賞: Relay 作成者: Faith Ogundimu 氏

Relay は、ウェブカメラを使用して物理電子工学プロジェクトをリアルタイムで監視し、ガイドするインタラクティブな AI ラボパートナーです。回路の組み立てを手順を追って支援する音声サポート、配線ミスを事前に検出する機能、組み込みの 3D シミュレーションサンドボックスとパーソナライズされたクイズによるスキルの強化機能が用意されています。

Relay - 電子機器向けのリアルタイム Voice AI および Vision AI チューター | Gemini Live API + Google Cloud

この流れを推し進めましょう

素晴らしいプロジェクトに触発されましたか？Google の最新のプログラムやイベントを通じて、構築を開始し、コミュニティとのつながりを維持しましょう。

Gemini Enterprise Agent Ready（GEAR）にご参加ください。このプログラムは、開発者や意思決定者を支援し、プロダクションレディな AI エージェントを構築、デプロイできるように設計されています
Google Cloud Next 2026 の最新情報: Google Cloud Next は大盛況のうちに終了しました。会場にお越しいただけなかった方、あるいはもう一度あの熱気を味わいたい方は、SNS とライブ配信のハイライトをご覧ください。魅力的な開発者の活躍の一部を会場の雰囲気とともにお楽しみいただけます。
新しいツール、プロダクトの最新情報、今後のハッカソンについていち早く知りたい方は、毎週火曜日のライブ配信をお見逃しなく。午前 9 時（太平洋夏時間）/ 正午（東部夏時間）に配信が開始されます。Google Cloud の最新情報をチェックしてください。

受賞者の皆様、参加者の皆様、本当におめでとうございます。皆様が次にどのようなものを構築されるのか楽しみにしています。

- Google Cloud、プロダクトマーケティングマネージャー、Dilasha Panigrahi

Google I/O '26 が Google Cloud でのエージェント開発にもたらすもの

Mon, 01 Jun 2026 01:00:00 +0000

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

Google I/O では、Antigravity 2.0 と Managed Agents API を備えた統合開発ツールキットをご紹介しました。これにより、デベロッパーは共有プロトコルレイヤ上でローカルに構築し、クラウドに安全にデプロイできるようになります。このブログ記事では、Gemini Enterprise Agent Platform と Google I/O で発表された新しいデベロッパーツールの組み合わせ方、構築における選択肢の幅を整理し、実際にまず何から試すのがおすすめかをご紹介します。

Vertex AI が Gemini Enterprise Agent Platform に進化し、セッションメモリや一元化されたガバナンスなどの新機能により、エージェントの構築、スケーリング、管理、最適化を行うための包括的なプラットフォームとなりました。そして今回、これらの機能をローカルの開発ツールに直接展開します。Google の目標は、高速なプロトタイピングと、安全でコンプライアンスに準拠した企業向けデプロイの間のギャップを埋めることです。そのために、クイックスタートワークフローか、あるいはスタックの特定のニーズに合わせて本番環境を完全に制御するかを選択できる、モジュール式のアプローチを提供しています。

幅広い選択肢の中で、これらの要素がどのように位置づけられるかを整理すると、次のようになります。

4 つの段階: エージェント構築方法の全体像

エージェント開発のエコシステムは、4 段のはしごのようなものだと考えています。これは、すぐに使える構成から完全なコードファーストの制御まで、ニーズに合わせて調整できるスライダーのように設計されています。これらは意図的に積み上げ式に構成されており、下の段階から素早く始めたとしても、より高度なカスタマイズが可能な上の段階への移行が制限されることはありません。

4 つの段階すべてを支えているのが A2A プロトコルです。この相互運用性により、最初の段階で構築されたエージェントを 4 番目の段階でサブエージェントとして呼び出すことができ、アーキテクチャ全体を同じインフラストラクチャ上でシームレスにスケールできます。

1 段目: Agent Studio（ローコード）

Agent Platform 内のビジュアルワークスペース。Model Garden でモデルを見つけ、プロンプトをエンジニアリングし、ツールを接続して、コードを記述せずにエージェントをリリースします。ビジネス部門のチームや迅速なプロトタイピングに最適です。ここで構築するエージェントは、その下にあるすべてのものとまったく同じランタイムで実行されます。

2 段目: Managed Agents API

I/O で新たに発表された Managed Agents API は、「マシンではなくミッションを管理したい」と考えている技術チームを対象としています。エージェントの動作を定義するだけで、Google Cloud が煩雑な作業を代行するため、管理不要のサービスとしてのエージェント（Agent as a Service）として機能します。

Managed Agents API を使用してエージェントを構成し、Interactions API を使用してエージェントを呼び出します。指示、スキル、ツールをパッケージ化して POST すると、Gemini がエージェントを構築して実行します。

これをデプロイ可能にしているのは、安全性を重視して設計された Google Cloud サンドボックスです。エージェントハーネスは Google のサーバーで実行され、各エージェントには、スキル、Model Context Protocol（MCP）サーバー、サーバーサイドツールがプロビジョニングされた独自の一時的なサンドボックスがあります。A2A および Agent Platform のガバナンスおよびセキュリティとの完全なインテグレーションは、近日公開予定です。

3 段目: Antigravity とその仲間たち

Antigravity は、コーディングタスクやエージェントオーケストレーションに AI を活用したいと考えているデベロッパー向けの主要なソリューションであり、チームがアプリの構築とデプロイの方法を変革できるようにします。デベロッパー向けのコーディング戦略を、複数のサーフェスで共有されるこの単一の強力なハーネスに統合しました。

Gemini モデルファミリーと相互に最適化されており、高い効率性により開発サイクルを加速し、コストを削減します。Antigravity で開発したスキルは、さまざまなサーフェスでそのまま利用できるように設計されています。

コーディングワークフロー内で Google の高度な推論機能を活用し、カスタム開発ループを実装して、アプリケーションの構築、デプロイ、管理の方法を変革したいと考えている開発チームを対象としています。

このたび、以下の新しいツールによってこの機能を拡張しました。

Antigravity 2.0: コーディングエージェントの操作、カスタマイズ、オーケストレーションを行う一元化されたワークスペースを提供する、新しいスタンドアロンのデスクトップアプリケーションです。デベロッパーはこれを使用して、コードのリファクタリング、単体テストの生成、仕様に基づく新しいサービスコンポーネントのスキャフォールディングなど、エージェントをオーケストレートする複雑なタスクを管理できます。エージェントは 1 つのプロンプトからサブエージェントを生成でき、マルチエージェントオーケストレーションによりタスクを並行して実行できます。
Antigravity CLI: このツールを使用すると、Antigravity のすべての機能をコマンドラインで利用できます。Antigravity 2.0 と同じハーネス、同じエージェント、同じ品質のインテリジェンスを備え、ターミナルに合わせたプロダクトエクスペリエンスを提供します。速度とオーバーヘッドの削減に最適化されており、ユーザーに合わせて柔軟に変化します。CLI はデスクトップアプリと緊密に統合されており、認証、コンテキスト、スキル、構成を共有しているため、どちらのインターフェースでも一貫したエクスペリエンスが得られます。独自のランタイムを構築するには、Antigravity SDK を使用します。
エンタープライズセキュリティとコンプライアンス: Google Cloud のお客様は、Gemini Enterprise Agent Platform プロジェクトで Antigravity 2.0 と Antigravity CLI を使用できるようになりました。Cloud OAuth でログインし、Agent Platform プロジェクト ID とリージョンを設定するだけです。その結果、すべてのエージェント推論は安全なクラウド境界内の Agent Platform モデルを介して実行され、Google Cloud の標準的なデータプライバシー保護と利用規約を継承します。これにより、顧客データをお客様自身の管理下に置き、リージョンのモデルエンドポイントを利用できるようになります。

他のコーディングエージェントの統合

Antigravity は Google が推奨するエージェントコーディングソリューションですが、Google Cloud は、お客様が選択したあらゆるコーディングエージェントと連携して機能するように設計されています。Google のプラットフォームはオープンであり、柔軟性を確保するために次のようなツールを用意しています。

Agent CLI と Agent Development Kit（ADK）を使用すると、Claude Code などのツールを含むさまざまなソースからエージェントを構築して操作できます。つまり、デベロッパーは多くの場合、基盤となる AI 推論を Google Cloud で実行しながら、使い慣れたインターフェースを使い続けることができます。このアプローチにより、ワークフローにおいて Google Cloud のセキュリティ、コンプライアンス、インフラストラクチャのメリットを確実に享受できます。
Next でリリースされた Google Skills for Google products は、複数のコーディングツールと互換性を持つように設計されており、一貫した機能セットでさまざまなエージェントを強化できます。

この柔軟性により、チームは使い慣れたツールやモデルを統合し、確立されたワークフロー内でシームレスかつコンプライアンスに準拠した運用を確保できます。

4 段目: Agent Development Kit（ADK 2.0）

コードファースト、低い導入障壁（ローフロア）、高い柔軟性（ハイシーリング）。Managed Agents が構成ファーストであるのに対し、ADK はエンジニアリングファーストです。これは、カスタムエージェントメッシュをゼロから構築したいソフトウェアエンジニア向けのツールです。アーキテクチャやモデルを問わず、制約のない自由な開発が可能です。

ADK の機能強化が Google Cloud Next で発表され、すべてのお客様にご利用いただけるようになりました。ADK には、動的なモデル主導の推論から厳格かつ決定論的なワークフローまでスライダーで調整できる、グラフベースの統合エンジンが導入されています。このフレームワークは、サブエージェント、ツール、データが相互にどのように受け渡されるかを管理し、マルチエージェントの連携という煩雑な作業を処理します。

コラボレーションワークフロー（Python v2.0.0）: 以前はタスクベースのエージェントコラボレーション API と呼ばれていました。これは、自己管理型エージェントチームを構築するための機能です。コーディネーターは、明示的な動作モードを使用してサブエージェントに委任します。

チャット: 完全なユーザーインタラクション、親エージェントへの手動での復帰。これは「サブエージェントへの会話の引き渡し」です。
タスク: ユーザーインタラクションによる明確化、親エージェントへの自動復帰。これは新しい「この課題での共同作業」であり、他の 2 つのオプションの長所を兼ね備えています。
シングルターン: ユーザーインタラクションなし、並列実行、自動復帰、「ツールとしてのエージェント」。

動的ワークフロー: ADK の動的ワークフローでは、グラフベースのパス構造を脇に置き、選択したプログラミング言語の機能を最大限に活用してワークフローを構築できます。動的ワークフローでは、シンプルなデコレータでワークフローを作成し、ワークフローノードを関数として呼び出し、複雑なルーティングロジックを構築できます。
ADK Kotlin（ベータ版）:「ADK for Android」。Kotlin のサポートが加わったことで、Python、Go、Java と合わせて対応言語が増え、オンデバイスのモバイルエージェントとバックエンドの Python エージェントをシームレスに連携させることができます。

最後に、Agents CLI は、ADK、評価、デプロイ、オブザーバビリティ、公開に関する Google のエキスパートスキルをパッケージ化し、あらゆる AI コーディングエージェント（Antigravity、Gemini CLI、Claude Code、Cursor など）をエージェントアプリ構築とエージェントオペレーションのエキスパートに変えます。これにより、AI エージェントに Google Cloud エージェントスタックを理解するスキルが与えられ、広大なエコシステムが、エージェント構築の山登りに挑むデベロッパーにとってシームレスな組み立てラインに変わります。

これからの展開にご期待ください

エージェントの分野は急速に進化しています。Agent Platform は、安全かつ柔軟性に優れた基盤を提供します。Agent Gateway、ID 管理、Skill Registry などのコアコンポーネントが連携して、エージェントのための堅牢で管理された環境を確保し、ベンダーロックインなしで柔軟にイノベーションを実現できます。

プロジェクトに合った段階を選んでも、チームが好むコーディングエージェントを導入しても、どちらの場合も、最終的に行き着くプラットフォームは同じです。データは常に Cloud プロジェクト内に留まります。

この投稿を読んだ後に 1 つだけドキュメントを読むなら、Agent Platform のドキュメントにあるエージェントの概要をおすすめします。興味深いものを作成された際は、ぜひ共有してください。優れた事例は、次回のテンプレートに採用させていただきます。

皆様が構築されるソリューションを楽しみにしております。

- Google Cloud AI、ディレクター、Addy Osmani

- Google Cloud、プロダクトマネージャー、Alan Blount

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 0x7fc24b3d55b0>)])]>

エージェントはすぐに、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 0x7fc24b3d5580>)])]>

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 0x7fc24b3d52b0>)])]>

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 0x7fc24b3d5340>)])]>

仕組み

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 0x7fc24b3d5ac0>)])]>

バックグラウンドでは、デプロイは 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 0x7fc24b3d59d0>)])]>

アシスタントはブラックボックスの中で動作しているわけではありません。ナレッジベースから一般的な 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 0x7fc24b3d5e80>)])]>

その後、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 0x7fc24b3d54f0>)])]>

パイプラインを定義したら、それを自動的に実行する方法が必要です。エージェントは、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 0x7fc24b3d5550>)])]>

セキュリティと管理

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 0x7fc24a3406d0>), ('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 0x7fc24b486640>)])]>

パート 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 0x7fc24b486bb0>)])]>

ルーティングパイプラインを構成するには、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 0x7fc24b4861c0>)])]>

上記の 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 0x7fc24b486d60>)])]>

具体的な指示とこのカスタムツールセットを装備したエージェントは、外部のコンテキストを積極的に収集することでアラートを自律的に調査します。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 0x7fc24a6d7820>), ('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 0x7fc24a6d7250>), ('btn_text', ''), ('href', ''), ('image', None)])]>

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

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

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

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

aside_block: <ListValue: [StructValue([('title', 'ラボに移動'), ('body', <wagtail.rich_text.RichText object at 0x7fc24a6d7d60>), ('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 0x7fc24a6d7400>), ('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 0x7fc24a6d7460>), ('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 0x7fc24a259160>)])]>

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

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

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 0x7fc24a259a60>)])]>

これにより、エージェントや 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 0x7fc24a5d3580>)])]>

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 0x7fc24a5d3790>)])]>

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 0x7fc24a5d3c40>)])]>

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

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

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

エージェント機能の構築: 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 0x7fc24a5d39d0>)])]>

ツールの構成

ツールセットは 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 0x7fc24a5d3ee0>)])]>

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 0x7fc24a5d3310>)])]>

画像生成ツール（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 0x7fc24a5d37c0>)])]>

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 0x7fc24a5d3520>)])]>

サーバーエントリポイント（`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 0x7fc24a5d3700>)])]>

生成ロジック（`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 0x7fc24a5d3490>)])]>

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 0x7fc24a5d3a00>)])]>

データモデル（`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 0x7fc24a5d3910>)])]>

ツールの依存関係（`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 0x7fc24a5d3610>)])]>

まとめ

シリーズのパート 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 0x7fc2486c0e20>)])]>

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

ステップ 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 0x7fc2486c07f0>)])]>

これで、評価担当者が 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 0x7fc2486c0760>)])]>

これで、リサーチャー（ポート 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 0x7fc2486c0af0>)])]>

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

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

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

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

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

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

構築を始めるにあたって

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

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

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

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

デベロッパー

Google Cloud Storage MCP サーバーを活用した AI エージェントと非構造化データの連携

Google Cloud Storage でのエージェントの実際の成功事例

（Airwallex AI アシスタントのご紹介: グローバルな財務処理を簡単に実現するコンシェルジュ）

MCP を使用してエージェントを GCS に接続

使ってみる

TPU、GKE マネージド DRANET、マルチクラスタ推論ゲートウェイを使用したテスト

構成要素

設計パターンの例

設定手順

フェイルオーバーのテスト

次のステップ

Cloud Run での AI のコールド スタートに関するガイド

Cloud Run でカスタムモデルを使用して AI アーキテクチャを構築する

AI のコールド スタートの仕組み

AI のコールド スタートを処理するためのベスト プラクティス

フェーズ 4 の最適化

スケーリングと信頼性に関する戦略

Elastic の戦略から得られる教訓

準備ができたら

Gemini API キーと Google API キーの保護

ステップ 1: 新しい API キーを生成する

API の制限

アプリケーションの制限

ステップ 2: API キーを保存する

問題が発生した場合

すべての API キーを確認する

API の使用量を確認する

ステップ 3: API キー管理のハイジーン

まとめ

Gemini Live Agent Challenge: 受賞者とハイライトを発表

Google Cloud Next '26 で各部門の受賞者を発表

受賞者

Orion - 音声指示による手術 AI アシスタント | Gemini Live Agent ハッカソン

ドローン コパイロット: Gemini Live API を使用した音声制御ドローンと自律検査

Sankofa デモ動画

Moonwalk のデモ動画 #geminiliveagentchallenge

Wand -- ユーザーとともに見て、検索して、クリックするライブ対応エージェント

JohnKeats.AI — 黙るべき時を知るために構築された初の AI エージェント

Rayan - 3D の記憶の宮殿が聞き取り、記憶し、話しかける

Ekaette - マルチモーダル AI 音声およびメッセージング アシスタント

vibeCat - プロアクティブなデスクトップ コンパニオン

Call My Parts AI Tool : ハッカソン Gemini Live 2026

Relay - 電子機器向けのリアルタイム Voice AI および Vision AI チューター | Gemini Live API + Google Cloud

この流れを推し進めましょう

Google I/O '26 が Google Cloud でのエージェント開発にもたらすもの

4 つの段階: エージェント構築方法の全体像

他のコーディング エージェントの統合

おすすめの開始手順

これからの展開にご期待ください

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 エージェントの拡張

Cloud Run での AI のコールドスタートに関するガイド

AI のコールドスタートの仕組み

AI のコールドスタートを処理するためのベストプラクティス

ドローンコパイロット: Gemini Live API を使用した音声制御ドローンと自律検査

Ekaette - マルチモーダル AI 音声およびメッセージングアシスタント

vibeCat - プロアクティブなデスクトップコンパニオン

他のコーディングエージェントの統合

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

あらゆるインフラストラクチャで、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）`

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