LLMモニタリングツールとは、AIエージェントの実行経路・ツール呼び出し・コスト・出力品質を追跡し、本番運用を支える可観測性の基盤である。
自前ホストでデータを社内に囲い込みたいならLangfuse系、LangChainで組んだ資産があるならLangSmith、既存のAPMに載せたいならDatadog。ツールの数だけ選択肢はありますが、迷う原因は機能の多寡ではありません。選定を分けているのは、突き詰めると3つの軸だけ。「自前ホストのOSSか、マネージドのSaaSか」「OpenTelemetryなどの標準に準拠しているか」「評価（eval）機能まで持つか」。この3点を運用形態に当てはめれば、候補は自然に絞り込めます。
- ・LLMエージェントの本番運用は「作る技術」ではなく「動かし続ける運用」の問題。だから可観測性の層が要る
- ・主要ツールは「OSS自前ホスト」「マネージドSaaS」「標準化レイヤー」の3タイプに整理でき、混同すると選定を誤る
- ・料金・仕様は変動が速い。本記事の数値は2026年7月時点の各公式ドキュメント記載に基づく
エージェントは作れる、問題は本番で動かし続けること
ここ2年で、AIエージェントを「作る」ためのツールは出揃いました。フレームワーク、ワークフロービルダー、ドラッグ&ドロップのキャンバス、Pythonライブラリ、マルチエージェントのオーケストレータ。ひとつの仕事をこなすエージェントを立ち上げるだけなら、かつてないほど手数が減っています。国内でも、ノーコード・ChatGPT・Gemini・Claude Code・Python など複数のアプローチが目的とスキルに応じて選べる、という解説記事が並ぶ状況です。
それでも、本番にエージェントを投入したチームの多くが、いまだに一度きりの実験のような運用をしている。今日の難所は、エージェントを作ることではなく、作ったエージェントを本番で動かし続けることのほうへ移っています。これはフレームワーク選びの問題ではなく、運用（Ops）の問題。ベースにした海外の技術記事も、この点を主軸に置いていました。
ソフトウェアの成熟過程を思い返すと分かりやすいかもしれません。最初はスクリプトがあり、次にアプリケーションになり、やがて同時に走るプロセスが増えて、それらを下から束ねる何かが必要になった。その何かがOSでした。OSはリソースをスケジューリングし、プロセスを調整し、マシン上で動く全体を制御する単一の面を提供します。多数のエージェントを同時に走らせる段階では、同じように下層で運用を支える基盤が要る。そうした見立てが語られています。これはあくまで比喩であり、「AI OS」という確立した製品カテゴリが存在するわけではない点には注意してください。
その「下層」の中核を担うのが、本記事のテーマである可観測性のツール群です。エージェントが実際にどう動き、どこでトークンを浪費し、どこで失敗したのかを追跡する層。なお、トレースを具体的にどうコードへ組み込むかという実装手順は別記事で解説しているため、本記事は「どのツールを選ぶか」という選定の話に絞ります。実装記事とはあえて役割を分けている、と考えてください。
なぜLLMエージェントに可観測性が必要か：RPAとの決定的な違い
同じ業務自動化でも、RPAとAIエージェントでは監視に求められるものが根本から違います。この違いを押さえておくと、なぜ従来型の監視では足りないのかが腑に落ちます。
決定的な自動化と非決定的なエージェントの監視要件の違い
RPAは、あらかじめ定義されたルールと分岐に従ってタスクを実行します。手順が決まっているぶん、LLMエージェントよりは実行経路を予測しやすい。ただし完全に決定的というわけではなく、UIの変更や外部システム・APIの状態、タイムアウト、例外分岐、リトライ、部分成功といった揺れは起こります。そのため監視も、成功・失敗の二値だけでなく、どのステップで止まったかのログや例外情報までは必要になります。それでも経路自体は手順表から追いやすく、どこで止まったかは比較的特定しやすい。
AIエージェントはそうはいきません。判断能力を備えていて、状況に応じた柔軟な対応や推論を行う。目標を与えると、計画を立て、ツールを呼び出し、結果を検証しながら自律的に進みます。この「判断を伴う」という性質が、監視の要件を一変させる。同じ入力を渡しても、モデルがそのとき選ぶ経路は変わりうるのです。あるときはツールAを2回呼び、別のときはツールBを経由してから答えにたどり着く。非決定的、というのはそういうことです。
結果だけを見ていては、なぜその結果になったのかが分からない。ここで必要になるのが、実行の全経路を記録するトレースです。エージェントがどのツールをどの順番で呼び、どの段階で何を受け取り、どこで想定と違う分岐に入ったのか。この一連の流れを見えるようにして初めて、失敗の原因究明も、コストの最適化も、品質の検証も可能になります。可観測性（オブザーバビリティ）という言葉が指すのは、まさにこの「動いている中身を観測できる状態」のこと。RPA時代の稼働監視とは、目的からして別物なのです。
LLMモニタリングツールが追跡する観測対象
では、可観測性のツールは具体的に何を見ているのでしょうか。観測対象は大きく5つに分けられます。この5つを頭に入れておくと、後で各ツールの機能差を比べるときの物差しになります。
まず筆頭がトレースです。エージェントが目標を受け取ってから答えを返すまでの実行経路そのもの。どのLLM呼び出しが走り、どのツールが呼ばれ、どんな中間出力が渡り、どこで分岐したか。トレースは他の4つの土台になる情報で、これが取れていないと残りの指標も文脈を失います。
2つめがトークンコスト。LLM呼び出しは処理ごとに課金が発生するため、どのエージェントの、どのステップが、いくらのトークンを消費したかを把握できないと、費用が読めません。無駄なリトライやループが起きていても、コストの内訳が見えなければ気づけない。
3つめがレイテンシです。応答にどれだけ時間がかかっているか。全体だけでなく、どの呼び出しが遅延の原因になっているかを分位（P50やP99など）で見られると、ボトルネックの特定が早まります。
4つめが出力品質の評価、いわゆるeval（エバリュエーション）。ここが重要な分かれ目になります。トレース・コスト・レイテンシは「どう動いたか」を測る指標ですが、「出てきた答えが良かったのか悪かったのか」は、それだけでは分かりません。速く安く動いても、回答がずれていたら本番では使えない。測っている次元（コスト・速度）と、測っていない次元（出力の良し悪し）は別物なのです。この評価機能を持つかどうかが、後の選定軸のひとつになります。
最後がエラーの捕捉。ツール呼び出しの失敗、タイムアウト、想定外の例外。エージェントが非決定的に動く以上、エラーの出方も一様ではありません。どの経路で、どんな条件下でエラーが起きたかをトレースと紐づけて記録できると、再現と修正がぐっと楽になります。
この5つを並べると、可観測性ツールが「稼働しているか」を見る従来の監視とは守備範囲が違うことが見えてきます。稼働確認は入口にすぎず、その先の「何をどう処理し、いくらかけて、どんな品質の答えを返したか」までを観測対象に含む。これがLLMモニタリングツールの土俵です。
選定を分ける3つの判断軸
観測対象を押さえたうえで、いよいよツールを選ぶ段に入ります。世の中には多くのツールがありますが、選定を分けているのは次の3つの軸です。機能一覧を端から比べる前に、この軸で運用形態を切り分けたほうが、候補は速く絞れます。
1つめは、自前ホストのOSSか、マネージドのSaaSか。これはデータをどこに置くかとコストの問題に直結します。自前ホストのオープンソースなら、トレースやコストといった実行データを自社の環境内に留められる。機密性の高いプロンプトや出力を外部に出したくない組織では、この点が決め手になります。一方でマネージドのSaaSは、インフラの管理をベンダーに任せられる代わりに、データは相手の基盤を通る。どちらが正解ということはなく、データ管理の要件と、インフラ運用に割ける人手のどちらを重く見るかで決まります。
2つめは、標準に準拠しているか。ここでいう標準とは、OpenTelemetryのGenAIセマンティック規約や、それを補完するOpenInferenceといった計装の共通仕様を指します。OpenTelemetryのGenAIセマンティック規約は、LLM呼び出し・エージェント・ツール実行の属性スキーマ（gen_ai.* など）を標準化する取り組みで、Datadog・Honeycomb・New Relic などが対応を進めています。標準に沿った形でトレースを取っておけば、独自SDKだけに依存するより乗り換えは楽になります。ただし各バックエンドが受け付ける規約やバージョンは同一ではなく（たとえばDatadogはOTelのGenAI規約に対応する一方、OpenInferenceは非対応）、乗り換え先によっては属性の変換や一部の再計装が要ることもあります。それでも特定ベンダー独自の形式だけに縛られるより、標準へ寄せておくほうが移行の余地は広い。ロックインを避けたいなら、この軸は外せません。
3つめは、評価とAPM統合の範囲です。前の章で触れたeval機能を持つかどうか、そして既存の監視基盤（APM）にどこまで溶け込むか。出力品質を継続的にスコアリングしながら回したいなら評価機能は必須ですし、すでにDatadogのようなAPMで社内のシステムを監視している組織なら、LLMの可観測性も同じ画面に統合できるほうが運用が一本化されます。逆に、まだ監視基盤を持たず小さく始める段階なら、統合よりも導入の手軽さが効いてくる。
この3軸（データの置き場所、標準準拠、評価・統合の範囲）を状況に当てはめれば、次章以降で比べる各ツールが「どのケースの誰に向くか」が見えてきます。次は、この軸を踏まえて主要ツールを実際に並べてみます。
主要LLMモニタリングツール比較
3つの軸を手にしたところで、実際のツールを並べてみましょう。ここで扱うのは、選定段階で公式ソースを確認できたLangfuse・LangSmith・Arize Phoenix・W&B Weave・Datadog LLM Observabilityの5つ。料金やプラン内容は更新が速いため、以下の数値は2026年7月時点の各公式ドキュメント記載であり、導入前には必ず各社の最新のpricingページで再確認してください。この注意書きは各章で繰り返さず、ここで一度だけまとめます。
| 項目 | Langfuse | LangSmith | Arize Phoenix | W&B Weave | Datadog LLM Observability |
|---|---|---|---|---|---|
| 提供形態 | OSS＋Cloud | SaaS中心 | OSS | SaaS | 企業向けAPM統合 |
| 自己ホスト | 可（無償） | マネージド主体 | 可（ローカル実行可） | マネージド主体 | 不可（SaaS） |
| ライセンス | コアMIT（EE別） | 商用 | オープンソース | 商用 | 商用 |
| 標準対応 | OpenTelemetry統合 | framework-agnostic | OTel＋OpenInference | 独自SDK中心 | GenAI規約サポート |
| 評価機能 | あり | あり | あり | あり（スコアリング） | あり |
| 料金の目安 | 無料〜月199USD＋ | 無料〜39USD/席＋従量 | 無償（OSS） | 要問合せ | 既存APM課金体系 |
| 向いている人 | 自前ホスト志向 | スタック横断で使いたい | ロックイン回避 | 実験管理から延長 | 既存Datadog利用 |
表の数字だけでは選べません。ここで見落としてはいけないのが、自前ホスト型とマネージド型では比較の土俵そのものが変わるという点。
表の読み方（自前ホスト型とマネージド型で軸が変わる）
OSSの自己ホスト型は、料金欄が「無償」でも運用コストがゼロという意味ではありません。サーバーもデータベースも自前で立てて保守する手間が乗る。逆にマネージド型は月額が発生する代わりに、その手間をベンダーが引き受けます。「料金」の行を横並びで比べると自己ホストが圧倒的に安く見えますが、人件費を含めた総コストで見れば話は変わってくる。表は入口の地図として使い、最終判断は次章以降の各タイプの説明と突き合わせてください。
OSS・自前ホスト型：Langfuse / Arize Phoenix
データを自社の環境に留めたい、あるいはコストを抑えて小さく始めたい。そんなケースで軸になるのがOSS・自前ホスト型です。
Langfuseは、MITライセンスのオープンソースとして提供されるLLMエンジニアリング基盤。公式ドキュメントによれば、トレーシング・評価・プロンプト管理・データセットといった基本機能とAPIをMITライセンスで無制限に自己ホストでき、SSO・監査ログ・SLAといった一部のエンタープライズ機能・サービスのみがライセンスキーを要します。2026年1月にはデータベース企業のClickHouseに買収されましたが、オープンソースと自己ホストの提供はこれまでどおり維持されると公式にアナウンスされています。OpenTelemetry・LangChain・OpenAI SDK・LiteLLMなどと統合できる点も明記されている。クラウド版を使う場合、無料のHobbyプランが月50,000ユニットまで、Coreプランが月29USDで100,000ユニット、Proプランが月199USD、Enterpriseが月2,499USDという体系（ここでいうユニットはトレース・observation・スコアなど課金対象イベントの単位で、単純なトレース件数ではありません）。自己ホストなら、これらとは別に無償で立てられます。
Arize Phoenixは、OpenTelemetryとOpenInference計装の上に構築されたオープンソースのAI可観測性プラットフォーム。公式ドキュメントでは、APIキーやクラウドアカウントなしにローカル環境で実行できると説明されており、ベンダーロックインを避けたい場面で選択肢になります。評価機能はPhoenix EvalsやOpenInferenceといった周辺ライブラリと組み合わせて使う形で、LangSmithのような一体型サービスとは提供のされ方が異なります。標準の計装に素直に乗っているため、後述の標準化レイヤーとの相性がよい。なおPhoenixには商用のマネージド版としてArize AXがあり、アラートやオンライン評価、エンタープライズ機能を含む本番運用を求める場合の受け皿になります（Phoenixからの移行は同一プランの延長ではなく別契約で、課金はスパン単位）。
自前ホストで注意する運用コスト
計装レイヤー：OpenLLMetry（Langfuse／Phoenixへデータを供給する層）
OpenLLMetry（Traceloop）は、Apache 2.0ライセンスのオープンソース計装ライブラリです。ここまでのLangfuseやPhoenixが「データを受け止めて見せる」可観測性プラットフォームなのに対し、OpenLLMetryはその一段下で「データを取り出して送り出す」計器にあたります。OpenTelemetryの上に構築され、LLMプロバイダやベクタDBを計装して、OTelのGenAI規約に沿ったデータを送り出します。Datadog（OpenLLMetry 0.47以降に対応）のように直接受け取れる基盤もあれば、PhoenixのようにOpenInferenceを中心に据え、他形式は変換して取り込む基盤もあります。LangfuseやPhoenixと横並びで選ぶ対象というより、それらへデータを供給する層と捉えると位置づけが掴めます。
SaaS・マネージド型：LangSmith / W&B Weave / Datadog LLM Observability
インフラ管理はベンダーに任せて、本業のエージェント運用に集中したい。そういう組織にはSaaS・マネージド型が向きます。
LangSmithは、LangChain社が提供するLLM・エージェントの可観測性＆評価プラットフォーム。公式ドキュメントによれば、Python/TypeScript/Go/JavaのSDKを持ち、LangChain以外のスタック（OpenAI SDK・Anthropic SDKなど）もトレースできるframework-agnostic設計です。トレース数・ユーザーフィードバック・トークン使用量・コスト内訳・レイテンシ分位（P50/P99）などを可視化する。料金はDeveloper／Plus／Enterpriseの3段で、Plusは席料金に加えてトレース数に応じた従量課金があります。2026年7月時点の公式では、無料のDeveloperが月5,000 baseトレース・保持14日・最大1シート、Plusが月39USD/席で10,000 baseトレース・シート無制限。従量はbaseトレースが1,000件あたり2.50USD（保持14日）、延長トレースが1,000件あたり5USD（保持400日）です。含有トレース数や無料枠は変わりうるので公式料金ページで確認したい。LangChainで組んだ資産があれば導入は素直ですが、framework-agnosticなので、OpenAIやAnthropicのSDKで組んだスタックでも起点にできます。
W&B WeaveはWeights & Biasesの可観測性機能で、@weave.opデコレータ一行でLLM呼び出しの入力・出力・コスト・レイテンシを記録し、データセット上でスコアリングする評価機能を持ちます。実験管理のW&Bを既に使っているチームなら、その延長線上で導入できるのが強み。
Datadog LLM Observabilityは、既存のAPMに統合された企業向けの選択肢。公式ブログによれば、OpenTelemetryのGenAIセマンティック規約をサポートしています。すでにDatadogで社内システムを監視している組織であれば、LLMの可観測性も同じ画面に統合できる。
既存の監視基盤（APM）がある組織の選び方
すでにDatadogやNew RelicのようなAPMを社内標準として運用しているなら、LLMの監視を別ツールで分断せず、同じ基盤に寄せるほうが運用は一本化されます。アラートの窓口も、当番の見る画面も一つで済む。逆に、監視基盤をまだ持たない小規模チームが「いずれ統合したいから」と重厚なAPMから入るのは、オーバースペックになりがちです。今の規模に合った軽い導入から始め、必要になった段階で標準に沿って乗り換える道を残すほうが現実的でしょう。
標準化レイヤーとロックイン回避：OpenTelemetry GenAI と OpenInference
ツール選びで最後に効いてくるのが、計装の標準に乗っているかどうか。OpenTelemetryのGenAIセマンティック規約は、LLM呼び出し・エージェント・ツール実行の属性スキーマ（gen_ai.*など）を標準化する取り組みで、Datadog・Honeycomb・New Relicなどが対応を進めています。OpenInferenceは、AIアプリのトレーシング用にArizeが定める規約とプラグイン群で、OTelのGenAI規約とは別系統です。これらの標準に沿ってトレースを取っておけば、独自形式だけに依存するより乗り換えはしやすくなります。ただし両者は完全互換ではなく、バックエンドごとに対応する規約が違う（DatadogはOTel GenAIを受け付けるがOpenInferenceは非対応、PhoenixはOpenInference中心で他形式は変換して取り込む）ため、移行時には対応状況の確認や一部の再計装が要ることもあります。それでも標準へ寄せておくほうが、独自形式だけに縛られるより移行の範囲を小さくできる分岐点です。
観測対象を動かす実行環境そのものの選び方については、姉妹サイトのClaude Code推奨スペック｜GPU不要・ノートPCで快適に使える環境を解説も参考になります。可観測性の層と、その下でエージェントを走らせる基盤の層は、セットで設計すると迷いが減る。
採用前に状態を確認したいツール
標準準拠と並んで、ツール自体の保守状況も見ておきたい点。プロキシ型のオープンソース可観測性として知られるHeliconeは、公式の告知によれば動きに変化がありました。
Heliconeは2026年3月3日にMintlifyへの買収が発表され、以後はメンテナンスモードへ移行しました。公式ブログによれば、セキュリティ更新・新モデルへの対応・バグ修正・パフォーマンス修正は継続する一方、大規模な新機能開発を前提とした通常のロードマップ運営とは異なる状態とされています。（出典: Helicone公式ブログ「Helicone is joining Mintlify」／Mintlify公式ブログ、2026年3月3日発表）
まとめ
LLMモニタリングツールに唯一の正解はありません。決まるのは、運用形態を3つの軸に当てはめたときの答えです。
データを自社内に留めたい、コストを抑えて小さく始めたいなら、自己ホストできるOSS型。可観測性プラットフォームとしてはMITライセンスで無償の自己ホストが可能なLangfuse、ローカル実行できるArize Phoenixが候補になります。計装をベンダー非依存にしたいなら、そこへデータを送るOpenLLMetryを計器の層として組み合わせる形です。ただしインフラ保守の手間が乗る点は、運用人員と相談してください。
インフラ管理を任せて本業に集中したいなら、マネージド型。スタックを問わず使えるLangSmith、実験管理から延長したいならW&B Weave、既存のDatadogに統合したいならDatadog LLM Observabilityが素直な選択です。
そして、どのタイプを選ぶにせよ、OpenTelemetryのGenAI規約やOpenInferenceといった標準に乗っているかは外さないほうがいい。完全な互換が保証されるわけではありませんが、独自形式だけに依存するより、乗り換え時にトレース設計を作り直す範囲を小さくできます。評価（eval）機能の有無も忘れずに。トレースやコストは測れても、出力の品質そのものは別の次元。品質を継続的に見たいなら、評価機能を選定条件に含めてください。Heliconeのように保守状態が変わったツールは、状態を確認したうえで新規採用の可否を決める。この当てはめができれば、迷いは絞り込めます。
よくある質問
Q. LLMモニタリングツールは無料で使えますか？
オープンソース型は無償で自己ホストできます。Langfuseは公式ドキュメントによればMITライセンスでコア機能を無償で自己ホスト可能、Arize Phoenixもオープンソースとして提供されています。マネージドのSaaSは無料枠と有料プランに分かれ、2026年7月時点でLangSmithは無料のDeveloperプラン（月5,000 baseトレース）から、Langfuse Cloudは無料のHobbyプランからとなっています。料金は変動するため公式で確認してください。
Q. LangChainを使っていないと導入できませんか？
いいえ。LangSmithは公式ドキュメントによればframework-agnostic設計で、OpenAI SDKやAnthropic SDKなどLangChain以外のスタックもトレースできます。LangfuseやArize Phoenixも特定フレームワークに縛られず、OpenTelemetryなどの標準計装で幅広く連携可能。LangChain資産があると相性がよいツールはありますが、前提条件ではありません。
Q. 既存のDatadogなどAPMと併用できますか？
可能です。Datadog LLM Observabilityは公式ブログによればOpenTelemetryのGenAIセマンティック規約に対応しており、既存のAPMにLLM可観測性を統合できます。OpenLLMetryのように、標準のOTelデータを既存基盤へ送る計装層を使う方法もあります。標準準拠のツールを選べば、監視画面を一本化しやすくなる。
Q. 小規模な運用でもモニタリングは必要ですか？
必要です。LLMエージェントは同じ入力でも実行経路が変わる非決定的な挙動を持つため、成功・失敗のログだけでは「どこで何を呼び、なぜ失敗したか」を追えません。小規模でも実行トレースを取っておくと、障害の切り分けとコスト把握が早くなります。無償の自己ホストや無料プランから始められるので、規模が小さいうちに計器を仕込んでおくのが現実的です。
参考資料
- Langfuse 公式: GitHub リポジトリ
- Langfuse 公式: 料金プラン
- LangSmith 公式: Observability ドキュメント
- Arize Phoenix 公式: ドキュメント
- OpenTelemetry 公式: GenAI Semantic Conventions
- OpenInference 公式: GitHub リポジトリ
- OpenLLMetry (Traceloop) 公式: GitHub リポジトリ
- Datadog 公式: LLM Observability と OpenTelemetry
- Helicone 公式ブログ: Helicone is joining Mintlify（Mintlify買収・メンテナンスモード移行）
