Langfuse・LangSmith・Helicone比較｜料金と選び方を解説

結論：評価運用はLangfuse／LangSmith、Gateway一体運用はHelicone

オープンソースとセルフホスト、モデル非依存の評価・Prompt Managementを重視するならLangfuseが第一候補です。LangChain・LangGraphを中心に開発し、トレースから評価、デプロイまで同じ環境へ寄せたいならLangSmithが合います。AI APIの前段へ素早く置き、ログ、キャッシュ、レート制限、フォールバックもまとめたいならHeliconeを比較します。

これは機能数の勝敗ではありません。SDKやOpenTelemetryでアプリ内部のspanまで観測するのか、Proxy経由でモデル呼び出しを短期間に集めるのかで導入経路が異なります。また、無料枠の『1件』は3社で同じではないため、表示件数だけの比較は避けます。

本番採用では、代表タスク100〜1,000件を同じ粒度で記録し、月額だけでなく調査時間、保存量、評価モデル費、Gateway経由の遅延、運用人件費まで含む総コストで判断します。

この節の一次情報：Langfuse公式料金（2026年10月15日確認） ／ LangSmith公式料金（2026年10月15日確認） ／ Helicone公式料金（2026年10月15日確認）

比較表：料金より先に課金単位と保持期間をそろえる

Langfuse CloudはHobby無料、Core月29ドル、Pro月199ドルです。Core以上は月10万ユニットを含み、超過は10万ユニット当たり8ドルからです。1ユニットはtrace、observation、scoreのいずれか1件なので、1タスクの内部工程と評価数で使用量が増えます。

LangSmithはDeveloperが1席無料で月5,000 base traces、Plusは1席月39ドルで月1万base tracesを含みます。base traceは14日、extended traceは180日保持です。HeliconeはHobby無料で月1万requestと1GB、Pro月79ドル、Team月799ドルで、requestとstorageの従量料金が追加されます。

各社の課金単位は変換できません。1回のユーザー操作に10個の内部spanと3つの評価を付ける場合、task、trace、observation、requestの件数は一致しないからです。見積もりでは実際の計測データを各社の単位へ変換します。

この節の一次情報：Langfuse公式｜Billable Units ／ LangSmith公式｜Plans and Pricing ／ Helicone公式｜Pricing and plan limits

機能差：観測の深さとAPI経路への関与が違う

Langfuseはトレース、session、user、token・costを記録し、dataset、experiment、LLM-as-a-Judge、人手annotation、Prompt Managementを同じデータへ結び付けます。OpenTelemetryやSDKでモデル呼び出し以外の検索、ツール、独自処理もspanとして扱いやすく、RAGや複数ステップのagentを原因分析したい場合に向きます。

LangSmithもtracing、monitoring、online／offline eval、dataset、annotation queueを提供します。LangChainやLangGraphは必須ではありませんが、同じ製品群のDeploymentやStudioまで使うチームでは、実装から評価、公開後の監視を一続きにしやすい点が特徴です。反対に、観測だけを独立したOSS基盤として持ちたい組織は契約と移行性を比較します。

HeliconeはProxyのURLへ置き換える導入を中心に、request、session、user、cost、latencyを集計し、cache、rate limit、automatic fallbackなどGateway機能も提供します。モデルAPI通信を早く可視化したい場合は有力ですが、Proxyを同期経路へ入れるなら、障害時のバイパスとp95・p99遅延を実測します。評価やdatasetも備えるものの、自社が必要とする複雑なagent traceを同じ粒度で表せるかはPoCで確認します。

判断フロー：5つの質問で候補を絞る

最初にデータ経路を決め、次に評価運用、最後に料金を比較します。機密情報を含むpromptとoutputを保存するため、便利な画面より保存場所、保持、削除、権限を先に確定します。

• 1. 自社VPCへデータを閉じる必須要件がある → Langfuse OSS、LangSmith Enterprise、HeliconeのSelf-host／On-premを契約条件込みで比較
• 2. LangChain・LangGraphの開発とagent deploymentを一体化したい → LangSmithを先に検証
• 3. provider SDKのURL変更で素早く観測し、cacheやfallbackも使いたい → Heliconeを先に検証
• 4. OpenTelemetry、モデル非依存、評価・Prompt Management、OSSを重視 → Langfuseを先に検証
• 5. どれも必須ではない → 代表トラフィックを3社の課金単位へ換算し、運用時間を含む月額で比較

向くケース・向かないケース

Langfuseは、複数モデルや独自frameworkをまたぎ、評価データとpromptをベンダー中立に管理したいチームに向きます。既存SREがなく、PostgreSQLやClickHouseまで運用できない小規模チームが『OSSだから無料』だけでセルフホストを選ぶのは向きません。

LangSmithは、LangChain・LangGraphを中心にagentを開発し、traceからdataset化、回帰評価、deploymentへ進めたいチームに向きます。人数が増えるほど席課金が効き、Self-hostやHybridはEnterprise条件なので、framework非依存と調達柔軟性を最優先する組織は出口コストを確認します。

Heliconeは、複数providerのAPI通信、費用、latencyを短期間で集め、Gatewayのcache、rate limit、fallbackも同時に使いたいチームに向きます。アプリ内部の検索やツール処理まで細かく追いたい場合や、Proxyを本番経路へ加えられない場合は、非同期連携を含めて観測範囲を確認します。

契約・セキュリティで確認すること

料金ページにSOC 2、HIPAA、SSO、SLAが並んでいても、すべてのプランで同じ条件ではありません。LangfuseのEnterprise SSOや細かなRBACはadd-onまたはEnterprise要件があり、LangSmithのHybrid／Self-hostもEnterpriseです。HeliconeのSAML SSOとOn-premはEnterprise欄に掲載されています。

保存する本文を最小化し、client-side maskingだけに依存しない設計にします。DPA、subprocessor、データ地域、暗号化、削除API、backupからの消去、退会後のexport、インシデント通知、SLAクレジットを確認します。評価用モデルへtrace本文を再送する場合は、そのモデル事業者もデータ経路に加わります。

企業各社が掲げる『高速』『低コスト』『簡単』は自社環境での保証ではありません。この記事の料金・保持・プラン上限は公開資料で確認できる事実ですが、実効遅延、欠落率、調査時間、評価精度は独立したPoCで検証する必要があります。

• prompt・output・tool結果のうち保存しない項目を定義する
• 開発・本番・顧客tenantの権限境界をテストする
• 保存期間、export、削除、解約後の返却方法を契約へ入れる
• 評価モデル、分析連携、subprocessorまでデータフロー図へ含める
• 月次で課金単位、取り込み上限、保持期間、契約条件を再確認する

FAQ

Q. 一番安いLLM Observabilityはどれですか？　A. 単純には決められません。Langfuseは観測レコード、LangSmithはtraceと席、Heliconeはrequestとstorageが中心です。同じ本番ログを各社の単位へ変換し、運用人件費と評価モデル費を加えて比較します。

Q. LLM Observabilityを入れると推論が遅くなりますか？　A. 同期Proxy、SDK送信、batch送信で影響が異なります。とくにProxyを通す構成はp95・p99と障害時の挙動を実測し、観測先停止時に本体処理を継続できるか確認します。

Q. セルフホストなら無料ですか？　A. OSSのライセンス料が無料でも、DB、保存、backup、監視、upgrade、on-callの費用は残ります。Enterprise機能やサポートは別契約の場合があります。

Q. 既存のAPMで代用できますか？　A. latencyやerrorは追えますが、prompt、token、cost、model、dataset、evaluation scoreを業務単位で扱うには追加実装が必要です。OpenTelemetryで既存APMとLLM専用基盤を併用する方法もあります。

Q. 最初から全リクエストを保存すべきですか？　A. いいえ。機密度、障害影響、分析価値でsamplingと本文保存を分けます。高リスク処理は詳細、定型処理は統計中心とし、保存しない場合でもrequest IDと請求照合用の最小メタデータは残します。