AIエージェントをKubernetesで10倍動かせる基盤をGoogleが公開

AIエージェントを何体も同時に動かそうとして、Kubernetesのサーバーがすぐに手一杯になった経験はないだろうか。1体のエージェントに実行環境を1つずつ割り当てると、エージェントがAIの返事や人間の承認を待っているだけの時間も、その環境は専有されたままになる。

Googleは2026年11月5日、この無駄を解消する基盤「Agent Substrate」を発表した。あわせて、コンテナを安全に隔離する技術「gVisor」もオープンソース化した。両方を業界団体CNCF(Cloud Native Computing Foundation)へ寄贈したと公式ブログで明らかにした。

Google自身の計測では、この基盤を使うと同じサーバーで最大10倍の数のエージェントを待機させられるという。しかも特定のクラウドに縛られず、手持ちのKubernetesクラスタにそのまま持ち込める。なぜそんなに数を増やせるのか、そして自分のクラスタでも同じことができるのか。仕組みから見ていく。

AIエージェントは待ち時間が9割

そもそも、なぜAIエージェントはKubernetesの上でこんなに「場所を取る」のか。Googleの説明では、AIエージェントはモデルの推論結果や外部APIの応答、人間の承認を待つ時間が全体の90〜95%を占めるという。それにもかかわらず、1エージェントに1つの実行環境(Pod)を割り当てる素朴な構成では、待っている間もメモリとCPUを確保したままになる。

待機中だけPodを止めてしまうサーバーレス的な方法もあるが、これだと再開のたびにコールドスタートが発生し、対話のテンポが崩れる。Kubernetesはもともと「常に動いているサービス」を効率よく配置するために設計された仕組みだ。そこに「ほとんど待っているだけの存在」を大量に詰め込もうとすると、無理が出る。自分はここで、オーケストレーターの前提とAIエージェントの実態がそもそも噛み合っていなかったのだと腑に落ちた。この板挟みを、Googleはどう崩したのか。

待機中は預けて実行枠を空ける

Agent Substrateは、エージェントがAIの返事を待っている間、その状態を保存して実行環境を手放す仕組みだ。会話の途中経過やメモリ、固有のIDをひとまとめにした単位を「Actor」と呼び、Actorを受け取って実際に動かす実行枠を「Worker」と呼ぶ。Actorが待機に入ると、Worker上のメモリやファイルの状態は高速なストレージへスナップショットとして保存される。Workerは手放され、別のActorに回される。次に動く必要が出たら、空いているWorkerへ状態を読み込み直して再開する。Googleはこの動きを「家を持つのではなく、ホテルの部屋を使う」ことに例えている。

三つの方式を並べると、違いがはっきりする。

表が示すとおり、サーバーレスは資源を解放できてもコールドスタートが残り、Agent Substrateは資源の解放と高速な再開を両立させている点が違う。もう一つ、Actorごとの身元を見てアクセス権限を割り振り、必要な認証情報だけを渡す「Gateway」という要素もある。エージェントの実行環境に機密鍵を置きっぱなしにしない役割を担う。では、実際にどれくらいの速さで「預けて、呼び戻す」のか。その数字が、冒頭の「10倍」を支えている。

なぜ「10倍」の密度が出せるのか

Googleの公式発表によれば、Agent Substrateは1秒間に500回以上のペースでActorの預け入れと呼び戻しをこなす。復元にかかる時間は500ミリ秒に満たないという。数百万のサンドボックスを本番環境で扱えるとも説明している。待っている間は場所を取らず、動くときだけ瞬時に戻ってくる。この速さがあるから、Workerの台数を増やさなくても、同じ台数でこなせるActorの数が増える。

「10倍」が指しているのは処理の速さではなく、同じサーバーに待たせておけるエージェントの数のことだ。ただし、この数値はGoogle自身が公表したもので、比較したコンテナランタイムの種類やベンチマークの環境は公式発表に書かれていない。

エージェントが実行するコードは、人間がレビューしていない生成コードのこともある。その実行を安全に隔離するのが「gVisor」だ。Goで書かれた軽量なユーザー空間カーネルで、コンテナとホストOSの間でシステムコールを処理する。信頼されていないコードがホストのLinuxカーネルに直接触れないようにする仕組みだ。

2018年にGoogleがオープンソース化し、GKE SandboxとCloud Runの基盤として日々数百万のサンドボックスを動かしている。Anthropic・OpenAI・Modal・Snowflakeなどが利用している。Agent Substrateでは、この隔離境界としてgVisorか、より重い「Cloud Hypervisor microVM」かを選べる。ここまでの仕組みはすべてGoogleが開発したものだが、Google1社の持ち物のままでは、使う側はGoogleの方針に左右され続ける。その不安を、Googleはどう解消したのか。

特定のクラウドに縛られなくなった理由

Googleは2026年11月5日付けで、Agent SubstrateとgVisorをCNCFへ寄贈したと発表している。あわせて、強化学習の後段学習に使う「OpenRL」も同時に寄贈した。中立団体の管理下に置くことで、ロードマップがGoogle1社の判断だけで決まらなくなる。公式ブログは、単一ベンダーの所有物のままではLinuxカーネル本体へのパッチ取り込みが進みにくかった、と寄贈の動機を明かしている。

gVisor側の公式ブログでも、この移管の経緯が語られている。CNCF Sandboxへの申請は2026年9月7日に提出し、9月28日に受理され、10月2日に発表した。寄贈したのはGoogleで、短期的にはメンテナ制のガバナンスへ移り、Google以外のメンテナも参加する。それでも既存の利用者への影響は「Not much(大したことはない)」と明記している。長期的なメンテナとしてAnt Group・Modal・Tinesが参加を表明し、OpenAI・Tencent・NVIDIAも貢献を続けるという。

寄贈によって、読者にとっては次が変わる。

• Agent SubstrateとgVisorはOSSとして公開され、手持ちのKubernetesクラスタへそのまま導入できる。特定のクラウドの契約は要らない
• Google Cloudを使っているなら、GKE上でマネージド版「Agent Substrate on GKE」が一般提供(GA)になっており、クラスタ構築の手間なく試せる
• gVisorはAnthropic・OpenAI・Modal・Snowflakeなどが既に採用している実績のある隔離技術で、寄贈後も開発が止まる心配は少ない

まとめ

Agent Substrateは、待機中のAIエージェントの状態をスナップショットとして預け、実行枠を他のエージェントに使い回す基盤だ。この仕組みにより、Google公表値で従来比10倍の密度でエージェントを動かせるという。gVisor・OpenRLとともにCNCFへ寄贈されたことで、特定のクラウドに縛られず、誰でも自分のKubernetesクラスタに導入できるようになった。Kubernetesクラスタが手元にあるならOSS版を、Google Cloudを使っているならGKEのマネージド版を、それぞれ今日から試せる。