💁‍♂️

AIが“正しく動いている”とはどういうことか？――AISREという新しい考え方

に公開
AI
SRE
MLOps
Observability
LLM
idea

本記事は、ING Bank の SRE、Ehsan Khodadadi 氏が Medium に公開した
「AISRE: It is time for AI Site Reliability Engineering」を要約・再構成した内容です。
原文の著作権は著者および Medium に帰属します。
出典：https://medium.com/ing-blog/aisre-it-is-time-for-ai-site-reliability-engineering-6315f5890542

0. TL;DR

  • AISRE（AI Site Reliability Engineering）は、従来の SRE を AI 特有の失敗モード（意味の誤り・検索の鮮度・エージェントのループ・コスト暴走・ドリフト）にまで拡張した運用フレームワーク。
  • 監視対象は「可用性・レイテンシ」だけでは不十分。根拠ある正しさ（grounding）・安全性・経済性・振る舞い変化 を含むレイヤ別 SLI/SLO が必要。
  • AI プロダクトを 5 つのレイヤ（基盤モデル／RAG／エージェント・ツール／プロダクト体験／横断）に分け、それぞれにロールバック単位と観測点を持たせる。
  • 実務ではまず 計測（Instrumentation）→ 自動化（Automation）→ 適応最適化（Adaptive Optimisation） の順で成熟させていく。
  • スターターセットとしては、「意味＋検索＋安全」の三本柱に絞った SLI、リネージログ、スナップショット＆ロールバック、ループ防止ガードあたりから始めるのがおすすめ。

1. 何が問題？――「全部グリーンなのにおかしい」

AI を含むサービスで、こんな状況が起きえます。

  • ダッシュボード上はエラー率もレイテンシも「グリーン」
  • なのにタスクあたりコストがじわっと 40% くらい上昇
  • 根拠あり回答率（grounded answer rate）が数％落ちる
  • ユーザーの「再生成（Regenerate）」が倍増している

インフラ的には「問題なし」ですが、プロダクトとしては 静かに品質が悪化している状態 です。

原因になりがちなのは例えば以下です。

  • プロンプトの軽微な修正
  • ベンダー側の埋め込みモデル更新
  • 検索インデックスの鮮度低下
  • モデルのサイレント差し替え
  • UI が再生成ボタンを押させまくる

従来の SRE で見ている指標（CPU・メモリ・エラー率）では、こういった「意味・行動」の変化は検知しづらい。
そこで出てくるのが AISRE という考え方です。

2. SRE と AISRE の違い

ざっくり比較するとこうなります。

観点 従来 SRE AISRE
信頼性の対象 可用性、レイテンシ、エラー率 意味的正確性、根拠性、安全性、コスト効率、ドリフト耐性
主な依存関係 アプリケーション、DB、ネットワーク モデル、埋め込み、RAG、エージェント、ツール、ポリシー
失敗モード 落ちる／遅い／エラーを返す ハルシネーション、検索崩れ、エージェントのループ、静かなモデル更新
検知方法 メトリクス＋ログ＋トレース 上記に加え、意味評価・検索精度サンプル・リネージ追跡
変更管理 バイナリ／設定のリリースとロールバック プロンプト、モデル、埋め込み、インデックス、プランナー、安全設定も「デプロイ対象」として扱う

3. レイヤードビュー：どこを、どう見る？

AI プロダクトを 5 つのレイヤ(基盤モデルレイヤ・RAGレイヤ・エージェントレイヤ・に分けて、それぞれに

  • どんな SLI を持つか
  • どこをロールバック単位にするか
  • どのような観測点（ログ・メトリクス）を持つか

を決めていく、という整理です。

A. 基盤モデルレイヤ（生成モデル／埋め込み）

生成モデルや埋め込みモデルと、そのバリアント・設定を扱うレイヤです。

  • 見る指標

    • ttft_ms（最初のトークンが出るまでの時間）
    • tpot_ms（トークン生成速度）
    • goodput（ユーザーにとって役に立ったトークン量/秒）
    • 構造化出力の遵守率（JSON などのフォーマットを守れているか）

  • 変更面

    • モデルの種類・バージョン
    • デコーディング設定（温度、top_p など）
    • バリアント間の差分（pin & diff）

  • ロールバック

    • モデル＋デコーディング設定の固定化・切替

B. RAG（Retrieval）レイヤ

外部のコーパス（文書・DB）から情報を取ってきてプロンプトに埋め込む部分です。

  • 見る指標

    • コーパス取り込みの遅延（ingestion lag）
    • 検索結果の精度（context_precision@k など）
    • リランカー導入による精度向上度（rerank_gain）
    • インデックスの健全性（サイズ異常、ビルド失敗など）
    • 使われなかったコンテキストの比率（unused_context）

  • 変更面

    • チャンク分割ルール、オーバーラップ
    • 埋め込みモデルの種類・バージョン
    • BM25 とベクトル検索の重み付け（ハイブリッド検索）

  • ロールバック

    • ベクターインデックスのスナップショット切替
    • 埋め込みモデルのバージョン固定／巻き戻し

C. エージェント／ツールレイヤ

プランナーやツール実行チェーンなど、エージェント的な動きをする部分です。

  • 見る指標

    • プランの収束性（plan_steps_p95 など）
    • ループ中断率（loop_abort_rate）
    • ツールのタイムアウト率・スキーマ不整合率
    • 危険な書き込みをブロックできているか（unsafe_action_block_rate）
    • 人間へのエスカレーション遅延（human_escalation_latency）

  • 変更面

    • プランナーのロジック
    • ルーティングルール（どのツールを使うか）
    • ツールの allowlist / denylist

  • ロールバック

    • プランナー定義の固定・切替
    • 高リスクな書き込みアクションの一時停止・人間承認フローへの切替

D. プロダクト／体験レイヤ

ユーザー視点で「この AI は使えるのか？」が決まる部分です。

  • 見る指標

    • 再生成率（regeneration_rate）
    • 早期中断率（early_abort_rate）
    • セッションあたりの「根拠あるターン数」
    • 課金の整合性（未帰属トークン比率、ツールコストの孤立分）
    • 安全 UX のバランス（false_refusal_rate と unsafe_output_rate のトレードオフ）

  • 変更面

    • UI 設計（コンテキストの見せ方、ボタン配置など）
    • パーソナライズのロジック
    • エラー時・フォールバック時のメッセージ

  • ロールバック

    • UI ガードの有効化／無効化
    • 再生成の抑制や、より保守的な応答への切替

E. 横断レイヤ（ドリフト／コスト／リネージ／安全）

全レイヤに関わる横断的なテーマです。

  • 見る指標

    • ドリフト：semantic_accuracy_delta（基準との意味的精度差）
    • コスト：cost_per_successful_task、token_waste_ratio
    • リネージ：どのプロンプト・モデル・埋め込み・インデックスから出力されたか
    • ガバナンス・安全：policy_violation_rate、pii_leak_rate
    • フィードバックループ：feedback_capture_rate、label_latency

  • 運用面

    • 影評価（shadow evaluation）
    • 新旧の差分評価（differential eval）
    • 毎日のカナリアチェック
    • 監査用の証跡保存

4. 最小構成の SLI/SLO セット

いきなり全部やろうとすると死ぬので、まずはこのあたりからが現実的だと思います。

  • 意味（Semantic）

    • hallucination_rate をまずは定義し、1〜3% 以下を目標にする
    • 完全自動でなくても、人手レビューのサンプリングでOK

  • 検索（Retrieval）

    • context_precision@5 を決めて、基準比 ±2% 以内をキープ

  • 安全（Safety）

    • unsafe_output_rate の上限と、false_refusal_rate とのバランス

  • 体験（UX）

    • regeneration_rate、early_abort_rate を継続監視

  • 経済（Economics）

    • cost_per_successful_task の上限
    • token_waste_ratio（意味のなかったトークン率）

  • 運用（Ops）

    • mttr_model_rollback（モデルやインデックスを戻すまでの時間）の目標

5. 代表的な失敗モード

ざっと列挙するとこんな感じです。

  • 意味系

    • 明らかな誤情報（ハルシネーション）
    • 根拠となる文書との不整合
    • JSON など構造化出力の崩壊

  • 検索系

    • インデックスの鮮度低下
    • 埋め込みモデル差し替えによる検索傾向の変化
    • ハイブリッド検索（BM25＋ベクトル）の重みずれ

  • エージェント系

    • プランが堂々巡りして終了しない
    • 同じツールを短時間に連打
    • 危険な書き込みや外部操作

  • 安全系

    • 正当な指示までブロックしてしまう過剰拒否
    • 逆に危険な出力が漏れてしまうケース

  • プロダクト／UX 系

    • UI が再生成ボタンを押させまくる設計
    • 文脈説明が弱く、ユーザーが「よくわからない」と感じて離脱

  • サイレント変更系

    • ベンダーモデルや埋め込みが、通知なしでひっそり更新される
    • リランカーが切り替わって検索結果の質が変わる

6. AISRE 成熟度ステップ

AISRE の成熟段階はざっくり 3 ステップで考えられます。

  1. 計測（Instrumentation）

    • レイヤ別の最低限のメトリクスとログを出し、ダッシュボードを作る

  2. 自動化（Automation）

    • アラートとロールバックを自動化し、「気づき」と「戻す」の時間を短縮

  3. 適応最適化（Adaptive Optimisation）

    • モデル選択やルーティング、プランナーの振る舞いをフィードバックで自動調整

まずは 1 をやらないと 2, 3 は絶対に無理、という順番です。

7. コントロールポイントとガード

AISRE 的には、「どこで止めるか／巻き戻すか」 のポイントをあらかじめ設計しておきます。

  • Gateway

    • モデルやリトリーバーの識別、フォールバックの順番、用途ごとのクォータ

  • Retrieval

    • BM25 → ベクトル → リランカーの段階的検索
    • 差分カナリア（新旧リトリーバを一部トラフィックで比較）

  • Router

    • 問い合わせの意図・難易度に応じて、最小で足りるモデルにルーティング
    • スコアが閾値未満なら、より強いモデルや人間にエスカレーション

  • Safety Sandwich

    • 入力前処理（PII マスク・プロンプト注入防御）
    • 生成中の制御（トークンレベルでの安全）
    • 出力後のフィルタ＋修復＋フォールバック

  • Agent Supervisor

    • ステップ数の上限
    • ループや重複アクションの検知とブレーク
    • 高リスク書込みの人間承認ワークフロー

  • Caching

    • 厳格一致キャッシュ＋セマンティックキャッシュ
    • コスト感度を考慮したキャッシュ戦略

  • Index Ops

    • ベクターインデックスのスナップショット保存
    • すぐ戻せるロールバックパス

8. インシデント対応の雛形

例として、「ハルシネーション＋検索鮮度の複合事故」のプレイブックです。

  • 検知条件（例）

    • hallucination_rate > 3%
    • かつ context_precision@5 が基準比から 10% 以上低下
    • これが 10 分以上続く

  • 即時アクション

    1. プロンプト／モデル／リトリーバのバージョンを凍結
    2. 直近で「良好」だったインデックスのスナップショットへ切替
    3. 新旧バンドル（モデル＋リトリーバ＋プロンプト）で影評価を実行
    4. 埋め込み遅延と取り込みジョブの状態を確認

  • 退出条件（例）

    • hallucination_rate < 1.5%
    • context_precision@5 が基準比 ±2% 以内
    • これを 60 分維持

9. スターター・チェックリスト

実務で「とりあえずここまではやろう」という最低ラインをまとめるとこんな感じ。

  • semantic_accuracy / context_precision@5 / loop_abort_rate / cost_per_successful_task / unsafe_output_rate のような レイヤを跨いだ SLI を定義
  • プロンプト・モデル・埋め込み・インデックス・リランカー・プランナーを 全部バージョン管理＆ログ化
  • リトリーバ／プランナーの デイリー・カナリア を回す
  • モデル／リトリーバ／プランナーを本番昇格する前に 影評価＋差分評価 を行う
  • エージェントの ループ防止ガード と 危険書込みガード を入れておく
  • 取り込み遅延と未使用コンテキストを可視化するダッシュボードを作る
  • モデル・プロンプト・インデックス・リランカー・プランナーそれぞれの ロールバックスクリプト を用意

10. ぼくおも（ぼくがおもったこと）

すごい目新しい発見はないが、AIを使ったプロダクトを開発している人が肌感で意識していることをSREになぞって綺麗に整理してくれていていい記事だと思った。
精度の低下についてはサンプリングして人手で採点となっているが、これはAIの精度を信じきれない限り無くならない仕事の一種だろうな。うまいこと管理できる方法はないのか。ユーザーがうまく評価してくれればいいが。社内で使うツールであれば、そのシステムを良くするためにユーザー（社員）を評価に使うのはありな気がするが。その評価が著しく低くなっときに異常検知すれば、運用者は少しは楽になるはず。
openAI社のdev ops周り知りたいな。

Discussion