SageMaker AI推論の品質劣化を検出するメタモニタリング基盤、AWSが公開

何が発表されたか

AWSは2026年7月30日、Amazon SageMaker AIエンドポイント向けの『推論メタモニタリング』ソリューションをブログで公開しました。これは本番環境のML推論パイプラインの上に置くガバナンス層で、予測品質とデータ品質のメトリクスを継続的に追跡し、傾向を可視化するものです。Amazon Quickを中心に、オプションでSageMaker AI MLflow Appを組み合わせます。

主な対象は、不正検知、与信スコアリング、需要予測などに使われる予測モデルです。システムには、データドリフトとモデルドリフトの検出、遅延して届く正解ラベルの統合、自動化されたパフォーマンスダッシュボードの作成という機能が含まれます。セットアップ用のCloudFormationテンプレートも提供されており、VPCやSageMaker AIドメイン、JupyterLabスペースを自動で作成できます。

技術的な新しさ

従来、本番モデルの品質劣化に気づくのは、顧客からの苦情や抜き打ちチェックがきっかけになることが多く、問題の発見が数週間後になるケースがありました。不正検知であれば偽陽性の急増、与信審査であればフラグが立つべき申請の見逃し、需要予測であれば過剰在庫といった形で問題が顕在化します。このソリューションでは、モデル品質の低下やデータドリフトを検出した時点で即座にアラートを出し、チームが早期に対応できるようにします。

技術的な特徴は、モデル登録時に『baseline.json』という不変の基準ファイルを固定する点です。このファイルには、モデルが評価されたデータスライスのIcebergスナップショットIDと、そのモデルを生成したコードのコミットSHAが記録されます。ドリフト計算のたびにこの基準を参照するため、本番の推論データは常に、登録されたモデルが実際に使ったデータとコードの正確なバージョンと比較されます。後からソーステーブルを再投入しても、過去のドリフト判定が変わることはありません。

システムの構成

全体は訓練、推論、監視の3つのパイプラインで構成され、Amazon AthenaのIcebergテーブルを中央のデータレイクとして統合します。訓練ではKaggleのクレジットカード不正検知データセットを使い、transaction_idに対する決定的ハッシュで80%を訓練データ、20%を評価データに分割します。この評価データはドリフト監視の基準として固定され、登録されるすべてのモデルの評価も同じスライスに対して行われます。

推論エンドポイントのカスタムハンドラは、すべての推論結果をAmazon SQSに書き出します。inference-logger Lambda関数が最大10件、または30秒間に到着した分の予測をまとめてAthena Icebergテーブルに保存します。監視用のLambda関数は、エンドポイントが現在提供しているモデルを特定してbaseline.jsonを読み込み、データドリフトとモデルドリフトをそれぞれ独立に計算します。

データドリフトの計算にはEvidently AIのDataDriftPresetを使用し、列ごとに統計検定を自動選択します。サンプル数が1000未満の場合はコルモゴロフ・スミルノフ検定またはカイ二乗検定、1000以上の場合にはWasserstein距離またはJensen-Shannon距離を使います。例えば、学習データのtransaction_amountの平均が50ドルだったのに、最近の予測では平均が500ドルになっていれば、KS検定が分布の変化を検出します。モデルドリフトにはClassificationPresetを使用し、ROC-AUC、適合率、再現率、F1の低下を追跡します。検定方式によってドリフトの方向が異なる問題に対処するため、正規化されたdrift_magnitudeフィールドも計算されます。

既存手法との比較

このソリューションは、AWSマネージドサービスとオープンソースのMLツールを組み合わせた構成です。MLflowは実験追跡とモデル登録を担当し、Evidently AIはドリフト検出エンジンとして機能します。SageMaker AIのMLflow Appとして統合できるため、AWS上で運用しながらMLflowやEvidently AIのエコシステムを活用できます。

ドリフト計算の結果はmonitoring_responsesテーブルに保存され、計算対象となったモデルパッケージのARNとIcebergスナップショットIDが記録されます。これにより、モデルバージョンごとに傾向をスライスして確認できます。また、データドリフトとモデルドリフトで基準を分けている点も特徴です。データドリフトは学習データの分布を基準に、モデルドリフトは評価データの分布を基準に、それぞれ独立して計算されます。

注意点と今後の課題

このソリューションは、ノートブック内のステップ2〜4（ドリフトデータの生成、推論の送信、正解ラベルの適用）をそのまま本番で使うことは想定していません。これらは開発・テスト用の操作であり、本番ではアプリケーションがエンドポイントを呼び出す処理と、不正調査チームがラベルを確定するプロセスに置き換える必要があります。遅延ラベルの例では、自動承認された取引、顧客によるチャージバックの申し立て、銀行による不正判定などが実際の確定ラベルになると説明されています。

監視の閾値は環境変数で調整できます。例として、データドリフトでは直近1日分の推論を対象に、特徴量の20%以上がドリフトしたらアラートを出す設定が示されています。モデルドリフトではROC-AUCの低下が0.05を超えた場合にアラートを出す例が示されており、正解ラベルが届くまでの遅延に応じて参照期間を調整します（config.yamlのデフォルトは30日）。なお、このソリューションでは2つの追加テーブルが作成されますが、現時点では未使用とされています。うち1つはground_truthテーブルで、確定ラベルの保持に使われる可能性があります。