2026年のMLOps: MLflow、モデルレジストリ、技術面接の質問

MLOpsの面接質問は、2026年においてニッチな専門分野から、データサイエンスと機械学習エンジニアリングの採用における中核へと変化しました。企業はもはやモデルの学習方法だけを問うのではなく、実際のトラフィックが到達した後に、そのモデルがどのように追跡され、バージョン管理され、デプロイされ、監視されるのかを掘り下げて確認します。本ガイドでは、MLOps面接で繰り返し登場する質問を、ライフサイクルの各段階ごとに整理し、本番環境の構成を反映したMLflowの例とともに解説します。

機械学習ライフサイクルに関するMLOps面接質問

Q1: MLOpsとは何であり、DevOpsとどう異なりますか?

MLOpsは、自動化、CI/CD、監視といったDevOpsの原則を機械学習システムに適用し、さらに従来のソフトウェアには存在しない3つの関心事、すなわちデータのバージョン管理、モデルのバージョン管理、そして実際のデータ分布に対する継続的な検証を加えたものです。従来のDevOpsでは、変化するアーティファクトはコードだけです。一方、MLOpsではコード、データ、学習済みモデルがそれぞれ独立してバージョン管理され、そのいずれもがコードを1行も変更することなく、出力の品質を静かに劣化させる可能性があります。よく引用されるHidden Technical Debt in Machine Learning Systemsという論文は、モデルのコードは実際のMLシステムのごく一部にすぎず、データパイプライン、監視、設定が大部分の表面積を占めていると指摘しています。

Q2: 本番環境の機械学習ライフサイクルの各段階を説明してください。

優れた回答は、5つの段階と、それぞれが生み出すアーティファクトを挙げます。データの取り込みと検証(バージョン管理されたデータセット)、実験(メトリクス付きで追跡された実行)、モデル登録(バージョン管理され昇格可能なモデル)、デプロイ(サービングエンドポイントまたはバッチジョブ)、そして監視(再学習にフィードバックされるドリフトと性能のテレメトリ)です。面接官はフィードバックループに耳を傾けます。監視は実験へと接続し直されなければならず、そうでなければシステムは時間とともに劣化する一方通行のパイプラインになってしまいます。

MLflowチュートリアル例による実験追跡

実験追跡は、ほとんどのMLOpsの質問が土台とする基盤であるため、実際のロギングを示すMLflowチュートリアルの回答は重みを持ちます。MLflowは実行ごとにパラメータ、メトリクス、アーティファクトを記録し、これによってあらゆる結果がその実行ID(run ID)から再現可能になります。

Q3: MLflowのトラッキングはどのように実験を記録し、なぜrun IDが重要なのですか?

mlflow.start_run()を呼び出すたびに、ハイパーパラメータ、メトリクス、シリアライズされたモデルを記録する実行(run)が開始されます。run IDは不変のハンドルであり、あるメトリクスを、それを生み出した正確なコード、パラメータ、データのスナップショットへと結びつけます。これこそが、数か月後でも実験を再現可能にするものです。

# train_with_mlflow.py
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import f1_score

mlflow.set_tracking_uri("http://localhost:5000")  # tracking server
mlflow.set_experiment("churn-prediction")

with mlflow.start_run(run_name="rf-baseline") as run:
    params = {"n_estimators": 300, "max_depth": 12}
    model = RandomForestClassifier(**params).fit(X_train, y_train)

    f1 = f1_score(y_val, model.predict(X_val))

    mlflow.log_params(params)                       # hyperparameters
    mlflow.log_metric("val_f1", f1)                 # validation metric
    mlflow.sklearn.log_model(model, name="model")   # MLflow 3.x uses name=

    print("run_id:", run.info.run_id)               # reproducibility handle

name引数は、MLflow 3.xで非推奨となったartifact_pathを置き換えるものであり、現行のAPIへの理解を示すために言及する価値のある変更点です。MLパイプラインの検証パターンを通じて特徴量とデータセットの追跡に触れる候補者は、より高い評価を得る傾向があります。なぜなら、再現性はモデルだけでなくパイプライン全体に依存するからです。

モデルレジストリ2026: バージョン管理と昇格

MLflowのモデルレジストリは、実行のアーティファクトを、ガバナンスの効いた昇格可能なオブジェクトへと変えます。最近の最大の変化であり、2026年の面接で頻繁に問われる点は、名前付きステージからの脱却です。

Q4: MLflowのモデルレジストリはどのようにモデルを昇格させ、2026年に何が変わったのですか?

以前のバージョンのMLflowは、Staging、Production、Archivedという固定された名前付きステージを通じてモデルを昇格させていました。MLflow 3.xでは、これらのステージが非推奨となり、エイリアスとタグが採用されました。というのも、ハードコードされたステージのリストでは、champion、challenger、shadowといった実際のデプロイのトポロジーを表現できなかったからです。エイリアスは1つのバージョンを指す可変のポインタであるため、昇格はモデルを変化させるのではなく、エイリアスを付け替えることになります。

# register_and_promote.py
import mlflow
from mlflow import MlflowClient

client = MlflowClient()

# Register a logged run artifact as a new model version
result = mlflow.register_model(
    model_uri=f"runs:/{run_id}/model",
    name="churn-classifier"
)

# MLflow 3.x: aliases replace deprecated stages
client.set_registered_model_alias(
    name="churn-classifier",
    alias="champion",        # production traffic resolves here
    version=result.version
)

# Any service loads the current champion without knowing the version
model = mlflow.pyfunc.load_model("models:/churn-classifier@champion")

利用側はmodels:/churn-classifier@championを読み込むため、ロールバックは以前のバージョンへエイリアスを1回付け替えるだけで済み、再デプロイは不要です。MLflowモデルレジストリの公式ドキュメントでは、エイリアスのガバナンスとwebhookトリガーが詳しく解説されています。

機械学習のデプロイパターンとサービング

デプロイに関する質問は、モデルを実際に世に出したことのある候補者と、学習させただけの候補者を区別します。パターンの選択は個人の好みではなく、レイテンシの許容範囲(レイテンシバジェット)に従います。

Q5: バッチ、オンライン、ストリーミングの機械学習デプロイを比較してください。

| パターン | レイテンシ | 代表的なユースケース | サービング形態 | |---------|---------|------------------|-----------------| | バッチ | 数時間〜1日単位 | チャーン(解約)スコアリング、レコメンドの更新 | テーブルに書き込むスケジュール実行ジョブ | | オンライン(リアルタイム) | 数十ミリ秒 | 不正検知、リクエスト時のランキング | RESTまたはgRPCエンドポイント | | ストリーミング | サブ秒、連続的 | イベントフローの異常検知 | メッセージキュー上のコンシューマ |

追加の質問では、ほぼ必ずオンラインのケースをどうサービングするかが問われます。MLflowモデルは自身の実行環境をパッケージ化するため、レジストリのURIに対して1つのコマンドを実行するだけでサービングできます。

# serve_model.sh
# Serve the current champion as a REST endpoint on port 5001
mlflow models serve \
  --model-uri "models:/churn-classifier@champion" \
  --host 0.0.0.0 --port 5001 --env-manager uv

Q6: ブルーグリーンデプロイとカナリアデプロイは、モデルのロールアウトにおいてどのようにリスクを低減しますか?

ブルーグリーンは、2つの同一の環境を保持し、新しいモデルがチェックに合格した後に全トラフィックを一度に切り替えることで、即座にロールバックできる経路を提供します。カナリアは、トラフィックのごく一部を新しいバージョンに振り向け、実際のメトリクスを観察しながら、徐々に割合を引き上げていきます。モデルの場合、通常はカナリアの方が安全です。というのも、モデルの品質問題は実際の入力に対してしか表面化せず、カナリアであれば影響範囲を一部のユーザーに限定できるからです。

機械学習パイプラインのテストとCI/CD

Q7: MLパイプラインのCI/CDは、標準的なソフトウェアパイプラインではテストしない何をテストしますか?

ソフトウェアのCIパイプラインは、コードに対してユニットテストと統合テストを実行します。MLパイプラインは、その上にデータとモデルのテストを追加します。入力データに対するスキーマ検証、学習実行が破損した特徴量を静かに取り込まないための分布チェック、そして候補モデルが固定されたホールドアウトセットで現在のchampionを下回るスコアだった場合にビルドを失敗させるモデル品質ゲートです。したがって、MLの継続的デリバリーは、単なるコンテナイメージではなくモデルのアーティファクトを昇格させ、昇格ゲートはグリーンなテストスイートだけではなくメトリクスのしきい値になります。厳密なパイプラインでは、データのスナップショットと依存関係のバージョンも固定し、どの再実行も決定論的になるようにします。これこそが、再現可能なビルドと、たまたま今日通っただけのビルドを区別するものです。

監視、データドリフト、モデルの再学習

デプロイされたモデルは、その足元で世界が変化するにつれて劣化するため、監視に関する質問こそがシニアとしてのシグナルが現れる場面です。

Q8: データドリフトはどのように検知され、どのメトリクスがそれを定量化しますか?

データドリフトとは、本番環境の入力の分布が学習時の分布から離れてしまうことを意味します。Population Stability Index(PSI)は、一般的でフレームワークに依存しない指標です。参照分布をビンに分割し、本番環境の頻度をそれらのビンと比較し、重み付けされた対数差を合計します。

# population_stability_index.py
import numpy as np

def psi(reference, production, bins=10):
    # Bin edges come from the reference (training) distribution
    edges = np.quantile(reference, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf

    ref_pct = np.histogram(reference, edges)[0] / len(reference)
    prod_pct = np.histogram(production, edges)[0] / len(production)

    # Clip to avoid division by zero and log(0)
    ref_pct = np.clip(ref_pct, 1e-6, None)
    prod_pct = np.clip(prod_pct, 1e-6, None)

    return float(np.sum((prod_pct - ref_pct) * np.log(prod_pct / ref_pct)))

# PSI < 0.1 stable | 0.1-0.25 moderate shift | > 0.25 major drift, investigate
score = psi(reference_scores, production_scores)

自作の指標にとどまらず、本番環境のチームはEvidentlyのようなツールを用いて、特徴量ドリフト、ターゲットドリフト、データ品質を定期的に追跡します。完全な回答は、データドリフト(入力が変化する)とコンセプトドリフト(入力と出力の関係が変化する)を区別します。というのも、後者は入力を監視するだけでは捉えられず、ラベル付けされた結果を必要とするからです。

Q9: 再学習パイプラインは何によってトリガーされるべきですか?

一定の周期で行う時間ベースの再学習は最も単純な選択肢ですが、何も変わっていないときには計算資源を無駄にし、何かが壊れたときには反応が遅くなります。より優れたトリガーはメトリクスベースのものです。PSIがしきい値を超えたとき、実際の評価メトリクスが下限を下回ったとき、あるいは新たにラベル付けされたデータに対する定期的なバックテストが悪化したときに再学習します。再学習ジョブはその後challengerを登録し、カナリアのロールアウトがエイリアスを付け替える前に、それを現在のchampionと比較します。

MLOpsのシステム設計に関する面接質問

Q10: 一貫した特徴量で数百のモデルをサービングするプラットフォームを設計してください。

期待される中心的な要素は特徴量ストア(feature store)です。これは特徴量を一度だけ計算し、同一の値を学習と推論の両方に提供することで、学習・サービング間のスキュー(training-serving skew)を解決します。Feastのようなツールは、学習用のオフラインストアと、サービング用の低レイテンシなオンラインストアを提供します。完全な設計では、バージョン管理のためのモデルレジストリ、リネージのためのトラッキングサーバー、パイプラインのためのオーケストレーター、そして再学習へとループを閉じる監視レイヤーも挙げられます。この特徴量エンジニアリングの面接ガイドで扱われているようなトレードオフなど、実際の特徴量に関する作業に回答を根ざさせることで、図を暗記したのではなく実践的な経験があることを示せます。

まとめ

• MLOpsを、DevOpsにデータとモデルのバージョン管理を加えたものとして捉えましょう。再現性、昇格の安全性、監視が、面接官が評価する3つの軸です
• MLflow 3.xのAPIの変化を把握しましょう。エイリアスとタグが非推奨のStagingおよびProductionステージを置き換え、log_modelはartifact_pathではなくnameを取るようになりました
• デプロイパターンをレイテンシバジェットに合わせ、モデルのロールアウトではブルーグリーンよりもカナリアを既定としましょう。品質の問題は実際の入力に対してしか現れないからです
• PSIのような具体的な指標でドリフトを定量化し、データドリフトとコンセプトドリフトを区別しましょう。ラベルなしで見えるのは一方だけだからです
• 再学習をカレンダーではなくメトリクスでトリガーし、生まれたchallengerをchampionエイリアスの付け替え前にカナリアを通して検証しましょう
• システム設計のどの回答でも特徴量ストアを挙げ、学習・サービング間スキューのギャップを、追加質問として指摘される前に埋めましょう