§5 ML パイプラインの自動化とオーケストレーション
E2E パイプライン構築、再訓練の自動化、CI/CD/CT。比重 ~18%。MLOps の心臓部。
このセクションの結論
ML パイプラインは Pipelines、ETL+ML は Managed Airflow、
分散 ML/RL は Ray on Agent Platform 🆕、軽量 API は Workflows。
MLOps Level 2 は CI/CD/CT が全部回る状態。
🌳 オーケストレータ選定
何を動かす？
├─ ML パイプライン専用（KFP / TFX）
│ → Agent Platform Pipelines（第一候補・サーバーレス）
├─ ETL + ML / 複雑な依存 / 既存 Airflow 資産
│ → Managed Service for Apache Airflow（旧 Cloud Composer）
├─ 分散 ML / 強化学習 / 大規模ハイパラチューニング
│ → Ray on Agent Platform 🆕
└─ 軽量 API 呼び出し / 数ステップのフロー
→ Cloud Workflows
| Pipelines | Managed Airflow | 🆕 Ray | Workflows | |
|---|---|---|---|---|
| 主用途 | ML パイプライン | ETL+ML/汎用 | 分散 ML / RL | 軽量 API |
| 言語 | Python (KFP v2) | Python (Airflow) | Python (Ray API) | YAML |
| サーバーレス | ◎ | ◎ | ○ | ◎ |
| 系統管理 (lineage) | ◎ (ML Metadata) | △ | △ | × |
| 第一候補 | ML 専用 | ETL+ML、既存資産 | RL/HPT/分散 | API 連携 |
名前のひっかけ
「Cloud Composer」の新名称は Managed Service for Apache Airflow。
Cloud Workflows は別物（YAML 軽量オーケストレーション）。
🔗 典型的なパイプライン構成
[1. データ取り込み]
↓
[2. データ検証] (TFDV: スキーマ/統計/異常)
↓
[3. 前処理・特徴量化] (TFT / Feature Store)
↓
[4. 訓練]
↓
[5. 評価] (TFMA)
↓
[6. モデル検証] (vs baseline、SLO 合格判定)
↓
[7. Model Registry に登録]
↓
[8. 推論基盤にデプロイ] (カナリア → 本番)
↓
[9. モニタリング] (ドリフト / 精度劣化)
↓ (劣化検知)
[再訓練トリガー]
✅ データとモデルの検証
TFDV (Data Validation)
ベースラインのスキーマと統計を出力。新規データの統計と比較してアノマリー検出（欠損率急変、新規カテゴリ、分布変化）。
TFMA (Model Analysis)
スライス別評価（地域・年齢層 etc.）、公平性メトリクス、ベースライン比較。"前バージョン以下ならデプロイ阻止" の合格判定に使う。
🔁 訓練/サービング前処理の一貫性
| アプローチ | 仕組み | 強み |
|---|---|---|
| TFT (TF Transform) | 訓練時に Transform graph 出力、推論時に再利用 | TF エコシステムで完結 |
| Feature Store | 中央保管、訓練/推論で同じ取得経路 | フレームワーク非依存 |
🔄 再訓練ポリシー
スケジュール
日次/週次/月次。データが安定 + 緩やか
データ量閾値
新規 N 件以上で起動
データドリフト検知
Model Monitoring → Pub/Sub → 自動再訓練
精度劣化
評価メトリクス閾値割れ
ビジネスイベント
季節要因、キャンペーン
オンデマンド
手動、緊急
推奨
スケジュール + ドリフト検知 のハイブリッドが定石。
🏗 MLOps 成熟度モデル
| Level | 名称 | 特徴 |
|---|---|---|
| 0 | 手動 | ノートブック手動実行、人手でデプロイ |
| 1 | ML パイプライン自動化 | パイプラインで自動訓練・自動デプロイ |
| 2 | CI/CD パイプライン自動化 | コード変更でパイプライン自体も自動更新 + CT |
⚙ CI/CD/CT パイプライン構成
[ Source Repo (Git) ]
│ (push to main)
▼
[ Cloud Build trigger ]
│
├─ ① CI: テスト
│ - Unit test / データバリデーション小規模 / 静的解析
│
├─ ② Container Build
│ - 訓練コードコンテナ化 → Artifact Registry
│
├─ ③ Pipeline Compile & Submit
│ - KFP コンパイル → Pipelines に submit
│
└─ ④ CT: 訓練 → 評価 → モデル検証 → Registry → CD (canary)
│
└─ 失敗 → アラート / 旧モデル維持
⚠️ 試験での頻出ひっかけ
| シナリオ | 不正解 | 正解 |
|---|---|---|
| "ML パイプラインを K8s 管理なしで" | GKE 自前構築 | Agent Platform Pipelines |
| "複雑な ETL + ML を 1 つのオーケストレータで" | Pipelines | Managed Service for Apache Airflow |
| "RL で並列ロールアウト" | Pipelines / Airflow | Ray on Agent Platform |
| "軽量な API オーケストレーション" | Pipelines | Cloud Workflows |
| "Cloud Composer の新名称は？" | そのまま | Managed Service for Apache Airflow |
| "訓練/推論の前処理 skew で精度低下" | 手動同期 | TFT or Feature Store |
| "データ品質を訓練前に自動検証" | スキップ | TFDV を Pipelines に組み込み |
| "モデル評価が前バージョン以下ならデプロイ阻止" | 強行 | モデル検証ステップで条件分岐 |
| "ドリフト応じた自動再訓練" | スケジュールのみ | Model Monitoring → Pub/Sub → Pipelines |
| "コード push で自動再訓練" | 手動 submit | Cloud Build + Pipelines (CI/CD/CT) |
| "失敗ステップだけ再走" | 全体再実行 | KFP v2 キャッシュ + 部分再実行 |
📝 セルフチェック（6 問）
Q1
ML 専用のパイプラインをサーバーレスで動かしたい。最適は？
正解: A。
Q2
ETL + ML を同じオーケストレータで管理し、既存 Airflow DAG 資産を移行したい。
正解: B。
Q3 🆕 新ガイド
強化学習や大規模 HPT の分散実行に最適なサービスは？
正解: B。
Q4
モデル評価で前バージョン以下ならデプロイ阻止したい。設計は？
正解: A。
Q5 複数選択
データドリフト検知に応じた自動再訓練 (CT) の必要要素 2 つ：
正解: A, B。
Q6
MLOps Level 2 の特徴は？
正解: C。