Amazon MLS-C01: MLOps、モニタリング、ラベリングとモデルガバナンス — 学習ガイド

By Laurynas Brazys · 26 July 2026 · #amazon #mls-c01 #certification #exam-prep #study-guide

こちらの一部です： AWS Machine Learning Specialty MLS-C01 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

パイプライン、CI/CD、および自動化

本番環境レベルのMLでは、データインジェスト、検証、トレーニング、チューニング、モデルパッケージング、デプロイメントを、再現可能なパイプラインに統合するエンドツーエンドの自動化が必要です。Amazon SageMaker Pipelinesを使用して、Processingジョブ（Data WranglerまたはScriptProcessor）、Training（Distributed Data ParallelまたはXGBoost/BlazingTextによるマネージドトレーニング）、Hyperparameter Tuning（目的メトリクスとトレーニングジョブのStoppingConditionを指定したHyperparameterTuningJob）、およびSageMaker Model Registryへのモデル登録のステップを定義します。パイプラインをAWS CodePipelineおよびCodeBuildと統合してコードレベルのCIチェックと単体テストを行い、CloudFormationまたはCDKを使用して一貫性のある環境をプロビジョニングします。変更のない作業の再実行を避けるためにステップのキャッシュを設定し、パイプラインの入力（S3プレフィックス、インスタンスタイプ）をパラメータ化します。HPOでは、MaxNumberOfTrainingJobsだけに頼るのではなく、トレーニングジョブごとのStoppingCondition（MaxRuntimeInSeconds）も設定し、利用可能な場合は自動早期停止を有効にしてコストの暴走を避けてください。よくある落とし穴には、増え続けるデータセットに対してファイルモードを使用すること（大規模データセットの場合はパイプモードまたは分散トレーニングに切り替える）、データセットと特徴量をバージョニングしないこと、再トレーニング前にデータ検証ゲート（SageMaker Processing + DeequまたはData Wranglerのチェック）を含めないことなどがあります。データベース内モデル（Redshift ML）とSageMakerのどちらを選択するかの判断基準は、モデルの複雑さ、レイテンシー、および運用上のコントロールに基づきます。Redshift MLはSQL内で単純なXGBoostモデルを扱うのに便利ですが、ディープネットワーク、カスタムアーキテクチャ、スケーラブルなエンドポイントにはSageMakerが必要です。

モニタリング、ドリフト検出、およびモデル品質

継続的なモニタリングでは、モデルのパフォーマンスとデータ品質の両方をキャプチャする必要があります。SageMakerモデルエンドポイントのデータキャプチャを有効にしてリクエストとレスポンスをS3に保存し、次にSageMaker Model Monitorのベースラインジョブでトレーニングデータの分布をベースライン化します。スキーマ違反や単変量ドリフトメトリクスには、Model Monitorの組み込みチェックを使用します。分布シフトについては、KLダイバージェンス、PSI（Population Stability Index）、またはKS検定を計算し、ドリフトのしきい値に対してCloudWatchアラームを設定します。モデルメトリクスを追跡します—分類：適合率/再現率（precision/recall）、ROC AUC、混同行列、クラス固有のFPR/FNR。回帰：RMSE、MAE、MAPE。Clarifyは、トレーニング前およびトレーニング後のタイミングでバイアスと説明可能性のチェックを実行し、SHAPベースの特徴量アトリビューションを生成できます。Clarifyを使用して、サブグループ間のパフォーマンス格差（機密属性）を検出します。運用上のよくある落とし穴には、推論コンテキスト（特徴量のマッピング、モデルバージョン、リクエストID）をキャプチャしないこと、ラベルの遅延を無視すること（ラベルが遅れるとタイムリーな評価が破綻する）、ポピュレーションシフトとコンセプトドリフトを混同することなどがあります。これらは異なる方法で対処します（再トレーニング vs ラベルを収集して特徴量を再評価）。アラートのためには、集計されたメトリクスとドリフト指標をCloudWatchにプッシュし、しきい値を超えた場合にはSageMaker Pipelinesを介してロールバックまたは再トレーニングを自動化します。

ラベリング、データ準備、および特徴量エンジニアリング

高品質なラベルと一貫性のある特徴量パイプラインは、基盤となります。Amazon SageMaker Ground Truthを使用して、自動事前ラベリング（モデル支援ラベリング）、アクティブラーニング、アノテーションの統合を含むラベリングワークフローを作成します。ワーカータイプ（プライベート、ベンダー、またはパブリック）を選択し、ラベルの検証とアノテーター間の一致度に関するメトリクスを設定します。EDAと変換には、データセットをSageMaker Data Wranglerに取り込み、分布のプロファイリング、欠損値の補完を行い、処理スクリプトをSageMaker Processingジョブにエクスポートします。Amazon SageMaker Feature Storeにオンライン特徴量とオフライン特徴量を永続化し、ランタイムでの一貫した取得と簡単なバックフィルを実現します。エンコーディングの決定は、スケールとカーディナリティに依存します。カーディナリティの低いカテゴリカル変数はワンホットエンコーディングできます。カーディナリティの高い項目（例：100個の製品SKU）は、ターゲットエンコーディングまたは埋め込み（TensorFlow/PyTorchの埋め込みレイヤーまたはSageMakerの組み込みアルゴリズム）を使用し、複数選択式のアンケート回答はマルチホットベクトルにマッピングします。日々のメタデータを追加する際のラベルリーケージ（特徴量エンジニアリングウィンドウとリーケージテストを含める）、非常に大きなS3データセットに対するファイルモードの使用（パイプモードはレコードをストリーミングし、マルチインスタンス分散トレーニングをサポートする）、変換をバージョニングしないことなどのよくある落とし穴に注意してください。トレーニングと推論の間でパリティ（一貫性）を確保するために、Data Wranglerの変換を再利用可能なProcessing/Trainingステップにエクスポートします。

説明可能性、ガバナンス、MLチームのスケーリング

説明可能性とガバナンスには、実用的なアーティファクトと監査証跡が必要です。SageMaker Clarifyを使用して、トレーニング前のバイアス指標とトレーニング後の特徴量アトリビューション（SHAP）を計算し、その結果をModel Registryのエントリと共に保存します。SageMaker Model Registryに、承認ステータス、署名付きのModelPackageGroup、自動化された昇格ゲートを付けてモデルを登録します。SageMaker Experimentsで実験とリネージを追跡し、CloudTrailを有効にしてAPI呼び出しを監査します。説明可能性の技術については、ツリーモデル（XGBoost組み込みのSHAP）にはモデルネイティブの特徴量の重要度を優先的に使用し、ディープネットワークにはSHAPまたはIntegrated Gradientsを使用し、実行時コストに注意します。バッチ処理の顧客向けには説明をオフラインで事前計算し、リアルタイムリクエストには要約を公開します。ガバナンスのベストプラクティスには、データセットの説明、公平性のチェック、文書化されたビジネスルールを含むモデルカードの作成や、モデルデプロイに対するIAMの最小権限の強制が含まれます。チームをスケールさせるには、パイプラインをモジュール化し、前処理/検証用の標準テンプレートを作成し、Feature Storeを中央集権化し、ドリフト検出と再トレーニングのトリガーを自動化して、データサイエンティストが運用ではなく改善に集中できるようにします。よくある罠には、因果関係の判断を特徴量の重要度に過度に依存すること、デプロイされたモデルの監査ログを維持しないこと、低レイテンシーのエンドポイントでコストのかかる説明可能性の計算を同期的に公開することなどがあります。

実践的な問題：ユースケースシナリオ

シナリオ： Acme Manufacturing社は、断続的な接続性を持つリモートセンサー群を運用しており、中央集約のためにAWS IoTとS3を使用しています。同社のAWS ML環境には、SageMaker、IoT Core、Kinesis Data Streams、およびGreengrassが有効化されたエッジデバイスが含まれています。

課題： 接続が断続的なリモートサイトで低レイテンシーの異常検知を提供しつつ、Direct Connectなしで中央での再トレーニングとドリフト検出のためにテレメトリを収集する。

推奨アプローチ：

SageMaker Neoでコンパイルしたコンパクトな異常検知モデルをエッジデバイス上のAWS IoT Greengrassにデプロイし、リアルタイムのローカル推論とアクション（ローカルアラーム、短期的なバッファリング）を実行します。
要約されたテレメトリと異常フラグをAWS IoT Core経由でAmazon Kinesis Data Streamsにストリーミングし、Kinesis Data Firehoseを使用して生データと集計データをS3（parquet形式）に永続化し、中央ストレージに保存します。
S3のバッチを取り込み、Processingジョブ（Data Wrangler）を実行してベースラインの計算と特徴量エンジニアリングを行い、必要に応じてHyperparameterTuningJobsをトリガーし、検証済みのモデルをSageMaker Model Registryに登録するSageMaker Pipelineを構築します。
中央のエンドポイントでSageMaker Model Monitorを有効にし、エッジで収集されたデータ分布をトレーニングのベースライン（PSI/KL）と比較するバッチジョブをスケジュールします。また、サンプリングされたアラートに対してSageMaker Ground Truthを使用してヒューマンラベリングを行い、フィードバックループを完成させます。

論理的根拠： Greengrass + Neoによるエッジ推論は、断続的な接続性の中でも低レイテンシーの意思決定を保証します。Kinesis + Firehoseは、再トレーニングのためにS3への信頼性が高く順序付けられた取り込みを保証します。SageMaker PipelinesとModel Registryは、モデルの品質を維持するために、ドリフトチェックを伴う再現可能な再トレーニング、バージョニング、および自動昇格を提供します。

← セキュリティ、プライバシーとコンプライアンス · すべてのドメイン

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →