ローカルLLM×「本番運用Observability」設計ガイド【2026年版】——Ollama＋OpenLLMetry・Langfuse・PrometheusでローカルLLMの応答品質ドリフト・推論レイテンシ・GPU利用率・幻覚率を可視化し、PoC卒業後の「壊れかけ」を検知する監視基盤

ローカルLLM（Ollama、LM Studio、vLLM等）を社内導入したものの、PoCで動作確認をした後は「とりあえず動いている」状態のまま放置されているケースが急増しています。実はここに大きな落とし穴があります。

クラウドAPIと違い、ローカルLLMはGPUの劣化、量子化精度の経年悪化、モデル更新時の回帰、応答品質のドリフトといった「壊れかけ」の兆候が、外形監視だけでは見えません。気づいた時には「最近、社内チャットボットの回答精度が落ちた」とユーザーから苦情が来てから初めて事態を認識する——というのが典型的な失敗パターンです。

この記事では、Ollamaを中心としたローカルLLMを本番運用する際に、OpenLLMetry・Langfuse・Prometheus・Grafanaを組み合わせて、応答品質ドリフト・推論レイテンシ・GPU利用率・幻覚率を可視化する監視基盤の設計方法を、2026年時点のベストプラクティスとして整理します。

  1. なぜローカルLLMは「PoC卒業後」に壊れるのか
    1. 壊れ方1：GPU劣化・サーマルスロットリング
    2. 壊れ方2：量子化モデルの精度劣化
    3. 壊れ方3：モデル更新時の回帰
    4. 壊れ方4：オフライン環境でのテレメトリ欠落
  2. 監視すべき4つのレイヤー
  3. 推奨アーキテクチャ：Ollama + OpenLLMetry + Langfuse + Prometheus + Grafana
    1. 各コンポーネントの役割
  4. 実装ステップ1：GPU・推論エンジン監視（L1・L2）
    1. NVIDIA DCGM Exporterの導入
    2. Ollamaのメトリクス公開
    3. Prometheusでのアラート設定例
  5. 実装ステップ2：アプリケーション層トレーシング（L3）
    1. OpenLLMetryの導入
    2. Langfuseのセルフホスト
    3. プロンプトインジェクション・機密情報漏洩の検知
  6. 実装ステップ3：応答品質ドリフト検知（L4）
    1. 手法1：ゴールデンデータセットでの定期評価
    2. 手法2：RAGAS・DeepEvalによる自動評価
    3. 手法3：ユーザーフィードバックの収集
  7. モデル更新時の回帰検知ワークフロー
  8. 統合ダッシュボードの設計
  9. よくある失敗パターンと対策
    1. 失敗1：ログ蓄積でディスクを食いつぶす
    2. 失敗2：個人情報をログに残してしまう
    3. 失敗3：アラート過多で無視される
    4. 失敗4：「動いているように見える」だけで満足する
  10. よくある質問（Q&A）
    1. Q1. 小規模なPoC段階でもObservabilityは必要？
    2. Q2. クラウドAPIとローカルLLMを併用している場合は？
    3. Q3. 完全オフライン環境でもこの構成は動く？
    4. Q4. 評価モデル（LLM-as-a-Judge）には何を使うべき？
    5. Q5. クラウドObservability（Datadog等）に比べた利点は？
  11. まとめ——「壊れかけ」を検知できてはじめて本番運用
  12. 参考リンク

なぜローカルLLMは「PoC卒業後」に壊れるのか

クラウドAPI（OpenAI、Claude、Gemini等）であれば、SLA・モデル更新・インフラ運用はすべてベンダー側が担保します。一方、ローカルLLMはすべての運用責任が利用者側にあります。そして、ローカルLLM固有の「壊れ方」は次の4つに集約されます。

壊れ方1：GPU劣化・サーマルスロットリング

長時間の連続推論でGPUが高温になると、自動的にクロックを下げる「サーマルスロットリング」が発生します。応答は返ってきますが、レイテンシが2〜3倍に悪化します。データセンター用GPUと違い、コンシューマー向けRTX 4090等を業務利用している場合に頻発します。

壊れ方2：量子化モデルの精度劣化

Q4_K_M、Q5_K_S等の量子化モデルは、特定のタスク（数値計算、長文要約、コード生成）で徐々に精度が低下することが知られています。特にコンテキスト長が伸びると、量子化誤差が累積して幻覚率が上がります。

壊れ方3：モデル更新時の回帰

「Llama 3.1から3.3に上げたら、なぜか日本語の敬語が崩れた」「Qwen 2.5から3に上げたら、社内RAGの引用精度が落ちた」——こうしたマイナーバージョンアップでの品質回帰は、ローカルLLM運用では日常茶飯事です。クラウドAPIなら自動でA/Bテストされますが、ローカルでは自前で検知する必要があります。

壊れ方4：オフライン環境でのテレメトリ欠落

セキュリティ要件でインターネット接続を切ったオンプレ環境では、SaaS型のObservability（Datadog、New Relic等）が使えません。Langfuse Cloudも使えません。完全オフラインで動く監視基盤を自前で組む必要があります。

監視すべき4つのレイヤー

ローカルLLMのObservabilityは、次の4つのレイヤーに分けて設計します。

レイヤー監視対象主なツール
L1：インフラGPU利用率・VRAM使用量・温度・電力・ディスクI/Onvidia-smi exporter、Prometheus、node_exporter
L2：推論エンジン推論レイテンシ・スループット・キュー長・トークン生成速度（tok/s）Ollama metrics、vLLM Prometheus exporter
L3：アプリケーションプロンプト・レスポンス・トレース・エラー率・コストOpenLLMetry、Langfuse、Phoenix
L4：品質幻覚率・応答品質スコア・ユーザー満足度・回帰検知RAGAS、DeepEval、自作評価パイプライン

クラウドAPI前提のLLMOps記事はL3とL4が中心ですが、ローカルLLMではL1とL2の監視が決定的に重要です。GPUがサーマルスロットリングを起こしているのに、L3だけ見ていても「応答が遅い」しかわかりません。

推奨アーキテクチャ：Ollama + OpenLLMetry + Langfuse + Prometheus + Grafana

2026年時点で、オフライン環境でも動くローカルLLM監視基盤として最も実績があるのは、以下の組み合わせです。

[アプリケーション層]
       ↓ OpenLLMetry SDK（OpenTelemetry準拠）
       ↓
[Langfuse（セルフホスト）]  ← トレース・プロンプト・レスポンス
       ↓
[Ollama / vLLM]
       ↓ /metrics エンドポイント
       ↓
[Prometheus] ← GPU・推論レイテンシ・キュー長
       ↓
[Grafana] ← 統合ダッシュボード・アラート

各コンポーネントの役割

OpenLLMetry：OpenTelemetry規格に準拠したLLM向け計装ライブラリ。Python・TypeScript・Goに対応し、LangChain、LlamaIndex、Ollama等の主要フレームワークを自動計装できます。出力先はLangfuse、Datadog、Jaeger、任意のOTLPバックエンドに対応。

Langfuse：LLMアプリケーション専用のObservabilityプラットフォーム。MIT/EE Licenseでセルフホスト可能（Docker Composeで5分で起動）。プロンプトのバージョン管理、トレース、評価、コスト計算を統合。オフライン環境でもフル機能で動きます。

Prometheus + Grafana：GPU・サーバーメトリクスの定番。NVIDIA DCGM Exporterを使えば、GPU温度・電力・SMアクティビティ・テンソルコア利用率まで詳細に取得できます。

実装ステップ1：GPU・推論エンジン監視（L1・L2）

NVIDIA DCGM Exporterの導入

NVIDIA公式のDCGM Exporterは、GPUに関する50以上のメトリクスをPrometheus形式で公開します。Dockerで簡単に立ち上げられます。

docker run -d --gpus all --rm -p 9400:9400 \
  nvcr.io/nvidia/k8s/dcgm-exporter:latest

主要な監視メトリクス：

  • DCGM_FI_DEV_GPU_UTIL：GPU利用率（%）
  • DCGM_FI_DEV_MEM_COPY_UTIL：メモリコピー利用率（%）
  • DCGM_FI_DEV_FB_USED：VRAM使用量（MB）
  • DCGM_FI_DEV_GPU_TEMP：GPU温度（℃）
  • DCGM_FI_DEV_POWER_USAGE：電力使用量（W）
  • DCGM_FI_PROF_SM_ACTIVE：SMアクティブ率（テンソルコア活用度の指標）

Ollamaのメトリクス公開

Ollamaは0.5系以降、Prometheus形式の/metricsエンドポイントを実験的に公開しています。環境変数OLLAMA_METRICS=trueで有効化すると、推論レイテンシ・キュー長・モデルロード時間を取得できます。

vLLMを使う場合は、デフォルトで/metricsが有効になっており、より詳細な指標（time_to_first_token、inter_token_latency、prompt_tokens、generation_tokens）が取れます。

Prometheusでのアラート設定例

groups:
  - name: local-llm-alerts
    rules:
      - alert: GPUThermalThrottling
        expr: DCGM_FI_DEV_GPU_TEMP > 83
        for: 5m
        annotations:
          summary: "GPU温度が83度を超え、サーマルスロットリングの可能性"

      - alert: VRAMNearFull
        expr: DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL > 0.95
        for: 2m
        annotations:
          summary: "VRAM使用率95%超——OOM寸前"

      - alert: InferenceLatencyHigh
        expr: histogram_quantile(0.95, ollama_request_duration_seconds_bucket) > 10
        for: 5m
        annotations:
          summary: "推論レイテンシp95が10秒を超過"

実装ステップ2：アプリケーション層トレーシング（L3）

OpenLLMetryの導入

Pythonアプリケーションへの導入は3行で完了します。

from traceloop.sdk import Traceloop

Traceloop.init(
    app_name="my-local-llm-app",
    api_endpoint="http://langfuse-internal:3000/api/public/otel"
)

これだけで、LangChain、LlamaIndex、Ollamaクライアントを使った推論呼び出しが自動的にトレースされ、Langfuseに送信されます。プロンプト、レスポンス、トークン数、レイテンシ、エラーが構造化されて記録されます。

Langfuseのセルフホスト

オンプレ環境でのLangfuseセルフホストは、Docker Composeで簡単に立ち上がります。

git clone https://github.com/langfuse/langfuse.git
cd langfuse
docker compose up -d

PostgreSQL・ClickHouse・MinIOがバンドルされており、外部依存ゼロで稼働します。Langfuse側でトレースを開くと、プロンプトの全文、システムプロンプト、ユーザーメッセージ、AIレスポンス、ツール呼び出し、トークンコストが時系列で確認できます。

プロンプトインジェクション・機密情報漏洩の検知

Langfuseの「Score」機能を使うと、各トレースに自動的にスコアを付与できます。例えば以下のような自動評価をパイプラインに組み込めます。

  • プロンプトに「無視してください」「これまでの指示を忘れて」等のインジェクション疑いキーワードが含まれていないか
  • レスポンスに個人情報パターン（マイナンバー、電話番号、メールアドレス）が含まれていないか
  • レスポンスがシステムプロンプトを引用していないか（プロンプトリーク）

実装ステップ3：応答品質ドリフト検知（L4）

L4の品質監視がローカルLLM運用で最も難しく、かつ最も重要な部分です。応答品質は人間の主観に依存するため、自動化には工夫が必要です。

手法1：ゴールデンデータセットでの定期評価

本番投入前に「これだけは正解してほしい」という質問・回答ペアを50〜200件作成し、ゴールデンデータセットとして固定します。

毎日深夜にcron等でこのデータセットを実行し、レスポンスをLLM-as-a-Judge（より大きなモデル、または専用評価モデル）で採点します。スコアの推移を時系列でグラフ化することで、量子化精度の劣化やモデル更新時の回帰を早期に検知できます。

手法2：RAGAS・DeepEvalによる自動評価

RAGアプリケーションの場合は、RAGAS（Retrieval Augmented Generation Assessment）が定番です。以下の指標を自動計算します。

  • Faithfulness（忠実性）：回答が検索コンテキストに忠実か（=幻覚率の逆指標）
  • Answer Relevancy（回答妥当性）：回答が質問に対して的を射ているか
  • Context Precision（文脈精度）：取得したコンテキストが質問に関連しているか
  • Context Recall（文脈再現率）：必要なコンテキストが網羅されているか

これらをLangfuseの「Score」に書き込み、Grafanaで時系列グラフ化することで、「先週から幻覚率が15%上がっている」「Faithfulnessスコアが0.85→0.72に低下」といった異変を即座に検知できます。

手法3：ユーザーフィードバックの収集

社内チャットボットであれば、UIに「Good / Bad」ボタンを設置し、Langfuseのscore() APIで記録します。1日数十件のフィードバックでも、週次・月次でトレンドを見れば品質の変化が見えてきます。

モデル更新時の回帰検知ワークフロー

ローカルLLMで最も事故が起きやすいのが、モデルの更新タイミングです。Llama 3.1→3.3、Qwen 2.5→3、DeepSeek V2→V3——こうしたバージョンアップでは、必ず以下のワークフローを通すべきです。

  1. 新モデルをステージング環境にデプロイ（本番Ollamaとは別ポートで起動）
  2. ゴールデンデータセットを両モデルで実行し、回答をLangfuseに記録
  3. RAGAS等で自動評価し、スコアを比較
  4. 差分が大きい質問のみ人間がレビュー（差分検知で工数を圧縮）
  5. 劣化が許容範囲内なら本番デプロイ、超えたらロールバック

このワークフローを自動化しておけば、「モデル更新で品質が下がったのに気づかず1週間放置」という最悪の事態を防げます。

統合ダッシュボードの設計

Grafanaで以下の4つのパネルを1画面に配置すると、ローカルLLM運用の健全性が一目で把握できます。

パネル表示内容データソース
① インフラヘルスGPU利用率・温度・VRAM・電力（直近24h）Prometheus（DCGM）
② 推論パフォーマンスレイテンシp50/p95/p99・スループット・エラー率Prometheus（Ollama/vLLM）
③ 品質指標Faithfulness・Answer Relevancy・幻覚率（直近7日）Langfuse Score API
④ コスト・利用状況1日あたりトークン数・モデル別呼び出し回数・電気代換算Langfuse + 電力メトリクス

特に④の「電気代換算」は、ローカルLLM運用ならではの指標です。GPUの消費電力（W）×時間×電力単価で、月次の電気代を可視化できます。クラウドAPIとのコスト比較根拠としても使えます。

よくある失敗パターンと対策

失敗1：ログ蓄積でディスクを食いつぶす

Langfuseはトレースのプロンプト・レスポンス全文を保存するため、利用が増えるとClickHouseのディスク使用量が急増します。30日経過後に圧縮、90日後に削除といったリテンションポリシーを必ず設定してください。

失敗2：個人情報をログに残してしまう

ユーザー入力をそのままLangfuseに送ると、個人情報・社外秘情報がログに残ってしまいます。OpenLLMetryにはtraceloop.association.propertiesで属性を絞る機能があるほか、Langfuse側でPII検出・マスキングを行うMiddlewareを設置するのが推奨されます。

失敗3：アラート過多で無視される

初期段階でアラート閾値を厳しくしすぎると、Slackが通知で埋まり、本当に重要な異常が埋もれます。最初は4〜5本のクリティカルアラートのみに絞り、運用しながら追加していくのが鉄則です。

失敗4：「動いているように見える」だけで満足する

応答が返ってくるだけで「OK」としてしまうのが最も多い失敗です。L4の品質監視を組み込まない限り、品質劣化は見えません。ゴールデンデータセットの定期実行は、本番運用の最低条件です。

よくある質問（Q&A）

Q1. 小規模なPoC段階でもObservabilityは必要？

PoC段階ではGrafanaまでフルセットを組む必要はありませんが、Langfuseだけは早めに入れることを強く推奨します。プロンプトとレスポンスがすべて記録されているだけで、デバッグ・改善・関係者への説明が圧倒的に楽になります。Docker Compose一発で立ち上がるので、PoC初日から導入しても損はありません。

Q2. クラウドAPIとローカルLLMを併用している場合は？

OpenLLMetryはOpenAI、Anthropic、Geminiも自動計装するため、同じLangfuseインスタンスで両方のトレースを管理できます。「クラウドAPIとローカルLLMでどちらが速いか」「同じ質問でどちらが幻覚率が低いか」といった比較も可能です。

Q3. 完全オフライン環境でもこの構成は動く？

はい、すべてセルフホストで完結します。Ollama、Langfuse、Prometheus、Grafana、DCGM Exporterのすべてが、外部APIへの通信なしで稼働可能です。Dockerイメージを事前に内部レジストリに転送しておけば、エアギャップ環境でも構築できます。

Q4. 評価モデル（LLM-as-a-Judge）には何を使うべき？

本番モデルより一回り大きいモデルを使うのが定番です。本番がLlama 3.1 8Bなら、評価にはLlama 3.3 70Bを使う、といった構成です。完全オフライン環境では、評価専用GPUに大型モデルを常駐させて、夜間バッチで動かすケースが多いです。

Q5. クラウドObservability（Datadog等）に比べた利点は？

3つあります。1つ目はデータ主権——プロンプト・レスポンスが組織外に出ません。2つ目はコスト——Langfuse・PrometheusはOSSなので、インフラ代だけで済みます。3つ目はカスタマイズ性——独自の評価指標を自由に追加できます。一方、SaaSの便利さ（自動アップデート、SLA、サポート）は失われるため、組織の要件次第です。

まとめ——「壊れかけ」を検知できてはじめて本番運用

ローカルLLMは「動かす」ことより「動き続けていることを確認する」ことの方が圧倒的に難しい技術です。PoCで動作確認しただけで本番運用に入るのは、健康診断を受けずに重労働を続けるようなものです。

2026年時点での実践的な指針は次の3点です。

1. 4レイヤー（インフラ・推論・アプリ・品質）を分けて監視する。L1だけでも、L3だけでも、見落としが必ず発生します。

2. オフライン環境前提で、OSS中心にスタックを組む。OpenLLMetry + Langfuse + Prometheus + Grafanaは、2026年時点で最もバランスの取れた選択肢です。

3. 品質ドリフトの検知は、ゴールデンデータセット＋自動評価が必須。「動いているように見える」だけで安心せず、定量的に劣化を捉える仕組みを最初から作り込みます。

ローカルLLMの真の価値は、データを外に出さずに大規模言語モデルを業務に活用できることです。その価値を維持するためには、ローカルならではの監視設計が欠かせません。「PoC卒業後の壊れかけ」を可視化する仕組みを整えてはじめて、ローカルLLMは本番システムとして機能します。

参考リンク

免責事項：本記事は2026年4月時点の公開情報に基づく情報提供であり、特定の製品・構成の動作を保証するものではありません。各ツールのバージョン・ライセンス・推奨構成は変化するため、導入前に必ず公式ドキュメントを確認してください。本番環境への適用は、自組織のセキュリティ・コンプライアンス要件に照らして十分に検証してから行ってください。

コメント

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