Datadog LLM Observability実装｜スパン設計と評価・コスト管理

LLMアプリが本番で誤った答えを返したとき、アプリケーションログだけでは原因にたどり着けません。どのツール呼び出しが空を返したのか、検索で拾った文書が的外れだったのか、モデルの出力そのものが崩れたのか。この切り分けを可能にするのがDatadogのLLM向け可観測性機能です。本記事では、7種のスパン種別の割り当て方、環境変数だけで始める計装、OpenTelemetryのGenAI規約との関係、評価機能の3方式、そして費用の伸び方と見送るべき条件を、2026年8月時点の公式ドキュメントをもとに実装目線で整理します。

まとめ：LLMアプリ計装で先に決めるスパン設計と費用上限の線引き

結論から置きます。コードに手を入れる前に決めるのは3点。処理のどこにどのスパン種別を割り当てるか、プロンプトと出力の本文をどこまで残すか、評価をどこまで自動で回すか。この3点が曖昧なまま自動計装を有効にすると、トレースは出るのに検索できないダッシュボードと、想定を超えた請求が同時に届きます。

スパン設計から述べます。自律的に次の行動を決めるループにだけagentを割り当て、順序が固定された処理はworkflowにしてください。全部をagentにすると、後から「ツール呼び出しが失敗した回数」を数えられなくなります。記録範囲も同じく先に決めます。個人情報や契約書の本文を扱うアプリで、入出力の全文保存を既定にするのは避けてください。

費用の入口は無料枠です。2026年8月時点の公式製品ページでは、Freeプランに月40,000 LLMスパン・保持15日、Proプランは月額160ドルで100K LLMスパンが含まれると案内されています。超過分はオンデマンド課金で、単価は非公開。だからこそサンプリング率と計装粒度を先に決めておく必要があります。根拠と例外は判断章に書きます。

LLM Observabilityが記録する7種のスパンとAPMトレースとの接続

この機能の中身は、LLMアプリ専用のスパン定義と、それを束ねるトレースです。通常のAPMトレースと同じ構造の上に、LLM固有の属性（モデル名・トークン数・入出力）が乗ります。まずスパンの種類を押さえると、以降の設計判断が速く進みます。

なお、公式サイト上の製品名は2026年8月時点で「Agent Observability」に切り替わりました。ドキュメントのURLパスや環境変数には llmobs の表記が残り、検索で見つかる日本語記事の大半は旧名称の「LLM Observability」で書かれています。同じ機能を指していると理解しておけば、名称差で迷いません。

llm・workflow・agent・toolなど7種のスパン種別の使い分け

SDKが定義するスパン種別は7つです。それぞれ記録される属性と、後から検索・集計できる軸が変わります。

割り当てで迷うのは agent と workflow の境目でしょう。判定基準は「次に何をするかをモデルが決めているか」の一点。プロンプトの結果でツールの呼び先が変わるなら agent、決まった順に呼ぶだけなら workflow です。RAGの検索部分は retrieval、前段のベクトル化は embedding に分けておくと、応答が遅い原因が検索側かモデル側かを一目で切り分けられます。

ml_appによるアプリ単位の分離とAPMサービスとの紐付け基準

スパンをどのアプリのものとして扱うかは DD_LLMOBS_ML_APP で決まります。ここに入れた名前が画面上の切り替え単位になり、評価の有効化やダッシュボードの絞り込みもこの単位で効きます。社内チャットボットと問い合わせ要約バッチを1つの名前に押し込むと、品質指標が混ざって使い物になりません。用途ごとに分けるのが既定解です。

すでにAPMを入れている環境では、LLMスパンが既存のトレースにぶら下がります。HTTPリクエストのスパンから、DBクエリと並んでLLM呼び出しが見える状態。この接続の有無で調査の速度がまるで変わるため、Webアプリに組み込む場合はAPM側の計装を先に済ませてください。製品全体の機能構成はDatadogとは何かで整理しています。

入出力とトークン数の記録範囲：どこまで本文を残すかの線引き基準

LLMスパンにはプロンプトと出力の本文を添付できます。障害調査では本文がないと話になりません。一方でそこには顧客の氏名も社内の未公開情報も入り込む。判断を言い切ります。取り扱いデータに個人情報が含まれる本番環境では、全文記録を全スパンの既定にしないでください。

現実的な設計は二段構えです。既定では入出力の先頭部分とトークン数・モデル名・エラー内容だけを残し、機微情報の検出はSensitive Data Scannerに任せる。そのうえで、品質改善のために本文が要る機能に限って全文記録を有効にします。スパン木をどう組むか、どの粒度で親子関係を作るかという製品非依存の設計論はエージェントトレーシングのスパン木設計にまとめました。

Python・Node.js・Javaでの計装手順と自動計装が効く範囲

導入の重さは言語で変わります。PythonとNode.jsは環境変数と起動オプションだけで動き始め、Javaはスパンの開始と終了を明示的に書く必要がある。以下、最小構成から順に見ていきます。

DD_LLMOBS_ENABLEDなど環境変数だけで始める最小構成の手順

公式ドキュメントに記載された対応版は、Pythonが3.7以降（ddtrace）、Node.jsが16以降（dd-trace）、Javaが8以降（dd-trace-java v1.51.0以降）です。2026年8月時点の記載であり、古い記事の版数をそのまま信じないでください。

1. アプリの実行環境に ddtrace または dd-trace を追加する
2. DD_LLMOBS_ENABLED に 1 または true を設定する
3. DD_SITE に契約しているサイト（例：us5.datadoghq.com）を指定する
4. DD_LLMOBS_ML_APP にアプリ識別名を入れる
5. Agentを経由しない場合のみ DD_API_KEY を渡す
6. Pythonは ddtrace-run、Node.jsは NODE_OPTIONS 経由で起動する

コードに直接書く方式もあります。Pythonなら LLMObs.enable()、Node.jsなら tracer.init() を初期化処理に置く形です。複数環境へ配る前提なら環境変数側に寄せたほうが、ステージングと本番でml_app名を切り替えるだけで済みます。

OpenAI・LangChain・Bedrock連携で自動的に埋まるスパン

主要なライブラリは自動計装の対象です。SDKが対応しているのは次の系統で、呼び出しをフックしてレイテンシ・エラー・トークン使用量を自動で記録します。

• OpenAI のクライアントライブラリ経由の推論呼び出し
• LangChain のチェーン・エージェント実行
• AWS Bedrock 経由のモデル呼び出し
• Anthropic のクライアントライブラリ経由の推論呼び出し

注意したいのは、自動計装が埋めるのは「モデルを呼んだ事実」までという点です。自社の検索ロジック、プロンプト組み立て、後処理のバリデーションは対象外で、何もしなければトレース上は空白になります。障害の多くはむしろこの空白部分で起きます。

デコレータとwrapによる手動計装：独自処理をスパン化する境界

空白を埋める手段が手動計装です。Pythonは @llm や @workflow のデコレータ、もしくはコンテキストマネージャ。Node.jsは llmobs.wrap() で関数を包み、Javaはstart系のメソッドでスパンを開始してfinishで明示的に閉じます。

どこまで刻むかは、後から答えたい問いから逆算してください。「検索が遅いのか生成が遅いのか」を知りたいなら検索関数を retrieval で包めば足ります。1行ごとに task スパンを作ると、スパン数が跳ね上がって費用に直結するうえ、トレース画面も読めません。刻みすぎは損です。

Agent経由とagentless送信の選択基準とサンプリング率の設定

送信経路は2つあります。ホストやサイドカーで動くDatadog Agentを経由する方式と、DD_LLMOBS_AGENTLESS_ENABLED を有効にしてSDKから直接送る方式です。常時稼働のコンテナやEC2ならAgent経由、Lambdaのように起動と終了が短い環境やAgentを置けないマネージド環境ではagentlessを選びます。

保持するトレースの割合は DD_LLMOBS_SAMPLE_RATE で調整でき、既定値は1.0です。つまり何も設定しなければ全件が送られます。トラフィックが日に数万リクエストあるアプリでは、この既定のまま本番投入すると初月から無料枠を超えます。導入初期は全件で挙動を確かめ、定常運用に移す時点で下げる。この二段階が現実的です。

OpenTelemetry GenAI規約での取り込みとddtrace計装の選び分け

計装方法はDatadog独自のSDKだけではありません。OpenTelemetryで計装したアプリのスパンをそのまま取り込む経路が用意されており、この選択がベンダーロックインの度合いを決めます。

gen_ai属性のマッピングとOTLP経由で送るときの注意点

2025年12月1日公開の公式ブログによると、DatadogはOpenTelemetryのGenAIセマンティック規約 v1.37以降にネイティブ対応しました。gen_ai.request.model、gen_ai.provider.name、gen_ai.usage.input_tokens、gen_ai.usage.output_tokens、gen_ai.operation.name といった属性が、製品側のスキーマへ自動で対応づけられます。OTelで計装済みなら、コードを二重に書く必要はありません。

送信経路はOTLPエクスポータからの直送、Agent側のOTLP受信、Collectorまたはディストリビューション経由の3系統。どれを選ぶかで、プロセッサによるデータの絞り込みができるかどうかが変わります。経路ごとの構成と選定基準はDatadog OpenTelemetry連携の4方式で扱いました。規約のバージョンが古い計装だと属性名が一致せず、モデル名が空欄のスパンが並ぶ点にはご注意ください。

ベンダーロックインを避けたい場合の計装方針と乗り換え時の手戻り

判断を明確にします。監視基盤の乗り換え可能性を残したいなら、計装はOpenTelemetry側に寄せてください。SDK固有のデコレータで書いた計装は、他ツールへ移るときに全面的な書き換えが要ります。属性名が標準化されているOTel計装なら、送信先の設定変更で移行が済みます。

ただし全部がそれで済むわけではありません。マネージド評価、データセットと実験機能、注釈キューは製品固有で、OTel計装だけでは再現できません。評価まで含めて依存するなら、乗り換えコストを織り込んだうえで踏み込む。可視化だけが目的なら標準規約で計装しておく。この線引きを導入時に決めておくと、2年後の判断が楽になります。

評価機能の3方式：マネージド評価・LLM-as-a-judge・外部送信

可視化の次に来るのが品質評価です。評価の入り方は3つ用意されており、それぞれ運用の手間と自由度が違います。混ぜて使うのが通常の姿です。

マネージド評価で拾える品質と安全性の観点・有効化する単位の決め方

Datadog側が用意・運用する評価がマネージド評価です。公式ドキュメントで名称を確認できるものとしては、応答が入力と異なる言語で返っていないかを見るLanguage Mismatch（品質）と、機微情報や規制対象データの混入を検出するSensitive Data Scanning（セキュリティ）があります。製品ページではプロンプトインジェクションの検出にも言及があります。

有効化はml_app単位で行うため、ここでもアプリ名の切り方が効いてきます。全ml_appに全評価をかける運用は避けてください。評価そのものが処理を伴うため、対象を絞らないと費用と処理時間の両方が膨らみます。外部公開のチャットには安全性系を、社内バッチには品質系だけを、といった掛け方が実務的です。

独自評価をLLM-as-a-judgeで書くときの判定基準と誤判定対策

業務固有の正しさは既製の評価では測れません。見積書の金額が転記できているか、社内規程の条項番号が合っているか。こうした観点はカスタムのLLM-as-a-judge評価で書きます。設計上のコツは、判定を二値に落とすことです。「品質を5段階で採点せよ」という指示は、モデルが変わるたびに分布がずれて時系列比較ができなくなります。「条項番号が入力と一致していればtrue、していなければfalse」と書けば、判定のブレは小さい。判定理由も一緒に出力させ、falseのスパンだけを人が見るワークフローに寄せてください。全件を人が見る運用は数週間で破綻します。

データセットと実験機能でプロンプト変更前後の品質を比較する手順

本番トレースから代表的な入出力を抜き出してデータセット化し、プロンプトやモデルを変えた場合の結果を比較する機能が実験（Experiments）です。人手でのラベル付けを回す注釈キューも用意されています。

効くのはモデルの版が上がるタイミングです。同じプロンプトでも出力の傾向は変わる。過去の失敗ケースを集めたデータセットがあれば、切り替え前に再現テストを回して判断できます。逆にデータセットを作らないまま本番トレースを流しているだけでは、この機能の価値は出ません。導入から1か月ほど回した時点で失敗例を50件程度集めておくと、その後の運用が回り始めます。

費用が跳ねる条件と、Datadogを選ぶ場合・見送る場合の分岐

ここからが導入判断です。機能の多さと請求額は比例します。どこで費用が跳ねるのかを構造として理解し、自社に合わないケースを先に切り落とします。

無料枠40,000スパンとPro 100Kスパンの超過で費用が動く仕組み

2026年8月時点の公式製品ページの表記では、Freeプランが月額0ドルで最大40,000 LLMスパン、Proプランが月額160ドルで最大100K LLMスパン、いずれも保持は15日です。100Kを超えた分はオンデマンド課金となりますが、超過分の単価は公開ページに掲載されていません。予算を組む段階では営業窓口に確認する前提で考えてください。

ここで効いてくるのが、1リクエストで何スパン作るかという設計です。エージェントが3回ツールを呼び、2回検索し、4回モデルを呼ぶ構成なら、1リクエストで10スパン前後に達します。日に200リクエストでも月6万スパンです。無料枠は「1日1,300リクエスト分」ではなく「1日1,300スパン分」だと読み替えてください。コスト面の追跡には ml_obs.span.llm.total.cost などのメトリクスがあり、公開価格をもとに800を超えるモデルのトークンコストが自動算出されます。課金単位の全体像はDatadogの料金体系と費用が膨らむ課金単位で整理しています。

スパン数を抑える3つの手：サンプリング率・計装粒度・評価の範囲

抑制の手は3つあり、効き目の大きい順に並びます。第一が DD_LLMOBS_SAMPLE_RATE によるサンプリング。定常運用でトラフィックが読めているなら、0.1〜0.3程度まで下げても傾向は追えます。第二が計装粒度で、補助的な整形処理まで task で刻むのをやめるだけでスパン数は目に見えて減ります。第三が評価対象の絞り込みです。

ただしエラー時だけは全件残したいはずです。サンプリングを下げるときは、失敗したリクエストの記録が落ちないよう例外処理側で扱いを分ける設計にしてください。平常時のトレースは間引き、異常時は残す。この非対称な設計にしておくと、費用を下げても調査能力は落ちません。

Datadogを見送るべき条件：APM未導入・単発PoC・完全オンプレ

採用しないほうがよい場面を、条件付きで言い切ります。第一に、監視基盤がGrafanaやSplunkなど他社製で統一されており、DatadogのAPMを入れる予定がない場合。この製品の価値の大半は既存のAPMトレースと同じ画面でLLM処理を追えることにあり、単体で使うならLangfuseのようなLLM専用ツールのほうが導入も費用も軽く済みます。

第二に、数週間で終わる検証だけが目的の場合。無料枠で試すのは妥当ですが、評価やデータセットの設計に工数をかける段階ではありません。第三に、閉域網でSaaSへのデータ送信そのものが認められない環境。逆に、既にインフラとAPMをDatadogで見ており、LLM機能を本番の業務フローに組み込む段階なら、追加の運用負担がほぼ発生しない点で有力な候補になります。

AIエージェント本番運用の体制づくりと外部委託を挟む判断ライン

計装と評価が回り始めると、次の壁は運用体制です。誤判定を誰が見るか、プロンプト変更を誰が承認するか、モデルの版上げをいつ試すか。ツールを入れただけでは、この当番表は埋まりません。

自社に機械学習の運用経験者がいない状態で、いきなり本番の顧客対応にエージェントを置くのは避けたほうが賢明です。設計と初期運用を外部に預け、評価基準とデータセットが固まった段階で内製へ引き取る。この進め方なら失敗の傷が浅く済みます。一創ではAIエージェント開発として、トレース設計から評価の作り込み、本番移行後の運用引き継ぎまでを支援しています。既存の監視基盤を前提とした構成のご相談も可能です。

よくある質問

導入検討時に実際に問い合わせの多い論点を、5つに絞って答えます。

LLM Observabilityは無料で試せますか？

試せます。2026年8月時点の公式製品ページでは、Freeプランに月40,000 LLMスパン・保持15日が含まれ、評価やコンテキストの制限は設けられていないと案内されています。検証目的なら、この枠内でスパン構造の確認から評価の挙動までひととおり触れる範囲です。注意点はサンプリング率の既定値が1.0で全件送信になること。トラフィックのあるアプリにそのまま入れると枠を早く消費するため、検証は限定した環境で始めてください。

APMを入れていなくてもLLM Observabilityだけ使えますか？

使えます。SDKを入れて環境変数を設定すればLLMスパンは単体で送信でき、専用の画面でトレースも評価も確認できる状態になります。ただし得られる情報は狭い。APMがあれば、HTTPリクエストからDBクエリ、LLM呼び出しまでが1本のトレースにつながり、遅延の原因がモデル側かアプリ側かを同じ画面で切り分けられます。Webアプリに組み込むなら、APM計装を先に済ませておくほうが調査効率は上がります。

ddtraceのバージョンはどこまで上げる必要がありますか？

公式ドキュメントに記載された対応版は、2026年8月時点でPython 3.7以降、Node.js 16以降、Java 8以降（dd-trace-java はv1.51.0以降）です。自動計装の対応範囲は随時広がるため、OpenAIやLangChainの新しい版でスパンが出ない場合は、まずSDK側を上げて確認してください。

LangfuseやLangSmithとどう違いますか？

差が出るのは統合範囲です。LangfuseやLangSmithはLLMアプリに特化しており、プロンプト管理やトレース閲覧を軽量に始められます。一方このツールは、インフラメトリクス・ログ・APMトレースと同じ基盤の上にLLMスパンが乗る。既にDatadogで本番監視をしているなら、アラートも権限管理も既存の仕組みをそのまま使えます。監視基盤が別にあるなら、専用ツールのほうが軽く収まります。

プロンプトや出力の本文を記録しても大丈夫ですか？

取り扱うデータ次第です。個人情報や機密情報が入力に含まれる場合、本文をそのまま保存すると保管場所と保持期間が監査の対象になります。製品側にはSensitive Data Scannerによる機微情報の検出があり、マネージド評価にも該当データの混入を見るものが用意されています。実務的には、既定では本文を残さず、調査が必要な機能に限って有効化する二段構えにしてください。社内規程の確認を先に通しておけば、後の差し戻しを避けられます。

関連記事

• Datadog APM導入の実装手順：LLMスパンをぶら下げる土台となるAPM側の計装を扱っています。
• LLMOpsとは？MLOpsとの違いとトレース・評価・コスト管理：製品に依存しない工程全体の枠組みを整理しています。
• Langtraceとは？OpenTelemetry準拠のLLM監視：他ツールを比較検討する際の判断材料になります。
• Datadog運用のベストプラクティス：タグ設計とコスト抑制の考え方をまとめています。