はじめに
LLM アプリを本番運用しようとすると、LLM の呼び出しを後から追える仕組みが必要になります。
たとえば、次のようなことを確認したくなります。
- どのプロンプトで、どんな出力が返ったのか
- モデルごとのトークン数やコストはどれくらいか
- エラーになった LLM 呼び出しはどれか
- プロンプトを変えたあと、品質やコストはどう変わったか
- どの API リクエストが遅く、その中で LLM が何秒かかったのか
- LLM 以外の DB / 外部 API / キューの遅延とどう関係しているのか
このための候補として、よく出てくるのが Langfuse と OpenTelemetry / Grafana です。ただし、この記事が前提にするのは SaaS 利用ではなくセルフホストです。ここが重要になります。
Langfuse は LLM アプリ向けの専用 UI として便利です。プロンプト、入力、出力、トークン、コスト、評価、データセットなどを扱いやすい形で見られます。
一方で、Langfuse v3 をセルフホストする場合、v2 より構成が重くなります。PostgreSQL だけでなく、ClickHouse、Redis、MinIO / S3 互換オブジェクトストレージなどを含む構成になります。つまり、Langfuse は「LLM 監視に便利だから入れる」で終わる話ではありません。
セルフホストするなら、次の問いを先に考える必要があります。
- Langfuse v3 の構成を運用できるか
- ClickHouse やオブジェクトストレージのバックアップをどうするか
- 小規模チームや PoC に対して重すぎないか
- 既存の Grafana / Prometheus / OpenTelemetry 基盤があるなら、そこに LLM 監視を載せる方がよいのではないか
- Langfuse と OpenTelemetry を併用するなら、どこで役割分担するのか
この記事では、セルフホスト前提で Langfuse v2 / v3 と OpenTelemetry / Grafana の違いを整理します。
この記事の結論
セルフホスト前提なら、最初に見るべきなのは機能一覧ではなく、運用できる構成かどうかです。
ざっくり言うと、判断は次のようになります。
| 状況 | 向いている選択 |
|---|---|
| LLM のプロンプト / 出力 / 評価 / データセットを専用 UI で見たい | Langfuse |
| Langfuse を新規セルフホストしたい | 基本は v3。ただし構成は重い |
| 小さく試したいだけ | Langfuse クラウド版か、検証用セルフホスト |
| 既に Grafana / Prometheus / Tempo / OTel がある | OpenTelemetry の gen_ai.* を載せる |
| サービス全体のトレース / レイテンシ / アラートを見たい | OpenTelemetry + Grafana |
| LLM の中身とサービス全体の両方を見たい | Langfuse + OpenTelemetry の併用 |
重要なのは、Langfuse と OpenTelemetry が別のものだという点です。Langfuse は、LLM アプリ専用の観察・評価ツールです。OpenTelemetry は、サービス全体のテレメトリを扱うための標準です。Grafana は、OpenTelemetry などで集めたトレースやメトリクスを可視化するダッシュボードです。
そのため、問いを分けると判断しやすくなります。
LLM の中身を見たい:
Langfuse
サービス全体のどこが遅いか見たい:
OpenTelemetry + Grafana
セルフホストの運用負荷を抑えたい:
既存基盤に載せる、または SaaS を検討する
専用 UI と全体監視の両方が必要:
併用する
まずセルフホスト前提で考える
Langfuse をクラウド版で使う場合と、セルフホストする場合では、判断基準が変わります。クラウド版なら、ClickHouse や Redis やオブジェクトストレージの運用は Langfuse 側に任せられます。しかし、セルフホストでは自分たちで運用します。
LLM 監視ツールとしての便利さだけでなく、次のような運用観点も見ます。
- 何個のコンテナーが必要か
- どのデータストアをバックアップするか
- 障害時にどこを見ればよいか
- メモリやディスク使用量はどれくらいか
- アップグレード時にデータ移行が必要か
- チームが ClickHouse やオブジェクトストレージを扱えるか
- 既存の監視基盤と重複しないか
この観点を先に置かないと、「Langfuse は LLM 専用機能が多くて便利」という機能面だけで判断してしまいます。
特に Langfuse v3 は、LLM 監視用の専用 UI として魅力がありますが、セルフホスト構成は軽くありません。
Langfuse v2 と v3 のセルフホスト構成の違い
Langfuse のセルフホストを考えるとき、v2 と v3 の違いはかなり重要です。
Langfuse v2
Langfuse v2 は、比較的軽い構成でした。
ローカル検証なら、主に次のような構成で動かせます。
langfuse server
PostgreSQL
構成としては、Web UI / API と PostgreSQL を立てる形です。そのため v2 は、「暫定的に Docker Compose で試す」用途に向いた構成でした。ただし、v2 は旧世代です。今から新規にセルフホスト版 Langfuse を導入するなら、v3 を前提にします。
v2 は、既存環境の理解や v3 移行の比較対象として扱うのが自然です。
Langfuse v3
Langfuse v3 では、セルフホスト構成が大きく変わります。
主な構成要素は次の通りです。
| コンポーネント | 役割 |
|---|---|
| langfuse-web | Web UI と API |
| langfuse-worker | 非同期処理 |
| PostgreSQL | ユーザー、設定、プロンプトなど |
| ClickHouse | トレース / イベントの集計 |
| Redis | ワーカー用キュー |
| MinIO / S3 互換オブジェクトストレージ | イベントやメディア等のオブジェクト保存 |
v2 と比べると、明らかに運用対象が増えます。特に大きいのは、ClickHouse とオブジェクトストレージです。ClickHouse は、大量のトレースやイベントを集計するためには強力です。
たとえば、次のような集計に向いています。
直近 7 日間のモデル別コスト
プロジェクトごとのトークン使用量
プロンプト version ごとの生成回数
日次のレイテンシ / 利用量集計
一方で、ClickHouse は PostgreSQL だけの構成よりも運用負荷が高いです。
- メモリを使う
- バックアップ設計が必要
- 移行やバージョンアップの注意点が増える
- ディスク使用量を見続ける必要がある
- 障害時に PostgreSQL 以外も調査対象になる
さらに、オブジェクトストレージも必要になります。MinIO を使うなら MinIO 自体の永続化とバックアップが要ります。クラウドの S3 互換ストレージを使う場合、認証情報、バケットポリシー、ネットワーク、保持期間を検討します。Redis もワーカー用キューのために要ります。つまり Langfuse v3 の self-host は、「LLM ログを見るための Web アプリを 1 個立てる」だけの作業ではありません。
小さな監視基盤を運用する、という感覚に近いです。
Langfuse v3 をセルフホストする条件
Langfuse v3 をセルフホストするなら、次の条件を満たせるかを見た方がよいです。
複数コンポーネントの運用
PostgreSQL だけでなく、ClickHouse、Redis、オブジェクトストレージを含めて運用できる必要があります。
ローカル検証なら Docker Compose で動かせても、本番では次のような論点が出ます。
- 各コンポーネントの永続ボリューム
- バックアップ / リストア
- メモリ / ディスクのサイジング
- ヘルスチェック
- アップグレード
- 移行
- 監視
- secret 管理
このあたりを運用できないなら、セルフホスト v3 は重く感じるはずです。
LLM トレースの保存量
Langfuse v3 の構成は、大量の LLM トレースやイベントを扱うことを意識しています。逆に、LLM 呼び出しが少ない PoC や、数人だけの検証では、ClickHouse や MinIO まで持つ構成が過剰になる可能性があります。
小規模なら、まずクラウド版や検証用環境で試す方が軽いです。
LLM 専用 UI の必要性
Langfuse を選ぶ大きな理由は、LLM 専用 UI です。
- プロンプトを見たい
- 出力を見たい
- ユーザーフィードバックを見たい
- score を付けたい
- データセット評価をしたい
- プロンプト version ごとに比較したい
- コスト / トークンを LLM アプリ文脈で見たい
これらが必要なら、Langfuse の価値は大きいです。
逆に、見たいものが「API 全体のレイテンシ」「エラー率」「サービス間トレース」なら、OpenTelemetry + Grafana の方が自然です。
4. 個人情報・機密情報の保存方針を決められる
LLM の入力と出力には、個人情報や機密情報が含まれます。
セルフホストなら SaaS より管理しやすい面はありますが、それでも保存方針は必要です。
- プロンプト / 出力を全文保存するか
- マスキングするか
- 保存期間を何日にするか
- 誰が UI を見られるか
- 監査ログを残すか
- project ごとに権限分離するか
Langfuse は「LLM の中身を見る」ツールなので、ここを曖昧にしたまま本番投入しない方がよいです。
OpenTelemetry / Grafana 側のセルフホスト構成
次に OpenTelemetry / Grafana 側を見ます。OpenTelemetry は、Langfuse のような LLM 専用 UI ではありません。アプリ全体のトレース / メトリクス / ログを扱う標準です。
セルフホストでよくある構成は、たとえば次のようなものです。
アプリ
↓ OTLP
OpenTelemetry Collector
↓
Tempo / Prometheus / Loki
↓
Grafana
それぞれの役割は次の通りです。
| コンポーネント | 役割 |
|---|---|
| OpenTelemetry SDK | アプリからトレース / メトリクスを出す |
| OTel Collector | テレメトリを受け取り、加工して保存先に送る |
| Tempo | トレースを保存する |
| Prometheus | メトリクスを保存する |
| Loki | ログを保存する |
| Grafana | ダッシュボードとアラート |
すでに Prometheus / Grafana を運用しているチームなら、LLM 呼び出しもこの流れに載せやすいです。
OpenTelemetry の gen_ai.* セマンティック規約を使うと、LLM 呼び出しをスパンとして表現できます。
ただし、gen_ai.* は現時点で安定版ではなく、まだ Development ステータスです。標準化の流れにあるものとして取り入れつつ、属性名やメトリクス名の追従コストは見ておいた方がよいです。
たとえば、LLM 呼び出しスパンに次のような属性を付けます。
gen_ai.system = "anthropic"
gen_ai.request.model = "claude..."
gen_ai.usage.input_tokens = 1234
gen_ai.usage.output_tokens = 256
これにより、通常の Web API トレースの中に LLM 呼び出しを含められます。
HTTP request
↓
DB query
↓
LLM call
↓
external API
この構成の強みは、LLM だけでなくサービス全体を見られることです。一方で、Langfuse のような LLM 専用 UI はありません。
プロンプト管理、人手評価、データセット評価は別に用意する必要があります。
Langfuse と OpenTelemetry の役割の違い
セルフホスト前提でも、役割の違いは変わりません。Langfuse は LLM の中身を見るツールです。
OpenTelemetry / Grafana はシステム全体を見るツールです。
| 観点 | Langfuse | OpenTelemetry + Grafana |
|---|---|---|
| 主な目的 | LLM の入出力・評価を見る | サービス全体のトレース / メトリクスを見る |
| プロンプト管理 | 得意 | 対象外 |
| 出力の確認 | 得意 | 可能だが設計が必要 |
| 人手評価 | 得意 | 対象外 |
| データセット評価 | 得意 | 対象外 |
| トークン / コスト集計 | 得意 | 可能だがダッシュボード作成が必要 |
| API / DB / LLM の横断トレース | 主目的ではない | 得意 |
| アラート | 主目的ではない | 得意 |
| 標準化 | Langfuse の仕様に依存 | OpenTelemetry 標準 |
| セルフホストの運用負荷 | v3 は重め | 構成次第。既存基盤があれば軽い |
| すぐ使える LLM 専用 UI | あり | なし |
問いを分けると、判断しやすくなります。
この回答はなぜ出たのか？
→ Langfuse
この API はなぜ遅いのか？
→ OpenTelemetry + Grafana
プロンプト改善をしたい
→ Langfuse
本番障害を追いたい
→ OpenTelemetry + Grafana
LLM の中身も、本番のレイテンシも見たい
→ 併用
セルフホスト前提での選び方
1. LLM 開発・評価が主目的なら Langfuse
LLM のプロンプト、出力、score、データセット、コストを見たいなら Langfuse が向いています。
特に次のような場合です。
- プロンプト改善を継続的に行う
- LLM の回答を後から人間が確認する
- ユーザーフィードバックを蓄積する
- データセットを使ってモデル / プロンプトを比較する
- LLM 呼び出しごとのコストを UI で見たい
ただしセルフホストの場合は、v3 の運用コストを受け入れられるかが条件です。
運用負荷が重いなら、クラウド版やマネージドな選択肢も含めて検討します。
2. 既存監視基盤があるなら OpenTelemetry を優先
すでに OpenTelemetry / Prometheus / Grafana / Tempo を使っているなら、LLM 呼び出しもそこに載せるのが自然です。
特に次のような場合です。
- API 全体の遅延を見たい
- DB / 外部 API / LLM を同じトレースで見たい
- アラートを作りたい
- 複数サービスをまたいで原因調査したい
- 既存の運用チームが Grafana を使っている
- 標準仕様に寄せたい
この場合、Langfuse を入れなくても、最低限の LLM レイテンシ / トークン / エラーは観測できます。
ただし、プロンプト管理や人手評価は別途必要です。
小規模 PoC での v3 セルフホストの重さ
PoC や初期検証では、Langfuse v3 セルフホストはやや重いことがあります。
理由は、必要なコンポーネントが多いからです。
PostgreSQL
ClickHouse
Redis
MinIO / S3
web
worker
もちろん、Docker Compose で試すことはできます。しかし、本番セルフホストではバックアップ、監視、アップグレード、障害対応を考える必要があります。
そのため、小規模 PoC では次のような段階を踏むのが現実的です。
1. まず Langfuse クラウド版や検証用セルフホストで試す
2. LLM 専用 UI が本当に必要か確認する
3. 必要なら v3 セルフホストの運用体制を検討する
4. 既存 Grafana 基盤があるなら OTel 連携も並行して考える
両方必要な場合の併用
Langfuse と OpenTelemetry は排他ではありません。
むしろ、役割を分けて併用するのが自然な場合もあります。
Langfuse:
LLM のプロンプト / 出力 / score / データセット / コスト
OpenTelemetry + Grafana:
API / DB / LLM / external API のトレース / メトリクス / アラート
たとえば Grafana を見て、この API リクエストで LLM 呼び出しが遅い、と判明した状況を考えます。
その後、Langfuse で該当する LLM 呼び出しのプロンプトや出力を確認できます。
Grafana:
どこが遅いかを見る
Langfuse:
LLM の中身を見る
この分担にすると、本番運用と LLM 改善の両方を扱いやすくなります。
導入前チェックリスト
セルフホスト前提で導入するなら、次を確認します。
Langfuse v3 セルフホストを選ぶ前に
- ClickHouse を運用できるか
- Redis を運用できるか
- MinIO / S3 互換オブジェクトストレージを運用できるか
- PostgreSQL / ClickHouse / オブジェクトストレージのバックアップ / リストアを設計できるか
- プロンプト / 出力に含まれる個人情報や機密情報の扱いを決めているか
- UI を見られる人の権限管理を決めているか
- 保存期間を決めているか
- v2 から移行する場合、データ移行の計画があるか
- 小規模利用に対して構成が重すぎないか
OpenTelemetry + Grafana を選ぶ前に
- OTel Collector を運用できるか
- トレース保存先を何にするか決めているか
- メトリクス保存先を何にするか決めているか
- Grafana ダッシュボードを作る人がいるか
- アラート設計をする人がいるか
- LLM のプロンプト / 出力をスパンにどこまで入れるか決めているか
-
gen_ai.*の仕様変更に追従できるか - LLM 専用の評価 UI がなくても足りるか
まとめ
セルフホスト前提で LLM 監視基盤を選ぶなら、最初に見るべきなのは「機能が多いか」ではなく「運用できる構成か」です。Langfuse は、LLM のプロンプト、出力、score、データセット、コストを扱う専用ツールとして便利です。ただし、Langfuse v3 のセルフホストは v2 より構成が重く、PostgreSQL だけでは済みません。ClickHouse、Redis、MinIO / S3 互換オブジェクトストレージ、worker まで含めて運用する前提になります。一方、OpenTelemetry + Grafana は LLM 専用 UI ではありません。しかし、API、DB、外部 API、LLM 呼び出しを同じトレースに載せ、サービス全体の遅延やエラーを見るには向いています。
判断を簡単にすると、こうです。
LLM の中身を見たい:
Langfuse
セルフホストで Langfuse を使う:
v3 の運用負荷を受け入れられるか確認する
サービス全体を見たい:
OpenTelemetry + Grafana
既存の監視基盤がある:
まず OTel gen_ai.* を載せる
両方必要:
併用する
Langfuse と OpenTelemetry は競合というより、見ているレイヤーが違います。
セルフホスト前提では、機能比較だけでなく、運用対象の数、バックアップ、権限管理、保存するデータの機密性まで含めて選ぶのが重要です。