AIエージェントに資料作成や開発作業を任せると、モデルとの対話だけでは処理が完結しません。エージェントはシェルコマンドを実行し、ファイルを書き換え、ブラウザで外部サービスへアクセスします。便利になるほど、誤った命令やプロンプトインジェクションによって、認証情報や社内データが持ち出される危険も増えます。Google CloudがAGNTConとMCPConで発表した「Agent Compute Engine」は、この実行環境をAIエージェント専用に設計したコンピュートサービスです。

中心となる考え方は、エージェントのセッションごとに、ハードウェアレベルで隔離されたmicroVMを1台割り当てることです。各microVMは独自のゲストカーネル、root権限、Hyperdiskを備えます。Google Cloudは、仮想マシンに近い隔離強度を確保しながら、コンテナのような起動速度と収容密度を目指しています。



この基盤は、業務を実行するエージェントとしてのGeminiにすでに利用されています。Googleが挙げるAntigravityのほか、社内の評価処理や強化学習パイプラインも稼働対象です。一般企業向けには、今後数カ月以内のカスタマープレビューが予定されています。

ただし、提供開始日、料金、起動時間、1台のホストに収容できるセッション数は明らかにされていません。現段階で注目すべきなのは性能値より、エージェントを信用せずに動かすことを前提とした設計です。企業が生成AIを試験導入から実運用へ進める際、モデルの精度だけでなく、ツール実行環境そのものを統制対象として扱う流れが鮮明になっています。

Agent Compute Engineでは、エージェントを「ハーネス」と「サンドボックス」の2つに分けます。ハーネスはモデルを呼び出し、次に何をするかを決める「頭脳」に相当します。サンドボックスは、生成された指示に従ってコード、シェル、ブラウザなどを操作する「手」の役割を担います。ハーネスはサンドボックスの外側で動き、必要なコマンドだけを明示的に送る構造です。

一般的なコンテナでは、複数の実行環境がホスト側のカーネルを共有します。microVMはセッションごとにゲストカーネルを持ち、Cloud Hypervisorの境界で他のセッションやホストから切り離されます。コンテナより構成要素は増えますが、エージェントがroot権限を使う場合でも、影響範囲を専用の仮想環境内に閉じ込めやすくなります。



ホストはGoogleが管理し、TitanシリコンとTitanium IPUを利用します。ホスト自体は状態を保持しないアプライアンスとして構成され、ルートファイルシステムは読み取り専用です。改ざん検知にはdm-verityが使われ、環境の正当性を証明するアテステーション鍵はゲストの外にあるTitanium側で保持されます。

ここで大切なのは、サンドボックス内のエージェントを安全な主体とは見なしていない点です。モデルが不正な入力に影響され、内部を完全に操作された状況まで想定されています。隔離境界の目的は、エージェントが常に正しく振る舞うと保証することではありません。誤動作や侵害が起きても、ホスト、別のセッション、認証基盤へ被害を広げにくくすることです。この発想が、通常のアプリケーション実行基盤とエージェント専用基盤を分ける理由になっています。

Agent Compute Engineの特徴が最も表れるのは、microVMから外部サービスへ接続する経路です。各microVMには標準的なネットワークインターフェースがなく、デフォルトゲートウェイも設定されません。VPCへ直接接続する経路も持たないため、サンドボックスを奪われた攻撃者が、そのまま社内ネットワークを探索する構成にはなっていません。

通信はvirtio-vsockの境界を通ってホスト上のローカルプロキシへ渡り、そこから外部のゲートウェイへ送られます。サンドボックスに与えられるのは、セッション単位の短命なSPIFFE証明書と一時的なアイデンティティトークンだけです。SPIFFEは、分散環境にあるワークロードを識別するための仕組みで、この証明書は「どのサンドボックスから通信が来たか」を示します。



バックエンドAPIの実際の認証情報は、サンドボックスに保存されません。Agent Gatewayが通信内容とポリシーを確認したうえで、外部へ出る途中に必要な認証情報を差し込みます。エージェントから見れば許可されたAPIを呼び出せますが、そのAPIキーやアクセストークンを読み出して別の場所へ送ることは難しくなります。

従来の実装では、環境変数や設定ファイルを通じてAPIキーを実行環境へ渡すことがあります。この方法は単純ですが、プロンプトインジェクションでエージェントにファイルや環境変数を調べさせると、秘密情報が応答や外部通信へ混入しかねません。Agent Compute Engineは、侵入されたサンドボックスには盗める長期認証情報がない状態を作ろうとしています。

もっとも、秘密情報を置かないだけで全てのリスクが消えるわけではありません。許可済みAPIを不適切に操作される可能性は残るため、ゲートウェイ側の権限範囲、通信先、操作内容を絞る必要があります。安全性を左右するのはmicroVMの壁だけではなく、壁の外に設ける認可ポリシーでもあります。

Google Cloudは、1つのエージェント処理に関係するアイデンティティを4種類に分けています。利用者、利用者から委任された権限、実行中のワークロード、エージェント自身を同じアカウントとして扱わない設計です。誰が依頼したのか、何を任されたのか、どの環境が通信したのか、エージェント固有の資産は何かを別々に追跡できます。

「ユーザーアイデンティティ」はタスク全体を開始した利用者を認証します。ただし、利用者本人の権限をそのままサンドボックスへ渡すものではありません。「代理実行アイデンティティ」は、利用者に代わって処理できる範囲を示す委任情報です。この権限は中央の認可サービスに保存され、実行ノードには配置されません。



「Agent Workload Identity」は、個々のサンドボックスを識別する短命なSPIFFEアイデンティティです。サンドボックスから出る通信で直接使われるのはこれだけですが、流出してもバックエンドAPIを直接呼ぶための認証情報にはなりません。ゲートウェイが通信元を確認し、中央側にある委任情報と照合するための識別子として機能します。

「Agent Workforce Identity」は、エージェント自身のアカウントと、そのエージェントが所有するリソースを表します。人間の利用者の代理として動く場面と、エージェント固有の立場で動く場面を区別できるため、監査ログを確認する際にも責任の所在を整理しやすくなります。

企業システムへの適用では、4種類の名前を覚えることより、1つの強力な資格情報を全処理で使い回さない考え方が参考になります。人、委任、実行環境、エージェントを分離すれば、あるセッションが侵害された際に無効化すべき権限を限定できます。アクセス記録も、単に「AIが操作した」と残すのではなく、依頼者と実行セッションを結び付けて検証できるでしょう。

AIエージェントは、処理時間の全てを計算に使うわけではありません。モデルの応答や利用者の確認を待つ間、サンドボックス側では実行する作業がなくなります。Googleの開発チームは、この待機時間を前提に、ツール呼び出しが終わるとサンドボックスからホストへ合図を送り、microVMをチェックポイントへ退避させる方式を採用しました。

退避後のmicroVMは、アクティブなCPUやメモリ資源を消費しない状態になります。次のツール呼び出しが届くと、保存したスナップショットから処理を再開します。「ゼロアクティブリソース」は、作業データまで消えるという意味ではありません。実行状態を保管領域へ移し、動いていないセッションのために計算資源を占有し続けない仕組みです。



メモリ効率にはコピーオンライト方式が使われます。事前に温めたスナップショットイメージをDAXで直接マッピングし、同じホスト上のmicroVMがOSやライブラリの共通ページを共有します。各エージェントが変更したページだけを専用メモリとして持つため、共通部分をセッションごとに複製する無駄を抑えられます。ハーネス側では、クローン、スナップショットからの分岐、巻き戻し、ロールバックも利用できます。

ストレージは、破棄可能なスクラッチオーバーレイ、複数環境で共有する読み取り専用ボリューム、Hyperdisk上の永続的なユーザーワークスペースに分かれます。例えば、一時的なビルド生成物と、繰り返し使う開発環境、継続保存すべき成果物を同じ寿命で管理せずに済む構成です。

この方式は、多数のエージェントを同時に登録し、その一部だけが断続的に動く用途と相性がよいと考えられます。ただし、Agent Compute Engine自体の復帰時間や収容密度は公表されていません。遅延や費用を見積もる際は、後述するAgent Substrateの測定値を、そのままマネージドサービスの保証値として扱わない注意が必要です。

Googleはマネージド型のAgent Compute Engineとは別に、Kubernetes上で動くオープンソース基盤「Agent Substrate」を提供しています。2026年9月15日からGoogle Kubernetes Engine（GKE）で利用でき、Cloud HypervisorによるmicroVMか、コンテナ向けサンドボックスのgVisorを選択できます。Claude Code、OpenClaw、Hermesなどのハーネスにも対応します。

公開されたベンチマークでは、20万エージェントを対象に、毎秒500件のアクティベーションと500ミリ秒未満の休止・復帰を記録しました。ホスト1台あたり1,000を超える休止中エージェントを保持し、従来型コンピュートと比べて最大10倍の収容密度を示しています。これらはAgent Substrateの数値であり、Agent Compute Engineの起動時間や性能値ではありません。



Agent Substrateは、全GKE顧客が非本番用途で試せます。本番向けの一般提供は許可リスト方式です。ソースコードが公開されているため、自社のKubernetesクラスタへ組み込めますが、インフラ運用やポリシー設計を利用企業側で担う場面も増えるでしょう。マネージド型を待つか、オープンソース版で検証を進めるかは、運用体制を含めて判断する必要があります。

競合サービスも、セッション単位の隔離と休止処理を取り入れています。AWS AgentCore Runtimeは専用microVMを使い、ファイルシステムを停止・再開後も維持します。Azure Dynamic SessionsはHyper-Vサンドボックスを事前に温めたプールから割り当て、E2BはFirecracker microVMを一時停止した際にファイルシステムとメモリをスナップショットへ保存します。

比較時には「microVMを使っているか」だけでは差を判断できません。認証情報をサンドボックスへ置くか、待機中の課金対象は何か、状態をどこまで永続化できるか、最大セッション時間はどの程度かまで見る必要があります。Agent Compute Engineは資格情報を置かない設計を明確にしていますが、料金と主要な性能値は未公表です。セキュリティ構想は具体的でも、費用対効果の比較には情報が足りない段階です。

Google Cloudは、Gemini向けに整備してきた業務エージェントのガバナンスを、Agent Runtime、Cloud Run、Agent Sandboxes、GKE、Agent Compute Engineへ広げる方針です。構成要素には、通信と認可を制御するAgent Gateway、エージェントを管理するAgent Registry、アイデンティティ基盤、OpenTelemetryを使った可観測性が含まれます。

今後の提供予定には、マルチクラウドやハイブリッド環境で使うEnvoyベースのポリシー適用ポイントがあります。管理対象端末で動くClaude CodeやAntigravity CLIなど、ローカルのコーディングエージェントにもガバナンスを適用する計画です。トークン管理、モデルルーティング、Service Extensionsとの連携、Cloud Run向けExpress Linkも同四半期中のプレビュー対象とされています。Ping Identity、SailPoint、Saviyntと連携する委任認可も予定されています。



日本企業が評価を始める場合、プレビューを待つ間にも整理できる項目があります。エージェントに渡す権限と実行環境の選定を同時に進め、モデル選びだけで導入計画を終わらせないことが要点です。特に、次の確認事項は製品を問わず利用できます。

- エージェントが実行するシェル、ブラウザ、API操作を洗い出します。
- 人の権限、委任された権限、実行セッションの識別子を分離します。
- 長期的なAPIキーをサンドボックスへ保存していないか確認します。
- 通信先と操作内容をゲートウェイ側で制限できるか検証します。
- セッションの休止、再開、破棄後に残るデータを分類します。
- 依頼者、エージェント、実行結果を監査ログで結び付けます。

Agent Compute Engineを正式な選択肢として比較するには、料金、提供地域、起動・復帰時間、収容密度、サービスレベルなどの追加情報が必要です。それでも、認証情報を実行環境に置かず、侵害を前提に通信と権限を外側から制御する設計は、自社のエージェント基盤を点検する基準になります。導入検討の最初の一歩として、現在の試験環境に保存されている資格情報と、エージェントが直接到達できる通信先を棚卸しするとよいでしょう。