グラレコ
はじめに 🎯
langfuse/langfuse は、LLM（大規模言語モデル）を使ったアプリケーションを 開発・監視・評価・デバッグ するための、オープンソースのプラットフォームです。2023年に公開され、GitHub のスターは執筆時点で約28,400。Y Combinator の 2023年冬バッチ（W23）出身のプロジェクトでもあります。本体は TypeScript 製で、ライセンスは MITです。
LLMアプリは、作るだけなら意外と簡単に動きます。けれど本番で運用し始めると、「なぜこの回答になったのか」「どこで時間がかかっているのか」「品質は上がっているのか下がっているのか」が見えなくて困る、という壁にぶつかります。プロトタイプでは気持ちよく動いていたのに、実際のユーザーに使わせ始めた途端、「たまに変な答えを返す」「なぜか遅い」といった声が上がる。でも、出てきた回答だけを見ても原因がわからない——この「中が見えない」もどかしさは、LLMアプリを運用した人なら覚えがあると思います。
Langfuse は、この 可観測性（observability） を中心に、LLMアプリの運用を支えようとするツールです。この記事では、LLMアプリを開発・運用するエンジニアに向けて、Langfuse が何を解決するのか、どんな機能があるのか、どう始めるのか、そしてチームでどう運用に乗せていくかまでを整理していきます。
この記事でわかること:
- 🤔 LLMアプリの運用が、ふつうのアプリ運用と何が違うのか（読み方の前提）
- 🔍 observability（可観測性）が、LLMアプリでなぜ重要なのか
- 🧰 6つの主要機能（トレーシング / プロンプト管理 / 評価 / データセット / プレイグラウンド / API）
- 🔌 20を超える統合（OpenAI、Langchain、LiteLLM、OpenTelemetry など）
- 🗺️ 評価設計・Dataset化・Prompt Management の現実的な運用
- 🚀 クラウドとセルフホストの選び方
- 🐍 SDKでの始め方と、最初の30日の進め方
- 👥 チーム導入でつまずきやすいところ
少し長めですが、「自分たちの運用に組み込めそうか」を判断できる材料を詰め込みました。気になる見出しから読んでも大丈夫です。
まず前提を揃える — LLMアプリの運用は何が違うのか 🧭
Langfuse の話に入る前に、「LLMアプリの運用は、ふつうのアプリ運用と何が違うのか」を押さえておきます。
ふつうのアプリは、基本的に 同じ入力には同じ出力 を返します。バグがあれば、同じ手順で再現できます。だからログを見れば、たいてい原因にたどり着けます。
ところが LLMアプリは違います。同じ入力でも、毎回少しずつ違う出力 になり得ます。さらに、内部では検索・プロンプト組み立て・モデル呼び出し・ツール利用などが何段にも重なっていて、どこで品質が落ちたのかが見えにくいのです。「なんとなく最近回答が悪い気がする」を、感覚ではなくデータで追えるようにする——これが LLMアプリ運用の難しさであり、Langfuse が狙う領域です。
この図は、ふつうのアプリと LLMアプリの「追いやすさ」の違いを示しています。読み取ってほしいのは、LLMアプリは 出力が揺れるうえに処理が多段なので、専用の見える化が要る という点です。ふつうのアプリ向けの監視だけでは、LLM特有の「なぜこの答えになったか」には届きにくいのです。
なぜ「可観測性」が要るのか 🔍
LLMアプリは、内部でいろいろなことが起きています。ユーザーの入力を受け、関連情報を検索し、プロンプトを組み立て、モデルを呼び、ときにはエージェントが複数のツールを使う——。ところが、出てきた回答だけを見ていても、「途中で何が起きたか」がわかりません。良い回答ならまだしも、変な回答が返ってきたとき、どこが原因なのかを追えないのは厳しいものです。
ここで出てくるのが observability（可観測性） という考え方です。これは「システムの内部で起きていることを、外から観察できる状態にしておく」という意味です。その中核が トレーシング（tracing）、つまり一連の処理の流れを記録して後から追えるようにすることです。
この図は、可観測性の有無で「困ったときに追えるかどうか」が変わることを示しています。読み取ってほしいのは、Langfuse が 処理の一つひとつのステップを記録し、後から「ここでこうなった」と辿れるようにする という点です。これがあると、変な回答に出会ったときに原因の場所まで降りていけます。
💡「トレース」は、ひとつのリクエストが処理される間に起きたことを、時系列でつないだ記録です。検索に何を使い、どんなプロンプトを組み、モデルが何を返したか——を一連の流れとして残します。これがあると、後から「3番目のステップで関係ない情報を拾っていた」のように、問題の場所を特定できます。
6つの主要機能 🧰
Langfuse は、可観測性を起点に、LLMアプリ運用に必要な機能を一通り揃えています。主要な6つ＋APIを見ていきます。
この図は、Langfuse が提供する機能群を俯瞰したものです。それぞれを簡単に説明します。
LLM Observability（トレーシング）: アプリにトレーシングを組み込み、LLM呼び出し・検索・埋め込み・エージェントの行動などを追跡します。複雑なログやユーザーセッションを検査・デバッグできます。Langfuse の中心機能です。
Prompt Management（プロンプト管理）: プロンプトを一元管理し、バージョン管理します。チームで協力しながら改善でき、サーバー側・クライアント側のキャッシュによって、運用に余計な遅延を足さずに反復できる、とされています。
Evaluations（評価）: 品質をどう測るかの部分です。LLM-as-a-judge（LLM自身に別のLLMの出力を採点させる手法）、コードによる評価、ユーザーフィードバックの収集、手動ラベリング、カスタム評価パイプラインに対応します。
Datasets（データセット）: テストセットやベンチマークを作る機能です。デプロイ前のテストや、構造化した実験に使えます。
LLM Playground（プレイグラウンド）: プロンプトやモデル設定を試す場です。トレーシングで悪い結果を見つけたら、そこから直接プレイグラウンドに飛んで改善できる、という導線になっています。
Metrics（メトリクス）: パフォーマンスの計測です。
そして API: OpenAPI 仕様、Postman コレクション、Python / JS / TS の型付き SDK が提供されています。
💡「LLM-as-a-judge」は、人間が全部の出力を採点する代わりに、LLMに採点役をやらせる手法です。スケールしやすい一方、judge 自身の精度も見ておく必要があります。Langfuse はこれを含む複数の評価方法をまとめて扱えます。
6機能はバラバラではなく「改善のループ」になっている
ここで大事なのは、この6つが独立した機能の寄せ集めではなく、ひとつの改善ループ としてつながっていることです。
この図は、6機能が「発見 → 改善 → 記録 → テスト化 → 評価」という循環を作る様子を示しています。読み取ってほしいのは、Langfuse が 「観測して終わり」ではなく、観測から改善・評価まで一周できるように設計されている という点です。トレースで問題を見つけ、Playground で直し、それを Dataset に加えて以後のテストにし、Evaluations で良くなったかを測る。この一周を回し続けることが、LLMアプリの品質を地道に上げていくことにつながります。
20を超える統合 🔌
Langfuse を導入するうえで現実的に大事なのが、自分が使っているフレームワークやSDKとつながるか です。Langfuse は20以上の主要パッケージと統合できる、とされています。代表的なものを挙げます。
| 統合先 | つなぎ方（READMEより） |
|---|---|
| OpenAI (Python/JS/TS) | SDK を置き換えるだけで自動計測 |
| Langchain (Python/JS/TS) | コールバックハンドラで自動計測 |
| LlamaIndex (Python) | コールバックシステム経由 |
| LiteLLM (Python/JS/TS) | 複数LLMの統一インターフェース |
| OpenTelemetry | 標準的な可観測性の規格に対応 |
| Vercel AI SDK / Mastra (JS/TS) | エージェント系フレームワーク |
このほかにも、Haystack、Instructor、DSPy、Ollama、Amazon Bedrock、AutoGen、Flowise、Langflow、Dify、OpenWebUI、CrewAI など、幅広いツールに対応しています。
💡OpenTelemetry は、システムの可観測性データ（トレースやメトリクス）を扱うための業界標準の規格です。これに対応していると、Langfuse 専用の作り込みに縛られず、既存の可観測性のしくみと地続きで使えます。
「いま使っているスタックにそのまま差し込める」ことが多いのは、導入のハードルを下げる大きなポイントです。たとえば OpenAI の SDK をそのまま置き換えるだけ、Langchain ならコールバックを1つ足すだけ、というように、アプリの作りを大きく変えずに計測を始められる のが現実的なメリットです。
実際、Langflow、Open WebUI、Lobe Chat、LlamaIndex、Firecrawl、LiteLLM といった有名なOSSプロジェクトが Langfuse を採用している、とREADMEに挙げられています。
評価とデータセットの運用 🗺️
可観測性は「見える化」ですが、Langfuse の価値はそこから一歩進んで「品質を測って良くする」ところにあります。ここは導入後の運用で効いてくる部分なので、少し丁寧に見ておきます。
評価設計の考え方
LLMアプリの品質を測るのは、ふつうのテストより難しいです。「正解が1つに決まらない」からです。たとえば要約タスクなら、良い要約はいくつもあり得ます。Langfuse は、この難しさに複数のアプローチで対応します。
- LLM-as-a-judge: LLMに採点させる。スケールしやすいが、judge自身の精度も確認が要る
- コードによる評価: 「特定のキーワードを含むか」など、機械的に判定できるもの
- ユーザーフィードバック: 実際のユーザーの「良い/悪い」を集める
- 手動ラベリング: 人が目で見て採点する。少数でも基準づくりに有効
実務では、これらを 組み合わせる のが現実的です。まず手動ラベリングで「何を良しとするか」の基準を作り、それを LLM-as-a-judge に落とし込んでスケールさせ、ユーザーフィードバックで実際の手応えを確かめる、という流れです。
Dataset化で「再現できるテスト」を作る
評価を一度きりで終わらせず、継続的に回すには Datasets が効きます。トレースで見つけた「悪い結果」を Dataset に加えていくと、それが以後の回帰テスト（前は直したのに、また悪くなっていないかを確かめるテスト）になります。
この図は、本番で見つけた問題を Dataset に取り込み、デプロイ前のテストとして使い回す流れを示しています。読み取ってほしいのは、「本番で起きた失敗」を「次は防ぐためのテスト」に変えられる という点です。これを続けると、テストセットが自分たちのアプリの弱点を反映した実用的なものに育っていきます。
Prompt Management の運用
プロンプトは、コードと同じくらい品質を左右します。Langfuse の Prompt Management は、プロンプトを バージョン管理 できるので、「この変更で良くなったのか・悪くなったのか」を後から追えます。しかもキャッシュが効くので、運用に余計な遅延を足さずに反復できる、とされています。
運用のコツは、プロンプトを「コードの外」で管理すること です。プロンプトをコードに直書きすると、変更のたびにデプロイが必要になります。Langfuse で管理すれば、プロンプトの改善とアプリのデプロイを切り離せて、改善のサイクルが速くなります。
クラウドとセルフホストの選び方 🚀
Langfuse は、使い始め方をいくつか用意しています。手元で試すのか、本番で運用するのかで選びます。
この図は、利用シーン別のデプロイ選択肢を示しています。
- Langfuse Cloud: 公式が運用するマネージド版。無料枠があり、クレジットカードは不要です。とりあえず試すなら最短です。
-
ローカル（Docker Compose）:
git cloneしてdocker compose upするだけで、5分ほどで起動できる、とされています。手元の検証向きです。 - Kubernetes（Helm）: 本番運用の推奨構成です。
- Terraform: AWS / Azure / GCP 向けのテンプレートが用意されています。
セルフホストの場合、Langfuse は内部で ClickHouse（大量のデータを高速に集計するのが得意なデータベース）を使っています。
どれを選ぶか
選択肢が多いと迷うので、判断の目安を示します。
| 状況 | おすすめ | 理由 |
|---|---|---|
| まず試したい / 個人・小規模 | Langfuse Cloud | 無料枠で最速。インフラ管理が不要 |
| データを社外に出せない | セルフホスト（Docker→K8s） | トレースが自社環境に閉じる |
| すでにK8s基盤がある | Kubernetes (Helm) | 既存の運用に乗せやすい |
| IaCで管理したい | Terraform | 構成をコードで再現できる |
「まずは Cloud の無料枠で触ってみて、データの取り扱い要件やスケールの都合でセルフホストが必要になったら移行する」 という順序が現実的です。最初からセルフホストでフル構成を組もうとすると、ClickHouse を含むインフラの運用が負担になりがちです。Cloud で価値を確かめてから、本格運用の形を考えるのが無理がありません。
⚠️ライセンスは「MIT」です。Enterprise Edition にあたる ee フォルダの部分は別ライセンスなので、セルフホストで使う範囲を確認しておくと安心です。
SDKでの始め方 🐍
Python を例に、最小の始め方を見てみます。OpenAI と一緒に使う場合です。
pip install langfuse openai
使い方の中心は @observe() デコレータ です（以下は概念を示すための例で、実際のAPIはバージョンによって変わり得ます）。関数にこれを付けると、その関数の実行がトレースとして記録される、というイメージです。OpenAI 統合を使えば、モデルのパラメータなども自動的に取得されます。実行結果は Langfuse のダッシュボードに表示され、後から追える状態になります。
認証やエンドポイントは、環境変数で指定します。
-
LANGFUSE_SECRET_KEY— シークレットキー -
LANGFUSE_PUBLIC_KEY— パブリックキー -
LANGFUSE_BASE_URL— 接続先（Cloud か、自分でセルフホストした先か）
「まず Cloud に登録して、SDK を入れて @observe() を付ける」だけで、トレースがダッシュボードに流れ始める、という手軽さです。正確な書き方は変わり得るので、実装時は公式ドキュメントの最新のサンプルを確認してください。
💡テレメトリ（利用状況データ）が収集される設定になっていますが、生のトレース・プロンプト・スコアは含まれない、とされています。気になる場合は TELEMETRY_ENABLED=false で無効化できます。
最初の30日の進め方
入れただけで終わらないよう、最初の1か月の目安を置いておきます。あくまで一例です。
| 時期 | やること | ねらい |
|---|---|---|
| 1週目 | Cloudに登録し、SDKでトレースを流す | 「中が見える」感覚をつかむ |
| 2週目 | 悪い結果をPlaygroundで直してみる | 観測→改善の往復を体験 |
| 3週目 | 改善した例をDatasetに溜める | テスト化の習慣を作る |
| 4週目 | LLM-as-a-judge等で評価を回す | 品質を数字で追えるようにする |
この表のポイントは、「観測 → 改善 → テスト化 → 評価」を1か月で一周してみる ことです。まず見えるようにし、直してみて、それをテストに変え、品質を測る。この一周を体験しておくと、Langfuse をただのログビューアではなく「改善のループ」として使えるようになります。
チーム導入でつまずきやすいところ 👥
個人で試すぶんには簡単な Langfuse ですが、チームで運用に乗せるときには、いくつかつまずきやすいポイントがあります。先に知っておくと回避しやすいので、共有しておきます。
1つ目は、「入れただけ」で止まりがちなこと です。トレーシングを仕込むところまではやったものの、誰もダッシュボードを見ない、という状態になりやすいです。対策としては、「変な回答の報告が来たら、まずトレースを見る」という運用のルールを最初に決めておくのが効きます。
2つ目は、評価の基準づくりが後回しになること です。「品質を測ろう」と言いつつ、何を良しとするかが曖昧なまま LLM-as-a-judge を回すと、judge の採点が信用できません。少数でいいので、最初に手動ラベリングで基準を作るのが遠回りなようで近道です。
3つ目は、プロンプトの管理場所が分散すること です。コードに直書きする人、スプレッドシートで管理する人、Langfuse で管理する人が混在すると、どれが最新か分からなくなります。Prompt Management に寄せると決めたら、チームで揃えるのが大事です。
どんな人に向いているか ⚖️
ここまでを踏まえて、向き・不向きを整理します。
| こんな人に向いている | 理由 |
|---|---|
| LLMアプリを本番運用している | トレーシングで原因を追える |
| プロンプトをチームで改善したい | バージョン管理＋協力的な反復 |
| 品質を継続的に測りたい | 評価・データセット機能 |
| 既存スタックを変えたくない | 20+の統合、OpenTelemetry対応 |
| データを自社で持ちたい | セルフホスト（Docker/K8s/Terraform） |
逆に、まだ試作段階で本番運用していないなら、可観測性の機能はオーバースペックに感じるかもしれません。とはいえ、Cloud の無料枠で手軽に始められるので、「本番に出す前に一度トレースを見てみる」 くらいの軽い気持ちで触ってみるのがよさそうです。「観測が要るほど複雑なことはまだしていない」段階なら、無理に全機能を使わず、トレーシングだけから始めるのも十分ありです。
まとめ 🏁
Langfuse をひとことでまとめると、「LLMアプリの中で何が起きているかを追えるようにし、プロンプト改善や品質評価まで支えるオープンソースの運用基盤」 です。
個人的にいちばん価値を感じるのは、「なぜこの回答になったか」を後から辿れる という一点です。LLMアプリは、動かすだけなら簡単になりました。けれど本番で信頼して使い続けるには、変な挙動の原因を追える状態がどうしても要ります。Langfuse はそこに、トレーシングを起点とした答えを出しています。
そして観測で終わらず、Playground での改善、Dataset でのテスト化、Evaluations での品質測定まで一周できるように設計されているのが、長く使ううえでの強みです。しかも、OpenAI や Langchain、LiteLLM、OpenTelemetry といった広く使われているものに差し込めるので、いまのスタックを大きく変えずに始められます。導入のハードルが低いのは、運用ツールとしてはとても重要な性質です。
LLMアプリを運用していて「中が見えなくて困っている」なら、まずは Cloud の無料枠に登録して、@observe() を1つ付けてみるところから試してみてください。最初の一周（観測 → 改善 → テスト化 → 評価）を体験すれば、Langfuse が単なるログビューアではなく、品質を地道に上げていくための「改善のループ」だと実感できると思います。