azure-recipe-user ■ 1. なぜLLMに「可観測性」が必要なのか
システム運用における可観測性（Observability）は本来、“内部状態が外から観測できるようにする仕組み” のことを指します。
ところが、LLMを組み込んだシステムでは以下の理由から 可観測性が従来以上に重要になります。
● LLM特有の“見えにくい振る舞い”
- 出力が確率的で、再現性が低い
- 入力（プロンプト）によって挙動が大幅に変わる
- RAG・エージェント・ガードレイヤなど多数の連携ポイントを持つ
- セキュリティ事故が「ログが無いと原因特定できない」
特に ログが不十分なAIサービスは“監査不能なブラックボックス”になる危険があります。
可観測性の整備は、安全性・品質・改善サイクルのすべての起点 と言えます。
■ 2. LLMシステムで「必ずログに残すべき」項目
LLMアプリケーションは、従来のWebアプリより記録すべき情報が多くなります。
以下は、本番運用に必須のログ項目です。
◆ ① 入力ログ（Input Logging）
| 項目 | 目的 |
|---|---|
| ユーザー入力プロンプト | 誤答・不適切出力の“原因”を追跡するため |
| 入力前のサニタイズ結果 | 静的検査が正しく働いているか確認 |
| PIIマスキング後の内容 | 個人情報を残さずに監査可能にする |
※個人情報を含む生データはログに残さないのが原則。
◆ ② RAG / 外部データ利用ログ
| 項目 | 目的 |
|---|---|
| 検索クエリ（Embeddingベクトルのハッシュ等） | 検索挙動の再現 |
| ヒットしたドキュメントID・スコア | Lineageとの連動。誤引用の原因追跡 |
| アクセス制御判断（RBAC判定結果） | 権限制御の妥当性を確認 |
◆ ③ モデル応答ログ（Output Logging）
| 項目 | 目的 |
|---|---|
| モデルの生成結果 | 不適切出力の分析・改善のため |
| Content Safetyの判定結果 | 安全フィルタが何を検知したか |
| 再生成（Retry）が発生したか | 安定性の問題検知 |
◆ ④ システム側の制御ログ（Decision Logging）
AIシステムは複数の判断レイヤをもつため、その“判断”自体を記録する必要があります。
例：
- 「禁止語検知 → リジェクト」
- 「類似度が閾値を超えたためセマンティックキャッシュを採用」
- 「Agent実行をユーザー承認待ちに変更」
- 「RAG検索結果が0件 → fallback回答へ」
これらの判断記録がないと、 インシデント時に“どこで何が起きたか”を再現できません。
◆ ⑤ 活用状況ログ（Usage Metrics）
一般的なメトリクスもAIでは重要なヒントになります。
- API応答時間
- トークン使用量（過剰利用の検知に有効）
- エラー率（モデル側 or ネットワーク側）
- 高負荷の時間帯
これらは 性能監視（SRE領域）とセキュリティ監査の両方に役立ちます。
■ 3. ログをどう分析し、どんな異常を見つけるか
可観測性の目的は「記録すること」ではなく、その情報から“異常”や“改善点”を導くことです。
◆ ① セキュリティ異常の検知
例：
- プロンプトインジェクションを示唆する入力
「前の指示を無視して」
「システムプロンプトを開示して」 - RAGの権限外文書へのアクセス試行
- Agentic AI が禁止ツールを呼び出そうとした痕跡
これらは SIEM に取り込むことで自動アラート化 も可能です。
◆ ② サービス品質の問題検知
- 特定質問への誤答率が高い
- 特定時間帯のみ応答遅延
- 特定部門からのアクセスが偏る
- キャッシュヒット率が低下
改善ポイントが可視化されます。
◆ ③ モデル改善のヒント
- 再生成が多い質問 → プロンプト改善／RAG改善の候補
- よく参照される文書 → 更新優先度が高い
- Content Safety の警告が多い → ガードレール見直し
ログは “改善サイクル” の材料として最強の資源です。
■ 4. 監視体制の構築──インシデント対応までつなげる
可観測性は単体の仕組みではなく、「収集 → 集約 → 可視化 → アラート → 対応」 の一連の流れを設計する必要があります。
◆ ① 収集
アプリケーションログ、LLMログ、RAGログ、Agentログを集約。
◆ ② 集約（ログ基盤）
代表例：
- Azure Monitor / Log Analytics
- AWS CloudWatch + OpenSearch
- Datadog
- Splunk / Elastic / SIEM系
AI専用のログビューを作ると管理しやすい。
◆ ③ 可視化（ダッシュボード）
- モデル応答の成功率
- エラー件数
- 不適切出力の検知件数
- アクセス数・負荷傾向
- RBAC拒否件数
◆ ④ アラート設計
異常パターンをルール化する。
例：
- 「システムプロンプト漏洩」に該当する出力 → 即通知
- 禁止ツール呼び出し → 自動停止
- RAGで権限外検索が発生 → 管理者に通知
- 短時間で大量の外部API呼び出し → 不正利用疑い
◆ ⑤ インシデント対応プロセスとの統合
重要なのは、ログ → 監視 → 検知 → 初動対応 → 原因分析 → 再発防止 までつなげること。
扱ったガイドライン化や、監査ログ設計とも強く関係します。
■ まとめ：可観測性は“安全なAI運用”の必須基盤
LLMはブラックボックス性が高く、可観測性が無いと、問題発生時に“何が起きたか”を把握できません。
本記事の要点：
- 入力・出力だけでなく 判断ログ・RAGログ・安全フィルタログ まで残す
- ログ分析により 異常検知・品質改善・セキュリティ対応 が可能
- ダッシュボード化・SIEM連携により 運用体制が整う
- インシデント対応と結びつけて 継続的な強化サイクル を作る
可観測性を整えることは、
“AIサービスを責任を持って運用するための最低ライン” でもあります。
本記事は、ナレッジコミュニケーションによる生成AIセキュリティ支援の実務知見をもとに執筆しています。
安全にAIを活用するための導入支援・運用設計をご希望の方は、ぜひご相談ください。
👉 AIセキュリティ支援サービス
