Gemini Enterprise Agent Platform のエージェントのオブザーバビリティにより、デプロイされたエージェントと Model Context Protocol（MCP）サーバーのパフォーマンス、動作、健全性を包括的に把握できます。主要な指標をモニタリングし、実行パスをトレースして、マルチエージェント システム全体をモニタリングすることで、問題を診断し、リソース消費を最適化して、エージェントの信頼性を向上させることができます。
このドキュメントでは、Gemini Enterprise Agent Platform で利用可能なオブザーバビリティ ツール（システム全体のトポロジ、個々のエージェントのモニタリング、MCP サーバーの指標など）の概要について説明します。
テレメトリーの設定
これらのオブザーバビリティ ダッシュボード、トポロジ、トレースにデータを入力するには、OpenTelemetry 形式のテレメトリー データを Google Cloud Observability のストレージ システムに送信するようにエージェントを構成する必要があります。
エージェントと MCP サーバー環境が、このデータを出力するように適切に構成されていることを確認します。組み込みの Google Cloud コンポーネントは、OpenTelemetry 形式でテレメトリーを自動的に出力します。たとえば、Model Armor は標準化されたテレメトリーをネイティブに出力するため、カスタムの計測を必要とせずに、トレースデータ内でリアルタイムのポリシー インターセプトを直接シームレスに公開してモニタリングできます。
エージェント テレメトリーの設定手順と要件については、次のリソースをご覧ください。
- ADK で構築されたエージェントを計測するには、OpenTelemetry を使用して ADK アプリケーションを計測するをご覧ください。
- ADK で構築されていない Gemini Enterprise Agent Platform の Agent Runtime でエージェントを計測するには、AI エージェント デベロッパー向けのオブザーバビリティをご覧ください。
- MCP サーバーのテレメトリーについては、Cloud Trace を使用して MCP ツールの使用状況をモニタリングするをご覧ください。
- Model Armor のテレメトリーについては、Model Armor のロギングを構成するをご覧ください。
オブザーバビリティ シグナル
Gemini Enterprise Agent Platform は、指標、トレース、ログを通じてオブザーバビリティを提供します。
レジストリから特定のエージェントを選択すると、[オブザーバビリティ] タブに、IT 運用の健全性、パフォーマンス、インフラストラクチャの使用状況をモニタリングするための、ターゲットを絞ったダッシュボードが表示されます。[オブザーバビリティ] タブの左側のナビゲーションを使用して、次のビューを切り替えます。
- 概要: 選択した期間における全体的な使用状況（合計セッション数、セッションあたりの平均ターン数、エージェントの呼び出しの合計数など）を追跡します。時系列グラフには、トークン使用量（入力と出力）、エージェントの全体的なトラフィック量、レイテンシのパーセンタイル（p50、p95、p99）、エラー率が表示されます。
- 評価: 継続的な品質評価のためのオンライン モニターが表示されます。これには、平均レスポンス品質、安全性指標、ハルシネーション率、ツール使用品質を追跡する時系列ウィジェットが含まれます。
- モデル: 基盤となる基盤モデル別にパフォーマンスを分類します。特定のモデルで分離された p95 レイテンシ、合計呼び出し数、エラー率、レートに基づく割り当てエラー、トークン使用量をモニタリングできます。
- ツール: エージェントに接続されている外部ツールとサービスをモニタリングします。このビューには、ツールごとの P95 レイテンシ、呼び出し数、エラー率、ツールが呼び出されなかったインタラクションの頻度が表示されます。
- 使用状況: エージェントのランタイム環境のインフラストラクチャ レベルの指標（コンテナの CPU 割り当て、コンテナのメモリ割り当て、トークンの使用状況など）を提供します。
- ログ: 重大度、タイムスタンプ、実行の概要など、詳細なトラブルシューティングを行うための、フィルタ可能な未加工のエージェント ログのストリームが表示されます。詳細については、エージェント ログを表示するをご覧ください。
[オブザーバビリティ] タブのダッシュボードに加えて、エージェントの [トレース] タブを使用して、スパンと入出力の有向非巡回グラフなど、特定のセッションのステップバイステップの実行を検査できます。詳細については、エージェント トレースを表示するをご覧ください。[トポロジ] タブを使用して、その単一エージェントの特定のインバウンド依存関係とアウトバウンド依存関係を表示することもできます。
MCP サーバーの場合、リクエスト数と p95 リクエスト時間をモニタリングして、使用率と応答性を追跡できます。
エージェント アクションの監査
エンタープライズ セキュリティとコンプライアンス監査をサポートするため、Gemini Enterprise Agent Platform はデュアル アトリビューション ロギングを使用して、エージェントのアクティビティを Cloud Logging に記録します。エージェントがユーザーに代わってアクションを実行したり、ツールを呼び出したりすると（ユーザー委任権限）、監査ログと実行ログに、SPIFFE ベースのエージェント ID（監査ログの principal://...、または実行ログの spiffe://...）と、開始した人間のユーザーの ID の両方が記録されます。エージェントが独自の権限で自律的に動作する場合、ログにはアクションが固有のエージェント ID に直接関連付けられます。
監査者とセキュリティ管理者は、ログクエリで is_agentic=true フラグをフィルタすることで、Cloud Logging でエージェントが開始したイベントを分離して確認できます。is_agentic=true をエージェント ID またはユーザー プリンシパルと組み合わせることで、エンドツーエンドの実行パスをトレースし、すべてのエージェント インタラクションでポリシーの適用を検証できます。
緊急停止とポリシーの伝播に関する想定
セキュリティ インシデントやエージェントの異常な動作に対応する場合、Agent Platform はエージェントのアクティビティを停止するための 2 つの補完的なレイヤを提供します。
- ランタイムの即時終了またはトラフィックの再ルーティング: Agent Runtime（
runtimes.deleteまたはreasoningEngines.delete）にデプロイされたエージェントを削除すると、コンテナ インスタンスが直ちに終了し、アクティブなセッションとストリーミング呼び出しが停止します。削除オペレーションが完了すると、SPIFFE エージェント ID が完全に無効になります。または、trafficSplitManualを使用してルート トラフィックの 100% を既知の正常なリビジョンに再ルーティングするか、spec.deployment_spec.agent_gateway_configを更新して既存のリビジョンをアーカイブすることもできます。 - ポリシーベースのアクセス取り消し: Agent Gateway（
iamEnforcementMode: "ENFORCE"）によって適用される統合アクセス ポリシー（UAP）にDENYルールを追加するか、Identity and Access Management（IAM）の拒否ポリシーまたはロールの取り消しを適用すると、フォレンジック分析のためにランタイム コンテナを保持しながら、アウトバウンド ツールと API 呼び出しをブロックできます。ただし、UAP と IAM ポリシーの更新は結果整合性があります。直接ポリシーの変更は通常 2 分以内に有効になりますが、グローバルに反映されるまでに最大 7 分以上かかることがあります（アクセス権の変更の伝播をご覧ください）。principalSetまたはグループ メンバーシップの更新は、同期に数分から数時間かかることがあります。ポリシーの更新は新しい認可チェックで評価され、再認可されない限り、すでに確立されているストリーミング接続を強制的に終了することはありません。
アクティブなインシデント中に即座にキルスイッチを適用するには、ポリシー拒否ルールを適用するだけでなく、エージェント ランタイムを削除するか、リビジョン トラフィックを再ルーティングします。詳しい手順については、緊急停止とアクセス権の取り消しをご覧ください。
テレメトリーとセキュリティ検出結果のレイテンシ
オブザーバビリティとセキュリティのコントロールは、取り込みと評価のスケジュールが異なります。これらのレイテンシの予測を理解することで、インシデント対応者はインライン適用と非同期の脅威検出を区別できます。
次の表に、Agent Platform の各テレメトリー シグナルとセキュリティ シグナルの評価モデルと想定されるレイテンシをまとめます。
| 信号または制御 | 評価と取り込みのモデル | 通常のレイテンシ |
|---|---|---|
Cloud Audit Logs と Agent Gateway リクエストログ（cloudaudit.googleapis.com/*、networkservices.googleapis.com/gateway_requests） |
API 呼び出しとゲートウェイ認可チェックが評価されるときに同期的に生成され、Logging に取り込まれます。 | ほぼリアルタイム（通常は数秒以内にログ エクスプローラで検索可能）。--freshness=6h などの狭い CLI 鮮度フィルタでは、最近インデックスに登録されたエントリが欠落することがあります。最近のイベントを確認する場合は、--freshness=1d を使用してください。 |
Agent Runtime の実行ログ（aiplatform.googleapis.com/reasoning_engine_stdout、reasoning_engine_stderr） |
ランタイム コンテナから Logging に非同期でストリーミングされます。 | 通常、出力から数秒以内に表示されます。 |
| Cloud Trace の分散トレース | OpenTelemetry スパンの完了時に非同期でエクスポートされます。構成された samplingRate ルールと parentBasedSampling ルールが適用されます。 |
通常、スパンの完了から数秒以内に検索可能になります。 |
| Cloud Monitoring の指標 | Agent Runtime、Agent Gateway、異常検出パイプラインから定期的にサンプリングされます。 | 60 ～ 120 秒ごとにサンプリングされ、Metrics Explorer とダッシュボードに表示されるまでに最大 180 ～ 420 秒の遅延が発生します。 |
| インライン ポリシーの適用（Agent Gateway、Identity-Aware Proxy、Model Armor） | ツール呼び出し、MCP リクエスト、モデル プロンプトが完了する前に、ライブ リクエストパスで同期的に評価されます。 | リアルタイムのインライン インターセプト（後処理の遅延なし）。 |
Agent Anomaly Detectionと Security Command Center（Security Command Center）の検出結果（AGENT_SESSION_ANOMALY） |
セッション ログとトレースが取り込まれた後、多層検出パイプライン全体で非同期に帯域外で評価されるため、ライブ エージェントのレスポンスにレイテンシが追加されることはありません。 | 最初のスコープの有効化には約 40 分かかります。異常指標は 120 秒ごとにサンプリングされます（最大 420 秒の可視性遅延）。確認済みの検出結果が Security Command Center に表示される前に、追加の同期レイテンシが適用されます。 |
監査ログの改ざん検知可能な保持
Cloud Audit Logs エントリは不変であるように設計されています。Logging が監査ログエントリを書き込んだ後、そのペイロードとメタデータを変更することはできません。管理アクティビティ監査ログとシステム イベント監査ログは、_Required ログバケットに保存されます。このバケットでは、400 日間の固定保持期間が適用され、変更や削除はできません。
デフォルトでは、データアクセス監査ログ（cloudaudit.googleapis.com/data_access）、ポリシー拒否ログ（cloudaudit.googleapis.com/policy_denied）、Agent Gateway リクエストログ（networkservices.googleapis.com/gateway_requests）、デュアル アトリビューション エージェント実行ログ（is_agentic=true）は、30 日間の保持期間で _Default ログバケットに転送されます。
コンプライアンスの証拠として、改ざん防止、1 回限りの書き込み、複数回の読み取り（WORM）の保持を適用するには、エージェント監査ログとゲートウェイ ログをカスタム Logging バケットに転送し、カスタム保持期間（1 ～ 3,650 日）を構成して、バケットを完全にロックします。Logging バケットのロックは元に戻せない操作です。プロジェクト オーナーや組織管理者を含むすべてのユーザーが、バケットの削除、保持期間が終了する前のログエントリの削除、保持期間の短縮を行うことができなくなります。
Google Cloud CLI を使用してエージェント監査ログ用のカスタム Logging バケットを作成してロックするには、次のコマンドを実行します。
gcloud logging buckets create BUCKET_ID \
--location=LOCATION \
--retention-days=RETENTION_DAYS \
--project=PROJECT_ID
gcloud logging buckets update BUCKET_ID \
--location=LOCATION \
--locked \
--project=PROJECT_ID
次のように置き換えます。
BUCKET_ID: 監査ログバケットの固有識別子（例:agent-audit-worm-bucket）。LOCATION: バケットのロケーション（例:global、us、eu）。RETENTION_DAYS: ログエントリを保持する日数（1～3650）。PROJECT_ID: 実際の Google Cloud プロジェクト ID。
親プロジェクトが削除された場合にロックされたログバケットが削除されないようにするには、プロジェクトにプロジェクト リーエンを設定します。または、ロックされた保持ポリシー（バケットロック）で構成された Cloud Storage バケットに監査ログをエクスポートすることもできます。詳細については、ログバケットの構成と管理をご覧ください。
監査ログを SIEM にエクスポートする
セキュリティ モニタリング、相関、長期的なコンプライアンス アーカイブを一元化するには、エージェント監査ログ、Agent Gateway の認可決定、is_agentic=true 実行ログを Google Security Operations（Google SecOps）またはサードパーティのセキュリティ情報およびイベント管理（SIEM）システムに継続的にエクスポートします。
プロジェクト レベルの Logging シンク、または組織レベルまたはフォルダレベルの集約シンクを構成して、次の宛先にログを転送できます。
- Google Security Operations: Cloud Audit Logs、Agent Gateway ログ、Security Command Center からの
AGENT_SESSION_ANOMALYの検出結果を、Google SecOps にネイティブに、または Pub/Sub フィードや Cloud Storage フィードを介して取り込み、エンタープライズ セキュリティ テレメトリーとともにエージェント セッションを調査します。設定手順については、 Google Cloud データを Google SecOps にエクスポートするをご覧ください。 - Pub/Sub（Pub/Sub）: エージェント監査ログを Pub/Sub トピックにリアルタイムでストリーミングし、Pub/Sub サブスクリプションまたは Dataflow コネクタを使用してサードパーティの SIEM プラットフォーム（Splunk、Datadog、QRadar など）で取り込みます。詳細については、Pub/Sub にログを転送するをご覧ください。
- BigQuery（BigQuery）またはオブザーバビリティ分析: ログを BigQuery データセットにエクスポートするか、オブザーバビリティ分析が有効なログバケットを BigQuery にリンクして、エージェント ID、ユーザー委任、ゲートウェイ ポリシーの拒否にわたって SQL コンプライアンス クエリを実行します。
- Cloud Storage: バッチ処理された JSON ログファイルを、バケットロックが有効になっている Cloud Storage バケットにエクスポートして、長期の不変アーカイブを行います。
SIEM 取り込みのためにエージェント監査ログとゲートウェイ ログを Pub/Sub トピックにストリーミングする Logging シンクを作成するには、次の操作を行います。
Cloud Audit Logs、Agent Gateway リクエストログ、Agent Runtime ログ、デュアル アトリビューション エントリ（
is_agentic=true）をキャプチャする一致フィルタを使用してログシンクを作成します。gcloud logging sinks create SINK_NAME \ pubsub.googleapis.com/projects/DESTINATION_PROJECT_ID/topics/TOPIC_ID \ --log-filter='logName:("cloudaudit.googleapis.com" OR "networkservices.googleapis.com%2Fgateway_requests" OR "aiplatform.googleapis.com%2Freasoning_engine") OR jsonPayload.is_agentic=true OR labels.is_agentic="true"' \ --project=PROJECT_ID次のように置き換えます。
SINK_NAME: ログシンクの名前（例:agent-audit-siem-sink）。DESTINATION_PROJECT_ID: 宛先 Pub/Sub トピックをホストしているプロジェクト ID。TOPIC_ID: SIEM がサブスクライブする Pub/Sub トピックの ID。PROJECT_ID: ログをエクスポートするプロジェクトのプロジェクト ID。組織全体にエクスポートするには、--project=PROJECT_IDを--organization=ORGANIZATION_ID --include-childrenに置き換えます。
シンクの書き込みサービス アカウント ID を取得し、宛先トピックに対する Pub/Sub パブリッシャー ロール（
roles/pubsub.publisher）を付与します。WRITER_IDENTITY=$(gcloud logging sinks describe SINK_NAME \ --project=PROJECT_ID \ --format='value(writerIdentity)') gcloud pubsub topics add-iam-policy-binding TOPIC_ID \ --project=DESTINATION_PROJECT_ID \ --member="${WRITER_IDENTITY}" \ --role="roles/pubsub.publisher"
OpenTelemetry 生成 AI の規則
エージェント トレースとプロンプトとレスポンスのログは、生成 AI システムの OpenTelemetry セマンティック規則に大きく依存して、生成 AI テレメトリーのキャプチャ、構造化、レポートの方法を標準化しています。
これらの規則に準拠することは、エージェント トレースにとって重要です。これにより、ツールの実行、取得ステップ、トークン消費など、複雑なマルチステップのエージェント ワークフローを記述するための、ベンダーに依存しないユニバーサルな形式が確立されるためです。この標準化により、 Google Cloudの内外を問わず、さまざまなオブザーバビリティ バックエンドと分析ツール間でシームレスな相互運用性が実現します。
次のステップ
- トポロジグラフとしてエージェントの関係を表示します。
- エージェント トレースを表示して、エージェントの動作をデバッグする。
- エージェントを評価する。