変更要約: 各節に図（figure）を追加＝cert-figure-retrofit。AI-200 第4章を新規作成（シークレット管理＝Key Vault/App Configuration/マネージドID キーレス/RBAC、可観測性＝OpenTelemetry 計装/分散トレース/Application Insights・Azure Monitor/KQL/AI 固有監視＝トークン・コスト・クォータ・生成品質）
4.2可観測性（監視・トレース・ログ）
分散した AI バックエンドの挙動を把握する可観測性——OpenTelemetry による計装、分散トレース、Application Insights / Azure Monitor、KQL によるログ分析、そしてトークン/コスト/品質の監視——を理解します。
イベント駆動・分散の AI パイプラインは、1つのリクエストが複数のサービスにまたがって処理されます。問題が起きたとき「どこで・なぜ遅い/失敗したか」を追えるよう、可観測性（observability）を設計します。標準は OpenTelemetry による計装（コードにトレース・メトリクス・ログを埋め込む）で、収集先として Application Insights / Azure Monitor を使います。
4.2.1分散トレースとログ分析
分散トレース は、1つのリクエストが通った各サービスの処理（スパン）を1本のトレースとしてつなぐ仕組みです。これにより「埋め込み生成は速いが AI 呼び出しで詰まっている」といったボトルネックを可視化できます。収集したログ/メトリクスは KQL（Kusto Query Language）で問い合わせ、エラー率・レイテンシ分布・特定エラーの追跡などを分析します。アラートをしきい値で設定し、異常を早期に検知します。
4.2.2AI 固有の監視
一般的なメトリクス（エラー・レイテンシ）に加え、AI 特有の指標も監視します。トークン使用量とコスト（入力＋出力）、レート制限（クォータ）への到達、そして生成品質（評価＝グラウンデッドネス/関連性、第2章の AI-103 と同様）です。これらを監視・評価することは、責任ある AI（信頼性と安全性・説明責任）を運用で担保することにもなります。
頻出：
①「分散したサービスにまたがる1リクエストを追跡」＝分散トレース（OpenTelemetry で計装）。
②テレメトリ収集先＝Application Insights / Azure Monitor。
③ログ/メトリクスの分析クエリ言語＝KQL。
④AI 固有の監視＝トークン/コスト・クォータ到達・生成品質（評価）。
混同・注意：
①メトリクス（数値の集計）／ログ（イベント記録）／トレース（リクエスト追跡）は別の観点——可観測性は3つを組み合わせる。
②OpenTelemetry は計装の標準で、収集先（Application Insights/Azure Monitor）とは別。
③KQL は分析のクエリ言語であり保存先ではない。
④AI ではコスト/品質も監視対象——一般メトリクスだけでは不十分。
4.2.3この節のまとめ
- OpenTelemetry で計装し、Application Insights / Azure Monitor に収集。分散トレースでリクエストを追跡
- ログ/メトリクスは KQL で分析、しきい値アラートで早期検知
- AI 固有の監視：トークン/コスト・クォータ・生成品質（評価）＝責任ある AI の運用実装
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 分散した複数サービスにまたがる1つのリクエストの処理を1本につないで追跡する仕組みはどれですか？
Q2. トレース・メトリクス・ログをコードに埋め込む（計装する）ための業界標準はどれですか？
Q3. Azure に収集したログやメトリクスを問い合わせて分析するためのクエリ言語はどれですか？
Q4. 一般的な監視（エラー・レイテンシ）に加えて、AI バックエンドで特に監視すべき指標はどれですか？
Q5. 可観測性の3つの柱（メトリクス・ログ・トレース）の関係として正しいものはどれですか？