変更要約: 各節に図（figure）を追加＝cert-figure-retrofit。AI-300 第4章を新規作成（ドメイン4「生成 AI の品質保証と可観測性」: 評価=テストデータセット/データマッピング/AI 品質メトリクス(根拠性/関連性/一貫性/流暢性)/リスク・安全性評価/自動評価ワークフロー、可観測性=Foundry 継続監視/パフォーマンス(レイテンシ/スループット/応答時間)/コスト(トークン消費/リソース使用)/ログ・トレース・デバッグ）
4.2生成 AI アプリ・エージェントの可観測性
Foundry での継続的な監視、パフォーマンスメトリクス（レイテンシ・スループット・応答時間）の監視、コストメトリクス（トークン消費量・リソース使用量）の追跡と最適化、そして本番のトラブルシュートのための詳細なログ・トレース・デバッグの構成を理解します。
生成 AI アプリは本番で継続的に監視し、性能・コスト・障害を把握して改善します。これが 可観測性（observability）で、GenAIOps の運用ループを支えます。
4.2.1パフォーマンスとコストの監視
Foundry の 継続的な監視で、パフォーマンスメトリクス（レイテンシ＝応答までの遅延、スループット＝単位時間あたりの処理量、応答時間）を追跡します。生成 AI 特有の重要指標が コストメトリクスで、特に トークン消費量（入力＋出力トークン）とリソース使用量を監視・最適化します。トークン消費はそのままコストに直結するため、プロンプトの簡潔化やキャッシュ、適切なモデル選択でコストを下げます。
4.2.2ログ・トレース・デバッグ
本番のトラブルシュートには 詳細なログ・トレース・デバッグが必要です。トレースは、リクエストがアプリ→検索（RAG）→モデル→ツールとどう流れたかを可視化し、遅延や失敗の原因を特定します（分散トレース）。エージェントのように複数ステップが連なる場合、トレースは特に有効です。ログとあわせて、品質劣化やエラーの根本原因を素早く突き止めます。
| 観点 | メトリクス/手段 | 要点 |
|---|---|---|
| 応答の速さ | レイテンシ／応答時間 | 遅延を監視 |
| 処理量 | スループット | 単位時間あたりの処理 |
| コスト | トークン消費量／リソース使用量 | トークン＝コスト直結 |
| 原因特定 | ログ／トレース／デバッグ | リクエストの流れを可視化 |
混同に注意：
①パフォーマンス（レイテンシ/スループット）とコスト（トークン消費）は別の監視軸——生成 AI ではトークン消費が重要。
②ログ（記録）とトレース（リクエストの流れの可視化＝原因特定）は役割が違う。
③可観測性は「デプロイ後」も品質と効率を保つための運用。
「測りたいこと → 手段」：例「応答の遅延を監視」＝レイテンシ、「処理量を監視」＝スループット、「コストを抑える」＝トークン消費量の監視・最適化、「遅延や失敗の原因を特定」＝トレース（分散トレース）、「本番の不具合を調査」＝詳細なログ＋デバッグ。
4.2.3この節のまとめ
- Foundry で継続監視：パフォーマンス（レイテンシ/スループット/応答時間）
- コストはトークン消費量/リソース使用量で監視・最適化（トークン＝コスト直結）
- ログ・トレース・デバッグでリクエストの流れを可視化し原因を特定
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 生成 AI のコストに直結するため、特に監視・最適化すべきメトリクスはどれですか？
Q2. リクエストがアプリ→検索→モデル→ツールとどう流れたかを可視化し、遅延や失敗の原因を特定するのはどれですか？
Q3. 応答までの遅延を表すパフォーマンスメトリクスはどれですか？
Q4. 生成 AI アプリを本番で継続的に監視し、性能・コスト・障害を把握する運用の考え方はどれですか？
Q5. トークン消費量を抑えてコストを下げる方法として適切でないものはどれですか？
Q6. ログとトレースの役割の違いとして正しいものはどれですか？