デプロイ後に「品質は大丈夫か」「費用が膨らんでいないか」と心配になっていませんか。モデル監視やCI/CDは重要ですが、現場で日々の判断を支えるのはSLO（サービス品質目標）とそれを支える計測・自動化の仕組みです。本記事では、AIとPythonを実務に落とし込む観点から、最小限の実装パターンと現場で使えるテンプレートを提示します。シリーズ「AIとPythonの実務」向けの、すぐ試せる設計ガイドです。
SLOが必要な理由（モデル監視・CI/CDと何が違うか）
SLOは「期待される品質を数値で合意し、運用行動を決める仕組み」です。モデル監視はデータや挙動を検知する手段、CI/CDは安全にデプロイする仕組みであり、SLOはその上で「いつ」「誰が」「どう対応するか」を定義します。違いを端的にまとめると：
- モデル監視：異常の検知（データドリフト、精度低下など）
- CI/CD：変更を安全に本番へ届ける仕組み
- SLO：現場の合意（例：p95レイテンシ < 500ms、成功率 > 99%）に基づき、監視結果を運用アクションへ結び付ける
SLI候補と定義方法
まず計測対象を絞ります。以下は実務で使いやすいSLI候補と計測式、サンプルしきい値です。
| 指標 | 計測式（例） | サンプルしきい値（実務向け） |
|---|---|---|
| レイテンシ | p95 レイテンシ = 95パーセンタイルの応答時間 | p95 < 500ms、p99 < 1.5s |
| 成功率 / エラー率 | 成功率 = 正常レスポンス数 / 総リクエスト数 | 成功率 ≥ 99%（業務重要度に応じて調整） |
| モデル品質（参照セット） | F1 = 2 * (precision * recall) / (precision + recall) | 参照セットF1 ≥ 0.85、または相対低下 < 5% |
| 説明可能性チェック | 重要特徴の寄与度が訓練時と大きく乖離している割合 | 寄与度乖離割合 < 10% |
| コスト指標 | リクエスト単位コスト = トークン数×単価 + GPU秒×単価 | 日次予算：プロジェクトごとに上限設定（例：¥10,000/日） |
しきい値は業務重要度やSLA（顧客向け契約）に合わせて合意します。まずは「p95レイテンシ + 成功率 + 日次コスト」の最小実装から始めるのが現場では有効です。
計測の実装パターン（Python中心）
実務では既存の監視基盤に接続することが現実的です。以下は代表的パターンとPythonでの実装例の概略です。
Prometheus + prometheus_client によるメトリクス公開
アプリケーションやAPIでメトリクスをエクスポートし、Prometheusで収集します。Pythonの例（概略）：
from prometheus_client import Summary, Counter, start_http_server
REQUEST_LATENCY = Summary('request_latency_seconds', 'Request latency')
REQUEST_COUNT = Counter('request_count', 'Total requests', ['status'])
def handle_request(req):
with REQUEST_LATENCY.time():
# リクエスト処理
pass
REQUEST_COUNT.labels(status='200').inc()
if __name__ == '__main__':
start_http_server(8000) # /metrics を公開
OpenTelemetryでトレースとメトリクスを連携
トレース情報とメトリクスを同時に収集して、障害時のRoot Cause分析をスムーズにします。ライブラリを使ってサーバーサイドでSpanとカスタムメトリクスを出力します。
定期バッチでの品質SLI（黄金データ検査）
本番から定期的にサンプルを取り、黄金データ（reference set）でモデルの精度を評価します。日次バッチはCloud Schedulerやcronで回し、結果をメトリクスやアラートに変換します。簡単な流れ：
- 本番からN件サンプルを抜粋
- モデル推論を行い、黄金データと比べて精度を集計
- 精度が閾値を下回ればアラートを発火
コスト計測と割当方法
コストはリクエスト単位で推定し、テナントやプロジェクトへ帰属させます。基本式と実務パターンは以下の通りです。
| 項目 | 計算式 / 手順 | 備考 |
|---|---|---|
| リクエスト単位コスト | トークン数×モデルトークン単価 + GPU秒×GPU単価 | API課金モデルではトークン数が主要なドライバ |
| プロジェクト帰属 | リクエストにプロジェクトID/テナントIDを付与して集計 | ログ/トレースと結合して請求APIと突合 |
| クラウド請求の集計 | AWS/Azure/GCPの請求APIを定期取得して、タグやラベルで分配 | PythonでAPIを叩き、日次でプロジェクト別に集計するのが実務的 |
Pythonの集計パターンは、リクエストログの集計（トークン数合計 × 単価）とクラウド請求APIの仕訳（タグベース）を突合する流れです。
アラートと自動対応の設計
SLO違反や予算超過時は段階的に対応します。一般的なワークフロー：
- 警告（通知） — Slack/メールで担当者へ通知
- 軽度自動対応 — レート制限やキューイングで負荷緩和
- 中度自動対応 — 軽量モデルへルーティング（モデルフェイルオーバー）
- 重度自動対応 — 新規リクエスト停止、オペレーション介入待ち
Pythonでの自動化戦略（概略）：監視 → 判定ロジック → アクション呼び出し。例：
def check_slo(metrics):
if metrics['p95_latency'] > 0.5:
trigger_action('route_to_light_model')
if metrics['daily_cost'] > budget:
trigger_action('throttle_requests')
def trigger_action(action):
# Kubernetes API を叩いてデプロイを切り替える、
# またはサービスメッシュのルーティングを更新する
pass
重要なのは「自動化して終わり」ではなく、手動判断に移す時のエスカレーション手順を明確にすることです。
CI/CDとの結合点
- モデルデプロイ前のSLO回帰テスト：新モデルを参照セットで評価し、SLOを満たすか自動判定
- プルリクでのコスト予測チェック：変更がコストに与える影響を簡易見積もり（トークン増加予測など）
- CIパイプラインで閾値チェック：パフォーマンス/精度/コストの自動判定を通さないとマージできないルール
運用ドキュメントとRunbook連携
SLO違反時に誰が何をするかを明記したRunbookは必須です。テンプレート例：
| 項目 | 内容（例） |
|---|---|
| 検知条件 | p95 レイテンシ > 500ms を 5分間継続 |
| 一次対応者 | オンコール担当（Slackチャンネルへの通知） |
| 一次対応手順 | 1. モニタで該当ホストを確認 2. ログでエラー傾向を確認 3. 自動ルーティングを一時解除 |
| エスカレーション | 15分以内に改善しない場合はエンジニアリングリードへ報告 |
| 復旧後チェック | 原因分析（ポストモーテム）とSLO/閾値の見直し |
失敗しやすい点と実務チェックリスト
よくある落とし穴と対処法：
- 過度に細かいSLO設定：まずは最小実装から始める（p95, 成功率, 日次コスト）
- 指標の測り方のブレ：メトリクス定義をドキュメント化し、サンプリングルールを固定する
- コストメトリクスの遅延：日次集計を採用し、リアルタイムは概要アラートに留める
- アラート疲れ：多段階アラートと抑制ルール（同一イベントの抑制期間）を設定
実務チェックリスト（まず試す）：
- p95レイテンシの計測をPrometheusで開始
- 成功率のカウントをアプリに埋め込む
- 日次コスト集計スクリプトを用意してSlack通知
- 簡単なRunbookを1ページで用意してオンコールに共有
サンプルリソースと次の一歩
短いPythonコードテンプレート（概略）：メトリクス公開、日次コスト集計、閾値判定の例です。
# prometheus_client による最小メトリクス公開 (前述)
# 日次コスト集計の概略
import datetime
def daily_cost_sum(logs, token_price):
today = datetime.date.today()
total_tokens = sum(entry['tokens'] for entry in logs if entry['date'] == today)
return total_tokens * token_price
最小ダッシュボード構成（Prometheus + Grafana）：
- パネル1：p95/p99 レイテンシ（API別）
- パネル2：成功率（時間推移）
- パネル3：日次コストと予算残（プロジェクト別）
次に試すべきトピック：SLOに基づく自動コンテナスケーリング、容量予測、より細かいテナント別課金の自動化など。
まとめ
SLOは単なる観測ではなく、現場の判断と行動を数値で支える仕組みです。まずは「p95レイテンシ・成功率・日次コスト」の最小実装から始め、Prometheusや簡易スクリプトで計測・集計して運用ルール（Runbook）に落とし込みましょう。段階的な自動対応とCI/CDでの前倒しチェックを組み合わせることで、信頼性と費用のバランスを保ちながら現場運用が楽になります。次回はこのSLOに基づく自動スケール運用の具体例を扱います。
（参考）Manage AI シリーズ「AIとPythonの実務」: 記事一覧は https://manageai.online をご覧ください。