変更要約: 初版: ドメイン4（運用効率と最適化）の3節を作成
4.3GenAI アプリケーションのモニタリング
FM アプリの可観測性を学びます。CloudWatch でのトークン使用/ハルシ率/応答品質、Bedrock Model Invocation Logs、異常検知、ツール呼び出しのオブザーバビリティ、golden dataset による幻覚検出を扱います。
GenAI は従来 ML にない固有の故障モード（幻覚・応答ドリフト・トークン急増）を持ちます。運用メトリクスに加え、品質・コストの GenAI 特化メトリクスを監視します。
4.3.1可観測性の構成要素
- 運用＋GenAI メトリクス：CloudWatch でレイテンシ/エラーに加え、トークン使用・プロンプト有効性・ハルシ率・応答品質を追跡。
- Model Invocation Logs：Bedrock Model Invocation Logs で各リクエスト/レスポンスを詳細分析する。
- 異常検知：トークンのバースト/応答ドリフトの異常検知、コスト異常検出、パフォーマンスベンチマーク。
- GenAI 固有のトラブルシュート：golden dataset で幻覚検出、出力 diff で応答一貫性、推論経路トレースで論理エラーを特定。
「リクエスト/レスポンスの詳細ログ＝Bedrock Model Invocation Logs」「幻覚を継続検出＝golden dataset との比較」「トークン使用/ハルシ率を監視＝CloudWatch カスタムメトリクス」「ツール呼び出しの可観測性」 は頻出です。X-Ray は分散トレースに使えます。
監視は「運用」と「GenAI 固有」を重ねます。基本は CloudWatch でレイテンシ・エラー・スループットを見つつ、GenAI 特化メトリクス（トークン使用量・プロンプト有効性・ハルシネーション率・応答品質・コスト）をカスタムメトリクス/ダッシュボードで可視化し、ビジネス影響メトリクスも併記します。詳細分析は Bedrock Model Invocation Logs（各呼び出しの入出力を S3/CloudWatch Logs へ）で行い、X-Ray でサービス境界をまたいでトレース。異常はトークンのバーストパターンや応答ドリフトの異常検知、コスト異常検出 で捕捉します。GenAI 固有の故障は golden dataset（期待回答セット）との比較で幻覚を検出、出力 diff で応答一貫性を確認、推論経路トレースで論理エラーを特定。エージェントはツール呼び出しのオブザーバビリティ（呼び出しパターン/多エージェント協調）を、ベクトルストアは検索性能/データ品質を監視します。フォレンジック用途の監査ログも残します。
| 目的 | 使うもの | ポイント |
|---|---|---|
| 詳細な呼び出し分析 | Bedrock Model Invocation Logs | 入出力を記録 |
| GenAI メトリクス監視 | CloudWatch カスタムメトリクス | トークン/ハルシ率/品質 |
| 幻覚の継続検出 | golden dataset 比較 | 期待回答との差分 |
| 分散トレース | X-Ray | サービス境界をまたぐ |
ひっかけ： 「レイテンシとエラー率だけ見ていれば GenAI の運用監視は十分」は誤りです。幻覚率・応答品質・トークン使用などの GenAI 固有メトリクスと golden dataset 比較が必要。また「Model Invocation Logs は課金専用」も誤り（リクエスト/レスポンスの詳細分析・品質監視に使う）。
4.3.2この節のまとめ
- 詳細分析＝Model Invocation Logs／GenAI 監視＝CloudWatch カスタムメトリクス（トークン/ハルシ率/品質）
- 幻覚検出＝golden dataset 比較／トレース＝X-Ray
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 本番の Bedrock 呼び出しについて、各リクエストとレスポンスの内容を詳細に記録して品質分析や監査に使いたい。最適なのは？
Q2. RAG ボットの回答に幻覚が増えていないかを継続的に検出する仕組みを作りたい。最適な手段は？
Q3. GenAI アプリのコストと品質を運用監視したい。従来の運用メトリクスに加えて追うべき GenAI 固有メトリクスはどれ？