AIPテスト、検証、トラブルシューティング
あるヘルスケア企業が、Amazon Bedrock AgentsとLambdaアクショングループで構成した診療予約アシスタントを開発しています。テスト中、エージェントが特定の複雑な依頼（複数条件での空き枠検索）に対して、定義済みのアクショングループを呼ばずに自然言語で「該当する枠はありません」と回答してしまう事象が散発します。Lambda単体テストでは該当条件で正しく枠を返すことを確認済みです。この問題の原因を切り分け、エージェントがツールを呼ばずに応答した経緯を追跡するために最も有効な手段はどれですか。
AInvokeAgentのレスポンスでトレース（trace）を有効化し、各ステップのオーケストレーション理由・モデルの推論（rationale）・アクション選択結果を確認する
✓ 正解
トレースはオーケストレーション各ステップのモデル推論(rationale)とアクション選択結果を記録し、なぜツールを呼ばずに応答したかの経緯を直接追えるため、原因切り分けに最も有効でアクション定義の不備特定にもつながる。
BCloudTrailでInvokeAgent APIの呼び出しログを取得し、リクエストパラメータとレスポンスのステータスコードからツール呼び出し有無を判定する
CloudTrailはAPIレベルの監査ログでInvokeAgentの呼び出し自体は記録するが、エージェント内部の推論過程やどのアクションを選んだ/選ばなかったかは記録しないため、ツール未呼び出しの経緯を追跡できない。
CLambdaの実行ログをCloudWatch Logsで確認し、アクショングループが呼ばれた回数とエラー率からエージェントの挙動を推定する
ツールが呼ばれていない事象ではLambdaログ自体が出力されず、呼ばれなかった理由を説明できないため、エージェントがなぜツール選択を回避したかの原因切り分けには使えない。
DBedrock Guardrailsのログを有効化し、ブロックされたツール呼び出しがないかをフィルタリングして原因を特定する
Guardrailsログはコンテンツのブロック有無を記録するもので、今回はブロックではなくモデルがツールを選ばなかった事象のため、推論経緯やアクション選択の判断過程を追跡できない。
解説
Bedrock Agentsのトレース機能は、エージェントのオーケストレーション各ステップでモデルがどう推論し（rationale）、どのアクショングループ/関数を選択した（または選択しなかった）かを段階的に記録するため、ツールを呼ばずに応答した経緯の切り分けに最適。
トレースを見れば、アクショングループの説明文やパラメータ定義が不十分でモデルが該当ツールを選べなかったのか、入力解釈で誤ったのかを特定でき、根本原因（多くはアクション/パラメータの記述不足）の改善につながる。
選択肢BのCloudTrailはAPI監査ログでありエージェント内部の推論やツール選択の経緯は記録しない。
選択肢CのLambdaログはそもそもツールが呼ばれていない事象では出力されず、呼ばれなかった理由を説明できない。
選択肢DのGuardrailsログはブロック有無のみで、ツールを呼ばなかった推論経緯は追えない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでAIPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →