Google Cloud Next Tokyo 26で見えた、AIエージェント本番運用の全体像
AIエージェントの試作と、業務システムとして安定稼働させるための本番運用では、必要な設計が大きく異なります。本番環境では、実行場所を用意するだけでは不十分です。エージェントを識別し、接続先を管理し、通信と入出力を保護したうえで、問題が発生したときに処理経路や原因を追跡できる仕組みが必要です。
Google Cloud Next Tokyo 26の公式案内では、AIエージェントの社会実装に向け、インフラ、開発、データ、セキュリティを横断して、開発・デプロイ・運用・スケールを支える基盤がテーマとして示されました。本記事では、この方向性とGoogle Cloudの公式情報を踏まえ、AIエージェントの本番運用で考えるべき要素を、インフラ担当者・SREの視点から6つの基盤として整理します。これはGoogle Cloudが定めた固定分類ではなく、本記事独自の整理です。
AIエージェントの実行先は要件によって異なり、Google Cloudでは、Compute Engine（GCE）、Google Kubernetes Engine（GKE）、Cloud Runなどの実行基盤も選択肢になります。本記事では、これらの個別サービスの構築方法ではなく、実行基盤を含めてAIエージェントを本番運用する際に必要となる管理、ID、通信、保護、観測の観点を整理します。
1. はじめに
PoCでは回答やツール呼び出しが評価の中心ですが、本番運用では運用面の検討事項が加わります。障害時にどこまで復旧するか、外部接続にどの権限を使うか、不適切な入出力をどこで制御するか、性能や品質の劣化をどう検知するかまで設計しなければなりません。
公式案内では、Day 2基調講演「AIエージェントを社会実装へ」において、インフラ、エージェント開発、データ、セキュリティを横断した基盤を扱うと案内されました。一方、Gemini Enterprise Agent Platformそのものは、米国で開催されたGoogle Cloud Next ’26において、Build、Scale、Govern、Optimizeの4領域で発表されています。両イベントは別であり、本記事ではNext Tokyo 26で示された社会実装の方向性と、Next ’26およびその後の公式ドキュメントで確認できる製品情報を組み合わせて整理します。
各サービスの提供状況は、機能や連携方法によって異なります。本記事では個別設定ではなく、設計時に検討すべき全体像を示します。対象機能、リージョン、制限、料金、SLAは、実際に利用する時点の公式情報で確認する必要があります。
2. AIエージェント本番化で問われる6つの設計事項
AIエージェントの本番化では、最初から製品名を並べるより、運用上の課題から考えると全体を捉えやすくなります。本記事では、次の6つを設計の起点とします。
- 1. どこで実行し、どうスケールさせるか：エージェントの実行環境、デプロイ単位、可用性、リソース消費を設計します。
- 2. 何が動き、どこへ接続しているかをどう把握するか：エージェント、MCPサーバー、ツールがどこで動き、どのシステムと接続しているかを把握できるようにします。
- 3. 誰として動き、誰の権限を使うか：エージェント自身の権限と、利用者から委任された権限を明確に分けます。
- 4. 通信をどこで制御するか：利用者からエージェントへの入口と、エージェントからツールへの出口に適用する認証、認可、ポリシーを設計します。
- 5. 入力と出力をどこで検査するか：プロンプトインジェクション、機密情報の漏えい、有害コンテンツなどのリスクを検出し、制御する場所を定めます。
- 6. 状態をどう観測し、異常からどう復旧するか：ログ、メトリクス、トレース、トポロジーから遅延、エラー、依存関係、利用量を把握し、復旧対応につなげます。
この6つの設計事項は、互いに独立しているわけではありません。実行場所が決まれば通信経路や監視方法に影響し、IDの設計はGatewayでの認可や監査記録に影響します。重要なのは、単一の製品ですべてを解決しようとせず、実行環境、ID、通信、保護、監視を相互に関連付けて設計することです。
図1 本記事がインフラ・SRE視点で整理した、AIエージェント本番運用を支える6つの基盤
3. 本番運用を支える6つの基盤
ここからは、6つの設計事項に対応するGoogle Cloudの機能を確認します。Google Cloud公式ではGemini Enterprise Agent PlatformをBuild、Scale、Govern、Optimizeで説明していますが、本記事では運用設計上の役割に合わせて6つの基盤に整理しています。
3.1 Agent Runtime
役割：Agent Runtimeは、AIエージェントをデプロイし、管理し、需要に応じてスケールさせる実行基盤です。従来はVertex AI Agent Engineと呼ばれていましたが、2026年4月にAgent Runtimeへ名称が変更されました。APIでは後方互換性のためReasoningEngineというリソース名が残っています。
なぜ必要か：本番では推論だけでなく、セッション、メモリ、ネットワーク、監視も運用対象です。マネージド基盤により、エージェントの実装と基盤運用を分けやすくなります。
設計時のポイント：稼働させるリージョンを決め、ピーク時のスケール、セッション、メモリの扱いを設計します。実行リソース、モデル利用量、ログ保存量も見積もります。Agent Runtimeは東京リージョンに対応しています。ただし、セッションやメモリなどの関連機能については、それぞれ対応状況を確認します。
3.2 Agent Registry
役割：Agent Registryは、AIエージェント、MCPサーバー、ツールを登録し、発見し、統制するためのカタログです。論理的な識別子、実体の稼働場所、IAMで使う主体は別の概念として管理されます。Registry自体は、リクエストが必ず通過するネットワーク装置ではありません。
なぜ必要か：エージェントやツールが増えると、稼働場所、接続先、所有者が見えにくくなります。Registryで構成要素を把握できれば、GatewayのポリシーやObservabilityの分析に使う基礎情報を揃えられます。
設計時のポイント：登録する対象を決め、命名規則、所有者、ライフサイクルの管理方法を統一します。また、運用チームが継続してカタログを更新できる運用体制を整えます。利用するリージョンや構成によって登録方法や制約が異なるため、採用する構成の条件を確認します。
3.3 Agent Identity
役割：Agent Identityは、エージェント単位の固有IDを持たせ、エージェント自身の権限と、利用者から委任された権限を区別する仕組みです。エージェントを独立した主体として扱い、必要な権限だけを付与できるようにします。
なぜ必要か：複数のエージェントがIDを共有すると、監査記録から実行主体を追いにくくなります。固有IDを持たせ、利用者の代理処理とエージェント自身の処理を分けることで、最小権限と追跡可能性を両立しやすくなります。
設計時のポイント：エージェント自身に与える権限と、利用者から委任される権限を分けて設計します。また、IDの発行、更新、失効、監査の手順を定め、必要最小限の権限を維持します。
3.4 Agent Gateway
役割：Agent Gatewayは、エージェントとの通信に認証、認可、セキュリティポリシーを適用するネットワークコンポーネントです。利用者からエージェントへ入るClient-to-Agentと、エージェントからツールへ出るAgent-to-Anywhereの2つの考え方があります。
なぜ必要か：エージェントは社内API、データベース、SaaSなどを呼び出します。接続先ごとの個別実装では認証や監査がばらつくため、入口と出口に共通の判断点を設け、主体と要求内容に応じて制御します。
設計時のポイント：どの通信をGateway経由にするかを決め、入口と出口のどこにポリシーを適用するかを設計します。リージョンの組み合わせ、VPC Service Controlsとの併用条件、接続先証明書の要件も確認します。Agent Gatewayは、利用する機能や連携方法によって提供状況が異なる場合があるため、採用する構成ごとに対応状況を確認します。
3.5 Model Armor
役割：Model Armorは、プロンプトとレスポンスを検査し、プロンプトインジェクション、機密情報の漏えい、有害コンテンツなどのリスクを検出する仕組みです。Agent Gatewayと組み合わせる構成では、通信経路上の検査とポリシー適用に利用できます。
なぜ必要か：通信相手の認証に成功しても、要求や応答が安全とは限りません。意図しないツール実行や機密情報を含む応答に備え、IDと通信の制御に加えてコンテンツを検査します。
設計時のポイント：検査する入力と出力を決め、問題を検出した場合に遮断、記録、通知のどの処理を行うかを設計します。誤検知が発生した場合や、検査を実行できなかった場合の対応も定めます。利用する連携方法、データ形式、リージョンで必要な機能を利用できるか確認します。
3.6 Agent Observability
役割：Agent Observabilityは、ログ、メトリクス、トレースを集約し、エージェントやツールの関係をトポロジーとして把握するための運用基盤です。ダッシュボードでは、セッション、呼び出し、遅延、エラー、モデル・ツールの利用状況などを確認できます。
なぜ必要か：応答遅延や失敗は、モデル、Runtime、Gateway、外部ツールのどこでも発生します。共通のトレースと相関情報があれば、どの経路で何が起きたかを追いやすくなります。
設計時のポイント：収集するログ、メトリクス、トレースを決め、閲覧できる担当者と権限を設定します。入出力を保存する場合は、機密情報の取り扱いと保存期間も定めます。エージェントやツールの呼び出し関係を可視化できるように、ログやトレースを関連付けて記録します。
4. 6基盤が連携する処理の流れ
代表例として、利用者の要求がGatewayを経由してRuntime上のエージェントへ届き、そのエージェントがGatewayを介して外部ツールを呼び出す流れを説明します。これはClient-to-AgentとAgent-to-Anywhereを使う概念例です。実際の経路は、製品、連携機能、リージョン、ネットワーク設計によって変わります。
正常時には、Gatewayが実行主体とポリシーを確認し、Runtimeがエージェントを実行します。ツールを呼び出す際にも、接続先と権限を確認します。Model Armorを組み込む場合は、組み込んだ箇所で入出力を検査します。ポリシー違反は拒否し、タイムアウトや接続障害はエラーとして扱います。
ここでRegistryは接続先や構成要素のメタデータを管理し、Identityは認証・認可の判断に使う実行主体を識別します。どちらもリクエストが順番に通過する機能ではありません。Observabilityは各処理のログ、メトリクス、トレースを横断的に記録し、処理経路をトポロジーとして運用者に示します。
図2 Gatewayを利用した代表的な通信経路と、管理・ID・観測の関係
5. 本番化に向けた確認項目
6つの基盤をすべて一律に導入するのではなく、システム要件に照らして、それぞれの必要性を判断します。少なくとも、次の観点を設計レビューで確認します。
- ・実行：デプロイ単位、スケール、セッション、メモリ、障害時の再実行範囲が決まっているか。
- ・構成管理：エージェント、MCPサーバー、ツール、接続先の所有者とライフサイクルを追跡できるか。
- ・IDと権限：エージェント自身の権限と利用者からの委任を分け、共有IDへの依存を減らしているか。
- ・通信：入口と出口の通信経路、許可する接続先、拒否時の挙動、閉域化要件を説明できるか。
- ・コンテンツ保護：検査対象、遮断条件、誤検知時の対応、検査できなかった場合の扱いが決まっているか。
- ・観測と復旧：サービスレベル指標、ログ・トレースの相関、アラート、障害切り分け、保存期間を決めているか。
- ・提供条件：利用機能のGA／Preview、対応リージョン、クォータ、料金、SLAを、製品全体ではなく機能単位で確認したか。
提供条件は、この章でまとめて確認します。2026年8月2日の調査時点では、各基盤でAPIや連携機能ごとにGAとPreviewが混在しています。製品名だけで判断せず、実際に利用する機能ごとに提供状況を確認します。料金は実行、モデル、保存、監視などに分けて見積もります。SLAについては、公式に対象とされているサービス範囲を確認します。東京リージョンが対応地域の一覧に含まれていても、関連するすべての機能を同じ地域で利用できるとは限りません。
記事の公開前、導入前、重要な構成変更前に、提供状況、リージョン、制限、料金、SLAを再確認します。不明点は推測せず、未確認事項として記録し、確認できるまで採用判断を保留します。
6. まとめと今後のテーマ
AIエージェントの本番運用では、「どのモデルを使うか」だけでなく、実行場所、管理対象、実行時のID、通信とコンテンツの制御、監視方法を一体として設計する必要があります。本記事では、その全体像をAgent Runtime、Agent Registry、Agent Identity、Agent Gateway、Model Armor、Agent Observabilityの6つの基盤で整理しました。これはGoogle Cloudの固定分類ではなく、インフラ担当者やSREが設計を進めるための本記事独自の枠組みです。
今後の記事では、「AIエージェント基盤・運用」と「インフラ・プラットフォーム拡張」の2つの観点から、実行基盤、通信制御、SRE、データ連携、アプリケーション設計、ネットワーク、ハイブリッド基盤、運用分析などを扱う予定です。今後取り上げる候補テーマを図3に示します。
本記事では、各基盤の役割と、設計時に確認すべき内容までを説明しました。APIの有効化、CLIやTerraform、IAMロール、Gatewayポリシー、Model Armorのしきい値、OpenTelemetryを使ったログやトレースの収集、具体的な障害調査は、今後の記事でテーマに応じて掘り下げます。
図3 今後取り上げる候補テーマ