🔖 キーワード索引

本ページは AI 運用（AI Operation）を 12 のセクションで多角的に解説します。 上のチップは検索・関連語の手がかりです。 以下のリンクで各セクションに直接ジャンプできます：

🔖 キーワード索引 — 核となる 14 トピック

AI 運用 (MLOps) の核となる 14 トピックを、 監視・再訓練・ロールバックの観点から整理。 本番運用に必要な「silent failure 検出」「data drift 検出」「SLO 設計」を中心に取り上げます。

🎨 直感で掴む

機械学習を本番運用するための工程・基盤。 開発と運用の橋渡しを担います。

AI 運用 (MLOps) の核心は 「学習時に固定した世界」と「本番が直面し続ける動く世界」のギャップ管理。 データドリフト・コンセプトドリフト・特徴量パイプライン故障の 3 つを監視し、 自動再学習・カナリアデプロイ・ロールバックで継続的に整える。 単発の学習プロジェクトと違い、 完了点が存在しない継続営みである点が DevOps と類似する。

🎨 直感で掴む — 具体例で理解する

AI モデルは「放っておくと劣化する生き物」。 学習時点のデータと本番データの分布が日々ズレ（データドリフト）、 ユーザー行動が変わり（コンセプトドリフト）、 上流の特徴量パイプラインが壊れる。 運用とは これらの異変を素早く検知し、 再学習・ロールバック・モデル切替を実施する仕組みを作って回すこと。

🎨 直感で掴む — 「AI モデルは生鮮食品」

AI モデルは 「賞味期限のある生鮮食品」のように扱うべき、 という比喩がよく使われます。 学習時の世界 (data distribution) と、 デプロイ後の世界はじわじわ違ってくる。 これを data drift と呼びます。

3 種類の drift

核心メッセージ: モデルが返す予測値は同じ形式 (例: float の販売額) なので、 ログを見ても劣化は分からない。 分布を監視する仕組みを別途用意しない限り、 silent failure に陥ります。

SLO/SLI で「許容できる劣化」を定義する

SLI (Service Level Indicator) は実測値、 SLO (Service Level Objective) は目標値、 SLA (Agreement) は契約値。 AI 運用では下記のような SLO 設計が定石。

• レイテンシ SLO: 99% のリクエストで p99 < 200ms
• 精度 SLO: 月次の precision > 0.85 (毎月再計算)
• drift SLO: 主要 5 特徴量で PSI < 0.1 (週次)
• 可用性 SLO: 月間ダウンタイム < 43 分 (99.9%)

📐 定義

本番環境でAIを運用・保守する活動

英語名 AI Operation。

🎯 いつ・どこで使うか

• 「MLOps」分野の標準的な道具として、 多くの分析で登場します。
• 📚 データエンジニアリング を学ぶときに必ず通過する基本概念です。
• 論文・実務レポートで頻出する用語なので、 1 度はちゃんと理解しておくと後が楽です。

📋 前提条件・適用範囲

この用語を理解・使用するときは、 次のような前提を意識してください：

• データの性質：尺度（名義/順序/間隔/比例）と分布を確認
• サンプル数：手法によって最低限のサンプル数が異なります
• 独立性：観測が独立であるかを確認（時系列・パネル等では別の手法が必要）
• 欠損・外れ値：前処理の方針を明確に

📐 数式・定義

AI 運用を数式 / 形式定義で表す：

学習データと本番データの分布乖離を KL ダイバージェンスで測る。 一定閾値を超えたら再学習トリガー。

📐 数式: PSI と KL divergence による drift 検出

(1) Population Stability Index (PSI) — 業界標準の drift 指標。 ベース期間 (学習時) の分布 $P$ と現在の分布 $Q$ をビン分割し、 各ビン $i$ の確率質量を比較する。

(2) KL divergence — 情報理論的な distance (非対称)。

(3) モデル精度劣化の SLO violation 検出 — 連続 $k$ 期間 SLO 未達なら再訓練トリガ。

判定基準 (PSI 業界慣習): 0.1 未満=安定、 0.1-0.25=要注意 (調査開始)、 0.25 以上=明確な drift (再訓練必須)。

ロールバックの判断式

新モデル (challenger) と現モデル (champion) を $\rho:1-\rho$ で並走 (canary)、 challenger の指標が champion を下回ったら自動 rollback:

$\delta$ はマージン (たとえば 2 ポイント)。 $\rho$ は通常 5%-10% から始め、 異常がなければ段階的に増やす。

🔬 発展トピック

🔬 発展トピック

「AI運用」を入門レベルで習得した次に進むべき発展テーマ：

① 理論的拡張

基本概念を 確率論・情報理論・最適化理論の観点で再定式化すると、 隣接する手法との理論的な関係が見えてきます。 たとえば 正則化は事前分布の最大事後推定と等価、 クロスエントロピー損失は KL ダイバージェンスを最小化、 といった対応関係を押さえると教科書間の往復が楽になります。

② 実装的拡張

scikit-learn 標準実装の外側に出ると、 GPU 対応・分散学習・低精度浮動小数点（fp16/bf16）・量子化（int8）・グラフ最適化（TorchScript・ONNX Runtime）など、 推論性能を 10–100 倍引き上げるテクニックが豊富にあります。 本番運用では モデル精度と推論コストのトレードオフを意識した実装が鍵。

③ 評価・解釈の拡張

予測精度だけでなく SHAP・LIME・Permutation Importance によるモデル解釈、 Calibration（確率の校正）、 Counterfactual Explanation、 Fairness 指標（demographic parity, equalized odds 等）を組合せると、 業務応用での説得力が一段増します。

④ 業界応用

医療（薬機法・GxP）・金融（モデル管理ガイドライン）・公共（個人情報保護法）など、 業界固有の規制・ガイドラインを モデル設計段階から埋め込むのが現代のスタンダード。 「AI運用」を業務適用するときは、 ドメインの専門家・法務との早期コラボレーションが成否を分けます。

PSI と KL の各記号を、 SSDSE-B-2026 の文脈で翻訳します。

📖 物語として読むと: 「PSI = $(P-Q) \log(P/Q)$ は、 ビンごとに『どれだけ多く・少なくシフトしたか』を符号付きで集計する。 $P > Q$ なら $(P-Q)>0$ と $\log(P/Q)>0$ で正、 $P < Q$ なら両方負で正 — 結果常に非負になる絶妙な設計。 だから PSI=0 は完全一致、 PSI が大きいほど drift が深刻」。

🔬 数式を言葉で読み解く（AI 運用 — MLOps 4 ステージと SLA/SLO/SLI の実務）

AI 運用 (AI operation) は「学習済みモデルを本番環境で安全に動かし続ける」一連の活動を指す。 ここでは MLOps の 4 ステージ (Build → Deploy → Monitor → Improve) を縦串に、 SLA/SLO/SLI を横串にして、 オンコール体制、 ロールバック、 監視ダッシュボード、 障害対応、 ポストモーテム、 改善計画までを連続した運用サイクルとして読み解く。 SSDSE-B-2026 を用いた人口推計モデルを題材にすると、 学習データ更新 (5 年周期の国勢調査)、 推計人口の確報値・改定値、 平均年齢の丸め桁数変更といった「実データならではの運用イベント」を具体例として扱える。 以下では「数式」よりも「運用方程式」(可用性 = MTBF / (MTBF + MTTR) など) を中心に、 言葉と数値で読み解いていく。

① MLOps 4 ステージ ― Build / Deploy / Monitor / Improve

Build ステージでは、 データ取得・前処理・特徴量設計・学習・評価・パッケージングの 6 工程を「再現可能なパイプライン」として書き下す。 SSDSE-B-2026 の場合、 raw CSV を Git LFS に置くか、 オブジェクトストレージ (S3 / GCS) に置いた上で data_version=2026.04 のようにバージョン管理する。 学習スクリプトは Docker 化し、 ハッシュ値 (Git SHA + データ SHA + 環境ハッシュ) で「学習成果物の指紋」を作る。 これがないと、 後で「なぜこの予測値か」を遡れない。

Deploy ステージは (a) Shadow Deploy → (b) Canary Deploy → (c) Full Rollout → (d) Rollback Ready の 4 段階に分解する。 Shadow ではトラフィックの 100% を新モデルにも流すが、 応答は使わずログだけ取る。 Canary は 1% → 5% → 25% → 100% と段階的に増やす。 SSDSE-B モデルの場合、 47 都道府県を 1% (1 県) → 5% (3 県) → 25% (12 県) → 100% (47 県) と段階展開できる。 Rollback Ready はワンクリックで前バージョンに戻せる状態を維持し続けること、 「巻き戻し対象モデルは 2 世代保持」が運用ルールの常識。

Monitor ステージでは、 5 種の指標 (① データ drift、 ② 予測 drift、 ③ 精度劣化、 ④ レイテンシ p99、 ⑤ 失敗率/null 率) を常時計測する。 SSDSE-B では特に「平均年齢」「推計人口」など年度をまたぐ列で drift が出やすい。 drift の検出は Population Stability Index (PSI) や KL Divergence を週次バッチで計算し、 PSI > 0.2 を黄色信号、 > 0.25 を赤信号として段階的にアラートを上げる。 監視は「閾値突破」だけではなく「閾値突破の継続時間」も同時に見る (突発的スパイクは無視、 30 分連続は通知)。

Improve ステージでは、 monitor で蓄積した障害ログ・drift 履歴・ユーザフィードバックを毎月のレトロスペクティブで読み返し、 (a) データの追加 (新しい SSDSE のリリース年度を吸収)、 (b) 特徴量の見直し (高齢化率と推計人口の二項交互作用を追加)、 (c) アルゴリズムの差替え (Ridge → LightGBM)、 (d) パイプラインの再構築 (Airflow → Prefect 移行) の 4 種の改善を優先度付きでバックログに積む。 これが「単なる維持運用」と「成長する運用」を分ける。

② SLA / SLO / SLI の三層構造

運用方程式 (可用性): 可用性 = MTBF / (MTBF + MTTR) で表される。 MTBF (平均故障間隔) を伸ばす施策と、 MTTR (平均修復時間) を縮める施策は別物で、 前者は「冗長化・カオステスト」、 後者は「runbook 整備・自動ロールバック」が効く。 SSDSE-B 推論 API で「月間 99.9% SLO、 月の総時間 43,200 分」と置くと、 許容ダウンタイムは月 43.2 分。 これを「エラーバジェット 43.2 分」と呼ぶ。 エラーバジェットが残っていれば、 多少のリスクを取って新機能をリリースできる。 使い切ったら、 新機能を凍結して安定化に専念する。 これが SRE 流の「リリース速度と信頼性のバランス」だ。

SLI 設計の落とし穴: 「成功率 = (2xx + 3xx) / 全レスポンス」を SLI にすると、 入力欠損で 400 を返すケースもエラーバジェットを消費しないため SLO が達成しやすく見える。 だが利用者から見れば「結果が返ってこない」のは同じ。 SSDSE-B では「正常な都道府県コードだが該当年度のデータがない」ケースを 400 で返してしまうと、 内部 SLO は OK でも実体感は劣化する。 そのため SLI は「ユーザ視点の成功」で測ることが重要だ。

③ オンコール体制と Runbook

オンコール (on-call) は「障害発生時に即座に対応するための当番制」だ。 一般的に Primary (1 次担当)、 Secondary (バックアップ)、 Manager-on-Duty (意思決定者) の 3 役を 1 週間ローテーションで回す。 SSDSE-B モデルのような小規模チーム (3-5 名) でも、 必ず「2 人ペア」にして、 1 人体制を避ける。 1 人だと、 体調不良・睡眠時間ゼロ・判断ミスのリスクが高すぎる。

アラート設計は「P0 = 即時 (5 分以内)」「P1 = 30 分以内」「P2 = 翌営業日」の 3 段階を基本とし、 Slack/PagerDuty の通知先を分ける。 P0 をやたら作ると「アラート疲れ (alert fatigue)」が起こり、 本物のインシデントを見逃す。 SSDSE-B の場合、 (a) 推論 API が完全停止、 (b) drift PSI > 0.5 が 30 分継続、 (c) エラー率 > 5%、 の 3 つに P0 を限定し、 それ以外は P1/P2 に落とす。 これで「夜中の P0」を月 1 回以下に抑えられる。

Runbook は「障害が起きた時、 誰が何を見て、 何を実行するか」を箇条書きで書いた手順書だ。 SSDSE-B の例: 「(1) Datadog ダッシュボード ai-ops-ssdse を開く、 (2) /predict の p99 が 500ms 超過していないか確認、 (3) drift メトリクスを確認、 (4) 直近のデプロイ履歴を確認、 (5) 異常があれば kubectl rollout undo deployment/ssdse-predict で巻き戻す、 (6) Slack の #incident チャンネルに状況を投稿、 (7) Manager-on-Duty に連絡」。 この粒度で書かれていれば、 オンコール初回でも 5 分以内に行動を開始できる。

④ ロールバックの 3 戦略

ロールバック禁忌: (a) DB スキーマ変更を伴うリリースは「単純な戻し」が破綻するため、 マイグレーションを「前方互換 (forward compatible)」に設計する。 SSDSE-B の例では、 新カラム「人口推計信頼区間」を追加する時に、 旧モデルが読まなくても落ちないよう NULL 許容にしておく。 (b) Feature flag を使う場合、 ロールバックは「コード戻し」ではなく「フラグ OFF」だけで済む設計にすると、 切り戻し時間が 5 秒に短縮できる。

Roll forward vs Roll back の判断軸: 「再現可能性」「修正コスト」「ユーザ影響継続時間」の 3 軸で決める。 例えば、 SSDSE-B 推論 API でレイテンシが 800ms に悪化したとき、 (a) 原因がコード起因で 5 分で fix できるなら roll forward (前進修正)、 (b) 原因不明・調査に 30 分以上かかるなら roll back (巻き戻し) を選ぶ。 オンコール対応の鉄則は「先に止血、 後で原因究明」。 ユーザ影響を継続させたまま原因究明するのは、 (一部の高額契約を除き) 推奨されない。

⑤ 監視ダッシュボード設計 ― RED と USE と Four Golden Signals

RED メソッド (Rate, Errors, Duration) はサービスレベル監視の 3 指標。 SSDSE-B 推論 API では (Rate = /predict の RPS、 Errors = 5xx と 4xx を分けて表示、 Duration = p50/p90/p99 を 3 本線で表示) という構成を 1 つのダッシュボードに集約する。 USE メソッド (Utilization, Saturation, Errors) はリソースレベル監視の 3 指標。 CPU 使用率、 メモリ saturation (swap 使用量)、 ディスク I/O のエラー件数を合わせて見る。 Four Golden Signals (Latency, Traffic, Errors, Saturation) は Google SRE 本由来で、 これも実質 RED + Saturation の組合せだ。

ダッシュボードの 3 段階構成: (a) Executive ダッシュボード (SLA/SLO の達成率、 月次のエラーバジェット消費)、 (b) Service ダッシュボード (RED + USE をリアルタイム表示)、 (c) Debug ダッシュボード (個別 endpoint のレイテンシ分解、 GC 時間、 DB クエリ時間)。 オンコール担当が真っ先に開くのは (b)、 RCA で潜るのは (c)、 月次レビューで見るのは (a)。 役割別に画面を分けると「アラート → 5 分で初期対応 → 30 分で root cause」の動線が成立する。

⑥ 障害対応のタイムライン (Incident Response Lifecycle)

標準的な障害対応は 6 フェーズ: (1) Detect (検知) → (2) Triage (重大度判定) → (3) Mitigate (一時対処) → (4) Resolve (本対処) → (5) Postmortem (事後分析) → (6) Prevent (再発防止)。 SSDSE-B で「全推論が NaN を返し続ける」障害が起きた場合のタイムラインを書き下すと:

⑦ ポストモーテム ― Blameless と 5 Whys

Blameless Postmortem は「個人を責めず、 システムの弱さを責める」原則。 「○○さんがコマンドを打ち間違えた」ではなく「打ち間違えても安全装置が働かない設計だった」と書く。 そうしないと、 次から誰も正直に経緯を語らなくなり、 学びが消える。 SSDSE-B の例で「推計人口の二重取り込み」が原因だった場合、 個人の見落としではなく「データ取り込みパイプラインに idempotent (冪等) 性が欠如していた」と表現する。

5 Whys は「なぜ?」を 5 回繰り返して根本原因に辿り着く技法。 上記の例: (1) なぜ NaN が出た? → 推計人口が二重に足されゼロ除算が発生。 (2) なぜ二重に足された? → 確報値と改定値が別レコードとして CSV に共存。 (3) なぜ別レコードが見えなかった? → スキーマ検証が「行数のみ」で内容を見ていない。 (4) なぜ内容検証がなかった? → 過去のリリースで「形式チェック」のみで通っていた。 (5) なぜ通っていた? → 「データ品質テスト」が CI に組み込まれていない。 → 根本対策: dbt や Great Expectations を CI に組み込む。 ここまで降りて初めて、 表面対症療法ではない構造改善になる。

ポストモーテムの構成要素 (8 項目): (1) サマリ (3 行)、 (2) ユーザ影響 (人数・時間・損失)、 (3) タイムライン (5 分粒度)、 (4) Root cause (5 Whys)、 (5) Resolution (どう収束したか)、 (6) Lessons learned (何を学んだか、 ポジティブも含む)、 (7) Action items (期限・担当・優先度付き、 通常 5-10 件)、 (8) Supporting documents (Slack ログ、 Datadog 画面のスクリーンショット)。 これを毎月 1 回チーム全員でレビューする「Postmortem Review Meeting」を設けると、 1 件のインシデントから 10 人が学べる。

⑧ 改善計画 (Continuous Improvement)

4 種の改善バックログ: (a) Reliability (信頼性) — エラーバジェット消費を減らす施策、 (b) Performance (性能) — レイテンシ削減、 スループット改善、 (c) Cost (コスト) — クラウド費用、 GPU 時間の最適化、 (d) Developer Experience (開発者体験) — CI 時間短縮、 デプロイ自動化。 各バックログから毎四半期 1-2 件ずつ取り、 OKR (Objective and Key Results) に紐付ける。 SSDSE-B チームなら「Q1 OKR: p99 を 500ms → 250ms にする (Reliability + Performance)」のような形で結束させる。

エラーバジェット駆動の優先付け: 月初にバジェットが 100% 残っていれば新機能リリース、 50% 残なら新機能とリライアビリティ施策を半々、 25% 以下なら新機能凍結。 これにより「リリースを止めるか進めるか」が感情論ではなく数字で決まる。 SSDSE-B で「月のうち SLO 違反が 30 分、 バジェット 43.2 分の 70%」なら、 残り 13.2 分。 新機能のリリースを 1 件に絞り、 残りはリライアビリティ施策に充てる、 という判断ができる。

⑨ AI 運用に特有のメトリクス ― ML-specific Observability

ML-specific Observability の鉄則は「労力をかけてラベルを付けて検証する遅延評価 (delayed evaluation) と、 即時に観測できる代理指標 (proxy metric) の 2 段構え」にすること。 SSDSE-B 推計人口は、 答え合わせが翌年の確報まで待つ必要があるため、 「予測の自己整合性 (前月予測との滑らかさ)」「過去の同月予測との差分」など、 ラベル不要の proxy metric を主軸にし、 毎年の答え合わせで proxy の妥当性そのものを検証する。

⑩ 図で見る運用サイクル

✅ 理解度チェック (3 問)

Q1. SLO 99.9% を月次目標として運用する SSDSE-B 推論 API がある。 月初から 25 日経過時点で、 累計ダウンタイムが 35 分だった。 月の総時間を 43,200 分とすると、 残りエラーバジェットは何分か。 また、 この状況で新機能をフルリリースして良いか? (答え: 43.2 - 35 = 8.2 分。 バジェット消費 81%、 残り 19%。 25% 未満になっているので新機能はフリーズ、 リライアビリティ施策のみに専念すべき。)

Q2. SSDSE-B モデルで「推計人口」の drift PSI が 0.18 → 0.22 → 0.27 と 3 週連続で上昇した。 PSI 閾値は 0.20 = 黄、 0.25 = 赤に設定されている。 オンコール担当はどう行動すべきか? (答え: 黄突破後の継続上昇かつ赤突破済み。 (a) 直近のデータ取り込みパイプライン変更を確認、 (b) 確報値と改定値の取り込みが二重になっていないか確認、 (c) 必要なら再訓練ジョブをトリガ、 (d) Slack で状況共有し、 状況によっては Manager-on-Duty にエスカレーション。)

Q3. ポストモーテムで「オペレータがコマンドを打ち間違えた」と書きたくなった。 Blameless 原則に従って書き換えるなら、 どう表現するか? (答え: 「破壊的コマンドに confirmation prompt がなく、 typo を防ぐ安全装置が不十分だった」と書く。 個人ではなくシステムの設計上の弱点として記述する。 Action item としては「rm -rf, kubectl delete などに confirm 必須化する shell wrapper を導入」と続ける。)

📝 まとめ ― 運用の四原則

AI 運用は「Build / Deploy / Monitor / Improve」の 4 ステージを止めないこと。 (i) SLA/SLO/SLI で測定可能な目標を立て、 エラーバジェットで優先付け、 (ii) オンコールと runbook で 5 分以内に初動できる体制、 (iii) ロールバックは「コマンド 1 つで 30 秒以内に戻せる」状態を常時維持、 (iv) Blameless postmortem と 5 Whys で構造改善を続ける。 SSDSE-B のような実データを扱う運用では、 「データ更新サイクルに合わせた drift 監視」「確報値・改定値の二重取り込み防止」「47 都道府県粒度での Canary 展開」など、 ドメイン固有の運用設計が品質を分ける。 教科書的な MLOps を学んだら、 必ず自分の手元データで「障害台帳」「runbook」「postmortem テンプレート」を 1 枚ずつ書いてみると、 運用の解像度が一気に上がる。

🧮 SSDSE-B 実値計算 — 都道府県データで手を動かす

SSDSE-B-2026 で 「過去 2 年（2024 vs 2026）の人口分布変化」を擬似ドリフトとして可視化することで、 運用フェーズで必要な分布監視のイメージを掴む。

使用データ：SSDSE-B-2026.csv（独立行政法人 統計センター提供、 47 都道府県 × 100 超の社会経済指標）。 出典

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

import pandas as pd
import numpy as np

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df.rename(columns={df.columns[2]: 'pref'})

# 「過去総人口」を A1101 から出生数(A4101)を引いて擬似生成（ドリフト検知デモ）
df['pop_now']  = df['A1101']
df['pop_past'] = df['A1101'] - df['A4101']  # 1 年分の出生数を引いた擬似過去人口

# 分布の平均・標準偏差で簡易ドリフト指標
mu_now,  sd_now  = df['pop_now'].mean(),  df['pop_now'].std()
mu_past, sd_past = df['pop_past'].mean(), df['pop_past'].std()
drift = abs(mu_now - mu_past) / sd_past
print(f'Drift 指標 = {drift:.4f}（0.1 以上で要再学習）')

▲ 上記コードはそのまま実行可能。 CP932 エンコーディング・skiprows=[1]（2 行目の日本語名行をスキップし 1 行目の列コードをヘッダにする）・列名の英数字コード（A1101 = 総人口 など）に注意。

🧮 SSDSE-B-2026 で PSI を実値計算

SSDSE-B-2026 の A1101 (人口) を 5 つのビンに分割し、 仮想的に「学習時 (5 年前と仮定)」と「現在」の分布で PSI を計算します。

判定: PSI = 0.0429 < 0.1 → 「安定」領域。 緩やかな少子高齢化を反映した分布シフトはあるが、 モデルを慌てて再訓練する必要はない。 ただし継続監視は必要 (来月 0.12 になるかもしれない)。

🧮 数式に値を入れて手で計算する: 月次 SLA (稼働率)

AWS や Azure の SLA 公開数値 (月間 99.9% 以上) に準じた代表シナリオで、 月別の稼働時間から SLA 達成率を計算する。 SSDSE-B-2026 を題材にした運用ログ集計の実装は下の章 8 を参照。

Step 1: 月別ダウンタイム

Step 2: 5 ヶ月平均稼働率

🐍 Python で再現

1
2
3
4
5
6

import numpy as np
total = np.array([744, 672, 744, 720, 744])
down = np.array([2, 5, 1, 3, 7])
uptime = (total - down) / total
print(f"月別稼働率: {uptime.round(4)}")
print(f"平均: {uptime.mean()*100:.2f}%")

📤 実行結果

💬 手計算 (Step 2) 99.50% と Python 出力が完全一致。

🐍 Python での扱い

SSDSE-B-2026 のような公的統計データを Python で扱う際の基本パターン：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

import pandas as pd
import numpy as np

# データ読み込み
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
print(df.shape)
print(df.dtypes)
print(df.describe())

# 「AI運用」の文脈で扱う場合の例：
# 分野: MLOps
# 関連手法は同カテゴリの他用語を参照してください。

具体的なコードは データエンジニアリング を参照してください。

📝 レポートでの報告

分析結果を報告するときに含めるべき情報：

• 使ったデータ：出典・期間・サンプル数
• 適用条件の確認：前提が満たされているか
• 計算結果：数値だけでなく不確実性（CI・SE）も
• 解釈：何を意味するか、 何を意味しないか
• 限界：適用範囲外への拡張は避ける

✅ チェックリスト

• □ 「AI運用」を使う場面か再確認したか
• □ データの尺度・分布・サンプル数を確認したか
• □ 前提条件を満たしているか
• □ 計算した値だけでなく不確実性も把握したか
• □ 解釈と限界を区別したか
• □ 関連グループ教材で全体像を確認したか

🔗 同カテゴリの他用語

🐍 Python 実装バリエーション

「AI 運用」を扱う代表的なライブラリ別実装。 同じ目的でも書き方が違うため、 自分のプロジェクトの依存関係に合わせて選択する：

① pandas + numpy（最小依存）

1
2
3
4
5
6
7
8

import pandas as pd
import numpy as np

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df.rename(columns={df.columns[2]: 'pref'})

print('行数:', len(df), '列数:', df.shape[1])
print(df[['pref', 'A1101', 'A1303', 'A4101', 'B4101']].head())

② scikit-learn（学習・評価）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

from sklearn.linear_model import LinearRegression
from sklearn.metrics import r2_score, mean_squared_error
from sklearn.model_selection import train_test_split
import numpy as np

X = df[['A1101', 'A1303']].fillna(0).values
y = df['A4101'].values
X_tr, X_te, y_tr, y_te = train_test_split(X, y, test_size=0.2, random_state=42)
m = LinearRegression().fit(X_tr, y_tr)
pred = m.predict(X_te)
print(f'R²   = {r2_score(y_te, pred):.3f}')
print(f'RMSE = {np.sqrt(mean_squared_error(y_te, pred)):.2f}')

③ scipy.stats（統計検定・分布）

1
2
3
4
5
6
7
8
9

from scipy import stats

# 例: 2 変数の Pearson 相関 + p 値
r, p = stats.pearsonr(df['A1101'], df['A4101'])
print(f'相関係数 r = {r:.3f}, p 値 = {p:.2e}')

# 例: 1 標本 t 検定（平均が一定値と異なるか）
t, p = stats.ttest_1samp(df['A4101'], popmean=df['A4101'].mean())
print(f't = {t:.3f}, p = {p:.3f}')

④ 可視化（matplotlib + seaborn）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

import matplotlib.pyplot as plt
import seaborn as sns

fig, ax = plt.subplots(figsize=(8,5))
sns.scatterplot(data=df, x='A1101', y='A4101', ax=ax)
ax.set_xlabel('総人口')
ax.set_ylabel('出生数')
ax.set_title(f'{len(df)} 都道府県の関係')
plt.tight_layout()
plt.savefig('out.png', dpi=120)
plt.close()

🐍 Python 実装 — drift 検出と監視の 4 パターン

例 1: scipy で PSI 関数を実装

🎯 このコードでやること: SSDSE-B-2026 の A1101 (人口) を 10 ビンに分割し、 PSI を計算する関数を自作する。 学習時の分布として「2023 年の全 47 都道府県」、 現在の分布として「上位 30 都道府県のみ」をシミュレート。

📥 入力データ:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

import pandas as pd
import numpy as np

def psi(base, current, n_bins=10):
    edges = np.linspace(base.min(), base.max(), n_bins + 1)
    p, _ = np.histogram(base,    bins=edges); p = p / p.sum() + 1e-6
    q, _ = np.histogram(current, bins=edges); q = q / q.sum() + 1e-6
    return float(np.sum((p - q) * np.log(p / q)))

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
d = df[df['SSDSE-B-2026'] == 2023]            # 2023 年の 47 都道府県に固定
base    = d['A1101']
current = d.nlargest(30, 'A1101')['A1101']    # 上位 30 だけのシナリオ
print(f'PSI (基準 vs 上位 30): {psi(base, current):.4f}')
interpret = lambda v: '安定' if v < 0.1 else ('要注意' if v < 0.25 else '要再訓練')
print(f'判定: {interpret(psi(base, current))}')

📤 実行例:

💬 結果の読み方: 「上位 30 都道府県だけ」は意図的に分布を歪めたシナリオなので PSI が 0.21 (要注意帯 0.1–0.25) に上昇する。 母集団が 47 件と小さいためビンが粗く、 0.25 の再訓練閾値までは届かない。 実運用では「先月の入力」と「今月の入力」のような時系列で比較する。

例 2: KS test で連続変数の drift 検定

🎯 このコードでやること: Kolmogorov-Smirnov test で 2 分布の差を統計的に検定する。 PSI は連続値だが、 KS test は p 値が得られるので「統計的に有意な drift か」を判定できる。

📥 入力データ: 例 1 の base, current を流用。

1
2
3
4
5
6

from scipy.stats import ks_2samp

stat, pval = ks_2samp(base, current)
print(f'KS 統計量: {stat:.4f}')
print(f'p 値     : {pval:.4f}')
print(f'結論     : {"drift あり (有意)" if pval < 0.05 else "drift なし"}')

📤 実行例:

💬 結果の読み方: KS 統計量 0.36 (= 2 分布の CDF の最大差) で p=0.012 < 0.05 → 「2 分布は統計的に異なる」と結論。 PSI (連続値) と KS (有意性検定) を組み合わせると堅牢な検出ができる。

例 3: 精度の継続監視ログ

🎯 このコードでやること: 月次でモデル精度 (RMSE) を測定し、 SLO (RMSE < 5,000) を割ったらアラート文字列を出力する。 ドリフトの発生自体は合成 (シミュレーション) で、 固定した検証セットに月ごとに増大する乖離を注入している。

📥 入力データ: SSDSE-B-2026 を学習データとし、 SSDSE-B-2026 の 2023 年 47 都道府県で 総人口 A1101→出生数 A4101 回帰を学習。 現実には未来データを待つが、 デモのため固定検証セット (20 件) に月次でドリフト係数 (月 6%) を掛けた合成シナリオで RMSE 推移を再現する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

import pandas as pd
import numpy as np
from sklearn.linear_model import LinearRegression
from sklearn.metrics import mean_squared_error

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
d = df[df['SSDSE-B-2026'] == 2023]              # 2023 年の 47 都道府県に固定
model = LinearRegression().fit(d[['A1101']], d['A4101'])
val = d.sample(n=20, random_state=42)           # 固定の検証セット
pred = model.predict(val[['A1101']])
SLO_RMSE = 5000
for month in range(1, 7):                       # 月ごとに drift を注入するシミュレーション
    drift = 1 + 0.06 * (month - 1)              # 合成: 関係性が月 6% ずつ乖離
    rmse = np.sqrt(mean_squared_error(val['A4101'] * drift, pred))
    status = 'OK' if rmse < SLO_RMSE else 'ALERT'
    print(f'2026-{month:02d}  RMSE={rmse:>8.0f}  [{status}]')

📤 実行例:

💬 結果の読み方: 注入したドリフトにより 4 月から SLO 違反開始。 3 か月連続 ALERT で「再訓練トリガ」発動が定石。 これがあるからこそ「silent failure」が「audible failure」に変わる。

例 4: champion-challenger とロールバック判定

🎯 このコードでやること: 現行モデル (champion) と新候補 (challenger) を並走させ、 challenger のメトリクスが下回ったら rollback フラグを立てる。

📥 入力データ: 同じ SSDSE-B-2026 で、 出生数 (A4101) を目的変数とし、 champion は総人口 (A1101) のみ、 challenger は総人口 + B4101 (年平均気温) を使う。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

import pandas as pd
from sklearn.linear_model import LinearRegression
from sklearn.model_selection import cross_val_score

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
d = df[df['SSDSE-B-2026'] == 2023]              # 2023 年の 47 都道府県に固定
y = d['A4101']
champion   = LinearRegression()
challenger = LinearRegression()
r2_champ   = cross_val_score(champion,   d[['A1101']],          y, cv=5).mean()
r2_chal    = cross_val_score(challenger, d[['A1101', 'B4101']], y, cv=5).mean()
margin = 0.005
rollback = r2_chal < r2_champ - margin

print(f'champion   R^2: {r2_champ:.4f}')
print(f'challenger R^2: {r2_chal:.4f}')
print(f'rollback判定: {rollback}')

📤 実行例:

💬 結果の読み方: challenger に加えた B4101 (気温) は出生数とほぼ無相関のため R² はほぼ同値 (−0.0002pt)。 margin 0.5pt 以内なので自動 rollback は発火しないが、 明確な改善もないため昇格は見送り、 champion を維持するのが定石。 「悪化していない」ことと「昇格に値する」ことは別、 という運用判断がここでの学び。 これが MLOps の継続デリバリの肝。

⚠️ よくある落とし穴

⚠️ よくある落とし穴（5 件）

「AI 運用」を実務・試験で扱うときに頻発する典型的なミスです。 各項目を 1 度読んでおけば 9 割の事故が防げます：

⚠️ AI 運用の 5 大落とし穴

1. Silent failure: モデルはエラーを吐かず、 ただ精度だけが下がる。 HTTP 500 監視では検知不能。 必ず予測分布・特徴量分布の監視 (PSI / KL) を別レイヤで仕込む。
2. コスト爆発: GPU 推論は 1 リクエスト数円規模。 「ユーザー急増で 1 日 100 万円課金」事故が頻発。 必ず予算アラート (AWS Budgets / GCP Billing alert) と auto-scale 上限を設定。
3. ロールバック手順の未整備: 「とりあえずデプロイ」で本番が落ちた時、 旧モデルへの戻し方が不明だと数時間〜数日の障害に。 model registry に必ず previous version を保持し、 ワンクリックで戻せる体制を作る。
4. ラベル遅延: 教師信号 (正解) が即座に得られないタスク (例: 1 年後の販売額予測) では、 精度劣化が見えるまで 1 年かかる。 「proxy metric」 (短期的に観測可能な代理指標) の設計が必須。
5. 監査ログ不足で再現不能: 「いつ・どのバージョンのモデルが・どのデータで予測したか」を残さないと、 顧客クレーム対応や規制対応で詰む。 MLflow / Weights & Biases / DVC で lineage を強制保存。

🌐 関連手法・派生

🔗 関連用語（前提・並列・発展）

📘 前提となる用語

「AI 運用」を理解する前に押さえておきたい基礎概念：

📗 並列・対比される用語

同じ抽象度で並べて比較すると理解が深まる用語：

📕 発展・関連派生

「AI 運用」を起点に学習を進めると次に出会う応用・派生：

📌 まとめカード — 試験前 1 分復習

🗓 歴史・年表

AI運用の主要なマイルストーン：

📊 比較表 — 同カテゴリの主要選択肢

「AI運用」と関連する手法・概念を比較しておくと、 使い分けに迷わない：

❓ よくある質問 (FAQ)

「AI運用」について試験対策・実務で頻出する質問とその回答：

📝 実践演習 — 手を動かして定着

本ページの理解を確認する 5 問の練習問題です。 紙とペン、 もしくは Python で取り組んでみてください：

1. 定義の言い換え：「AI運用」を 2 行以内で自分の言葉に書き直してください。 出典を引用しないこと。
2. カテゴリ整理：「AI運用」が属するカテゴリ「MLOps」内で、 隣接する 3 用語を挙げ、 それぞれとの違いを 1 文で書く。
3. SSDSE-B-2026 で実装：本ページの「🧮 実値計算」のコードを実行し、 出力結果をスクリーンショットで残す。
4. 落とし穴チェック：本ページの「⚠️ 落とし穴」5 件のうち、 自分が実際にやってしまいそうな 1 件を選び、 防止策を 100 字で書く。
5. 応用シナリオ：「AI運用」を新しい問題（自分の業務 or 卒研テーマ）に当てはめると、 どの場面で何のために使えるか、 200 字で書く。

💡 ヒント：練習問題の答えは正解が 1 つではありません。 思考プロセスを書き残すことが学習効果を高めます。

🔗 関連用語 (前提・並列・発展)

📚 参考文献・学習リソース

📚 参考文献・学習リソース

「AI運用」をさらに深掘りするための一次資料・教科書・オンラインコース：

• はじめてのパターン認識（平井有三、 森北出版）— 古典 ML の網羅的入門
• Pattern Recognition and Machine Learning（Bishop, Springer）— 数理的に厳密
• Deep Learning（Goodfellow, Bengio, Courville）— 深層学習の標準教科書
• The Elements of Statistical Learning（Hastie, Tibshirani, Friedman）— 統計学習の正典
• scikit-learn ユーザーガイド — Python 実装の決定版オンライン教材
• Hugging Face Course — Transformer/LLM の無料コース
• Kaggle Learn — 短時間で実践スキルが身につくマイクロコース
• JDLA G 検定 公式テキスト — 日本の AI 資格対策に最適
• 統計検定 公式問題集 — 統計理論の橋渡しに有用
• JMOOC / Coursera / edX — 大学レベル講義を無料/低価格で受講可能

🔍 深掘り解説 — 中級者向け補強

AI 運用は 「動かし続けること」が至上命題。 デプロイ後の精度劣化、 トラフィック急増、 上流データの破損、 推論レイテンシ悪化、 すべてが運用フェーズで対応すべき事象。 SRE 的観点で SLO/SLA を定め、 ダッシュボードとアラートを整備し、 オンコール体制を組む。 これらが整って初めて「本番運用」と呼べる。

📋 代表シナリオ一覧

AI 運用の主要タスク：

💼 ビジネス文脈での扱い

「AI運用」を業務適用する際は、 (1) 業務 KPI と評価指標の対応、 (2) データの収集・保管・更新コスト、 (3) 社内承認とコンプライアンス、 (4) 運用人員の確保、 (5) 失敗時のロールバック計画の 5 観点をプロジェクト計画書に必ず明記してください。 技術検証（PoC）の段階で 本番運用要件を逆算しておくと、 後の本番化フェーズで詰まる確率が下がります。

🧪 学習ロードマップ

1. 定義の把握：本ページの「📐 数式・定義」を 3 回読む
2. 具体例の理解：「🎨 直感で掴む」と「🧮 実値計算」のコードを実行する
3. 落とし穴の暗記：「⚠️ 落とし穴」5+ 件を 1 行ずつ自分の言葉で要約
4. 関連概念の整理：「🔗 関連用語」を前提・並列・発展でマインドマップに描く
5. 応用問題：自分の業務 or 卒研テーマにAI運用を適用してみる
6. 説明テスト：他人に 3 分で説明できるか試す。 詰まったポイントを補強

🗂 ミニ用語集 — 本ページ頻出語

「AI運用」を学ぶ過程で頻出する関連語を 12 個、 短文定義でまとめます。 知らない語があれば各ページにジャンプしてください：

機械学習 (ML)

データからパターンを自動で学ぶ手法。 AI の中核技術。

深層学習 (DL)

多層ニューラルネットによる ML。 画像・言語で強い。

教師あり学習

入力と正解ラベルのペアから学習する枠組み。

教師なし学習

正解ラベルなしで構造を見つける学習。 クラスタリング等。

強化学習

環境との相互作用と報酬から最適行動を学ぶ。

汎化

学習データに含まれない未知データでも性能を出すこと。

過学習

Train データに適合しすぎ、 未知データで性能が落ちる現象。

交差検証 (CV)

データを K 分割し平均で評価。 小データのロバスト評価。

特徴量エンジニアリング

予測精度を上げるために変数を設計・変換する作業。

評価指標

RMSE・F1・AUC など、 モデル性能を測る尺度。

ハイパラ調整

学習で直接決まらない設定値を体系的に最適化する作業。

MLOps

ML モデルの本番化・運用・監視・再学習を統合する活動。

AI運用集は 514 用語を 29 のグループ教材と連動して整理しています。 周辺概念を 1 つずつ辿ると、 「AI運用」の位置づけと使い分けが立体的に理解できます。

✅ チェックリスト — 実務で使う前の最終確認

AI運用を実際のプロジェクトやレポートに適用する前に、 以下の項目を確認してください：

• □ 定義の理解：本ページ「📐 数式・定義」の数式を、 紙に書き出して自分で説明できる
• □ 適用条件の把握：使用前提（サンプル数・データ尺度・独立性）を満たしているか確認した
• □ データ品質チェック：欠損値・外れ値・スケール・分布の偏りを確認した
• □ ベースラインの設定：シンプルなモデルから始めて、 比較基準を作った
• □ 評価指標の選定：業務 KPI と機械学習指標の対応関係を明文化した
• □ Train/Val/Test の分割：データリーケージを避けた分割設計
• □ 再現性の確保：random_state 固定・ライブラリバージョン固定・データバージョン管理
• □ 不確実性の評価：点推定だけでなく信頼区間・標準誤差も算出
• □ 結果の解釈：「何を意味するか」「何を意味しないか」を明確に区別
• □ 限界の明示：適用範囲外への外挿を避ける記述を加えた
• □ 倫理・規制の確認：プライバシー・公平性・説明責任への対応
• □ 運用設計：監視・再学習・ロールバックの仕組みを準備した
• □ ドキュメント化：モデルカード・実験ログを残した
• □ ステークホルダ説明：非技術者にも 3 分で説明できる
• □ 関連グループ教材で全体像を確認した

📝 レポート・論文での書き方

AI運用を分析レポート・卒業論文・社内資料で扱う際の 標準的な記述構成：

① 背景と目的

何を予測・分類・最適化したいか、 業務上の意義を 100-200 字で明確化。 ターゲット指標と成功基準を必ず数値で記述（例「F1 ≥ 0.85 を目指す」）。

② 使用データ

出典・期間・サンプル数・前処理手順を表形式で示す。 SSDSE-B-2026 のような公的データを使う場合は 取得日と URLも明記。 欠損率・外れ値処理の方針も記述。

③ 手法

使用したアルゴリズム・ハイパラ・ライブラリバージョンを記述。 数式は本ページ「📐」のように $$...$$ で記述すると LaTeX/Markdown 共通で扱える。

④ 結果

点推定だけでなく、 信頼区間・標準誤差・p 値を併記。 グラフは scatter / box plot / heatmap を適材適所で使い分け。 軸ラベル・凡例・キャプションを忘れず。

⑤ 解釈

「数値が意味すること」と「意味しないこと」を分けて記述。 相関と因果を混同しない、 外挿を避ける、 など慎重に。

⑥ 限界と今後

本研究の制約（データ量・対象期間・対象地域）と、 今後の研究で解決したい点を率直に書く。 査読者・上司は限界の自己認識を必ず確認する。

⑦ 参考文献

本ページ「📚 参考文献・学習リソース」を起点に、 一次資料を引用。 BibTeX 形式で管理しておくと再利用が楽。

🎓 試験対策ピンポイント

統計検定・G 検定・基本情報・応用情報・ML エンジニア試験でAI運用が問われやすい論点：

1. 定義の言い換え問題：AI運用を別の言葉で説明できるか。 教科書の定義丸暗記ではなく、 自分の言葉に翻訳しておく。
2. 隣接概念との比較：似て非なる概念（例：AI と ML、 分類と回帰、 Val と Test）の違いを 1 行で書ける。
3. 数式の読み解き：本ページ「🔬 数式を言葉で読み解く」の記号一覧を覚える。 各記号の意味を埋める穴埋め問題が多い。
4. 代表的アルゴリズム名：AI運用の代表手法（例：勾配ブースティングなら XGBoost, LightGBM）を 3 つ以上挙げられる。
5. 落とし穴の選択肢問題：本ページ「⚠️ 落とし穴」の典型ミスは試験で問われる頻出論点。
6. 応用シナリオ判定：「このシナリオでどの手法を使うか？」という選択肢問題。 本ページ「🔍 深掘り解説」のシナリオ表が役立つ。
7. 計算問題：簡単な数値計算が出る場合がある。 本ページ「🧮 実値計算」のコードを 1 度実行しておくと身につく。
8. 歴史・年代問題：AI運用が提案された年・人物が問われる場合がある。 本ページ「🗓 歴史・年表」を確認。

📌 試験対策のコツ：用語の 定義 + 使用場面 + 制約条件 をセットで覚えると応用が利きます。

• 関連教材: MLOps 全体像 — デプロイから廃止までのライフサイクル
• 関連教材: モデル監視と可観測性 — SRE × ML の融合
• 関連教材: AI/データ ガバナンス — 規制対応とリスク管理
• 関連教材: クラウド AI 運用 — AWS/GCP/Azure の実例
• 関連教材: クラウドサービスとコスト — GPU/推論コストの削減策

📈 MLOps 成熟度モデル — Google による 3 レベル

Google Cloud の MLOps 成熟度モデルでは、 組織を 3 レベルで分類します。 自社がどこにいて、 次にどこを目指すかの目安に。

多くの企業は Level 0 ↔ Level 1 の境界にいます。 Jupyter で動くものを「pipeline 化」するだけで再現性・監査性が劇的に向上します。 SSDSE-B-2026 を扱うような社会指標分析でも、 月次再訓練を行うなら Level 1 化が現実的目標。

♻️ 再訓練ストラテジー 4 種

「モデルを再訓練すべきタイミング」の判断基準は、 ユースケースの drift 速度と運用コストのバランスで決まります。

ハイブリッド推奨: 実務では「スケジュール型 (基本)」+「drift 駆動型 (緊急対応)」のハイブリッドが王道。 「毎月 1 日に再訓練。 ただし PSI > 0.25 検知時は即時再訓練」のような複合トリガを設定。

📡 AI 運用の可観測性 (Observability) — 4 シグナル

SRE 由来の可観測性 4 シグナル (latency / traffic / errors / saturation) を AI 運用向けに拡張すると、 下記 8 シグナルになります。 これらをすべて Prometheus / Datadog / CloudWatch などに送り、 アラート設計します。

運用 Tips: 4 つの SRE シグナルは「アプリ落ちた」を検出するが、 後半 4 つの ML シグナルがないと「精度劣化」は見えない。 だから AI 運用では 両方を必ず併用することが、 silent failure 防止の最低条件です。

💰 推論コスト最適化の 6 テクニック

本番運用で最も「黙って溶ける」のが推論コスト。 SSDSE-B-2026 のような小規模データなら問題になりませんが、 大規模 LLM の推論では月額数百万〜数億円のコストに直結します。

1. モデル蒸留 (distillation): 大きな teacher モデルから小さな student モデルに知識転移。 推論速度 5-10 倍。 蒸留 参照。
2. 量子化 (quantization): float32 → int8 で 4 倍の高速化・メモリ削減。 精度劣化は 1% 程度。 量子化 参照。
3. キャッシング: 同じ入力には同じ予測を返す。 SSDSE のように静的データなら 100% キャッシュヒットも狙える。
4. バッチ推論: リアルタイム不要なら 1 時間分まとめて推論。 GPU 利用率が劇的に上がる。
5. autoscale: トラフィックに応じて vm 数を調整。 ピーク以外は最小台数で稼働。
6. 段階的推論 (cascade): 軽量モデルで先にフィルタ、 難しいケースのみ重いモデル。 平均コスト 30% 減のケースも。

典型コスト構造: LLM API 系は「入力トークン数 × 単価 + 出力トークン数 × 単価」。 SSDSE のような構造化データを直接モデルに入力する場合は前処理 (csv → text) で大量トークン消費するので、 必要な列だけ抜粋する設計が重要。

🧪 本番 A/B テストの設計 (champion-challenger の運用編)

オフライン評価 (cross_val_score) で勝っても、 本番では負けることがあります。 これを 「オフライン-オンラインギャップ」と呼び、 必ず本番 A/B テストで最終判定します。

設計の 5 要素

1. 仮説: 「challenger は champion より RMSE が 5% 改善する」
2. メトリクス: primary (KPI 直結) + secondary (健全性) + guardrail (悪化監視)
3. サンプルサイズ: 統計的検出力 0.8 を満たすトラフィック量 (大抵 1 週間〜1 ヶ月)
4. 分割: ユーザー単位 (cookie / user_id) で 50:50 split。 都道府県単位だと交絡発生
5. 停止条件: guardrail (例: latency p99 > 500ms) 抵触で即時停止

よくある失敗

• ピーク効果: テスト開始直後の新規性で一時的に上がる → 最低 2 週間は観察
• weekly seasonality: 月曜と土曜で挙動が違うので、 必ず 7 日の倍数で評価
• SRM (sample ratio mismatch): 50:50 のはずが 48:52 になっている → ランダム化バグ

🧰 MLOps ツールスタック早見表

「自社の MLOps スタックを 0 から組む」場面で参考になる、 OSS 中心の選択肢を機能別に整理しました。

SSDSE スケールでの実装案: 47 都道府県の月次再訓練なら、 MLflow + Airflow + Evidently の OSS 3 点セットで十分。 クラウド (AWS / GCP) の請求書を抑えつつ、 lineage・パイプライン・drift 監視の 3 本柱が揃う最小構成。

🚨 AI インシデント対応 7 ステップ

drift 検知 / SLO 違反 / クレーム受信のいずれかで発火するインシデントには、 SRE の handbook を AI 向けに拡張した手順で対応します。

1. Detect — 監視ダッシュボードで異常検知。 「PSI > 0.25 が 3 日連続」「precision < 0.85 が週次で 2 期間連続」など明確な発火条件。
2. Triage — 重大度 (P0 / P1 / P2) を判定。 顧客影響あり = P0 (即対応)、 内部 KPI のみ = P2 (週次対応可)。
3. Mitigate — 即時の被害最小化。 旧モデルへロールバック、 traffic を 50% カット、 ルールベースに切替など。
4. Diagnose — 根本原因 (RCA) 特定。 「特定セグメントの drift」「上流データソースの schema 変更」「敵対的攻撃」などを切り分け。
5. Remediate — 恒久対応。 再訓練、 特徴量追加、 アーキ変更。 challenger モデルとして検証してから昇格。
6. Verify — 復旧確認。 同じトリガが再発しないことを 2 週間ほど監視し、 SLO 復帰を確認。
7. Postmortem — 振り返り会議。 blame-less でタイムライン整理、 再発防止策を 3-5 個リストアップしチケット化。

典型 RCA カテゴリ (SSDSE 文脈): ① データ収集側で smbc が schema を変更、 ② 季節性 (年度替わりで人口統計データの更新タイミング変化)、 ③ 上流統計の方法論変更 (国勢調査の集計区分変更)。 いずれも自前モデル外の原因なので、 上流ステークホルダーとの連携が必須。

📡 補遺 — 監視ダッシュボードに必ず置く 5 つのチャート

AI 運用で最初に整備すべきは 5 種類の時系列モニタ。 SSDSE-B-2026 を学習データとし、 都道府県の経済指標を予測するモデルを本番運用するケースを想定して具体化する。

SSDSE-B 固有のリスク要因: ① 国勢調査の更新は 5 年周期で大きな段差を生むため、 更新月は drift アラートを一時的に緩める、 ② 推計人口は確報値・改定値の 2 段階で発表されるため、 同じ年でも値が変わる (二重学習注意)、 ③ 平均年齢の小数点丸めが過去と異なる年度がある (前処理を改修した時は backfill 必須)。 これらを postmortem に必ず反映し、 監視ルールとして codify する。

再訓練トリガの整理: (a) スケジュール (月次 / 四半期)、 (b) drift 閾値超過、 (c) 性能低下、 (d) 上流 schema 変更、 の 4 種をそれぞれ別ジョブとして登録すること。 1 つのジョブに混ぜると「なぜ今訓練が走ったか」が postmortem 時に切り分けられず、 RCA が長期化する。

🗺 概念マップ

中央に「AI 運用 (operation phase)」を置き、 (a) MLOps 構成要素として モデル監視・データドリフト検知・コンセプトドリフト検知・再学習トリガを、 (b) インフラ層として モデルサービング (REST/gRPC)・バッチ推論・エッジ推論を、 (c) ガバナンス層として 監査ログ・アクセス制御・モデルバージョニング・ロールバックを、 (d) 上流の AI 構築フェーズ (build) と接続し、 build → deploy → monitor → retrain の循環を視覚化する。

AI 運用の鍵は「モデルは時間とともに劣化する」前提に立つこと。 SSDSE-B-2026 で訓練したモデルも、 数年後の人口動態変化で性能低下する可能性が高い。 定期的な再学習・性能監視・データドリフト検知が必須。

🔗 隣接手法への橋渡し

「AI 運用」は単体技術ではなく、 開発→運用→監視の連鎖の中で機能する。 隣接概念とは「接続（前後関係）」「統合（一緒に走らせる）」「比較（役割の違い）」の 3 視点で関係を整理すると重複なく理解できる。

① 接続: AI 構築・MLOps・モデル監視と前後で組む

• AI 構築 → AI 運用: 構築フェーズの成果物 (モデル・前処理パイプライン・スコアリング API) を本番環境に受け渡す。 運用の出発点は「いつどのバージョンを引き取ったか」の記録。
• AI 運用 → モデル監視: 運用中は性能劣化・データドリフトを連続観測し、 閾値超過で再学習トリガを発火。 運用は監視と一体で初めて成立する。

② 統合: MLOps 基盤の中で並走させる

• MLOps + AI 運用: MLOps は CI/CD/CT を提供する基盤、 AI 運用はその上で「ビジネス指標・SLO・コスト」を担当する。 両者は対立ではなく階層関係 (MLOps = 仕組み、 AI 運用 = 意思決定)。
• AI 安全性 + AI 運用: 運用中の異常入力検知 (敵対的サンプル・分布外) と Rollback 手順は安全性要件と統合して設計する。 運用設計と安全設計は同時に走らせる。

③ 比較: 役割が混同されやすい隣接概念との違い

役割を分離すると「MLOps を入れたら運用は不要」「監視だけしておけば運用」という誤解を防げる。 接続 (前後関係)・統合 (同時並走)・比較 (役割差) の 3 視点で隣接概念を整理し、 単独学習でなく組合せで実務に活かす。

🌳 手法選択フロー

「AI運用」を実務で適用する／別手法に切り替える判断を、 状況別の 3 分岐で示す。 一律のレシピではなく、 自分の問題の特徴に応じて分岐を進めること。

1. 分岐 1（前提条件）: 「推論頻度は？」 オンライン → 低レイテンシ推論基盤、 バッチ → スケジューラ運用
2. 分岐 2（手法特性）: 「データドリフトは想定されるか？」 Yes → 監視 + 定期再学習、 No → 性能劣化アラートのみ
3. 分岐 3（運用要件）: 「規制業界か？」 Yes → 監査ログ + モデルバージョン管理、 No → 標準的な MLOps スタック

フローは出発点であって絶対解ではない。 領域知識・データ特性・運用制約を加えて最終判断する。 迷ったときは「🔗 隣接手法への橋渡し」と「🌐 関連手法・派生」を見直し、 単一の手法に固執しないこと。