2026年10月8日に、Google SREのSLO、SLOアラート、Prometheusのhistogram、scikit-learnの評価指標、NIST AI RMF Coreを再読しました。SLOは利用者の信頼性目標とSLI・分母を結び、アラートは行動できる条件と担当へつなげます。histogramの分位点はバケット設定と集計方法に依存し、モデル指標もタスクと誤りコストに合わせます。品質・速度・費用を一つの点数に潰さず、変更後に同じ条件で再測定します。
AIシステムのパフォーマンス監視：継続的な改善のための実践ガイド
AIが返事をしていても、必要な答えを返しているとは限りません。逆に、評価用の問題で高い点数が出ていても、利用者が待ちきれず離脱することはあります。監視では、処理が動くことと、仕事に使える結果が出ることを分けて測る必要があります。
ここでは、運用する担当者が、何を集計し、通知を受けたら何を確かめるかを決められるように整理します。数値例はすべて仮想であり、特定の企業やモデルの実績ではありません。
30秒で要点
- 品質・速度・可用性・費用を分け、分子、分母、測定区間、対象外を決めます。
- 500msや99.9%は全AIに共通する正解ではありません。利用者の仕事と、守れる運用条件から目標を置きます。
- 通知には担当、最初の確認、利用停止や代替手段への切替条件を結び付けます。
- 改善後も同じ条件で比較します。前後の差だけでは、変更の効果とは言い切れません。
監視指標は、判断する対象から選ぶ
最初に「誰が何をできなくなると困るか」を書きます。問い合わせの下書きを作るAIなら、応答の有無だけでなく、回答根拠の誤りや担当者の修正負担も問題になります。在庫予測なら、正解率という一語より、予測が何個ずれたか、欠品と過剰在庫のどちらへ影響したかが判断につながります。
NISTのAIリスク管理の枠組みは、配備条件に近い評価、運用中の監視、測定できないリスクの記録、利用者からの問題報告を扱います。これは任意の枠組みであり、どのAIにも同じ精度基準を指定するものではありません。
表が収まらない場合は、横にスクロールできます
| 観点 | 問いと指標の例 | 見落としやすい条件 |
|---|---|---|
| 品質 | ラベルを確認した回答の正誤、分類の適合率・再現率、予測の誤差 | 評価対象の偏り、正解が判明するまでの遅れ |
| 速度 | 利用者の送信から完了までの時間、一定時間以内の完了割合 | 待ち行列、通信、再試行、長い入力 |
| 可用性 | 対象要求のうち正常に完了した割合 | タイムアウトを分母から落としていないか |
| 費用 | 対象期間の利用費、運用費、品質確認の時間 | 再試行、失敗、監視そのものの費用 |
指標を一つの総合点にすると、費用削減の代わりに誤りが増えたことを見失いがちです。初めは各観点から判断に必要な少数を選び、「この値が悪化したら何をするか」を添えます。
同じ割合でも、分母が違えば意味が違う
仮に、1週間の対象要求が10,000件、正常完了が9,980件、失敗が20件だったとします。失敗には、事前に決めたタイムアウトも含めます。この定義で正常完了率は9,980÷10,000＝99.8%です。
一方、品質を人が確認できた回答は200件だけで、そのうち正しかったものが170件なら、確認対象内の正解率は85%です。これを「全10,000件の85%が正しい」とは言えません。抽出方法、未確認の理由、対象期間を併記します。
分類では「陽性」を業務上どう定義するかも必要です。例えば、不良品を陽性とする仮想の200件を、人の判定と照合して次のようになったとします。
表が収まらない場合は、横にスクロールできます
| 実際に不良 | 実際に正常 | |
|---|---|---|
| AIが不良と判定 | 40件（TP） | 10件（FP） |
| AIが正常と判定 | 20件（FN） | 130件（TN） |
正解率は170÷200＝85%、適合率は40÷50＝80%、再現率は40÷60≒66.7%です。F1は2×40÷（2×40＋10＋20）≒72.7%になります。見逃した不良20件と、正常品を止めた10件では負担が違うため、F1だけで採用可否を決めません。指標の定義
分母が0になる場合は、便宜的な0を実測の悪化と混同しないようにします。「対象なし」「未判定」を記録し、計算上どの扱いをしたかを示します。多分類の場合も、全体平均だけでなく重要な分類ごとの件数を確認します。
連続値の予測には、別の指標を選びます。仮に実績が100、120、80個、予測が90、130、100個なら、平均絶対誤差（MAE）は（10＋10＋20）÷3≒13.3個です。単位が個なので、需要量の違う商品を比べる際には規模の影響も考えます。「予測精度85%」と書くより、何をどれだけ外したかを定義できます。MAEの定義
500msと99.9%を、条件のある目標へ変える
速度は、どこからどこまでを測ったかで変わります。サーバー内の推論時間、利用者から見た完了時間、文章の最初の部分が届くまでの時間を混ぜないでください。途中まで表示できても、その後に失敗する場合があります。
例えば「対象要求の95%が送信から500ms以内に正常完了」という目標を仮置きするなら、残り5%の遅さ、失敗の扱い、対象機能、集計窓も必要です。これは説明のための設定で、長い文書を生成するAIにも500msを求めるという推奨ではありません。
平均が短くても、一部の利用者が長く待つ場合があります。分位点は、時間を小さい順に並べた位置を表します。95パーセンタイルなどを見るときは、件数、期間、近似方法も記録します。複数サーバーの95パーセンタイルを単純平均しても、全要求の95パーセンタイルにはなりません。Prometheusの分布と分位点の説明
可用性も、時間の割合と要求の割合を区別します。Google SREのSLO設計は、利用者の経験に結び付く指標と、関係者が合意する目標を説明しています。SLOはサービスの目標、SLIはその達成状況を測る指標です。
先ほどの10,000件に仮の99.9%目標を置けば、許容する失敗は10件です。実際の仮想失敗20件は、その枠の200%を使ったことになります。この20件を時間へ換算することはできません。一方、時間ベースで30日を分母に99.9%と定義した場合の0.1%は43.2分です。要求ベースと時間ベースの例は別の計算です。
MTBF（故障間隔）やMTTR（復旧時間）を使う場合も、故障と復旧の定義、件数、観測期間を残します。故障がなかった短期間から、長期の故障間隔を確定することはできません。
ログを集める前に、測定契約を一枚にする
ダッシュボードの見栄えより先に、集計を再現できる情報を決めます。次は編集部が整理した記録項目で、特定の監視製品への設定手順ではありません。
表が収まらない場合は、横にスクロールできます
| 項目 | 決める内容 |
|---|---|
| 対象 | 機能、モデルや設定の識別子、入力の種類、対象利用者 |
| 観測単位 | 利用者の一要求か、内部API呼出しか。再試行をどう数えるか |
| 時間 | 開始・完了・失敗の時刻、タイムゾーン、集計窓 |
| 品質 | 評価基準、正解を確かめる人、抽出方法、未判定件数 |
| 通知 | 条件、継続時間、担当、連絡先、確認できない時の代行 |
| 保存 | 必要な項目、保管期間、閲覧権限、本文を保存しない方法 |
再試行を含めて内部の試行が合計3回ある一要求を、利用者の成功率の分母では1件、内部処理費では3回として数えることがあります。両方の集計は有用ですが、同じ「要求数」という名前にしないことが大切です。必要以上に入力本文を収集せず、識別子や結果分類だけで調べられる範囲から始めます。
PrometheusやGrafana、Datadog、New Relicなどの採用を考えるときも、先にこの定義を用意します。既存の運用基盤、計装できる場所、権限、保管量、当番体制、費用から選びます。製品を導入しただけで回答の正しさを自動判定できるとは限りません。
通知を、確認と復旧につなげる
通知条件は「精度が80%未満」だけでは足りません。直近1件の失敗でも割合は大きく動きます。品質判定の遅れや集計漏れで値が動くこともあります。最低件数、継続時間、重大な失敗を一件でも止める条件を、リスクに合わせて分けます。
Google SREのエラーバジェットに基づく通知は、消費の速さ、複数の時間窓、低トラフィック時の問題を説明しています。資料中の数値をそのまま採用するのではなく、通知を受けた人が間に合うか、通知を無視する状態にならないかを点検します。
表が収まらない場合は、横にスクロールできます
| 仮想の用途 | 最初に確認すること | 対応の候補 |
|---|---|---|
| チャットボット | 根拠資料の変更、質問の種類、誤答/保留/引継ぎの内訳 | 対象を絞る、人へ引き継ぐ、資料を訂正して再評価 |
| 画像分類 | 撮影条件、商品構成、判定済み標本、見逃しと誤検出 | 該当条件を人の確認へ戻し、原因別に評価 |
| 需要予測 | 実績確定の遅れ、欠損、季節や販売条件、誤差の方向 | 対象商品の利用を保留し、業務側の代替予測と比較 |
通知には、対象、観測値、分母、期間、直近変更、担当者、確認手順を含めます。原因が不明なまま自動で再学習や本番切替を繰り返すと、別の変化を重ねてしまいます。停止・復旧の権限と、復旧を認める確認条件を先に決めます。
費用と品質を同じ見直しに載せる
仮に1週間のAI利用費が12,000円で、対象要求が10,000件なら1要求あたり1.2円です。失敗や再試行の費用も含めた期間総額を、どの分母で割ったかを書きます。正常完了9,980件で割るなら約1.20円ですが、別の指標です。
さらに品質確認が5時間、社内の比較用単価を3,000円/時間と仮置きすれば、確認負担は15,000円、利用費との合計は27,000円です。これは会計上の支払額をそのまま表すとは限らず、負担を比較するための仮想計算です。ログ保管や当番の費用も必要なら加えます。
一つの機能で始める最小検証
まず一機能だけ選び、正常・失敗・タイムアウト・再試行を含む合成記録で集計を確かめます。次に、通知を受け取った担当者が、対象の特定から保留・代替手段まで進めるかを机上で確認します。これは計測設計の点検で、実利用時の性能試験とは別です。
運用後は、見直し日と確認条件を先に決め、入力構成、モデルや設定、資料、集計方法の変更を残します。変更前後の差には季節や利用者構成も混ざります。A/Bテストを使うなら対象の割付や観測窓を設計し、単なる前後比較をA/Bと呼ばないようにします。統計的思考と比較条件
改善案を採用するか、元へ戻すか、追加確認するか。その判断と次に見直す条件まで記録できて、監視が運用に役立ちます。入力の検査と評価用データの扱いはAIデータ品質管理、モデル変更時の確認はモデル選定ガイドも参照してください。