社内でAIエージェントを作り始めたが、そのエージェントがどの権限で、どこで動き、いくら使ったのかを一覧で答えられない。開発者のPCではClaude Codeが動き、クラウドでは別のエージェントが動いている。Google Cloudが10月22日に出した発表は、まさにこの「ばらばらに動くエージェントをどう管理するか」に向けたものです。
発表の冒頭は次のとおりです。
Today at AGNTCon + MCPCon, we are delivering these capabilities to customers by launching Agent Compute Engine, a purpose-built compute service that already powers Gemini as an agent for work tasks. It will be available in preview in the coming months, providing hardware-isolated runtime sandbox security.
ただし、発表された機能の多くは「これから」のものです。発表文の書き方から提供の段階を仕分けし、社内でエージェントを動かす会社がいま決められることを整理します。
発表は2つの柱
発表は、エージェントを動かす場所（実行基盤）と、エージェントを管理する仕組み（統制）の2つに分かれています。
動かす場所：Agent Compute Engine
エージェントごとに専用の小さな仮想マシン（microVM）を用意するサービスです。発表によると、Geminiのエージェントの作業環境として既に使われています。特徴として挙げられているのは次の点です。
- 起動が速いmicroVMで、エージェントが考えている間（ツールの実行を待っている間）は一時停止し、スナップショットからすぐに再開する
- Googleの専用チップ（Titanium）とCloud Hypervisorによる、ハードウェアで分離された実行環境。エージェントの中で信頼できないコードが動く前提の設計
- microVMごとに短期間だけ有効な認証情報と固有のIDを持ち、外部のサービスの認証情報はmicroVMの外側（通信の出口）で付け加える
- microVMごとに専用のディスク（Hyperdisk）を持ち、長い作業の途中の状態を残せる
Kubernetesで自分たちで運用したい会社向けには、オープンソースの「Agent Substrate」をGKEで使う選択肢も示されています。Agent Substrateは2026年5月に公開されたもので、別の記事（エージェントは待っている時間が長い — AXが置き直した前提）で扱いました。発表は、Agent SubstrateがClaude Codeなどのエージェントの枠組みを問わず動くとしています。
管理する仕組み：エージェントの統制（ガバナンス）
Gemini for business（Googleの法人向けのGemini）には、すでに次の4つの機能があると発表は説明しています。
- Agent Gateway：エージェントとの間の通信の関所。機密データの保護、エージェントへの攻撃の防御、独自のポリシーの適用
- Agent Registry：承認済みのエージェント、ツール、MCPサーバー、スキル、モデル、接続先の台帳
- Agent Identity：SPIFFEという標準に基づく、エージェントごとの固有のID
- 観測：OpenTelemetryに沿ったログ・指標・トレース
今回の発表は、この統制の対象を広げるというものです。
提供の段階を仕分ける
発表文の書き方をそのまま並べると、使える時期は次のように分かれます。
| 機能 | 発表文での段階 |
|---|---|
| Agent Compute Engine | 今後数か月でプレビュー（関心の登録を受付中） |
| Agent Substrate（GKE） | オープンソース。「今日から試せる」（GKEのリリースノートでは9月11日から評価・本番以外の用途向けで、本番のサポートは許可リスト制の限定GA） |
| 統制をAgent Runtime・Cloud Run・GKEなどGoogle Cloudの実行環境に広げる | 対象に含むと記載（Agent Compute Engineはプレビュー） |
| 他社クラウド・オンプレミスへの統制（Envoyベース） | まもなくプレビュー |
| 社員のPCのClaude Code・Antigravity CLIの統制（OSレベルのサンドボックス） | まもなくプレビュー |
| Agent Gatewayのトークン・費用の管理、モデルの振り分けなど | 今四半期にプレビュー |
「まもなく」「今後数か月」は具体的な日付ではありません。10月27日時点で、Google Cloudのリリースノートには Agent Compute Engine の項目はなく、ドキュメントのページもまだありません。プレビューの機能は、正式版までに仕様が変わることがあります。顧客の本番のシステムを、これらの機能の提供を前提に設計するのは、提供が始まって条件を確かめてからが無難です。
社員のPCのClaude Codeまで対象にする意味
発表のなかで、エージェントを社内で使う会社に関係が深いのは、統制の対象を社員のPCに広げる部分です。
Governance for local agents on endpoints: Extends governance to coding agents like Claude Code and Antigravity CLI on managed devices with an OS-level sandbox and local governance services (in preview soon).
クラウドで動くエージェントは、通信の出口や権限で管理しやすい一方、開発者のPCで動くコーディングエージェントは、そのPCの権限でファイルを読み、コマンドを実行します。発表は、管理対象の端末（managed devices）でOSレベルのサンドボックスとローカルの統制の仕組みを使う、としています。管理対象の端末の条件、対応するOS、料金は発表文には書かれていません。
Claude Codeには、提供元のAnthropicが用意する管理者向けの設定もあります。その一例として、拡張機能「mod」の既定の動きを管理者が止める方法をClaude Codeのmodを会社で管理するで扱っています。Google Cloudの新しい機能を待つ前に、いま使える管理の手段で足りるかを確かめておくのが先です。
いま決めておけること
プレビューを待つ間にも、どの基盤を選ぶかに関係なく決められることがあります。ここからは編集部の提案です。
- エージェントの台帳を作る：どのエージェントが、どこで（クラウド・社員のPC）、誰の権限で、何につながって動いているか。発表のAgent Registryが担う役割を、まずは表で持つ
- 認証情報をエージェントの手元に置かない方針を決める：発表は、認証情報をエージェントの実行環境の外側で付け加える設計を繰り返し挙げています。APIキーを環境変数でエージェントに渡している構成は、見直しの候補になります
- 費用の上限の単位を決める：部署ごとか、エージェントごとか。Agent Gatewayのトークンの管理がプレビューになったときに、そのまま設定に落とせます
- ログの形式をそろえる：発表はOpenTelemetryに沿った観測を挙げています。自社で作るエージェントも、同じ形式でログを出しておくと、後から基盤を移しても使えます
実行環境を自分たちで作るか、サービスを使うかの考え方は100万個のサンドボックスの話から、AIの実行環境の線を引くで整理しています。
確認した範囲
2026年10月25日に、Google Cloudのブログ「Introducing Agent Compute Engine and expanded agent governance」（2026年10月22日）を確認しました（資料調査）。10月27日に、同じブログを確認し直し、技術解説の記事（Inside Agent Compute Engine、10月23日。「targeted for preview in the coming months」と記載）、Google Cloudのリリースノート、エージェントの統制とAgent Gatewayのドキュメントを確認しました。料金、対応リージョン、社員のPCの統制で対象となるOSと条件は、確認した範囲には書かれていません。いずれの機能も、編集部では動かしていません。
社内で動かすAIエージェントの設計や、権限・費用の管理の仕組みづくりは、開発・AI・自動化のご相談からお問い合わせください。
