GKE Agent Sandbox 徹底解説 — AIエージェント時代のKubernetes分離基盤とは

はじめに

AIエージェントが「コードを書く」だけでなく「そのコードを自分で実行する」段階に入り、インフラ側の前提が静かに崩れ始めている。人間がレビューしたコードを動かす従来のワークロードと違い、エージェントが生成したコードは信頼できない前提で扱わざるを得ない。GoogleがGKE（Google Kubernetes Engine）に投入した GKE Agent Sandbox は、まさにこの「信頼できないコードを、大量に、高速に、安全に走らせる」という難題への回答だ。本記事では、その仕組みとエンジニアへの実務的な意味を掘り下げる。

GKE Agent Sandbox とは何か

GKE Agent Sandbox は、LLMが生成した信頼できないコードを隔離実行するために設計された、Kubernetesベースの実行環境である。KubeCon NA 2025 で Kubernetes SIG Apps のサブプロジェクト（kubernetes-sigs/agent-sandbox）として登場し、Cloud Next ‘26 でマネージド機能として発表された。GKE 1.35.2 以降のクラスタで利用できる。

最大の特徴は、Kubernetes に 3つの新しいカスタムリソース（CRD） を持ち込んだ点にある。

Sandbox: 安定したホスト名・ネットワークID・永続ストレージを持つ、ステートフルな単一Podを表すコアリソース
SandboxTemplate: セキュリティ設定やネットワークルールを定義する「設計図」
SandboxClaim: 実装の詳細を意識せず、実行環境を「請求」するためのリソース

この分離は、Kubernetes の PersistentVolumeClaim（PVC）を知っている人には馴染み深い発想だ。開発者は「どんな環境が欲しいか」を SandboxClaim で宣言するだけで、コントローラが背後で Pod の割り当てや再利用を差配する。エージェントフレームワーク（LangChain や Vertex AI の Agentic SDK）は Python SDK 経由でこの請求モデルを叩き、面倒な CRD 設定を隠蔽できる。

技術的な背景 — なぜ普通のコンテナでは足りないのか

エージェントが吐くコードは、意図せず、あるいは悪意を持って、ホストのカーネルやクラスタの制御プレーンを叩きに来る可能性がある。通常のコンテナは Linux カーネルを共有するため、カーネルの脆弱性を突かれれば隔離は破られる。ここで効いてくるのが gVisor だ。

gVisor は Google が開発したアプリケーションカーネルで、コンテナの軽量さを保ちつつ、VM に近い強力な分離を提供する。各サンドボックスは独自のカーネル・ネットワーク・ファイルシステムを持つ「バブル」の中で動き、悪意あるコードはその中に閉じ込められる。Agent Sandbox はこの gVisor をネイティブサポートし、加えて デフォルト拒否（Default Deny）のネットワークポリシー を標準で適用する。内部ネットワークや GKE 制御プレーンへのアクセスは既定でブロックされ、必要な通信だけをテンプレートで明示的に開ける。分離ランタイムは gVisor に限らず Kata Containers なども差し込めるプラガブル設計になっている。

しかし、強い分離には代償がある——起動の遅さだ。ここを解くのが2つの仕掛けだ。1つは ウォームプール。事前に温めた Pod のプールを保持し、SandboxClaim が来た瞬間にイメージpullやコールドスタートを待たずに割り当てる。Google はこれで 1クラスタあたり毎秒300サンドボックス、割り当ての90%が200ミリ秒以内 に完了すると謳う。コールドスタート比で最大90%の高速化だ。

もう1つが GKE 限定の Pod Snapshots。実行中のPodの状態をまるごとチェックポイント/リストアできる機能で、アイドル状態のサンドボックスを一時停止してリソースを解放し、リクエスト時に数秒で復元する。GPUを使う高価なエージェントワークロードで、「使わない間は止め、必要な瞬間に瞬時に戻す」という運用が現実になる。

エンジニアへの影響

まず、AIエージェントをプロダクションに載せるチームにとって、「コード実行のサンドボックス」を自前で組む必要が薄れる。これまで Firecracker や自作 gVisor 構成で悩んでいた分離レイヤが、Kubernetes のリソースとして宣言的に扱えるようになる意味は大きい。SandboxClaim モデルにより、アプリ側のコードは「セキュアな実行環境をください」と請求するだけで済む。

次に、コスト構造が変わる。ウォームプールと Pod Snapshots の組み合わせは、「常時起動で待たせる」か「都度コールドスタートで待たせる」かという従来の二択を崩す。標準容量バッファ（サスペンド済みVM）による“コールドプール”を併用すれば、GPU付きサンドボックスのアイドルコストを抑えつつ、体感はほぼ即時に保てる。Google は Axion プロセッサ上で他社比 最大30%良好な価格性能 も主張している。

一方で、これは Google のロックインを強める動きでもある。CRD 自体は SIG のオープンソースだが、Pod Snapshots は GKE 専用機能だ。マルチクラウドを重視するなら、どこまで GKE 固有機能に寄せるかは設計判断になる。エージェント基盤の選定では「移植性 vs 起動レイテンシ」のトレードオフを意識したい。

まとめ

GKE Agent Sandbox は、AIエージェント時代のインフラに必要な「信頼できないコードの隔離実行」を Kubernetes のプリミティブとして再設計した試みだ。要点は3つ——(1) gVisor によるカーネルレベル分離とデフォルト拒否ネットワーク、(2) SandboxClaim による宣言的な環境請求モデル、(3) ウォームプールと Pod Snapshots によるサブ秒起動とコスト最適化。エージェントが自らコードを実行する流れが不可逆である以上、こうした「エージェント専用の実行基盤」は今後の標準要件になっていくだろう。GKE 固有機能への依存度をどう設計するかが、当面の腕の見せどころになりそうだ。

今日のその他のニュース

Claude Sonnet 5 が登場（6/30）: Anthropic がワークホース層の Sonnet を刷新。推論・ツール利用・コーディングが Sonnet 4.6 から大幅向上。Microsoft 365 Copilot など多くのアプリが叩く層のため影響範囲が広い。同週に OpenAI は GPT-4.5 を撤去し GPT-5.5 へ集約と、主要各社の世代交代が一気に進んだ。
Loop Engineering が話題: 「自分の仕事は loop を書くこと」——個別プロンプトではなく、エージェントが自律的に回り続けるループを設計するという発想転換。すでに4800スターを集め、AIコーディングの実務知見が一段深まりつつある。
curl が7月の脆弱性報告受付を停止: AIスロップ（AI生成の低品質報告）が優秀になった逆説として、curl プロジェクトが脆弱性報告の受付を一時停止。OSSのセキュリティ運用がAI時代にどう変わるかを象徴する一件。