---
title: "モデルモニタリングとは？ドリフト検知の仕組み・指標・しきい値設計を実装目線で解説【2026年版】"
url: "https://www.issoh.co.jp/tech/details/16338/"
published: 2026-08-09
updated: 2026-09-30
categories: ["AI"]
publisher: "株式会社一創"
---

# モデルモニタリングとは？ドリフト検知の仕組み・指標・しきい値設計を実装目線で解説【2026年版】

モデルモニタリングは、本番で動く機械学習モデルの入力・出力・精度を継続的に測り、劣化を検知して手当てにつなげる仕組みです。その中心にあるのがドリフト検知、つまり学習時と本番のデータ分布のずれを統計で測る処理です。この記事では、ドリフト検知とは何を捉える仕組みなのか、4つの監視シグナルが何を見ているのか、指標をどう選んでしきい値を置くのか、正解ラベルが遅れる現場で性能監視をどう成立させるのか、検知結果をどこまで自動で再学習に流してよいのかを、計算コードつきで扱います。推論APIの構成そのものは[モデルサービングとは？推論APIの構成と製品選定](https://www.issoh.co.jp/tech/details/16073/)で扱うため、本記事は稼働後の監視設計に絞ります。

## まとめ：モデルモニタリングで最初に決める監視シグナルとしきい値

モデルモニタリングが解く問題は1つです。学習時の前提と本番のデータがずれても、モデルは黙って予測を返し続けます。エラーも出ないまま精度だけが落ちるため、アプリケーション監視では検知できません。このずれを分布の比較で見つける処理がドリフト検知です。

見る対象は4層。入力の分布を見るデータドリフト、出力の分布を見る予測ドリフト、入力の型や欠損を見るデータ品質、正解ラベルと突き合わせるモデル性能です。即座に効くのはデータ品質で、上流のETL障害やスキーマ変更を最初に捉えます。モデル性能は正解ラベルが入る案件でしか成立しません。

導入順序は、データ品質、予測ドリフト、データドリフト（重要度上位の特徴量のみ）、モデル性能の順。4つ同時に入れると、しきい値が定まらないうちに通知だけが増え、半年でアラートが無視されます。しきい値は過去半年分の運用データで空回しし、誤検知率から逆算してください。製品面では Amazon SageMaker Model Monitor が新規顧客の受付を終了しており（2026年9月時点のAWS公式ドキュメント表記）、新規案件は Azure Machine Learning か Evidently 系の自前構成を選びます。

## ドリフト検知とは：学習時と本番のずれを統計で測る仕組みと3つの型

「ドリフト検知とは何か」を一言で置くと、参照データと本番データの分布を定期的に比べ、差が許容幅を超えたら知らせる仕組みです。監視の設計に入る前に、何がずれるのか、どう時間変化するのか、同じ言葉を使う別分野と何が違うのかを揃えておきます。

### ドリフト検知の定義と、エラーを出さずに予測精度が落ちていく仕組み

機械学習モデルは「学習データと本番データが同じ分布から来る」という前提で作られています。前提が崩れても推論APIは200 OKで予測を返し、ログにも例外は残りません。たとえば需要予測で主要顧客の構成が変わっても、モデルは過去の顧客像に合わせた数字を出し続けます。

ドリフト検知は、この「静かな劣化」を正解ラベルの到着より先に捉えるための早期警戒です。やっていることは単純で、ある期間の本番データを集め、学習データなどの参照と分布を比べ、距離や検定統計量を1つの数値にします。数値がしきい値を超えれば通知する。仕組みとして難しい部分はなく、判断が要るのは比べる相手・窓の長さ・線の位置の3点です。

注意したいのは、ドリフトの検知は精度低下の確定ではない点です。分布がずれてもモデルが頑健で精度が保たれる場合もあれば、分布が動かないまま精度だけ落ちる場合もあります。[EvidentlyのDataDriftPresetの公式ドキュメント](https://docs.evidentlyai.com/metrics/preset%5Fdata%5Fdrift)も、正解ラベルが無いときの代理指標としてドリフトを位置づけています。

### 共変量シフト・事前確率シフト・概念ドリフトの3類型と見分け方

ずれる対象で分けると3類型になります。入力をX、正解をYと置いたとき、どの分布が動いたかで呼び名が変わります。

| 類型      | 動く分布   | 典型例           | 検知の手がかり    |
| ------- | ------ | ------------- | ---------- |
| 共変量シフト  | 入力Xの分布 | 利用者の年齢層が変化    | データドリフト    |
| 事前確率シフト | 正解Yの比率 | 不正取引の比率が上昇    | 予測ドリフト     |
| 概念ドリフト  | XとYの関係 | 同じ属性でも購買傾向が変化 | モデル性能・代理指標 |

共変量シフトは入力の統計を見れば捉えられ、監視の大半はここを対象にしています。事前確率シフトは正解の比率が動く型で、分類モデルなら予測クラスの比率の変化として出力側に現れます。

厄介なのは概念ドリフトです。入力の分布が動かないまま「その入力なら何が正解か」だけが変わるため、入力側のドリフト検知には映りません。捉えられるのは正解ラベルとの突合か、後続業務の代理指標だけ。ドリフト検知を入れても概念ドリフトは残る、と最初から設計に書いておくと、監視の過信を防げます。

### 急変・漸進・周期・再発の4パターンで変わる検知窓と参照データの選び方

ずれ方の時間パターンでも手当てが変わります。急変は仕様変更や制度改正で一夜にして分布が変わる型で、捉える手段は短い窓の日次比較。漸進は顧客層がゆっくり入れ替わる型で、前週比では毎週の差が小さすぎて見逃すため、学習データ基準の長い窓で測ります。

周期は季節や曜日で行き来する型です。学習データ基準だと繁忙期のたびに鳴るので、前年同期を参照にするか、周期の特徴量を監視対象から外します。再発は過去に見た状態へ戻る型で、キャンペーン期間のように予定が分かるものは、その期間用の参照データを別に持つと誤検知が減ります。

実務では、1つの特徴量に1つのパターンを割り当て、参照データと窓の長さを特徴量ごとに決めるのが現実的です。全特徴量を同じ窓で測ると、周期性のある列が毎月鳴り、漸進する列は一度も鳴らないという逆転が起きます。

### 機械学習のドリフト検知と、IaCの構成ドリフト検知で比べる対象の違い

「ドリフト検知」で検索すると、インフラ構成の話が混ざります。こちらはコードで定義した構成と実環境の設定の食い違いを見つける機能で、[AWS CloudFormationのドリフト検出](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)がコンソールなどから手で変えられたリソースを洗い出すのが代表例です。

両者は名前が同じだけで、比べる対象がまったく違います。構成ドリフトは「定義」と「現状」の差分で、差があれば必ず誤りです。機械学習のドリフトは「過去の分布」と「今の分布」の差で、差があっても誤りとは限らず、統計的なしきい値で判断します。構成管理の文脈は[IaCとは？Infrastructure as Codeの仕組みと導入判断](https://www.issoh.co.jp/column/details/13004/)で扱っており、本記事は機械学習側だけを対象にします。

## モデルモニタリングの定義と、4つの監視シグナルが見ている対象の違い

「モデルを監視する」は、話し手によって指す範囲が違います。責任境界を引いてから中身に入ります。

### モデルモニタリングが引き受ける範囲と、アプリ監視・基盤監視との境界

推論エンドポイントのレイテンシ、エラー率、GPU使用率。これらはアプリケーション監視とインフラ監視の領分で、CloudWatchやDatadogが既に面倒を見ています。モデルモニタリングが引き受けるのは、その上の「200 OKで返っている予測の中身が正しいか」だけです。システム全体の可観測性との関係は[オブザーバビリティとは？監視・モニタリングとの違い](https://www.issoh.co.jp/column/details/3077/)で整理しています。

境界を混ぜると運用が崩れます。特徴量がオンラインストアに更新されているかという鮮度監視は、モデルではなくデータ基盤側の問題で、[特徴量ストアとは？二層構成と導入判断](https://www.issoh.co.jp/tech/details/16334/)で扱う運用監視の範囲。上流のバッチが落ちて古い値が配られている状態は、モデルの劣化ではなくジョブ障害です。両方を同じダッシュボードに並べると、アラート時に「どちらが動くのか」で毎回議論になります。

実務では、システムの生死＝インフラ監視、値の供給＝データ基盤監視、予測の妥当性＝モデルモニタリングの3分割で責任を割り当ててください。この分割が先にあれば、しきい値設計もアラート先も自然に決まります。IT運用の異常検知に機械学習を使う[AIOpsとは？IT運用×AIの仕組みとMLOpsとの違い](https://www.issoh.co.jp/tech/details/13803/)は、監視する側にモデルを使う話で、監視される側のモデルを扱う本記事とは向きが逆です。

### データドリフト・予測ドリフト・データ品質・モデル性能の使い分け

[Azure Machine Learningのモデル監視の公式ドキュメント](https://learn.microsoft.com/ja-jp/azure/machine-learning/concept-model-monitoring?view=azureml-api-2)では、組み込みシグナルがこの4層に特徴量属性ドリフト（プレビュー）を加えた構成になっています。それぞれ比較する相手が違うため、検知できる異常も違います。

| シグナル    | 比較する対象      | 代表的な指標     | 捉えられる異常   |
| ------- | ----------- | ---------- | --------- |
| データ品質   | 入力の型・欠損・範囲  | 欠損率・型エラー率  | 上流ETLの障害  |
| 予測ドリフト  | 出力の分布と検証データ | JS距離・KS検定  | 出力の偏りの変化  |
| データドリフト | 入力の分布と学習データ | PSI・JS距離   | 母集団の入れ替わり |
| モデル性能   | 予測と正解ラベル    | 正解率・適合率・F1 | 実精度の低下    |

使い分けの原則は「検知の速さ」と「確からしさ」のトレードオフです。データ品質とドリフトは正解を待たず当日中に出せる代わりに、出ても精度が落ちているとは限りません。モデル性能は確実な劣化の証拠ですが、正解の判明まで数週間から数か月かかります。前者を早期警戒、後者を確定診断として二段構えで置きます。

この4層は表形式データの予測モデルを前提とした整理です。LLMアプリでは監視対象がトレース・コスト・出力品質の評価へ移ります。そちらは[LLMOpsとは？MLOpsとの違いと実装](https://www.issoh.co.jp/tech/details/16069/)の範囲として切り離してください。

## ドリフト検知で使う統計指標の選び分けと、しきい値を決める実務手順

ドリフト検知の中身は、参照データと本番データの分布を統計的に比べる処理です。難しいのは計算ではなく、どの指標を選びどこに線を引くかの判断になります。

### PSI・JS距離・KS検定・カイ二乗の適用範囲と数値/カテゴリの選択

Azure Machine Learningがデータドリフトに用意する指標は、Jensen-Shannon距離、母集団安定性指数（PSI）、正規化Wasserstein距離、2標本Kolmogorov-Smirnov検定、Pearsonのカイ二乗検定の5つ（2026年9月時点の公式ドキュメント）。予測ドリフトにはこれにChebyshev距離が加わります。

| 指標     | 向くデータ型  | 値の性質       | 実務での扱い     |
| ------ | ------- | ---------- | ---------- |
| PSI    | 数値・カテゴリ | 0以上・上限なし   | 段階しきい値を置ける |
| JS距離   | 数値・カテゴリ | 底2で0〜1に収まる | 特徴量間で横並び比較 |
| KS検定   | 連続値のみ   | p値と統計量     | 標本が多いと過検知  |
| カイ二乗検定 | カテゴリのみ  | p値と統計量     | 水準数が多いと不安定 |

選び方の基準は3つ。第1に、数値とカテゴリが混在する現実のテーブルでは、両方へ同じ式で適用できるPSIかJS距離を主指標に据えると運用が単純になります。第2に、検定系（KS・カイ二乗）は標本数が増えるほど小さな差でも有意になり、日次数十万件規模のログでは常時赤になりがち。第3に、JS距離は対数の底を2にすれば0から1に収まるので、値を並べ替えて最もずれた箇所をそのまま読めます。

この考え方はEvidentlyの既定値にも表れています。[Evidentlyのドリフト手法の解説](https://docs.evidentlyai.com/metrics/explainer%5Fdrift)によると、参照データが1,000件以下なら数値列にKS検定、カテゴリ列にカイ二乗検定を当て、1,000件を超えると数値列はWasserstein距離、カテゴリ列はJensen-Shannonダイバージェンスへ切り替え、しきい値0.1で判定します。標本が増えたら検定から距離へ移る、という設計です。

実装は主指標をJS距離、補助にPSIを併記する構成を勧めます。JS距離で順位を見て、PSIの絶対水準で警告レベルを判定する。検定系は標本数が数千件までのバッチ推論に限ってください。

### PSIとJS距離をPythonで計算し、しきい値で判定する最小コード

ライブラリに頼る前に、1特徴量ぶんを手で計算しておくと、製品が返す数値の意味を読み違えません。以下はNumPyとSciPyだけで動く最小構成です。JS距離は[SciPyのjensenshannon](https://docs.scipy.org/doc/scipy/reference/generated/scipy.spatial.distance.jensenshannon.html)を`base=2`で呼び、KS検定は[ks\_2samp](https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.ks%5F2samp.html)を参考値として並べます。

```
import numpy as np
from scipy.spatial.distance import jensenshannon
from scipy.stats import ks_2samp

def binned(ref, cur, bins=10):
    # 参照データの分位点で区切り、両方を同じビンで数える
    cuts = np.quantile(ref, np.linspace(0, 1, bins + 1))[1:-1]
    r = np.bincount(np.searchsorted(cuts, ref, side="right"), minlength=bins) / len(ref)
    c = np.bincount(np.searchsorted(cuts, cur, side="right"), minlength=bins) / len(cur)
    eps = 1e-6  # 空ビンでlog(0)にならないよう下駄を履かせる
    return np.clip(r, eps, None), np.clip(c, eps, None)

def psi(ref, cur, bins=10):
    r, c = binned(ref, cur, bins)
    return float(np.sum((c - r) * np.log(c / r)))

def js(ref, cur, bins=10):
    r, c = binned(ref, cur, bins)
    return float(jensenshannon(r, c, base=2))  # base=2で0〜1に収まる

rng = np.random.default_rng(0)
ref = rng.normal(50, 10, 20000)  # 学習時の分布
cur = rng.normal(55, 12, 5000)   # 本番で平均と散らばりがずれた分布

print(f"PSI={psi(ref, cur):.3f} JS={js(ref, cur):.3f}")
print("KS p値", ks_2samp(ref, cur).pvalue)
if js(ref, cur) >= 0.1:
    print("ドリフト判定: 要確認")
```

ビンの境界を参照データの分位点で切るのが要点です。本番側の分位点で切ると、比べる物差しが毎回変わって値が比較できなくなります。版は2026年9月時点のPyPI表示でSciPyが1.18系、NumPyが2.5系で、どちらもPython 3.12以上が前提。

このコードを実務へ持ち込むときの変更点は2つです。カテゴリ列は分位点でなく水準ごとの出現比率をそのまま`r`と`c`にすること。そして判定の0.1はEvidentlyの既定値を借りた仮の線で、次の節の空回しで案件ごとに置き直すことです。

### 参照データ（ベースライン）の取り方と、比較窓の重なりで検知が鈍る理由

参照データの候補は2つ。学習に使ったデータセットか、直近の本番データかです。Microsoftのベストプラクティスは、データドリフトとデータ品質には学習データを、予測ドリフトには検証データを推奨しています。学習時の前提からどれだけ離れたかを測る目的に素直です。

直近の本番データを参照にする構成にも用途があります。季節性のように「学習時からずれるのが当たり前」の特徴量は、学習データ基準だと常時アラートになるため、前週比で急変だけを拾います。ただしゆっくり進むドリフトは前週比では検知できません。参照を直近データにした特徴量は、四半期に一度は学習データ基準でも測り直してください。

もう1つの注意が、比較する窓の重なりです。Azure Machine LearningはルックバックウィンドウのサイズとオフセットをISO 8601形式（`P7D`のような表記）で指定しますが、参照窓と本番窓が重なると同じ行を両側で数え、差が小さく出ます。公式ドキュメントでは参照データのオフセット既定値が本番データのウィンドウサイズの2倍とされ、統計的に意味のある量の参照データを確保する設定です。自前実装でも、参照窓の終端を本番窓の始端より前に置いてください。

### しきい値を過去データの空回しで決める手順と、誤検知率の許容水準

しきい値を業界の目安値からコピーする進め方は勧めません。特徴量の性質と業務の変動幅は案件ごとに違います。

手順は4段階。まず過去6か月分の本番データを日次または週次のウィンドウに切ります。次に学習データを参照として全ウィンドウのドリフト指標を計算し、時系列でプロット。そのうえで、精度低下が起きた時期（インシデント記録で特定できます）と指標の山が一致するかを確認し、平常期に鳴らず低下期は捉える水準へ線を引く。1〜2日の空回しで、運用開始後のアラート疲れが大きく減ります。前節のコードを窓ごとにループさせれば、この空回しはそのまま組めます。

初期値はAWSが公開する置き換え用サンプルが参考になります。ドリフトは「ドリフト判定された特徴量の比率が30%超で通知」、モデル品質は F1 0.70・正解率 0.80・ROC AUC 0.75 が既定値。Evidentlyのデータセット単位の判定は「列の50%以上がドリフト」が既定で、AWSのサンプルより緩めです。個別特徴量ごとより、まず「全体の何割がずれたか」の集約指標で1本引くほうが初期は安定します。誤検知は週1回までなら確認でき、月1回超で無視され始めるのが現場の感覚値。

## 正解ラベルが遅れて届く案件で、モデル性能の監視をどう設計するか

ドリフト検知だけでは「精度が落ちた」とは言い切れません。確定診断にあたるのがモデル性能監視で、ここは正解ラベルの入手可能性という業務側の制約に縛られます。

### ラベル遅延の3類型と、推論IDで予測と正解を突合するテーブル設計

遅延の型は3つ。1つ目は数日で確定する型で、配送遅延予測や翌日の需要予測が該当。2つ目は数週間から数か月かかる型で、与信の延滞判定や解約予測が入ります。3つ目は一部しか得られない型で、不正検知が典型です。承認した取引の正解は後から分かりますが、拒否した取引が不正だったかは永久に分かりません。

共通して必要になるのが、予測と正解を後から突き合わせる仕組みです。推論のたびに一意な推論IDを発行し、入力特徴量・予測値・予測時刻とともに保存しておく。正解ラベルが確定したら、同じ推論IDで結合して評価用テーブルを作ります。AWSの置き換え構成にも、この突合パターンが組み込まれています。後付けは骨が折れるため、推論APIを作る段階で仕込んでください。

集計単位は予測時刻ベースで揃えます。正解が届いた時刻で集計すると、遅延の長い案件が後の期間に混ざり、どの時期のモデルが悪かったのか分からなくなります。

### 正解ラベルが得られない案件で代理指標を置くときの判断基準と限界

3つ目の型では、モデル性能シグナルを諦めて代理指標に置き換えます。使うのは後続の業務プロセスで観測できる数値です。不正検知なら拒否率とオペレーターの手動オーバーライド率、レコメンドならクリック率、審査なら差し戻し件数の推移。

判断基準は「モデルの出力が変わったときに、その指標が必ず動くか」の1点。オーバーライド率はモデルの誤りに反応するため機能しますが、売上のように外部要因が支配的な指標では信号が埋もれます。

限界も明示してください。代理指標は劣化の存在を示唆するだけで、程度は測れません。動いたときの対応は「再学習する」ではなく「サンプリングして人手でラベルを付け、実精度を測る」です。人手評価の予算と担当を運用設計に含めない案件では、代理指標を置いても行動につながりません。

## 監視のアラートを再学習につなげる判断設計と、自動化してよい範囲

検知だけして手当てが決まっていない監視は、通知を増やすだけの装置です。アラートから先の分岐を設計時に文書として固めてください。

### 再学習を自動起動してよい条件と、人が判断を挟むべき条件の線引き

Azure Machine Learningでは、モデルモニタリングが生成したイベントをEvent Gridで受け、精度が一定を下回ったら再学習ジョブを起動する構成が案内されています。技術的には自動化できます。問題はどの案件でやってよいかです。

自動起動を許してよいのは3条件が揃った場合に限ります。第1に、正解ラベルが自動で十分な量入手できること。第2に、本番へ出す前に保留データでの精度が前バージョン以上だと機械的に検証する関門があること。第3に、精度が下がったら旧バージョンへ即座に戻せること。3つ目がないまま自動化すると、劣化モデルが自動で本番に出ます。版の管理と昇格は[モデルレジストリとは？版管理と本番昇格の設計](https://www.issoh.co.jp/tech/details/16082/)の範囲で、自動再学習の前提条件です。

与信・医療・採用のように判断の説明責任が問われる領域では、再学習の起動そのものに人の承認を挟んでください。自動化は工数を節約しますが、モデルがいつ何を根拠に変わったのかを説明できなくなる代償を伴います。

### 再学習で直らないドリフトの見分け方と、データ品質障害との切り分け

ドリフトのアラートに反射的に再学習を回す運用は、半分の場面で無駄になります。原因が3つに分かれるためです。

- データ品質障害：上流が壊れ欠損や型不整合が混入。再学習しても悪化します
- 母集団の変化：顧客層が入れ替わった。再学習が正しい手当てです
- 概念ドリフト：入力と正解の関係が変わった。特徴量の設計見直しが要る場合もあります

切り分けの順序は決まっています。まずデータ品質シグナルを見て、欠損率・型エラー率・範囲外率が跳ねていないかを確認。跳ねていれば上流の障害で、対応先はモデルではなく[データパイプラインとは？構成要素と設計判断](https://www.issoh.co.jp/tech/details/15848/)で扱う取り込み経路です。品質が正常でドリフトだけ出ているなら母集団の変化。入力分布が動かないのに性能だけ落ちるなら概念ドリフトです。この切り分けを手順書に1枚のフローとして書き、アラート本文にシグナル名を含めるだけで、一次対応の時間は短くなります。

## 実装スタックの選択肢と、2026年9月時点の各サービスの提供状況

製品の選択は既存のクラウドと推論基盤で8割方決まります。そのうえで2026年9月時点の提供状況を確認してください。

### Azure Machine Learningのシグナル構成とルックバック窓の設計

Azure Machine Learningは、オンラインエンドポイントにデプロイしたモデルについて、推論データの収集から監視ジョブの実行までを組み込みで提供します。シグナルはデータドリフト、予測ドリフト、データ品質に加え、特徴量属性ドリフトとモデルパフォーマンスがプレビュー扱い（2026年8月時点の確認）。データ品質はnull値率・データ型エラー率・範囲外率の3指標で、計算精度は最大0.00001です。

設定で効いてくるのが監視頻度とルックバック窓です。日次のトラフィックが十分にあるなら日次、そうでなければ週次か月次へ落とす。標本数が足りないまま日次で回すと分布の推定が不安定になり、指標が振れて使い物になりません。特徴量が多いモデルでは重要度の上位N件に絞る設定があり、計算コストとノイズを同時に抑えられます。大規模データの計算にSparkを使う関係で、`MLTable`の扱いに制約がある点も明記されています。マネージド仮想ネットワークで承認済み送信のみを許す分離設定に対応しない点も、閉域構成の案件では事前確認の対象です。

### SageMaker Model Monitorの新規受付終了と置き換え先の構成

AWS側は状況が変わりました。[Amazon SageMaker Model Monitorの公式ドキュメント](https://docs.aws.amazon.com/sagemaker/latest/dg/model-monitor.html)には「no longer open to new customers」と明記され、既存顧客は継続して使えるものの新機能の追加予定はないとされています（2026年9月30日に再確認）。新規案件でこれを前提にした設計は成り立ちません。

AWSが案内する置き換えは、aws-samplesで公開されているOSSの監視ソリューション（SageMaker AI MLflow Apps と Evidently AI の組み合わせ）に、QuickSightのダッシュボードとCloudWatchを重ねる構成です。データ品質は Evidently の`DataDriftPreset`でPSIとKS統計量を、モデル品質は`ClassificationPreset`でROC-AUCやF1を算出するよう組まれています。既存のModel Monitorを止めるときは、監視スケジュールがProcessingジョブを定期起動し続けるため、`delete-monitoring-schedule`で削除しないと課金が残ります。

### Evidentlyで自前実装するときの構成要素と、割に合う規模の目安

Evidentlyは参照データと本番データからドリフトと品質のレポートを返すOSSで、[PyPI](https://pypi.org/project/evidently/)表示の安定版は2026年9月時点で0.7系（0.7.23）、Python 3.10以上が前提です。ソースは[GitHubのevidentlyaiリポジトリ](https://github.com/evidentlyai/evidently)で公開されています。自前で組む部品は、推論ログの保管先、参照データの管理、スケジュール実行、通知の4つ。

0.7系の最小構成は次のとおりです。前日分の推論ログと学習時の特徴量を読み込み、`DataDriftPreset`で全列を比べてHTMLとJSONに書き出します。

```
import pandas as pd
from evidently import Report
from evidently.presets import DataDriftPreset

ref = pd.read_parquet("features/train.parquet")        # 学習時の特徴量
cur = pd.read_parquet("logs/inference_2026-09-29.parquet")  # 前日分の推論ログ

report = Report([DataDriftPreset()])
my_eval = report.run(cur, ref)  # 第1引数が本番側、第2引数が参照側
my_eval.save_html("drift_2026-09-29.html")
my_eval.save_json("drift_2026-09-29.json")
```

引数の順番に注意してください。`run`は本番側を先、参照側を後に渡します。逆にすると本番データが基準として扱われ、レポートの参照側の分布表示も入れ替わります。列ごとの手法は型と件数から自動で選ばれ、データセット全体は列の50%以上がドリフトしたときに陽性です。JSONを日次で保存しておけば、しきい値の空回しにそのまま使えます。

日次バッチでレポートを生成してSlackへ流すだけなら数日、データキャプチャと遅延ラベルの突合まで含めると2〜3人月の規模。本番モデルが1〜3本ならスクリプトで足り、5本を超えて複数チームが持つ段階から共通基盤にする価値が出ます。製品ごとの機能差を含む比較は[MLOpsツールの比較と選定](https://www.issoh.co.jp/tech/details/15341/)に整理しました。

## モデル監視を導入する順序と、薄く始めるべき案件を見極める判断基準

ここまでを案件に落とすときの判断として言い切ります。監視は入れるほど良いものではありません。

### 4シグナルを同時に入れない・データ品質から始める導入順序の根拠

最初に入れるのはデータ品質です。理由は3つ。第1に、参照データが学習データそのままで済み、設計判断がほぼ不要。第2に、欠損率や型エラー率は「0%であるべき」という自明の基準があり、しきい値の議論が要りません。第3に、本番障害の多くは上流のスキーマ変更やETL失敗で、ここを押さえるだけで検知数が最も多い。

2番目が予測ドリフトです。出力は1次元（分類なら各クラスの確率分布）なので監視が軽く、入力側の異常も出力の偏りとして間接的に現れます。3番目にデータドリフトを重要度上位の特徴量だけで足し、正解ラベルが流れ始めた段階でモデル性能を載せる。避けるべきは設定画面のシグナルを全部オンにする進め方で、初日から数十の指標が通知され、チューニングの起点が失われます。

### モデル監視を薄く始めてよい3つの条件と、厚く作るべき案件の判断軸

次の3条件が揃う案件では、日次のデータ品質チェックとバッチ再学習の定期実行だけで足ります。第1に、モデルが1〜2本で担当者が学習と運用の両方を見ていること。第2に、バッチ推論のみでリアルタイム性の要求がないこと。第3に、予測が最終判断ではなく人のレビューを経ること。レビュー経路があれば、明らかな異常は現場で先に気づかれます。

厚く作るべきなのは逆の条件です。予測がそのまま自動処理へ流れ人が介在しない、金額や与信のように誤りが直接損失になる、規制業界で判断根拠の説明を求められる。どれかが当てはまるなら、4シグナルすべてと遅延ラベルの突合、再学習の関門まで設計してください。投資判断は精度ではなく、誤った予測が1件通ったときの損害額で決まります。

リアルタイム推論はあるが損害が限定的な案件では、データ品質と予測ドリフトに絞り、モデル性能は四半期ごとの人手評価で代替します。運用体制全体をどこまで整えるかの判断は[MLOpsとは？機械学習の運用を支える仕組みと導入判断](https://www.issoh.co.jp/column/details/2939/)で、判断者向けに整理しています。

### 受託開発でモデル監視を引き渡すときのアラート責任と運用移管の範囲

引き渡しで揉めるのは、アラートが鳴ったときの一次対応者です。データ品質のアラートは上流のシステム保守側、ドリフトと性能のアラートはモデル担当側。この振り分けを通知先の設定として実装に落とし、口頭の合意で終えないでください。

移管する文書に含めるべきは4点。シグナルごとのしきい値と決めた根拠、参照データの版と更新条件、再学習の起動判断フロー（自動か承認か）、代理指標の限界と人手評価の頻度です。しきい値の根拠が残っていないと、後任が誤検知に耐えかねて閾値を緩め、監視が実質的に無効化されます。

監視の設計を含む機械学習システムの構築から運用移管まで一貫して支援する体制については[機械学習モデル開発](https://www.issoh.co.jp/service/ai/machine-learning/)のページで整理しています。

## よくある質問

### ドリフトが検知されたら必ず再学習すべきですか？

いいえ。まずデータ品質シグナルを確認してください。欠損率や型エラー率が跳ねているなら原因は上流の障害で、その状態で再学習すると壊れた分布を学習します。品質が正常でドリフトだけ出ている場合も、精度が落ちているとは限りません。正解ラベルか代理指標で確認してから再学習を判断します。

### 正解ラベルが手に入らないモデルでも監視は成立しますか？

成立しますが範囲は限られます。入力のデータ品質とデータドリフト、出力の予測ドリフトは正解なしで測れるため、早期警戒としては機能します。ただし劣化の程度は測れません。オーバーライド率や差し戻し件数のような代理指標を併せて置き、動いたときに人手でラベルを付ける運用まで設計してください。

### ドリフト検知とは何を検知する仕組みですか？

学習時などの参照データと本番データの分布を比べ、ずれが許容幅を超えたことを知らせる仕組みです。主に捉えるのは入力の分布が変わるデータドリフト（共変量シフト）と、出力の偏りが変わる予測ドリフト。一方、入力と正解の関係そのものが変わる概念ドリフトは入力分布が動かないケースがあり、入力側のドリフト検知には映りません。顧客層が入れ替わって年齢分布が動くのが前者、同じ年齢層でも購買傾向が変わるのが後者で、後者の手がかりは正解ラベルか代理指標だけです。

### 監視のしきい値はどのくらいの頻度で見直すべきですか？

定期見直しは四半期に1回が目安。加えて、再学習でモデルを入れ替えたときは必ず見直します。入れ替えそのものの工程と切り戻しの単位は[モデルデプロイの6工程と切り戻しの設計](https://www.issoh.co.jp/tech/details/16345/)にまとめています。参照データが新しい学習データに変わり、以前のしきい値が同じ意味を持たなくなるためです。誤検知が週1回を超え始めたときも見直しの合図で、放置すると通知が無視される状態に入ります。

### SageMaker Model Monitorは今から新規案件で使えますか？

2026年9月時点のAWS公式ドキュメントでは、Model Monitor は新規顧客への提供を終了したと明記されています。既存の環境は継続して使え、新機能の追加予定はないとの記載。AWS上で新たに構築するなら、公式に案内されるOSS監視ソリューション（MLflowとEvidently）にQuickSightとCloudWatchを重ねる構成を選びます。

## 関連記事

- [特徴量ストアとは？二層構成と導入判断](https://www.issoh.co.jp/tech/details/16334/)：特徴量の鮮度管理を扱います。
- [モデルレジストリとは？版管理と本番昇格](https://www.issoh.co.jp/tech/details/16082/)：再学習したモデルの入れ替えです。
- [モデルサービングとは？推論APIの構成](https://www.issoh.co.jp/tech/details/16073/)：監視対象となる推論基盤の設計です。
- [LLMOpsとは？MLOpsとの違い](https://www.issoh.co.jp/tech/details/16069/)：生成AIアプリでの監視と評価です。
- [MLOpsとは？機械学習の運用体制](https://www.issoh.co.jp/column/details/2939/)：運用全体像を判断者向けに整理しています。
- [モデル解釈性とは？説明可能性との違いとSHAP・LIMEの選び方](https://www.issoh.co.jp/tech/details/16357/)：説明の変化を監視項目へ足す側の設計です。
- [MLOpsツール比較と選定基準](https://www.issoh.co.jp/tech/details/15341/)：監視を含む主要スタックの比較です。

---

出典: [モデルモニタリングとは？ドリフト検知の仕組み・指標・しきい値設計を実装目線で解説【2026年版】](<https://www.issoh.co.jp/tech/details/16338/>)（株式会社一創）