コンテンツへスキップ
← ブログ

DevOps・MLOps・LLMOps：生成AIはいかに本番運用へ進んだか

DevOpsからMLOps、LLMOpsへの検証可能な歴史と、プロンプト、RAG、評価、可観測性、セキュリティ、コストの実践ガイド。

2026年8月5日公開·読了目安 17分
  • DevOps
  • MLOps
  • LLMOps
  • 生成AI
  • プラットフォーム

よくある比較図は、三つのパイプラインを世代交代のように並べます。入口としては便利ですが、本質を隠します。DevOps、MLOps、LLMOpsは競合製品でも、前の段階を置き換える階段でもありません。定義と検証が次第に難しくなった成果物を運用するための答えです。ソフトウェアにはデリバリー自動化が、機械学習にはデータと統計的挙動が、基盤モデルには自然言語のコンテキスト、外部プロバイダー、ツール、意味上のリスクが加わりました。

ソフトウェアデリバリーから機械学習パイプライン、LLM運用までの進化を描いたオリジナル図
一つの系譜と三つの運用範囲：ソフトウェア、学習モデル、複合LLMシステム。

以下では、その変化を確認可能な資料でたどり、特にLLMOpsチームが実際に何を運用するのかを詳しく説明します。MLOpsにもLLMOpsにも、世界的に合意された一つの誕生日はありません。そのため、特定の「発明者」を作らず、検証できる節目を用います。

三つの名前、運用すべき三つの成果物

実践バージョン管理対象主なループ特徴的な障害
DevOpsコード、設定、インフラビルド、テスト、デプロイ、観測回帰、設定、容量
MLOpsコード + データ + 特徴量 + モデル学習、検証、登録、提供、再学習ドリフト、バイアス、training-serving skew
LLMOpsモデル + プロンプト + コンテキスト + 索引 + ツール + ポリシー評価、ルーティング、生成/実行、追跡、学習もっともらしい誤り、インジェクション、ツール悪用

これは固定的な組織境界ではありません。LLM製品にもCI/CD、シークレット、ネットワーク、ロールバック、SLOが必要です。自社で重みを持つなら、データリネージとモデルレジストリも必要です。LLMOpsはDevOpsとMLOpsを拡張するもので、消去するものではありません。

2009年：DevOpsと引き渡しの壁

Velocity 2009で、John AllspawとPaul Hammondは10+ Deploys per Day: Dev and Ops Cooperation at Flickrを発表しました。[flickr] 頻繁なリリースを可能にするのは、壁越しにパッケージを投げる英雄ではなく、協働と自動化だという主張が題名に表れています。同年、ベルギーのゲントで最初のDevOpsDaysが開かれました。[devopsdays]

記録に残る逸話：四半期ごとのリリースが多い時代に「一日十回以上」は刺激的でした。しかし十という数字自体が教訓ではありません。小さな変更がフィードバックを短くし、開発と運用に共同責任を持たせたのです。後にDORAはデリバリーを指標化し、速度と安定性は必ずしも反対ではないと示しました。[dora]

2015–2017年：成果物が学習し始めたとき

MLの挙動はコードだけでは決まりません。データ、変換、ハイパーパラメーター、配備先の現実に依存します。Googleの「隠れた技術的負債」の論文は、モデルコードは実システムの一部にすぎないこと、結合したシステムでは一つの変更が全体を変え得ることを明確にしました。[debt]

ここに、現在MLOpsと呼ばれる必要性があります。データセットと特徴量を再現し、スキーマを検証し、実験とモデルを登録し、学習とサービングのずれを防ぎ、ドリフトを監視して再学習を判断することです。2017年のML Test Scoreは、本番準備のための28項目のテストと監視要件を提示しました。[mltest]

数字のある事例：TFX論文は、Googleが壊れやすいglue scriptを標準コンポーネントへ置き換えた経緯を説明します。Google Playでの一例では新データでモデルを更新し、著者らは実験サイクルの短縮、本番投入が月単位から週単位になったこと、データとモデル分析の改善に関連するインストール数2%増を報告しました。[tfx] これは一事例の結果であり、一般的な保証ではありません。

MLOpsはCI/CDにMLパイプラインの継続的デリバリーと継続的学習を加えました。Google Cloudのガイドは、手作業、MLパイプライン自動化、完全なCI/CD自動化を区別しています。[mlops]

2020–2022年：単体モデルから基盤システムへ

三つの変化がLLMOpsを準備しました。2020年のRAGは、パラメトリックな記憶と外部索引を組み合わせ、更新可能な知識と出典を導入しました。[rag] Stanfordの2021年報告はfoundation modelという語を定着させました。広範に学習し多数のタスクへ適応できる反面、多くの製品が同じ欠陥を継承する危険もあります。[foundation]

2022年のInstructGPTは、人のフィードバックが有用性を大きく変えると示しました。著者らのプロンプト分布では、評価者は1.3Bモデルを175BのGPT‑3より好みましたが、単純な誤りは残りました。[instruct] 同年のHELMは、一つのベンチマーク値ではなく、透明で多面的な評価を提案しました。[helm]

この環境でLLMOpsという呼称が広まりました。「MLOpsにプロンプトを足す」ことでも、基盤モデルを学習することでもありません。多くのアプリは重みを学習せず、API、プロンプト、検索、ツール、ルールを運用します。変更単位は複合LLMシステムです。

LLMOpsが本当に運用するもの

1. 単独プロンプトではなく、版管理されたバンドル

デプロイ可能な版には少なくとも、プロバイダーとモデル版、推論パラメーター、システムメッセージとテンプレート、ツールschema、RAGのコーパス、parser、chunking、embedding、索引、安全ポリシー、評価セット、オーケストレーションコードを含めます。見えるプロンプトが同じでも、どれかが変われば別製品です。

昇格する組合せは不変にします：app@sha + prompt@sha + index@snapshot + eval@version + policy@version + model@id。再構築できなければ、インシデントを説明できず、信頼できるロールバックもできません。

2. 最適化より先に評価

従来のテストには期待値があります。言語には複数の正しい表現があり、流暢な誤答もあります。LLMOpsは実タスク、境界条件、予測可能な悪用から評価データセットを作るところから始めます。各例に必要なのは単一のgolden stringではなく評価基準です。

  • タスク品質：正確性、完全性、形式、指示遵守。
  • RAG：retriever recall、コンテキスト関連性、回答の忠実性、引用品質。検索と生成を分けて評価します。
  • 安全：直接/間接インジェクション、データ漏えい、ツール悪用、禁止コンテンツ。
  • 運用：エンドツーエンド遅延、token、費用、retry、エラー、quota。

LLM judgeは評価を拡張できますが、それ自体もモデルです。人の判断で校正し、版を記録し、不一致を残します。堅牢なrelease gateは、決定的チェック、judge、敵対的テスト、人手サンプルを組み合わせます。

3. RAGをオンラインデータパイプラインとして扱う

RAGは「ベクトルDBをつなぐ」だけではありません。文書認可 → 抽出 → 清掃 → chunking → embedding → index → retrieval → reranking → context組立 → generation → 引用、という連鎖です。各矢印が劣化します。

コーパスと索引を版管理し、鮮度を測り、権限のない文書を検索させず、traceにchunk IDを残し、出典が既知の質問で試します。検索は根拠付けを改善しても、出力を自動的に真実にせず、prompt injectionも除去しません。OWASPも明記しています。[owasp]

4. 意味的な可観測性とFinOps

HTTP 200は役立つ回答を意味しません。traceは入力、policy、retrieval、reranking、モデル呼び出し、tool、retry、最終出力をつなぐべきです。OpenTelemetryはモデル、token、message、tool callの規約を定義しています。内容には機密データがあり得るため、content captureは任意にします。[otel]

有用なダッシュボードは品質と運用を結びます。版ごとのタスク成功率とgroundedness、p50/p95/p99遅延、入出力token、一呼び出しではなく完了タスク当たり費用、cache hit、agentの深さ、tool障害、人へのエスカレーションです。token単価が安くても、agentがループすれば高くつきます。

SLOはユーザーが感じる可用性、遅延、正しさから定義します。[sre] 例：「認可されたポリシー質問の95%に6秒以内で有効な引用付き回答を返し、テナント間漏えいを起こさない」。

5. セキュリティ、ガバナンス、権限の限界

モデルは同じチャネルでデータと命令を受け取ります。この曖昧さにより、prompt injectionは最後にフィルターを置けば済む問題ではなく、アーキテクチャ問題です。OWASPはLLM固有リスクを整理し、NISTの生成AIプロファイルはガバナンス、測定、リスク管理の行動を構造化しています。[nist][owasp]

  • 検索文書、Webページ、tool結果を信頼できない入力として扱う。
  • toolごとに最小権限を与え、読む・提案する・実行するを分離する。
  • SQL、shell、メール、支払い、インフラ変更の前に出力を検証する。
  • 不可逆または重大な操作には人の承認を求める。
  • promptとtraceの保持、PIIマスキング、所在地、アクセスを定義する。
  • kill switch、step/予算制限、timeout、rollbackを用意する。

本番LLMOpsパイプラインの9段階

  1. タスクとリスクを定義：支援する判断、許可する操作、責任者、禁止事項。
  2. 評価セットを作成：通常、境界、多言語、関連グループ、攻撃を含め、baselineを固定。
  3. 制約で選定：タスク品質、遅延、プライバシー、地域、context、tool、費用で選ぶ。
  4. contextを構築：知識や追跡性が必要な場合だけRAGを使い、ACL、出典、鮮度を保持。
  5. リリース前に計装：version/correlation ID、span、token、費用、eval結果。
  6. offline gate：回帰、安全、負荷、予算。平均改善で重大障害を隠さない。
  7. shadow/canary：実トラフィックで比較し、候補に最初から全権限を与えない。
  8. 本番サンプリング：自動シグナル、文脈付きfeedback、プライバシーを守る人手レビュー。
  9. バンドル全体を昇格/戻す：モデル、prompt、index、tool、policyを一緒に動かす。

運用ルールになった三つの逸話

Flickr、2009年：「一日十回」が記憶に残りましたが、長く残るのは題名の「DevとOpsの協働」です。頻度は短いフィードバックと共同責任の見える結果でした。[flickr]

TFX、2017年：より良いアルゴリズムではなく、場当たり的なglueを再現可能なプラットフォームに置き換えて本番問題を解きました。「モデルがある」から「モデルを運用できる」への転換です。[tfx]

Tay、2016年：Tayは現代LLM以前で、LLM障害と呼ぶべきではありません。しかし運用上の警告でした。Microsoftは最初の24時間に協調攻撃が想定外の脆弱性を突き、botを停止したと説明しました。[tay] ラボ試験、red team、実環境観測、撤回経路は製品の一部です。

よくあるLLMOpsの誤り

  • プロンプト一覧を「プラットフォーム」と呼ぶ。評価、lineage、権限、trace、rollbackがなければ保管庫です。
  • hallucination rateだけを測る。有用性、棄権、形式、安全、遅延、費用も成功を決めます。
  • 方針なしに全promptを記録する。可観測性が機密データの影コピーになります。
  • 本番で直接モデルを交換する。「より良い」モデルでも文体、tool calling、長さ、費用は変わります。
  • toolにサービスアカウント権限を渡す。agentはユーザーscopeか最小機能IDで動かします。

本当の進化：責任を持つ対象を広げる

DevOpsはソフトウェア変更を運用可能にしました。MLOpsは変化するデータと予測挙動を加え、LLMOpsはコンテキスト、意図、行動を加えます。成熟とは箱を増やすことではなく、各出力について五つの質問に答えられることです。どの版が、どのコンテキストで生成し、どう評価され、何を許可され、いくらかかったか。

答えがあれば、信仰に頼らず改善できます。なければ「LLMOpsパイプライン」は、本番ネットワークへつながったデモのままです。

出典と参考資料

本稿で参照した一次論文、公式ドキュメント、当事者組織によるインシデント報告です。

  1. John Allspaw & Paul Hammond — 10+ Deploys per Day: Dev and Ops Cooperation at Flickr
  2. DevOpsDays — Ghent 2009, official event archive
  3. DORA / Google Cloud — 2019 Accelerate State of DevOps Report
  4. Sculley et al. — Hidden Technical Debt in Machine Learning Systems
  5. Breck et al. — The ML Test Score
  6. Baylor et al. — TFX: A TensorFlow-Based Production-Scale ML Platform
  7. Google Cloud Architecture Center — MLOps: Continuous delivery and automation pipelines
  8. Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
  9. Bommasani et al. — On the Opportunities and Risks of Foundation Models
  10. Ouyang et al. — Training language models to follow instructions with human feedback
  11. Liang et al. — Holistic Evaluation of Language Models (HELM)
  12. Microsoft — Learning from Tay’s introduction
  13. NIST AI 600-1 — Generative AI Profile
  14. OWASP GenAI Security Project — Top 10 for LLM Applications
  15. OpenTelemetry — Inside the LLM Call: GenAI Observability
  16. Google SRE Book — Service Level Objectives

Was this useful?