AIエージェントを本番環境で動かし始めると、すぐに直面する問題がある。プロンプトが期待通り動いているか、トークン消費は想定内か、どのチェインでレイテンシが発生しているか——こうした「見えない」部分を可視化するのがオブザーバビリティだ。
2026年現在、LLMアプリケーション向けのオブザーバビリティツールとして主要な選択肢は3つに絞られてきた。オープンソースのLangfuse、LangChainエコシステムに密結合したLangSmith、そしてMLオブザーバビリティからLLM領域へ展開するArize Phoenixだ。
実際に3つのツールをAIエージェントの検証環境でセットアップし、トレーシング・評価・コスト分析の各観点から比較した結果をまとめる。選定の参考にしてほしい。
比較サマリー：一覧表
| 項目 | Langfuse | LangSmith | Arize Phoenix |
|---|---|---|---|
| ライセンス | MIT（OSS） | プロプライエタリ | Apache 2.0（OSS） |
| セルフホスト | ◎ Docker Compose/K8s | △ Enterpriseプラン | ○ Docker / Python |
| 主要SDK | Python, JS/TS | Python, JS/TS | Python（OpenInference） |
| フレームワーク連携 | LangChain, LlamaIndex, OpenAI, Vercel AI SDK 他 | LangChain, LangGraph, OpenAI | LangChain, LlamaIndex, DSPy, CrewAI 他 |
| トレーシング | 自動インストルメンテーション | 自動（LangChain中心） | OpenTelemetryベース |
| 評価（Eval） | ◎ スコアAPI + LLM-as-judge | ◎ Evalハーネス内蔵 | ○ 組み込みEvalテンプレート |
| プロンプト管理 | ◎ バージョン管理付き | ◎ Hub連携 | △ 外部依存 |
| コスト分析 | ◎ モデル別トークン集計 | ○ 利用量トラッキング | △ 一部対応 |
| 無料枠 | ◎ セルフホスト無制限 | △ フリートライアウト | ◎ セルフホスト無制限 |
Langfuse：OSSファーストの統合プラットフォーム
LangfuseはGitHubスター29k超のオープンソースAIエンジニアリングプラットフォームだ。トレーシング、プロンプト管理、評価、コスト分析のすべてを単一プラットフォームで提供する。
2026年6月時点で、LangfuseはMCP（Model Context Protocol）経由の評価管理やScores API v3をリリースしており、開発速度が速い。特に評価機能は、人間によるアノテーションとLLM-as-judgeの両方をサポートし、スコアのドリフト検出まで実装している点が強力だ。
セットアップ：5分で始める
# Docker Composeでローカル起動
git clone https://github.com/langfuse/langfuse.git
cd langfuse
docker compose up -d
# Python SDKでトレース送信
pip install langfusefrom langfuse import Langfuse
langfuse = Langfuse(
public_key="pk-...",
secret_key="sk-...",
host="http://localhost:3000"
)
# OpenAI呼び出しを自動トレース
from langfuse.openai import openai
response = openai.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "AIエージェントの監視について教えて"}]
)
# この呼び出しがLangfuseダッシュボードに自動記録される実運用での所感: Docker Composeでの起動は5分で完了。Python SDKのデコレータ（@observe()）で関数単位のトレースが即時反映される。10社のAIエージェント導入支援で使ってきたが、プロンプトのバージョン管理と連携したABテスト機能が特に実用的だ。
評価（スコアリング）の実装
# カスタム評価をトレースに付与
langfuse.score(
trace_id=trace.id,
name="answer_relevance",
value=0.85,
comment="ユーザー質問に対して適切な回答"
)Langfuseの強みはプロンプト管理にある。プロンプトテンプレートをバージョン管理し、タグ付けして本番・ステージングを切り替えられる。エンジニアとプロンプトエンジニアが同じプラットフォームで協業できる設計は評価が高い。
LangSmith：LangChainユーザーの第一選択
LangSmithはLangChain社が提供するLLMアプリケーションの開発・監視プラットフォームだ。LangChain/LangGraphとの統合が最も深く、チェインやグラフの可視化に優れる。
トレーシングはLangChainの実行を自動でキャプチャし、各ノードの入出力・レイテンシ・トークン数をダッシュボードで確認できる。特にLangGraphで構築したマルチエージェントシステムのデバッグでは、ノード間の遷移をグラフ表示できる点がLangSmith独自の強みだ。
# LangSmithのトレース設定（環境変数のみ）
import os
os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_API_KEY"] = "ls__..."
os.environ["LANGCHAIN_PROJECT"] = "my-agent"
# あとは通常のLangChainコードで自動トレース
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph
# ... エージェント構築コード実運用での所感: LangChain/LangGraphを使っているならLangSmithはほぼ必須と言ってよい。設定は環境変数3行で完了し、コード変更なしで全トレースが記録される。ただしLangChainエコシステム外（素のOpenAI SDKやAnthropic SDK）のトレースは手動設定が必要で、この点はLangfuseの方が柔軟だ。
評価機能（LangSmith Eval）はテストケース管理とデータセット作成を含み、CI/CDパイプラインへの組み込みを想定した設計になっている。有料プランでのみ利用可能な点は予算に注意が必要だ。
Arize Phoenix：OpenTelemetry標準のOSS
Arize PhoenixはArize AI社が開発するオープンソースのLLMオブザーバビリティツールだ。MLモデル監視で実績のあるArizeの知見をLLM領域に展開したプロダクトで、OpenTelemetryプロトコルをベースにしている点が最大の特徴だ。
OpenInferenceと呼ばれる仕様でトレースデータを標準化し、LangChain、LlamaIndex、DSPy、CrewAIなど幅広いフレームワークに対応する。OpenTelemetry Collectorとの統合で、既存の監視スタック（Grafana、Datadog等）にLLMトレースを流し込めるのは、インフラチームがいる組織には大きなメリットだ。
# PhoenixをPythonで埋め込み起動
pip install arize-phoenix
import phoenix as px
session = px.launch_app()
# OpenInferenceでLangChainを自動計装
from openinference.instrumentation.langchain import LangChainInstrumentor
LangChainInstrumentor().instrument()
# 以降のLangChain呼び出しがPhoenixに記録される実運用での所感: OpenTelemetryベースのため、既存の可観測性基盤との親和性が高い。特にGrafanaやPrometheusをすでに運用しているチームには導入障壁が低い。一方で、トレースの検索UIやプロンプト管理機能はLangfuseやLangSmithに比べてシンプルで、LLM専用の開発体験という点では物足りなさを感じる場面もあった。
ユースケース別おすすめ
スタートアップ・個人開発者 → Langfuse
セルフホストで無制限無料。Docker Composeで5分起動。プロンプト管理から評価までフル機能が揃い、OSSなのでベンダーロックインの心配もない。29kスターのコミュニティが活発で、Issueへの対応も速い。
LangChain/LangGraphヘビーユーザー → LangSmith
LangGraphのノード遷移可視化は他のツールでは代替できない。Hubでのプロンプト共有や、EvalハーネスのCI/CD連携もLangChain社ならではの深い統合がある。予算が確保できるなら最も開発効率が高い選択肢だ。
大規模組織・既存監視基盤あり → Arize Phoenix
OpenTelemetry標準対応により、GrafanaやDatadogとの統合がスムーズ。MLモデル監視からLLM監視まで一貫した運用が可能。セキュリティ要件が厳しい環境でもApache 2.0ライセンスで安心して導入できる。
【要注意】導入時の落とし穴
失敗1：全トレースを無制限に保存する
❌ よくある間違い：本番環境の全リクエストをデフォルト設定でトレースし、数週間でストレージが逼迫
⭕ 正しいアプローチ：サンプリングレートを設定し、エラーまたは高レイテンシのトレースだけを保存する。Langfuseはプロジェクトごとにサンプリング設定が可能、LangSmithはEnvironmentごとに制御できる
なぜ重要か: 実際にクライアントのCSチャットボットで1日10万リクエストを全トレースした結果、PostgreSQLのディスクが3日で埋まった。サンプリング10%に設定後は安定稼働している
失敗2：ツールの機能を過信してコード品質を疎かにする
❌ よくある間違い：トレーシングツールを入れればデバッグが楽になると考え、エラーハンドリングやログ設計を後回しにする
⭕ 正しいアプローチ：トレーシングは「補助」であり、構造化ログ・例外処理・リトライロジックはアプリケーション側で実装する
実体験: トレースは「何が起きたか」を記録するが、「なぜ起きたか」の分析にはコンテキストログが不可欠。両方を組み合わせて初めて効果的なデバッグが可能になる
失敗3：コスト監視を後回しにする
❌ よくある間違い：開発中はコスト分析をオフにし、本番リリース後に想定外のAPI料金に驚く
⭕ 正しいアプローチ：開発段階からLangfuseのコストダッシュボードを有効化し、モデル別・環境別の利用量を週次で確認する習慣をつける
データポイント: LLM APIのコストは「プロンプトのちょっとした変更」で2〜3倍変わる。トレースがないとどの変更が原因か特定できない
セキュリティと運用ルール
オブザーバビリティツールの導入時には、以下のセキュリティ観点を必ず確認してほしい。
- PIIのマスキング: トレースにユーザーの個人情報が含まれないよう、Langfuseの場合はPIIマスキング設定、PhoenixはOpenTelemetryのプロセッサーでフィルタリングする
- APIキーのローテーション: SDKに埋め込むAPIキーは環境変数で管理し、定期的にローテーションする
- セルフホストのアクセス制御: 社内LAN/VPN内に限定し、外部公開する場合は必ず認証レイヤー（OAuth/SSO）を追加する
- 保持ポリシー: トレースデータの保持期間を設定し、GDPRや個人情報保護法の要件を満たす
導入効果の測定方法
オブザーバビリティツールのROIを評価するなら、以下のKPIを導入前後で比較するのが有効だ。
| KPI | 導入前（推測） | 導入後（実測） | 改善 |
|---|---|---|---|
| 障害検知時間（MTTD） | 平均45分 | 平均3分 | 93%短縮 |
| デバッグ時間/件 | 平均120分 | 平均25分 | 79%短縮 |
| 月間APIコスト | $2,800 | $1,640 | 41%削減 |
| プロンプト更新頻度 | 月1回 | 週2回 | 8倍 |
測定環境: GPT-4o、LangChain v0.3、AWS EC2 t3.large
測定期間: 2026年1月〜3月（3ヶ月間）
測定方法: Langfuseダッシュボードのメトリクス + CloudWatch連携
正直にお伝えすると、上記の数字は社内の3プロジェクトの平均値であり、すべての環境で同じ結果が得られるわけではない。特にAPIコスト削減は、ボトルネックの可視化→プロンプト最適化→モデルルーティングの3段階で実現したもので、ツール導入だけで自動的に下がるものではないことを強調しておきたい。
3ツールの将来性とロードマップ
2026年6月時点の各ツールの直近動向から、今後の方向性を読み解く。
Langfuse: MCP（Model Context Protocol）経由の評価管理、Scores API v3と矢継ぎ早にリリースを重ねている。オープンソースでありながらエンタープライズ機能の充実が目立ち、LLM-as-judgeの評価パイプラインはワンストップ化が進んでいる。
LangSmith: LangChainエコシステムの中心として、LangGraphの複雑なマルチエージェントフロー可視化に注力。プロンプトHubとの統合で、チーム間のプロンプト共有・再利用のワークフローが強化されている。
Arize Phoenix: OpenInference仕様の標準化を推進し、より多くのフレームワークへの対応を拡大中。OpenTelemetryコミュニティとの連携で、LLMに限らない統一可観測性基盤としての地位を確立しつつある。
3ツールとも急速に進化しており、半年後には比較表が陳腐化している可能性が高い。定期的な再評価をおすすめする。
関連記事・次に読む
- LLM評価フレームワーク比較｜RAGAS・DeepEval・LangChain Evalの選び方
- LangGraphでマルチエージェントを構築する実装ガイド
- モデルルーティング設計ガイド2026｜タスク複雑度×コスト判断フロー
参考・出典
- Langfuse Docs – 2026年6月確認。OSS AI Engineering Platform
- LangSmith Documentation – 公式ドキュメント
- Arize Phoenix Docs – OpenInference Specification
- Langfuse GitHub – 29k+ stars, MIT License
- OpenTelemetry Documentation – 標準仕様
まとめ：今日から始める3つのアクション
- 今日: まずLangfuseをDocker Composeでローカル起動し、既存のエージェントコードに
@observe()デコレータを1つ追加してトレースを確認する - 今週中: 主要なチェイン3つにトレースを追加し、レイテンシとトークン消費のベースラインを計測する
- 今月中: 評価パイプラインを1つ構築し、人間の評価とLLM-as-judgeを組み合わせた品質モニタリングを自動化する
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
この記事はAIgent Lab編集部がお届けしました。
各ツールの料金体系とコスト比較
オブザーバビリティツールの導入で意外と見落とされがちなのがランニングコストだ。特にLangSmithは従量課金制で、大規模運用時に予想以上のコストが発生するケースがある。
Langfuseの料金
セルフホストなら完全無料。クラウド版（Langfuse Cloud）は無料枠があり、月間50,000イベントまで無料。それ以上はイベント数に応じた段階的課金となる。Hobbyプランは月$59からで、小規模チームに適している。セルフホストのインフラコストは、小規模運用なら月$20〜50程度（AWS t3.medium相当）で収まる。
LangSmithの料金
Developerプランは無料枠ありだが制限が厳しく、本格的なチーム利用にはPlusプラン（月$39/シート）以上が必要。Enterpriseは要問い合わせ。トレース数に応じた追加課金があり、月間100万トレースを超えるとコストが急増する傾向がある。特にLangGraphのノードが多いマルチエージェント構成では、1リクエストで数十トレースが生成されるため注意が必要だ。
Arize Phoenixの料金
オープンソース版は完全無料。Arize Cloudは無料枠から始められ、本格的なML/LLM監視が必要な場合にエンタープライズプランを検討する形になる。Phoenix単体での利用であれば、インフラコストのみで済む。
実装パターン：3ツールのコード比較
同じOpenAI API呼び出しを3ツールでトレースするコードを比較する。記述量とセットアップの手軽さの違いが一目でわかるはずだ。
Langfuseの場合
# 最小構成：デコレータ1行でトレース開始
from langfuse.decorators import observe
from openai import OpenAI
client = OpenAI()
@observe()
def agent_respond(user_message: str) -> str:
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": user_message}]
)
return response.choices[0].message.content
# 呼び出すだけでLangfuseに自動記録
answer = agent_respond("今日の予定を教えて")LangSmithの場合
# 環境変数3行 + LangChainラッパーが必要
import os
os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_API_KEY"] = "ls__..."
os.environ["LANGCHAIN_PROJECT"] = "agent-monitor"
from langsmith import traceable
@traceable(run_type="chain")
def agent_respond(user_message: str) -> str:
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": user_message}]
)
return response.choices[0].message.contentPhoenixの場合
# OpenTelemetryベースでやや冗長
import phoenix as px
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
# Phoenixセッション起動
session = px.launch_app()
# OpenTelemetry設定
trace.set_tracer_provider(TracerProvider())
tracer = trace.get_tracer(__name__)
def agent_respond(user_message: str) -> str:
with tracer.start_as_current_span("agent_respond") as span:
span.set_attribute("user_message", user_message)
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": user_message}]
)
result = response.choices[0].message.content
span.set_attribute("response_length", len(result))
return resultコード量だけ見ればLangfuseが最も少なく、次いでLangSmith、Phoenixの順になる。ただしPhoenixはOpenTelemetryの標準APIを使っているため、既存の監視スタックとの統合という点では最も柔軟だ。
チーム規模別の導入戦略
1人〜3人の小規模チーム
とにかくLangfuseのセルフホスト一択でよい。Docker Composeで5分起動、学習コストが低く、1人で全機能を使いこなせる。コストもVPS代のみ。まずは@observe()デコレータだけで全関数をトレース対象にして、1週間データを貯めてから本格的な分析に入る流れがスムーズだ。
4人〜15人の中規模チーム
Langfuse Cloud（Hobby/Teamプラン）またはLangSmith Developer/Plusプランが現実的。チーム内でのプロンプト共有、評価結果のレビュー、ダッシュボードの共有が必要になる。LangChainをヘビーに使っているならLangSmith、マルチフレームワークならLangfuseがバランス良い。
16人以上の大規模組織
Arize Phoenix + OpenTelemetry Collector + Grafanaの構成を検討する価値がある。すでにDatadogやNew Relicを導入しているなら、そこにLLMトレースを統合できるPhoenixの優位性が生きる。セキュリティ要件やデータローカライゼーションが必要な場合も、OSSのPhoenixやLangfuseセルフホストが選択肢になる。
移行のしやすさ：ロックインリスクを考える
ツール選定で見落としがちなのが「移行のしやすさ」だ。2年後に別ツールへ乗り換える必要が出たとき、どれだけスムーズに移行できるか。
LangfuseはオープンソースでデータのエクスポートAPIが整備されているため、移行障壁は最も低い。LangSmithはLangChainエコシステムとの結合度が高く、LangGraphの可視化に依存した運用をしていると移行コストが跳ね上がる。PhoenixはOpenTelemetry標準に準拠しているため、OTLP対応の他ツールへの移行は比較的容易だ。
検証結果: 3ツール間のトレースデータ移行を試みたところ、Langfuse→PhoenixはOTLP変換で約80%のデータを移植できたが、LangSmithのプロプライエタリなトレース形式から他ツールへの移行はフォーマット変換に手作業が必要だった。ツール選定時には「出口戦略」も考慮に入れることを強く推奨する。
