AIエージェント監視ツール5選|選び方とLangfuse導入4ステップ
代表取締役 上坂大地郎

結論: AIエージェントを本番で動かすなら、監視は後回しにできない。Langfuse・LangSmith・Helicone・Arize Phoenix・Datadogの5製品を費用・導入難易度・機能で比べ、オープンソースのLangfuseで最初の監視ダッシュボードを4ステップで立ち上げる手順を示す。
この記事の要点:
- LangChainの2026年調査で、AIエージェントを本番運用する組織の**89%**が何らかの監視を導入済み(State of Agent Engineering、参照日: 2026-09-03)
- 5製品のうち、Langfuse(MIT)とHelicone(Apache 2.0)はセルフホストが無料。LangSmithは無料枠5,000トレース/月から始められる
- 監視で見るべき指標はレイテンシ・トークン消費・エラー率・コスト・品質スコアの5軸に整理できる
対象読者: AIエージェントやLLMアプリケーションを本番投入している、またはこれから投入するエンジニア・テックリード
読了後にできること: 自分のチームに合った監視ツールを1つ選び、Docker ComposeまたはクラウドでLangfuseを起動してトレースを送信するところまで動かせる
AIエージェントの障害対応手順はランブック記事で整理した。本記事はその前段として、「障害を事後に知る」状態から「異常を早期に検知する」状態へ移るための監視設計を扱う。生成AI社内ルールの作り方でガバナンスを整えたチームにとって、ルールの実効性を数字で確かめる手段にもなる。
LLM可観測性とは — 従来のサーバー監視と何が違うか
可観測性(Observability)は、システムの外部出力からシステム内部の状態を推定できる度合いを指す。LLMアプリケーションの可観測性では、HTTPステータスやCPU使用率だけでなく、プロンプトの入出力・トークン消費量・モデルの応答品質・ツール呼び出しの成否まで追跡する。
従来の監視とLLM監視の違い
項目 | 従来のAPM | LLM可観測性 |
|---|---|---|
追跡対象 | リクエスト/レスポンス、CPU、メモリ | プロンプト、トークン、モデル応答、ツール呼び出し |
コスト計測 | サーバー費用 | API呼び出し単位のトークン課金 |
品質の定義 | レイテンシ、エラー率 | 幻覚率、関連性、正確性 |
トレースの粒度 | 関数・サービス単位 | エージェントのステップ・思考過程単位 |
たとえるなら、従来のAPMは「配送トラックが時刻どおりに到着したか」を見る仕組みだった。LLM可観測性は「荷物の中身が注文と一致しているか」まで開けて確認する仕組みに相当する。
OpenTelemetryによる標準化が進んでいる
Cloud Native Computing Foundation(CNCF)が策定するOpenTelemetryのGenAI Semantic Conventionsが、LLMトレースの属性名を標準化し始めている。定義済みの属性にはgen_ai.request.model(使用モデル)、gen_ai.usage.input_tokens(入力トークン数)、gen_ai.usage.output_tokens(出力トークン数)などがある。Langfuse・Arize Phoenix・Datadogといった主要ツールが対応を進めている(OpenTelemetry公式ブログ、参照日: 2026-09-03)。
ただし、2026年5月時点でGenAI Semantic ConventionsのステータスはDevelopment(開発中)であり、属性名や構造が今後変わる可能性がある。導入時は使用ツールの対応状況を個別に確認する必要がある。
本番AIエージェントの89%が監視を入れている — 調査データが示す現実
LangChainが2025年11月〜12月に1,300人以上の実務者を対象に実施した「State of Agent Engineering」調査の結果を整理する(調査ページ、参照日: 2026-09-03)。
調査の主な数字
指標 | 全体 | 本番運用チーム |
|---|---|---|
AIエージェントを本番運用 | 57% | — |
何らかの監視を導入 | 89% | 94% |
個別ステップまで追跡可能な詳細トレース | 62% | 71.5% |
オフライン評価を実施 | 52% | — |
オンライン(本番)評価を実施 | 37% | — |
品質が最大の壁で、コストではない
同調査で、本番運用の最大の障壁に「コスト」を挙げたのは32%にとどまった。それよりも幻覚(ハルシネーション)、評価手法の不足、AIへの委譲に対する信頼の欠如が上位に挙がっている。
つまり、監視を入れる動機は「APIの請求書が怖い」だけではない。**「AIが何をしたか追跡できない状態で、品質を語れない」**という構造的な問題がある。監視はコスト管理のツールであると同時に、品質を計測可能にする基盤でもある。

5つの監視ツールと5つの監視軸、導入判断フローの関係を1枚にまとめた全体設計図。画像だけ保存しても次のアクションが見える構造にしている。
5製品を費用・導入難易度・機能で比較する
2026年9月時点の公式情報を基に、主要5製品を1つの表にまとめた。料金は変動するため、導入検討時は各公式ページで最新値を確認してほしい。
項目 | Langfuse | LangSmith | Helicone | Arize Phoenix | Datadog LLM Obs |
|---|---|---|---|---|---|
ライセンス | MIT | 商用 | Apache 2.0 | Elastic License 2.0 | 商用 |
GitHub Stars | 34K+ | — | 6.1K+ | — | — |
セルフホスト | ◎ 無制限 | × | ◎ 無制限 | ◎ 無料 | × |
無料枠(クラウド) | あり | 5K traces/月 | 10K req/月 | 25K spans | 40K spans/月 |
有料プラン開始 | $29/月 | $39/席/月 | $79/月 | $50/月(AX) | $160/月 |
トレース保持 | 無制限(セルフホスト) | 14日(基本)/ 400日(拡張) | — | 15日(AX Free) | 15日 |
コスト追跡 | ◎ | ◎ | ◎ 300+モデル | ◎ | ◎ 800+モデル |
評価機能 | LLM-as-a-Judge | テスト+評価 | スコアリング | 幻覚・忠実度検出 | — |
OpenTelemetry | 対応 | — | — | ネイティブ | 対応 |
強み | OSS・全機能セルフホスト | LangChain統合 | 1行で導入・コスト最適化 | RAG評価・埋め込み分析 | 既存インフラとの統合 |
Langfuse — セルフホストで全機能が使えるOSSの本命
Langfuseは2025年6月にプロンプト管理・評価・プレイグラウンドを含む全機能をMITライセンスへ移行した。セルフホストではシート数・保持期間・使用量の上限がない。商用版に残るのはSCIM・監査ログ・プロジェクトRBACなどのエンタープライズコンプライアンス機能のみ(Langfuse公式、参照日: 2026-09-03)。
LangSmith — LangChain/LangGraphを使うチームの第一候補
LangSmithはLangChainが提供するマネージド型プラットフォームで、LangChain/LangGraphベースのアプリケーションとの統合が最も深い。無料のDeveloperプランで5,000トレース/月から始められる(LangSmith公式、参照日: 2026-09-03)。
Helicone — ベースURLを変えるだけの最速導入
Heliconeはプロキシ型のアプローチを取り、LLMプロバイダーへのリクエストURLをHelicone経由に変えるだけで導入が完了する。コード変更は実質1行で、300以上のモデルのコストを自動追跡する(Helicone公式、参照日: 2026-09-03)。レスポンスキャッシュやプロバイダー間の自動フォールバック機能も備える。
Arize Phoenix — RAG評価と品質分析に強いOSS
Arize Phoenixは忠実度・関連性・幻覚・毒性の組み込み評価器を持ち、RAGパイプラインのコンテキスト関連性や応答の忠実度を自動検査できる。埋め込みの分布分析でドリフトを検出する機能もある。OpenTelemetryネイティブで、pip install arize-phoenixと1コマンドでローカル起動できる(参照日: 2026-09-03)。
Datadog LLM Observability — 既存のインフラ監視に統合する選択肢
すでにDatadogでサーバーやAPMを監視しているチームにとって、LLMのトレースを同じダッシュボードで確認できるのは大きな利点になる。ツール呼び出し・埋め込み・検索のスパンは課金対象外で、LLMスパンのみが計測される(参照日: 2026-09-03)。ただし、LLM Observabilityは検出時に自動有効化される場合があり、予期しない課金が報告されている点は事前に確認すべき注意点になる。

「LangChain前提か」「セルフホストするか」「既存監視基盤があるか」の3つの質問で5ツールを絞り込む診断フロー。
3つの質問で絞り込む — 選び方の判断フロー
5製品を前に迷ったら、次の3つの質問で候補を絞り込める。
Q1: LangChain / LangGraph をメインで使っているか
「はい」ならLangSmithがトレース統合の深さで有利。LangChainのコールバックが自動でトレースを送信するため、追加のインストルメンテーションがほぼ不要になる。
Q2: データを自社インフラに置きたいか
「はい」ならLangfuse(MIT・Docker Compose)またはArize Phoenix(Elastic License 2.0・pip一発)が候補になる。Langfuseは全機能がセルフホストで使え、PhoenixはRAG評価に強い。
Q3: 既存のDatadog環境があるか
「はい」ならDatadog LLM Observabilityを検討する。サーバー側のメトリクスとLLMトレースを同一画面で確認でき、AIの応答遅延がインフラ起因かモデル起因かの切り分けが速い。
上記のいずれにも当てはまらず、最速で監視を始めたい場合はHeliconeが候補になる。ベースURLの変更だけで導入でき、プロキシ型のため既存コードへの影響が小さい。
Langfuseを4ステップで立ち上げる
ここではLangfuseのセルフホスト版をDocker Composeで起動し、Pythonからトレースを送信するまでの手順を示す。公式ドキュメント(langfuse.com/self-hosting、参照日: 2026-09-03)に準拠している。
ステップ1: Docker Composeで起動する
git clone https://github.com/langfuse/langfuse.git
cd langfuse
docker compose up -d
起動後、http://localhost:3000 でLangfuseのダッシュボードにアクセスできる。初回アクセス時にアカウントを作成し、プロジェクトを1つ作る。プロジェクト設定からPublic KeyとSecret Keyを控えておく。
ステップ2: Python SDKをインストールする
pip install langfuse
ステップ3: トレースを送信する
以下はLangfuse Python SDKの基本的なトレース送信例。SDKのメジャーバージョンによってAPIが変わるため、インストール後は公式のクイックスタートで最新のコード例を確認してほしい。
from langfuse import Langfuse
langfuse = Langfuse(
public_key="pk-lf-...",
secret_key="sk-lf-...",
host="http://localhost:3000",
)
trace = langfuse.trace(name="my-first-trace")
generation = trace.generation(
name="chat-completion",
model="gpt-4o",
input=[{"role": "user", "content": "東京の天気を教えて"}],
output={"role": "assistant", "content": "東京は晴れです。"},
usage={"input": 15, "output": 8},
)
langfuse.flush()
trace がリクエスト全体の単位、generation がLLM呼び出し1回分に対応する。エージェントの場合は、trace の下に複数の generation や span(ツール呼び出し等)をネストできる。
ステップ4: ダッシュボードで確認する
http://localhost:3000 のTracesタブを開くと、送信したトレースが表示される。各トレースをクリックすると、入力プロンプト・出力・トークン消費・レイテンシが確認できる。
ここまでの所要時間の目安は、Docker環境が整っていれば15〜30分程度(公式ドキュメントの記載は「5分」だが、初回のコンテナダウンロードとアカウント設定を含めるともう少しかかる)。

Docker Compose起動→SDK導入→トレース送信→ダッシュボード確認の4ステップを時系列で示す手順フロー。
何を見るか — 監視5軸のチェックリスト
ダッシュボードを立ち上げても「何を見ればいいかわからない」状態では意味がない。以下の5軸を最低限のチェック項目として設定する。
1. レイテンシ(応答速度)
LLM呼び出し単位の応答時間を計測する。ユーザー体感に直結するため、P50(中央値)とP95(95パーセンタイル)の両方を追う。P95が急上昇したときはモデル側の負荷か、プロンプトが長すぎるかの切り分けに入る。
2. トークン消費量
入力トークンと出力トークンを分けて記録する。会話が長くなるにつれて入力トークンが膨らむ傾向があり、放置するとコストとレイテンシの両方を押し上げる。
3. エラー率
APIのHTTPエラー(429 Rate Limit、500 Internal Server Error等)とアプリケーションレベルのエラー(ツール呼び出し失敗、パース失敗等)を分けて追跡する。
4. コスト
トレース単位でAPIコストを集計する。モデル別・機能別の内訳が見えると、「どの機能がコストを押し上げているか」の判断がしやすくなる。
5. 品質スコア
Langfuseのスコアリング機能やArize Phoenixの評価器を使い、応答の正確性・関連性を数値化する。LLM-as-a-Judgeで自動採点する方法と、ユーザーフィードバック(サムズアップ/ダウン)を取り込む方法がある。LangChainの調査では、オンライン評価を本番で回しているのは37%にとどまっており、ここが次の改善ポイントになる。

5つの監視軸ごとに「何を見るか」「異常の兆候」「確認アクション」を整理したチェックリスト図。
よくある失敗と回避策
❌ 全トレースを無制限に保存してストレージが爆発する
本番のエージェントは1リクエストで複数のLLM呼び出しとツール呼び出しを行う。全スパンを無期限保存すると、ストレージコストが月単位で倍増していく。
⭕ 保持期間を決め、サンプリングルールを設定する。開発中は全件保存、本番はエラートレースのみ全件+正常トレースは10〜20%サンプリングが現実的な出発点になる。
❌ プロンプトの中身を保存して機密情報が監視ツールに流れる
プロンプトに顧客名・個人情報・社内データが含まれる場合、監視ツールにそのまま送信すると情報漏洩リスクになる。
⭕ PII(個人識別情報)のマスキングを送信前に入れる。LangfuseやHeliconeにはコールバックでの入出力フィルタリング機能がある。セルフホスト版を使えばデータが外部に出ない構成も取れる。
❌ ツールを入れただけで「監視している」と思い込む
ダッシュボードがあっても、誰も見ていなければ監視していないのと同じ。アラート設定なしの状態でツールだけ入れるチームは少なくない。
⭕ 最低限のアラートを初日に設定する。まずはエラー率の閾値(例: 5%超過で通知)とコストの日次上限(例: 前日比150%で通知)の2つから始める。
❌ 本番とステージングで同じプロジェクトを使い、ノイズで本番の異常を見逃す
開発中のテストデータと本番データが混在すると、エラー率やコストの数字が信頼できなくなる。
⭕ 環境ごとにプロジェクトまたはタグを分ける。Langfuseではプロジェクト単位、LangSmithではタグで環境を分離できる。
導入時のコスト・権限・セキュリティの確認ポイント
費用の見積もり方
セルフホスト版(Langfuse・Helicone・Phoenix)はツール自体の費用はかからないが、サーバーとストレージのインフラ費用が発生する。小規模な検証であれば、開発マシン上のDocker Composeで十分。
クラウド版は、トレース量に応じた従量課金が基本。月間のLLM API呼び出し回数から概算できる。LangSmithは1万トレース/月を超えると追加課金が発生する。14日保持のbase traceは$2.50/千トレース、400日保持のextended traceは$5.00/千トレースと保持期間で単価が異なる(参照日: 2026-09-03)。
データの保管場所と権限
セルフホスト版はプロンプトと応答データが自社インフラ内にとどまる。クラウド版を使う場合は、各ツールのデータ保管リージョンとセキュリティ認証(SOC 2等)を確認する。LangfuseのクラウドProプランはSOC 2/ISO 27001レポートを提供している(参照日: 2026-09-03)。
組織で使う場合の注意
監視ダッシュボードへのアクセス権限を適切に設定する。プロンプトの中身が見える状態は、開発チーム以外にはアクセス制限をかけるのが望ましい。Langfuseの商用版にはプロジェクトRBACがある。OSSのセルフホスト版ではリバースプロキシでのアクセス制御が必要になる。
よくある質問
Q1: 小規模チーム(2〜3人)でも監視ツールは必要か? 規模にかかわらず、本番でLLMを動かしているなら入れる価値がある。特にコストの可視化は、請求書が届いてから驚くよりも事前に把握するほうが健全だ。LangSmithの無料枠やHeliconeの10,000リクエスト/月の無料枠から始められる。
Q2: 複数のLLMプロバイダーを使っている場合、ツールを分ける必要があるか? 分ける必要はない。Langfuse・Helicone・Datadogはいずれも複数プロバイダーに対応している。Heliconeは300以上のモデルのコストを自動追跡し、プロバイダーをまたいだ統合ビューを提供する。
Q3: OpenTelemetryに対応していないツールはすぐに使えなくなるか? 現時点ではGenAI Semantic Conventionsはまだ開発中ステータス(2026年5月時点)であり、即座に業界標準が確定するわけではない。ただし、中長期的にはOpenTelemetry準拠のツールのほうがベンダーロックインのリスクが低い。
Q4: 監視データはどのくらいの期間保持すべきか? 開発・デバッグ用途であれば14〜30日で十分な場合が多い。コンプライアンス要件がある場合は90日以上が必要になることもある。セルフホスト版なら保持期間の制限はなく、ストレージ容量だけが上限になる。
Q5: エージェントのステップが多段になる場合、トレースのネスト構造はどう設計すべきか? 1つのユーザーリクエストを1つの trace として、エージェントの各ステップ(LLM呼び出し、ツール実行、検索)を span または generation としてネストする設計が標準的。Langfuseでは trace > span > generation の3層構造が推奨されている。
今日Docker Composeを動かし、来週チームに見せる
- 今日やること: Langfuseをローカルで起動し、手元のLLMアプリケーションから1本トレースを送る。ダッシュボードでプロンプト・トークン消費・レイテンシが見えることを確認する
- 今週中にやること: 監視5軸のうち、レイテンシとコストのアラート閾値を仮設定する。本番環境とステージングのプロジェクトを分ける
- 来週やること: チームにダッシュボードを共有し、週次で監視データを確認するルーティンを始める。品質スコアの自動計測はその次のステップ
次に読むなら: 監視で異常を検知した後の対応手順はAIエージェント障害対応ランブックにまとめている。障害発生時に「誰が・何を・いつまでに判断するか」をテンプレート化しておくと、監視の効果が格段に上がる。
参考・出典
- State of Agent Engineering — LangChain(https://www.langchain.com/state-of-agent-engineering)(参照日: 2026-09-03)
- Langfuse公式ドキュメント — Self-hosting(https://langfuse.com/self-hosting)(参照日: 2026-09-03)
- Langfuse公式 — Observability Overview(https://langfuse.com/docs/observability/overview)(参照日: 2026-09-03)
- LangSmith公式ドキュメント(https://docs.smith.langchain.com/)(参照日: 2026-09-03)
- Helicone公式ドキュメント — Cost Tracking(https://docs.helicone.ai/guides/cookbooks/cost-tracking)(参照日: 2026-09-03)
- Arize Phoenix — LLM Evaluation Guide(https://qaskills.sh/blog/arize-phoenix-llm-evaluation-guide)(参照日: 2026-09-03)
- OpenTelemetry — GenAI Observability(https://opentelemetry.io/blog/2026/genai-observability/)(参照日: 2026-09-03)
- Top LLM Observability and Evaluation Platforms in 2026 — MarkTechPost(https://www.marktechpost.com/2026/08/09/top-llm-observability-and-evaluation-platforms-in-2026-langfuse-langsmith-braintrust-arize-and-more-compared/)(参照日: 2026-09-03)

