Cloud Blog JA

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

没入感のある 3D エクスペリエンスと詳細な場所情報で地図を変革

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

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

ブランドの魅力を生き生きと伝える没入感のある UX

デモ動画を見る

新しい場所に関する豊富な情報を提供し、デジタル上での探索を可能にする地図は、ユーザーが現地に到着する前に、その場所の雰囲気をつかむのに役立ちます。Google Maps Platform の最新機能を使用すると、標準的な地図を、ユーザーが現実世界を探索する感覚に近い 3D エクスペリエンスへと変えることができます。

3D マップの新しいカスタマイズツールにより、地図の UI と UX をこれまでになく細かく制御できるようになりました。フォトリアリスティックな世界を作成し、そこに独自のブランドアイデンティティやデータを組み込むことができます。

また、新しいプログラム可能なカメラ設定により、広角レンズや望遠レンズをシミュレートできます。チルトや回転といった映画のような効果を使用して、ユーザーにさまざまな視点から場所を見せることができます。ユーザーの視野に地図をどの程度表示するかも制御できます。

開発者はこれまでも、Google のデフォルトのピンを使用したり、画像ベースのマーカーをレンダリングしたりすることで、カスタム地図マーカーを追加できました。今回、カスタム HTML プレイスマーカーの作成機能が追加されたことで、ブランドに合わせてデザインをさらに細かく制御できるようになりました。カーソルを合わせると拡大するフォトギャラリーや、リアルタイムの価格データなど、アニメーションやインタラクティブな機能を追加することもできます。

都市計画、不動産、メディア、イベントの分野では、新しいメッシュ平坦化機能により、地図上の特定のエリアから既存の樹木や建物を取り除き、デジタル上で整理された状態にできます。これにより、独自の建築モデルやブランドアセットを配置するためのクリーンなキャンバスを作成できます。

これら 3 つの機能はすべて、ウェブデベロッパー向けの 3D Maps for JavaScript で利用できます。Android および iOS 向けの Maps 3D SDK でも近日中に利用可能になる予定です。

ユーザージャーニーのあらゆる段階で一貫したエクスペリエンスを提供

デモ動画を見る

フォトリアリスティックな地図は、ユーザーが目的地に到着する前に、その周辺の雰囲気を現地にいるような感覚で把握するのに役立ちます。一方、模式的で抽象化された地図は、道案内に必要なわかりやすいグラフィック表現を提供し、スムーズなナビゲーションを支援します。

地図を使用する体験全体に一貫性を持たせるため、3D マップに抽象ベースマップを追加しました。この機能により、ユーザーは詳細なフォトリアリスティック画像と簡略化された抽象ビューをシームレスに切り替えることができます。また、検索、発見、探索を 1 つの直感的なインターフェースに統合できます。これにより、旅行前に目的地の雰囲気を確認する場合でも、到着後に建物の入口や駐車場を特定する場合でも、ユーザーは自分のニーズに最も合った方法で地図を探索できます。

この機能は現在、Maps JavaScript API の JavaScript アルファチャンネルを通じて、ウェブ向け 3D Maps でテストできます。iOS では Maps3D SDK を有効にすることで利用できます。Android でも近日中に利用可能になる予定です。

直感的でカスタマイズ可能な UI と、ユーザーが信頼できる詳細なデータ

没入感のあるインターフェースの価値は、それを支えるデータの質によって決まります。そこで Google Maps Platform では、場所に関する情報を大幅に拡充し、エンドユーザーが正確な住所とその場所の雰囲気を同時に把握できるようにしました。

新しいプレイスタイプでは、スペイン風居酒屋から電動自転車の充電スタンドまで、約 200 種類の詳細なカテゴリを追加しました。これにより、ユーザーは探している場所をより正確に見つけられるようになります。これらのカテゴリに加え、ブランドに合わせてカスタマイズできる完全一致のローカライズ済みプレイスラベルを使用することで、単なるキーワード検索を新しい地域を探索する機会へと変えることができます。

また、Places UI キットでは、ウェブ、iOS、Android 向けに、モジュール式でカスタマイズ可能なコンポーネントを提供しています。このキットを使用すれば、Google マップが持つ場所に関する情報と直感的なインターフェースをプロダクトにすばやく組み込むことができます。

新しいシェイプファイルと 3D モデルのインポート機能で Google Earth により多くのデータを取り込む

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

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

Google Earth は、地理空間情報の信頼できる唯一の情報源を作成できるよう、データインポート機能を拡張しています。このたび、2 種類の新しいデータインポート形式のサポートと、測定ツールの新しいデータ機能を発表することになりましたのでお知らせします。

シェイプファイル（SHP）: 業界標準の GIS データを、柔軟なデータレイヤとして Google Earth に直接取り込むことができます。
3D モデル（GLB）: 建築物のモックアップなどのカスタム 3D モデルを、ウェブブラウザ上で簡単にアップロード、配置、共有できます。
高度プロファイル: 測定ツールでシンプルな図形を描画するだけで、インスペクタパネルに美しい高度（標高）プロファイルグラフを表示できます。

シェイプファイルと 3D モデルが Google Earth に登場

現実世界のキャンバスにデータを表示

ユーザーの皆様からは、Google Earth の現実世界のキャンバスに、より多くのデータ、画像、モデルを取り込みたいという声が寄せられていました。このたび、シェイプファイルと 3D モデルのインポートをサポートすることで、Google はその期待に応えるための次の一歩を踏み出します。

最適な意思決定を行うには、それぞれの業務に合わせてカスタマイズされた地図が必要です。インサイトの真の価値は、関係者の理解を深め、行動を促せる点にあるからです。しかし、プロジェクトが初期の敷地評価から関係者レビューへと進むにつれ、チームは動作が重い GIS ソフトウェア、計画用のスプレッドシート、プレゼンテーション資料の間を何度も行き来しなければなりません。新しいフェーズや対象者ごとに、データを手動でエクスポート、変換、ラングリングする作業は非常に負担が大きく、貴重な時間を奪います。さらに、誰かが常に古い情報を見ている状態にもつながります。

Google Earth は、こうした煩わしさを解消します。データインポート機能の拡張により、Google Cloud ベースの地図プロジェクト内で独自データをセキュアに結合し、スタイルを設定し、可視化して共有できるようにしました。Google Earth は、地図をチーム全体が共同作業し、インサイトを一元化できる統合ワークスペースへと進化させています。全員がまったく同じ、信頼できる唯一の情報源に基づいて作業できるようになれば、ファイル管理に費やす時間を減らし、確信を持って意思決定するための時間を増やせます。

シェイプファイルを追加して全体像を把握

新機能: KML、KMZ、GeoJSON に加えて、シェイプファイルもサポート対象に追加されました。シェイプファイルを含む .zip ファイルをアップロードすると、フィーチャーと関連属性の両方を、パフォーマンスに優れたクラウドネイティブなデータレイヤとしてレンダリングできます。

シェイプファイルは、GIS の専門家にとって業界標準の形式です。この機能は、不動産デベロッパーや都市計画担当者が、税区画、インフラストラクチャ、地形データなどの大規模な独自データをインポートし、敷地の適合性を評価したり、新たな機会を見つけたりする際に欠かせません。

シェイプファイル（SHP）を地図プロジェクトにインポートし、地理空間データのスタイルを設定して共有できます。

現実世界のコンテキストで 3D モデルを活用

新機能: カスタム 3D モデルをアップロード、配置、共有し、デザインや建物のボリュームを現実世界のコンテキストで確認できます。まずは GLB ファイル形式に対応し、モデルを地球上に正確に配置、拡大縮小、回転できる入力フィールドを用意しました。

これにより、Google Earth はカスタムデザインを表示するインタラクティブなステージへと変わります。建築家や建設の専門家は、リソースを投入する前に、提案中の建築デザインや建物のモックアップを実際の場所に即した形で正確に可視化できます。関係者の間で共通のビジョンをすり合わせることが、これまでよりはるかに簡単になります。

3D モデルを現実世界のコンテキストで可視化できます。

高度プロファイルを可視化

新機能: 測定ツールに高度プロファイルが追加されました。これまでと同じように測定ツールで描画するだけで、インスペクタパネルに美しい高度（標高）プロファイルが表示されます。

測定ツールは、地図探索の中核となる万能ツールとして使用されてきました。今回のアップデートにより、さらに強力で柔軟なツールになります。地形はほぼすべてのプロジェクトに影響するため、このビジュアルデータはさまざまな用途に活用でき、推測に頼っていた作業を具体的な空間インテリジェンスにすばやく置き換えることができます。複雑なルート計画や輸送計画、可視域分析、重機のロジスティクス計画など、さまざまな場面で、地形の起伏を地図上で即座に把握できるようになります。

地形を可視化して時間を節約し、プロジェクトのリスクを軽減できます。

新しい Google Earth Discord チャンネルで他のユーザーと交流

Google Earth にデータを追加する準備はできましたか。ほかのプロフェッショナルがこれらのツールをどのように活用して、効率よく作業しているのか知りたいと思いませんか。

Google Maps Platform サーバーに新設された #GoogleEarth Discord チャンネルに参加して、他のユーザーと交流しましょう。実績のあるワークフローを共有したり、複雑な空間分析の課題をリアルタイムで解決したり、Google Earth プロダクトチームと直接つながったりできます。今すぐ世界中の専門家のネットワークに参加し、Google Earth を活用してよりスマートに作業し、時間を節約する方法を学びましょう。

- Google Earth 担当プロダクトマーケティングマネージャー、Willy Thomas

「Google for Startups Accelerator: 中東、北アフリカ、トルコ」に新たに選出された企業の紹介

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

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

Google の使命は世界中の情報を整理し、世界中の人々がアクセスできるようにすることです。中東、北アフリカ、トルコ（MENA-T）のような技術革新に意欲的な急成長市場では、AI ファーストのスタートアップを支援することで、このミッションを遂行しています。これらのスタートアップは、次世代の情報主導型サービスをグローバル規模で構築しています。Google は、その高いレジリエンスで知られるこの地域の創業者たちがどんな状況でも成功を収めるための支援を提供したいと考えています。

Google for Startups Accelerator: MENA-T プログラムの最新のコホート（15 社）が 6 月 1 日にスタートします。前回にあたる第 6 回は 2025 年 11 月に終了し、この地域に新たなベンチマークを打ち立てました。

第 6 回のプログラムでは、8 か国から 14 社の AI ファーストスタートアップが参加し、Google のスペシャリストから 230 時間を超える専門的な 1 対 1 の指導を受けました。このサポートにより、ビジネス戦略のブラッシュアップ、Google Cloud を使用した AI / ML イニシアチブの加速、プロダクトデザイン全体の強化など、技術面とビジネス面の両方で測定可能な成果を達成しました。

2026 年のプログラムでは、リソース、重点分野、トレーニングをさらに拡充し、地域や世界に影響を及ぼす可能性のある不確実な地政学的な状況を乗り切るための支援を提供します。

最新の「Google for Startups Accelerator: 中東、北アフリカ、トルコ」のコホートの紹介

今回は過去最多の応募数を記録しましたが、このことからも、AI テクノロジーを活用して事業を通じた重要課題の解決に取り組むスタートアップがますます増えていることがうかがえます。このコホートに参加する 15 社をご紹介します。

BioTwin は、健康に関するデータからバーチャルツインを作成し、リスクの検出と予防措置の推奨を行います。
Coral は、企業全体のサステナビリティ関連の指標をリアルタイムで提供し、手作業のプロセスを不要にします。
Each::labs は、複雑なデベロッパーワークフローを合理化する次世代の AI ネイティブツールを構築しています。
Hakeem は、臨床研究を個々の患者に合わせたガイダンスにリアルタイムで変換し、医療従事者に提供します。
inveon.ai は、エージェント型 AI をデプロイして、e コマース向けの自律型デジタル従業員を提供します。
Jusoor Labs は AI を使用して科学実験でのインタラクションを分析し、学習成果を向上させています。
Openfarming は、販売業者のワークフローを自動化して、廃棄物の削減と利益の保護に貢献します。
Plusfinity は、スケーラブルでインタラクティブな教育を実現する AI ネイティブな学習インフラストラクチャを構築しています。
Promake は、AI を活用した設計と生産の最適化ツールで製造業を支援します。
Qanooni は、手動で行われる法律業務を構造化された検索可能なワークフローに変換します。
Repzo は AI を使用して、複雑な現場のデータを現場のチームが読む自然言語のレポートに変換します。
RFxAI は、AI 主導型の回答評価を通じて調達と販売を合理化します。
Tapper は、ML を適用して異常を検出し、無効なトラフィックをブロックします。
TruBuild は、構造化されていない建設データを分析することで、より迅速かつ客観的な入札評価を実現します。
Woliz は、音声 AI を使って小型店舗のオーナーがオンライン注文を利用できるようにします。

成果を上げるためのカリキュラム

6 月 1 日以降、各企業の創業者はスタートアップ特有の課題の解決を目的に特別にカスタマイズされた 3 か月間のプログラムに参加します。カリキュラムでは、包括的なスタック監査やグローバルエキスパートによる 1 対 1 のメンターシップなど、集中的な技術サポートが提供されます。

AI セキュリティとジェネレーティブデザインに焦点を当てた高度な技術トレーニングと、戦略的なビジネスモデリングおよび市場参入計画のバランスを調整することで、イノベーションの安全な拡大を支援します。この包括的なアプローチは、スタートアップが勢いを維持し、地域の持続的なデジタル成長と長期的なレジリエンスを促進することを目的としています。

このプログラムは昨年秋のコホートでも大きな成果を上げており、多くのスタートアップが成長と開発を加速させています。

エージェント型セキュリティオペレーションセンター（SOC）スイートのプロバイダである COGNNA も、継続的な成長を遂げている企業の一つです。アクセラレータ期間中に改善された同社のプラットフォームにより、アナリストは以前より 80% 速く作業できるようになりました。その後、同社は 920 万ドルのシリーズ A 資金調達ラウンドを完了しました。

BigQuery を使用してペタバイト規模のデータを取り込み、Google Kubernetes Engine により調査をスケールすることで、セキュリティ運用の変革と効率性の大幅な向上を達成しました。COGNNA の共同創業者 / CTO である Ziyad Alshehri 氏は「Google は、グローバル市場でのスケーリングを可能にすることで、COGNNA の未来を形作っています」と語っています。

AI を活用した不動産投資を行う UAE のスタートアップである Smart Bricks は、最近、a16z Speedrun が主導する 500 万ドルのプレシードラウンドを完了しました。Smart Bricks は、Google の ML パイプラインを使用して、ドバイ、ロンドン、ニューヨークの不動産投資ワークフローの 99% を自動化しています。

Smart Bricks の創業者 / CEO である Mohamed Mohamed 氏は次のように述べています。「Google for Startups Accelerator は、当社の技術開発を加速させるうえで重要な役割を果たしました。Google AI とクラウドスタックにアクセスできたことは、エージェント型 AI モデルの構築とスケーリングに役立ちました。特に、当社が扱うデータの規模と複雑さを考えると、その恩恵は大きなものでした。また、Gemini Enterprise Agent Platform や BigQuery などのインフラストラクチャにより、開発サイクルを大幅に高速化し、モデルのパフォーマンスを向上させ、より堅牢なデータドリブンプラットフォームをより迅速に市場に投入することができました。」

MENA-T の成長に向けた Google の取り組み

Google は、イノベーションの継続的な拡大を目的として、専門的なリソースとクラウドインフラストラクチャを提供し、この地域の創業者を支援し続けています。Google は、この地域のデジタルエコノミーがより安全で革新的な未来に向けて加速し続けることを目指しています。

この新しいコホートが MENA-T エコシステムの未来を形作っていくことを楽しみにしています。

- Google Accelerator およびスタートアップエコシステム責任者（中東、北アフリカ、トルコ担当）、Baris Yesugey

事後対応からレジリエンスへ: 高度な環境インテリジェンスで業界を支援

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

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

このたび Cloud Next において、Google は Google Earth AI の一部である新しい環境データセットを発表しました。これらのデータセットは、現在 Google Maps Platform で試験運用版として利用できます。Environment API スイートを補完するもので、大気質、花粉、天気に関するインサイトを提供します。これにより、API で提供されるリアルタイムデータの枠を超え、BigQuery とシームレスに統合されたハイパーローカルで高解像度の過去データから、環境に関するインサイトを引き出せるようになります。

これらのデータセットは、組織が複雑な環境データを実用的なインサイトへと変換し、先を見越した計画、健康アウトカムの改善、ビジネスレジリエンスの強化に活用できるよう設計されています。たとえば、医療機関は大気質や花粉量をモデル化することで、患者数の急増を予測できます。また、製薬会社は、症状の悪化などのさまざまな健康関連指標を、集約された過去データや信頼性の高い健康基準と関連付けることができます。

これらのデータセットの精度は、Google 独自の AI モデル、政府の基準観測局や商用センサーネットワークなどの膨大な地理空間データソースの組み合わせ、信頼性の高い過去インサイトと予測インサイトを確保するための継続的な検証によって支えられています。

天気に関するインサイト

天気インサイトデータセットでは、約 5 年分の高解像度の過去の気象データにアクセスできます。このデータは、世界全体では 0.1 度、米国と欧州では約 4 km 四方で 1 時間単位の詳細な情報を提供します。この包括的な気象記録を BigQuery 上の運用データと組み合わせることで、過去のパターンを分析して需要を予測し、配送ルートを最適化し、エネルギーや旅行関連のプロジェクトを戦略的に計画できます。こうした過去のインサイトを活用して先を見越した戦略を構築し、Weather API の予測と組み合わせてリアルタイムに適切なアクションを取ることで、小売、物流、旅行、エネルギー、保険、モビリティなどの業界で、運用効率を高め、レジリエンスを維持できます。たとえば旅行会社は、季節ごとの環境パターンに基づいて天気と予約の傾向を予測し、旅行パッケージやマーケティングキャンペーンを最適化できます。

BigQuery での降水量データの可視化

大気質と花粉に関するインサイト

大気質と花粉に関するインサイトデータセットを使用すると、数年分の過去データにアクセスし、特定の汚染物質や花粉の種類の濃度を 500 m または 1 km のグリッド単位で把握できます。これにより、地域ごとの「盲点」をなくすうえで必要な高精度のデータを得られます。たとえば、こうした精緻な環境パターンを患者記録と直接関連付けたり、今後の花粉飛散のピークを見越して小売店の在庫を最適化したりすることができます。検証済みの環境コンテキストを BigQuery 上の独自データと簡単に統合することで、事後対応型の意思決定から、健康への影響に関するより深い分析や、先を見越したケア管理へと移行できます。

特定の日におけるマンハッタンの PM2.5 の中央値を可視化

大気質、花粉、天気の過去データが、より高い精度と予測力の実現にどのように役立つのか、ぜひご確認ください。早期アクセスにご登録のうえ、詳細をご覧ください。

- Google Maps Platform 担当グループプロダクトマネージャー、Yael Shamir Zelmanoff

TPU 上で兆単位のパラメータを扱うモデルのクラスタレベルの信頼性

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

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

フロンティア AI モデルにより、コンピューティングの単位が大きく変化しています。数兆パラメータ規模の AI トレーニングでは、数千もの相互接続されたコンポーネントが、産業規模のデプロイメントでオーケストレートされ、単一の巨大なエンティティとして動作する必要があります。

同様に、信頼性に関しては、インフラストラクチャの総合的な可用性が重要です。しかし、これまで 20 年近くにわたり、インスタンスレベルの信頼性がクラウドの標準になっていました。インスタンスレベルの信頼性は、マイクロサービスと水平方向にスケーラブルなアプリケーション向けに設計されており、独立した小さなユニットの集合としてインフラストラクチャを扱います。このモデルは、大規模な AI ワークロードには根本的に不十分です。

Google は、信頼性をインスタンスレベルからクラスタレベルのモデルに移行する必要があると考えています。

Google は 10 年以上にわたり、Tensor Processing Unit（TPU）クラスタを大規模に運用し、最新の AI ワークロードのアーキテクチャ要件を満たす信頼性を実現してきました。このブログ記事では、Superpod レベルでの集合的なパフォーマンスに焦点を当てた、Google Cloud TPU のクラスタレベルの信頼性フレームワークをご紹介します。このフレームワークは、Google 社内で世界最先端の AI モデルを構築するために使用しているものです。現在、本番環境で使用している TPU の運用標準であり、先日発表された第 8 世代 TPU のアーキテクチャのブループリントとして機能しています。

AI スーパーコンピュータの信頼性

TPU の Superpod では、数千個のチップがキューブ（64 個の TPU）に編成されています。高速チップ間相互接続（ICI）リンクがキューブ内のすべてのチップを接続し、動的に構成可能な光回路スイッチ（OCS）ネットワークがすべてのキューブを接続して Superpod を形成しています。

システム全体のトレーニングの進行のためには、Superpod 内で完全に正常なキューブの数を最大化する必要があります。AI モデルのパフォーマンスは高帯域幅で低レイテンシの通信に依存するため、あるユニットがトレーニングの進行に貢献するには、キューブ内のすべてのチップと ICI リンクが動作可能な状態にある必要があります。こうしたアーキテクチャの現実を踏まえ、Google のクラスタレベルのフレームワークは、業界がインスタンスレベルの信頼性から大規模な可用性へと移行し、この AI 時代にどのように信頼性を実現できるかを定義するのに役立ちます。

詳細: 大規模な可用性の計算

インスタンスレベルの信頼性モデルは多くの場合、決定的ですが、産業規模の AI デプロイメントでは、数千個のチップにわたる確率的アプローチが必要です。従来の設定では、単一のチップの平均故障間隔（MTBF）を追跡していたかもしれません。しかし、フロンティア AI の規模では、コンポーネントの数が増えるにつれてクラスタレベルの MTBF が急激に低下します。

スケーリングによって信頼性がどれほど早く損なわれるかを可視化するには、マルコフの不等式のような単純な上限を確認できます。

障害が発生したキューブ数を X と定義した場合、マルコフの不等式からわかることは、クラスタサイズとともに予想される障害数 E[X] が増加したときに、システム的なアーキテクチャの変更なしでは、厳格な障害の基準を下回る確率を保証することが、ますます困難になるということです。

マルコフの不等式は、大規模なリスクについて有用な経験則を提供しますが、Google は、大規模な可用性を、クラスタの総合的な健全性の二項分布を使用してモデル化しています。n 個の独立したユニット（キューブ）から構成される Superpod で、k 個以上のキューブが完全に動作し、相互接続される確率を、n 個の独立した試行の成功の累積分布として定義します。トレーニングの生産性において 95% の信頼区間を確保するには、次の式で k を求めます。

ここで、n は Superpod 内の合計キューブ数を表し、p はキューブレベルの総合的な可用性を表します。

このモデルにより、インスタンスレベルのモデルが、大規模トレーニングの実際のパフォーマンス要件を反映するトポロジ対応フレームワークに置き換わります。このため、より大きなコンピューティングブロックが正常な状態で接続され、継続的なトレーニングの進行を促進できるようになります。

ML の生産性向上

グッドプット指標は、ML 生産性の主要な尺度です。信頼性における Google の新しい標準は、グッドプットの決定的な基盤を提供し、要求の厳しいヒーロージョブでこの指標を最大化するように設計されています。これにより、最先端の研究に必要な大規模なインフラストラクチャが単一のエンティティとして機能することが可能となります。

このモデルは、大規模なトレーニング実行にリソースのフルセットを利用できるようにすることで、3 つのグッドプット指標の一つであるスケジューリンググッドプットで高い値を実現します。このインフラストラクチャレベルの可用性とソフトウェアスタックを組み合わせることで、全体的なグッドプットを向上させることができます。Google は、次の 3 層から構成される信頼性モデルを通じてこれを実現しています。

インフラストラクチャ: TPU Superpod が、必要な規模を物理的に利用可能にして接続するための容量フットプリントを提供します。
フレームワーク: JAX と Pathways がレジリエンスを提供します。障害が発生したノードを再構成またはホットスワップして、完全な再起動を必要とせずに前進を維持します。
アプリケーション: 自動チェックポイントやマルチティアチェックポイントなどのフォールトトレランスメカニズムにより、トレーニングの状態が保持されるため、障害が発生した場合に失われる進行分を最小限に抑えることができます。

次世代の AI ブレークスルーを実現

クラスタレベルの信頼性モデルは、AI 時代の新しい標準の始まりを示しています。今後は、AI スーパーコンピュータが、イノベーションのための信頼できる産業規模のエンジンとなるでしょう。Google は、その信頼性に対するスタンスを、フロンティアモデルのニーズに合わせることで、次世代の AI ブレークスルーをより迅速で、より信頼性が高く、より予測可能なものにしています。TPU の詳細を確認して利用を開始するには、こちらをクリックしてください。

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

- グループプロダクトマネージャー、Mohan Pichika

一般提供が開始された Nano Banana 2 と Nano Banana Pro がクリエイティブなワークフローを強化

Wed, 03 Jun 2026 03:00:00 +0000

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

各業界の組織は、画像生成と編集の新たな利用方法を開拓しようとしています。次世代のエクスペリエンスを推進するために、企業は AI をクリエイティブなエージェント型ワークフローに直接組み込む取り組みを進めています。しかし、次世代のワークフローには、信頼できるエンタープライズグレードの AI が必要です。

新機能: お客様が安全にクリエイティブな作業を続けられるよう、このたび Nano Banana 2 （Gemini 3.1 Flash Image）と Nano Banana Pro（Gemini 3 Pro Image）の一般提供（GA）を Gemini Enterprise Agent Platform で開始いたしました。エンタープライズグレードのインフラストラクチャとセキュリティに支えられたこれらのモデルにより、高品質の画像生成および編集機能をアプリケーションやワークフローに直接統合できます。

両モデルのリリースに加え、モデルによるマルチモーダル入力の処理方法を大幅に拡張する強力な新機能もプレビュー版で発表いたしました。Nano Banana 2 がサポートする入力プロンプトとして、動画ファイルが新たに追加されました。テキスト、PDF、画像の入力を参照するのに加えて、モデルは動画の深い理解に基づき映像内の視覚的コンテキスト、特定の被写体、アクションを分析し、サムネイルやリッチなインフォグラフィックなど、コンテキストを認識した画像を生成します。この機能はこちらでお試しいただけます。

注: 1K と 2K の解像度での出力機能は両方のモデルで一般提供されていますが、4K での出力機能はプレビュー版のままです。

Nano Banana モデルを活用したイノベーションの例

Google は、パートナー様やお客様が可能性の限界を押し広げる姿に常に刺激を受けています。さまざまな組織が、こうした高度な画像生成機能を業務に取り入れることで、クリエイティブパイプライン全体でイノベーションを実現し、ユーザーが次世代のビジュアルエクスペリエンスを構築できるようにしています。

クリエイティブとマーケティングのイノベーションの促進

組織は、業界をリードするクリエイティブツールやワークフローに Google の生成画像モデルを直接組み込むことで、前例のないクリエイティブなイノベーションを推進し、カスタマイズされたキャンペーンを拡大し、ブランドとオーディエンスの関わり方に根本的な変化をもたらしています。

Adobe Firefly Enterprise のプロダクトマーケティング責任者である Aaron Mitchell Finegold 氏は、次のように語ります。「マーケティングチームとクリエイティブチームは、ブランドの整合性を最優先で確保しながら、高品質なエンタープライズグレードのコンテンツをより迅速に制作するプレッシャーに直面しています。Nano Banana モデルは、Adobe Firefly や Adobe GenStudio で作業する企業のチームがそうした現実に対処するうえでの支えとなっています。お客様は、業界をリードする AI モデルと Adobe の最高水準のクリエイティブツールを併用できます。高度な生成モデルの力と信頼できるクリエイティブおよびマーケティングのワークフローを組み合わせることで、組織は実験からエンタープライズ規模での実行へと移行できます。」

「Google とのパートナーシップを拡大したことで、WPP は Nano Banana 2 と Nano Banana Pro への早期アクセス権を獲得しました。これらのモデルは、WPP のエージェント型マーケティングプラットフォームである WPP Open に統合されています。整合性と制御性を高めるこれらのモデルは、Verizon、L’Oreal、Unilever などのクライアント向けに実装された大規模コンテンツ制作システムの基盤として急速に定着しました。WPP Open で Google の画像モデルを使用することで、チームはメディアのアセットを迅速に最適化し、クリエイティブを適応させることができます。Google Cloud と提携して、生成メディアを活用した創造性の限界を押し広げられることを嬉しく思います。」- WPP、最高イノベーション責任者、Elav Horwitz 氏

小売と顧客対応の変革

ショッピングプラットフォームは、バーチャル試着や動的なカタログ拡充などの没入型エクスペリエンスを提供するために Google の画像モデルを使用しています。これにより、購入前の買い物客は高度にインタラクティブかつパーソナライズされた環境で商品を確認することができます。

「品質と速度が向上した Nano Banana と Nano Banana Pro は、販売者のみなさまにさらに優れた画像生成技術を提供します。画像生成機能を活用すれば、既存の商品写真を補完できるだけでなく、魅力的でリアルなソーシャル画像やライフスタイル画像を生成してカタログを際立たせ、購入者の関心を引くことができます。」- Shopify、シニアスタッフプロダクトマネージャー、Matthew Koenig 氏

同様に、URBN（Urban Outfitters）は Google の生成メディア機能を活用して、製品開発の初期段階を加速させています。

「URBN は、Google の画像生成および編集機能を活用して、製品開発の初期段階を加速させています。最初の試験運用において、市場投入までのパイプラインを大幅に圧縮できる可能性が示されました。」- URBN（Urban Outfitters）、グローバルエグゼクティブディレクター、Demo Lymberopoulos 氏

次世代のメディア制作ワークフローの構築

メディアやエンターテイメント業界の企業は、これらのモデルを採用して、複雑な制作パイプラインを管理する次世代のアプリケーションを構築しています。そうしたアプリケーションは、スタジオがディレクションコントロールを維持しながらワークフローを革新することを可能にします。

「世界で最も複雑な AI クリエイティブの課題に取り組んだ経験を活かして構築された Nodey は、クリエイターの足かせとなる分断されたインターフェースや手動のワークフローを解消することを目的としています。Nodey を当社の空間インテリジェンスプラットフォームである OKO に統合することで、AI のテストとプロフェッショナルな制作の間の隔たりを埋めることができます。クリエイターは、試行錯誤で入力されるプロンプトに代わって空間環境に固定されたワークフローを使用することで、制御可能で安全な 3D パイプライン内で Nano Banana や Veo などの Google の生成モデルを使用できるようになりました。これにより、生成される要素とクリエイティブな意図との完全な整合性が保証されます。」- Magnopus、CEO、Ben Grossmann 氏

Gemini 3 Pro Image と Veo 3.1 のワークフロー

エンタープライズグレードのマルチモーダルエクスペリエンスの構築を開始する

没入型の小売アプリケーション、インタラクティブなコマースツール、メディア制作ワークフローの加速など、Google Cloud は、次世代のエージェントクリエイティブとマルチモーダルエクスペリエンスを構築するためのモデルとツールを提供します。エンタープライズ SLA で完全にサポートされた Nano Banana 2 と Nano Banana Pro をエンタープライズ規模でデプロイするために必要な技術的フレームワークおよび商業的フレームワークには、こちらからアクセスできます。

リソース:

Nano Banana 2（Gemini 3.1 Flash Image）のドキュメント
Nano Banana Pro（Gemini 3 Pro Image）のドキュメント
デベロッパーは Gemini API を介して両方のモデルにアクセスすることもできます（エンタープライズ SLA の対象外）
Nano Banana 向けプロンプト完全ガイド

- Google Cloud、プロダクトマネージャー、Stanley Tack

【Next Tokyo セッション公開】ドラクエ・イオン・日テレが登壇！AI 変革のリアルを学ぶ注目セッション

Wed, 03 Jun 2026 03:00:00 +0000

セッション公開！
AI 変革のリアルを学ぶ注目セッション

2026 年 7 月 30 日（木）、 31 日（金）に開催する旗艦イベント Google Cloud Next Tokyo のセッション情報を公開しました。話題の AI エージェントをはじめ、インフラ、アプリケーション開発など、米 Next の最新アップデートと、AI ネイティブな変革を推進する日本のお客様の活用術をお届けします。

皆様へのおすすめセッションとして、ゲーム運用、大規模リテール、エンタメ×AI の最前線を走る企業の事例を厳選。ドラクエの運用を支える Gemini の裏側から、イオンの大規模な 1 to 1 顧客体験、最新の生成 AI マーケティング事例まで、他では聞けない豪華セッションを多数公開しております。

さらに会場では、進化した Agentic AI とクラウドをライブ体験できるブースや、実際に Google Cloud を操作できる Learning Lab もご用意しています。

未来を築くのは、あなた自身です。Next で得られる最先端の知見や戦略、ツールを手に、次の一歩を踏み出しましょう。ご登録がまだの方は、ぜひ、今すぐ公式サイトからご登録ください。

注目のブレイクアウトセッション

進化した AI エージェントが、どのように実際のビジネスに活かし、新たな価値を生み出していくのか。各業界のトップランナーによる、一歩進んだ次世代のビジネス戦略と具体的な活用術をお届けします。

☁️ Day 1

12:00 - 12:30 スクウェア・エニックス：『ドラゴンクエストX オンライン』の世界観を守り抜く Gemini 実装の全貌。「チャット AI」を「相棒」にする技術とは

15:00 - 15:30 AOI Pro. / リクルート：GenMedia 最新アップデートと、SUUMO・KANAMEL の画像・映像生成事例

☁️ Day 2

12:00 - 12:30 イオンリテール：AI で「探す手間」を「選ぶ楽しさ」へ。実店舗とデジタルが創る 1500 万人の 1 to 1 体験

17:00 - 17:30 日本テレビ放送網：コンテンツど真ん中を人と AI で創る。日本テレビの AI クリエイティブ戦略

当日はライブ配信がなく、席数に限りがありますので、お早めにセッション登録をお願いします。

開催概要

名称：Google Cloud Next Tokyo（略称 Next Tokyo）

日時：2026 年 7 月 30 日（木）、31 日（金）

会場：東京ビッグサイト南展示棟・会議棟

対象：エンジニアからビジネスリーダーまで、生成 AI やクラウドを活用して、ビジネスを次のステージへと進めたいすべての方へ

- お問い合わせ -
Google Cloud Next Tokyo 運営事務局
E-mail: gc-nexttokyo-info@google.com

最新調査: IT リーダーにとってブラウザでの AI セキュリティ確保が最優先事項に

Wed, 03 Jun 2026 02:00:00 +0000

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

私たちの働き方は根本的に変わりました。自動化されたエージェントから高度な AI サービスまで、生成 AI は、大多数の従業員にとって日常的なツールとなっています。しかし、この急速な導入に伴い、IT リーダーには新しい重大な課題が突きつけられています。それは、ブラウザが主要なワークスペースとなり、データが AI 主導のワークフローを頻繁に行き来する現代において、いかに企業情報を保護するかという点です。

組織がこの新しい状況にどのように向き合っているかを把握するため、Google は業界アナリスト企業である Omdia にレポートを委託しました。北米の IT およびサイバーセキュリティの専門家 400 人を対象に調査を実施した結果、最新の企業セキュリティにおいてブラウザが最前線となっており、特に AI 利用のセキュリティを確保するうえで極めて重要であることが示されました。

ブラウザの重要性は高まり続けている

次々と現れる新たな脅威が、ブラウザ管理の重要性を高めています。10 人中 9 人が、ブラウザのセキュリティは優先事項の上位 5 つに入ると回答しており、組織においてブラウザがいかに重要な役割を果たしているかを強調する結果となりました。

生成 AI の利用が増加するにつれ、そのセキュリティ確保の優先度も高まる

調査によると、実に 92% もの組織が現在、従業員によるパブリックな生成 AI アプリケーションの使用を許可しており、その利用の大部分がブラウザ内で直接行われています。これにより、企業の監視が届かないところでデータが流出する、新たな経路が生まれることになります。

ブラウザのセキュリティは主要な優先事項となっており、AI 利用のセキュリティを効果的に確保する絶好の機会でもある

こうした変化に伴い、ブラウザ関連の脅威が大きな懸念事項となっています。このレポートでは、55% の組織が過去 12 か月間にブラウザベースのセキュリティ攻撃を経験したことがわかりました。新たな脅威について尋ねたところ、IT リーダーは AI を活用したフィッシング（75%）と生成 AI ツールからのデータ漏洩（71%）を最大の懸念事項として挙げました。

新しいセキュリティソリューションを評価する際、59% の IT リーダーが「生成 AI アプリケーションのセキュリティ」を、組織におけるセキュアなブラウジングソリューションの重要なユースケースとして挙げています。

Chrome Enterprise ソリューション

このレポートの調査結果は、クラウドファーストで AI を活用した世界において、従来のネットワークベースのセキュリティツールには限界があることを浮き彫りにしています。このような以前のシステムでは、SaaS や生成 AI アプリケーションへの暗号化されたトラフィックを可視化して検査する機能が不足している場合があり、データ保護に大きな空白が生じることになります。

Chrome Enterprise は、ネットワークプロキシや追加のエージェントに依存するのではなく、AI セキュリティをブラウザに直接組み込んでいます。Chrome Enterprise を使用すると、IT チームとセキュリティチームは次のことが可能になります。

AI の使用状況を把握して管理する: 従業員による生成 AI ツールの使用状況を可視化し、エンタープライズ向けの管理機能によってデータ持ち出しのリスクを特定します。
データ保護管理を適用する: 生成 AI ツールを含むあらゆるウェブベースのアプリケーションで、きめ細かい管理を使用してアップロード、ダウンロード、コピー＆ペースト、印刷、スクリーンキャプチャをきめ細かく制御することで、データ損失を防止します。
コンテキストアウェアアクセスポリシーを設定する: 単純なブロックにとどまらず、Chrome Enterprise では、ユーザー、デバイス、場所のコンテキストに基づいて、承認された AI ツールへのアクセスを許可するポリシーを作成できるため、生産性とセキュリティを両立できます。

働き方がますますブラウザ中心で AI 主導となるにつれ、ブラウザのセキュリティ確保はもはやオプションではなく、必須となっています。

調査のハイライト「Securing AI Usage Starts in the Browser（AI 利用の保護はブラウザから）」を今すぐチェックして、最新のブラウザセキュリティ戦略や、Chrome Enterprise が組織の保護にどのように役立つかについてご確認ください。

- Chrome Enterprise、シニアプロダクトマネージャー、Niamh Cunningham

Cloud Run、Firebase、Cloud SQL を使用したフルスタックのバイブコーディングが AI Studio で可能に（クレジットカードは不要）

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

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

Google I/O 2026 では、Google AI Studio と Google Cloud のインテグレーションに関する最新情報を発表しました。

新規ユーザーは、請求先アカウントなしで、フルスタックアプリケーションを 2 つまで Google Cloud スターターティアにデプロイ可能
データベースの選択肢の拡大: 非リレーショナルデータ用の Firestore と、新しいリレーショナルデータベースオプションとしての Cloud SQL
Firebase Auth を単一のユーザーログインフローとして使用することで、Google スプレッドシート、Google カレンダー、Gmail などの Google Workspace ツールとの緊密なインテグレーションを実現

これらは、3 月に発表したインテグレーションのアップデートであり、これには、Cloud Run、Firestore、Firebase Auth を活用することで、バイブコーディングされたフルスタックアプリケーションを AI Studio からデプロイするためのサポートが含まれていました。

このインテグレーションの拡大により、AI Studio を使用してより幅広いアプリケーションを構築できるようになりました。データベースには、Cloud SQL を使用したリレーショナルデータベースか、Firestore を使用した非リレーショナルデータベースのいずれかを使用できますが、ユーザーがデータベースを指定する必要はありません。AI エージェントが、アプリや機能に適したデータベースを自動的に判断します。

ぜひ実際にお試しください。AI Studio では、スターターティアで Cloud Run、Cloud SQL for PostgreSQL（来月提供開始）、Firestore、Firebase Auth を無料でご利用いただけます。

AI Studio から Cloud Run へ、フルスタックアプリケーションをワンクリックで公開

手軽に導入: Google Cloud スターターティア

AI Studio でアプリケーションを構築して、プロトタイプを Cloud Run に直接デプロイしたり、Firebase Auth で認証を行ったり、データを Firestore や Cloud SQL データベースに保存したりできます。クレジットカードや Google Cloud アカウントは必要ありません、面倒な手続きも一切不要です。プロンプトを入力するだけで、すぐに開始できます。

AI Studio では、アカウントがない場合は、Google Cloud スターターティアを使用してリソースが作成されます。フルスタックアプリケーションは 2 つまでデプロイできます。スターターティアの制限を超えた場合は、請求先アカウントが登録されている標準の Google Cloud プロジェクトにアップグレードできます。すべてのリソースが課金対象の Google Cloud プロジェクトに移行されるため、アプリケーションを成長に合わせてスケールできます。

Cloud SQL でフルスタックのバイブコーディングを強化

インテリジェントかつ自動化されたデータ基盤を導入することで、デベロッパーは、インフラストラクチャではなくアプリケーションに集中できるようになります。

AI Studio と Cloud SQL のインテグレーションには、以下が含まれます。

即座に利用開始: インスタントプロビジョニングにより、プロンプト入力から完全にデプロイされた PostgreSQL データベースの利用までを迅速に実現できます。
無料で開始: クレジットカードや Google Cloud アカウントがなくても、Google Cloud スターターティアで Cloud SQL を無料でお試しいただけます。
柔軟な費用管理: AI エージェントは新しい Cloud SQL for PostgreSQL デベロッパーエディションを使用します。これにより、バックエンドが自動的にゼロにスケールできるようになります。課金されるのはアプリを使用している間のみです。
エージェント主導のエクスペリエンス: 新しいプロンプトを入力するだけでアプリケーションを更新できます。AI エージェントが自動的にスキーマを作成し、データベース内で SQL ステートメントを実行します。
グローバルなスケーラビリティ: インターフェースはシンプルですが、アプリケーションは Google Cloud の堅牢で信頼性が高く、安全に設計されたインフラストラクチャ上で実行されます。数百万人ものユーザーをサポートするようにスケールすることも可能です。

Cloud SQL for PostgreSQL デベロッパーエディションを活用したアプリの作成

Firestore と Firebase Auth を使用したフルスタックのバイブコーディング

AI Studio でアプリを構築する際、エージェントは、プロンプトに基づいてデータストレージや認証が必要かどうかをプロアクティブに検出し、データベースやユーザー認証の設定を提案します。ドキュメントデータベースが役立つアプリの場合、エージェントは、Firestore や Firebase Authentication を有効にするカードを表示し、ユーザーの承認を求めます。

アプリケーションで Firebase を有効にするかどうかの確認を求めるエージェント

[Firebase を有効にする] をクリックすると、エージェントは自動的に以下の処理を行います。

Firestore をプロビジョニングし、認証を有効にして、アプリをデータベースに接続する
ウェブアプリのログインページを作成し、Google ログインによる認証を構成する
アプリ内で Firestore コードを生成し、セッションやデバイス間でデータを同期できるようにする
アプリのロジックに基づいて Firestore セキュリティルールの下書きを作成してデプロイする（ただし、アプリの共有やデプロイを行う前に、ユーザーがこれらのルールを必ず再確認する必要があります）

Firebase Auth を使用すると、以下のことが可能になります。

自然言語を使用してアプリを Google Workspace に接続する: Workspace の機能（Google スプレッドシート、Google カレンダー、Gmail など）をリクエストすると、エージェントは Firebase Authentication を利用した「Google でログイン」フローを実装し、Google AI Studio がデータに安全にアクセスできるようにします

Firebase Authentication を利用してアプリを Google スプレッドシートに接続

詳しくは、Google I/O で発表された Firebase の最新情報に関するブログ記事をご覧ください。

AI Studio を使ってみる

アイデアをアプリで実現することは、もはや絵空事ではありません。以下の手順に沿って進めることで、フルスタックアプリケーションを無料で構築できます。

AI Studio にログインする: プラットフォームにアクセスしてプロジェクトを開始します。
プロンプトを使用して構築する: 自然言語のプロンプトを使用してアプリケーションの構築を開始します。たとえば、「経費管理アプリを構築して」などと指示します。
データベースを有効にする:「データベースを追加して」という指示をすると、AI Studio が「Enable」ウィジェットを通じてデータベースをインテリジェントにプロビジョニングします。特定のリレーショナルデータベースを明示的に指定することもできます。
システムを設定する: [Enable] を選択し、利用規約に同意します。
共有を開始: [Publish] ボタンを使用してアプリケーションをデプロイし、共有します。

AI Studio を今すぐ利用して、アイデアを数秒でライブアプリケーションに変換しましょう。

- プロダクトマネージャー、Justin Mahood

- プロダクトマネージャー、Gopal Ashok

Next ‘26 でのストリーミング AI に関する発表

Wed, 03 Jun 2026 00:00:00 +0000

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

データは、ありとあらゆるデバイス、ユーザー、マイクロサービスで生成されます。このデータを取り込み、意味とインサイトを抽出し、リアルタイムでビジネス上の意思決定を推進することで、変革的なビジネス価値を生む可能性が高まります。リアルタイム分析に内在する課題も、エージェント型 AI の急発展で克服のチャンスが現実のものとなっています。エージェント型 AI は導入加速の大きな可能性を秘めていますが、ユーザーはリアルタイムデータを効果的に活用するうえで、以下の新しい課題に直面しています。

コンテキストのリアルタイム実装が困難。開発チームは通常、データベースの定期的な同期やスケジュールされた更新など、バッチ処理的アプローチでデータを取り込みます。このため、エージェントは、古いデータに依存するか、メモリを大量に消費するコンテキストウィンドウを必要とします。この「コンテキストの時差」は、不正行為の検出、e コマースの動的なおすすめ表示、サプライチェーンの自律的な調整など、せっかくのリアルタイムエージェントタスクの効果を帳消しにしてしまいます。
リアルタイムシステムは柔軟性に欠ける。エージェントツールには、お客様固有の要件に適応するためのモジュール性が欠けており、組織は難しいアーキテクチャの選択を迫られます。データ実務者は、レイテンシ、精度、費用のトレードオフを自由に選択できるプラットフォームを必要としています。

これらの課題に対応するために Google Cloud は、緊密に統合された統一ストリーミングデータプラットフォームを提供しています。このプラットフォームは、フルマネージドの Google Cloud ネイティブサービスとオープンソース互換サービスの両方を提供し、大規模な AI トレーニングと推論をサポートします。このプラットフォームを構成する 5 つの主要サービスは以下のとおりです。

Pub/Sub: メッセージングとイベントストリーミングのための、信頼性の高いサーバーレスなフルマネージドサービスで、BigQuery、Dataflow、Cloud Storage と統合されています。Pub/Sub は Anthropic をはじめとする多くの組織で利用されています。
Dataflow: バッチ、ストリーミングのための、そして今やエージェント型 AI を支えるサーバーレスエンジンです。Waymo や Google マップなどの Google サービス同様、Palo Alto Networks などの大手企業にも採用されています。たとえば、Waymo 車両は Dataflow を使用して周囲の状況を「把握」し、ルートを計画したり、障害物を予測したりします。自動車が実際に道路を走行する前に、シミュレータで数百万マイルを「走行」し、Dataflow でトレーニングデータセットを生成して自動運転に使用されるモデルを検証します。
Managed Service for Apache Kafka: 信頼性、安全性、費用対効果に優れたオープンソースのストリーミングストレージ兼データ統合システム Apache Kafka を、Google Cloud 上で実行するためのフルマネージドサービスです。大企業からスタートアップまで、Apache Kafka は重要なトレーニングデータと AI エージェントコンテキストのリアルタイム更新のステージングロケーションとして利用されています。
BigQuery: リアルタイムの取り込みと分析のための統合プラットフォーム。Storage Write API が、1 回限りの配信セマンティクスとストリームレベルのトランザクションで、BigQuery と Lakehouse for Apache Iceberg のテーブルに高スループットストリーミングを提供します。さらに、BigQuery の継続的クエリでは、AI.GENERATE_TEXT などの生成関数を呼び出すことで、データパイプライン内で直接リアルタイムの AI 推論が可能になり、データが取り込まれると同時に分析情報を得ることができます。
Bigtable: Google の NoSQL リアルタイムデータベース。継続的なマテリアライズドビューを使用して Pub/Sub と Dataflow からのストリーミングデータを自動的に処理し、結果を数秒で提供します。Bigtable のインメモリ階層を使用して低レイテンシでサービス提供できるようにします。

インサイトから自律的アクションへと進化

Google Cloud Next '26 では、ストリーミング AI 機能セットの Agentic Data Cloud への追加が発表されました。これにより、自律型エージェントに即座にコンテキストが提供され、リアルタイムのアクションが可能になります。つまり、組織は AI エージェントにリアルタイムのコンテキストをフィードできるようになります。

たとえば、サプライチェーンエージェントは、IoT データをモニタリングするだけでなく、悪天候を避けてルートを自律的に変更したり、配送先の倉庫と納期の許容範囲を再調整して顧客のポータルを更新したりできます。しかも、これらすべてが、人間の監督者が問題に気づく前に実行されるのです。また、金融サービスエージェントは、不正なトランザクションパターンを特定し、即座にアカウントを凍結して、お客様が希望する手段で連絡を取ってから新しいカードの発送を手配してくれます。これらすべてが、不審なアクティビティが発生してから数秒以内に遂行されます。これらの機能は、検索を強化するためにストリーミングデータのエンベディングを作成する場合でも、マルチエージェントによる高度な不正行為検出システムを構築する場合でも、強力な新しい武器となります。

これらの新機能について詳しく見ていきましょう。

新しいストリーミング AI 機能

Next ‘26 で発表された新機能は、Google Cloud のストリーミングデータプラットフォームに 3 つの主要分野にわたって緊密に統合されています。

1. エージェントにリアルタイムで豊富なコンテキストを提供

1.1. Pub/Sub AI 推論 SMT（一般提供）: Pub/Sub を介してストリーミングされたメッセージに対して推論を実行できるようになりました。データ実務者は、Gemini Enterprise Agent Platform で利用可能なモデルを自由に選択できます。Pub/Sub が推論を呼び出し、各メッセージに結果を追加してダウンストリームへと送ります。Pub/Sub のシンプルさと Gemini Enterprise のフルマネージドツールとが効果的に融合します。

1.2. Pub/Sub Bigtable サブスクリプション （プレビュー版）: Pub/Sub データを Bigtable に直接ストリーミングします。Pub/Sub Bigtable サブスクリプションは、Pub/Sub トピックからイベントデータを直接 Bigtable テーブルにマテリアライズするため、カスタムパイプラインが不要になり、ストリーミングアーキテクチャを大幅に簡素化します。たとえば、ベクトルエンベディングを Bigtable に簡単に取り込み、セマンティック検索ワークロードを強化できます。

1.3. BigQuery 継続的クエリのステートフルデータ処理（プレビュー版）: BigQuery の継続的クエリで JOIN を使用して複数のデータストリーム間の複雑な相関関係を特定し、タンブリングウィンドウ集計を使用して一定の時間間隔で指標を計算できるようになりました。たとえば、30 分間の平均値の計算や、異なるストリーム間のイベントの関係付けなどの高度な分析を、データが BigQuery に取り込まれると同時に直接行うことができます。さらに、AI.GENERATE_TEXT などの生成関数を呼び出すことで、AI をデータパイプラインに直接統合できます。また、継続的クエリの SQL 結果を BigQuery テーブルにマテリアライズしたり、リアルタイムのリバース ETL のために Bigtable、Spanner、Pub/Sub などの運用シンクにエクスポートしたりできます。

2. エージェントに指示してリソースを管理

2.1. Pub/Sub、Managed service for Apache Kafka、Bigtable、BigQuery の Model Context Protocol（MCP）サポート（一般提供）: エージェントが、フルマネージドの MCP エンドポイントを使用して、Pub/Sub、Managed service for Apache Kafka サービス、BigQuery を管理できるようになりました。エージェントは Pub/Sub にメッセージをパブリッシュすることもできます。

2.2. ADK インテグレーション（一般提供）: エージェントが、事前構築された ADK インテグレーションを通じて、Pub/Sub、Bigtable、BigQuery、その他の Google Cloud サービスに保存されたリアルタイムデータとやり取りできるようになりました。このため、デベロッパーはリアルタイムのコンテキストに基づいて動作するエージェントを、複雑な構成やパイプライン調整の作業なしで構築できます。

3. マルチエージェントシステムとデータ処理の統合

3.1. イベントドリブンな自律エージェント: ワークフローの中核をエージェントが担うようになると、リアルタイムのデータパイプラインを進化させてエージェントをストリームに直接組み込む必要が生じます。Google Cloud では、エージェントロジックを Dataflow パイプライン内で第一級の対象として扱うことで、これを実現しました。これにより、Agent Development Kit（ADK）を使用してエージェントコードを組み込み、RunInference 変換と新しい ADKAgentModelHandler を使用して、特別ノードとしてデプロイできるようになりました。このアプローチには主に次のメリットがあります。

優れたスケーラビリティ: Dataflow のアーキテクチャを活用して、アップストリームで高速のイベントを処理し、数百のエージェントセッションを同時にアクティブに保ちます。各セッションは個々に特定の受信イベントによって起動されます。
事前処理の効果: Dataflow が複雑なデータ拡充の作業を一手に引き受け、エージェントに「すぐに行動可能」のコンテキストを受け渡して、エージェントが推論に集中できるようにします。

3.2. Dataflow 統合エンベディングシンク: 統合エンベディングの生成プロセスをデータストリーム内に直接組み込み、「コンテキストのタイムラグ」を解消しました。これにより、Dataflow を使用して、受信データを高次元ベクトルに低レイテンシで変換できるようになりました。さらに、このリアルタイムエンベディングは、Cloud Spanner（組み込みベクトル検索の新機能を搭載）と AlloyDB を含む、拡張された高スループットのベクトルシンクスイートにシームレスにマテリアライズされます。これにより、セマンティック検索のニーズに対応する最新のベクトルデータベースが利用可能になります。また、RAG 呼び出しを行う自律エージェントは、即座に検索可能で完全に同期された長期記憶を利用できるようになります。この機能は、リモートモデルとローカルモデルの両方で動作します（例: Gemma）。

Google Cloud は今後もプラットフォームを拡充し続け、より緊密な統合とより強力な機能をお客様にお届けしてまいります。皆様がこれらの新機能を活用して次に何を生み出すのか、楽しみにしております。

- プロダクト管理担当ディレクター、Jagdeep Singh

- グループプロダクトマネージャー、Prateek Duble

AI 時代に向けた Google のグローバルおよびデータセンターネットワークの進化

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

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

Google のグローバルネットワークを構築してきた過去 25 年間、私たちはインターネットからストリーミング、そしてクラウドへと、主要なアーキテクチャの時代を歩んできました。現在、私たちは第 4 の時代、すなわち AI 時代の真っ只中にいます。AI 時代のアプリケーションは、これまでの時代の消費者向けアプリケーションや企業向けアプリケーションとは根本的に異なり、コンピューティングリソースはもちろんのこと、ネットワークに対しても、これまでにない厳しい要件を課します。

基本的な物理的課題として、電子（電力）を移動させるのは、光子（ファイバー経由のデータ）を移動させるよりもはるかに難しいという点があります。AI コンピューティングの需要は、個々の施設のスペースや電力容量を上回ることが頻繁にあるため、Google はデータセンターをサステナブルなエネルギー源の近く、あるいは地域の電力網にクリーンエネルギー源を導入する手段が整った場所に戦略的に配置しています。こうして、ネットワークを活用して AI ワークロードをキャンパス全体に分散させることで、単一サイトの電力制限を克服する大規模なプール型ハイパーコンピューティングリソースを構築します。

これを実現するために、Google はチップからシステム、プラットフォーム、アプリケーション、エージェント型エコシステムまで、あらゆるものを網羅するエンドツーエンドの垂直統合型 AI 技術スタックを構築しました。このスタックには、事前構築されたエージェントとアプリケーションのポートフォリオ、AI 対応アプリケーションの構築、スケーリング、ガバナンス、最適化を支援する Gemini Enterprise Agent Platform、世界クラスの AI モデル、統合データプラットフォームが含まれています。これらすべての中核をなすのが、Google の AI Hypercomputer です。これは、専用のハードウェアとオープンソフトウェアを組み合わせた統合インフラストラクチャであり、柔軟な使用オプションが用意されています。数十年にわたるイノベーションを通じて築き上げられた Google のネットワークは、AI Hypercomputer の不可欠なファブリックです。

このスタックを支えるネットワークは、AI ワークロードにおける帯域幅、スケール、パフォーマンスへの厳しいニーズを満たさなければなりません。これは、ネットワークをスケールアップおよびスケールアウトさせる必要があるキャンパス内だけでなく、広帯域な相互接続を含む広域ネットワーク（WAN）全体にも当てはまります。AI トレーニングデータをデータソースから AI コンピューティングリソースへと転送する必要があるためです。

これらの課題に対処するため、Google はネットワークインフラストラクチャの 3 つの主要な柱（AI Hypercomputer 内のファブリック、AI Hypercomputer 間のファブリック、グローバルネットワーク）を再構築しました。それぞれを詳しく見ていきましょう。

1. AI Hypercomputer 内のファブリック

基盤 AI モデルのパラメータの爆発的な増加を背景に、現在の AI モデルは大規模化しており、AI トレーニングにはコンピューティングとネットワークの両面で極めて高い負荷がかかっています。

そのため、必要なネットワーク帯域幅は指数関数的に増加し、遅延（テールレイテンシなど）には厳しい制限が課せられます。これは、パフォーマンスの変動に対する敏感さや同期バースト（ミリ秒レベルで発生する激しく統制されたトラフィックスパイク）といった、AI ワークロード特有のトラフィックパターンに対応するためです。さらに、大規模なトレーニングジョブは障害やパフォーマンスのストラグラー（停滞）に対して特有の脆弱性があるため、高い信頼性と予測可能なパフォーマンスを維持することが絶対に不可欠です。

最新の AI ワークロードに必要なスケール、低レイテンシ、高い予測可能性、そして極端なバーストからの保護に対応するため、Google は「キャンパスをコンピュータとして」という理念を採用し、ネットワークを 3 つの異なるドメインに分離しました。

Pod 内接続用のスケールアップドメイン
専用の East-West スケールアウトアクセラレータファブリック
North-South のコンピューティングおよびストレージアクセス用の Jupiter フロントエンドネットワーク

この分離されたアーキテクチャには 3 つの戦略的利点があります。ドメインを個別に進化させてイノベーションを加速できること、大規模なトレーニング帯域幅を備えたノンブロッキングのスケールアウトネットワークを提供できること、新しい ML アクセラレータと足並みを揃えてネットワークを共同設計し、優れたハードウェアサポートを実現できることです。

Google は最近、最新の AI 向けに特別に設計されたスケールアウトデータセンターファブリックである Virgo Network を発表しました。Virgo は、高基数スイッチとフラットな 2 レイヤのノンブロッキングトポロジを利用して膨大な二分割帯域幅を提供すると同時に、ネットワーク階層を減らすことでレイテンシを最小限に抑えています。各プレーンに独立した制御ドメインを備えたマルチプレーン設計により、ハードウェアレベルの復元力と障害分離を実現しています。さらに、Virgo は複数のデータセンターに拡張できるため、物理的な建物の制限がなくなり、AI コンピューティングの柔軟なスケーリングが可能になります。

ネットワークとアクセラレータの共同設計の有効性は、最近発表された第 8 世代 TPU で完璧に実証されています。このアーキテクチャでは、Virgo Network は 134,000 個の TPU 8t チップをリンクして、単一のファブリックで最大 47 ペタビット/秒のノンブロッキング二分割帯域幅を実現できます。Virgo Network は、前世代比で TPU 8t アクセラレータあたり最大 4 倍の帯域幅を提供します。また、TPU 8t の無負荷時のファブリックレイテンシは、前世代の TPU ネットワークと比較して 40% 低減されています。この構成では、Virgo Network がアクセラレータの未加工のトラフィックを管理し、Jupiter がグローバル WAN とストレージへの信頼性の高い高速アクセスを提供します。Pathways と JAX を統合すると、この AI Hypercomputer ネットワーキングエンジンにより、単一の論理クラスタで最大 100 万個の TPU 8t チップまでほぼ線形にスケールできます。

自律的な信頼性: ワークロードのグッドプットを保護する

復元力のあるメガスケールのファブリックを構築することは、課題の一部にすぎません。数十万個のチップからなるクラスタでは、ハードウェア障害は統計的に必ず発生します。インスタンスが 1 つでも停止すると、同期トレーニングジョブ全体が停止し、貴重なコンピューティングサイクルが無駄になります。そのため、効率的な障害箇所の特定が不可欠となります。

Google は、自律的な信頼性機能を備えた Virgo Network を設計し、大規模環境におけるワークロード効率（いわゆるグッドプット）を最大化しました。既存のストラグラー検出を拡張し、Virgo Network には自動ハング検出機能も新たに搭載されました。障害停止イベントが発生した瞬間に、専門のエージェントが直ちに障害箇所を特定して故障したインスタンスを隔離し、チェックポイントからのトレーニングジョブの復元を可能にします。これにより、手動による介入を最小限に抑えつつ、トレーニングのタイムラインを迅速に軌道に戻すことができます。詳しくは、こちらのデモをご覧ください。

これらの機能を補完するために、高解像度のサブミリ秒単位のテレメトリーも使用して、従来の 30 秒間隔のモニタリングでは通常見逃される、捉えにくいネットワークマイクロバーストを検知します。高解像度テレメトリーの進歩により、ネットワーク運用がより効率的になり、プロビジョニングが改善され、平均復旧時間が短縮されます。

2. AI Hypercomputer 間のファブリック

最新の AI ワークロードは指数関数的に増加しているため、WAN を介してそれらを複数のキャンパスにスケールして分散する必要があります。同時に、従来のネットワークは AI トラフィックの広帯域や極端なバースト性を想定して設計されておらず、深刻なパフォーマンス低下を招く恐れのあるマイクロバーストを検出できないことがよくあります。Google は、サイトをまたぐ AI デプロイにおける WAN のパフォーマンスを最適化するために、以下のような一連のイノベーションを開発しました。

水平スケーリングを可能にするマルチシャードのグローバルネットワーク。Google のグローバルネットワークは、2020 年から 2025 年にかけての 10 倍という WAN トラフィックの増大に対応しました。
可用性、レイテンシ、サービス品質（QoS）といった不可欠な特性に合わせた、ファブリックのチューニング。リアルタイムのマイクロバースト管理により、マルチテナントインフラストラクチャ全体で公平な帯域割り当てとインフラストラクチャの分離が確保されます。
各ネットワークシャードが独自のコントロールプレーン、データプレーン、管理プレーンで動作するマルチシャード分離構造。

リージョン分離と Protective Reroute を組み合わせることで、このアーキテクチャは障害の影響を最小限に抑え、ユーザーに影響する停止時間を短縮し、AI ワークロードに不可欠な 99.999% を超える信頼性を実現します。

高速で柔軟かつ費用対効果の高い相互接続を提供することも優先事項です。AI トレーニングは、オンプレミスやさまざまなクラウドに分散していることが多く、膨大なデータセットに依存しています。AI コンピューティングの費用は高額であるため、アイドル時間を最小限に抑えることが不可欠です。たとえば、100 Gbps のリンクから 3.2 Tbps の接続にアップグレードすると、1 ペタバイトのデータを転送する時間が 22.2 時間からわずか 0.7 時間に短縮されます。これは、データ待ちによる AI コンピューティングのアイドル時間が 97% 削減されることを意味します。Google の AI ネイティブの Cloud Interconnect は、AI ワークロードの広帯域と低レイテンシのニーズに合わせて専用設計されており、400 Gbps のリンクを備えた最適化されたデータパスが特徴です。このリンクは 3.2 Tbps 単位でスケールアウトし、ペタビット/秒の容量にまで達します。また、トラフィックの差別化に加えて、直接ファイバーピアリングやコロケーション施設などの柔軟な接続オプションも提供しています。AI ネイティブな Cloud Interconnect は、クロスクラウドでの AI トレーニングやサービングに不可欠な、信頼性の高いプライベート接続により、ペタビット規模のデータ転送をサポートします。

3. 推論の時代を支える、復元力のあるグローバルネットワーク

世界中のユーザーに AI 推論を提供するアプリケーションや、エージェント型の企業を支えるアプリケーションは、従来のウェブアプリよりもはるかに高い性能が要求されます。遠隔地にある高価な AI コンピューティングリソースを機動的に活用する必要性や、分散されたサービス間の依存関係、そしてトラフィックのバースト性といった要因により、グローバルフットプリントを持つ広帯域ネットワークに加え、SaaS プロバイダや ISP、ハイパースケーラーとのディープピアリングが求められます。応答性と「常時オン」の可用性を維持するために、アプリケーションには低レイテンシかつ高復元力のネットワークが求められます。

Google のグローバルネットワークは、接続性、スケール、復元力に優れており、AI 推論時代のニーズに応えるための最適な基盤を整えていますGoogle のネットワークは 1,000 万キロメートルを超える陸上および海底の光ファイバー網を網羅し、43 の Cloud リージョンを接続しているほか、200 以上のエッジロケーションを備えています。これらは、AI 推論を提供する上で欠かせない広大なフットプリントとなっています。Google のプレミアムティアネットワークは、一貫した高品質のグローバルユーザーエクスペリエンスに必要な低レイテンシと信頼性を提供します。トラフィックの出入り口を最適化することで、ネットワークはアプリケーションのパフォーマンスを大幅に向上させます。この「常時オン」のインフラストラクチャは、復元力をその中核に備えています。

共に築く未来

Google Cloud のお客様は、これらのネットワークイノベーションを環境に直接組み込むことができます。Google のネットワークは、AI ワークロードに不可欠となる大規模なスケール、キャパシティ、信頼性、そしてパフォーマンスを実現します。

AI 時代には、単なるコンピューティング能力だけでなく、スケーリングのための堅牢なネットワークファブリックが必要になります。シリコンからソフトウェアエコシステムまで、垂直統合された Google AI の技術スタックは、AI Hypercomputer を基盤としており、お客様の変革を加速し、AI をすべての人にとって役立つものにします。メガスケールのファブリック、推論を支える復元力の高いグローバルネットワーク、AI ネイティブな Cloud Interconnect などにより、Google はお客様の AI 活用への道のりを、効率的かつ信頼性の高いものにします。Google は、皆様とともにこの未来を築いていきたいと考えています。

- Google グローバルインフラストラクチャ担当バイスプレジデント、Bikash Koley

- Google Cloud、エンジニアリングフェロー、Arjun Singh

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

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

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

Urban Outfitters、Sterling OMS を AlloyDB for PostgreSQL に移行して大幅な費用削減を実現

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

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

編集者注: Urban Outfitters, Inc.（URBN）は最近、大規模なインフラストラクチャのアップグレードを完了し、既存の IBM Sterling Order Management System（Sterling OMS）の Oracle データベースを Google Cloud の AlloyDB for PostgreSQL に移行しました。Google Cloud と IBM のパートナーシップの拡大を証明するこの戦略的な取り組みは、URBN に大きなメリットをもたらし、効率向上と費用削減を実現したほか、将来を見据えたテクノロジー環境の構築への道を開きました。この成功事例は、企業が AlloyDB for PostgreSQL を活用してデータベースをモダナイズし、新たなレベルのパフォーマンスとスケーラビリティを実現する方法を示しています。

変化の速い小売業界において、注文管理はシームレスなカスタマーエクスペリエンスの基盤となります。Urban Outfitters, Inc.（URBN）は、IBM Sterling Order Management System（Sterling OMS）を同社のグローバルな e コマース事業の中心に据え、注文の受付から、リアルタイムの在庫追跡、納品の最適化、購入後のロジスティクスに至るまで、あらゆる業務をオーケストレートしていました。このシステムは、店舗、倉庫、デジタルチャネルのグローバルネットワーク全体で数百万件のトランザクションを効率的に処理でき、迅速で正確かつ柔軟に注文を処理するという顧客の期待に応えられるものでした。

しかし、この重要なシステムの基盤である 11 TB もの巨大な Oracle データベースが、次第にボトルネックになりつつありました。また、高額なライセンス費用や保守費用、増大する運用上の複雑さ、独自技術による制約が、スケーラビリティと長期的なイノベーションにとって重大な課題となっていました。そのため、Sterling OMS の高可用性、パフォーマンス、トランザクションの整合性を維持するために、以下のような要件を満たす最新のデータベースソリューションが必要になりました。

総所有コスト（TCO）の削減: 信頼性を維持しながら、ライセンス費用、運用上のオーバーヘッド、インフラストラクチャ費用を削減する。
ビジネス継続性の確保: 高可用性、迅速なフェイルオーバー、障害復旧をサポートし、注文処理や顧客取引の中断を防ぐ。
オープンスタンダードの採用: 独自技術から移行し、オープンで柔軟性があり、将来を見据えたソリューションを採用する。
同等の機能の維持: Sterling OMS の機能を損なうことなくシームレスな移行を実現し、すべてのミッションクリティカルな機能をそのまま維持する。

URBN のような小売企業においては、注文管理のわずかな不具合でさえ、財務面や運用面に重大な影響を及ぼす可能性があります。取引の失敗、在庫の予測ミス、納品の遅延は、顧客満足度、ブランドの評判、収益に直接影響します。Sterling OMS はミッションクリティカルなシステムであるため、URBN は技術的に堅牢かつ正確な移行アプローチを必要としていました。そのため、ダウンタイム、データ損失、パフォーマンス低下をほぼゼロに抑えた移行が求められました。

ソリューション: AlloyDB for PostgreSQL

この複雑な移行の成否は、URBN、IBM、Google Cloud による緊密かつ継続的なコラボレーションにかかっていました。このパートナーシップにより、業界をリードする専門知識と最先端の技術が結集し、各チームが全フェーズを通じて綿密に連携して取り組みました。URBN の技術スタッフと IBM と Google Cloud の専任エンジニアが直接連携することで、各チームは大規模なデータベースの移行を綿密に計画し、最適化できました。

このプロジェクトの成功は、以下のような重要な柱によって支えられました。

ファーストティアデータベースの認識と機能開発: IBM と Google Cloud のエンジニアリングチームが協力して、Sterling OMS で AlloyDB for PostgreSQL をファーストティアデータベースとして完全に認識し、サポートできるようにしました。
2 つの読み取りレプリカによるエンタープライズグレードの信頼性: パフォーマンスを向上させ、高可用性とスケーラビリティを実現するために、AlloyDB のデプロイアーキテクチャには 2 つの読み取りレプリカが含まれています。これにより、レポート作成や分析のためのデータへの低レイテンシアクセスが可能になり、Sterling OMS アプリケーション全体のオペレーショナルレジリエンスが向上します。
広範なパフォーマンスチューニング: Google Cloud の専任のパフォーマンスエンジニアリングチームが、URBN と IBM のエキスパートと協力して、データベースクエリの微調整と構成の最適化を行いました。このような継続的かつ高品質なサポートにより、AlloyDB は以前の Oracle データベースのパフォーマンスベンチマークを達成しただけでなく、それを上回る成果を上げることができました。この作業は、AlloyDB 上で Sterling OMS の膨大なトランザクション量を処理する、URBN のような非常に大規模な小売業者にとって不可欠です。
厳格な切り替えテストとリスク軽減: Google Cloud と IBM のチームは、厳格かつ反復的な切り替えテスト戦略で URBN を支援しました。この戦略には、Sterling OMS システムで AlloyDB を丸 1 日稼働させてから Oracle データベースに戻すという作業が含まれていました。このプロアクティブなテストにより、URBN のチームは制御された環境下で潜在的な問題を特定、解決でき、リスクを大幅に軽減するとともに、移行後のシステムに対する信頼性を高めることができました。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud データベースでよりスマートに構築'), ('body', <wagtail.rich_text.RichText object at 0x7f24922405e0>), ('btn_text', ''), ('href', ''), ('image', None)])]>

変革をもたらす転換

AlloyDB への移行により、URBN のデータ戦略は根本的に再構築されました。パフォーマンスや信頼性を損なうことなく、最適化されたストレージとコンピューティングアーキテクチャを通じて、より望ましい TCO を実現しています。さらに、PostgreSQL 互換データベースである AlloyDB への移行により、オープンソースエコシステムの柔軟性を手に入れました。この移行により、ベンダーロックインから解放されるだけでなく、活気のあるコミュニティやさまざまな最新ツールにアクセスできるようになり、長期的な技術的アジリティの確保につながりました。

この移行によって、費用や柔軟性の面だけでなく、優れたパフォーマンスと拡張性が実現し、URBN のミッションクリティカルな業務をサポートできるようになりました。また、最適化されたデータベースカーネルと高精度のクエリ調整を組み合わせることで、大幅な速度向上を実現し、Sterling Commerce システムの応答性を直接的に高めることができました。

成功への道筋: 計画とテスト

URBN が IBM Sterling OMS での AlloyDB への移行を成功させたこの事例は、ミッションクリティカルなインフラストラクチャをモダナイズし、AI の拡張に備えた将来性のある環境を構築しようとする組織にとってのブループリントとなります。組織をまたいだ緊密なパートナーシップと、段階的にリスクを軽減するアプローチの組み合わせは、極めて複雑なミッションクリティカルな移行でさえも実現できることを証明しています。

モダナイゼーションの課題に直面している企業にとって、URBN の事例は成功への明確なロードマップとなります。AlloyDB 上でシステムを実行し、元の環境に戻すという反復的な切り替えテストの実施は、本番稼働に必要な信頼を築くための「秘訣」でした。このレベルの厳格なテストを優先することで、企業はよりアジリティと効率性に優れ、イノベーションに満ちた未来へと進むことができます。

その他の情報

AlloyDB が PostgreSQL の優れた機能と Google Cloud の強みを組み合わせている方法を紹介している最新の電子書籍。
AlloyDB を 30 日間無料で試せる AlloyDB の無料トライアルクラスタ。
AlloyDB for PostgreSQL の詳細。

- Urban Outfitters、CIO、Rob Frieman 氏

- Google Cloud、プロダクト管理、データベース担当バイスプレジデント、Raj Pai

Google Cloud でリソース単位からビジネス単位のメンテナンスへの移行を実現

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

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

定期メンテナンスの管理は、信頼できるビジネスを運営するうえで不可欠です。しかし、クラウドフットプリントが数百、数千のプロジェクトに拡大すると、個々のアップデートをすべて把握するのは大変な作業になります。多くのプラットフォームチームは、作業の分断という現実に直面しています。どのメンテナンスイベントがどのビジネスサービスに影響するかを把握するために、ダッシュボードを切り替える必要があります。

Google Cloud では、ビジネス上の問題を解決しようとするときに、インフラストラクチャの管理について案じるべきではないと考えています。そこで、アプリ単位でメンテナンスイベントを可視化する Unified Maintenance の新機能をリリースすることになりました。

ビジネスに焦点を移す

これまで、メンテナンスの可視化では主にリソースに重点が置かれていました。特定の Compute Engine VM や Cloud SQL インスタンスの更新期限は確認できましたが、それらのリソースが稼働させているアプリケーションとのマッピングは手動で行う必要がありました。

Google Cloud は、アプリ単位での可視化を提供することで、インフラストラクチャレベルのリソースからビジネス指向のビューに焦点を移します。App Hub と直接統合された Unified Maintenance では、アプリケーションのコンテキストでメンテナンスイベントを確認できるようになりました。

仕組み

この新機能では、「アプリケーション」を主要な管理単位として活用します。GKE クラスタ、GCE VM、AlloyDB インスタンスなどのリソースを App Hub に登録すると、Unified Maintenance によってメンテナンススケジュールが自動的に集計され、アプリケーションを認識する単一のダッシュボードに表示されます。

この新機能によってプラットフォームエンジニアは以下のことが可能になります。

トイルの削減: メンテナンスアラートをアプリケーションオーナーに手動でマッピングする必要がなくなります。
トリアージの迅速化: アプリのパフォーマンス低下が、計画されたインフラストラクチャのアップデートと一致するかどうかを即座に確認できます。
予測可能な運用: メンテナンスが環境全体に及ぼす影響をビジネス指向で把握できます。

使ってみる

Google Cloud でアプリケーションをすでに定義している場合は、Google Cloud コンソールで新しいアプリ単位の可視化機能を直接確認できます。アプリケーションの境界の設定とリソースのマッピングについて詳しくは、スタートガイドをご覧ください。

また、サポート対象のサービスのページで新しいサービスのオンボーディングをご確認ください。

- Google Cloud、プロダクトマネージャー、Erol-Valeriu Chioasca

Google I/O 2026 のスタートアップ向けの主な発表

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

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

世界で特に急成長を遂げている AI スタートアップの多くが、その完全かつオープンな AI スタックを理由に、自社の未来、そして世界の未来を構築する場所として Google Cloud を選択しています。アーキテクチャのあらゆるレイヤに AI を組み込んでいる Google Cloud は、エージェントの時代に求められる構築とスケーリングの機能を提供します。

Google Cloud Next ‘26 では、小規模なチームの作業をより速く効率的にするためにスタックの各レイヤに導入された新機能が重点的に紹介されました。Google は、個別の AI ツールを組み合わせる段階からさらに一歩進んでエージェントのライフサイクル全体を支えるプラットフォームへ進化した統合 Agent Platform と、トレーニングと推論の両方に最適化された新世代の TPU を導入しました。これに加えて、世界初の Agentic Data Cloud（人間に合わせたスケールからエージェントのスケールへの移行に対応するよう設計されたシステム）と、AI を活用したサイバーセキュリティプラットフォームのアップデートも提供されます。このプラットフォームは、Google の脅威インテリジェンスとセキュリティ運用を Wiz のクラウド＆ AI Security プラットフォームと組み合わせることで、エージェントの時代における脅威の防止、検出、対応を実現します。

世界中の多様なスタートアップが、すでにこのスタックを実用化しています。たとえば、Photoroom は、高度に最適化された Google のコンピューティングを利用して、1 分あたり 1,000 枚以上の画像を処理しています。企業の顧客エンゲージメントの分野では、Satisfi Labs が Gemini、BigQuery、AlloyDB を活用して、スポーツ、エンターテイメント、観光業界の 800 社の顧客にインテリジェントなインタラクションとリアルタイムの分析情報を提供しています。一方、グローバルコラボレーションプラットフォームの Notion は、業界の先駆けとなって生産性向上ツールへの AI の統合を進めています。また、Mantis AI は、高スループットの推論パイプラインを運用して、主要な放送局に動画ネイティブのインテリジェンスを提供しています。

Google I/O 2026 では、より費用対効果の高いフロンティアモデルを導入し、これらのエージェント機能を開発ワークフローに直接組み込むことで、この基盤をさらに発展させることを発表しました。ローカルでのプロトタイピングとクラウド規模のギャップを埋め、アプリケーションの構築、テスト、配布をチームが簡単に行えるようにします。

Google I/O で発表されたスタートアップ向けの重要な発表と、それらをビジネスに適用する方法を見てみましょう。

1. よりスマートで高速なモデル

依然として多くのスタートアップがモデルを基盤として Google Cloud 上で構築を行っているため、進化したモデルを提供できることを嬉しく思います。この新世代のモデルは、驚異的な効率で最大限のインテリジェンスを提供します。

Gemini 3.5 Flash は、Flash ならではの高速性を維持しつつ、大規模なフラッグシップモデルに匹敵するインテリジェンスを提供します。Google 史上最も強力なエージェント型モデルであり、コーディングモデルでもあります。長期的なエージェント型タスクに取り組むのに最適で、通常、同等のモデルの半額以下の費用で利用可能です。
Gemini 3.5 Pro（事前発表）: Google のフラッグシップ推論モデルが来月正式にリリースされることを発表いたしました。
Gemini Omni は、テキスト、音声、画像、動画の入力を統合して動的な動画コンテンツを生成する画期的な新モデルです。Gemini Omni は、動画の作成と編集に非常に直感的なアプローチを提供します。e コマース向けのインタラクティブなバーチャル試着サービスの開発や複雑なポストプロダクションワークフローの合理化、あるいはカスタマイズされた動画ナラティブの生成など、どのような場合でも、Gemini Omni はコンテンツ作成と顧客エンゲージメントの深化に新たな方法を提示します。

スタートアップにとっての意味: DeepMind の最先端モデルを使用して直接構築できるようになりました。Google は AI の可能性を広げ続けています。新しいフロンティアを開拓すると同時に、スタートアップが拡大するために必要なスピードとコスト効率を提供します。

3.5 Flash は、Artificial Analysis 指標の右上象限に位置し、最先端レベルのインテリジェンスを驚異的なスピードで提供します。品質とレイテンシのトレードオフは不要になります。

2. ユーザーに寄り添う AI

Next ‘26 では、脅威ハンティングの SecOps エージェントやモジュール式のデータエージェントから、構成ミスを自律的に修正する自律型クラウドインフラストラクチャまで、スタックのあらゆるレイヤで煩雑な作業を処理する専用のエージェントが紹介されました。

しかし、この大規模で専門的なエージェントが能力を発揮するには、コーディネーターが必要です。Google Antigravity は、究極のコントロールプレーンです。これらの新しいアップデートにより、アプリケーションの構築、デプロイ、管理の方法が大きく変わります。

Antigravity 2.0: Mac、Windows、Linux 向けの専用のスタンドアロンデスクトップアプリケーションです。従来のコードエディタ（IDE）に縛られることなく、複雑な AI ワークフローを構築、テスト、オーケストレートするための「エージェントファースト」のワークスペースとして機能します。
Antigravity CLI と SDK: キーボードから離れたくないデベロッパーのために、スタックに依存しない超高速のコマンドラインインターフェースが用意されています。エージェントのシームレスな実行とモニタリングを可能にします。また、Python SDK で Google の内部エージェントインフラストラクチャを利用し、安定したエージェントループをプログラムでコーディングして制御することが可能です。
動的なサブエージェント: 特定のサブタスクを処理するための小規模で専門的な子エージェントを親 AI エージェントが自動で生成できるようになります。これにより、エンジニアリングの並列処理が大幅に向上します。たとえば、メインのローカルエージェントがデータベースクエリを Cloud Data Agent に委任したり、ローカルのコードレビューサブエージェントをスピンアップしたりできます。これらすべてが、メインのメモリスペースを占有することなく行われます。
タスクのスケジューリング: バックグラウンドタイマーと cron スケジュールを設定することで、手動のメンテナンス作業が不要になります。クラウドベースのオブザーバビリティエージェントをトリガーしたり、毎晩午前 0 時にローカルリポジトリの健全性チェックを実行したりする処理を Antigravity に指示して完全に自律的に実行させることができます。
エンタープライズグレードのセキュリティ: Antigravity は、ローカルのデスクトップとターミナルのエージェントループを、ユーザーのプライベート Google Cloud プロジェクトに直接接続します。Google Cloud の標準的なデータプライバシー保護と利用規約を継承することで、顧客データを組織の管理下に置き、デフォルトで安全なクラウド境界内でエージェントアクティビティを実行できるようになります。

スタートアップにとっての意味: コーディングアシスタントだけでなく、専門の AI エンジニアのチーム全体をすぐに利用できるようになります。Next でリリースされた専用のクラウドエージェントと Antigravity コントロールプレーンを組み合わせることで、小規模なチームでも、データパイプラインのオーケストレーション、セキュリティの管理、大規模な並列コーディングタスクの実行を、すべて 1 つの安全な環境から行うことができます。

Antigravity 2.0 は、エージェント主導の同時実行をデプロイできます。上の画像では、ウェブサイトの自動コード生成、ブランドに合ったアセットの作成、パーソナライズされた顧客向けメールの作成が例として示されています。シーケンスは一部省略されています。

3. 開発を加速するその他の方法

デベロッパーのワークフローを合理化し、プロンプトからプロダクションレディなアプリケーションへの移行をスムーズに実現できるようにします。今年のアップデートでは、これまで作業の遅延要因となっていたインフラストラクチャのセットアップを省略することに重点を置いています。

AI Studio でのネイティブ Android のサポート: 完全にネイティブな Android アプリを自然言語プロンプトを使ってブラウザ内で直接作成できるようになりました。これには Google Play Console のサポートが含まれており、デベロッパーはローカル SDK 環境を管理することなく、テストトラックにアプリを直接公開できます。
シームレスなハンドオフ: 新しいインテグレーションにより、Google AI Studio のプロジェクト全体をワンクリックでローカルの Antigravity 環境に直接エクスポートできます。これにより、コードベース、ファイル、会話のコンテキストがすべて転送されるため、ウェブプロトタイピングからローカル開発に移行しても、作業を中断したところから再開できます。
マネージドエージェント: 本番環境グレードのエージェントを構築するのに必要な複雑なインフラストラクチャの管理からリーンスタートアップチームを解放します。Gemini API と Google Cloud の Agent Platform の両方で利用できる新しい Managed Agents API は、Agent as a Service として機能するため、「マシンではなくミッションを管理」することができます。指示とツールを定義するだけで、1 回の API 呼び出しで、安全な短命性 Google Cloud サンドボックス内にエージェントをスピンアップできます。これにより、チームはバックエンドのメンテナンスという煩雑な作業から解放され、優れたエージェントエクスペリエンスの構築に専念できます。

スタートアップにとっての意味: プロトタイプから本番環境への簡単なパスを提供します。ブラウザでアプリのコンセプトを迅速にテストし、ローカルワークスペースに移動して詳細なオーケストレーションを行い、マネージドクラウドインフラストラクチャを使用してユーザー向けエージェントをデプロイできます。これにより、エンジニアリングチームは数週間にわたるセットアップとメンテナンスの時間を節約できます。

4. 個人の生産性を向上

Google は、エンジニアによるプロダクト開発の加速を推進する一方で、会社の運営に伴う日々の雑務を管理する創業者や経営者を支援したいとも考えています。

この課題を解決するために、Google は Gemini Spark を導入します。Gemini Spark は、Google Workspace やその他の日常的なツール全体でバックグラウンドで動作する、新しい 24 時間 365 日対応のパーソナル AI エージェントです。単に質問に答えるだけでなく、マルチステップのワークフローを自律的に実行できます。

たとえば、Spark は、重要な製品の遅延を特定し、チームのドキュメントを相互参照してタイムラインを再計算し、内部のトラッキングシートを更新し、投資家に最新状況を伝えるメールの下書きを作成できます。これらすべては、ユーザーの明示的な承認を待って実行されます。

スタートアップにとっての意味: Antigravity がプロダクトを構築する一方、Spark はデジタル参謀のような役割として機能します。Spark が日常的な手動の運用プロセスを処理するため、経営者は影響力の大きい戦略的なイノベーションに集中できます。

今すぐ構築を開始: Google for Startups AI Agents Challenge

世界中の対象スタートアップの創業者とデベロッパーが参加できるこのコンペティションでは、チームごとに 500 ドル分のクラウドクレジットと、新しい Agent Platform へのアクセスが提供されます。参加者は、自律型エージェントを構築しながら、総額 90,000 ドルの賞金獲得を目指して競い合います。

また、参加者それぞれの現在のフェーズに合わせて、複数のトラックをご用意しています。まったく新しいエージェントをゼロから構築したい場合でも、既存のプロトタイプを本番環境向けに最適化したい場合でも、あるいはエンタープライズ向け展開を見据えたビジネス対応のエージェントを仕上げたい場合でも、それぞれに適したトラックを選択できます。応募締切は 2026 年 6 月 5 日です。審査では、技術実装、ビジネスケース、革新性、最終デモをもとに評価が行われます。詳細の確認とお申し込みは、こちらからお願いします。

- Google、グローバルスタートアップおよび投資家エコシステム担当バイスプレジデント、Darren Mowry

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

エージェント型開発の未来: Data Agent Kit でデータ実務担当者のライフサイクルを再定義

Sun, 31 May 2026 16:00:00 +0000

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

現代のソフトウェア開発は、単一の場所で完結するものではなく、エージェント型ツールのエコシステム全体に広がっています。エージェントはかつてない規模で開発されており、コンテキストとグラウンディングのために、企業データに直接アクセスする必要があります。

しかし、エージェントの構築やデータ管理に使用される現在のツールは大きく断片化されています。そのため、データへのアクセスが難しくなり、セキュリティリスクが高まるだけでなく、開発者体験が損なわれ、イノベーションの妨げになる可能性があります。

この課題に対処するため、Google は最近、Data Agent Kit をリリースしました。これは、データエンジニアリングとデータサイエンスのスキル、ツール、プラグインをまとめた統合型のオープンソースコレクションです。VS Code、Claude Code、Codex、Gemini CLI、Antigravity CLI など、実務担当者がすでに使用している環境に直接統合できます。こうした中核的なツールやスキルを企業データとシームレスに結び付けることで、Data Agent Kit は、エージェントに必要なコンテキスト、メモリ、パーソナライズを支える包括的な基盤として機能します。Data Agent Kit には、以下が含まれます。

エージェント型スキル: クエリ最適化、ML のベストプラクティス、データ検証、データドリフトチェック、ガバナンス、トラブルシューティングなど、データ資産とやり取りするためのあらかじめコード化された手順。
Model Context Protocol（MCP）ツール: エージェント型ワークフローと、BigQuery、AlloyDB、Google Cloud Storage などのクラウドデータプラットフォームを安全に接続するツール。デベロッパーは、複雑な手動のパイプラインコードを管理しなくても、クラウドデータセットやデータ処理エンジンの接続パラメータを構成できるようになります。
プラグインと拡張機能: コンテキストを踏まえた高度な開発者体験を可能にするネイティブ IDE 統合。

これらの Data Agent Kit の機能を組み合わせることで、データ実務担当者は、手作業でコードを記述する従来の作業から、インテントドリブンなデータサイエンスとエンジニアリングへと移行できます。つまり、実現したいビジネス成果、制約、成功基準を定義すれば、AI で強化されたシステムがその実行方法を判断できるようになります。この変化は非常に重要です。現在、複雑なデータアーキテクチャを扱うエージェント型アプリケーションを構築する際には、多くの場合「コンテキストウィンドウ税」とも言える負担が発生します。つまり、デベロッパーは膨大な量のスキーマメタデータを手作業でプロンプトに貼り付ける必要があり、トークン上限を消費し、レイテンシも増加します。一方で、データ実務担当者は、クラウドデータを効率的にクエリ、最適化、トラブルシューティングする方法について十分なガイダンスを得られないことが多く、専門化され断片化した開発環境では、データ資産全体を見渡すことができません。Data Agent Kit は、こうした課題をはじめとするさまざまな問題に対応し、データ実務担当者が新しいエージェント型の働き方に移行するために必要な基盤機能を提供します。

Data Agent Kit の機能とメリット、インストール方法、ローカル環境をデータ資産に接続する方法、インテントドリブンエンジニアリングの例について、以下で詳しく説明します。

データ資産とライフサイクルを統合するハブ

Data Agent Kit を使用すると、データ資産全体を 1 つのビューで利用できるようになります。これは、BigQuery、AlloyDB、Spanner などのデータベース向けに単純なカタログを提供するだけのものではありません。データエンジニアリングとデータサイエンスのタスク、オーケストレーションパイプライン、ジョブを単一のインターフェースに統合します。これにより、実務担当者は、検出から本番環境への移行まで、データワークフロー全体をコンテキストを切り替えることなく管理できます。Data Agent Kit のインテリジェントなルーティングは、タスクに最適なコンピューティングエンジンを自動的に選択します。たとえば、SQL ネイティブな分析や ELT には BigQuery、カスタムの Python 変換や分散 ML トレーニングには Spark を選択できます。

データ資産とライフサイクルを統合するハブ

エコシステム主導のインテリジェンス: 体系化されたエージェント型スキル

Data Agent Kit は、Google Cloud のデータエンジニアリングとデータサイエンスの専門知識に基づき、事前定義されたエージェント型スキル（ML のベストプラクティス、ELT、データアプリの構築など）のライブラリを提供します。汎用的な LLM プロンプトに頼るのではなく、規範的なガイドラインをワークフローに組み込みます。これにより、エンタープライズグレードのデータインテリジェンスを IDE や CLI に直接取り込むことができます。

事前定義されたデータエンジニアリングおよびデータサイエンスのエージェント型スキル一覧を確認する

自然言語によるデータ探索の変革

Data Agent Kit は、この統合されたデータを基盤として、ワークスペース内でネイティブの会話型分析を直接提供し、データを簡単に探索できるようにします。Conversational BigQuery や Looker などのファーストパーティエージェントにも採用されている Gemini の自然言語から SQL への変換技術を活用することで、自然言語クエリを実行し、データセットのプロファイリング、検索、可視化を行うことができます。

Data Agent Kit では、会話型分析を使用してデータを探索できます。

実践的なチュートリアル: データの統合とモデルの構築

Data Agent Kit のスキルと MCP ツールがどのように連携するのかを確認するために、金融サービスのシナリオを考えてみましょう。ある企業で不正請求が増加しているとします。Cloud Storage に保存されたトランザクションデータを使用して、信頼性の高い不正検出モデルを構築し、オーケストレーションパイプラインをスケジュールする必要があります。従来であれば、複数のコンソールをまたいで何時間もデータラングリングを行う必要がありました。Data Agent Kit を使用すれば、この作業を IDE や CLI 内で直接、数分で完了できます。では、その方法を見ていきましょう。

オンボーディング: 1 分でセットアップ

統合されたセットアッププロセスにより、Data Agent Kit は 1 分以内に使い始めることができます。

IDE のマーケットプレイス（VS Code）で「Google Cloud Data Agent Kit」を検索するか、後述の「使ってみる」セクションにあるリンクから CLI（Gemini、Antigravity、Claude、Codex）向けの GitHub リポジトリにアクセスします。Data Agent Kit は依存関係を自動的に構成し、Google Cloud へのログインステータスを確認します。

アクティビティバーの Google Cloud アイコンをクリックし、IAM 経由で認証します。ログインすると、Cloud Storage、データベース、カタログアセットがワークスペースにすぐに表示されます。

設定メニューを使用してプロジェクト ID とリージョンを設定し、MCP のステータスを確認して、すべてのバックエンドサービスに必要な権限が付与されていることを確認します。Data Agent Kit には、ツールとスキルの使用方法を説明するクイックスタートガイドも含まれています。

インテントドリブンなデータエンジニアリングの例

Data Agent Kit をインストールすると、手動による ETL の定型作業を省き、コーディングアシスタント（Claude Code、GitHub Copilot など）に自然言語で大まかな目標を直接伝えることができます。アシスタントは Data Agent Kit のスキルを活用して、ワークフローを計画し、実行します。

プロンプト:

未加工のトランザクションログが GCS バケット gs://fin-clearing-raw/ に保存されています。

まず、Spark ノートブックを作成し、（1）これらのログを BigQuery の Iceberg テーブルに取り込みます。

次に、dbt プロジェクトを作成して、（2）重複を除去し、（3）無効なトランザクション ID を持つトランザクションを削除して別の Iceberg テーブルに保存し、（4）タイムスタンプを標準化して、その他の必要なクリーンアップタスクを実行し、（5）出力を別の Iceberg テーブルに同期し、（6）この出力テーブルを、支払い者と受取人の ID を含むテーブルと結合して、最終的な Iceberg テーブルに書き込みます。

3 つ目として、ノートブックを使用して Spark で ML モデルをトレーニングし、出力テーブル内の不正なトランザクションを検出したいと考えています。LightGBM モデルを検討していますが、他に提案があればそれも検討します。プロジェクト内の関連データセットを使用してください。

最後に、上述のパイプラインに Spark ノートブックを使用した推論ステップを作成し、バッチ推論を実行して、フラグが付けられたトランザクションを Spanner テーブルに書き込んでください。

まず取り込みを実行し、次に dbt、最後に推論ノートブックを実行するオーケストレーションパイプラインを作成してください。

内部の仕組み: データパイプラインの手順

Data Agent Kit は、探索から推論まで、データライフサイクル全体にわたる堅牢な複数ステップのオーケストレーションを背後で計画します。

ステップ 1: ノートブックの作成、取り込み、初期保存

ブロンズデータ、つまり金融取引に関する未加工でフィルタされていないデータを見つけ、変換を行う前に Iceberg テーブルに取り込みます。

Cloud Storage から未加工のログを取り込むためのノートブックを自動的に作成します。
必要な SQL を記述し、取り込んだデータを BigQuery の Iceberg テーブルに保存します。

Ingestion into a bronze table

ステップ 2: 変換（dbt プロジェクト）

次に、ブロンズデータをクリーニングし、シルバーテーブルとゴールドテーブルに変換します。

データの準備: トランザクションログの重複を除去します。
無効な ID のフィルタリング: 無効な ID を持つトランザクションを特定し、別の Iceberg テーブルに保存します。
クリーンアップと標準化: タイムスタンプを標準化し、その他の必要なクリーンアップタスクを実行します。
同期: BigQuery MCP サーバーを活用して、クリーニング済みのデータを別の Iceberg テーブルに出力します。
エンリッチメント: クリーニング済みのテーブルを、支払い者と受取人の ID 情報を含むテーブルと結合します。
最終出力: 結合したデータセットを最終的な Iceberg テーブルに書き込みます。

シルバーテーブルとゴールドテーブルを作成するためのデータ変換

ステップ 3: ML と推論

ゴールドテーブルができあがったら、次はデータサイエンス、つまりモデルのトレーニングと推論に進みます。ここでは、エージェントが前のステップでクリーンアップしたデータをモデルに渡し、不正のパターンを検出します。

トレーニング: Spark ノートブックを使用して ML モデルをトレーニングします。
推論: バッチ処理用の Spark ノートブック推論ステップを作成します。
保存: Spanner MCP を活用して、フラグが付けられた不正なトランザクションをすべて Spanner テーブルに書き込みます。

ML と推論

ステップ 4: オーケストレーションと実行

最後に、本番環境への移行に向けて、取り込み → 変換 → 推論というオーケストレーションパイプライン全体をスケジュールします。

オーケストレーションパイプラインと実行スケジュール

予期せぬ問題が発生した場合: エージェント型インシデント管理とインテリジェントな復旧

オーケストレーションパイプラインが失敗しても心配はいりません。Data Agent Kit は、インテリジェントなインシデント管理機能を使用して、解決までのプロセスを効率化します。

インテリジェントな診断: 根本原因分析を自動的に実施し、障害の発生源を特定します。
自律的な修復: 手動デバッグを介さずに、修正案を作成してテストします。
自動復旧: 自動化された Git ワークフローを通じて修正を検証し、デプロイします。

問題の診断と修復

これで、元データの探索から、完全に自動化された不正検出の仕組みの構築まで、同じ UX 内でわずか数分のうちに完了できます。複数のブラウザタブや IDE インターフェースを行き来したり、データエンジニアリングやデータサイエンスのベストプラクティスを一から学んだりする必要はありません。Data Agent Kit は、さまざまな MCP ツールと体系化されたスキルを活用し、クリーンなエンドツーエンドのフローをオーケストレートします。最終的に、このアプローチにより、最も重要なこと、つまり革新的で高性能なデータアプリケーションを大規模に提供することに集中できます。

使ってみる

Data Agent Kit は、このたびプレビュー版の提供を開始いたしました。まずは、お好みの IDE または CLI にインストールしてください。

詳細を確認して使い始めるには、ドキュメントをご覧ください。

- データクラウド担当グループプロダクトマネージャー、Brahm Kohli

- データクラウド担当エンジニアリングディレクター、Dinesh Chandnani

Google、Gartner® Magic Quadrant™ の AI アプリケーション開発プラットフォーム部門でリーダーに選出: 中間報告

Fri, 29 May 2026 03:15:00 +0000

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

2026 年 5 月の更新: この投稿は、レポートが初公開された昨年 11 月から半年後の時点での Google のポジショニングとプラットフォームの進化を反映して更新されました。

昨年秋、Google は Gartner® Magic Quadrant™ の AI アプリケーション開発プラットフォーム部門でリーダーに選出され、実行能力については評価対象となった全ベンダーの中で最高評価を獲得しました。

先週公開された中間報告では、Google がその勢いを維持していることが示されています。今回の報告で、Google はリーダーに選出され、実行能力において最も高い評価を獲得しました。また、関連する Critical Capabilities レポートでは、評価された 3 つのユースケースすべてでランキング 1 位を獲得しました。

昨年 11 月以降、プラットフォーム自体を含め、多くの変化がありました。Google Cloud Next ‘26 で、Google は Vertex AI のコア機能を Google DeepMind と Google Cloud の画期的な新技術と統合し、Gemini Enterprise として提供することを発表しました。その結果誕生したのが Gemini Enterprise Agent Platform です。これは、プロダクションレディなエージェントの構築、スケーリング、ガバナンス、最適化を支援する統合されたプラットフォームです。

以下では、Gartner レポートからも読み取れる、Google のエージェントプラットフォーム戦略の指針となる 3 つの原則を紹介します。

後付けではなく、デフォルトでガバナンスを適用

通常、ガバナンスを後から追加するものとして扱うと、過度な制限でイノベーションを妨げるか、一貫性のない手動チェックで組織を危険にさらすかという、いずれかの極端な結果になってしまいます。

Agent Platform では、エージェントのライフサイクル全体を管理するための統合された信頼フレームワークを提供します。これにより、すべてのエージェントが検証可能な ID を持ち、無秩序に乱立しないよう中央レジストリにインベントリとして登録されるほか、すべてのリクエストがセキュアゲートウェイを介してルーティングされるようになります。

これらの制御を Model Armor のリアルタイム保護や最近買収した Wiz の技術と統合することで、コード、クラウド、ランタイムを単一の共有コンテキストに接続させます。これにより、チームが環境全体のリスクを特定して修正できるようにします。

L’Oréal にとって、このアーキテクチャは、スクリプトによる自動化から自律型エージェントのオーケストレーションへの抜本的変化を可能にするものです。

「Google Cloud は、人間による監視を中核に据えつつ、（当社の Beauty Tech Data Platform を）グローバルにスケールするために必要なレジリエンス、マルチ LLM の柔軟性、エンタープライズグレードの信頼フレームワークを提供してくれます。」– L'Oréal、グループ CIO、Etienne Bertin 氏

長時間実行タスクの永続性

Chatbot と真のエージェントの違いは、タスクを最後までやり遂げる能力の有無です。エージェントが実際の成果を上げるには、ユーザーの同僚のように機能する必要があります。つまり、数日間にわたってコンテキストを維持し、複数のステップからなるプロセスを実行する能力が求められます。

Google は、Agent Runtime を再設計し、セッションをまたいでコンテキストを永続的に保持するメモリバンクを利用して、エージェントが数日間アクティブな状態を維持できるようにしました。これにより、人間の常時介入がない状況でも、エージェントは長時間にわたるビジネスプロセスを管理できます。

Payhawk では、このインフラストラクチャによってエージェントがビジネスに貢献できる範囲が根本的に変わりました。

「Payhawk は Gemini Enterprise Agent Platform を使用して、AI エージェントを単純なタスク実行者から真の財務アシスタントに変革しています。当社のエージェントは専任のチームメンバーのように行動し、ユーザー固有の制約や履歴を自律的に呼び出すようになりました。」- Payhawk、プリンシパル応用 AI エンジニア、Diyan Bogdanov 氏

予測可能な成果の可視化

非決定論的な世界では、エージェントが何をしたかを知るだけでは、全体像の半分しかわかりません。運用上の成果は、エージェントがそのように行動した理由を把握し、エージェントのパフォーマンスが低下し始めたときにユーザーに影響が及ぶ前にそれを検知するツールを持つことから生まれます。

Google は、AI エージェントのユースケースに関する Critical Capabilities レポートで最高スコアを獲得しました。これは、エージェントの推論をチームが深く把握できるようにするという Google の取り組みが正しかったことを裏付けるものです。Agent Platform でエージェントシミュレーションと軌跡評価を行うことで、組織は当て推量から脱却し、エージェントが実際のインタラクションで期待どおりに動作することを確認できます。

Burns & McDonnell の場合、この可視性を利用して、エージェントの創造的な推論を特定のビジネスルールでグラウンディングしています。

「Agent Platform は、決定論的なビジネスルールと確率的推論を組み合わせることで、このイノベーションを責任を持ってスケールできるようにします。これにより、AI は単なる生産性向上ツールではなく、信頼できる運用機能となります。Agent Platform を活用することで、知識を管理するだけでなく、経験を活かして、より迅速かつ的確な意思決定を促進しています。」- Burns & McDonnell、最高イノベーション責任者、Matt Olson 氏

オープンなエージェントエコノミーに対する Google の取り組み

プラットフォームは進化しましたが、選択肢、柔軟性、アクセシビリティに関する Google の基本的な理念は変わっていません。Model Garden では、Gemini 3.1、Gemma 4、Anthropic の Claude などのサードパーティの主要モデルを含む、200 を超える最高水準のモデルを継続して提供しています。

Google は、幅広いモデルを提供するだけでなく、オープンソースコミュニティと、より広範なエージェントエコノミーの相互運用性に対する投資も行っています。Google が提供するオープンソースの Agent Development Kit（ADK）は、オープンに構築するために必要なコアツールを開発者に提供します。プラットフォーム間のコラボレーションをさらに標準化するために、Google は Agent2Agent プロトコル（A2A）を Linux Foundation に寄贈し、Agent Payments Protocol（AP2）を FIDO Alliance に正式に寄贈しました。

また、Model Context Protocol（MCP）を基盤となる標準として採用し、エージェントを Google Cloud エコシステムに安全に接続させるために利用できる Google マネージド MCP サーバーを 50 個以上提供しています。これらは、安全でベンダーに依存しないエージェントトランザクションの実現に向けた長期的な取り組みです。

Google Cloud は、スタックに関係なく、あらゆるビジネスに役立つエージェントエコノミーの標準を構築しています。

2026 年 Gartner Magic Quadrant の更新版を無料でダウンロードするには、こちらをクリックしてください。

^{Gartner® Magic Quadrant™ AI アプリケーション開発プラットフォーム部門: 中間報告 - Cary Pillers、Mike Fang、Steve Deng、Jim Scheibmeir、2026 年 4 月 27 日}

^{Gartner® Critical Capabilities™ AI アプリケーション開発プラットフォーム部門: 中間報告 - Jim Scheibmeir、Cary Pillers、Steve Deng、Mike Fang、2026 年 4 月 28 日}

^{Gartner は、リサーチに関する発行物に掲載されている特定のベンダー、製品、サービスを推奨するものではありません。また、最高の格付けまたはその他の評価を得たベンダーのみを選択するように助言するものでもありません。Gartner のリサーチに関する発行物は、Gartner のリサーチ組織の見解を表したものであり、事実を表現したものではありません。Gartner は、明示または黙示を問わず、本リサーチの商品性や特定の目的への適合性を含め、いかなる保証も行いません。上の図は、リサーチドキュメントの一部として Gartner, Inc. より公開されているもので、ドキュメント全体の文脈に即して評価する必要があります。この Gartner のドキュメントをご希望の方は、Google にご請求ください。}

- Gemini Enterprise Agent Platform 担当ディレクター、Mike Clark

Cloud Blog JA

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

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

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

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

フェーズ 4 の最適化

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

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

準備ができたら

没入感のある 3D エクスペリエンスと詳細な場所情報で地図を変革

ブランドの魅力を生き生きと伝える没入感のある UX

ユーザー ジャーニーのあらゆる段階で一貫したエクスペリエンスを提供

直感的でカスタマイズ可能な UI と、ユーザーが信頼できる詳細なデータ

最新機能はすぐに利用可能

新しいシェイプファイルと 3D モデルのインポート機能で Google Earth により多くのデータを取り込む

シェイプファイルと 3D モデルが Google Earth に登場

現実世界のキャンバスにデータを表示

シェイプファイルを追加して全体像を把握

現実世界のコンテキストで 3D モデルを活用

高度プロファイルを可視化

新しい Google Earth Discord チャンネルで他のユーザーと交流

「Google for Startups Accelerator: 中東、北アフリカ、トルコ」に新たに選出された企業の紹介

最新の「Google for Startups Accelerator: 中東、北アフリカ、トルコ」のコホートの紹介

成果を上げるためのカリキュラム

MENA-T の成長に向けた Google の取り組み

事後対応からレジリエンスへ: 高度な環境インテリジェンスで業界を支援

天気に関するインサイト

大気質と花粉に関するインサイト

TPU 上で兆単位のパラメータを扱うモデルのクラスタレベルの信頼性

AI スーパーコンピュータの信頼性

詳細: 大規模な可用性の計算

最新の AI ハードウェアの規模

ML の生産性向上

次世代の AI ブレークスルーを実現

一般提供が開始された Nano Banana 2 と Nano Banana Pro がクリエイティブなワークフローを強化

Nano Banana モデルを活用したイノベーションの例

クリエイティブとマーケティングのイノベーションの促進

小売と顧客対応の変革

次世代のメディア制作ワークフローの構築

エンタープライズ グレードのマルチモーダル エクスペリエンスの構築を開始する

【Next Tokyo セッション公開】ドラクエ・イオン・日テレが登壇！AI 変革のリアルを学ぶ注目セッション

セッション公開！AI 変革のリアルを学ぶ注目セッション

注目のブレイクアウト セッション

最新調査: IT リーダーにとってブラウザでの AI セキュリティ確保が最優先事項に

Cloud Run、Firebase、Cloud SQL を使用したフルスタックのバイブ コーディングが AI Studio で可能に（クレジット カードは不要）

手軽に導入: Google Cloud スターター ティア

Cloud SQL でフルスタックのバイブ コーディングを強化

Firestore と Firebase Auth を使用したフルスタックのバイブ コーディング

AI Studio を使ってみる

Next ‘26 でのストリーミング AI に関する発表

インサイトから自律的アクションへと進化

新しいストリーミング AI 機能

AI 時代に向けた Google のグローバルおよびデータセンター ネットワークの進化

1. AI Hypercomputer 内のファブリック

自律的な信頼性: ワークロードのグッドプットを保護する

2. AI Hypercomputer 間のファブリック

3. 推論の時代を支える、復元力のあるグローバル ネットワーク

共に築く未来

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 - プロアクティブなデスクトップ コンパニオン

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

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

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

ユーザージャーニーのあらゆる段階で一貫したエクスペリエンスを提供

エンタープライズグレードのマルチモーダルエクスペリエンスの構築を開始する

セッション公開！
AI 変革のリアルを学ぶ注目セッション

注目のブレイクアウトセッション

Cloud Run、Firebase、Cloud SQL を使用したフルスタックのバイブコーディングが AI Studio で可能に（クレジットカードは不要）

手軽に導入: Google Cloud スターターティア

Cloud SQL でフルスタックのバイブコーディングを強化

Firestore と Firebase Auth を使用したフルスタックのバイブコーディング

AI 時代に向けた Google のグローバルおよびデータセンターネットワークの進化

3. 推論の時代を支える、復元力のあるグローバルネットワーク

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

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

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

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

インテントドリブンなデータエンジニアリングの例

内部の仕組み: データパイプラインの手順