Containers & Kubernetes

GKE の弾力性がさらに向上: ゼロへのスケーリング、費用削減、ワークロードの応答性維持

Sat, 17 Oct 2026 02:00:00 +0000

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

真の弾力性は、クラウドネイティブエンジニアリングの究極の目標として長年追求されてきました。Kubernetes はリソース管理に革命をもたらしましたが、散発的に実行されるワークロード（バッチプロセッサ、イベントドリブンワーカー、開発環境など）は、処理を待機している間もコンピューティングリソースを消費するため、費用の増加を招きます。

Google Kubernetes Engine（GKE）1.37 では、ゼロへのスケールダウンとゼロからのスケールアップをネイティブに実現することで、この問題に正面から取り組んでいます。新しい一連の機能を使用すると、ワークロードを完全にゼロレプリカにスケールダウンして、リソースの消費を停止できます。同時に、需要が戻ったときには、GKE のキャパシティバッファでこれらのワークロードを迅速かつ簡単に再起動できるため、インフラストラクチャの無駄を減らすことができます。これは単に費用を削減するだけでなく、常時稼働のインフラストラクチャの費用をワークロードの準備状況から切り離すことにもつながります。

進化: HPA ベースのゼロへのスケーリングと KEDA

長年にわたり、Kubernetes Event-Driven Autoscaling（KEDA）というオプションの Kubernetes コンポーネントが、ゼロへのスケーリングの定番ソリューションでした。KEDA は強力ですが、環境が複雑になります。

機能	GKE のゼロへのスケーリング	KEDA ベースの設定
運用上のトイル	マネージドサービス。追加のコンポーネントは不要。	`ScaledObject` CRD とオペレーターの管理が必要。
構成	ネイティブなHPA と CRD（最小限の YAML）。	大規模なフリートでは、YAML が 10,000 行を超えることもあります。
レイテンシ	内部化された信号経路により、反応時間を短縮します。	ポーリング間隔とホップ数により、コールドスタートの遅延が増加します。

ゼロへのスケーリングを GKE コントロールプレーンに直接組み込むことで、アドオンオペレーターや数千行の構成が不要になります。ロジックは「サイドカー管理」からワークロードのネイティブ属性に移行します。

仕組み: AutoscalingMetric と KEP-2021 を使用した HPA

GKE 内でゼロにスケールする鍵は、2 つの重要なコンポーネントの統合にあります。

AutoscalingMetric を使用した HPA: これは、Google Cloud Managed Service for Prometheus からの外部シグナルの直接読み取りをサポートするマネージド指標シグナルパイプラインです。AutoscalingMetric を使用した HorizontalPodAutoscaler（HPA）は、Pub/Sub、Cloud Monitoring、ロードバランサのシグナルからオートスケーラーに指標を送信するための、統合された高パフォーマンスのパスを提供します。アダプターの煩雑さを伴わずに済みます。
KEP-2021: HPA で minReplicas: 0 を可能にする Kubernetes Enhancement Proposal

に基づいて構築されたこのメカニズムにより、指標がしきい値を下回ると、HPA はすべての Pod を停止できます。また、指標が保留中の作業を示したらすぐに、HPA が Deployment を「起動」できるようにします。

最初の「ゼロへのスケーリング」ワークロードの構成

ネイティブなゼロへのスケーリングを実装するには、指標定義と HPA という 2 つの主要なオブジェクトが必要です。次の例では、Pub/Sub サブスクリプションの未配信メッセージ数に基づいてワーカーをスケーリングします。

指標のソースを定義する

AutoscalingMetric CRD を使用して、外部の Cloud Monitoring 指標をクラスタにマッピングします。

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling.gke.io/v1beta1\r\nkind: AutoscalingMetric\r\nmetadata:\r\n name: my-autoscalingmetric\r\nspec:\r\n metrics:\r\n - promql:\r\n name: pubsub-undelivered\r\n query: >\r\n {\r\n "pubsub.googleapis.com/subscription/num_undelivered_messages",\r\n subscription_id="my-subscription"\r\n }'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45a5bfb10>)])]>

minReplicas: 0 を使用して HPA を構成する

HPA で指標を参照し、最小レプリカ数を明示的にゼロに設定します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling/v2\r\nkind: HorizontalPodAutoscaler\r\nmetadata:\r\n name: worker-hpa\r\nspec:\r\n scaleTargetRef:\r\n apiVersion: apps/v1\r\n kind: Deployment\r\n name: worker-deployment\r\n minReplicas: 0\r\n maxReplicas: 50\r\n metrics:\r\n - type: External\r\n pods:\r\n metric:\r\n name: autoscaling.gke.io|my-autoscalingmetric|pubsub-undelivered\r\n target:\r\n type: AverageValue\r\n averageValue: 10'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45a5be5d0>)])]>

これで、外部指標に基づいてワークロードをゼロにスケールダウンしたり、ゼロからスケールアップしたりできるようになりました。

ゼロへのスケーリング機能は、Cloud Monitoring からの外部指標を GKE でサポートすることで実現しています。AutoscalingMetric カスタムリソースを拡張することで、複雑なサードパーティアダプタを使用せずに、Google Managed Service for Prometheus から指標をクエリできるようになりました。これにより、レイテンシが短縮され、セキュリティが簡素化されます。また、ネイティブな「ゼロへのスケーリング」ワークロードを構成するための重要な基盤となります。このインテグレーションについて詳しくは、GKE での外部指標のネイティブサポートに関するブログ投稿をご覧ください。

キャパシティバッファによる起動レイテンシの管理

ゼロからのスケーリングにおける最大の課題は、いわゆるコールドスタートです。これは、GKE がノードをプロビジョニングし、コンテナがそれを pull して起動するまでにかかる時間です。そこで役立つのが GKE キャパシティバッファです。

キャパシティバッファは、プールされたウォーム状態のキャパシティとして機能します。GKE は、ゼロにスケールできる複数のワークロードで共有できる少量のウォームコンピューティングリソースを維持することで、HPA が 0 から 1 にジャンプしたときに、Pod がすぐに要求できるリソースを確保します。これにより、新しい GKE ノードがスピンアップするまでの 60～90 秒の待ち時間がなくなり、起動レイテンシが数分から瞬時に短縮されます。その間、ワークロードの費用はゼロに抑えられます。

キャパシティバッファには、アクティブとスタンバイの 2 種類があります。小さなアクティブバッファは、ゼロにスケールされた数百のワークロードに対応できます。各ワークロードがレプリカを維持するのではなく、アクティブバッファがクラスタ全体にサービスを提供するワイルドカードキャパシティとして機能します。スタンバイバッファはアクティブバッファに比べて大幅に低コストで、サイズが大きくなるため、クラスタで持続的な負荷が発生した場合にアクティブバッファを迅速に補充できます。これらを併用することで、即時のスケーリングを実現しながら、低コストも維持できます。

今後について

Google は、GKE の弾力性に関するロードマップを継続的に拡大しています。たとえば、開発環境を午後 8 時にゼロにスケールダウンし、午前 7 時にスケールアップするとします。繰り返し発生するスケーリングをより細かく制御する方法に注目し、ゼロへのスケーリングの時間枠を事前に定義できるようにしましょう。

ゼロへのスケーリングを今すぐ始めましょう

アイドル状態のリソースに料金を支払う時代は終わりを迎えようとしています。イベントドリブンなワークロードや散発的なワークロードに対して GKE のネイティブなゼロへのスケール機能を有効にすることで、起動パフォーマンスを犠牲にすることなく費用を削減できます。ゼロへのスケールを開始するには、次の手順を行います。

アイドル期間を伴う、需要が変動するワークロードを特定します。
AutoscalingMetric を構成し、minReplicas をゼロに設定します。
クラスタまたはワークロードにキャパシティバッファを追加して、応答時間を短縮します。

詳細は、HPA を使用した GKE ワークロードのゼロへのスケールダウンとゼロからのスケールアップに関するドキュメントをご覧ください。

- Google Kubernetes Engine、プロダクトマネージャー、Eyal Yablonka

- Google Kubernetes Engine、シニアソフトウェアエンジニア、Scott Funkenhauser

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 支援による EKS から GKE への移行を実現する GKE エージェント型移行の概要

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

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

最も重要な AI 駆動型ワークロードを実行するために、Google Kubernetes Engine（GKE）を標準として採用する企業が増えています。高スループットのデータアクセスを実現する Cloud Storage FUSE から、カスタムコンピューティングクラス（CCC）や高度な GPU スライス法まで、GKE は最新のアプリケーションに必要なスケールと効率性を備えています。

しかし、複雑な Kubernetes 環境を AWS EKS から GKE に移行することは、従来、エンジニアリング上の大きな課題であり、多大な手間を伴うものでした。プラットフォームチームは、複雑な Infrastructure as Code（IaC）を手動で分析し、クラウド固有のアーキテクチャの違いを把握して、カスタム変換スクリプトを構築する必要があります。

エンジニアリングチームは、汎用 LLM を使用してコード変換のドラフトを作成することをよく試みていますが、アドホックなプロンプトはすぐに運用上の落とし穴になる可能性があります。未加工のモデルは、存在しないリソースプロパティのハルシネーションを起こしたり、重要なネットワーク構成や ID 構成を欠落させたり、相互に依存するファイル間でコンテキストを失ったりします。プラットフォームエンジニアがモデルエラーを監査、解決、デバッグするために費やす時間は、当初得られるはずだったスピード向上効果を相殺し、手作業による労力と予測不可能性を生み出します。

このたび、Google は GKE エージェント型移行のオープンソースリリースを発表いたしました。これは、不安定なアドホックプロンプトに代わり、決定論的なガードレールで保護された AI 支援移行パイプラインを提供する専用のエージェントプラグインです。

「大企業のお客様にとって、クラウドのモダナイゼーションにおける最大の障壁は、実行リスクと予測不可能性です。コンテキストを失い、構成をハルシネーションする未加工のチャットプロンプトとは異なり、Google の GKE エージェント型移行は、生成 AI のスピードと、企業が必要とする決定論的なガードレール（構造化された状態の永続性、プラットフォームチームとアプリチーム間のマルチペルソナ境界、交渉の余地のない人間の承認ゲート）の両方を備えてます。これにより、当社のグローバルエンジニアリング部門は、コンパイラ並みの精度で検証可能な移行ファクトリーを手に入れることができ、デリバリーリスクを大幅に削減できました。- Persistent、EVP、Rahul Shrivastava 氏

インフラストラクチャの移行に伴う課題

インフラストラクチャの移行プロセスについてお客様と話すとき、ガバナンスに関するいくつかの課題をよく耳にします。

自動化の信頼ギャップ: Kubernetes 構成を手動でリファクタリングすると、非常に時間がかかることがあります。しかし、汎用的な AI コーディングアシスタントを使用すると、許容できないリスクが生じます。標準的な LLM は、インフラストラクチャコードをハルシネーションしたり、非推奨の API フィールドを使用したり、重要なセキュリティルールを省略したりすることがあります。「ほぼ正しい」コードを生成しても、ボトルネックがコードの作成からデバッグに移行するにすぎません。
ライブクラスタの可変性の危険性（ClickOps）: 従来の移行ツールは多くの場合、ライブクラスタに直接接続し、API 呼び出しを介してデプロイします。これにより、組織の Git リポジトリ（信頼できる情報源）がバイパスされて、CI / CD パイプラインが中断され、ロールバックが非常に困難になります。
サイロ化されたハンドオフのボトルネック: 移行は多くの場合、複数週にわたる長期的な作業となります。プラットフォームエンジニアがランディングゾーンを構築し、アプリケーションデベロッパーがワークロードを移行します。標準的な AI ツールを使うと、引き継ぎ時にコンテキストが失われます。
断片化されたツールチェーン: Velero などのバックアップツールは障害復旧には優れていますが、AWS 固有の構成（ALB など）をそのままキャプチャするため、Google Cloud 向けには変換されません。一方、リバースエンジニアリングツールは、デベロッパーの本来の論理的な意図を排除したフラットな構成を生成します。

GKE エージェント型移行の概要

GKE エージェント型移行は、LLM の推論機能と厳格で決定論的なツールを組み合わせることで、これらの課題に対処します。エージェントスキルとローカルの Model Context Protocol（MCP）サーバーを組み合わせた設計になっており、AI を使用して複雑な AWS EKS IaC と Kubernetes マニフェストを、自動化された pull リクエスト経由で GKE ランディングゾーンに直接変換します。

GKE エージェント型移行の特徴となっている主な機能は次のとおりです。

1. ハイブリッド検証 - LLM で生成し、決定論的に検証。危険な IaC ハルシネーションに対処するため、LLM ワーカーが Terraform と Kubernetes YAML の複雑な作成を処理し、サーバーが Workload Identity アノテーションやイメージレジストリなどの正確なマッピングのために決定論的な変換を実行します。重要なのは、AI が生成したこれらの変換は、ユーザーに提示される前に、厳格な決定論的検証（terraform validate、Kubernetes マニフェストコントラクトなど）にかけられることです。このアプローチは、ハルシネーションに対する安全性を維持しつつ、あらゆる操作を人間参加型（HITL）の承認によって制限するのに役立ちます。

2. GitOps ネイティブの PR ワークフロー: プラグインがライブクラスタに変更を直接適用することはありません。代わりに、信頼できる情報源を読み取り、ターゲット状態を生成して、pull リクエストを開きます。これにより、すべての変更が標準の人間参加型（HITL）CI / CD 審査プロセスをとおして処理されるようになります。「ClickOps」は不要です。

3. 変換と転送の分離を保護: プラグインは、アーキテクチャ変換の面倒なロジックを自動化しますが、ステートフルデータを意図的に転送しません。最も機密性の高いアセットを保護するため、プラグインは、専用の SLA に裏付けられたツール（Google Cloud の Database Migration Service や Storage Transfer Service など）の使用をチームに指示する、コンテキストに応じたランブックを生成します。

4. マルチペルソナの状態管理: 移行はチームが行う取り組みです。プラグインは、長時間実行される移行状態を保持します。これにより、保護された非同期のハンドオフが可能になります。プラットフォームエンジニアがベースラインのランディングゾーンを確立し、アプリデベロッパーは各自のマシンからワークスペースに個別にアクセスして、権限が分離されたフォルダ内で個々のワークロードを変換します。

仕組み: 移行のライフサイクル

内部的には、GKE エージェント型移行は実行可能関数の移行状態グラフを利用し、チェーンに沿ってコンテキストを体系的に渡します。オープンソースのエージェントプラグインとしてパッケージ化されているため、カスタム CLI バイナリをインストールする必要も、中央のコントロールプレーンを管理する必要もありません。チームは既存の開発ハーネスを通じてコラボレーションし、検証済みの pull リクエストと実用的なランブックをソースリポジトリに直接配信できます。これには、次のような利点があります。

EKS リポジトリの念入りな検出: プラグインは、ソース Git リポジトリのクローンを作成するか、EKS クラスタのライブスキャンを実行し、ソースマニフェストをプログラムによりインデックスに登録して、依存関係をマッピングし、インベントリを構築します。
評価とブロッカーガバナンス: アーキテクチャの非互換性を特定する準備状況レポートを生成します。設計を開始する前に、すべてのブロッカーにオーナーと解決目標日を割り当てる必要があります。プラットフォームエンジニアは、変換を開始する前に移行の境界を承認します。
ランディングゾーンの設計: プラグインは、プラットフォームの明示的な決定（GKE Autopilot か GKE Standard かなど）に基づいて、基本的な Google Cloud Terraform モジュール（VPC、サブネット、GKE クラスタ、組織のポリシー）をスキャフォールディングします。
AI を活用したクラウド変換: プラグインは、AWS IRSA から Workload Identity への変換、ALB Ingress から Gateway API へのマッピング、Karpenter ノードクレームから GKE ノード自動プロビジョニング（NAP）またはカスタムコンピューティングクラス（CCC）への変換など、独自の移行を処理します。
オフライン検証: 生成されたモジュールとマニフェストは、オフラインでコンパイルされ、検証されます（terraform validate、マニフェスト構造のチェック、出力コントラクト）。
デプロイ（pull リクエスト経由）: 最終的な構成がローカルで検証され、レビューのために PR が開かれます。

使ってみる

GKE エージェント型移行は、クラウド移行を、まとまりのないリファクタリング作業から、予測可能で AI が支援する、レビュー可能な GitOps ワークフローへと変革します。GKE への移行を加速させる準備は整いましたか？

GitHub の GKE エージェント型移行リポジトリにスターを付け、クローンを作成してみましょう。
オンボーディングガイドを読み、サンプルの EKS リポジトリに対してプラグインを実行しましょう。
Google Cloud コミュニティに参加して、フィードバックの共有、質問、投稿を行ってください。

- GKE プロダクトマネージャー、Sunny Hwang

- GKE エンジニアリングマネージャー、Hamed Seifoddini

Agent Substrate は GKE にて高密度でスケーラブルな信頼できるインフラストラクチャを提供します

Fri, 25 Sep 2026 02:00:00 +0000

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

本日は、Google Kubernetes Engine（GKE）で Agent Substrate が利用可能になったことをお知らせします。Agent Substrate は、オープンソースかつセキュアバイデフォルトのエージェント実行ランタイムであり、標準的なコンテナランタイムよりも 10 倍高い密度で数百万のサンドボックスを実行できるように設計されています。自律型エージェントの時代に向けて専用設計された Substrate は、ネイティブのゼロトラストカーネルとネットワーク分離により、1 秒あたり 500 回を超える一時停止 / 再開アクティベーションを実行しながら、500 ミリ秒未満での再開オペレーションを実現します。

Agent Substrate は、あらゆる Kubernetes インフラストラクチャで動作し、GKE 向けに最適化されたオープンソースソリューションとして提供されます。最先端の AI チームはすでに Agent Substrate を活用しています。Hermes Agent の開発チームである Nous Research は、Agent Substrate を基盤とした開発を積極的に進めています。Hermes は現在、生産性、コーディング、CLI、個人向けエージェントの OpenRouter 使用量において、世界第 1 位の AI エージェントにランクされています。

ローカルから 100 万エージェント規模へ

デベロッパーはすでに Antigravity、Claude Code、Codex、OpenClaw、Hermes などのハーネスをローカルで実行していますが、それと、コード生成、ツールとの連携、自動実行を行う数十万の長期実行エージェントを同時に稼働させることとでは、根本的に異なります。そして、これこそが既存のアーキテクチャでは対応が極めて難しい課題となっています。

エージェントプラットフォームをローカルプロトタイプから大規模なエージェントの実行にスケールすると、インフラストラクチャの制約が根本的に変化します。これには、次のようなものが含まれます。

不透明な信頼境界: モデルは任意のコードをその場で生成して実行できます。カーネルレベルの分離と動的なネットワーク制御がなければ、人間の目に触れたことのない信頼できないコードを実行することは、ホストエスケープや認証情報の窃盗、データの流出といったリスクを伴います。
ツールアクセスの障壁: エージェントがコマンドラインツール、ヘッドレスブラウザ、ファイルシステムワークスペースを呼び出すには、フル機能のコンピュータ環境が必要です。これらを安全に実行するには、高速かつ容易でなければなりません。
大規模なバースト: エージェントハーネス、ベンチマーク、強化学習のロールアウトにより、1 分間に数千のサンドボックスが生成されることがあります。汎用スケジューラはこうしたチャーンに対応しきれず、また、コンテナイメージが繰り返し解凍されることで、深刻なディスク競合が発生する恐れがあります。
アイドル状態のコンピューティング: 自律型エージェントは、モデルの推論、ツールの応答、人間のフィードバックを待つ間、ほとんどの時間を休止状態で過ごします。アイドル状態のコンテナに専用の CPU と RAM を予約すると、貴重なリソースが無駄になります。

エージェント専用に構築された基盤

プラットフォームチームがこれらの課題にぶつかったとき、彼らは受け入れがたいトレードオフを迫られます。それは、「制御と分離を犠牲にする」か、それとも「VM の高レイテンシと非効率性に目をつぶる」か、という選択です。Google は、チームがどちらか一方を選択する必要はないと考えています。

Agent Substrate は、エージェントの実行をマシン管理から切り離すことで、この問題を回避します。クラウドネイティブな Kubernetes インフラストラクチャ上に構築された Agent Substrate は、エージェントワークロード専用に設計された新しい実行レイヤを提供します。

この基盤の上で、実行レイヤがサンドボックス化されたエージェント環境のライフサイクルを直接管理し、以下の機能を提供します。

デフォルトでのセキュリティ確保: ハードウェアで分離された Cloud Hypervisor microVM または gVisor サンドボックスを採用。さらに、きめ細かいネットワークポリシーを適用する Egress プロキシを組み合わせ、エージェントの手の届かない場所で認証情報を安全に挿入することで、認証情報の窃盗を防止します。
1 秒未満で起動: コンテナの起動遅延を排除。オンデマンドで、事前にウォームアップされたワーカーに対して、アクティブ化したエージェントをミリ秒単位で即座にディスパッチします。
高効率: アイドル状態のアクターは数百ミリ秒で一時停止され、スケジュールが解除されるため、コンピューティングリソースが解放されます。
オープンソースでポータブル: あらゆるコンピューティング環境のあらゆる Kubernetes クラスタで実行でき、Claude Code、OpenClaw、Hermes などのあらゆるエージェントフレームワークやハーネスと連携します。

アーキテクチャの基本原則

Agent Substrate がこれらの課題を解決する上での指針として、以下の4つのコア・アーキテクチャ原則を掲げています。

1. カーネルとネットワークのレベルで、デフォルトで保護

AI エージェントは、信頼できないコードやターミナルコマンドを生成、実行することをコア機能としています。共有サーバー上でそうしたコードを実行することは、共有カーネルまたはネットワークレベルで、ブレイクアウトや意図しないデータ漏洩を引き起こす重大なリスクを伴います。

Agent Substrate は、ホストカーネルとネットワークレイヤの両方で、デフォルトで安全な状態を維持します。チームは、完全な Linux カーネル互換性を提供するハードウェア分離された Cloud Hypervisor microVM か、さらにオーバーヘッドの低いカーネル分離を提供する gVisor サンドボックスのいずれかを選択できます。Agent Substrate の統合ゲートウェイは、すべての Egress リクエストと Ingress リクエストを管理し、ネットワークアクセスをきめ細かく拡張可能な方法で制御できるようにします。

2. 低レイテンシのアクティベーション用に構築されたコントロールプレーンとデータプレーン

分離された環境で長時間実行されるエージェントワークロードの密度を最適化するには、レイテンシを極限まで抑え、一時停止および再開のオペレーションを極めて高い頻度で実行できる、専用設計のコントロールプレーンとデータプレーンが必要です。Agent Substrate は、最小限のレイテンシでデータアウェアスケジューリングを処理する専用のコントロールプレーンを導入しています。一方、データプレーンは、事前にウォームアップされたワーカー上で 1 秒あたり数百件の一時停止 / 再開オペレーションを直接処理し、環境の準備にかかるオーバーヘッドを削減します。スナップショットは、永続的な状態を維持するためにローカルディスクと Google Cloud Storage に書き込まれます。サンドボックス環境は 500 ミリ秒未満で以前の状態に再開でき、アイドル状態になるとすぐに再び一時停止できます。

3. 高密度かつアクティブ時のみのコンピューティングエコノミクス

エージェントは、ほとんどの時間をモデルの推論、ツールの応答、ユーザー入力の待機に費やします。アイドル状態のコンテナのために物理 CPU と RAM を予約することは、高価で希少な容量をロックすることになり、エージェントフリートを大規模に実行できなくなる恐れがあります。

Agent Substrate は、エージェントが一時停止した瞬間にリソースを解放できます。ゲストハイパーバイザの状態をローカルディスクと Cloud Storage にスナップショットとして保存し、そのまま維持しながら、RAM と CPU を解放して他のエージェントを実行できるようにします。次のターンまたはツール呼び出しが到着すると、Agent Substrate はスナップショットとして保存したセッションをミリ秒単位で再開します。このゼロアイドルモデルでは、ホストあたり 1,000 を超える休止状態のエージェントを収容でき、従来のコンピューティングよりも 10 倍高いコンピューティング密度を実現します。ターン間で共有ファイルシステムを必要とするワークロードの場合、オプションの Filestore エージェントボリュームコントローラが永続的な NFS ストレージを提供します。詳細については後述します。

4. 基盤としての Kubernetes: スケールと信頼性

標準 VM 上にカスタムサンドボックスオーケストレーターを構築すると、チームはノードの復元、自動スケーリング、マルチゾーンスケジューリング、ネットワークポリシーといった、煩雑な運用ツールのメンテナンスを余儀なくされます。しかし、1 秒に満たないツール呼び出しを標準の Kubernetes Pod ライフサイクル経由でルーティングすると、リクエストごとに数秒の遅延が発生してしまいます。

Agent Substrate は、両方のアプローチを組み合わせています。高頻度の一時停止 / 再開は、専用設計されたデータプレーンを介してローカルワーカー上で直接実行されます。一方、Kubernetes はマシンを管理し、自己修復ノード、フリートの自動スケーリング、クラスタの信頼性を制御するとともに、ワーカー Pod 自体のライフサイクルを司ります。標準の Pod セマンティクスを必要とするワークロードでは、Agent Sandbox やカーネル分離 Pod などの既存のプリミティブが引き続き並行して動作します。

Google Cloud インフラストラクチャ向けに最適化

100 万エージェント規模を実現できるエージェントプラットフォームを構築するには、適切な基盤となるコンピューティングとストレージのインフラストラクチャが必要です。GKE 上の Agent Substrate は、カスタム ComputeClass を使用して、スポットプールやオンデマンドプールを含む、さまざまなシェイプやファミリーにわたるマシンプールを動的に管理することで、マシンの入手可能性と柔軟性を最大化します。これには、Google のカスタム Arm ベースプロセッサである Google Axion のネイティブサポートが含まれます。Google Axion は、競合するクラウドサービスと比較して、サンドボックスワークロードのコストパフォーマンスを最大 30% 向上させます。ステートフルなワークスペースの場合、GKE 上の Agent Substrate を Filestore エージェントボリュームとオプションで統合できます。これは、NFS マウントをミリ秒単位でアタッチ / デタッチする新しいサービスで、エージェントをほぼ瞬時に開始 / 再開できます。また、ネイティブの Read-Write-Many（RWX）アクセスと POSIX 準拠のファイルロックにより、書き込みの競合なしに安全なマルチエージェントコラボレーションを実現します。

スケーラブルな基盤上にエージェントプラットフォームを構築

本番環境向けのエージェントアプリケーションを構築する際、強固なセキュリティ、低レイテンシ、運用規模のいずれかを犠牲にする必要はありません。

Nous Research は、OpenRouter において使用量世界第 1 位を誇る AI エージェントである Hermes を開発しています。Hermes は、生産性、コーディング、個人向け、CLI エージェントでも第 1 位にランクされています。Nous Research は、Agent Substrate の初期設計パートナーとして、エージェントワークロードが導入する分離と ID の要件をランタイムがどのように処理するかを評価しています。

「Hermes Enterprise は、お客様が既存のインフラストラクチャにデプロイできるようにすると同時に、エージェントごとの分離と拡張可能なアクセス制御を処理できるように構築されています。Agent Substrate は、プラットフォームレイヤでこの両方に対処しつつ、貴重なコンピューティングリソースの消費も抑えます。Agent Substrate を使用した経験から、エージェントワークロードの増加に合わせてアーキテクチャを効率的にスケールできると確信しています。」 - Nous Research、最高ビジネス責任者、Hervé Bizira 氏

Agent Substrate は、Kubernetes のマシンの復元力、自己修復ノード、宣言型管理を、カーネル分離、アクティブ時のみのコンピューティング、1 秒未満の実行のために構築されたエージェントネイティブのデータプレーンと組み合わせることで、エンジニアリングチームに確実な拡張への道筋を提供します。

Agent Substrate はオープンソースであり、GKE をご利用のすべてのお客様が非本番環境ワークロードで利用できます。本番環境向けの一般提供サポートは、許可リストを通じてご利用いただけます。GKE クラスタにデプロイするには、GKE 上の Agent Substrate に関するドキュメントをご覧ください。詳細については、Agent Substrate について、またはオープンソースリポジトリをご覧ください。

- エンジニアリング担当バイスプレジデント、Alex Zakonov

- エンジニア、Tim Hockin

分散 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 0x7fa45976a890>)])]>

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

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 氏

GKE の ClusterNetworkPolicy: マイクロサービスの制御と自律性のバランスを取る

Mon, 24 Aug 2026 01:00:00 +0000

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

マルチテナントの Kubernetes 環境におけるネットワークセキュリティの管理では、通常、2 つの異なるニーズのバランスを取ることが求められます。デベロッパーがマイクロサービス間で円滑な通信を確保したいと考える一方で、プラットフォームおよびセキュリティチームは、コンプライアンスの維持、ラテラルムーブメントの防止、そしてクラスタ全体のガードレールの確立を確実に行わなければなりません。

従来、これには標準の Kubernetes NetworkPolicy が主なツールとして使われてきました。標準の NetworkPolicy は、単一の名前空間を分離するには効果的ですが、そのスコープは個々の名前空間に厳密に限定されており、デベロッパーのセルフサービスを前提とした設計になっています。クラスタ管理者がグローバルなセキュリティ強化のために使用しようとすると、ポリシーの競合や運用上の課題が生じる可能性があります。

この問題に対処するため、Google は Kubernetes SIG-Policy ワーキンググループ（WG）が開発したオープンソース標準である ClusterNetworkPolicy（CNP）を Google Kubernetes Engine（GKE）に導入しました。大規模環境を想定して設計された CNP は、クラスタ全体のリソースです。これにより、管理者はネットワークセキュリティを一元管理できるようになり、グローバルセキュリティの担当者が、一貫性のあるバイパスできないポリシーを実装するための仕組みを提供します。

CNP の技術的な詳細、一般的なユースケース、ポリシーの例、利用開始方法について、以下をご覧ください。

ティアによるポリシーの構造化

ClusterNetworkPolicy のコア機能は、その階層的なティアシステムです。CNP は、フラットで競合するピアルールを同時に調整しようとするのではなく、決定論的なトップダウンの評価階層を確立します。

管理者ティア: 最も優先度の高いレベル。ここでのルールは、他のあらゆるポリシーよりも先に適用されます。
ネットワークポリシーティア: 標準の名前空間レベル。デベロッパーが個々のアプリケーションポリシーを管理します。
ベースラインティア: 最も優先順位が低く、他のどのポリシーも適用されない場合のクラスタのデフォルト動作を規定します。これは、名前空間スコープのポリシーを使用でオーバーライドできます。

このティア構造により、ネットワークセキュリティを組織の役割と整合させることができます。標準のロールベースアクセス制御（RBAC）を使用すると、管理者ティアを管理してコンプライアンス要件を適用できます。一方、プラットフォームチームはベースラインティアを使用して、クラスタ全体にデフォルトの「すべて拒否」ゼロトラスト体制を設定できます。同時に、デベロッパーはコアセキュリティ要件をオーバーライドすることなく、自身のアプリケーションに対して標準ネットワークポリシーを定義できます。

この決定論的なトップダウンの評価方法により、異なるチームのポリシー間の競合が解消されます。管理者ティアでは、明示的な Pass アクションが導入されています。これにより、セキュリティチームはグローバルルールに照らしてトラフィックを検査し、最終的な許可または拒否の決定をデベロッパーの名前空間ポリシーに委任できるため、中央での統制と分散管理の両立が容易になります。

一般的なネットワークセキュリティシナリオ

このティアアーキテクチャは、複雑なセキュリティ要件を一元化されたルールへと落とし込みます。ClusterNetworkPolicy が有効な解決策となる一般的なシナリオをいくつか紹介します。

機密性の高いワークロードの分離: 管理者ティアのグローバル拒否ルールを適用して、支払い処理やコンプライアンスデータに使用される名前空間など、特定の名前空間をクラスタの他の部分から分離できます。このアクションは、放っておくとこれらの環境をさらしてしまう恐れのある、制限の緩いデベロッパーポリシーをオーバーライドします。
コアサービスの保護: 内部運用に支障をきたすような構成を防ぐため、管理者は kube-dns などの重要なサービスに対して、管理者ティアのグローバル許可ルールを作成できます。これにより、名前空間ポリシーに構成ミスがあっても、これらのサービスへのアクセスを維持できます。
外部への下り（外向き）の管理: IP アドレス範囲のマッチングを利用することで、下り（外向き）トラフィックをクラスタレベルで制御できます。この機能を使用すると、企業イントラネットや外部 IP 範囲へのアクセスを明示的に制限または許可できるため、不正なデータの持ち出しに対する安全対策として機能します。

シナリオの例

一般的な企業の要件を考えてみましょう。すべての名前空間にわたるアプリケーションワークロードは、中央のプラットフォームインフラストラクチャ（共有認証サービスやテレメトリーサービスなど）へのアクセスが許可されている必要がありますが、その一方で、機密性の高い環境（制限付きの Vault 名前空間など）へのアクセスは厳格に禁止されます。その一方で、通常のマイクロサービス間のトラフィックは、デベロッパーが管理する名前空間スコープのポリシーに委ねられます。

ClusterNetworkPolicy を使えば、これを簡単に実現できます。プラットフォーム管理者は、管理者ティアのガードレールを次のように一元的に定義するだけです。

code_block: <ListValue: [StructValue([('code', 'apiVersion: policy.networking.k8s.io/v1alpha2\r\nkind: ClusterNetworkPolicy\r\nmetadata:\r\n name: platform-isolation-guardrail\r\nspec:\r\n tier: Admin\r\n priority: 10\r\n subject:\r\n # Target all application tenant namespaces, excluding system and core infrastructure\r\n namespaces:\r\n matchExpressions:\r\n - key: kubernetes.io/metadata.name\r\n operator: NotIn\r\n values: ["kube-system", "shared-services", "restricted-vault"]\r\n egress:\r\n # 1. Mandate access to central shared platform services\r\n - name: allow-shared-services\r\n action: Accept\r\n to:\r\n - namespaces:\r\n matchLabels:\r\n kubernetes.io/metadata.name: shared-services\r\n\r\n # 2. Enforce strict block on accessing the restricted vault namespace\r\n - name: block-restricted-vault\r\n action: Deny\r\n to:\r\n - namespaces:\r\n matchLabels:\r\n kubernetes.io/metadata.name: restricted-vault\r\n\r\n # 3. Explicitly delegate all remaining traffic to developer namespace policies\r\n - name: delegate-remaining-egress\r\n action: Pass\r\n to:\r\n - namespaces: {}\r\n - networks:\r\n - 0.0.0.0/0\r\n - ::/0'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa4597f5290>)])]>

オープンソース基盤の拡張

Google は、この機能を独自の拡張機能として構築するのではなく、Kubernetes コミュニティと協力して ClusterNetworkPolicy API（policy.networking.k8s.io）を設計し、名前空間スコープの NetworkPolicy API（networking.k8s.io）と明確に区別しました。さらに、Cilium コミュニティと緊密に連携して、API の実装を構築しました。

GKE はオープンソース標準に基づいて構築されているため、セキュリティ構成をさまざまな環境に移植することが可能です。ClusterNetworkPolicy API は、ティアの選択をネイティブにサポートしているため、明確で決定論的なポリシー評価が可能です。このアプローチにより、管理者は堅牢なセキュリティガードレールを適用しながら、開発チームが必要とする運用上の柔軟性を維持できます。

GKE の ClusterNetworkPolicy は、ワークロードのネットワークセキュリティを強化し、運用を名前空間スコープのルールから、クラスタ全体にわたる統合されたガバナンスに移行します。現在は、バージョン 1.36 以降でプレビューとして利用可能です。詳細と利用開始方法については、以下をご覧ください。

- グループプロダクトマネージャー、Srini Jasti

- ソフトウェアエンジニア、Blaz Zupan

少ないリソースでより多くの成果を上げる: GKE でエージェントあたりの費用を 75% 削減する方法

Fri, 07 Aug 2026 02:00:00 +0000

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

昨今のエージェントの時代において、最新のクラウドアプリケーションは、単なる受動的なツールの集合体から、幅広いタスクにわたって推論、計画、実践する自律的なデジタルワーカーのフリートへと進化しています。

このような環境を設計するプラットフォームエンジニアリングチームにとって、最も簡単なアプローチは、仮想マシン（VM）上で動作する OpenClaw や Hermes などのオープンソースフレームワークにエージェントをデプロイすることです。しかし、それらのワークロードが本番環境に移行し、追加のユーザーやユースケースをサポートするためにスケールするにつれ、チームはすぐに重大な課題に直面します。AI エージェントはバースト的に動作する傾向があり、しばらくの間はリクエストを積極的に処理したりコードを実行したりしますが、その後はユーザー入力や外部トリガーを待つ間、長期間の非アクティブ状態になります。静的なコンピューティング割り当てに依存している場合、アイドル状態のエージェントであっても貴重な CPU とメモリを消費し続けます。

問題となるのは、信頼性、スケーラビリティ、効率性を損なうことなく、固定されたコンピューティングフットプリントに、いかに多くのエージェントを安全に詰め込むかということです。

その答えは、初期段階からオーケストレーションをアーキテクチャ全体の一部として組み込むことです。オーケストレーションにより、ユニットエコノミクスとスケーラビリティ、使いやすさ、信頼性を初日から大幅に向上させることができます。Google Kubernetes Engine（GKE）は、高度なオーケストレーション機能を提供します。コンピューティング能力を最大限に活用できるよう、Google は、固定の Google Compute Engine VM インスタンス（n2-standard-48）で実行される単一の GKE ノードに、パフォーマンス低下や繰り返しの障害を発生させずに搭載できる AI エージェントの最大数をテストしました。OpenClaw プロファイルを使用して、段階的な最適化を適用し、エージェントワークロードを大規模に実行するうえでオーケストレーションが果たす重要な役割を実証しました。詳細については、以下をお読みください。

ベースライン: microVM で OpenClaw を実行する

信頼できないマルチエージェントワークロードをセキュアに実行するには、強力な分離が必要です。一般的なアプローチとして、Kubernetes デプロイメント上の専用マイクロ VM（Kata コンテナなど）内で各エージェントを実行する方法があります。これにより、ハードウェアレベルでの強力な分離が実現します。

この方法では必要なセキュリティ境界は確保できますが、すぐにスケーリングの限界に直面します。各マイクロ VM には、メモリと CPU リソースを消費する独自のゲストオペレーティングシステムが必要であるため、実際のエージェントで使用できる実際のリソースが制限されます。このベースラインシナリオでは、標準の GKE ノードで OpenClaw エージェントが 61 個に達した時点でスケーリングの限界に達し、信頼性が低下してワークロードのヘルスチェックが定期的に失敗するようになりました。

最適化 1: GKE Agent Sandbox で密度を向上する

この問題に対処するため、同じエージェントワークロードをマイクロ VM から GKE Agent Sandbox に移行しました。GKE Agent Sandbox は、エージェントの実行におけるセキュリティとパフォーマンスの要件に特化して設計された Kubernetes プリミティブです。

GKE Agent Sandbox は、重いゲストオペレーティングシステムに依存するのではなく、オープンソースの安全なコンテナサンドボックスである gVisor を活用します。gVisor は、ユーザー空間カーネル（Sentry）を使用してシステムコールをインターセプトし、フィルタリングします。これにより、標準の Kubernetes コンテナの軽量なフットプリントを維持しながら、信頼できないコードの実行に対して本番環境レベルの安全な分離が提供されます。

オーバーヘッドが削減されたことでサンドボックス自体の効率が向上し、障害が発生する前に同じ VM 内に 88 個の OpenClaw エージェントをデプロイできるようになりました。これは、信頼性の高いセキュリティ境界を維持しつつ、同じ固定容量で実行できるエージェントの数が 44% 増加したことを意味します。

そのため、5 月に GKE Agent Sandbox の一般提供が開始してから、4 週間足らずで使用量が 7 倍以上に増加したのも不思議ではありません。

重要なポイント: Google のテストでは、OpenClaw タイプのエージェントを GKE Agent Sandbox に移行することで、vCPU あたりのエージェント数を 40% 以上増やし、エージェントあたりの費用を 30% 以上削減しながら、パフォーマンスプロファイルはほぼ同じ水準を維持できました。

最適化 2: オーケストレーションの価値

GKE Agent Sandbox はアクティブなワークロードを最適化しますが、アイドル状態の AI エージェントの問題を解決するには、ワークロードオーケストレーションをエージェントアーキテクチャの中心に据える必要があります。

アイドル状態のエージェントをバックグラウンドで実行し続けるのではなく、GKE Pod スナップショットを使用して永続ストレージにチェックポイント（固定）することで、物理 CPU とメモリリソースをクラスタに解放できます。新しいタスクトリガーが到着すると、軽量の Kubernetes コントローラまたはイベントゲートウェイがリクエストをインターセプトし、スナップショットからエージェントを再開するよう GKE にシグナルを送信します。この処理はミリ秒単位で行われます。

このパターンにより、ワークロードの動作に基づいて物理的なコンピューティングリソースを確実にオーバーサブスクライブできるため、同じノードにより多くのエージェントを配置できます。ただし、オーバーサブスクリプションは万能なアプローチではなく、いくつかのトレードオフが伴います。AI エージェントごとにレイテンシ要件と実行モデルが異なるためです。すべてのエージェントを同じように扱うと、レイテンシによってユーザーエクスペリエンスが低下するか、VM のオーバープロビジョニングによってプロジェクトが破綻することになります。

GKE を使用すると、さまざまなタイプのエージェントやユースケースに合わせてカスタマイズされたデプロイをサポートするエージェントプラットフォームを運用できます。各デプロイは、独自のパフォーマンスと費用の要件に合わせてファインチューニングされます。

GKE は、レイテンシの感度とリソース密度のバランスを取りながら、エージェントワークロードのさまざまな動作をサポートします。

以下に、パフォーマンス要件が大きく異なるエージェントワークロードの例を紹介します。

リアルタイムのコーディングアシスタント（レイテンシの影響を受けやすい）: 開発者向けの直接エージェントには、1 秒未満の起動時間（1 秒未満）が求められ、キューイングは一切許容されません。GKE は、GKE Pod スナップショットと Agent Sandbox ウォームプールを組み合わせることで、ほぼ瞬時に実行できる、ウォームアップ済みの分離されたサンドボックスを維持します。
自律型チームメイト （バランス型）: インタラクティブなバックグラウンドエージェントは、平均的な起動時間（数秒）を許容できます。GKE の一時停止と再開の機能により、これらのエージェントはオンデマンドで復元されるため、アイドル状態の間にコンピューティングリソースを消費することはありません。
ヘッドレスバックグラウンドエージェント（レイテンシ許容型）: 毎日スケジュール設定される調査や分析の cron ジョブは、キューの遅延を許容できます。クラスタ容量が利用可能になるまで 1 時間待ってこれらのジョブを実行しても、ビジネスの成果が損なわれることはありません。このようなエージェントのコストを抑えるには、最大のリソースオーバーサブスクリプションを使用します。

つまり、GKE では、クラスタ全体で単一の戦略を強制するのではなく、ノードプールとワークロード構成全体で異なる動作を同時にサポートできます。

「Thundering Herd」問題、つまり、エージェントが一斉に起動し、同時にコンピューティングを要求する状況を想定してください。GKE では、Agent Sandbox ウォームプールや一時停止と再開などの機能を使用して、特定の要件（パフォーマンス重視かコスト重視か）に基づいて、コスト削減の可能性とパフォーマンス保証とのバランスをチューニングできるようになっています。

パフォーマンス重視: 大規模で突発的なトラフィックの急増時にも、1 秒未満のパフォーマンスを保証する必要があるユースケースの場合は、Agent Sandbox のウォームプールを使用してバッファをプロビジョニングできます。この構成では、同じノードで 133 個の OpenClaw エージェントを実行できました。
コスト重視: レイテンシを許容できるワークロードや、段階的に実行できるワークロードでは、オーバースクリプション率を高くすることでノード密度を大幅に高めることができます。この構成では、起動時間を 5 秒未満に抑えながら、同じノードで 274 個のエージェント（ベースラインの 3 倍以上）を実行できました。

重要なポイント: GKE Agent Sandbox と GKE の一時停止および再開機能を組み合わせることで、アイドル状態のエージェントを固定し、固定のコンピューティング容量をオーバーサブスクライブできます。アクティビティが断続的に発生するエージェントの場合、エージェント密度が最大 3.5 倍になり、エージェントあたりのコストが最大 75% 削減されます。

予算を増やさずにエージェントをスケールさせる

エージェントをスケールしても、インフラストラクチャの予算を比例してスケールする必要はありません。例が示すように、適切なプラットフォーム機能を採用し、最初からオーケストレーションを考慮することで、コンピューティング容量から得られる価値を劇的に変えることができます。GKE を使用すると、積極的なコスト削減を優先する場合でも、パフォーマンスを最適化する場合でも、インフラストラクチャをビジネス目標に容易に合わせることができます。

そして、これはまだ始まりにすぎません。Google Cloud は、エージェントの時代の要求に対応できるよう、常に新しいイノベーションを推進しています。コンピューティング容量をさらに有効活用する準備はできていますか？GKE Agent Sandbox に関するドキュメントで、GKE がチームのイノベーションをより迅速かつ低コストで実現するのにどのように役立つかをご覧ください。

- プロダクトマネージャー、Drake Williams

- エンジニアリングマネージャー、Steven Linde

アイドル状態のアクセラレータを最小限に抑える: 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 0x7fa45ab53d50>)])]>

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

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

GKE における AI サプライチェーンの保護: 自動 AI BOM 対応 k8s-aibom のご紹介

Wed, 29 Jul 2026 01:00:00 +0000

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

セキュリティチームは、シャドー AI にどのように対応すべきでしょうか？デベロッパーが正式に登録せずにデプロイしたワークロードは、多くの場合、従来のセキュリティスキャナを回避できます。特権 DaemonSet、カーネルレベルのアクセス、Pod 仕様の手動編集を求めることで、開発を遅らせて安定性を損なうことに組織が消極的であるためです。

この行き詰まりを打開するため、Google はこのたび k8s-aibom をオープンソース化いたしました。この特権なしの軽量 Kubernetes コントローラは、クラスタ API とコンテナ環境を継続的にモニタリングして、実行中の AI ランタイム（vLLM や Triton など）を自動的に検出し、標準的な CycloneDX Machine Learning Bill of Materials（ML-BOM）を生成します。

k8s-aibom は、ワークロードが正式に登録されているかどうかに関係なく、ランタイム実行から直接、監査に適した可視性を自動的に確保し、デベロッパーに統合の負担をかけることなく AI プロジェクトをパイロットから本番環境に安全に移行できるようチームを支援します。

負担のないアーキテクチャ

k8s-aibom は、総合的な可視性に関する CISO の要件と、クラスタの安定性に関する SRE の要件の両方を尊重するようにゼロから設計されています。k8s-aibom-system Namespace に、特権なしの単一の Deployment としてデプロイされます。デベロッパー側の負担はゼロです。サイドカー、eBPF カーネルモジュール、特権 DaemonSet は不要で、既存のデベロッパー Pod 仕様を変更する必要もありません。

k8s-aibom は AI ワークロードを監視し、BOM を生成します。

検出パイプラインは、次の 4 つの明確な段階を経て実行されます。

クラスタワークロードのスクレイピング: コントローラは、クラスタ全体で KServe リソース、Deployment、StatefulSet、DaemonSet、Job を継続的にモニタリングします。
AI スタックの特定: 高度なパターンマッチングにより、コンテナイメージ、環境変数、コマンドライン引数を検査して、サービングランタイム（vLLM、Triton Inference Server、TGI、Ollama）、自律型エージェントフレームワーク（LangChain、AutoGen、CrewAI）、ベクトルデータベースと RAG ストア（Milvus、Qdrant、pgvector）、分散トレーニングジョブと評価ハーネスを検出します。
標準的なマニフェストの生成: コントローラは、検出されたアーティファクトを正式な OWASP CycloneDX 1.6 Machine Learning Bill of Materials（ML-BOM）ドキュメントにコンパイルします。
シンクへのエクスポート: コントローラは、生成された ML-BOM をクラスタ内の AIBOM カスタムリソース（CR）のカスタムリソースステータス（status.bomDocument）に直接アタッチし、Google Cloud Storage バケットや外部 Webhook エンドポイントなどのオプションの外部シンクにルーティングします。

アプリケーションチームが、Pod 仕様の変更、サイドカーコンテナの挿入、継続的インテグレーションと継続的デリバリー（CI / CD）のパイプラインの変更を行う必要はありません。さらに、k8s-aibom は Kubernetes クラスタの状態を純粋な関数入力として扱うため、同一のクラスタ入力からは、バイト単位で同一の ML-BOM ドキュメントが生成されます。この決定論的プロパティを持つ k8s-aibom は、GitOps ワークフローに最適です。これにより、サイト信頼性エンジニア（SRE）は、AI の依存関係がドリフトしたときに正確な差分を実行し、精密な変更検出アラートをトリガーできます。

既存の AIBOM ツールでカバーできない領域

多くの AI BOM ソリューションはビルド時スキャナを備えており、保存されているアーティファクトから BOM を生成します。これらのツールを使用すると、デプロイする予定だったコードを追跡できます。

商用 AI セキュリティプラットフォームは、クラウドネイティブなポスチャー管理によって可視化できる範囲を拡大しますが、通常はベンダー固有のデータモデルを中心に形成された外部スキャンによってこれを実現します。こうしたツールで、コンプライアンスレビュー担当者、セキュリティ運用（SecOps）チーム、プラットフォームエンジニアが、現在何が実行されているか、どこに接続しているか、アサーションを検証するにはどうすればよいかを把握できることはほとんどありません。

Google は k8s-aibom を、このギャップを埋めるための専用ツールとして構築しました。k8s-aibom は、アーティファクトのスキャンではなく、ライブクラスタの観測から BOM を生成し、ベンダー独自の形式ではなく、より広範な OWASP および Open Source Security Foundation（OpenSSF）サプライチェーンエコシステムと統合する標準準拠の CycloneDX 1.6 ML-BOM を出力します。また、準拠する Kubernetes クラスタで特権なしのコントローラとして実行されるため、既存のビルド時およびポスチャー管理ツールの代わりとなるのではなく、これらを補完するものとなります。

信頼度モデル: 意図と推論の分離

コンプライアンス監査担当者や SecOps エンジニアにとって、未加工のテレメトリーがノイズになることがよくあります。標準的なモニタリングツールは、コンテナが実行中であることを示しますが、AI モデルがプラットフォームエンジニアによって明示的に構成されたのか、実行時に自律スクリプトによって動的に抽出されたのかを証明することはできません。k8s-aibom は、その決定論的な信頼度モデルによってこの曖昧さを解消し、検出されたアセットを明確な階層に分類します。

宣言: ワークロード構成で、顧客またはデベロッパーによって明示的に定義された（例: --model meta-llama/Llama-2-7b など、明示的に渡されたコンテナ引数）。「宣言」の信頼度検出は、人間の明確な意図を表します。
推論: コンテナイメージ、環境変数、実行プロファイルの詳細な検査を通じて、コントローラのパターンマッチングエンジンによって自律的に導出された（例: ^vllm/.* コンテナ署名の特定）。
未解決: アクティブな AI の存在が検出されたが、正確なモデルパラメータ、重み、バージョンを決定論的に確立できないワークロードに適用される。「未解決」の信頼度検出の場合、対象を絞ったセキュリティレビュー向けにワークロードに即座にフラグが付けられます。

この構造化された分類により、コンプライアンスレビュー担当者は、明示的なエンジニアリングの意図と機械の推論を即座に分離し、監査中に揺るぎない信頼の連鎖を確立できます。

不変性と最小権限: 監査に適したセキュリティモデルの構築

侵害されたノードや権限が昇格された管理者によってログや指標が変更、削除、改ざんされる可能性があるため、監査担当者は標準的なオブザーバビリティテレメトリーに対して依然として強い懐疑心を抱いています。k8s-aibom は、厳格な最小権限の分離とデータの不変性をベースにした、監査に適した証拠トレイルを確立します。

このコントローラは、最小限の Identity and Access Management（IAM）Workload Identity にバインドされた専用の Kubernetes サービスアカウントの下で動作します。BOM レコードを外部ストレージシンクに書き込む権限を持つ唯一の ID として機能し、roles/storage.objectCreator 権限のみを必要とします。

Google Cloud Storage の外部シンクの実装では、最も厳格な監査基準と証拠基準を満たすために、オブジェクト作成時に DoesNotExist 事前条件が適用されます。ML-BOM が Cloud Storage バケットに書き込まれると、オブジェクトは暗号化され、変更できなくなります。

侵害されたクラスタアクターや不正なワークロードによって、サイレントに上書き、変更、または遡及的に改ざんされることはありません。SecOps チームは、規制当局に提出された過去の監査ログが、クラスタ実行の変更不可能な記録であることを絶対的に保証できます。

ガバナンス体制の整備の促進: グローバルな規制フレームワークへのマッピング

k8s-aibom は、標準化された CycloneDX 1.6 ML-BOM の生成を自動化することで、低レベルの Kubernetes ランタイム状態と高レベルのガバナンスフレームワークのギャップを直接的に埋めます。また、主要な国際基準に不可欠な基礎的実証データを提供することで、停滞していた GKE AI のデプロイの道を切り拓きます。

EU AI 規則: 組織が第 12 条（継続的なトレーサビリティのための自動ロギングと記録保持）と第 50 条（AI システムの透明性義務）に準拠できるように設計されています。このツールは、サービングランタイムとエージェントスタックを自動的にカタログ化することで、コンプライアンス監査中に必要となる可能性のある技術的証拠の収集を簡素化します。
NIST AI リスク管理フレームワーク（AI RMF）: ガバナンス、マッピング、測定、管理の各機能を実現する、継続的かつ実証的なアセットの可視性がもたらされ、コンプライアンスワークフローを、純粋な手動チェックから、より自動化されたアセットインベントリトラッキングへと移行できます。
ISO/IEC 42001: AI マネジメントシステムのアセットの検出と追跡に関するコンプライアンスの取り組みをサポートし、インベントリの検証における手動のスプレッドシート入力や定期的なスナップショット監査への依存度を低下させます。

ご利用にあたって

k8s-aibom は、CISO、ガバナンス、リスク、コンプライアンスの各チーム、SecOps チーム、プラットフォームエンジニア、デベロッパーに影響を与えるシャドー AI の多面的な問題の軽減に役立つ数少ない技術ソリューションの一つです。

このコントローラの詳細とカスタムリソース定義について、またオープンソースの k8s-aibom プロジェクトにご協力いただける場合は、k8s-aibom GitHub リポジトリをご覧ください。

- グループプロダクトマネージャー、Glen Messenger

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

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

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

GKE スタンバイバッファの概要: 予算を抑えながらノードの起動時間を短縮

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

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

アプリケーションオーナーやプラットフォームエンジニアは、長い間、難しい選択を迫られてきました。それは、オーバープロビジョニングに過剰な費用をかけて迅速な起動を保証するか、費用を最小限に抑える代わりに起動に時間がかかる「コールドスタート」に耐えるか、という選択です。

このたび、この問題を解決するソリューションとして、Google Kubernetes Engine スタンバイバッファの提供を開始いたします。これは、今年初めにリリースした GKE アクティブバッファを基盤としています。GKE アクティブバッファは、Kubernetes CapacityBuffers API のネイティブバージョンであり、すぐに利用できる容量を簡単にプロビジョニングすることでトラフィックの急増に対処できるほか、新しい Pod の起動にかかるレイテンシをほぼゼロにすることができます。しかし、アクティブバッファには、パフォーマンスと費用のトレードオフが生じるという課題が依然として存在していました。新しい GKE スタンバイバッファは、GKE クラスタ用に低コストの一時停止された容量バッファを維持することで、この課題を解決します。GKE スタンバイバッファを利用すると、費用オーバーヘッドを 1 桁台前半という無視できるレベルに抑えつつ、ワークロードのスケジューリングをほぼ即座に実現できます。これは、汎用ワークロード、エージェント型ワークロード、その中間的なものなど、あらゆる種類のワークロードに有用です。

トラフィック負荷が同一の場合、スタンバイバッファのないクラスタではレイテンシが急激に上昇し、P50、P95、P99 の各指標が 4～6分で推移しました。一方、スタンバイバッファのあるクラスタでは、P50 レイテンシはわずか数秒に抑えられ、P95 と P99 の指標は一時的に 1 分まで上昇したものの、すぐに数秒へと正常化しました。どちらの構成も割り当て可能なコアコストはほぼ同じであり、バッファリング方式の方がはるかに効率的でした。

問題: 高いコストとレイテンシ

従来、標準的な Kubernetes による自動スケーリングは効果的ではありましたが、処理速度が遅いという課題がありました。トラフィックの急増やバッチジョブが発生すると、クラスタのオートスケーラーが新しいノードをプロビジョニングする必要があるため、Pod は保留状態になります。この遅延を防ぐには、HorizontalPodAutoscaler（HPA）のしきい値を下げる、あるいは、Balloon Pod で管理するといった、費用のかかる煩雑な回避策に頼るしかありませんでした。

Balloon Pod の管理は運用が複雑であり、正しく機能させるには、優先度クラスやリソースリクエストを手動で構成し、継続的にメンテナンスする必要がある。
HPA のしきい値を下げると、ノードプールのサイズに比例して空き（無駄な）スペースが増加する。

GKE のアクティブバッファとスタンバイバッファの両方を利用すると、容量を宣言的に定義できるようになるため、こうした煩雑で運用上の負担が大きい回避策は不要になります。

さらに、GKE スタンバイバッファでは、ノードの状態がディスクに保存されるためインフラストラクチャ費用を削減できます。これにより、コンピューティングとメモリの費用を削減して、永続ディスクと IP アドレスの費用のみを維持できます。また、アクティブバッファと組み合わせることで、オーバープロビジョニングと同等のパフォーマンスを実現しながら、非常に手頃な価格で、ほぼ瞬時の Pod スケジューリングが可能になります。

GKE キャパシティバッファの概要 - 低レイテンシの Pod スケジューリングを実現するネイティブ Kubernetes の方法

アクティブバッファとスタンバイバッファの連携

すべての GKE キャパシティバッファは、YouTube などのプラットフォームにおける動画ストリーミングと同様の原理で動作します。GKE は、差し迫った需要に先立って利用可能な容量をプロアクティブにプロビジョニングおよび管理することで（動画コンテンツの事前ダウンロードのように）、必要なときにリソースを確実に利用できるようにします。

今回のリリースにより、この 2 種類のキャパシティバッファを連携できるようになりました。

アクティブバッファ: クラスタオートスケーラーが、既存のクラスタノード上で事前定義された数の Pod に対応する十分な容量を確保し、必要に応じて追加のノードをプロビジョニングします。レイテンシの影響を受けやすいワークロードの容量を確保する場合は、このすぐに使用できるバッファを選択します。
スタンバイバッファ: ノードは事前にプロビジョニングされ、Kubernetes DaemonSet などの必要なコンポーネントで完全に初期化されます。イメージをプリロードする時間が確保されますが、その後は一時停止されます。その間、基盤となるコンピューティング容量は解放されて費用が節約されます。需要が急増すると、これらのノードは新しいノードを作成するよりも 2～3 倍速く再開され、コールドスタートと常時利用可能な容量とのギャップを埋めます。

アクティブバッファは、スタンバイバッファが再開されるまでの初期の需要急増をカバーします。システムは、スタンバイバッファからアクティブバッファへの補充を優先します。スタンバイバッファは負荷の増加に対応し、ノードのコールドスタートによる遅延を防ぎます。スタンバイバッファが補充されると、まず構成可能な時間だけアクティブ状態になり、その後一時停止されます。これにより、トラフィック負荷が持続している間、アクティブな容量が増加します。

初期ベンチマーク

Google のテストでは、スタンバイバッファを使用することで、完全なオーバープロビジョニングと比較して最大 90% の費用削減を実現しつつ、Agent Sandbox のスケジュール設定のレイテンシを 1 秒未満に抑えることができました。

ビジネスニーズに合わせて最適化

多くの企業は、業務を合理化しながらリソース消費を最適化するという絶え間ないプレッシャーにさらされています。Google は、散発的に急増するワークロードの管理には、よりスマートなツールが必要であることを認識し、スタンバイバッファを早急に提供できるよう取り組んできました。エージェント、バッチジョブ、CI/CD パイプライン、ゲームサーバー、急激に変動するワークロードなどの実行に、GKE のキャパシティバッファを使用することで、パフォーマンスと費用のバランスを動的に調整できるほか、トラフィックの急増に対する「保険」を、高額な保険料を支払うことなく定義できます。GKE スタンバイバッファを使用すると、以下のことが可能になります。

コールドスタートの回避: スタンバイバッファによって一時停止されたノードは、新しいノードをプロビジョニングする場合に比べて 2～3 倍速く再開されるため、トラフィックの急増時や持続的な負荷の下での Pod スケジューリングレイテンシが短縮されます。
費用削減: スタンバイバッファでは基盤となる VM が一時停止状態になるため、アクティブ容量に比べて大幅に低コストです。コンピューティング時間全体ではなく、ストレージと IP アドレスの費用を支払うことになります。
宣言型コントロールの実現: 複雑な Balloon Pod による回避策を、シンプルでネイティブな宣言型 CapacityBuffers API に置き換えます。必要な容量を明示的に指定するだけで、残りの処理は GKE に任せることができます。

「GKE スタンバイキャパシティバッファを使用することで、非常に手頃な価格で、準備完了までの時間を数分から 30 秒に短縮できました。」
- Unico、チーフアーキテクト、Pedro Spagiari 氏

- Unico、チーフアーキテクト、Pedro Spagiari 氏

使ってみる

パフォーマンス向上と費用削減に向けて踏み出しましょう。

まず、クラスタに CapacityBuffer リソースを定義し、目標とするバッファサイズを指定します。
持続的な負荷に対する Pod スケジューリングレイテンシを短縮し、予測不可能な即時の容量ニーズに対応できるよう、スタンバイバッファとアクティブバッファのバランスを取ります。

例として、カスタム ComputeClass を使用しながら Deployment のバッファを構成する方法を見てみましょう。

基本設定

まず、基本設定として Namespace を作成します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: Namespace\r\nmetadata:\r\n name: my-namespace'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa4689c0450>)])]>

次に、カスタム ComputeClass を作成します（省略可）。

code_block: <ListValue: [StructValue([('code', 'apiVersion: cloud.google.com/v1\r\nkind: ComputeClass\r\nmetadata:\r\n name: my-ccc\r\n namespace: my-namespace\r\nspec:\r\n # バッファもこれらの優先順位に従って作成される\r\n priorities:\r\n - machineFamily: n4\r\n - machineFamily: n4d\r\n - machineFamily: c4\r\n - machineFamily: c4d\r\n nodePoolAutoCreation:\r\n enabled: true'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45a04c550>)])]>

バッファユニットのサイズを定義する

PodTemplate をバッファユニットのサイズの基準として使用できます。また、特定の Deployment や scale subResource を定義する任意のオブジェクトに対してバッファを作成することもできます。

code_block: <ListValue: [StructValue([('code', '# バッファの 1 ユニットに対するリソース要件を定義する\r\napiVersion: v1\r\nkind: PodTemplate\r\nmetadata:\r\n name: my-buffer-unit-template\r\n namespace: my-namespace\r\ntemplate:\r\n spec:\r\n terminationGracePeriodSeconds: 0\r\n tolerations:\r\n # 省略可: バッファ Pod が任意のノードに配置されるようにする\r\n - key: "node-role.kubernetes.io/master"\r\n operator: "Exists"\r\n effect: "NoSchedule"\r\n containers:\r\n - name: buffer-container\r\n image: registry.k8s.io/pause:3.9\r\n resources:\r\n requests:\r\n cpu: "1"\r\n memory: "1Gi"\r\n limits:\r\n cpu: "1"\r\n memory: "1Gi"\r\n # 省略可: カスタム ComputeClass でバッファを使用する / \r\n # GKE がプロビジョニングするノードのプロパティを制御する\r\n nodeSelector:\r\n cloud.google.com/compute-class: my-ccc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45a04f1d0>)])]>

バッファを作成する

最後に、PodTemplate を参照して CapacityBuffer オブジェクトを作成します。ここでは、50 個の CPU と 50 GB の RAM のスタンバイバッファを作成します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling.x-k8s.io/v1beta1\r\nkind: CapacityBuffer\r\nmetadata:\r\n name: my-standby-buffer-resource-limits\r\n namespace: my-namespace\r\n annotations:\r\n # 省略可: バッファノードが一時停止されるまでの時間\r\n # デフォルトは 5 分\r\n buffer.gke.io/standby-capacity-init-time: "5m"\r\n # 省略可: スタンバイバッファが再作成されるまでの時間\r\n # デフォルトは 1 日、「never」にすると更新されない\r\n buffer.gke.io/standby-capacity-refresh-frequency: "1d"\r\nspec:\r\n podTemplateRef:\r\n name: my-buffer-unit-template\r\n # 望ましい状態はスタンバイバッファが 20 ユニット\r\n # スタンバイバッファが使用されると新しいバッファが作成される\r\n limits:\r\n cpu: "50"\r\n memory: "50Gi"\r\n provisioningStrategy: "buffer.gke.io/standby-capacity"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45a883650>)])]>

（省略可）アクティブバッファの例: 5 個の CPU と 5 GB の RAM

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling.x-k8s.io/v1beta1\r\nkind: CapacityBuffer\r\nmetadata:\r\n name: my-active-buffer-resource-limits\r\n namespace: my-namespace\r\nspec:\r\n podTemplateRef:\r\n name: my-buffer-unit-template\r\n # 望ましい状態はアクティブバッファが 2 ユニット\r\n # アクティブバッファが使用されると新しいバッファが作成される\r\n limits:\r\n cpu: "5"\r\n memory: "5Gi"\r\n provisioningStrategy: "buffer.x-k8s.io/active-capacity"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45a882090>)])]>

最後に、上記のオブジェクトをクラスタに適用します。これで設定は完了です。

バッファによって予約されたスペースでスケジュールできる既存および将来の Deployment は、Pod スケジューリングレイテンシの短縮によるメリットを享受できます。

バッファをテストする

以下の方法でバッファのステータスを確認できます。Kubernetes では、一時停止されたノードは Suspended という条件で識別できます。

code_block: <ListValue: [StructValue([('code', 'kubectl get nodes -o custom-columns=\'NAME:.metadata.name,SUSPENDED:.status.conditions[?(@.type=="Suspended")].status\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45a8820d0>)])]>

以下のような出力が表示されるので、スタンバイバッファが一時停止されるまで待ちます。

code_block: <ListValue: [StructValue([('code', 'NAME SUSPENDED\r\ngke-my-cluster-nap-n4-standard-8-k960-...-ffbx False # ノードが再開されました。\r\ngke-my-cluster-nap-n4-standard-4-k960-...-h2x4 <none> # ノードは一時停止されませんでした。\r\ngke-my-cluster-nap-n4d-standard-8-1cip-...-74jf True # ノードは一時停止されています。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45a8835d0>)])]>

バッファをテストするには、Deployment を作成してスケールします。

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: my-deployment\r\n namespace: my-namespace\r\nspec:\r\n replicas: 1\r\n selector:\r\n matchLabels:\r\n app: my-deployment\r\n template:\r\n metadata:\r\n labels:\r\n app: my-deployment\r\n spec:\r\n containers:\r\n - name: busybox\r\n image: busybox\r\n command: ["sleep", "inf"]\r\n resources:\r\n requests:\r\n cpu: "500m"\r\n memory: "500Mi"\r\n # 省略可: カスタム ComputeClass でバッファを使用する /\r\n # GKE がプロビジョニングするノードのプロパティを制御する\r\n nodeSelector:\r\n cloud.google.com/compute-class: my-ccc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45a882290>)])]>

この Deployment を 2 つのレプリカにスケーリングすると、それらはアクティブバッファに割り当てられ、即座にスケジューリングされます。その後、アクティブバッファは、スタンバイバッファからすぐに補充されます。同時に、スタンバイバッファは新しいノードのプロビジョニングを開始します。

この Deployment をさらに 50 個のレプリカにスケールすると、ノードが再開されたときに、すべてのレプリカがスタンバイバッファにスケジュールされます。スタンバイバッファを補充するためにプロビジョニングされた新しいノードは、短時間だけアクティブバッファとして機能し、一時的にスタンバイ能力を増強します。したがって、この間に、この Deployment を 100 個のレプリカにさらにスケールすると、新しいレプリカが即座にスケジューリングされるメリットをより実感できるかもしれません。

GKE スタンバイバッファのベストプラクティス

GKE スタンバイバッファを使用する際は、以下の点を考慮してください。

想定される負荷の増加を十分にカバーできるサイズのスタンバイバッファを定義し、コールドスタート時でもバックグラウンドでバッファが補充されるようにします。十分なサイズのスタンバイバッファがあれば、Pod のスケジューリングにおける最大レイテンシを、ノードの再開にかかる時間（約 30 秒）まで短縮できます。
バッファが使用され始め、補充されると、新しいバッファノードは一時停止する前に、まずアクティブ状態になります。これにより、負荷が長期間続く間、アクティブな容量を増やすことができます。
アプリケーションで可能な限り低い Pod スケジューリングレイテンシが必要な場合は、スタンバイバッファのノードが再開できるまでに発生すると想定される、初期のトラフィック急増をカバーするのに十分なアクティブバッファサイズを定義します。システムは、スタンバイバッファを消費することでアクティブバッファの補充を優先します。十分なサイズのアクティブバッファとスタンバイバッファを確保することで、オーバープロビジョニングに比べて大幅な低コストを実現できるほか、Pod スケジューリングレイテンシも短縮できます。
ワークロードに適した結果が得られるまで、さまざまなバッファサイズを試すことを推奨します。

参考までに、パフォーマンス目標を達成するために必要なバッファサイズを見積もることができるシミュレータをご用意しました。https://github.com/gke-labs/buffers-simulator から入手してご利用ください。

まとめ

GKE のアクティブバッファとスタンバイバッファは、ウォーム状態とスタンバイ状態のキャパシティバッファを維持することで、低レイテンシかつ費用対効果の高いワークロードスケーリングを実現するネイティブなソリューションです。低速なノードのコールドスタートを回避することで、パフォーマンスが重要なアプリケーションにおいて突発的なトラフィックの急増に対処できるようになります。また、Balloon Pod のような複雑な手動の回避策を、シンプルで宣言的な API に置き換えることができるほか、固定、割合ベース、またはリソース上限ベースのバッファリング戦略によって、ピーク時のオーバープロビジョニングを行うことなく、費用対効果の高い方法で厳格なサービスレベル目標を維持できます。

スタンバイバッファは、バージョン 1.36.0-gke.2253000 以降を実行している GKE クラスタで利用できます。バッファの使用を開始するには、こちらのドキュメントをご覧ください。

- Google Kubernetes Engine、プロダクトマネージャー、Eyal Yablonka

- Google Kubernetes Engine、スタッフソフトウェアエンジニア、Konrad Kurdej

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使ってみる

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

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

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

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

GKE のノード起動が高速化され、コールドスタートレイテンシが解消

Wed, 20 May 2026 01:00:00 +0000

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

このたび、クラウドインフラストラクチャにおける最も厄介な問題の一つであるコールドスタートレイテンシを解決する Google Kubernetes Engine（GKE）の重要なアップデートをリリースしました。GKE の以前のバージョンと比べると、対象となるノードの起動時間が最大 4 倍高速になるため、お客様は迅速かつ効率的にプロビジョニングができます。設定の切り替えや、構成ファイルへのパッチ適用は必要ありません。インフラストラクチャのプロビジョニング方法がアーキテクチャ上でアップグレードされるため、何も操作を行わなくてもノードが高速で起動します。これは、クラウド運用のアジリティと費用効率の向上に直結し、AI 推論用のモデルの迅速なデプロイから、アクセラレータノードと汎用ノードの動的なスケーリングまで、幅広いユースケースに大きく影響します。

今回取り組んだ問題:「コールドスタート」の負担

ご存じのように、需要が変動するワークロード、特に AI 推論やバッチ処理を実行している場合、新しいノードのスピンアップを待つのは苦痛です。需要が急増すると、オートスケーラーがノードをリクエストします。その後、しばらく待ちます。この待機時間と、それによってユーザーに生じるレイテンシを回避するために、多くのチームは「万が一に備えて」高価なノードを稼働させ続ける、オーバープロビジョニングに頼っています。この場合、起動の遅延に対する保険として、アイドル状態のコンピューティングに対して料金を支払うことになります。この保険は、希少なアクセラレータの場合に特に高額になります。

解決策: ノードプロビジョニングの完全な再構築

この問題に対処するため、VM と GKE ノードのプロビジョニングロジックを再構築しました。大まかに言うと、インテリジェントなコンピューティングバッファ、特別に設計された高速起動の仮想マシン、VM を再起動せずに即座にサイズ変更できる新しいコントロールプレーンアーキテクチャを組み合わせて使用しています。技術的な詳細は複雑ですが、お客様にとってのメリットはシンプルです。GKE クラスタのスケーリングが本質的に高速かつ効率的になり、貴重なリソースを必要な場所にシフトできるようになりました。

影響

オーバープロビジョニングの削減: ノードがより高速でオンラインになるため、オートスケーラーのリアルタイムでの対応を信頼でき、アイドル状態のノードのバッファを維持する必要がなくなります。
AI 推論の改善: GPU で実行されるモデルの場合、ノードのプロビジョニングが高速化されることで、リクエストの急増からモデル提供のトラフィックまでの時間が短縮されます。
「運用」のオーバーヘッドなし: これは自動的に機能し、利用するために Terraform ファイルや YAML ファイルを変更する必要はありません。

対象

現在、プロビジョニングの高速化は、以下のハードウェアを使用して GKE Autopilot で実行されるワークロード（Standard クラスタ内で実行される Autopilot ワークロードを含む）でご利用いただけます。

以下を含むその他のマシンにも近日中に展開される予定です。今後の情報にご注目ください。

試す方法

対象のインスタンスタイプで GKE Autopilot をすでにご利用の場合は、この改善にお気づきかもしれません。

GKE Standard クラスタを実行している場合は、クラスタ全体を移行することなく、これらのワークロードに Autopilot をご利用いただけます。Pod で Autopilot ComputeClass を指定するだけで、Pod は Standard ノードと共存しながら、この起動速度を継承します。

高速起動ノードに関する技術ドキュメントの全文はこちらをご覧ください。

次のステップ

以下のリソースで、これらの新たな改善点を活用してワークロードの応答性を向上させる方法をご確認ください。

- Google Cloud、プロダクトマネージャー、Eyal Yablonka

- Google Cloud、プリンシパルソフトウェアエンジニア、Karen Aleksanyan

Next ‘26 で発表された GKE の新機能

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

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

今週開催の Google Cloud Next ‘26 では、Google Kubernetes Engine（GKE）の進化についてご紹介しています。GKE は、特に要求が厳しく複雑なワークロードや、次世代の AI アプリケーションとエージェントアプリケーションに対して、優れたパフォーマンス、効率性、セキュリティ、スケーラビリティを提供します。

重要である理由: Kubernetes は AI 時代のオペレーティングシステムとして急速に普及しており、GKE は現在、最大規模のフロンティアモデルの構築企業を含む、プラットフォーム上の上位 50 社すべてのお客様の AI ワークロードを支えています。エンタープライズ AI は急速に普及しています。わずか数か月で、マルチエージェント AI ワークフローの数が 327% も急増しました。同時に、組織の 66% が生成 AI アプリやエージェントの強化に Kubernetes を利用しています。

自律型エージェントが大規模に運用されるこの新しい時代には、インフラストラクチャの管理方法に根本的な変革が求められています。これは、ステートレスアプリケーションからステートフルアプリケーションへの移行よりも要求の厳しい変革です。

新機能:

GKE Agent Sandbox: 安全でスケーラビリティが高く、低レイテンシのエージェントインフラストラクチャ
GKE ハイパークラスタ: Google Cloud リージョン全体で数百万のアクセラレータを管理する、単一の適合 GKE コントロールプレーン
推論パフォーマンスの向上: GKE Inference Gateway と KV キャッシュ管理の基盤となる機能強化
強化学習（RL）の強化機能: アクセラレータ使用率をスロットリングするボトルネックを解消するネイティブ機能
カスタム指標に基づくスケーリング: CPU とメモリ以外のトリガーに基づくインテントベースの自動スケーリングをサポート

GKE に関するこれらのお知らせについて詳しく説明します。

GKE Agent Sandbox: エージェント時代を加速

AI が単純な会話型チャットボットから、エコシステム全体へのプロアクティブで自律的なエージェントへと進化するにつれて、基盤となるインフラストラクチャは、従業員と連携して複雑なタスクを計画、評価、実行するために数百または数千のエージェントを処理できるように適応していく必要があります。大規模なインフラストラクチャでは、パフォーマンス、応答性、厳格なセキュリティが不可欠です。

このたび Google は、業界有数のスケーラビリティと低レイテンシを誇る AI エージェントインフラストラクチャである GKE Agent Sandbox を発表しました。Gemini の保護と同じ gVisor カーネル分離テクノロジーで構築された Agent Sandbox を使用すると、パフォーマンスを犠牲にすることなく、信頼できないコード、ツール、エージェント全体を安全に実行できます。GKE は、完全に分離されたエージェントに対して、1 秒あたり 300 個のサンドボックス、1 秒未満のレイテンシ、Axion で実行した場合の他のハイパースケールクラウドと比較して最大 30% 優れた費用対効果を実現し、業界をリードするスピードと効率性を提供します。

Lovable を使用すると、誰でもアプリやウェブサイトを構築できます。毎日ビルダーによって 20 万件以上の新しいプロジェクトが作成されています。Lovable では、起動の速さとスケーリングの速さ、そして安全な分離が可能なことから、これらの AI 生成アプリケーションを GKE Agent Sandbox で実行しています。

「GKE の最先端のサンドボックス機能により、1 秒あたり数百個の安全なサンドボックスに確実にスケーリングできるため、予測不能な膨大な需要が発生した場合でも、ビルダーをシームレスに支援できます」- Lovable、共同創業者 Fabian Hedin 氏

GKE ハイパークラスタがスケーラビリティの上限を再定義

基盤となる AI モデルが指数関数的に成長し、アクセラレータの需要が高い状態が続いているため、組織は Kubernetes コンピューティングインフラストラクチャを数百の切断されたクラスタに分割する手段をとっており、これは、運用上の大きな負担につながる可能性があります。この問題を解決するために、Google は GKE ハイパークラスタの限定公開 GA を発表します。これにより、複数の Google Cloud リージョンにまたがる 256,000 個のノードに分散された 100 万個のチップを、Kubernetes に準拠した単一の GKE コントロールプレーンで管理できるようになります。GKE ハイパークラスタを使用すると、広範囲に分散されたインフラストラクチャが、複数の地理的場所にまたがる単一の統合された容量の予備となります。

セキュリティを損なうことなくグローバルにスケーリングするために、GKE ハイパークラスタは Google の Titanium Intelligence Enclave を利用しています。これは、プライベート AI コンピューティングを提供するソフトウェア強化型のセキュリティエンジンです。この「管理者権限なし」モデルは、ハードウェア証明済みの Pod レベルの分離を提供するため、独自のモデルの重みとプロンプトは、プラットフォーム管理者とインフラストラクチャレイヤから暗号的にシールされたままになります。

最先端の推論を強化

最先端の推論を実現するには、数か月にわたる複雑なパフォーマンスチューニングが必要です。この手間を軽減するために、GKE では TPU と GPU 全体で「SOTA までの時間」をわずか数分に短縮しました。これを実現するために、以下の新機能を提供しています。

GKE Inference Gateway の ML を活用した予測レイテンシブースト。ヒューリスティックな推測をリアルタイムの容量を考慮したルーティングに置き換えることで、最初のトークンまでの時間（TTFT）のレイテンシを最大 70% 削減できます。手動によるチューニングは必要ありません。
RAM、ローカル SSD、GCS/Lustre 間での自動 KV キャッシュストレージティアリングにより、長いコンテキストのメモリボトルネックが解消されます。KV キャッシュを RAM にオフロードすると、システムプロンプトの長さが 10,000 の場合、TTFT が 40% 以上短縮され、スループットが 50% 向上しました。KV キャッシュをローカル SSD にオフロードすると、システムプロンプトの長さが 50,000 の場合、スループットがほぼ 70% 向上しました。これらのベンチマークについて詳しくは、llm-d Offloading Prefix Cache to Shared Storage guide をご覧ください。

レイヤ化されたコンポーズ可能なスイートの一部として構築されたこれらの新しい GKE 機能は、現在公式の CNCF サンドボックスプロジェクトである llm-d を活用しています。最大限の柔軟性を実現するため、Google は NVIDIA と緊密に連携して Dynamo をシームレスに統合し、大規模な混合エキスパート（MoE）モデルをスケーリングできるようにしました。どのツールを選択しても、GKE は、あらゆる最先端の AI ワークロードを安全に実行するために必要な、高度に最適化された柔軟なインフラストラクチャを提供します。これには、新しく発表された Gemma 4 の高度なエージェント機能も含まれます。

RL コンピューティングのボトルネックの解消

強化学習（RL）は AI コンピューティング需要の重要な推進力であり、RL ジョブにはサンプリング、報酬、トレーニングの順次処理が含まれます。これらの RL ステップの間では GPU および TPU アクセラレータがアイドル状態になる可能性があります。RL を効率化するために、新しい GKE 機能をプレビュー版として追加しています。

RL スケジューラは「ストラグラー効果」とバッチ間のテールレイテンシを解決し、インテリジェントなルーティングによってスループットを最大化します。
RL Sandbox は、ツール呼び出しと報酬評価のためにカーネルレベルの分離を提供し、ミリ秒単位でプロビジョニングします。RL サンプリングと報酬のステップとの統合は簡単です。
RL のオブザーバビリティと信頼性のダッシュボードは、RL ループ全体のトラブルシューティングと最適化を即座に、すぐに使える状態で実行するために必要な詳細な可視性を提供します。

GKE レシピの RL、特に Verl と NeMo RL の実装をご確認ください。

カスタム指標に基づくインテントベースの自動スケーリング

従来、アプリケーションの健全性に基づいて AI ワークロードをスケーリングするには、「カスタム指標税」が課せられていました。基本的なコンピューティングやメモリ使用率以外の要素に基づいてシステムをスケーリングするには、組織は複雑なモニタリングシステムと IAM ロールを管理する必要があります。これにより、運用上のリスクが生じます。外部のオブザーバビリティスタックに障害が発生すると、自動スケーリングも機能しなくなります。

インテントベースの自動スケーリングでは、GKE の HorizontalPodAutoscaler（HPA）のネイティブなカスタム指標サポート により、このオーバーヘッドが解消されます。このエージェントレスアーキテクチャは、Pod から直接指標を取得することで外部依存関係を回避し、信頼性を高めながらコストを削減します。重要なのは、反応時間が 25 秒からわずか 5 秒に短縮されたことです。これは、インフラストラクチャの弾力性がほぼ瞬時に発揮されることを意味し、パフォーマンスが 5 倍向上しています。

新しいワークロード、変わらないミッション

GKE は 10 年以上にわたり、スケーラブルなインフラストラクチャの標準を確立してきました。エージェント AI と自律型 AI の時代を迎えても、Google の使命は変わりません。それは、運用上の摩擦を排除し、お客様がイノベーションに集中できるようにすることです。Next '26 で発表する機能（GKE ハイパークラスタ、Agent Sandbox、超高速推論、インテントベースの自動スケーリングなど）は、意欲的な AI ワークロードを成功させるために必要な、安全で効率的かつ強力なエンジンを提供します。AI ワークロードに GKE を使用する方法について詳しくは、GKE Inference Quickstart をご覧ください。

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

- GKE グループプロダクトマネージャー Gari Singh

Envoy: エージェント型 AI ネットワーキングのための将来を見据えた基盤

Fri, 17 Apr 2026 01:30:00 +0000

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

昨今のエージェント型 AI 環境では、ネットワークに新たな責任が課せられています。

従来のアプリケーションスタックでは、ネットワークは主にサービス間でリクエストを移動するものでした。しかし、最近のホワイトペーパー Cloud Infrastructure in the Agent-Native Era で説明されているように、エージェントシステムでは、モデル呼び出し、ツール呼び出し、エージェント間のやり取り、エージェントができることを定義するポリシーの決定の間にネットワークが位置します。多様なフレームワーク上に構築されることが多いエージェントが急速に普及しているため、すべてのエージェントパスにわたってガバナンスとセキュリティを一貫して大規模に適用する必要があります。これを実現するには、適用レイヤがアプリケーションレベルから基盤となるインフラストラクチャに移行する必要があります。つまり、ネットワークはもはや盲目的なトランスポートレイヤとして機能することはできず、より多くのことを理解し、より適切に適用を行い、より迅速に適応する必要があります。この移行において役立つのが Envoy です。

Envoy は、高パフォーマンスの分散プロキシおよびユニバーサルデータプレーンとして、大規模なスケーリングに対応するように構築されています。Google Cloud を含む要求の厳しいエンタープライズ環境で信頼されており、単一サービスのデプロイから、上り（内向き）、下り（外向き）、サイドカーの各パターンを使用した複雑なサービスメッシュまで、あらゆるものをサポートします。Envoy は、優れた拡張性、堅牢なポリシー統合、運用上の成熟度により、プロトコルが急速に変化し、制御が不十分な場合のコストが高くなる時代に特に適しています。エージェント型 AI を構築するチームにとって、Envoy は単なるコンセプトではなく、実用的でプロダクションレディな基盤です。

エージェント型 AI がネットワーキングの問題を変える

エージェントワークロードは依然としてトランスポートとして HTTP を使用することが多いですが、従来の HTTP 仲介役が依存する前提の一部には従いません。Model Context Protocol（MCP）や Agent2agent（A2A）などのプロトコルは、HTTP 上で JSON-RPC または gRPC を使用し、標準の HTTP リクエスト / レスポンスセマンティクスに加えて、クライアントとサーバーがそれぞれの機能を交換する MCP 初期化などのプロトコルレベルのフェーズを追加します。仲介役が適応する必要がある、エージェントシステムの主な側面は次のとおりです。

企業ガバナンスの多様な要件。主な課題は、安全性、セキュリティ、データプライバシー、規制遵守に関する、企業にとって譲れない幅広い要件を満たすことです。これらのニーズは、標準的なネットワークポリシーの枠を超えることが多く、内部システムとの緊密な統合、カスタムロジック、新しい組織ルールや外部規制に迅速に適応する能力が必要になります。そのため、企業が独自のガバナンスモデルを組み込める、拡張性の高いフレームワークが求められます。
ポリシー属性は、ヘッダーではなくメッセージ本文内に存在する。パスやヘッダーなどのポリシー入力に簡単にアクセスできる従来のウェブトラフィックとは異なり、エージェントプロトコルでは、重要な属性（モデル名、ツール呼び出し、リソース ID など）が JSON-RPC または gRPC ペイロードの奥深くに埋もれていることがよくあります。このため、仲介役はメッセージの内容を解析して理解し、コンテキストに応じたポリシーを適用できる必要があります。
多様で進化するプロトコルの特性に対応する。エージェントのプロトコルは一様ではありません。Streamable HTTP を使用する MCP のような一部のプロトコルでは、（Mcp-Session-Id などを使用した）分散プロキシ全体でのセッション管理が必要となるステートフルなインタラクションが導入されることもあります。このような多様な動作をサポートする必要性と、将来のプロトコルのイノベーションにより、本質的に適応性と拡張性に優れたネットワーキング基盤の必要性が高まっています。

これらの要因により、企業は単なる接続性以上のものを必要としています。ネットワークは、前述した重要なガバナンスのニーズを満たす中心的な役割を果たす必要があります。これには、プロトコルとエージェントの動作の急速な進化に対応しながら、一元化されたセキュリティ、包括的な監査可能性、きめ細かいポリシーの適用、動的なガードレールなどの機能を提供することが含まれます。簡単に言えば、エージェント型 AI はネットワークを単なるトランジットパスから重要な制御ポイントに変えます。

Envoy がこの移行に対応できる理由

Envoy は、以下の 3 つの理由から、エージェント型 AI ネットワーキングに最適です。

実証済み。Envoy は、セキュリティが重要な大規模環境で企業がすでに利用しており、新世代のトラフィック管理とポリシー適用を支える信頼できるプラットフォームとなっています。
拡張可能。Envoy は、ネイティブフィルタ、Rust モジュール、WebAssembly（Wasm）モジュール、外部処理パターンを通じて拡張できます。これにより、プラットフォームチームは、エコシステムが変化するたびにネットワーキングレイヤを再構築することなく、新しいプロトコルを採用できるようになります。
今すぐ運用に役立つ。Envoy はすでに、コントロールプレーンのゲートウェイ、適用ポイント、オブザーバビリティレイヤ、統合サーフェスとして機能しています。そのため、標準が定着するのを待たずに今すぐ移行する必要がある組織にとって、実用的な選択肢となります。

Envoy は、以下の中核的な強みを基盤として、エージェントネットワーキングに特有のニーズを満たすアーキテクチャの進歩を遂げています。

1. Envoy はエージェントトラフィックを理解する

エージェントネットワーキングの最初の要件はシンプルです。ゲートウェイはエージェントが実際に何をしようとしているのかを理解する必要があるということです。

ただし、これはそれほど簡単ではありません。MCP、A2A、OpenAI スタイルの API などのプロトコルでは、重要なポリシーシグナルがリクエスト本文内に存在することがあります。従来の HTTP プロキシは、本文を不透明なバイトストリームとして扱うように最適化されています。この設計は効率的ですが、プロキシで適用できることが制限されます。JSON メッセージを使用するプロトコルの場合、プロキシはポリシーの適用に必要な属性値を見つけるために、リクエスト本文全体をバッファリングする必要がある場合があります。特に、それらの属性が JSON メッセージの末尾にある場合はその必要性が高まります。使用されたトークンに基づくレート制限など、生成 AI プロトコルに固有のビジネスロジックでも、サーバーのレスポンスの解析が必要になる場合があります。

これに対処するために、Envoy は、HTTP で伝送されるプロトコルメッセージをデフレーミングし、有用な属性をフィルタチェーンの残りの部分に公開します。生成 AI プロトコルの拡張性モデルは、次の 2 つの目標を指針としています。

RBAC（ロールベースアクセス制御）やトレーサーなど、生成 AI プロトコルにそのまま対応する既存の HTTP 拡張機能を簡単に再利用できる。
デベロッパーが HTTP や JSON エンベロープを処理する必要がなく、生成 AI のビジネスロジックに集中できるように、生成 AI 固有の拡張機能用のデフレーミングされたメッセージに簡単にアクセスできる。

これらの目標に基づき、生成 AI プロトコルの新しい拡張機能は、依然として HTTP 拡張機能として構築され、HTTP フィルタチェーンで構成されます。これにより、OAuth や mTLS 認証などの HTTP ネイティブのビジネスロジックと生成 AI プロトコルのロジックを 1 つのチェーンで混在させる柔軟性が得られます。デフレーミング拡張機能は、HTTP で伝送されるプロトコルメッセージを解析し、抽出された属性、さらには解析されたメッセージ全体を含むアンビエントコンテキストを、既知のフィルタ状態とメタデータ値を介してダウンストリームの拡張機能に提供します。

Envoy では、すべてのポリシーコンポーネントが JSON エンベロープやプロトコル固有のメッセージ形式を独自に解析することを強制するのではなく、これらの属性を構造化されたメタデータとして利用できるようにします。ゲートウェイがプロトコルメッセージをデフレーミングすると、ext_authz や RBAC などの既存の Envoy 拡張機能がプロトコルプロパティを読み取り、MCP のツール名、A2A のメッセージ属性、OpenAI のモデル名などのプロトコル固有の属性を使用してポリシーを評価できます。

アクセスログには、モニタリングと監査を強化するためのメッセージ属性を含めることができます。プロトコル属性は Common Expression Language（CEL）ランタイムでも使用できるため、RBAC や複合拡張機能で複雑なポリシー式を簡単に作成できます。

バッファリングとメモリ管理Envoy は、HTTP リクエストをプロキシする際にできるだけ少ないメモリを使用するように設計されています。しかし、エージェントプロトコルの解析には、特に拡張機能でメッセージ全体をメモリに格納する必要がある場合、変動する量のバッファ領域が必要になることがあります。特に、信頼できないトラフィックが存在する場合は、拡張機能でより大きなバッファを使用できる柔軟性と、メモリ枯渇からの適切な保護のバランスを取る必要があります。

これを実現するために、Envoy ではリクエストごとにバッファサイズを制限できるようになりました。リクエストデータを保持するバッファもオーバーロードマネージャーと統合されているため、アイドルタイムアウトの短縮や、長期間にわたって最も多くのメモリを消費するリクエストのリセットなど、メモリ不足時のあらゆる保護アクションが可能になります。これらの変更により、Envoy はリソース効率を損なうことなく、生成 AI プロトコルのゲートウェイおよびポリシー適用ポイントとして機能できるようになっています。

2. Envoy は重要な事項に関するポリシーを適用する

トラフィックを理解することは、ゲートウェイがそれに基づいて動作できる場合にのみ役立ちます。

エージェントシステムでは、ポリシーはエージェントがアクセスできるサービスだけでなく、エージェントが呼び出せるツール、使用できるモデル、提示する ID、消費できる量、追加の制御が必要な出力の種類も規定するものです。これらは、単純なレイヤ 4 またはパスベースの制御よりも価値の高い決定であり、エージェントが企業に代わって行動することを許可する場合に、企業が重視する種類の制御です。

この点において Envoy は、トランスポートレベルのセキュリティとアプリケーション対応のポリシー適用を組み合わせることができるため、優れています。チームは、mTLS と SPIFFE ID でワークロードを認証し、RBAC、外部認証、外部処理、アクセスロギング、CEL ベースのポリシー式を使用してプロトコル固有のルールを適用できます。

この機能は、プラットフォームチームがエージェントの開発と適用を切り離せるため、非常に重要です。デベロッパーは有用なエージェントの構築に集中でき、オペレーターはツール、モデル、プロトコルが変化し続けても、ネットワークレイヤで一貫したゼロトラスト体制を維持できます。このゼロトラストの分離の好例は、「エージェントの背後にユーザーがいる」重要なシナリオ、つまり AI エージェントが人間のユーザーに代わってタスクを実行する必要がある場合です。従来、ユーザーの認証情報をアプリケーションに直接渡すことは、重大なセキュリティリスクをもたらします。エージェントが侵害されたり、プロンプトインジェクションによって操作されたりした場合、攻撃者は認証情報を抜き取ったり、不正使用したりできるためです。ID 管理を Envoy にオフロードすることで、プロキシはインフラストラクチャレイヤでユーザー委任トークンをアウトバウンドリクエストに自動的に挿入できます。エージェントが機密性の高い認証情報を直接保持することはないため、侵害されたエージェントがトークンを不正使用したり漏洩させたりするリスクは完全に排除され、アクションはユーザーの実際の権限に厳密にバインドされたままになります。

ケーススタディ: エージェントを特定の GitHub MCP ツールに制限するGitHub の問題をトリアージするエージェントを考えてみましょう。

GitHub MCP サーバーは数十のツールを公開している可能性がありますが、エージェントに必要なのは、list_issues、get_issue、get_issue_comments など、ごく一部の読み取り専用のツールのみである場合があります。ほとんどの企業にとって、この違いは重要です。有用なエージェントが、無制限のエージェントに自動的に変わるべきではありません。

MCP サーバーの前に Envoy を配置することで、ゲートウェイは mTLS handshake 中に SPIFFE を使用してエージェントの ID を検証し、デフレーミングフィルタを介して MCP メッセージを解析し、リクエストされたメソッドとツール名を抽出して、その特定のエージェント ID に対して承認されたツール呼び出しのみを許可するポリシーを適用できます。RBAC は、MCP デフレーミングフィルタによって作成されたメタデータを使用して、MCP メッセージ内のメソッドとツール名をチェックします。

code_block: <ListValue: [StructValue([('code', 'envoy.filters.http.rbac:\r\n "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBACPerRoute\r\n rbac:\r\n rules:\r\n policies:\r\n github-issue-reader-policy:\r\n permissions:\r\n - and_rules:\r\n rules:\r\n - sourced_metadata:\r\n metadata_matcher:\r\n filter: envoy.http.filters.mcp\r\n path: [{ key: "method" }]\r\n value: { string_match: { exact: "tools/call" } }\r\n - sourced_metadata:\r\n metadata_matcher:\r\n filter: envoy.http.filters.mcp\r\n path: [{ key: "params" }, { key: "name" }]\r\n value:\r\n or_match:\r\n value_matchers:\r\n - string_match: { exact: "list_issues" }\r\n - string_match: { exact: "get_issue" }\r\n - string_match: { exact: "get_issue_comments" }\r\n principals:\r\n - authenticated:\r\n principal_name:\r\n exact: "spiffe://cluster.local/ns/github-agents/sa/issue-triage-agent"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45a3d3dd0>)])]>

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

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

RBAC ルールを使用して表現できない複雑なコンプライアンスポリシーは、ext_authz プロトコルを使用して外部認証サービスに実装できます。Envoy は、ext_authz RPC のコンテキストで、HTTP ヘッダーとともに MCP メッセージ属性を提供します。また、ピア証明書からエージェントの SPIFFE ID を転送することもできます。

code_block: <ListValue: [StructValue([('code', 'http_filters:\r\n - name: envoy.filters.http.ext_authz\r\n typed_config:\r\n "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz\r\n grpc_service:\r\n envoy_grpc:\r\n cluster_name: auth_service_cluster\r\n include_peer_certificate: true\r\n metadata_context_namespaces:\r\n - envoy.http.filters.mcp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45a0b18d0>)])]>

これにより、エージェントや MCP サーバーがポリシーレイヤを認識する必要なく、エージェント ID、MCP メソッド、ツール名、その他のプロトコル属性の完全な組み合わせに基づいて、外部サービスが認証の決定を行うことができます。

プロトコルネイティブのエラーレスポンス

Envoy がリクエストを拒否した場合、返されるエラーは呼び出し元のエージェントにとって意味のあるものである必要があります。MCP トラフィックの場合、Envoy は local_reply_config を使用して、HTTP エラーコードを適切な JSON-RPC エラーレスポンスにマッピングできます。たとえば、403 Forbidden は、isError: true および人間が読めるメッセージを含む JSON-RPC レスポンスにマッピングできます。これにより、エージェントは不透明な HTTP ステータスコードではなく、プロトコルに適した拒否を受け取ることができます。

3. Envoy はステートフルなエージェントのインタラクションを大規模にサポートする

エージェントトラフィックのすべてがステートレスであるわけではありません。MCP の Streamable HTTP など、一部のプロトコルはセッション指向の動作に依存する場合があります。特に、トラフィックが複数のゲートウェイインスタンスを通過してスケーラビリティと復元力を実現する場合、仲介役にとって新たな課題が生じます。MCP セッションは、そのセッションを確立したサーバーにエージェントを効果的にバインドします。すべての仲介役は、受信 MCP 接続を正しいサーバーに転送するために、このことを認識する必要があります。

1 つのバックエンドでセッションが確立された場合、その会話における後のリクエストは正しい宛先に到達する必要があります。単一プロキシのデプロイでは簡単そうに聞こえますが、水平方向にスケールされたシステムでは、複数の Envoy インスタンスが同じエージェントからの異なるリクエストを処理する場合があり、より複雑になります。

パススルーゲートウェイ

よりシンプルなパススルーモードでは、Envoy はダウンストリーム接続ごとに 1 つのアップストリーム接続を確立します。主な用途は、外部 MCP サーバーに対するクライアントの認可、RBAC、レート制限、認証など、一元化されたポリシーの適用です。仲介役の間で転送されるセッション状態には、最初の HTTP 接続でセッションを確立したサーバーのアドレスのみが含まれる必要があります。これにより、セッション関連のすべてのリクエストがそのサーバーに送信されます。

異なる Envoy インスタンス間でのセッション状態の転送は、MCP サーバーから提供された MCP セッション ID に、エンコードされたセッション状態を追加することで実現されます。Envoy は、リクエストを宛先 MCP サーバーに転送する前に、セッション ID からセッション状態の接尾辞を削除します。このセッションの永続性は、Envoy の envoy.http.stateful_session.envelope 拡張機能を構成することで有効になります。

集約ゲートウェイ

集約モードでは、Envoy は複数のバックエンド MCP サーバーの機能、ツール、リソースを集約することで、単一の MCP サーバーとして機能します。これにより、ポリシーが適用されるだけでなく、エージェントの構成が簡素化され、複数の MCP サーバーのポリシー適用が統合されます。

このモードでのセッション管理はより複雑になります。セッション状態に、ツールとリソースから、それらをアドバタイズしたサーバーアドレスとセッション ID へのマッピングも含まれる必要があるためです。Envoy がエージェントに提供するセッション ID は、ツールやリソースが認識される前に作成され、マッピングはその後、Envoy とバックエンド MCP サーバー間の MCP 初期化フェーズが完了した後に確立される必要があります。

現在 Envoy で実装されているアプローチの一つは、ツールやリソースの名前と、その配信元サーバーの識別子およびセッション ID を組み合わせるというものです。通常、正確なツール名やリソース名はエージェントにとって意味がなく、この追加の来歴情報を伝えることができます。変更されていないツール名やリソース名が必要な場合は、マッピングのない Envoy インスタンスを使用し、特定のツールを呼び出す前に tools/list コマンドを発行してマッピングを再作成するというアプローチもあります。このアプローチは、レイテンシと引き換えに、MCP セッションの外部グローバルストアをデプロイする複雑さが伴います。現在、ユーザーからのフィードバックに基づいて計画中です。

これは、Envoy が単純なトラフィック転送にとどまらないことを意味するため重要です。これにより、Envoy は、実際のエージェントワークフロー（複数のリクエスト、ツール、バックエンドにわたるものを含む）の信頼できる仲介役として機能できます。

4. Envoy はエージェントの検出をサポートする

Envoy は、既知の AgentCard エンドポイントを介した A2A プロトコルとエージェントの検出のサポートを追加しています。エージェント機能が記載された JSON ドキュメントである AgentCard は、スキル、認証要件、サービスエンドポイントをアドバタイズすることで、検出とマルチエージェントの調整を可能にします。AgentCard は、直接レスポンス構成を介して静的にプロビジョニングすることも、xDS API または ext_proc API を介して一元化されたエージェントレジストリサーバーから取得することもできます。A2A の実装とエージェントの検出の詳細は、今後のブログ投稿で公開する予定です。

5. Envoy はエージェントネットワーキングの課題に対する包括的なソリューション

Envoy は、要求の厳しいデプロイで MCP プロトコルのポリシー適用が可能になった基盤と同じ基盤を基に、OpenAI と、エージェントプロトコルの RESTful HTTP API へのコード変換のサポートを追加しています。このコード変換機能により、生成 AI エージェントと既存の RESTful アプリケーションの統合が簡素化されます。また、OpenAPI ベースのアプリケーションがすぐにサポートされ、動的モジュールまたは Wasm 拡張機能を通じてカスタムオプションを利用できます。Envoy は、コード変換に加えて、割り当て管理などの高度なポリシー適用、生成 AI システムの OpenTelemetry セマンティック規則に準拠した包括的なテレメトリー、安全なエージェント運用を実現する統合ガードレールなど、本番環境への対応に不可欠な領域で強化されています。

安全なエージェントのためのガードレール

投資対象となる次の重要な分野は、すべてのエージェントトラフィックのガードレールの一元管理と適用です。現在、ポリシー適用ポイントを外部のガードレールと統合するには、特注の実装が必要ですが、この問題領域は標準化の機が熟しています。

コントロールプレーンがこれを運用可能にする

ゲートウェイは、ソリューション全体の一部にすぎません。このポリシー管理とロールアウトを大規模に実現するにあたり、xDS プロトコル（ユニバーサルデータプレーン API とも呼ばれる）を使用してデータプレーンを動的に構成するために別のコントロールプレーンが必要になります。

そこで重要になるのがコントロールプレーンです。Cloud Service Mesh は、Envoy AI Gateway や kube-agentic-networking などのオープンソースプロジェクトとともに、Envoy をデータプレーンとして使用しながら、オペレーターがエージェントワークロードのポリシーをより高いレベルで定義、管理できるようにします。

この組み合わせは強力です。Envoy はトラフィックパスに適用機能と拡張性を提供し、コントロールプレーンはチームがその機能を一貫してデプロイするために必要な運用モデルを提供します。

このソリューションが重要な理由

エージェントシステムや生成 AI プロトコル（MCP、A2A、OpenAI など）への移行に伴い、ネットワーク仲介役の進化が求められています。Envoy が主に対応する複雑な課題は次のとおりです。

プロトコルの詳細な検査。プロトコルデフレーミング拡張機能は、HTTP リクエストの本文からポリシーに関連する属性（ツール名、モデル名、リソースパス）を抽出し、従来のプロキシでは不透明なバイトストリームしか確認できなかった状況で正確なポリシー適用を可能にします。
きめ細かいポリシーの適用。これらの内部属性を公開することで、RBAC や ext_authz などの既存の Envoy 拡張機能は、プロトコル固有の基準に基づいてポリシーを評価できます。これにより、ネットワークオペレーターは、統一されたゼロトラストのセキュリティポスチャーを適用し、エージェントが特定のツールやリソースのアクセスポリシーに準拠するようにできます。
ステートフルなトランスポート管理。Envoy は、MCP で使用される Streamable HTTP トランスポートのセッション状態の管理をサポートしており、仲介役のフリート全体でも、パススルーゲートウェイモードと集約ゲートウェイモードの両方で堅牢なデプロイを可能にします。

エージェント型 AI プロトコルはまだ初期段階にあり、プロトコルの状況は今後も進化し続けます。まさにそのために、ネットワーキングレイヤには適応性が必要なのです。新しいエージェントフレームワーク、トランスポートパターン、ツールプロトコルが普及するたびに、企業がセキュリティとトラフィックのインフラストラクチャを再構築する必要はありません。制御を犠牲にすることなく変化を吸収できる基盤が必要です。

Envoy は、本番環境での実証済みの成熟度、高度な拡張性、エージェントワークロードのプロトコル認識の向上という、一度に持ち合わせることが難しい 3 つの特性を兼ね備えています。Envoy をエージェントゲートウェイとして活用することで、組織はセキュリティとポリシーの適用をエージェント開発コードから切り離すことができます。

これにより、Envoy は AI トラフィックを処理するプロキシ以上の存在になり、エージェント型 AI ネットワーキングの未来を見据えた基盤となります。

^{このブログ記事の共同執筆者である、Google のソフトウェアエンジニア Boteng Yao、Google のソフトウェアエンジニア Tianyu Xia、Google のシニアプロダクトマネージャー Sisira Narayana に感謝します。}

- Google、スタッフソフトウェアエンジニア、Yan Avlasov

- Tetrate、プロダクトおよびプロダクトマーケティングマネージャー、Erica Hughberg 氏

新しい GKE Cloud Storage FUSE プロファイルにより、AI ストレージの構成における当て推量が不要に

Thu, 16 Apr 2026 02:00:00 +0000

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

AI / ML の世界では、データはトレーニングと推論のワークロードに欠かせない要素です。Google Kubernetes Engine（GKE）ユーザーは、Cloud Storage FUSE を使用して Google Cloud Storage に保存されているデータに高いパフォーマンスでスケーラブルにアクセスできます。しかし、Cloud Storage FUSE のパフォーマンスを最大限に引き出すのは複雑な場合がある、というお客様の声が寄せられていました。

このたび、GKE Cloud Storage FUSE プロファイルが導入されました。この新機能は、運用オーバーヘッドを最小限に抑えながら、パフォーマンス調整を自動化し、AI / ML ワークロード（トレーニング、チェックポイント、推論）のデータアクセスを高速化するように設計されています。特定のワークロードのニーズに合わせて調整されたこれらのプロファイルを使用すると、Cloud Storage FUSE の高いパフォーマンスをすぐに活用できます。

導入前（手動調整）

code_block: <ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: PersistentVolume\r\nmetadata:\r\n name: serving-bucket-pv\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n capacity:\r\n storage: 64Gi\r\n persistentVolumeReclaimPolicy: Retain\r\n storageClassName: ""\r\n claimRef:\r\n name: serving-bucket-pvc\r\n mountOptions:\r\n - implicit-dirs\r\n - metadata-cache:ttl-secs:-1\r\n - metadata-cache:stat-cache-max-size-mb:-1\r\n - metadata-cache:type-cache-max-size-mb:-1\r\n - file-cache:max-size-mb:-1\r\n - file-cache:cache-file-for-range-read:true\r\n - file-system:kernel-list-cache-ttl-secs:-1\r\n - file-cache:enable-parallel-downloads:true\r\n - read_ahead_kb=1024\r\n csi:\r\n driver: gcsfuse.csi.storage.gke.io\r\n volumeHandle: BUCKET_NAME\r\n volumeAttributes:\r\n skipCSIBucketAccessCheck: "true"\r\n gcsfuseMetadataPrefetchOnMount: "true"\r\n---\r\napiVersion: v1\r\nkind: PersistentVolumeClaim\r\nmetadata:\r\n name: serving-bucket-pvc\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n resources:\r\n requests:\r\n storage: 64Gi\r\n volumeName: serving-bucket-pv\r\n storageClassName: ""\r\n–--\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: gcs-fuse-csi-example-pod\r\n annotations:\r\n gke-gcsfuse/volumes: "true"\r\nspec:\r\n containers:\r\n # Your workload container spec\r\n ...\r\n volumeMounts:\r\n - name: serving-bucket-vol\r\n mountPath: /serving-data\r\n readOnly: true\r\n serviceAccountName: KSA_NAME \r\n volumes:\r\n - name: gke-gcsfuse-cache # gcsfuse file cache backed by RAM Disk\r\n emptyDir:\r\n medium: Memory \r\n - name: serving-bucket-vol\r\n persistentVolumeClaim:\r\n claimName: serving-bucket-pvc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45abeb090>)])]>

導入後（Cloud Storage FUSE のマウントオプション、CSI 構成、ファイルキャッシュメディアが自動的に構成されます）

code_block: <ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: PersistentVolume\r\nmetadata:\r\n name: serving-bucket-pv\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n capacity:\r\n storage: 64Gi\r\n persistentVolumeReclaimPolicy: Retain\r\n storageClassName: gcsfusecsi-serving\r\n claimRef:\r\n name: serving-bucket-pvc\r\n csi:\r\n driver: gcsfuse.csi.storage.gke.io\r\n volumeHandle: BUCKET_NAME\r\n---\r\napiVersion: v1\r\nkind: PersistentVolumeClaim\r\nmetadata:\r\n name: serving-bucket-pvc\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n resources:\r\n requests:\r\n storage: 64Gi\r\n volumeName: serving-bucket-pv\r\n storageClassName: gcsfusecsi-serving\r\n–--\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: gcs-fuse-csi-example-pod\r\n annotations:\r\n gke-gcsfuse/volumes: "true"\r\nspec:\r\n containers:\r\n # Your workload container spec\r\n ...\r\n volumeMounts:\r\n - name: serving-bucket-vol\r\n mountPath: /serving-data\r\n readOnly: true\r\n serviceAccountName: KSA_NAME \r\n volumes: \r\n - name: serving-bucket-vol\r\n persistentVolumeClaim:\r\n claimName: serving-bucket-pvc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45abea5d0>)])]>

Cloud Storage FUSE の最適化に伴う課題

高パフォーマンスのワークロード向けに Cloud Storage FUSE を最適化することは、多次元的な問題です。従来、ユーザーは数十ページに及ぶ手動構成ガイドを読み解く必要がありました。AI / ML の進化に伴い、Cloud Storage FUSE の機能も強化され、ワークロードを高速化するための新しいマウントオプションが利用できるようになりました。設定が「適切」かどうかは静的なものではなく、さまざまな動的要因に大きく左右されるものでした。

バケットの特性: データセットの合計サイズとオブジェクトの数は、メタデータとファイルキャッシュの要件に大きく影響します。
インフラストラクチャの多様性: GPU、TPU、汎用コンピューティングのいずれを使用するかによって、最適な構成は異なります。
ノードリソース: Cloud Storage への費用のかかるラウンドトリップを最小限に抑えるためにローカルにキャッシュ保存できるデータの量は、利用可能な RAM とローカル SSD の容量によって決まります。
ワークロードパターン: トレーニングワークロード（大規模データセットの高スループット読み取り）では、チェックポイントワークロード（バースト性が高い、高スループット書き込み）やサービングワークロード（レイテンシの影響を受けやすいモデルの読み込み）とは異なる調整が必要です。

実際、多くのお客様は、Cloud Storage FUSE の設定が最適化されていないか、誤って構成されているために、利用可能なパフォーマンスを十分に活用できていないか、信頼性の問題（Pod のメモリ不足による強制終了など）に直面しています。

GKE 向け Cloud Storage FUSE プロファイルの概要

GKE Cloud Storage FUSE プロファイルは、特定の AI / ML パターンに合わせてカスタマイズされた、事前定義された動的管理の StorageClass を使用して、この複雑さを簡素化します。数十ものマウントオプションを手動で調整する必要はなく、ワークロードのタイプに一致するプロファイルを選択するだけでかまいません。

これらのプロファイルは、階層化されたモデルで機能します。Cloud Storage FUSE の基本的なベストプラクティスをベースに、GKE 固有のインテリジェンスレイヤを追加します。プロファイルを使用して Pod をデプロイすると、GKE は自動的に次の処理を行います。

バケット（または特定のディレクトリ）をスキャンして、そのサイズとオブジェクト数を把握します。
ターゲットノードを分析して、利用可能な RAM、ローカル SSD、アクセラレータタイプを確認します。
最適なキャッシュサイズを計算し、最適なバッキングメディア（RAM またはローカル SSD）を自動的に選択します。

リリース時には、次の 3 つの主要なプロファイルが用意されています。

gcsfusecsi-training: GPU と TPU にデータを供給し続ける高スループットの読み取りに最適化されています。
gcsfusecsi-serving: モデルの読み込みと推論に最適化され、自動化された Rapid Cache 統合が可能です。
gcsfusecsi-checkpointing: 数ギガバイトの大きなチェックポイントファイルを高速かつ確実に書き込むように最適化されています。

GKE Cloud Storage FUSE プロファイルを使用すると、次のようなメリットがあります。

調整の簡素化: 複雑でエラーが発生しやすい手動構成が、3 つのシンプルな専用 StorageClass に置き換えられます。
リソースを認識した動的な最適化: CSI ドライバは、リアルタイムの環境シグナルに基づいてキャッシュサイズを自動的に調整するため、ノードの安定性を損なうことなくパフォーマンスを最大化できます。
読み取りパフォーマンスの向上: サービングプロファイルは Rapid Cache を自動的にトリガーし、データをコンピューティングの近くに配置して、コールドスタートモデルの読み込みを高速化します。
きめ細かなパフォーマンス分析情報: 構造化されたログを通じて自動調整の決定を可視化し、特定のキャッシュサイズとメディアが Pod に対して選択された理由を正確に把握できます。

GKE Cloud Storage FUSE プロファイルの推論プロファイルを使用することで、TPU（480 GB）上の Qwen3-235B-A22B ワークロードのモデル読み込み時間を 39 時間からわずか 14 分に短縮できました。これにより、お客様は Cloud Storage FUSE GCSFuse をすぐに使用して最大限のメリットを得ることができます。

GKE で Cloud Storage FUSE プロファイルを使用する方法

まず、Cloud Storage FUSE CSI ドライバが有効になっている GKE バージョン 1.35.1-gke.1616000 以降がクラスタで実行されていることを確認します。

1. StorageClass を特定する

GKE には、プロファイルベースの StorageClass がプリインストールされています。次のコマンドで確認できます。

code_block: <ListValue: [StructValue([('code', 'kubectl get sc -l gke-gcsfuse/profile=true'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45abebe50>)])]>

2. PV と PVC を作成する

PersistentVolume を作成する際、Cloud Storage バケットを参照するようにします。GKE は、最適な構成を判断するためにバケットスキャンを自動的に開始します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: PersistentVolume\r\nmetadata:\r\n name: gcs-pv\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n capacity:\r\n storage: 5Gi\r\n persistentVolumeReclaimPolicy: Retain \r\n storageClassName: gcsfusecsi-training\r\n mountOptions:\r\n - only-dir=my-ml-dataset-subdirectory # Optional\r\n csi:\r\n driver: gcsfuse.csi.storage.gke.io\r\n volumeHandle: my-ml-dataset-bucket\r\n---\r\napiVersion: v1\r\nkind: PersistentVolumeClaim\r\nmetadata:\r\n name: gcs-pvc\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n resources:\r\n requests:\r\n storage: 5Gi\r\n storageClassName: gcsfusecsi-training\r\n volumeName: gcs-pv'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45abe8ed0>)])]>

3. デプロイを作成する

PersistentVolumeClaim（PVC）がバインドされたら、他のボリュームと同様に Deployment で使用するだけです。GKE は、ハードウェアとデータセットに必要となる正確な設定でボリュームをマウントします。

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: my-deployment\r\nspec:\r\n replicas: 3\r\n selector:\r\n matchLabels:\r\n app: my-app\r\n template:\r\n metadata:\r\n labels:\r\n app: my-app\r\n annotations:\r\n gke-gcsfuse/volumes: "true"\r\n spec:\r\n serviceAccountName: my-ksa\r\n containers:\r\n - name: my-container\r\n image: busybox\r\n volumeMounts:\r\n - name: my-gcs-volume\r\n mountPath: "/data"\r\n volumes:\r\n - name: my-gcs-volume\r\n persistentVolumeClaim:\r\n claimName: gcs-pvc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa45abe9110>)])]>

デプロイ後、CSI ドライバは、GPU や TPU、メモリ、ローカル SSD、バケットまたはサブディレクトリのサイズ、サイドカーのリソース上限など、ノードのリソースに基づいて最適なキャッシュサイズとマウントオプションを自動的に計算します。

使ってみる

GKE Cloud Storage FUSE プロファイルを使用すると、高パフォーマンスなクラウドストレージを構成する際に当て推量が不要になります。手動の「ノブ調整」からワークロードを認識する自動プロファイルに移行することで、ストレージスループットのデバッグに費やす時間を減らし、次世代の AI の構築に多くの時間を費やすことができます。

ぜひご利用ください。GKE Cloud Storage FUSE プロファイルは、バージョン 1.35.1-gke.1616000 で一般提供されています。AI / ML ワークロード向けに GKE で Cloud Storage FUSE プロファイルを構成する方法については、公式ドキュメントをご覧ください。

- エンジニアリングマネージャー、Nishtha Jain

- ソフトウェアエンジニア、Uriel Guzmán-Mendoza

GKE Inference Gateway を使用して、同じインフラストラクチャでリアルタイム推論と非同期推論を実行する

Tue, 14 Apr 2026 01:00:00 +0000

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

AI ワークロードが実験的なプロトタイプから本番環境グレードのサービスに移行するのに伴い、それらをサポートするインフラストラクチャは、利用率のギャップが拡大するという課題に直面しています。昨今の企業は通常、同時実行性が高く、低レイテンシのリアルタイムリクエストに対応するシステムを構築するか、高スループットの「非同期」処理用に最適化するかという二者択一を迫られています。

Kubernetes 環境では、従来、これらの要件には、サイロ化された別々の GPU および TPU アクセラレータクラスタによって対応してきました。リアルタイムトラフィックは、バーストを処理するためにオーバープロビジョニングされるため、オフピーク時には大幅なアイドル容量が発生する可能性があります。一方、非同期タスクは多くの場合、セカンダリクラスタに追いやられるため、ソフトウェアスタックが複雑化し、リソース管理が断片化します。

AI サービングワークロードの場合、Google Kubernetes Engine（GKE）は、推論パターンの全範囲に対応する統合プラットフォームである GKE Inference Gateway を使用して、この「費用とパフォーマンス」のトレードオフに対処します。Google は OSS ファーストのアプローチを活用することで、アクセラレータの容量を単一の流動的なリソースプールとして扱うスタックを開発しました。これにより、決定論的なレイテンシと高スループットの両方を必要とするワークロードに対応できます。

この投稿では、最新の AI サービスを推進する 2 つの主要な推論パターンと、それぞれのパターンにおける問題および現在利用可能なソリューションについて説明します。このブログ記事を最後までお読みいただくと、GKE が GKE Inference Gateway を介してこれらのパターンにどのように対応するかについておわかりいただけます。

2 つの推論パターン: リアルタイムと非同期

このブログ記事では、リアルタイムと非同期という 2 種類の AI 推論ワークロードを取り上げます。リアルタイム推論の場合、これらは優先度の高い同期リクエストです。たとえば、お客様が LLM からの即時レスポンスを待っている、chatbot とのやり取りなどです。一方、小売業におけるインデックス登録や商品分類のドキュメント化などの非同期トラフィックでは、通常、レイテンシが許容されます。つまり、トラフィックはキューに入れられ、遅延して処理されることがよくあります。

1. リアルタイム推論: レイテンシの影響を受けやすい 0 秒のリクエスト

優先度の高い同期トラフィックの場合、レイテンシが最も重要な指標となります。しかし、従来のロードバランシングでは、高レイテンシを示す KV キャッシュ使用率などのアクセラレータ固有の指標が無視されることが多いため、パフォーマンスを最適化できません。

ソリューション: GKE Inference Gateway

この問題のソリューションは、Inference Gateway です。Inference Gateway は、リアルタイムの指標（KV キャッシュのステータスなど）に基づいてモデルサーバーのパフォーマンスを予測し、レイテンシを考慮したスケジューリングを実行して、最初のトークンまでの時間を最小限に抑えます。これにより、キューイングの遅延も減り、負荷が高い場合でも一貫したパフォーマンスを確保できます。

2. 非同期（ニアリアルタイム）推論: 0 分のレイテンシ

レイテンシが許容されるタスクは、ミリ秒単位の要件ではなく、分単位のサービスレベル目標（SLO）で動作します。従来のセットアップでは、リアルタイムトラフィックとのリソース競合を防ぐために、これらのリクエストを別々の専用インフラストラクチャで実行することがよくありました。この静的なパーティショニングは、利用の断片化とハードウェア費用の膨張につながる可能性があります。さらに、カスタムビルドの非同期ポーラーは、通常、同じアクセラレータにワークロードを多重化するために必要な高度なスケジューリングロジックを備えていないため、エンジニアは 2 つの異なる複雑なソフトウェアスタックを管理する必要があります。

ソリューション: 非同期プロセッサエージェント + Inference Gateway

Inference Gateway を Cloud Pub/Sub と統合する「プラグアンドプレイ」アーキテクチャ。バッチ処理エージェントは、構成されたトピックからリクエストを pull し、それらを「削除可能な」トラフィックとして Inference Gateway にルーティングします。システムはバッチタスクを「フィラー」として扱い、リアルタイムの急増の合間にアイドル状態のアクセラレータ（GPU / TPU）の容量を使用します。これにより、リソースの断片化が最小限に抑えられ、ハードウェア費用を削減できます。

主な機能:

リアルタイムトラフィックのサポート: リアルタイム推論トラフィックは Inference Gateway によって処理されます。
永続的なメッセージング: Pub/Sub を介して信頼性の高いリクエスト処理が行われます。
インテリジェントな再試行: キューの深さのリアルタイムモニタリングに基づいて、キューアーキテクチャに組み込まれた構成可能な再試行ロジックを活用します。
厳密な優先順位: ゲートウェイレベルでは、リアルタイムトラフィックがバッチトラフィックよりも常に優先されます。
緊密な統合: ユーザーは Pub/Sub トピックを「プラグイン」するだけで、エージェントが共有アクセラレータプールへのルーティングロジックを処理します。

図 1 : リアルタイム推論トラフィックと非同期推論トラフィックを解決するための統合アーキテクチャの概要。

上の図に示されているリクエストフローは次のとおりです。

ユーザーがリアルタイムリクエストを送信します。Inference Gateway はまずそのリクエストのスケジュール作成をします。
ユーザーは、構成された Pub/Sub トピックを介して非同期推論リクエストをパブリッシュできます。
非同期プロセッサが、利用可能な容量に基づいてキューから読み取りを行います。
非同期プロセッサは、同じアクセラレータ（GPU / TPU）リソースを利用して、Inference Gateway を介してリクエストをルーティングします。リアルタイムリクエストが優先されます。非同期リクエストは、コンピューティングサイクルで未使用のアクセラレータに割り当てられます（上の図を参照）。
非同期プロセッサは、レスポンスを出力トピックに書き込みます。
ユーザーは、レスポンストピックから非同期リクエストのレスポンスを取得します。

これらのリアルタイムワークロードと非同期ワークロードを共有アクセラレータに統合することで、GKE は「費用とパフォーマンス」のパラドックスを解決します。脆弱なカスタムキューポーラーを管理したり、使用率の低いクラスタを個別に維持したりする必要はもうありません。さらに、これらの作業はすべてオープンソースで可能です。つまり、複数のクラウドや環境でこれらのプロダクトを使用できます。

統合ワークロードの実例

共有インフラストラクチャでリアルタイムワークロードと非同期ワークロードを実行するというアイデアは、理論的には素晴らしいものですが、実際にはどのように機能するのでしょうか。優先度の高いリアルタイムワークロードとレイテンシが許容されるバッチリクエストを統合リソースプール内で同時に処理する有効性を分析したところ、有望な結果が得られました。

リアルタイムトラフィックは、予測不能な急増が特徴です。低レイテンシの回答を維持するには、ピーク時にプールの容量の 100% をリアルタイムトラフィックに使用できるようにする必要があります。一方、レイテンシが許容されるタスクは、容量が使用可能になるまで保留状態のままにする必要があります。

最初のテストで、管理されていない多重化のリスクが明らかになりました。優先度が低く、レイテンシが許容されるリクエストが、非同期プロセッサエージェントを使用せずに Inference Gateway に直接送信された場合、リソースの競合によりメッセージの 99% が削除されました。しかし、非同期プロセッサを使用した場合、レイテンシが許容されるリクエストの 100% が利用可能なサイクル中に処理されました。

図 2: リアルタイムトラフィック + レイテンシが許容されるバッチトラフィックで使用率が向上することを示しています。

次のステップ

同じインフラストラクチャでリアルタイム AI ワークロードとバッチ AI ワークロードの両方を実行することに関心をお持ちの場合は、最初に、Inference Gateway を使用した非同期推論のクイックスタートガイドをご覧ください。GitHub で OSS プロジェクトに参加して、この取り組みに貢献することもできます。開発の次の段階では、期限を考慮したスケジューリングに重点を置き、ユーザーがバッチ完了期間に「ソフトリミット」を設定できるようにすることで、フィラートラフィックとリアルタイムの需要のバランスをシステムが取る方法をさらに最適化します。この重要な取り組みでコミュニティと連携できることを楽しみにしています。

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

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

Containers & Kubernetes

GKE の弾力性がさらに向上: ゼロへのスケーリング、費用削減、ワークロードの応答性維持

進化: HPA ベースのゼロへのスケーリングと KEDA

仕組み: AutoscalingMetric と KEP-2021 を使用した HPA

最初の「ゼロへのスケーリング」ワークロードの構成

キャパシティ バッファによる起動レイテンシの管理

今後について

ゼロへのスケーリングを今すぐ始めましょう

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 支援による EKS から GKE への移行を実現する GKE エージェント型移行の概要

インフラストラクチャの移行に伴う課題

GKE エージェント型移行の概要

仕組み: 移行のライフサイクル

使ってみる

Agent Substrate は GKE にて高密度でスケーラブルな信頼できるインフラストラクチャを提供します

ローカルから 100 万エージェント規模へ

エージェント専用に構築された基盤

アーキテクチャの基本原則

Google Cloud インフラストラクチャ向けに最適化

スケーラブルな基盤上にエージェント プラットフォームを構築

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

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

gVisor を選ぶ理由

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

GKE の ClusterNetworkPolicy: マイクロサービスの制御と自律性のバランスを取る

ティアによるポリシーの構造化

一般的なネットワーク セキュリティ シナリオ

シナリオの例

オープンソース基盤の拡張

少ないリソースでより多くの成果を上げる: GKE でエージェントあたりの費用を 75% 削減する方法

ベースライン: microVM で OpenClaw を実行する

最適化 1: GKE Agent Sandbox で密度を向上する

最適化 2: オーケストレーションの価値

予算を増やさずにエージェントをスケールさせる

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

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

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

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

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

フロー: 全体像

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

使ってみる

GKE における AI サプライ チェーンの保護: 自動 AI BOM 対応 k8s-aibom のご紹介

負担のないアーキテクチャ

既存の AIBOM ツールでカバーできない領域

信頼度モデル: 意図と推論の分離

不変性と最小権限: 監査に適したセキュリティ モデルの構築

ガバナンス体制の整備の促進: グローバルな規制フレームワークへのマッピング

ご利用にあたって

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

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

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

Ray Serve に GKE を選ぶ理由

GKE で Ray Serve LLM を試す

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

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

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

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

GKE スタンバイ バッファの概要: 予算を抑えながらノードの起動時間を短縮

問題: 高いコストとレイテンシ

GKE キャパシティ バッファの概要 - 低レイテンシの Pod スケジューリングを実現するネイティブ Kubernetes の方法

アクティブ バッファとスタンバイ バッファの連携

キャパシティバッファによる起動レイテンシの管理

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

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

スケーラブルな基盤上にエージェントプラットフォームを構築

一般的なネットワークセキュリティシナリオ

GKE における AI サプライチェーンの保護: 自動 AI BOM 対応 k8s-aibom のご紹介

不変性と最小権限: 監査に適したセキュリティモデルの構築

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

GKE スタンバイバッファの概要: 予算を抑えながらノードの起動時間を短縮

GKE キャパシティバッファの概要 - 低レイテンシの Pod スケジューリングを実現するネイティブ Kubernetes の方法

アクティブバッファとスタンバイバッファの連携

GKE スタンバイバッファのベストプラクティス

GKE のノード起動が高速化され、コールドスタートレイテンシが解消

今回取り組んだ問題:「コールドスタート」の負担

解決策: ノードプロビジョニングの完全な再構築

1. Envoy はエージェントトラフィックを理解する

5. Envoy はエージェントネットワーキングの課題に対する包括的なソリューション

コントロールプレーンがこれを運用可能にする

2. 非同期（ニアリアルタイム）推論: 0 分のレイテンシ

ソリューション: 非同期プロセッサエージェント + Inference Gateway