LLMはリリースして終わりじゃない——Claude Codeで始めるLLMOps実践ガイド

はじめに

AIチャット機能をリリースした翌週、ユーザーから「昨日と同じ質問をしたのに返答がおかしくなった」という報告が入ってきた。そういう経験をしたEMやエンジニアは、2026年現在、決して少なくないはずだ。

LLMを使ったプロダクトに特有の難しさは、「動いている」と「ちゃんと動いている」の間に巨大な溝があることだ。従来のAPIなら503や400のエラーで問題が表面化した。LLMはエラーを返さない。それどころか、自信満々に間違った回答を返し続ける。その損失額は、2024年の推定で世界全体で6兆7,400億円規模に達するという報告もある（出典: Zedtreeo「LLMOps Explained: The Complete 2026 Guide」）。

この問題に向き合うための実践分野が「LLMOps」だ。LLMOpsの全体像をEMの視点から整理しながら、Claude Codeを使って実際にどう構築・運用するかを見ていく。

LLMOpsとは何か——MLOpsとの違いから入る

LLMOps（Large Language Model Operations）は、LLMをプロダクション環境にデプロイ・監視・評価・保守するための実践分野だ。MLOpsと混同されがちだが、前提が根本的に違う。

| 項目 | MLOps | LLMOps |
|------|-------|--------|
| 評価方法 | 精度・F1スコアなど数値指標 | 有用性・安全性・妥当性（定性的） |
| 制御範囲 | 訓練データ・モデル重みを制御 | プロンプト工学・微調整で対応 |
| 主なコスト要因 | GPU実験・ハイパーパラメータ調整 | APIトークン課金・推論コスト |
| ドリフトの種類 | データドリフト主体 | プロンプトドリフト・出力ドリフトが新課題 |

MLOpsではモデルの再訓練コストが主役だったが、LLMOpsではAPIトークンの課金と「出力ドリフト」への対応が中心になる。出力ドリフトとは、コードを一切変えていないのにLLMの返答品質が時間とともに劣化する現象だ。プロンプトの文脈変化、モデル側のアップデート、ユーザーの入力パターン変化など、要因が複数重なって起きる。

市場規模も急拡大している。2025年のLLMOps市場は58〜88億ドル規模とされ、2026年には71〜155億ドルへの成長が予測されている（出典: 前掲Zedtreeo）。企業の67%がすでにLLMを導入済みであり、「やるかどうか」ではなく「どう運用するか」のフェーズに入っている。

LLMOpsの3本柱とClaude Codeでの実践

LLMOpsには3本の柱がある。プロンプト管理、評価（Evals）、そして監視・可観測性だ。それぞれClaude Codeでどう実装するかを、具体的なコードと合わせて見ていく。

プロンプト管理

最初によく起きる失敗は、プロンプトをコードに直接埋め込むことだ。

# ❌ よくある失敗パターン
system_prompt = "あなたはカスタマーサポートのアシスタントです。丁寧に答えてください。"

この書き方だと、プロンプトを改善するたびにコードの変更とデプロイが必要になる。チーム開発では誰がいつ何を変えたかも追えなくなる。

解決策は、プロンプトをコードから切り離して専用ツールで管理することだ。Langfuse（MITライセンス、GitHub 19,000以上のスター）はこの用途に特化したオープンソースツールで、バージョン管理・A/Bテスト・環境別管理をまとめて扱える。

Claude Codeを使うと、Langfuseとの統合コードを数分で生成できる。

from langfuse import Langfuse
from anthropic import Anthropic

langfuse = Langfuse()
client = Anthropic()

# トレース開始
trace = langfuse.trace(name="customer-support-v2")

# Langfuseからプロンプトを取得（バージョン管理済み）
prompt = langfuse.get_prompt("customer-support", version=2)

# 推論実行
generation = trace.generation(
    name="claude-response",
    model="claude-opus-4-6",
    input=user_message
)

response = client.messages.create(
    model="claude-opus-4-6",
    max_tokens=1024,
    system=prompt.compile(),
    messages=[{"role": "user", "content": user_message}]
)

# 結果記録（後から人間評価スコアを付加できる）
generation.end(output=response.content[0].text)
trace.score(name="quality", value=1)

「このコードをDeepEvalのテストと連携させて、プロンプト変更前後の品質比較ができるスクリプトを作ってほしい」とClaude Codeに投げると、ほぼそのまま使えるテストスイートが出てくる。ゼロから設計する必要はない。

評価（Evals）

「LLMの品質をどう測るか」は、LLMOpsで最も扱いが難しい部分だ。数値スコアが出るMLOpsとは違い、「この回答は適切か」という判断に人間の感覚が入ってくる。

現在の主流は「LLM-as-a-Judge」という手法だ。LLM自身を採点者として使い、品質評価をスケールさせる。

主要フレームワークの特徴を整理しておく。

| フレームワーク | 特徴 | 向いている用途 |
|--------------|------|--------------|
| DeepEval | Pytest式の記述、CI/CD統合がしやすい | テスト自動化重視のチーム |
| G-Eval | LLM-as-a-Judge + CoTで任意の評価基準に対応 | カスタム評価基準が必要な場合 |
| Evidently | 100以上の組み込みチェック、非エンジニアでも扱いやすい | 分析チームとの協業 |
| OpenAI Evals | ベンチマークレジストリが充実 | 既存ベンチマークとの比較 |

評価対象として押さえておくべきメトリクスは4つ。幻覚率（hallucination rate）、有害性スコア（toxicity score）、接地度（groundedness。RAGを使っている場合の根拠整合性）、そして出力ドリフトだ。

Claude Codeを活用したCI/CDへの組み込みフローはこうなる。

プルリクエスト作成
  ↓
GitHub Actions（Claude Code headlessモード）
  ↓
DeepEvalテストスイート自動実行
  ↓
品質劣化 → PRブロック
品質維持 → マージ承認

プロンプトの変更がプロダクションに入る前に品質を機械的に確認する。これを整備すると、「前回のデプロイで何かおかしくなった」という事後対応がなくなる。

監視・可観測性

デプロイ後の監視で最低限追うべきメトリクスはレイテンシ、スループット、コストの3項目だ。

具体的には、レイテンシはTime to First Token、スループットはTokens Per Second、コストはAPIトークン課金のリアルタイム追跡で把握する。

Heliconeはプロキシ方式のツールで、API呼び出しのURLを1行変えるだけで監視を開始できる。無料枠が月10万リクエストと広く、キャッシング機能で20〜40%のコスト削減効果がある（出典: Getathenic「LangSmith vs Helicone vs Langfuse: Comparison 2026」）。「まず何か入れてみたい」という段階にはHeliconeが素直に勧めやすい。

ツール選定で迷う場合、判断軸はシンプルだ。データを自社環境で持ちたい・LangChain以外のフレームワークも使うならLangfuse。LangChainが中心ならLangSmith。高速に導入してコスト最適化を先に試したいならHelicone。

EMとして今すぐ動く——採用基準の変化と3ヶ月の監視体制

技術の話だけで終わらせたくない。EMが特に意識すべき変化が2つある。

採用基準が「System Verifier」に変わっている

2026年の採用トレンドで注目されているのが「Senior-Only」モデルへの移行だ。AIがコードを生成できる時代に求められるのは、生成されたコードと品質を検証・判断できる人材だ。「Code Generator」から「System Verifier」への転換と言われる（出典: LeadDev「How engineering leaders can better leverage AI in 2026」）。

LLMOpsの文脈でいえば、評価パイプラインを設計して品質ゲートを定義できるエンジニアが希少になっている。MLOps専門知識を持つ人材は他のスキルセットより30〜50%高い給与水準になっているという報告もある（出典: 前掲LeadDev）。

EMとして採用要件を見直す際、「LLMの品質評価ができるか」という観点を加えることは理にかなっている。

3ヶ月で整える段階的セットアップ

「全部一度にやろう」とすると止まる。私が薦めるのは3フェーズだ。

Month 1〜2: 基本可視化

まずLangfuseを導入して、すべてのLLMコールの記録を始める。コストとレイテンシのダッシュボードを作るだけでいい。「何にいくら使っているか」が見える状態にすることが最初のゴールだ。ここをすっ飛ばすと、品質改善の施策を打ってもコストが増えたのか減ったのかすら分からなくなる。

Month 3〜4: 品質評価の自動化

LLM-as-a-Judgeで自動品質スコアリングを始める。幻覚率と有害性のアラートを設定し、「品質劣化を人間が気づく前に検知できる」状態を作る。ここで初めて、開発チームが「リリースして終わり」から脱せる。

Month 5〜6: 最適化と自動化

プロンプトA/Bテストを定常化し、Heliconeのキャッシング機能を導入する。CI/CDへの評価パイプライン統合を完了させ、プルリクエストのたびに品質チェックが自動で走る状態を目指す。

6ヶ月後には、「デプロイのたびに何かが壊れていないか不安」という状態から、「品質が機械的に保証されている」状態に変わる。

まとめ

LLMOpsは、AIをリリースした後も品質を維持し続けるための仕組みだ。幻覚やドリフトが表面化したとき、「AIだから仕方ない」では済まなくなっている。

Claude Codeはこの仕組みを構築する速度を大きく上げる。Langfuseとの統合コード、DeepEvalのテストスイート、CI/CDへの組み込みスクリプト——ゼロから設計しなくても、「こういうパイプラインを作りたい」という要求をそのまま投げれば動くコードが返ってくる。

まず手を動かすなら、既存のLLMコール1本にLangfuseのトレースを追加してほしい。コード変更は10行以内で完了する。それが「LLMOpsを始めた日」になる。

コメント

タイトルとURLをコピーしました