--- title: "Agent Substrateとは：AIエージェントをgVisorで隔離しKubernetesで高密度に動かす仕組みと導入手順" url: "https://www.issoh.co.jp/tech/details/19574/" published: 2026-11-10 updated: 2026-11-10 categories: ["インフラ・クラウド"] publisher: "株式会社一創" --- # 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とは？コンテナを隔離するサンドボックスの仕組み](https://www.issoh.co.jp/tech/details/15689/)で扱っています。 ## まとめ｜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の発表](https://opensource.googleblog.com/2026/11/sandboxing-untrusted-ai-agents-at-scale.html)によると、GoogleはKubeCon North Americaの週に、Agent Substrate、gVisor、強化学習向けのOpenRLをCNCFへSandboxの段階で寄贈しました。SandboxはCNCFの成熟度で最初の段階にあたり、業界標準として確定したわけではありません。ソースは[GitHubのagent-substrate/substrate](https://github.com/agent-substrate/substrate)で公開され、ライセンスはApache-2.0です。READMEは1.0に到達したと明記し、API・CLI・設定形式の互換性を保つ方針を示しています。2026年11月10日時点でReleases欄は空で、パッチ版の番号は確認できませんでした。 経緯をたどると、初出は2026年5月21日の[Google Cloudブログ](https://cloud.google.com/blog/products/containers-kubernetes/bringing-you-agent-sandbox-on-gke-and-agent-substrate)で、GKEのAgent Sandboxの一般提供と同時に予告されました。9月16日には[GKEでの提供開始](https://cloud.google.com/blog/products/containers-kubernetes/agent-substrate-available-on-gke)が発表され、本番以外は全GKE利用者が使え、本番向けサポートは許可リスト方式です。 ### 1エージェント1Podの前提が数千規模で行き詰まる3つの理由 通常のKubernetesはエージェント1つにPodを1つ割り当て、待っている間もCPUとメモリの予約を握り続けます。Google Open Source Blogによれば、対話型エージェントの稼働時間の90〜95%は推論・外部API・人のレビューの待ちです。[公式のArchitectureドキュメント](https://github.com/agent-substrate/substrate/blob/main/docs/concepts/architecture.md)は、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](https://github.com/kubernetes-sigs/agent-sandbox)はKubernetes SIGのプロジェクトで、Google Cloudブログは両者を置き換えではなく併用の関係と説明しています。 ## ActorとWorkerを分ける設計と中断中のエージェントへ要求が届く流れ ### ActorとWorkerPoolとActorTemplateの役割と5つの用語の対応 [GKEのAgent Substrate解説ページ](https://docs.cloud.google.com/kubernetes-engine/ai-ml/about-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リクエストが届いたときの順序は次のとおりです。 1. クライアントが`ate-target-actor`ヘッダに`/`を付けて送る 2. Envoyベースのatenet-routerが、制御プレーンのate-api-serverへ`ResumeActor`を依頼 3. ate-api-serverが空きWorkerを確保し、そのノードのateletへ復元を指示 4. ateletがスナップショットをノード上のコピーかオブジェクトストレージから取得 5. ateletがWorker内のateworkerへ`RestoreWorkload`を呼び、サンドボックスを復元 6. ate-api-serverがWorkerのPod IPを返し、Actorが`RUNNING`になる 7. atenet-routerがWorkerのatunnel（8443番）へmTLSのCONNECTトンネルを張る 8. atunnelがリクエストをActorへ転送し、応答が同じ経路で戻る 要求は再開が終わるまでルーターで保留されるので、呼び出し側は相手が中断中かを意識しません。ActorとWorkerの対応はPostgreSQLに保存されます。 ### gVisorとmicroVMの隔離と認証情報を持たせないegressの設計 隔離方式は2種類で、既定はgVisorの`runsc`です。gVisorはメモリとプロセスの表を自前で管理するため、実行中の環境を凍結して別ノードで戻せます。ハードウェア仮想化の境界が必要ならKata ContainersとCloud HypervisorのmicroVMを選び、違いは[Kata Containersとは](https://www.issoh.co.jp/tech/details/15693/)や[Firecracker（マイクロVM）とは](https://www.issoh.co.jp/tech/details/15691/)で比べています。通常のrunc、つまり素のLinuxコンテナでは動きません。スナップショットの保存先はGCSかS3です。 セキュリティは全Actorを互いに敵対しうるものとして扱います。[公式サイトate.dev](https://ate.dev/)によると、Actorは受信も他のPodへの通信も禁じられた状態で起動し、ActorごとにSPIFFE形式の短命な証明書が発行されます。LLMのAPIキーはActorの中に置かず、外向き通信を中継するatenet-egressが許可された宛先にだけ差し込む方式です。乗っ取られても盗める鍵が中にありません。 ## kindのローカル環境でcounterデモを動かし中断と再開を確かめる手順 ### Go・kubectl・Dockerの前提と1,000サンドボックス超で要るカーネル設定 [公式のQuickstart](https://ate.dev/docs/get-started/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](https://github.com/agent-substrate/substrate/blob/main/docs/reference/api-guide.md)の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のインストールガイド](https://docs.cloud.google.com/kubernetes-engine/ai-ml/install-overview-substrate)の主な前提は次のとおりです。 - GKE Standardのみ（Autopilotは対象外） - コントロールプレーンとノードがGKE 1.37以降 - 既存クラスタはDataplane V2が必要 - ノードはc3-standard-4以上（E2は不可） - Cloud Shellは容量不足で使えない 導入は[substrate-gke](https://github.com/ai-on-gke/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による隔離](https://www.issoh.co.jp/tech/details/15689/)だけで足ります。GPUをサンドボックス内で使う処理、WebSocketやDB接続を張り続ける処理も対象外です。Kubernetesの運用経験が無いチームは、[Kubernetesの仕組み](https://www.issoh.co.jp/tech/details/2928/)を押さえるところから始めてください。 ### マネージドのサンドボックスと比べてGKEで自前運用を選ぶ判断基準 クラスタを持たずに隔離環境を借りたいなら、[Cloudflare Containers](https://www.issoh.co.jp/tech/details/18880/)や[Docker Cloud Sandboxes](https://www.issoh.co.jp/tech/details/18257/)のようなマネージド型が早道です。データを自社のVPCの外に出せない、既存のGKEと同じネットワークで社内システムを呼ばせたい、という要件があればAgent Substrateを選びます。 ノードプールやIAMの権限設計を社内で抱えきれないなら、[一創のインフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)で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から受け取る形への書き換えは必要になります。 ### gVisorとmicroVMはどちらを選べばよいですか？ 既定のgVisorから始めます。GKEではコアの部品として入り、ノードの追加条件もありません。カーネル互換性が足りない処理や、ハードウェア仮想化の境界を求める社内基準がある場合だけmicroVMを選びます。microVMにはx86のネステッド仮想化かベアメタルのノードが必要です。 ## 関連記事 - [gVisorとは？コンテナを隔離するサンドボックスの仕組みとrunc・Kata比較・導入判断](https://www.issoh.co.jp/tech/details/15689/)：Agent Substrateの既定の隔離ランタイム - [Kata Containersとは？軽量VMで隔離するセキュアコンテナの仕組みとgVisor・runc比較・導入判断](https://www.issoh.co.jp/tech/details/15693/)：microVM方式を支える仕組み - [Firecracker（マイクロVM）とは？仕組み・KVMとの関係とgVisor・コンテナとの使い分けを実装者目線で解説](https://www.issoh.co.jp/tech/details/15691/)：マイクロVMの隔離と性能の比較 - [Cloudflare Containersとは？AIエージェントのサンドボックスを動かす手順と料金【2026年10月時点】](https://www.issoh.co.jp/tech/details/18880/)：マネージドで借りるエージェントのサンドボックス - [Docker Cloud Sandboxesとは？sbxでAIエージェントを隔離実行する手順・料金とローカル版の違い【2026年11月時点】](https://www.issoh.co.jp/tech/details/18257/)：Docker製のエージェント向け隔離環境 --- 出典: [Agent Substrateとは：AIエージェントをgVisorで隔離しKubernetesで高密度に動かす仕組みと導入手順]()（株式会社一創）