LLMオブザーバビリティとは｜LangSmith・Langfuse・Datadog など主要7ツールの整理

LLMを業務で使うとき、最初に整備するのはプロンプトとRAGですが、本番運用に入った瞬間に問われるのは「品質と費用が説明できるか」です。AI（ChatGPT、Claude、Geminiなど）のAPI呼び出しは確率的にふるまうため、CPU使用率やHTTPステータスを見ても「出力の品質が落ちているか」「コストが想定通りか」は判定できません。LLMオブザーバビリティは、この説明責任を果たすための運用設計です。

01.まず結論：LLM運用は「動いている」より「品質と費用が説明できる」を見る

従来のWebアプリケーション運用は「200 OKが返っているか」「レイテンシは閾値以下か」を見ます。LLMアプリケーションでは、これらが正常でも「回答が事実と違う」「言葉遣いが不適切」「同じ質問にも毎回違うトーンで答える」といった品質問題が起きます。さらに、トークン消費が増えれば月次コストが想定の数倍になることもあります。

2026-05時点で本番運用に耐えるLLMアプリは、次の3層を持っています。どこから着手するにせよ、最終的にはこの3層を埋める前提で設計を始めます。

• 1リクエストの全工程を時系列に追えるトレース
• コスト・遅延・利用量の集計メトリクス
• 出力品質を継続的にスコア化する評価

02.LLMオブザーバビリティとは何か

従来のAPM・ログ監視との違い

APMが見るのはサーバの状態（CPU・メモリ・レイテンシ・エラー率）で、可観測対象が決定論的です。LLMの場合、同じ入力でも温度設定や内部状態により出力が変わるため、「正常／異常」の境界が確率的になります。APMで見える「動いている／止まっている」の二値判定では、品質劣化のような連続的な変化を捉えられません。

LLMオブザーバビリティは、APMが見るインフラ層に加え、次の4つを観測対象に追加します。

• プロンプトと回答の中身
• 1リクエスト内の複数LLM呼び出しの連鎖
• 出力品質スコア
• ユーザーフィードバックの集計

RAG設計や品質管理と隣接する運用領域として位置づけられます（ AIエージェント＋RAG実務ガイド／ Agentic RAG）。

3本柱：トレース／メトリクス／評価

LLMオブザーバビリティの観測対象は次の3層に整理できます。

APMの世界では「メトリクス・ログ・トレース」がオブザーバビリティ3本柱とされてきました。LLMの世界はそれに「評価（Evaluation）」を加えた構成で、品質という確率的な次元を継続観測する点が大きな違いです。

OpenTelemetry GenAI Semantic Conventionsの位置づけ

2024〜2025年にかけて、CNCFの OpenTelemetry GenAI Semantic Conventions が整備されました。これはLLM呼び出しのトレース・メトリクスをどう名前付け・記録するかの共通仕様で、ベンダー横断の互換性を目指しています。2026-05時点で安定版に向けた策定が進む段階で、各ツールが対応を進めています。

実務的な意味は次の2点です。新規にLLMアプリを設計するなら、OpenTelemetry互換を計装の前提に置くと将来の選択肢が広がります。

• 自社で計装したトレースが特定SaaSに縛られない
• Datadog・Langfuse・Arize Phoenixなど対応ツールの間で観測データを乗り換えやすくなる

03.監視すべき5つの軸（品質・コスト・遅延・利用・安全）

BtoBの本番運用で必ず計測する観点を5軸で整理します。導入初期は全部を埋める必要はありませんが、「どの軸をいつ追加するか」のロードマップは事前に決めておくと検討の手戻りが減ります。

品質軸は AI出力の品質管理 、安全軸は AI（セキュリティ・権限管理） と接続します。観測ツールはどちらの軸も拾えますが、組織内で誰がその数値を見るか（品質→プロダクト、安全→セキュリティ／法務）を分けて運用するのが現実的です。

04.主要ツール7選の整理

2026-05時点で日本のBtoB企業がLLMオブザーバビリティを検討するときに候補に上がりやすい7ツールを、提供形態とOpenTelemetry互換性で整理します。料金や提供形態は各社で頻繁に更新されるため、最終判断時には公式ドキュメントで再確認してください。

LangSmith（LangChain公式SaaS）

LangChain Inc.が提供するLLMアプリ向けSaaSです。LangChain／LangGraphで組んだエージェントのトレースが最小設定で取れ、評価データセット・プロンプト管理・本番モニタリングまで一体で揃います。LangChain前提のチームには第一候補になります。LangChainを使わない場合でも、SDKやOTelエクスポータ経由で計装できる構成が用意されています（詳細は公式ドキュメントで2026-05時点の対応範囲を確認）。

Langfuse（OSS＋クラウド／セルフホスト両対応）

OSSとして公開されており、クラウド版とセルフホスト版（Docker／Kubernetes）の両方が選べます。プロンプト管理・評価・トレースが揃い、機微情報を社外SaaSに出したくない要件で採用されやすい選択肢です。LangChain以外（自前実装、各社SDK）との組み合わせでも計装でき、2026-05時点では国内BtoBでも採用報告が増えています。

Arize Phoenix（OSS、OpenTelemetry互換）

Arize AIが公開するOSSで、OpenTelemetryをネイティブ前提に設計されています。ノートブックで開発しながら同じ計装を本番に持っていけるため、研究・PoCから本番への移行が連続的です。Arizeの商用版（Arize AX）でエンタープライズ運用に拡張するパスもあります。

Helicone（OSSプロキシ型）

LLM APIの前段にプロキシを置き、リクエスト／レスポンスを記録する方式が中心です。コードへの差し込みが軽く、コストとレイテンシの可視化が短期で始められます。OTel計装にも対応しているとされていますが、2026-05時点の正確な対応範囲は公式ドキュメントで確認するのが安全です。

Traceloop / OpenLLMetry（OpenTelemetry拡張）

TraceloopはLLM／RAG／エージェント向けにOpenTelemetry計装ライブラリ「OpenLLMetry」を提供しています。それ自体は計装SDKでバックエンドを持たず、収集したトレースはDatadog・Langfuse・Arize PhoenixなどOTel対応の任意の保存先に送れます。「特定SaaSにロックインしたくない」「既存OTelスタックに統合したい」要件に合います。

Datadog LLM Observability（APM統合型）

既存のAPM・ログ・インフラ監視・SIEMをDatadogで運用しているチーム向けの選択肢です。LLM Observability製品としてプロンプト・回答・トークン消費・評価まで取り込み、既存ダッシュボードに統合できます。LLM専門ツールよりもインフラ寄りの観点（インフラ障害との相関、SLO管理）と一気通貫で見たい場合に強みが出ます。

Weights & Biases Weave（実験管理連携）

Weights & Biases（W&B）がLLMアプリ向けに提供する観測・評価製品です。元々ML実験管理で広く使われている基盤の延長で、モデル学習・ファインチューニング・評価データセットとLLMアプリの観測を同じUI上でつなげます。社内に既にW&Bを使う研究／データチームがある場合は強い選択肢です。

05.選定の考え方（提供形態 × 運用環境）

ツール選定は「機能比較で1番のものを選ぶ」のではなく、次の3点で逆算します。2軸4象限で自社の現在地を確認すると判断が早くなります。

• OSS／SaaSの提供形態
• セルフホスト／マネージドの運用環境
• 既存スタック（LangChain利用／Datadog利用／OTel整備済み）との整合

この図は「左上が良くて右下が悪い」という評価図ではなく、選定軸を可視化するだけのものです。Datadogが既に全社で動いているなら、Datadog LLM Observabilityを追加して観測対象を増やす方が運用負担は小さくなります。逆に、医療・金融・公共などで個人情報や機微情報を扱うなら、LangfuseやArize Phoenixをセルフホストする方向が安全です。

06.実運用シナリオ：いつ・どこを開いて・何を判断するか

3本柱・5軸・7ツールが揃っても、運用側がそれらをいつ開き何を判断材料にするかが言語化できていないと、「ダッシュボードはあるが見ていない」状態になりがちです。本節では本番運用で頻出する4つのシナリオを「開く画面／見る数字／取るアクション」の順に具体化します。3本柱と5軸が実際にどう手と画面に落ちるかの動作イメージを掴むのが目的です。

シナリオ1：ユーザーから「回答が違う」と報告された

目的：誤回答の根本原因（検索ミスか LLM の解釈ミスか）を切り分け、修正と再発防止までの最短経路に乗せる。
結果：従来 1 日かかっていた原因特定を 30 分台に圧縮し、修正コミットからカナリアリリースまでを数時間で完結させる。同じケースが再発しないよう評価データセットも 1 件強化される。

ユーザーが thumbs down を押し、コメントで「契約条項Aの内容が間違っている」と報告。観測ツール側ではこのフィードバックがトレースIDに紐づいて記録されます。担当者は Traces 一覧で該当 ID を開き、1リクエストの span 構造（RAG検索 → LLM呼び出し → 後処理）をたどって、次の3点を確認します。

• RAG が取得した文書チャンクの中身
• LLM に渡した最終プロンプト全文（システムプロンプト＋取得チャンク＋ユーザー入力）
• LLM の出力

これで「検索が正しい文書を引けていない」「文書は正しいが LLM の解釈が異なる」のどちらかに切り分けられます。修正後は同じ入力をリプレイ（LangSmith／Langfuse の playground 機能）して改善を確認し、評価データセットにこのケースを追加して回帰検知の対象にします。

シナリオ2：月次コストが想定の2倍に膨らんだ

目的：請求書を見てから慌てるのではなく、コスト膨張の原因軸（機能・モデル・ユーザー）を特定して打ち手を一意に決める。
結果：プロンプト圧縮・モデルルーティング・出力長制限・レート制限のどれを当てるかが決まり、月次コストの傾向を翌月の予算計画に折り込める。

請求書または週次コストダッシュボードで気づくパターンです。コスト分解画面を開き、機能タグ別／モデル別／ユーザー別の積み上げで「どの軸で膨らんでいるか」を特定します。よくある内訳は次の4つです。

• 特定機能のコンテキスト肥大（RAGチャンク数の過剰）
• 想定より高いモデルへの誤ルーティング
• 入力に対して出力が長すぎる
• 上位1%の重いユーザー（bot 的利用を含む）

原因軸が決まれば、プロンプト圧縮・モデルルーティング修正・出力長制限・レート制限など打ち手がほぼ一意になります。事後対応ではなく月次予算の閾値アラートまで設定しておくと、請求書を見て気づく事態を避けられます。

シナリオ3：プロンプト変更／モデル切替の安全性を確認したい

目的：新旧の差を「感覚」ではなく数値で比較し、品質劣化のあるリリースを本番に出さない。
結果：カナリアリリース判断（5% → 25% → 100%）が定量根拠で出せるようになり、退化ケースが評価データセットに蓄積されて回帰検知の精度が上がっていく。

「GPT-4o → より新しいモデルへ切替えたい」「システムプロンプトを刷新したい」というタイミングは、評価（Evaluation／Datasets）画面の出番です。事前に用意した固定の正解集（数十件で十分）に対し、新旧両バージョンを並走実行し、次の観点で比較します。

• 事実一致率／出典一致率（品質）
• トーンの適切さ（運用観点）
• 1リクエスト単価（コスト）
• p95 レイテンシ（遅延）

主要指標が劣化していなければカナリアリリース（5% → 25% → 100%）に進み、退化したケースは正解集に追加して次回以降の回帰検知対象にします。これで「リリース判断」と「回帰検知」が同じデータ基盤の上で回り、属人化を避けられます。

シナリオ4：p95レイテンシが急に悪化した

目的：「全体が遅い」のではなく「どの span が遅いか」を特定し、打ち手を局所化する。
結果：原因が RAG／LLM／外部ツールのどこかに切り分けられ、ウォームアップ追加・モデル切替・タイムアウト調整など最小修正でユーザー体感速度を戻せる。

本番デプロイ直後、ユーザーから「最近遅い」と報告。p95 が 2 秒 → 8 秒に悪化しました。レイテンシ分布のダッシュボードを開き、遅いトレース上位 N 件を取得します。1トレース内のどの span（RAG検索／LLM呼び出し／外部ツール）が遅いかを見れば、原因は次のどれかに切り分けられます。

• ベクトル検索のインデックスウォームアップ漏れ（デプロイ後の初回コールドスタート）
• LLM 側のレイテンシ悪化（モデル切替・プロバイダ側の混雑）
• 外部 API のタイムアウト／リトライ多発

ストリーミング応答なら初トークン到達時間（TTFT）を別途見ると、体感速度の悪化原因が見えやすくなります。原因 span が決まれば、ウォームアップ追加・モデル切替・タイムアウト調整・並列化など打ち手に進めます。

日次／週次／月次の運用ルーチン例

シナリオを場当たりで処理するのではなく、「誰がどの頻度で何を見るか」を決めると改善ループが安定します。BtoB の LLM アプリで現実的に回るルーチンの一例を整理します。

このルーチンが回り始めると、ダッシュボードが「眺める対象」ではなく「次のアクションを決める材料」になります。観測ツールを入れて数字を出すこと自体は数日でできますが、誰がどの頻度で見て、その数字をどう改善ループに繋ぐかを決めるところで運用の質が分かれます。

07.実運用で得られる効果（代表的なパターン）

s-06 のシナリオを継続的に回した先で、どんな効果が現れるかを 4 パターンに整理します。ここに挙げる数字は LangSmith／Langfuse／Datadog の公式ブログとカンファレンス発表で繰り返し言及されるレンジを、自社プロジェクトの参考目安として整理したものです。実数は機能内容・トラフィック規模・初期品質で大きく変動するため、絶対値ではなく改善幅のオーダーとして読んでください。

これらは「ツールを入れたら自動で起きる効果」ではなく、観測ツール × 評価データセット × 改善ループの 3 点セットが回り始めてから現れる効果です。最小構成でも 3 ヶ月程度の継続運用が前提になります。 06-5 の運用ルーチンと合わせて、定例的な改善サイクルを設計するのが現実的な進め方です。

個別の公開ケーススタディは Langfuse Customers／ LangChain Customer Stories／ Datadog LLM Observability Blogなどで公開されています。自社の機能規模・業界に近い事例を選んで読むと、当てはめ判断がしやすくなります。

08.導入工程と落とし穴

BtoBでLLMオブザーバビリティを立ち上げるときに、PoCから本番に持ち上げる段階で見落とされやすい点を整理します。実装手順そのものは各ツールの公式ドキュメントに従いますが、運用設計として外しがちな視点を先に把握しておくと検討の手戻りが減ります。

評価データセット設計やプロンプト改善の具体は プロンプトベストプラクティス に寄せます。観測ツールが揃っても、評価対象のデータと改善ループが無ければ「数字を見ているだけ」になりがちで、運用側の意思決定に結びつきません。

09.よくある質問（FAQ）

10.まとめ

LLMオブザーバビリティは、AI（ChatGPT、Claude、Geminiなど）を業務で使うアプリケーションの「品質と費用が説明できる」状態を作る運用設計です。観測対象はトレース・メトリクス・評価の3層で、APMの延長では届かない確率的な品質次元を継続的に見られるようにします。2025年以降のOpenTelemetry GenAI Semantic Conventionsで、ベンダー横断の互換性も整理されつつあります。

2026-05時点での主要ツールは、LangSmith・Langfuse・Arize Phoenix・Helicone・OpenLLMetry・Datadog LLM Observability・W&B Weaveの7つに整理できます。「機能比較で1番」を選ぶのではなく、提供形態（OSS／SaaS）と運用環境（セルフホスト／マネージド）に既存スタックを重ね、自社の現在地から逆算して選ぶのが現実的です。評価データセット・PII対策・サンプリング設計の3点は、ツール選定と並行して早めに着手すると運用が落ち着きます。