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

モデルモニタリングは、本番で動く機械学習モデルの入力・出力・精度を継続的に測り、劣化を検知して手当てにつなげる仕組みです。この記事では、4つの監視シグナルが何を見ているのか、指標をどう選んでしきい値を置くのか、正解ラベルが遅れる現場で性能監視をどう成立させるのか、検知結果をどこまで自動で再学習に流してよいのかを扱います。推論APIの構成そのものはモデルサービングとは？推論APIの構成と製品選定で扱うため、本記事は稼働後の監視設計に絞ります。

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

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

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

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

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

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

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

推論エンドポイントのレイテンシ、エラー率、GPU使用率。これらはアプリケーション監視とインフラ監視の領分で、CloudWatchやDatadogが既に面倒を見ています。モデルモニタリングが引き受けるのは、その上の「200 OKで返っている予測の中身が正しいか」だけです。

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

実務では、システムの生死＝インフラ監視、値の供給＝データ基盤監視、予測の妥当性＝モデルモニタリングの3分割で責任を割り当ててください。この分割が先にあれば、しきい値設計もアラート先も自然に決まります。

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

Azure Machine Learningの組み込みシグナルは、この4層に特徴量属性ドリフト（プレビュー）を加えた構成になっています。それぞれ比較する相手が違うため、検知できる異常も違います。

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

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

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

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

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

Azure Machine Learningがデータドリフトに用意する指標は、Jensen-Shannon距離、母集団安定性指数（PSI）、正規化Wasserstein距離、2標本Kolmogorov-Smirnov検定、カイ二乗検定の5つ。EvidentlyのDataDriftPresetもPSIとKS統計量を全特徴量に対して計算します。

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

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

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

参照データの候補は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 が既定値。個別特徴量ごとより、まず「全体の何割がずれたか」の集約指標で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つ目がないまま自動化すると、劣化モデルが自動で本番に出ます。版の管理と昇格はモデルレジストリとは？版管理と本番昇格の設計の範囲で、自動再学習の前提条件です。

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

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

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

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

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

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

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

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

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

設定で効いてくるのが監視頻度とルックバック窓です。日次のトラフィックが十分にあるなら日次、そうでなければ週次か月次へ落とす。標本数が足りないまま日次で回すと分布の推定が不安定になり、指標が振れて使い物になりません。特徴量が多いモデルでは重要度の上位N件に絞る設定があり、計算コストとノイズを同時に抑えられます。大規模データの計算にSparkを使う関係で、複雑なMLTableの扱いに制約がある点も明記されています。

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

AWS側は状況が変わりました。Amazon SageMaker Model Monitor は新規顧客への提供を終了しており（AWS公式ドキュメントの「no longer open to new customers」表記）、既存顧客は継続して使えるものの新機能の追加予定はないとされています。新規案件でこれを前提にした設計は、2026年8月時点では成り立ちません。

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表示の安定版は0.7.21、Python 3.10以上が前提です。自前で組む部品は、推論ログの保管先、参照データの管理、スケジュール実行、通知の4つ。

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

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

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

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

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

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

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

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

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

リアルタイム推論はあるが損害が限定的な案件では、データ品質と予測ドリフトに絞り、モデル性能は四半期ごとの人手評価で代替します。

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

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

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

監視の設計を含む機械学習システムの構築から運用移管まで一貫して支援する体制については機械学習モデル開発のページで整理しています。

よくある質問

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

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

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

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

データドリフトと概念ドリフトはどう違いますか？

データドリフトは入力の分布が変わること、概念ドリフトは入力と正解の関係そのものが変わることを指します。顧客層が入れ替わって年齢分布が動くのが前者、同じ年齢層でも購買行動の傾向が変わるのが後者。概念ドリフトは入力分布が動かないケースがあり、入力側の監視では検知できません。正解ラベルか代理指標だけが手がかりです。

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

定期見直しは四半期に1回が目安。加えて、再学習でモデルを入れ替えたときは必ず見直します。参照データが新しい学習データに変わり、以前のしきい値が同じ意味を持たなくなるためです。誤検知が週1回を超え始めたときも見直しの合図で、放置すると通知が無視される状態に入ります。

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

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

関連記事

• 特徴量ストアとは？二層構成と導入判断：特徴量の鮮度管理を扱います。
• モデルレジストリとは？版管理と本番昇格：再学習したモデルの入れ替えです。
• モデルサービングとは？推論APIの構成：監視対象となる推論基盤の設計です。
• LLMOpsとは？MLOpsとの違い：生成AIアプリでの監視と評価です。
• MLOpsとは？機械学習の運用体制：運用全体像を判断者向けに整理しています。