株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
MLOps成熟度モデルとは
MLOps成熟度モデルは、組織の機械学習運用の能力や不足を整理するフレームワークです。自動採点で唯一のレベルが決まるものではなく、人・プロセス・技術の状態を確認することで、「次に何に投資すべきか」を合理的に判断できます。
本記事では、Google Cloudの3段階モデルとMicrosoftの5段階モデルを解説し、改善アクションを提示します。両者のレベル番号は同じ意味ではありません。後半のチェックリストと優先順位はMicrosoftの番号を参考にした本記事の整理で、公式の認定基準ではありません。
Google Cloudの3段階モデル
Level 0: 手動プロセス
データ準備・モデル学習・評価・デプロイがすべて手動で行われる段階です。Jupyter Notebookで実験し、学習済みモデルを手動でサーバーにコピーする運用が典型的です。
特徴: Notebookやスクリプトの手動実行、工程間の手動引き継ぎ、CI/CDや継続的な性能監視の不足。ソース管理があっても、この段階に該当する場合がある（Google Level 0の説明）。
Level 1: MLパイプラインの自動化
データ取得→前処理→学習→評価→デプロイをパイプライン化し、CT（Continuous Training）を可能にする段階です。データとモデルの自動検証、実行トリガー、メタデータ管理を整え、必要に応じて新しいデータで再学習します（Google Level 1）。
特徴: パイプラインの自動実行・データ/モデル検証・学習履歴の管理。Feature Storeは追加できる任意の部品であり、Level 1の必須条件ではない
Level 2: CI/CDパイプラインの自動化
パイプラインのコード自体もCI/CDの対象となり、パイプラインの変更がテスト→ビルド→デプロイの自動プロセスを経る段階です。コードのバージョン管理とテストを組み合わせ、パイプラインの変更を継続的に検証します。バージョン管理だけで品質が保証されるわけではありません。
特徴: パイプライン構成要素のテスト・CI/CD・モデル配備と監視。ロールバックの自動化や承認方法は運用要件に応じて設計する（Google Level 2）
Microsoft Azureの5段階モデル
Level 0: No MLOps（手動管理）
学習・テスト・リリースが手動で、実験や性能の追跡も十分に統一されていない段階です。手動中心という点はGoogle Level 0と共通しますが、両モデルの評価観点や細部は同じではありません（Microsoft Level 0）。
Level 1: DevOps but No MLOps
アプリケーションのコード管理、ビルド、テスト、リリース等の自動化が進む一方、モデルのリリースは手動で、実験結果の追跡や再現性が不十分な段階です。データ収集の自動化や推論スクリプトのバージョン管理がある場合も含まれます（Microsoft Level 1）。
Level 0→1の移行: Git導入・コードレビュー・基本的なCI（リンティング・テスト）の整備
Level 2: Automated Training（学習の自動化）
学習が自動化され、実験結果の追跡、学習コード・モデルのバージョン管理、実行環境の管理が行われる段階です。モデルのリリースはまだ手動です。MLflow等は実装の選択肢であり、特定製品の導入そのものが段階の定義ではありません（Microsoft Level 2）。
Level 1→2の移行: MLflow導入・学習スクリプトのパイプライン化・データバージョニング
Level 3: Automated Model Deployment（デプロイの自動化）
モデル配備が自動化され、配備したモデルから元のデータまで追跡できる段階です。学習・テスト・本番の環境を管理し、レジストリを使ったモデルの受け渡しや検証を整備します（Microsoft Level 3）。
Level 2→3の移行: Model Registry導入・デプロイパイプライン構築・A/Bテスト基盤
Level 4: Full MLOps Automated Operations
本番の性能指標やドリフトを監視し、その情報を再学習・テスト・モデル更新につなげる段階です。検証結果や運用方針に基づく自動更新を整備します。自動ロールバックは個別の実装設計であり、単独で成熟度を決める条件ではありません（Microsoft Level 4）。
Level 3→4の移行: モニタリングダッシュボード・ドリフト検知→再学習トリガー・SLO定義
自社の成熟度を診断するチェックリスト
以下は不足を探すための簡易チェックです。「はい」が一つあるだけでそのLevelを達成したと判定せず、人の連携、再現性、テスト、監視等を合わせて確認します。Microsoftの説明でも、複数レベルの特徴が組織内に混在し得るとしています。
| 診断項目 | 主に参照するMicrosoftのLevel |
|---|---|
| モデルのコードがGit管理されているか | 1の要素 |
| 実験のパラメータ・メトリクスが記録されているか | 2の要素 |
| 学習パイプラインが自動実行できるか | 2の要素 |
| モデルのバージョンをレジストリ等で管理しているか | 2以降の要素 |
| 本番デプロイが自動化されているか | 3の要素 |
| データドリフトを自動検知しているか | 4に関わる確認項目 |
| ドリフト検知→再学習が自動トリガーされるか | 4に関わる確認項目 |
レベルアップの優先順位
以下はMicrosoftの番号に沿った改善案です。移行期間は対象モデル数、既存基盤、担当者の経験、審査・検証の範囲を洗い出して見積もります。ツール名やカナリア配信の割合は実装例で、公式モデルの一律の要件ではありません。
Level 0→1: まずGitとテストを整備する（既存のコード管理・CIを確認）
MLOpsの改善を進める際は、コード変更を追跡し、検証するためのソフトウェアエンジニアリング基盤を整えることが重要です。まずコードのGit管理・CI（リンティング・テスト）・コードレビューを整備します。
Level 1→2: 実験管理と学習パイプライン（対象の実験・データを整理）
MLflow Trackingを導入し、全実験を記録可能にします。次にNotebookからスクリプトに移行し、学習パイプラインをコード化します。これにより「実験の再現性」と「チーム間の知識共有」の改善を狙います。ROIは、実験のやり直しや引き継ぎにかかる時間がどれだけ減るかを、導入・運用費と比較して評価します。
Level 2→3: デプロイの自動化（検証・承認・切戻しを設計）
モデルの検証完了や承認を受けて、配備先とバージョンを明示した自動デプロイパイプラインを動かします。MLflowでは固定のModel Stages（Staging/Production等）は2.9.0から非推奨で、タグ・エイリアス・環境ごとの登録モデルを使う移行方法が案内されています。エイリアスの更新だけで配備が自動実行されるわけではなく、配備処理を別途接続します。カナリアデプロイは、例えば10%のトラフィックから検証する方法ですが、割合・判定指標・切戻し条件はリスクに合わせて決めます（公式のStages移行ガイド）。
Level 3→4: モニタリングと自動再学習（更新頻度と運用体制で判断）
この段階への投資は、更新頻度、変化の速さ、誤予測の影響、運用費から判断します。日次・週次等の頻繁な更新や、データ変化への迅速な対応が必要なECレコメンド等は検討対象ですが、頻度だけで採算は決まりません。再学習後の品質検証、承認・切戻し、継続監視の体制まで含めて評価します（再学習トリガーと頻度の考え方）。
導入時に確認したい成熟度の課題
- Level 0-1の確認: PoCの評価に加え、本番に必要な検証・配備・性能監視・担当者間の引き継ぎを計画する
- Level 2への準備: Notebookでの実験を、再実行できるスクリプトやジョブへ整理し、データ・学習条件・結果を追跡する
- Level 4への投資判断: ツール一式の導入を目的にせず、現在不足する能力と運用体制を確認し、段階的に投資する
以上は特定企業で起きた事例ではなく、Google・Microsoftの公開資料に基づく確認の観点です。renueでは「まずLevel 2を確実に」を推奨しています。実験管理と学習パイプラインの自動化だけでも大きな効果が見込めます（効果は条件により異なります）。その上で、ビジネス要件に応じてLevel 3以上を段階的に投資する判断が合理的です。
まとめ
MLOps成熟度モデルは「ゴール」ではなく「現在地の把握と次の一手の判断ツール」です。Level 4が全組織の正解ではありません。自社のモデル更新頻度・チーム規模・ビジネスインパクトに応じて、適切なレベルを目指しましょう。
関連記事
- MLOpsとは？機械学習の本番運用 総合ガイド
- MLOpsツール比較2026 — MLflow・Kubeflow・SageMaker・Vertex AI
- MLOps CI/CDパイプライン構築 実装ガイド
- MLOps入門 — 最初にやるべき5ステップ
よくある質問（FAQ）
Q. 成熟度Level 4を目指すべき企業はどんな企業ですか？
A. 日次・週次等の頻繁なモデル更新や、データ変化への迅速な対応が必要な事業（ECレコメンド、広告最適化、不正検知等）は検討対象です。ただし更新頻度は一律の足切り条件ではなく、誤予測の影響、評価・監視体制、導入・運用費を合わせて判断します（再学習頻度の考え方）。
Q. GoogleとMicrosoftのモデル、どちらを使うべきですか？
A. Microsoftの5段階モデルは人・モデル作成・リリース・アプリへの統合等を整理し、Googleの3段階モデルはMLパイプラインとCI/CDの自動化を中心に説明します。自社が確認したい観点に合わせて使い分け、両者のLevel番号を同一視しないことが重要です（Microsoft、Google）。
Q. 成熟度の評価は誰がやるべきですか？
A. MLエンジニア・データサイエンティスト・エンジニアリングマネージャー等で共同評価する方法があります。業務責任者、運用、セキュリティ、データ管理の担当も必要に応じて加え、技術面と組織面の不足を確認します。