AI インフラストラクチャ

AI インフラストラクチャとオーケストレーションに関する最新情報

Tue, 20 Oct 2026 02:00:00 +0000

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

9 月はスケーラビリティ月間です。世界がエージェントフリートの急増に備えるなか、Google はそのニーズに迅速かつ適切に対応できるように AI インフラストラクチャとオーケストレーションサービスを強化するとともに、ワークロードの分離とセキュリティを維持し、コストを抑えています。今回の記事では、Google Cloud のコンピューティング、ネットワーク、ストレージ、オーケストレーションのサービス全体でこれらの機能強化がどのように現れているかに加えて、お客様が Google Cloud AI インフラストラクチャを使用する新しい方法、Google の戦略に対するサードパーティの業界検証をご紹介します。

プロダクト、テクノロジー、ツールに関する最新情報

Google Kubernetes Engine の更新: GKE チームはプラットフォームのスケーラビリティの向上に全力を注いでいます。9 月には、さまざまな形や規模で改善が行われました。

新機能: エージェントワークロードに、より高密度の実行ランタイムが必要ですか？新しいオープンソースの GKE Agent Substrate は、標準的なコンテナランタイムよりも 10 倍高い密度で数百万のサンドボックスを実行できるように設計されています。また Agent Substrate は、ネイティブのゼロトラストカーネルとネットワーク分離により、1 秒あたり 500 回を超える一時停止 / 再開アクティベーションを実行しながら、500 ミリ秒未満での再開オペレーションを実現します。
プロダクトの最新情報: GKE にゼロへのスケーリング機能が組み込まれました。ワークロードをスケールダウンするために複雑なコンポーネントを構成する必要はありません。AutoscalingMetric を使用した HPA と KEP-2021 のサポートにより、その作業はすぐに自動的に行われます。詳細については、こちらのブログ記事をお読みください。
プロダクトの最新情報: さらに、GKE HPA（前述の AutoscalingMetric を使用）では、標準指標に加えてカスタム PromQL 指標に基づいてスケールアップとスケールダウンを行えるようになりました。これにより、ビジネスにとって意味のある独自の条件に従ってワークロードをトリガーできます。詳しくはこちらをご覧ください。
新機能: もう一つのスケーラビリティ機能は GKE Pod スナップショットです。これは、CPU や GPU のメモリを含むワークロードの実行状態を保存し、オンデマンドで復元できるようにするものです。内部テストによると、GKE Pod スナップショットにより、AI 推論の起動時間を最大 89% 短縮できます。詳しくはこちらをご覧ください。
新しい移行ツール: 最後に、コンテナワークロードを AWS EKS から GKE に移行したいと考えていたものの、困難で摩擦の多いエンジニアリング作業を恐れていた方のために、GKE エージェント型移行をリリースしました。これは、不安定なアドホックプロンプトに代わり、決定論的なガードレールで保護された AI 支援移行パイプラインを提供する専用のエージェントプラグインです。エージェントスキルとローカルの Model Context Protocol（MCP）サーバーを組み合わせた設計になっており、AI を使用して複雑な AWS EKS IaC と Kubernetes マニフェストを GKE ランディングゾーンに直接変換します。オンボーディングガイドを確認して利用を開始しましょう。
機能の更新: 強化学習（RL）と評価のワークロードは非常に複雑です。標準的なエージェント RL ループでは、LLM ポリシーが GPU 上でコードスニペットなどのアクションを生成し、分離された CPU サンドボックス内で実行して報酬シグナルを観察します。しかし、このループをスケールアップして数万の並列ロールアウトをサポートしようとすると、アクセラレータのアイドル状態、イメージのカーディナリティ、コントロールプレーンの飽和など、インフラストラクチャのボトルネックが発生します。そこで、RL 向けに最適化された GKE Agent Sandbox に加えて、Agent Sandbox RL オーケストレーション SDK、一般的な RL ジムやハーネスとのネイティブ連携機能を開発しました。すべて一般提供が開始されています。詳しくはこちらをご覧ください。

ストレージの最新情報: AI は大量のデータをトレーニングして作成します。そのデータは、ブロックストレージシステム、ファイルシステム、オブジェクトストア、データベースのいずれかに保存する必要があります。この重要なレイヤがエージェントの要求に対応できるよう、ストレージポートフォリオの強化を発表しました。

プロダクトの最新情報: Filestore エージェントボリュームは、エージェントワークロード向けに高パフォーマンスで柔軟な永続ファイルストレージを提供します。GKE Agent Substrate および GKE Agent Sandbox との緊密なインテグレーションにより、Filestore エージェントボリュームは、分離された専用ファイルワークスペースを GKE Agent Sandbox にミリ秒単位で自動的に割り当て、アタッチします。プレビュー版へのアクセスはこちらからリクエストできます。
新しいプロダクト: 生成 AI と RAG のデータレイヤ（Milvus、Pinecone、Qdrant、Vespa、Redis、インメモリコンテキストキャッシュなど）を実行している場合は、M4N ファミリーの VMをご覧ください。一般提供が開始されたこれらの VM は、主要なハイパースケーラーの中でコアあたりの IOPS とスループットが最高です。M4N インスタンスは、Google Cloud のカスタム Titanium オフロードアーキテクチャおよび Hyperdisk Extreme と組み合わせることで、ホストあたり合計で最大 25,000 MiB/秒（25 GiB/秒）のストレージスループットと最大 100 万 IOPS を実現します。
新しいプロダクト: もう一つの新しい Compute Engine プロダクトである Z4D の一般提供が開始され、AI / ML のトレーニングおよび推論ワークロード向けの強力なストレージソリューションとしてご利用いただけるようになりました。ベアメタルインスタンスとして構成すると、Z4D はエージェント型マイクロ VM に必要な大容量のローカル SSD（LSSD）と低レイテンシの両方を提供するため、ホストごとに数千の分離されたサンドボックスをネイティブのパフォーマンスと効率で実行できます。Z4D マシンの詳細はこちらでご確認ください。
プロダクトの最新情報: 現在の AI トレーニングや推論のパイプラインは、ほとんどのストレージ管理システムが対応できないほどのスピードでデータを作成するため、ストレージ資産を把握しようとするチームにとって課題となっています。Storage Intelligence アドバイザーの新バージョンでは、「バケットには何が入っているか？」という疑問の答えが簡単にわかり、予期しない変更をすばやく特定できます。さらに、強化されたバッチオペレーションにより、バケット全体にわたる一括変更、たとえば、ストレージクラスの移動、古いデータや一時データの一括削除、メタデータ、タグ付け、保持、暗号化の変更の適用などを自動化できます。Storage Intelligence アドバイザーの最新情報については、こちらをご覧ください。
新しいプロダクト: 最後に、AlloyDB for PostgreSQL の新バージョンは、Google の先駆的なインフラストラクチャである Colossus 分散ファイルシステムと Jupiter ネットワークを統合し、エージェントの時代における妥協のない新しいデータベースアーキテクチャを実現します。

実践ガイドとハウツー

ハウツー: 世界中に分散している GPU と TPU を、単一のエントリポイントの背後にある単一のプールとして動作させたいとお考えの場合は、こちらのブログ記事でその方法をご確認いただけます。エッジでは、マルチクラスタ GKE Inference Gateway が、グローバルなマルチリージョントラフィック分配と高可用性を担います。その下では、LLM-d ルーターが、使用率を高く維持するための複雑なメモリ認識型スケジューリングアルゴリズムを処理します。このアーキテクチャは、ランタイム、モデル、アクセラレータに依存しないように意図的に設計されており、テストでは、マルチクラスタ GKE Inference Gateway を介してトラフィックをルーティングしたところ、オーバーヘッドは 1% 未満でした。
ガイド: AI モデルのトレーニングや推論に TPU 上の GKE を使用されているか、使用される予定ですか？巨大な大規模言語モデル（LLM）のトレーニングや、高スループットの推論サービングの実行には、Cloud TPU や Cloud GPU などの特殊な AI ハードウェアへの多額の投資が必要です。費用対効果を最大化するには、GKE のワークロードライフサイクル指標を理解する必要があります。この詳細なガイドでは、不透明なクラスタの動作を実用的なテレメトリーに変換する方法を説明します。

お客様とパートナーに関する最新情報

GKE のお客様: ゲームのスタートアップである SeaVerse がマルチテナントワークロードに GKE Agent Sandbox を利用している理由と、このプラットフォームによってインフラストラクチャ費用を 60% 削減できた経緯をご覧ください。

調査、レポート、詳細解説

また、Google は Gartner と Forrester の 3 つの主要なアナリストレポートでリーダーに選出され、プロダクトまたは戦略のいずれかで最高スコアを獲得しました。

Google、「The Forrester Wave™: Public Cloud Platforms, Q3 2026」でリーダーに選出: クラウドプロバイダの中で最高の総合スコアを獲得しました。
Google、2026 年 Gartner® Magic Quadrant™ で戦略的クラウドプラットフォームサービス部門のリーダーに選出: 評価対象となったすべてのベンダーの中で、「ビジョンの完全性」において最高評価を獲得しました。
Google、2026 年 Gartner Magic Quadrant でコンテナ管理部門のリーダーに選出: 評価対象となった全ベンダーの中で「実行能力」において最高評価を獲得しました。
Google Cloud は、世界中の GPU プロバイダの信頼性、パフォーマンス、サポート、料金、セキュリティを評価する最新の SemiAnalysis ClusterMax 3.0 レポートでゴールド評価を獲得しました。詳しくは、レポート全文をご覧ください。

2026 年 8 月

プロダクト、テクノロジー、ツールに関する最新情報

プロダクトの最新情報: Filestore は Google Cloud がファーストパーティとして提供するセキュアでスケーラブルな NFS ファイルサービスであり、AI やエージェントワークフロー向けのストレージプラットフォームとして人気を集めています。このたび、Google の基盤となる分散ストレージシステムである Colossus 上に直接構築された新しいバックエンドストレージレイヤが追加され、これらのタスクにさらに適したサービスとなりました。この新しいバックエンドでは、ストレージ容量とは別に IOPS をプロビジョニングでき、GKE と緊密に統合されています。AI 環境では、いわゆるエージェントスウォーム（多数のエージェントからなる大規模なグループで、共通のデータセットに対して読み取りと書き込みを行う必要がある）を、パフォーマンスを低下させることなく処理できます。詳しくは、ブログ投稿をご覧ください。
新機能: gVisor サンドボックスを GKE 上の分散 Ray クラスタで利用できるようになりました。Anyscale との提携により、gVisor を分散 Ray クラスタに直接組み込むことができる、Ray 向けの試験運用版ライブラリを導入しました。gVisor は Google のオープンソースアプリケーションカーネルであり、通常のコンテナよりも強力な分離機能を持ち、起動時間が短く、メモリオーバーヘッドが少ない軽量な環境を提供します。GKE でこれらのサンドボックス機能を試すには、Ray サンドボックスユーザーガイドをご覧ください。
プロダクトの最新情報: 費用はあまりかけたくないけれど、パーソナル AI エージェントを実行するための高性能で使いやすいインフラストラクチャをお探しという方に朗報です。新しい Cloud Run インスタンスは、Cloud Run 上の専用のシングルトンコンピューティングランタイムであり、エージェントがアイドル状態になってもシャットダウンされません。さらに、1 個の vCPU と 1 GiB のメモリを備えた Cloud Run インスタンスを 30 日間連続で実行しても、費用は 5.70 ドルしかかかりません。

実践ガイド、ドキュメント、ハウツー

入門ガイド: Model Context Protocol（MCP）に関する最新情報: 2026-07-28 仕様で、プロトコルコアは「完全にステートレスになりました。handshake はなくなり、initialize / initialized handshake（SEP-2575）と論理的な Mcp-Session-Id ヘッダー（SEP-2567）は完全に削除されました。代わりに、すべてのリクエストが自己記述型で独立したものになりました。」最新の MCP 仕様の変更点と、さらに重要なその実装方法について詳しくは、こちらの Google for Developers のブログ記事をご覧ください。
ガイド: 従来のネットワークロードバランシング手法では、リアルタイム AI システムをうまく扱いきれない場合があります。「バックエンドは、今までのように個別のリクエストを処理するのではなく、継続的なライブ双方向ストリームを管理する必要があります。音声チャンク、文字起こし、モデル出力、合成音声が同時にやり取りされる、絶え間ないストリームを処理するからです。」ここにユーザーへの対応が追加されると、状況はさらに悪化します。「サーバーは、現在処理中の音声生成を即座に停止して、コンテキストを更新し、場合によっては新しいツールをトリガーして、別の回答の作成を開始する必要があります。また、これを接続を切断することなく行わなくてはなりません。」AI 時代における負荷管理の新しいアプローチについては、セッション対応のロードバランシングによるリアルタイム AI エージェントのスケーリングをご覧ください。
ハウツー: さまざまな GPU アクセラレータが混在する場合でも、GKE 上に弾力性のあるスケーラブルな LLM 推論プラットフォームを構築する方法を学びます。ここで提案するアーキテクチャでは、Capacity Advisor と Compute Advisor に加え、Run:ai Model Streamer や、並列ダウンロード機能を備えた GCSFuse などの高性能ストレージを組み合わせて使用します。詳しくは、こちらをご覧ください。
ドキュメント: GPU や TPU を搭載したホストの問題は、ライブマイグレーションを使用して更新することができないためにメンテナンスが困難であることです。この新しいドキュメントページでは、トレーニングワークロードと推論ワークロードのダウンタイムをどれだけ許容できるかに応じて、アクセラレータ搭載ホストを更新する方法を説明します。
ドキュメント: Advanced Compute Images（ACI）は AI / ML および HPC インフラストラクチャ用の標準化されたイメージスタックであり、独自のカスタムイメージを手動で構築する必要はありません。この新しいドキュメントページでは、Google Cloud CLI、コンソール、または SchedMD の Slurm ワークロードマネージャーを使用して ACI イメージを作成する方法を説明します。
ガイド: AI ワークロードは、設計の難しさ、リソース消費の激しさ、そしてバースト性があることで知られています。これらはスケーリングのボトルネックを招くだけでなく、十分に活用されない（または誤用される）コンピューティングリソースを大量に発生させる原因にもなります。新しいブログ投稿では、Google Cloud で動的な容量管理を実現する 3 つの主な方法について説明します。その 3 つの方法は以下のとおりです。1）計画的なダウンタイムに備えて容量をスケジュールする、2）計画外のダウンタイムに備えて自動フォールバック容量を確保しておく、3）GKE のコアオーケストレーション機能を利用してリソース割り当てを自動化する。

お客様とパートナーに関する最新情報

ビジネスオーケストレーションソフトウェアプロバイダの UiPath は、急激に変動するワークロードに対処し、費用の予測可能性を高めたいと考えていました。これを実現するために、同社は分離された複数のクラスタで構成されていたインフラストラクチャを再設計し、トレーニング用の A3 VM インスタンス（NVIDIA H100 GPU）と推論用の G4 VM インスタンス（NVIDIA RTX PRO 6000 Blackwell Server Edition GPU）の両方を含む共有 Google Cloud GPU フリートへと移行しました。同社のアーキテクチャについて詳しくは、こちらをご覧ください。
AI 開発の加速に注力する最先端の AI 研究所である Mirendil は、モデルの事前トレーニングとトレーニング後のアプリケーションをサポートするために、TPU と NVIDIA GPU の両方を備えた AI Hypercomputer を使用することを発表しました。
小売業向け CRM プロバイダの Replenit は、BigQuery、Gemini Enterprise Agent Platform、Cloud TPU で実行するオープンソースの Gemma モデルを使用して、Google Cloud で AI 意思決定エンジンを構築しました。同社では、この組み合わせにより、以前のクラウドプロバイダと比較してパイプライン費用が 90% 削減されたとしています。詳しくは、事例紹介の全文をご覧ください。
Malachyte は、Bigtable、Managed Service for Apache Kafka、Pub/Sub、Compute Engine、そして GKE を基盤として、AI を活用した e コマースレコメンデーションプラットフォームを構築しました。こちらのブログ記事で、これらがどのように連携するかをご覧ください。

2026 年 7 月

プロダクト、テクノロジー、ツールに関する最新情報

プロダクトの最新情報: Google Cloud Managed Lustre の一般提供が開始されました。4 種類のパフォーマンスティアがあり、容量 1 TiB あたり 125 MB/秒、250 MB/秒、500 MB/秒、1,000 MB/秒のスループットを選択できます。ストレージ容量は最大 8 PB までスケールアップ可能です。Managed Lustre ソリューションは DDN の EXAScaler を活用しており、DDN が数十年にわたって培ってきた高パフォーマンスストレージ界をリードする技術と、Google Cloud のクラウドインフラストラクチャに関する専門知識を組み合わせています。
プロダクトの最新情報: C4N ネットワーク / ストレージ最適化 VM の一般提供を開始しました。C4N は、データ転送のボトルネックを解消するために構築された、Google 初のネットワークとブロックストレージに最適化された VM シリーズです。第 5 世代 Intel Xeon スケーラブルプロセッサを搭載し、Google の Titanium オフロードハードウェア上に構築された C4N は、400 Gbps のネットワーク帯域幅と 9,500 万パケット/秒（95 MPPS）の処理速度を実現します。また、Hyperdisk Extreme と組み合わせた場合のブロックストレージスループットは最大 25 GiB/秒に達します。
新機能: GKE Dataplane V2 が、ネットワークポリシー適用下で最大 15,000 ノードまでサポートできるようになりました（一般提供）。これにより、標準の GKE クラスタ上で、ネットワークポリシーの適用を完全に維持したまま、最大 15,000 ノードまでのスケールアップが可能になります。大企業や AI / ML を活用するお客様の膨大なインフラストラクチャニーズに対応する機能です。
新機能: llm-d が協調型タイムスライスに対応しました。強化学習（RL）ワークロードで、独立した RL ジョブを共有の物理ハードウェアにインターリーブして実行できるようになりました。これにより、モデルの収束や精度に影響を与えることなく、アクセラレータの総デューティサイクルをベースラインの約 40% から最大 70% まで引き上げることが可能です。
新しい AI セキュリティツール: GKE 上の AI サプライチェーンの保護、AI ワークロードの安全なデプロイ、シャドー AI の削減をお考えですか？Google は k8s-aibom をオープンソース化しました。これは、コンテナクラスタを継続的にモニタリングして、実行中の AI ランタイム（vLLM や Triton など）を自動的に検出し、標準的な CycloneDX Machine Learning 部品構成表（ML-BOM）を生成する、軽量で特権を必要としない Kubernetes コントローラです。k8s-aibom プロジェクトをチェックして、ぜひ開発にご参加ください。

実践ガイドとハウツー

入門ガイド: 7 月 27 日、Google は Moonshot AI の 2.8 兆パラメータのオープンウェイトモデルである Kimi K3 の「Day 0 サポート」を発表しました。モデルのウェイト公開と同時にサポートを開始し、即日の利用を可能にしました。Model Garden、カスタムオーケストレーション、llm-d レシピを使用した GKE など、選択したデプロイ手法に合わせて Google Cloud で Kimi K3 を評価して試験運用するための詳細な手順をこのガイドでご確認いただけます。
入門ガイド: Google Kubernetes Engine（GKE）マネージド DRANET は、GPU と TPU の両方に対応しています。この実装を使用するための構成には、標準クラスタ（ユーザーが完全に制御可能）や Autopilot クラスタ（Google によって複雑な構成が自動的に行われる）など、いくつか選択肢があります。詳細については、ハンズオンラボ TPU を使用する GKE Autopilot クラスタ、GKE マネージド DRANET、Gemma 4 でご確認いただけます。
入門ガイド: GPU ではなく TPU で Ray を実行する方法を学べます。全 2 回シリーズのパート 1 では、TPU スライスについて説明します（ヒント: Ray は TPU スライスを、スケジュール設定可能なアクセラレータの一種として認識します）。続くパート 2 では、Ray のさまざまな AI ライブラリについて説明します。
入門ガイド: 新しいマイクロベンチマークスイートを使用して、サンプルワークロードにおける TPU の性能を評価します。このスイートを活用することで、デバイスが理論上のパフォーマンス仕様を達成しているかを正確に測定できるほか、特定の性能ギャップやアーキテクチャ固有のボトルネックを特定することも可能です。詳細はこちらでご確認いただけます。
入門ガイド: 予算を圧迫することなく、エージェントをスケールしましょう。GKE Agent Sandbox と Pod スナップショットを活用して固定のコンピューティングリソース内でより多くのエージェントを安全に集約する方法を、GKE オーケストレーションの観点から解説します。パフォーマンス重視かコスト重視かを問わず、エージェントの効率を最大化するための適切な最適化方法を解説します。
技術ブループリント: Ironwood における Mistral 3 Large 推論の最適化について詳細に解説します。こちらのブログ記事では、Google のあるチームが Google の Ironwood（TPU v7x）で Mistral 3 Large MoE モデルの推論を最適化し、パフォーマンスを 1.5 倍向上させた方法について説明しています。具体的には、ハイブリッドシャーディングの導入、線形 VPU 合計からツリーリダクションへの置き換え、GMM / MLA カーネルの最適化、非同期スケジューリングの採用によって、これを実現しました。その結果、ベンチマーク精度を維持したまま、スループットを最大 48% 向上させるという成果を収めました。ブログの全文はこちらでご覧ください。

調査、レポート、詳細解説

レポート: Google は、初めて発表された GartnerⓇ Magic Quadrant™ の AI インフラストラクチャ部門において、リーダーに選出され、「実行能力」で最高位、「ビジョンの完全性」で最も先進的との評価を獲得しました。Gartner は、Google 独自の拡張可能なコンピューティング、統合された AI Hypercomputer アーキテクチャ、AI コンピューティング容量の規模を主な強みとして挙げています。レポートはこちらからダウンロードしてお読みいただけます。
レポート: Google は先ごろ、「AI インフラストラクチャの現状」レポートの作成にあたり、1,400 人を超える IT 部門の上級リーダーを対象に調査を実施しました。その結果、AI に対する構想とインフラストラクチャの実態との隔たりが広がっているという明確な傾向が浮かび上がりました。実際、83% の組織が、本番運用に対応できるエージェント型 AI を支えるには、インフラストラクチャのアップグレードが必要だと回答しています。この調査について紹介したブログ記事では、エージェント型アプリケーションがシステムに求める要件に合わせてインフラストラクチャを整備することで、試験導入から本番運用への移行を進めやすくなることを説明しています。

2026 年 6 月

プロダクト、テクノロジー、ツールに関する最新情報

プロダクトの最新情報: AI で使用される機密データの保護は、先進的でセキュアなクラウドインフラストラクチャを実現するうえで欠かせない要素です。Confidential Computing は、ハードウェアベースの高信頼実行環境（TEE）で使用中のデータを暗号で保護し、データの完全性を検証可能にする技術です。このたびこの技術が、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載したアクセラレータ最適化型 G4 マシンシリーズで提供開始されました。Confidential G4 VMs と Confidential G4 GKE Nodes をぜひ使ってみてください。
デベロッパー向けリソース: 新設された TPU デベロッパーハブは、モデルの作成者、最適化担当者、デベロッパーが Google Cloud TPU のパフォーマンスを最大限に引き出す方法を学ぶための場所です。詳細については、こちらのブログ記事をご覧ください。
新プロダクト: 新しい OpenTelemetry ベースの TPU AI テレメトリーコレクタエージェントを使用して、AI ワークロードをスケールしましょう。このたび初めて、高忠実度の TPU ハードウェアテレメトリーを、Google Cloud Monitoring、Google Managed Prometheus、または独自のセルフホスト型 Grafana スタックにルーティングできるようになりました。

実践ガイドとハウツー

入門ガイド: TPU、Cloud Storage FUSE、動的リソース割り当て（DRA）を使用して、GKE Inference Gateway で実行される AI 推論ワークロードで高可用性を実現する方法を学べます。こちらのブログ記事で概要を紹介しています。また、技術的な詳細についてはハンズオン Codelab でご確認いただけます。
入門ガイド: Model Context Protocol（MCP）を使用して、AI エージェントを Cloud Storage の非構造化データに接続できることをご存じですか？こちらのブログ記事では 3 つのお客様事例に基づく導入のメリットと、具体的な実装方法を解説しています。フルマネージドサービスにすべきか、詳細なカスタマイズと管理が可能なセルフマネージドローカルサーバーにすべきかを判断する方法もご紹介しています。

調査、レポート、詳細解説

レポート: 第三者機関によるベンチマークレポートにおいて、GKE Inference Gateway は他社の主要マネージド Kubernetes サービスを凌駕するパフォーマンスを記録しました。具体的には、スループットは 15.7% 高く、待ち時間は 92.8% 短く、トークン間のレイテンシは 62.6% 低いという結果でした。このパフォーマンスの鍵は、接頭辞キャッシュの使用にあります。長く繰り返し使用されるプロンプトの接頭辞に対応する KV キャッシュ（アクティベーション状態）を保存することで、LLM のパフォーマンスを最適化しています。詳しくは、こちらのブログ記事をご覧ください。
アーキテクチャの詳細解説: 今回は TPU と GKE におけるコールドスタート問題を深堀りし、Run:ai Model Streamer がどのようにその状況を変えられるかについて解説します。

お客様とパートナーに関する最新情報

お客様の成功事例: Pager Health は、GKE、BigQuery、Cloud SQL、Gemini Enterprise Agent Platform を活用して運用の断片化を解消し、人々の生活に大きな変化をもたらすシンプルかつパーソナライズされた医療体験を米国で展開しています。
お客様の成功事例: カスタマーレビュープラットフォームの Trustpilot は、A100 GPU 搭載のコスト最適化済み A2 VM 上で Dataflow と Gemini Enterprise Agent Platform を活用して、大規模なストリーミングパイプラインを構築しました。ファインチューニングされた Gemma モデルや、同プラットフォームが管理する最適化版 vLLM を採用しています。

2026 年 5 月

プロダクト、テクノロジー、ツールに関する最新情報

プロダクトの最新情報: GKE Agent Sandbox の一般提供が開始されました。
新しいオープンソースプロジェクト: Agent Substrate は、エージェントインフラストラクチャの密度を限界まで高めることを目指す、新しいオープンソースプロジェクトです。
新機能: Google AI Edge Portal は、オンデバイス ML を大規模にテストしてベンチマーク評価するためのソリューションです。このたび、オンデバイス LLM のベンチマークとデバッグに対応しました。詳しくはこちらをご覧ください。
プロダクトの詳細解説: AI ワークロード向けの新しい高性能ストレージサービスファミリーである Cloud Storage Rapid について詳しく説明しました。リリース時点でご利用いただけるサービスには、高パフォーマンスのゾーンオブジェクトストレージサービスである Rapid Bucket（旧称: Rapid Storage）と、オンデマンドで読み取りを高速化して既存バケットのワークロードのコンピューティングとデータをコロケーションする Rapid Cache（旧称: Anywhere Cache）が含まれます。

調査、レポート、詳細解説

アーキテクチャの詳細解説: Google グローバルインフラストラクチャ担当バイスプレジデントの Bikash Koley とエンジニアリングフェローの Arjun Singh が、AI ワークロードがネットワークインフラストラクチャにもたらす課題の概要を説明し、AI ワークロードをより適切にサポートするためにデータセンターファブリック、WAN、グローバルネットワークに施した大幅な機能強化をご紹介します。
アーキテクチャの詳細解説: TPU で最先端の AI モデルを開発するために、インスタンスレベルの信頼性モデルを廃止し、新しいクラスタレベルの信頼性モデルを公開しました。

お客様とパートナーに関する最新情報

お客様の成功事例: ビジュアルメディアプロバイダの Imgix は、NVIDIA RTX PRO 6000 Blackwell GPU 搭載の G4 VM を備えた AI Hypercomputer を活用して、80 億を超える画像や動画を配信しています。

- Google Cloud ブログ編集者、Alex Barrett

AI21、AI Hypercomputer の導入により AI ワークロードの起動時間を 83% 短縮

Wed, 14 Oct 2026 02:50:00 +0000

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

編集者注: AI21 Labs は、基盤モデル、特に Jamba ファミリーの構築で長年の実績を持つ世界有数の AI ラボであり、現在は特化型 LLM とエージェント最適化テクノロジーに注力しています。Google Cloud AI Hypercomputer の導入により、AI21 は優先度の高いジョブの待ち時間を 72 時間から 12 時間へと短縮し、手動によるスケジューリング介入を週 20 回からゼロへと削減しました。

AI21 は、企業が最先端の品質でエージェントを効率的に実行できるようにする基盤モデルとエージェント最適化プロダクトを構築しています。Jamba ファミリーを含む AI21 の言語モデルとエージェント最適化プロダクトスイートは、AI21 独自のワークロードをはじめとする、要求の厳しい本番環境ワークロードを稼働させています。そこで、これらを大規模なスケールで稼働させるために Google Cloud AI Hypercomputer を選択しました。

モデルトレーニングの稼働率を高く維持するには、インフラストラクチャ、オーケストレーション、使用量モデル全体で共同設計された、パフォーマンスとスケーラビリティに優れた環境が必要でした。モデルのトレーニングは、共有の Google Kubernetes Engine（GKE）クラスタの 1 つで実行され、数千の Google Cloud A3（NVIDIA H100 Tensor Core GPU 搭載）インスタンスと A3 Ultra（NVIDIA H200 Tensor Core GPU 搭載）インスタンスをプールしています。これにより、どのチームも、割り当てられた一部のキャパシティに制限されることなく、フリートの全キャパシティを活用できます。このクラスタは、Jamba ファミリー以外のモデルやエージェント最適化ワークロードのトレーニングにも使用されています。このアプローチによって使用率は高く維持されますが、その反面、スケジューリングは困難になります。

高使用率クラスタの行き詰まり

オーケストレーションに GKE を活用する前は、Slack で手動でキャパシティを調整していました。トレーニング実行のためのキャパシティが必要な場合は、#gpu-resources に投稿して、うまくいくことを祈るしかありませんでした。

クラスタに余裕があるときは、これで問題ありませんでした。使用率が 100% 近くに張り付くと、機能しなくなりました。これこそが、予約済みのコンピューティングフリートに求められる稼働状態であるにもかかわらず、です。

やがて、すべてのリクエストが交渉の対象となりました。チームリーダーは、コンピューティングリソースの割り当てを巡る争いの仲裁に時間を費やしていました。優先度の高いジョブ、つまりクラスタの半分以上を一度に必要とし、モデルプロジェクトのクリティカルパスとして機能する大規模なマルチノードトレーニング実行は、十分な連続した空きキャパシティが確保できるまで最大 72 時間ブロックされる可能性がありました。

図 1: #gpu-resources での典型的な 1 日。手動リクエスト、アドホックな調整、返信を待つ研究者。

リソースの不足は 2 つの異なる問題を生み出しましたが、それらを別々の問題として認識するまでには時間がかかりました。1 つ目は競合です。次にコンピューティングリソースにアクセスできるユーザーを決定する必要があり、これは交渉によって解決しました。2 つ目は断片化です。技術的には空きキャパシティがあるものの、大きなジョブで使用するには小さすぎる断片に分散している状態であり、これはいくら交渉しても解決できないビンパッキング問題でした。

図 2: GPU の断片化。4 つのノードに 1+1+4+2 として分散された 8 つの空き GPU では、8 GPU のワークロードを収めることができません。

理論上は十分な空きキャパシティがある場合でも、それが複数のマシンに分散していて、大きなジョブを実際に実行するにはチャンクが小さすぎることもありました。オールオアナッシングアドミッションがなければ、クラスタはデッドロックに陥り、誰かが手動で介入するまで、マシンは有用な作業を行わずにリソースを保持することになります。

現状がうまくいっていないことは明らかで、もっと良いものが必要でした。

適切なスケジューラの選択

当社では、Apache YuniKorn、Volcano、Kueue など、いくつかのオープンソースバッチスケジューラを検討しました。YuniKorn は、当社のすべてのユースケースをカバーしていませんでした。Volcano は機能が豊富でしたが、当社の環境に統合するには、Kubernetes スケジューラのコアコンポーネントを置き換える必要がありました。

シンプルさと統合のしやすさが、Kueue を採用する決め手となりました。標準の Kubernetes で動作し、コアコンポーネントを置き換える必要がなく、ジョブ仕様を書き直す必要もありませんでした。

Kueue と、GKE を通じた AI Hypercomputer の柔軟でオープンな運用を組み合わせたことも、成功に貢献しました。GKE を利用しているのは、コンピューティング負荷の高い AI ワークロードを適切に制御できるからです。GPU ハードウェアとドライバに直接アクセスできる一方で、生のインスタンスを自社で管理するオーバーヘッドは発生しません。Kueue は、Spot VM や Dynamic Workload Scheduler などの Google Cloud のキャパシティタイプを含め、GKE とネイティブに統合されているため、予約されたキャパシティが満杯になると、ジョブが滞ることなく、同じスケジューリングロジックが自動的に拡張可能なキャパシティにアクセスできます。

オープンソースとのフィードバックループの確立

Kueue の導入は、単なるプロセスの変更以上のものとなりました。Google Cloud と提携しているため、当社には専任のテクニカルアカウントマネージャーがついています。その担当者が、AI21 を Kueue チームのデザインパートナーに推薦する好機だと考えてくれました。そうすれば、単なるユーザーにとどまらず、本番環境における実際の要件を提供する存在として、ツールの今後の方向性を形作るのに貢献できます。

このパートナーシップから最初に生まれたものの一つが、Kueue チームと共有した要件ドキュメントです。このドキュメントには、まだ存在していなかった、必要とする動作が記載されていました。それは、通常は公平なスケジューリングに付随するプリエンプションを行うことなく、マルチノードジョブに対してチーム間で公平なアドミッション順序を実現することです。Kueue チームは、この機能を実際に開発してくれました。Admission Fair Sharing（AFS）は、すでに実行されているジョブを中断することなく、これまで使用したキャパシティが少ないチームを優先するようにアドミッションキューを並べ替えます。同じ頃、トポロジを考慮したスケジューリングも有効にしました。この既存の機能により、Kueue は物理クラスタのレイアウトを認識できるため、単一ノードに収まらないジョブを、実行する場所がないまま配置するのではなく、受け入れを拒否できます。

当社にとって、これはオープンソースのフィードバックループの最良の形です。本番環境での使用を通じて実際の要件が明らかになり、それが Kueue に直接フィードバックされます。

同じフリートで、よりスムーズに

Slack の #gpu-resources チャンネルはアーカイブされました。デバッグ pod、マルチノードトレーニング実行、推論デプロイなど、あらゆるワークロードがキューに登録され、優先順位が付けられ、自動的にスケジュールされます。効果はすぐに表れました。手動による介入は、週に約 20 回からゼロに減少しました。以前は最大 72 時間待機していた優先度の高いジョブの待ち時間が、今では 12 時間に短縮されました。クラスタ全体の断片化は 15% から 8% に減少し、「ゾンビジョブ」の問題（ワークロードが部分的に受け入れられ、実行する場所がない）は解消されました。

これによって総費用が変わることはありませんでした。当社では、予約済みフリートを意図的に 100% に近い稼働率で運用しているため、純粋な支出額そのものは、もともと最適化の対象ではありませんでした。変わったのは、従業員が何に時間を費やすかです。チームリーダーはコンピューティングに関する争いを仲裁する必要がなくなり、研究者は Slack での返信を待つ必要がなくなりました。これにより、誰もがより多くのテストを実施し、より迅速に反復処理を行えるようになります。

- AI21、テクノロジーおよびアーキテクチャ担当バイスプレジデント、Barak Peleg 氏

- AI21、DevOps エンジニア、Asaf Ben-Tovim 氏

45 倍高速な GKE Agent Sandbox でエージェント型 RL と評価研究を加速

Fri, 09 Oct 2026 01:00:00 +0000

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

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

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

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

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

最初のコマンド実行までの時間を 10～45 倍高速化: GKE は、サンドボックス環境を 45～85 秒ではなく 1～9 秒でスピンアップできるため、高価な GPU を常にフル稼働させることができます。
テールレイテンシを短縮: サンドボックスの最悪の場合の待ち時間を 7.5 分から 10 秒未満に短縮しました。
コントロールプレーンのチャーンを 3 分の 1 に削減: RL のトレーニングステップごとに大量のロールアウトが一斉にトリガーされ、数千ものサンドボックスが一度にリクエストされます。SDK では、Pod を削除して再作成するのではなく、ロールアウト間で再利用するインプレースリサイクル戦略が採用されています。これにより、作成される Pod の数が 3 分の 1 に減り、チャーンが発生しても、安定した Kubernetes API サーバーを維持できます。

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

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

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

アクセラレータのアイドルコスト、すなわち最初のコマンド実行までの時間（TTFC）とテールレイテンシの罠: エージェント型 RL はバッチワークロードです。同期型の RL ステップでは、バッチ内で最も処理の遅いサンドボックスの準備が整うまでトレーニングを進めることができません。CPU サンドボックスを起動する際、プロビジョニング、イメージの pull、初期起動スクリプトの実行に数分かかれば、高価なアクセラレータの容量が無駄になってしまいます。
膨大なイメージカーディナリティ: 標準的なコンテナのキャッシュ保存は、少数の静的なベースイメージを前提としています。しかし、エージェント型 RL では、一つひとつのタスク（SWE-bench や R2E-Gym にある数千の GitHub リポジトリなど）に、完全に異なる OCI コンテナイメージが必要となることが少なくありません。実行ごとに数千もの一意の大型イメージを管理すると、イメージの pull における深刻なボトルネックや、ストレージフリクションが生じる可能性があります。
コントロールプレーンの飽和: バースト性の高いバッチワークロードであるエージェント型 RL は通常、バッチサイズのイメージタスクと、タスクごとに複数のロールアウト（タスクごとに 4、8、16 回のロールアウトなど）を実行するため、すでに大量にあるイメージ数が極限まで増加してしまいます。たとえば、テストに使用した一般公開データセットの一つには、4,578 件の R2E イメージが含まれています。イメージごとにロールアウトを 4 回行うと仮定すると、18,312 個のタスクが発生し、18,312 個のサンドボックスが同時に必要となります。標準の Kubernetes コントロールプレーンは、このようなバースト負荷が生じるとパフォーマンスが大幅に低下します。1 分間に数万ものエフェメラル Pod の作成と削除を頻繁に繰り返すと、API サーバーのキューのボトルネックや Pod の状態エラーが発生し、ノード障害の誤判定によるエビクションがトリガーされます。

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

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

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

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

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

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

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

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

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

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

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

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

主要な指標	重要である理由	標準の K8s Pod ベースライン	GKE Agent Sandbox SDK	ベンチマークの向上
TTFC、平均	GPU のアイドル時間を左右する	44～85 秒（平均）	1.1～8.8 秒（平均）	10 倍高速
テールレイテンシ - 最大 TTFC（最悪のケース）	バッチのボトルネックになる	7.5 分（450 秒）	10 秒未満	45 倍高速

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

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

イメージのハイドレーションをクリティカルパスから除外。カーディナリティの高いコーパスはローカルディスクの容量をはるかに超えるため、トレーニング中にコールドイメージを pull すると、I/O の競合や数分に及ぶテールレイテンシが発生します。SDK がノード全体にわたるイメージの配置を計画し、 GKE イメージストリーミングと事前のウォームプーリングが残りの処理を行います。これにより、ロールアウトが要求する前にハイドレーションが完了します。
コントロールプレーンのペースを調整。同時実行数の多いロールアウトは、API サーバーのサンダリングハードをトリガーします。Agent Sandbox Controller v1.0.0 では、ウォームプールの補充速度を制限するレート制御が追加され、バースト中も etcd と API サーバーの安定性が維持されます。

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

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

主要な指標	重要である理由	標準の K8s Pod ベースライン	GKE Agent Sandbox SDK	ベンチマークの向上
コントロールプレーンのチャーン（4,578 イメージ × 4 回のロールアウト実行）	コントロールプレーンが飽和	18,312	5,869	チャーンが 3.1 分の 1 に減少

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

トレードオフ

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

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

ご利用開始

今すぐ構築する: Agent Sandbox リポジトリまたは Agent Sandbox RL リポジトリを参照し、Python SDK や、Gymnasium、NVIDIA NeMo Gym、OpenHands などの RL ツール向けネイティブ連携をご確認ください。
アクセラレータの使用率をさらに高める: llm-d 協調型タイムスライスリポジトリとスナップショットエージェントガイドを参照し、独立した RL ジョブを共有の物理ハードウェア上で動的にインターリーブする方法をご確認ください。
詳細を確認する: GKE Agent Sandbox を使用してセキュアな実行環境をデプロイする方法については、公式ドキュメントをご覧ください。

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

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

マルチクラスタ GKE Inference Gateway で 1% 未満のオーバーヘッドでグローバル AI ルーティングを実現

Fri, 09 Oct 2026 00:00:00 +0000

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

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

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

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

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

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

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

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

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

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

マルチクラスタ GKE Inference Gateway トポロジ。構成クラスタはルーティング構成を保持しますが、リクエストパスの外側に配置されています。各ターゲットクラスタは独自の EPP を実行し、KV キャッシュの使用率をロードバランサに報告します。

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

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

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

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

フリートトポロジ	リクエストのスループット	トークンのスループット	成功率
1 クラスタ（us-east5-a）	0.72 リクエスト/秒	2,898 トークン/秒	99.87%
2 クラスタ（+ us-west8-a）	1.40 リクエスト/秒	6,380 トークン/秒	99.95%
3 クラスタ（+ europe-west4- b）	2.10 リクエスト/秒	8,457 トークン/秒	99.90%

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

Linear scaling across regions

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

Instead, throughput multiplied almost exactly in line with capacity:

Fleet topology	Request throughput	Token throughput	Success rate
1 cluster (us-east5-a)	0.72 req/s	2,898 tok/s	99.87%
2 clusters (+ us-west8-a)	1.40 req/s	6,380 tok/s	99.95%
3 clusters (+ europe-west4- b)	2.10 req/s	8,457 tok/s	99.90%

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

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

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

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

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

価値の提供

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

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

チームへの影響

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

よりスマートなロードバランシングは、それ自体が価値を生み出します。ラウンドロビンルーティングでは、メモリやコンピューティングの負荷を把握できないため、高価な GPU 容量を無駄にしてしまいます。リアルタイムのアプリケーションシグナルに基づくルーティングにより、断片化されたリージョンクラスタが 1 つの効率的なフリートに統合されます。これにより、ハードウェアが遊休状態になるのを防ぎ、希少なコンピューティングリソースの利用率を 90%以上に高めることができます。
エージェントワークロードがボトルネックを変化させます。極めて大きなコンテキストウィンドウを持つ長時間実行型のエージェントは、コンピューティングリソースが限界に達するずっと前にメモリを使い果たしてしまいます。ルーティングレイヤがメモリ負荷を認識できない場合、VRAM が満杯になったノードの陰に、まだ余裕のあるコンピューティング容量が取り残されてしまいます。KV キャッシュの使用率を最優先のルーティングシグナルにします。
AI トラフィックがウェブ時代の前提を覆します。従来のロードバランサは 1 秒未満のトランザクション向けにチューニングされていますが、LLM リクエストは数分間実行されることがあります。AI 規模のレイテンシを考慮して、接続上限とタイムアウトを早期に計画してください。そうしないと、本番環境で接続が中断される可能性があります。
ルーティングレイヤは、ネイティブのサービングパターンと統合する必要があります。分散 LLM エンジンには、特定の Pod のみがトラフィックを処理できるマスターワーカートポロジがあります。Gateway を LeaderWorkerSet（LWS）などのネイティブな Kubernetes 構造と組み合わせることで、グローバルルーティングはローカル Pod トポロジをそのまま考慮した制御を行い、チームがカスタムプロキシインフラストラクチャを構築する必要がなくなります。
大規模な基盤モデルの構築には、オープンでポータブルなスタックが最適です。業界最先端の規模で運用しているチームは、容量の断片化という最も深刻な課題に直面しています。そのため、空き容量があるリージョンならどこであっても、コンピューティングリソースを探し回ることを余儀なくされています。GKE 上の LLM-d のようなオープンでポータブルな推論スタックを使用すると、単一のクラスタ、リージョン、または独自のインフラストラクチャにサービングアーキテクチャを固定することなく、空き容量がどこにあっても吸収できます。

次のステップ

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

自分でデプロイする: マルチクラスタ GKE Inference Gateway を設定する。
アーキテクチャを理解する: マルチクラスタ GKE Inference Gateway について。
この投稿で紹介したクロスリージョンスピルオーバーの動作については、弾力性のあるクロスリージョン高可用性についてと弾力性のあるクロスリージョン高可用性を構成するをご覧ください。

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

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

Google、2026 年 Gartner Magic Quadrant でコンテナ管理部門のリーダーに選出

Mon, 05 Oct 2026 01:00:00 +0000

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

Gartner は 2026 年の Gartner® Magic Quadrant™ で、「ビジョンの完全性と実行能力」に基づき、Google を 4 年連続でコンテナ管理のリーダーとして認定しました。Google は、評価対象となった全ベンダーの中で実行能力において最も高い評価を得ています。これは、パフォーマンスと効率の両面で高度に最適化されたコンテナプラットフォームを提供するという Google のミッションの成功を証明するものと考えています。Google は、次世代の AI アプリケーションやエージェントアプリケーションなど、特に要求が厳しく複雑なワークロードを大規模に構築、実行できるよう、世界中のお客様を支援しています。

Magic Quadrant に付随する 2026 Gartner Critical Capabilities for Container Management レポート（2026 年の Gartner のコンテナ管理の重要機能に関するレポート）によると、Google Cloud は、すべてのユースケース（新しいクラウドネイティブなアプリケーション、コンテナ化された既存のアプリケーション、AI トレーニング、AI 推論、エッジアプリケーション、ハイブリッドアプリケーション）において第 1 位にランクインしました。

Gartner は、「Kubernetes を使用する新規の AI デプロイは、2025 年には 30% 未満だったが、2028 年までに 95% になる」と予測しています1。コンテナは昨今の特に革新的なアプリやビジネスを推進し、エージェントの時代にビジネスを変革するお客様が求めるインフラストラクチャを提供します。

Google Cloud は、2014 年に Kubernetes を導入し、2015 年に世界初のマネージド Kubernetes サービスである Google Kubernetes Engine（GKE）をリリースしたことで、業界全体のクラウドネイティブ革命を主導しました。それ以来、コンテナプラットフォームと、活気に満ちた革新的な Kubernetes エコシステムに対する Google の取り組みは、さらに強化され、深まっています。GKE とともに、Google のサーバーレスコンテナプラットフォームである GKE Autopilot と Cloud Run により、運用コストが大幅に削減され、デベロッパーは優れたコンテナ化アプリをこれまで以上に迅速に提供できるようになります。

エンタープライズ AI の急速な普及を受け、Google は AI 時代に向けてインフラストラクチャ管理を再定義しました。2026 年、Google はこれまでに、GKE と Cloud Run を、自律型 AI システム、大規模な推論ワークロード、セキュアなランタイム分離向けに設計された、エージェントネイティブな高性能プラットフォームに移行するために、幅広い基盤の改善を導入しています。最先端の AI トレーニング、AI スタートアップの立ち上げ、企業の AI 変革の主導など、あらゆるニーズに対応するコンテナプラットフォームをご用意しています。重要なポイントは次のとおりです。

AI インフラストラクチャで優れたパフォーマンスと効率を実現

GKE 予測レイテンシブースト: GKE Inference Gateway に組み込まれたこの ML 駆動型機能は、静的な構成ではなく容量認識ルーティングを使用して、最初のトークンまでの時間（TTFT）を最大 70% 短縮します。
GKE の自動 KV キャッシュストレージ階層化: KV キャッシュデータを RAM、ローカル SSD、Cloud Storage 間で自動的に移動します。これにより、メモリのボトルネックが軽減され、RAM へのオフロードによって TTFT が 40% 短縮され、大規模なプロンプトコンテキストではローカル SSD によってスループットが 70% 向上します。[1]
GKE によるコンテナとモデルの起動の高速化: GKE ノードのスピンアップ時間が最短で 4 分の 1 に短縮され、Pod の起動速度が最大 80% 向上しました。さらに、ネイティブの Run:ai Model Streamer のインテグレーションにより、重いモデルを Cloud Storage から 5 倍速く pull できます。
Cloud Run のオンデマンドサーバーレス GPU のゼロへのスケーリング: Cloud Run は NVIDIA RTX PRO 6000 Blackwell GPU をサポートしているため、チームは 700 億以上のパラメータがあるモデルをオンデマンドでサービングできます。サービスは、ゼロの状態から、完全にプロビジョニングされた GPU（すべてのドライバがプリインストール済み）に 5 秒未満で移行できます。アクティブな推論やファインチューニングの実行が完了すると、Cloud Run はインスタンスを自動的にゼロの状態にスケールダウンし、アイドル状態のインフラストラクチャ費用を排除します。

エージェントインフラストラクチャのセキュリティとスケールに対応する Kubernetes の進化

GKE Agent Substrate: オープンソースでセキュアバイデフォルトのエージェント実行ランタイムである Agent Substrate は、標準的なコンテナランタイムよりも 10 倍高い密度で数百万のサンドボックスを実行できるように設計されています。自律型エージェントの時代に向けて専用設計された Substrate は、ネイティブのゼロトラストカーネルとネットワーク分離により、1 秒あたり 500 回を超える一時停止 / 再開アクティベーションを実行しながら、500 ミリ秒未満での再開オペレーションを実現します。Agent Substrate は、あらゆる Kubernetes インフラストラクチャで動作し、GKE 向けに最適化されたオープンソースソリューションとして提供されます。
GKE Agent Sandbox: gVisor カーネル分離テクノロジーを基盤とする Agent Sandbox は、信頼できないマルチエージェント AI のコード実行からホスト環境を分離します。セキュアな実行を大規模に実現し、1 秒未満のレイテンシで 1 秒あたり最大 300 個のサンドボックスを処理します。また、Axion プロセッサで実行した場合、同等のハイパースケーラークラウドプロバイダと比較して最大 30% 優れたコストパフォーマンスを実現します。
GKE Dataplane V2 のスケーラビリティの上限: アクティブな NetworkPolicy を実装する GKE クラスタのアーキテクチャ上の容量上限が、クラスタあたり 7,500 ノードから 15,000 ノードに倍増し、大企業や AI を活用するお客様の膨大なインフラストラクチャニーズに対応します。
GKE のインテントベースの自動スケーリング: GKE は、基本的なハードウェア指標だけでなく、アプリケーションインテントとカスタム指標を使用して、ネイティブに水平自動スケーリングできるようになりました。これにより、リソース割り当ての反応時間が 25 秒からわずか 5 秒に短縮されます。
Filestore エージェントボリューム: NFS マウントをミリ秒単位でアタッチ / デタッチする新しいサービス。エージェントをほぼ瞬時に開始 / 再開できるほか、ネイティブの Read-Write-Many（RWX）アクセスと POSIX 準拠のファイルロックにより、書き込みの競合を発生させることなく、安全なマルチエージェントコラボレーションを実現します。

サーバーレスコンテナによる次世代のデベロッパーエクスペリエンス

Cloud Run は、標準的なウェブ API のホスティング、負荷の高いバッチデータジョブの実行、非同期メッセージキューの処理、複雑な AI エージェントのデプロイなどをすべて、比類のないデベロッパーエクスペリエンスと最大限のエンジニアリング速度を実現する単一の統合されたサーバーレスモデルで処理します。

Google AI Studio でのワンクリックプロトタイピング: フルスタックアプリケーションを直接構築してデプロイできる Google AI Studio は、迅速なプロトタイピングやテストに最適な環境となっています。ワンクリックで、バイブコーディングされたアプリケーションを即座にパッケージ化して Cloud Run に公開できます。
Cloud Run インスタンス: この新しいプリミティブは、Cloud Storage ボリュームマウントを統合した、個別にアドレス指定可能な長時間実行のシングルトンリソースを管理します。これにより、OpenClaw のような常駐型のバックグラウンドエージェントを費用対効果よくデプロイできるようになります。Cloud Run インスタンスは、ベースラインの共有 CPU 構成の料金が、予測しやすい月額約 5.70 ドルの定額料金（1 つの vCPU と 1 GiB の RAM の場合）からとなっており、従来の VM の無駄なアイドル費用や運用上のオーバーヘッドを回避しながら、常時稼働の VM のようなエクスペリエンスを提供します。
Cloud Run サンドボックス: 500 ミリ秒未満でスピンアップするハードウェア的に隔離された環境で、信頼性の低いモデル生成コードを安全に実行し、ホストシステムを不正アクセスから保護します。

次のステップ

Google は、コンテナプラットフォームのパフォーマンス、セキュリティ、スケールを新たな高みへと引き上げながら、オープンな環境で未来を築き続けています。ぜひ、Agent Sandbox と Agent Substrate を今すぐお試しください。お客様やパートナー様とともに、エージェントインフラストラクチャの未来を築いていけることを楽しみにしています。学習を続けるには、以下のリソースをご覧ください。

2026 年 Gartner® Magic Quadrant™ のコンテナ管理部門を無料でダウンロードできます。
GKE で Agent Sandbox をお試しください。
Agent Sandbox のオープンソースコミュニティに参加して協力しましょう。
Agent Substrate をご確認ください。
11 月 9～12 日にソルトレイクシティで開催される KubeCon North America 2026 にご参加ください。1 日早く到着して 11 月 9 日の GKE Day にも参加すると、より一層お楽しみいただけます。
Google が 2026 年 Gartner® Magic Quadrant™ でクラウドネイティブアプリケーションプラットフォーム部門のリーダーにも選出された理由をご確認ください。
cloud.run で、サーバーレスアプリケーションの未来を築きましょう。

^{1. Gartner レポート: Critical Capabilities for Container Management、2026 年 9 月 8 日}

^{Gartner、Magic Quadrant のコンテナ管理部門、Dennis Smith 他、2026 年 9 月 2 日Gartner、Critical Capabilities for Container Management、Tony Iams、Wataru Katsurashima、Lucas Albuquerque、Dennis Smith、Bhuvie Chhabra、2026 年 9 月 8 日。Gartner および Magic Quadrant は、Gartner, Inc. および / またはその関係会社の商標です。免責事項: Gartner は、発行物に掲載されている特定の企業、ベンダー、製品、サービスを推奨するものではありません。また、最高の格付けまたはその他の評価を得たベンダーのみを選択するように助言するものでもありません。Gartner の発行物は、Gartner のビジネスおよびテクノロジーインサイト組織の見解を表したものであり、事実を表現したものではありません。Gartner は、明示または黙示を問わず、商品性や特定の目的への適合性を含め、本出版物に関連したいかなる保証も行いません。}

ゲームチェンジャー: エージェント型 AI を使用してインフラストラクチャコードを保護する

Thu, 01 Oct 2026 02:00:00 +0000

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

AI は、かつてないペースでソフトウェア開発を加速させています。しかし、コード生成が拡大するにつれて、コードのセキュリティを確保する課題も増大しています。特に、AI を利用した新たな脆弱性の悪用が懸念されています。こうした課題に対処するため、Google AI およびインフラストラクチャチームは、セキュリティへの取り組み方を変革しています。この記事では、Google が開発した新しい AI ネイティブなエージェント手法について説明します。この手法は、高精度で網羅的な脆弱性スキャンとパッチ適用を、Google のソフトウェア開発ライフサイクルに体系的かつ直接組み込むものです。Google は、インフラストラクチャにデプロイされる数億行に及ぶコードのあらゆる変更を継続的にスキャンすることで、毎月数百件もの脆弱性がコードベースや本番環境に混入するのを未然に防ぎ、グローバルネットワーク、AI インフラストラクチャ、そしてユーザーを保護しています。

ソリューションアーキテクチャと実装

送信前のエージェント型スキャンを徹底: 継続的なソフトウェア開発の一環としてのセキュリティ

従来、テクノロジー業界は、処理に時間がかかり、十分なコンテキストを把握できない単発の大規模なセキュリティスキャンに頼ってきました。その結果、脆弱性の発見が遅れることがよくあります。Google のアプローチでは、これとは異なり送信前スキャンに焦点を当てています。AI エージェントを活用し、スタックのあらゆるレイヤにおいて、コードのチェックインをリアルタイムで評価します。デベロッパーの使い慣れたツールに送信前スキャンを統合することで、セキュリティは、ルールチェッカーや可読性レビューなどのソフトウェア開発ツールと同じように、開発プロセスにおける日常的なルーティン作業になります。また、AI の観点から見ると、個々のコード変更をスキャンする方が、大規模な 1 回限りのスキャンを実行するよりもはるかに少ないコンテキストで済むため、スキャンの効果が大幅に向上します。

ローカライズされた脅威モデルの重要性

この取り組みのために、Google はオープンソースのマルチエージェントレビューハーネスである Mantis を進化させ、ローカライズされた堅牢な脅威モデルのコホートと照合することで、セキュリティエージェントの精度を高めました。脅威モデルは、コードから切り離された静的なドキュメントに依存するのではなく、リアルタイムのコードベースメタデータを使用します。スキャンエージェントは、パッケージやライブラリ間の依存関係コールグラフを使用し、脅威モデルのコンテキストを拡張および洗練させることで、精度をさらに向上させます。脅威モデルを継続的な脆弱性スキャンの一部に組み込むことで、開発者が脅威や依存関係を常に更新するようになり、モデルを最新の状態に保つことができます。ローカライズされた正確な脅威モデルデータを使用することは、精度の劇的な向上に直結しており、場合によっては偽陽性率をわずか 3% にまで抑えることができます。

専門のトリアージエージェントが開発を加速

コードチェックインの一環として脆弱性スキャンを行う場合、エンジニアリングの生産性を妨げないよう、コードを生成する開発者やエージェントに迅速に対応する必要があります。低レイテンシで回答を得るために、2 段階の検証プロセスを実行しています。まず、迅速な軽量スキャンを実行し、その結果を専門のトリアージエージェントで検証します。このエージェントは、コードの実際の構造をプログラムでチェックし（抽象構文ツリーの解析、コールグラフの走査、事前インデックス化されたドメイン安全ルールを使用）、脆弱なパスが実際に攻撃者によって到達可能であることを証明します。このエージェントは 92% 以上の精度を達成し、1 分以内に作業を完了します。次に、夜間の統合テストの一環として、送信後のスキャンが第 2 の防御層として機能し、オフピークサイクルを使用して、複数の変更にわたって導入された可能性のある脆弱性をテストします。

バグ修正エージェントがループを閉じる

脆弱性を見つけることは、解決への道のりの半分にすぎません。Google のソリューションの最後のコンポーネントは、スキャン結果と生成された実証コード（脆弱性がどのように再現されるかを示すコードスニペット）を使用して、Google の社内コーディング標準に合致した正確な修正案を自律的に生成する自動バグ修正エージェントです。エージェントは、元の変更リクエストのレビューの一環として、人間によるレビューのために修正を送信します。これにより、検出から解決までの時間がさらに短縮されます。

学んだことと行動喚起

継続的なスキャンをソフトウェア開発ライフサイクルに直接組み込むことは、Google においてまさにゲームチェンジャーとなりました。AI が提示する修正案は広く採用されており、数多くの脆弱性がコードベースに混入するのを未然に防いでいます。セキュリティ向上を目指す組織であれば、次の原則に従うことで、同様の AI ネイティブなアプローチを導入することが可能です。

システムを分離する: バイアスを防ぐため、開発、スキャン、トリアージの各エージェントのハーネス、ルール、コンテキストを分離します。軽量な AI スキャンと決定的かつ構造的な検証を組み合わせることで、レイテンシを短縮し、精度を向上させます。
コンテキストを賢く使用する: 既存の脅威モデルをエージェントにフィードします。偽陽性を減らすには、正確なコンテキストが不可欠です。また、最新の脅威モデルを使用することで、送信前スキャンの真陽性率が向上し、チームのセキュリティポスチャーの最低基準が引き上げられます。
優れたハーネスを構築する: 基盤となるモデルの選択は重要ですが、マルチエージェントハーネスを使用すると、モデル選択のばらつきを補うことができるため、大きな効果が得られます。
修正を自動化する: エージェントを使用して、人間参加型の修正を提案し、解決までの時間をさらに短縮します。

独自の AI ネイティブなセキュリティ変革を始めたい場合は、Mantis がオープンソースとして公開されていますので、ぜひ活用してそのメリットをお役立てください。また、サイバーセキュリティの基礎や、このエージェント型パイプラインを支える他のプラットフォーム（Google Cloud、Gemini Enterprise、Trillium および Ironwood TPU で実行される Gemini モデル）についても詳しく学ぶことができます。また、Google Cloud のセキュアなソフトウェア開発のライフサイクル（SDLC）の取り組みに不可欠な要素として、エージェント型の脆弱性スキャンと修復が Google Cloud のお客様をどのように保護しているかについても、ヒントを得ることができます。

^{この成果の実現に多大な貢献をした主要メンバーである、Stella Voutsina（リードプログラムマネージャー）、Yulong Zhang（シニアスタッフセキュリティエンジニア、Mantis）、Nick Galloway（スタッフセキュリティエンジニア、Mantis）に心からの敬意を表します。}

- Google、上級エンジニア、Andrés Lagar-Cavilla

- バイスプレジデント兼エンジニアリングフェロー、Parthasarathy Ranganathan

Filestore エージェントボリュームのご紹介: エージェントワークスペース向けのフルマネージドストレージ

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

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

ビルドツールの運用から、データ分析パイプラインや共同リサーチまで、データドリブンなタスクの実行は、あらゆるエンタープライズエージェントにとって不可欠な作業です。

にもかかわらず、多くのプラットフォームチームは、エージェントのストレージ要件にカスタムの回避策を継ぎ合わせて対応しているのが現状です。たとえば、エージェントサンドボックスと一元化されたストレージの間で状態をやり取りしたり、ローカルディスクやセルフホスト型ファイルシステムを手動で管理したりしています。このようなアプローチは、エージェントフリートが拡大するにつれ、コールドスタート時のレイテンシ、運用の複雑化、未割り当てアイドル状態のストレージの費用といった課題とのバランスを取るのが難しくなります。

エージェントサンドボックスは、数千、数百万のセッションを同時進行する規模までスケーリングする可能性があります。ストレージはそれに合わせて上記の課題を克服し、ワークスペースの徹底した隔離、セッションの即時再開、柔軟な従量課金制、流動的なマルチエージェントコラボレーションを必要とする動的なワークロードのニーズを満たすように進化する必要があります。

こうした新たな需要に応えるため、Google は AI ストレージポートフォリオを拡大し、Filestore エージェントボリュームの提供を開始しました。これは、高パフォーマンスの柔軟なファイルストレージで Google Cloud でのエージェントワークロードのスケーリングを可能にするために設計されたフルマネージドの新機能です。

AI エージェントワークスペース専用のストレージ

自律型エージェントが安全にタスクを実行するためには、隔離されたランタイム環境が必要です。たとえば、動的コードの実行、サードパーティパッケージのインストール、各種ツールの運用を、ホストインフラストラクチャやテナントデータを危険にさらすことなく実行する必要があります。GKE 上の Agent Substrate と GKE Agent Sandbox は、高密度のエージェントフリートを実行するために必要な専用コンピューティング環境を提供しますが、サンドボックスには専用の永続ワークスペースも必要です。

Google Cloud Filestore に含まれる Filestore エージェントボリュームは、AI エージェントフリートのスケーリングと弾力性を考慮して特別に設計された動的プロビジョニングアーキテクチャにより、エージェントコンピューティングを補完する専用のエージェントストレージを提供します。Agent Substrate との連携で大規模なエージェントフリートもサポートできるように設計されており、GKE サンドボックスに隔離された永続的なファイルストレージへの即時アクセスを可能にします。Filestore を活用するようにエージェント環境を構成すると、GKE のストレージ管理がバックグラウンドで行われます。GKE が新しいエージェントタスク用にサンドボックスを起動するたびに、Filestore は隔離された専用ファイルワークスペースをミリ秒単位でその環境に自動的に割り当て、アタッチします。プラットフォームチームは、個々のエージェントの実行用にストレージボリュームを手動で作成、アタッチ、破棄する必要はありません。エージェントフリートのスケールアップとスケールダウンに応じて、システムがボリュームのライフサイクル全体を自動的に処理します。これにより、効率的なエンドツーエンドのインフラストラクチャソリューションが実現し、費用対効果の高いエージェント管理が以下の機能性をもたらします。

緻密な隔離と企業のガードレール: エージェントプラットフォームは、信頼できない自律型コードを実行する際に、セキュリティとデータ漏洩のリスクに直面します。Filestore エージェントボリュームは、ワークスペースごとに厳格な境界制御と細分化されたアクセス権限を適用します。これにより、エージェントは指定されたディレクトリ内でのみ動作し、動的なツールチェーンがテナント間で厳密に分離されます。
1 秒未満でのセッション再開: 従来のストレージプロビジョニング手法では、インタラクティブなエージェントセッションがコールドスタート時のレイテンシの影響で停止することがありました。Filestore エージェントボリュームではミリ秒単位でアタッチとデタッチが行われるため、オーケストレーターがアイドル状態のサンドボックスを積極的に停止してコンピューティング費用を節約し、新しいタスクやユーザー入力を受け取ると直ちに再開します。
スマートライフサイクルエコノミーと従量課金制: 数千もの短時間または断続的なエージェントタスクに固定サイズの高パフォーマンスストレージを事前割り当てすると、ストレージが大量に無駄になる可能性があります。Filestore エージェントボリュームを使用すると、プラットフォームは消費されたストレージ容量に対してのみ課金され、自動ライフサイクル階層化のメリットを享受できます。つまり、エージェントがコードの読み取り / 変更やデータセットの分析を行っていないときは、アイドル状態のワークスペースを自動的に低コストのストレージに移行でき、費用の無駄を省いて高パフォーマンスを実現できます。
マルチエージェントコラボレーション: マルチエージェントスウォームの使用は、データ受け渡しのパイプラインが脆弱になりがちで、ファイル競合のリスクにもつながります。Filestore エージェントボリュームは、ネイティブの Read-Write-Many（RWX）サポートと POSIX ファイルロックを備えており、オーケストレーターが複数のエージェントに単一の共有ワークスペースをアタッチできます。共同作業を行うエージェントは、ファイルレベルの整合性と書き込み競合プロテクトにより、プロジェクトファイルを安全に共同編集、テスト、レビューできます。

次世代エージェントワークロードをサポート

Filestore エージェントボリュームは、柔軟で高パフォーマンスの分離されたファイル階層化により、以下を含む本番環境の幅広いエージェントワークロードとユースケースをサポートします。

ソフトウェアエンジニアリングとコーディングのサンドボックス: エージェントコーディングプラットフォームで、数千件もの隔離されたワークスペースをスピンアップできます。エージェントは、ストレージ固有のカスタマイズを必要とせず、標準の POSIX ファイルセマンティクスを活用して、ライブラリのインストール、複数ファイルのパッチ作成、ビルドツールの運用、そして単体テストを安全に行うことができます。
マルチエージェントスウォームのコラボレーション: リードオーケストレーターがリサーチ、コード生成、検証担当の専任サブエージェントにタスクを委任するような複雑なワークフローで、統合ファイルツリーを直接共有できます。RWX サポートにより、エージェントは書き込みの競合を発生させることなく、プロジェクトファイルを同時に共同編集およびレビューできます。
インタラクティブな長期ワークフロー: ユーザーが関与するアプリケーション（ユーザー承認を不定期に複数回必要とするエージェントや、数時間にわたるデータ分析パイプラインを実行するエージェントなど）の場合、プラットフォームはアイドル状態のエージェントサンドボックスを一時停止してコンピューティングの無駄を最小限に抑え、実行の再開にはオンデマンドで瞬時に対応します。

今すぐ利用開始

Agent-as-a-Service プラットフォームの構築から、コーディング支援のスケーリングやエンタープライズエージェントフリートのデプロイまで、いかなるタスクにおいても、ストレージティアはイノベーションを妨げるのではなく、加速させるものでなければなりません。

Filestore エージェントボリュームは、Google Cloud のすべてのお客様が非本番環境ワークロードで今すぐご利用いただけます。本番環境ワークロードの一般提供サポートは、許可リストを通じてのご提供となります。この新サービスは、GKE 上の Agent Substrate および GKE Agent Sandbox と直ちに統合できる点を特長としており、応答性が高く、スケーラブルで、費用対効果の高いエージェントプラットフォームをすぐに構築することができます。

Filestore エージェントボリュームへのアクセスをご希望の場合は、こちらのフォームをご提出ください。詳細については、Filestore のドキュメントと GKE のドキュメントをご覧ください。

- グループプロダクトマネージャー、Micah Waldman

- エンジニアリングマネージャー、Maya Gal

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

これにより、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 0x7f1273e7be90>)])]>

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

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

このたび、タイムスライスのフルスタック（スナップショットエージェント、アクセラレータオーケストレーター、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 0x7f1280aaba90>)])]>

同じ 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 0x7f1272dba790>)])]>

ユースケース 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 0x7f128275bb10>)])]>

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 インフラストラクチャ

AI インフラストラクチャとオーケストレーションに関する最新情報

プロダクト、テクノロジー、ツールに関する最新情報

実践ガイドとハウツー

お客様とパートナーに関する最新情報

調査、レポート、詳細解説

2026 年 8 月

プロダクト、テクノロジー、ツールに関する最新情報

実践ガイド、ドキュメント、ハウツー

お客様とパートナーに関する最新情報

2026 年 7 月

プロダクト、テクノロジー、ツールに関する最新情報

実践ガイドとハウツー

調査、レポート、詳細解説

2026 年 6 月

プロダクト、テクノロジー、ツールに関する最新情報

実践ガイドとハウツー

調査、レポート、詳細解説

お客様とパートナーに関する最新情報

2026 年 5 月

プロダクト、テクノロジー、ツールに関する最新情報

調査、レポート、詳細解説

お客様とパートナーに関する最新情報

AI21、AI Hypercomputer の導入により AI ワークロードの起動時間を 83% 短縮

高使用率クラスタの行き詰まり

適切なスケジューラの選択

オープンソースとのフィードバックループの確立

同じフリートで、よりスムーズに

45 倍高速な GKE Agent Sandbox でエージェント型 RL と評価研究を加速

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

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

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

トレードオフ

ご利用開始

マルチクラスタ GKE Inference Gateway で 1% 未満のオーバーヘッドでグローバル AI ルーティングを実現

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

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

Linear scaling across regions

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

価値の提供

チームへの影響

次のステップ

Google、2026 年 Gartner Magic Quadrant でコンテナ管理部門のリーダーに選出

AI インフラストラクチャで優れたパフォーマンスと効率を実現

エージェント インフラストラクチャのセキュリティとスケールに対応する Kubernetes の進化

サーバーレス コンテナによる次世代のデベロッパー エクスペリエンス

次のステップ

ゲーム チェンジャー: エージェント型 AI を使用してインフラストラクチャ コードを保護する

ソリューション アーキテクチャと実装

ローカライズされた脅威モデルの重要性

専門のトリアージ エージェントが開発を加速

バグ修正エージェントがループを閉じる

学んだことと行動喚起

Filestore エージェント ボリュームのご紹介: エージェント ワークスペース向けのフルマネージド ストレージ

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 ジョブのインターリーブ）のメリット

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

フロー: 全体像

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

エージェントインフラストラクチャのセキュリティとスケールに対応する Kubernetes の進化

サーバーレスコンテナによる次世代のデベロッパーエクスペリエンス

ゲームチェンジャー: エージェント型 AI を使用してインフラストラクチャコードを保護する

ソリューションアーキテクチャと実装

専門のトリアージエージェントが開発を加速

Filestore エージェントボリュームのご紹介: エージェントワークスペース向けのフルマネージドストレージ

AI エージェントワークスペース専用のストレージ

次世代エージェントワークロードをサポート

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

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

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

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

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

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