モデルのリリースや更新を現場で安全に回すとき、どの段階で人の判断を挟むべきか、どのテストを自動化するかで迷うことが多いはずです。本記事では「現場で使える」実務手順に重点を置き、チェックリストや短いPythonスニペットを交えて、段階的に導入できるCI/CD設計を示します。
狙いと前提
目的：モデルの開発から本番デプロイ、監視・ロールバックまでを、実務担当者が安全に運用できるCI/CDパイプラインに落とし込むこと。
- 対象読者：AIを仕事に活かしたい実務担当者、個人事業主、中小企業の担当者
- 前提条件：モデル監視・フィードバック・ステージング運用が既にあること（第60〜64回で触れた内容をベースにしています）
- 狙い：自動テスト、アーティファクト管理、段階的デプロイ（ステージング→カナリー→本番）、およびロールバックを現場ルールに落とし込む
全体像
以下が実務で回すときの大まかなフローです。図は省略し、各フェーズと担当の境界を明確にします。
- 開発（ローカル／CIビルド）→ 自動テスト → モデルアーティファクト登録 → ステージングデプロイ → カナリー → 本番切替 → 監視・フィードバック・必要ならロールバック
役割分担（実務上の例）
- デベロッパー：コード/ユニットテスト、軽量E2Eテスト作成
- MLエンジニア：モデルパイプライン、アーティファクト定義、性能テスト設計
- 運用（SRE/担当者）：デプロイ手順、監視・アラート設定、承認ゲート運用
実務チェックリスト
まずはリポジトリとアーティファクトの必須項目を揃えましょう。以下のテーブルは最低限の実務ルール例です。
| 項目 | 必須内容 | コメント |
|---|---|---|
| レポジトリ構成 | src/, tests/, infra/, models/, ci/ | CIワークフローとrunbookをci/に置く |
| モデルアーティファクト | フォーマット（.onnx/.pt/.bin/quantized）, checksum | モデルはバイナリ＋メタデータで管理 |
| メタデータ | バージョン, トレーニングデータID, KPI（精度/latency） | デプロイ可否判定の根拠として必須 |
| モデルカード | 用途、期待KPI、想定入出力、制約 | 担当者間の認識合わせ用 |
| 署名・バージョンルール | セマンティックバージョン＋ビルドID＋署名 | artifactの不変性を担保 |
| 推論コンテナ基準 | ベースイメージ、依存固定、ヘルスチェックエンドポイント | コンテナにより環境差異を減らす |
自動テスト戦略
テストは多層化します。目的は「早期に問題を検出」して「デプロイ時のリスクを定量化」することです。
ユニットテスト
- 入力処理、前処理、ユーティリティ関数をテスト
- プロンプトやシリアライゼーションの境界など、モデル以外の破綻を防ぐ
統合（軽量E2E）テスト
- 小さなリクエストセットでエンドツーエンドを検証（レスポンス構造・ステータス）
差分・スナップショットテスト
- 既知の入力に対する出力差分を閾値で監視
性能テスト
- latency (p50/p95) と throughput をCIで計測（軽量）
データ契約／スキーマ検証
- 入力のスキーマ検証を自動化し、契約違反をリジェクト
簡単なPythonによるエンドポイント検証例（pytest + requests）:
# tests/test_inference.py
import requests
def test_health():
r = requests.get("http://localhost:8000/health")
assert r.status_code == 200
def test_inference():
payload = {"input": "テスト入力"}
r = requests.post("http://localhost:8000/predict", json=payload, timeout=5)
assert r.status_code == 200
j = r.json()
assert "output" in j
アーティファクト管理とリリース
モデルは単なるバイナリでなく、メタデータを持つ『リリース資産』です。第56回（モデル資産カタログ）と連携することを想定してください。
- 保存先：モデルレジストリ or オブジェクトストレージ（S3等）
- メタデータ：release_tag（kpi基準）、training_data_id、evaluation_report_url
- 署名と保存：CIパイプライン中でアーティファクト作成→ハッシュ・署名→保存
- リテンション：本番で使用中のものは長期保持、古いは自動削除ルール
デプロイ実装パターン
代表的パターンと使い分けです。
- バルクデプロイ：少数のモデルを一括更新。スケールメリットあるがリスクも高い。
- カナリー／フェイルオーバー：段階的にトラフィックを移す。問題検出時は簡単に戻せる。
- ブルーグリーン：全トラフィックを切り替える。確実性は高いがリソースコストが増える。
CIから呼べるシンプルなPythonデプロイラッパー例：
# ci/deploy.py
import sys
def deploy(model_uri, stage):
# 実際はAPI呼び出しやkubectl等で行う
print(f"Deploying {model_uri} to {stage}")
if __name__ == '__main__':
deploy(sys.argv[1], sys.argv[2])
GitHub Actions の簡単な雛形（断片）:
name: Model CI
on: [push]
jobs:
build-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run tests
run: pytest -q
deploy-staging:
needs: build-test
runs-on: ubuntu-latest
steps:
- name: Deploy to staging
run: python ci/deploy.py s3://bucket/model.tar.gz staging
ロールバックと障害時対応
自動ロールバックは、事前定義した閾値に達したときに自動実行するか、あるいは運用担当の承認で行うかを決めます。第46回の運用手順書と合わせて使うと実務で回しやすくなります。
- トリガー例：エラーレートが基準を超える、p95レイテンシが閾値超過、ビジネスKPI悪化
- 実行手順（簡易版）:
- 自動検知 → アラート発出
- 自動/手動判定（運用担当）
- ロールバックコマンド実行（以前の安定版を再度デプロイ）
- 事象解析とポストモーテム
- Runbookに必須の項目：緊急連絡先、ロールバックコマンド、監視の参照先、エスカレーション手順
運用との接続
CI/CDに監視と承認を組み込むことが重要です。デプロイ直後に短時間の自動検証ジョブ（smoke test）を回し、その結果に応じてカナリーの拡大やロールバックを行います。
- 自動検証ジョブ：デプロイ直後の軽量テスト（10〜15分の観察窓）
- フィードバックループ：本番の誤応答やユーザー報告にタグを付け、再学習トリガーへ接続（第61回との連携案）
コスト・ガバナンスと承認フロー
デプロイ頻度やステージング環境の数はコストに直結します。承認ゲートは自動化と人判断のバランスを取りましょう（第54回の承認ワークフローを参照）。
- コスト対策：ステージングはオンデマンド起動、性能テストは夜間バッチで実行
- 承認ゲート例：主要KPI改善が確認できる場合のみ自動承認、それ以外は人承認
- 監査ログ：CIの全ステップでメタデータ（誰が、いつ、どのモデルを）記録
実践リポジトリとワークショップ案
記事を読んだ後に試せるミニハンズオン案です。
- サンプルrepo構成（最小）:
- src/: 推論コード
- models/: サンプルモデルアーティファクト
- tests/: pytest スクリプト
- ci/: デプロイスクリプト、workflow雛形
- 実行手順概要：ローカルでサーバを立てる → pytest を実行 → CIワークフローでstagingへデプロイ → カナリーで観察
- 次に学ぶべきトピック：SLA設計、マルチテナントCI/CD、コスト最適化の詳細
成果物フォーマット
本記事はWordPressへそのまま貼れるHTML構成（h2/h3/p/ul/li/table）で作成しています。必要なコードは短めのPythonスニペットとして掲載していますので、コピーして試してください。
まとめ
- モデル用CI/CDは「アーティファクト＋メタデータ＋観察窓」を明確にすることが鍵です。
- 自動テストは多層化（ユニット→E2E→性能→スナップショット）し、段階的デプロイ（カナリー等）でリスクを下げる。
- ロールバックと運用の接続を事前に定義し、承認や監査ログをCIに組み込むことで現場で回せる運用になる。
次回以降では、具体的なSLO設計やコスト最適化の方法を取り上げます。まずは本記事のチェックリストとミニハンズオンから始めてみてください。