MLOps と LLMOps の統合

この記事の目的

既存の ML 基盤・ML チームを持つ組織で、LLM アプリの運用(LLMOps)を二重投資なく統合できるようになります。従来の MLOps と何が共通で何が違うのかを整理し、再利用できる既存基盤・できない部分を見極め、役割分担とツール選定の方針を持ち帰れる状態を目指します。個別領域(バージョニング・プロンプト管理・可観測性)の設計は各正本に譲り、本記事は組織・基盤をどう統合するかに絞ります。

対象読者

既に MLOps 基盤・ML チームがある組織で、LLM アプリ運用の立ち上げ・統合を担うプラットフォーム/ML リード
「LLMOps を別立てすべきか、既存 MLOps に載せるべきか」を判断したいテックリード

前提知識

バージョニング・デプロイ・モデル更新追従 — LLM アプリの資産・変更管理の正本(本記事はその組織統合)
プロンプト管理とバージョニング — 「プロンプトという新資産」の管理の正本

本文

概要: LLMOps は MLOps の「別物」ではなく「差分」

LLMOps は MLOps を捨てて作り直すものではありません。多くは再利用でき、一部が本質的に異なるという差分で捉えるのが実務的です。本記事は個別領域の設計(バージョニング・プロンプト管理・可観測性)を各正本に委ね、それらを組織と基盤としてどう束ねるかを扱います。

共通点と相違点

以下は、自社学習の予測モデルと、外部モデルを使う生成アプリを比較するための代表例です。MLOps 全体が決定的・単一指標という意味ではありません。従来の ML でも不確実性・安全性・公平性・費用を測り、変更頻度は業務と運用体制に依存します。

観点	MLOps(従来)	LLMOps(LLM アプリ)
中心資産	自作モデル(重み)	プロンプト・RAG・エージェント構成(多くはモデルを借りる)
実験管理	ハイパラ・データセット	プロンプト・モデル・構成の版
評価	正解ラベルに対する精度・較正・公平性・運用費用等	自由文・実行過程・副作用も含む品質・安全・コスト
変更サイクル	データ・特徴量・学習・配信の更新	左記に加えて、学習を伴わないプロンプト・検索・ツール更新
監視	データドリフト・精度劣化	品質・コスト・レイテンシ・安全シグナル

共通(再利用できる発想): 実験管理・バージョニング・監視・データパイプラインという運用の骨格は共通です。「変更を記録し、比較し、監視する」構図は変わりません
LLM アプリで追加しやすい論点: (1) モデル提供者の更新との依存関係、(2) プロンプト・検索設定・ツール定義の組み合わせ、(3) 自由文や実行結果の評価、(4) 学習を伴わない変更のリリース管理。既存基盤がどこまで扱えるかを機能ごとに確認します

再利用できる既存基盤・できないもの

既存 MLOps 基盤のうち、そのまま活きるもの・作り替えが要るものを仕分けます。

再利用できる: 実験管理(記録・比較の仕組み)、監視基盤(メトリクス・アラート)、データパイプライン(ETL・特徴量の一部)、CI/CD、権限・監査の基盤。これらは LLM でも土台になります
作り替え・追加が要る: プロンプトの版管理(プロンプト管理とバージョニング)、LLM 特有の評価(確率的・LLM-as-a-Judge)、トークン単位のコスト監視(コスト管理)、トレース(プロンプト・ツール呼び出しの記録可観測性とトレーシング)
仕分けの原則: 「変更を記録・比較・監視する骨格」は再利用し、「何を資産とし、何を指標とするか」は LLM 用に足す、と考えます

役割分担

組織にすでに ML チームがある場合、誰が何を持つかを決めないと責任が曖昧になります。

ML チーム: 従来の ML モデル、そして LLM のファインチューニングを始めたときの学習パイプライン。モデルを「作る」側の知見
LLM アプリチーム: プロンプト・RAG・エージェント構成・アプリ品質。モデルを「使って作る」側
プラットフォームチーム: 共通基盤(ゲートウェイ・監視・実験管理・CI/CD)。両者が乗る土台を提供(LLM ゲートウェイの設計)
境界を明示する: とくに「モデルを借りる(アプリチーム)」と「モデルを作る/FT する(ML チーム)」の境界を決めます。曖昧だと、FT を始めた途端に責任が宙に浮きます

ツール類型: 特化型 vs 既存拡張

LLMOps のツールは、大きく 2 類型です。どちらを選ぶかは既存資産の量で決まります。

LLM 特化型ツール: プロンプト管理・トレース・評価を LLM 向けに作り込んだ専用ツール。ゼロから立てるなら早いが、既存 MLOps と二重になりやすい
既存 MLOps の拡張: 既存の実験管理・監視基盤に LLM 用の記録・指標を足す。既存資産が厚い組織はこちらが二重投資を避けられる
判断軸: 既存 MLOps 基盤の成熟度・LLM の利用規模・組織の分業体制で選びます。「既存基盤が薄い/小規模 → 特化型で早く」「既存基盤が厚い → 拡張で統合」が目安です

ファインチューニングを始めたときの合流点

多くの LLM アプリは「モデルを借りる」だけですが、ファインチューニングを始めた瞬間に MLOps と合流します。

学習パイプラインが復活する: FT を始めると、学習データの管理・学習ジョブ・モデル版の管理という、従来 MLOps の領域が必要になります(ファインチューニングと蒸留)
既存 MLOps の出番: ここは ML チーム・既存基盤の強みが活きる場面です。FT を「アプリチームだけで抱える」と、学習運用のノウハウを再発明することになります
合流点を設計しておく: 最初は借りるだけでも、「FT を始めるならここで ML 基盤と合流する」という接続点を想定しておくと、いざ FT に進むときに滑らかです

実務での注意点

アンチパターン

LLMOps を既存 MLOps と完全別立てにする → 実験管理・監視・CI/CD を二重に持ち、投資が重複する → 再利用できる骨格は流用し、LLM 固有部分だけ足す
既存 MLOps で全部足りると過小評価する → プロンプト資産・確率的評価・トークンコスト監視が抜ける → LLM 固有の資産・指標を追加する
モデルを借りる/作るの境界を決めない → FT を始めた途端に責任が宙に浮く → アプリチームと ML チームの境界を明示する
既存資産を見ずにツールを選ぶ → 特化型と既存基盤が二重になる → 既存 MLOps の成熟度で特化型か拡張かを選ぶ
評価を精度の単一指標だけで済ませる → 費用・遅延・安全性・振る舞いの問題を見逃す → 従来 ML でも行う多面評価に、生成内容・ツール実行・権限逸脱の観点を追加する

チェックリスト

MLOps と LLMOps の共通点(骨格)と相違点(資産・評価・サイクル)を整理した
再利用できる既存基盤とできない部分を仕分けた
ML チーム / LLM アプリチーム / プラットフォームチームの役割と境界を決めた
「モデルを借りる/作る(FT)」の境界を明示した
既存 MLOps の成熟度に応じて、特化型ツールか既存拡張かを選んだ
FT を始めるときに ML 基盤と合流する接続点を想定している

参考資料

Google Cloud — MLOps: Continuous delivery and automation pipelines in machine learning — 実験・検証・メタデータ管理・配信・本番監視をつなぐ運用の骨格(アクセス日: 2026-09-10)
MLflow — Prompt Registry — プロンプトの版や参照を既存の ML プラットフォームへ加える実装例。本文の組織分担はこれらを参考にした本記事の設計例です(アクセス日: 2026-09-10)

TODO・未確認事項

なし