ちゅらデータ株式会社Publicationへの投稿
🚀

【24日目】MLOps パイプラインの構築 〜 モデルを育て、届け、改善し続ける仕組みを Databricks で実現する 〜

クルトン
に公開
MLflow
CI/CD
Databricks
MLOps
modelserving
tech

みなさんこんにちは、クルトンです！

Day23では Delta Sharing を通して、Databricksが安全に“外へ共有する力”を持っていることを整理しました。

そして今日のDay24は、モデルを作る → 提供する → 監視する → 改善する というサイクルを自動で回す「MLOps」の世界へ踏み込みます。

DatabricksではMLflowを中心にModel Serving、Monitoring、CI/CD、Jobs(Lakeflow)といった仕組みが連携し、 継続的で高品質なモデル運用を支える強力なプラットフォーム が整っています。

本日はこれらを整理していきます！

🧭 MLOpsとは？まずは全体像を掴んでみよう

MLOpsとは、機械学習モデルを 開発 → 本番提供 → 監視 → 改善 という流れで継続的に運用するための仕組みのことです。

一般的に問題となりやすいのが……

  • モデルの精度が徐々に低下する
  • 開発者ごとに管理方法がバラバラ
  • 手動デプロイで人為的ミス発生
  • 本番環境の状態が見えない

といった課題です。

DatabricksではMLflowを中心に、以下のような流れでMLOpsを実現します。

全体をザッと捉えたところで、各要素を詳しく見ていきましょう！

🔬 MLflow Tracking：実験管理の基盤

Databricks公式(tracking, experiments, runs)：
https://docs.databricks.com/aws/ja/mlflow/tracking
https://docs.databricks.com/aws/ja/mlflow/experiments
https://docs.databricks.com/aws/ja/mlflow/runs

MLflow Trackingは、モデル開発時に行う “実験管理” を担います。

✔ Experiment（実験）

モデル開発をまとめるフォルダのようなものです。

  • あらゆるRunをグルーピング
  • 見比べやすくする
  • チーム開発でも一貫性を保てる

✔ Run（学習の1セッション）

  • 入力パラメータ
  • メトリクス(精度、損失など)
  • 生成されたアーティファクト(モデルファイルなど)

が記録されます。

✔ Autologging（自動記録）

MLflowが自動でパラメータ・メトリクス・モデルを記録してくれる仕組みです。

これにより、「どの条件でどのモデルが良かったか」を追跡できるようになります。

🧱 Model Registry：モデルのライフサイクル管理

Databricks公式(モデルのライフサイクル)：
https://docs.databricks.com/aws/ja/machine-learning/manage-model-lifecycle
https://docs.databricks.com/aws/ja/machine-learning/manage-model-lifecycle/workspace-model-registry
https://docs.databricks.com/aws/ja/mlflow/model-registry-webhooks

MLflow Model Registryは、学習したモデルをまとめて保管する場所です。
(2025年時点では、新規プロジェクトではUnity Catalog配下のモデルレジストリ利用が推奨されており、Workspace Model Registryは既存ワークスペース向けの位置づけになっています。)

✔ Model Version（モデルの版管理）

学習を行うたびに “v1, v2, v3…” とバージョンが作られます。

✔ Stage（モデルの段階）

代表的なStageとしては以下です。

  • None（登録直後）
  • Staging（検証段階）
  • Production（本番稼働）

✔ Promotion（昇格）

Stagingのモデルをテストした後、Productionに昇格させる流れが一般的です。
(つまり動作チェックした後に本番に活用するという流れですね。)

✔ Webhooks（自動化の起点）

モデルが登録・更新されたタイミングで外部サービスに通知できます。

これが CI/CDのトリガー となります。

⚙️ Model Serving：モデルを本番で使えるようにする

Databricks公式(Model Servingについて)：
https://docs.databricks.com/aws/ja/machine-learning/model-serving
https://docs.databricks.com/aws/ja/machine-learning/model-serving/create-manage-serving-endpoints
https://docs.databricks.com/aws/ja/machine-learning/model-serving/manage-serving-endpoints
https://docs.databricks.com/aws/ja/machine-learning/model-serving/foundation-model-overview

Model Servingは、学習したモデルを リアルタイムで呼び出せる形にするための仕組み です。
(LLMを含むモデルを、REST APIとして一貫した形で提供できます。)

✔ Serving Endpointの基本

  • APIとしてモデルを公開
  • Endpoint単位で管理
  • モデルの更新はバージョン切替で簡単に行える

✔ モデル更新（ロールアウト）

  • 新しいモデルバージョンを登録
  • Endpointに反映
  • 必要に応じて段階的に切り替え

MLflow Registryと密接に連携しています。

✔ Foundation Model（LLM）の提供にも対応

Day16・Day20などで触れたLLM基盤と同じServingに統合されているため、Databricks上で統一的に扱えます。

📊 Monitoring：モデルの状態を見る

Databricks公式(Monitoring関連)：
https://docs.databricks.com/aws/ja/machine-learning/model-serving/monitor-diagnose-endpoints
https://docs.databricks.com/aws/ja/machine-learning/model-serving/inference-tables
https://docs.databricks.com/aws/ja/data-quality-monitoring
https://docs.databricks.com/aws/ja/mlflow3/genai/eval-monitor/production-monitoring

モデルは一度作ったら終わりではありません。時間が経つと精度が下がったり入力データが変化したりしますので、モデルの状態を見続け改善していく必要があります。

✔ Endpoint Monitoring

  • エラー率
  • レイテンシ
  • スループット

など、Endpointの健康状態が確認できます。

✔ Inference Tables（推論ログ）

推論時の入力・出力をDeltaテーブルで管理できます。

これが後述の 再学習サイクルの起点 になります。

✔ ドリフト検知・評価指標

  • データドリフト
  • 予測ドリフト
  • バイアス検知(必要に応じて)

Databricksでは、

  • Endpointのメトリクス
  • Inference Tables
  • Data Quality Monitoring
  • MLflow 3のProduction Monitoring

などを組み合わせることで、ドリフトや品質劣化を検知する設計ができます。
こうした監視結果をもとに、次のアクションを決めていきます。

🔁 再学習サイクル（Retraining）で改善し続ける

Databricks公式(ワークフローについて)
https://docs.databricks.com/aws/ja/machine-learning/manage-model-lifecycle/upgrade-workflows

モデル品質を維持するためには、監視 → 再学習 → 更新 という流れが必要です。

✔ 再学習の流れ

  1. Monitoringで異常や精度低下を検知
  2. 再学習ジョブを起動
  3. 新しいモデルがRegistryに保存
  4. Stagingで検証
  5. 問題なければProductionに昇格
  6. Serving Endpointを更新

🔧 CI/CD：モデルを自動で更新する仕組み

Databricks公式(CI/CD関連)：
https://docs.databricks.com/aws/ja/machine-learning/mlops/ci-cd-for-ml
https://docs.databricks.com/aws/ja/machine-learning/mlops/deployment-patterns
https://docs.databricks.com/aws/ja/mlflow/model-registry-webhooks
https://docs.databricks.com/aws/ja/dev-tools/bundles/mlops-stacks

CI/CDを導入すると、モデル更新の品質とスピードが一気に向上します。

✔ Git（Repos）とMLflowの連携

  • Notebook・PythonモジュールをGit管理
  • Pull Requestベースで品質担保

✔ 自動テスト → 自動デプロイ

  • WebhooksでCIを起動
  • テスト環境(Staging)で検証
  • 問題なければProductionへPromote

✔ Asset BundlesによるIaC化

  • 構成をYAMLとコードで管理
  • “環境差分がない” 安定したMLOpsを実現

⚙️ Workflow（Lakeflow / Jobs）でパイプラインを自動化

Databricks公式(Lakeflowジョブ)：
https://docs.databricks.com/aws/ja/jobs

Lakeflow（Jobs） を使うことでパイプラインの自動化ができます。

✔ 再学習パイプラインの例

  • 特徴量抽出(Feature Store)
  • モデルトレーニング
  • モデル登録
  • モデル昇格
  • Endpoint更新
  • モニタリングチェック

Databricks では、この一連の流れを すべて自動化できる のが強みです。

🧩 今日のまとめ

  • MLOpsは「作って終わり」ではなく「継続的に改善し続ける仕組み」
  • MLflow Trackingで実験管理
  • Registryでモデルのバージョン・ステージ管理
  • Servingで本番提供
  • Monitoringで状態を監視
  • 再学習サイクルで品質改善
  • CI/CDやLakeflowを組み合わせて自動化を実現

DatabricksはこのMLOps サイクルを プラットフォーム全体で統合的に支えてくれる のが魅力なサービスですね。

📚 参考URL

✨ 終わりに

Day24では、モデルを“育て続ける”ためのDatabricksのMLOpsを整理してきました。

明日の Day25（最終日） は、Databricksの発展的トピックにどのようなものがあるか、ここまでのDay24までのブログ内容をどう確認していくと良いのか についてまとめていきます！

本日はここまで。
それではまた明日！

ちゅらデータ株式会社
ちゅらデータ株式会社Publication

沖縄に「最高に面白い仕事」を作る IT ベンチャーです！ エンジニア積極採用中！！

Discussion