株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
MLOpsにおけるCI/CDパイプラインの役割
ソフトウェア開発のCI/CDが「コードの品質と配信速度」の改善を支えるように、MLOpsのCI/CDは「モデルの品質と本番反映速度」の改善を支えます。しかし機械学習特有の複雑さ — データの変動、学習の再現性、モデルサイズの大きさ — により、従来のDevOps手法をそのまま適用できません。
本記事では、GitHub Actions + MLflow + Dockerを軸に、実務で使えるMLOps CI/CDパイプラインの構築手順を解説します。CI・CT・CDの役割はGoogle CloudのMLOps解説を参照し、以下では学習・評価・配信を組み合わせる構成例として説明します。
MLOps CI/CDの3つの柱: CI・CT・CD
CI（Continuous Integration）— コードとデータの検証
コード変更がプッシュされるたびに、リンティング・ユニットテスト・データスキーマ検証を自動実行します。データの分布変化（ドリフト）を検知するバリデーションもこのフェーズに含まれます。
CT（Continuous Training）— モデルの自動再学習
新しいデータが蓄積された際、またはスケジュールに従い、学習パイプラインを自動実行します。MLflowにパラメータ・メトリクス・アーティファクトを記録し、過去の実験と比較可能にします。
CD（Continuous Deployment）— モデルの本番配信
MLflowのModel Registryでは、モデルバージョンに「candidate」や「champion」といったエイリアスを割り当てられます。本記事の構成例では、candidateで参照するモデルを評価し、合格したバージョンにchampionを付け替えます。その後、新しいDockerイメージをビルドしてサービングエンドポイントへ配信する処理を起動します。評価、エイリアス更新、配信処理の連携はパイプライン側で実装するもので、名前を付けただけで自動昇格・デプロイされるわけではありません。
GitHub Actionsによるワークフロー設計
GitHub Actionsは、pushやpull_request、schedule等のイベントを設定してCI/CTパイプラインを自動起動できます。PRマージ後の実行は、例えば対象ブランチへのpushを条件に設定します。MLOps固有のポイントは以下の通りです。
- ワークフロートリガー:
pushイベントに加え、schedule（cron）で定期再学習を設定 - セルフホストランナー: GPU学習が必要な場合、GPU付きのセルフホストランナーを利用する方法がある。対応プランではGPU付きのGitHub-hosted larger runnerも選択肢となる
- シークレット管理: APIキー等はGitHub ActionsのSecretsで管理。対応するクラウドではOIDCで短期認証情報を取得する方式も利用できる
- アーティファクト管理: 学習済みモデルはMLflow Artifact Store（保存先にS3/GCS等を設定可能）で管理する。Actionsのアーティファクトも成果物の受け渡しに使えるが、保存容量・費用・保存期間（既定90日）とモデルの保持要件を照合して選ぶ。一律に非推奨ではない
MLflow連携の実装ポイント
実験追跡（Tracking）
学習スクリプト内でmlflow.log_params()・mlflow.log_metrics()を呼び出し、各実験で必要なパラメータと評価値を記録します（MLflow Tracking API）。CI/CDパイプラインと手動実験で同じTracking URIを設定し、適切な実験・runに記録することでメトリクスを統一管理できます。これらの関数だけでモデル本体や全実験が自動保存されるわけではなく、モデル・アーティファクトの保存も別途設定します。
Model Registry
学習完了後、モデルをMLflow Model Registryに登録します。Model StagesはMLflow 2.9.0以降非推奨のため、本記事では旧Staging／Production方式を使わず、candidate／championエイリアスを使う構成に統一します。新バージョンにcandidateを明示的に割り当て、事前に定めた評価を通過した場合に、同じバージョンへchampionを付け替える処理を実装します。この評価ゲートは、設定した基準を満たさないモデルの本番配信を防ぐ助けになりますが、未検証の入力や運用後の変化による品質低下まで排除するものではありません。
モデルサービング
championエイリアスから配信対象のモデルバージョンを解決し、そのバージョンを固定してDockerイメージをビルド・デプロイする方式を構成できます。mlflow models serveでローカルのREST APIサーバーを起動する方法はMLflow公式資料に説明されています。カスタムFastAPIサーバーでラップする場合も、モデルの読み込み、認証、ヘルスチェック等を実装します。エイリアスの付け替えだけで起動済みプロセスのモデルが切り替わるとは限らないため、再読み込みや再デプロイの手順を決めます。
データバリデーションの自動化
本番データの品質劣化や分布変化は、モデル精度が低下する要因の一つです。CI段階で以下を自動検証します。
- スキーマ検証: カラム名・データ型・NULL許容の一致を確認
- 分布検証: KL divergence / PSI（Population Stability Index）で学習データとの乖離を検出
- 異常値検出: IQR法やz-scoreで統計的外れ値をフラグ付け
Great ExpectationsのExpectationでデータの検証ルールを定義し、パイプラインに組み込めます。EvidentlyはKL divergenceやPSI等による分布比較にも対応しています。列の型・欠損・分布・外れ値では検証方法が異なるため、ライブラリが対応する指標を選び、必要に応じて独自の検証処理を実装します。
モデルモニタリングとフィードバックループ
デプロイ後も継続的なモニタリングが必要です。追跡すべきメトリクスは3カテゴリに分けられます。
- 推論パフォーマンス: レイテンシ、スループット、エラーレート
- モデル品質: 精度、F1スコア、AUC（ラベル付きフィードバックがある場合）
- データドリフト: 入力特徴量の分布変化を検知し、再学習トリガーとする
GrafanaはPrometheusをデータソースとして利用でき、レイテンシやエラーレート等の可視化に使えます。Evidently AIによるデータドリフトの評価など、ML向けの検証と組み合わせる構成も考えられます。WhyLabsは会社の事業終了とプラットフォームのOSS化を案内しているため、従来の商用サービスとしての利用を前提にせず、公開ソフトウェアの運用・保守を担えるかを確認する必要があります。
実装時の落とし穴と対策
- 再現性の担保: ランダムシードの固定だけでは不十分。Dockerイメージで環境を固定し、データのバージョンもDVC等で管理する。ライブラリやハードウェアの違いも含め、再現条件を記録する
- 学習時間とCI/CDの整合: 学習時間をrunnerの実行上限とジョブ設定に照らす。GitHub-hostedは1ジョブ6時間、self-hostedは5日が上限で、timeout-minutesの既定は360分。self-hostedでも設定値や認証情報の有効期間を考慮する。長時間の処理はAWS Batch等の非同期ジョブへ委譲する方法がある。CIで長時間待ち続けず、ジョブIDを保存して別の短いジョブや完了通知で状態確認する
- モデルサイズとレジストリ: 数GBのモデル本体を通常のGit履歴へ格納すると、複製や履歴管理の負荷が大きくなる。MLflow Artifact Store + クラウドストレージで管理し、モデルバージョン等の参照をコードに持つ
- A/Bテストとカナリアデプロイ: いきなり100%切り替えではなく、一部のトラフィックで新モデルを検証する。例えば10%から始める設計もあるが、配信割合・観測期間・合格基準はリスクと必要な標本数に応じて決める。カナリア配信やA/Bテストによるオンライン検証を経て全量切り替えを判断する
まとめ
MLOps CI/CDパイプラインは「コード品質」「データ品質」「モデル品質」の3つを継続的に検証する仕組みです。GitHub Actionsで自動トリガーを設定し、MLflowで実験・モデルを一元管理し、Dockerで環境を固定する — この3要素を組み合わせ、評価範囲と運用後の監視を設計することで、再現性と配信速度の改善を図れます。
関連記事
- MLOpsとは？機械学習の本番運用・CI/CDパイプライン構築・ツール比較【総合ガイド】
- MLOpsツール比較2026 — MLflow・Kubeflow・SageMaker・Vertex AI選定ガイド
- MLOps入門 — データサイエンティストが最初にやるべき5ステップ
- MLOps成熟度モデル — レベル0から2への組織導入ロードマップ
よくある質問（FAQ）
Q. GitHub ActionsとJenkinsのどちらがMLOps CI/CDに適していますか？
A. GitHub上のコードとワークフローをまとめて管理するならGitHub Actionsが候補です。オンプレミスGPUもセルフホストランナーで利用できるため、大規模組織は必ずJenkinsという区分にはなりません。Jenkinsもローカルやクラウドのエージェントでジョブを実行できます。既存のCI資産、ネットワーク制約、GPU管理、保守体制、費用に応じて選定します。（GitHub Actionsのrunner指定／Jenkinsのエージェント）
Q. モデルの再学習頻度はどう決めるべきですか？
A. データの変化、正解ラベルが集まる頻度、モデル品質、学習コストに応じて決めます。ECのレコメンドと製造業の異常検知でも、業種名だけで日次・月次と固定はできません。日次・週次・月次の定期実行や、ドリフト・品質低下を契機とする実行を候補に、モニタリング結果から調整します。事業要件と運用コストの均衡も考慮します。（Google Cloudの再学習トリガーの説明）
Q. CT（Continuous Training）とCDは同じワークフローに入れるべきですか？
A. 障害対応や承認の単位を分けたい場合は、CTを学習・Model Registryへの登録と評価まで、CDを承認済みモデルの配信までとする設計が考えられます。本記事では評価後にchampionエイリアスを対象バージョンへ付け替え、配信処理を起動する構成です。Registryの登録やエイリアス操作だけでGitHub Actionsは起動しないため、評価後のAPI呼び出し等による連携を実装し、対象バージョンと評価結果を記録します。（MLflowのエイリアス／Actionsの起動イベント）
Q. パイプラインの失敗通知はどうすべきですか？
A. GitHub ActionsからSlackへ実行結果を通知する連携を設定し、失敗時に対応者へ届くようにします。通知先や条件はワークフローで設計します。加えてMLflowに記録した評価メトリクスの異常も検知対象にし、通知の優先度と当番を決めることで対応の遅延を減らします。（Slack公式GitHub Action）
Q. セキュリティ上の注意点は？
A. 学習データへのアクセス権限を最小化し、モデルアーティファクトの暗号化、推論APIの認証・レートリミットを設定します。特にLLMの場合、プロンプトインジェクション対策も必要です。
