記事ライフサイクル・運用 / AI設計 / architecture
AIシステムのオブザーバビリティとSLO設計
質問から検索・生成・検証・承認・実行までを記録し、誤回答の原因を追跡できる運用を考える。技術指標と品質指標を分け、SLOと異常時の対応を設計する。
更新履歴
読む目的： AI導入・責任・評価
目次
AIシステムのオブザーバビリティとSLO設計
種別：運用設計 / 監視設計 適用対象：生成AI、RAG、QAチャット、AIエージェント 対象工程：運用 / 監視 / 事故調査 / 改善
はじめに
AIシステムが動いていることと、正しく役立っていることは違う。
サーバーが正常でも、AIが古い文書を使って回答しているかもしれない。エラーが出ていなくても、答えるべき質問を大量に拒否しているかもしれない。
システムの内部で何が起きたかを、外部の記録から調べられる性質をオブザーバビリティという。
AIシステムでは、次の二つを両方見る必要がある。
- 技術的に動いているか
- 業務上、期待した結果を出しているか
監視とオブザーバビリティの違い
監視は、事前に決めた異常を見つける活動である。
たとえば、エラー率が5%を超えた、応答が10秒以上かかった、といった条件を検知する。
オブザーバビリティは、想定していなかった問題が起きたときにも、記録をたどって原因を調べられるようにする考え方である。
AIの誤回答は原因が一つとは限らない。
- 質問の解釈を誤った
- 検索が古い文書を選んだ
- モデルが根拠を読み違えた
- 出力検証が見逃した
- 人間承認で誤って採用した
この経路を後からたどれなければ、改善できない。
一回の処理をつなげて記録する
利用者の一回の依頼には、検索、AI生成、ツール実行、承認など複数の処理が含まれる。
各処理へ共通の識別番号を付けると、一連の流れをつなげて確認できる。
たとえば、誤回答について次を調べられる。
- どの質問を受けたか
- どの文書を検索したか
- どのモデルとプロンプトを使ったか
- どの検証を通ったか
- 誰が承認したか
- 外部システムへ何を反映したか
この一連の記録をトレースという。
版を記録する
同じサービス名でも、中身は変わる。
- モデル
- プロンプト
- 検索インデックス
- 参照文書
- 出力検証
- 外部ツール
- ワークフロー
問題が起きた時刻だけ記録しても、その時点でどの組み合わせが動いていたか分からなければ再現できない。
一回の処理ごとに、主要な構成要素の版を結び付ける。
三種類の記録を使い分ける
メトリクス
一定時間ごとの件数や割合である。
- 利用件数
- エラー率
- 平均待ち時間
- 拒否率
- 人間への移管率
- 一件あたりの費用
全体傾向を見るのに向いている。
ログ
個別に起きた出来事の記録である。
- 文書検索に失敗した
- 禁止されたツール実行を拒否した
- 人間が回答を修正した
- モデルを切り替えた
トレース
一回の依頼が、どの処理を通ったかをつなげた記録である。
三つは代替関係ではない。傾向をメトリクスで見つけ、ログとトレースで原因を調べる。
質問全文を保存すればよいとは限らない
AIの質問や回答には、個人情報、顧客情報、ソースコード、社内機密が含まれることがある。
調査しやすさだけを考えて全文を保存すると、監視基盤そのものが大きな情報漏えい源になる。
目的に応じて保存範囲を変える。
- 件数や時間だけ保存する
- 本文を伏せ、文書番号や版だけ保存する
- 問題が起きた処理だけ、権限を限定して保存する
- 保存期間を短くする
本文を保存しない場合でも、原因を調べられる識別情報は残す。
技術指標と品質指標を分ける
技術指標は、システムが動いているかを見る。
- 成功率
- エラー率
- レイテンシ
- タイムアウト率
- 外部ツールの失敗率
品質指標は、結果が役立っているかを見る。
- 正しい根拠を示した割合
- 人間が修正した割合
- 答えるべき質問へ答えた割合
- 答えてはいけない質問を拒否した割合
- 利用者が問題を解決できた割合
技術指標が正常でも品質は悪化し得る。両方を一つの画面で見られるようにする。
SLOで「正常」の基準を決める
SLOは、サービスがどの水準を満たすべきかを定めた目標である。
たとえば次のように決める。
- 95%の回答を5秒以内に返す
- 権限外文書の検索を0件にする
- 重要な質問の根拠提示率を99%以上にする
- 人間移管が必要なケースの見逃しを1%未満にする
すべての質問へ同じ目標を置く必要はない。雑談と、契約や安全に関わる質問では、必要な水準が異なる。
セキュリティ違反のように、一件でも許容できないものは、通常のエラーと同じ平均値で扱わない。
品質の変化を早く見つける
モデルを変えていなくても、利用状況は変わる。
- 新しい製品の質問が増えた
- 文書の書き方が変わった
- 長い質問が増えた
- 利用者層が広がった
- 新しい攻撃方法が現れた
入力や結果の傾向が以前と変わることをドリフトという。
ドリフト自体は必ずしも異常ではない。しかし、変化を見つけたら、既存の評価データが現在の利用状況を表しているか確認する。
アラートには対応を結び付ける
異常を知らせるだけのアラートは、運用者を疲れさせる。
アラートごとに、誰が何をするかを決める。
- 権限違反を検知したら、該当機能を直ちに停止する
- 根拠提示率が下がったら、検索インデックスの更新を確認する
- 費用が急増したら、再試行やループ回数を確認する
- 人間移管が急増したら、新しい質問分野を調査する
対応方法がない指標は、記録しても運用へつながらない。
まとめ
AIシステムの運用では、エラーがないことだけを見てはいけない。
どの質問が、どの文書、モデル、検証、承認を通り、どの結果へ至ったかを後から説明できるようにする。
技術的な安定性と、回答品質、安全性、費用を一緒に観測することで、AIを継続的に改善できる。
参考資料
- OpenTelemetry, Semantic Conventions
- OpenTelemetry, Inside the LLM Call: GenAI Observability with OpenTelemetry, 2026
- NIST, AI Risk Management Framework 1.0, 2023