あるSaaS企業がAmazon Bedrockを使ったドキュメント要約機能を本番運用しています。週に数件、モデルが指示と無関係な内容を生成したり要約に関係のない文章が出力に混入するという異常な応答が報告されています。問題の再現性が低くテスト環境では確認できないため、本番環境で問題が発生したリクエストを事後的に特定して原因を究明したいと考えています。最も効果的なアプローチはどれですか？
Amazon Bedrockのモデル呼び出しロギング（Model Invocation Logging）は、InvokeModel / InvokeModelWithResponseStream APIのデータプレーンを記録する機能です。アカウントレベルで有効化すると、全推論リクエストの入力プロンプト・モデルの出力テキスト・トークン使用量・モデルIDなどがS3バケットおよびCloudWatch Logsに保存されます。これにより事後的にCloudWatch Logs Insightsで問題の発生したリクエストをクエリ検索し、無関係な内容が混入した出力を特定できます。また入力プロンプトも保存されているため、特定のユーザー入力がプロンプトインジェクションを引き起こしているかどうかも合わせて検証できます。 選択肢BのCloudTrailはBedrock APIのコントロールプレーン操作（モデル設定変更・ポリシー変更）を記録しますが、実際の推論リクエストの入力・出力内容（データプレーン）は記録しないため、異常な応答内容の調査には使えません。 選択肢CのCloudWatch Alarmsによるトークン数監視は出力が長すぎる場合のアラートは可能ですが、問題が必ずしも長い出力として現れるとは限らず、また問題リクエストの入力内容を保存・参照する手段が別途必要です。 選択肢DのProvisioned Throughputはモデルバージョンを固定してスループットを確保する機能であり、特定の入力内容によって引き起こされる異常応答の原因調査には寄与しません。