まずは、運用に不安を感じている方へ。推論バッチやデータ処理ジョブが突然止まったり、結果の品質低下に気づくのが遅れて困った経験は多いはずです。本記事は「何を」「どう計測し」「どのようにアラートして」「どのように対応を自動化するか」を、現場で使える実務手順として整理します。第122回（大規模CSV・バッチ推論）の続きとして読めるように、実用的なチェックリストとコピー可能なコード例を用意しました。
この記事の狙いと前提
対象読者は、AIを仕事に活かしたい実務担当者や中小企業の担当者です。理想論ではなく、実際のジョブ（バッチ推論・ETL・定期検証）を安定稼働させるための観点と手順を中心に説明します。関連回：第103回（データ検証）、第118回（リトレーニング）、第122回（バッチ推論）。
全体手順（要点）
- 1) ビジネス観点でSLI/SLOを決める（成功率・遅延・品質）
- 2) メトリクスを計測・集約する（軽量エミッタ→Prometheus/クラウド）
- 3) 分布監視と変化検出を行う（PSI/統計的検定/要約統計）
- 4) ノイズ対策を施したアラートを設計し、runbookを用意する
- 5) 自動復旧パターンを実装し、安全性ルールを定める
- 6) テストと段階的導入で運用に移す
SLI/SLO設計の実務ワークシート
まずはビジネスに直結する指標を選び、SLOとエラーバジェットを定めます。以下は設計テンプレートの例です。
| ビジネスゴール | SLI（計測式） | SLO（目標） | エラーバジェット | 優先度 |
|---|---|---|---|---|
| 日次バッチの完了 | 完了ジョブ数 / 予定ジョブ数 | 99.5%（月間） | 0.5%（月間） | 高 |
| 推論成功率（エラーなし） | 正常出力数 / 総リクエスト数 | 99.0%（週） | 1.0%（週） | 高 |
| 予測遅延（バッチ平均処理時間） | 95パーセンタイル処理時間 | < 10 分 | 5回/月 | 中 |
| 出力品質（業務評価） | 上位K指標（例：F1スコア） | >= 0.80（検証データ） | モデル更新までの許容低下量 | 高 |
計測（メトリクス）実装パターン（Python）
実務では軽量で再利用しやすいエミッタモジュールを作ると便利です。ポイントは冪等性、例外発生時の安全な計測、タイミング計測の自動化です。
設計パターン
- 関数ベースのエミッタ（呼び出し箇所が明確）
- コンテキストマネジャで処理時間を自動計測
- 例外ハンドリングで失敗メトリクスを記録
- ローカルは時系列ファイルや軽量DBで集約、外部はPrometheus/クラウドAPIへ送信
コピーして使える最小限の例（概念）
以下はシンプルなコンテキストマネジャ型の計測パターン（擬似コード）。必要であればPrometheus clientやクラウドSDKに差し替えてください。
from time import perf_counter
class MetricEmitter:
def __init__(self, metrics_sink):
self.sink = metrics_sink
def timing(self, name, tags=None):
start = perf_counter()
try:
yield
except Exception as e:
self.sink.increment(f"{name}.error", tags=tags)
raise
finally:
elapsed = perf_counter() - start
self.sink.observe(f"{name}.duration", elapsed, tags=tags)
ここで metrics_sink はログ、ファイル集約、Prometheus PushGateway、またはクラウドメトリクスAPIに対応するインターフェースです。
ローカル集約の軽量例
標準ライブラリだけでの累計／平均集計は簡単にできます。メモリに乗らない場合はジェネレータとchunkごとの集約を使います。
| 目的 | 手法 | 利点 |
|---|---|---|
| 平均・分散 | Welfordの1パスアルゴリズム（statistics不要） | メモリ効率が高い |
| 大規模ファイルの要約 | ジェネレータでchunk処理、部分集約を結合 | メモリ制約下で安定 |
| 短期ログ | ローテーション付のCSV/JSON行書き出し | デバッグが容易 |
分布監視と変化検知
スコアや入力特徴量の分布変化は品質劣化の前兆です。しきい値アラートと統計的差分検出を使い分けましょう。
手法の一覧
| 手法 | 用途 | 注意点 |
|---|---|---|
| Population Stability Index (PSI) | 既存分布とのズレ検出 | バケット定義に依存、定期更新が必要 |
| KS検定（Kolmogorov–Smirnov） | 連続分布の差の検出 | サンプルサイズ感度あり、大規模データでの解釈に注意 |
| 要約統計（平均・分散・percentile） | 急な変化の検出に有効 | 単一指標は誤検知の原因になる |
実務上の実装ポイント
- 定期ジョブ（夜間）で参照分布と比較する。リアルタイムはコストとノイズに注意。
- メモリ制約時はストリーミング要約（t-digestやQDigest）やchunk比較を使う。
- 複数指標でアンサンブル的に判定（例：PSI大 & 95p変化大）すると誤検知が減る。
アラート設計とrunbook
誤検知を減らし、受け取る側がすぐ動けるアラート設計が重要です。以下は実務向けのテンプレートと例です。
アラート設計のチェック項目（短く）
| 項目 | 意図 |
|---|---|
| 複合条件 | 単一指標のノイズを抑える（例：エラー率↑かつ処理時間↑） |
| 評価ウィンドウ | 短期ノイズを除去（例：5分のウィンドウで3回閾値超え） |
| サプレッションと再試行 | 連続発報を防ぐ（初回は低頻度で、復旧確認後に解除） |
| エスカレーション | 重要度に応じた通知フロー（Slack→メール→電話） |
簡潔なrunbookテンプレート
| 項目 | 内容（例） |
|---|---|
| 優先度 | P1（処理停止） / P2（品質劣化） |
| 最初の確認 | ジョブの最後のログ、リソース使用率、最近のデプロイ |
| 短期対処 | ジョブ再起動、キューの再処理、フォールバックモデル適用 |
| 根本原因調査（RCA） | 入力データの変化、外部API障害、モデルドリフト、コード変更 |
| 復旧確認 | メトリクスがSLO内に戻ることを確認後クローズ |
自動復旧パターンと安全性ルール
自動化はミスを早く解消しますが、安全策を入れておくことが不可欠です。
代表的な自動化パターン
- リトライ＋指数バックオフ（外部APIやDB接続）
- フォールバックモデルの切替（主要モデル障害時に軽量モデルへ）
- ジョブの再スケジュールと部分再処理（失敗バッチのみ）
- 緊急停止（stop switch）と手動承認フロー
安全性担保ルール（運用ルール例）
| ルール | 理由 |
|---|---|
| 自動アクションは冪等に実装 | 複数回実行されても安全にするため |
| クールダウン期間を設ける | 無限ループや震災的な再起動を防止 |
| 重大変更は手動承認を必須に | 誤った自動化が大被害を出すのを防ぐ |
| 自動処理はまず小さなトラフィックで検証 | 影響範囲を限定してから全体へ拡張するため |
テストと運用導入チェックリスト
導入前に最低限確認すべき項目をまとめます。
| カテゴリ | チェック項目 |
|---|---|
| メトリクス | 計測対象が想定通り計測され、ラベルが一貫しているか（単体テスト） |
| アラート | サイレント期間で誤検知を確認、通知フローが動くか（統合テスト） |
| 自動化 | リトライ・フォールバックの安全性、ログが追えるかを確認 |
| ダッシュボード | 受け入れ基準（SLO可視化、原因切り分けに必要なグラフがあるか） |
| 導入手順 | 段階的ロールアウト計画（影響の小さい環境→本番） |
成果物と短期優先タスク（実行リスト）
まず取り組むと効果の大きいタスクを列挙します。
- 1週間でできる：主要SLIの決定と軽量エミッタの導入（ローカルファイル可）
- 2週間でできる：定期分布監視ジョブ（PSI/要約統計）とアラートの試運転
- 1ヶ月でできる：Prometheusなど本番送信とrunbookの完成、段階的導入
参考：記事内で提供するサンプル（内容の一例）
本記事では以下を付録として提供します（本文中にコピーできる形で）：
- メトリクスエミッタの最小実装（コンテキストマネジャ例）
- 分布検査ジョブのサンプル（PSI算出とthresholdチェック）
- runbookテンプレート（テーブル版）
次の一歩（関連回への案内）
本記事は第122回の続きです。データ検証やリトレーニングの運用については第103回／第118回の記事を参照してください。可観測性の設計は一度作って終わりではなく、モデル更新や業務要件の変化に合わせて見直す必要があります。
まとめ
可観測性とアラート設計は、「何を計測するか」をビジネス観点で決めることから始まります。軽量なメトリクスエミッタを先に入れて、分布監視や複合条件のアラートで誤検知を減らす。自動復旧は有効ですが、安全性ルール（冪等性、クールダウン、手動承認）を必ず入れてください。最後に、テストと段階的導入で運用に移すことを忘れずに。これらを順に実施すれば、推論パイプラインやバッチジョブの安定稼働に必要な基盤が整います。
Manage AI シリーズ：AIとPythonの実務 — 次回も実務で使える手順をお届けします。