AIPテスト、検証、トラブルシューティング
ある金融機関が Amazon Bedrock（Claude）を使った社内ナレッジ問い合わせAPIを本番運用しています。「特定の質問で時々おかしな回答が返る」という再現性の低い品質問題の調査を依頼されましたが、現状アプリ側のログには最終的なテキスト応答しか残っておらず、モデルへ実際に送られた入力プロンプトやモデルパラメータ、停止理由などが分かりません。監査要件もありデータは暗号化保管が必須です。原因調査の基盤として最も適切な対策はどれですか。
AAmazon Bedrock のモデル呼び出しログ（model invocation logging）を有効化し、入力・出力・メタデータを KMS で暗号化した S3 または CloudWatch Logs に出力する
✓ 正解
モデル呼び出しログは実際にBedrockへ渡された入力プロンプト・出力・推論パラメータ・停止理由などを記録し、S3やCloudWatch LogsへKMS暗号化で出力できるため、再現性の低い異常応答を後から分析でき監査・暗号化要件も同時に満たします。
BAPI Gateway のアクセスログを詳細レベルに上げ、リクエスト/レスポンスのステータスコードとレイテンシーを記録する
API GatewayのアクセスログはHTTPステータスコードやレイテンシーなどリクエストのメタ情報が中心で、モデルへ送られた実際の入力プロンプトや推論パラメータ・停止理由を捕捉できないため、生成品質問題の原因調査基盤としては不十分です。
CAWS X-Ray のトレースを有効化し、Lambda から Bedrock 呼び出しまでのサービス間レイテンシーを可視化する
X-RayはLambdaからBedrock呼び出しまでのサービス間レイテンシーやボトルネックの可視化が目的であり、モデルの入力内容や生成結果そのものを記録しないため、回答品質の異常を調査する用途には適しません。
DAmazon Bedrock Model Evaluation のジョブを毎日実行し、品質スコアが基準を下回った日のデータを抽出して調査する
Model Evaluationは集計された品質スコアの評価ジョブで、個々の異常応答について実際の入力プロンプトやモデルパラメータを記録・特定する仕組みを持たないため、再現性の低い問題の原因究明の基盤には向きません。
解説
再現性の低い品質問題を調査するには、実際にモデルへ渡った入力プロンプト・出力・推論パラメータ・停止理由などの完全な呼び出し記録が必要です。Bedrock のモデル呼び出しログを有効化すると、これらを S3 / CloudWatch Logs に出力でき、KMS による暗号化で監査・データ保護要件も満たせます。問題発生時のリクエストを後から再現・分析できます。
選択肢BのAPI Gatewayアクセスログはステータスやレイテンシー中心で、モデルへの入力プロンプトや停止理由は取得できません。
選択肢CのX-Rayはサービス間レイテンシーの可視化が目的で、生成内容の調査には使えません。
選択肢DのModel Evaluationは集計品質の評価で、個別の異常応答の入力・パラメータを記録・特定する用途には向きません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでAIPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →