🎓 レベル：標準 | 重要度：A（必須）
📎 前提：MLパイプラインの全体設計 | 関連：再学習と継続的トレーニング（CT）
要点（BLUF）
- 成熟度モデルは「MLライフサイクルのどこまでを自動化・再現化できているか」を段階で測る物差しです。Google は3段階（L0/L1/L2）、Microsoft Azure は5段階（L0〜L4）で表します。
- 共通の軸は自動化の範囲：手作業 → 学習パイプラインの自動化（継続的トレーニング CT）→ CI/CD によるパイプライン自体の自動デプロイ、と段階的に上がります。
- 大事なのは「最高段階を目指すこと」ではなく「今の現在地を正しく測り、ボトルネックの1段階だけ上げる」こと。L0 でいきなり L2 を狙うと運用が破綻します。
1. なぜ成熟度を測るのか
MLOps の改善は「何でも自動化すればよい」ではありません。再現性が無いまま自動化すると、壊れたものを高速に量産するだけです。成熟度モデルは「次に手を付けるべき1段階」を見極めるための診断ツールです。現在地を測り、最も効くボトルネックを1つずつ解消します。
2. Google の3段階モデル
| レベル | 名前 | 何が自動化されているか | ボトルネック |
|---|---|---|---|
| L0 | 手作業プロセス | 何もない。ノートブックで手動学習・手動デプロイ | デプロイが稀・再現困難 |
| L1 | MLパイプライン自動化 | 学習パイプラインが自動。継続的トレーニング（CT）で新データに自動再学習 | パイプライン自体の更新は手動 |
| L2 | CI/CD パイプライン自動化 | パイプライン自体を CI/CD で自動ビルド・テスト・デプロイ。新しい実装が高速に本番へ | 組織・ガバナンスの整備 |
L0→L1 の鍵は「学習を再現可能なパイプラインにし、トリガーで自動再学習できる」こと（再学習と継続的トレーニング（CT））。L1→L2 の鍵は「パイプラインのコードを変えたら、自動テストを通って自動デプロイされる」こと（MLパイプラインのオーケストレーションとCI/CD/CT）。
3. Microsoft の5段階モデル
| レベル | 名前 | 状態 |
|---|---|---|
| L0 | No MLOps | 完全手作業。再現性なし |
| L1 | DevOps but no MLOps | コードはCI/CDだが、データ・モデルは手動 |
| L2 | Automated Training | 学習が自動化・再現可能。手動リリース |
| L3 | Automated Deployment | テスト→本番へモデルが自動デプロイ。監視が稼働 |
| L4 | Full MLOps | 監視→自動再学習→自動再デプロイが閉じたループに |
Google の3段階を細かく刻んだものと見ると対応が取れます：Google L0 ≒ MS L0-1、Google L1 ≒ MS L2-3、Google L2 ≒ MS L4。
flowchart LR L0["L0 手作業（再現性なし）"] --> L1["L1 学習パイプライン自動化（CT）"] L1 --> L2["L2 パイプラインをCICDで自動デプロイ"] L2 --> L3["L3 監視と自動再学習で閉ループ"]
4. 動く最小例：チェックリストから成熟度スコアを出す
成熟度は感覚で語らず、能力（capability）の有無で測ります。代表的な能力をチェックリスト化し、達成段階を判定します。
# 各能力：True=できている。段階ごとに「その段階に必要な能力」を定義
capabilities = {
"コードがバージョン管理されている": True,
"データがバージョン管理されている": True,
"学習が再現可能なパイプライン": True,
"新データで自動再学習できる(CT)": True,
"本番モデルを監視している": True,
"パイプライン自体がCICDで自動デプロイ": False,
"ドリフト検知で自動再学習が起動": False,
}
levels = {
"L0 手作業": ["コードがバージョン管理されている"],
"L1 再現可能な学習": ["データがバージョン管理されている", "学習が再現可能なパイプライン"],
"L2 継続的トレーニング": ["新データで自動再学習できる(CT)", "本番モデルを監視している"],
"L3 CICD自動化": ["パイプライン自体がCICDで自動デプロイ"],
"L4 完全自動ループ": ["ドリフト検知で自動再学習が起動"],
}
achieved = "未達(L0未満)"
for name, required in levels.items():
if all(capabilities[c] for c in required):
achieved = name
else:
break # 連続して満たした最上位までが現在地
n_done = sum(capabilities.values())
print(f"達成能力数 : {n_done} / {len(capabilities)}")
print(f"現在の成熟度 : {achieved}")
print(f"次の一手 : 「パイプライン自体がCICDで自動デプロイ」を満たすとL3へ")出力：
達成能力数 : 5 / 7
現在の成熟度 : L2 継続的トレーニング
次の一手 : 「パイプライン自体がCICDで自動デプロイ」を満たすとL3へ出力の意味：能力は段階順に積み上がるので、「連続して満たした最上位」が現在地になります。この組織は L2（継続的トレーニングまで自動）で、次のボトルネックは「パイプライン自体の CI/CD 化」だと一意に決まりました。成熟度は飛び級できない——下の段階の能力が欠けたまま上を実装しても機能しません。
5. 運用の勘所
- 1段階だけ上げる：L0 から L4 を一気に狙わない。直近のボトルネック1つを潰す。
- 再現性が全段階の土台：再現性とバージョニングができていないと、どの自動化も信頼できない。
- 段階に応じて投資配分を変える：L0-1 はパイプライン化に、L2-3 は監視と自動デプロイに、L4 は閉ループのガバナンスに投資する。
- 過剰な自動化を避ける：モデルを年1回しか更新しないなら、L4 のフル自動ループは過剰投資。頻度に見合う段階を選ぶ。
なぜそうするのか
成熟度モデルを使うのは、改善を「気分」でなく「診断」で進めるためです。自動化は手段であって目的ではありません。再現性のない L0 でいきなり自動デプロイ（L2）を入れると、壊れたモデルを高速に本番へ流すだけになります。段階を測ることで、投資対効果の高い「次の1段階」が一意に決まります。
⚠️ よくある落とし穴
- 段階を飛ばす：再現性（下段）抜きの自動化（上段）は、壊れたものの量産。
- 「ツールを入れた＝成熟度が上がった」と錯覚する：MLflow や Kubeflow を入れても、再現可能なパイプラインとして運用していなければ段階は上がらない。
- 全社一律の段階を目指す：プロダクトごとに適切な成熟度は違う。更新頻度・リスクで決める。
- L4 を常に正解とみなす：完全自動ループは運用コストも高い。必要十分な段階を選ぶ。
対応 lab
- なし（概念ノート）。成熟度チェックリストは本文 §4 に同梱。
関連ノート
- MLパイプラインの全体設計（L1 の中身）
- 再現性とバージョニング（全段階の土台）
- 再学習と継続的トレーニング（CT）（CT＝L1-L2 の核）
- MLパイプラインのオーケストレーションとCI/CD/CT（L2-L3 の核）
- 第1章 MLOpsの全体像 目次
- MLOps・AI基盤 全体目次