implementing-mlops

MLOps パターン

実験から本番環境へのデプロイ、監視まで、機械学習モデルを運用します。

目的

ML エンジニアとプラットフォームチームが、本番環境に対応した ML インフラストラクチャを構築するための戦略的なガイダンスを提供します。実験追跡、モデルレジストリ、フィーチャーストア、デプロイパターン、パイプラインのオーケストレーション、監視を含む、ライフサイクル全体をカバーします。

このスキルを使用するタイミング

次のような場合にこのスキルを使用します。

• 本番環境の ML システム向けに MLOps インフラストラクチャを設計する
• 実験追跡プラットフォーム（MLflow、Weights & Biases、Neptune）を選定する
• オンライン／オフラインの特徴量サービング向けにフィーチャーストアを実装する
• モデルサービングソリューション（Seldon Core、KServe、BentoML、TorchServe）を選定する
• トレーニング、評価、デプロイ向けの ML パイプラインを構築する
• モデル監視とドリフト検出を設定する
• モデルガバナンスとコンプライアンスのフレームワークを確立する
• ML 推論のコストとパフォーマンスを最適化する
• ノートブックから本番環境の ML システムへ移行する
• 継続的なトレーニングと自動再トレーニングを実装する

コアコンセプト

1. 実験追跡

再現性と共同作業を確保するため、実験を体系的に追跡します。

主なコンポーネント：

• パラメーター：各トレーニング実行で記録されるハイパーパラメーター
• メトリクス：時間経過に伴って追跡されるパフォーマンス指標（精度、損失、F1）
• アーティファクト：モデルの重み、プロット、データセット、設定ファイル
• メタデータ：タグ、説明、Git コミット SHA、環境の詳細

プラットフォームの比較：

MLflow（オープンソースの標準）：

• フレームワークに依存しません（PyTorch、TensorFlow、scikit-learn、XGBoost）
• セルフホスト型、またはクラウドに依存しないデプロイ
• モデルレジストリを統合
• 基本的な UI を備え、ほとんどのユースケースに十分です
• 無料ですが、インフラストラクチャの管理が必要です

Weights & Biases（SaaS、コラボレーション重視）：

• 高度な可視化とダッシュボード
• ハイパーパラメーター最適化（Sweeps）を統合
• 優れたチームコラボレーション機能
• SaaS の料金は使用量に応じて変動します
• クラス最高の UI

Neptune.ai（エンタープライズグレード）：

• エンタープライズ機能（RBAC、監査ログ、コンプライアンス）
• 本番環境の監視を統合
• W&B より高コスト
• 規制の厳しい業界に適しています

選定基準：

• オープンソースが必須 → MLflow
• チームコラボレーションが重要 → Weights & Biases
• エンタープライズコンプライアンス（RBAC、監査） → Neptune.ai
• ハイパーパラメーター最適化を最優先 → Weights & Biases（Sweeps）

詳細な比較と選定フレームワークについては、references/experiment-tracking.md を参照してください。

2. モデルレジストリとバージョン管理

バージョン管理とステージ管理を備えたモデルアーティファクトを一元化します。

モデルレジストリのコンポーネント：

• モデルアーティファクト（重み、シリアライズ済みモデル）
• トレーニングメトリクス（精度、F1、AUC）
• トレーニングで使用したハイパーパラメーター
• トレーニングデータセットのバージョン
• 特徴量スキーマ（入出力シグネチャ）
• モデルカード（ドキュメント、ユースケース、制限事項）

ステージ管理：

• None：新規登録されたモデル
• Staging：本番前環境でテスト中
• Production：本番トラフィックを処理中
• Archived：非推奨。コンプライアンスのために保持

バージョン管理戦略：

モデルのセマンティックバージョニング：

• メジャーバージョン（v2.0.0）：入出力スキーマに対する破壊的変更
• マイナーバージョン（v1.1.0）：新機能、後方互換性あり
• パッチバージョン（v1.0.1）：バグ修正、新しいデータでモデルを再トレーニング

Git ベースのバージョン管理：

• Git でモデルコードを管理（トレーニングスクリプト、設定）
• DVC（Data Version Control）または Git-LFS でモデルの重みを管理
• コミット SHA とデータバージョンハッシュによる再現性

モデルの系譜追跡とレジストリのパターンについては、references/model-registry.md を参照してください。

3. フィーチャーストア

特徴量エンジニアリングを一元化し、学習と推論の一貫性を確保します。

解決する課題： 学習時とサービング時のずれ

• 学習：将来の情報を使って特徴量を計算します（データリーク）
• 推論：過去のデータのみを使って特徴量を計算します
• 結果：モデルは学習時には高い性能を発揮しますが、本番環境では失敗します

フィーチャーストアによる解決策：

オンラインフィーチャーストア：

• 目的：リアルタイム推論向けに、低レイテンシで特徴量を取得します
• ストレージ：Redis、DynamoDB、Cassandra（キーバリューストア）
• レイテンシ：特徴量の検索で10ms未満
• ユースケース：リアルタイム予測（不正検知、レコメンデーション）

オフラインフィーチャーストア：

• 目的：学習やバッチ推論向けに、過去の特徴量データを提供します
• ストレージ：Parquet ファイル（S3/GCS）、データウェアハウス（Snowflake、BigQuery）
• レイテンシ：数秒から数分（バッチ取得）
• ユースケース：モデル学習、バックテスト、バッチ予測

ポイントインタイムの正確性：

• 学習中に将来のデータがリークしないようにします
• 時刻 T における特徴量の値には、時刻 T より前に利用可能だったデータのみを使用します
• 過度に楽観的な学習指標を避けるために重要です

プラットフォームの比較：

Feast（オープンソース、クラウド非依存）：

• 最も広く使われているオープンソースのフィーチャーストアです
• Redis、DynamoDB、Datastore（オンライン）と Parquet、BigQuery、Snowflake（オフライン）に対応しています
• クラウド非依存で、ベンダーロックインがありません
• 活発なコミュニティがあり、導入が拡大しています

Tecton（マネージド、本番環境向け）：

• Feast 互換の API
• フルマネージドサービス
• モニタリングとガバナンスを統合しています
• コストは高めで、エンタープライズ向けです

SageMaker Feature Store（AWS）：

• AWS エコシステムと統合されています
• マネージドのオンライン／オフラインストア
• AWS にロックインされます

Databricks Feature Store（Databricks）：

• Unity Catalog と統合されています
• オフラインストレージに Delta Lake を使用します
• Databricks エコシステムにロックインされます

選定基準：

• オープンソース、クラウド非依存 → Feast
• マネージドソリューション、本番環境向け → Tecton
• AWS エコシステム → SageMaker Feature Store
• Databricks ユーザー → Databricks Feature Store

特徴量エンジニアリングのパターンと実装については、references/feature-stores.md をご覧ください。

4. モデルサービングパターン

同期、非同期、バッチ、ストリーミング推論向けにモデルをデプロイします。

サービングパターン：

REST API デプロイメント：

• パターン：同期予測のための HTTP エンドポイント
• レイテンシ：<100ms で許容可能
• ユースケース：リクエストとレスポンスを行うアプリケーション
• ツール：Flask、FastAPI、BentoML、Seldon Core

gRPC デプロイメント：

• パターン：低レイテンシ推論向けの高性能 RPC
• レイテンシ：<10ms を目標
• ユースケース：マイクロサービス、レイテンシが重要なアプリケーション
• ツール：TensorFlow Serving、TorchServe、Seldon Core

バッチ推論：

• パターン：大規模なデータセットをオフラインで処理
• レイテンシ：数分から数時間で許容可能
• ユースケース：数百万件のレコードに対する日次／時間単位の予測
• ツール：Spark、Dask、Ray

ストリーミング推論：

• パターン：ストリーミングデータに対するリアルタイム予測
• レイテンシ：ミリ秒単位
• ユースケース：不正検出、異常検出、リアルタイムレコメンデーション
• ツール：Kafka + Flink/Spark Streaming

プラットフォームの比較：

Seldon Core（Kubernetes ネイティブ、高度）：

• 高度なデプロイ戦略（カナリア、A/B テスト、マルチアームドバンディット）
• 複数のフレームワークをサポート
• 説明可能性を統合（Alibi）
• 複雑性が高く、習得に時間がかかる

KServe（CNCF 標準）：

• 標準化された InferenceService API
• サーバーレススケーリング（Knative によるゼロスケーリング）
• Kubernetes ネイティブ
• 採用が拡大中で、CNCF が支援

BentoML（Python ファースト、シンプル）：

• 最も簡単に使い始められる
• 優れた開発者エクスペリエンス
• ローカルテストからクラウドへのデプロイまで対応
• Seldon/KServe より複雑性が低い

TorchServe（PyTorch 公式）：

• PyTorch 専用のサービング
• 本番環境向けで、PyTorch モデルに最適化
• 複数のフレームワークを使う場合の柔軟性は低い

TensorFlow Serving（TensorFlow 公式）：

• TensorFlow 専用のサービング
• 本番環境向けで、TensorFlow モデルに最適化
• 複数のフレームワークを使う場合の柔軟性は低い

選定基準：

• Kubernetes、高度なデプロイ → Seldon Core または KServe
• Python ファースト、シンプルさ → BentoML
• PyTorch 専用 → TorchServe
• TensorFlow 専用 → TensorFlow Serving
• マネージドソリューション → SageMaker/Vertex AI/Azure ML

モデル最適化とサービングインフラストラクチャについては、references/model-serving.md を参照してください。

5. デプロイ戦略

ロールバック機能を備えて、安全にモデルをデプロイします。

ブルーグリーンデプロイメント：

• 同一の環境を2つ用意します（Blue：現行、Green：新規）
• Green にデプロイしてテストし、トラフィックを一瞬で100％切り替えます
• 即座にロールバックできます（Blue に切り戻します）
• トレードオフ：インフラストラクチャが2倍必要で、全か無かの切り替えです

カナリアデプロイメント：

• トラフィックの一部に段階的に展開します
• 時間をかけて5％ → 10％ → 25％ → 50％ → 100％にルーティングします
• 各段階でメトリクスを監視し、劣化があればロールバックします
• トレードオフ：ルーティングロジックが複雑で、デプロイに時間がかかります

シャドウデプロイメント：

• 新しいモデルにトラフィックを送りますが、予測は使用しません
• 新旧のモデルをオフラインで比較します
• 本番環境へのリスクはありません
• トレードオフ：コンピューティングリソースが2倍必要で、フィードバックが遅れます

A/B テスト：

• モデルのバージョン間でトラフィックを分割します
• ビジネスメトリクス（コンバージョン率、収益）を測定します
• 統計的有意性を検定します
• ユースケース：ML メトリクスだけでなく、ビジネス成果を最適化します

マルチアームドバンディット（MAB）：

• イプシロン・グリーディ：探索（新しいモデルを試す）と活用（最良のモデルを使う）
• トンプソンサンプリング：探索にベイズ的アプローチを使用
• ユースケース：継続的な最適化、A/B テストより速い収束

選定基準：

• リスクの低いモデル → ブルーグリーン（即時切り替え）
• リスクが中程度のモデル → カナリア（段階的な展開）
• リスクの高いモデル → シャドウ（本番環境でテストし、影響を与えない）
• ビジネス最適化 → A/B テストまたは MAB

デプロイアーキテクチャと例については、references/deployment-strategies.md を参照してください。

6. ML パイプラインのオーケストレーション

トレーニング、評価、デプロイのワークフローを自動化します。

トレーニングパイプラインのステージ：

1. データの検証（Great Expectations、スキーマチェック）
2. 特徴量エンジニアリング（生データを変換）
3. データの分割（トレーニング／検証／テスト）
4. モデルのトレーニング（ハイパーパラメーターのチューニング）
5. モデルの評価（精度、公平性、説明可能性）
6. モデルの登録（指標がしきい値を満たした場合、レジストリにプッシュ）
7. デプロイ（ステージング／本番環境に昇格）

継続的トレーニングのパターン：

• 本番データを監視してドリフトを検出
• データ分布の変化を検出（KS 検定、PSI）
• ドリフトを検出したら、自動再トレーニングを開始
• デプロイ前に新しいモデルを検証
• カナリアまたはシャドウ戦略でデプロイ

プラットフォームの比較：

Kubeflow Pipelines（ML ネイティブ、Kubernetes）：

• ML 専用のパイプラインオーケストレーション
• Kubernetes ネイティブ（K8s とともにスケール）
• コンポーネントベース（パイプラインのステップを再利用可能）
• Katib（ハイパーパラメーターのチューニング）と統合

Apache Airflow（成熟した汎用プラットフォーム）：

• 最も成熟したオーケストレーションプラットフォーム
• 大規模なエコシステムと豊富な統合機能
• Python ベースの DAG
• ML 専用ではありませんが、ML ワークフローで広く使われています

Metaflow（Netflix、データサイエンス向け）：

• 人間中心の設計で、データサイエンティストが使いやすい
• 優れたローカル開発体験
• バージョン管理を標準搭載
• Kubeflow／Airflow よりシンプル

Prefect（モダン、Python ネイティブ）：

• 静的な DAG ではなく、動的なワークフロー
• Airflow より優れたエラー処理
• モダンな UI と開発者体験
• コミュニティが拡大中

Dagster（アセットベース、テスト重視）：

• アセットベースの考え方（タスクの依存関係だけではありません）
• 強力なテスト機能とデータ品質機能
• モダンなアプローチで、データチームに適しています
• Airflow より小規模なコミュニティ

選定基準：

• ML 専用、Kubernetes → Kubeflow Pipelines
• 成熟度、実績 → Apache Airflow
• データサイエンティスト、使いやすさ → Metaflow
• ソフトウェアエンジニア、テスト → Dagster
• モダンで Airflow よりシンプル → Prefect

パイプラインのアーキテクチャと例については、references/ml-pipelines.md を参照してください。

7. モデルの監視とオブザーバビリティ

本番モデルのドリフト、パフォーマンス、品質を監視します。

データドリフトの検出：

• 定義：入力特徴量の分布が時間とともに変化します
• 影響：古い分布でトレーニングされたモデルの予測品質が低下します
• 検出方法：
  • Kolmogorov-Smirnov（KS）検定：分布を比較
  • Population Stability Index（PSI）：分布の変化を測定
  • カイ二乗検定：カテゴリ特徴量に使用
• 対応：ドリフトを検出したら、自動再トレーニングを開始

モデルドリフトの検出：

• 定義：モデルの予測品質が時間とともに低下します
• 影響：精度、適合率、再現率が低下します
• 検出方法：
  • 正解データによる精度（遅延ラベル）
  • 予測分布の変化
  • キャリブレーションのドリフト（予測確率と実際の結果の比較）
• 対応：チームにアラートを送信し、再トレーニングを開始

パフォーマンスの監視：

• 指標：
  • レイテンシー：推論時間の P50、P95、P99
  • スループット：1 秒あたりの予測数
  • エラー率：失敗した予測数／予測の合計数
  • リソース使用率：CPU、メモリ、GPU の使用状況
• アラートのしきい値：
  • P95 レイテンシー > 100ms → アラート
  • エラー率 > 1% → アラート
  • 精度の低下 > 5% → 再トレーニングを開始

ビジネス指標の監視：

• 下流への影響：コンバージョン率、収益、ユーザー満足度
• モデルの予測とビジネス成果の相関
• ユースケース：ML 指標だけでなく、ビジネス価値を高めるモデルを最適化

ツール：

• Evidently AI：データドリフト、モデルドリフト、データ品質レポート
• Prometheus + Grafana：パフォーマンス指標、カスタムダッシュボード
• Arize AI：ML オブザーバビリティプラットフォーム
• Fiddler：モデルの監視と説明可能性

監視アーキテクチャと実装については、references/model-monitoring.md を参照してください。

8. モデル最適化手法

モデルサイズと推論レイテンシを削減します。

量子化：

• モデルの重みを float32 から int8 に変換します
• モデルサイズの削減：4 分の 1
• 推論速度：2～3 倍高速
• 精度への影響：最小限（通常、劣化は 1% 未満）
• ツール：PyTorch quantization、TensorFlow Lite、ONNX Runtime

モデル蒸留：

• 小規模な生徒モデルを、大規模な教師モデルの動作を模倣するようにトレーニングします
• 教師（BERT-large）から生徒（DistilBERT）に知識を転移します
• サイズの削減：2～10 分の 1
• 速度の向上：2～10 倍高速
• ユースケース：エッジデバイスに小規模モデルをデプロイし、推論コストを削減します

ONNX 変換：

• モデルを Open Neural Network Exchange（ONNX）形式に変換します
• フレームワーク間の互換性（PyTorch → ONNX → TensorFlow）
• ONNX Runtime による最適化された推論
• 速度の向上：ネイティブフレームワークより 1.5～3 倍高速

モデルのプルーニング：

• ニューラルネットワークから重要度の低い重みを削除します
• スパース性：重みの 30～90% をゼロに設定します
• サイズの削減：2～10 分の 1
• 精度への影響：構造化プルーニングでは最小限です

最適化手法と例については、references/model-serving.md を参照してください。

9. LLMOps パターン

専用のパターンを使用して、大規模言語モデルを運用します。

LLM のファインチューニングパイプライン：

• LoRA（Low-Rank Adaptation）：パラメーター効率の高いファインチューニング
• QLoRA：量子化 LoRA（4 ビット量子化）
• パイプライン：ベースモデル → ファインチューニング用データセット → LoRA アダプター → マージ済みモデル
• ツール：Hugging Face PEFT、Axolotl

プロンプトのバージョン管理：

• プロンプトのバージョン管理（Git、プロンプト管理プラットフォーム）
• 品質とコストを最適化するためのプロンプトの A/B テスト
• 時間の経過に伴うプロンプトの有効性を監視します

RAG システムの監視：

• 検索品質：取得したドキュメントの関連性
• 生成品質：回答の精度、ハルシネーションの検出
• エンドツーエンドのレイテンシ：検索と生成にかかる時間
• ツール：LangSmith、Arize Phoenix

LLM 推論の最適化：

• vLLM：高スループットの LLM サービング
• TensorRT-LLM：NVIDIA 向けに最適化された LLM 推論
• Text Generation Inference（TGI）：Hugging Face のサービング
• バッチ処理：スループット向上のための動的バッチ処理

埋め込みモデルの管理：

• モデルとともに埋め込みのバージョンを管理します
• 埋め込みのドリフト（分布の変化）を監視します
• 基盤となるモデルが変更されたら、埋め込みを更新します

LLMOps のパターンと実装については、references/llmops-patterns.md を参照してください。

10. モデルのガバナンスとコンプライアンス

モデルリスク管理と規制コンプライアンスのためのガバナンスを確立します。

モデルカード：

• ドキュメント：モデルの目的、トレーニングデータ、パフォーマンス指標
• 制限事項：既知のバイアス、障害モード、対象範囲外のユースケース
• 倫理的な考慮事項：公平性、プライバシー、社会的影響
• テンプレート：Model Card Toolkit（Google）

バイアスと公平性の検出：

• 人口統計グループ間の不均衡な影響を測定します
• ツール：Fairlearn、AI Fairness 360（IBM）
• 指標：人口統計的均等性、均等化オッズ、キャリブレーション
• 軽減策：再重み付け、敵対的デバイアス、しきい値の最適化

規制コンプライアンス：

• EU AI Act：高リスク AI システムにはドキュメントと監視が必要です
• モデルリスク管理（SR 11-7）：銀行業界の要件
• GDPR：自動化された意思決定について説明を受ける権利
• HIPAA：医療データのプライバシー

監査証跡：

• すべてのモデルバージョン、トレーニング実行、デプロイを記録します
• モデルの移行（ステージング → 本番環境）を誰が承認したか追跡します
• コンプライアンス監査のために過去の予測を保持します
• ツール：MLflow、Neptune.ai（監査ログ）

ガバナンスのフレームワークとコンプライアンスについては、references/governance.md を参照してください。

意思決定フレームワーク

フレームワーク 1：実験追跡プラットフォームの選択

決定木：

主な要件から選択します：

• オープンソース、セルフホストの要件 → MLflow
• チームでのコラボレーション、高度な可視化（予算あり） → Weights & Biases
• チームでのコラボレーション、高度な可視化（予算なし） → MLflow
• エンタープライズコンプライアンス（監査ログ、RBAC） → Neptune.ai
• ハイパーパラメーター最適化が主なユースケース → Weights & Biases（Sweeps）

詳細な基準：

基準	MLflow	Weights & Biases	Neptune.ai
コスト	無料	$200/user/month	$300/user/month
コラボレーション	基本	優れている	良好
可視化	基本	優れている	良好
ハイパーパラメーター調整	外部（Optuna）	統合（Sweeps）	基本
モデルレジストリ	含まれる	アドオン	含まれる
セルフホスト	はい	いいえ（有料のみ）	制限あり
エンタープライズ機能	なし	制限あり	優れている

組織別の推奨事項：

• スタートアップ（50人未満）：MLflow（無料で十分）または W&B（予算がある場合）
• 成長企業（50～500人）：Weights & Biases（チームでのコラボレーション）
• エンタープライズ（500人超）：Neptune.ai（コンプライアンス）または MLflow（コスト）

詳細な決定フレームワークについては、references/decision-frameworks.mdを参照してください。

フレームワーク 2：特徴量ストアの選択

決定マトリックス：

主な要件：

• オープンソース、クラウドに依存しない → Feast
• マネージドソリューション、本番環境対応、マルチクラウド → Tecton
• AWS エコシステム → SageMaker Feature Store
• GCP エコシステム → Vertex AI Feature Store
• Azure エコシステム → Azure ML Feature Store
• Databricks ユーザー → Databricks Feature Store
• UI 付きでセルフホスト → Hopsworks

基準の比較：

要素	Feast	Tecton	Hopsworks	SageMaker FS
コスト	無料	$$$$	無料（セルフホスト）	$$$
オンラインサービング	Redis, DynamoDB	マネージド	RonDB	マネージド
オフラインストア	Parquet, BigQuery, Snowflake	マネージド	Hive, S3	S3
時点整合性	はい	はい	はい	はい
モニタリング	外部	統合	基本	外部
クラウドロックイン	なし	なし	なし	AWS

推奨事項：

• オープンソース、自社管理 → Feast
• マネージド、本番環境対応 → Tecton
• AWS エコシステム → SageMaker Feature Store
• Databricks ユーザー → Databricks Feature Store

詳細な決定フレームワークについては、references/decision-frameworks.mdを参照してください。

フレームワーク 3：モデルサービングプラットフォームの選択

決定木：

インフラストラクチャ：

• Kubernetes ベース → 高度なデプロイパターンが必要ですか？
  • はい → Seldon Core（最も多機能）または KServe（CNCF 標準）
  • いいえ → BentoML（よりシンプルで、Python を優先）
• クラウドネイティブ（マネージド） → クラウドプロバイダーは？
  • AWS → SageMaker Endpoints
  • GCP → Vertex AI Endpoints
  • Azure → Azure ML Endpoints
• フレームワーク固有 → フレームワークは？
  • PyTorch → TorchServe
  • TensorFlow → TensorFlow Serving
• サーバーレス／最小限のインフラストラクチャ → BentoMLまたは Cloud Functions

詳細な基準：

機能	Seldon Core	KServe	BentoML	TorchServe
Kubernetes ネイティブ	はい	はい	任意	いいえ
マルチフレームワーク	はい	はい	はい	PyTorch のみ
デプロイ戦略	優れている	良好	基本	基本
説明可能性	統合	統合	外部	なし
複雑さ	高	中	低	低
学習曲線	急	中	緩やか	緩やか

推奨事項：

• Kubernetes、高度なデプロイ → Seldon Core または KServe
• Python を優先、シンプルさ重視 → BentoML
• PyTorch 固有 → TorchServe
• TensorFlow 固有 → TensorFlow Serving
• マネージドソリューション → SageMaker/Vertex AI/Azure ML

詳細な決定フレームワークについては、references/decision-frameworks.mdを参照してください。

フレームワーク 4：ML パイプラインオーケストレーションの選定

選定マトリックス：

主なユースケース：

• ML 専用パイプライン、Kubernetes ネイティブ → Kubeflow Pipelines
• 汎用オーケストレーション、成熟したエコシステム → Apache Airflow
• データサイエンスのワークフロー、使いやすさ → Metaflow
• モダンなアプローチ、アセットベースの考え方 → Dagster
• 動的なワークフロー、Python ネイティブ → Prefect

評価基準の比較：

要素	Kubeflow	Airflow	Metaflow	Dagster	Prefect
ML 専用	優秀	良好	優秀	良好	良好
Kubernetes	ネイティブ	互換性あり	オプション	互換性あり	互換性あり
学習曲線	急	急	緩やか	中程度	中程度
成熟度	高い	非常に高い	中程度	中程度	中程度
コミュニティ	大規模	非常に大規模	成長中	成長中	成長中

推奨：

• ML 専用、Kubernetes → Kubeflow Pipelines
• 成熟度が高く、実績のあるもの → Apache Airflow
• データサイエンティスト向け → Metaflow
• ソフトウェアエンジニア向け → Dagster
• モダンで、Airflow よりシンプル → Prefect

詳しい選定フレームワークについては、references/decision-frameworks.md を参照してください。

実装パターン

パターン 1：エンドツーエンドの ML パイプライン

データからデプロイまで、ML ワークフロー全体を自動化します。

パイプラインのステージ：

1. データ検証（Great Expectations）
2. 特徴量エンジニアリング（生データを変換）
3. データ分割（トレーニング／検証／テスト）
4. モデルのトレーニング（ハイパーパラメーター調整を含む）
5. モデル評価（精度、公平性、説明可能性）
6. モデル登録（MLflow レジストリにプッシュ）
7. デプロイ（ステージング／本番環境に昇格）

アーキテクチャ：

Data Lake → Data Validation → Feature Engineering → Training → Evaluation
    ↓
Model Registry (staging) → Testing → Production Deployment

実装の詳細とコード例については、references/ml-pipelines.md を参照してください。

パターン 2：継続的トレーニング

ドリフト検出に基づくモデルの再トレーニングを自動化します。

ワークフロー：

1. 本番データの分布変化を監視する
2. データドリフトを検出する（KS 検定、PSI）
3. 自動再トレーニングパイプラインをトリガーする
4. 新しいモデルを検証する（精度、公平性）
5. カナリア戦略でデプロイする（5% → 100%）
6. 新しいモデルのパフォーマンスを監視する
7. 指標が低下した場合はロールバックする

トリガー条件：

• スケジュール：毎日／毎週の再トレーニング
• データドリフト：KS 検定の p 値 < 0.05
• モデルドリフト：精度の低下 > 5%
• データ量：新しいトレーニングデータがしきい値（10K サンプル）を超える

実装の詳細については、references/ml-pipelines.md を参照してください。

パターン 3：フィーチャーストアの統合

トレーニングと推論で、一貫した特徴量を使用できるようにします。

アーキテクチャ：

Offline Store (Training):
  Parquet/BigQuery → Point-in-Time Join → Training Dataset

Online Store (Inference):
  Redis/DynamoDB → Low-Latency Lookup → Real-Time Prediction

時点整合性：

• トレーニング：特定のタイムスタンプ時点の特徴量を取得する（未来のデータは使用しない）
• 推論：最新の特徴量を取得する（過去のデータのみを使用）
• 保証：トレーニングと推論で同じ特徴量ロジックを使用する

実装の詳細とコード例については、references/feature-stores.md を参照してください。

パターン 4：シャドーデプロイテスト

リスクを伴わずに、本番環境で新しいモデルをテストします。

ワークフロー：

1. 新しいモデル（v2）をシャドーモードでデプロイする
2. v2 に本番トラフィックのコピーを送信する
3. レスポンスには v1 の予測を使用する（ユーザーへの影響なし）
4. v1 と v2 の予測をオフラインで比較する
5. 差異を分析し、v2 の精度を測定する
6. パフォーマンスに問題がなければ、v2 を本番環境に昇格する

ユースケース：

• 高リスクのモデル（金融、医療、安全性が極めて重要な用途）
• 切り替え前に広範なテストが必要
• 実際の本番データでモデルの挙動を比較する

デプロイアーキテクチャについては、references/deployment-strategies.md を参照してください。

ツールの推奨

本番環境向けツール（高い採用率）

MLflow - 実験の追跡とモデルレジストリ

• GitHub スター数：20,000+
• 信頼度スコア：95/100
• ユースケース：実験の追跡、モデルレジストリ、モデルサービング
• 強み：オープンソース、フレームワークに依存しない、セルフホストの選択肢
• はじめ方：pip install mlflow && mlflow server

Feast - フィーチャーストア

• GitHub スター数：5,000+
• 信頼度スコア：85/100
• ユースケース：オンライン／オフラインでの特徴量サービング、時点整合性の確保
• 強み：クラウドに依存しない、最も人気のあるオープンソースのフィーチャーストア
• はじめ方：pip install feast && feast init

Seldon Core - モデルサービング（上級）

• GitHub スター数：4,000+
• 信頼度スコア：85/100
• ユースケース：Kubernetes ネイティブなサービング、高度なデプロイパターン
• 強み：カナリアリリース、A/B テスト、MAB、説明可能性
• 制約：複雑性が高く、学習曲線が急

KServe - モデルサービング（CNCF 標準）

• GitHub スター数：3,500+
• 信頼度スコア：85/100
• ユースケース：標準化されたサービング API、サーバーレススケーリング
• 強み：CNCF プロジェクト、Knative との統合、採用が拡大中
• 制約：Kubernetes が必要

BentoML - モデルサービング（シンプルさ）

• GitHub スター数：6,000+
• 信頼度スコア：80/100
• ユースケース：簡単なパッケージ化、Python を優先したデプロイ
• 強み：学習曲線が最も緩やか、優れた開発者体験
• 制約：Seldon／KServe より高度な機能が少ない

Kubeflow Pipelines - ML オーケストレーション

• GitHub スター数：14,000+（Kubeflow プロジェクト）
• 信頼度スコア：90/100
• ユースケース：ML 専用パイプライン、Kubernetes ネイティブなワークフロー
• 強み：ML ネイティブ、コンポーネントの再利用性、Katib との統合
• 制約：Kubernetes が必要、学習曲線が急

Weights & Biases - 実験の追跡（SaaS）

• 信頼度スコア：90/100
• ユースケース：チームでの共同作業、高度な可視化、ハイパーパラメーター調整
• 強み：クラス最高の UI、統合された Sweeps、強力なコミュニティ
• 制約：SaaS の料金体系、無料のセルフホストプランなし

ツールの詳細な比較については、references/tool-recommendations.md を参照してください。

組織別のツールスタックの推奨

スタートアップ（コスト重視、シンプル）：

• 実験の追跡：MLflow（無料、セルフホスト）
• フィーチャーストア：当初は不要 → 必要になったら Feast
• モデルサービング：BentoML（簡単）またはクラウド関数
• オーケストレーション：Prefect または cron ジョブ
• モニタリング：基本的なログ記録 + Prometheus

成長企業（バランス重視）：

• 実験の追跡：Weights & Biases または MLflow
• フィーチャーストア：Feast（オープンソース、本番環境に対応）
• モデルサービング：BentoML または KServe（Kubernetes ベース）
• オーケストレーション：Kubeflow Pipelines または Airflow
• モニタリング：Evidently + Prometheus + Grafana

エンタープライズ（フルスタック）：

• 実験の追跡：MLflow（セルフホスト）または Neptune.ai（コンプライアンス対応）
• フィーチャーストア：Tecton（マネージド）または Feast（セルフホスト）
• モデルサービング：Seldon Core（上級）または KServe
• オーケストレーション：Kubeflow Pipelines または Airflow
• モニタリング：Evidently + Prometheus + Grafana + PagerDuty

クラウドネイティブ（マネージドサービス）：

• AWS：SageMaker（エンドツーエンドのプラットフォーム）
• GCP：Vertex AI（エンドツーエンドのプラットフォーム）
• Azure：Azure ML（エンドツーエンドのプラットフォーム）

シナリオ別の推奨については、references/scenarios.md を参照してください。

よくあるシナリオ

シナリオ 1：スタートアップの MLOps スタック

背景： 20 人規模のスタートアップ、データサイエンティスト 5 人、モデル 3 つ（不正検出、レコメンデーション、解約予測）、予算に制約あり。

推奨：

• 実験の追跡：MLflow（無料、セルフホスト）
• モデルサービング：BentoML（シンプルで、素早く反復可能）
• オーケストレーション：Prefect（Airflow よりシンプル）
• モニタリング：Prometheus + 基本的なドリフト検出
• フィーチャーストア：当初は見送り、データベースのテーブルを使用

理由：

• コストを最小限に抑える（すべてオープンソース、セルフホスト）
• 素早く反復できる（BentoML はデプロイが簡単）
• 過剰な設計を避ける（モデル 3 つなら Kubeflow は不要）
• モデルが 10 個以上に増えたらフィーチャーストア（Feast）を追加

詳細なシナリオについては、references/scenarios.md を参照してください。

シナリオ 2：エンタープライズ ML プラットフォーム

コンテキスト： 従業員 500 人の企業、データサイエンティスト 50 人、100 を超えるモデル、規制コンプライアンス、マルチクラウド。

推奨事項：

• 実験トラッキング：Neptune.ai（コンプライアンス、監査ログ）または MLflow（コスト）
• フィーチャーストア：Feast（セルフホスト可能、クラウドに依存しない）
• モデルサービング：Seldon Core（高度なデプロイパターン）
• オーケストレーション：Kubeflow Pipelines（ML ネイティブ、Kubernetes）
• モニタリング：Evidently + Prometheus + Grafana + PagerDuty

根拠：

• コンプライアンスが必須です（Neptune の監査ログ、RBAC）
• マルチクラウドに対応します（Feast はクラウドに依存しません）
• 高度なデプロイに対応します（Seldon のカナリアデプロイ、A/B テスト）
• スケールに対応します（100 を超えるモデルには Kubernetes）

詳細なシナリオについては、references/scenarios.md を参照してください。

シナリオ 3：LLM ファインチューニングパイプライン

コンテキスト： 特定のドメイン用途に合わせて LLM をファインチューニングし、本番環境でサービングします。

推奨事項：

• 実験トラッキング：MLflow（ファインチューニングの実行を追跡）
• パイプラインオーケストレーション：Kubeflow Pipelines（GPU スケジューリング）
• モデルサービング：vLLM（高スループットな LLM サービング）
• プロンプトのバージョン管理：Git + LangSmith
• モニタリング：Arize Phoenix（RAG モニタリング）

根拠：

• ファインチューニングの実験を追跡します（LoRA アダプター、ハイパーパラメーター）
• GPU オーケストレーションに対応します（Kubernetes 上の Kubeflow）
• LLM を効率的にサービングします（vLLM はスループット向けに最適化されています）
• RAG システムをモニタリングします（検索と生成の品質）

詳細なシナリオについては、references/scenarios.md を参照してください。

他のスキルとの連携

直接的な依存関係：

• ai-data-engineering：特徴量エンジニアリング、ML アルゴリズム、データ準備
• kubernetes-operations：K8s クラスター管理、ML ワークロード向け GPU スケジューリング
• observability：ML システムのモニタリング、アラート、分散トレーシング

補完的なスキル：

• data-architecture：ML モデルにデータを供給するデータパイプライン、データレイク
• data-transformation：特徴量変換パイプライン向けの dbt
• streaming-data：リアルタイム ML 推論向けの Kafka、Flink
• designing-distributed-systems：ML ワークロードのスケーラビリティパターン
• api-design-principles：ML モデル API、REST/gRPC サービングパターン

下流のスキル：

• building-ai-chat：ML モデルを利用する LLM 搭載アプリケーション
• visualizing-data：ML メトリクスとモニタリング用のダッシュボード

ベストプラクティス

1. すべてをバージョン管理します：

   • コード：再現性のための Git コミット SHA
   • データ：DVC またはデータバージョンのハッシュ
   • モデル：セマンティックバージョニング（v1.2.3）
   • 特徴量：フィーチャーストアのバージョン管理

2. テストを自動化します：

   • 単体テスト：モデルが読み込まれ、入力を受け付け、出力を生成すること
   • 統合テスト：パイプラインのエンドツーエンド実行
   • モデル検証：精度のしきい値、公平性チェック

3. 継続的にモニタリングします：

   • データドリフト：時間の経過に伴う分布の変化
   • モデルドリフト：精度の低下
   • パフォーマンス：レイテンシー、スループット、エラー率

4. シンプルに始めます：

   • まずは MLflow と基本的なサービング（BentoML）から始めます
   • 必要に応じて複雑さを追加します（フィーチャーストア、Kubeflow）
   • 過剰な設計を避けます（モデルが 2 つしかないのに Kubeflow を構築しないでください）

5. 時点整合性を確保します：

   • フィーチャーストアを使用して、学習時とサービング時のずれを防ぎます
   • 学習データへの未来データの混入がないことを確認します
   • 学習と推論で一貫した特徴量ロジックを使用します

6. デプロイ戦略：

   • 中リスクのモデルにはカナリアデプロイを使用します（段階的なロールアウト）
   • 高リスクのモデルにはシャドーデプロイを使用します（本番環境への影響ゼロ）
   • 常にロールバック計画を用意します（以前のバージョンへ即座に切り替え）

7. ガバナンス：

   • モデルカード：モデルの目的、制限、バイアスを文書化します
   • 監査証跡：すべてのモデルバージョン、デプロイ、承認を追跡します
   • コンプライアンス：EU AI Act、モデルリスク管理（SR 11-7）

8. コストを最適化します：

   • 量子化：モデルサイズを 4 分の 1 に削減し、推論速度を 2～3 倍に向上させます
   • スポットインスタンス：プリエンプティブル VM で学習します（コストを 60～90％削減）
   • オートスケーリング：負荷に応じて推論エンドポイントをスケールします

アンチパターン

❌ 本番環境でのノートブックの使用：

• Jupyter ノートブックを本番環境にデプロイしないでください
• ノートブックは実験のみに使用してください
• 本番環境では、スクリプト、Docker コンテナ、CI/CD パイプラインを使用してください

❌ モデルの手動デプロイ：

• CI/CD パイプラインでデプロイを自動化してください
• モデルレジストリのステージ遷移（ステージング → 本番環境）を使用してください
• 人的ミスをなくし、再現性を確保してください

❌ モニタリングの欠如：

• モニタリングなしで本番環境のモデルを運用すると、気づかないうちに性能が低下します
• ドリフト検出（データドリフト、モデルドリフト）を導入してください
• 精度の低下やレイテンシの急増に対するアラートを設定してください

❌ トレーニングとサービングの不一致：

• トレーニングと推論で異なる特徴量ロジックを使用する
• 特徴量ストアを使用して一貫性を確保してください
• 本番環境へのデプロイ前に、特徴量の同等性をテストしてください

❌ データ品質の軽視：

• 入力が悪ければ、出力も悪くなります（GIGO）
• データスキーマ、範囲、分布を検証してください
• データ検証には Great Expectations を使用してください

❌ 過剰な設計：

• モデルが 2 つしかないのに Kubeflow を構築しないでください
• シンプルに始めてください（MLflow + BentoML）
• 必要になった場合にのみ複雑さを追加してください（モデルが 10 個以上）

❌ ロールバック計画の欠如：

• 常に以前のモデルバージョンにロールバックできるようにしてください
• ブルーグリーン、カナリア、シャドーデプロイにより、即時のロールバックが可能になります
• 本番環境へのデプロイ前にロールバック手順をテストしてください

さらに読む

参考ファイル：

• 実験の追跡 - MLflow、W&B、Neptune の詳細
• モデルレジストリ - バージョン管理、系譜、ステージ遷移
• 特徴量ストア - Feast、Tecton、オンライン／オフラインのパターン
• モデルサービング - Seldon、KServe、BentoML、最適化
• デプロイ戦略 - ブルーグリーン、カナリア、シャドー、A/B
• ML パイプライン - Kubeflow、Airflow、トレーニングパイプライン
• モデルモニタリング - ドリフト検出、可観測性
• LLMOps のパターン - LLM のファインチューニング、RAG、プロンプト
• 意思決定フレームワーク - ツール選定のフレームワーク
• ツールの推奨事項 - 詳細な比較
• シナリオ - スタートアップ、エンタープライズ、LLMOps のユースケース
• ガバナンス - モデルカード、コンプライアンス、公平性

サンプルプロジェクト：

• examples/mlflow-experiment/ - MLflow の完全なセットアップ
• examples/feast-feature-store/ - Feast のオンライン／オフライン
• examples/seldon-deployment/ - カナリア、A/B テスト
• examples/kubeflow-pipeline/ - エンドツーエンドのパイプライン
• examples/monitoring-dashboard/ - Evidently + Prometheus

スクリプト：

• scripts/setup_mlflow_server.sh - PostgreSQL + S3 を使用した MLflow
• scripts/feast_feature_definition_generator.py - Feast の特徴量を生成
• scripts/model_validation_suite.py - モデルの自動テスト
• scripts/drift_detection_monitor.py - スケジュールされたドリフト検出
• scripts/kubernetes_model_deploy.py - Seldon／KServe へのデプロイ