Googleの「Agent Anomaly Detection」は、Gemini Enterprise Agent Platform上のAgent Runtimeで稼働し、ADK(Agent Development Kit)for Python 1.2以降で構築された自律型エージェント向けの、推論ベースの監視・監査レイヤーです。GoogleはADK 2.1.0以降の使用を推奨しています。現在はプライベートプレビューとして提供されています。
Agent Anomaly Detectionが監視する対象
Agent Anomaly Detectionは、エージェントが発するトレースを評価し、意図された範囲外で動作していないかを判定します。挙動の異常、疑わしい意図、ポリシー違反をフラグ付けします。
各異常検知結果には、深刻度レベル、検知のきっかけとなった事象の平易な説明、推奨対応が含まれます。検知結果はSecurity Command Centerに公開され、他のセキュリティ検知結果と合わせてトリアージできます。
Agent Anomaly Detectionには、OWASPのAgentic Top 10から選ばれたリスクに対応する検知機能が含まれています。具体的には、ツールの悪用、ID・権限の乱用、エージェント連鎖障害、そして暴走エージェントです。
ツールの悪用には、安全でないツールチェーン、パラメータ操作、間接的なプロンプトインジェクションといったリスクが含まれます。ID・権限の乱用には、動的な信頼委譲、なりすまし(ペルソナ偽造)、メモリのエスカレーション、混乱した代理人(confused-deputy)脆弱性といった問題から生じる不正な操作が含まれます。エージェント連鎖障害には、無限実行ループ、振動するリトライ、障害の伝播、フィードバックループの増幅などが含まれます。暴走エージェントの検知は、宣言された役割を放棄したり、ガードレールを回避したり、システム指示から逸脱したりするエージェントを対象としています。
このシステムはさらに、リソース枯渇やトークン使用量の急増といった運用上のリスクも検知します。
「私たちは現在、ユーザーが自社ビジネスの文脈における『異常』の定義をカスタマイズできるようにする機能に取り組んでいます。これにより、ユーザーは決定論的なルールと組み合わせて、自然言語で柔軟な異常検知ルールを記述できるようになり、エージェントが企業固有のビジネスガイドラインを逸脱した際にフラグを立てられるようになります。さらに、ユーザーは新たなカスタムビジネスロジックの精度を、過去のトラフィックに対して検証できるようになります」と、GoogleのシニアソフトウェアエンジニアであるAchuth Narayan Rajagopal氏は説明しています。
要件とセットアップ
ワンクリックプロビジョニングでAgent Anomaly Detectionを有効化するには、いくつかの前提条件を満たす必要があります。
ロギングおよびオブザーバビリティ用のバケットは、同一の米国マルチリージョン内に存在している必要があります。OpenTelemetryによるトレーシングとロギングはADKを通じて有効化されている必要があり、生のテレメトリはプロンプトの入力とレスポンスの出力を捕捉していなければならず、またenable_tracingを明示的にfalseに設定してはいけません。
リージョナルスキャナーのサービスアカウントには、ロギングおよびオブザーバビリティ用バケットへの十分な読み取りアクセス権限が必要です。ログバケットに対しては、Log AnalyticsとObservability Analyticsも有効化されている必要があります。エージェントは、その設定を検証し登録できるよう、有効なテレメトリデータのフローを持っていなければなりません。
発見されたエージェントは「監視対象エージェント」として表示されます。明示的に有効化されるまで、それらのログやトレースは分析されず、コストも発生しません。要件を満たさないエージェントは発見対象になりません。
異常検知の仕組み
検知速度、コスト、カバレッジのバランスを取るため、トレースとログは複数のレイヤーで分析されます。まず、軽量な第一パスがすべてのトラフィックを対象に統計的な異常をスキャンし、通常とは異なるセッションにフラグを立てます。続いて、LLMベースの推論レイヤーがそれらのセッションを詳しく検証します。
例えば、list_inventoryツールを持つInventory Agentを考えてみましょう。あるユーザーが一度に100件のアイテムを表示するよう要求し、エージェントがオフセットを変えながらそのツールを繰り返し呼び出して、カタログ全体を取得したとします。
このエージェントの動作はエラーや明確なポリシー違反を一切発生させないかもしれません。それでもなお、この活動は通常とは異なる利用パターンを表している可能性があります。第一のレイヤーは、呼び出し回数と繰り返しのパターンに基づき、このセッションを統計的な外れ値として識別します。第二のレイヤーはやり取り全体を検証し、大量バッチかつオフセットを飛ばしていくパターンを組織的なスクレイピングとして特定し、平易な説明を添えた判定結果を返します。さらに詳細な検証が必要な場合には、第三の呼び出しレベルのレイヤーが、会話トレース内の個々のツール実行、実行状態、パラメータの履歴を分析します。
セッション異常分析(出典:Google)
この例では、システムは深刻度「Critical」、確率95%の「リソース枯渇」という検知結果を生成します。この検知結果には、その根拠と推奨対応が含まれており、例えば当該ユーザーに対するlist_inventoryツールのレート制限またはブロック、認可チェックによる一括在庫アクセスの制限、大規模オフセットによるページネーションパターンへのアラート設定などが挙げられます。
検知処理は実際の実行パスの外側で非同期に行われるため、分析対象のリクエストを遅延させることはありません。アプリケーションはAPIを通じて異常検知結果を取得でき、ADKのコールバックやプラグインを利用して深刻度と確率を設定済みのしきい値と比較することで、しきい値を超えた場合に後続のツール呼び出しをブロックしたり、その後のターンを停止したりできます。
翻訳元: https://www.helpnetsecurity.com/2026/09/17/google-agent-anomaly-detection-audit-layer/
