クラウドとインフラ

Google、クラウド顧客向けに安全なエージェント基盤を公開

Googleは、Geminiを支えるハードウェア分離型microVMシステムである「Agent Compute Engine」を、今年後半にGoogle Cloudユーザー向けのプレビューサービスとして提供開始します。

サーバーラックが入ったガラスの立方体。分離され保護されたエージェントインフラストラクチャを象徴しています。
この記事用に生成されたイラスト

英語の原文から自動翻訳されました。

Googleは、同社のGeminiエージェントを支える内部インフラストラクチャを、パブリッククラウドサービスとしてリリースする準備を進めています。サンノゼで開催されたLinux FoundationのAGNTCon+MCPConで発表されたこの「Agent Compute Engine」は、今年後半にGoogle Cloudユーザー向けにプレビュー版が提供され、AIエージェントの実行用にハードウェア分離型のmicroVMを提供します。

何が起きたか

新サービス「Agent Compute Engine」は、すべてのAIエージェントに専用の分離されたmicroVMを提供します。このアーキテクチャは、コンテナの高速な起動時間と、従来の仮想マシン(VM)の強力なセキュリティ境界を組み合わせたものです。今回の発表は大きな転換点であり、Googleはこの技術をGemini、Antigravity、モデル学習パイプラインなどの社内利用から、外部開発者向けの商用サービスへと移行させます。

このローンチにより、Googleはエージェント用サンドボックスを提供する他の主要プロバイダーと直接競合することになります。E2BやDaytonaなどのスタートアップ企業はすでに類似の環境を提供しており、Firecracker microVMやコンテナベースの分離技術を使用していることが一般的です。AWSもBedrock AgentCoreを提供しており、各エージェントセッションごとに独自のmicroVMを割り当て、アイドル待機中の課金を停止します。Googleの参入は、データセンター内で計算リソースとストレージの最大の消費源となりつつあるエージェント型ワークロードの急成長を支えるため、自社の大規模なスケールメリットを活用しています。

仕組み

Agent Compute Engineは、エージェント実行における速度とセキュリティのバランス課題に対応します。従来の仮想マシンは強力な分離を提供しますが、AIエージェント特有の短命タスクには起動およびサスペンドが遅すぎます。一方、コンテナは高速ですが、安全なコード実行に必要なカーネルレベルの分離がありません。Googleのソリューションは、高速に起動し、アイドル時にチェックポイント化できるハードウェア分離型microVMを使用します。エージェントがモデルからの応答やユーザー入力待ちの場合、ホストはmicroVMの状態をディスクに保存してアクティブなリソースを解放し、必要に応じて即座に再開します。

セキュリティは各セッションの基盤に組み込まれています。各microVMは読み取り専用ファイルシステムを持つステートレスホスト上で動作し、GoogleのTitanおよびTitanium IPUセキュリティプラットフォームを使用して起動時に暗号学的に検証されます。microVM自体はオープンソースのモニターであるCloud Hypervisor上で動作し、各インスタンスは独自のゲストカーネルとルートアクセス権限を持ちます。重要なのは、これらの環境がメモリ上にもディスク上にも秘密情報(シークレット)を保持しない点です。アイデンティティ管理は、有効期限の短いセッションスコープのトークンを通じて行われ、すべてのトラフィックは暗号化されます。ネットワークアクセスはサンドボックス外のプロキシ経由で行われ、認証情報はGoogleのAgent Gatewayによるユーザー委任の検証後にのみ注入されます。

主な詳細

  • Agent Compute Engineは、2026年後半にGoogle Cloudユーザー向けにプレビュー版として利用可能になる予定です。

  • 各エージェントは、独自のゲストカーネルを持つ単一テナントのハードウェア分離型microVM内で実行されます。

  • システムはアイドル状態のmicroVMをチェックポイント化し、状態を保持しながらアクティブなリソースを解放します。

  • セキュリティは、ハードウェア検証のためにGoogleのTitanおよびTitanium IPUプラットフォームに依存しています。

  • サンドボックス環境内のメモリまたはディスクには秘密情報は保存されません。

  • すべてのネットワークトラフィックはプロキシ経由で暗号化され、認証情報はVM外で管理されます。

なぜ重要なのか

エージェント型システムを構築するエンジニアにとって、セキュリティは採用における最大の障壁のままです。エージェントはコードの実行、Web閲覧、シェルスクリプトとの対話のためにルートレベルのアクセス権限を必要とすることが多く、侵害された場合のリスクは重大です。攻撃者がエージェントを制御しても価値のあるものが見つからないようなサンドボックスを提供することで、Googleは信頼できないコードを実行することに伴う責任負担を軽減します。この「盗むものがない」というアプローチにより、開発者は機密性の高いインフラや認証情報を露出させることなく、エージェントにより広範な権限を付与できます。

アイドル時のエージェントをチェックポイント化することによる効率向上は、コストとスケーラビリティにも影響します。エージェントは時間の大半を外部入力待ちに費やすため、これらの期間中にフル計算リソースに対して課金することは無駄です。microVMをサスペンドしてアクティブなCPUリソースを解放することで、インフラはより高密度な同時エージェントをサポートできます。このモデルは数週間続く可能性のある長時間ループをサポートし、従来は経済的に管理することが難しかった強化学習や大規模モデル評価などの複雑なワークフローを可能にします。

対応策

  • 今年後半のAgent Compute Engineプレビュー版のローンチについて、Google Cloudコンソールを監視してください。
  • ルートレベルの分離が必要なタスクと単純なコンテナ化で十分なタスクを特定するために、現在のエージェントワークロードを評価してください。
  • プロキシベースのアイデンティティモデルに合わせて、エージェントの認証情報管理に関するセキュリティプロトコルを見直してください。
  • マネージドサービスを希望しない場合は、既存のKubernetesクラスタでのAgent Substrateのテストを検討してください。
  • アイドル時のチェックポイント化による潜在的なコスト削減を見積もるために、エージェントのサスペンドおよび再開時間をベンチマークしてください。
  • オープンソースのSubstrateランタイムを使用している場合は、Claude CodeやOpenClawなどのツールとの統合を検討してください。
  • #google cloud
  • #ai agents
  • #infrastructure
  • #security
  • #microvm

Bytechapストアのツール

続きを読む

クラウドとインフラ

AIワークロードでKubernetesの自動スケーリングが失敗する理由と、DRAによる解決策

Kubernetesの自動スケーリングはGPUトポロジー要件との不一致が生じやすく、高価なハードウェアを遊休状態に陥れることがあります。Dynamic Resource Allocation(DRA)は、スケジューリングとプロビジョニングの間のギャップを埋めます。

クラウドとインフラ

Kubernetes コントロールプレーンのスケーリングを制限する3つの異なるボトルネック

Kubernetes クラスターの大規模化における失敗は、単なるノード数の多さではなく、ノードのチャーン(頻繁な作成・削除)、オブジェクトの状態、書き込み強度に起因します。新しいアーキテクチャ上の「シーム」により、各ボトルネックに対して的確な対策が可能になります。

すべての記事