DatadogのLLM Observabilityを触ってみた〜LLMアプリのブラックボックス化に怯えないために〜

こんにちは。クラウド事業部の遠見です。

本記事は、Datadogの「LLM Observability」を実際に検証したエンジニアが、内容をできる限り客観的に共有することを目的に作成しました。

AIが急速に発展し続ける中で、LLMアプリケーションの「見える化」は運用における重要な課題となっています。

そこで今回は、Datadogが提供する「LLM Observability」を実際に試してみました。

はじめに：Datadog×APC共催ランチセミナー開催
検証の背景
検証環境の構成
検証環境の構築
Datadog LLM Observability での確認
検証環境のクリーンアップ
検証コスト
まとめ
お知らせ

はじめに：Datadog×APC共催ランチセミナー開催

本編に入る前に、Datadogにご興味のある方へお知らせです。

4/21(火)に、Datadog×APC共催ランチセミナーを開催いたします！

参加者を募集していますので、監視・運用環境の改善や効率化に関心がある方は、ぜひ以下のリンク（X、Linkedin）から詳細をチェックしてみてください。

少人数の情シスでも「攻めのIT」は実現できる？
4/21(火) 11:00〜
【無料セミナー＠ Datadog Japanオフィス】豪華お弁当付き
AI×オブザーバビリティ×パートナー活用で、次世代クラウド運用の実践戦略を解説。
事例紹介やデモンストレーションも
※先着50名申込みはお早めにhttps://t.co/dDQzbeXFa8
— エーピーコミュニケーションズ公式🌈 (@apc_tweet) 2026年3月16日

www.linkedin.com

検証の背景

LLMを組み込んだアプリケーションを本番運用に乗せようとしているエンジニアなら、「実際にユーザーがどんなプロンプトを投げ、それに何秒かかっているのか、そしてコストはいくら跳ね上がっているのか」が見えないという怖さを感じているはずです。

Datadogの「LLM Observability」は、こうした「LLMのブラックボックス化」を、専用のトレースと分析基盤によって解消するソリューションです。

www.datadoghq.com

複雑なログ解析をすることなく、プロンプトの内容からトークン消費量、APIのレイテンシまでをリアルタイムに可視化し、一元管理することを可能にします。

導入することで、現場には例として以下のような「状態の変化」が訪れます。

作業の変化：ログからトークン数やコストを手動で集計する泥臭い作業がゼロになる
思考の変化：「遅延がP95で閾値を超えたらアラートが鳴る」という確信を持って運用できるようになる
状態の変化：チームがインフラの保守に追われるのではなく、本質的なプロンプト改善や精度向上に集中できるようになる

こうした「状態の変化」を実際に体験するため、今回はDatadogの「LLM Observability」を触ってみました。

具体的なセットアップの手順から、実際に得られた可視化データによって何が明らかになったのか、そのプロセスを一つずつ紐解いていきます。

検証環境の構成

ローカルPCのサンプルアプリから、Microsoft Foundryの「gpt-4o-mini」を呼び出し、そのトレースをDatadogへ直接送信する構成で検証しました。

検証環境の構築

Microsoft Foundryでのモデルデプロイ

Microsoft Foundryの「プロジェクト作成」については、以下のブログで紹介している内容と同じため、そちらをご参照ください。

techblog.ap-com.co.jp

プロジェクト作成

プロジェクト作成後、モデルをデプロイします。

[ビルド] > [モデル] > [デプロイ] > [基本モデルをデプロイする]を選択します。

今回は「gpt-4o-mini」を利用します。
検索に「gpt-4o-mini」を入力し、表示された「gpt-4o-mini」を選択します。

[デプロイ] > [カスタム設定]を選択します。

今回は、デプロイの種類で「標準（Standard）」を選択しました。

理由は、先ほど紹介した過去ブログでも同様だったのですが、私の環境ではグローバル標準だとTPM（1分あたりのトークン数）がデフォルトで0に設定されており、検証が滞ってしまうケースがあったからです。

[デプロイ]を選択します。

モデルが作成されると、デプロイ名（今回はデフォルトの「gpt-4o-mini」）が付いた画面に遷移します。

これで「Microsoft Foundryでのモデルデプロイ」は完了です。

Pythonスクリプトに必要な情報の取得

Microsoft Foundryの画面で先ほどデプロイした「gpt-4o-mini」を選択します。

右側に表示される以下の情報を取得します。

キー
コードサンプル

from openai import OpenAI

endpoint = "https://llm-o11y-tomi-resource.openai.azure.com/openai/v1/"
deployment_name = "gpt-4o-mini"
api_key = "<your-api-key>"

client = OpenAI(
    base_url=endpoint,
    api_key=api_key
)

completion = client.chat.completions.create(
    model=deployment_name,
    messages=[
        {
            "role": "user",
            "content": "What is the capital of France?",
        }
    ],
)

print(completion.choices[0].message)

次に、Datadogから以下の情報を取得します。

APIキー
- [Organization Settings] > [API Keys] > APIキーをコピー
Site URL
- URLから確認（datadoghq.com / ap1.datadoghq.com など）

Python仮想環境の構築

ローカル環境を汚さないために、Python仮想環境を構築することにしました。

仮想環境構築にはuvを利用しています（インストールが必要）。

任意の作業ディレクトリに移動し、以下を実行します。

uv init llm-o11y

作成されたディレクトリに移動し、必要なパッケージをインストールします。

# 作業ディレクトリに移動
cd llm-o11y

# パッケージの追加
uv add ddtrace openai python-dotenv

以降は、この環境で作業を実施します。

Pythonスクリプトの実装

作業ディレクトリに.envファイルを作成し、以下の環境変数を記載します。

AZURE_OPENAI_ENDPOINT=<Microsoft Foundryで控えたコードサンプルのendpoint>
AZURE_OPENAI_API_KEY=<Microsoft Foundryで控えたAPIキー>
AZURE_OPENAI_DEPLOYMENT=gpt-4o-mini

DD_API_KEY=<Datadogで控えたAPIキー>
DD_SITE=<Datadogで控えたSite URL>
DD_LLMOBS_ENABLED=1
DD_LLMOBS_ML_APP=<任意のアプリ名（今回は「foundry-llm-monitor」）>

Microsoft Foundryで控えたコードサンプルを基に、Pythonスクリプト側を作成します。

まず、必要なライブラリのインポートを追加します。
環境変数の読み込みと、Datadogへトレースを送信するためのライブラリが必要です。

import os
from dotenv import load_dotenv
from ddtrace.llmobs import LLMObs

次に、LLMObsを用いて計装します。
.envファイルから環境変数を読み込み、Datadogへの直接送信を有効にするための設定ブロックを追加します。

load_dotenv() 

LLMObs.enable(
    ml_app=os.environ["DD_LLMOBS_ML_APP"],
    api_key=os.environ["DD_API_KEY"],
    site=os.environ["DD_SITE"],
    agentless_enabled=True,
    integrations_enabled=False,
)

integrations_enabled=Falseについては、コネクションエラーを回避するために設定しています。

この設定がない状態でPythonスクリプトを実行したところ、データは正常にDatadogに送信されるものの、以下のエラーが出ました。

failed to send, dropping 1 traces to intake at http://localhost:8126/v0.4/traces: client error (Connect)

このエラーは、ライブラリが「ローカルで動いているはずのDatadog Agent」にデータを送ろうとして失敗したことを意味します。
今回の環境ではAgentを起動していないので、接続エラーが発生しました。

LLM Observability SDK Referenceに、LLM統合を使用しない場合はintegrations_enabledをfalseに設定するように記載がありました。

docs.datadoghq.com

integrations_enabled - default: true
optional - boolean
A flag to enable automatically tracing LLM calls for Datadog’s supported LLM integrations. If not provided, all supported LLM integrations are enabled by default. To avoid using the LLM integrations, set this value to false.

この指示に従い、integrations_enabled=Falseに設定したところ、Datadog Agentへの接続試行が止まり、エラーが表示されなくなりました。

最後に、コードサンプルでは直接コード内に書き込まれていたエンドポイントURLやAPIキーの情報を、os.environを使った環境変数からの取得に変更しています。

endpoint        = os.environ["AZURE_OPENAI_ENDPOINT"]
deployment_name = os.environ["AZURE_OPENAI_DEPLOYMENT"]
api_key         = os.environ["AZURE_OPENAI_API_KEY"]

それ以外は、元のコードサンプルをそのまま使用しています。

完成したPythonスクリプト（llm_test.py）は以下となります。

import os
from dotenv import load_dotenv
from openai import OpenAI
from ddtrace.llmobs import LLMObs

load_dotenv()

LLMObs.enable(
    ml_app=os.environ["DD_LLMOBS_ML_APP"],
    api_key=os.environ["DD_API_KEY"],
    site=os.environ["DD_SITE"],
    agentless_enabled=True,
    integrations_enabled=False,
)

endpoint        = os.environ["AZURE_OPENAI_ENDPOINT"]
deployment_name = os.environ["AZURE_OPENAI_DEPLOYMENT"]
api_key         = os.environ["AZURE_OPENAI_API_KEY"]

client = OpenAI(
    base_url=endpoint,
    api_key=api_key
)

completion = client.chat.completions.create(
    model=deployment_name,
    messages=[
        {
            "role": "user",
            "content": "What is the capital of France?",
        }
    ],
)

print(completion.choices[0].message)

スクリプト実行

uv run python llm_test.py

実行結果

PS ...\llm-o11y> uv run python llm_test.py
ChatCompletionMessage(content='The capital of France is Paris.', refusal=None, role='assistant', annotations=[], audio=None, function_call=None, tool_calls=None)
PS ...\llm-o11y>

Datadog LLM Observability での確認

[AI Observability] > [LLM Observability] > [Traces]を確認すると、データが取得できていることが確認できました。

この一覧画面では、入力プロンプト（INPUT）の「What is the capital of France?」と、その回答（OUTPUT）である「The capital of France is Paris.」が記録されていることがわかります。

このトレースを選択すると、詳細画面が表示されます。

遅延（Duration）、推定コスト（Estimated Cost）、合計トークン数（Total Tokens）、入力プロンプトと回答の記録が一画面で確認できます。

本番運用では意図しない回答や異常なレスポンスをここで発見できます。

[Overview]では、各項目の全体的な情報を一目で確認することが可能です。

[Summary]では、LLMリクエストの全体像やLLMの呼び出し回数（3回）に加え、エラー率、処理時間などの主要なメトリクスが一目で把握できます。

[Cost] では、複数回の実行それぞれのプロンプト、トークン数、コストが時系列で記録されています。
「どのプロンプトがコストを圧迫しているか」をこの画面で特定できます。

[Latency]では、遅延をパーセンタイル（P75/P90/P95）で可視化できます。
本番運用としては、「たまに遅いリクエストがある」という問題をP95で検知する、などが考えられます。

そのようなモニターを作成したい場合は、上部の「+ Create Monitor」ボタンを使い、簡単に設定することができます。

このような設定がスムーズに行えることは、本番運用で使う際の魅力的なポイントです。

検証環境のクリーンアップ

Microsoft Foundryは、Azureポータルからリソースグループ（今回はllm-o11y-tomi-resource が含まれるもの）を削除するだけでOKです。

ローカルのフォルダには、.envファイルにAPIキーが記載してありますので、忘れずに削除しましょう。

検証コスト

Azure側は、約0.03円でした。

Datadog上の推定コスト（0.0021¢ ＝約0.003円）と実行回数（Pythonスクリプトを何度も実行した）を踏まえると、想定内の金額となりました。

Datadog側は、トライアル期間のためコストは発生していません。

まとめ

今回は、Datadogの「LLM Observability」のハンズオンに挑戦しました。

これからLLMアプリケーションを本番環境へデプロイしようとしている状況なら、今すぐLLM Observabilityを導入する価値があります。

また、すでにLLMアプリケーションを導入しているが「プロンプトのブラックボックス化」「遅延」「コスト」「セキュリティ」などをチェックしたいという場合でも、LLM Observabilityは大きな力を発揮すると感じました。

お知らせ

弊社では、Datadogの導入支援から運用サポートまでをトータルでご支援するサービスを提供しています。
初期設計・エージェント展開・モニタリング設定・ダッシュボード構築まで、お客様のニーズに合わせた支援が可能です。
「自社だけでの導入が不安」「もっと効率的に監視環境を整えたい」という方は、ぜひお気軽にご相談ください。
www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。 www.ap-com.co.jp

本記事の投稿者: とみー
Datadogやオブザーバビリティに関する情報を発信しています。

APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。