LLM Observability

結論 - 数えるのはモデル呼び出しだけ

最初に押さえるべきは課金の数え方です。課金対象は LLM スパン、つまりモデル呼び出しを表すスパンだけで、周りのツール呼び出し (tool) やワークフロー (workflow)、検索 (retrieval) のスパンは対象外です (2026 年 8 月時点・出典: Datadog Pricing の FAQ)。1 リクエストの中でモデルを 1 回呼び、その前後で検索とツール呼び出しを 5 回行うアプリでも、数えられるのは 1 スパンです。周りの処理を細かくスパンに分けても料金は変わらないので、切り分けのためにトレースを詳しくすることをためらう理由がありません。名称にも 1 点注記します。公式ドキュメントのこの製品のページは 2026 年 9 月時点で「Agent Observability」の見出しで掲載されており、料金ページの SKU 名は「LLM Observability」のままです (出典: Agent Observability)。本記事は料金ページの名称で統一します。

APM のスパンと何が同じで、何が違うか

APM のスパンは「サービスの中の 1 処理」を表し、HTTP リクエストや DB クエリのような処理の種類は自動で決まります。LLM Observability のスパンも親子関係で 1 本のトレースを組む点は同じですが、スパンに「種別 (span kind)」という属性があり、その処理が LLM アプリの中で何の役割かを表します。公式ドキュメントが挙げる種別は 7 つです (2026 年 9 月時点・出典: Terms and Concepts)。

APM が「どのサービスのどの処理が遅いか」を答えるのに対し、この種別が答えるのは「遅いのはモデルの応答か、その前の検索か、ツール呼び出しか」です。同じトレースという器を使いながら、問いの単位がサービスから LLM アプリの工程に変わります。

1 本のトレースには 3 つの形がある

トレースの組み方は、根になるスパンの種別で 3 つに分かれます。LLM スパン 1 つだけの推論トレース、Workflow スパンを根にして LLM / Task / Tool / Embedding / Retrieval のスパンを入れ子にするワークフロートレース、Agent スパンを根にしてさらに Workflow まで入れ子にするエージェントトレースです (2026 年 9 月時点・出典: Terms and Concepts)。

最初の一歩は推論トレースで十分です。モデル呼び出しを 1 スパンで記録するだけで、入出力とトークンと遅延が揃います。「答えが遅い」の原因がモデルの外にあると分かった時点で、周りの処理を Tool や Retrieval のスパンとして足し、ワークフロートレースに育てます。課金対象は LLM スパンだけなので、この育て方で料金は増えません。

品質を数値にする評価は 3 つの入口を持つ

遅延とエラーは数えれば分かりますが、「答えの質」は数えられません。評価 (Evaluations) はこの穴を埋める仕組みで、個々のスパンに評価結果を紐づけ、その評価に至った入出力をスパンから直接たどれるようにします。入口は 3 つあります (2026 年 9 月時点・出典: Terms and Concepts)。

評価とは別に、本番トラフィックの入出力を話題ごとに自動で束ねる Patterns と、直近 1 週間の遅延やエラー率の外れ値をスパン名 / ワークフロー種別 / 話題の軸で浮かび上がらせる Insights も用意されています (出典: Agent Observability)。「利用者が何を聞いているか」と「どこで質が落ちたか」を、個別のログを読まずに掴めるのがこの層の価値です。

取り込みの経路は SDK / HTTP API / OpenTelemetry の 3 本

計装の経路は 3 本です。推奨は SDK で、Python 3.7 以上 / Node.js 16 以上 / Java 8 以上に対応し、いずれも自動計装と手動計装の両方が使えます。SDK を使えない言語や環境には HTTP API でスパンを直接送る経路があります (2026 年 9 月時点・出典: Instrumentation)。

すでに OpenTelemetry で計装している組織が気にする点を 1 つ添えます。計装ページの配下には OpenTelemetry 計装の専用ページがあり、OpenTelemetry 1.37 以上の GenAI セマンティック規約か OpenInference の規約に沿ったトレースなら、Datadog SDK を使わず OTLP エクスポーターの設定だけで送れると説明されています (2026 年 9 月時点・出典: OpenTelemetry Instrumentation)。評価やプロンプト追跡など対応範囲の細部は同ページで確かめてください。

料金は LLM スパンの数だけで決まる

料金は月額の枠と、枠を超えた LLM スパンの追加課金の 2 段です。Free は月 4 万 LLM スパンまで無料、Pro は月額の中に 10 万 LLM スパンが含まれ、超えた分は 1 万 LLM スパンごとの追加単価で加算されます。Pro の月額と追加単価はいずれも年契約 / 月契約 / オンデマンドの 3 形態で異なります (2026 年 8 月時点のプラン区分・出典: Datadog Pricing)。具体的な金額は同ページで確認してください。

月 30 万回モデルを呼ぶアプリなら、Pro の枠 10 万スパンを超える 20 万スパンが追加分で、月額は「Pro の月額 + 20 × (1 万 LLM スパンあたりの追加単価)」と読めます。検索やツール呼び出しの回数は計算に入りません。逆に 1 回の質問で内部的にモデルを 3 回呼ぶ設計なら、LLM スパンは 3 倍です。APM のホスト課金とは別の SKU で、料金全体での位置は料金体系の読み解きで確かめてください。

APM で足りるか、LLM Observability が要るか

LLM を呼ぶアプリなら必ずこの製品が要る、という話ではありません。知りたいことが「モデルの API を月に何回呼び、応答に何ミリ秒かかり、何回失敗したか」までなら、APM のトレースで外部 API 呼び出しとして見えます。LLM Observability が要るのは、問いが呼び出しの中身に入るときです。

判断の目安は、障害調査の場面を思い浮かべることです。「遅い」の調査がモデル応答時間の確認で終わるなら APM、「答えがおかしい」の調査を本番の入出力で行う必要があるなら LLM Observability です。Free の月 4 万 LLM スパンは、この判断を実測で下すための試用枠として十分な広さがあります。CPU やメモリの側から同じアプリを見る Continuous Profiler とは補完関係で、モデル待ちの時間はプロファイラには映らず、逆に埋め込み計算の CPU 負荷は LLM Observability には映りません。