2026.11.10 インフラ・クラウド

Agent Substrateとは：AIエージェントをgVisorで隔離しKubernetesで高密度に動かす仕組みと導入手順

Agent Substrateは、Googleが開発し、2026年11月5日にCNCF（Cloud Native Computing Foundation）へSandboxプロジェクトとして寄贈した、AIエージェント向けの実行基盤です。Kubernetesの上に独自の制御プレーンを重ね、待ち時間の長いエージェントを中断してスナップショットに退避します。要求が来れば、空いているPodで500ミリ秒未満で再開させる仕組みです。この記事では、設計、kindでのデモ、WorkerPoolとActorTemplateの書き方、GKEでの導入条件を一次情報で確認し、Agent Sandboxで足りる場面との線引きまで示します。隔離を担うgVisor自体はgVisorとは？コンテナを隔離するサンドボックスの仕組みで扱っています。

まとめ｜Agent SubstrateはPodを使い回しエージェントを中断と再開で多重化する基盤

単位は「Actor」で、エージェント1つのセッションをメモリとファイルシステムごとスナップショットにできます。Actorは特定のPodに張り付かず、事前に起動した少数のWorker Podを順に借りて動く設計です。公式サイトは、標準的なコンテナランタイムの10倍の集積度と、毎秒500回を超える中断と再開をうたっています。いずれもGoogleの発表値です。

向いているのは、推論やユーザーの返答を待つ時間が大半のエージェントを数百以上抱えるサービスです。同時に数十程度、GPUを使う、DBやMCPサーバーとの接続を張り続けたい、のいずれかに当たるなら、1エージェント1Podの構成かAgent Sandboxで足ります。GKEでは追加料金なしで導入でき、課金は作成したリソース分だけです。

Agent Substrateの位置づけとCNCF寄贈・GKE提供に至った経緯

CNCF Sandboxへ寄贈された1.0系のApache-2.0オープンソース

Google Open Source Blogの発表によると、GoogleはKubeCon North Americaの週に、Agent Substrate、gVisor、強化学習向けのOpenRLをCNCFへSandboxの段階で寄贈しました。SandboxはCNCFの成熟度で最初の段階にあたり、業界標準として確定したわけではありません。ソースはGitHubのagent-substrate/substrateで公開され、ライセンスはApache-2.0です。READMEは1.0に到達したと明記し、API・CLI・設定形式の互換性を保つ方針を示しています。2026年11月10日時点でReleases欄は空で、パッチ版の番号は確認できませんでした。

経緯をたどると、初出は2026年5月21日のGoogle Cloudブログで、GKEのAgent Sandboxの一般提供と同時に予告されました。9月16日にはGKEでの提供開始が発表され、本番以外は全GKE利用者が使え、本番向けサポートは許可リスト方式です。

1エージェント1Podの前提が数千規模で行き詰まる3つの理由

通常のKubernetesはエージェント1つにPodを1つ割り当て、待っている間もCPUとメモリの予約を握り続けます。Google Open Source Blogによれば、対話型エージェントの稼働時間の90〜95%は推論・外部API・人のレビューの待ちです。公式のArchitectureドキュメントは、APIサーバーが数百万件のリソースに向かないこと、Podの起動に数秒かかることも挙げています。

観点	通常のPod	Agent Sandbox	Agent Substrate
割り当て	1エージェント＝1Pod	1エージェント＝1Pod	多数のActorでWorkerを共有
待機中の資源	握ったまま	Pod Snapshotsで中断可	退避してWorkerを解放
経路上の制御	Kubernetes API	Sandbox API	専用の制御プレーン
隔離方式	runc等	gVisor、Kata等	gVisor、microVM

そこでAgent Substrateは、Kubernetesの役割をWorker Podの用意やノードの増減に限り、Actorの中断と再開を専用の制御プレーンで処理します。なおAgent SandboxはKubernetes SIGのプロジェクトで、Google Cloudブログは両者を置き換えではなく併用の関係と説明しています。

ActorとWorkerを分ける設計と中断中のエージェントへ要求が届く流れ

ActorとWorkerPoolとActorTemplateの役割と5つの用語の対応

GKEのAgent Substrate解説ページとREADMEの定義を表にまとめます。

用語	実体	Kubernetesリソース
Actor	エージェント1つの実行単位	いいえ
Worker	Actorを載せる待機中のPod	はい（Pod）
WorkerPool	Workerの数と隔離方式の定義	はい（CRD）
ActorTemplate	イメージとCPU・メモリの雛形	いいえ
Atespace	Actorをまとめる名前空間	いいえ

KubernetesのリソースはWorkerPoolだけで、ActorとActorTemplateはkubectl ateプラグインで制御プレーンに登録します。etcdにオブジェクトが増えないため、Actorが数百万になってもAPIサーバーの負荷は変わりません。

SUSPENDEDのActorがRUNNINGに戻るまでの8段階の処理

ActorはSUSPENDEDで作られ、要求が来るとRESUMINGを経てRUNNINGになります。Architectureドキュメントが示す、中断中のActorにHTTPリクエストが届いたときの順序は次のとおりです。

クライアントがate-target-actorヘッダに<atespace>/<actor>を付けて送る
Envoyベースのatenet-routerが、制御プレーンのate-api-serverへResumeActorを依頼
ate-api-serverが空きWorkerを確保し、そのノードのateletへ復元を指示
ateletがスナップショットをノード上のコピーかオブジェクトストレージから取得
ateletがWorker内のateworkerへRestoreWorkloadを呼び、サンドボックスを復元
ate-api-serverがWorkerのPod IPを返し、ActorがRUNNINGになる
atenet-routerがWorkerのatunnel（8443番）へmTLSのCONNECTトンネルを張る
atunnelがリクエストをActorへ転送し、応答が同じ経路で戻る

要求は再開が終わるまでルーターで保留されるので、呼び出し側は相手が中断中かを意識しません。ActorとWorkerの対応はPostgreSQLに保存されます。

gVisorとmicroVMの隔離と認証情報を持たせないegressの設計

隔離方式は2種類で、既定はgVisorのrunscです。gVisorはメモリとプロセスの表を自前で管理するため、実行中の環境を凍結して別ノードで戻せます。ハードウェア仮想化の境界が必要ならKata ContainersとCloud HypervisorのmicroVMを選び、違いはKata ContainersとはやFirecracker（マイクロVM）とはで比べています。通常のrunc、つまり素のLinuxコンテナでは動きません。スナップショットの保存先はGCSかS3です。

セキュリティは全Actorを互いに敵対しうるものとして扱います。公式サイトate.devによると、Actorは受信も他のPodへの通信も禁じられた状態で起動し、ActorごとにSPIFFE形式の短命な証明書が発行されます。LLMのAPIキーはActorの中に置かず、外向き通信を中継するatenet-egressが許可された宛先にだけ差し込む方式です。乗っ取られても盗める鍵が中にありません。

kindのローカル環境でcounterデモを動かし中断と再開を確かめる手順

Go・kubectl・Dockerの前提と1,000サンドボックス超で要るカーネル設定

公式のQuickstartの前提はGo、kubectl、Dockerの3つで、kindはGo経由で自動的に用意されます。1台のLinuxホストで1,000を超えるサンドボックスを動かす場合は、ARPのneighbor tableの上限を広げます。

sudo sysctl -w net.ipv4.neigh.default.gc_thresh1=4096
sudo sysctl -w net.ipv4.neigh.default.gc_thresh2=16384
sudo sysctl -w net.ipv4.neigh.default.gc_thresh3=32768

既定値1024のままだと、hack/create-kind-cluster.shが警告を出します。

ate-setupで導入しkubectl ateでActorの中断と再開を試すコマンド

READMEとQuickstartのコマンドで、kindクラスタの作成からcounterデモの呼び出しまで進めます。ATE_INSTALL_KIND=trueはate-setupを動かすすべてのシェルで設定してください。

git clone https://github.com/agent-substrate/substrate.git
cd substrate
hack/create-kind-cluster.sh
export ATE_INSTALL_KIND=true
go run ./cmd/ate-setup deploy ate-system --credential-provider='{"name":"k8s.io"}' \
  --ingress-allowed-spiffe-ids=spiffe://cluster.local/ns/ate-system/sa/atenet-client
go run ./cmd/ate-setup deploy demo counter
go install ./cmd/kubectl-ate
kubectl ate create actor my-counter-1 -a ate-demo-counter --template counter
kubectl ate proxy actor my-counter-1 -a ate-demo-counter

kubectl ate proxyは8000番ポートでプロキシを開き、別のターミナルからcurl -X POST -i http://localhost:8000/を送るとカウンターが増えます。中断は次の操作です。

kubectl ate get actor my-counter-1 -a ate-demo-counter
kubectl ate suspend actor my-counter-1 -a ate-demo-counter

中断後にもう一度curlを送ると、Actorは空いているWorkerで再開し、カウンターは中断前の続きから数えます。kindでのスナップショットの保存先はgs://ate-snapshots/です。片付けは./hack/delete-kind-cluster.shで済みます。

WorkerPoolとActorTemplateを書いて自作エージェントを載せる設定例

WorkerPoolでgVisorを指定し待機Workerを10台置く定義

次はAPI Configuration GuideのWorkerPoolの例です。

apiVersion: ate.dev/v1
kind: WorkerPool
metadata:
  name: agent-pool
  namespace: ate-demo
  labels:
    workload: secret-agent
spec:
  replicas: 10
  workerImage: ko://go.ate.dev/substrate/cmd/ateworker-gvisor
  sandboxClasses:
  - name: gvisor
    configRef:
      name: gvisor-default

replicasは待機させるWorker Podの数です。隔離方式はsandboxClasses[].nameにgvisorかmicrovmを書いて決め、後から変えられず、指定できるのは1つだけです。Workerの容量はtemplate.resources.limitsで決め、Actorはそれを分け合って配置されます。

ActorTemplateでイメージとCPU・メモリを宣言する定義

ActorTemplateはapiVersionとkindを持たない形式で、kubectl ate create actor-template -fで登録します。

metadata:
  atespace: ate-demo
  name: secret-agent
containers:
- name: agent
  image: gcr.io/my-project/my-agent@sha256:7f28ab0e...
  wakeupProbe:
    httpGet:
      path: /readyz
      port: 80
workerSelector:
  matchLabels:
    workload: secret-agent
resources:
  limits:
    cpuMillicores: 1000
    memoryBytes: 1073741824 # 1Gi

イメージはダイジェスト指定が必須で、workerSelectorでWorkerPoolのラベルを選びます。resources.limitsはCPUとメモリの両方が必須で、作成後は変えられません。wakeupProbeを書けば、エンドポイントが200を返すまで再開完了を待ちます。

注意したいのは再開後の接続です。GKEの解説ページは、DBのセッションやMCPサーバーとの接続は中断をまたいで維持されないと明記しています。エージェントのコードには、再開直後に接続を張り直す処理が要ります。

GKEでの導入条件：Standard 1.37以降・c3以上のノードとインストーラー

Standardクラスタ1.37以降の前提とinstall.shでの導入コマンド

GKEのインストールガイドの主な前提は次のとおりです。

GKE Standardのみ（Autopilotは対象外）
コントロールプレーンとノードがGKE 1.37以降
既存クラスタはDataplane V2が必要
ノードはc3-standard-4以上（E2は不可）
Cloud Shellは容量不足で使えない

導入はsubstrate-gkeのインストーラーで行い、デモも入れるなら--demoを付けます。

curl -sSL https://raw.githubusercontent.com/ai-on-gke/substrate-gke/main/install.sh | bash -s -- --demo

実行者にはProject IAM Adminなど7つのロールが要ります。

GPUパススルー非対応とGKE Sandboxを併用できないノードプールの制約

設計に響く制約は3つです。1つ目はGPUのパススルーに対応しないことで、gVisorは動作中のCUDAコンテキストをスナップショットできません。推論は外部のAPIか別のPodに任せます。2つ目は、Agent Substrateを動かすノードプールでGKE Sandboxを有効にできないことです。別のノードプールなら使えます。3つ目は、1ノードで約800を超える同時サンドボックスにはinotifyとARPの上限の引き上げが要ることです。インストーラーで作ったクラスタには自動で入りますが、既存クラスタでは手作業になります。

Agent Substrateを採用する条件とAgent Sandboxで足りる場面

待機の長いエージェントを数百以上同時に抱えるサービスなら採用する

判断材料はエージェントの数と待ち時間の割合です。顧客ごと・セッションごとにエージェントを分け、その大半が推論や人の返答を待っているなら採用します。1エージェント1Podでは待機中もノードの資源を予約し続け、抱えられる数がノード数で頭打ちになるからです。生成コードの実行など、信頼できない処理をユーザーごとに隔離したい場合も当てはまります。

同時数十程度・GPU必須・DB常時接続のエージェントでは導入を見送る

同時に動くエージェントが数十程度なら見送ります。ate-api-server、PostgreSQL、atelet、ルーター、egressと部品が増え、運用の手間がPodの節約分を上回るためです。この規模なら、Agent SandboxのウォームプールとgVisorによる隔離だけで足ります。GPUをサンドボックス内で使う処理、WebSocketやDB接続を張り続ける処理も対象外です。Kubernetesの運用経験が無いチームは、Kubernetesの仕組みを押さえるところから始めてください。

マネージドのサンドボックスと比べてGKEで自前運用を選ぶ判断基準

クラスタを持たずに隔離環境を借りたいなら、Cloudflare ContainersやDocker Cloud Sandboxesのようなマネージド型が早道です。データを自社のVPCの外に出せない、既存のGKEと同じネットワークで社内システムを呼ばせたい、という要件があればAgent Substrateを選びます。

ノードプールやIAMの権限設計を社内で抱えきれないなら、一創のインフラ構築（AWS・Google Cloud・Azure）でGKEのクラスタ構築と運用設計を相談できます。

よくある質問

Agent Substrateを調べ始めた段階で出やすい疑問をまとめました。

Agent SubstrateとAgent Sandboxの違いは何ですか？

Agent Sandboxは、エージェント1つに専用のPodを割り当てるKubernetesのリソースで、ウォームプールとPod Snapshotsを備えます。Agent Substrateはそのランタイムとスナップショット機能を土台に、Kubernetes APIを通らない制御プレーンを足し、多数のActorを少数のWorkerで使い回す仕組みです。Google Cloudブログは、置き換えではなく、通常のPodの振る舞いが要る処理では並行して使う関係だと説明しています。

Agent SubstrateはGKE以外のKubernetesでも動きますか？

動きます。コアはオープンソースで、READMEはkindでの手順を載せており、公式サイトが示す要件はKubernetes 1.37以降です。EKSなどGKE以外向けの専用インストーラーは、2026年11月10日時点の公式ドキュメントには見当たりません。

Agent Substrateの利用料金はかかりますか？

ソフトウェアはApache-2.0で、ライセンス費用はありません。GKEのインストールガイドも追加料金なしと明記しています。課金されるのは、GKEのクラスタとノード、スナップショットを置くCloud Storageなど、作成したリソースの分です。

LangChainやClaude Codeで作ったエージェントを載せられますか？

ate.devは対応例にAgent Development Kit、LangChain、Claude Code、Codex、MCPサーバーなどを挙げています。Agent SubstrateはSDKではなく、OCIコンテナを動かす低レベルのランタイムです。HTTPで要求を受けるコンテナにすれば載りますが、再開後の接続の張り直しと、認証情報をegressから受け取る形への書き換えは必要になります。