Google、AIエージェント実行基盤をCNCFへ寄贈、隔離方式と導入時の要点

Googleは2026年11月5日、AIエージェント向けのオープンソース実行基盤「Agent Substrate」と、コードを隔離して実行する「gVisor」のCloud Native Computing Foundation（CNCF）への寄贈を発表した。Agent Substrateは正式版1.0を公開しており、Google Kubernetes Engine（GKE）でも利用できる。GKE向けの提供には、GPU利用や一時停止時のネットワーク接続、本番サポートに条件がある。

■CNCFの下で開発体制を拡大

CNCFはLinux Foundation傘下でクラウドネイティブ技術の開発を支える組織だ。GoogleはAgent SubstrateとgVisorを、OpenRLとともにCNCFのSandboxプロジェクトとして寄贈し、移行手続きを進めている。

gVisorプロジェクトが10月2日に公表した経緯によると、Googleは9月7日に申請し、CNCFは9月22日の審査を経て9月28日に受理した。Agent Substrateについても、CNCFの公開記録では9月28日に受け入れ投票が可決され、10月20日に寄贈契約への署名と受け入れ手続きの開始が記録されている。

Agent Substrateは、Kubernetes上で動作する独立した実行基盤として開発されてきた。Solo.ioのLin Sun氏も、7月7日にCNCFへ寄稿した解説で、当時はKubernetesのSIGなどに属さない独立プロジェクトと紹介していた。

gVisorプロジェクトは10月の発表で、Google以外のメンテナーへのマージ権限付与を数週間以内に、組織単位の投票を含む長期的な統治体制への移行を数カ月以内に進める方針を示した。Ant Group、Modal、Tinesがメンテナーへの参加を表明し、OpenAI、Tencent、NVIDIAも貢献を続けるとしている。

Googleは、米ユタ州ソルトレークシティーで開かれるKubeCon + CloudNativeCon North America 2026で両プロジェクトを紹介する。同イベントの開催期間は11月9日から12日までだ。

■エージェントの状態と実行用リソースを分離

Agent Substrateは、エージェントの状態を持つ「アクター」と、実際に処理を実行する「ワーカー」を分けて管理する。モデルの応答や人間の入力を待つ間はアクターを一時停止し、メモリとローカルファイルの状態を保存して、ワーカーを共有プールへ戻す。

次の要求が届くと、利用可能なワーカーに状態を復元し、処理を再開する。Googleの説明では、保存には階層型ストレージを使う。待機中のエージェントごとにCPUやメモリを確保し続ける負担を減らす仕組みだ。

制御プレーンのAPIサーバーは「ate-api-server」で、実行バイナリ名は「ateapi」だ。受信要求を振り分ける「atenet-router」と連携し、アクターの実行先や一時停止・再開を管理する。

アクターの隔離には、gVisorまたはCloud HypervisorのマイクロVMを選べる。gVisorはユーザー空間で動くアプリケーションカーネルで、「Sentry」がアプリケーションのシステムコールを処理し、「Gofer」がファイルアクセスを仲介する。アプリケーションがホストのLinuxカーネルへ直接アクセスする範囲を抑える構造だ。

Cloud Hypervisorを使う場合は、ハードウェア仮想化によるマイクロVM内で処理を実行する。Agent Substrateは、隔離方式を選びながら、共通の管理インターフェースでエージェントのライフサイクルを扱える。

■GKE版のGPU利用と接続維持に関する条件

2026年11月7日時点のGoogleのGKE向けドキュメントでは、アクターコンテナへのGPUデバイスのパススルーは未対応だ。「nvidia.com/gpu」を指定してPodをGPU搭載ノードへ配置しても、アクターへGPUデバイスは渡されない。また、実行中のCUDAコンテキストのスナップショットにも制約がある。

gVisor自体には、サンドボックス内のプロキシドライバー「nvproxy」を通じてCUDAアプリケーションからNVIDIA GPUを利用する機能がある。gVisorのGPU対応、Agent Substrate on GKEでのデバイス提供、一時停止時に保存できる状態は、それぞれ導入時に確認する項目となる。GKE版でGPU推論を組み合わせる場合は、推論処理を外部サービスなどへ分離する設計が必要だ。

データベースのセッションや、AIと外部ツールを接続するModel Context Protocol（MCP）のサーバーへの接続などは、アクターの一時停止時に保持されない。エージェント側には、再開後の再接続と、必要に応じて処理を再試行する仕組みを組み込む必要がある。

対応環境は、英語版の現行ドキュメントでは制御プレーンとノードプールがバージョン1.37以降のGKE Standardクラスタだ。Workload Identity Federation for GKEの有効化も必要になる。マイクロVMを選ぶ場合は、ネストされた仮想化に対応するノード、またはx86のベアメタルノードを用意する。

■再開時間と実行密度の公表値

Googleは、Agent Substrateの再開時間を500ミリ秒未満、標準的なコンテナランタイムに対する実行密度を10倍、停止・再開のアクティベーションを毎秒500回超と説明している。いずれも同社が公表した性能値であり、導入時には自身のワークロードと保存・復元条件に合わせて評価する必要がある。

技術解説者のLuca Berton氏は10月10日の記事で、ワーカーの共有による密度30〜100倍、起動待ち時間の95パーセンタイル値100ミリ秒未満という目標を紹介した。同氏はこれらを目標値として扱っている。Googleの公表値とあわせ、想定する負荷や評価対象を確認することが重要になる。

高密度での実行には、ホスト側の設定も関わる。Googleの現行GKEドキュメントは、1ノードで約800個を超えるサンドボックスを同時実行すると、ファイル監視機構のinotifyや、アドレス解決に使うARPの近隣テーブルの既定上限を超えると説明する。インストーラーが新規作成するクラスタには必要な設定が適用される。

■gVisorの運用実績と更新管理

Googleによると、gVisorはGKE SandboxとCloud Runで毎日数百万のサンドボックスを支えている。gVisorプロジェクトは、Google、Ant Group、OpenAI、Anthropic、Modal、Tinesを利用企業として挙げている。

更新管理では、Goferに関する脆弱性「CVE-2026-96812」も確認対象となる。Googleが登録したCVE情報によると、CUSEが有効なLinuxホストで、攻撃者がコンテナイメージを配置する権限を持つ場合に、ホスト上でroot権限のコード実行につながる。CVSS v4.0の基本値は8.8だ。

Debianのセキュリティ追跡情報は、この問題の修正をgVisorのリリース20260824.0に対応付けている。Agent Substrateのv1.0.0-rc.1のリリースノートには、gVisorを20261026.0へ更新したことが記載されている。運用では隔離方式の選択に加え、実際に導入するランタイムの版と更新状況を管理することが重要だ。

■正式版1.0と本番サポートの範囲

Agent Substrateは、10月29日のv1.0.0-rc.1などのリリース候補を経て、11月5日付で正式版v1.0.0を公開した。2026年11月7日時点のREADMEは、公開API、CLI、設定形式の互換性と安定性を維持し、互換性を壊す変更にはメジャーバージョンの更新を伴う方針を示している。

GoogleはAgent Substrate on GKEの一般提供も発表している。日本語の公式ドキュメントによると、評価・非本番用途はすべてのGoogle Cloudユーザーが利用でき、本番サポートは許可リストに基づく限定公開の一般提供プログラムで提供される。CNCFはSandboxを、実験的で本番環境での検証がまだ広範ではない段階と説明している。

関連するマネージドサービスが、Googleが10月22日に発表したAgent Compute Engineだ。エージェントごとに専用マイクロVMを用意し、Titaniumなどを用いたハードウェアに根差す認証・隔離機構を備える。認証用の秘密鍵はゲスト環境の外に保持し、長期的な認証情報もサンドボックス外で管理する。

Agent Compute Engineのプレビューは、10月22日の発表で今後数カ月以内とされ、具体的な開始日や価格は示されていない。Agent Substrateを導入するチームは、クラスタの運用方法、必要な隔離方式、GPU処理の配置、再接続の設計、本番サポートの条件を整理して利用環境を選ぶことになる。

元記事: Google Donates AI Agent Sandbox to Linux Foundation’s CNCF; Agent Substrate Lacks GPU Passthrough