📚 参考書籍
※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。
『ゼロから触ってわかった！いまのDatabricks AIがわかる本 ― 機械学習、RAG、Agent、Lakebase、Databricks Apps― 』
Databricksでの プロンプト設計・RAG構築・モデル管理・ガバナンス を扱うAIエンジニアの入門決定版。
生成AIとデータエンジニアリングの橋渡しに必要な“実務の型”を体系化しています。
資格本ではなく、実務基盤としてAIを運用する力 を育てる内容です。
https://link.amazon/B0eKLGVSk
####『ゼロから触ってわかった！AI Agent Observability入門― MLflow・Databricksで実践するAIエージェントの評価・監視・安全性・説明可能性』
本書は、AI Agentを「作って動かす」だけでなく、その品質をどう観測し、どう評価し、どう守り、どう説明可能にするかを体系的に学ぶための入門書です。
https://link.amazon/B04VaTlR3
####『ゼロから触ってわかった！Databricks Agent Engineering実務入門 ～AI Gatewayでつなぎ、Agent Skillsで標準化・量産し、MLflowで運用する ～』
AI Gatewayでつなぎ、Agent Skillsで企業の仕事を標準化し、Pipeline Factoryで量産し、MLflowで評価・改善する。
その一連のライフサイクルを、データパイプライン開発という具体的な題材を通して理解することが本書のゴールです。
https://link.amazon/B03g0YUiI
Databricks AI Functions入門：ai_queryでSQL・PythonからLLMを呼び出す
1. ai_queryとは何か
ai_queryは、Databricks上のSQLやPythonからModel Serving Endpointを呼び出し、LLMやAIモデルの結果をデータ処理へ組み込むための汎用AI Functionです。
要約や分類など特定用途向けのAI Functionとは異なり、
- 利用するモデル
- プロンプト
- モデルパラメータ
- 出力形式
- エラー処理
を柔軟に指定できます。
2026年10月現在、Databricksは目的に合うタスク特化型AI Functionがある場合はそちらを優先し、より細かな制御が必要な場合にai_queryを利用することを推奨しています。
2. SQLの各レコードをLLMへ渡す
例えば問い合わせ内容を要約する場合は、次のように記述できます。
SELECT
inquiry_id,
message,
ai_query(
'system.ai.gpt-oss-120b',
CONCAT(
'次の問い合わせを100文字以内で要約してください。',
message
)
) AS summary
FROM inquiries;
このSQLでは、inquiriesテーブルの各行についてmessageがモデルへ渡され、結果がsummary列として返されます。
つまりLLMを、
「入力列 → AI処理 → 新しい列」
という通常のデータ変換と近い感覚で利用できます。
分類なら、
- 返品
- 配送
- 支払い
- その他
のような候補をプロンプトに指定し、レコード単位でカテゴリを生成できます。
3. Structured Outputで後続処理しやすくする
自由文を返すだけでなく、生成結果を後続処理で利用する場合はStructured Outputが重要です。
responseFormatを指定すると、LLMの出力を定義した構造へ合わせられます。
例えば、
SELECT ai_query(
'system.ai.gpt-oss-20b',
CONCAT('問い合わせからカテゴリと要約を抽出してください。', message),
responseFormat =>
'STRUCT'
)
FROM inquiries;
のように定義できます。
現在のai_queryでは、DDL形式だけでなく、text、json_object、json_schemaなどのレスポンス形式も利用できます。
AIの結果をテーブルへ保存する場合、自由文より構造化された出力の方が、その後のSQL処理や集計で扱いやすくなります。
4. modelParametersでモデル動作を調整する
modelParametersでは、Temperatureや最大出力トークン数などを設定できます。
SELECT ai_query(
'system.ai.gpt-oss-120b',
CONCAT('次の文章を簡潔に要約してください。', message),
modelParameters => named_struct(
'temperature', 0.1,
'max_tokens', 100
)
)
FROM inquiries;
分類や情報抽出のように結果の一貫性を重視する処理では、Temperatureを低くする方法があります。
ただし、利用可能なパラメータはモデルやEndpointによって異なるため、事前確認が必要です。
5. PythonのDataFrameからも利用できる
PySparkのDataFrameでもai_queryを利用できます。
[
df_out = df.selectExpr(
"inquiry_id",
"""
ai_query(
'system.ai.gpt-oss-120b',
concat('次の問い合わせを要約してください。', message)
) AS summary
"""
)
df_out.write.mode("overwrite").saveAsTable(
"catalog.schema.inquiry_summaries"
)
]
これにより、既存のPySparkパイプラインへLLM処理を組み込み、生成結果をDelta Tableへ保存できます。
6. 大量処理ではエラーとコストを設計する
ai_queryでは各レコードでモデル推論が行われるため、大量データでは処理時間とトークン利用量を意識する必要があります。
実務では、
- 未処理レコードだけ対象にする
- 空データを除外する
- 更新された行だけ再処理する
- 少数件で品質確認してから拡大する
- 生成結果を保存して重複実行を避ける
といった設計が重要です。
また、failOnError => falseを指定すると、一部レコードの推論が失敗しても、成功結果とエラーメッセージを行単位で取得できます。
大規模なバッチ処理では、失敗行だけを後から再実行できるようにしておくと運用しやすくなります。
2026年10月時点では、ai_queryはDatabricks Runtime 15.4 LTS以上が必要で、最新機能やパフォーマンス面では18.2以上が推奨されています。Classic SQL Warehouseでは利用できません。
ai_queryのポイントは、LLMを特別なアプリケーションから呼ぶのではなく、SQLやDataFrameのデータ変換処理の中へ直接組み込めることです。
AI処理をデータパイプラインの一部として扱うからこそ、プロンプトだけでなく、出力形式、失敗時の再処理、対象件数、コストまで含めて設計することが重要になります。