ひとことで言うと
本番のエンドポイントに流れている実データを S3 に貯め、学習時に作ったベースラインと定期的に突き合わせて、外れたら CloudWatch で鳴らす仕組みです。監視するのはインフラの健康状態ではなく、データとモデルの中身です。
要するに、定期健診の基準値表です。健診が意味を持つのは、比較対象になる基準値が先に決まっているからで、Model Monitor も同じくベースラインを作らないと何も始まりません。そして健診は「血液を採る」ところが前提条件になる——それが Data Capture です。採血していない項目は、あとから遡って測れません。
なぜ生まれたか
学習データは丁寧に整えられていますが、本番に来るデータはそうではありません。公式の言い方では「本番のモデルは、たいていの学習データセットのように注意深くキュレーションされていない現実のデータに対して予測しなければならない」。入力の統計的性質がベースラインから離れていくと、モデルは壊れないまま精度だけ落ちます。エラーも出ず、レイテンシも正常で、CPU 使用率も変わりません。
さらに厄介なのは、モデル品質の劣化は正解ラベルが遅れて届くことです。与信の焦げ付きは数か月後にしか分かりません。この「遅れて来る正解と、すでに出した予測を突き合わせる」作業を仕組みにしたのが、モデル品質監視の Ground Truth マージです。
| その前の不便 | Model Monitor が用意したもの |
|---|---|
| 本番データの分布ずれが誰にも見えない | Data Capture で入出力を S3 に保存し、ベースラインと定期比較 |
| 「ずれている」の閾値を毎回自分で決める | ベースラインジョブが統計量と制約（constraints）を自動で提案する |
| 正解ラベルが遅れて届き、予測と紐づかない | 推論IDを使って Ground Truth と予測をマージする経路 |
| 公平性の測定が学習時の一度きり | バイアスドリフト・特徴量寄与ドリフトをスケジュール実行 |
何に使うか
4種類あり、必要な入力が全部違います。ここの切り分けが試験でも実務でも本体です。
| 監視の種類 | 何を見るか | 必要な入力 | 関連ドメイン |
|---|---|---|---|
| データ品質 | 入力特徴量の統計的ドリフト。ベースラインは Deequ（Apache Spark 上の OSS）で各特徴量のスキーマ制約と統計量を算出 | 学習データ（ベースライン）＋キャプチャした推論入力。正解ラベルは不要 | D4 / D5 |
| モデル品質 | 精度そのもの。問題種別に応じた指標（回帰なら MSE など） | 上記に加えて S3 に置いた実際の Ground Truth ラベル。予測とマージして比較 | D5 |
| バイアスドリフト | 保護属性（facet）ごとの結果の偏りが、許容範囲から外れていないか | Clarify が作ったバイアスのベースライン＋キャプチャデータ | D3 |
| 特徴量寄与ドリフト | 特徴量の重要度の順位が学習時から入れ替わっていないか | Clarify が作った SHAP ベースライン＋キャプチャデータ | D3 |
動かし方は4種とも同じ骨格です。① Data Capture を有効化 → ② ベースラインを作る → ③ 監視スケジュールを定義 → ④ レポートと違反を見る／CloudWatch で鳴らす。リアルタイムエンドポイントの継続監視、定期実行するバッチ変換ジョブの継続監視、非同期バッチ変換のスケジュール監視の3形態に対応します。
試験でどう問われるか
Model Monitor も主役では出ません。 AIP-C01 は生成AIアプリの試験で、そこで監視の主役になるのは CloudWatch と Bedrock のモデル呼び出しログのほうです。Model Monitor が出るのは、**D3.3 の「ドリフト・バイアス監視」、D4.3 の「監視」、D5.2 の「ドリフト診断」**で、シナリオに SageMaker AI のエンドポイントに載せた予測モデルが登場したときに限られます。
そして最大の引っかけは「LLM の応答品質を監視したい」に Model Monitor を選ばせにくる形です。 公式が明記しているとおり、Model Monitor が指標と統計量を計算できるのは表形式データだけ。テキストの入出力は対象外です。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| LLM の応答品質・ハルシネーション率を継続監視したい | Bedrock のモデル呼び出しログ＋CloudWatch（＋評価は Bedrock Evaluations） | Model Monitor。表形式データにしか統計量を出せない |
| 入力データの分布が学習時からずれたか知りたい | データ品質監視。正解ラベルが要らないのが決め手 | モデル品質監視（正解ラベルが揃うまで動かせず、要件に対して重い） |
| 精度が落ちていないか知りたいが、正解は数か月後にしか出ない | モデル品質監視＋Ground Truth の取り込み・マージ（推論IDで突合） | データ品質監視（分布は見られるが精度は答えない）／「正解が無いので監視できない」とする選択肢 |
| 特定の属性に対する予測の偏りが本番で変化していないか | バイアスドリフト監視（ベースラインは Clarify） | データ品質監視（特徴量の分布は見るが、facet ごとの結果の偏りは見ない） |
| 「学習時は SAT スコアが最重要だったのに、今は別の特徴量が効いている」を検知したい | 特徴量寄与ドリフト監視 | モデル品質監視（精度が保たれたまま寄与だけ入れ替わる場合、鳴らない） |
| 監視を始めたいが、エンドポイントは既に数か月動いている | まず Data Capture を有効化。過去に遡ってキャプチャはできない | 「既存のエンドポイントログから復元する」案 |
| 逸脱を検知したら自動で通知したい | CloudWatch メトリクスとアラーム | 監視ジョブ自体が再学習を自動実行するという選択肢（Model Monitor は検知して知らせるところまで） |
1問拾える境目: データ品質とモデル品質を分けるのは正解ラベルが要るかどうか、バイアスドリフトと特徴量寄与ドリフトを分けるのは「誰に対する結果か」を見るか「どの特徴量が効いているか」を見るかです。特徴量寄与ドリフトは NDCG（Normalized Discounted Cumulative Gain）で学習時と本番の寄与ランキングを比較し、NDCG が 0.90 を下回ると自動でアラートを上げます。順位の入れ替わりだけでなく、元の寄与スコアが高かった特徴量ほど重く効くように設計されています。
実務でどう使うか
Model Monitor は新規のお客様には提供されていません。公式ドキュメントの各ページ冒頭に「Amazon SageMaker Model Monitor is no longer open to new customers」と入り、既存利用者は継続利用できるものの新機能の追加予定は無いと明記されています。公式が示す置き換えは、aws-samples で公開されているオープンソースの SageMaker AI 監視ソリューション（MLflow ＋ Evidently AI）＋ QuickSight ＋ CloudWatch の組み合わせです。試験ガイドの In-Scope には残っているので概念は覚える価値がありますが、新規採用の対象ではありません。
- Data Capture は高いディスク使用率で取りこぼします。 推論リクエストに影響を与えないため、ディスク使用率が高くなるとキャプチャを停止する設計です。公式の推奨は75% 未満に保つこと。監視の穴が「静かに」空くので、気づきにくい部類です。
- マルチモデルエンドポイントは監視できません。 対応するのは単一モデルをホストするエンドポイントだけです。推論パイプラインは監視できますが、キャプチャと分析はパイプライン全体に対して行われ、個々のコンテナ単位では見られません。
- 画像を入力するモデルでも「出力だけ」は監視できます。 表形式にしか統計量を出せないというのは入力の話で、ラベルを出す画像分類モデルなら出力側の指標は取れます。監視を諦める前にここを確認します。
- カスタム VPC で Studio を動かしている場合、S3 と CloudWatch への VPC エンドポイントが要ります。 これが無いと監視ジョブが通信できません。
- 監視スケジュールは Processing Job のインスタンスを定期的に立ち上げます。 使っていない監視を放置すると、実行のたびに課金が続きます。スケジュールを削除すると停止も同時に行われますが、過去の実行履歴は削除されません。
- Ground Truth のマージには推論IDが要ります。 バッチ変換では、Data Capture の設定で出力と一緒に推論IDを生成するオプションがあり、これがキャプチャデータと正解データの突合の鍵になります。設計時に決めておかないと、後から紐づけられません。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon CloudWatch | CloudWatch はインフラと呼び出しの指標（レイテンシ、エラー、CPU/GPU）。Model Monitor はデータとモデルの中身。Model Monitor の結果を鳴らす先が CloudWatch なので、対立ではなく上下の関係 |
| Amazon SageMaker Clarify | Clarify は測る式そのもの。Model Monitor はそれを定期実行して逸脱を鳴らす器。バイアスドリフトと特徴量寄与ドリフトは、両者が組んで初めて成立する |
| Amazon Bedrock Evaluations | 生成AIモデルの評価。Model Monitor は表形式データ専用なので、LLM の応答品質はそもそも守備範囲外 |
| Amazon SageMaker Model Registry | Registry はデプロイ前の版と承認。Model Monitor はデプロイ後の実測。時間軸が逆で、監視結果が次の版の承認材料になる |
| AWS Glue Data Quality | Glue Data Quality はデータパイプライン上のデータの品質。Model Monitor はエンドポイントに実際に届いた推論入力の品質。見ている場所が違う |
想起チェック
Q1. データ品質監視とモデル品質監視を分ける、たった1つの判定基準は何ですか。
Ground Truth（正解ラベル）が必要かどうかです。データ品質は入力の分布をベースラインと比べるだけなので正解が要りません。モデル品質は S3 の正解ラベルを予測とマージして精度を計算します。
Q2. 精度は落ちていないのに、特徴量の重要度が学習時と入れ替わっています。どの監視が該当しますか。
特徴量寄与ドリフト監視です。NDCG で学習時と本番の寄与ランキングを比較し、0.90 を下回るとアラートが上がります。モデル品質監視は精度しか見ないので、この状態では鳴りません。
Q3. 「LLM チャットボットの応答品質を継続的に監視したい」。Model Monitor を選びますか。
選びません。 Model Monitor が指標と統計量を計算できるのは表形式データだけで、テキストの入出力は対象外です。Bedrock のモデル呼び出しログと CloudWatch、評価は Bedrock Evaluations 側になります。
Q4. すでに3か月稼働しているエンドポイントを、今日から監視したくなりました。最初にやることは何ですか。
Data Capture を有効にすることです。キャプチャは過去に遡れないので、有効化した時点より前の推論は分析対象になりません。ベースライン作成はそのあとです。