Databricks Model Serving（LLM Chat）× AI Gateway 推論テーブルについて

投稿日 2026年1月22日
著者 azure-recipe-user
カテゴリー AIGateway
カテゴリー AIセキュリティ
カテゴリー Databricks
カテゴリー UnityCatalog
カテゴリー生成AI

はじめに

この記事は、DatabricksのMosaic AI Gatewayの推論テーブルについてまとめた記事になります。また、この記事は株式会社ナレッジコミュニケーションが運営するチャットボットと AIエージェント Advent Calendar 2025 の22日目にあたる記事になります！

運用が一気に楽になるログ基盤

Databricks の AI Gateway を Model Serving の LLM エンドポイント（Chat入力） の前段に置くと、推論リクエスト／レスポンスを Unity Catalog 配下の推論テーブル（Delta） に自動記録できます。

LLM アプリ運用で困りがちな、

何が投げられたか
何が返ってきたか
どれくらい遅かったか
どれくらい使われたか

を SQL でそのまま分析可能 になるのが最大のメリットです。

想定構成（Chat LLM Endpoint）

クライアント（アプリ / Notebook）
→ AI Gateway 経由
→ Databricks Serving Endpoint（LLM, Chat形式）

AI Gateway
└ 推論内容を Inference Table（Unity Catalog 管理）に保存

推論テーブルに保存されるもの（イメージ）

環境や設定によって差はありますが、基本的に 1 リクエスト = 1 行 で以下のような情報が残ります。

timestamp
実行時刻
endpoint_name
どの Serving Endpoint か
request
Chat messages などの入力（JSON）
response
モデルの返答（JSON）
status / status_code
成功・失敗
error
失敗時の内容
latency_ms
レイテンシ
usage
トークン数（prompt / completion / total など。取得できる場合）

ポイント
ログが「ファイル」ではなく テーブル（Delta） なので、
あとから JOIN / 集計 / 可視化が非常にやりやすい点が重要です。

何ができる？（LLM Chat 運用で刺さる用途）

1) 障害解析・監視

エラー率、タイムアウト増加の検知
p95 / p99 レイテンシの劣化を時系列で追跡
「特定の入力でだけ失敗する」ケースの切り分け

2) コスト・利用量の把握（トークン）

日別 / 機能別のトークン消費量
長文入力が増えていないか
出力が冗長化していないか

3) 品質改善（プロンプト・応答の振り返り）

「微妙な回答」の再現と原因調査（入力 → 出力を並べて確認）
よくある質問のテンプレ化
システムプロンプト改善の材料

4) 監査・トレーサビリティ

「いつ・誰の（※識別情報を持たせる設計の場合）・どの会話に・何を返したか」を追跡可能

まずやる：テーブルのスキーマ確認

列名は環境によって異なるため、最初にこれを実行するのが確実です。

DESCRIBE TABLE catalog.schema.inference_table;

				1
2

						DESCRIBE TABLE catalog.schema.inference_table;

すぐ使える SQL 例（Chat 入力を想定）

以下ではテーブル名を catalog.schema.inference_table とします。
列名は環境に応じて読み替えてください。

1) 直近のエラーを確認

SELECT
  timestamp,
  endpoint_name,
  status,
  status_code,
  error
FROM catalog.schema.inference_table
WHERE status <> 'OK'
ORDER BY timestamp DESC
LIMIT 100;


				
					
				1
2
3
4
5
6
7
8
9
10
11
12

						SELECT
  timestamp,
  endpoint_name,
  status,
  status_code,
  error
FROM catalog.schema.inference_table
WHERE status <> 'OK'
ORDER BY timestamp DESC
LIMIT 100;
 
 

					

			

2) endpoint 別の p95 レイテンシ

SELECT
  endpoint_name,
  date_trunc('hour', timestamp) AS hour,
  percentile(latency_ms, 0.95) AS p95_latency_ms
FROM catalog.schema.inference_table
GROUP BY 1,2
ORDER BY hour DESC, endpoint_name;


				
					
				1
2
3
4
5
6
7
8
9

						SELECT
  endpoint_name,
  date_trunc('hour', timestamp) AS hour,
  percentile(latency_ms, 0.95) AS p95_latency_ms
FROM catalog.schema.inference_table
GROUP BY 1,2
ORDER BY hour DESC, endpoint_name;
 
 

					

			

3) 日別のトークン消費（usage がある場合）

SELECT
  date_trunc('day', timestamp) AS d,
  sum(usage.total_tokens)       AS total_tokens,
  sum(usage.prompt_tokens)      AS prompt_tokens,
  sum(usage.completion_tokens)  AS completion_tokens
FROM catalog.schema.inference_table
GROUP BY 1
ORDER BY d DESC;


				
					
				1
2
3
4
5
6
7
8
9
10

						SELECT
  date_trunc('day', timestamp) AS d,
  sum(usage.total_tokens)       AS total_tokens,
  sum(usage.prompt_tokens)      AS prompt_tokens,
  sum(usage.completion_tokens)  AS completion_tokens
FROM catalog.schema.inference_table
GROUP BY 1
ORDER BY d DESC;
 
 

					

			

4) Chat の「最後の user 発話」をざっくり抽出

request に messages 配列が入っている想定の例です
（実データに合わせて JSON パスは調整してください）。

SELECT
  timestamp,
  endpoint_name,
  get_json_object(request, '$.messages[-1].role')    AS last_role,
  get_json_object(request, '$.messages[-1].content') AS last_content,
  get_json_object(response, '$.choices[0].message.content') AS assistant_reply
FROM catalog.schema.inference_table
ORDER BY timestamp DESC
LIMIT 50;


				
					
				1
2
3
4
5
6
7
8
9
10
11

						SELECT
  timestamp,
  endpoint_name,
  get_json_object(request, '$.messages[-1].role')    AS last_role,
  get_json_object(request, '$.messages[-1].content') AS last_content,
  get_json_object(response, '$.choices[0].message.content') AS assistant_reply
FROM catalog.schema.inference_table
ORDER BY timestamp DESC
LIMIT 50;
 
 

					

			

※ JSON パスや構造は実際のログ形式に依存します。
SELECT request FROM ... LIMIT 10; で中身を先に確認すると早いです。

運用上の注意（最低限）

PII / 機密情報
Chat の入力・出力がそのまま入る可能性あり
→ Unity Catalog の権限、マスキング、保持期間の設計が必須
ログ増加
推論回数に比例して増える
→ 監視用 / 評価用など用途別に保持期間を分けると管理しやすい

まとめ

LLM（Chat）を Model Serving で提供する場合、
AI Gateway の推論テーブルは「本番運用に必要なログを、最初から分析可能な形で貯める仕組み」になります。

エラー
レイテンシ
トークン消費
会話内容

をすべて SQL で横断的に追えるため、
監視・コスト管理・品質改善が一気に回しやすくなります。

この記事を書いた人

azure-recipe-user

記事一覧