Amazon Bedrock AgentCore、エージェントの静かなる失敗を検出

大規模に AI エージェントを運用している場合、Amazon Bedrock AgentCore は、これまで経験はあっても検出が難しかった洞察の一種を明らかにします。それは「ダッシュボード上ではすべて緑色（正常）に見える」状態です。完了率が 99% で、レイテンシーも健全で、エラーの急増もない。それなのに、顧客からは不正確な結果に関する苦情がひっそりと届き始めています。

実際には実行されなかった注文の変更や、在庫 API のタイムアウトにより「在庫あり」と表示された商品、あるいはスキップされてしまった承認ステップなどです。これらはインフラ上の問題とは異なる「行動上の失敗」です。システム側から見れば正常に完了しており、ヘルスチェックも通過します。そのため、大規模な影響がユーザーに及んでから数週間経って顧客からのエスカレーションを通じて初めて表面化することが多いのです。

エラー信号を発生するケースであっても、別の課題が存在します。1 日に数千セッションを処理するエージェントで数百件のエラーが発生した場合、どれを優先して対応すべきかです。個別のトレースを確認すれば単一セッションでの出来事はわかりますが、それがトラフィックの 30% に影響するパターンなのか、それとも数セッションだけの例外事象なのかを見極めることはできません。

Amazon Bedrock AgentCore の最適化機能は、エラー信号を一切生成しない「沈黙の失敗」を含む、デプロイ済み AI エージェントの行動上の不具合を発見し、その原因を説明し、優先順位をつけて対応するためのインサイト（洞察）を提供します。この機能により、観測可能性のモデルは事後のトレース調査から、先行的なパターン検知へとシフトします。これにより、失敗の特定、影響範囲の把握、そして優先度順での修正が可能になります。

本記事では、AgentCore 最適化におけるインサイトがどのように機能するか、設定方法、および実際のエージェントに対して適用した際にどのような洞察が得られるかについて解説します。

Amazon Bedrock AgentCore 最適化が提供するインサイトとは

インサイトは、既存の観測スタックよりも一段上位で動作します。ツールがすでに収集しているトレースデータを消費し、それを実行可能な行動に関する知見へと変換します。これにより、個々のセッションでの失敗に留まらず、スケールした環境全体に影響を与える広範なパターンを理解するための調査機能が強化されます。

以下の図は、AgentCore がインサイトを配信するために実施する一連の分析を示しています。各セッション分析メソッドは、それぞれのセッションから 1 つ以上の属性を抽出します。これらの属性は、各分析メソッドごとに独立してクラスタリングされ、さらに解釈しやすくするため各クラスタが要約されます。

インサイトレポートでは、以下の内容が提示されます。

根本原因分析を伴う失敗パターンのランク付け

数百セッションにわたるクラスターをランク付けして表示します。事前定義されたカテゴリやフィルタは不要です。各クラスターには、影響を受けたセッション全体を網羅する集約的な説明が付与され、個別のトレースを開かなくても具体的なアクションを起こせるレベルで詳細が示されます。

パターンは、影響を受けるセッションの割合に応じて順序付けられているため、重要な問題と単なる例外ケースを即座に区別できます。この機能がない場合、開発者は勘頼りでエラーの優先順位を決めざるを得ず、数百ものトレースを手動で確認しない限り、体系的な問題を特定することはできません。

ユーザー意図の分析

異なるシナリオにおけるユーザーとエージェントの相互作用を明らかにします。本番環境のエージェントは、設計時に想定していた範囲から外れたリクエストを受け取ることも珍しくありません。意図分析機能を使えば、ユーザーが実際に何を求めているかの分布を確認できます。

これにより、対応すべきカバレッジの隙間や、守るべきスコープの境界を特定できます。既存のトレース収集以外に追加の計装（インストルメンテーション）を行う必要はありません。

実行状況の洞察

異なるシナリオにおけるエージェントの応答挙動を可視化します。実行状況の洞察からは、エージェントが採用している戦略や、セッション中のアクション進行状況、そして設計意図から実際の動作がどこで乖離しているかが分かります。

これは「エージェントに何を実現させるつもりだったか」と「大規模運用時に実際に何をしているか」のギャップを埋めるものです。

各機能の詳細解説

ここからは、それぞれの機能を詳しく見ていきましょう。

Failure pattern discovery

AgentCore は、セッションのトレースを行動失敗タイプの構造化された分類体系に対して分析します。これにより、ハルシネーション（幻覚）、誤った動作、タスク指示違反、オーケストレーションエラー、コンテキスト処理の問題など、11 のカテゴリに分類される失敗を検出します。この分析は単なるエラー信号に依存するのではなく、ポリシー準拠や行動の正しさについて推論を行います。これにより、目に見えない「サイレント・フェイル」も検知可能になります。

検出された各失敗には、トレース上の位置、カテゴリ、そして何が起きたのかを自然言語で記述した説明が付与されます。これらの説明はさらにグループ化され、クラスタリングされます。その結果、数百セッションにわたる個別のトレースエントリではなく、単一の「名前付きパターン」として表面化します。

以下の図は、失敗のクラスタリングと根本原因分析（RCA）パイプラインを示しています。各セッションで失敗を特定し、それらをサブクラスタに分類します。そして、各失敗サブクラスタに含まれるセッションごとに、根本原因の説明を生成します。

AgentCore は、各失敗クラスタに対して実行グラフを遡って追跡し、単に失敗が発生した場所だけでなく、その原因がどこにあるかを特定します。セッションは、推論呼び出しやツール実行、サブエージェントの呼び出しなどを表すスパン（span）からなるグラフとして表現されます。システムはまず、失敗に関係ない分岐を切り捨てた上で、因果関係の分析を行います。この剪定処理により、50 ステップに及ぶワークフローの中から失敗に至る特定のパスに焦点が絞られ、長期セッションにおける根本原因分析（RCA）が可能になります。

出力では、根本原因の場所（ログ内のスパン ID）、因果関係の分類、そして修正提案（システムプロンプトの変更、ツールの説明更新、インフラ対応など）が表示されます。これらの知見はクラスタ内で根本原因をグループ化し、「100 件の失敗のうち 90 件が同じ根本原因と同一の修正タイプに起因している」といった洞察を提供します。

クラスタリングだけでは「どのような種類の失敗が存在するか」がわかりますが、スコープランキングによって「どの失敗が最も重要か」を判断できます。各失敗クラスタには影響を受けたセッション数が付与され、クラスタは分析対象となった全セッション数に対する相対的なカウント順に並べ替えられます。この二段階の階層構造により、広範な失敗カテゴリと具体的なサブパターンが明確に区別されます。

上位クラスタでは「エージェントが情報収集をバイパスしている」という事象が 116 セッションに発生していると表示されます。詳細を確認すると、そのうち 114 セッションは「必須情報の取得をスキップした」という単一のサブパターンによるものであり、残りの 2 セッションは無関係なエッジケースであることがわかります。この構造により、失敗の大部分を解決する単一の修正点を即座に特定できます。

ユーザー意図分析

障害検出以外にも、AgentCore ではエージェントの振る舞いに関する 2 つの追加的な視点を提供します。「ユーザー要求クラスタリング」機能では、実際にユーザーが送信したプロンプトを埋め込み・グループ化することで、本番環境でのユースケースの分布を把握できます。例えば、設計時に想定していたユースケースがトラフィックの 40% を占めている一方で、部分的にしか対応できていないものが 30%、そして全く予想していなかったユースケースが残り 30% であるといった発見も可能です。

実行インサイト

「実行サマリー」では、各セッションでエージェントがどのようなアプローチを採用し、どのような結果に至ったかを抽出します。これは長さの異なるセッションを柔軟に処理する階層的な要約戦略を用いており、その後 AgentCore がこれらのサマリーをクラスタリングすることで実行パターンを可視化します。これにより、エージェントが採用する一般的な戦略や、それらが成功・失敗とどう関連しているか、そして実際の振る舞いが設計意図からどこで乖離しているかが明らかになります。

これらを組み合わせることで、単なるエラー検出を超え、システムがどのように利用され、どのように応答しているかを理解するための、本番環境におけるエージェントの行動マップを構築できます。

Amazon Bedrock AgentCore のインサイト設定方法

Amazon Bedrock AgentCore の観測機能でテレメトリデータが記録されているエージェントがある場合、インサイトを活用することで、そのエージェントの失敗モードやユーザーの意図、実行サマリーを理解することが可能です。

AgentCore コンソールの「Optimizations > Insights > Create Insights」から、インサイトの設定を作成できます。

分析対象の選択

「生成するインサイト（Insights to generate）」セクションで、分析したいタイプを選択してください。

• 失敗分析 (Failure analysis): セッション全体を通じて、根本原因を特定し、不正確または不完全な結果がどこで発生したかを浮き彫りにします。
• ユーザー意図分析 (User intent analysis): ユーザーがエージェントに送信しているリクエストをクラスタリングし、彼らが何を達成しようとしているのかを把握できます。
• 実行サマリー (Execution summary): セッションごとにエージェントが実行したアクションとその解決に向けた進行状況を抽出します。

これらは個別に実行することも、まとめて実行することも可能です。

エージェントの接続

セッションデータに対してインサイトを指向させるには、以下の 2 つの方法があります。

• エージェンシーエンドポイントを選択: AgentCore ランタイムを通じてデプロイされたエージェントを選ぶと、関連する Amazon CloudWatch ロググループが自動的に選択されます。
• Amazon CloudWatch ロググループを選択: エージェントが AgentCore ランタイム外で動作している場合は、トレースデータが格納されるロググループを直接指定してください。

スケジュールの設定

インサイトには、以下の 2 つのモードを設定できます：

Recurring（定期） は、選択した間隔で自動的にレポートを生成します。日次、週次、月次の分析頻度を組み合わせて有効化することも可能です。一度作成すると、追加の操作なしにバックグラウンドでセッションの解析が実行されます。

One-time（一時） は、特定の期間に対して単一のレポートを生成します。デプロイ後のレビューや苦情に基づく調査、説明が必要なメトリクス異常などに対応する際に使用してください。

「作成後にこの設定を有効にする」チェックボックスはデフォルトでオンになっており、保存直後に処理が開始されます。

オプション：フィルター、サンプリング、権限

「Filters and sampling（フィルターとサンプリング）」を展開して、分析対象のセッション条件を絞り込んだり、トラフィックの一部をサンプリングしたりできます。また、「Permissions（権限）」を展開すると、ログへのアクセスに使用する IAM ロールを設定できます。

設定が完了したらCreate Insights（インサイト作成）を選択し、選択したスケジュールに基づいて最初のレポートが利用可能になります。

インサイトの実践例

投資分析、株式推奨、セクターパフォーマンスデータを提供する market trends agent（市場動向エージェント） を想定してください。10 回のセッションを実行した後、各インサイト解析ビューで確認できる内容は以下の通りです。

失敗分析

インサイトから特定された失敗カテゴリは「ツール呼び出しなしの幻覚的な金融データ」です。10 セッションのうち 1 つで発生しました。このエージェントは、利用可能なデータ取得ツールを呼び出すことなく、具体的な金融数値や市場レート、数値主張を生成し、あたかも事実であるかのように提示してしまいました。これは、主張を行う前に実際のデータを取得するよう指示されたシステムプロンプトの要件に違反しています。

根本原因である「ツール呼び出しなしの捏造データ主張」は、明記された要件と実行時の強制力との間にギャップがあることに起因します。システムプロンプトでは回答を実際のデータに基づかせるよう指示していますが、事実上の主張を行う前にツールの使用を義務付けるための十分な強制メカニズムが欠けています。その結果、エージェントはデータ検証のステップを迂回し、未検証な情報を権威ある情報として提示してしまいました。

この失敗ではエラーが発生していません。セッション自体は正常に完了しました。しかしインサイトを確認することで、根本原因や影響を受けた具体的なセッション、そして解決への明確な道筋が見えてきます。具体的には、数値主張を行う前にツールの呼び出しを強制するようシステムプロンプトを強化することが必要です。

ユーザーの意図分析

エージェントに対してユーザーが何を求めているかを理解するには、通常、セッションのトランスクリプトを手動で読み込む必要があります。しかし、「意図分析」機能を使えば、すでに収集したトレースデータから自動的にその分布を把握できます。

ここでは、ユーザーのリクエストを 3 つのカテゴリにクラスタリングし、実際にユーザーがエージェントに何を求めているかの実態を示しています：

• プロファイルの取得とポートフォリオ評価（全セッションの 5/10）：既存のポートフォリオデータを表示したり、パーソナライズされた投資プロファイル情報を求めたり、リスク許容度に基づいたセクター別のおすすめを依頼するケースです。
• マクロ経済およびセクター分析（3/10 セッション）：市場全体の状況やセクターレベルのトレンドについて質問するケースです。
• 複数銘柄の比較・分析（2/10 セッション）：特定の銘柄同士を比較するケースです。

トラフィックの半分はプロファイルやポートフォリオの取得に関連しています。これは、まず信頼性の強化に注力すべき箇所を示唆しています。もしプロファイルの参照が失敗したり、古くなったデータが返されたりすれば、ユーザーの 50% に体験を損なう結果になります。

実行サマリー

エージェントが本来何のために設計されたかは知っていても、大規模なセッション全体で実際にどのような動作が行われているかについては、可視化の範囲に限界があります。この「実行サマリー」機能は、そのギャップを埋めるものです。

ここでは市場エージェントの振る舞いを、3 つの実行パターンに分類して示しています：

多セクター金融分析とポートフォリオ配分（10セッション中6回）：エージェントは市場の概要データ（VIX、セクターのパフォーマンス、センチメント）を取得し、防衛的なセクターを分析。さらに、コカ・コーラ (KO)、プロクター・アンド・ギャンブル (PG)、ジョンソン・エンド・ジョンソン (JNJ)、ユニオン・パシフィック (UNH) などの大型株の個別データを取得し、具体的な配分比率とリスク調整済みの推奨を含む多セクター配分フレームワークを構築します。

プロファイルファーストの明確化と情報収集（10セッション中2回）：エージェントは行動に移す前に、まずユーザーのプロファイルを理解することに優先順位を置きます。

AI とセクターインテリジェンスを活用した複数銘柄の比較分析（10セッション中2回）：エージェントはセクターレベルの文脈を加味しながら、複数の銘柄を比較します。

これらの結果から、主要な実行パターンとしてエージェントがアドバイザリーワークフローをエンドツーエンドで完遂する傾向が浮かび上がります。一方、残りの小規模なパターンからは、これとは異なる行動経路が存在することも読み取れます。

結論

Amazon Bedrock AgentCore の最適化機能は、エージェントが「静かに誤った判断」を下している際にその実態を可視化する強力なツールです。デプロイ後に苦情が急増するもののダッシュボードの数値には異常が見られない場合、この機能を用いて事後検証を行うことで根本原因を特定できます。また、顧客に問題が発覚する前に「見えない障害」を検知するための週次モニタリングにも活用可能です。

さらに、限られた数の苦情が実は全体の 10% もない影響範囲に留まっている場合でも、その実態を評価・ランク付けする際にも役立ちます。システムプロンプトの変更を特定の時間枠で検証する場合も、苦情の背景にあるセッションを追跡する場合も、基本となるワークフローは同じです。対象となるセッションを提出し、ランク付けされたパターンを受け取り、具体的な根本原因に対してアクションを起こすという流れです。

Amazon Bedrock AgentCore の最適化機能で insights を有効にすれば、従来のダッシュボードでは捉えきれなかった重要な情報が明らかになります。詳細については ドキュメント をご覧ください。

謝辞

この機能の実現に貢献された科学者およびエンジニアリングチームの皆様に感謝いたします：Sanjana Agarwal、Abhimanyu Siwach、Vincent Chen、Swarnim、Frankie Kim、Stephanie Yuan、Aron Thakur、Jaejin Cho、Muhyun Kim、Arron Bailiss、Shoaib Javed、Gitika Jha、Michael Fan。

著者について

Vivek Singh

AWS AgentCore の観測、評価、行動分析を担当するプロダクトリードです。Vivek は、企業が本番環境で AI エージェントの振る舞いを理解・測定・改善できる製品を開発しています。これにより、プロトタイプと生産レベルの自律システムとの間に存在するギャップを埋めることを目指しています。

彼の業務範囲は、計測機能の実装から自動化された評価フレームワーク、そして大規模なエージェントワークフローを透明性・テスト可能性・信頼性の高いものにするための最適化ツールまで多岐にわたります。仕事以外では、F1、チェス、テニス、カレッジフットボール、サッカーなど、おそらく健康には良くないほどの多くのスポーツを楽しんでいます。また、ガーデニングやシアトル近郊の美味しいベーカリーを探すことも好きです。

Bharathi Srinivasan

AWS の責任ある AI に関する技術的な市場展開を担当する Bharathi は、最先端の AI コンセプトを組織が安全に実環境へ移行できるよう支援しています。AI の信頼性と開発者のエンパワーメントに情熱を注ぐ彼女は、大規模言語モデル（LLM）の評価、信頼性、セキュリティに関する研究論文やコードサンプルを頻繁に公開しています。

趣味は山岳地帯のトレイル探索やバックカントリーでの冒険の準備、そして韓国ドラマを楽しむことです。