APC 技術ブログ

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

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

トップ > さくらのクラウド > さくらのAI EngineをDatadog LLM Observabilityで可視化してみた

さくらのAI EngineをDatadog LLM Observabilityで可視化してみた

さくらのクラウド さくらのAI Engine Datadog LLM Observability

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

  • 本記事は、「さくらのAI Engine」をDatadogの「LLM Observability」で可視化する検証を実施したエンジニアが、内容をできる限り客観的に共有することを目的に作成しました。
  • 本記事内の見解は執筆者個人のものであり、所属組織を代表するものではありません。

生成AIのビジネス活用が進む中で、「AIがいつ、どれくらいのコストで、どのような精度で動いているか」を把握するLLM Observabilityの重要性が高まっています。

今回は、「さくらのAI Engine」とDatadogの「LLM Observability」を組み合わせた構成を検証しました。

データ所在を国内で完結させ、日本の法規制やビジネス慣習に準拠したセキュアな監視環境をいかに構築するか、その実践的なステップを構想しながら検証を行いました。

目次

はじめに

国産クラウドへの想いと技術的ロマン

本題の技術検証に入る前に、1人のITエンジニアとして、最近の国内ITインフラの動向について少し触れておきたいと思います。

2026年3月27日、さくらのクラウドが国産クラウドとして初めて「ガバメントクラウド」に正式認定されました。

www.sakura.ad.jp

www.digital.go.jp

公表日：2026年3月27日
さくらのクラウドについて、すべての技術要件を満たしたことを確認できたので、2026年3月27日以降本番環境の提供が可能となります。

もちろん、巨額の投資を背景に進化し続けるメガクラウドと、単純な機能数やサービス網羅性で競い合うのは容易ではないかもしれません。
しかし、私がさくらのクラウドに寄せている期待は、単なる「国産推し」という感情論ではなく、日本の技術基盤を支える「重要なピース」としての実用性です。

特に、今回取り上げる「さくらのAI Engine」には、大きな可能性を感じています。

現在、日本社会におけるAI導入のネックのひとつに、海外への情報流出のリスクや処理プロセスの不透明さに対する「漠然とした不安」があると思います。
そんな中、国内法が適用され、データの所在が明確な「安心して使えるAIインフラ」の存在は、スペックの数字以上に大きな意味を持ちます。

現実的な「実用性」において、必ずしも世界最先端のベンチマークを競う必要はないと思っています。
それよりも、「日本独自のニーズに寄り添い、実務において十分に機能し、安心して託せる」こと、「モダンなAIのトレンドに振り回されるのではなく、地に足のついた『実用的なAI』として社会の発展に貢献していく」こと、そこに「技術的なロマン」を感じています。

今回の検証について

そんな「日本のためのAIインフラ」の実践的な運用を支えるべく、Datadogの「LLM Observability」を組み合わせた構成に挑戦しました。

現在、弊社はさくらインターネットとパートナー契約を締結しています。

www.ap-com.co.jp

また、Datadog社ともパートナーシップを結んでおり、その知見を活かした運用支援に力を入れています。

www.ap-com.co.jp

Datadog自体も日本リージョン（AP1）を提供しているため、さくらのクラウドと組み合わせることで、「データの所在を国内に限定した、高度な監視・分析基盤」を構築することが可能です。

すでにDatadogで既存インフラを監視している企業はもちろん、これから生成AIの導入にあたってセキュアなガバナンス体制を整えたいと考えている企業にとっても、有力な選択肢の一つになれば幸いです。

今回の構成とゴール

本ハンズオンでは、以下の構成でチャットアプリを構築し、その挙動を可視化することを目指します。

  • 実行環境: ローカルPC
  • LLM基盤: さくらのAI Engine
  • 監視プラットフォーム: Datadog LLM Observability
  • 特徴: データの流れを国内完結（さくら ＋ Datadog AP1）させることで、国内法規制への対応やエンタープライズ用途を意識する
  • 実行環境詳細
項目 バージョン
OS Windows 11 Home 25H2
Powershell 7.5.5
Python 3.12.4
uv 0.11.7
  • 構成図

  • ファイル構成
sakura-datadog-chat/
├─ .venv/  # Python仮想環境
├─ .env    # APIキーなどの機密情報（本番用）
├─ .env.example    # APIキーなどの機密情報（テンプレート）
├─ app.py  # バックエンド（Datadog、AI Engine通信）
├─ pyproject.toml  # プロジェクトの設計図
└─ static/
  └─ index.html  # フロントエンド（チャット画面のUI）

事前準備

さくらのAI Engineのアカウント作成

さくらのクラウドのアカウントは作成済みの想定です。

[さくらのクラウド ホーム] > [トップ] > [さくらのAI Engine]をクリックします。

[サービス約款の同意]が表示されます。

[プラン] > [基盤モデル無償プラン] > [契約する]をクリックします。

[契約履歴]にプランが表示されます。

さくらのAI Engineのトークン作成

[さくらのAI Engine] > [アカウントトークン]タブ > [アカウントトークンを作成]をクリックします。

任意のアカウントトークン名を入力し、[作成する]をクリックします。

[アカウントトークン作成完了]ダイアログで表示されたトークンをコピーしておきます。
コピーができたら、[閉じる]をクリックします。

[アカウントトークン一覧]から、作成したアカウントトークンをクリックすると、利用可能なモデル一覧と利用量のグラフが確認できます。

DatadogのAPIキー取得

Datadog AP1（Japan）のアカウントは作成済みの想定です。

[Datadogポータル] > 左下の[アカウント] > [Organization Settings] > [API Keys]をクリックします。
今回はデフォルトで作られているAPIキーを利用します。
APIキーをクリックし、コピーします。

環境構築

さくらのAI EngineはOpenAI API互換のため、既存のSDKをそのまま利用できるのが大きなメリットです。
base_urlを切り替えるだけで既存のOpenAIコードがそのまま動作します。

www.sakura.ad.jp

APIは、業界標準のOpenAI APIと互換性があるため、既にOpenAI APIをご利用の方はスムーズに移行できます。

今回利用するモデルは以下です。

用途 モデル 開発元
動作確認・デバッグ preview/Phi-4-mini-instruct-cpu Microsoft
本番デモ gpt-oss-120b OpenAI
本番デモ（国産モデル） llm-jp-3.1-8x13b-instruct4 LLM-jp（国立情報学研究所など）

Python仮想環境の構築

今回は、Python仮想環境で検証します。

uvを使ってプロジェクトを作成し、作成したプロジェクトのディレクトリに移動します。

# プロジェクト作成
uv init sakura-datadog-chat

# ディレクトリ移動
cd sakura-datadog-chat

今回利用するパッケージを追加します。

uv add fastapi uvicorn openai ddtrace python-dotenv
パッケージ 役割 今回の用途
fastapi WebAPIフレームワーク /api/chat エンドポイントを作る
uvicorn ASGIサーバー FastAPIを実際に動かすサーバー
openai OpenAI SDK さくらのAI Engine（OpenAI互換）への接続
ddtrace Datadog トレースSDK LLMのレイテンシ・トークン・エラーをDatadogに送信
python-dotenv 環境変数管理 .env ファイルからAPIキーを読み込む

動作確認（Datadog連携前）

test-app.pyを作成し、動作確認を行います。
チャットに送るメッセージには「LLM Observabilityについて教えて」と記載しています。

最初は　最も安価なpreview/Phi-4-mini-instruct-cpuモデルを利用してみます。

from openai import OpenAI

client = OpenAI(
    api_key="さくらのAI Engineのアカウントトークン",
    base_url="https://api.ai.sakura.ad.jp/v1"
)

response = client.chat.completions.create(
    model="preview/Phi-4-mini-instruct-cpu",
    messages=[
        {"role": "user", "content": "こんにちは！LLM Observabilityについて教えてください"}
    ]
)

print(response.choices[0].message.content)

test-app.pyを実行します。

uv run python test-app.py

出力結果は、以下のようになりました。
（長文だと画面上わかりにくいため、文章の改行を行っています）

..\sakura-datadog-chat> uv run python test-app.py
こんにちは！LLM、つまり大きな言語モデルの文脈では、Observabilityを指します。  
Observabilityとは、システムのクローゼットへのデバッグや管理を思い込む言い方です。  
プログラミングやシステムリーダーにおいて、それは能力を決定するために非常に重要です。  
それはシステム以上のものを見ることを可能にし、内部状態をベースラインになくなり、外部のパフォーマンスデータを除いてそれを観察することを可能にします。

大規模言語モデルにおけるObservabilityの観点からはjdbc、仮想チャットボット、その他AIサービスとの相互作用など、アプリケーションコンテキスト内でのモデルの挙動を追跡、監視、コントロールすることを意味します。  
これはクオリティ・オブ・サービス、モ #### 1 disappointing! もう一度計画してみてください

LLM Observabilityについて教えてください。

軽量モデルのため、日本語が少し不自然です。
また、出力も途中で終わってしまいました。

次に　gpt-oss-120bモデルを利用してみます。
test-app.pyの変更点は、modelの箇所のみです。

...
model="gpt-oss-120b",
...

出力結果は、以下のようになりました。
（膨大な出力があったため、「…」で省略しています）

..\sakura-datadog-chat> uv run python test-app.py
## LLM Observability とは？

LLM Observability（大規模言語モデルの観測性）は、LLM（ChatGPT、Claude、Gemini など）を本番環境で運用するときに、「何が起きているか」を可視化・測定・診断・改善する仕組み・手法の総称です。  
従来のシステム監視（CPU・メモリ・ネットワーク）に加えて、LLM 特有の以下の要素を観測対象にします。

| カテゴリ | 主な指標・データ | 目的 |
|---|---|---|
| 入力/出力ログ | プロンプト全文、モデル出力、温度・top‑p などのパラメータ | デバッグ、再現性、品質分析 |
| トレース | エンドツーエンドの呼び出しフロー（API → 前処理 → LLM → 後処理） | ボトルネック特定、遅延測定 |
| メトリクス | レイテンシ、スループット、エラー率、トークン消費量、コスト | SLA・SLO の管理、リソース最適化 |
| 品質評価 | 正確性 (accuracy)、ファクトチェック、ハルシネーション率、センチメント、バイアス指標 | モデル出力の信頼性確保 |
...

---

## なぜ LLM Observability が必要か？
...
## 観測性を構成する 5 つの柱
...
### 1. Instrumentation（計測コードの埋め込み）
...
### 2. Logging（入力/出力・メタデータの記録）
...
### 3. Tracing（エンドツーエンドのリクエストフロー）
...
### 4. Metrics（数値指標）
...
### 5. Evaluation & Alerting（品質評価・リアルタイムアラート）
...

LLM Observability は 「データ」＋「測定」＋「可視化」＋「フィードバック」 のサイクルを確立することです。  
このサイクルが整っていれば、以下が実現できます。

- インシデントの即時検知と高速復旧  
- 予算超過の未然防止  
- ユーザー体験（正確さ・安全さ）の継続的向上  
- 規制遵守（GDPR・HIPAA など）の証明  

ぜひ、上記のコンポーネントとベストプラクティスを自社システムに取り入れ、LLM の本格的な本番運用に備えてください。質問や特定のツールの導入支援が必要であれば、遠慮なくどうぞ！ 🚀

最後に、llm-jp-3.1-8x13b-instruct4モデルを利用してみます。
出力結果は、以下のようになりました。
（一部「…」で省略しています）

..\sakura-datadog-chat> uv run python test-app.py
こんにちは！LLM（Large Language Model）のObservabilityについて説明しますね。

### 1. Observabilityとは？
Observabilityは、システムやアプリケーションの動作を監視し、その状態やパフォーマンスに関するデータを収集・分析するプロセスを指します。これにより、問題が発生した際に迅速に対応し、システムの健全性を維持することができます。

### 2. LLMにおけるObservabilityの重要性
LLM（大規模言語モデル）は、自然言語処理（NLP）タスクにおいて非常に強力ですが、以下の理由からObservabilityが特に重要です：

- パフォーマンスの最適化: LLMの応答時間やリソース使用量を監視することで、ボトルネックを特定し、パフォーマンスを向上させることができます。
  
- エラー検出とデバッグ: モデルが出力する結果が期待通りでない場合、その原因を特定するためにログやメトリクスを分析します。

- リソース管理: メモリやCPUの使用量を追跡し、スケーリングの必要性を判断します。

- セキュリティ: 不正アクセスや異常な動作を検出するために、ログやイベントを監視します。

### 3. LLM Observabilityの要素
LLMのObservabilityを実現するためには、以下の要素が必要です：

#### a. ロギング
- モデルのトレーニング、推論、および運用の各フェーズで生成されるログを収集します。
- ログには、エラーメッセージ、警告、成功メッセージなどが含まれます。

#### b. モニタリング
- メトリクス収集: CPU使用率、メモリ使用量、ディスクI/Oなどのシステムメトリクスを収集します。
- パフォーマンス指標: 応答時間、スループット、エラーレートなどの指標を監視します。

#### c. アラート設定
- 異常検知: 特定のメトリクスが一定の閾値を超えた場合にアラートを発生させます。
- 通知: メールやチャットツールを通じて関係者に通知します。

#### d. データ可視化
- ダッシュボード: リアルタイムでシステムの状態を視覚的に表示するためのダッシュボードを作成します。
- レポート生成: 定期的にレポートを生成して、運用状況を把握します。

### 4. ツールと技術
LLMのObservabilityを実現するために使用される一般的なツールと技術には以下があります：

- Prometheus: オープンソースのモニタリングシステムで、メトリクスの収集とアラート設定が可能です。
- Grafana: データ可視化ツールで、Prometheusと連携してダッシュボードを作成します。
- ELK Stack (Elasticsearch, Logstash, Kibana): ログの収集、解析、可視化を行うためのツールです。
- OpenTelemetry: 分散トレースとメトリクス収集のためのオープンソースフレームワークです。

### 5. 実装例
以下は、簡単な実装例です：

1. ロギングの設定
...

2. PrometheusとGrafanaの設定
   - Prometheusの設定ファイル (`prometheus.yml`) にメトリクスのエンドポイントを追加します。
   - GrafanaでPrometheusデータソースを設定し、ダッシュボードを作成します。

### まとめ
LLMのObservabilityは、システムの健全性を維持し、パフォーマンスを最適化するために不可欠です。適切なロギング、モニタリング、アラート設定、データ可視化を行うことで、問題発生時に迅速に対応できるようになります。適切なツールと技術を選定し、実装することで、効果的なObservabilityを実現できます。

何か具体的な質問があれば、どうぞお知らせください！

gptよりも、シンプルにまとめられた出力結果が得られました。

本番検証のWebアプリ作成

今回の検証では、環境構築の手間を最小限に抑えつつ、データの流れをシンプルにするため、「エージェントレスモード」を採用しています。

通常、Datadogへのデータ送信は常駐プログラムであるDatadog Agentを経由しますが、今回はPythonライブラリ（ddtrace）から直接DatadogへHTTPS送信を行います。
これにより、ローカル環境からでも追加のインフラ構築なしで、セキュアに「国内完結」のオブザーバビリティを試すことが可能です。

環境変数の設定

.env.exampleをコピーして.envを作成します。

copy .env.example .env

.envに以下の環境変数を設定します。

# さくらのAI Engine
SAKURA_API_KEY=さくらのAI Engineのアカウントトークン

# Datadog（東京リージョン AP1）
DD_API_KEY=DatadogのAPIキー
DD_SITE=ap1.datadoghq.com
DD_LLMOBS_AGENTLESS_ENABLED=1
DD_LLMOBS_ML_APP=sakura-llm-app  # 任意の名前

バックエンド（app.py）のポイント

DatadogのLLM Observabilityを「さくらのAI Engine」で活用するためのポイントは、大きく分けて以下の4点です。

Datadog LLM Observabilityの初期化

今回の設定ではDatadog Agentを介さず（エージェントレス）、Pythonライブラリ（ddtrace）が直接HTTPSでDatadogのAPIエンドポイントへデータを飛ばします。
そのため、agentless_enabled=Trueとしています。

LLMObs.enable(
    ml_app=os.getenv("DD_LLMOBS_ML_APP", "sakura-llm-app"),
    agentless_enabled=True,
)

接続先を「さくら」に切り替える

OpenAI SDKをそのまま使い、base_url を指定するだけで接続先を切り替えられます。

# さくらのAI Engine クライアントの初期化
sakura_client = OpenAI(
    api_key=os.getenv("SAKURA_API_KEY"),
    base_url="https://api.ai.sakura.ad.jp/v1",  # さくらのエンドポイントを指定
)

LLM操作を「スパン」として定義する

LLMObs.llm コンテキストマネージャを使うことで、AIの推論処理をひとつの「意味のある単位（スパン）」としてDatadogに記録します。

with LLMObs.llm(
    model_name=req.model,
    model_provider="sakura-ai-engine", # 任意のプロバイダー名を指定可能
    name="sakura-chat",
) as span:
    # この中でAI Engineを呼び出す
    response = sakura_client.chat.completions.create(...)

トークン数やメタデータを「アノテーション」する

推論完了後、実際に消費したトークン数や入出力の内容をLLMObs.annotateで付与します。
これにより、Datadog上でコスト、精度、エラー率などの詳細な分析が可能になります。

LLMObs.annotate(
    span=span,
    input_data=[{"role": "user", "content": req.message}],
    output_data=[{"role": "assistant", "content": answer}],
    metrics={
        "input_tokens": response.usage.prompt_tokens,
        "output_tokens": response.usage.completion_tokens,
        "total_tokens": response.usage.total_tokens,
        "latency": latency_ms / 1000,
    },
)

通常、ddtraceライブラリは OpenAI本家への通信を自動的に識別して計測を行いますが、今回はさくらインターネットのカスタムエンドポイントを使用しているため、自動識別が難しい場合があります。
そこで、このように明示的にannotateを実行することで、確実にメトリクスを送信する手法をとっています。

フロントエンド（static/index.html）のポイント

チャットUIは static/index.html に配置します。

主な機能は以下です。

  • ダークテーマのチャット画面
  • モデルをセレクトボックスで切り替え（gpt-oss-120b / llm-jp-3.1 / preview/Phi-4-mini-instruct-cpu）
  • 返答の下に「Datadogトレース」バッジ（クリックでスパン詳細を表示）
  • 右サイドバーにリクエスト数・平均レイテンシ・総トークン数・エラー数をリアルタイム集計

サーバー起動・動作確認

以下を実行します。

uv run uvicorn app:app --host 0.0.0.0 --port 8000 --reload

ブラウザで想定通りのUIが表示されるか確認します。

http://localhost:8000

【検証】チャットUIから各モデルの出力を確認する

モデルをpreview/Phi-4-mini-instruct-cpuに切り替えて、「LLM Observabilityとは？」と送信します。

右上の選択欄では、preview/Phi-4-mini-instruct-cpuモデルが選ばれています。
中央のチャット回答欄では、「LLM Observabilityとは？」という問いに対して回答が返ってきています。
画面右側の「DATADOG 統計」と下部の「Datadogトレース」欄では、レイテンシ、トークン数、エラー数がUIに反映されています。

このモデルは回答に5分近くかかっています。
名前の通りCPU推論であるため、GPU推論がいかに高速かを逆説的に証明する結果となっています。

モデルをgpt-oss-120bに切り替えて、「LLM Observabilityとは？」と送信します。

このモデルは120b（Billion）という巨大なパラメータ数を持っており、20秒で長文を返してきています。

モデルをllm-jp-3.1-8x13b-instruct4に切り替えて、「LLM Observabilityとは？」と送信します。

3つのモデルの中で圧倒的にレスポンスが早いです。
チャットUIとして非常に快適な速度感であり、実用性が高いことがわかります。

【検証】Datadogダッシュボードで情報を確認する

実際にチャットを動かすと、Datadogの「LLM Observability」で「さくらのAI Engine」がどのように可視化されているかを確認できます。

[Datadogポータル] > [AI Observability] > [LLM Observability] > [Overview]をクリックします。

今回情報を取得した[sakura-llm-app]をクリックします。

Summary（全体俯瞰）

「Summary」では、アプリ全体の健康状態を示しています。

  • 主要メトリクスの把握
    • エラー率（0%）、応答速度（Duration p95: 20.24s）、トークン使用量（11.1K）がひと目で分かります。
  • 傾向の可視化
    • 右側の時系列グラフから、特定の時間帯（11:55や12:00前）にリクエストがあったことや、その時のスパン（実行単位）が記録されていることが分かります。

Cost（個別の対話解析）

個別のトレースIDの詳細画面です。

  • 上部の概要
    • Duration: 20.4s → レイテンシ20.4秒
    • Total Tokens: 9.06K → 合計9,060トークン消費
    • Model Calls: 2 → 2回のLLM呼び出し
  • 左のスパンツリー
    • sakura-chat → ワークフロー全体
    • OpenAI.createChatCompletion → 実際のAPI呼び出し
  • 「何を聞いて、何と答えたか」の可視化
    • 「Input Message」（LLM Observabilityとは？）と「Output Message」（それに対するAI Engineからの詳細な回答内容）がログとして記録されています。
  • 詳細なメタデータ
    • 画面下部の「Metadata」に、今回指定したモデル名（gpt-oss-120b）が記録されており、どのモデルがこの回答を出したのかが分かります。
  • 実行環境の証明
    • Tagsを見ると、language:python や ddtrace.version が確認でき、ローカルのPythonアプリから正しくデータが飛んでいることが分かります。

Cost（コストと計算資源）

「Cost」タブ（実際にはトークン量）の画面です。

  • プロバイダーの識別
    • 「sakura-ai-engine」 という名前で集計されています。
    • これはコード内の model_provider で指定した値が正しく反映されている証拠です。
  • トークン配分の分析
    • Input Tokens（75）に対して Output Tokens（4.46K）が圧倒的に多いことが分かります。
    • 回答が長文になったことがデータからも読み取れます。

Latency（応答性能の分析）

「Latency」タブの時系列グラフとリストです。

  • モデルごとの性能差
    • preview/Phi-4-mini-instruct-cpuは平均4.98分、gpt-oss-120bは平均20.4秒、llm-jp-3.1-8x13b-instruct4は平均4.4秒など、モデルごとの応答速度の差がランキング形式で可視化されています。
  • ボトルネックの特定
    • sakura-chat というスパンの中に OpenAI.createChatCompletion が含まれており、時間のほとんどがAI Engine側での生成待ちであることがわかります。

【検証】さくらのAI Engineの利用量を確認する

「さくらのAI Engine」管理画面の利用量（Usage）を確認します。

Datadog側のデータとこの画面を突き合わせることで、「インフラ側の記録」と「アプリケーション側の観測」が一致していることが分かります。

まとめ

さくらのAI EngineとDatadogのLLM Observabilityを組み合わせることで、手軽に「中身の見えるAI環境」を構築できました。

特に複数モデルの使い分けにおいて、トークン消費量やレイテンシを同一画面で比較できるメリットは大きく、実運用における「コスト性能比」を判断する強力な武器になります。

推論の裏側を可視化できれば、ブラックボックス化への不安やコスト膨張のリスクもコントロールできます。
この「見える安心感」こそが、LLMの本番運用におけるインシデント検知やコスト防止につながると感じました。

「国内でのデータ完結」という安心感と、「グローバル水準のガバナンス」を両立する。
このハイブリッドな構成が、コンプライアンスや規制が厳しい国内の現場でAI実装を前に進めるための、最も現実的な第一歩になるのではないか。

そんな仮説を持って進めた今回のハイブリッド検証が、皆さんの開発における何かのヒントになれば幸いです。

お知らせ

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

本記事の投稿者: s_tomi