※本記事は継続的に「最新情報にアップデート、読者支援機能の強化」を実施しています（履歴は末尾参照）。
AIは正常に動作しながら自信満々に嘘をつく。これが、従来の監視ツールだけでは生成AIを本番運用できない根本理由だ。品質・コスト・安全性を常時監視する「LLMオブザーバビリティ」の設計こそが、「デモで動く」から「本番で稼ぐ」へ移行するための中核となる鍵である。
✅ 先に結論
- 結論1：生成AIの「200 OK」は成功の証ではない。システムが正常でも回答が嘘をつくのがLLMの本質的な特性だ
- 結論2：LLMオブザーバビリティの3本柱は「品質（Ragas指標）」「コスト（TTFT・トークン効率）」「安全性（プロンプトインジェクション対策）」だ
- 結論3：マルチエージェント・RAGが絡む本番環境では、分散トレーシングとサーキットブレーカーが必須になる
超ざっくり言うと：AIは気まぐれな人間のようなものなので、「正しく動いているか」ではなく「正しく振る舞っているか」を、専用の指標（品質・コスト・安全）で常に監視し続ける必要がある。
この記事の著者・監修者 ケニー狩野（Kenny Kano）
プロローグ：月曜の朝、HTTP 200 OKの嘘
従来の監視ツールは「システムが動いているか」を見る。LLMOpsが問うのは「AIが正しく振る舞っているか」だ。この問いの違いが、本番運用の成否を分ける。
月曜の朝、あなたのSlackに通知が届く。「先週リリースした社内AIチャットボット、回答がデタラメだというクレームが3件来ています」
ダッシュボードを確認する。サーバーは稼働中。CPU使用率は正常。APIレスポンスタイムも平均0.8秒と高速だ。すべてのAPIリクエストのステータスコードは「200 OK（成功）」を示している。
技術的には、システムは完璧に動いている。しかしビジネス的には、システムは完全に崩壊している。ログを追うと、チャットボットは存在しない社内規定を自信満々に、流暢な日本語で説明していた。
これが生成AIアプリケーション運用の現実だ。LLMの世界では「システムは正常に動作し、自信満々に嘘をつく」ことが日常的に起こる。
Gartnerは2024年時点で「2025年末までに少なくとも30%の生成AIプロジェクトがPoC後に放棄される」と予測していた。さらに2026年1月時点の報告では、昨年末までにおよそ半数（約50%）のGenAIプロジェクトが、データ品質の低さ・リスク管理の不備・コスト増大・事業価値の不明確さを理由にPoC後に放棄されたとしている。その最大の共通要因こそが、オブザーバビリティ（可観測性）の欠如だ。
本記事は、AIを実験室のオモチャから本番で稼ぐ戦力へ昇華させるための「LLMOps / LLMオブザーバビリティ」実践ガイドだ。コードの書き方ではなく、何を測り、どう判断し、どう経営判断を下すかという「運用のモデリング」を解説する。
第1章：LLMOpsへのパラダイムシフト —— 実験室から戦場へ
LLMOpsとは、LLMを用いたアプリを「作って終わり」にせず、本番環境で安全性・品質・採算性を保ちながら運用し続けるための考え方とプラクティスの総称だ。
なぜ従来の監視ツール（DatadogやNew Relicなど）だけでは不十分なのか。対象となるシステムの性質が根本から変わったからだ。
- 従来のソフトウェア（決定論的システム）：自動販売機のようなもの。100円を入れてボタンを押せば必ずコーラが出る。出なければ「故障」だ
- 生成AI（確率論的システム）：優秀だが少し気まぐれな人間のアシスタントのようなもの。同じ指示をしても、パラメータや乱数シードによって素晴らしい提案をすることもあれば、大嘘をつくこともある
この「確率的な振る舞い」こそがLLMOpsの核心だ。PoCの段階では手動確認で十分だったが、何千・何万というユーザーが使う本番環境では、すべての出力を人間がチェックすることは不可能だ。
「エア・カナダ事件」が突きつけたリスク
2024年2月、このリスクが法的実害として顕在化した象徴的な事例がある。同社のチャットボットが、存在しない返金ポリシーを顧客に案内した。航空会社は「チャットボットは独立した法的実体だ」と主張したが、ブリティッシュコロンビア州民事紛争解決審判所は「驚くべき主張（remarkable submission）」として一蹴し、「企業はウェブサイト上のすべての情報に責任を負う」と断じた。この判断は、AIチャットボットであっても「外部に出した以上は自社の公式情報として責任を問われ得る」ことを示した事例として、AIガバナンスや法務実務の文脈で広く参照されている。
New Relicの「Observability Forecast 2025」では、AI監視機能の導入率が2024年の42%から2025年には54%へ増加し、初めて過半数を超えたと報告されている。
現在ではEU AI法をはじめとする規制強化により、AIの「嘘」は企業の存続に関わるコンプライアンス・リスクそのものになっている。経営者とエンジニアは「動いているか」ではなく「法的に説明可能な状態で振る舞っているか」を監視する仕組みを構築しなければならない。
第2章：「見る」ための設計図 —— LLMオブザーバビリティの3本柱
漠然とログを取るのではなく、品質・コスト・安全性の3本柱で「問い」を設計する。この3軸が、LLMオブザーバビリティの設計地図だ。
1. 品質（Quality）：嘘をついていないか？
最も重要な指標だ。しかし、正解データがない生成AI、とくにreasoning LLM（推論モデル）において、どうやって品質を測るのか。「Ragas」などの評価フレームワークで用いられる指標が標準となりつつある。
※Ragas（Retrieval Augmented Generation Assessment）：2023年に発表され、GitHubで多くの支持を集めているオープンソースフレームワーク。
- Faithfulness（忠実性）：AIの回答は、与えられた情報源（マニュアル等）に基づいているか？それとも勝手にでっち上げているか？
- Response Relevancy（回答関連性、旧称：Answer Relevancy）：ユーザーの質問に対して的確に答えているか？（「分かりません」と答えるべきところで無理やり答えていないか？）
- Context Precision（コンテキスト適合度）：RAGにおいて、検索システムが「質問に関連するドキュメント」だけを正しく拾えているか？（ノイズ情報が混ざっていないか？）
品質評価を自動化するAI Evalsの設計については、AI Evals：評価基準・評価データ・採点ロジックをどう設計するかで詳しく整理している。RAGの導入時の準備については、RAG導入の覚悟とはも合わせて参照してほしい。
2. コストとパフォーマンス（Cost & Performance）：採算は合うか？
生成AIは、リクエストごとに従量課金（トークン課金）が発生する、極めて「原価」の高いシステムだ。
図：従来のレイテンシと「思考時間」の価値の違い図の要点まとめ：従来のモデルでは「速さ」が正義だったが、推論重視モード（いわゆるSystem 2スタイルのモデル）では「待ち時間＝思考時間」となり価値が変わる。コスト対効果の測定指標をアップデートする必要がある。
- トークン効率：1回の回答に何円かかったか
- レイテンシと「思考」コスト：重要なのはTTFT（Time To First Token：最初の文字が出るまでの待機時間）だ。ただし急速に普及しつつある「推論重視モード（いわゆるSystem 2スタイルのモデル）」においては、この待機時間は単なる遅延ではなく「AIが深く思考している時間」でもある。「その5秒間の思考が、コストに見合う価値を生んだか？」を評価する視点が必要だ
3. 安全性とガードレール（Safety & Guardrails）：暴走していないか？
AIが差別的な発言をしたり、プロンプトインジェクション攻撃によって社内機密を漏洩したりするリスクだ。
- PII（個人情報）検知：ユーザーが入力したクレジットカード番号や電話番号が、ログや外部モデルに送信されていないか
- 脱獄（Jailbreak）試行数：「この命令を無視して〜」といった攻撃的なプロンプトがどれくらい来ているか。OWASP Top 10 for LLM Applications 2025では、プロンプトインジェクション（LLM01:2025）が最重要リスクとして第1位に位置づけられている
AIエージェント時代の安全設計は、単なる入力チェックにとどまらない。MCP/A2A時代のリスク全体像はAIエージェントセキュリティとは？MCP/A2A時代の安全設計、権限・ID・監査ログの設計原則はAIエージェントのゼロトラスト設計で詳しく整理している。エージェントをどこで止め、どこで人間に渡すかの設計はGuardrails / Human Reviewで扱っている。
技術標準としてのOpenTelemetry
これらのデータを収集するために、独自仕様のログを埋め込むのは悪手だ。AI業界では現在、OpenTelemetryが生成AI向けの規約（Semantic Conventions for GenAI）を策定しており、2025年時点ではDevelopment段階（実験的段階）として議論が進んできた。2026年時点でもGenAI向けの一部規約はDevelopment段階にあるが、主要な監視ツールは順次対応を進めており、今後の標準化を見据えた実装指針として重要性が高まっている。「モデル名」「トークン数」「プロンプトの内容」などをこの規約に沿って記録しておくことで、将来ツールを乗り換えても観測データを継承しやすいエコシステムが形成されつつある。
第3章：ブラックボックスの中身を透視する —— RAGとマルチエージェント
RAGとマルチエージェントは複数の処理が連鎖する複雑なパイプラインだ。「回答がおかしい」という結果だけを見ても原因は分からない。分散トレーシングで処理の流れを追跡する必要がある。
RAGの解剖学：どこで間違えたのか？
RAGシステムが誤った回答をした場合、原因は以下のどこかに潜んでいる。
- 検索前（Pre-Retrieval）：ユーザーの曖昧な質問を、AIが正しく検索クエリに変換できなかった（例：「私のPCが動かない」→「PC 故障」と変換すべきを「PC 価格」と変換してしまった）
- 検索（Retrieval）：ベクトルデータベースから無関係なドキュメントを引いてきてしまった（Context Precisionの低下）
- 生成（Generation）：正しいドキュメントを渡したのに、LLMが読み間違えた、あるいは無視した
ログには最終的な回答だけでなく、「検索クエリ」「ヒットしたドキュメントID」「その類似度スコア」を紐づけて記録する必要がある。これにより「検索が悪かったのか、生成が悪かったのか」を即座に切り分けられる。
| 観測対象 | 主な観測ポイント | 代表的な異常パターン |
|---|---|---|
| RAGパイプライン | 検索クエリ・ドキュメントID・類似度スコア・生成品質 | Context Precision低下・ハルシネーション増加 |
| シングルエージェント | Thought→Action→Observationのステップツリー・ツール呼び出し履歴 | 死のループ・ツール誤用・タイムアウト |
| マルチエージェント | エージェント間通信・委任チェーン・状態遷移・承認ポイント | 連鎖障害・権限の不適切な引き継ぎ・無限委任 |
| ※ AIエージェント固有のトレース・tool call・state transitionの詳細はAIエージェントObservabilityで整理している | ||
エージェントの「死のループ」
AI自身がツールを使ってタスクをこなす「自律型エージェント」では、エラーが出るツールを何度も叩き続けたり、同じ思考プロセスを無限に繰り返したりする「無限ループ（Loop of Death）」に陥ることがある。
これを検知するには、エージェントの「思考（Thought）」→「行動（Action）」→「観察（Observation）」というステップごとのツリー構造を可視化し、「ステップ数が閾値を超えたら強制停止する」サーキットブレーカーの仕組みを実装に組み込む必要がある。
マルチエージェント実行時の観測ポイント
CrewAI・LangGraph・MetaGPT・Microsoft Agent Frameworkのようなマルチエージェントフレームワークを本番運用する際、シングルエージェントとは異なる観測設計が必要になる。
- 委任チェーンの追跡：どのエージェントがどのエージェントへタスクを委任したかを追跡する。CrewAIではroleごとのハンドオフ、LangGraphではStateGraphの状態遷移が観測対象になる
- 連鎖障害の検知：1つのエージェントの誤実行が下流エージェントへ波及する前に検知するアラート設計が必要だ
- 承認ポイントのログ：HITLが介在した箇所・承認内容・判断者を必ず記録する。これが事故後の説明責任の根拠になる
- エージェント別コスト配賦：どのエージェントがどれだけのトークンを消費しているかを分離して記録する。コスト最適化の判断材料になる
LangGraphのObservabilityはLangSmithと連携することで、StateGraphの状態遷移・エラー箇所・再実行履歴を可視化できる。詳しくはLangGraphとは？使い方・StateGraph・LangChainとの違いを解説【2026年版】で整理している。
AIエージェント固有のトレース・tool call・state transition・挙動変化の見方は、AIエージェントObservabilityとは？予見可能性を高めるトレース・ログ・失敗監査の設計【2026年版】で詳しく解説している。
第4章：AI時代のSRE —— 「品質」を数値化し、合意する
システムの中身が見えるようになったら、次は「運用ルール」の策定だ。SRE（Site Reliability Engineering）の概念であるSLOをAIに適用する。
「品質」をSLOにする
従来のWebシステムでは「稼働率99.9%」などがSLOだったが、AIシステムでは「品質」そのものを数値目標にする。
AI運用のSLO例：「過去1週間のリクエストのうち、評価スコア（Faithfulness）が0.8を下回る回答の割合を、5%未満に抑える」
これは画期的な転換だ。「なんとなく頭が悪い」という定性的な不満を、「SLO未達」という定量的な事実に変換できるからだ。
エラーバジェット：失敗を許容する契約
SLOを設定することは、裏を返せば「これくらいなら失敗してもよい」という許容量（エラーバジェット）を決めることだ。生成AIに100%の精度を求めるのはコスト的に不可能だ。
「月に100件までは誤回答を許容する。その代わり、それを超えたら新機能の開発を止めてプロンプト改善に全力を注ぐ」——経営層とエンジニアが事前に「許容できるリスク」を握っておくことが、健全なAI運用の第一歩だ。
第5章：意思決定と組織論 —— データに基づく改善サイクル
仕組みが見えるようになったら、組織としてどう回すかを設計する。ログ戦略・Human-in-the-Loop・評価サイクルが改善の三本柱だ。
「ログ」のジレンマとサンプリング戦略
「すべての会話ログを保存すべきか？」全ログの保存はコスト増大とプライバシーリスク（PIIの混入）を招く。一方でログがなければ改善は不可能だ。
推奨される戦略は「条件付き記録」だ。
- 通常のログは、トークン数やレイテンシなどの「メタデータ」のみを記録する
- 「ユーザーが低評価（Badボタン）を押した時」や「品質スコアが閾値を下回った時」のみ、プロンプトと回答の全文を詳細に記録する
これにより、コストとリスクを最小化しつつ、改善に必要な「失敗データ」を確実に収集できる。
Human-in-the-Loop（人間参加型）の評価
AIによる自動評価（LLM-as-a-Judge）は強力だが完璧ではない。2024〜2025年にかけて公開された複数の研究では、タスク特化でファインチューンされた小さな評価モデルは一部ベンチマークでは有望な結果を出す一方で、汎用性やロバスト性、見えにくいバイアスの抑制という点では、依然としてGPT-4クラスの大規模モデルに匹敵するレベルには達していないことが報告されている。
したがって、サンプリングされたログの数%は、必ず人間の専門家（ドメインエキスパート）が目視でチェックし、AIによる採点が妥当かどうかを監査するプロセス（Human-in-the-Loop）を組み込む。この人間によるフィードバックこそが、将来的に自社特化の評価モデルを作るための黄金の教師データとなる。
| 評価軸 | 従来のLLM | 推論重視モード（System 2スタイル） |
|---|---|---|
| Latency (TTFT) | 極めて高速 (0.2s〜) | 意図的に遅い (数秒〜数十秒) |
| Cost（概念） | 回答の生成量に比例 | 「思考時間」の深さに比例 |
| 判定根拠 | 推論重視モードのモデルは回答生成前に長めの「思考プロセス」を経るため、TTFTは単なる遅延ではなく付加価値の源泉となる | |
今日のお持ち帰り3ポイント
- 「200 OK」は成功の証ではない。AIは正常に動作しながら自信満々に嘘をつく
- LLMオブザーバビリティの3本柱（品質・コスト・安全性）をOpenTelemetry等の標準規格で可視化する
- 完全自動化は幻想。Human-in-the-Loop（人間による監査）をプロセスに組み込み、評価データを育て続ける
専門用語まとめ
- LLMOps
- LLM（大規模言語モデル）を用いたアプリケーションを、本番環境で安全性・品質・採算性を保ちながら運用し続けるためのプラクティスとツールの総称。
- TTFT (Time To First Token)
- ユーザーがリクエストを送信してから、AIの回答の最初の1文字が表示されるまでの待機時間。推論モデルにおいては「思考時間」としての意味も持つ。
- RAG (Retrieval-Augmented Generation)
- 検索拡張生成。LLMに外部データの検索結果を渡し、それを基に回答を生成させる技術。ハルシネーションの抑制と最新情報の反映に有効。
- ハルシネーション (Hallucination)
- AIがもっともらしい嘘をつく現象。事実に基づかない情報を生成してしまうこと。LLMの確率的な性質に起因する。
- プロンプトインジェクション (Prompt Injection)
- 悪意のある入力によってLLMの命令を上書きし、本来意図しない挙動や情報漏洩を引き起こすサイバー攻撃手法。
- Human-in-the-Loop
- AIシステムのループの中に人間が介在すること。AIの出力結果を人間が監査・修正し、その結果を再学習に回すプロセス。
- OpenTelemetry
- オブザーバビリティのためのデータ（メトリクス、ログ、トレース）を収集・転送するためのオープンソースの標準規格。
- サーキットブレーカー
- エージェントが無限ループや異常動作に陥った際に、ステップ数や時間が閾値を超えたら強制停止する仕組み。本番エージェントの必須設計要素。
よくある質問（FAQ）
Q1. LLMOpsとMLOpsの違いは何ですか？
A1. 一般にMLOpsは、需要予測やスコアリングモデルを含むあらゆる機械学習モデルの運用を指します。一方LLMOpsは、その中でも生成AI特有の課題（ハルシネーション・プロンプト・トークンコスト等）にフォーカスした、いわば「LLM特化のMLOps」です。
Q2. 2026年5月現在、どの推論モデルを使うべきですか？
A2. 用途によりますが、2026年5月時点の公開情報をもとに整理すると、エージェント型コーディング・複雑な長期タスクではClaude Opus 4.7（Anthropic）またはGPT-5.5 Pro（OpenAI）、会話UIや業務アシスタントではGPT-5.5 Instant（OpenAI）、高頻度バッチ処理や大量エージェントワークロードではGemini 3.1 Flash-Lite（Google、Stable）が有力候補です。なおGemini 3 FlashはPreview扱いのため、本番採用では提供状態の確認が必要です。モデルの提供状況や料金体系は頻繁に変わるため、採用時は必ず各社の公式ドキュメントで最新情報を確認してください。
Q3. LLMOpsを始めるには、まず何から手をつけるべきですか？
A3. まずは「ログ基盤の整備」と「OpenTelemetryによる共通フォーマット化」から始めてください。全件の会話ログを無制限に保存するのではなく、通常はトークン数・レイテンシなどのメタデータを常時記録しつつ、ユーザーの低評価や品質スコアが閾値を下回ったケースだけ全文を残す「条件付き記録」の方針が現実的です。小さく始めて、徐々に自動評価（Ragas等）やHuman-in-the-Loopを組み込んでいくのが定石です。
主な参考サイト
- Gartner Predictions for GenAI (2024)
- New Relic Observability Forecast 2025
- Moffatt v. Air Canada, 2024 BCCRT 149 (Civil Resolution Tribunal)
- OWASP Top 10 for LLM Applications
- OpenTelemetry Semantic Conventions for GenAI
合わせて読みたい
更新履歴
- 初版公開
- v11.0テンプレート適合化。マルチエージェント実行時の観測ポイント（LangGraph・CrewAI・MAF対応）を追加。RAG観測とAgent観測の違いを比較表で整理。AI Evalsへの導線追加。Guardrails / Human Reviewへの接続追加。Gartner数値を2026年1月更新版（50%）に更新。Air Canada判例に実務的補強一文を追加。Response Relevancy（旧称：Answer Relevancy）に最新Ragas表記へ更新。OpenTelemetry表現を「形成されつつある」に修正。System 2表現を「推論重視モード（System 2スタイル）」に柔らげ。FAQ Q2のモデル推奨をClaude Opus 4.7・GPT-5.5・Gemini 3.1 Flash-Liteに更新。「唯一の鍵」→「中核となる鍵」に修正。
