導入｜この記事を書く理由
前回投稿したLangfuseに関する記事に対して、
長期運用を前提とするなら、LangSmithという選択肢もあるのではないか？
というコメントをいただきました。
確かに、RAGを短期のPoCではなく長期運用するシステムとして考えた場合、Observabilityの選択は精度や実装以上に重要な論点になります。
一方で自分自身、LangSmithについてはトレースを試し、ログが可視化されることは確認していたものの、「本当にどちらを選ぶべきか」「LangSmithのメリットや料金体系を踏まえると、どう判断するのが現実的か」という問いに対して、軽く答えられるほど整理できている状態ではありませんでした。
そこで本記事では、Langfuseを選ばざるを得なかった現場の制約を起点にしながら、LangSmithがどのようなケースで有力な選択肢になり得るのかを整理していきます。
単純なツール比較ではなく、RAGを長期運用する際にObservabilityをどう選定すべきか、その判断軸を明確にすることを目的としています。
この記事で分かること
- LangSmithとLangfuseの思想的な違い
- 長期RAG運用でObservabilityが重要になる理由
- SaaS型とセルフホスト型の判断軸
- なぜ現場によって「選ばざるを得ない」ケースが生まれるのか
前提整理｜「長期RAG運用」とは何を指すのか
本記事でいう「長期RAG運用」とは、単にRAGの精度を維持し続けることではありません。
FAQ RAGや社内ドキュメント検索、AIエージェントと組み合わせた業務支援など、RAGはすでに一時的なPoCではなく、継続的に使われる業務システムになりつつあります。
その結果、RAGは「作って終わり」ではなく、運用・保守を前提としたシステム設計が求められるようになっています。
近年は生成AIの登場によって、エンジニア1人あたりが担当するシステム数も増え、少人数で複数のサービスを運用する体制が現実的になっています。
このような状況では、個々のシステムにどれだけ手間がかかるかが、長期的なコストや持続性に直結します。
そのため長期RAG運用では、
- どこまでを自前で管理するのか
- どこからをフルマネージドサービスや外部SaaSに委ねるのか
といった 運用負荷を含めた設計判断が重要になります。
Observabilityも同様で、「機能が豊富かどうか」よりも、半年〜1年後も無理なく回し続けられるかという観点で選定する必要があります。
LangSmithとは何か
LangSmithは、LLMアプリケーションの開発・運用を支援するために提供されている、LangChain社のSaaS型Observability／Evaluationツールです。
LangChainを用いてRAGやAIエージェントを開発するケースは多いと思いますが、LangSmithはその実行過程をトレースとして可視化し、後から振り返れる状態を作ることを主な目的としています。
前回の記事でも触れましたが、RAGやAIエージェントを運用していくうえで、「どこで期待通りに動いていないのか」を把握できなければ、原因特定や改善は困難になります。
LangSmithでは、LLMが回答を生成するまでの一連の流れを実行単位で記録し、次のような情報をまとめて確認できます。
- ユーザーが入力した質問
- Retrieverによって取得されたドキュメント
- 実際にLLMへ渡された最終プロンプト
- LLMの出力結果
- チェーンやツール、エージェントごとの実行構造（階層）
- 実行時間やトークン使用量などのメタ情報
これにより、「なぜその回答が生成されたのか」「どのステップに問題がありそうか」を後から再現・検証できる状態を作ることができます。
特にLangChainを中心にLLMアプリを構築している場合、追加の実装コストを抑えたままトレースや評価を導入できる点は、LangSmithの大きな特徴です。
開発初期からObservabilityを組み込みやすく、PoCから本番まで一貫して使える設計になっています。
一方で、LangSmithはSaaSとして提供されるサービスであり、ログや評価データは外部環境に送信されます。
そのため、長期運用を前提とした場合には、セキュリティ要件・運用負荷・コスト構造といった観点を含めて検討する必要があります。
次章では、こうした前提を踏まえたうえで、LangSmithが持つメリットをもう少し具体的に整理していきます。
LangSmithのメリット
LangSmithの最大のメリットは、LLMアプリケーションの運用に関わる負荷を、大きく外部SaaSに委ねられる点にあります。
従来のアプリケーション開発では、ログやメトリクスをDatadogなどの外部SaaSに集約し、エラー検知や可視化を行うことが一般的です。
LangSmithは、この考え方をLLMアプリケーションの世界にそのまま持ち込んだツールだと捉えることができます。
具体的には、次のような運用コストを自前で抱えずに済みます。
- 実行ログやトレースを保存・可視化するための基盤構築
- 評価結果や実行履歴を管理するためのデータ設計
- LLMの挙動を比較・分析するためのUI実装
- ログや評価データを長期間保管・検索するための運用
これらをSaaSとして提供してくれるため、LLMアプリの運用者は「基盤を作ること」ではなく、「どこをどう改善するか」という判断に集中できます。
また、LangSmithはアカウント作成から導入までの手順が比較的シンプルで、LangChainとの親和性が高い点も大きな強みです。
既にLangChainを用いてRAGやAIエージェントを開発している場合、トレースや評価を追加するための実装コストは最小限で済みます。
このように、LangSmithは「早く導入でき、長期間にわたって運用負荷を抑えられる」点で非常に魅力的な選択肢です。一方で、このメリットはSaaSであることを前提に成り立っています。
次章では、この前提を踏まえたうえで、LangSmithの料金体系と、長期運用時にどのようなコスト構造になるのかを整理します。
LangSmithの料金体系まとめ
LangSmithはSaaSとして提供されており、料金は トレース量・保存期間・利用ユーザー数 を軸に設計されています。
まずは公式の料金体系を整理します。
| 特徴 | Developer | Plus | Enterprise |
|---|---|---|---|
| 月額費用 | 0円 | 39$ | カスタム |
| ユーザー | 最大1席(無料) | 最大10席 1席あたり月額39$ |
カスタム |
| トレース量 | 5000トレース/ 月 超過後は従量課金 |
10000トレース/ 月 超過後は従量課金 |
カスタム |
| ホスティング | クラウド | クラウド | クラウド/ ハイブリッド/ セルフホスト |
| データ保存場所 | LangChainのクラウド（米国またはEU） | LangChainのクラウド(米国またはEU) | クラウド: LangChainのクラウド(米国またはEU) ハイブリッド: LangChainのクラウド(米国またはEU) セルフホスト: 顧客VPC |
| 請求形態 | 月額(セルフサービス) | 月額(セルフサービス) | 年間契約(請求書) |
※2026年1月17日時点の情報です。
データ保存場所に関する注意点
LangSmithはSaaSとして提供されるため、Developer / Plusプランでは LangChain社が管理するクラウド環境（米国またはEU）にデータが保存されます。
企業によっては、
- 本番ログを海外リージョンに保存できない
- 社内ドキュメントを外部SaaSに送信できない
といったセキュリティ要件を持つケースも少なくありません。
Enterpriseプランでは「セルフホスト（お客様のVPC）」と記載されていますが、これはOSSを自由に構築するという意味ではなく、
- LangChain社との契約
- 組織アカウントの提供
- 構築方式・責任分界点の事前相談
が前提になると考えられます。
実際の運用形態（AWS/Azureどちらか、ネットワーク構成、責任範囲など）は、導入前に個別確認が必要になりそうです。
トレース保存期間と追加料金
LangSmithでは、トレースの保存期間によっても料金が発生します。
| トレースの保持について | ベース | 拡張 |
|---|---|---|
| 価格 | 0.5$/ 1000トレース | 5$/ 1000トレース |
| 保存期間 | 14日 | 400日 |
料金体系から見えるLangSmithの思想
LangSmithの料金設計は非常に合理的です。
- インフラ構築不要
- UI・検索・比較機能を即利用可能
- 運用基盤をSaaSに完全委譲できる
一方でその前提は、
「LLMアプリの運用基盤を外部SaaSに預ける」
という思想の上に成り立っています。
この思想がフィットする環境では、LangSmithは非常に強力な選択肢になります。
しかし実際の現場では、
- セキュリティ要件
- 本番ログの持ち出し制限
- 長期保存コスト
- トラフィック増加時の予算管理
といった別の論点が浮上するケースも少なくありません。
次章では、こうした前提を踏まえたうえで、なぜ自分の現場ではLangfuseを選ばざるを得なかったのかを整理していきます。
Appendix(Langfuseの料金体系まとめ)
Langfuse Cloudの場合
| 特徴 | Hobby | Core | Pro | Enterprise |
|---|---|---|---|---|
| 月額費用 | 0円 | 29$ | 199$ | 2499$ |
| ユーザー | 2 | 無制限 | 無制限 | 無制限 |
| トレース量 | 50k ユニット | 100k ユニット 超過後は従量課金 |
100k ユニット 超過後は従量課金 |
100k ユニット 超過後は従量課金 |
| ホスティング | クラウド | クラウド | クラウド | クラウド |
| データ保存場所 | 米国またはEU | 米国またはEU | 米国またはEU | 米国またはEU |
| 請求形態 | - | セルフサービス | セルフサービス | セルフサービス、年間契約は営業に問い合わせ |
| 支払い方法 | - | クレジットカード | クレジットカード | クレジットカード、請求書 |
| SDK(Python、JavaScript) | ⚪︎ | ⚪︎ | ⚪︎ | ⚪︎ |
| 取り込みスループット | 1000リクエスト/ 分 | 4000リクエスト/ 分 | 20000リクエスト/ 分 | カスタム |
| 履歴データへのアクセス | 30日間 | 90日間 | 無制限 | 無制限 |
| データ保持期間の変更 | 利用不可 | 利用不可 | 変更可能 | 変更可能 |
※2026年1月17日時点の情報です。
※ Langfuseでは課金単位として「トレース数」ではなく「ユニット（Units）」が採用されています。
※ユニットの計算方法について
Units = Traces + Observations + Scores
LangSmithがトレース数を中心に課金されるのに対し、Langfuseでは観測されるすべてのイベント量が課金対象になります。そのため、評価処理やエージェント構成が複雑になるほど、実行内容のボリュームがコストに反映される設計になっています。
※ Langfuse APIの制限について
※データ保持期間の設定
データ保持期間は最短3日間から、無制限に変更できるとのことです。(プランにより変動)
「履歴データへのアクセス」と「データ保持期間」は意味が異なります。
追加のAppendix
LangfuseのさらなるAppendix
価格計算ツールもあるようなので、詳細見積もりはサイトで見積もってみてもいいかもしれません。
またスタートアップや研究目的、オープンソースプロジェクトの方は割引も用意しているようです。
↓↓↓↓↓↓↓↓↓
Langfuse セルフホスティングの場合
| 特徴 | Open Source |
|---|---|
| 月額費用 | 0円 ※但しインフラ代は自前 |
| ユーザー | 無制限 |
| トレース量 | 制限なし（※インフラ容量に依存） |
| ホスティング | 構築した環境 |
| データ保存場所 | 構築したクラウド/ オンプレミス |
| 請求形態 | OSS利用は無料（Enterpriseアドオン利用時のみ有料） |
| SDK(Python、JavaScript) | ⚪︎ |
| ライセンス | MITライセンス |
※2026年1月17日時点の情報です。
なぜ実運用環境ではLangfuseを選ばざるを得なかったか
実運用を想定した環境で最も大きな前提条件だったのは、RAGで扱うドキュメントの性質でした。
LLMアプリケーションにおいてRAGを活用する場合、Retrieverによって参照されるドキュメントは、単なる公開情報ではありません。
多くの場合、
- 社内規程
- 業務マニュアル
- 顧客情報を含む資料
- 社外持ち出しが禁止されている内部文書
といった、企業外へ持ち出せない機密データが含まれます。
これらのドキュメントや本番ログを外部SaaSへ送信するという運用方針を採用できないケースも少なくありません。
そのため、LLMアプリケーションのObservability基盤についても、
- 外部SaaSにログを送信しない
- 自社もしくは顧客管理下の環境で完結する
というセルフホスティング前提の構成が求められます。
セルフホスティングという前提に立ったときの選択肢
この条件下では、LangSmithとLangfuseのいずれも「セルフホスティングが可能な選択肢」として候補に挙がります。
ただし両者のセルフホストは、性質が大きく異なります。
LangSmithの場合、セルフホストはEnterpriseプランでのみ提供されており、
- 商用契約が前提
- 年間契約による費用発生
- LangChain社との構築方式・責任分界点の事前調整
が必要になります。
さらに「顧客VPC上に構築する」という前提から、
- 利用するクラウド環境（AWS / Azure 等）の提供
- ネットワーク設計やアカウント管理
といった点についても、事前に整理・合意する必要がありました。
結果としてLangfuseを選択した理由
一方でLangfuseは、MITライセンスのOSSとして提供されており、
- ソフトウェア利用料は不要
- セルフホスト構成が標準で想定されている
- 自社管理下のクラウドやオンプレミス環境で完結できる
という特徴があります。
今回の案件では、
- 外部SaaSへのログ送信が不可
- 顧客環境外へのデータ持ち出しが不可
といった制約条件が重なりやすくなります。
これらの条件を整理していくと、
「Langfuseを選ぶべきだった」というよりも、Langfuse以外の選択肢が現実的に残らなかった
という結論に近い判断になります。
LangSmithは非常に完成度の高いObservabilityツールであり、外部SaaS利用が許容される環境であれば有力な選択肢になります。
しかし、セキュリティ要件と運用責任が強く制約される実運用環境では、OSSとしてセルフホスト可能なLangfuseが現実解になるケースも多いという整理になります。
LangSmithはどんなケースで「アリ」か
ここまで、Langfuseを選ばざるを得なかった背景や制約条件を整理してきました。
一方で、それはあくまで「外部SaaSを利用できない環境」における判断であり、すべてのLLMアプリケーションに当てはまる話ではありません。
前提として、Observability基盤をセルフホストすること自体は技術的に可能です。
しかし実際には、
- インフラ構築
- データベース運用
- バックアップ設計
- 障害対応
- バージョンアップ追従
といった運用・保守コストが継続的に発生します。
そのため、
- 外部SaaSの利用が許容されている
- セキュリティ要件が比較的緩やか
- 運用チームの人数を増やせない
- LLMアプリの開発スピードを優先したい
といった環境では、SaaS型Observabilityを選択する合理性は非常に高くなります。
その中でもLangSmithは、
- LangChainとの高い統合度
- トレース・評価・デバッグの導入が容易
- インフラ管理を一切意識せずに運用できる
という点で、「まず動かす」「早く回す」フェーズとの相性が極めて良いツールです。
PoCから本番初期フェーズにかけて、
- まずユーザーに使わせたい
- 評価や改善サイクルを早く回したい
- Observability基盤の構築に時間を割きたくない
といった状況であれば、LangSmithをSaaSとして利用する判断は十分に「アリ」だと考えています。
Appendix | 最小構成でトレースを体験する
本記事はLangSmith / Langfuseの機能比較や導入手順を目的としたものではなく、 長期RAG運用におけるObservabilityの設計判断を整理することを主眼としています。
そのため、Appendixでは「実際にどの程度の実装でトレースが確認できるのか」を最小構成のサンプルのみで確認します。
詳細なRAG構築や評価実装については扱いません。
※ Langfuseのトレースについては、下記のAppendixで詳しく解説しています。
LangSmithでざっくりトレースしてみる
LangSmithは、LangChainの実行トレースを非常に少ない実装で可視化できます。
以下は、LLMを1回呼び出すだけの最小構成です。
※ 以下は Azure OpenAI を利用する場合の例です。
※ LangSmithの環境変数は公式ドキュメントに従って事前に設定してください。
- LANGSMITH_TRACING
- LANGSMITH_API_KEY
- LANGSMITH_PROJECT
- AZURE_OPENAI_API_KEY
- AZURE_OPENAI_ENDPOINT
from langchain_openai import AzureChatOpenAI
from langchain_core.messages import HumanMessage
llm = AzureChatOpenAI(
azure_deployment="YOUR_DEPLOYMENT_NAME",
api_version="2025-01-01-preview",
)
response = llm.invoke(
[
HumanMessage(content="Langsmithとは何ですか？1文で説明してください。")
]
)
print(response.content)
LangSmithの画面でログを確認する
- Trace一覧
- Trace詳細
結論｜Observabilityはツール選びではなく運用設計
LangSmith、Langfuseはいずれも、LLMアプリケーションを本番環境で安定して運用していくために欠かせないObservabilityツールです。
重要なのは「どちらが優れているか」ではなく、自分たちのシステム要件や運用体制にどちらが適しているかを見極めることにあります。
LangSmithは、SaaSとして完成度が高く、インフラ管理や運用基盤を外部に委ねることで、開発スピードと運用効率を最大化できます。
一方でLangfuseは、OSSとしてセルフホストが可能であり、セキュリティ要件やデータ管理の制約が厳しい環境でも柔軟に運用できる点が強みです。
どちらを選ぶにしても、Observabilityは後付けできるものではありません。RAGやAIエージェントを長期運用していく以上、
- ログをどこに保存するのか
- 誰が運用責任を持つのか
- どこまでをSaaSに委ねるのか
といった 運用設計そのもの が品質と持続性を左右します。
生成AIの進化スピードが速い現在においては、ツール選定以上に「運用を回し続けられる構成」を選ぶことが重要です。
LangSmithか、Langfuseか。その答えは一つではありません。
自分たちの組織とシステムにとって、半年後・一年後も無理なく運用できるかという視点から、Observabilityの設計を考えていくことが、長期RAG運用の出発点になるはずです。
Discussion