GKE Agent Sandboxがエージェント1台あたりのコストを75%削減する仕組み
AIエージェントを本番環境でスケールさせようとすると、すぐにコストとリソースの壁にぶつかる。Google Cloudが2026年7月30日に公開したブログ記事では、Google Kubernetes Engine（GKE）の新機能「GKE Agent Sandbox」とオーケストレーションを組み合わせることで、同一の仮想マシン上で動かせるエージェント数を最大3.5倍に増やし、エージェント1台あたりのコストを最大75%削減できるという検証結果が示された。
エージェントは要求に応じて動作するバースト型のワークロードであり、何もしない待機時間が長い。従来のように固定的なコンピュートリソースを割り当てる方法では、遊休状態のエージェントが貴重なCPUやメモリを消費し続けてしまう。この問題に対するGKEのアプローチを詳しく見ていく。
マイクロVM方式の限界とGKE Agent Sandboxの登場
マルチエージェントを安全に動かすための一般的な方法として、各エージェントを専用のマイクロVM（Kata Containersなど）で隔離するやり方がある。ハードウェアレベルの隔離によってセキュリティを確保する狙いだ。しかしこの方式には大きな落とし穴がある。
マイクロVMはエージェントごとにゲストOSを起動するため、メモリとCPUに無視できないオーバーヘッドが生じる。実際にGoogle CloudのチームがOpenClawプロファイルを使い、48vCPUの標準VMインスタンス（n2-standard-48）上でテストしたところ、61個のエージェントを起動した時点で信頼性が低下し、ヘルスチェックの失敗が頻発し始めたという。
これに対してGKE Agent Sandboxは、gVisorというオープンソースのセキュアコンテナサンドボックスを土台にしている。gVisorはユーザー空間カーネル（Sentry）でシステムコールを捕捉・フィルタリングし、ハードウェア隔離に近いセキュリティを実現しつつ、ゲストOSを丸ごと動かす必要をなくした。
結果として、同一VM上で動作可能なエージェント数は88個まで増加。これはベースライン比で44%の密度向上であり、エージェント1台あたりのコストは30%以上削減された計算になる。しかも性能プロファイルはほぼ維持できると報告されている。
この方式が評価を得たのは早く、2026年5月の一般提供開始から4週間足らずで利用量が7倍以上に急増した事実が、その実用性を裏付けている。
遊休エージェントを「凍結」するオーケストレーションの威力
GKE Agent Sandboxは稼働中のワークロードを効率化するが、遊休状態のエージェントがリソースを占有し続ける問題は残る。そこでカギを握るのが、Kubernetes本来のオーケストレーション機能とGKE Podスナップショットを組み合わせた「凍結・再開」パターンだ。
具体的には、エージェントが待機状態に入ったタイミングでPodスナップショットを作成し、永続ストレージにチェックポイント（凍結）として保存する。これにより物理的なCPUとメモリが解放され、クラスタに返却される。新しいトリガーが届くと、軽量なコントローラやイベントゲートウェイがリクエストを捕捉し、ミリ秒単位でスナップショットからエージェントを再開する。
この仕組みによって、物理リソースをワークロードの実態に基づいて「オーバーサブスクライブ（超過割り当て）」できるようになる。つまり、実際の瞬間的な需要以上のエージェントを同じノードに詰め込めるわけだ。その結果、間欠的にしか動かないエージェントであれば、ベースラインの3.5倍にあたる274個のエージェントを単一ノードで動作させることが可能になった。
ただし、やみくもに詰め込めばよいわけではない。エージェントの種類によって求められる起動時間やレイテンシは大きく異なるからだ。
エージェントの特性に合わせた3つのデプロイ戦略
GKEでは、すべてのエージェントに一律の戦略を強制するのではなく、ノードプールやワークロード設定ごとに異なる挙動を共存させられる。Google Cloudのブログでは、レイテンシ要件に応じた3つの典型例が紹介されている。
リアルタイムコーディングアシスタント（レイテンシ重視）
開発者向けの対話型エージェントでは、起動時間が1秒未満であることと、待ち行列が一切発生しないことが絶対条件だ。このケースでは、GKE Podスナップショットと「Agent Sandboxウォームプール」を組み合わせる。事前にウォームアップされた隔離サンドボックスを常時待機させておくことで、ほぼ瞬時に実行を開始できる。この構成で同一ノード上に133個のエージェントを収容できたと報告されている。
自律的なチームメイト型エージェント（バランス型）
バックグラウンドで対話的に動くエージェントは、平均的な起動時間（数秒）を許容できる。サスペンド＆レジューム機能を利用し、遊休時にはリソースを解放、必要時にオンデマンドで復元する。待機中のコンピュートコストを支払う必要はない。
ヘッドレスなバックグラウンドエージェント（レイテンシ許容型）
日次レポートの生成や調査タスクのような定期ジョブは、多少の待ち時間があってもビジネス成果に支障をきたさない。こうしたエージェントには最大限のリソース超過割り当てを適用し、クラスタに空きが出るまで1時間ほど待つ戦略も有効だ。
このように、ワークロードの性質に合わせて「パフォーマンス最適化」と「コスト最適化」のバランスをチューニングできるのがGKEの強みだ。サンダリングハード（多数のエージェントが一斉に起動してコンピュートを要求する問題）に対しても、ウォームプールやサスペンド＆レジュームの設定で自由度の高い制御が可能になる。
コスト削減を実現するための実践的なアプローチ
GKE Agent Sandboxとオーケストレーションの組み合わせによって、エージェントの台数に比例してインフラ予算が増えていく構図を抜本的に変えられる。Google Cloudの検証では、パフォーマンスを重視する構成でも133個のエージェント（ベースライン比約2.2倍）、コスト最適化を突き詰めた構成では274個（同3.5倍）のエージェントを同一ノードで動作させることに成功した。
実務に落とし込む際のポイントは3つある。第一に、セキュリティを保ったままオーバーヘッドを削減するGKE Agent Sandboxへの移行を検討すること。第二に、Podスナップショットによる「凍結・再開」をアーキテクチャに組み込み、遊休リソースを徹底的に活用すること。第三に、すべてのエージェントを同じ扱いにせず、レイテンシ要件に応じてデプロイ設定を変えることだ。
なお、GKE Agent Sandboxの詳細な設定やウォームプール、サスペンド＆レジュームの具体的な手順は、Google Cloudの公式ドキュメントで公開されている。まずは既存のエージェントワークロードを対象に、小規模なPoCから始めてみるとよいだろう。
この記事のポイント
- GKE Agent SandboxはgVisorベースの軽量サンドボックスで、マイクロVMに比べてエージェント密度を44%向上させ、1台あたりのコストを30%以上削減する
- Podスナップショットとサスペンド＆レジュームの組み合わせにより、遊休エージェントを凍結して物理リソースを解放し、理論上3.5倍の密度（最大75%のコスト削減）を達成可能
- ワークロードのレイテンシ要件に応じて「リアルタイム型」「バランス型」「コスト最適化型」の3戦略を使い分けることで、無理なくスケールできる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GKE Agent Sandboxが一般提供開始。エージェント向け基盤Agent Substrateも発表
Google Cloudが2026年5月20日、エージェント実行環境「GKE Agent Sandbox」の一般提供（GA）を開始した。合わせて、超大量エージェントの高密度実行を目指す新たなOSSプロジェクト「Agent Substrate」を発表している。
2025年11月のKubeCon NAでプレビューが公開されて以降、Agent Sandbox上のサンドボックス数は5か月足らずで16倍以上に成長した。LangchainやLovableといった顧客がすでに数百万単位のエージェントを本番環境で動作させている。
自律的にコードを実行するAIエージェントにとって、インフラの安全性と起動速度は実用化の鍵となる。今回のGAで安定版APIが提供され、エージェント実行基盤としての成熟度が一段と上がった。
GKE Agent Sandbox GAの主要な機能強化点
GKE Agent SandboxはKubernetes上に構築されたOSSの実行環境だ。AIエージェントが信頼できないコードを安全かつ高速に実行するための基盤として設計されている。今回のGAでは、実運用で課題となるアイドル状態の効率化と、起動レイテンシの低減に焦点が当てられた。
Pod Snapshotによるアイドルリソースの削減
エージェントのワークロードは、短いバースト的な処理の後に長いアイドル時間が続くという特徴を持つ。従来のようにアイドル中もPodを起動したままにしておくと、コンピュートリソースを無駄に消費してしまう。
GKE Agent SandboxはPod Snapshot機能と統合されている。アイドル状態のエージェントワークロードを一時停止（サスペンド）し、リクエストが来たときに数秒で再開できる。Google Cloudの発表によれば、この仕組みで不要なコンピュートコストを大幅に削減できるという。
Pod Snapshotの最大の利点は、エージェントワークロード特有の「使うときだけ高速に起動したい」という要求に応えられる点だ。サスペンド状態からの復帰は数秒で完了するため、ユーザーの待ち時間を最小限に抑えられる。
ウォームプールによる低レイテンシプロビジョニング
エージェントのリクエストが来るたびに新しいサンドボックスを作成すると、コールドスタートによる数秒の遅延が発生する。この遅延はエージェントの応答性を損ない、ユーザー体験を悪化させる要因となる。
GKE Agent Sandboxは、サンドボックスAPIにウォームプールを統合した。あらかじめ準備されたサンドボックスレプリカをプールしておき、リクエスト発生時に即座に割り当てる仕組みだ。これにより、1クラスタあたり毎秒300のサンドボックスを割り当て可能で、割り当ての90パーセントが200ミリ秒以内に完了する。
ウォームプールのコスト最適化も考慮されている。プール内のレプリカは常時稼働しているが、スタンバイキャパシティバッファと統合することで、一部のサンドボックスをサスペンド状態で待機させられる。ウォームプールが枯渇した際には、この「コールドプール」から素早く補充され、大幅なコスト削減につながる。
gVisorとネットワークポリシーによる強固な隔離
セキュリティ面では、gVisorをネイティブサポートし、デフォルト拒否のKubernetesネットワークポリシーを採用している。gVisorはユーザースペースで動作するカーネルであり、ホストOSから隔離された環境を提供する。コンテナ内のプロセスがホストカーネルに直接アクセスできないため、悪意あるコード実行のリスクを大幅に低減できる。
さらにKata ContainersのようなOSSサンドボックスにも対応するプラグイン可能なインターフェースを備えている。利用者は自社のセキュリティ要件に合わせてカーネル隔離レベルを選択できる。
コンピュートの選択肢も広がった。Google Cloud独自のAxionプロセッサ上でAgent Sandboxを実行すると、同等のハイパースケーラークラウドプロバイダと比較して最大30パーセント優れた価格性能比を達成すると発表されている。
Agent Substrateがもたらす次の変革
エージェントワークロードは今後、数千万から数億インスタンス規模へとスケールアップしていく。同時に、人間の操作やイベントを待つアイドル時間もますます長くなる。カーネルとネットワークの隔離を維持しながら高密度にスケジュールするのは、既存のKubernetesコントロールプレーンでは限界が近づいている。
この課題に対してGoogle Cloudが発表したのが、新たなOSSプロジェクト「Agent Substrate」だ。
Kubernetesの限界を超える最小限のコントロールプレーン
Agent Substrateは、Agent Sandboxの安全なランタイムとSnapshot機能を中核に据えつつ、Kubernetesの制約を部分的に回避する最小限のコントロールプレーンを組み合わせる。標準のKubernetesが数千の長時間稼働サービスを扱うのに最適化されているのに対し、Agent Substrateは数百万単位のサブ秒ツール呼び出しの「チャタリング」に耐えられるよう設計されている。
新たな抽象化レイヤーを導入し、Kubernetes上で稼働するコンピュートキャパシティに対して、エージェントをリアルタイムに乗せたり外したりする。Google Cloudの発表では、従来のコントロールプレーンでは処理しきれない高頻度の短命ワークロードに対して、レイテンシを低減しつつスケールと効率を最適化できるとしている。
Agent Substrateの目標は、現在のコンピュートインフラの限界を押し広げることにある。一例として、エージェントの状態とスケジューリングが協調して動作するようデータの局所性をスケジューラの中核に組み込む構想も示された。オーバーヘッドを1ミリ秒単位で削り取るため、あらゆる可能性を探求する姿勢が打ち出されている。
Agent HarnessやAgent Executorとの関係
Agent Substrateは、単独で動作するものではなく、エージェントエコシステム全体の基盤レイヤーとして位置づけられている。Agent HarnessやAgent Runtime、さらにはGoogle Cloudが別途発表している分散エージェントランタイム「Agent Executor」プロジェクトを支える役割を担う。
Google Cloudのブログ記事では、Agent Substrateを「エージェントネイティブなインフラストラクチャの次の章」と表現している。Kubernetesが登場初期に多様なコントリビューターの知見を集めて成功したように、エージェントインフラも同じ転換点にあるという認識が示された。
この記事のポイント
- GKE Agent Sandboxが一般提供開始。安定版APIでエージェント実行の本番運用に対応
- Pod Snapshotでアイドル時のリソース消費を抑え、リクエスト時に数秒で復元可能
- ウォームプールにより毎秒300サンドボックスをサブ秒で割り当て。コスト最適化も統合
- 新OSSプロジェクトAgent Substrateは数百万規模の短命ワークロードに特化した設計
- Axionプロセッサ利用時に最大30パーセントの価格性能比向上を達成
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験