はじめに
この記事は、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;
すぐ使える 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;
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;
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;
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;
※ JSON パスや構造は実際のログ形式に依存します。
SELECT request FROM ... LIMIT 10;で中身を先に確認すると早いです。
運用上の注意（最低限）
-
PII / 機密情報
Chat の入力・出力がそのまま入る可能性あり
→ Unity Catalog の権限、マスキング、保持期間の設計が必須 -
ログ増加
推論回数に比例して増える
→ 監視用 / 評価用など用途別に保持期間を分けると管理しやすい
まとめ
LLM（Chat）を Model Serving で提供する場合、
AI Gateway の推論テーブルは「本番運用に必要なログを、最初から分析可能な形で貯める仕組み」 になります。
- エラー
- レイテンシ
- トークン消費
- 会話内容
をすべて SQL で横断的に追える ため、
監視・コスト管理・品質改善が一気に回しやすくなります。