필사 모드: LLMOps 完全ガイド: モデル・プロンプト・評価セットの3軸バージョン管理、Canary、コスト統制、プラットフォームチーム (2025)

Season 4 Ep 11 — Ep 10 が「守る軸」だったなら、Ep 11 は持続可能に回し続ける軸だ。「最初のリリースまで1週間、その次の1年は地獄」を避ける方法。

• Prologue — 「LLMOps は MLOps か DevOps か？」
• 第1章 · 3軸バージョン管理
  • 1.1 軸
  • 1.2 リリースメタデータ
  • 1.3 ログとの接続
• 第2章 · デプロイ戦略
  • 2.1 Shadow
  • 2.2 Canary
  • 2.3 Blue-Green
  • 2.4 A/B 実験
  • 2.5 Percentage Router
• 第3章 · コスト統制
  • 3.1 トークン監査
  • 3.2 キャッシング
  • 3.3 モデルルーティング
  • 3.4 トークンダイエット
  • 3.5 ストレージ・ネットワーク
  • 3.6 現実的な削減目標
• 第4章 · プラットフォームチームの構成
  • 4.1 3階層
  • 4.2 インターフェース
  • 4.3 規模別
  • 4.4 政治的な落とし穴
• 第5章 · 評価ハーネス — LLMOps の心臓
  • 5.1 評価セットのバージョニング
  • 5.2 CI 統合
  • 5.3 On-demand 実験
  • 5.4 本番のフィードバックループ
• 第6章 · 観測性と運用
  • 6.1 Ep 6 の延長
  • 6.2 核心ダッシュボード
  • 6.3 オンコール
  • 6.4 ベンダー障害への備え
• 第7章 · データガバナンス
  • 7.1 データ分類
  • 7.2 ユーザー同意
  • 7.3 PII の取り扱い
  • 7.4 ライセンス
• 第8章 · 失敗事例10選
  • 8.1 トークン暴走
  • 8.2 プロンプトのロールバック不能
  • 8.3 モデルの deprecation
  • 8.4 一つのリージョン障害で全体ダウン
  • 8.5 RAG インデックスのドリフト
  • 8.6 ユーザーログの過剰保有
  • 8.7 プロンプトインジェクション
  • 8.8 False refusal の急増
  • 8.9 ベクトル DB のコスト暴走
  • 8.10 A/B 結果の解釈ミス
• 第9章 · KPI・OKR
  • 9.1 プロダクト KPI
  • 9.2 エンジニアリング KPI
  • 9.3 AI Quality KPI
  • 9.4 運用 KPI
• 第10章 · 韓国・アジアの環境
  • 10.1 クラウド
  • 10.2 供給元の多角化
  • 10.3 従業員教育・文化
• 第11章 · 道具まとめ (2025)
  • 11.1 ゲートウェイ・ルーティング
  • 11.2 観測性
  • 11.3 評価
  • 11.4 プロンプトレジストリ
  • 11.5 データ/フィーチャー
  • 11.6 サービング
  • 11.7 ガードレール・セキュリティ
  • 11.8 コスト・リソース
• 第12章 · アンチパターン10選
  • 12.1 モデルだけ変えてデプロイ
  • 12.2 単一ベンダー依存
  • 12.3 プロンプトが Git の外に
  • 12.4 Shadow・Canary を使わない
  • 12.5 コストダッシュボードがない
  • 12.6 Eval set と訓練データが混ざる
  • 12.7 ベンダー障害への対応計画がない
  • 12.8 AI Platform チームの過大な権力
  • 12.9 規制・監査を考慮しない
  • 12.10 Postmortem を書かない
• 第13章 · チェックリスト — LLMOps ローンチ前の12項目
• 第14章 · 次回予告 — Season 4 Ep 12: 「AI プロダクトデザイン」

Prologue — 「LLMOps は MLOps か DevOps か？」

どちらでもあり、どちらでもない。

• MLOps と違って モデル学習はまれ（使うのはホスティング API かアダプター）
• DevOps と違って 結果が確率的なのでテストが難しい
• しかしデプロイ・観測・ロールバック・コスト統制は、両者の教訓がすべて必要

2025年の LLMOps の核心的な問い:

1. 3軸バージョン管理（モデル・プロンプト・評価セット）をどう一貫して管理するか？
2. コスト: トークンの無駄をどう見つけ、どう減らすか？
3. 組織: AI プラットフォームチームと製品チームの境界はどこか？
4. 規制・監査: すべてのデプロイ・変更の痕跡をどう残すか？

第1章 · 3軸バージョン管理

1.1 軸

• Model: gpt-4o-2025-03-15、claude-3.7-sonnet、qwen2.5-14b-awq など
• Prompt: システムプロンプトの Git/レジストリのバージョン
• Eval set: 各リリースに紐づく評価セットのスナップショット

1.2 リリースメタデータ

release: v1.4.2
model: anthropic/claude-3.5-sonnet-2025-02
prompt_version: sales_copilot@v23
eval_set: v12 (scored 91.3/100)
adapters:
  - korean_tone_lora@v3
guardrails:
  - llama_guard@v1
  - custom_policy@v8
rollout:
  canary: 5%

すべてのリリースで、このメタデータが不変として固定されていなければならない。

1.3 ログとの接続

• 各リクエストのログに release_id を含める
• 後から「この応答がどの設定から出たのか」を100%再現できる
• 規制監査の最低要件

第2章 · デプロイ戦略

2.1 Shadow

• 新バージョンを本番トラフィックに対して並列で呼び出す（応答は使わない）
• 既存の応答との diff と指標の比較
• ユーザーへの影響なしで回帰・改善を確認

2.2 Canary

• 1–5% → 10% → 50% → 100% と順次拡大
• 各段階で自動ゲート（評価セットのスコア、p95 レイテンシ、エラー率）
• 失敗時は即座に前バージョンへロールバック

2.3 Blue-Green

• 二つの環境（Blue が本番、Green が待機）にそれぞれ旧バージョンと新バージョン
• 切り替えはロードバランサーのスイッチング
• ロールバックは即時（秒単位）

2.4 A/B 実験

• 統計的有意性の確保（標本・期間）
• 指標: Quality, Cost, Latency, User satisfaction
• エンドユーザーの区分（ユーザー基準/企業基準）

2.5 Percentage Router

• 小さな LLM gateway サービスがユーザー・組織・機能ごとにトラフィックを分割
• トグルで即座にバージョン変更が可能
• Helicone, Portkey, Martian, LiteLLM などのオープン/SaaS ゲートウェイ

第3章 · コスト統制

3.1 トークン監査

• リクエストごとに input/output トークンを記録
• ユーザー・機能・エンドポイント別に集計
• 上位コストのエンドポイント・プロンプトを週次レビュー

3.2 キャッシング

• プロンプトキャッシュ: Anthropic・OpenAI・Google のネイティブ機能
• レスポンスキャッシュ: 同一・類似の入力に対して以前の応答を再利用
• RAG 検索キャッシュ: クエリ → ドキュメントのマッピングをキャッシュ

3.3 モデルルーティング

• 単純なクエリ → 小さいモデル → 複雑なクエリ → 大きいモデル
• ルーター自体が分類器（LoRA あるいはルール）
• 2025年は Martian・RouteLLM のようなオープンルーターが台頭

3.4 トークンダイエット

• システムプロンプトを継続的に減量
• RAG に入れるドキュメント数を最適化
• JSON 応答フィールドを必須/任意で区分
• Structured Output（Ep 2）で無駄を除去

3.5 ストレージ・ネットワーク

• ログの長期保管は cold storage
• ベクトル DB インデックスの圧縮・パーティショニング
• クロスリージョン転送を最小化

3.6 現実的な削減目標

• 最初の3か月: 20–40%（低いところの果実）
• 6か月目: さらに 15–30%（モデルルーティング・キャッシュの高度化）
• 以降: 5–10% の維持改善

第4章 · プラットフォームチームの構成

4.1 3階層

• Foundation / Infra: GPU・モデルサービング・観測インフラ
• AI Platform: 共用 SDK・プロンプトレジストリ・評価ハーネス・ガードレール
• Product AI: 各プロダクトの機能実装（チャットボット・RAG・エージェント・音声など）

4.2 インターフェース

• AI Platform → Product AI: 使いやすい SDK + 標準の観測性
• Infra → AI Platform: 安定したサービングとコストダッシュボード
• 各境界は SLA + オンコール を持つ API のように管理する

4.3 規模別

• スタートアップ 10–50人: チームを分けず「AI 責任者 1–2人 + 製品エンジニア」
• 中堅 50–500人: AI Platform 5–15人、製品ごとに AI owner
• 大企業 500人以上: 3階層をすべて分離、セキュリティ・規制は別チーム

4.4 政治的な落とし穴

• 「すべての AI は我々のチームに」→ ボトルネック
• 「製品ごとに独自の AI インフラ」→ 重複の無駄
• 中道: 共通プラットフォーム + 製品の自律が2025年の支配的モデル

第5章 · 評価ハーネス — LLMOps の心臓

5.1 評価セットのバージョニング

• Git LFS またはデータレジストリ（DVC, Hugging Face Datasets, S3 + メタ）
• 各評価セットにバージョン・スキーマ・ラベラー・作成日
• 訓練データと厳格に分離する

5.2 CI 統合

• PR ごとに軽量な評価セットを自動実行
• マージ後に大型の評価セットを非同期実行
• 回帰を検知したら Slack/Discord に通知

5.3 On-demand 実験

• 新しいモデル候補・プロンプト変形を即座に評価
• コスト・結果の比較ダッシュボード
• 並列実験（複数の変形を同時に）

5.4 本番のフィードバックループ

• ユーザーの thumbs → ラベル候補
• ラベラーの検収 → 評価セットに追加
• 月次の「事故ケース統合リリース」

第6章 · 観測性と運用

6.1 Ep 6 の延長

• Trace/Span/Metric の3層
• OpenTelemetry ベース
• LangFuse/LangSmith/Phoenix/Helicone/W&B

6.2 核心ダッシュボード

• 品質: 評価セットのスコア推移、thumbs up/down
• コスト: 日/月の合計、機能別、ユーザー別
• レイテンシ: p50/p95/p99、TTFT、TTL
• 安全: 攻撃の試行、拒否率、false refusal
• エラー: ステータス別、ベンダー別、リトライ率

6.3 オンコール

• 主要指標の SLI/SLO を定義
• アラート等級（P1/P2/P3）
• Runbook: 供給元の障害、コスト暴走、品質回帰
• 事故後の Postmortem は 24–72h

6.4 ベンダー障害への備え

• マルチプロバイダールーティング（OpenAI 障害 → Anthropic へ自動フォールバック）
• ローカルモデルによる最小機能モード
• エスカレーション経路を明確に

第7章 · データガバナンス

7.1 データ分類

• Public / Internal / Confidential / PII / Regulated
• 各等級ごとのモデル・ベンダー・ログ保有ポリシー
• 自動分類器（DLP）を活用

7.2 ユーザー同意

• AI 利用の告知、ログ保有範囲の透明化
• 削除・提供リクエストの API
• GDPR・個人情報保護法の遵守

7.3 PII の取り扱い

• 入力時に PII を検知し、マスキング/仮名化（pseudonymize）
• 出力時に再マスキング
• 監査ログはハッシュのみ

7.4 ライセンス

• 合成データを生成するモデルの利用規約
• サードパーティデータ利用の契約
• ユーザーの著作権対応（RAG 検索結果の引用）

第8章 · 失敗事例10選

8.1 トークン暴走

システムプロンプトを3000→8000トークンに更新した後、コストが急増。

8.2 プロンプトのロールバック不能

Git ではなくインライン文字列だったため、以前のバージョンが見つからない。

8.3 モデルの deprecation

供給元がモデル終了を告知、代替モデルで回帰が発生。

8.4 一つのリージョン障害で全体ダウン

単一リージョン依存。マルチリージョン/マルチベンダーのフォールバックが不在。

8.5 RAG インデックスのドリフト

ドキュメント更新がインデックス再構成につながらず、古い回答が出る。

8.6 ユーザーログの過剰保有

規制監査で指摘され、過料。

8.7 プロンプトインジェクション

間接インジェクションで社内文書が流出。

8.8 False refusal の急増

ガードレール強化後、正常なリクエストの拒否率が上昇。

8.9 ベクトル DB のコスト暴走

想定より多くのチャンクが生成され、月額コストが2倍。

8.10 A/B 結果の解釈ミス

標本不足・分散の無視で、誤ったバージョンを昇格。

第9章 · KPI・OKR

9.1 プロダクト KPI

• Task completion rate
• Time saved（ユーザー当たり）
• NPS / Retention
• Adoption / Active usage

9.2 エンジニアリング KPI

• p95 latency
• Error rate
• Cost per request
• Availability (SLA)

9.3 AI Quality KPI

• Eval set score（週/月）
• Hallucination rate
• Safety violations
• False refusal rate

9.4 運用 KPI

• MTTR (mean time to recovery)
• 事故の頻度（週/四半期）
• リリース周期（週に何回）
• テストカバレッジ

第10章 · 韓国・アジアの環境

10.1 クラウド

• AWS・GCP・Azure・Oracle + 国内（NHN Cloud, KT Cloud, Naver Cloud）
• 規制監査に応じて国内クラウド/オンプレの要求
• ソウル・東京リージョンの遅延に備える

10.2 供給元の多角化

• OpenAI・Anthropic・Google・Cohere・Mistral + 国内（Upstage, LG AI Research）
• 金融・公共: 国内ベンダー優遇の条件

10.3 従業員教育・文化

• AI 利用ガイドライン（社内データ流出の防止）
• プロンプトエンジニアリングの基礎教育（1–2時間）
• 新規プロダクトの AI 導入前にセキュリティレビュー

第11章 · 道具まとめ (2025)

11.1 ゲートウェイ・ルーティング

• LiteLLM, Portkey, Helicone, Martian, OpenRouter

11.2 観測性

• LangFuse, LangSmith, Phoenix(Arize), Helicone, W&B Weave, Datadog/NewRelic LLM extensions

11.3 評価

• RAGAS, DeepEval, Promptfoo, Giskard, PyRIT（攻撃）, OpenAI Evals, Confident AI

11.4 プロンプトレジストリ

• LangSmith Prompt Hub, Humanloop, PromptLayer, W&B Weave, Agenta

11.5 データ/フィーチャー

• Weights & Biases Artifacts, MLflow, DVC, LakeFS

11.6 サービング

• vLLM, TGI, SGLang, TensorRT-LLM, Ollama, Modal, Anyscale, Together, Fireworks

11.7 ガードレール・セキュリティ

• NeMo Guardrails, Guardrails AI, Lakera Guard, Rebuff, Azure Content Safety, Google Cloud Model Armor

11.8 コスト・リソース

• Helicone Cost Insights, OpenMeter, CloudZero, Cast AI, Karpenter(K8s)

第12章 · アンチパターン10選

12.1 モデルだけ変えてデプロイ

評価セット・プロンプトの再確認なしでロールアウト。

12.2 単一ベンダー依存

障害・値上げ・規約変更のリスク。

12.3 プロンプトが Git の外に

Config ファイル・インラインコード・SaaS-only → バージョニングが消失。

12.4 Shadow・Canary を使わない

問題を本番で発見する。

12.5 コストダッシュボードがない

月末の請求書を見てびっくり。

12.6 Eval set と訓練データが混ざる

評価の水増し。

12.7 ベンダー障害への対応計画がない

ユーザーの体感が大きいダウンタイム。

12.8 AI Platform チームの過大な権力

Product AI の自律を抑圧。

12.9 規制・監査を考慮しない

リリース後に罰金・強制停止。

12.10 Postmortem を書かない

同じ事故が繰り返される。

第13章 · チェックリスト — LLMOps ローンチ前の12項目

• 3軸（モデル・プロンプト・評価セット）のバージョニングとリリースメタの固定
• Shadow + Canary + 自動ロールバックの構築
• コストダッシュボード（日/月、機能別・ユーザー別）
• マルチベンダーのフォールバック経路
• 評価ハーネス + CI 統合
• 観測性（Trace/Metric）の標準計測
• ガードレール・Red team CI
• SLI/SLO + オンコール体系
• データ分類・PII マスキング・削除 API
• 事故対応・Postmortem のプロセス
• AI プラットフォームと製品の間の責任・API の合意
• 従業員教育・セキュリティガイド

第14章 · 次回予告 — Season 4 Ep 12: 「AI プロダクトデザイン」

エンジニアリングが安定したなら、残るのはユーザー体験だ。

• 確定的 UI と生成的 UI の境界
• 「信頼」をつくるデザイン（引用・不確実性・編集可能性）
• フィードバック UX: 👍/👎 の先にあるパターン
• ストリーミング・遅延・フィードバックの処理
• Agent UX: 進行・承認・中断・リプレイ
• Voice UX の深掘り（Ep 9 の延長）
• データ・学習の UX
• オンボーディング・第一印象の設計
• 失敗・障害の UX
• アクセシビリティ・包摂性
• 倫理的な AI UX
• 韓国語・韓国文化への特化

「良い AI プロダクト = 良いモデル + 良い UX」ではなく、「良い AI プロダクト = 制約の中で信頼をつくる UX 設計」だ。

次回の記事で会おう。

まとめ: LLMOps は3軸バージョン管理・Shadow/Canary・コスト統制・プラットフォームチーム・監査に要約される。MLOps と DevOps の教訓を吸収しつつ、LLM 固有の確率性とベンダー依存を考慮した追加の慣行が必要だ。一度作るのは簡単になったが、「1年間止まらずに改善され続ける LLM プロダクト」をつくるには、この記事の12チェックリストが最低限の出発点になる。「AI はデプロイするものではなく、回すものだ」が2025年の教訓。