Agent Substrateとは？多数のAIエージェントを低遅延で動かす基盤

Agent Substrateとは？多数のAIエージェントを低遅延で動かす基盤

まず「判断するAI」「ツールを動かす作業場所」「作業場所を管理する基盤」の三つに分けると、Kubernetesやサンドボックスとの関係を整理できます。

Agent Substrateの役割とKubernetesとの関係

Agent Substrateを理解する鍵は、一つのエージェントの賢さではなく、多数の作業環境をどう動かすかにあります。コードを修正するエージェントなら、LLMが修正方針を考え、実行環境がファイルの編集やテストを行い、その環境の準備や寿命を基盤が管理します。

LLMは、文章やコードなどを生成する大規模言語モデルです。LLMが「テストを実行する」と判断しても、実際にプログラムを動かすにはCPU、メモリ、ファイルを置く場所が必要です。ランタイムとは、こうしたプログラムの実行を支える環境や仕組みを指します。モデルへの問い合わせとツールの実行は、別の場所で処理されることもあります。

Kubernetesは、アプリケーションをまとめたコンテナを複数の計算機へ配置し、稼働状態などを管理する仕組みです。GKE（Google Kubernetes Engine）は、Google Cloudが提供するKubernetesのマネージドサービスです。多数の環境を支える土台になりますが、利用者ごとの作業状態や待機後の再開方法まで、Kubernetesという名前だけで決まるわけではありません。

その上で、エージェント向けの基盤には、短時間に増減する実行環境や、作業途中で長く待つ環境を扱う工夫が求められます。Agent Substrateは、このような環境群の運用という観点で位置づけられます。アプリケーション側には、実行するツール、権限、完了条件を定める役割が残ります。

関連する公式発表には、Google Cloudによる2026年5月20日の紹介と、同年9月15日のGKE向け提供発表があります。紹介時の構想と提供時の仕様は分けて読み、利用できる構成や機能を判断するときは、対象時点の提供条件を確認する必要があります。

多数のエージェントで待機と隔離が課題になる理由

エージェントの処理は、常にCPUを使い続けるとは限りません。LLMの応答、外部APIからの情報、人による修正案の承認などを待つ間、作業用のプロセスは動いていても、計算はほとんど進んでいないことがあります。

それでも、環境を起動したまま保持すれば、メモリやファイル、接続情報などが残ります。CPUの予約量も、実際の使用率が低いだけでは減らない場合があります。こうした環境が多数になると、個々のタスクは軽くても、環境群全体の資源負担は大きくなります。

ここでいうfleet-scale computeは、多数の実行環境を一つの群として管理する計算基盤という意味で捉えられます。単一のテストを速く終わらせる能力と、大量の環境を作成・待機・再開させる能力は別です。個別の起動が速くても、再開要求が集中して待ち行列が伸びれば、利用者の待ち時間は増えます。

待機中の環境をどう扱うかは、主に次の三つで比較できます。これは一般的な運用方式の整理であり、個々の製品がすべての方式を備えることを示すものではありません。

同時に、利用者やタスクごとの隔離も必要です。別の利用者のファイルが見えたり、一つのテストが他の作業を壊したりしては困ります。環境を細かく分けるほど管理対象が増えるため、隔離の強さと、一台の計算機へ安全に収容できる環境数を合わせて考えることになります。

休止・再開とデータプレーンで実行を支える仕組み

休止・再開（suspend/resume）の目的は、待機中の資源負担を減らしながら、必要な作業状態を使って処理を続けられるようにすることです。一般的な流れは「準備→実行→待機→休止→再開→終了」です。ただし、アプリケーションが待っている状態と、基盤が環境を休止した状態は異なります。

たとえば、プログラムが承認を待つループに入っても、それだけで基盤の資源が解放されるわけではありません。休止には、どの時点なら止められるかを判断し、実行を止め、必要な状態を保持する仕組みが必要です。承認を受け取って再開を指示する役割は、休止する作業環境の外側に置く設計が考えられます。

保存対象は分けて考えましょう。プロセスとメモリが保存されるなら、計算途中の変数などを引き継げる可能性があります。ファイルだけが残る方式なら、プログラムを起動し直して保存済みの結果を読み込む設計になります。ファイルについても、一時領域と永続領域では寿命が異なります。Agent Substrateでの具体的な保存・復元範囲は、これらの一般論から推定せず、利用する構成の仕様で確認する項目です。

外部サービスとの関係は、環境内の状態とは別です。メモリを復元できても、相手側が接続を閉じていたり、認証トークンが期限切れになっていたりする場合があります。再開後には接続を張り直し、必要に応じて認証を更新できるようにします。環境の再開に成功したことと、途中の業務処理を安全に続けられることを分ける必要があります。

この管理を考える際に登場するのが、コントロールプレーンとデータプレーンです。前者は、環境の作成や終了などを指示・調整する管理側の仕組みです。後者は、実際の処理を担う側の仕組みです。一般に、管理要求を受け付ける速さだけでなく、実行先の確保や状態の復元が詰まらないことが、環境群の応答性を左右します。製品固有の配置経路や再開経路は、この一般的な区分だけでは決まりません。

再開を速くして短縮できるのは、主に作業環境を使えるようにするまでの待ち時間です。LLMの文章生成や外部APIの応答が自動的に速くなるわけではありません。また、休止によってCPUの使用を減らせても、保持するメモリ、保存領域、基盤側の費用までゼロになるとは限りません。

Agent Sandbox・gVisor・microVMとの違い

これらの用語は、同じエージェントの実行環境に関係していても、扱う階層が異なります。環境を管理する仕組みと、環境の内外を隔離する方式を分けると、比較の軸が明確になります。

サンドボックスは、プログラムが影響を及ぼせる範囲を制限した実行環境です。Agent Sandboxでは、その環境をKubernetesから作成・管理する役割に注目します。一方、Agent Substrateでは、多数の環境を実際に動かす基盤としての役割が中心です。両者を同義語や単純な代替品として扱わず、どの仕組みが作成要求を受け、どこが実行を担うかを確認すると理解しやすくなります。

gVisorのユーザー空間カーネルは、アプリケーションが利用するOSの機能を仲介します。microVMは、小さな構成に絞った仮想マシンを使う考え方です。隔離の境界が異なるため、アプリケーションとの互換性、起動時間、メモリ使用量など、評価する点も変わります。どちらも名称だけで安全性や性能の優劣が決まるものではありません。

この整理は役割の比較です。gVisorとmicroVMが同じ技術であることや、Agent Substrateで常に両方を使うことを意味しません。特定の構成で利用できる隔離方式と、休止・再開の対応範囲は、それぞれ確認する必要があります。

調査やコード修正を並列に進める利用例

用途を考えるため、複数のリポジトリの依存ライブラリを更新する、架空の開発支援システムを例にします。これは運用設計の説明であり、特定企業の導入実績や性能測定ではありません。

まず、リポジトリごとに作業環境を準備し、対象コードと必要な依存関係を用意します。次に、エージェントが変更内容を判断してファイルを修正し、テストを実行します。タスクごとにファイルの置き場所や権限を分けておけば、ある修正で生じた問題を、他の作業環境へ広げにくくできます。

テストが通った環境から、人による確認を待つ状態に移ります。この間も別の環境はテストを続けるため、群全体には実行中と待機中の環境が混在します。保存・復元の条件が合う環境を休止対象にできれば、途中の作業を引き継ぎつつ待機資源を減らす余地が生まれます。

承認後は対象の環境を再開し、必要な接続を回復してから追加確認や成果物の出力を行います。最後に、変更差分、テスト結果、実行記録を回収し、環境を終了します。成果物を環境の外へ保存しておくことで、作業環境の削除後も結果を確認できます。

同じ考え方は、複数の調査タスクやブラウザー操作にも当てはまります。調査では外部情報の取得待ちが生じ、ブラウザー操作では画面遷移や利用者の確認を待つことがあります。ただし、ブラウザー内の状態が戻っても、ログイン先のセッションが有効とは限らない点は考慮が必要です。

適性を見る軸は、同時に保持する環境数、待機時間の割合、引き継ぎたい状態の量です。計算を連続して行う処理では休止の機会が少なく、少数の短い単発処理では環境を作り直す方が単純な場合もあります。待機が多く、再準備の手間が大きい処理ほど、環境群の管理方法を見直す意味があります。

導入前に確かめたい性能・安全性・運用条件

導入判断では、起動の速さだけでなく、実際の作業を無理なく運用できるかを確かめます。最初の評価では、通常の負荷と、承認や外部応答が重なって再開要求が集中する負荷を用意すると、環境群としての違いを捉えやすくなります。

公式の性能値は、ベンダーが特定条件で測定した発表値として読みます。測定対象が新規起動か再開か、要求受付から計った時間か、処理を実行できるまでの時間かで意味が変わります。負荷、計算機の構成、保存状態の大きさ、同時実行数、比較対象が不明な数字を、そのまま自分の環境へ当てはめることはできません。

平均値だけでは、遅い要求を見落とします。たとえば95パーセンタイルは、要求の95％がその時間以内に収まるという指標です。再開遅延の平均と遅い側の値、失敗率を合わせて記録し、CPU、メモリ、保存領域の使用量も比べましょう。待機資源を削減できても、復元処理や運用の手間が増える可能性があるためです。

安全性では、実行環境の隔離と、外部サービスで許される操作を別々に設計します。隔離された環境でも、強い権限の認証情報を渡せば、外部のデータを削除したり変更したりできます。タスクに必要な最小限の権限を与え、秘密情報の渡し方、アクセスできる通信先、公開や削除などの操作に必要な承認を定めます。

状態の寿命も管理対象です。保存するファイルやメモリに秘密情報が含まれる可能性を考え、保存先へのアクセス、保持期間、終了後の削除を決めます。承認が来ない環境にはタイムアウトを設け、長期間残り続けることを防ぎます。休止する直前の状態が、必ず業務上の安全な区切りになるとは限りません。

失敗時の再試行では、二重実行に注意します。たとえば外部への登録は成功したのに、結果を記録する前に環境が停止すると、再開後に同じ登録を繰り返すおそれがあります。処理済みの記録や操作ごとの識別子を使い、同じ要求が複数回来ても結果を重複させない設計にします。ログにはタスクと環境の識別子を含め、休止前後の処理を追跡できるようにします。

2026年10月22日時点の記事としても、提供段階、対応環境、利用制限、料金を固定的な条件とは扱えません。採用時点の公式情報で利用可能な範囲を確認し、自分の負荷で再開遅延、失敗率、資源使用量、運用負担を評価することが必要です。Agent Substrateの価値は、多数の隔離環境が待機と実行を繰り返す仕事で、状態の引き継ぎと資源効率を両立できるかにあります。

更新履歴