はじめに

前回の記事ではMLOPsで活用される技術スタックをミニマムなハンズオン形式で投稿しました。今回は私が直近で学んだ内容として「AWSリソースも用いたMLOPsパイプラインの全体像、MLOPsにおける重要な考え方、カンコツ」を読者の皆さんが体系的に学べるよう(+自分用の備忘録として)記事にまとめます。

こんな人に読んでほしい

MLモデル作成の知識はあるが、本番環境へのデプロイや運用全体の流れ（パイプライン設計）を学びたい方。
通常のシステム開発・インフラ運用の知識は豊富だが、機械学習システム特有の課題や「継続的学習（CT）」の仕組みを理解したい方。
プロジェクトにMLOpsを導入する本質的なメリットや、どのようなコンポーネントが必要なのか全体像を掴みたい方。

１．MLOpsの必要性

機械学習（ML）プロジェクトに関わる人が、最初に突き当たる大きな壁としての一つとして「ローカル環境やNotebook上で高精度なモデルを作れたのに再利用できる形にするのが難しい、継続的に運用できない」などの問題があるかと思います。
そこで必要になってくるのがMLOPsです。

1-1. MLOpsの定義

MLOPsの定義に対する誤解として、「MLOps ＝モデルの学習を自動化すること」というものがよくあります。しかし、これはMLOpsのほんの一部にすぎません。

MLOpsの真の定義は機械学習モデルの開発から本番運用、そこで継続的な改善に至るライフサイクル全体を迅速かつ安定して回すための「システム全体設計とプロセス」です。

具体的には、以下の6つのプロセスを終わりのないループ（フィードバックループ）として継続運用します。

データ収集・管理: 常に最新のデータを安全に蓄積し、分析可能な状態にする。
モデル学習: 再現性を担保した上で、データを元にモデルを自動的に学習する。
デプロイ: 学習したモデルを安全かつ迅速に本番システムへ反映する。
推論: ユーザーやサービスからの要求に対し、高精度な予測値を返す（リアルタイム/バッチ）。
監視（モニタリング）: 本番環境のデータやモデルの予測精度、システム負荷を常に監視する。
再学習: 精度劣化やデータの変化を検知し、自動的（またはトリガーベース）にデータを更新して学習し直す。

このように、MLOpsとは「単発のモデル構築」ではなく、「MLシステムを壊さずに継続運用するためのライフサイクル設計」そのものを指します。

1-2. なぜ「学習コード」だけでは不十分なのか？

「モデルを学習して保存するコードが書けたのだから、あとはそれをサーバーで動かすだけで十分では？」と思うかもしれません。しかし、本番運用においては、学習コードはシステム全体のごく一部にすぎません。

Googleが発表した有名な論文「Hidden Technical Debt in Machine Learning Systems（機械学習システムにおける隠れた技術的負債）」では、システム全体における「MLコード（学習コード）」の割合を以下のように視覚的に表現しています。

本番の機械学習システムを安定稼働させるためには、MLコードの周囲にある以下のような「周辺基盤」がすべて必要になります。

インフラ管理: 学習や推論に必要なサーバー、コンテナ（Docker）、GPUなどの割り当て。
データと特徴量の管理: 生データから推論に必要な「特徴量」への一貫した変換（Training/Serving Skewの防止）。
モデルのバージョン管理: どのデータとどのコードを使って作られたモデルなのかを追跡可能にする（再現性の確保）。
API化とサービング: アプリケーションから安全に呼び出せるインターフェースの提供。
監視とアラート: 本番データの傾向が変わったこと（データドリフト）を検知し、モデルをロールバックまたは再学習する仕組み。

これら周辺基盤を整備しないまま本番運用を開始すると、障害発生時に原因の特定ができなくなったり、いつの間にかモデルの予測精度がボロボロになっていたりする「沈黙の障害」に直面することになります。

1-3. MLOpsの本質

MLOpsの本質は機械学習をインフラからアプリケーション開発にまたがる『CI/CD（継続的インテグレーション/継続的デプロイ）』および『継続運用』のフローへ組み込むことにあります。

従来のシステム開発（DevOps）と、機械学習開発（MLOps）の最大の違いは、管理対象の要素にあります。

従来のDevOpsの管理対象: 「コード」 のみ。
- コードをビルドし、テストが通ればデプロイする。
MLOpsの管理対象: 「コード」＋「データ」＋「モデル」 の3つ。
- プログラムコードが一切変わっていなくても、インプットされるデータ（市場やユーザーの行動など）が変われば、モデルの予測精度（＝出力）は劣化します。

そのため、MLOpsでは「コードの変更」だけではなく、「データの変化」をトリガーにして、自動的に学習・テスト・デプロイが回る仕組み（継続的学習：CT = Continuous Training）が必要不可欠です。

２．全体アーキテクチャとデータ・特徴量管理

1章では、MLOpsが「単なるモデル作り」ではなく「機械学習を継続運用するためのシステム全体設計」であること、そして「コード＋データ＋モデル」を管理する複雑さについて解説しました。

2章では、実践に即したMLOpsの全体アーキテクチャを紐解き、その成否を分ける「データ」と「特徴量（Feature）」の管理手法について解説します。

2-1. MLOpsの全体アーキテクチャ（オンラインとバッチの融合）

MLOpsを理解する上で重要なのが、「オンライン（推論API）側」と「バッチ（学習・変換）側」がどのように繋がり、協調して動くのかという全体像を把握することです。

図に起こすと少し複雑になってしまいますが以下にAWSリソースを用いた構成例を示します。少しでもわかりやすくするために、MLパイプライン、CI/CD、推論APIごとの箱分けとMLパイプライン起点の矢印を赤にしております。

ポイント：「推論を行うオンラインAPI」と「モデルを作る学習パイプライン」が、S3（モデルストレージ）とFeature Store（特徴量ストア）を介して疎結合（綺麗に分離）されている。またCI/CDによってモデル、データ、推論APIが一括管理される。

2-2. MLOpsで管理すべきもの

データ

機械学習システムにおけるデータは、ただ保管すれば良いわけではありません。データは以下のように姿を変えていきます。

raw data (生データ) ──> 前処理 (加工) ──> 特徴量 (モデルに入力する数値)

このライフサイクルの中で、MLOpsが管理・担保しなければならないのは以下の5つの要素です。

データ品質 (Quality): 異常値やフォーマットの崩れがないか。
スキーマ (Schema): データの構造（列名や型）が意図せず変更されていないか。
欠損 (Missing): 必要な値が抜け落ちていないか。
ドリフト (Drift): 本番環境に流れてくるデータの分布が、学習時のデータから変化していないか。
バージョン (Version): 「どの時点のデータ」を使ってモデルを学習したのか。

AWSにおけるデータ基盤構成例

実務において、これらのデータパイプラインを処理するために非常によく使われるAWSの構成パターンは以下の通りです。

目的	AWSサービス名	実務での役割
Data Lake	Amazon S3	とにかく大量の生データ（raw data）を安全・安価に保存する場所。
ETL	AWS Glue	S3内の生データをクレンジングし、機械学習用の「特徴量」に加工する。
SQL分析	Amazon Athena	S3に保存されたデータに対して、サーバーレスで直接SQLクエリを投げて中身を分析する。
ストリーム	Amazon Kinesis	ユーザー行動ログなどのリアルタイムデータを途切れなく収集し、S3へ流し込む。

特徴量（Feature）

MLOpsを構築する上で、エンジニアが最も頭を悩ませ、かつ最も重要なのが特徴量（Feature）の管理です。

なぜ特徴量管理がそれほど重要なのか？

それは、「学習時と推論時で特徴量の計算ロジックがズレると、モデルの精度が致命的に崩壊する」からです。

この現象を Training/Serving Skew（学習と推論の乖離） と呼びます。

【具体例】売上予測システムでの Training/Serving Skew

例えば、店舗の売上予測モデルに「過去7日間の平均売上」という特徴量を入力するとします。

学習時（バッチ処理）: PythonのPandasで「df['sales'].rolling(7).mean()」と綺麗に計算して学習させた。
推論時（本番API）: アプリケーション開発者が、スピード優先で「直近1週間の売上をSQLで集計して合計し、単純に7で割る」というAPI側のロジックを独自に書いた。

一見同じに見えますが、「欠損値の扱い」「端数処理の丸め方」「時差（タイムゾーン）の計算」などが1ミリでもズレていると、モデルは学習時とまったく異なる数値を受け取ることになり、予測精度はガタガタになります。

2-3. Feature Store（特徴量ストア）

Training/Serving Skewを防ぎ、学習と推論の双方で「全く同じ特徴量計算ロジック」を共有するために導入されるのが Feature Store（特徴量ストア） という概念です。

Feature Storeは、役割に応じて以下の2種類を使い分けます。

① Offline Feature Store（学習用）

大量の過去データを蓄積し、モデルの学習に最適化されたストレージです。リアルタイム性は不要ですが、スループット（データの一括取得能力）が求められます。

AWS構成例: Amazon S3, Amazon Redshift, Snowflake
用途: 過去数年分の特徴量をまとめて抽出し、ECS/Fargate等の学習ジョブに流し込む。

② Online Feature Store（リアルタイム推論用）

推論API（FastAPI等）が、ユーザーの要求に対してミリ秒単位で超高速に特徴量を取得するためのストレージです。最新の1レコードをキー（例：user_id）で即時に引ける必要があります。

AWS構成例: Amazon DynamoDB, Redis
用途: APIが「ユーザーAの直近のアクション特徴量」をDynamoDBからミリ秒で取得し、モデルに入力して推論する。

ケースバイケースですがコストパフォーマンスと構築のシンプルさの観点からOffline（S3）と Online（DynamoDB）の組み合わせが採用されることがよくあるみたいです。

３．モデル学習パイプラインとDocker化

2章では、MLOpsにおける「データ」と「特徴量（Feature）」の管理、そしてTraining/Serving Skew（学習・推論時の特徴量ズレ）を防ぐための「Feature Store」について解説しました。

3章では、加工された特徴量を用いてモデルを自動生成する**「モデル学習パイプライン」と、環境依存を完全に排除して再現性を担保するための「Docker化」**の重要性について解説します。

3-1. モデル学習パイプラインの典型構成

機械学習のモデル構築は、データサイエンティストが手動でスクリプトを叩くのではなく、「定義された一連のステップ」として自動実行可能なパイプラインにする必要があります。

一般的な学習パイプラインは、以下のステップで進みます。

データ抽出 ──> 前処理 ──> 特徴量生成 ──> モデル学習 ──> モデル評価 ──> モデル登録

データ抽出: Data Lake（S3等）から必要な期間・対象の生データをクエリする。
前処理（ETL）: 欠損値の穴埋め、外れ値の除外などを行い、クレンジングする。
特徴量生成: モデルの学習に入力可能な特徴量ベクトルを計算し、Offline Feature Storeへ保存する。
モデル学習: アルゴリズム（LightGBM, PyTorch等）にデータを投入し、最適なパラメータ（重み）を決定する。
モデル評価: テストデータを使ってモデルの精度（Accuracy, AUC等）を算出し、本番環境の基準を満たしているか検証する。
モデル登録: 基準をクリアしたモデルのメタデータ（精度や作成日時）とモデル本体ファイルをレジストリに保存する。

3-2. AWSによる学習パイプラインの構築例

定番のAWSを用いた構築パターンが以下になります。

① AWS Step Functions （ワークフロー制御）

パイプラインの各ステップ（特徴量生成 ──> 学習 ──> 評価 ──> デプロイ）を正しい順序で実行し、エラーハンドリング（再試行やアラート通知）を行う司令塔です。

  [特徴量生成 (Feature Extraction)]
                 │
                 ▼
        [モデル学習 (Training)]
                 │
                 ▼
        [モデル評価 (Evaluation)]
         /               \
   (基準クリア)       (基準未満で異常終了)
       /                   \
      ▼                     ▼
  [デプロイ (Deploy)]     [通知/終了]

② AWS ECS / Fargate （学習ジョブの実行環境）

Step Functionsの指示を受け、コンテナ（Docker）上で実際に重い学習スクリプトを走らせるための実行基盤です。

3-3. なぜ「ECS/Fargate」なのか？

「AWSで機械学習をするなら Amazon SageMaker を使うべきでは？」と思う方もいるかもしれません。SageMakerも強力なML専用サービスですが、実務の現場（特にWebシステムへの組込み）ではECS/Fargateを選択するケースがあります。

その理由は以下の3点です。

圧倒的な自由度の高さ:
- SageMaker独自のPython SDKやコンテナのルールに縛られず、使い慣れた通常のDockerイメージで学習ジョブを実行できるため、ライブラリのバージョン競合などで悩む時間が激減します。
Dockerベースのローカル再現性:
- ローカルPCのDocker上で動かした学習コードが、インフラの設定（AWS）を一切変えることなく、そのままクラウドのFargate上で100%同じ挙動で動きます。
Webシステム開発との技術統一感:
- すでに本番システムでECSやEKS（Kubernetes）を使っている場合、「同じインフラ監視手法」「同じデプロイ手法（CI/CD）」「共通のインフラ知識」でML基盤も運用できるため、運用コストが劇的に下がります。

これもケースバイケースで、推論対象や組織によりやり方は様々です。

3-4. なぜ MLOps では Docker が必須なのか？

以前の記事でもDockerの意義については軽く触れましたが、機械学習の世界では、ライブラリ（Python, PyTorch, LightGBM等）のアップデートが非常に激しく、「パッケージのバージョンが1つズレるだけで、モデルの精度が変わる、あるいは動かなくなる」というトラブルが日常茶飯事です。

これを防ぎ、インフラから学習環境を100%固定するために Docker（コンテナ） は必須です。

ECSで学習ジョブを走らせるための Dockerfile 例

以下は、実務で実際に使われる、学習ジョブ用の最もシンプルな Dockerfile の構成例です。

FROM python:3.12-slim

WORKDIR /app

# 依存ライブラリのインストール
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 学習スクリプトのコピー
COPY src/ ./src/

# コンテナ起動時に学習ジョブを実行し、終わったらコンテナを自動終了する
ENTRYPOINT ["python", "src/train.py"]

ポイント解説

FROM python:3.12-slim: OSやPython環境のバージョンを完全に固定します。slim イメージを使うことで、コンテナのサイズを小さく抑え、Fargateの起動を高速化しています。
COPY requirements.txt .: インストールする各種機械学習ライブラリのバージョンをここで厳密に固定し、環境の完全な再現性を担保します。
ENTRYPOINT: コンテナが起動した瞬間に自動的に train.py（学習スクリプト）が実行されるように定義しています。学習処理が終わるとコンテナが自動で停止するため、「起動している時間だけ課金される」というFargateのコストメリットを最大限に活かせます。

４．モデル管理、推論サーバー、そして「監視（Monitoring）」

3章では、AWS Step FunctionsとECS/Fargateを用いてモデルの自動学習パイプラインを構築する手順と、再現性を担保するためのDocker化について解説しました。

4章では、完成したモデルをバージョン管理する「Model Registry」、それを外部から利用可能にする「推論サーバー」、そしてMLOps運用において最も重要な命綱となる「監視（Monitoring）」の設計について解説します。

4-1. モデル管理と Model Registry

従来のソフトウェア開発では、成果物は「コンパイルされたプログラムコード」のみであり、Git（GitHub）でバージョン管理すれば十分でした。

しかし、機械学習の世界ではそうはいきません。なぜなら、成果物であるモデルは、以下の3つの要素の掛け算で構成されているからです。

モデル ＝ プログラムコード × 重み（パラメータファイル） × 学習に使ったデータ

コードが1行も変わっていなくても、学習データが変わればモデルの挙動は180度変わります。また、モデルのバイナリファイル（重み）は数十MB〜数百GBと非常に巨大なため、Gitで管理することは不可能です。

そこで必要となるのが Model Registry（モデルレジストリ） という概念です。

DynamoDB を使ったモデルメタデータの管理例

データベース（Amazon DynamoDB）を用いて、学習されたモデルの「履歴と評価値（メタデータ）」を以下のように管理する。

管理項目	格納データの例	役割
version	`v12`	モデルの世代番号（順次インクリメント）。
accuracy	`0.912`	学習時・評価時の検証データに対する予測精度スコア。
作成日時	`2026-05-18T12:00:00Z`	モデルが学習されたタイムスタンプ。
S3 path	`s3://my-mlops-bucket/models/v12/model.tar.gz`	実際のモデルバイナリファイルが保存されているS3の場所。

このテーブルを参照することで、システムは「どのモデルが最も優秀か」「現在どのバージョンが稼働しているか」を動的に把握し、必要に応じて古いバージョンへ瞬時にロールバック（巻き戻し）できるようになります。

4-2. 推論サーバー（FastAPI）の構築

登録されたモデルを用いて、外部のアプリケーションやユーザーからの要求に対して予測結果を返すのが推論サーバーです。

一例として高速でモダンなPythonフレームワークである FastAPI を用いて推論APIを構築した例です。

リアルタイム推論APIの実装イメージ

推論APIは、リクエストを受け取ってから結果を返すまでに、内部で以下の処理をミリ秒単位で超高速に処理します。

from fastapi import FastAPI
import boto3
import joblib

app = FastAPI()

# S3から学習済みモデルをロード (実際には起動時や定期更新時に実行)
s3 = boto3.client('s3')
s3.download_file('my-mlops-bucket', 'models/latest_model.joblib', '/tmp/model.joblib')
model = joblib.load('/tmp/model.joblib')

@app.post("/predict")
def predict(user_id: str):
    # ① Online Feature Store (DynamoDB) からユーザーの最新特徴量を取得
    features = get_features_from_dynamodb(user_id)
    
    # ② 特徴量をモデルに入力して推論実行
    prediction = model.predict([features])
    
    # ③ 予測結果をJSONで即時返却
    return {"user_id": user_id, "prediction": int(prediction[0])}

ポイント解説

FastAPI: Pythonで非常に高速に動作するWebフレームワークで、型ヒントを用いたリクエスト検証や、API仕様書（Swagger UI）の自動生成が可能です。
get_features_from_dynamodb: 第2章で解説した「Online Feature Store（DynamoDB）」から、その user_id に紐づく特徴量（例：直近のクリック数など）をミリ秒で引いてきます。これにより、API側で重い計算処理をする必要がなくなり、Training/Serving Skew（学習と推論の乖離）も完全に防げます。
model.predict: 読み込まれたモデルに特徴量を与えて予測を行い、即座にレスポンスを返します。

推論方式の使い分け

実務における機械学習の推論には、システムの要件に応じて主に2つの方式があります。

推論方式	処理イメージ	具体例	メリット / デメリット
リアルタイム推論	APIに対してリクエストを投げ、即時に予測結果を得る。	広告のクリック率（CTR）予測、推薦（レコメンド）、クレカ不正検知。	メリット: 最新のデータに基づいて即時予測可能。デメリット: 常時サーバーを稼働させるためコストが高く、ミリ秒単位の応答速度（レイテンシ）制限が厳しい。
バッチ推論	数時間〜日次などの間隔で、大量のデータをまとめて一括で予測し、DBに保存しておく。	翌日の店舗の売上予測、月次のユーザー解約率予測、需要予測。	メリット: 夜間などの空き時間にまとめて計算できるためインフラ効率が良く安価。デメリット: リアルタイムな状況変化に対応できない。

4-3. 監視（Monitoring）

MLOpsと、通常のソフトウェア運用（DevOps）を隔てる違いの一つが、この「監視（Monitoring）」の設計です。

通常のシステムでは、「サーバーが起動しており、メモリやCPUに余裕があり、エラーコード（500エラー等）を吐いていない」＝「正常に動いている」と判定します。しかし、機械学習システムでは、エラーを全く吐かずに「無言で間違った予測をし続ける」という沈黙の障害が発生します。

そのため、MLOpsでは「システム監視」に加えて、「ML固有の監視」を組み込む必要があります。

(A) システム監視 (AWS: CloudWatch)

通常のWebシステムと同様に、CPU・メモリ使用率、APIのレイテンシ、HTTP 5xxエラー率などを監視します。

(B) ML監視

本番稼働中のデータの健全性を監視するため、以下の3つの指標をトラッキングします。

データドリフト (Data Drift)

本番環境に入力されるデータの分布が、学習時のデータから変化してしまう現象です。

例: ECサイトの推薦モデルにおいて、学習時は「20代〜30代のユーザー行動データ」が中心だったが、本番環境で「60代〜70代のシニアユーザー」が急増した。モデルに入力される「年齢」の平均値が大きくズレるため、モデルの予測精度は低下します。

Concept Drift (Concept Drift)

データそのものの分布は変わっていなくても、社会情勢やユーザーの価値観が変わり、「入力に対する正解ルール（関係性）」が変わってしまう現象です。

例: 旅行の需要予測モデルにおいて、新型コロナウイルスの流行により、「休日＋晴れ＝旅行客増加」という従来のルールが突如崩壊した。市場のルール自体が変わるため、古いモデルは役に立たなくなります。

精度劣化 (Accuracy Decay)

本番環境の予測結果を後から実際の正解データ（数日〜数週間後に確定する）と突き合わせることで、実質的な本番精度（AccuracyやF1スコアなど）がどれくらい下がっているかを直接計測します。

５．継続的学習（CT）とCI/CD、AWS構成パターン

4章では、モデルレジストリによるバージョン管理、FastAPIを用いた推論APIの構築、そしてデータの劣化を検知する「データドリフト・コンセプトドリフト監視」について解説しました。

5章では、検知した劣化に対してモデルを自動でリフレッシュする「継続的学習（Continuous Training: CT）」、MLOpsにおける「CI/CD」の設計、指示されたインフラ構成における「AWS構成パターン」や「最重要設計思想」について徹底解説します。

5-1. 継続的学習（CT）の自動フィードバックループ

4章で解説した「ML監視（データドリフトや精度劣化）」は、ただアラートを鳴らすだけでは意味がありません。真価を発揮するのは、監視から得られたフィードバックを元に、自動でモデルを再学習・更新するサイクル（CT）を構築した時です。

  [監視 (Monitoring)] ──(ドリフト/精度低下を検知)──> [再学習パイプライン起動]
          ▲                                                 │
          │                                                 ▼
  [新しいモデルの配信] <──(自動テスト合格 & デプロイ)─── [モデル再評価]

この自動サイクルがMLOpsの特徴の１つです。

5-2. MLOpsにおける CI/CD と通常 DevOps の違い

「すでに通常のシステムでCI/CD（継続的インテグレーション/継続的デプロイ）を回しているから、MLOpsも同じでしょ？」と思われがちですが、その中身は決定的に異なります。

従来の DevOps の CI/CD

管理対象: プログラムコード のみ。
CI（ビルド＆テスト）: コードのコンパイル、構文エラーチェック、単体テスト。
CD（デプロイ）: 実行可能な成果物（バイナリやコンテナ）を本番環境へ配置。

MLOps の CI/CD

管理対象: コード＋データ＋モデル。
CI (インテグレーション):
- コードのテストだけでなく、入力される「データの品質テスト（スキーマ検証など）」を実施する。
- 学習が完了した「モデルの品質テスト（検証データによる精度やバイアスの検証）」を実施する。
CD (デプロイ):
- 単にサーバーを入れ替えるだけでなく、「モデルサービングAPI」への安全なデプロイ（一時的なA/Bテストや、旧モデルへの迅速なロールバック体制の確保）を行う。

5-3. GitHub Actions の活用と CI/CD 実装例

実務において、これらのコードテストやコンテナイメージのビルドを自動化するためによく使われるのが GitHub Actions です。

以下は、MLOpsにおける一般的なCI/CDの最も基礎的なワークフロー構成例（.github/workflows/mlops-pipeline.yml）です。

name: MLOps CI/CD Pipeline

on:
  push:
    branches: [ main ]

jobs:
  test_and_build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v3
      
      - name: Setup Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.12'
      
      - name: Install dependencies and Lint
        run: |
          pip install flake8 pytest
          flake8 src/
          pytest tests/
          
      - name: Build Docker Image
        run: |
          docker build -t my-mlops-image:latest .
          
      - name: Push to Amazon ECR
        run: |
          # AWS認証情報を使ってECRにログインしてプッシュする (疑似コード)
          echo "AWS ECR Login & Push"

ポイント解説

on: push: main ブランチにソースコードがプッシュ（またはPRマージ）されたことをトリガーに、自動的に実行されます。
flake8 & pytest: Pythonコードの静的解析（スタイルチェック）と、前処理ロジックなどの単体テスト（Unit Test）を自動実行し、バグのあるコードがビルドされるのを防ぎます。
Build Docker: テスト合格後、第3章で作成した Dockerfile を用いて、環境に依存しないコンテナイメージを自動ビルドします。
Push ECR: ビルドされたイメージをAWSのコンテナレジストリ（Amazon ECR）にプッシュし、本番環境（ECS/Fargate等）が常に最新の環境をロードできるように同期します。

5-4. AWSでよく使う構成パターン比較

実務におけるMLOpsインフラの構築パターンは、システムの規模や組織の成熟度によって異なります、以下はインフラ規模違いにおける例です。

レイヤー	① 小〜中規模構成（本リポジトリに近い構成）	② 大規模構成（かつAWSリソース以外）
主な用途	実運用を意識した最小構成。コストと学習コストを最小化したい場合。	大規模なMLチーム、数万件以上のリクエスト、数多くのモデルを運用する場合。
インフラ基盤	AWS ECS / Fargate（サーバーレスコンテナ）	EKS (Kubernetes)
パイプライン制御	AWS Step Functions	Argo Workflows / Kubeflow Pipelines
データ / ETL	S3 / AWS Glue / Amazon Athena	Snowflake / Spark (EMR)
特徴量管理	DynamoDB（Online）＋ S3（Offline）	Feast（本格的なFeature Storeツール）
実験・モデル管理	DynamoDB（メタデータ）＋ S3（本体）	MLflow / Weights & Biases
監視	Amazon CloudWatch	Prometheus ＋ Grafana ＋ ML監視専用SaaS

これも組織やビジネス、推論対象によって様々な構成が考えられますが、最初は「① 小〜中規模構成」を参考に始めるといいかもしれません。Kubernetesなどの知見がない状態で最初からKubernetesやKubeflowなどの大規模ツール群を導入すると、インフラの管理コストと学習コストが爆発し、MLプロジェクトそのものが頓挫の可能性があります。

5-5. MLOpsで最重要な4大設計思想

高品質なMLOpsを設計する上で、すべてのエンジニアが頭に叩き込んでおくべき「4つのコア原則」があります。

再現性 (Reproducibility):
- 「1ヶ月前のあのモデルをもう一度同じ条件で作って」と言われた際、同じコード、同じDockerイメージ、同じデータバージョンから**「100%同じモデルを再現できること」**。
自動化 (Automation):
- データの変換、学習、評価、デプロイに手動の介入を一切排除すること。「手動によるコピペ作業」は、属人化と本番障害の最大の温床です。
観測可能性 (Observability):
- 「今、本番環境で何が起きているか」がログやメトリクス、ドリフト監視によって常に見えている状態にすること。
スケーラビリティ (Scalability):
- モデルのサイズ拡大、データ量の増加（GPUの追加など）、および推論アクセスの急増（Auto Scaling）にインフラが自動で耐えられる設計にすること。

5-6. インフラの再現性を担保する IaC (Terraform) の重要性

MLOpsにおいて「再現性」が求められるのは、コードやデータだけではありません。「インフラ環境そのもの」の再現性も決定的に重要です。

AWSのコンソール画面（GUI）からマウスでポチポチと手動で構築したインフラは、「どの設定をどう変えたか」の履歴が残らず、開発環境から本番環境へコピーすることも極めて困難になります。

そこで、インフラをコード化する Terraform（Infrastructure as Code: IaC） を導入します。

TerraformのようなIaCツールを使用するとメリットがあります。

インフラ構成が完全にコード（git管理）され、変更履歴が残る。
terraform apply を実行するだけで、開発・検証・本番の全く同じAWSインフラをミリ単位のズレなく瞬時に複製・再構築できる。

特にTerraformの場合、マルチクラウド戦略（例えばAWS×GCP）にも対応できます。

６．実務のアンチパターン

5章では、継続的学習（CT）のフィードバックループ、MLOpsにおけるCI/CDの設計、AWSの構成パターン、4大設計思想、そしてTerraform（IaC）の重要性について徹底解説しました。

最終章となる6章では、実務で絶対に避けるべき「MLOpsのアンチパターン」とまとめです。

6-1. 実務でよくある失敗（MLOpsのアンチパターン）10選

MLOpsの導入、設計を誤ったりすることで失敗に陥ることがないように「MLOpsのアンチパターン」としてよく指摘されている、代表的な失敗例10選を以下にまとめてみました。

失敗パターン	主な原因	発生する致命的な結果	対策
① Notebookだけで開発・運用	Jupyter Notebookだけで前処理や学習を完結させ、そのまま本番環境で動かそうとする。	再現性が全くなく、コードの管理やAPIとしての本番稼働が不可能になる。	動作検証が終わったら必ずコードをPythonスクリプト化（`.py`）し、Dockerコンテナ化する。
② すべて手動デプロイ	エンジニアがローカルで学習したモデルのファイルを、手動でサーバーにアップロードして入れ替える。	属人化が発生し、「どのモデルが本番で動いているか」がブラックボックス化する（ミスの温床）。	GitHub ActionsなどのCI/CDツールを導入し、デプロイプロセスを100%自動化する。
③ Feature計算の不一致	学習時（バッチ）と推論時（API）で、特徴量の計算コードを別々に記述している。	Training/Serving Skew が発生し、本番環境での予測精度が致命的に崩壊する。	Feature Store を導入し、学習と推論で「全く同じ特徴量ロジック」を一元管理・共有する。
④ 監視をしない（放置）	モデルを一度デプロイした後、エラーを吐いていない（APIが動いている）からと放置する。	データドリフトやコンセプトドリフトが発生し、予測精度が「無言で」劣化し続ける。	CloudWatch やドリフト検知ツールを用い、本番の入力データやモデル精度を常に監視する。
⑤ バージョン管理の欠如	学習済みモデルにバージョン（v1, v2等）を付与せず、単に「`latest_model`」などの名前で上書き保存する。	障害発生時に「どのバージョンが原因か」を特定できず、以前の正常なモデルへのロールバックも不可能になる。	Model Registry（DynamoDB等）を導入し、モデルとメタデータをセットで世代管理する。
⑥ データのバージョン未管理	モデルのコードや成果物（`.bin`など）は管理しているが、学習に使った生データや中間データを保存・追跡していない。	まったく同じコードを動かしても二度と同じモデルを再現できず、不具合時の原因究移が不可能になる。	DVC (Data Version Control) などを導入し、データとコードのバージョンを紐づけて管理する。
⑦ 「壁の向こうへ投げ込む」運用	データサイエンティスト（DS）がモデルを作り、エンジニア（ML / Dev / Ops）に「あとは本番実装よろしく」と丸投げする。	実装不備による手戻り、DSの意図しない本番仕様への変更が発生し、リリースが数ヶ月単位で遅延する。	企画段階からDSとエンジニアがクロスファンクショナルなチームを組み、本番を見据えた仕様を初期から共有する。
⑧ 早すぎる最適化・最初からのフルオート	プロジェクトの初期段階（PoC直後など）から、巨大なオーケストレーターや全自動再学習パイプラインを構築しようとする。	システムが複雑化しすぎて開発スピードが著しく低下。ビジネスの検証が終わる前に予算とリソースを使い果たす。	最初の数回は「手動バッチ」や「シンプルなスクリプト」で運用し、ビジネス価値が証明されてから段階的に自動化する。
⑨ リテイニング（再学習）の盲信	定期的に最新データでモデルを再学習（リトレイン）させ、評価をスキップしてそのまま自動デプロイしてしまう。	異常値（バグやスパムなど）を含んだデータで学習してしまった場合、モデルの精度が急激にクラッシュして本番障害になる。	自動再学習の後に必ず検証ステップ（評価データでの精度判定、前モデルとの比較検証）を挟み、承認されたモデルのみをデプロイする。
⑩ 評価指標とビジネスKPIの乖離	オフライン評価（AUCやRMSEなど）の最適化ばかりに集中し、売上やクリック率、インフラコストなどのビジネス指標を見ていない。	「モデルの精度は上がったのに、売上は全く上がらない」「推論コストが高すぎて、ビジネスとして赤字になる」という本末転倒が起きる。	開発初期にビジネス側と「どのビジネスKPIを動かすためのAIか」を合意し、ABテスト等でビジネス成果を直接評価する。

6-2. おわりに

MLOpsは今後ますます需要が高まる領域であり「実務で使いそうだから勉強をしておく」だけでも、他の分野にも応用が利く知識だと思います。
本記事が、読者様の「実践的なMLOps」への第一歩を踏み出す一助となれば幸いです。最後までお読みいただき、ありがとうございました！

参考文献・参考URL

本記事は以下の書籍や公式ドキュメント、論文を参考にいたしました。より深く学びたい方は、ぜひこちらも合わせてご参照ください。

実践MLOPs　作って理解する機械学習システムの構築と運藤　著：長江　五月
- URL: https://www.ohmsha.co.jp/book/9784274233982/
MLOps: 機械学習における継続的デリバリーと自動化のパイプライン (Google Cloud 公式)
- URL: https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning
Hidden Technical Debt in Machine Learning Systems (Google 研究論文)
- URL: https://papers.nips.cc/paper/2015/hash/86df7ad6c01a9c7940c0ef50d4b0b7f1-Abstract.html