Langfuse・LangSmithの使い方｜LLMトレース管理と選び方

LLMアプリのトレース管理とは｜通常のAPM監視との違い

結論として、LLMアプリの可観測性は従来のAPM監視の延長では成立しません。理由は、障害が「エラーとして現れない」からです。

通常のWebアプリケーションなら、500エラーやレイテンシ悪化という形で異常が観測できます。LLMアプリは違います。HTTPステータスは200、レスポンスタイムも正常、それでも返している内容が間違っているという状態が起こる。この種の劣化を捕まえるには、ステータスコードではなく入出力そのものを記録する必要があります。

もうひとつの差分がコストです。リクエスト1件ごとに従量課金が発生するため、トークン消費量は監視対象の指標になります。プロンプトを少し長くしただけで請求が跳ねる、という事故は実際に起きます。

トレース・スパン・オブザベーションの関係

LLMアプリの実行記録は、入れ子構造で保存されます。

この階層があると、「回答が遅い」という報告に対して、遅いのは検索なのかLLM推論なのかツール呼び出しなのかを切り分けられます。ログを単なるテキストとして吐くだけの実装では、この切り分けができません。

RAG構成でどの工程が精度のボトルネックになっているかを数値で特定する手法は、RAGの評価方法｜Ragasの評価指標とボトルネック特定・精度改善で扱っています。本記事は「記録の取り方」側に絞ります。

ミニFAQ：既存のDatadogやNew Relicではダメなのか

使えます。ただし、プロンプトと出力をスパン属性として入れる設計を自前で組む必要があり、プロンプトのバージョン管理や評価スコアの紐付けは別の仕組みが要ります。汎用APMの守備範囲はDatadogとは｜統合監視SaaSの特徴・Sentryとの違い・案件単価を徹底解説を参照してください。既存の監視基盤がすでにあるなら、LLM部分だけLangfuse・LangSmithに寄せて、OTLPで両方へ送る構成も取れます。

LangfuseとLangSmithの違い｜4軸の比較表

先に判断軸を並べます。2026年10月時点で各社の公式ドキュメント・料金ページから確認した内容です。

課金単位が違うので、数字をそのまま比べない

ここは誤読が多い箇所です。

Langfuseの「unit」は、送信したトレーシングデータポイント1つを指します。つまりtrace・observation（span / event / generation）・score（評価結果）が、それぞれ1 unitとしてカウントされる。RAGアプリのように1リクエストで検索・再ランキング・LLM呼び出しと複数の処理が走る構成では、1トレースが10 unit以上を消費することもあります。

一方LangSmithの「base traces」は、トレース単位の数え方です。

したがって「50,000 vs 5,000だから10倍お得」という比較は成立しません。自分のアプリで1リクエストあたり何個のスパンが発生するかを数えてから試算してください。超過分はLangfuseの場合、100k〜1M unitの帯で$8.00/100k unitという従量課金になります（詳細はLangfuseの料金ページ）。

ClickHouseによる買収とOSS継続

Langfuseは2026年1月に、ClickHouse社による買収が発表されました。Langfuse公式のGitHub Discussionで、MITライセンスの維持とセルフホスト提供の継続が明言されています。リポジトリの著作権表記もClickHouse, Inc.名義に変わっています。

OSSツールを本番採用するとき、買収は必ず確認すべき論点です。ライセンス変更やセルフホスト版の機能縮小は、過去に他のプロダクトで何度も起きてきました。現時点では継続方針が公式に示されている、というのが確認できる事実です。長期採用を前提にするなら、今後のライセンスと提供形態の更新も継続して確認しておきたいところです。

Langfuseの使い方｜導入からトレース計装まで

最短手順は3ステップです。

1. Cloudかセルフホストかを、データの取り扱い要件から決める

2. 計装方式を決める（コンテキストマネージャ / observeデコレータ / OTLP経由）

3. 1リクエストだけ流し、トレース・トークン数・レイテンシが画面に出ることを確認する

まずCloudかセルフホストかを決める

判断基準は単純です。顧客データや個人情報がプロンプトに含まれ、外部SaaSへの送信が契約上制限されるならセルフホスト。それ以外ならCloudの無料枠から始めるのが早い。

セルフホストは無料で、公式のセルフホスティングドキュメントではローカル検証向けにDocker Compose、本番向けにKubernetes（Helm）が案内されています。ただし運用負荷はゼロではありません。PostgreSQLとClickHouseを含む構成になるため、バックアップ・アップグレード・ストレージ増加への対応を自分たちで抱えることになります。PoC段階ではCloudから始めるほうが早いケースが多いでしょう。ただし閉域網での運用が前提の案件や、契約上データを外部に出せない案件は例外で、最初からセルフホストを選ぶ合理性があります。

Enterprise Licenseのキーが必要になるのは、Organization Creators、Instance Management API、UIカスタマイズといった管理機能に限られます。トレーシング・プロンプト管理・評価といった中核機能はセルフホストで使えます。

計装の3方式

公式SDKドキュメントで案内されている計装方法は3つです。

1. コンテキストマネージャ：クイックスタートの既定。処理ブロックを囲んでスパンを作る

2. observeデコレータ：関数に付けるだけで、その関数呼び出しが1スパンになる。既存コードへの差し込みが最も軽い

3. 手動オブザベーション：階層や属性を細かく制御したい場合

JavaScript / TypeScript環境では、OpenAIラッパーとLangChainコールバックが langfuse/openai、langfuse/langchain という別パッケージに分離されています。「一体で入っているはず」と思って探すと見つかりません。

日本語記事のコードが動かない理由

Langfuse Python SDKは現在v5系で、内部がOpenTelemetryベースに作り替えられています。 日本語で公開されている解説記事の多くはv2系の時点で書かれており、APIの呼び出し方が変わっているため、コピーしても動かないことがあります。

技術記事を参照するときは、公開日とSDKバージョンの記載を先に確認する。記載がなければ公式ドキュメントを正とする。ここは手間を惜しまないほうが結果的に速い。なおPython SDK v5系は3.11以上を要求します。

ミニFAQ：OTLPで送れるなら自前のOTel基盤に統合できるか

できます。Langfuseは api/public/otel のエンドポイントでOTLPを受け取ります。ただしOTLP over HTTPのみ対応で、gRPCは未対応です（公式のOpenTelemetry統合ドキュメント）。既存のCollector構成がgRPC前提なら、エクスポータ設定の変更が要ります。OpenLIT、OpenLLMetry、MLflowなどの計装ライブラリからの送信も受け付けます。

LangSmithの使い方｜LangChain非依存での計装

最短導入は、環境変数を設定し、traceableデコレータまたはwrap_openaiラッパーで計装して、LangSmithのプロジェクト画面でトレースを確認する流れです。以下は、その過程でつまずきやすい点を順に挙げます。

ドキュメントの場所が変わっている

実務上の落とし穴から先に書きます。LangSmithの公式ドキュメントは docs.smith.langchain.com から docs.langchain.com/langsmith へ移転しました。旧URLはリダイレクトで到達できますが、ブックマークや社内Wikiのリンクは更新しておいたほうがいい。

環境変数名が改称されている

以前の LANGCHAIN_TRACING_V2 系から、LANGSMITH_TRACING / LANGSMITH_API_KEY / LANGSMITH_PROJECT / LANGSMITH_ENDPOINT に変わっています。日本語の解説記事は旧名称のまま書かれているものが多く、「設定したのにトレースが飛ばない」の原因がここだったというケースは珍しくありません。

LangChainを使っていなくても計装できる

「LangSmith = LangChain専用」という誤解がありますが、違います。公式クイックスタートでは、Pythonの traceable デコレータ、OpenAI SDKを包む wrap_openai ラッパーが案内されています。Anthropic・Google Gemini向けのラッパーも提供されています。

OTel経由の送信も可能です。エンドポイントは api.smith.langchain.com/otel で、こちらはgRPC・HTTPの両方に対応します。リージョン別のエンドポイント（eu. / apac. など）も用意されています。送信された gen_ai.request.model、gen_ai.usage.input_tokens といった属性が、LangSmith側のデータモデルにマッピングされる仕組みです（OpenTelemetryでのトレース送信）。

LangGraphでエージェントを組んでいる場合は、ステップ間の遷移がそのまま階層として見えるため相性がいい。構成そのものについてはLangGraphとは｜LangChainとの違い・エージェント構築の基本を参照してください。

LangSmithが持っていてLangfuseにない領域

デプロイ機能です。LangSmithはObservability・Evaluation・Prompt Engineeringに加えて、アプリケーションのデプロイまでを守備範囲に含めています。LangChainエコシステムで一式そろえたいなら、この統合は効きます。

OpenTelemetryとの関係｜GenAI規約はまだ安定版ではない

ここは competitor記事に誤りが多い部分なので、慎重に書きます。

結論：OpenTelemetryの生成AI向けセマンティック規約（GenAI semantic conventions）は、2026年10月時点でDevelopmentステータスです。安定版ではありません。 不安定なのは属性名などの規約部分であり、OTLPという送信経路そのものの有用性は別の話です。

事実関係を整理します。

• 規約の仕様ファイル冒頭には Status: Development と明記されている

• 2026年6月のsemconv v1.42.0で、本体リポジトリから semantic-conventions-genai という専用リポジトリへ分離された

• その専用リポジトリはタグ付きリリースが未発行で、READMEのSchema URLもTODOのまま

• opentelemetry.io 配下の旧URLは200を返すが、中身は移転告知になっている

つまり「OTelのGenAI規約に準拠しておけば、後からベンダーを乗り換えても属性名はそのまま使える」という想定は、現時点では置けません。規約が変われば属性名も変わります。

実務上の扱い方としては、次のように考えるのが無難です。

• ベンダーロックインを完全に避けられる段階ではない、と前提する

• ただしOTLPでの送信経路自体は両ツールが対応しているため、送信先の差し替え余地は確保できる

• 属性名の変更に備え、計装コードをアプリ本体に直接埋め込まず、薄いラッパー層を挟んでおく

OpenTelemetryそのものの仕組み・Collector構成・導入手順はOpenTelemetryとは｜可観測性標準の仕組み・導入の流れ・案件動向で解説しています。

トレース設計の実務｜何をどこまで記録するか

ツールを入れただけでは運用になりません。設計判断が3つあります。

スパン階層の切り方

原則は、後から切り分けたい単位でスパンを切ることです。

RAGアプリなら、クエリ書き換え・検索・再ランキング・プロンプト構築・LLM呼び出し・後処理。エージェントなら、計画・ツール呼び出し（ツールごと）・最終生成。この粒度があれば、レイテンシ悪化やコスト増加の原因を数分で特定できます。

逆に、細かく切りすぎるとLangfuseではunit消費が増えて課金に直結します。ループ処理の中で1イテレーションごとにスパンを切る実装は、コストを見てから判断してください。

PII・機密情報のマスキングと保持期間

プロンプトと出力をそのまま保存するということは、ユーザーが入力した個人情報もそのまま保存されるということです。ここを無自覚に運用すると、後から大きな手戻りになります。

実装時に決めておく項目を挙げます。

• マスキング対象（氏名・メールアドレス・電話番号・社内識別子など）と、マスキングを行う層（SDKに渡す前か、送信フック側か）

• データ保持期間。Langfuse Hobbyは30日、Coreは90日、LangSmithのbase traceは14日で、拡張保持は追加課金になる

• 誰がトレース画面を見られるか（権限設計）

• 障害調査で生データが必要な場合の例外フロー

保持期間はプランによって上限が決まるため、「3年分の監査ログが要る」といった要件があるなら、プラン選定の段階で効いてきます。

入力経由の攻撃をトレースから検知する観点はプロンプトインジェクション対策｜LLMアプリのセキュリティ実装ガイド、出力側の制御はLLMのガードレールとは｜出力制御の実装パターンとツール選定が詳しいです。

コスト・レイテンシの閾値とアラート

トレースは「見るもの」ではなく「アラートを出すもの」にして初めて運用に乗ります。最低限、次の3つは閾値を決めてください。

トークン削減そのものの手法はLLMコスト最適化案件の単価相場｜トークン削減・推論設計のフリーランス実務にまとめてあります。

なお、トレースに評価スコアを紐付けると、品質の時系列変化も追えます。評価の設計思想とLLM-as-a-Judgeの作り方はLLM評価（Evals）とは｜LLM-as-a-Judgeと品質保証の実務まで解説に譲ります。本記事の範囲は、スコアを「どこに記録するか」までです。

ケース別の選び方

ケース1：受託開発で顧客のデータを扱う

セルフホスト可能なLangfuseが選択肢に入りやすいケースです。顧客データを外部SaaSに送れるかは契約と情報セキュリティ規程で決まります。送れない場合、LangSmithのセルフホストはEnterpriseプランが前提になるため、予算が立たないことがあります。

国内にデータを置く要件なら、LangfuseのCloud日本リージョン（東京）も候補になります（データリージョンの公式ドキュメント）。リージョン間は完全に分離されており、EUとUSのデータが混ざることはありません。

ケース2：自社プロダクトをLangChain / LangGraphで構築している

LangSmithの統合が効くケースです。エージェントの実行ステップがそのまま階層表示され、デプロイまで同じエコシステムで完結します。有料プランはseat課金のため、チーム人数で費用が変わる点だけ試算に入れてください。

ケース3：PoC段階で、まず可視化したいだけ

どちらも無料枠で始められます。選定を急ぐ必要はありません。

ただしPoCの段階で、本番移行時のunit消費量・トレース数を見積もれる状態にしておくと後が楽です。1リクエストあたりのスパン数を記録しておき、想定リクエスト数を掛ける。これだけで、プラン選定の議論が「感覚」から「数字」に変わります。

よくある失敗と導入チェックリスト

失敗1：全部記録して、あとから消せなくなる

最初から全量を記録する設計にして、PIIが混ざっていることに後から気づくパターンです。マスキングは最初の計装と同時に入れる。後付けは既存データの棚卸しを伴うため、工数が跳ねます。

失敗2：トレースを見る人がいない

ダッシュボードは作られたが誰も開かない、という状態。アラート設定まで到達していないのが原因です。閾値とSlack通知を同時に設定してください。

失敗3：PoCのまま本番に入り、課金で驚く

スパン数の見積もりをしないまま本番トラフィックを流し、unit超過で想定外の請求が来るケース。前述のとおり、Langfuseはobservationもscoreも1 unitです。

失敗4：日本語記事のコードをそのまま使う

SDK世代が合わず動かない、環境変数名が旧称のまま、という2パターンが頻出します。

導入チェックリスト

着手前に、以下が埋まっているか確認してください。

フリーランスエンジニアから見たLLMOps案件での位置づけ

LLMアプリの可観測性は、実装スキルと運用設計スキルの両方が問われる領域です。主要フリーランスエージェントの公開案件（2026年10月時点・業務委託の開発案件）を確認する限りでは、「LLMアプリ開発」「生成AI開発」の募集要項にトレース基盤の構築・運用が含まれるかたちで登場することが多く、可観測性だけを切り出した募集は目立ちません。あくまで公開案件を見た範囲の傾向で、非公開案件まで含めた母集団ではない点に注意してください。

参画時に確認しておくと齟齬が減る論点を挙げます。

• データ所在地と送信可否の決裁がすでに取れているか。ここが未決のままツール選定に入ると、後で全部やり直しになる

• セルフホストの運用を誰が持つか。構築だけ受けて運用は先方、という切り分けが曖昧なまま進むケースがある

• 既存の監視基盤との関係。DatadogやGrafanaがすでに動いているなら、LLM部分をどう接続するかが設計の主論点になる

• 契約終了後のプロンプト資産・トレースデータの引き継ぎ。プロンプト管理機能を使い込むほど、移管の手順を決めておく価値が上がる

• PoCから本番への移行判断を誰が持つか。コスト試算の責任範囲は契約前に確認しておく

権限設計やHuman-in-the-loopの組み方まで含めて任される案件もあります。その範囲はAIエージェントの権限設計｜最小権限とHuman-in-the-loopの実装が参考になります。

自分のスキルセットでどの程度の単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。実際の募集内容を見たい場合はフリコンの案件一覧から探せます。

まとめ

セルフホストが要るならLangfuse、LangChainエコシステムで統合したいならLangSmith。これが最短の判断軸です。

• Langfuseはコア部分がMITライセンスでセルフホストが無料。LangSmithのセルフホストはEnterpriseプラン限定

• 無料枠はLangfuse Hobbyが月50,000 unit・保持30日、LangSmith Developerが月5,000 base traces・保持14日

• 課金単位が異なる（unitはtrace・observation・scoreそれぞれ1件、base traceはトレース単位）ため、数字の単純比較は避ける

• どちらもLangChain非依存で計装でき、OTLP送信にも対応する。ただしLangfuseはHTTPのみでgRPC未対応

• OTelのGenAI規約はDevelopmentステータスのため、「規約準拠＝移行安全」という前提は置かない

• マスキングと保持期間は、計装と同時に設計する。後付けは手戻りが大きい

次のステップは2つです。まず無料枠で1本だけトレースを流し、トレース・トークン数・レイテンシが画面に出ることを確認してください。そのうえで1リクエストあたりのスパン数を数える。この数字がないと、プラン選定もコスト試算も議論が進みません。無料枠で1週間ほど流せば実測値が取れます。

参照した一次情報は以下のとおりです。

• Langfuse 料金ページ

• Langfuse セルフホスティング

• Langfuse SDK ドキュメント

• Langfuse OpenTelemetry 統合

• Langfuse データリージョン

• LangSmith 可観測性クイックスタート

• LangSmith OpenTelemetry でのトレース送信

• LangSmith プラットフォーム構成

• LangChain 料金ページ

• OpenTelemetry GenAI セマンティック規約リポジトリ