GoogleがGKEでAgent Substrateの一般提供を開始、次のリクエストでActorを500ミリ秒未満で復元可能

Agent Substrateでできること

Agent Substrate 1.0は、エージェントのセッションとIDを実行中の計算資源から切り離します。メモリやファイル、IDを保持するActorと、ポリシーを担うGatewayは、KubernetesのWorkerのウォームプールから分離されています。^[1]

図1　Agent Substrate 1.0の3つの構成要素

標準のKubernetesの課題

エージェントは数秒コードやテストを実行した後、モデルの応答や外部API、人の入力を待ちます。標準のKubernetesでアクティブなエージェントごとにPodを与えると、待機中もメモリとCPUがふさがり、コントロールプレーンは数百万の永続オブジェクトを追跡します。

図2　標準のKubernetesでの待機中の課題

標準のKubernetesでは、IDがPodに結び付き、アクセスと秘密情報の制御が指数関数的に複雑です。エージェントには隔離された計算資源のほか、機密の鍵を持たずに許可されたツールとサービスだけへアクセスするための個別のIDと中央の強制点が必要です。

Actorの保存と復元

エージェントがモデルやツールの応答を待つと、Agent Substrateはメモリやファイルをストレージへ保存し、Workerをウォームプールへ戻します。次のリクエストが届くと、空いているWorkerへActorを500ミリ秒未満で復元し、中断した時点から再開します。

図3　Agent Substrateの主な数値

数百万のサンドボックスで本番ワークロードを受け入れられることも、Googleの評価です。Agent Substrateは標準のOCIコンテナを実行するため、ADKのエージェントやステートフルなコーディング環境、生産性エージェントがそのまま動きます。

CNCFへ寄贈されるほかの2プロジェクト

今回のリリースにより、任意のKubernetesクラスタやクラウドで、CPUやGPU、TPUにまたがって動くオープンなスタックが提供されます。各プロジェクトはコミュニティのメンテナーや独立したビルド基盤とともにCNCF Sandboxのオンボーディングを進め、gVisorはIncubationへ向かう途上です。^[1]

図4　今回のリリースが提供するオープンなスタック

RLによるエージェント学習は、数百万の並列なサンドボックスのロールアウトから学ぶオープンなループを開発者に与えます。Googleは、研究プレビューのOpenRLを事後学習とサービングの効率的な分散手段としています。

2月に研究プレビューとして始まったOpenRLはこのスタックで最も新しい層で、目標は任意のモデルを任意のアクセラレータで扱う1つのレシピです。Googleは、アクセラレータや推論エンジン、学習フレームワーク、オープンウェイトモデルの開発者とともに作るため、設計が固まる前にCNCFの中立的なガバナンスを整えるとしています。

図5　研究プレビューのOpenRLが目指す形

gVisorによるコードの分離

エージェントが記録系から行動系のシステムへ移ると、生成されたシェルコマンドや未レビューのパッケージを実行します。標準コンテナはホストのLinuxカーネルをノード上のほかのワークロードと共有するため、Googleは信頼できないコードには危険だとしています。

図6　標準コンテナとgVisorの分離の違い

ベアメタルやネストされた仮想化を使えない標準Linuxインスタンスでも、コンテナ並みの密度で強く分離するのがgVisorです。Goで書かれたアプリケーションカーネルが、システムコールをユーザー空間で処理し、信頼できないコードとホストカーネルの直接の接触を防ぎます。

gVisorの効率と対応環境

Googleは、gVisorのメモリが負荷に応じて増減するため、ノードごとに多くのエージェントを載せ、エージェント当たりのコストを下げられるとしています。gVisorはネストされた仮想化を必要とせず、任意のクラウドやローカルのLinuxノードへ同じ形でデプロイできます。

図7　エージェント向けのgVisorの3つの機能

gVisorでは、エージェントがサンドボックス内でアクセラレータを使え、アイドル時の一時停止も可能です。ただし、Agent Substrate on GKEはActorコンテナへのGPUパススルーをサポートしていません。^[1][2]

OpenRLの事後学習ループ

OpenRLは、自己ホスト型の強化学習（RL）の事後学習ループを、Kubernetes上で素のPythonにより動かします。研究プレビューとして始まった発表時点のOpenRLの主な特徴は、以下の通りです。

研究プレビューのOpenRLの特徴

OpenRLとllm-dの連携

研究プレビューとして始まった発表時点のOpenRLは、エピソードをAgent Substrateのサンドボックス内で実行します。llm-dのルーターは、一致するKVキャッシュのプレフィックスを持つサンプラーへ複数ターンのロールアウトを送り、重複するprefill計算を減らします。

図8　研究プレビューのOpenRLとllm-dの連携

RLの学習ではサンプラーとトレーナーが交互に動くため、片方の処理中はもう片方のチップ群が空いた状態です。研究プレビューのOpenRLは、llm-dの時分割で同じ物理GPUをサンプリングと学習で共有し、空いたアクセラレータの時間を回収します。

Agent Substrateなどを試す場所

試す場所とGKEでの実行の入口、インストールの前提は、以下の通りです。^[1][2]

GKE Sandboxを使うStandardクラスタで未処理のソケットを開くには、コンテナのセキュリティコンテキストへのNET_RAWの明示的な追加が必要です。^[3]

spec:
  containers:
  - name: my-container
    securityContext:
      capabilities:
        add: ["NET_RAW"]

公式資料からの抜粋：GKE Sandbox（制限事項 / 機能）。対象版・範囲：確認日時点のGKE Sandboxのドキュメント（Standardクラスタに適用、最終更新日2026-11-05 UTC）。

上記のコードでは、my-containerのcapabilitiesのaddにNET_RAWを指定しています。pingやtcpdumpは、未処理のソケットを作るツールの例です。

図9　GKE SandboxのStandardクラスタでのNET_RAW

Agent Substrate on GKEの利用条件

Agent Substrateは1.0に到達し、Agent Substrate on GKEとして一般提供されています。2026年9月16日の発表時点では、非本番ワークロードはすべてのGKE利用者が使え、本番向けのGAサポートは許可リスト経由でした。^[1][4]

図10　Agent Substrateの提供状態

Agent Substrate on GKEでは、一時停止したアイドル状態のエージェントはCPUやメモリを使いません。コンピューティング料金は、タスクを処理している場合にのみ発生します。^[2]

Agent Substrate on GKEは、コントロールプレーンとノードプールが1.37以降のGKE Standardクラスタに対応します。主な要件は、以下の通りです。

1ノードで約800個を超えるサンドボックスを同時に動かすと、カーネルの既定の上限を超えます。インストーラは作成したクラスタに設定を適用し、既存クラスタや独自のノードプールでは自分で適用する前提です。

Agent Substrateの構成の選び方

編集部が、実行先と分離方式を場面別に整理しました。Agent Substrate 1.0では、ライフサイクルの管理方法を変えずに分離の境界を選べます。^[1]

Google Cloudでマネージドに使うならAgent Substrate on GKE、自前のKubernetesクラスタならオープンソースのコードが候補です。クラスタを管理せずAPIで専用のmicroVMを使う場合、GoogleはAgent SubstrateがAgent Compute Engineを補完するとしています。

図11　Agent Substrateの実行形態と補完サービス

Linuxカーネル全体との互換性が必要な場合は、ハードウェアで分離するCloud Hypervisor microVMsが候補です。ネストされた仮想化を使えないノードで分離したい場合や低いオーバーヘッドを重視する場合は、gVisorが候補です。^[1][4]

図12　Agent Substrateの分離方式の比較（編集部の整理）