7月24日、AWSが「Detecting silent agent failures with Amazon Bedrock AgentCore optimization」と題した記事を公開した。この記事では、プロダクション環境で動作するAIエージェントの「サイレント障害」を Amazon Bedrock AgentCore optimization で検出・分析するための仕組みが詳しく紹介されている。エラーシグナルを一切出さないまま誤った処理結果を返し続けるという、従来のモニタリングでは捉えられない障害クラスへの具体的な対処法だ。
ダッシュボードが「グリーン」でも、エージェントは壊れている
AIエージェントを本番運用していると、厄介な状況に遭遇することがある。完了率99%、レイテンシ正常、エラーレートゼロ。しかし顧客からは「注文が実行されていない」「在庫APIがタイムアウトしたのに『在庫あり』と表示された」「承認ステップがスキップされた」という苦情が届く。
これがサイレント障害（silent failure）だ。システム側からは正常完了に見えるが、実際の処理結果は誤っている。エラーシグナルを出さないため、従来のモニタリングでは検出できない。問題が発覚するのは顧客のエスカレーション経由で、しかも大規模に影響が出てから数週間後というケースも珍しくない。
さらに別の問題もある。1日数千セッションをこなすエージェントで数百件のエラーが積み上がったとき、どれを優先して調査すべきか。個別のトレースを見れば1セッションの挙動はわかるが、それがトラフィック全体の30%に影響するパターンなのか、3セッションだけのエッジケースなのかは判断できない。
Amazon Bedrock AgentCore は、Amazon Bedrock 上でAIエージェントのデプロイ・実行・管理を行うためのフレームワークだ。その中で AgentCore runtime はエージェントを実行するインフラ基盤を指し、AgentCore optimization はその上で収集されたトレースデータを事後分析するサブ機能に位置づけられる。今回紹介する Insights は、AgentCore optimization が提供する分析機能であり、AgentCore runtime 外のエージェント（CloudWatch ロググループ経由）でも利用可能な点が特徴だ。
Insightsが提供する3つの分析
Insightsはすでに収集済みのトレースデータを消費し、以下の3種類の分析を実行する。
1. 障害パターン発見とRCA（最も実用的な機能）
AgentCore optimization は各セッションのトレースを、11カテゴリの行動的障害タイプに照らして分析する。元記事では幻覚（Hallucination）、誤ったアクション（Incorrect Action）、タスク指示違反（Task Instruction Violation）、オーケストレーションエラー（Orchestration Error）、コンテキスト処理の問題（Context Processing Issue）などが例示されており、残るカテゴリについては元記事に全リストが掲載されている。エラーシグナルに依存せず、ポリシー準拠と行動の正確性を推論するため、サイレント障害を検出できる。
検出された障害はクラスタリングされ、数百セッション分が1つの名前付きパターンに集約される。さらにAgentCore optimizationは実行グラフを遡って根本原因を特定する。セッションはスパン（推論呼び出し、ツール実行、サブエージェント呼び出し）のグラフとして表現され、障害と無関係なブランチを刈り込んでから因果関係を推論する。50ステップのワークフローを、障害につながった特定の実行パスに絞り込むこの枝刈りが、長いセッションでもRCAを実用的にしている。
出力として得られるのは：
- 根本原因の場所（ログ内のスパンID）
- 因果関係の分類
- 修正提案（システムプロンプトの変更、ツール説明の更新、インフラ作業のいずれか）
さらにスコープランキングが重要だ。「Agent Bypasses Information Gathering」が116セッションで発生しているとする。ドリルダウンすると、そのうち114件は「Skipped Prerequisite Information Retrieval」という単一のサブパターンで、残り2件は無関係なエッジケースだとわかる。最大の障害シェアに対処する単一の修正を即座に特定できるのがこの構造の価値だ。
2. ユーザーインテント分析
実際にユーザーがエージェントに送っているプロンプトをクラスタリングし、本番環境でのユースケース分布を可視化する。設計時に想定したユースケースが全体の40%で、30%は部分的にしかサポートしていないケース、残り30%は全く想定していなかったケースといった実態が浮かぶことがある。追加のインスツルメンテーションは不要で、既存のトレースから自動的に得られる。
3. 実行サマリー
各セッションでエージェントが取ったアプローチと達成した結果を抽出し、クラスタリングする。可変長のセッションを扱う階層的な要約戦略を採用。「設計した通りの挙動」と「スケールで実際に起きている挙動」のギャップを可視化する。
実際の検出例：ファイナンシャルエージェントのケース
市場トレンドエージェント（投資分析、株式推奨、セクターパフォーマンスデータを提供）で10セッションを分析した例が紹介されている。
障害分析の結果：「Hallucinated Financial Data Without Tool Invocation」が10セッション中1件で検出された。エージェントはデータ取得ツールを呼び出さず、具体的な財務データや市場レートを事実として提示していた。このセッションはエラーなしで正常完了している。根本原因は「システムプロンプトがツール使用を義務付ける十分な強制機構を持っていない」ことで、修正提案は「数値的な主張の前にツール呼び出しを強制するようシステムプロンプトを強化する」だ。
ユーザーインテント分析の結果：
- プロファイル取得・ポートフォリオ評価：5/10セッション（50%）
- マクロ経済・セクター分析：3/10セッション
- 複数銘柄の比較分析：2/10セッション
トラフィックの半数がプロファイル・ポートフォリオ取得であることがわかる。プロファイル取得が失敗したり古いデータを返したりすると、ユーザーの50%の体験が劣化する。信頼性投資の優先順位がここから決まる。
セットアップ方法
AgentCore コンソールの Optimizations > Insights > Create Insights から設定する。AgentCore runtime にデプロイされたエージェントはエンドポイントを直接選択できるが、AgentCore runtime を使用していない外部エージェントでも、CloudWatch ロググループを指定することで Insights を利用できる。LangChain や独自フレームワークで構築したエージェントであっても、ログを CloudWatch に流していれば対象になる点は覚えておきたい。
主な設定項目は以下の通り。
- 分析対象の選択：Failure analysis / User intent analysis / Execution summaryを個別または組み合わせて指定
- データソースの接続：AgentCore runtimeにデプロイされたエージェントエンドポイントを選択するか、AgentCore runtime外で動くエージェントの場合はCloudWatchロググループを直接指定
- スケジュール：日次・週次・月次の定期実行、または特定期間の単発実行を選択可能
- フィルタとサンプリング：特定セッション条件への絞り込み、トラフィックのサンプリングが設定可能
なお、エージェントの観測・評価ツールとしては LangSmith のような製品も存在するが、AgentCore optimization はAWSインフラ（CloudWatch）との統合を前提とし、既存トレースを追加インスツルメンテーションなしに消費できる点が特徴的なアプローチだ。※編集部の考察
使いどころ
記事では以下のシナリオが挙げられている：
- デプロイ後検証：苦情は増えているがダッシュボードが正常を示している状況
- 週次プロアクティブモニタリング：顧客より先に見えない障害を捕捉する
- スコープランキング評価：数件の苦情が実際の影響の10%未満だったと判明するケース
詳細はDetecting silent agent failures with Amazon Bedrock AgentCore optimizationを参照していただきたい。
