11月6日、Google Open Source Blogが「Sandboxing Untrusted AI Agents at Scale: Google Donates Agent Substrate and gVisor to the CNCF」と題した記事を公開した。GoogleがAIエージェント向けサンドボックス基盤「Agent Substrate」およびセキュアコンテナランタイム「gVisor」をCloud Native Computing Foundation（CNCF）に寄贈したことを発表する内容で、Kubernetesそのものを作り直すのではなく、Kubernetes上に追加レイヤーを設けることで根本的なアーキテクチャ上の問題を解決するアプローチが詳述されている。
KubernetesはAIエージェントのために設計されていなかった
2014年の公開から12年。Kubernetesが採用するPodという実行単位は「起動→リクエスト処理→停止」という単純なライフサイクルを前提に設計されてきた。
AIエージェントはこのモデルと根本的に相性が悪い。
コーディングアシスタント、SREトラブルシューター、マルチターンの評価ループ——これらのエージェントは大半の時間を「待機」に費やす。モデルのトークン生成を待ち、人間のレビューを待つ。典型的なセッションでは、**エージェントがCPUを使う時間はわずか5〜10%**にすぎない。
問題は、待機中であってもコンテナを単純に落とせない点だ。エージェントはメモリとディスク上に重要な状態を保持している——アクティブな言語ランタイム、ローカルのGitリポジトリ、未コミットのファイル編集、ツールセッション。これらを失えばセッションが壊れる。
標準的なKubernetesで対応しようとすると、プラットフォームエンジニアは2つの悪い選択肢に直面する：
- 専用Podを常時起動し続ける → レスポンスは速いが、1万ユーザー規模になるとアイドル状態のコンピュート費用が膨らみ、クラスタコストが持続不可能になる
- サーバーレスコンテナでゼロスケールする → コスト節約はできるが、コールドスタート時にリポジトリのクローン・パッケージ再インストール・メモリ再構築が発生し、ウェイクアップのレイテンシが20秒を超え、インタラクティブな体験が破綻する
もう一つの問題がコントロールプレーンの過負荷だ。強化学習ループやベンチマーク評価では、数千のタスクを同時並行で実行する必要がある。サンドボックスごとにフルのKubernetes Podを要求すると、etcdへの書き込みが殺到し、kube-apiserverが飽和し、サブネットのIPアドレスが枯渇する。
Agent Substrateのアーキテクチャ：ActorとWorkerの分離
Agent SubstrateはKubernetes上にアクターベースのコントロール・データプレーンを追加することでこの問題を解く。核心はActorとWorkerの分離だ：
- Actor：個別のエージェントセッションを表す。ファイルシステム、環境変数、メモリ状態、ネットワークルールを保持する「状態の器」
- Worker：事前に暖機済みのKubernetes Podで構成される共有プール（WorkerPool）。コンテナランタイムとサンドボックス境界を持つ「計算リソース」
エージェントへのリクエストが来ると、L7プロキシであるatenet-router（Agent Substrateのネットワーク層に位置し、ActorへのリクエストをWorkerプールへルーティングする専用コンポーネント）がリクエストを受け取り、対象のActorがサスペンド中であればメモリ上で保留しながらSubstrateコントローラに通知。コントローラはウォームなWorkerプールからスロットを割り当て、Actorのメモリとディスク状態を階層型ストレージから500ミリ秒以内に復元する。ターンが終わると状態をスナップショットしてWorkerスロットを解放、次のワークロードに回す。
この仕組みにより、新たなPodオブジェクトを作らずに毎秒数千のActorをアクティベート・サスペンド・レジュームできる。
セキュリティの要：gVisorとmicroVM
AIエージェントが実行するコードはモデルが生成した信頼できないコードだ。標準的なLinuxコンテナはホストカーネルを共有するため、マルチテナント環境ではそのまま使うのはリスクが高い。
Agent SubstrateはgVisor（runsc）と組み合わせて使う。gVisorはGoで書かれたGoogleのオープンソースアプリケーションカーネルで、システムコールをユーザー空間でインターセプトすることで、信頼できないコードをホストカーネルから隔離する。gVisorが独自のメモリとプロセステーブルを仮想化するため、Substrateは実行中の環境をフリーズし、メモリページをストレージに書き出し、別ノード上で500ミリ秒以内に復元できる。
ハードウェア仮想化やカスタムカーネルモジュールが必要なワークロードには、同じ統一APIの下でCloud Hypervisor microVMもサポートする。
CNCFへの寄贈：オープンスタックとしての位置づけ
今回の寄贈で、クラウドネイティブコミュニティ向けのエージェントインフラのオープンスタックが次の3層で構成される：
- Layer 1（セキュアな分離）：gVisor — ユーザー空間カーネル隔離と高速メモリチェックポイント
- Layer 2（エージェントランタイム）：Agent Substrate — ステートフルなActorをウォームなWorkerプールに多重化し、500ms以内のウェイクアップを実現
- Layer 3（トレーニングオーケストレーション）：OpenRL — Kubernetesネイティブの強化学習（Reinforcement Learning）ループと評価サンドボックスを調整するコンポーネント。AIモデルのトレーニングパイプラインをKubernetes上でオーケストレーションする役割を担う
Agent SubstrateはすでにCommunityで急速にコア機能の開発とAPI安定化が進んでおり、最新の1.0リリースに至っている。KubeCon + CloudNativeCon North America（11月9〜12日、ソルトレイクシティ）では、ATEconと呼ばれるAgent Substrate専用デイ（11月9日）のほか、Tim HockinとKelsey Hightowerによるファイアサイドチャット「Kubernetes Act II」、GKE上でのハンズオンワークショップなど複数のセッションが予定されている。
詳細はSandboxing Untrusted AI Agents at Scale: Google Donates Agent Substrate and gVisor to the CNCFを参照していただきたい。
