AI インフラストラクチャ

Google、「The Forrester Wave™: Public Cloud Platforms, Q3 2026」でリーダーに選出

Fri, 18 Sep 2026 02:50:00 +0000

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

このたび、「Forrester Wave™: Public Cloud Platforms, Q3 2026」レポートにおいて、Google Cloud がリーダーに選出され、「現在のサービス」カテゴリで最高スコアを獲得しました。このレポートは、30 項目の包括的な基準に基づいて、最も重要なパブリッククラウドプロバイダ 10 社を評価したものです。また Google は、ビジョン、イノベーション、AI 開発サービス、データベースサービス、分析サービス、コンテナおよび Kubernetes サービス、モダナイゼーションサービス、セキュリティサービスなど、30 項目の評価基準のうち 23 項目で最高スコアを獲得しました。Forrester による今回の評価は、エージェントの時代をリードするには、シリコンからシステム、モデルに至るまで、ゼロから設計された完全な統合プラットフォームが必要であるという Google の信念を裏付けるものだと考えています。

無料レポート The Forrester Wave™: Public Cloud Platforms, Q3 2026 をご覧ください。

グローバル企業で実績のある共同設計インフラストラクチャを基盤に構築

10 年以上にわたり、Google のインフラストラクチャエンジニア、アプリケーションデベロッパー、AI 研究者は肩を並べて、Gemini、検索、YouTube、マップ、Gmail を支えるインフラストラクチャを共同設計してきました。必要なプラットフォームとインフラストラクチャを単純に購入することはできず、自社での開発が必要でした。その結果、TPU から、Transformer アーキテクチャ、Kubernetes、Axion、そして Gemini に至るまで、あらゆるものが生み出されました。

エージェントの時代には、最前線で AI 研究に取り組んでいなくても、コンピューティング、オーケストレーションソフトウェア、モダナイゼーションツール、グローバルネットワークが連携して、投資からより多くの価値を引き出す統合 AI スタックが必要です。Google Cloud は、大手企業、スタートアップ、最先端の研究機関にこうした画期的なイノベーションをもたらし、新たなレベルの規模と効率性を実現できるよう、たゆまぬ努力を続けてきました。Forrester の評価は、その戦略が正しいことを証明するものだと考えています。

「Google Cloud のビジョンは『エージェント型エンタープライズ』を実現することです。AI はすでにそのプラットフォームに浸透しており、同社は、企業における AI 導入をますます形作っているビジネスユーザー向けに、技術スタックをさらに拡張する立場にあります。Google Cloud は、迅速な技術革新と、AI を活用した幅広いクラウドプラットフォームを求める企業に最適です。」-「The Forrester Wave™: Public Cloud Platforms, Q3 2026」レポート

セキュアで柔軟なプラットフォームでエージェントを迅速に実行

従来のインフラストラクチャのほとんどは、エージェントの進化についていけないため、企業はスケーラブルな代替インフラストラクチャを必要としています。しかし、AI エージェントのためだけに新しいグリーンフィールドプラットフォームを導入することは望ましくありません。Kubernetes は、マイクロサービスやトランザクションデータベースからリアルタイムの LLM 推論まで、最新のエンタープライズアプリケーションにおける実績のある業界標準です。Google は、組織が単一の実績あるプラットフォーム上で従来のワークロードとともに自律型エージェントをスケールできるように、Google Kubernetes Engine（GKE）と運用ツールを進化させています。

Forrester は、コンテナおよび Kubernetes サービス、サーバーレス / FaaS サービス、運用管理サービスの評価で Google Cloud に最高スコアを付け、次のように述べています。

「オペレーターは、運用管理、コンテナ、Kubernetes サービスにおいて、強力なサービスを見つけることができます。評価の結果、機能に大きなギャップは見つかりませんでした。」

過去 3 か月間、Google は、チームが企業の予測可能性を維持しながらエージェントワークロードをスケールできるように、インフラストラクチャポートフォリオを強化しました。最近のアップデートにより、以下のことが可能になりました。

GKE Agent Sandbox（一般提供版）と Cloud Run Sandbox（プレビュー版）を使用して、デフォルト拒否のセキュリティで従来のワークロードと並行して、信頼できないエージェントコードを安全に実行できます。これらのプロダクトにより、エージェント用に gVisor で分離された軽量の境界が 1 秒未満で（および 1 つのクラスタで毎秒最大 300 個のサンドボックスが）プロビジョニングされます。
GKE Pod スナップショットを使用してコンテナの RAM 状態を Google Cloud Storage に直接シリアル化することで、アイドル状態のコンピューティング費用を最大 90% 削減できます。これにより、アイドル状態のエージェントセッションを約 100 ミリ秒で一時停止し、約 280 ミリ秒で再開できます。
GKE Inference Gateway の予測ルーティングにより、最初のトークンまでの時間（TTFT）を最大 70%短縮し、キャッシュヒット率を 2 倍に向上させることができます。GKE Inference Gateway は継続的にトレーニングされた ML モデルを使用して、リアルタイムのトラフィックデータに基づいてルーティングを決定します。

リアルタイムの企業データでエージェントをグラウンディング

エージェントの有効性は、グラウンディングのコンテキストによって決まります。従来の分散データトポロジでは、断片化されたマルチホップパイプラインを介して、オペレーショナルデータベースと分析システムが分離されています。エージェントの時代において、この分断はマルチホップのレイテンシ、古いコンテキスト、ガバナンスの摩擦を引き起こします。

Google の Agentic Data Cloud は、エンタープライズデータプラットフォームを静的なリポジトリから動的な推論エンジンへと進化させます。トランザクション処理と分析インテリジェンスをアクティブなアクションシステムに統合し、自律型ワークフローに必要なリアルタイムのコンテキストと決定論的な応答性を提供します。Google は、データベースサービス、分析サービス、データ統合サービス、データガバナンスサービスの各基準で 5/5 のスコアを獲得しました。

「マルチクラウドとハイブリッドの機能、分析システムとトランザクションシステムを橋渡しする Agentic Data Cloud など、Google Cloud のデータベースサービスと分析における従来の強みは、優れたパフォーマンスを推進しています。」

過去 3 か月間で、Google は、お客様がデータ資産を統合できるよう、Agentic Data Cloud に以下の重要な機能を導入しました。

SAP BDC Connect for BigQuery（一般提供版）を使用して、コストのかかるデータの移動を必要とせずに、エージェントがライブの財務記録やサプライチェーン記録をクエリできるようにする。SAP BDC Connect for BigQuery により、SAP システムと BigQuery の間でゼロコピーの双方向データ共有が可能になります。
Knowledge Catalog を使用して、データ資産全体にわたってビジネス上の意味をマッピングおよび推論する。Google とパートナーのデータプラットフォーム、セマンティックモデル、サードパーティのカタログ全体でネイティブコンテキストを集約し、それらを管理された信頼できる唯一の情報源として統合できるようになりました。
レイクハウスフェデレーションを使用して、PostgreSQL データプレーンから Iceberg と BigQuery のライブデータにアクセスする。データの移動を必要とせずに、AlloyDB のトランザクションデータと BigQuery または Iceberg の過去の分析情報をライブで結合できます。また、Datastream を使用して、AlloyDB から BigQuery および Iceberg テーブルにデータを継続的に複製することもできます。

新たな基準の確立: Google Cloud で次世代のテクノロジーを構築

Google Cloud が The Forrester Wave™: Public Cloud Platforms, Q3 2026 においてリーダーに選出されたことを光栄に思います。この評価は、数十年にわたる基礎研究、統制されたフルスタックの共同設計、オープンで信頼性の高いクラウドの構築に対する Google の取り組みが認められた結果だと考えています。

断片化されたインフラストラクチャの時代は終わりを告げました。100 万個のアクセラレータチップでモデルをスケールする AI 研究機関、決済システムで数兆ドルを決済するグローバルな金融取引所、自律型ワークフローで数百万人のユーザーを支援する企業など、どのような組織にも、Google Cloud は次世代のテクノロジーの構築に必要なパフォーマンス、スケール、セキュリティ、データ基盤を提供します。

クラウドへの移行の次のステップ:

レポート全文をダウンロード: The Forrester Wave™: Public Cloud Platforms, Q3 2026 で詳細な分析をご覧ください。

- Google Cloud Platform および SRE 担当プレジデント、Brad Calder

- AI およびコンピューティングインフラストラクチャ担当バイスプレジデント兼ゼネラルマネージャー、Mark Lohmeyer

分散 Ray クラスタに gVisor サンドボックスを導入

Fri, 04 Sep 2026 11:20:00 +0000

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

強化学習（RL）のエコシステムでは、複雑なトレーニング後のワークフローを支える統合コンピューティングランタイムとして、Ray の採用が急速に進んでいます。Google Cloud のお客様も、マルチモーダルデータパイプラインから最先端の RL まで、さまざまなワークロードに Ray を活用しています。しかし、エージェントモデルと推論モデルが進化するにつれて、重大な課題が浮き彫りになってきています。それは、動的なロールアウト、コード生成、マルチターンのツール操作を安全に実行するために、安全で分離されたサンドボックスを大規模にオーケストレートすることです。このたび、Anyscale とのパートナーシップによる Ray の試験運用版ライブラリを導入いたします。このライブラリは、Google で開発中のエージェント型 AI テクノロジーを活用して、ネイティブで高性能なサンドボックス環境を分散 Ray クラスタに直接提供するものです。

Ray プリミティブとしてのサンドボックス

Ray は、トレーニング後のワークロードをオーケストレートするための標準的なランタイムとして定着しています。veRL、NeMo-RL、SLIME、MILES、SkyRL などのフレームワークは、すでに Ray を使用して分散トレーナー、推論エンジン、ロールアウトワーカーなどのコンポーネントを調整しています。

Ray サンドボックスの設計において重要な目標としたのは、隔離された実行のために新たな抽象化を導入するのではなく、既存の Ray プログラミングモデルに自然に馴染む形にすることです。サンドボックスは、Ray が管理する他のリソースと共通する特性を多く備えています。具体的には、マシンへの配置や、リソースの割り当て、作成と破棄、障害からの復旧、周囲のワークロードに応じたスケーリングなど、他のリソースと同様の管理が求められます。こうした背景から、各ハイレベルサンドボックスを Ray アクターとして表現する手法を採用しました。

Ray スケジューラは、どのノードでサンドボックスを実行するかを決定し、対応する CPU とメモリリソースを予約します。サンドボックスアクターが自身のライフサイクルを管理する一方で、gVisor はそのノード上で隔離された実行環境を提供します。

Ray 2.58 以降では、フレームワークの作成者と研究者は、他のワークロードで使い慣れた Ray API やパターンをそのまま使用して、サンドボックス環境を管理できます。以下にその例を示します。

code_block: <ListValue: [StructValue([('code', 'import ray\r\nfrom ray.experimental import sandbox\r\n\r\nray.init()\r\n# Create a gVisor sandbox environment and return an actor handle for a proxy actor\r\nsb = sandbox.create(\r\n cpu=1.0,\r\n memory="512Mi",\r\n image="python:3.12-slim"\r\n)\r\n# Execute code inside the sandbox\r\nresult = ray.get(sb.exec.remote("python -c \'import sys; print(sys.version)\'"))\r\nprint(result.stdout)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f2993cece90>)])]>

これにより、OCI 互換イメージから gVisor サンドボックスが作成され、Ray アクターのハンドルが返されます。exec の呼び出しは通常の Ray アクター呼び出しと同じであるため、サンドボックスはクラスタ内のどこにでも配置できます。作成されたアクターは、オペレーションを gVisor に転送するプロキシです。

サンドボックス API は、エージェント型ワークロードに必要な基本的なライフサイクル管理に対応しています。

OCI コンテナイメージから環境を作成する
CPU とメモリの上限を設定する
環境変数、作業ディレクトリ、ネットワーキングを構成する
コマンドを実行する
ファイルの読み取り、書き込み、アップロード、ダウンロードを行う
サンドボックスの状態を検査する
環境を終了または削除する

さらに詳細な制御が必要な場合は、SandboxRuntime を使用してローカルの gVisor サンドボックスを直接操作できます。これにより、gVisor に引き渡す前の OCI 仕様をユーザー側で編集できるようになります。この API を使用してアクター内にローカルサンドボックスのプールを構築する方法を以下に示します。

code_block: <ListValue: [StructValue([('code', 'import ray\r\nfrom ray.experimental.sandbox.runtime import SandboxRuntime\r\n\r\n@ray.remote\r\nclass SandboxPool:\r\n def __init__(self, size: int = 3, image: str = "python:3.10-slim"):\r\n self.runtime = SandboxRuntime()\r\n self.sandboxes = [\r\n self.runtime.create(image=image, memory="512Mi")\r\n for _ in range(size)\r\n ]\r\n\r\n def run_command(self, index: int, command: str):\r\n return self.runtime.exec(self.sandboxes[index], command)\r\n\r\n def close(self):\r\n for sb_id in self.sandboxes:\r\n self.runtime.delete(sb_id)\r\n\r\n# Deploy an actor managing a pool of local sandboxes\r\npool = SandboxPool.remote(size=3)\r\nresult = ray.get(pool.run_command.remote(0, "python3 -c \'print(\\"Hello from pool!\\")\'"))\r\nprint(result.stdout)\r\nray.get(pool.close.remote())'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f299386a650>)])]>

gVisor を選ぶ理由

モデルが生成したコードを実行する際は、その環境内のコードを「信頼できないもの」として扱う必要があります。Ray サンドボックスは、Google のオープンソースアプリケーションカーネルである gVisor を初期サンドボックスランタイムとして使用します。gVisor は、Linux システムコールインターフェースの大部分をユーザー空間に実装し、ワークロードとホストカーネルの間に、さらなる分離境界を追加します。OCI 互換で、標準のコンテナイメージをそのまま利用でき、Docker デーモンやホスト Docker ソケットをサンドボックスに公開する必要もありません。

この組み合わせは、エージェント型ワークロードに非常に適しています。環境を動的に作成できるほど軽量に保ちながら、生成されたコードを通常のコンテナで直接実行するよりも強力な隔離環境を実現できるからです。gVisor は 1 秒未満の高速起動と低メモリオーバーヘッドを両立しているため、サンドボックスを粒度の細かい分散リソースとして柔軟に活用できます。

Ray の今後のバージョンでは、Agent Substrate や Kata Containers といった他のサンドボックスランタイムにもサポートを拡大していく予定です。

GKE で Ray サンドボックスを試す

Ray サンドボックスの詳細は、Ray のドキュメントでご確認いただけます。GKE でこれらのサンドボックス機能を試すには、Ray サンドボックスのユーザーガイドをご参照ください。フィードバックやアイデアがございましたら、GitHub の issue でディスカッションにぜひご参加ください。強化学習における Ray の未来を一緒に考えていきましょう。

- Google、スタッフソフトウェアエンジニア、 Andrew Sy Kim

- Anyscale、最高技術責任者、Philipp Moritz 氏

AI インフラストラクチャの動的容量管理

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

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

インターネットによって数十億の人々とモバイルデバイスがつながり、今や誰もがコンピュータを手にしています。現在、私たちは次なる大きなテクノロジーシフトの真っ只中にいます。そこでは、何百万もの自律型 AI エージェントがデプロイされ、従業員やエンドユーザーとともに働くようになっています。このたび、Google は組織がプロジェクトレベルで AI 費用を管理し、トークンショックを解消できるよう、Gemini Enterprise の新しい FinOps コントロールを発表しました。しかし、エージェント時代の圧倒的なスケールは、インフラストラクチャを含むスタックのあらゆるレイヤに新たな制約をもたらしています。AI ワークロードは、設計の難しさ、リソース消費の激しさ、そしてバースト性があることで知られています。これらはスケーリングのボトルネックを招くだけでなく、十分に活用されない（または誤用される）コンピューティングリソースを大量に発生させる原因にもなります。

組織は、インフラストラクチャへの投資からさらなる価値を引き出すための分析情報を必要としています。このブログ記事では、動的容量管理のベストプラクティスについて説明します。これは、コストとパフォーマンスの予測可能性を維持しながら、単一の柔軟な基盤上でエンタープライズアプリケーションと AI アプリケーションを実行できるようにするための、スケジューリングと利用の戦略です。これらの機能は、オンデマンド、Spot、確約利用割引（CUD）といった使用量モデルを強化するように設計されており、ワークロードに応じた柔軟な料金設定と割引を提供します。それでは詳しく見ていきましょう。

概要

動的容量管理を実装する 3 つの方法:

計画されたイベントの容量をスケジュールする。Dynamic Workload Scheduler のカレンダーモードを使用して、計画されたイベントに先立ってミッションクリティカルなリソース（GPU、TPU、特定の VM ファミリー）をスケジュールしたり、Flex Start モードを使用して、開始時間が柔軟なバッチジョブの費用を最適化したりできます。容量が確保されると、指定した期間、それらのリソースが保証されます。
すべてのアプリケーションのフォールバック計画を作成して、サービスの継続性を維持する。マネージドインスタンスグループ（MIG）を使用して、優先順位に基づいたハードウェアの自動フォールバックリストを定義します。これにより、希望するオプションが利用できない場合でも、アプリが次の承認済みコンピューティングオプションに自動的に切り替わるようにします。
単一の適応型コントロールプレーンで、容量管理のライフサイクル全体を自動化する。Google Kubernetes Engine（GKE）は、カスタム ComputeClass を使用したフォールバックリストから、動的リソース割り当てを通じたきめ細かいハードウェアスライスまで、プロセス全体をオーケストレートするエージェントネイティブ環境を提供します。これにより、リソースを即座に再割り当てしながら、安全なサンドボックスやコンテナ内でエージェントを迅速にスピンアップすることが可能になります。

アーキテクチャの柔軟性が重要な理由

企業の 90% が今後 3 年以内にエージェントを導入したいと考えていますが、現在の IT 環境でその負荷を処理できると確信している IT リーダーはわずか 17% に留まっています。これらのワークロードには独自のパフォーマンスニーズがあるため、各組織はアクセラレータ（GPU、TPU）や、コンピューティング・メモリ・ストレージの比率をカスタマイズした CPU といった専用インフラストラクチャの導入を急ピッチで進めています。しかし、エージェントはエンタープライズアプリケーションやデータベースにもアクセスする必要があります。しかもそのアクセス量やスケールは、人間による通常の使用をはるかに凌駕することが少なくありません。エージェントとエージェントがやり取りするアプリケーションの両方からの大きな需要に対応するには、動的なインフラストラクチャが必要です。インフラストラクチャチームは、Google の Axion のようなカスタム設計のプロセッサを活用してこれらのニーズを満たすことができますが、ハードウェアだけでは完全なソリューションにはなりません。そのインフラストラクチャを賢く利用し、実行の非効率性を解決して、スタック全体でより柔軟性を高める方法も必要です。

インフラストラクチャの制約を克服する方法

このような柔軟性を実現するには、2 つのアプローチが必要です。予測できる需要に対してリソースを確保することと、予測できない需要に対応するための自動化を構築することです。この 2 つを組み合わせることで、計画されたイベントの容量を事前にスケジュールし、手動による介入なしにインフラストラクチャを予期しない変更に適応させることができます。

1. 計画されたイベントの容量をスケジュールする

Dynamic Workload Scheduler を使用すると、予定されているマイルストーン、オフライントレーニング、予想される需要の急増に先立って、ミッションクリティカルな容量を確保できます。必要なリソースを事前にスケジュールすることで、費用を最適化し、必要なコンピューティングリソースに確実にアクセスできます。Dynamic Workload Scheduler は、ハードウェアアクセラレータ（TPU と GPU）と一部の CPU をサポートしており、次の 2 つのモードがあります。

Flex Start モード: バッチ処理、モデルトレーニング、オフラインファインチューニングなど、レイテンシを許容できるワークロードに使用します。リソースをすぐに要求するのではなく、期間を定義したリクエストを送信することで、システムがジョブをインテリジェントにキューに入れ、容量が利用可能になり次第、リソースをプロビジョニングします。これにより、コスト効率を最大化し、需要の高いアクセラレータを確保できる可能性を大幅に高めることができます。
カレンダーモード: 主要なプロダクトのリリース、予定されている移行、季節的なトラフィックの急増など、ミッションクリティカルで時間制限のあるイベントに使用します。イベントの正確な開始日と終了日を指定することで、将来の予約を作成します。これにより、イベントの開始時に、リクエストされた容量が確実に利用可能になります。

2. すべてのアプリケーションのフォールバック計画を作成して、サービスの継続性を維持する

トラフィックの急増は、必ずしも予測できるものではありません。また、ニュース速報や市場の急激な変化などによってユーザーアクティビティが急増し、予期しないトラフィックが発生した場合に備えて計画を立てる必要もあります。サービスが必要なリソースを中断なく取得できるようにするには、フォールバック計画（許容可能なハードウェア構成の優先順位を付けた自動シーケンス）が必要です。この戦略により、以下のことが可能になります。

ワークロードを単一の VM シェイプ、サイズ、構成から切り離します。これにより、希望するオプションが利用できない場合でも、手動介入なしで実行できます。
最新世代の VM を第一の選択肢として採用し、旧世代の VM を自動フェイルバックオプションとして保持することで、段階的な技術更新を実行できます。

Google Compute Engine でコンテナ化されていないワークロードを実行する場合は、マネージドインスタンスグループ（MIG）のインスタンスの柔軟性と VM の一括作成を使用して、容量を動的に管理できます。インスタンスの柔軟性により、単一のマシンタイプに制限されることなく、VM インスタンスに複数のマシンタイプを指定できます。

仕組み: 希望するマシンタイプが一時的に利用できない場合、MIG はリアルタイムの容量に基づいて、リストから互換性のある代替マシンタイプを自動的にプロビジョニングします。これをロケーションの柔軟性と組み合わせる（MIG がリージョン内で検索できる複数のゾーンを指定する）ことで、プロビジョニングの成功率を大幅に向上させることができます。MIG が Spot VM を使用している場合、Compute Engine は Spot 容量シグナルと自動的に統合し、推定稼働時間が長く、プリエンプションのリスクが低いマシンタイプを優先します。

さらに、ベースラインディスクのデフォルト設定とディスクオーバーライドの構成により、インスタンスの柔軟性をブロックストレージレイヤまで拡張することが可能です。これにより、VM が別のマシンタイプにフォールバックした際、ストレージもそれに応じて自動的に適応します。

仕組み: ほとんどの場合、デフォルトのオプションを使用するだけで十分です。インスタンステンプレートから「ディスクタイプ」を完全に省略できます。ただし、関連付けられた VM よりも長く存続するデータディスクについては、複数の VM 世代にわたって高速で耐久性に優れた Hyperdisk を有効にできます。

Compute Engine は仮想マシンを使用する組織にインスタンスの柔軟性を提供しますが、GKE はさらに一歩進んで、単一のコントロールプレーンから容量のライフサイクル全体を自動化します。GKE カスタム ComputeClass を活用することで、プラットフォームチームは多次元のフォールバックリストを設計できるようになります。異なる VM マシンファミリーやサイズ、構成比の自動的な組み合わせ、複数ゾーンにわたるスケーリング、さらにはオンデマンド VM とスポット VM の切り替えまで、柔軟な運用が可能です。Dynamic Workload Scheduler を容量ターゲットとして使用し、カスタム ComputeClass を使用してポリシーと優先度を定義することで、容量管理のライフサイクルを完全に自動化できます。

仕組み: ComputeClass を設定すると、GKE は希望するノード構成が利用できない状況を自動的に検出し、優先順位に従って事前に承認された代替オプションにフォールバックします。アクティブな移行が有効になっている場合、GKE は容量が利用可能になると、ワークロードを優先度の高いノード構成に正常に移行します。ブートディスクなどの一時的なディスクの場合、GKE はインスタンスファミリーに基づいて適切なデフォルト設定を動的に選択します。ただし、VM よりも長時間存続するディスクには、Hyperdisk を使用できます。

GKE のもう一つの機能である動的リソース割り当ては、リソースの消費方法を指示する高度なルールをデベロッパーが定義できるようにすることで、「全か無か」といった無駄の多いハードウェア割り当てを解消するのに役立ちます。

仕組み: GPU や TPU 全体を要求するのではなく、アプリケーションが合計メモリやコア数などの正確なパラメータを指定します。それに基づき、システムが最適なハードウェアスライスを割り当てるため、使用率を最大化し、費用を削減できます。

動的インフラストラクチャへの次のステップ

AI をスケールしても、インフラストラクチャの予算が比例して増大したり、技術的負債が蓄積したりするわけではありません。これらの例が示すように、適切なツールを使用することで、制約を克服し、コンピューティングへの投資から得られる価値を劇的に変えることができます。利用を開始するには、次の 3 つのステップを実行します。

ワークロードを監査して、すぐにコストを削減する: 現在、単一の VM ファミリー、マシンタイプ、またはアベイラビリティゾーンに緊密に結合されているアプリケーションを特定し、実行可能な代替ハードウェアシェイプをマッピングします。既存の構成だけでなく、ワークロードレベルの目標に基づいて、より適しているか、代替として機能する可能性のある新しいコンピューティングオプションを評価します。次に、Compute Engine MIG、VM の一括作成、または GKE カスタム ComputeClasses を使用して自動的に採用し、フォールバックリストに統合します。
最小利用額を確約して大幅な割引を受ける: 継続利用による自動割引に加え、コンピューティングフレキシブル確約利用割引を利用すれば、最大 63% の割引が適用されます。この割引は、特定のマシンタイプやロケーションに関係なく、使用するリソースに関連付けられます。
アカウントチームに問い合わせる: Google Cloud アカウントチームに連絡して、カスタマイズされた容量管理戦略を策定し、自動フォールバックリストを構成します。

- オーケストレーションおよび Kubernetes プロダクト担当シニアディレクター、Drew Bradstock

Mirendil の事例: トレーニング前後のアプリケーションに AI Hypercomputer のTPU と GPU を活用

Tue, 01 Sep 2026 01:00:00 +0000

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

ほぼすべての大手 AI 研究所が、モデルのトレーニング、エージェントの推論、最先端の研究などに Google Cloud インフラストラクチャを使用しています。Google Cloud は、業界の研究とイノベーションを牽引する急成長中の新興 AI スタートアップから選ばれるプラットフォームであり続けています。

このたび、AI 開発の加速に注力する最先端の AI 研究所である Mirendil も、Google Cloud の AI Hypercomputer を採用することを発表しました。具体的には、Google の TPU AI アクセラレータと、Google Cloud 上で稼働するフルスタックの NVIDIA AI インフラストラクチャを併用し、この専用設計の AI インフラストラクチャによって Mirendil のモデル事前トレーニングと事後トレーニングのアプリケーションをサポートします。

Mirendil チームは、AI の研究開発を加速し、民主化するのに役立つ新しい AI システムを構築しています。これはつまり、初期モデルの事前トレーニングから事後トレーニングまで、複雑なエンドツーエンドのトレーニングワークフローを管理し、大規模な強化学習をサポートすることを意味します。Google Cloud を通じて TPU と、NVIDIA のフルスタックアクセラレーテッドコンピューティングプラットフォームの両方を自在に組み合わせることで、Mirendil は不可欠なコンピューティングに非常に迅速にアクセスし、状況の変化に合わせてワークロードを最適なアーキテクチャに適合させ続けることが可能になっています。

Google は Mirendil と緊密に連携して、コンピューティング、ストレージ、ネットワーク、コントロールプレーンの各層にわたって、TPU と NVIDIA AI インフラを統合した環境の設計からデプロイまでをエンドツーエンドで実施しました。また、Gemini Enterprise Agent Platform で実行されるマネージドトレーニングクラスタを使用するシステム構築でも協力し、Mirendil における TPU と GPU 両環境のプロビジョニングと管理を大幅に効率化しました。Mirendil はすでに TPU v5P チップのクラスタでの運用を開始しており、NVIDIA AI アクセラレーテッドコンピューティングシステムも近日中に稼働を開始する予定です。

Mirendil の共同創業者 / CEO である Behnam Neyshabur 氏は、次のように述べています。「AI の進歩は、実験の設計、結果の評価、反復という研究ループを人間がどれだけ速く実行できるかによって制限されてきました。私たちは、そのループ自体を加速させ、改善することができる AI システムを構築しています。Google Cloud を基盤として拡張することで、システムをさらに進化させ、最先端の AI 研究機能をより多くの科学者やエンジニアの手に届けるためのスケールと柔軟性が得られます。これにより、研究ループをより迅速かつ大規模に回すことが可能になります。」

Google と Mirendil のパートナーシップについて詳しくは、Mirendil のブログをご覧ください。

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

AI 時代のデジタル主権: 制御とイノベーションの二者択一が不要に

Fri, 21 Aug 2026 01:00:00 +0000

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

コンプライアンスと主権に関する厳格な要件を持つ企業や政府機関は、機密データをオンプレミスに保持しているがために最新の AI を利用できないことがよくあります。こうした組織は、次の 3 つの大きなリスクを管理しています。

管轄権のリスク: 現地の規制の変化や、知的財産（権）保護の必要性、国外からのデータアクセス要求といった要因により国内でのデータ管理が不可欠となっています。
経済的自立: 海外のインフラストラクチャプロバイダに依存すると、重要なサービスの脆弱化を招くおそれがあります。
地政学的リスク: 予測不可能な世界情勢の混乱から重要な国内サービスを保護する必要があります。

Google が「AI インフラストラクチャの現状」レポート作成のため最近実施した調査では、対象となった 1,400 人を超えるシニア IT リーダーの 48% が、現地のデータセキュリティ法を遵守するため、データ所在地の管理機能を備えたインフラストラクチャを優先していると回答しています。

しかし、オンプレミス環境にとどまることは、もはや最新のイノベーションから取り残されることを意味しません。このギャップを埋める手段として、オンプレミスとマルチクラウドを組み合わせたハイブリッドソリューションを導入する組織が増えてきています。Google の調査によると、現在 52% の組織が AI 活用のためにハイブリッドクラウドのアプローチを採用しています。

このアプローチでは、パブリッククラウドの圧倒的な処理能力を活用しながら、主権やコンプライアンス維持といったローカル環境のメリットも享受でき、データの所在地やアクセス権を自ら完全に制御することが可能です。これまで、こうした厳格なデータルール規制下にある組織は、高度な AI を簡単に取り入れることはできませんでした。独自の AI システムの構築も、スピードとコストの両面で現実的ではありませんでした。

そこで登場したのが、Google の Google Distributed Cloud（GDC）です。GDC を使用すると、データセンターやエッジなど、お客様が必要とする場所で Google Cloud を利用できるようになります。AI ワークロードの主権要件を満たすために、次の 2 つのデプロイモデルが用意されています。

エアギャップ: Google Cloud やパブリックインターネットから完全に遮断された環境で動作する、外部接続を必要としないソリューション。Google がリモートでシャットダウンすることはできません。
コネクテッド: 既存のハードウェア上で直接実行される、Google がソフトウェアライフサイクルを統合的に管理するモデル。

GDC は、AI ワークロード向けに最適化されたインフラストラクチャ、Gemini またはオープンモデルの選択肢、費用対効果の高い推論サービスを備えた、オンプレミスの完全な AI ソリューションを提供します。この基盤を活用すれば、データを完全に制御しながらセキュアな AI エージェントを構築して実行できます。

オンプレミスでソブリン AI のニーズを満たす

データ管理か、AI イノベーションかの二者択一を迫られることはもうありません。Google Distributed Cloud なら、データの主権を完全に維持しながら世界をリードする AI を自社の環境に直接導入できます。

大手企業のハイブリッド戦略の詳細を紹介した「AI インフラストラクチャの現状」レポートを、ぜひご一読ください。

- Google Cloud、Distributed & Sovereign Cloud 担当バイスプレジデント兼ゼネラルマネージャー、Ankur Mehrotra

アイドル状態のアクセラレータを最小限に抑える: llm-d での協調型タイムスライスによるネイティブ RL ジョブのインターリーブ

Mon, 03 Aug 2026 02:20:00 +0000

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

大規模言語モデル（LLM）のトレーニング後の強化学習（RL）において、その背後にある数学は妥協が許されないことで知られています。最先端の AI ラボでは、Group Relative Policy Optimization（GRPO）などの RL のトレーニング後のアルゴリズムを使用して推論モデルやコーディングモデルの限界を押し広げるなか、アーキテクチャやインフラストラクチャの厳しい制約に日常的に直面しています。業界の関心の多くは、依然としてアクセラレータの物理容量の獲得に集中していますが、複数の RL ジョブを実行し、モデルをより高いレベルのインテリジェンスに引き上げるために必要な高速性を実現するには、インフラストラクチャの効率も同様に重要です。大規模な分散 RL では、同期サンプリングとトレーニングが厳密に順次フェーズとして実行されるため、トレーナーとサンプラーのリソースが交互にアイドル状態になるため、深刻なリソースボトルネックが発生します。一方、非同期アーキテクチャではこれらのフェーズを重複させようとしますが、トレーナーは、次のサイクルを開始する前に特定の軌跡バッチが完了するのを待つ間、頻繁にアイドル状態になります。

本日は、この構造的な無駄を解消するソリューションとして、llm-d プロジェクトによる協調型タイムスライスをご紹介します。ロールアウトのサンプリングや勾配トレーニングといった個別の RL ステップを、スケジュール可能な動的エンティティとして扱うことで、独立した RL ジョブを共有物理ハードウェアにインターリーブできます。初期ベンチマークでは、このプラットフォームレベルの多重化により、モデルの収束や精度に影響を与えることなく、アクセラレータの集計デューティサイクルがベースラインの約 40% から最大 70% まで向上することが示されています。これにより、時間の経過とともに発生するコンピューティングの無駄がなくなるため、コストパフォーマンスが向上し、TCO の大幅な削減が実現します。

同期設定の場合、プラットフォームはサンプラーとトレーナーの両方をインターリーブして、交互に生じるアイドル時間を最小限に抑えます。一方、非同期ワークロードはタイムスライスを利用して、RL トレーナーのイテレーション間に生じる断片的なアイドル時間を動的に回収して再利用します。

このブログ記事では、このタイムスライスソリューションについて、技術フロー、現在のリリース、今後のロードマップを詳しく説明します。

RL インフラストラクチャの効率化のための llm-d（全体像）

Google は当初から、大規模な RL のトレーニング後にインフラストラクチャに深刻なボトルネックが生じることを予測し、RL ワークロードにおけるインフラストラクチャの非効率性を解消することに取り組んできました。

そのなかで、アクセラレータのアイドル時間をなくすことを重視し、推論、エージェント、RL ワークロード向けの高度にコンポーズ可能なインフラストラクチャスタックに llm-d を組み込みました。RL 向け llm-d スタックには、次のような特徴があります。

スループット重視の推論 （llm-d-router）: RL ワークロード全体にデプロイされ、成熟した、本番環境でテスト済みのエンジンです。ロールアウト生成スループットを最大化してパイプライン常にフル稼働させることに重点を置いています。
高ベロシティの Agent Sandbox （レシピ）: 大規模かつ高密度な環境での検証済みで、ロールアウトの生成と評価中に、安全な 1 秒未満でのツール使用と分離されたコード実行を実現します。Agent Sandbox は、報酬シグナルの生成のための高速インテークマニホールドとして機能し、タイムスライスされた NVIDIA GPU がリソース不足になるような、サンドボックスがレイテンシのボトルネックにならないように設計されています。
コアパイプラインプリミティブ: 重み転送の信頼性と速度の問題に対処するため、Google は Weight Propagation Interface（WPI）を構築するとともに、RL の全体的なオブザーバビリティと信頼性の向上に注力しています。

RL ループにおける効率性の課題

分散型 RL トレーニングの後の運用は、生成（ロールアウトのサンプリング）と最適化（勾配の更新）を交互に繰り返す、断片的で継続的なサイクルとして機能します。従来のクラウドインフラストラクチャは、継続的で安定した状態のワークロード向けに設計されているため、標準の Kubernetes クラスタでは、この交互のリズムに適応できません。

この構造的なケイデンスは、運用が大規模になると、次の 2 つのような大きなシステム上の非効率性を生み出します。

アイドル状態のアクセラレータ: 各フェーズは順次発生するため、GPU クラスタはライフサイクルの 40～60% の間にわたって、完全にアイドル状態（使用率 0%）になります。トレーナーはサンプリングロールアウトが完了するまでアイドル状態で待機し、サンプラーは勾配の更新と重みの分散中にアイドル状態で待機します。これは、年間で数百万ドル規模の資本の無駄につながる可能性があります。
コンテキストのロックイン: RL トレーニングとサンプラーは、NVIDIA CUDA コンテキストとすべてのデバイスメモリを常駐させておく必要があるため、アイドル状態のフェーズでも、ランタイム全体にわたってアクセラレータの割り当てを保持し続けます。標準的なスケジューラでは、これらの Pod を稼働中の RL ループのフェーズレベルでの状態が交互に変化することに合わせるのではなく、静的でサイロ化された割り当てとして扱います。そのため、非アクティブなフェーズでも貴重なハードウェアがロックされたままになります。

重要なのは、これが単なる同期 RL の問題ではないということです。非同期バリアントでは生成とトレーニングが重複して行われますが、アイドル時間を完全に軽減するわけではありません。生成は RL ループ固有のボトルネックであり、ロールアウトデータが蓄積されるのを待っている間、トレーナーアクセラレータは依然としてリソース不足に陥ります。非同期ジョブがポリシーに沿って実行されるほど、こうしたアイドル状態の時間は増大します。生成とトレーニングのずれを制限するバウンドステイルネスにより、新しいロールアウトの準備が整っていない場合はパイプラインが停止するからです。

協調型タイムスライス（RL ジョブのインターリーブ）のメリット

RL ジョブ中にアクセラレータがアイドル状態になるのを防ぐために、llm-d プロジェクトの協調型タイムスライスでは、ハードウェアがアップストリームフェーズを待機するのではなく、インフラストラクチャが独立した RL ジョブを共有ハードウェアブロックに動的にインターリーブできます。これにより、基盤となるモデルの収束や精度を変更することなく、アクセラレータの総使用率を向上させることができます。

同期 RL のフェーズ境界でジョブ A がアイドル状態になると（または非同期 RL で新しいロールアウトデータ待ちでジョブ A が停止すると）、インフラストラクチャは物理アクセラレータをタイムスライスし、ジョブ B のアクティブなサンプリングフェーズまたはトレーニングフェーズに切り替えます。内部的にこの切り替えは、チェックポイント / 復元として扱われます。ジョブ A のデバイス状態全体がアクセラレータメモリからホスト DRAM にチェックポイントされ、代わりにジョブ B の以前に保存された状態が復元されます。アクセラレータを占有するジョブの状態は常に 1 つだけであるため、フレームワークレベルの干渉やメモリ不足（OOM）障害を発生させることなく、ステップを安全に切り替えることができます。

タイムスライス: アーキテクチャの概要

タイムスライスシステムアーキテクチャは、ワークロードスコープ（アプリケーションロジック）、クラスタスコープ（調整）、ノードスコープ（ハードウェア管理）の 3 つのレイヤで構成されています。

ワークロードスコープのレイヤ（アプリケーションランタイム）ユーザーのコードが実行される場所で、トレーニングループ、推論サーバー、RL フレームワークなどがあります。新たに追加されたのは、タイムスライスクライアントライブラリで、タイムスライスオーケストレーターで 2 つの gRPC API を公開します。1 つはアクセラレータへの排他的アクセスをリクエストする acquire() で、もう 1 つはそれを解放する yield() です。ユーザーは、アクセラレータに触れるフェーズをこれらの呼び出しでラップし、オーケストレータにフェーズの境界を通知します。ML フレームワーク（PyTorch FSDP、vLLM など）や、CUDA コンテキスト、アクセラレータメモリ割り当てなど、他はすべて変更なしで実行されます。

クラスタスコープのレイヤ（制御およびオーケストレーションプレーン）このレイヤは、どのジョブがいつアクセラレータにアクセスできるかを決定します。同じ物理アクセラレータを共有するジョブ（例: 同じ GPU ノードセットでインターリーブする 2 つの RL ジョブ）は、1 つのグループに配置されます。タイムスライスオーケストレーターは、グループごとにロックキューを維持します。ロックキューは、そのグループのアクセラレータへの排他的アクセスを待機しているジョブの順序付きリストです。キューの先頭のジョブのみがロックを保持してハードウェア上で実行され、他のすべてのジョブは acquire() 呼び出しでブロックされた状態で待機します。実行中のジョブが yield() を呼び出すと、オーケストレーターはロックをキュー内の次のジョブに渡し、グループ内のすべてのノードで協調的なコンテキスト切り替えをトリガーします。将来的には、ワークロード配置オプティマイザーがワークロードフェーズパターンをプロファイリングし、互いに補完的なアイドルフェーズのジョブを自動的にペアリングできるようになるため、ユーザーがジョブのグループ化を明示的に指定する必要はなくなります。

ノードスコープレイヤ（ハードウェアとデータプレーンの分離）このレイヤは、各アクセラレータノードでチェックポイントと復元の切り替えを実行します。特権 DaemonSet であるスナップショットエージェントは、オーケストレーターから指示を受け取り、それをハードウェアレベルのオペレーションに変換します。具体的には、アクセラレータプロセスを一時停止し、デバイスの状態をホスト DRAM にシリアル化して、ジョブがアクセスを再開したときに復元します。このエージェントは、プラグイン可能なバックエンドインターフェースを中心に構築されており、最初の実装として cuda-checkpoint が使用されています（今後さらに追加される予定です）。今後のバックエンドでは、より高速なスナップショットメカニズムや、デバイスの状態全体ではなく LoRA アダプタなどの特定のメモリアドレスをオフロードするなどの、より選択的なアプローチが導入される見込みです。エージェント自体は、ベアメタル環境と Slurm 環境向けに Kubernetes の外部でスタンドアロンで動作するように設計されています。

フロー: 全体像

ワークロードが現在のアクセラレータフェーズを終了すると、そのタイムスライスクライアントライブラリはタイムスライスオーケストレーターに対して yield() を呼び出し、アクセスを解放します。オーケストレーターは、グループ内の各ノードのスナップショットエージェントに指示を送信して、コンテキストの切り替えを開始します。エージェントは、譲歩するワークロードのプロセスをフリーズし、そのデバイスの状態をアクセラレータメモリからホスト DRAM に移動します。

アクセラレータが解放されると、オーケストレーターはキューで待機している次のワークロードにグループロックを付与します。それらのノード上のスナップショットエージェントに対して、そのワークロードの以前に保存された状態をホスト DRAM からアクセラレータメモリに復元するよう指示し、その後、ワークロードの保留中の acquire() 呼び出しのブロックを解除します。ワークロードは、コンテナの再起動やフレームワークの再初期化、ストレージからのモデル再読み込みを行うことなく、中断したところから正確に実行を再開します。

譲歩したワークロードは、ホスト DRAM でウォーム状態を維持します。オーケストレータが再びロックを許可すると、スナップショットエージェントは同じ切り替えを逆方向に実行します。

開発者エクスペリエンス（クライアントサイド）研究者は、低レベルの CUDA コンテキスト切り替えやカスタムスケジューリングループに煩わされることなく、コアモデリングロジックに集中したいと考えています。RL ジョブのオーケストレーションに Ray や同様のプラットフォームを使用している場合、タイムスライスを使用してもクライアント側への影響は最小限に抑えられます。実際、プラットフォームレベルでトレーニングジョブとサンプリングジョブを別々にキューイングしている場合は、クライアント側にはまったく影響が及ばない可能性があります。

code_block: <ListValue: [StructValue([('code', 'from timeslice import TimeSliceOrchestratorClient\r\n\r\norchestrator = TimeSliceOrchestratorClient(target="orchestrator:50051")\r\n\r\n@orchestrator.on_accelerators(group_id="trainer-group")\r\ndef train_phase(model, trajectories):\r\n return model.update(trajectories)\r\n\r\n@orchestrator.on_accelerators(group_id="sampler-group")\r\ndef generate_phase(model, prompts):\r\n return model.generate(prompts)\r\n\r\n# Standard sequential loop — interleaved with other jobs under the hood\r\nfor epoch in range(EPOCHS):\r\n trajectories = generate_phase(policy, dataset)\r\n rewards = compute_rewards(trajectories)\r\n train_phase(policy, rewards)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f2993d67e90>)])]>

現在のリリースと今後の見通し

このたび、タイムスライスのフルスタック（スナップショットエージェント、アクセラレータオーケストレーター、Python クライアントライブラリ）をリリースいたしました。各スタックには、RL ワークロードにタイムスライスを統合するためのユーザーガイドが付属しています。

ロードマップの主なハイライトは次のとおりです。

レイテンシと状態の最適化: より高速なチェックポイント / 復元バックエンドでスナップショットエージェントを拡張し、コンテキスト切り替えのオーバーヘッドを最小限に抑えます。また、アプリケーション対応のバックエンドを使用して、特定のメモリ領域をスナップショットします（例: モデルの重み全体ではなく、LoRA アダプタを切り替え）。
自動スケジューリングとオンボーディング: 実行中のプロセスをプロファイリングし、タイムスライス可能な構造を特定して、ジョブの配置を動的に処理する自動スケジューラを導入します。
ハードウェア間の互換性: データプレーンのサポートを GPU から TPU やカスタムアクセラレータアーキテクチャに拡張します。

使ってみる

堅牢で高度に最適化された RL インフラストラクチャを構築するには、これらのワークロードを大規模に実行するエンジニアや研究者との緊密な連携が不可欠です。

現在課題となっている、トレーニング後のパイプラインでの GPU 使用率の低さ、同期による停止、複雑なスケジューリングロジックは、タイムスライスで解決できます。まずは以下のリソースをご確認いただき、ぜひフィードバックをお寄せください。

これらのユーザーガイドを使用して、RL の実行中にタイムスライスをお試しください。
RL 生成フェーズ中のサンプリングスループットを向上させるには、llm-d-router（Kubernetes ネイティブ）または RL スケジューラ（Python ライブラリ）のユーザーガイドをお試しください。
Weight Propagation Interface のリポジトリをご覧ください。
llm-d Slack の #sig-rl チャンネルでディスカッションにご参加ください。
リファレンス実装、ベンチマーク、エッジケースを共有して、この手法の改善にご協力ください。

このブログ投稿の執筆に協力してくれた Dolev Ish Am と Bogdan Berce に感謝します。

- シニアプロダクトマネージャー、Poonam Lamba

- ソフトウェアエンジニア、Aishu Kamal

AI エージェントの準備は完了。では、データは？

Thu, 30 Jul 2026 01:00:00 +0000

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

組織による AI イニシアチブの拡張を妨げている最大のボトルネックの一つは何でしょう？それは、現在のモデルの機能ではありません。ビジネスコンテキストとセマンティックな意味へのアクセスです。

エージェントの時代における企業は、単にデータを保存するだけでなく、信頼できるコンテキストでデータを有効活用し、受動的な記録システムから能動的な「アクションシステム」へと移行する必要があります。

しかし、AI エージェントは非線形的な速度で動作します。たとえば、1 つのプロンプトでエージェントが複数のシステムを対象に自律的にブラウジングを行い、クエリを発行して処理を実行する場合、基盤となるインフラストラクチャに負荷をかけることがあります。コンピューティング、ネットワーキング、ストレージの各レイヤがエージェント型 AI 向けに最適化されていない場合、その上に位置するデータプラットフォームは崩壊します。

Google のインフラストラクチャの現状に関するレポートによると、本番環境グレードのエージェント型 AI システムをサポートするにはインフラストラクチャのアップグレードが必要だと考える組織が 83% を占めています。

この問題を解決するために、Google は Google Cloud Next 2026 で Agentic Data Cloud を発表しました。これは、データ、AI モデル、運用データベースを単一の「アクションシステム」に統合するソリューションです。Agentic Data Cloud を機能させるには、チップからモデルまで、すべてが AI ネイティブである必要があります。基盤となるインフラストラクチャは、エージェントの負荷に対応できる必要があります。

Google の Agentic Data Cloud

適切なインフラストラクチャ基盤を整えることで、組織が現在直面している最大のデータ課題を Agentic Data Cloud がいかに解決できるか、以降で見ていきましょう。

コンテキストの欠如を克服する

エージェント型システムを効果的に機能させるにはコンテキストにアクセスする必要がありますが、こうしたコンテキストは、多くの場合、断片化されたデータシステムや従来のアーキテクチャに存在します。このため、エージェントがこうしたコンテキストを把握することが難しくなり、不完全かつ不正確な結果につながる可能性があります。実際、Google のレポートによると、43% の IT リーダーが「従来の API やデータソースとの統合の難しさ」をエージェント型 AI インフラストラクチャの最大のギャップとして挙げています。

しかし、組織が膨大なデータセットを移動して AI に接続しようとする場合、必ず複雑さと費用の増大が伴います。

Agentic Data Cloud は、オープンかつ柔軟なインフラストラクチャ上で実行されるボーダーレスなレイクハウスを活用することで、この問題を解決します。エージェントは、オープンスタンダード（Apache Spark、Apache Iceberg）を介して BigQuery や Spanner などの強力なネイティブエンジンにアクセスすることで、従来の環境で発生するレイテンシと費用を回避しながら、まるでローカルであるかのように複数の環境間でデータを読み取り、推論し、有効活用できます。

不要な手作業を回避する

分断されたシステムの寄せ集めにエージェントをスケールすると、大きなボトルネックが生じる可能性があります。Google の調査では、AI をスケールする際の予期せぬ費用の筆頭として、81% のリーダーが運用の複雑さとエンジニアリングのオーバーヘッドを挙げています。その例として、エンジニアが異なるシステムにまたがる AI エージェントを手動でつなぎ合わせる作業に費やす時間が挙げられています。

「考える」エージェントから「実行する」エージェントに移行するには、分析ソースと運用ソースの両方でリアルタイムデータを接続できなければなりません。これには垂直統合が必要です。モデル、データシステム、基盤となるアクセラレータが共同設計された AI ネイティブインフラストラクチャ上に Agentic Data Cloud を構築すると、ネットワークホップが減り、ツールがより適切に統合されます。この統合システムにより、エージェントは典型的なエンジニアリングのオーバーヘッドなしで分析情報を取得し、安全なトランザクションをトリガーできます。

データに信頼と知識をもたらす

エージェントに必要なのは、データを検出してクエリを実行する機能だけではありません。安全かつ正確なアクションを実行するには、豊富なコンテキストとビジネスロジックも必要です。しかし、36% のリーダーが、AI モデルのグラウンディングに使用される専門的な高スループットのベクトルデータベースの不足を、インフラストラクチャの主要なギャップとして挙げています。このギャップにより、エージェントにコンテキストを提供する能力が損なわれます。

エージェントがその可能性を最大限に発揮するには、レガシー ERP やサードパーティ CRM を含むデータシステムに対してリアルタイムで読み書きを実行できるように構築された基盤が必要です。また、複雑なタスクを実行する際に、たとえば 3 週間前のユーザーの好みを「思い出す」ことができる長期記憶も必要です。こうしたリアルタイムの自動化がない場合、エージェントはクエリごとにデータを再処理する必要があります。

AI にコンテキストを提供するために、組織は Knowledge Catalog を使用してデータレイク内のデータを集約して拡充し、エージェントによる検索を可能にしています。非構造化データから意味を抽出してセマンティクスを自動生成することで、カタログはアクティブな推論レイヤとして機能するようになります。そして、そのカタログは、エージェントが適切なコンテキストを取得できるように、高スループットのインフラストラクチャによって支えられている必要があります。

将来を見据える

今こそ、AI によって真の競争優位性を獲得するために、接続されたアクティブなデータエコシステムを構築する絶好のタイミングです。試験運用から本番環境に移行するには、エージェントがすべてのデータにシームレスにアクセスできるようにする必要があります。また、エージェントの時代の要求に対応できるインフラストラクチャで、これを支える必要があります。2026 年以降に勝利を収められるのは、必ずしも高度にスマートなエージェントを備える企業とは限りません。これらのエージェントに適切な知識を、安全かつ費用対効果の高い方法で大規模に提供できる企業が勝利するでしょう。貴社のデータは、エージェントの時代に対応する準備ができていますか？

エージェント型 AI 時代におけるインフラストラクチャの現状に関するレポートで、アーキテクチャに対して AI に最適化されたアプローチを採用しているリーダーたちの手法をご確認ください。

- プロダクト管理、データ分析担当バイスプレジデント、Sirish Chandrasekaran

Google Cloud、2026 年 Gartner® Magic Quadrant™ の AI インフラストラクチャ部門でリーダーに選出

Thu, 30 Jul 2026 00:30:00 +0000

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

エージェントの時代では、AI は質問に答えるだけでなく、推論して行動するよう進化しています。AI の次のフェーズで主導的な役割を担おうとしている企業は、こうした新しい要件に合わせて設計、最適化されたコンピューティングインフラストラクチャを必要としています。これは、イノベーションの加速、ユーザーや顧客への魅力的なエクスペリエンスの提供、費用対効果とエネルギー効率の最適化をすべて大規模に実現できるようにするものです。

このたび、Google が、新設された GartnerⓇ Magic Quadrant™ の AI インフラストラクチャ部門でリーダーに選出され、「実行能力」と「ビジョンの完全性」で最も高い評価を得ました。この結果は、Google が社内およびお客様のためにこれらの課題を解決することに尽力してきたことが認められたものと考えています。

レポート全文: 2026 Gartner Magic Quadrant™ for AI Infrastructure

Gemini で使用されるインフラストラクチャ基盤の構築

現在のモデルとサービングのアーキテクチャでは、シリコンとソフトウェアの相互作用を根本的に見直すことが求められます。Google は、構想していたプラットフォームは既製品として購入できるものではなく、自社開発する必要があることを早い段階で認識していました。10 年以上にわたり、Google のインフラストラクチャエンジニアと Google DeepMind の研究者は肩を並べて、Gemini、YouTube、検索のスタック全体を共同設計してきました。Google は、そうしたイノベーションを、よく利用されているサードパーティ製ソフトウェアやオープンソースソフトウェアとともに、Google Cloud を通じてお客様に提供しています。現在、Google の統合スタックは、フロンティア AI ラボの 10 社中 9 社、Citadel Securities などの資本市場企業、Mercedes Benz などの企業にサービスを提供しています。

ハードウェアレイヤでは、カスタムシリコンへの取り組みが主な強みとして Gartner に評価されました。Google は今年、カスタムシリコンの 2 つの新しい進歩について発表しました。この第 8 世代 TPU は、システムレベルで企業のスケーリングとメモリのボトルネックを解決するように設計されています。

TPU 8t（トレーニングの原動力）: トレーニングのタイムラインを最適化するために専用設計された TPU 8t は、1 つの Superpod に 9,600 個のチップを搭載し、Pod あたり前世代の約 3 倍のコンピューティングパフォーマンスで、フロンティアモデルに必要な高密度のコンピューティングを実現します。
TPU 8i（推論エンジン）: 専門エージェントの反復的な共同作業を処理するように設計された TPU 8i は、288 GB の高帯域幅メモリと 384 MB のオンチップ SRAM（前世代の 3 倍）により、リアルタイムのエージェントワークフローのメモリウォールを克服し、モデルのアクティブなワーキングセットを完全にオンチップで保持します。

Google の TPU プラットフォームは、可能なことの限界を押し広げますが、万能なプラットフォームというものは存在しません。お客様によってワークロード、要件、ユースケースは異なります。そのため、Google は NVIDIA とも緊密に連携し、最新のアクセラレーテッドコンピューティングプラットフォームを、Google Cloud の高性能で信頼性が高くスケーラブルなサービスとして提供しています。Google は、今年後半に提供される次世代の Vera Rubin プラットフォームをベースにした A5X インスタンスをいち早く提供し、お客様が選択できるようにします。また、Google は NVIDIA と緊密に連携して、GPU を多くの Google Cloud ソフトウェアサービスに統合し、お客様がアクセラレーテッドコンピューティングに簡単にアクセスできるようにしています。

さらに柔軟性を高めるために、Google は llm-d と vLLM を通じて、オーケストレーション、推論エンジン、フレームワークの各レイヤにわたるオープンソースプロジェクトに貢献し続けています。また、先日発表された TorchTPU を使用すると、PyTorch デベロッパーは複雑なコードの書き換えなしで移植性を確保し、デプロイのパフォーマンスを最大化できます。

AI Hypercomputer でコストパフォーマンスが向上

インフラストラクチャへの投資が増えるにつれて、AI アプリケーションを経済的に実現可能にするために、本来のパフォーマンスと費用のバランスを取る必要があります。AI を「今購入して後で統合する」というアプローチで導入することは、持続可能ではなくなりつつあります。Google は、柔軟な使用量モデルを特徴とする事前統合されたハードウェアとオープンソフトウェアのフレームワークを組み合わせることで、トレーニング、強化学習、推論にわたりコストパフォーマンスを向上させるように設計された統合システムを提供します。

Gartner は、Google の統合された AI Hypercomputer を主な強みとして評価しました。この AI 向けに最適化されたインフラストラクチャは、1 ドルあたりのパフォーマンスを大幅に高めるように設計されています。

大規模なコンピューティングクラスタは、データを提供するストレージシステムの性能によってその効果が左右されます。Google Cloud Managed Lustre は、新しい C4NX インスタンスと Hyperdisk Exapools を活用して、現在 10 TB/秒の帯域幅を実現しています。これは、他のハイパースケーラーの最大 20 倍の速度です。一方、Rapid Bucket は、1 秒あたり最大 2,000 万回のオペレーションでオブジェクトストレージを変革し、大規模なトレーニングチェックポイントとリカバリーをほぼ即座に実現します。
Google の Virgo Network は、複数のデータセンターサイトにわたって 100 万個を超える TPU をトレーニングクラスタに接続できる、または複数のサイトにわたって 最大 96 万個の GPU をパフォーマンスを低下させることなく接続できる、高帯域幅のスケールアウトファブリックを提供します。これにより、グローバルに分散されたインフラストラクチャが統合されたスーパーコンピュータに変わります。
GKE Inference Gateway は、LLM 対応ルーティング、キャッシュ保存、llm-d の分離型サービング機能を組み合わせることで、本番環境でモデルをほぼゼロのレイテンシでスケールし、スループットを最大 40% 向上させながら、サービング費用を最大 30% 削減します。

事実上規模を問わず流動的なインフラストラクチャ上で AI を実行

エージェントの時代において、インフラストラクチャは硬直的、静的な制約であってはなりません。ビジネスの優先順位の変化に適応し、需要に応じてスケールアップし、エージェントがアイドル状態のときはゼロまでスケールダウンしながら、一貫した信頼性の高いパフォーマンスを提供する、インテリジェントなリソースでなければなりません。AI Hypercomputer では、次のことが可能です。

よりスマートかつ迅速なトレーニングを行うために Cluster Director と Google Kubernetes Engine を使用し、最大 130,000 ノードまでスケールアップできます。同時に、TPU 8t と、Google DeepMind と共同設計されたソフトウェア、統合されたオープンソースフレームワーク（JAX から Pathways、Pallas まで）を組み合わせて使うことで、各アクセラレータから最大 97% の生産性（Goodput）を引き出すことができます。
GKE Agent Sandbox を使用して、安全で低レイテンシのエージェント実行を可能にします。エージェントはスケールする必要があるため、GKE Agent Sandbox はエージェントのバーストを検知して迅速に対応できます。クラスタごとに 1 秒あたり最大 300 個のサンドボックスをプロビジョニングし、エージェントがアイドル状態になると即座にスケールバックして、コンピューティング費用を最適化します。
マルチクラウド、エッジ、オンプレミス環境にわたって分散されたエンタープライズワークロードと AI ワークロードを一貫して実行します。これには、クロスクラウドネットワークと Cloud WAN を使用します。このアプローチにより、1,000 万キロメートル以上のファイバーと 200 以上の国と地域にまたがる Google のプライベートグローバルバックボーン全体で、低レイテンシのポリシー主導の接続が実現し、パブリックインターネットルーティングよりも最大 40% 高いパフォーマンスが得られます。

AI Hypercomputer で次のステップへ

フロンティアモデルから数十億のユーザーがいるアプリケーションまで、AI Hypercomputerは、AI のパフォーマンス、デベロッパーの生産性を高めながら費用を削減するために必要な専用ハードウェア、オープンソフトウェア、柔軟な使用量モデルを提供します。スケーラブルで手頃な価格の信頼できる AI システムを構築してきた数十年にわたる経験が、Gartner のリサーチでリーダーとして選出される形で評価されたことを光栄に思います。

2026 Gartner Magic Quadrant™ for AI Infrastructure のコピーを Google のウェブサイトから無料でダウンロードできます。

-AI およびコンピューティングインフラストラクチャ担当バイスプレジデント兼ゼネラルマネージャー、Mark Lohmeyer

IDC: 適切なネットワーキングアプローチがエージェント型 AI の基盤となる理由

Fri, 24 Jul 2026 01:00:00 +0000

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

編集者注: 今回は、IDC の「2026 AI in Networking Special Report Survey」の結果についてお話を伺います。このレポートは、組織におけるエージェント型 AI の台頭を支えるネットワーキングインフラストラクチャに関する企業の懸念事項について、Google Cloud が調査を委託したものです。

多くの企業が AI の試験運用を急速に進めていますが、試験運用から本番環境への移行は依然として不均一な状況にあります。AI モデルが重要なことは変わりませんが、IDC の調査によると、試験運用から本番環境への移行におけるボトルネックはインフラストラクチャを中心としたものであり、コアネットワーキングに関する懸念が AI プロジェクトの遅延や中止の主な要因の一つとして浮上しています。IDC の「2026 AI in Networking Special Report Survey」の調査結果により、以下のことが明らかになりました。

32.6% の回答者がセキュリティ上の懸念を挙げている: AI ワークフローが分散され、自律性が高まるにつれて、一貫したセキュリティとガバナンスを適用することが難しくなっている。
26.8% の回答者が自動化の課題を挙げている: 手動操作や制御の断片化は、導入を遅らせ、AI 環境のスケーリングを困難にする可能性がある。
24.7% の回答者がスタッフの時間的制約や人材不足を挙げている: スキルや運用リソースの不足によって、組織が AI イニシアチブを本番環境へ移行する能力が制限される可能性がある。

エージェント型 AI では、アプリケーション、サービス、API、ツール、データソース間での分散的かつ動的なやり取りが増えるため、こうした懸念がさらに高まります。本番環境では、こうしたやり取りは、異なるエージェントフレームワーク、モデルプロバイダ、クラウド、オープンソースツール、SaaS API、内部アプリケーションにまたがることが多く、運用範囲とセキュリティ / ガバナンスの対象領域の両方が拡大します。

大規模な運用管理、セキュリティ、ガバナンスのためのネットワーキング

ネットワーキングは、エージェント間の連携を可能にする主要な要素であり、クラウド内およびクラウド間のネットワークレイヤとサービスレイヤの接続、エンドツーエンドのセキュリティ、一貫したガバナンスにおいて基礎的な役割を担います。エージェントシステムでは、ネットワーキングがよりサービス中心の厳密な制御領域へと拡張され、分散したサービス同士がどのように互いを識別し、通信し、データを安全に交換するかを管理します。一般的な AI ワークロードでも East-West トラフィックの需要は増加していますが、エージェント型 AI ではさらに複雑性が加わり、アプリケーションのワークフローにより近い場所で、より厳密なポリシー、可視性、制御を必要とする動的なやり取りを生み出します。

インフラストラクチャの観点から見ると、ネットワーキングは単なる接続機能ではありません。ネットワーキングは、インフラストラクチャプラットフォームのコントロールプレーンの一部として、ポリシーベースの制御を適用し、オブザーバビリティをサポートし、AI エージェントの活動全体で一貫したセキュリティとガバナンスを維持する役割を担います。エージェントやサービスが異なるランタイム、クラウド、デプロイモデル、運用ドメインにまたがる環境では、フレームワークレベルの制御だけでは不十分になるため、これは重要です。

このような点から、インフラストラクチャレベルのアプローチが鍵となります。これは、アプリケーションフレームワークやオーケストレーション環境に代わるものではありませんが、複雑なアーキテクチャ環境全体で、より広範かつ一貫したポリシーの実装を可能にします。エージェント型 AI がより自律的かつ分散化されるにつれ、オブザーバビリティの断片化やポリシー適用の不整合を軽減し、管理されていないシャドーエージェントの活動を抑制するために、インフラストラクチャの一部としてこれらの制御機能を組み込む必要性が高まります。クラウドインフラストラクチャの観点から見ると、このときにクラウドネットワークサービスが戦略的に重要になります。

プラットフォームベースのアプローチとベストオブブリード型アプローチとのバランスを取る

エージェント型 AI システムは、その基盤となる分散ワークフローの性質上、本質的に断片化されています。多くの企業はすでに、ビジネス要件、オープンソースコンポーネント、新たなプロトコル標準、新しいアーキテクチャパターンなど、急速に進化する状況に対応しています。このような状況において、ベストオブブリード型のポイントソリューションとプラットフォームベースのアプローチのどちらを選択するかは、イデオロギーではなく戦略に基づいて行うべきです。

特定の技術要件に対応するには、ベストオブブリードの機能が必要になる場合があります。しかし、分散したエージェント型 AI 環境全体にポイントソリューションを導入することで、ポリシーの不整合、運用の複雑化、ガバナンスのギャップを生み出す可能性もあります。IDC の調査でこのジレンマが示されています。IDC の「2026 AI in Networking Special Report Survey」でも、AI ワークロードに対するアプローチとして、プラットフォームとベストオブブリードのどちらを支持するかは意見が分かれました。回答者がプラットフォームを支持した主な理由は、セキュリティの強化（32.9%）、複雑さの軽減（27.7%）、導入の迅速化（24.2%）でした。

IDC では、バランスが重要だと考えています。プラットフォームは、AI 導入に向けた一貫した運用とポリシーの基盤を提供できますが、同時に、ベストオブブリードの機能をプラットフォームのツールセットの一部として組み込めるよう、モジュール性と拡張性も備えている必要があります。エージェント型 AI に適したプラットフォームは、オープンで柔軟性があり、進化できるものでなければなりません。また、サードパーティ製ツールやオープンソースツールとの統合をサポートし、必要なセキュリティ機能やオブザーバビリティ機能を組み込むことができ、アーキテクチャを全面的に作り直すことなく適応できる必要があります。

現在は、テクノロジーが根本から変わる転換期にあります。企業は、動的なエージェント型 AI システムを適切に管理しながら、AI の目標を確実に達成しなければなりません。このような環境において、ネットワーキングは AI インフラストラクチャの単なる接続要素にとどまらず、組織が運用管理を確立し、ポリシーを一貫して適用し、エージェントワークフロー全体を通じてエンドツーエンドの信頼を維持するための基盤となります。

エージェント型 AI システムが進化し続ける中で、それらから生じる要求にベストオブブリードのポイントソリューションだけで対応することは、もはや現実的ではありません。エージェント型 AI を大規模に運用する組織は、オープンで柔軟かつ拡張可能なインフラストラクチャプラットフォームによって支えられた、適切なネットワーキングアプローチを活用することで、一貫性と適応力があるセキュリティとガバナンスのフレームワークを実現する必要があります。

スポンサーからのメッセージ

エージェントアプリケーションの自律的で非決定論的な通信は、クラウドネイティブ時代のインフラストラクチャやガバナンスモデルでは対応できない課題をもたらします。エージェントネイティブの時代には、効果的なガバナンスとオブザーバビリティを確保しつつ、エージェントアプリケーションを本番環境で大規模に運用するためのインフラストラクチャ主導のアプローチが求められます。オープン標準に基づく拡張可能なプラットフォームは、現在から成熟期までに至るエージェント活用の取り組みを支えるうえで不可欠です。実用的なエージェントインフラストラクチャを実現するためのインフラストラクチャの要件とオープン標準については、こちらをご覧ください。

- IDC、シニアリサーチマネージャー、Taranvir Singh 氏

Google Cloud で Claude を大規模に展開: エンタープライズ本番環境向けに構築された最先端の AI

Thu, 23 Jul 2026 03:00:00 +0000

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

最先端の AI を本番環境で運用するには、アクセラレータの管理、大陸間のレイテンシの安定化、規制対象データの地域内保持、長いコンテキストを扱うリクエストの確実な処理など、多くの課題があります。Google Cloud 上の Claude は、まさにこうした課題を解決するために構築されています。

モネと「睡蓮」のように、最先端のモデルとエンタープライズプラットフォームは、組み合わせることでより大きな価値を生み出すことがよくあります。今回のケースでは、推論機能を Claude が提供し、企業がすでに利用しているマネージドインフラストラクチャ、グローバルなリーチ、コンプライアンス体制を Google Cloud が提供します。Claude の呼び出しは、他の Google Cloud サービスを呼び出すのと運用上まったく同じになります。Identity and Access Management（IAM）、VPC Service Controls、オブザーバビリティも同じであるため、推論インフラストラクチャの運用に時間を費やす代わりに、機能開発に注力できるようになります。

この投稿では、Google Cloud 上の Claude が本番環境で提供する以下の 4 つの領域について説明します。

エンジニアの負担を減らすマネージドインフラストラクチャ
世界各地のユーザーベースに対してレイテンシを低く抑え、稼働時間を長く保つグローバルエンドポイント
Google Cloud から直接継承されるセキュリティとデータ主権の管理
大規模な環境でも費用とパフォーマンスを最適化するサービングレイヤの機能

エンジニアの負担を減らすマネージドインフラストラクチャ

Google Cloud 上の Claude はフルマネージドインフラストラクチャ上で実行されるため、エンタープライズチームはクラスタの構築に時間を費やすことなく、機能の提供に集中できます。最先端モデル規模でのコンピューティングプロビジョニング、自動スケーリングロジック、ロードバランシング、フェイルオーバーはプラットフォームによって処理されます。これらは、通常であれば複数のチームがフルタイムで取り組む作業です。

Claude は、Agent Platform の Model Garden を通じて Model-as-a-Service として利用でき、標準の REST / JSON over HTTP/1.1 または HTTP/2 エンドポイントを介してすぐに使用できます。Claude の呼び出しは、他の Google Cloud サービスの呼び出しと運用上は同じです。同じ IAM ポリシー、同じ VPC 制御、同じオブザーバビリティスタック（Cloud Logging や Cloud Monitoring 経由）を利用できます。

Claude をサービングするには、AnthropicVertex クライアントを使用して、数行の Python コードを記述します。

code_block: <ListValue: [StructValue([('code', 'from anthropic import AnthropicVertex\r\n\r\nclient = AnthropicVertex(\r\n project_id="your-project-id",\r\n region="us"\r\n)\r\n\r\nmessage = client.messages.create(\r\n model="claude-opus-4-8",\r\n max_tokens=1024,\r\n messages=[{"role": "user", "content": "Analyze this system architecture."}]\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f299c784e50>)])]>

同じ AnthropicVertex クライアントが、プロンプトのキャッシュ保存、ツールの使用、構造化された出力、ストリーミング、適応型思考を処理します。バッチ予測には Vertex AI Batch Prediction を使用します。認証にはアプリケーションのデフォルト認証情報が使用され、リクエストはプロジェクトの IAM と VPC の構成を自動的に継承します。

一貫した低レイテンシと組み込みのフェイルオーバーを備えたグローバルなリーチ

単一のエンドポイントから世界中のユーザーベースにサービスを提供すると、テールレイテンシが高くなり、単一障害点が発生します。安定したパフォーマンスを維持したうえで、複数の大陸にまたがって推論インフラストラクチャを複製できる企業はほとんどありません。

Agent Platform では、Claude 向けに以下の 3 種類のエンドポイントを提供しており、それぞれが異なる本番環境の要件に対応しています。

グローバルエンドポイント: 利用可能な AI コンピューティング容量があるリージョンにリクエストをルーティングします。たとえば、us-central1 の容量に制限がある場合、トラフィックは europe-west1 や、利用可能な容量がある別のリージョンにリダイレクトされます。これは、アプリケーション側でのルーティングロジックを必要とせずに、自動フェイルオーバーと地理的なロードバランシングを行います。グローバルエンドポイントは、費用を最小限に抑えながら最大限の可用性を実現するのに最適です。
リージョンエンドポイント（us-east5 や europe-west1 など）: プロンプト、完了状況、中間状態を特定の地理的境界内に保持できるため、低レイテンシやデータ所在地の要件に最適です。
マルチリージョンエンドポイント: 単一リージョンに依存することなく、米国や EU のデータ所在地を確保できます。リージョンのエンドポイント間で動的にルーティングできるほか、リージョンの障害や容量の制約に対するレジリエンスも組み込まれています。

以下の図は、アプリケーションがこれらのエンドポイントを介して Claude にアクセスする方法と、Agent Platform のサービングレイヤがリージョンをまたいでコンピューティング AI クラスタにトラフィックをルーティングする方法を示しています。

リージョンエンドポイントとグローバルエンドポイントからの Claude モデルのサービング

マルチリージョンエンドポイントからの Claude モデルのサービング

リージョンエンドポイントからの Claude モデルのサービング

エンタープライズセキュリティとデータ主権を組み込み

金融サービス、ヘルスケア、行政といった規制対象のワークロードであっても、コンプライアンスを犠牲にしたり、利便性を手放したりすることなく、エンタープライズグレードのセキュリティとデータ主権を確保できます。しかも、「推論」という制御が最も難しいレイヤ（プロンプト、完了状況、中間状態のすべてがサービングスタックを通過するプロセス）を再設計する必要もありません。

Agent Platform 上の Claude は、Google Cloud のセキュリティポスチャーを完全に継承します。FedRAMP High および HIPAA への準拠により、政府機関、医療機関、金融サービス環境での導入が可能となります。VPC Service Controls を使用すると、Agent Platform リソースの周囲に境界を定義して、データ漏洩を防ぐことができます。IAM ネイティブのアクセス制御により、他のすべての Google Cloud リソースを保護するのと同じロールとポリシーで Claude エンドポイントを管理できます。別途 API キーを管理したり、ローテーションしたりする必要はありません。Cloud Logging と Cloud Monitoring を使用すると、トークンの使用状況、エラー率、レイテンシ、割り当て使用量を準リアルタイムで可視化できます。

上記のリージョンエンドポイントとマルチリージョンエンドポイントを組み合わせることで、規制対象のお客様は、コンプライアンス体制の再監査を行うことなく、最先端の AI を本番環境で運用できるようになります。

費用とパフォーマンスを大規模に最適化

本番環境では、費用とパフォーマンスがあらゆるアーキテクチャ上の意思決定を左右します。この両方を適切に実現するには、Claude のネイティブモデル機能と Google Cloud のサービングインフラストラクチャという 2 つのレイヤの機能が必要です。Agent Platform は両方をサポートしているため、これらを個別に管理することなく、スタック全体にわたって最適化を図ることができます。

Agent Platform で完全にサポートされる Claude ネイティブの機能

以下の機能は Claude に組み込まれているため、追加構成を行わなくても Agent Platform で利用できます。

プロンプトキャッシュ: 共有プレフィックス（長いシステムプロンプト、法的文書、コードベースなど）を保存して再利用することで、リクエストのレイテンシを最大 80%、費用を最大 90% 削減します。
サーバー送信イベントを介したレスポンスのストリーミング: トークンが生成されるたびに配信されます。これは、認識されるレイテンシが重要となるチャットインターフェースやコーディングアシスタントにとって非常に重要です。
拡張された適応型思考: Claude は複雑な多段階の問題に対して、いつ、どの程度推論するかを動的に判断できます。また、ユーザー側で思考量を直接調整することも可能なため、費用管理などに活用することもできます。高度なコード生成、数学的推論、複数ドキュメントの分析などのユースケース向けに最適化されています。
最大 100 万トークンまで拡張されたコンテキストウィンドウ（Claude Opus 4.6、Sonnet 4.6、およびそれ以降のモデル）: 長文ドキュメントの分析、大規模なコードベースの推論、マルチターンの深い会話が可能になります。

Google Cloud のサービングインフラストラクチャ

Agent Platform は、Claude のネイティブ機能に加えて、以下のような独自のサービングレイヤ機能を提供します。

バッチ予測: ドキュメント分類、コンテンツモデレーション、一括要約といった大規模なオフラインワークロードを、低優先度で非同期的に処理し、費用を削減します。
プロビジョンドスループット: ミッションクリティカルなワークロードのために専用の推論容量を確保し、パブリックトラフィックから分離することで、需要のピーク時でも予測可能なパフォーマンスを保証します。
メモリ管理とスケジューリング: 長いコンテキストを扱うリクエストに対するメモリ管理やスケジューリングは、インフラストラクチャレイヤで処理されます。

これらの 2 つのレイヤを組み合わせることで、モデルレベルの効率性からインフラストラクチャレベルの容量制御に至るまで、単一の統合プラットフォームであらゆる最適化手段を活用できるようになります。

推論からエージェントへ

Claude の推論機能を提供するのと同じインフラストラクチャが、Google Cloud の Agent Platform のエージェントレイヤを支えています。構築と登録のフローには、以下の 3 つのステップがあります。

Claude で構築する。Claude はオーケストレーションのバックボーンとして非常に適しています。拡張されたコンテキストウィンドウ、ネイティブなツール使用、適応型思考により、複数のステップからなるタスクの計画やサブエージェントへの委任を効果的に行うことができます。Model Garden から任意の Claude モデル（Opus、Sonnet、Haiku）を選択し、Agent Development Kit（ADK）を使用して Python、Go、Java、TypeScript でコードファーストの構築を行った後、Agent Runtime、Cloud Run、Google Kubernetes Engine にデプロイします。
エージェントをランタイムにデプロイする。ユースケースに応じて、Agent Runtime、Google Kubernetes Engine、GKE Agent Sandbox を選択し、デプロイしたエージェントを実行します。
A2A を介して相互運用する。Agent2Agent（A2A）プロトコルはすでに 150 以上の組織で運用されています。このプロトコルを活用することで、登録済みの Claude 搭載エージェントが、SaaS やその他のサービスプロバイダのエージェントにタスクを委任できるようになります。

この結果、Claude を基盤とするプランニングエージェントは、統合された IAM の下で完全に監査可能となり、より広範なエージェントエコシステム全体でサブタスクをオーケストレートできます。しかも、基盤となる推論機能を提供するのと同じインフラストラクチャ上で動作します。

構築を開始しましょう

Agent Platform コンソールを開き、Model Garden で Claude を有効にして、AnthropicVertex SDK を使用して最初の API 呼び出しを行います。ワークロードの要件に応じて、プロンプトキャッシュやプロビジョンドスループットのほか、その他の機能も追加できます。エージェントを利用する準備が整ったら、Agent Platform 上の Claude の詳細をご確認ください。

Claude を本番環境に大規模に導入する方法については、Google Cloud の営業担当者にお問い合わせください。

- AI および SaaS ISV 担当シニアマネージャー兼グローバルパートナーテクニカルアーキテクチャ、Schneider Larbi

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

GKE で Ray Serve LLM をスケーリング: デベロッパーエクスペリエンスを損なうことなくパフォーマンスを向上

Thu, 09 Jul 2026 00:00:00 +0000

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

LLM 推論とモデルサービングを求めるデベロッパーは、Anyscale が構築した、デベロッパーに優しい Python ネイティブの API を備えたスケーラブルなモデルサービングライブラリである Ray Serve をよく利用します。デベロッパーは、Google Kubernetes Engine（GKE）と組み合わせることで、初期のモデル開発からオンラインの本番環境でのサービングまで、要求の厳しい LLM サービングのユースケース向けに最適化された強力な統合プラットフォームを利用できます。

この柔軟性と機能セットは、以前はパフォーマンスの低下を伴うものでした。しかし現在は、Anyscale とのパートナーシップにより、Ray Serve で最大 5 倍高いスループットと 8 分の 1 のレイテンシを実現しており、使いやすさを犠牲にすることなく、最先端の分散推論の高まる需要と厳格なパフォーマンス要件を満たしています。

ボトルネックなしで推論をスケーリング

共同エンジニアリングパートナーシップを通じて、Ray Serve LLM のパフォーマンス特性を大幅に向上させる 3 つの主要なアーキテクチャ最適化手法を導入しています。

Ray Serve HAProxy インテグレーション: Ray Serve に HAProxy が組み込まれ、内部リクエストのルーティングとロードバランシングを管理できるようになりました。このセットアップにより、プロキシのオーバーヘッドが大幅に削減され、トラフィックが多い場合でも Python ランタイムが飽和状態になるのを防ぐことができます。
直接トークンストリーミングアーキテクチャ: このアーキテクチャでは、初期リクエストパスと戻りストリームが分離されます。トークンは個々のモデルレプリカからプロキシに直接ストリーミングされ、ストリーミングデータパスの Ingress ルーターを完全にバイパスしてレイテンシを短縮します。
vLLM 用の v2 Ray エグゼキュータバックエンド: vLLM 用に改良された Ray バックエンドは、Ray をデータプレーンから移動して非同期スケジューリングを可能にします。これにより、コードパスがネイティブの vLLM エグゼキュータと統合され、パフォーマンスのギャップが解消され、Ray ユーザーが最新のエンジンレベルの最適化を利用できるようになります。

GKE でのパフォーマンスのベンチマーク

また、Anyscale と協力して、NVIDIA HGX B200 システムを搭載した Google Cloud A4 VM など、次世代 AI ハードウェアを利用する GKE クラスタで、更新された Ray Serve LLM のベンチマークを実施しました。オーケストレーションとルーティングによって生じるボトルネックを特定するために、小規模で効率的なモデルである Gemma 4 E2B を実行することにしました。ベンチマークでは、新しい Ray Serve LLM を以前のパフォーマンスと比較したほか、Ray エグゼキュータを使用したプレーンな vLLM セットアップとも比較しました。

これらの技術的強化により、パフォーマンスに大きな影響がもたらされ、以前の Ray Serve 構成と比較して、スループットが最大 5 倍高く、レイテンシが 8 分の 1 になっています。

改善された Ray Serve LLM は、8 つのレプリカを持つサービングクラスタで目覚ましい改善を実証し、以前のパフォーマンスをはるかに上回るスケーリングパターンと、vLLM をネイティブに実行した場合と同等のパフォーマンスを示しましたが、Ray がもたらす柔軟性はありませんでした。

同時ユーザー数が増加するなかで、Ray は 99 パーセンタイルの最初のトークンまでの時間を短く維持しながら、スループットをスケールアップできるようになりました。これは以前は難しかったことです。今では、LLM の実務担当者が、Kubernetes で本番環境レベルのパフォーマンスを実現するために、Ray の豊富な機能とエコシステムを犠牲にする必要はなくなりました。

Ray Serve に GKE を選ぶ理由

GKE は、これらのソフトウェアの最適化を最大限に活かすための基盤となるインフラストラクチャを提供します。GKE 用の Ray オペレーターアドオンを使用すると、自動水平スケーリング、モニタリング、マルチクラスタスケーリング、組み込みのフォールトトレランスなど、Google Cloud AI アクセラレータ全体でターンキーデプロイが実現します。GKE は、分散された物理ハードウェアのオーケストレーションの複雑な部分を抽象化するため、チームは Ray を使用してモデルとアプリケーションロジックの改良に集中できます。

GKE で Ray Serve LLM を試す

デベロッパーの皆様には、最新の Ray リリース（2.56 以降）でこれらの機能強化を試して、GKE での高パフォーマンス LLM サービングの未来を体験することをおすすめします。

詳細については、以下のリソースをご確認ください。

- Google、ソフトウェアエンジニア、Spencer Peterson

- Anyscale、ソフトウェアエンジニア、Seiji Eicher 氏

レポート: GKE Inference Gateway が AI 応答を最大 92% 高速化

Wed, 17 Jun 2026 01:30:00 +0000

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

生成 AI が試験運用から大規模な本番環境へと移行するにつれ、インフラストラクチャの効率が決定的な差別化要因になります。インフラストラクチャを最大限に活用し、コストのかかるアクセラレータのアイドル時間を最小限に抑える方法の一つが、Google Kubernetes Engine（GKE）Inference Gateway の活用です。GKE Inference Gateway は、リアルタイムのモデルサーバー指標に基づいて、生成 AI ワークロードをインテリジェントにルーティングします。

従来の単純なラウンドロビン方式のロードバランシングでは、アクセラレータでのコストのかかる再計算が頻繁に発生し、ユーザーレイテンシが急増することがあります。これに対し、GKE Gateway のネイティブ拡張機能である GKE Inference Gateway は、接頭辞キャッシュやモデル対応ルーティングなどの高度な機能を活用します。すぐに処理できる状態にある適切なアクセラレータにリクエストを確実に送ることで、GKE は大規模言語モデル（LLM）のサービング方法を変革し、優れたハードウェア使用率と極めて高速な応答時間を実現します。

実際、独立したベンチマークレポートによると、GKE Inference Gateway は、次に優れたマネージド Kubernetes サービスと比べて、スループットが 15.7% 高く、待機時間が 92.8% 短く、トークン間レイテンシが 62.6% 低いという結果を示しています。このパフォーマンスにより、LLM ベースのアプリケーションは、低速で高コストなものから、高速で本番環境対応のものへと変わります。

このパフォーマンスは、GKE Inference Gateway を使用した Snap の経験とも一致しています。

「Snap では、大規模で高性能な推論を実現するため、本番環境の AI インフラストラクチャに llm-d を統合しています。接頭辞キャッシュ対応ルーティングを採用することで、最大 75～80% の接頭辞キャッシュヒット率を達成しました。llm-d がオープンソースであることにより、Envoy ベースのサービスメッシュとシームレスに統合できる点を高く評価しています。」- Snap Inc.、ソフトウェアエンジニアリング担当シニアマネージャー、Vinay Kola 氏

このブログ投稿では、GKE Inference Gateway の接頭辞キャッシュについて、例を交えながら詳しく見ていきます。また、ベンチマーク結果の詳細もご紹介します。それでは詳しく見ていきましょう。

低レイテンシ AI の秘訣: 接頭辞キャッシュ

接頭辞キャッシュは、長く繰り返し使用されるプロンプトの接頭辞に対応する KV キャッシュ（アクティベーション状態）を保存することで、LLM のパフォーマンスを最適化します。連続するユーザーリクエストで、同じシステム指示、コンテキスト、ドキュメントが共有される場合、モデルはそれらのトークンの再処理を完全にスキップできます。GKE Inference Gateway は、受信リクエストの接頭辞を読み取り、そのデータをすでにメモリに保持している特定の Pod と照合します。これにより、GPU や TPU にかかる「思考」のコストを排除し、負荷の高い推論ループをほぼ瞬時の回答へと変えることができます。

ユースケース 1: 検索拡張生成（RAG）を使用したドキュメントとコードベースの Q&A

大規模なエンタープライズリポジトリをクエリする場合、RAG を使用してドキュメントセット全体を静的接頭辞としてキャッシュに固定することで、レイテンシを追加することなく、LLM の回答を根拠に基づいたものにできます。

GKE Inference Gateway は、ユーザーから質問があるたびに、数千行に及ぶ API リファレンスや社内 Wiki を LLM に再度読み込ませるのではなく、その特定のコンテキストがすでに KV キャッシュに保持されている Pod にクエリをルーティングします。これにより、LLM はユーザーの短い動的な質問のみを計算すればよく、コストの高いドキュメントの再評価を完全に回避できます。

code_block: <ListValue: [StructValue([('code', '[静的接頭辞 - キャッシュに保持] あなたは技術ドキュメントを専門とする AI アシスタントです。以下は、このソフトウェアプラットフォームの完全な API ドキュメントです。このコンテキストを使用して、ユーザーの質問に正確に回答してください。ドキュメント内に回答が見つからない場合は、「提供されたコンテキストでは見つかりません」と答えてください。\r\n\u200b\r\n<documentation> [10,000 語以上の API リファレンスドキュメント、エンドポイント、エラーコードなど] </documentation>\r\n\u200b\r\n[動的接尾辞 - リクエストごとに変化] ユーザーの質問: Python SDK を使用して 429 レート制限エラーを処理するにはどうすればよいですか？'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f2993e37b10>)])]>

ユースケース 2: マルチターンチャット

接頭辞キャッシュを使用すると、コンピューティングコストを累積的に増やすことなく、数千もの同時セッションにわたってカスタマーサービスのやり取りを維持できます。これは、固定のシステムペルソナと中核的なビジネスルールを LLM サーバーに直接キャッシュ保存することで実現できます。

エンタープライズチャットアーキテクチャでは、基本となるシステムプロンプトと参照テーブルが、数百万件の顧客インタラクション全体で完全に同一のまま維持されます。GKE Inference Gateway は、コンテキスト対応ルーティングを使用してこうしたマルチターンの会話を処理し、繰り返し発生するトークン処理をバイパスします。これにより、トラフィックのピーク時でも chatbot は極めて高い応答性を維持できます。

code_block: <ListValue: [StructValue([('code', '[静的接頭辞 - キャッシュに保持]\r\n- システムペルソナ: あなたは、ABC Banking Solutions の親切で共感力があり、コンプライアンスに準拠した仮想アシスタント「FinBot」です。次のルールを厳守してください。1. 具体的な投資助言は決して提供しないでください。2. ユーザーが当座預金口座について質問しているのか、貯蓄口座について質問しているのかを必ず確認してください。3. 回答は 3 文以内にしてください。4. ユーザーが怒っている場合は、人間のマネージャーにつなぐことを提案してください。\r\n\u200b\r\n2026 年 5 月時点の金利表は次のとおりです。\r\n- 貯蓄口座: 年利 4.2%\r\n- 当座預金口座: 年利 0.5%\r\n- CD（12 か月）: 年利 5.1%\r\n\u200b\r\n[動的接尾辞 - リクエストごとに変化] ユーザー: 10,000 ドルを 1 年間預けた場合、いくら受け取れるのか知りたいのですが。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f29936e9a50>)])]>

GKE は他のマネージド Kubernetes ソリューションを上回るパフォーマンスを発揮

こうしたアーキテクチャ上の利点を検証するため、Principled Technologies は先日、GKE Inference Gateway を搭載した GKE と、従来のラウンドロビン方式の HTTP ロードバランシングを使用する標準的なサードパーティのマネージド Kubernetes サービスを比較した、独立したベンチマークレポートを公開しました。

同一のハードウェア（8 基の NVIDIA A100 40GB GPU）を使用し、Llama 3.1 8B Instruct の共有接頭辞ワークロードでテストした結果、2 つの Kubernetes サービスの間に大きなパフォーマンス差があることが明らかになりました。GKE は単に優位性を示しただけでなく、次の 3 つの重要な指標すべてにおいて推論効率のあり方を大きく変えました。

スループットの向上: 1 秒あたりに処理されるトークン数が 15.7% 増加し、リクエスト処理能力を高めることができます。また、同じワークロードに必要なハードウェアを削減することも可能です。
最初のトークンまでの時間（TTFT）の大幅な短縮: 待機時間が 92.8% 短縮され、インタラクティブなシナリオで、応答が始まるまでの体感時間を大幅に短縮できます。
トークン間レイテンシ（ITL）の低減: 62.6% の低減により、最初のトークン以降のトークンストリーミングがよりスムーズかつ高速になります。

図 3: 共有接頭辞のユースケースにおける Llama 3.1-8B Instruct LLM での、GKE Inference Gateway を使用した GKE とサードパーティのマネージド Kubernetes サービスの平均レイテンシ（出力トークンあたりの正規化時間）。どちらのソリューションも同じハードウェアを使用しました。出典: Principled Technologies

	GKE	サードパーティのマネージド Kubernetes サービス	GKE の利点
平均出力トークンスループット	7,169.21 出力トークン/秒	6,042.05 出力トークン/秒	出力トークンスループットが 15.7% 向上
最初のトークンまでの平均時間（TTFT）	188.36 ミリ秒	2624.73 ミリ秒	TTFT が 92.8% 短縮
平均トークン間レイテンシ（ITL）	30.20 ミリ秒	81.03 ミリ秒	ITL が 62.6% 低減

図 4: GKE Inference Gateway を使用した GKE は、標準的な HTTP ロードバランサを使用するサードパーティのマネージド Kubernetes サービスと比較して、優れた AI 推論パフォーマンスを実現しました。

生成 AI 推論ワークロードを加速させる準備はできていますか？

リアルタイムのカスタマーサポートエージェント、動的なコーディングアシスタント、サブ秒単位の不正検出モデルなどの推論ワークロードをデプロイする場合、インフラストラクチャのレイテンシがユーザーエクスペリエンスを左右します。GKE Inference Gateway は、共有プロンプトの接頭辞がアクティブキャッシュにほぼ 100% ヒットするようにすることで、LLM を低速で高コストな推論エンジンから高速で資本効率に優れた本番環境対応の強力な基盤へと変えます。

GKE Inference Gateway が生成 AI ワークロードにもたらすパフォーマンス上の優位性を確認してみませんか？ベンチマークレポートの全文はこちらからご覧いただけます。また、詳細については、こちらの解説動画をご覧ください。

Principled Technologies のシニアパフォーマンスアーキテクトである Dan Sullivan 氏に感謝いたします。

- ソフトウェアエンジニア、Bob Tian

- アウトバウンドプロダクトマネージャー、Susan Wu

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

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

GKE 上の Agent Sandbox の一般提供開始のお知らせと Agent Substrate のご紹介

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

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

AI は、単純なチャットインターフェースから、関数呼び出し、コード実行、持続的なターミナル使用が可能な自律型エージェントへと短期間で変化しました。しかし、これらの機能を安全にオーケストレートするには、エージェントにインテリジェンスだけでなく、コードを実行するための堅牢かつ安全でスケーラビリティに優れたコンピューティング環境も必要となります。

2025 年 11 月の KubeCon NA で GKE Agent Sandbox のプレビュー版を発表後、コミュニティでの導入は急速に進みました。Google Kubernetes Engine（GKE）上のサンドボックス数は 5 か月足らずで 16 倍以上に増加しました。

Google の主要なお客様である Langchain と Lovable をはじめ、その他多くのお客様が、数百万のエージェントを迅速に本番環境にデプロイしています。Agent Sandbox は、その発表以来、新しいプロジェクトから、安定した API を備えた成熟したプロダクトへと急速に進化しました。この安定性により、現在はより広範なエージェントエコシステムへの統合が促進され、重要なインフラストラクチャレイヤとして機能するようになっています。

この投稿では、この勢いをさらに加速させる次の 2 点についてお知らせします。

GKE Agent Sandbox の一般提供開始。これは、エージェントワークロードのための安全でスケーラブルな基盤となります。
新しいオープンソースプロジェクト、Agent Substrate のご紹介。これはエージェントインフラストラクチャの密度を限界まで高めることを目的としたものです。

安全で低レイテンシの実行を大規模に実現する

Agent Sandbox は、Kubernetes 上に構築されたオープンソースのクラウドネイティブな実行環境であり、AI エージェント固有のニーズに特化して設計されています。ビルダーが独自のインフラストラクチャ上で、信頼できないロジックを、業界最高水準のスピードと効率性で安全かつ確実に実行できるよう支援する基盤のインフラストラクチャを提供します。

今回のリリースでは、最新のエージェントワークロードの主な要件に対応します。

Pod スナップショットでアイドル状態のコンピューティングを削減: エージェントは、バースト性の高い短いサイクルの後に長いアイドル期間が続くことがよくあります。GKE Agent Sandbox は、エージェントの実行を続けるために貴重なコンピューティングリソースを無駄にしないために、Pod スナップショットと統合してアイドル状態のエージェントワークロードを一時停止し、リクエストに応じて数秒で再開します。
低レイテンシのサンドボックスプロビジョニング: リクエストごとに新しいサンドボックスインスタンスを初期化していると、数秒のコールドスタートレイテンシが不必要に発生します。GKE Agent Sandbox には、ウォームプールが統合された Sandbox API が採用されています。Agent Sandbox API に統合されたこのウォームプールにより、GKE はクラスタごとに 1 秒あたり 300 個のサンドボックスを 1 秒未満のレイテンシで割り当てることができ、割り当ての 90% が 200 ミリ秒以内に完了します。
費用対効果の高いウォームプール: GKE Agent Sandbox のウォームプールでは、サンドボックスの起動レイテンシを最小限に抑えるために、事前プロビジョニングされたレプリカが常に準備されています。サンドボックスウォームプールの維持費用を最小限に抑えるため、Agent Sandbox はスタンバイ容量バッファ（一時停止された VM）と統合され、一時停止されたサンドボックスのコールドプールから、わずかな費用で迅速にウォームプールを補充できるようになっています。
堅牢なセキュリティと分離: Agent Sandbox は gVisor とデフォルト拒否の Kubernetes ネットワークポリシーにネイティブに対応しています。Agent Sandbox は、Kata Containers などのオープンソースサンドボックス用のプラグ可能なインターフェースを提供しているため、ユーザーはカーネルの分離をカスタマイズできます。

コンピューティングの需要が高まり続けるなか、このリリースにより、お客様は幅広い Google Cloud コンピューティングオプションを利用できるようになります。GKE Agent Sandbox は、Axion プロセッサで実行した場合、同等のハイパースケーラークラウドプロバイダと比較して最大 30% 優れたコストパフォーマンスを実現します。

エージェントインフラストラクチャにおける次の革新的な一歩: エージェント型ワークロードは、数千万から数億のインスタンス数にスケールアップしながら、それと同時に、人間による操作、イベント、トリガーを待ってアイドル状態になることが増えています。こうしたワークロードでは、引き続きカーネルとネットワークの強力な分離が求められるため、高密度なスケジューリングが課題となっています。このレベルのスケールと迅速な一時停止と再開への対応により、Kubernetes コントロールプレーンは限界に達しています。そのため、Google は、超大規模エージェントのパフォーマンスと密度に関するニーズに対応することを目的とした新しいオープンソースプロジェクトである Agent Substrate をスタートさせました。

Agent Substrate は、準備されたコンピューティング容量（もちろん Kubernetes で実行）にリアルタイムでエージェントを移動させたり、そこから別の場所に移動させたりする新しいレベルの抽象化を採用しています。Agent Substrate は、Agent Sandbox のコアとなる安全なランタイム機能とスナップショット機能を、Kubernetes の一部の制限を回避するように設計された最小限のコントロールプレーンと組み合わせるもので、それ以外の部分は変わりません。

これにより、Agent Substrate はクリティカルパスを最適化して、より高いスケールと効率でレイテンシを低減できます。標準の Kubernetes は数千の長時間実行サービスを処理するように最適化されていますが、Agent Substrate は、標準のコントロールプレーンでは処理しきれない、数百万に及ぶ 1 秒未満のツール呼び出し向けに設計されています。Agent、Agent Harnesses、そして新しい Agent Executor プロジェクトを含む Agent Runtime に最適な基盤となります。

Agent Substrate の目標は、より迅速な移動と、より大きなスケールのために、あらゆる可能性を模索することです。このレベルのスケールと効率性を実現するには、現在のコンピューティングインフラストラクチャの限界を押し広げる必要があり、あらゆる可能性を検討する必要があります。その一つとして、スケジューラの中核にデータの局所性を組み込み、エージェントの状態とスケジューリングを連携させて、オーバーヘッドをミリ秒単位で可能な限り削減する取り組みがあります。

オープンな環境で未来を築く

Kubernetes の初期には、同様の課題に取り組む多様なコントリビューターからのフィードバックと視点が、プロジェクトを成功に導くために不可欠でした。エージェントインフラストラクチャも同様の転換点にあると Google は考えています。これから、徹底的にオープンで共同的なイノベーションの威力を再現し、エージェントインフラストラクチャの未来を共に築いていきたいと願っています。オープンな環境で Agent Substrate プロジェクトを始動させることで、コミュニティの皆様に、この重要な次世代のインフラストラクチャの設計と構築へのご協力をお願いしたいと思います。

使ってみる

自律型エージェントの未来に向けて、スタックの重要なレイヤの構築を継続できることを嬉しく思います。ぜひ Agent Sandbox をワークロードにご活用ください。また、オープンソースコミュニティに参加して、エージェントネイティブインフラストラクチャの次のフェーズとなる Agent Substrate でコラボレーションしましょう。

GKE で Agent Sandbox を試す
Agent Sandbox のオープンソースコミュニティに参加して協力する
Agent Substrate を確認する

- GKE プロダクトマネージャー Brandon Royal

- GKE ソフトウェアエンジニア Tim Hockin

AI Edge Portal を使用してオンデバイス LLM のベンチマークと最適化を行う

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

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

LLM は小規模でも高い性能を実現できるようになりましたが、スマートフォンなどのエッジデバイスへのデプロイは依然として大きな課題です。現在、デベロッパーは、アクセラレータ、オペレーティングシステム、無数のシステムオンチップ（SoC）構成の広範な組み合わせにわたって最適化を行う必要があるものの、多くの場合は少数のデバイスでの手動テストに頼っています。Google AI Edge Portal は、こうした課題の解決に役立ちます。

Google AI Edge Portal を使用すると、120 種類以上の代表的な Android デバイスタイプで ML ワークロードをテストできるため、あらゆる CPU、GPU、NPU のバックエンドにわたり、レイテンシとパフォーマンスに関する詳細な分析情報が得られます。

この投稿では、生成 AI の時代に向けて Google AI Edge Portal を拡張する 2 つの新機能、オンデバイス LLM のベンチマークとデバッグについてご案内します。これらの新しいサービスにより、デベロッパーは Android エコシステム全体で生成 AI のパフォーマンスを正確かつ効率的に最適化することができます。

120 種類以上のモバイルデバイスで LLM のベンチマーク評価を行う

ユーザーがアプリ内で LLM を対応機能を利用する際には、デバイス上で高速かつ安定したパフォーマンスを期待します。初期化時間などの一般的な課題があると、アプリがフリーズしたように見えることがあります。最悪の場合、モデルが使用可能なメモリを使い切ってしまうと、完全にクラッシュすることもあります。

Google AI Edge Portal の最新リリースでは、120 種類以上の多様な Android デバイスから構成される物理ラボで、自動化された生成 AI ベンチマークを直接実行し、これらのシナリオを具体的にテストできるようになりました。Portal は、LiteRT-LM 形式の LLM に対する CPU と GPU のベンチマークをネイティブにサポートしています。

お客様は 120 種類以上の Android デバイスで生成 AI モデルのベンチマークを行い、初期化時間、プリフィル速度、デコード速度、メモリのピーク使用量などの指標を確認できます。

Portal で生成 AI のベンチマークジョブをトリガーすると、エンドユーザーがデバイス上で AI アプリを操作する際の体験を左右する以下の重要な指標がプロファイリングされます。

指標	測定するもの	デベロッパーにとっての重要性
初期化時間	モデルをメモリに読み込むのにかかる時間を測定します。	初期化時間が長いと、アプリの起動時に遅延が発生したり、ユーザーインターフェースがフリーズしたりする可能性があります。
プレフィル速度	デバイスがプロンプトトークンを処理して最初の出力トークンを生成するまでの速度を測定します。	ユーザーが最初の回答を見るまでの初期遅延を決定します。
デコード速度	モデルが回答中にトークンを生成する速度を測定します。	出力が生成される速度を決定します。
ピークメモリ	RAM の最大使用量をモニタリングします。	特にメモリが限られたデバイスで発生しやすい「メモリ不足」によるクラッシュのリスクを検出します。

これらの分析情報により、モデルをホストできる状態のデバイスを確信を持って決定し、出荷前にデバイスターゲティングのために LLM を調整または最適化できます。

Model Explorer でパフォーマンスを簡単にデバッグする

ベンチマークが役に立つのは、確認されたパフォーマンスの問題を修正できたときです。LLM のパフォーマンスが低かった場合、複数のレイヤと数千のノードからなる複雑なグラフの中から根本原因を見つけるのは、デベロッパーにとって気の遠くなるような作業です。面倒で時間のかかる検索が必要となり、数日とは言わないまでも数時間はかかることがあります。

このギャップを埋めるために、モデルグラフを簡単に可視化して比較できる機能を Portal に追加しました。ネイティブに統合されたグラフ可視化ツールである Model Explorer を使用すると、特定のノードを検索して見つけたり、同じタブでモデルを並べて比較したり、テンソルの形状を表示したり、入力と出力をトレースしたりできます。また、チームによるデバッグをさらに迅速化するために、特定のビューのスクリーンショットを作成して、Google Cloud で共同作業者と直接共有する機能も追加しました。

こうした可視化は、最適化の対象を特定する最も効果的な方法の一つです。

変換: Model Explorer の 2 つのビューの比較ツールを使用すると、変換の異常を簡単に特定できます。このインターフェースでは、特定のレイヤを選択的に展開または折りたたむことで、複雑なモデルアーキテクチャを走査し、内部の依存関係と構造ノードを細かい粒度で分析できます。
量子化: Model Explorer は、量子化がパフォーマンスを損なう可能性がある特定のオペレーションを検出するのに役立ちます。エラー指標を使用してレイヤを並べ替えることで、精度低下を特定し、レイヤごとの詳細なデータにアクセスするとともに、さまざまな量子化戦略を評価して、モデルのフットプリントと出力品質の最適なバランスを実現できます。
最適化: Model Explorer を使用してハードウェアの互換性を可視化し、オペレーションをレイテンシ別に整理して、異なるハードウェアアクセラレータ間でオペレーションごとのパフォーマンスを詳細に比較できます。

Model Explorer では、モデルグラフを確認し、特定のレイヤを検索し、モデルを並べて比較して、パフォーマンスをデバッグできます。

今すぐオンデバイス LLM のベンチマークを開始する

オンデバイス LLM の時代が到来した今、ベンチマークにおける重要なギャップを埋め、現在、販売中の何千種ものスマートフォンに AI の機能を提供するお手伝いができることを嬉しく思います。これらの最新機能をご利用になるには、こちらの登録フォームからお申し込みください。

Google AI Edge Portal は現在、許可リストに登録されている Google Cloud のお客様を対象に限定公開プレビュー版として提供されています。限定公開プレビューの期間中は無料でご利用可能で、プレビュー版の利用規約が適用されます。現在、許可リストに登録されているすべてのお客様は、自動的に新機能にアクセスできるようになります。

Google AI Edge Portal を使用して、皆様がどのような生成 AI 機能を幅広いデバイスにデプロイできるようになるのか楽しみにしています。

^{このリリースの拡張を可能にした次のチームメンバーと協力者の貢献に感謝します。Akshat Sharma、Ami Kubota、Charlie Xu、Chunlei Niu、Cormac Brick、Derek Bekebrede、Eric Yang、Jing Jin、Kathleen Low、Matthias Grundmann、Marissa Ikonomidis、Na Li、Ram Iyengar、Sachin Kotwani、Sommayah Soliman、Tenghui Zhu、Xiaoming Hu、Zi Yuan}

- Google プロダクトマネージャー、Derek Bekebrede

Cloud Storage Rapid: AI と分析のための超高速化されたオブジェクトストレージ

Fri, 22 May 2026 03:00:00 +0000

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

Google Cloud Next ’26 において、Google は AI や分析などのデータ集約型ワークロード向けのオブジェクトストレージ機能ファミリーである Cloud Storage Rapid を発表しました。Cloud Storage Rapid は登場時点で、高パフォーマンスのゾーンオブジェクトストレージサービスである Rapid Bucket（旧称: Rapid Storage）と、オンデマンドで読み取りを高速化し、既存のバケットのワークロードのコンピューティングとデータをコロケーションする Rapid Cache（旧称: Anywhere Cache）で構成されています。

Cloud Storage Rapid: AI と分析のための超高速化されたオブジェクトストレージ

組織が AI を中核に据えて構築を進めるなか、Google は次世代の要請に応えるために Cloud Storage Rapid を開発しました。チームは、数兆個のパラメータを持つモデルをトレーニングし、グローバル規模で推論をデプロイし、膨大な量のエンタープライズデータについて推論する自律エージェントを構築しています。GPU や TPU といったアクセラレータが注目を浴びがちですが、それらには極めて重要な依存関係があります。それがストレージです。

ストレージは、トレーニング中にアクセラレータにデータを供給するエンジンであり、リアルタイム推論を応答性の高いものにする高速アクセスレイヤです。しかし、モデルの規模が大きくなるにつれて、ストレージのパフォーマンスがボトルネックになる可能性があります。AI / ML クラスタがデータの読み取りを待機したり、チェックポイントの書き込みを停止したりするたびに、有用な作業を行っていない高価なコンピューティングサイクルに対して料金を支払うことになります。

これまで、AI / ML の実務担当者は、ニッチなゾーンストレージシステムの専門的なパフォーマンスと、Google Cloud Storage のようなグローバルオブジェクトストアの信頼性とスケーラビリティのどちらかを選択する必要がありました。多くのデベロッパーは、Cloud Storage のシンプルさ、スケーラビリティ、信頼性、費用対効果を高く評価していますが、AI 時代の進展に伴い、より負荷の高いワークロードを Cloud Storage に投入し、何千もの GPU や TPU を使用してトレーニングや推論のワークロードを実行しています。従来のオブジェクトストレージでは対応できないパフォーマンスの転換点に達しているのです。Rapid ファミリーは、コンピューティングワークロードを高パフォーマンスのゾーンストレージと直接コロケーションするための複数のオプションを提供します。これにより、アクセラレータをブロックする可能性のある I/O ボトルネックを最小限に抑え、GPU と TPU をフル稼働させて生産性を維持できます。このブログ投稿では、Cloud Storage Rapid の機能について詳しく見ていきましょう。

Rapid Bucket

Rapid Bucket（一般提供）は、Cloud Storage が大規模な生成 AI、分析、その他の高パフォーマンスワークロードの進化する需要に対応できるよう支援します。これは、Gemini や YouTube を支える Google の分散ストレージシステムである Colossus を活用することで可能になっており、専用のオブジェクトストレージゾーンバケットにおいて、膨大な読み取り / 書き込みパフォーマンスと超低レイテンシを実現します。

超高速パフォーマンスブロック型ストレージのミリ秒未満のレイテンシ、並列ファイルシステムのスループット、オブジェクトストレージのスケーラビリティと使いやすさを兼ね備えた Rapid Bucket は、お客様がよくご存じの Cloud Storage と同じ環境で高パフォーマンスを提供します。

主な機能は次のとおりです。

超低レイテンシ: 最大 2,000 万の秒間クエリ数とミリ秒未満のレイテンシを実現します。
優れたスケーラビリティ: Rapid Bucket は、単一の Rapid ゾーンバケットから 15 TB/秒以上の合計読み取りスループットを実現します。
新しいセマンティクス: ネイティブな追加、無制限のリーダー（書き込み中も可能）、ベクトル化された読み取りなどの新機能により、パフォーマンスを向上できます。

AI と分析向けに最適化Rapid Bucket は、AI / ML データ準備、トレーニング、チェックポイント処理、バッチおよびストリーミング分析処理、分散データベースアーキテクチャの最適化など、さまざまな要求の厳しいシナリオで使用できます。

主な利点は次のとおりです。

アクセラレータ使用率の最適化: Rapid Bucket を使用すると、マルチモーダルトレーニング実行で GPU ブロック時間が 50% 削減され、データ読み込みが最大 2.5 倍高速化されることが確認されました。
高速なチェックポイント処理: Rapid Bucket を使用すると、従来のオブジェクトストレージと比較して、最大でチェックポイントの復元が 5 倍、書き込みが 3.2 倍高速化されます。これにより、ワークロードの中断からの復旧が迅速になり、アクセラレータ時間の無駄が最小限に抑えられ、全体的な効率が向上します。

Rapid Bucket によりチェックポイントの復元が最大 5 倍高速化

Rapid Bucket により、チェックポイントの書き込みが最大 3.2 倍高速化

Rapid Bucket の使用を開始するには、こちらをご覧ください。

Rapid Cache

Cloud Next ‘25 で最初に発表された Rapid Cache は、データ準備、トレーニング、推論用のバースト性の高いモデルの読み込みなど、AI / ML ワークロードの帯域幅を高速化し、コードを変更することなく、既存のバケットに対して 2.5 TB/秒の合計読み取りスループットを実現します。推論ワークロードの場合、Rapid Cache を使用すると、モデルの読み込みが最大 2.1 倍（114%）高速化され、TCO が 47% 削減されることが確認されています。

マルチリージョンバケットと組み合わせることで、単一のバケット名前空間を維持しながら、地理的なリージョン間に分散された GPU と TPU に柔軟にアクセスできます。これにより、バケット間のデータ移動を手動でオーケストレートする必要がなくなり、ゾーン内にコロケーションされた高パフォーマンスのメリットを享受できます。

新機能: 書き込み時の Rapid Cache 取り込み世界最大規模の最先端 AI / ML ラボのお客様から、チェックポイントの復元ワークロードや、トレーニングにフィードするデータ準備パイプラインなど、書き込み直後の読み取りを高速化する方法を探しているという声が寄せられました。以前は、データをキャッシュに保存するには、まず読み取りを行って取り込みをトリガーする必要があり、その際は、標準のパフォーマンスでバケットから直接提供されていました。

Rapid Cache の新しい書き込み時の取り込み機能は、Cloud Storage バケットへの書き込みと同時に Rapid Cache にデータを書き込むことで、この問題を解決します。このプロアクティブなアプローチにより、最初のキャッシュミスのペナルティが排除され、ワークロードは最初の読み取りで即座にキャッシュヒットの恩恵を受けることができます。これにより、チェックポイントの復元時間が最大 2.2 倍高速化され、トレーニングクラスタが中断からより迅速に復元できるようになります。

書き込み時の取り込みを有効にするには、既存の Rapid Cache の取り込み基準を変更するだけです。

Rapid Cache のシンプルさとパフォーマンスは、爆発的な導入につながっています。一般提供開始からわずか 1 年で、お客様は数千の Rapid Cache をデプロイし、デプロイされたキャッシュは 20 倍に増加しました。実際、Rapid Cache は Cloud Storage のグローバル外向きトラフィックの最大 20% を処理しています。最先端の AI / ML を利用するお客様は、ワークロードを Rapid Cache にデプロイしています。その一例が Anthropic です。同社は Rapid Cache を使用して、単一のゾーンに TPU とデータを配置し、最大 2.5 TB/秒の動的にスケーラブルな読み取りスループットを提供することで、クラウドワークロードの復元力を向上させています。

事例紹介: Thinking Machines LabThinking Machines Lab は、AI の研究とプロダクト開発を行う企業です。その使命は、適応性とカスタマイズ性に優れた AI システムを構築し、誰もが独自のニーズや目標に合わせて AI を活用できる知識やツールにアクセスできる未来を築くことです。

Next ‘26 では、Thinking Machines Lab のテクニカルスタッフである James Sun 氏が、セッション「Cloud Storage Rapid: AI と分析のための高速オブジェクトストレージ」に登壇し、Thinking Machines Lab が大規模な高パフォーマンスストレージのために実行する、データを大量に消費する AI / ML ワークロードのニーズについて発表しました。

Thinking Machines Lab は、Dataflow、Kafka、Spark でのデータ処理、マルチモデルトレーニング、オープンソースモデルのファインチューニング用の柔軟な API である Tinker のサービングなど、さまざまなワークフローを実行しています。Sun 氏の説明によると、Thinking Machines Lab のワークロードは Google Cloud Storage で実行されています。このようなデータ集約型の AI / ML ワークロードを大規模に実行すると、インフラストラクチャに大きな課題が生じます。

1 つ目の課題は、ハブアンドスポーク型のデータアーキテクチャの管理です。このアーキテクチャでは、データ処理ハブは 1 つのプライマリリージョンに配置され、トレーニング GPU は複数のリージョンに分散されます。これまで、手動によるデータの移動とライフサイクル管理は、運用上の大きな懸念点となっていました。さらに、Thinking Machines Lab のワークロード（データ準備や事前トレーニングのワークフローなど）は、マルチモーダルデータセットを準備するために大規模な Spark ワークロードに依存しており、コールドからホットに瞬時に急増することがよくあります。以前は、このような急増により、データ処理と読み込みが停滞し、重要なトレーニングサイクルが中断されるという、破壊的な 429 エラーが発生していました。

これらのボトルネックを最小限に抑えるため、Thinking Machines Lab は AI / ML パイプライン全体に Rapid Cache を統合し、良好な結果を得ました。

「Rapid Cacheは、当社の AI / ML データインフラストラクチャの中核的な基盤となっており、データの準備から、事前トレーニング、実際のトレーニング、モデルの読み込みに至るまで、重要なワークフローを支えています。重要な帯域幅のシールドおよびブースターとして機能し、迅速なイノベーションに必要なオンデマンドの高帯域幅と一貫した安定性を提供してくれるため、当社はフリート全体でデータ集約型のワークロードを妥協することなくスケールできます。」- Thinking Machines Lab、テクニカルスタッフ、James Sun 氏

要約すると、Cloud Storage と Rapid Cache によって、Thinking Machines Lab は次のメリットを得ています。

簡単、即時、スケーラブル、オンデマンドの帯域幅: チームは現在、1.8 TB/秒を超える安定した読み取りスループットのピークを達成しています。
安定性の向上: Rapid Cache により、テールエンドのレイテンシと 429 エラーが大幅に削減され、マルチモーダルトレーニングに必要な一貫したパフォーマンスが提供されます。
フリート全体のスケーラビリティ: マルチリージョンバケットと組み合わせることで、データ集約型ワークロードをフリート全体にわたってスケールできるようになりました。手動でデータを移動する手間をかけずに、急速に拡大するコンピューティング規模の需要に対応しながら、ゾーンでコロケーションされたストレージによる高パフォーマンスのメリットを享受できます。
運用効率: 階層型名前空間（HNS）の使用により、ディレクトリ名の高速変更をサポートし、クラスタをスケールアウトする際に QPS をより迅速にランプアップできるようになり、データ準備のための大規模な Spark ワークロードが最適化されました。Rapid Cache の「書き込み時の取り込み」機能により、チェックポイントの復元時にキャッシュヒットが即座に発生します。

ビジネスを加速させる最適なプロダクトをお選びください

データ準備、大規模なトレーニング、低レイテンシの推論のいずれを実行する場合でも、Cloud Storage Rapid は、Cloud Storage の特徴である信頼性とスケーラビリティとともに、高いパフォーマンスを提供します。

Rapid Bucket は、Cloud Storage のスループットと秒間クエリ数が最も高く、分析、AI トレーニング、チェックポイント処理、モデル提供などの読み取り / 書き込みのユースケースでレイテンシが最も低くなります。これにより、ストレージのボトルネックを減らし、コンピューティングの利用率を高めることができます。
Rapid Cache は、コードを変更することなく、既存のバケットで読み取り帯域幅の向上とテールレイテンシの安定化を実現します。主なユースケースには、AI トレーニング、チェックポイントの復元、サービング、マルチリージョンバケットによるアクセラレータのオプションなどがあります。

Cloud Storage Rapid ファミリーの利用を今すぐ開始しましょう。

- シニアプロダクトマネージャー、Marco Abela

- シニアプロダクトマネージャー、Luigi Pontes

Next ‘26 で発表した AI ワークロードを加速するストレージイノベーション

Mon, 18 May 2026 01:00:00 +0000

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

Google Cloud Next では、ストレージスタックのあらゆるレイヤ（パフォーマンス、インテリジェンス、管理など）にわたるイノベーションを発表しました。これらは、構築する AI モデル、アプリ、エージェントと同様に、データも高速かつ有用なものにすることを見据えたものです。

利点: ストレージはもはや、単にデータを保管する場所ではありません。AI モデルのトレーニングにおいて、ストレージはデータを大量に消費するアクセラレータにデータを供給するエンジンとなります。AI 推論の際には、AI エージェントが効果的に機能するために必要なコンテキストのソースとして機能し、応答性を高めるアクセスレイヤとなります。ストレージのパフォーマンスが不足すると、アクセラレータはアイドル状態になり、エージェントの応答は遅くなり、データは AI モデルから見えない状態のままになります。

しかし、ストレージのパフォーマンスを上げるだけでは不十分であり、スマートに機能させる必要もあります。ストレージレイヤに直接統合された Google AI モデルを活用することで、単にビットを保存するのではなく、コンテンツに関する完全なコンテキストを持つデータを保存できるようになります。このスマートストレージの新時代において、元データは、さまざまなダウンストリーム AI やエンタープライズアプリケーションですぐに利用できる貴重な資産となります。

最新情報:

高性能ストレージインフラストラクチャ: 高性能オブジェクトストレージを実現する Cloud Storage の新しい Rapid ファミリーは、パフォーマンスを 10 倍向上させるとともに、Google Cloud Managed Lustre 向けに費用対効果の高い新しい Dynamic ティアを提供します。
Smart Storage: 自動化されたメタデータアノテーションと MCP を介した AI エージェントとの連携により、非構造化データの価値を引き出します。
Storage Intelligence: 構成不要のダッシュボード、集約されたアクティビティビュー、強化されたバッチオペレーションにより、データマネジメントを効率化します。
エコシステムの強化: Google Cloud NetApp Volumes、Filestore for GKE、および Google のバックアップとデータ保護のポートフォリオ全体で機能を拡張しました。

今週発表されたストレージの機能強化について詳しく見ていきましょう。

AI の進化に対応するストレージインフラストラクチャ

AI モデルのスケーリングに伴い、ストレージからコンピューティングレイヤに十分な速度でデータを転送することがボトルネックになる可能性があります。新しいストレージ機能により、パフォーマンスがストレージレイヤに直接組み込まれるため、総所有コスト（TCO）が削減され、アクセラレータを最大限に活用し続けることができるようになります。

Cloud Storage RapidCloud Storage のようなクラウドベースのオブジェクトストレージは、スケーラブルで費用対効果に優れていますが、ボトルネックが発生すると AI ジョブが停止し、高価なコンピューティングサイクルが無駄になる可能性があります。トレーニングクラスタが読み取りを待機したり、チェックポイントの書き込みが停止したりするたびに、有用な作業を行っていないアクセラレータに対して料金を支払うことになります。

Cloud Storage Rapid は、AI インフラストラクチャの設計において抜本的な転換をもたらします。オブジェクトストレージの信頼性を優先するか、AI 専用ストレージシステムの高い性能を優先するかといった取捨選択をする必要がなくなるからです。Cloud Storage Rapid を使用すると、業界をリードする耐久性、大規模な分散型スケール、費用対効果の高いオブジェクトストレージの自動階層化を活用しながら、極めて高いスループット、頻繁な I/O、超低レイテンシを実現できます。PyTorch と JAX にネイティブに統合された Cloud Storage Rapid は、人気のある AI / ML エコシステムフレームワークですぐに使用できるよう最適化されているため、データ準備、トレーニング、推論のワークロードを高性能かつ信頼性の高い基盤上で実行できます。

Cloud Storage Rapid ファミリーには、Rapid Bucket と Rapid Cache の 2 つのサービスがあります。

Rapid Bucket はすでに一般提供を開始しています。Gemini や YouTube を支える Google の分散ストレージシステムである Colossus を活用することで、単一のゾーンバケットにおいて 15 TB/秒を超える帯域幅、1 秒あたり 2,000 万件のリクエスト、1 ミリ秒未満のレイテンシを実現します。高性能な gRPC と S3 互換 API を介してアクセスできる Rapid Bucket は、マルチモーダル学習におけるアクセラレータ使用率の向上により、GPU ブロック時間を 50% 削減し、データ読み込みを 2.5 倍高速化します。従来のオブジェクトストレージと比較して、チェックポイントの復元は 5 倍、チェックポイントの書き込みは 3.2 倍高速化され、ワークロードの中断や GPU の無駄な時間を削減します。

Rapid Bucket により、チェックポイントの書き込みが 3.2 倍、復元が 5 倍高速化

Rapid Cache（旧称 Anywhere Cache）は、推論用のモデルの読み込みなど、バースト性の高いワークロードの帯域幅を高速化し、コードを変更することなく、既存のバケットに対して 2.5 TB/秒の合計読み取りスループットを実現します。新しい書き込み時取り込み機能により、チェックポイントの復元が最大 2.2 倍高速化され、トレーニングクラスタが中断からより迅速に復元できるようになります。Rapid Cache は、そのシンプルさとパフォーマンスの組み合わせにより、最先端の AI / ML を利用する Thinking Machines Lab のようなお客様に広く採用されています。「Rapid Cacheは、当社の AI / ML データインフラストラクチャの中核的な基盤となっており、データの準備から、事前トレーニング、実際のトレーニング、モデルの読み込みに至るまで、重要なワークフローを支えています。重要な帯域幅のシールドおよびブースターとして機能し、迅速なイノベーションに必要なオンデマンドの高帯域幅と一貫した安定性を提供してくれるため、当社はフリート全体でデータ集約型のワークロードを妥協することなくスケールできます。」- Thinking Machines Lab、テクニカルスタッフ、James Sun 氏

Google Cloud Managed LustreLustre 並列ファイルシステムは、AI のトレーニングと推論のワークロードで高スループットとミリ秒未満のレイテンシを必要とする組織にとっての業界標準となっています。世界中の AI ラボや HPC センターから信頼を得ており、数千のアクセラレータに同時にフィードでき、高負荷状態でも飽和状態を維持できることが評価されています。Google Cloud Managed Lustre は、その機能をフルマネージドサービスとして提供します。Next ‘26 では、クラウドで利用できるマネージド Lustre サービスの中で最も高いパフォーマンスを発揮できることを紹介しました。

Managed Lustre は現在、最大 10 TB/秒のスループットを実現しています。これは昨年比で 10 倍の向上であり、単一インスタンスにおける他のハイパースケーラーのマネージド Lustre サービスと比較して 4～20 倍高い数値です。C4NX VM と Hyperdisk Exapools を活用した Managed Lustre は、他の Google Cloud ストレージソリューションと比較して、チェックポイントの書き込みと復元が 2.6 倍高速です。

新しい Dynamic ティア（$0.06/GB-月）は、トレーニングやチェックポイント処理といった負荷の高い AI ワークロードに必要な低レイテンシのパフォーマンスを提供します。オブジェクトベースのキャッシュに依存するのではなく、永続ディスクからデータをサービングすることで、パフォーマンスの急激な低下をなくし、データの応答性を維持し、アクセラレータの生産性を確保します。単一の SKU により、従来のデータ階層化に見られる複雑な要素を排除し、シンプルで予測可能な料金体系を実現します。

「Managed Lustre を統合することで、典型的なオンボーディングのボトルネックが解消され、推論ワークロードを迅速に実行できるようになりました。この高スループット、低レイテンシのストレージにより、B200 GPU では完全に飽和状態が維持され、H200 と比較して LLM の推論で大幅なパフォーマンスの向上を実現できています。当社のお客様にとって、このパフォーマンスは、従来よりもはるかに低いレイテンシで複雑な推論を処理できる、より高速で応答性の高い AI エージェントの実現へと直結します。」 - Salesforce、ソフトウェアエンジニアリング PMTS、Lavnaya Karanam 氏

Smart Storage: AI 時代のコンテキスト

Cloud Storage のようなオブジェクトストレージシステムの魅力は、長らくそのシンプルさにありました。システムはオブジェクトの名前、サイズ、作成日時を把握しています。しかし、オブジェクトの内容（参照しているエンティティ、機密性の高い個人情報（PII）が含まれているかどうか、保留中のクエリに関連しているかどうかなど）を把握するには、カスタムパイプライン、個別のデータベース、カスタムメイドの拡充システムを使用する必要がありました。

AI はこの状況を一変させました。モデルをファインチューニングするには、数百万ものコーパスの中から適切なオブジェクトを最初から選択する必要があります。エージェントを構築するには、それぞれの意思決定において適切なコンテキストを取得することが必要です。コンプライアンスの義務を果たすには、法的責任が発生する前に、すべてのファイルの内容をあらかじめ把握しなければなりません。いずれの場合も、ボトルネックとなるのは計算能力やモデルの品質ではなく、オブジェクトを大規模に記述、検索、処理できない点にあります。

昨年発表した Smart Storage は、保存されているデータと利用可能なデータのギャップを埋めることを目的としています。Cloud Storage に直接組み込まれており、すべてのオブジェクトを自己記述型にします。このたび、Smart Storage に以下の機能を追加しました。

自動アノテーション: カスタムアノテーションパイプラインの構築や維持管理が不要になります。Smart Storage を有効にすると、Cloud Storage は画像アノテーションなどのコンテキストを自動的に生成できるようになり、データが保存された瞬間から検出と利用が可能になります。アノテーションにかかる費用の発生は書き込み時の一度だけで、オブジェクトの存続期間中、すべてのダウンストリームシステムがそれらのアノテーションを即座に利用できます。
Cloud Storage MCP サーバー: 標準の MCP プロトコルを使用して Cloud Storage データの読み取り、書き込み、分析を行うことができます。

Smart Storage は、このたび一般提供を開始したオブジェクトコンテキストを活用して、これらの機能をはじめとするさまざまな機能を実現します。このメタデータ基盤により、すべてのオブジェクトに対して、構造化された変更可能な IAM 管理のコンテキストが追加されます。ユーザーは独自のタグや分類を作成できます。ラベル、抽出されたエンティティ、コンプライアンスシグナルは、Google のアノテーションパイプラインで自動的に付加されます。

Smart Storage を利用すれば、ML チームは、検索パイプラインを構築することなく、セマンティックな基準に基づいてトレーニング用データセットを選択できます。AI エージェントは、別の検索レイヤを必要とせずに、エンタープライズデータに基づいて推論をグラウンディングできます。

Storage Intelligence: AI に対応したデータマネジメント

データ資産が数百ペタバイト規模にまで拡大すると、ストレージ費用が想定外に急増し、数十億のオブジェクトにわたってセキュリティの盲点が増える可能性があります。これを管理するには、自社のデータに関する基本的な課題に対処するためだけでも、複数のツールを組み合わせる必要があります。

Google は昨年、統合管理エクスペリエンスを Cloud Storage に直接組み込んで提供する Storage Intelligence をリリースしました。現在、Google の最大規模のお客様の 70% に利用されており、それぞれ 500 億個以上のオブジェクトが管理されています。

Storage Intelligence では、プロジェクトや組織全体を単一のビューで把握できるほか、リージョンをまたいだバケットの再配置といった独自の機能を利用できます。こうした機能に加えて、このたび、Storage Intelligence の機能を大幅に強化しました。

新しい構成不要のダッシュボード: 費用の異常を即座に把握できるほか、Security Command Center のデータセキュリティポスチャー管理（DSPM）データガバナンス機能が統合されているため、Cloud Storage 全体にわたって重大なセキュリティの脆弱性を検出できます。設定作業は一切不要です。
分析情報データセットの新しいオブジェクトイベントおよびバケットアクティビティテーブル: より詳細な費用分析が可能になり、運用タスクを加速できます。これらの分析情報を使用することで幅広い分析を行えます。たとえば、下り（外向き）パターンに基づいてバケット配置を最適化したり、影響を受けるオブジェクトを特定して 429 エラーを迅速にトラブルシューティングしたりできます。
バッチオペレーションの強化: 新しい ACL 変更やストレージクラスオペレーション、マルチバケットオペレーションのサポートにより、数十億のオブジェクトに対してますます容易にアクションを実行できるようになりました。

ストレージエコシステムの強化

中核となるストレージサービスに加え、データをクラウドに移行する方法や保護する方法を効率化しました。

Google Cloud NetApp Volumes: Flex Unified のリリースに伴い、NetApp Volumes ではデータセンターとクラウドを橋渡しする統合エンタープライズストレージプラットフォームが提供されるようになりました。これによって、同一のストレージプール上でブロック（iSCSI、NVMe/TCP）とファイル（NFS / SMB）の両方をプロビジョニングできます。新しい ONTAP モードでは、既存の自動化ツール（Terraform、Ansible）や ONTAP API を NetApp Volumes に直接取り込むことができます。
Filestore for GKE: Google Kubernetes Engine（GKE）で AI ワークロードを構築する際、100 GiB 程度の小規模な共有から始めることができます。容量と IOPS は個別にスケールできます。また、Colossus 分散ファイルシステムとの緊密な統合により、スケーリング機能とエンタープライズ機能が強化されています。
データ保護: Google Cloud Backup and DR に、バックアップアセットを自律的に監査し、カバレッジのギャップを修復できるエージェント型 AI 機能を追加しました。すでに一般提供されている AlloyDB と Filestore の新しいインテグレーションも利用できます。

導入の第一歩

AI の新時代を迎えるなか、ストレージ基盤には、より大規模でインテリジェントかつ自律的なモデルをサポートできることが求められています。Google Cloud のストレージプラットフォームは、高性能でインテリジェントな最新のストレージレイヤ、強化されたストレージ管理ツール、より堅牢なデータ保護基盤を備えており、これまで不可能だった方法でエンタープライズデータを理解できます。これにより、以下のようなことが可能になります。

AI データのボトルネックの解消: コンピューティングリソースを最大限に活用し、費用対効果を加速させます。卓越したパフォーマンスを提供する高スループットストレージによって大規模なトレーニングや推論に対応できるほか、高価な GPU や TPU を常に最大限に活用できます。
エージェント対応のデータ基盤の構築: カスタムパイプラインの構築から、アクティブなナレッジベースへと移行します。自己記述型オブジェクトによって、AI エージェントが手動での準備なしにデータを即座に推論できるようになります。
エクサバイト規模のデータにおける盲点の最小化: 断片化された管理ツールを、構成不要のダッシュボードとデータセットに置き換え、数十億のオブジェクトにわたる費用の異常やセキュリティリスクを即座に明らかにします。
ストレージエコシステムの活用: 移行と保護を効率化します。データセンターとクラウドを連携させ、コンテナ化されたアプリケーションをスケールし、エージェント型 AI でデータレジリエンスを自動化しましょう。

Google Cloud Storage コンソールにアクセスしてこれらの新機能をお試しください。Cloud Storage Rapid の詳細と、Next '26 のストレージのセッションもご覧ください。

- Google Cloud、ストレージ担当 VP 兼 GM、Sameet Agarwal

- Google Cloud、プロダクト管理担当シニアディレクター、Asad Khan

AI インフラストラクチャ

Google、「The Forrester Wave™: Public Cloud Platforms, Q3 2026」でリーダーに選出

グローバル企業で実績のある共同設計インフラストラクチャを基盤に構築

セキュアで柔軟なプラットフォームでエージェントを迅速に実行

リアルタイムの企業データでエージェントをグラウンディング

新たな基準の確立: Google Cloud で次世代のテクノロジーを構築

分散 Ray クラスタに gVisor サンドボックスを導入

Ray プリミティブとしてのサンドボックス

gVisor を選ぶ理由

GKE で Ray サンドボックスを試す

AI インフラストラクチャの動的容量管理

概要

アーキテクチャの柔軟性が重要な理由

インフラストラクチャの制約を克服する方法

動的インフラストラクチャへの次のステップ

Mirendil の事例: トレーニング前後のアプリケーションに AI Hypercomputer のTPU と GPU を活用

AI 時代のデジタル主権: 制御とイノベーションの二者択一が不要に

アイドル状態のアクセラレータを最小限に抑える: llm-d での協調型タイムスライスによるネイティブ RL ジョブのインターリーブ

RL インフラストラクチャの効率化のための llm-d（全体像）

RL ループにおける効率性の課題

協調型タイムスライス（RL ジョブのインターリーブ）のメリット

タイムスライス: アーキテクチャの概要

フロー: 全体像

現在のリリースと今後の見通し

使ってみる

AI エージェントの準備は完了。では、データは？

不要な手作業を回避する

データに信頼と知識をもたらす

将来を見据える

レポート: 83%の組織がエージェント型 AI に対応するためにインフラストラクチャのアップグレードを必要としている

Google Cloud、2026 年 Gartner® Magic Quadrant™ の AI インフラストラクチャ部門でリーダーに選出

Gemini で使用されるインフラストラクチャ基盤の構築

AI Hypercomputer でコスト パフォーマンスが向上

事実上規模を問わず流動的なインフラストラクチャ上で AI を実行

AI Hypercomputer で次のステップへ

IDC: 適切なネットワーキング アプローチがエージェント型 AI の基盤となる理由

大規模な運用管理、セキュリティ、ガバナンスのためのネットワーキング

プラットフォーム ベースのアプローチとベスト オブ ブリード型アプローチとのバランスを取る

スポンサーからのメッセージ

Google Cloud で Claude を大規模に展開: エンタープライズ本番環境向けに構築された最先端の AI

エンジニアの負担を減らすマネージド インフラストラクチャ

一貫した低レイテンシと組み込みのフェイルオーバーを備えたグローバルなリーチ

エンタープライズ セキュリティとデータ主権を組み込み

費用とパフォーマンスを大規模に最適化

推論からエージェントへ

構築を開始しましょう

GKE で Ray Serve LLM をスケーリング: デベロッパー エクスペリエンスを損なうことなくパフォーマンスを向上

ボトルネックなしで推論をスケーリング

GKE でのパフォーマンスのベンチマーク

Ray Serve に GKE を選ぶ理由

GKE で Ray Serve LLM を試す

レポート: GKE Inference Gateway が AI 応答を最大 92% 高速化

低レイテンシ AI の秘訣: 接頭辞キャッシュ

GKE は他のマネージド Kubernetes ソリューションを上回るパフォーマンスを発揮

生成 AI 推論ワークロードを加速させる準備はできていますか？

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

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

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

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

ML の生産性向上

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

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

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

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

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

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

共に築く未来

GKE 上の Agent Sandbox の一般提供開始のお知らせと Agent Substrate のご紹介

安全で低レイテンシの実行を大規模に実現する

オープンな環境で未来を築く

使ってみる

AI Edge Portal を使用してオンデバイス LLM のベンチマークと最適化を行う

120 種類以上のモバイル デバイスで LLM のベンチマーク評価を行う

Model Explorer でパフォーマンスを簡単にデバッグする

今すぐオンデバイス LLM のベンチマークを開始する

Cloud Storage Rapid: AI と分析のための超高速化されたオブジェクト ストレージ

Rapid Bucket

Rapid Cache

ビジネスを加速させる最適なプロダクトをお選びください

Next ‘26 で発表した AI ワークロードを加速するストレージ イノベーション

AI Hypercomputer でコストパフォーマンスが向上

IDC: 適切なネットワーキングアプローチがエージェント型 AI の基盤となる理由

プラットフォームベースのアプローチとベストオブブリード型アプローチとのバランスを取る

エンジニアの負担を減らすマネージドインフラストラクチャ

エンタープライズセキュリティとデータ主権を組み込み

GKE で Ray Serve LLM をスケーリング: デベロッパーエクスペリエンスを損なうことなくパフォーマンスを向上

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

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

120 種類以上のモバイルデバイスで LLM のベンチマーク評価を行う

Cloud Storage Rapid: AI と分析のための超高速化されたオブジェクトストレージ

Next ‘26 で発表した AI ワークロードを加速するストレージイノベーション

Storage Intelligence: AI に対応したデータマネジメント

ストレージエコシステムの強化