はじめに

前回は、SageMaker の推論方式として

Real-time Endpoint
Serverless Endpoint
Asynchronous Endpoint
Batch Transform

について整理しました。

今回は、モデルを本番環境にデプロイしたあとに重要になる
監視（Monitoring） について整理します。

機械学習モデルは、作ってデプロイしたら終わりではありません。

本番環境では、時間が経つにつれて

入力データの傾向が変わる
ユーザー層が変わる
ビジネス環境が変わる
モデルの精度が下がる
推論レイテンシーが悪化する
エラーや異常が発生する

といったことが起こります。

そのため、モデルを本番運用する場合は、
モデルが今も正常に動いているかを継続的に確認すること が重要です。

本記事では、

Monitoring とは何か
SageMaker Model Monitor とは何か
Data Drift とは何か
どのような項目を監視するのか
Data Drift が起きたらどうするのか
実務や試験での見られ方

を、初心者にも分かりやすく整理します。

🎯 対象読者

SageMaker Model Monitor の役割を整理したい方
Data Drift の意味を理解したい方
モデルをデプロイした後の運用を学びたい方
AWS の AI / ML 系資格を勉強している方
MLOps の基本を整理したい方

🧩 まず結論：モデルはデプロイ後も監視が必要

機械学習モデルは、デプロイした時点では問題なく動いていても、
時間が経つと予測性能が落ちることがあります。

理由は、モデルが学習したときのデータと、
本番で入力されるデータが変わっていく可能性があるからです。

一言で言うと、監視の目的は以下です。

Monitoring = モデルが本番環境で正常に動き続けているか確認すること

SageMaker では、このようなモデル監視を支援する機能として
SageMaker Model Monitor があります。

👀 Monitoring とは？

Monitoring とは、
モデルが本番環境で正しく動いているかを継続的に確認すること です。

機械学習では、モデルを学習してデプロイしたあとも、以下のような観点を見ます。

監視対象	確認したいこと
モデルが正常に動いているか	エラーやタイムアウトが発生していないか
予測結果が安定しているか	予測の分布が急に変わっていないか
入力データが変化していないか	学習時のデータと本番データが大きく違わないか
モデル精度が下がっていないか	予測が実態とずれてきていないか
システム性能に問題がないか	レイテンシー、スループット、失敗率など

つまり、監視とは単にサーバーが動いているかを見るだけではありません。

モデルの入力、出力、品質、性能を含めて、
モデルがビジネス上使える状態を保てているか を確認することが重要です。

🛠 SageMaker Model Monitor とは？

SageMaker Model Monitor は、
SageMaker 上でデプロイしたモデルの入力データや予測結果を監視するための機能 です。

一言で言うと、以下のように覚えると分かりやすいです。

Model Monitor = デプロイ後のモデルを監視するための仕組み

Model Monitor を使うと、たとえば以下のような確認ができます。

入力データの分布が変わっていないか
予測結果の傾向が変わっていないか
欠損値や異常値が増えていないか
データ品質に問題がないか
しきい値を超えた場合に通知できるか

モデルを Endpoint にデプロイしたあと、
本番データが学習時のデータと大きく違っていないかを確認するのに役立ちます。

🧪 Model Monitor の具体例

たとえば、顧客が商品を購入するかどうかを予測するモデルを考えます。

学習時のデータでは、主なユーザー層が 20〜30代だったとします。

しかし、モデルを本番に出したあと、広告施策やサービス変更によって、
実際にアクセスするユーザーの多くが 60代以上に変わったとします。

この場合、モデルは過去に学習したデータとは違う傾向の入力を受け取ることになります。

その結果、

予測精度が下がる
推薦結果が合わなくなる
購入予測がずれる
ビジネス上の判断が不正確になる

可能性があります。

Model Monitor は、このような入力データの変化を検知するために使えます。

🌊 Data Drift とは？

Data Drift とは、
モデルの学習時に使ったデータの分布と、本番環境で入力されるデータの分布が変わること です。

日本語では、データの分布変化、またはデータドリフトと呼ばれます。

一言で言うと、以下です。

Data Drift = 学習時のデータと本番データの傾向が変わること

モデルは、基本的に過去のデータから規則を学習します。

そのため、本番で入ってくるデータが過去データと大きく変わると、
モデルの予測が不正確になる可能性があります。

🧪 Data Drift の具体例

たとえば、以下のようなケースを考えます。

学習時

主なユーザー層：20〜30代
20代：40%
30代：40%
60代以上：5%

本番運用後

主なユーザー層：60代以上
20代：10%
30代：10%
60代以上：60%

この場合、学習時と本番運用時でユーザー層が大きく変わっています。

モデルは 20〜30代中心の行動パターンを学習しているため、
60代以上のユーザーに対する予測が不正確になるかもしれません。

これが Data Drift の典型的な例です。

📉 Data Drift が起きると何が問題なのか？

Data Drift が起きると、モデルの予測結果が信頼できなくなる可能性があります。

具体的には、以下のような問題が起きます。

問題	説明
予測精度の低下	学習時と違うデータに対応できない
誤判定の増加	本来とは違う判断をする可能性がある
推薦品質の低下	ユーザーに合わない推薦が増える
ビジネス判断の誤り	予測結果に基づく施策がずれる
再学習の必要性	新しいデータでモデルを更新する必要が出る

重要なのは、モデル自体は技術的には正常に動いていても、
予測結果が現実に合わなくなる可能性があるという点です。

🧭 何を監視するべきか？

モデル監視では、さまざまな項目を確認します。

代表的な監視対象を整理すると、以下のようになります。

監視対象	説明
入力データの分布	学習時のデータと本番データが大きく変わっていないか
予測結果の分布	予測の傾向が急に変わっていないか
データ品質	欠損値、異常値、型の不一致などが増えていないか
モデル精度	正解データが取得できる場合、精度が下がっていないか
システム指標	レイテンシー、失敗率、スループットなど
コスト	推論コストやリソース使用量が増えていないか

このように、モデル監視では
データ・モデル・システム の3つの観点が重要になります。

🛎 Model Monitor で行うこと

Model Monitor を使った監視の流れは、ざっくり以下のように考えると分かりやすいです。

本番 Endpoint の入出力データを収集する
↓
学習時データの基準と比較する
↓
データ分布や品質の変化を検出する
↓
しきい値を超えた場合に通知する
↓
結果を確認し、必要に応じて再学習や調査を行う

代表的には、以下のような作業を行います。

機能	説明
データ収集	本番推論の入力と出力を取得する
ベースライン作成	学習時データから基準となる統計情報を作る
比較	本番データとベースラインを比較する
違反検出	しきい値を超えた変化や異常を検出する
通知	問題があれば関係者に知らせる
レポート生成	監視結果を確認できる形で出力する

🔔 監視でアラートを出す意味

監視では、ただデータを見て終わりではなく、
異常があったときに気づけることが重要です。

たとえば、以下のような場合です。

欠損値が急に増えた
特定の特徴量の分布が大きく変わった
予測結果が急に偏った
推論失敗が増えた
レイテンシーが悪化した

このような変化が発生した場合、
通知を出して担当者が調査できるようにします。

本番運用では、問題を早く検知することが非常に重要です。

🔁 Data Drift が見つかったらどうするか？

Data Drift を検知した場合、すぐにモデルを作り直せばよいとは限りません。

まず、何が起きているのかを確認する必要があります。

主な対応は以下です。

対応	説明
データ品質を確認する	欠損や型不一致などのデータ問題か確認する
ビジネス変化を確認する	ユーザー層や施策変更などが原因か確認する
一時的な変化か確認する	キャンペーンや季節要因など一時的なものか確認する
モデル精度を確認する	正解データがある場合、実際に精度が下がっているか確認する
再学習を検討する	新しいデータでモデルを更新する
特徴量を見直す	変化に強い特徴量に改善する

Data Drift は、単なる技術的な問題ではなく、
ビジネス環境の変化を示していることもあります。

そのため、データサイエンティストだけでなく、業務担当者とも連携して確認することが重要です。

☁️ AWS 試験での見られ方

AWS の AI / ML 系試験では、Model Monitor や Data Drift は、
本番運用・MLOps・監視の文脈で出てきやすいテーマです。

特に、以下のようなキーワードが出たら意識するとよいです。

「モデルをデプロイ後に監視したい」

この場合は Model Monitor を考えます。

デプロイ後のモデル監視
入力データと予測結果の確認
データ品質や分布変化の検出

「本番データが学習時データと変わっている」

この場合は Data Drift を考えます。

学習時データと本番データの分布差
モデル精度低下の原因
再学習の検討

「予測精度が時間とともに低下している」

この場合、Data Drift やモデル劣化が疑われます。

対応としては、

本番データを確認する
Model Monitor の結果を見る
新しいデータで再学習する
特徴量やモデルを見直す

といった選択肢が考えられます。

👨‍💻 実務目線で見ると

実務では、モデルは「作って終わり」ではありません。

むしろ、本番に出してからが運用の始まりです。

たとえば、以下のようなケースがあります。

ユーザー層が変わる

広告施策や新サービスの影響で、
以前とは違うユーザーが増えることがあります。

商品やサービスが変わる

新しい商品カテゴリが追加されると、
過去データで学習したモデルが対応しにくくなることがあります。

季節性がある

年末、セール期間、長期休暇などで、
ユーザー行動が大きく変わることがあります。

データ取得方法が変わる

システム改修によって、入力データの形式や意味が変わることがあります。

このような変化に気づかないままモデルを使い続けると、
ビジネス判断を誤る可能性があります。

そのため、本番運用では監視と再学習の仕組みを考えることが重要です。

🧠 ここは特に覚えたいポイント

覚え方 1

Monitoring = モデルが本番で正常に動き続けているか確認すること

覚え方 2

Model Monitor = デプロイ後のモデル監視を支援する仕組み

覚え方 3

Data Drift = 学習時データと本番データの分布が変わること

覚え方 4

モデルはデプロイして終わりではない

覚え方 5

Data Drift を検知したら、データ品質・ビジネス変化・再学習の必要性を確認する

✅ まとめ

今回は、モデル運用で重要な Model Monitor と Data Drift について整理しました。

重要なポイントは以下です。

Monitoring は、モデルが本番環境で正常に動き続けているか確認すること
モデルはデプロイ後も、入力データや予測結果を継続的に確認する必要がある
SageMaker Model Monitor は、デプロイ後のモデル監視を支援する機能
Data Drift は、学習時データと本番データの分布が変わること
Data Drift が起きると、モデル精度が下がる可能性がある
監視対象には、入力データ、予測結果、データ品質、モデル精度、システム性能などがある
Data Drift を検知したら、データ問題なのか、ビジネス変化なのか、再学習が必要なのかを確認する

機械学習モデルは、作ってデプロイするだけでは不十分です。
本番環境で価値を出し続けるためには、
継続的に監視し、必要に応じて改善する仕組み が必要です。

📌 シリーズまとめ

ここまでの 12 日間では、機械学習の基礎から SageMaker の運用までを整理してきました。

Day 1：機械学習の全体像
Day 2：過学習・未学習・bias / variance
Day 3：データ分割と cross validation
Day 4：Confusion Matrix
Day 5：accuracy / precision / recall
Day 6：F1 Score
Day 7：データ前処理
Day 8：SageMaker の全体像
Day 9：Data Wrangler と特徴量作成
Day 10：Training とハイパーパラメータチューニング
Day 11：SageMaker の推論方式
Day 12：Model Monitor と Data Drift

このシリーズを通して、AWS の機械学習系資格や実務で必要になる基本的な考え方を、一通り整理できたと思います。

特に重要なのは、単にサービス名を暗記するのではなく、

どの場面で、何を使うのか
なぜその指標を見るのか
モデルを本番でどう運用するのか

を理解することです。

今後さらに学習を進める場合は、SageMaker Pipelines、Feature Store、Model Registry、Clarify、MLOps、セキュリティ、コスト最適化なども整理していくと、より実務に近い理解につながります。