AI-300 · LESSON 2
機械学習モデルのライフサイクルと運用の実装25–30% · 4項目
学習ジョブのオーケストレーションから、モデルの登録と版管理、本番へのデプロイ、本番での監視までの、ML のライフサイクル全体を学びます。
2.1モデルの学習をオーケストレーションする
Orchestrate model training
概念
学習はジョブとして実行します。コマンドジョブは 1 つのスクリプトの実行、スイープジョブはハイパーパラメータの探索、パイプラインジョブは複数のステップ(前処理→学習→評価)の連結、AutoML はモデルの選択と調整の自動化です。MLflow で指標・パラメータ・成果物を記録します。
仕組み・手順
- 学習スクリプトで mlflow.autolog() などを使い、指標を記録する
- コマンドジョブとして、環境・計算資源・入力データを指定して送信する
- スイープジョブで探索空間・サンプリング(ランダム・グリッド・ベイズ)・早期終了ポリシー(Bandit など)を設定する
- 前処理・学習・評価をコンポーネント化し、パイプラインジョブでつなぐ
- スケジュールやイベントでパイプラインを定期実行する
業務での例
需要予測のパイプラインを、毎週月曜にスケジュールで実行し、スイープで学習率と木の深さを探索、最良の実行だけを次のステップに渡す。
紛らわしい点・試験の注意
- 早期終了ポリシーは、見込みのない試行を止めてコストを下げるもの(精度を上げるものではない)
- ベイズサンプリングは早期終了ポリシーと併用できない
- パイプラインのステップの出力は、変更がなければ再利用(キャッシュ)される
ミニクイズ
Q1. 複数の学習ジョブのパラメーターと精度を記録し、後から比較したい。適切なものはどれか。
- Application Insights
- ジョブの標準出力のログ
- MLflow による実験追跡
- データ資産のタグ
答えと解説を見る
正解:C MLflow による実験追跡
MLflow でパラメーター・指標・成果物を記録すれば、ジョブ間で比較できる。 【他の選択肢】標準出力ログは比較用に構造化されていない。Application Insights は運用の監視向けで、実験の比較には使わない。データ資産のタグは試行の指標を記録しない。
Q2. どのアルゴリズムが適しているか分からない分類問題で、候補を効率よく探索したい。適切な機能はどれか。
- 責任ある AI のダッシュボード
- スイープジョブ(ハイパーパラメーター調整)
- 自動機械学習(AutoML)
- デザイナーのパイプライン
答えと解説を見る
正解:C 自動機械学習(AutoML)
AutoML は前処理とアルゴリズムの組み合わせを自動で探索する。 【他の選択肢】スイープジョブは決めたアルゴリズムのパラメーターを探索する。デザイナーは手作業でパイプラインを組む。ダッシュボードはモデルの分析用である。
参考リンク
2.2モデルの登録と版管理を実装する
Implement model registration and versioning
概念
モデルはワークスペースのモデルレジストリに名前と版で登録します。MLflow 形式で登録すると、スコアリングスクリプトや環境を書かずにノーコードでデプロイできます。複数のワークスペース(開発・本番)で共有するには Azure Machine Learning レジストリを使います。
仕組み・手順
- 最良のジョブの成果物から MLflow モデルとして登録する(版は自動で増える)
- タグやプロパティで、学習データの版・評価指標・承認状態を記録する
- 組織のレジストリにモデル・環境・コンポーネントを登録し、本番のワークスペースから参照する
- 本番に出す版を明確にし、旧版は削除せず残して切り戻しに備える
業務での例
開発のワークスペースで登録した churn-model の版 7 を、組織のレジストリにコピーし、本番のワークスペースのエンドポイントがレジストリから版を指定してデプロイする。
紛らわしい点・試験の注意
- ワークスペースのモデルレジストリはそのワークスペース内だけ。ワークスペース間の共有は「レジストリ」
- MLflow モデルはノーコードデプロイが可能。カスタムモデルはスコアリングスクリプトと環境が必要
- 同じ名前で登録すると上書きではなく新しい版になる
ミニクイズ
Q1. 登録済みモデルが不要になったが、監査のため履歴は残したい。適切な対応はどれか。
- モデルに「非推奨」のタグだけを付ける
- モデルのバージョンをアーカイブする
- モデルを別のワークスペースへ移す
- モデルの最新バージョンだけを削除する
答えと解説を見る
正解:B モデルのバージョンをアーカイブする
アーカイブすれば一覧からは外しつつ履歴を残せる。 【他の選択肢】削除すると履歴が失われる。タグだけでは一覧に表示され続ける。別のワークスペースへの移動は監査の履歴を分散させる。
Q2. ローカル PC で実行した学習の記録を、Azure Machine Learning のワークスペースに残したい。最も適切な方法はどれか。
- 学習の結果を、ワークスペースのジョブの説明欄に手で転記する
- ローカルの学習を中止し、ワークスペースのクラウドのジョブで再実行する
- ローカルの mlruns フォルダーをワークスペースのデータ資産として登録する
- MLflow の追跡 URI をワークスペースに設定する
答えと解説を見る
正解:D MLflow の追跡 URI をワークスペースに設定する
MLflow の追跡 URI をワークスペースに向けると、ローカルの学習でもワークスペースに記録できる。 【他の選択肢】再実行は不要な手間。データ資産の登録では実行の記録として扱われない。手での転記は誤りが起き、メトリクスも残らない。
参考リンク
2.3本番環境に機械学習モデルをデプロイする
Deploy machine learning models for production environments
概念
エンドポイントは呼び出しの入口、デプロイはその背後で動くモデルと計算資源の組です。マネージドオンラインエンドポイントはリアルタイムの低レイテンシ推論、バッチエンドポイントは大量データの非同期推論に使います。1 つのエンドポイントに複数のデプロイを置き、トラフィックの割合で切り替えられます。
仕組み・手順
- マネージドオンラインエンドポイントを作成し、認証(キーまたは Microsoft Entra トークン)を選ぶ
- blue デプロイ(現行)と green デプロイ(新版)を作り、green にトラフィックを 10% 流す
- ミラートラフィックで本番のリクエストのコピーを新版に送り、応答は返さずに検証することもできる
- 問題がなければ green を 100% にし、blue を削除する
- 大量の定期推論はバッチエンドポイントでデータ資産を入力にして実行する
業務での例
与信スコアの新モデルを green として 10% のトラフィックで 1 週間運用し、エラー率とレイテンシを確認してから全面的に切り替える。
紛らわしい点・試験の注意
- ミラー(シャドー)トラフィックは利用者に応答を返さない。トラフィック分割は実際に応答を返す
- バッチエンドポイントはリアルタイムの応答には使えない
- オンラインエンドポイントの自動スケールは Azure Monitor の自動スケール設定で行う
ミニクイズ
Q1. 受注の可否を画面操作中に即時判定したい。一方、月次の需要予測は大量データを夜間に処理したい。適切な組み合わせはどれか。
- 両方ともオンラインエンドポイントにし、月次予測は夜間に大量の要求を送る
- 両方ともバッチエンドポイントにし、即時判定はジョブの完了を待って返す
- 即時判定はリアルタイム(オンライン)エンドポイント、月次予測はバッチエンドポイント
- 即時判定はバッチエンドポイント、月次予測はリアルタイム(オンライン)エンドポイント
答えと解説を見る
正解:C 即時判定はリアルタイム(オンライン)エンドポイント、月次予測はバッチエンドポイント
低遅延の単発要求はオンライン、大量の非同期処理はバッチが適する。 【他の選択肢】2 つ目は役割が逆。オンラインエンドポイントでの大量処理は費用と負荷が大きい。バッチの完了待ちでは即時に判定できない。
Q2. 本番モデルの入力データの傾向が、学習時から変化していないか継続的に確認したい。適切なものはどれか。
- エンドポイントの要求数と遅延のメトリックに、しきい値のアラートを設定する
- データドリフトの監視と、しきい値超過時のアラート・再学習トリガー
- 推論の入出力をストレージに保存し、問題があった時に確認する
- 学習時の評価指標を記録し、四半期ごとに担当者が見直す
答えと解説を見る
正解:B データドリフトの監視と、しきい値超過時のアラート・再学習トリガー
ドリフト監視で劣化の兆候を早期に検知し、再学習につなげる。 【他の選択肢】要求数や遅延はデータの傾向を示さない。四半期ごとの見直しや事後の確認では継続的な監視にならない。
参考リンク
2.4本番の機械学習モデルを監視・保守する
Monitor and maintain machine learning models in production
概念
モデルの監視は、本番の入力や予測が学習時と比べて変化していないかを継続的に確認する仕組みです。Azure Machine Learning のモデル監視では、データドリフト・予測ドリフト・データ品質・特徴量アトリビューションのドリフトを、基準のデータ(学習データなど)と比べて計算し、閾値を超えたらアラートを出します。
仕組み・手順
- オンラインエンドポイントで推論データの収集(データコレクター)を有効にする
- 監視の基準データ(学習データまたは過去の本番データ)と信号・閾値を設定する
- スケジュールで監視を実行し、アラートを Azure Monitor・メールで受け取る
- ドリフトを検知したら原因を調べ、パイプラインで再学習・再登録・再デプロイする
- Application Insights でレイテンシとエラーも監視する
業務での例
解約予測の入力の「契約期間」の分布が大きく変わったアラートを受け、新しいデータで再学習し、green デプロイで検証してから切り替える。
紛らわしい点・試験の注意
- データドリフトは入力の分布の変化、予測ドリフトは出力の分布の変化
- 正解ラベルが遅れて届く場合、まずドリフトで早期に兆候をつかむ
- インフラの監視(CPU・エラー)とモデルの品質の監視は別物
ミニクイズ
Q1. 毎月の再学習の仕組みとして最も適切なものはどれか。
- 学習のコマンドジョブだけをスケジュールし、評価は四半期ごとに行う
- 前処理・学習・評価のノートブックを、担当者が毎月手で実行する
- 前処理・学習・評価・登録のパイプラインを、スケジュールで実行する
- 毎月 AutoML のジョブを手で設定し直し、最良のモデルを登録する
答えと解説を見る
正解:C 前処理・学習・評価・登録のパイプラインを、スケジュールで実行する
パイプラインにスケジュールを設定すると、毎月同じ手順で再学習・評価・登録ができる。 【他の選択肢】手作業の実行は漏れや手順の違いが出る。評価を別の周期にすると、再学習したモデルを確認せずに使うことになる。
Q2. モデルの監視でデータドリフトを計算するには、比較の基準となるデータが必要である。基準として最も適切なものはどれか。
- 評価に使ったテストデータの一部
- ランダムに生成した、同じ列を持つデータ
- 直近 1 日分の本番の推論の入力データ
- 学習データ(または検証済みの過去の本番データ)
答えと解説を見る
正解:D 学習データ(または検証済みの過去の本番データ)
ドリフトは基準データ(通常は学習データや安定していた時期の本番データ)との比較で計算する。 【他の選択肢】直近のデータ同士の比較では学習時からの変化が分からない。少量のテストデータは基準として偏る。ランダムなデータは分布が無関係である。
参考リンク
レッスンは当サイトがMicrosoft Learn の公開ページをもとに独自に作成したもので、試験の内容を保証するものではありません。製品の仕様は変わることがあるため、参考リンク先の最新情報を確認してください。
ご利用上の注意(非公式・独自問題・合格保証なし)
- 本サイトの問題は、公式に公開されているスキル概要・試験ガイドをもとに当サイトが独自に作成した練習問題であり、実際の試験問題ではありません。
- Microsoft、Azure、Copilot、Microsoft 365、Dynamics 365、Power Platform は Microsoft グループの商標です。本サイトは Microsoft と提携しておらず、Microsoft による承認・推奨を受けたものではありません。
- 本コンテンツは学習の補助であり、合格を保証するものではありません。試験の内容・形式・前提条件は予告なく変更されます。受験前に必ず公式ページで最新情報を確認してください。
- 本模擬試験の正答率は、公式試験の換算(スケール)スコア(合格 700)とは換算できず、合否を予測するものではありません。
- 未ログイン時の進捗はこのブラウザ内(localStorage)に保存します。Google でログインすると学習記録をアカウントに同期します。端末内の記録とサーバー上の記録は別に削除します。詳しくは保存・同期の説明とCookie・保存設定をご確認ください。