Langfuse(ラングフューズ)は、LLMアプリのトレース、プロンプト管理、評価をまとめて扱うオープンソースの基盤です。2026年1月にClickHouseが買収し、7月にはサーバーがv4へ上がりました。10月にはPython SDK v5とJS/TS SDK v6が出ています。v3時代の記事に載っている手順は、そのままでは動かない箇所があります。この記事では2026年10月18日時点の現行版(サーバーv4.63.0)を手元のDocker Composeで立て、Python・JavaScript・OTLP直送でトレースを送って確かめた結果をもとに、使い方・料金・LangSmithとの違いを整理します。
まとめ:Langfuseの要点と現行バージョン
- 読み方は「ラングフューズ」です。「ラングヒューズ」と書かれることもありますが、同じ製品を指します。
- 現行版はサーバーv4.63.0、Python SDK v5.0.2、JS/TS SDK v6.0.0です(2026年10月18日時点)。新しいSDKはセルフホストのv4.59.0以上を前提にしていて、v3サーバーでは使えません。
- 2026年1月16日にClickHouseが買収しました。主要機能のMITライセンスとセルフホストは続くと公式に表明されています。
- 料金はCloudのHobbyが無料(月5万units)、Coreが月29ドル(月10万units、超過分は10万unitsあたり8ドル)です。unitsはtrace・observation・scoreの件数の合計で数えます。
- LangSmithとの違いは、セルフホストの扱いとデータの置き場所に出ます。Langfuseは無料でセルフホストでき、日本リージョン(jp.cloud.langfuse.com)もあります。LangSmithのセルフホストはEnterprise契約が前提で、Cloudのデータ所在地はUSかEUです。
Langfuseとは:読み方・開発元・ClickHouseによる買収
読み方は「ラングフューズ」、LLMアプリの中身を記録するOSS
Langfuseはラングフューズと読みます。LLMアプリは同じ入力でも出力が揺れるうえ、RAGの検索やエージェントのツール呼び出しが何段にも連なります。そのため、品質が落ちたときにどの段が原因かをログの断片から追うのは困難です。Langfuseは1リクエストの処理全体を1本のトレースとして記録し、各段の入力・出力・トークン数・レイテンシ・コストを並べて見られるようにします。開発元はY CombinatorのWinter 2023バッチ出身のチームで、公式サイトでは5万社以上が利用していると公表しています。
ClickHouseによる買収(2026年1月16日)とライセンスの扱い
2026年1月16日、ClickHouseはLangfuseを買収したと発表しました。発表文には、主要機能は既存のMITライセンスのまま100%オープンソースで続け、Langfuse Cloudも独立したサービスとして運営を続けると書かれています。Langfuseはもともと観測データの保存先にClickHouseを使っていたため、利用者側の構成は買収の前後で変わっていません。
ただしリポジトリ全体がMITというわけではありません。LICENSEファイルでは ee/・web/src/ee/・worker/src/ee/ 配下に別のEnterpriseライセンスが適用されています。セルフホストでプロジェクト単位のRBAC、監査ログ、保持ポリシー、SCIMを使うには、ライセンスキーが必要です。
v4で変わったデータモデル:observations-first
2026年7月29日に出たv4.0.0は、データモデルを「observations-first」に作り替えたメジャー版です。ClickHouseの traces と observations の2テーブルを読む構成をやめ、LLM呼び出しやツール実行の1回を1行として持つ events_full と、その軽量版の events_core から読むようになりました。読み取り時の結合と重複排除が要らなくなり、全文検索、モニターとアラート、高速になったObservations API v2が使えます。コンテナ構成(Web・Worker・PostgreSQL・ClickHouse・Redis・S3)はv3と同じです。
Langfuseでできること:トレース・プロンプト管理・評価
エージェントのトレース:各処理の観測型と親子関係
トレースの単位はobservationです。Python SDK v5の start_as_current_observation() が受け付ける型は、span・generation・embedding・agent・tool・chain・retriever・evaluator・guardrail の9種類です。エージェントの可観測性を確保したいなら、LLM呼び出しは generation、検索は retriever、外部API呼び出しは tool と型を分けて記録します。UIのツリー表示で、どの段で時間とトークンを使ったかを切り分けられます。user_idやsession_idを付ければ、チャットのスレッド単位やユーザー単位でも集計できます。スパン木の切り方そのものはエージェントトレーシングとは?スパン木の設計・gen_ai属性・記録範囲を実装目線で解説【2026年版】で詳しく扱っています。
プロンプト管理:本番ラベルとSDKキャッシュ
プロンプトはLangfuse側で版を管理し、アプリからは名前で取得します。手元のv4.63.0で確かめたところ、版1に production ラベルを付けたあと、ラベルなしで版2を作っても、get_prompt("faq-answer") は版1を返しました。既定の取得は production ラベルの版で、版2は label="latest" または version=2 を指定すると取得できます。版を足しただけでは本番の挙動が変わらない設計なので、切り替えはラベルの付け替えで行います。
取得結果はSDKがキャッシュし、既定のTTLは60秒です。期限が切れるとバックグラウンドで取り直します。同じマシン上のDocker Composeに向けた1回の計測では、キャッシュからの取得が0.02ミリ秒、キャッシュを消したあとの取得が22.92ミリ秒でした。Cloudを使う場合は、ここにネットワークの往復時間が加わります。
評価:LLM-as-a-judge・データセット・Experiments
評価機能には、LLM-as-a-judge、コードで書く評価、ユーザーフィードバック、人手のアノテーションキューがあります。現行のドキュメントでは、本番データのLLM-as-a-judgeはobservation単位で評価する方式が推奨で、trace単位の評価器は非推奨です。v3から上げる場合、旧来のtrace単位の評価器はv4のデフォルト書き込みモードへ切り替えた時点で動かなくなります。データセットに入力と期待出力を登録しておけば、Experimentsでプロンプトやモデルを替えた版を同じデータで比べられます。指標とデータセットの設計はLLM評価とは?指標・データセット設計・評価ツールの選び方を実装視点で解説【2026年版】にまとめています。
Langfuseの使い方:Python SDK v5によるトレース送信
Python SDK v5のインストール要件と接続先設定
Python SDK v5はPython 3.11以上と、CloudまたはセルフホストのLangfuse v4.59.0以上が必須です。Python 3.10の環境で pip install langfuse を実行すると、v5ではなくv4系の最新が入ります。v3サーバーをセルフホストしている場合は、サーバーをv4へ上げるまでSDK v4に留めてください。キーはLangfuseのプロジェクト設定で発行します。
pip install "langfuse>=5"
# 接続情報(日本リージョンの例。EUは https://cloud.langfuse.com)
export LANGFUSE_PUBLIC_KEY="pk-lf-..."
export LANGFUSE_SECRET_KEY="sk-lf-..."
export LANGFUSE_BASE_URL="https://jp.cloud.langfuse.com"
Pythonの計装:@observeとstart_as_current_observation
関数に @observe() を付けると、その関数が1つのobservationとして記録され、入れ子の呼び出しは親子関係を保ったままツリーになります。LLM呼び出しは start_as_current_observation(as_type="generation") で囲み、モデル名とトークン数を渡します。次のコードは、手元のv4.63.0とSDK 5.0.2でこのまま実行したものです。
from langfuse import observe, get_client, propagate_attributes
lf = get_client()
@observe(as_type="retriever")
def retrieve(q):
return ["doc-1", "doc-2"]
@observe()
def answer(q):
docs = retrieve(q)
with lf.start_as_current_observation(
as_type="generation", name="llm-call", model="claude-sonnet-4-6",
input=[{"role": "user", "content": q}],
) as gen:
# ここで実際のLLM APIを呼び、応答とトークン数を渡す
gen.update(output="課金単位はtraces・observations・scoresの合計です",
usage_details={"input": 1200, "output": 80})
return "ok"
with propagate_attributes(user_id="user-001", session_id="sess-42", tags=["poc"]):
answer("Langfuseの課金単位は?")
lf.flush() # 短命なスクリプトやバッチでは終了前に呼ぶ
OpenAI SDKを使っているなら、from langfuse.openai import openai に差し替えるだけで呼び出しが自動で記録されます。複数のLLMをゲートウェイで束ねている場合は、LiteLLMのProxy側からLangfuseへログを送る構成も取れます。v5では openai>=1.0 が必要です。LangChainの CallbackHandler を使う場合は langchain-core>=1 が要ります。
Observations API v2による送信結果の確認
UIを開かなくても、Observations API v2で記録内容を確かめられます。
r = lf.api.observations.get_many(fields="core,basic,model,usage", limit=50)
for o in r.data:
print(o.name, o.type, o.usage_details)
# 実行結果(数秒後に反映)
# llm-call GENERATION {'input': 1200, 'output': 80, 'total': 1280}
# answer SPAN {}
# retrieve RETRIEVER {}
flush直後に読み戻したときは、新しいトレースがまだ一覧に出ませんでした。WebコンテナはSDKから受けたイベントをいったんS3(手元ではMinIO)に書き、WorkerがClickHouseへ取り込む非同期構成のためです。登録直後の値を読む自動テストを書くなら、数秒の待機か再試行を入れてください。llm-call のコストは0.0048ドルで、claude-sonnet-4-6の組み込み単価(入力100万トークンあたり3ドル、出力15ドル)から計算した 1,200×3e-6+80×1.5e-5 と一致しました。
JavaScript/TypeScriptとJavaからの送信
Node.js:JS/TS SDK v6はNode.js 22以上
JS/TS SDK v6はNode.js 22以上とLangfuse v4.59.0以上が必須で、@langfuse/* の各パッケージは同じメジャー版に揃える決まりです。OpenTelemetryのNodeSDKに LangfuseSpanProcessor を登録して計装します。次のコードをNode.js v26.5.0、@langfuse/tracing 6.0.0で実行すると、js-llm がGENERATIONとして記録され、コストは0.0018ドルでした。
npm install @langfuse/tracing@6 @langfuse/otel@6 @opentelemetry/sdk-node
// index.mjs(接続情報は Python と同じ環境変数で渡す)
import { NodeSDK } from "@opentelemetry/sdk-node";
import { LangfuseSpanProcessor } from "@langfuse/otel";
import { startActiveObservation } from "@langfuse/tracing";
const processor = new LangfuseSpanProcessor();
const sdk = new NodeSDK({ spanProcessors: [processor] });
sdk.start();
await startActiveObservation("js-answer", async (span) => {
span.update({ input: { q: "Langfuseの読み方は?" } });
await startActiveObservation("js-llm", async (gen) => {
gen.update({ model: "claude-sonnet-4-6", output: "ラングフューズです",
usageDetails: { input: 500, output: 20 } });
}, { asType: "generation" });
span.update({ output: "done" });
});
await processor.forceFlush();
await sdk.shutdown();
Java・GoなどからのOTLP/HTTPによる直接送信
トレース用の公式SDKはPythonとJS/TSで、料金ページでもJavaとGoはOpenTelemetry経由と案内されています。Java・Go・.NETからは、OpenTelemetryのOTLPで /api/public/otel に送ります。認証は公開キーと秘密キーを : でつないでBase64にしたBasic認証です。公式ドキュメントはv4向けに x-langfuse-ingestion-version=4 ヘッダーを付ける設定を示しています。受け付けるのはOTLP/HTTP(JSONとprotobuf)だけで、gRPCには対応していません。エクスポーターの既定がgRPCの言語では、プロトコルの指定が必要です。
export OTEL_EXPORTER_OTLP_ENDPOINT="https://jp.cloud.langfuse.com/api/public/otel"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Basic ${AUTH_STRING},x-langfuse-ingestion-version=4"
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf" # gRPCは非対応
# AUTH_STRING は echo -n "pk-lf-...:sk-lf-..." | base64 の結果
手元で、gen_ai.request.model=gpt-5.4-mini・gen_ai.usage.input_tokens=2000・gen_ai.usage.output_tokens=300 を持つスパン1本をcurlでJSON送信したところ、HTTP 200が返り、GENERATIONとして取り込まれて0.00285ドルのコストが付きました。誤った鍵ではHTTP 401(Invalid credentials)になります。SDKを使わない言語では、OpenTelemetryのGenAIセマンティック規約どおりに gen_ai.* 属性でモデル名とトークン数を渡せます。langfuse.observation.type などで型を明示していなければ、この例のようにモデル名の属性からGENERATIONと推定され、組み込みのモデル定義に価格tierがあればコストも付きます。属性の体系はOpenTelemetryのGenAIセマンティック規約|gen_ai属性とメトリクスの体系・移行の判断、Collectorを挟んで既存の監視基盤と分岐させる構成はLangfuse OpenTelemetry連携の実装|OTLP送信の設定と既存パイプラインの分岐で解説しています。
コストが空のままになる原因:モデル定義と価格tier
Langfuseは、generationのモデル名を組み込みのモデル定義(v4.63.0で187件)と照合し、トークン数に単価を掛けてコストを出します。モデル名が一致していればコストが付くと思われがちですが、手元の検証ではそうなりませんでした。入力100万・出力10万トークンを3つのモデル名で送った結果が次の表です。
| 送ったモデル名 | モデル定義との照合 | 価格tier | 計算されたコスト |
|---|---|---|---|
| claude-sonnet-4-6 | 一致 | 1件 | 4.5ドル(入力3.0+出力1.5) |
| gpt-4o-mini | 一致 | 0件 | 空(計算されない) |
| my-inhouse-model | 不一致 | なし | 空(計算されない) |
gpt-4o-miniの組み込み定義には入力単価(1.5e-7ドル/トークン)が入っているのに、価格tierが0件のためコストが付きません。同じ状態の定義はgpt-4o-mini-2024-07-18とgpt-4o-2024-08-06にもありました。独自モデルやローカルLLMの場合は、定義がないので何も計算されません。いずれも、UIのモデル設定で単価付きの定義を自分で追加すれば解決します。古いモデルをまだ使っているなら、ダッシュボードのコストを信じる前に、generationを1件開いてコスト欄が埋まっているかを確認してください。月次の費用を集計する用途では、この確認を抜くと実際より少なく見積もることになります。
セルフホスト:Docker Composeで立てる手順と必要なリソース
6コンテナの構成と起動にかかった時間・メモリ
公式リポジトリの docker-compose.yml を取得して docker compose up -d を実行すると、langfuse-web・langfuse-worker・PostgreSQL 17・ClickHouse 25.12・Redis 7・MinIOの6コンテナが起動します。4CPU/6GiBのDocker VM(Intel Mac上のcolima)では、イメージの取得を含めて初回の起動に約4分かかりました。トレースを数十件送ったあとのメモリ使用量は次のとおりです。
| コンテナ | 役割 | メモリ |
|---|---|---|
| langfuse-web | UI・API・OTLP受信 | 1.3GiB |
| clickhouse | トレース・スコアの保存 | 1.0GiB |
| langfuse-worker | 取り込み・評価などの非同期処理 | 710MiB |
| postgres | ユーザー・プロジェクト・プロンプト | 101MiB |
| minio | 受信イベント・添付ファイル | 66MiB |
| redis | キュー・キャッシュ | 10MiB |
アイドルに近い状態でも合計で約3.2GiBを使います。公式ガイドがDocker Compose用のVMに4コア・16GiBを推奨しているのは、ClickHouseが負荷に応じてメモリを使うためです。Docker Composeは公式の位置付けでもローカル検証用で、本番はKubernetes(Helm)やクラウドの構成が案内されています。
起動前に変える設定とポートの衝突
composeファイルの # CHANGEME が付いた箇所(SALT・ENCRYPTION_KEY・NEXTAUTH_SECRET・各パスワード)は、検証用の固定値のまま公開してはいけません。ENCRYPTION_KEY は openssl rand -hex 32 で作ります。Web(3000番)とMinIO(9090番)以外は 127.0.0.1 だけで待ち受ける設定です。手元ではホストの3000番を別の開発サーバーが使っていたため、http://localhost:3000 にアクセスすると、Langfuseではなくその開発サーバーの500エラーが返ってきました。ヘルスチェックが通らないときは、まず lsof -i :3000 で待ち受けているプロセスを確認してください。override ファイルで ports: !override と書き、Webのポートを 13000:3000 に置き換えます。NEXTAUTH_URL も合わせて変えれば解消します。!override を付けずに書くと、Docker Composeは元の 3000:3000 と新しい割り当てを両方残すため、衝突は解消しません。LANGFUSE_INIT_* 環境変数を使えば、組織・プロジェクト・APIキーを起動時に作れるので、検証環境を毎回同じ状態で立て直せます。
v3からv4への移行とSDKの対応関係
v3をセルフホストしている場合、v3へのセキュリティパッチは2027年1月31日までです。v4への移行では、先にClickHouseを25.12以上(推奨26.4)、PostgreSQLを15以上、Redisを7.0以上に上げます。次に、サーバーを最新のv3へ上げ、バックグラウンド移行がすべて完了したことを確認します。background_migrations テーブルで finished_at IS NULL の行が0件になっていれば完了です。ClickHouseの接続ユーザーには、v4が要求する追加権限も付けておきます。そのうえでv4へ更新します。v4のスキーマ移行は追加だけでなく古いテーブルの削除も含むため、未完了の移行が残っているとデータを失います。v3へ自動で戻す手段もありません。更新の直前にPostgreSQLとClickHouseの両方をバックアップしてください。過去データを新テーブルへ自動で書き直す場合は、ClickHouseのディスクに現データ量の約3倍の空きが要ります。
| SDK | セルフホストv3 | セルフホストv4 |
|---|---|---|
| Python SDK v5/JS SDK v6 | 非対応 | v4.59.0以上 |
| Python SDK v4/JS SDK v5 | v3.63.0以上 | 対応 |
| Python SDK v3/JS SDK v4 | v3.63.0以上 | 非推奨 |
| Python SDK v2以前/JS SDK v3以前 | 対応 | 非対応 |
サーバーとSDKは別々に版番号が進みます。「Langfuse v4」と書かれていても、サーバーの話かSDKの話かで意味が変わります。自分のサーバーの版は /api/public/health の version で確認できます。セルフホストのClickHouse・Redisの面倒を自社で見続けるのが重い場合は、保守運用・内製化支援のような運用の分担も選択肢になります。
Langfuse Cloudの料金:プランと課金単位units
Langfuse Cloudの料金は、月額の基本料金に、含まれる量を超えたunitsの従量課金を足す方式です。2026年10月18日時点のプランは次のとおりです。
| プラン | 月額 | 含まれるunits | 過去データの閲覧 | ユーザー |
|---|---|---|---|---|
| Hobby | 無料 | 5万 | 30日 | 2人 |
| Core | 29ドル | 10万 | 90日 | 無制限 |
| Pro | 199ドル | 10万 | 3年 | 無制限 |
| Enterprise | 2,499ドル | 10万 | 3年 | 無制限 |
超過分の単価は量に応じて下がります。10万〜100万unitsは10万unitsあたり8ドル、100万〜1,000万は7ドル、1,000万〜5,000万は6.5ドル、5,000万超は6ドルです。Proの月300ドルのTeamsアドオンを付けると、Enterprise SSOやプロジェクト単位のRBACが使えます。
見積もりで間違えやすいのはunitsの数え方です。unitsはtraceの件数・observationの件数・scoreの件数の合計で、リクエスト件数ではありません。上の計装例では1リクエストでtrace 1件とobservation 3件(answer・retrieve・llm-call)が記録されるので、4 unitsになります。この形のリクエストが月10万回あれば40万unitsで、Coreなら29ドル+30万units分の24ドル=53ドルです。LLM-as-a-judgeやExperimentsでLangfuse自身が作ったobservationやscoreも課金対象に入ります。なお、30日・90日・3年は閲覧できる期間で、期限を過ぎたデータを自動で消す保持期限ではありません。セルフホストのOSS版には従量課金がありません。
データの保存先は、EU(cloud.langfuse.com)、US(us.cloud.langfuse.com)、日本(jp.cloud.langfuse.com)、HIPAA(hipaa.cloud.langfuse.com)から選びます。日本リージョンはHobbyから選べるので、個人情報を含むプロンプトを国内に置きたい場合でも、まず無料枠で試せます。
LangfuseとLangSmithの違い:セルフホスト・データの所在地・課金
LangSmithはLangChain社の商用サービスで、LangChain・LangGraphを使ったアプリのトレースや評価、デプロイを扱います。違いが大きいのはセルフホスト、データの所在地、課金の単位の3点です。
| 比較項目 | Langfuse | LangSmith |
|---|---|---|
| ライセンス | OSS(主要機能はMIT) | 商用 |
| セルフホスト | 無料(一部機能はライセンスキー) | Enterprise向け |
| Cloudのデータ所在地 | EU・US・日本(HIPAA環境はUS) | US・EU |
| 無料枠 | 月5万units・2人 | 月5,000 base traces・1シート |
| 有料の入口 | Core 月29ドル(ユーザー無制限) | Plus 1シート月39ドル |
| データの保持 | 閲覧30日〜3年(プラン別) | base 14日・extended 180日 |
LangSmithの料金はシート課金で、Plusは1シート月39ドル、月1万base tracesまでが含まれます。base traceの保持は14日で、180日残すには追加料金でextended traceへ上げます。開発者が10人いれば、Plusはシート代だけで月390ドルです。Langfuse Coreはユーザー数に関係なく月29ドルからなので、人数が多いチームほど差が開きます。
選び方の目安は次のとおりです。LangGraphでエージェントを組んでいて、デプロイ基盤までLangChain社のサービスに揃えるならLangSmithを選びます。フレームワークが混在している、データを自社環境か日本リージョンに置く必要がある、人数課金を避けたい、のいずれかに当てはまるならLangfuseです。LangSmith側のトレース送信と料金はLangSmithとは?トレース送信の設定・評価の実行・料金とリージョンの選び方【2026年版】で詳しく比べています。ClickHouseやRedisを抱えずにセルフホストしたい場合の代替としては、Arize Phoenixの起動手順とLangfuseとの違いも整理しました。
導入判断:Langfuseを選ぶ条件と避けるべき場面
Langfuseが向いているのは、次のいずれかに当てはまる場合です。
- プロンプトや応答に機微な情報が含まれ、自社環境か日本リージョンに置く必要がある
- LangChain以外のフレームワークやOpenAI SDKの直接呼び出しが混在している
- 開発者や企画担当など、トレースを見る人が多い
LLMOps全体のなかでの位置付けはLLMOpsとは?MLOpsとの違いとトレース・評価・コスト管理の実装を解説【2026年版】を参照してください。
一方で、次の場面では導入を見送るか、設定を変えてから使ってください。
- セルフホストのClickHouseを運用できる人がいない:v4ではClickHouseの版上げと権限追加が移行の前提で、手順を誤るとv3へ戻せません。運用者を置けないならCloudを使ってください。
- サーバーレスで1回の実行時間を秒単位で削っている:Langfuseのサーバーを止めた状態で試すと、計装した関数自体は1.6ミリ秒で正常に返り、アプリは止まりませんでした。ただし
flush()は送信の再試行で3.23秒ブロックしました。終了前にflushが必須の関数では、送信先の障害がそのまま実行時間に乗ります。 - プロンプトを毎回Langfuseから取得している:サーバー停止中の
get_prompt()は、fallbackを渡していれば1.65秒後に代替のプロンプトを返しました。公式ドキュメントによれば、fallbackを渡さず、ローカルのキャッシュ(期限切れを含む)も無い状態で取得に失敗すると、再試行のあとに例外になります。キャッシュが無いのは、起動直後のインスタンスが初めて取得するときです。本番の呼び出しにはfallbackを渡すか、起動時にプロンプトを取得しておき、取れなければ起動を止めてください。
よくある質問
Langfuseの読み方は?「ラングヒューズ」は別製品ですか?
読み方は「ラングフューズ」です。「ラングヒューズ」や「lang fuse」は表記ゆれで、いずれも同じLLM向けのオープンソース基盤Langfuseを指します。
Langfuseは無料で使えますか?
使えます。CloudのHobbyプランは無料で、月5万units、2ユーザー、30日分のデータ閲覧までが含まれ、クレジットカードは不要です。主要機能はMITライセンスのため、Docker ComposeやKubernetesでのセルフホストも無料です。ただしプロジェクト単位のRBACや監査ログなど一部の機能は、セルフホストでもライセンスキーが必要です。
Langfuseに日本リージョンはありますか?
あります。接続先は https://jp.cloud.langfuse.com で、Hobbyプランから選べます。SDKでは環境変数 LANGFUSE_BASE_URL に、OTLPで直接送る場合は /api/public/otel を付けたURLを指定します。
JavaからLangfuseにトレースを送れますか?
送れます。トレース用の公式SDKはPythonとJS/TSだけなので、JavaではOpenTelemetryのOTLPエクスポーターの送信先をLangfuseの /api/public/otel にし、Basic認証のヘッダーを付ければ取り込まれます。LLM呼び出しとして集計させるには、スパンに gen_ai.request.model やトークン数の gen_ai.usage.* 属性を付けます。
ClickHouseに買収されたあともオープンソースで使えますか?
使えます。2026年1月16日の買収発表で、主要機能は既存のMITライセンスのままオープンソースで続け、セルフホストもLangfuse Cloudも継続すると表明されています。買収後の2026年7月にはv4.0.0がMITのまま公開され、10月時点でもリリースが続いています。