🔭

LLMアプリの観測性ツール7選を比較した結果、私がLangfuseを選んだ理由

に公開
Observability
llm
LangSmith
Langfuse
GenAIOps
tech

LLMアプリは「動いている」だけでは足りない

LLMアプリ開発を始めて、最初に直面する壁があります。

HTTPステータス200が返っていても、回答がデタラメかもしれません。

従来のWeb APIなら、レスポンスタイムとステータスコードを見ていれば健康状態はおおよそわかりました。しかしLLMを組み込んだAPIには、従来のAPIにはない3つの特性があります。

  1. 非決定的な出力 ── 同じリクエストでも毎回違う回答が返ります。200 OKでも中身は保証されません。
  2. 見えないコスト ── トークン課金は1リクエストごとは小さくても、月末に「えっ、こんなに？」が起こります。
  3. 変動するレイテンシ ── プロンプトの長さやモデルの負荷で応答時間が大きく揺れます。

Webエンジニアなら Datadog や Sentry でアプリを監視した経験があるでしょう。LLMアプリにも同じ「観測性（Observability）」が必要ですが、LLM特有のメトリクス──使用トークン数、コスト、プロンプトと応答の中身──を追跡するには、専用のツールが求められます。

2024〜2025年にかけて、この領域のツールは爆発的に増えました。選択肢が多すぎて「結局どれを使えばいいのか」がわかりにくい状況です。

本記事では、主要な7つのツールを比較した上で、私がなぜLangfuseを選んだのかを整理します。

主要ツール7選：一覧と特徴

まず全体像を俯瞰しましょう。各ツールの立ち位置を一言で表すと以下の通りです。

ツール 一言で言うと OSS
Langfuse LLM観測のスイスアーミーナイフ Yes（MIT）
LangSmith LangChain公式の専用ツール No
Arize Phoenix OpenTelemetryネイティブの実験特化型 Yes（Apache 2.0）
Helicone URLを変えるだけの最速導入ゲートウェイ Yes
Portkey マルチLLMプロバイダの経路制御＋観測 一部Yes
Braintrust 評価・A/Bテスト特化型 一部Yes
Datadog LLM Observability 既存インフラ監視へのLLMアドオン No

以下、それぞれ掘り下げていきます。

1. Langfuse ── 観測・評価・プロンプト管理のオールインワン

https://langfuse.com/

Langfuseの最大の特徴は、1つのプラットフォームで3つの機能が揃うことです。

  • トレース: 各APIコールの入出力、処理時間、使用トークン数、コストを自動記録
  • 評価: LLM-as-a-Judgeや人手評価のスコアリング
  • プロンプト管理: バージョン管理、UIからのデプロイなしでの切り替え

Webエンジニアへの類推で言えば、Datadog（APM）+ LaunchDarkly（Feature Flag）+ テストダッシュボードが1つになったようなものです。

from langfuse.decorators import observe

@observe()
def handle_question(question: str) -> str:
    context = retrieve_documents(question)  # RAG検索
    prompt = build_prompt(question, context)  # プロンプト構築
    response = call_llm(prompt)              # LLM呼び出し
    return response

@observe() デコレータを付けるだけで、関数の入出力・実行時間・トークン数が自動でLangfuseに送信されます。LangChain、LlamaIndex、OpenAI SDK、Vercel AI SDK、あるいは独自実装──何を使っていても統合できるフレームワーク非依存設計がポイントです。

向いているケース:

  • フレームワークに縛られない独自パイプライン構成
  • トレースからプロンプト管理まで一元管理したい
  • OSSでセルフホストも視野に入れたい（Cloud版の無料プランもあり）

注意点:

  • セルフホストにはClickhouse + Redis + S3が必要で、構成がやや重めです

2. LangSmith ── LangChainユーザーの第一選択肢

https://smith.langchain.com/

LangChainを作っている会社が提供する公式ツールです。環境変数を1つ設定するだけで、LangChain/LangGraphのすべてのステップが自動トレースされます。

export LANGCHAIN_TRACING_V2=true
export LANGCHAIN_API_KEY=your-key
# これだけ。コード変更ゼロ。

パフォーマンスオーバーヘッドも極めて小さく、LangChainで開発しているなら導入のハードルは最も低いです。

向いているケース:

  • LangChain/LangGraphで開発しており、最速で観測性を手に入れたい

注意点:

  • クローズドソースです。LangChainエコシステムへの依存度が高くなっています
  • LangChain以外のフレームワークとの統合は手間がかかります
  • ベンダーロックインのリスクがあります

3. Arize Phoenix ── OpenTelemetry時代の実験プラットフォーム

https://github.com/Arize-ai/phoenix

OpenTelemetry（OTLP）にネイティブ対応したオープンソースツールです。既にDatadogやJaegerでOTel基盤を構築しているチームなら、既存のパイプラインにそのまま乗せられます。

最大の魅力はセルフホストの手軽さです。Dockerコンテナ1つで起動できます。Langfuseのセルフホストが「Clickhouse + Redis + S3」を要求するのに対し、Phoenixは圧倒的に軽いです。

向いているケース:

  • OpenTelemetry基盤が既にある
  • セルフホストを最小構成で始めたい
  • 実験・開発フェーズの分析に注力したい

注意点:

  • プロンプト管理機能がありません
  • 本番環境でのコスト監視・使用量モニタリングは弱めです

4. Helicone ── コード1行で始める最速導入

https://www.helicone.ai/

Heliconeのアプローチは他と根本的に違います。SDKを組み込むのではなく、LLM APIのベースURLをHeliconeのプロキシURLに差し替えるだけで導入が完了します。

# Before
client = OpenAI(api_key="sk-...")

# After（これだけ）
client = OpenAI(
    api_key="sk-...",
    base_url="https://oai.helicone.ai/v1"
)

プロキシとして動作するため、レスポンスキャッシュやプロバイダフォールバックといったゲートウェイ機能も使えます。「まず最小コストで観測性を入れたい」というケースに強いです。

向いているケース:

  • 今すぐ、最小の変更でログを取り始めたい
  • コスト追跡・キャッシュ・フォールバックもまとめて欲しい

注意点:

  • リクエストがHeliconeを経由するため、レイテンシが増える可能性があります
  • 評価・プロンプト管理の深さではLangfuseに劣ります

5. Portkey ── マルチプロバイダ時代のAIゲートウェイ

https://portkey.ai/

「OpenAIとAnthropicとGeminiを使い分けている」──そんなチームにはPortkeyが刺さります。1,600以上のLLMプロバイダに対応し、ルーティング・フォールバック・ロードバランシングを一元管理できるAIゲートウェイです。

観測性はゲートウェイの付随機能として提供されます。リクエスト/レスポンスの40以上の詳細メトリクスを自動記録し、APIキーのVault管理やガードレール機能も内蔵されています。

向いているケース:

  • 複数のLLMプロバイダを使い分けており、経路制御が必要
  • ゲートウェイ＋観測を1つのツールで済ませたい

注意点:

  • 観測・評価の深さでは専業のLangfuseに劣ります
  • ゲートウェイが主目的なので、観測だけが目的なら過剰な場合があります

6. Braintrust ── 評価とA/Bテストに振り切ったプラットフォーム

https://www.braintrust.dev/

「モデルAとモデルBで、どちらのプロンプトがより良い結果を出すか？」──この問いに最も直接的に答えてくれるのがBraintrustです。実験管理・モデル比較・A/Bテストに特化しており、CI/CDパイプラインへの組み込みも容易です。

向いているケース:

  • プロンプトやモデルの比較実験を頻繁に行う
  • 評価をCI/CDに組み込みたい

注意点:

  • トレース機能は付随的です。本番監視にはLangfuseなど別ツールとの併用が必要な場合があります

7. Datadog LLM Observability ── 既存の監視基盤にLLMを追加

https://www.datadoghq.com/product/llm-observability/

チームが既にDatadogでインフラ・APMを運用しているなら、LLMの監視も同じダッシュボードに統合できます。新しいツールを導入する学習コスト・運用コストがゼロになるのは大きなメリットです。

向いているケース:

  • 既にDatadogで運用監視しており、ダッシュボードを統一したい
  • エンタープライズ規模のスケーラビリティが必要

注意点:

  • LLM専用設計ではないため、プロンプト管理・LLM特有の評価機能は弱めです
  • 料金がエンタープライズ寄りです。個人や小規模チームには向きません

選び方の早見表

あなたの状況 おすすめ 理由
LangChainで開発中、最速で入れたい LangSmith 環境変数1つ、オーバーヘッド最小
フレームワーク非依存で本番運用まで Langfuse 観測＋評価＋プロンプト管理がオールインワン
OTel基盤あり、軽量セルフホスト希望 Arize Phoenix Dockerコンテナ1つで起動
今すぐ最小変更でログを取りたい Helicone APIベースURL変更だけ
複数LLMプロバイダの経路制御が必要 Portkey ルーティング・フォールバック込み
評価・実験比較に注力したい Braintrust A/Bテスト・CI/CD統合が得意
既にDatadogで運用監視している Datadog 既存ダッシュボードに統合可能

私がLangfuseを選んだ理由

ここまで客観的に各ツールを比較してきました。ここからは私個人の選択理由を書きます。

理由1: フレームワークに縛られたくなかった

私のプロジェクトはFastAPI + 独自RAGパイプラインという構成です。LangChainは使っていません。この時点でLangSmithは候補から外れます。

Langfuseは @observe() デコレータやPython SDKで、どんなコードにも後付けで統合できます。フレームワークの選択がツールの選択を制約しません。これは「モデルもフレームワークも頻繁に変わるLLM開発」において、想像以上に重要です。

理由2: 「観測 → 評価 → プロンプト管理」を1ツールで回せる

開発初期はトレースだけあれば十分でした。しかしプロジェクトが進むにつれて、「この回答は本当に正しいのか？」（評価）、「プロンプトを変えたい」（プロンプト管理）というニーズが必ず出てきます。

Langfuseなら、ツールを乗り換えることなく段階的に機能を使い始められます。ツールの乗り換えコストはゼロです。

別の記事でも書きましたが、プロンプトをコードにハードコードするのは悪手です。Langfuseのプロンプト管理を使えば、エンジニア以外のメンバーもGUI上でプロンプトを修正・テストできます。デプロイなしで本番の振る舞いを変えられるのは、チーム開発では計り知れないメリットになります。

理由3: OSSであること

LLMの観測データには、ユーザーの質問内容やAIの回答が含まれます。つまり機密性の高いデータです。

Langfuseはオープンソース（MIT License）なので、必要に応じてセルフホストに移行し、データを自社管理下に置けます。Cloud版の無料プランで気軽に始めて、プロジェクトが大きくなったらセルフホストに切り替える──この段階的な移行パスがあるのは安心感があります。

理由4: コミュニティと開発の活発さ

GitHub Stars 6,000超、LangChain・LlamaIndex・OpenAI SDKとの公式インテグレーション、活発なDiscordコミュニティ。OSSプロジェクトの持続性を判断する上で、このエコシステムの厚みは重要です。

まとめ：「とりあえずLangfuse」で始めて問題ない

正直なところ、LLM観測性ツールの選定に正解はありません。プロジェクトの規模、使っているフレームワーク、チームの既存ツールスタックによって最適解は変わります。

しかし、迷っているならLangfuseから始めるのが最も安全な選択ですと私は考えます。理由は明快で：

  • フレームワークを問わない
  • 無料で始められる
  • 必要に応じて機能を段階的に使える
  • OSSなので逃げ道がある

LangChainを使っているならLangSmith、既にDatadogがあるならDatadog、とにかく最速で入れたいならHelicone──それぞれ「こっちの方が良い」ケースは確かにあります。

しかし、「今はまだ決めきれない」「将来どうなるかわからない」という状況なら、汎用性とオールインワンのバランスが最も良いLangfuseが、後悔の少ない選択になるはずです。

LLMアプリの設計論については、こちらの記事も参考にしてみてください:
LLMアプリ開発で死なないための設計思想 - Langfuse時代の実務ベストプラクティス

GitHubで編集を提案

Discussion