第3章: 競合地図と選定フレーム — LangSmith・Phoenix・Helicone との違い | Langfuse Deep Dive

LLMオブザーバビリティ市場の5カテゴリ

「LangfuseかLangSmithか」という二項対立で語られがちなLLMオブザーバビリティ市場ですが、実際には設計思想と得意領域が異なる 5つのカテゴリ に分化しています。カテゴリ内で競合する製品は当然ありますが、カテゴリ間では多くの場合「補完」の関係にあります。

カテゴリ	代表プロダクト	特徴
フレームワーク一体型SaaS	LangSmith（LangChain）、W&B Weave	フレームワーク提供元による純正、LangChain/LangGraphの統合が厚い
OSS観測基盤	Langfuse、Arize Phoenix、OpenLLMetry/Traceloop	Self-host可能、MIT/Apacheライセンス、OpenTelemetry準拠
Proxy/Gateway型	Helicone、Portkey、LiteLLM proxy	ワンラインでLLM APIの前段に挟む、キャッシュ・コスト削減が得意
評価・Dataset特化	Braintrust、PromptLayer	Evaluationワークフローが中心、Tracing機能もある
汎用APM拡張	Datadog LLM Observability、Pydantic Logfire	既存APM基盤にLLM機能を追加、インフラと一元化

Langfuse vs LangSmith — 最頻出の比較

「LangfuseはLangSmithの代替か？」は最も多い問いの1つです。答えは「用途次第」。両者の本質的な違いは フレームワークへの依存度とライセンスモデルの2軸に集約されます。

観点	Langfuse	LangSmith
ライセンス	MIT（コア全機能）	プロプライエタリ SaaS
Self-hosted	無料・Cloud機能同等	Enterprise契約必須
フレームワーク	非依存。OTel経由で80+統合	LangChain/LangGraph最適化
料金単位	Unit（trace/observation/score 各1）	Root execution（trace）
無料枠（2026年時点）	50,000 units/月・30日保持・2ユーザー	5,000 traces/月
主要プラン（月額）	Core $29 / Pro $199 / Ent $2,499	Developer / Plus / Enterprise
Evaluation	OK（LLM-as-Judge、Managed/Custom）	より成熟（CI/CD統合が強い）
監視/アラート	OK	すぐ使えるダッシュボード・アラートが強い
データ主権	完全エアギャップ可	ハイブリッド・基本クラウド
準拠	SOC2 Type II / ISO27001 / GDPR / HIPAA（Pro以上）	SOC2 / GDPR / HIPAA（Enterprise）

Langfuse vs Arize Phoenix — OSS同士の棲み分け

Arize Phoenix はArize AI（エンタープライズML観測SaaS）が提供するOSS LLM観測ツール。ライセンスはApache系で、Self-hostは単一Dockerコンテナで完結します。Langfuseとの違いは「スコープの広さ」と「セットアップの重さ」です。

観点	Langfuse	Arize Phoenix
ライセンス	MIT（コア）	Elastic License 2.0系 / Apache要素
位置付け	本番運用向けフルプラットフォーム	ローカルデバッグ・実験向け（Arize AXの入門層）
Self-host難度	高い（ClickHouse/Redis/S3/Postgresを別構築）	低い（単一Dockerで完結）
OTel	Native（/api/public/otel OTLP受信）	Native（OpenInferenceを自社開発・同梱）
計装	サードパーティ（OpenLLMetry/OpenInference等）依存	自社計装ライブラリOpenInferenceを同梱
Playground / LLM-as-Judge	Cloudでは有料プラン、Self-hostedはMITで全部無料	全て無料（OSS同梱）
機能成熟度	本番ワークロード志向で機能厚い	軽量・開発者向けツール色が強い
Self-host機能	Cloudと機能同等	Self-hostはArize AX Cloudと非同等

Langfuseの v3 以降は ClickHouse + Redis + S3 の構成が必須で、ローカルでサクッと立ち上げるにはやや重量級です。一方 Phoenix は pip install arize-phoenix とJupyterノートブックの数行で可視化できるほど軽量。「手元で実験中のRAGパイプラインをデバッグしたい」なら Phoenix、「本番アプリのObservability基盤として10年運用する」なら Langfuse、という切り分けが自然です。

Langfuse vs Helicone — Proxyアプローチの違い

Helicone は Y Combinator S23 出身の観測プラットフォームで、特徴は 「ワンラインProxyで計装」。 LLM APIのベースURLをHeliconeのエンドポイントに差し替えるだけで、SDK改修なしで観測が始められます。ネイティブキャッシュ機能を持ち、コスト削減20〜40%を謳う点もLangfuseにはない強みです。

観点	Langfuse	Helicone
統合方式	SDKファースト（OTel経由も可）	ワンラインProxy（SDK非同期ロギングも可）
アーキテクチャ	Postgres中心（+ClickHouse/Redis/S3 v3以降）	Cloudflare Workers + ClickHouse + Kafka
ライセンス	MIT	Apache 2.0
Self-host	可（構築やや複雑）	可
無料枠	50k units/月	100k requests/月
有料開始	Core $29 / Pro $199	$20/seat（Pro）
キャッシュ	ネイティブ無し	ネイティブあり（20〜40%コスト削減）
Prompt Management	強い（バージョニング/実験）	あり
エージェントTrace	強い	限定的
UI/導入易さ	SDK改修が必要	ワンラインで直感的

その他の競合 — 一覧比較

5カテゴリに出てきたその他の製品も含めて、主要な13製品を一覧で俯瞰します。機能「○」は十分実用的、「△」は部分的、「×」は未実装を示します。料金・機能は2026年初頭時点で変動しうるため、最終判断時は公式を確認してください。

製品	OSS	Self-host	OTel	Trace	Prompt Mgmt	Eval	Dataset	Playground
Langfuse	MIT	○（全機能）	Native	○	○	○	○	○
LangSmith	×	契約	部分	○	○	○（成熟）	○	○
Arize Phoenix	○	○（単一Docker）	Native	○	△	○（無料）	○	○
Helicone	Apache	○	対応	○（Proxy）	○	一部	○	△
OpenLLMetry/Traceloop	Apache	○	Native	○	△	△	○	×
W&B Weave	一部OSS	限定	対応	○	○	○	○	○
Braintrust	×	Enterprise	対応	○	○	○（中心）	○（中心）	○
PromptLayer	×	×（SaaSのみ）	OTel対応	○	○（中心）	○	○	○
Portkey	Gateway MIT	○（Gateway）	OTel	○（Gateway）	○	○	○	○
LiteLLM proxy	MIT	○	OTel対応	転送のみ	×	×	×	×
Datadog LLM Obs	×	SaaS/Agent	対応	○	△	○	○	×
Pydantic Logfire	部分	ほぼSaaS	Native	○	△	△	△	×
OpenInference	○（仕様）	—	Native	仕様	—	—	—	—

選定フローチャート

実務の選定は「1対1の比較」ではなく、プロジェクト制約から絞り込むフローで行うのが現実的です。以下は2026年時点の実務的な意思決定ツリーです。

flowchart TD
  S[選定開始] --> Q1{LangChain/LangGraph中心?}
  Q1 -->|Yes| LS[LangSmith推奨\nロックイン許容必須]
  Q1 -->|No| Q2{データ主権・エアギャップ必須?}
  Q2 -->|Yes| Q3{OSS + 統合プラットフォーム?}
  Q3 -->|Yes| LF1[Langfuse Self-host]
  Q3 -->|No| PX1[Phoenix Self-host\n軽量優先]
  Q2 -->|No| Q4{既存APMに統合?}
  Q4 -->|Yes| DD[Datadog LLM Obs\n/ Logfire / OpenLLMetry]
  Q4 -->|No| Q5{コスト削減+キャッシュ最優先?}
  Q5 -->|Yes| HC[Helicone / Portkey\n/ LiteLLM proxy]
  Q5 -->|No| Q6{評価ワークフロー中心?}
  Q6 -->|Yes| BT[Braintrust / LangSmith]
  Q6 -->|No| Q7{ローカルデバッグ単発?}
  Q7 -->|Yes| PX2[Arize Phoenix\n単一Docker]
  Q7 -->|No| LF2[Langfuse Cloud\nまたは Self-host]

  style S fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style LF1 fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style LF2 fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style LS fill:#f97316,stroke:#ea580c,color:#fff
  style PX1 fill:#f97316,stroke:#ea580c,color:#fff
  style PX2 fill:#f97316,stroke:#ea580c,color:#fff
  style HC fill:#f97316,stroke:#ea580c,color:#fff
  style BT fill:#f97316,stroke:#ea580c,color:#fff
  style DD fill:#f97316,stroke:#ea580c,color:#fff

LLMオブザーバビリティ製品選定フローチャート。Langfuseが選ばれるのは「フレームワーク非依存 + OSS/Self-host可 + 統合プラットフォーム」という組合せが最優先の場合

Langfuseが最も輝く状況

フローの結果として「Langfuse」に落ち着くのは、以下の条件の組合せが優先されるプロジェクトです。

条件	なぜLangfuseが適合するか
フレームワーク非依存	Pydantic AI、Vercel AI SDK、OpenAI SDK直叩きなど幅広く対応。OTel経由で80+統合
データ主権・オンプレ必須	MITライセンス、Cloudと機能同等のSelf-host、完全エアギャップも可能
Prompt + Eval + Dataset + Playgroundの統合	4機能を単一UIで往復でき、別SaaSの組合せより開発動線が短い
多言語バックエンド	OTel経由でJava/Go/.NET/Ruby/PHPから送信可能。公式SDKは Python/JS/TS、それ以外はコミュニティSDK or OTel
JP/EUデータレジデンシー	Cloud リージョン選択可（EU/US/JP）、Self-hostならインフラ完全制御

Langfuseが不向きな状況

逆に、以下の場合は他の選択肢を第一候補にする方が合理的です。

状況	代替案
LangChain/LangGraph完全依存	LangSmithが統合と純正Evalで一歩リード
ワンラインProxyでまず観測したい	Helicone / Portkeyが手軽
単一Dockerで気軽にデバッグ	Arize Phoenixが最短セットアップ
評価ワークフローが最優先	Braintrust / LangSmithのEvalが一歩成熟
キャッシュによるコスト削減必須	Langfuseはネイティブ無し。Helicone/Portkeyが適合
既存APMに一元化したい	Datadog LLM Observability / Pydantic Logfireが運用単純

複数ツール併用という現実解

2026年の実務トレンドとして、「1つに決めきらず、OTelの fan-out 機能で複数バックエンドに同時送信する」運用が増えています。例えば以下のような組合せです。

graph LR
  APP[LLM App] --> OTEL[OpenTelemetry SDK]
  OTEL -->|LLM特化| LF[Langfuse\nTrace / Prompt / Eval]
  OTEL -->|インフラ統合| DD[Datadog\nAPM / Logs / Infra]
  OTEL -->|リクエスト計測| GF[Grafana Tempo\n/ SigNoz]

  style APP fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style OTEL fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style LF fill:#f97316,stroke:#ea580c,color:#fff
  style DD fill:#14b8a6,stroke:#0d9488,color:#fff
  style GF fill:#ec4899,stroke:#be185d,color:#fff

OpenTelemetry fan-outパターン: 1つのSDKから複数バックエンドに同時送信。Langfuseは「LLM特化の観測」として位置付け、インフラ全体のAPMは既存ツールと併存

「Datadogでインフラとサービス全体のAPM、Langfuseで LLM 部分のトレース・評価・プロンプト管理」という役割分担は、既存のDevOps体制を壊さずにLLM観測を追加できる現実解です。Langfuseもこうした併用を公式にサポートしています。

理解度チェック

問題 0 / 50%

Langfuse vs LangSmith の本質的な差別化軸として、最も正確な組合せはどれですか？

キーボード: 1〜4 で選択、Enter で回答