はじめに
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 をセルフホストするなら、次の条件を満たせるかを見た方がよいです。
1. 複数コンポーネントを運用できる
PostgreSQL だけでなく、ClickHouse、Redis、オブジェクトストレージを含めて運用できる必要があります。
ローカル検証なら Docker Compose で動かせても、本番では次のような論点が出ます。
- 各コンポーネントの永続ボリューム
- バックアップ / リストア
- メモリ / ディスクのサイジング
- ヘルスチェック
- アップグレード
- 移行
- 監視
- secret 管理
このあたりを運用できないなら、セルフホスト v3 は重く感じるはずです。
2. LLM トレースの保存量がそれなりにある
Langfuse v3 の構成は、大量の LLM トレースやイベントを扱うことを意識しています。
逆に、LLM 呼び出しが少ない PoC や、数人だけの検証では、ClickHouse や MinIO まで持つ構成が過剰になる可能性があります。
小規模なら、まずクラウド版や検証用環境で試す方が軽いです。
3. 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 レイテンシ / トークン / エラーは観測できます。
ただし、プロンプト管理や人手評価は別途必要です。
3. 小規模 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 連携も並行して考える
4. 両方必要なら併用する
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 は競合というより、見ているレイヤが違います。
セルフホスト前提では、機能比較だけでなく、運用対象の数、バックアップ、権限管理、保存するデータの機密性まで含めて選ぶのが重要です。