Langfuse vs Helicone — LLM観測の2つのアプローチ

結論

• 既存コードをほとんど触らず今日から記録したい → Helicone
• エージェントの多段処理を追いたい → Langfuse
• 観測データを自社に留めたい → どちらも OSS だが Langfuse のほうが情報が揃っている

無料枠は Langfuse のほうが大きい。ただし数え方が違い、Langfuse は1トレース・1観測・1スコアをそれぞれ1ユニット、Helicone は1リクエストを1と数える。エージェントのように1回の処理で多くの観測が出る構成では、Langfuse の5万ユニットは Helicone の1万リクエストほど余裕がない。

2. 設置の仕方

Helicone はベースURLを差し替えるだけで始まる。既存のコードに手を入れず、その日のうちに記録が溜まりはじめる。導入の摩擦がほぼない。

Langfuse は SDK を入れて、どの処理をトレースにまとめるかを決める。手間はかかるが、「検索→判断→ツール呼び出し→生成」という流れを1つのトレースとして見られる。エージェントの原因追跡はこれがないと成立しない。

3. 見えるものの違い

ゲートウェイ型が見るのはモデルへのリクエストとレスポンスである。アプリ内部で何が起きたかは見えない。RAG の検索で何が引かれたかは、別途ログに残さない限り記録されない。

この差は、誤答の原因を切り分けるときに決定的になる。モデルの問題か検索の問題かを判別できないと、プロンプトを触って様子を見るしかなくなる。

4. ゲートウェイであることの副産物

Helicone はゲートウェイなので、観測以外の機能が付いてくる。同じ問い合わせのキャッシュ、プロバイダ障害時のフォールバック、レート制限である。これは観測ツールというより運用基盤の性格で、同じ質問が繰り返されるアプリではキャッシュだけで費用が下がる。

Langfuse にはこれがない。必要なら Portkey のようなゲートウェイと併用する構成になる。

5. 保持期間

Langfuse の Hobby は30日、Core で90日、Pro 以上で3年。Helicone は Hobby で1GB という容量の制限になっている。

30日は短い。四半期ごとに傾向を振り返る運用なら、Core 以上が前提になる。トレースは障害調査だけでなく、評価セットの材料にもなるので、捨てると後で困る。

6. 併用する構成

排他ではない。Helicone をゲートウェイとして置いてコストとキャッシュを管理し、Langfuse でアプリ内部のトレースを取る構成は成立する。ただし2つ運用する手間に見合うかは規模次第で、小さいうちは片方で足りる。

よくある質問

Q. どちらが安いですか。

A. アプリの形で変わります。単純なチャットなら Helicone の1万リクエストのほうが実質的に大きく、多段のエージェントなら Langfuse のユニットが早く尽きます。自分の1処理あたりの消費を測ってから比べてください。

Q. 両方 OSS なら自前運用でよいのでは。

A. ライセンス費用はかかりませんが、トレースは量が多くストレージとデータベースの運用が発生します。観測のために別の運用対象を増やすことになるので、データを外に出せる組織ならマネージドのほうが安く済みます。