GCP News - 2026-10-09

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

AI インフラストラクチャの需要はかつてないほど高まっています。世界的なアクセラレータ不足により、エンジニアリング チームが 1 つのデータセンターだけで必要なコンピューティング容量をすべて確保できることはほとんどありません。容量はあちこちのクラスタから、それも多くの場合、海を隔てた場所から確保されます。同時に、ワークロードはより多くの容量を必要とするようになっています。昨今の長時間実行されるエージェント ワークロードは、10 万～80 万以上のトークンのコンテキスト ウィンドウを持つことが多く、前の世代の AI トラフィックよりもはるかに速いペースでアクセラレータ メモリを消費します。

このような環境では、「1 ドルあたりのインテリジェンス」を最大化することが目標となります。しかし、断片化され、適切に負荷分散されていないインフラストラクチャでは、この要求に応えることは困難です。高価なアクセラレータがアイドル状態のまま放置される一方で、別の場所ではリクエストが処理待ちのキューに滞留してしまう、といった事態を招きかねません。

このギャップを埋めるために、Google は、世界中に分散した容量を単一のエントリ ポイントの背後にある単一のプールのように動作させる、階層型ルーティング アーキテクチャを構築しました。エッジでは、マルチクラスタ GKE Inference Gateway が、グローバルなマルチリージョン トラフィック分配と高可用性を担います。その下では、LLM-d ルーターが、使用率を高く維持する複雑なメモリ認識型スケジューリング アルゴリズムを処理します。

このアーキテクチャは、ランタイム、モデル、アクセラレータに依存しないように設計されており、サービング フレームワーク、モデル ファミリー、GPU または TPU ハードウェアを問わず機能します。単なる抽象論ではなく、具体的な成果を示すために、Google は最近、米国と欧州に分散した 17,000 のコンピューティング ノードで構成されるマルチリージョン GKE デプロイ全体において、本番環境レベルのグローバルなリクエスト ルーティングを大規模に処理する際のベンチマーク評価を実施しました。このデプロイでは、SGLang を使用して、主要な Mixture of Experts（MoE）基盤モデルをサービングしました。

結果: 3 つのクラスタにスケールすることで、多数のクライアントが同時にアクセスする高負荷な状況でも、99.9% の成功率を維持しつつ、ほぼ線形のスループット向上を達成しました。さらに、マルチクラスタ GKE Inference Gateway を介してトラフィックをルーティングすると、オーバーヘッドが 1% 未満に抑えられ、直接的なローカル クラスタ呼び出しのスループットの 99.5% を実現しました。

その仕組み、ベンチマークの結果の詳細、分散推論デプロイにおける意義について、以下で詳しく説明します。

3 つのリージョン、1 つのエンドポイント

デプロイは、us-east5（構成クラスタ）、us-west8、europe-west4 の 3 つの地理的リージョンにある 3 つの GKE クラスタにまたがっていました。しかし、クライアントの観点からは、そのような地理的な要素は存在しません。リクエストは単一のグローバル仮想 IP に到達し、ゲートウェイがリアルタイムで、各リクエストをどのクラスタで処理するかを決定します。

その決定を盲目的なものではなく、スマートなものにするのがテレメトリーです。ネットワーク層における従来のラウンドロビン ルーティングに代わり、マルチクラスタ ロードバランサは、アプリケーションのリアルタイムのシグナルに基づいてトラフィックをルーティングするように構成されています。具体的には、Endpoint Picker Proxy（EPP）が、基盤となる推論エンジンによってネイティブに公開される KV キャッシュ トークン使用率を読み取り、ロードバランサの指標として出力します。ロードバランサは、この出力された指標に基づいてリージョンが過負荷状態になっていることを確認すると、トラフィックを次の正常なリージョンに転送します。

これがトレードオフのすべてです。グローバル ロード バランシングのすべてのメリットを、実質的に無料で利用できます。

リージョン間の線形スケーリング

さらに大きな試練は、スケーリングです。テストでは、すべてのクライアント リクエストを単一のリージョン（us-east5）から送信しつつ、フリートを 1 つのクラスタから米国と欧州にまたがる 3 つのクラスタへと拡大しました。これにより、Gateway には大きな負荷がかかることになります。これほど離れた距離間で負荷を効率的に分散できなければ、ハードウェアを追加してもスループットは横ばいになってしまいます。

代わりに、スループットは容量とほぼ完全に比例して増加しました。

That’s the whole trade-off. All the benefits of global load balancing, essentially for free.

Linear scaling across regions 

A bigger test is scale. In our test, growing the fleet from one cluster to three, spanning the US and Europe, while every client request originated from a single region (us-east5), put real pressure on the Gateway: If it couldn’t distribute load efficiently across those distances, throughput would flatten as hardware was added. 

Instead, throughput multiplied almost exactly in line with capacity: 

3 つのクラスタにスケールすることで、多数のクライアントが同時にアクセスする高負荷な状況でも、99.9% の成功率を維持しつつ、ほぼ線形のスループット向上を達成しました。

メモリを考慮したルーティングの動作

ラウンドロビン ロード バランシングは、すべてのリクエストを均等に扱うため、LLM のサービングには適しません。まったくもって、不向きです。重いプロンプトは GPU コンピューティング コアを飽和させ、長文の生成はメモリ帯域幅を圧迫し、コンテキストの長い会話は VRAM を静かに消費し続け、最終的にエンジンが新しいリクエストをスケジュールできなくなってしまいます。

ここでは、メモリ帯域幅への負荷は、このデプロイで採用されたルーティング シグナルに起因していました。Inference Engine ネイティブのトークン使用量指標を Gateway の KV キャッシュ シグナルにマッピングすることで、ルーティング プレーンは 17,000 におよぶフリート全体のメモリ負荷をリアルタイムに把握できるようになりました。（ワークロードに応じて、キューの深さや実行中の同時実行数など、他のシグナルに基づいてルーティングすることもできます）。

本実際の運用負荷がかかる中、プライマリ リージョンが高帯域幅メモリ（HBM）の上限に近づくと、Gateway はクラスタの KV キャッシュ使用率がしきい値である 40% を超えた瞬間に飽和状態を検出し、即座に、オーバーフローを次の正常なリージョンへと自動的にルーティングし始めました。オペレーターの介入は必要ありませんでした。複数リージョンでの運用に伴う複雑さを、ユーザーが意識する必要はまったくありませんでした。

価値の提供

この GKE Inference Gateway の構成は、リアルタイムの KV キャッシュ使用率に基づいてトラフィックをルーティングすることにより、世界中に分散したコンピューティング容量を 1 つの統合エンジンに効果的にプールします。このデプロイでは、3 つのグローバル リージョンでほぼ線形のスループット向上が実現し、ルーティングのオーバーヘッドは実質的にゼロでした。

これは、資本を無駄にすることなく、フリートに追加するすべてのアクセラレータからほぼ完璧に比例するパフォーマンスを引き出し、「1 ドルあたりのインテリジェンス」を最大化することに直結します。

チームへの影響

独自の分散推論デプロイを計画している場合、この取り組みから得られた 5 つの教訓が参考になります。

• よりスマートなロード バランシングは、それ自体が価値を生み出します。ラウンドロビン ルーティングでは、メモリやコンピューティングの負荷を把握できないため、高価な GPU 容量を無駄にしてしまいます。リアルタイムのアプリケーション シグナルに基づくルーティングにより、断片化されたリージョン クラスタが 1 つの効率的なフリートに統合されます。これにより、ハードウェアが遊休状態になるのを防ぎ、希少なコンピューティング リソースの利用率を 90%以上に高めることができます。

• エージェント ワークロードがボトルネックを変化させます。極めて大きなコンテキスト ウィンドウを持つ長時間実行型のエージェントは、コンピューティング リソースが限界に達するずっと前にメモリを使い果たしてしまいます。ルーティング レイヤがメモリ負荷を認識できない場合、VRAM が満杯になったノードの陰に、まだ余裕のあるコンピューティング容量が取り残されてしまいます。KV キャッシュの使用率を最優先のルーティング シグナルにします。

• AI トラフィックがウェブ時代の前提を覆します。従来のロードバランサは 1 秒未満のトランザクション向けにチューニングされていますが、LLM リクエストは数分間実行されることがあります。AI 規模のレイテンシを考慮して、接続上限とタイムアウトを早期に計画してください。そうしないと、本番環境で接続が中断される可能性があります。

• ルーティング レイヤは、ネイティブのサービング パターンと統合する必要があります。分散 LLM エンジンには、特定の Pod のみがトラフィックを処理できるマスターワーカー トポロジがあります。Gateway を LeaderWorkerSet（LWS）などのネイティブな Kubernetes 構造と組み合わせることで、グローバル ルーティングはローカル Pod トポロジをそのまま考慮した制御を行い、チームがカスタム プロキシ インフラストラクチャを構築する必要がなくなります。

• 大規模な基盤モデルの構築には、オープンでポータブルなスタックが最適です。業界最先端の規模で運用しているチームは、容量の断片化という最も深刻な課題に直面しています。そのため、空き容量があるリージョンならどこであっても、コンピューティング リソースを探し回ることを余儀なくされています。GKE 上の LLM-d のようなオープンでポータブルな推論スタックを使用すると、単一のクラスタ、リージョン、または独自のインフラストラクチャにサービング アーキテクチャを固定することなく、空き容量がどこにあっても吸収できます。

次のステップ

分散アクセラレータの効率を最大化し、マルチクラスタ GKE Inference Gateway でグローバルなクロスリージョン ロード バランシングを設定する準備はできましたか？

1. 自分でデプロイする: マルチクラスタ GKE Inference Gateway を設定する。

2. アーキテクチャを理解する: マルチクラスタ GKE Inference Gateway について。

3. この投稿で紹介したクロスリージョン スピルオーバーの動作については、弾力性のあるクロスリージョン高可用性についてと弾力性のあるクロスリージョン高可用性を構成するをご覧ください。

- Google Kubernetes Engine、プロダクト マネージャー、Fisayo Feyisetan

- Google Kubernetes Engine、ソフトウェア エンジニア、Sina Chavoshi

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

Google Earth Engine では、スクリプトを記述することで、地球全体の森林面積を確認したり、建造環境の変化を検出したり、農作物の収穫量をモニタリングしたりでき、分析情報を得るための強力なツールとなります。Google Earth Engine は、地理空間モデルとデータセットのコレクションである Google Earth AI の一部を構成するプラットフォームです。Google Earth AI によって、地球規模の情報を実用的なインテリジェンスに変換することができます。この地球規模のインテリジェンスにさらに簡単にアクセスできるよう、このたび、新しい質問機能「Ask」を導入しました。

複雑な地理空間ロジックをコードに変換するのには、時間がかかります。また、特定の Google Earth Engine API 関数を記憶したり、ドキュメントを検索したり、構文エラーやメモリ不足エラーをデバッグしたりすると、作業の流れが中断されることがあります。「Ask」は、Gemini の機能を Google Earth Engine コードエディタに直接統合することで、行動につながるインサイトをより迅速に取得できるように設計されています。

早速、本日からでも、コードエディタから直接「Ask」を利用して、地理空間クエリの作成、デバッグ、理解、最適化に活用しましょう。

仕組み: コンテキストアウェアなアシスタント

コードエディタで直接質問すると、以下のようなワークスペースのコンテキストに基づいて、回答が表示されます。

• 作業中のスクリプト全文

• インポートしたアセットとジオメトリ

• 進行中のセッションのチャット履歴

Gemini in Google Earth Engine は、ユーザーの作業を自動的に理解するため、質問にコードを追加したり、データセットを説明したりする必要はありません。Gemini はこれらの詳細をすでに把握しており、より関連性の高い、有益な回答を提供します。さらに、Gemini が提示したスクリプトとの差分を自動表示して自分のスクリプトにマージすることもでき、コピーして貼り付ける必要はありません。

また、「Ask」をパーソナライズして、より包括的でニーズに合った回答を得ることもできます。たとえば、以下のことを実現できます。

• 最新の Gemini モデルにアクセス: ニーズに合った Gemini モデルを選択できます。現在、利用可能なモデルは、Gemini 3 Flash プレビュー版、Gemini 3.1 Pro プレビュー版、Gemini 3.5 Flash です。

• ドキュメント検索: AI を使用して、公式ドキュメントから最新の構文と関数を検索できます。

• データセット検索: AI による Earth Engine Data Catalog の検索を可能にして、必要なデータセットを確実に見つけて参照できます。

• Google 検索: Google 検索によるグラウンディングで、最新の公開ウェブ検索の結果で回答をグラウンディングします（ドキュメント検索およびデータセット検索とは併用できません）。

活用方法の例

どのように利用を開始したらよいかわからない場合は、ワークフローで Ask を使用する 4 つの方法を以下に紹介しますので、参考にしてください。

1. 自然言語からコードを生成する

NDVI（正規化植生指標）を計算したり、雲マスクを実行したり、グラフを作成したりしたいのに、正確な構文を思い出せないことはありませんか。そのような場合は、Ask にリクエストするだけで、Earth Engine が JavaScript コードを生成してくれます。チャットでコードを直接確認し、[挿入] をクリックしてスクリプトに追加するか、[コピー] をクリックしてクリップボードにコピーできます。エディタですでにコードの下書きを記述中の場合、チャットからコードを挿入すると、変更を適用する前に違いを確認できるよう、差分が並列表示されます。

プロンプトの例: 「2025 年のコロラド州ボルダーの Sentinel-2 画像を読み込み、雲マスクを適用して NDVI を計算し、中央値合成を地図に追加するスクリプトを記述してください。」

2. 複雑なコードを解説させる

同僚が作成したスクリプトを扱う場合や、コミュニティからのサンプルを応用する場合は、Gemini の機能を使用して構成やロジックを解説してもらうことができます。「このスクリプトの動作を説明してください」と尋ねるだけで、使用されているロジックと Earth Engine 関数の詳細な説明が得られます。

3. ワンクリックでトラブルシューティングとデバッグを実行する

デバッグはコーディングに不可欠なプロセスです。Google Earth Engine でスクリプトにエラーが生じると、コンソールにエラー メッセージが表示されます。このメッセージに [トラブルシューティング] ボタンが追加されました。クリックすると、エラー メッセージを引用しながら問題の診断と修正案を求めるプロンプトが [Ask] パネルに自動的に入力されます。

4. クエリを最適化する

たとえば、スクリプトの実行速度が遅い、リソースの消費効率が悪い、「計算がタイムアウトしました」や「同時集計が多すぎます」というエラーが発生するなどの場合は、最適化のヒントを求めましょう。Gemini には、早期のフィルタリングや計算ステップの削減、あるいはクライアントサイドのループをサーバーサイドでの処理に変換するなどのベスト プラクティスを提案する機能があります。

利用を開始するための 2 ステップ

Ask は現在、世界中でご利用いただけます。Gemini API キーがあれば、すぐに利用を開始できます。

1. API キーを取得する: Gemini API キーをまだお持ちでない場合は、Google AI Studio にアクセスして作成してください（無料オプションがあります。有料プランの API キーを選択した場合は、使用量に応じて課金されます）。詳しくは、Gemini API の利用規約をご覧ください。

2. API キーを Google Earth Engine に追加する: Google Earth Engine コードエディタを開き、右側のパネルで、[Ask] パネルをクリックしてください。左下隅にある鍵アイコンをクリックして、API キーを入力します。

ご意見、ご感想をお聞かせください。コードエディタの [フィードバック] ボタンを使用してフィードバックをお寄せいただければ幸いです。エクスペリエンスの向上にご協力のほどよろしくお願いいたします。

- プロダクト リード、Joel Conkling

- ソフトウェア エンジニア、Katie Friis

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

本日開催した Gemini at Work 2026 において、Google Cloud の CEO である Thomas Kurian は、以下を含む数々の発表を行いました。 

• Gemini は、業務のためのひとつの汎用的なエージェントとして、ユーザーの質問への回答、ナレッジワークの処理、画像やメディアの作成、コードの記述や実行を行います。

• Google Workspace のインライン機能により、Gemini は Gmail、Google ドライブ、Google ドキュメント、Google スライド、Google スプレッドシート、Google Chat、Google カレンダーの内部で直接機能し、どこで使用する場合でも同一のメモリ、スキル、ガバナンス制御を維持します。

• 新しいデータとアナリティクスのスキルにより、技術チームと日常業務を行うビジネスユーザーの双方が、自然言語の質問を用いて、実用的な運用インサイトを数分で取得できるようになります。

• アイデンティティとポリシー管理、認可および権限の制御、セキュアなサンドボックス環境、ネットワーク ゲートウェイなどを通じて、エージェントを保護し、ガバナンスを維持します。

Gemini エージェントが登場 

過去 1 年間で、500 近い Google Cloud のお客様のそれぞれが 1 兆個を超えるトークンを処理しました。現在、全 Google Cloud お客様の約 80% が AI 製品を利用しており、Fortune 100 企業の約 90% が Gemini Enterprise を採用しています。このような規模において、企業や組織は実証実験の域を超え、AI を基盤として業務を運用しています。 

いまや仕事の多くは、プロンプトの入力から始まります。 

Kurian は次のように述べています。「この時代の重要な局面に応えるため、本日、Gemini エージェントを発表します。これは、皆様の業務のための新しいひとつの汎用的なエージェントです。ビジネスのあらゆるコンテキストを把握し、ナレッジワークから質問への回答、コンテンツ作成からコーディングまで、すべてを単一のプロンプト ボックスから行うことができます。作業の計画を立て、スキルやツールを活用し、お客様のシステムに接続した上で、すでに作業で使用しているドキュメント、受信トレイ、開発環境の内部に完成した成果物を直接反映します。作業に最適とされるモデルを選択し、コスト制御機能を内蔵しているほか、何よりもお客様の企業において求められるセキュリティ、管理、ガバナンスを備えています。」

Gemini は質問への回答、ナレッジワークの処理、画像やメディアの作成、コードの記述と実行に対応し、すべてを単一のエージェントと単一の API で処理します。指示ではなく目標を与えるだけで、お客様は作業をすべて委託し、完成した成果物を受け取ることができます。エージェントがそれを実行するためには、個人のワークフロー、記録システム、そして企業のガバナンス制御に接続されている必要があります。 

Gemini はパーソナル アシスタントとしての役割だけでなく、プロジェクトマネージャーのようにチームメンバーとして動いたり、時には財務部門のアナリストのように機能したり、組織内の特定の役割を担って動くことができます。 

Gemini のエージェント機能は、主要なアーキテクチャ原則に基づいて構築されています。 

• 統合エージェント: Gemini は、チャットでの質問回答、割り当てられた目標を達成するための自律的な動作、コードの生成をすべて単一のインターフェースから実行できるエージェントです。作業の割り当て、タスク完了までのスケジューリング、イベントへの応答などを指示できます。

• どこからでもアクセス可能: Gemini は、Web、iOS および Android のモバイル デバイス、Windows および Mac のデスクトップを含むあらゆるデバイス、そして各種チャネル（コマンドライン、Google Workspace、Microsoft 365、Slack）からアクセス可能です。また、サードパーティ製アプリケーションやサーフェスに組み込むことができ、ヘッドレス エージェントとして機能するため、専用のユーザーインターフェースを必要としません。

• 永続的な実行: クラウド上で動作するため、アクセスするデバイスやチャネルに関係なく、単一のメモリセット、コンテキスト、1 つのパーソナライズ グラフを維持します。数時間や数日かかる作業であっても、PC を閉じた後も処理が継続され、戻ってきた際にもそのまま維持されます。

• マルチエージェント オーケストレーション: Gemini は、マルチステップのタスクに取り組むため、それぞれが固有のアイデンティティを持つ一時的なジョブ固有のサブエージェントのロースターを動的に作成し、これらと通信して、数時間または数日間にわたって実行される並列および直列ステップを調整します。さらにGemini は、@agents.company.com といった独自のメールアドレスや永続ストレージを含む専用のアイデンティティを持ち、ユーザーやチームメンバーが提供するコンテキストにのみアクセスできるコワーカー エージェントとして機能します。

• 深いコンテキスト理解: Gemini は、ツール、データ、作業履歴をすでに把握しており、あらゆるやり取りから学習します。チームで専用プロジェクトを作成することで、Gemini が連携して作業する際に使用するコンテキスト、スキル、ツールをさらに最適化できます。

• 柔軟なモデル選択: Gemini はエージェントであり、その下で動くモデルは状況に合わせて選択します。各ジョブにおいて最も適したモデル上で動作し、現時点では Google の Gemini モデル ファミリーや Anthropic の Claude モデル、将来的にはその他の主要なプライベート モデルおよびオープン モデルを横断してオーケストレーションを行うことで、最適とされる品質の提供とコスト削減を実現します。タスクにとって最適とされるモデルが、常に最も大規模なモデルであるとは限りません。作業とモデルを一致させることで、難度の高いジョブでの精度向上と、シンプルなジョブでのコスト削減を両立します。また、先行するモデルは数か月ごとに変化するため、この選択肢をオープンに保つことで、モデルが変更されてもコンテキスト、スキル、データはそのまま保持されます。

業界をリードするお客様企業が初期テスターとして 、すでにその効果を実感しています。プレミアム スポーツウェア ブランドの On は、市場投入スピードを加速させるためにこの新しい動的選択機能を検証しました。これは、すでに他社で実績のある大規模なマルチモデル戦略に基づいています。Shopify は数百万の事業者のためにフロンティア モデルを組み合わせてデータを活用し売上を促進しており、PayPal は毎週 1,000 万件のマルチモデル リクエストをルーティングしています。

Gemini を支える機能：スキル、ツール、コンテキスト

Gemini は、価格設定からプロダクト ポートフォリオ、部門ごとの規範に至るまで、お客様のビジネスや固有の組織の知識を理解しています。これを可能にするのが、システムと接続する「ツール」、作業手順を教える「スキル」、そして記憶を維持する「コンテキスト」の 3 つの機能です。

• ツールとツール レジストリ： Confluence、Microsoft Office、Teams、Slack、Google Workspace などのコラボレーション ツール、Git や Jira などの開発ツール、Salesforce や ServiceNow などのエンタープライズ プラットフォーム、BigQuery、Databricks、Postgres、Snowflake などのデータベース、デスクトップ上のファイルなど、自社で運用しているソフトウェアに安全に接続できます。また、社内外のネットワークにある Model Context Protocol（MCP）サーバーと安全に接続して機能させることも可能です。さらに、企業向けツール レジストリを提供しているため、チームでツールを構築し、社内全体に公開できます。

• スキルとスキル レジストリ： Gemini は豊富なグローバル スキル ライブラリを持っています。チームはカスタム スキルを構築し、企業の共有レジストリに公開でき、個人のカスタム スキルを構築することも可能です。Gemini はタスクを実行するために適切なスキルとツールを選択し、実行のたびに継続的に学習して一貫性を向上させながらトークンコストを削減します。

• コンテキストとメモリ： Gemini は、受けた質問や与えられた目標、一緒に働く人々から学習し、さらにはユーザー個人および組織のコンテキストを使用して回答をパーソナライズし、品質を向上させます。Gemini はまるで新入社員のように、自身をオンボーディングし、作業を開始する前にユーザー、ツール、チームについて学習します。

Gemini in Google Workspace

Gemini は、質問への回答や、ナレッジワークの処理、コード記述を行うだけではなく、Gmail、Google ドライブ、Google ドキュメント、Google スライド、Google スプレッドシート、Google Chat、Google カレンダーの中部で直接機能し、どこで使用する場合でも同一のメモリ、スキル、ガバナンス制御を維持します。メールのスレッド内や、ドキュメント、チャットスペースの中など、作業しているその場所（インライン）でそのまま作動します。

Google Workspace 内で、Gemini は 3 つの方法で機能します。

• パーソナル アシスタント： Gemini はパーソナル エージェントとして、カレンダー、チーム、プロジェクト、ドキュメントなどの関連性をあらかじめ把握し、指示を出す前からコンテキストを把握しています。たとえば、名前やメールアドレスを一つも入力することなく「来週、いつもの地域イベント担当チームとの会議を設定して」と依頼できます。Gemini はチャットスペースや過去のイベント スレッドから該当者を特定し、カレンダーを確認して、社外の参加者を含めて時間調整のメールを送ります。アプリケーションをまたぐ作業も同様に処理します。

• プロアクティブな委任：Gemini は同様のインテリジェンスを活用して、ユーザーが委任できるタスクをプロアクティブに提案します。最後に届いたメッセージではなく、最も重要度の高いインボックス内のメッセージを、その理由とともに強調表示します。

• チームメンバーとして活躍：Gemini を使って、チーム全体と協働するコワーカー エージェントを作成することもできます。エージェントにはメールアドレス、カレンダー、Google ドライブ、会社ディレクトリへの表示を含む独自の Google Workspace アカウントが付与されます。そして、Google Chat のスペースに追加したり @メンション したりすることで、同僚と連携するのと同様に操作できます。コワーカー エージェントはユーザーではなく独自のアイデンティティとして機能し、共有された内容のみを閲覧できます。アクセス権限はチームが既に使用している共有設定に従い、外部のコネクタがデータを保持することはありません。

データ分析、データ エンジニアリング、および機械学習

また、データ分野をはじめとする特定ドメイン向けのスキルを Gemini に提供します。

技術チームと一般的なビジネスユーザーの双方に合わせた専用機能を導入します。

• データおよび ML エンジニア向け： 機械学習のスキルとツールで Gemini を拡張し、すべてのデータ サイエンティストとデータ エンジニアをエージェント チームでバックアップします。エンジニアが望む成果を自然言語で説明すると、Gemini は PySpark コードを生成し、編集およびテスト用のノートブックを提供し、モデルをトレーニングし、パイプラインの問題を自律的にトラブルシューティングして修正します。

• ビジネス ユーザー向け： 組織内の誰もが、質問するだけで信頼性の高いリアルタイムのBigQuery や Knowledge Catalog と統合されたオペレーション レポートを生成できます。一度保存されれば、トークン コストを発生させることなくオンデマンドでレポートを実行でき、常に一貫した検証済みの回答が保証されます。

エージェントのセキュリティ保護とガバナンス

組織全体に自律型エージェントをデプロイするには、ガバナンスが重要です。

• アイデンティティ： すべてのエージェントに独自のアイデンティティが付与され、従業員と同様に管理されます。そのアイデンティティは、作業を記録するログや、代わりにコードを実行するために起動された仮想マシンに記録されます。

• 承認と権限： 各エージェントには、組織のセキュリティ管理者によって承認された、きめ細かいロールベースのアクセス権限が付与されます。Gemini エージェントが外部システムに接続する際、そのアイデンティティは OAuth などの業界標準を通じてマッピングされ、連携されます。

• 監査： Gemini が実行するすべてのアクションは監査証跡に記録され、人間ではなくエージェントに紐付けられます。Google Cloud のオブザーバビリティ ツールを使用して、これらのログをリアルタイムで監視し、問題が発生する前に異常な動作を検知できます。

• ポリシー管理と制御： Geminiは、デフォルトでアイデンティティ、検出、ガバナンス、セキュリティを提供します。すべての Gemini エージェントは独自のネットワーク境界を持つ Agent Sandbox 内で安全にタスクを実行します。エージェントへの入出力、およびエージェント間のすべてのトラフィックは、組織のポリシーをリアルタイムで適用する AI ネットワーク ファイアウォールである Agent Gateway を通過します。ポリシーを一度作成すれば、Gemini はそれを社内のすべてのエージェントに一括適用するため、エージェントごとに個別に確認する必要はありません。

インフラストラクチャ：コストパフォーマンスを 80% 向上

エージェント、データ、アイデンティティを含むこれらのイノベーションはすべて、Google Cloud の AI インフラストラクチャおよびモデル上で動作します。これこそが高い経済性を実現できる理由です。

Google Cloud の AI インフラストラクチャは、共同設計したチップ、ネットワーク、データセンター、およびそれらを一つに接続するソフトウェアで構成される、高度に最適化された AI ハイパーコンピュータで構築されています。この垂直統合により、一般的な環境と比較して優れた価格対性能比を実現しており、この分野で最先端の技術革新を推進し続けています。たとえば、最新の TPU 8i システムは、前世代と比較して価格対性能比を 80% 向上させており、複雑で付加価値の高いエージェント タスクを高速かつ手頃なコストで実行できます。

この基盤の上で、Google のモデル群が稼働します。最先端の推論を担う Argon、速度と処理量に優れた Flash、生成メディア用の Omni、そして軽量でオープンウェイトのエッジ ワークロード向け Gemma です。

日本での Gemini Enterprise の活用事例

日本企業をはじめとする多くの組織が、Gemini Enterprise を活用して成果を上げています。以下はその一例です。

• 株式会社日立製作所は、AI 駆動型ソリューションのポートフォリオである HMAX を通じて現場の作業員にエージェントを直接展開し、グローバルな電力および公共インフラ事業の変革を推進しています。現場の技術者は、作業前後にすべての工具や配線を写真で確認する画像認識エージェントなど、200 を超えるユースケース向けにエージェントを構築しました。これにより、作業員の安全性を確保しながら、生産性を最大 400 % 向上させています。

• 株式会社NTTドコモは、インサイト獲得までの時間を 2 週間から即時に短縮するデータ エージェントを構築し、年間 45 万時間もの作業時間を創出しました。この成功を基に、Gemini Enterprise を展開し、さらなる生産性向上を推進しています。

• SOMPOホールディングス株式会社は、3 万 4,000 人の従業員向けに 1万を超えるカスタム AI エージェントを構築し、ドキュメント検索や要約などのタスクを自動化して業務効率化を図っています。同社のエンジニアリング チームは Gemini Enterprise を活用することで、新しいモデルの開発時間を 1 週間からわずか 1 日に短縮し、エンジニアがより重要な業務に集中できる環境を実現しました。

• さらにアジア太平洋地域においても、電機メーカーの LG、総合商社の丸紅、製造の Tata Steel、IT サービスの TCS などの各業界のリーディング カンパニーが導入しています。

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

最先端の AI ラボが大規模な並列ロールアウトでエージェント型強化学習（RL）と評価をスケールアップしようとすると、必然的にボトルネックに直面します。高価な GPU クラスタがアイドル状態になり、CPU サンドボックスのコールド スタートに数分かかるうえ、数千件に及ぶ数ギガバイト規模の SWE-bench スタイルのイメージの pull とスケジューリングのバックログが発生するのです。これは、研究を知らぬ間に遅らせ、トレーニング予算を浪費してしまう、サンドボックス インフラストラクチャの問題です。

この根本的なインフラストラクチャのボトルネックを解決するため、Google はこのたび、RL 向けに最適化された GKE Agent Sandbox と Agent Sandbox RL オーケストレーション SDK、そして一般的な RL ジムやハーネスとのネイティブ連携の一般提供を開始いたしました。

最新 AI のためのオペレーティング システムとして、Kubernetes は大規模な GPU / TPU トレーニング クラスタと分散推論を強化するよう進化してきました。現在、Kubernetes は、AI コンピューティングの次のフロンティアである「エージェント」を牽引しようとしています。ただし、静的なワークロードとは異なり、エージェント型ワークロードは急速に進化するため、インフラストラクチャも同じ速度で進化しなければなりません。そこで、Google は RL 研究者が何を必要としているかを推測するのではなく、Kubernetes 自体をパフォーマンス ベンチマークと評価に基づく自動研究および検証ループに組み込みました。また、SWE-bench のような負荷の高いエージェント型ベンチマークを使用して、意図的に自社のクラスタに過酷な負荷をかけてダウンさせるストレステストを実施しました。etcd のタイムアウトから GPU のアイドル時間の急増まで、表面化したすべてのボトルネックを開発サイクルにフィードバックし、GKE の基本的な構成要素を改良しました。

その結果、以下のような特徴を備えた、エージェント型 RL と評価ワークロードに特化したサンドボックス レイヤが構築されました。

• 最初のコマンド実行までの時間を 10～45 倍高速化: GKE は、サンドボックス環境を 45～85 秒ではなく 1～9 秒でスピンアップできるため、高価な GPU を常にフル稼働させることができます。

• テール レイテンシを短縮: サンドボックスの最悪の場合の待ち時間を 7.5 分から 10 秒未満に短縮しました。

• コントロール プレーンのチャーンを 3 分の 1 に削減: RL のトレーニング ステップごとに大量のロールアウトが一斉にトリガーされ、数千ものサンドボックスが一度にリクエストされます。SDK では、Pod を削除して再作成するのではなく、ロールアウト間で再利用するインプレース リサイクル戦略が採用されています。これにより、作成される Pod の数が 3 分の 1 に減り、チャーンが発生しても、安定した Kubernetes API サーバーを維持できます。

この新しいプリミティブにより、AI ラボやエージェント ネイティブのスタートアップは、大規模なエージェント型 RL のトラジェクトリと評価を同時かつ確実に実行できるようになり、アクセラレータのアイドル時間を最小限に抑え、研究のスピードを大幅に加速させることができます。

現実世界におけるエージェント型 RL インフラストラクチャの課題

ソリューションについて説明する前にまず、エージェント型 RL がインフラストラクチャに大きな負担をかける理由を正確に把握しておきましょう。標準的なエージェント型 RL ループでは、LLM ポリシーが GPU 上でコード スニペットなどのアクションを生成し、隔離された CPU サンドボックス内で実行して報酬シグナルを観察します。しかし、このループをスケールアップして数万件の並列ロールアウトをサポートしようとすると、以下の 3 つの重大なインフラストラクチャのボトルネックが発生します。

1. アクセラレータのアイドルコスト、すなわち最初のコマンド実行までの時間（TTFC）とテール レイテンシの罠: エージェント型 RL はバッチ ワークロードです。同期型の RL ステップでは、バッチ内で最も処理の遅いサンドボックスの準備が整うまでトレーニングを進めることができません。CPU サンドボックスを起動する際、プロビジョニング、イメージの pull、初期起動スクリプトの実行に数分かかれば、高価なアクセラレータの容量が無駄になってしまいます。

2. 膨大なイメージ カーディナリティ: 標準的なコンテナのキャッシュ保存は、少数の静的なベースイメージを前提としています。しかし、エージェント型 RL では、一つひとつのタスク（SWE-bench や R2E-Gym にある数千の GitHub リポジトリなど）に、完全に異なる OCI コンテナ イメージが必要となることが少なくありません。実行ごとに数千もの一意の大型イメージを管理すると、イメージの pull における深刻なボトルネックや、ストレージ フリクションが生じる可能性があります。

3. コントロール プレーンの飽和: バースト性の高いバッチ ワークロードであるエージェント型 RL は通常、バッチサイズのイメージタスクと、タスクごとに複数のロールアウト（タスクごとに 4、8、16 回のロールアウトなど）を実行するため、すでに大量にあるイメージ数が極限まで増加してしまいます。たとえば、テストに使用した一般公開データセットの一つには、4,578 件の R2E イメージが含まれています。イメージごとにロールアウトを 4 回行うと仮定すると、18,312 個のタスクが発生し、18,312 個のサンドボックスが同時に必要となります。標準の Kubernetes コントロール プレーンは、このようなバースト負荷が生じるとパフォーマンスが大幅に低下します。1 分間に数万ものエフェメラル Pod の作成と削除を頻繁に繰り返すと、API サーバーのキューのボトルネックや Pod の状態エラーが発生し、ノード障害の誤判定によるエビクションがトリガーされます。

これらは机上の空論ではありません。最新のエージェントをトレーニングする最先端の AI ラボにとって、これらは日常的な現実なのです。

RL 向けに最適化された GKE Agent Sandbox

コード実行サンドボックスをファンアウトするため、Google は比較的小規模なクラスタを構築しました。このクラスタは、GKE イメージ ストリーミングが有効な 10 ノードの gVisor サンドボックス プール、Agent Sandbox コントローラ、ウォーム Pod を要求するクラスタ内 SDK ドライバで構成されています。そこでは、多数のイメージや高いカーディナリティなど、さまざまな戦略や設定をテストしました。

インフラストラクチャ レイヤ

GKE Agent Sandbox は、エージェントをセキュアに実行するためのオープンな Kubernetes プリミティブです。事前に初期化された正常な環境を維持することで、コールド スタートのオーバーヘッドを排除する、組み込みの SandboxWarmPool 機能を備えています。SandboxWarmPool を GKE Image Streaming と連携させることにより、数千もの大規模なイメージ（1.2 GB 超）を使用する場合でも、高いイメージ カーディナリティを必要とする RL ワークロードと評価ワークロードを効果的にサポートすると同時に、応答性の高いエージェント型トレーニングに必要な非常に低い TTFC を実現します。そのスナップショット、一時停止、再開機能により、エラー回復のためのチェックポイント設定や、複数のトレイルを探索するエージェントの並列分岐ロジックのサンドボックス フォークをサポートします。

この GKE プリミティブは、最先端の AI ラボである Mistral AI のエージェント型 RL トレーニング インフラストラクチャですでに活用されています。

「強化学習の限界を押し広げるには、予測不可能な需要に対応できるよう即座にスケールできるインフラストラクチャが必要です。RL 向けの高性能な GKE Agent Sandbox を活用することにより、クラスタ全体で数十万ものセキュアな環境をシームレスにオーケストレートし、単一のクラスタ上で 3 万を超えるサンドボックスの急増にも対応できるようになりました。このサンドボックスは、モデルのトレーニングとイテレーションのサイクルを加速させるために必要な、信頼性の高い基盤を提供してくれます。」- Mistral AI、リサーチ エンジニア、Jean-Malo Delignon 氏

オーケストレーション SDK と RL ツールの連携

研究者が Kubernetes YAML を記述したり、カスタム デーモンをコンテナ イメージに埋め込んだりしなくてもこの機能を活用できるよう、Google は Agent Sandbox RL オーケストレーション SDK を構築しました。この SDK は、特定の評価や RL トレーニング パターンに合わせて調整された、差し替え可能なウォーム プーリング戦略を備えた、シンプルで非同期な Python API を提供します。また、Gymnasium、NVIDIA NeMo Gym、OpenHands などの RL ツールとのネイティブ連携も構築しており、今後さらに追加される予定です。

ベンチマーク: アイドル状態のアクセラレータのロスを削減

このベンチマークは、10 ノードの gVisor サンドボックス プール上で 2 つのワークロードに対して実施しました。1 つは 500 イメージの SWE-bench 環境、もう 1 つはローカル ディスクに収まらない 4,578 イメージから成る、より負荷の高い R2E コーパスです。

1. TTFC とテール レイテンシ: 10～45 倍高速化

同時実行数は、500 のタスクとサンドボックスから、最大 18,312（4,578 件の R2E イメージ × 4 回のロールアウト）に及びました。このパフォーマンス向上は、すべての設定で一貫して確認されました。

これまでの流れ: コントローラ、SDK、RL フリートに計測機能を組み込み、固定された 10 ノードを上限として数百回の比較実行を行いました。その成果のほぼすべては、以下の 2 つの変更によりもたらされました。

• イメージのハイドレーションをクリティカル パスから除外。カーディナリティの高いコーパスはローカル ディスクの容量をはるかに超えるため、トレーニング中にコールド イメージを pull すると、I/O の競合や数分に及ぶテール レイテンシが発生します。SDK がノード全体にわたるイメージの配置を計画し、 GKE イメージ ストリーミングと事前のウォーム プーリングが残りの処理を行います。これにより、ロールアウトが要求する前にハイドレーションが完了します。

• コントロール プレーンのペースを調整。同時実行数の多いロールアウトは、API サーバーのサンダリング ハードをトリガーします。Agent Sandbox Controller v1.0.0 では、ウォームプールの補充速度を制限するレート制御が追加され、バースト中も etcd と API サーバーの安定性が維持されます。

これらの数値の根拠となる調整項目、ベンチマーク実行基盤、負荷テストはすべて、agent-sandbox-rl の例に含まれています。この例では、人が読める形式のレポートと JSON レポートが出力されるため、ご自身のクラスタで比較を再現できます。

2. マルチ トラジェクトリ ロールアウト中のコントロール プレーンと Pod のライフサイクル チャーンが 3 分の 1 に減少

標準の Kubernetes では、トラジェクトリのステップごとに Pod が再作成されます。タスクが 18,312 個ともなると、スケジューリングのオーバーヘッドが増大し、ディスク I/O が無駄になるだけでなく、大規模なテストでは、無限のガベージ コレクション ループがトリガーされました。SDK のインプレース recycle 戦略では、Pod を存続させ、ロールアウト エピソード間で Pod 内の git reset とリポジトリ チェックアウトを実行します。Pod の作成は 3.1 分の 1 に減少し、コントロール プレーンはバースト中も安定しています。

トレードオフ

事前に環境をウォームアップしておくと、安価な CPU とバックグラウンドのクラスタ処理時間を消費することにはなりますが、イメージ ストリーミングとレディネス チェックがクリティカル パスに影響することがなくなります。RL フリートにとって、これは単純なトレードオフです。アクセラレータのアイドル時間という高価なリソースを、このアプローチにより排除できます。

大規模なトレーニングでは、ある 1 つの細かな点が重要になります。SDK は、失敗したサンドボックスをすべてカウントし、黙って破棄するのではなく、再試行可能なエラーとして返します。追跡されない破棄は、単にロールアウトが失われるだけでなく、報酬バイアスを引き起こします。

ご利用開始

• 今すぐ構築する: Agent Sandbox リポジトリまたは Agent Sandbox RL リポジトリを参照し、Python SDK や、Gymnasium、NVIDIA NeMo Gym、OpenHands などの RL ツール向けネイティブ連携をご確認ください。

• アクセラレータの使用率をさらに高める: llm-d 協調型タイムスライス リポジトリとスナップショット エージェント ガイドを参照し、独立した RL ジョブを共有の物理ハードウェア上で動的にインターリーブする方法をご確認ください。

• 詳細を確認する: GKE Agent Sandbox を使用してセキュアな実行環境をデプロイする方法については、公式ドキュメントをご覧ください。

- プロダクト マネージャー、Tinsley Shi

- スタッフ ソフトウェア エンジニア、テクニカル リード、Tomer Glottmann

キーノート対談で示された AI for Growth の構想とエージェント時代の到来

オープニングを飾ったのは、dentsu Japan CAIO（Chief AI Officer）並河 進 氏 と、グーグル・クラウド・ジャパン 代表 三上 智子 によるキーノート対談です。

対談冒頭、並河氏は電通グループが掲げる「AI for Growth」構想について言及。「AI は人間の仕事を奪うものではなく、人の知性や創る力を拡張し、ビジネス プロセスを根本から変革するパートナーである」と強調しました。電通自身が自らの業務を AI 前提に作り替えるとともに、クライアント企業のマーケティングだけでなく、クライアントビジネスを牽引する存在へと進化していく決意を語りました。

続いて三上は、Google Cloud の AI フルスタック戦略（TPU をはじめとするインフラ基盤から Gemini Enterprise、マルチモーダル モデル Gemini に至る一貫したアーキテクチャ）を紹介。2026 年は単一の AI ツールから、複数の AI が協調して自律的に業務を遂行する「マルチエージェント」の実装フェーズへと突入したと解説しました。

両氏は、電通が誇る高度なマーケティング クリエイティビティに加え、Google Cloud の堅牢かつ最先端のテクノロジーを活用することで、単なる業務効率化を超えた新たな事業価値を生み出せるという共通のビジョンを共有しました。

日本郵便における戦略設計プロセス改革、Gemini と共に思考を深めるアプローチ

最初のセッションでは、「AI で変える、マーケティング戦略を支える実行への挑戦」と題し、日本郵便 （広報宣伝部部付部長/郵便・物流事業統括部マーケティング室部付部長 ）藤田 元 氏が同社における具体的な取り組みを紹介しました。

日本郵便では、人事異動や組織体制の変化に伴う属人化の解消や、過去に蓄積されたナレッジの有効活用が大きな課題となっていました。そこで、戦略設計の再現性とスピードを高めるため、Gemini Enterprise やマーケティング エージェントの導入に踏み切りました。

セッションでは、「ゆうパック × 引越し」をテーマに実施された PoC（概念実証）の事例が紹介されました。AI を単なる検索ツールとして扱うのではなく、プランナーの思考を刺激し、多角的な視点で仮説を深める壁打ちのパートナーとして位置づけた点が特徴です。これにより、従来は膨大な時間を要していた市場分析や販促シナリオの骨子作成を大幅に短縮しながら、企画の質を高めることに成功したプロセスが共有されました。

Google Cloud 自身の自己変革に学ぶ、カスタマーゼロ視点の AI-BPR 実践

続いてのセッションでは、多くの企業が直面する「PoC 止まりの壁」をいかに打破するかをテーマに、Google Cloud 執行役員 データクラウド事業本部の濱田 真、イグニション・ポイント 執行役員 AI Innovation Hub 代表の羽間 裕貴 氏による実践的な議論が行われました。

羽間氏は、数多くの大手企業支援を通じて得られた知見から、「生成 AI の成果を最大化する鍵は、既存の業務に AI を付け足すことではなく、業務プロセス自体を AI 前提に再設計する『AI-BPR（Business Process Re-engineering）』にある」と提起しました。

これを受け、濱田は Google Cloud 自身が自社プロダクトの最初の顧客となる「カスタマーゼロ」として進めてきた内部変革の事例を共有しました。情報の「検索（Search）」からタスクの「委任（Delegation）」へと働き方が大きくシフトする中で、AI エージェントを組み込んだ業務基盤・データ基盤をどのように刷新していったのか、その生々しい実践知が語られました。参加した企業担当者にとって、明日からの自社改革のロードマップを描くための実践的なヒントに満ちたセッションとなりました。

未来の顧客体験を創るデータ インテグレーション、「データ × CX」の好循環がもたらす価値

後半のセッションでは、マーケティングとデータ テクノロジーの最前線にフォーカスが当てられました。「Gemini による『データ × CX』の好循環がビジネスを変える」と題し、企業の持続的成長に必要なデータをどのように獲得し、活用していくかが議論されました。

電通グループが示したのは、AI を用いて顧客一人ひとりに最適な CX（顧客体験）を提供し、その接点から得られた高精度なファーストパーティ データが再び AI とサービスへ還元される自律的なエコシステムです。会場では業界特化型の仮想デモを披露し、蓄積されたマルチモーダル データから Gemini が瞬時にパーソナライズされた提案を生成し、全社的なデータ インテグレーションへと還流していく様子が紹介されました。

さらに特別プログラムとして、「ケアのまなざし」をテーマに介護現場での人間中心の AI 変革ストーリーも紹介され、AI がもたらす温かみのある社会的価値への共感を呼びました。

人と AI の協働で、日本企業のマーケティングとビジネスの可能性を広げる

クロージング セッションにおいて、並河氏は次のように総括しました。

「今日ご紹介した数々の実践は、電通グループと Google Cloud のコラボレーションが形作った新しいビジネス変革の第一歩に過ぎません。AI を駆使し、クライアントの皆様とともに新しい市場と感動を創り出していく。その挑戦をこれからも力強く推進してまいります」

本イベントを通じて、生成 AI や AI エージェントが実験段階を超え、マーケティングの戦略設計から基幹業務の改革、新たな顧客体験の創出に至るまで、実際のビジネスを動かす原動力となっていることが鮮明に示されました。

Google Cloud は今後も、dentsu Japan とともに、最先端の AI テクノロジーとインフラ基盤を通じて、日本企業の成長と変革を全力で支援してまいります。

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

このたび、Google Cloud Data Agent Kit の一般提供を開始しました。Data Agent Kit は、Model Context Protocol（MCP）ツールとエージェント スキルの無料セットです。Antigravity や Claude Code、Codex、その他の一般的なツールなど、すでに使用しているコーディング エージェントを Google Cloud データ プロダクトと直接連携させることができます。

一般提供では、オープン レイクハウスに対する BigQuery Graph、Bigtable、Managed Service for Apache Spark からのアクセスがサポートされるほか、日常業務をより迅速かつスムーズにするためのさまざまな機能強化が追加されています。

Data Agent Kit とは

コーディング エージェントは、SQL、PySpark、パイプライン コードの作成に非常に優れています。デフォルトで欠けているのは、開発環境に関するコンテキストです。たとえば、どのテーブルが存在するか、どのようにパーティション分割されているか、チームが信頼しているのはどれか、昨夜のジョブが失敗したのはなぜか、といった情報です。これらがないと、優れたエージェントであっても、推測に基づいて作業せざるを得ず、最終的にはスキーマやエラーログをチャットに貼り付けて不足している情報を補うことになります。

Data Agent Kit は、次の 2 つの要素でその不足を埋めます。

• MCP ツール: 15 以上の Google データクラウド サービスに接続できるため、エージェントはスキーマの検査、クエリの実行、ジョブ ログの読み取り、本番環境でのリソース管理を行うことができます。

• Google が作成したスキル: Google Cloud エンジニアが提供するオープンソースの指示書により、エージェントは BigQuery SQL の最適化、Bigtable 行キーの設計、dbt（データビルド ツール）パイプラインの構築といった、データのベスト プラクティスを学習できます。

Data Agent Kit は、VS Code、Antigravity IDE、Cursor、その他の VS Code 互換エディタの IDE 拡張機能として、または Antigravity 2.0、Antigravity CLI、Claude Code、Codex のプラグインとして、あるいは Cloud Shell や Cloud Workstations にプリインストールされた状態で、既存の作業環境でそのまま使用できます。また、IDE 拡張機能により、Google Cloud コンソールの軽量版がエディタに組み込まれるため、ウィンドウを切り替えることなく、データの閲覧、クエリの実行、エージェントの作業の確認を行うことができます。

仕組み

たとえば、エージェントに「ベストセラー商品の来月の需要を予測し、それに対応できる十分な在庫があるかどうかを確認して」と指示したとします。Data Agent Kit が関連するスキルを読み込むため、エージェントはタスクに関する Google のベスト プラクティスに従います。Knowledge Catalog を検索して、チームが信頼している販売テーブルと在庫テーブルを見つけます。次に、MCP ツールを使用して BigQuery で予測を実行し、AlloyDB for PostgreSQL で現在の在庫レベルを確認して、統合された回答をエディタまたはターミナルに返します。すべてのステップが独自の IAM 権限で実行されます。

構築できるもの

Data Agent Kit は、分析、オペレーショナル データベース、レイクハウス、パイプラインに対応しています。具体的にどのように機能するのか、まずは一般提供の新機能から見ていきましょう。

分析とグラフ: BigQuery と BigQuery Graph（一般提供の新機能）

グラフは、ユーザーが一緒に購入する商品や、サプライヤーが在庫にどのように接続しているかなど、関係性を自然に探索する方法です。通常、グラフを構築するには、CREATE PROPERTY GRAPH DDL を手動で記述し、GQL を学習して、どのキーが実際にエッジを形成するかを把握する必要があります。

代わりに、必要なグラフを指示するだけで、エージェントがグラフを構築してくれます。bigquery-graph-author スキルは、テーブルをノードとエッジにマッピングし、提案された各関係を実際のデータと照合したうえで、実際に作成する前に承認を求めるプランを表示します。既存の ER 図やデータモデルから始めることもできます。bigquery-graph-query スキルが GQL を記述し、IDE のグラフ ビジュアライザで結果をクリックして確認できます。

オペレーショナル データベースとリアルタイム データベース: Spanner、AlloyDB、Cloud SQL、Bigtable（一般提供版の新機能）

パーソナライズされたフィード、ライブ カウンタ、ストアフロントの「最近閲覧した商品」レールなど、一部の機能は即座に読み込む必要があります。Bigtable はまさにそのために構築されており、行キーを適切に設計することで、その恩恵を最大限に得られます。

一般提供により、Bigtable は Spanner、AlloyDB、Cloud SQL とともに、Data Agent Kit で完全にサポートされるデータベースとなりました。新しい bigtable-basics スキルは、データの読み取り方法に基づいてスキーマを設計し、作成する前に、ホットスポットとフルテーブル スキャンにフラグを立てます。エージェントはテーブルを作成し、GoogleSQL でクエリを実行して、列ファミリーを読み取り可能な列にフラット化できます。IDE では、カタログ エクスプローラで Bigtable インスタンスとテーブルをブラウジングし、SQL エディタからクエリを実行できます。

レイクハウスと Spark: Managed Service for Apache Spark と Lakehouse for Apache Iceberg（一般提供の新機能）

エージェントは、これまでも BigQuery を介して Lakehouse 内の Apache Iceberg テーブルにクエリを実行することができました。さらに今度は、Managed Service for Apache Spark 上のサーバーレス Spark を使用して、同じテーブルを操作できるようになります。クラスタの管理は不要です。各セッションは状態を保持するため、一時ビューがステートメント間で引き継がれ、ブランチ、タイムトラベル、スキーマの進化など、Iceberg の全機能を利用できます。

また、すべてのテーブルを Google Cloud 上に配置する必要もありません。federate-lakehouse-catalog スキルは、Lakehouse を AWS Glue と Databricks Unity Catalog に接続します。これにより、エージェントは最初に取り込みパイプラインを構築することなく、そのデータを移動させずにその場でクエリできます。

パイプラインとオーケストレーション: dbt、Dataform、Managed Service for Apache Airflow

ロジックが機能するようになったら、エージェントはそれを独自に実行されるパイプラインに変換できます。エージェントが dbt または Dataform モデルを作成すると、gcp-pipeline-orchestration スキルがそれらをノートブックとともにまとめ、Managed Service for Apache Airflow 上のオーケストレーション パイプラインとしてスケジュールします。パイプラインには、モデルのアップロードやバッチ推論の実行など、Gemini Enterprise Agent Platform のステップを含めることもできます。

IDE では、ビジュアル パイプライン キャンバスで各実行を追跡できます。タスクに対応が必要な場合は、[診断] をクリックしてログをエージェントに渡します。Airflow と Spark のトラブルシューティング スキルが根本原因を特定し、ユーザーが承認するだけの修正案を提案します。

デベロッパー エクスペリエンスの向上

一般提供では、セットアップや日常のワークフローも簡素化されます。利用を開始するには、1 回ログインして、使用する Google Cloud サービスを選択するだけです。Data Agent Kit は、必要な API を自動的に有効にし、対応するスキルをインストールして、手動で設定ファイルを作成することなく MCP サーバーを構成します。IDE では、SQL エディタとノートブックで、インライン コード生成、テーブルへの @ 参照、提案された変更の差分表示がサポートされるようになりました。この拡張機能は、アクティブなプロジェクト、開いているファイル、実行したばかりのクエリのエラーもエージェントと共有するため、「このクエリを修正して」と依頼するだけで機能します。

また、コアツールの高速化と応答性の向上も実現しました。新しい Spark ノートブックでは、Spark Connect ランタイムが自動的に作成、選択され、エディタ内の Spark SQL クエリは、組み込みの実行指標を使用して分離されたセッションで実行されます。カタログ エクスプローラの読み込みが速くなり、サイドバーに BigQuery の一般公開データセットが表示されるようになりました。チューニングされたノートブック スキルにより、エージェントはより少ないトークンでノートブック タスクをより迅速に完了できます。

エンタープライズに対応

Data Agent Kit は追加料金なしでご利用いただけます。エージェントが使用する Google Cloud サービスの標準料金のみをお支払いいただきます。また、スキルはエージェントをコスト効率の良いクエリパターンへと誘導します。たとえば、BigQuery クエリの実行前に、誤ったフルテーブル スキャンを避けるためにパーティション キーを確認したり、ドライランを実行したりするように促します。また、スキルは GitHub でオープンソースとして公開されているため、チームはスキルを監査したり、フォークしたり、社内基準に合わせたカスタムスキルを独自に作成したりできます。

アクセス制御については、エージェントはユーザーまたはユーザーが権限を借用するサービス アカウントとして接続するため、行レベルおよび列レベルのセキュリティ ポリシーが自動的に適用されます。管理者は、Identity and Access Management（IAM）で MCP アクセスを管理し、Model Armor で MCP トラフィックをスクリーニングし、VPC Service Controls とプリンシパル アクセス境界ポリシーでエージェントのスコープを設定することもできます。

インストールして使ってみる

Data Agent Kit は、IDE またはターミナルで 1 分以内に設定できます。

オプション 1: IDE 拡張機能をインストールする

• IDE 拡張機能: VS Code、Antigravity IDE、Cursor、または VS Code 互換エディタの拡張機能パネルで「Google Cloud Data Agent Kit」を検索します。VS Code Marketplace または Open VSX からインストールすることもできます。

• Antigravity 2.0: [設定] > [カスタマイズ] > [Build with Google Plugins] に移動し、Data Agent Kit をダウンロードします。

• Cloud Shell と Cloud Workstations: デフォルトですでにインストールされています。エディタを開いてログインするだけです。

オプション 2: CLI プラグインをインストールする

公式の GoogleCloudPlatform/data-agent-kit-plugin リポジトリを使用して、お好みのコーディング エージェントのコマンドを実行します。

そして最初のプロンプトとして、次を入力します:

次のステップとハンズオン リソース

• ドキュメントを読む: Data Agent Kit のドキュメントとプロダクトの概要ページをご覧ください。

• スキルを試す: GitHub でスキルを閲覧、スター付け、貢献する。

• 分析ワークフローを構築する: Data Agent Kit と Antigravity IDE を使用した分析の Codelab をお試しください。また、関連ブログ記事 Data Agent Kit でエージェントを駆使した問題分析もご覧ください。

• データ サイエンス パイプラインを構築する: Data Agent Kit と Antigravity IDE を使用した不正行為検出パイプラインの Codelab をお試しください。

- Google、プロダクト マネージャー Arun Nair

- Google、デベロッパー アドボケイト、Jeff Nelson