2026年6月15日、Azure Databricksの汎用AI関数であるai_queryが一般提供（GA）になりました。今回の中心的な変更は、SQL構文の刷新ではなく、ai_queryがプレビュー段階から正式提供へ移行したことです。SQLやPythonから、対応するAIモデルを直接呼び出す仕組みを本番ワークロードへ採用しやすくなりました。(Microsoft Learn)
既存の利用者に対する強制的なコード移行や期限は、2026年6月15日付の公式情報では案内されていません。ただし、本番利用を始める前に、Databricks Runtime、SQL Warehouse、リージョン、モデル権限、エラー処理、料金監視を確認する必要があります。
Azureの新機能・変更点：Azure Databricksのai_queryが一般提供へ
今回の変更点を先に整理すると、次のとおりです。
| 確認項目 | 2026年6月15日以降の状況 |
|---|---|
| 提供ステータス | ai_queryが一般提供（GA）に移行 |
| 主な用途 | SQLまたはPythonからAIモデルを呼び出す |
| 対応ワークロード | 対話的な推論、テーブルに対するバッチ推論 |
| 対応モデル | Databricksホストモデル、プロビジョニング済みモデル、カスタムモデル、外部モデル |
| 強制移行 | 公式情報では案内なし |
| 移行期限 | 公式情報では案内なし |
| 料金 | AI推論の利用量に応じて記録・課金される |
| 管理者の確認事項 | リージョン、ネットワーク、モデル権限、利用量監視 |
公式リリースノートで明示された変更はai_queryのGA化です。新しい関数名への置き換えや、既存SQLの一律変更は発表されていません。(Microsoft Learn)
なお、ai_query単体がGAになったことと、Azure DatabricksのすべてのAI FunctionsがGAになったことは同じではありません。タスク特化型関数や関連機能は、それぞれのリファレンスで提供ステータスを確認してください。(Microsoft Learn)
ai_queryとは何か
ai_queryは、Azure DatabricksのModel Servingエンドポイントを呼び出し、AIモデルの応答をSQLの戻り値として受け取る関数です。
基本構文は次のとおりです。
ai_query(endpoint, request)endpointにはモデルを提供するエンドポイント名、requestにはプロンプトやモデルへの入力を指定します。エンドポイントは同じワークスペース内に存在する必要があり、呼び出し元には対象エンドポイントのCAN QUERY権限が必要です。(Microsoft Learn)
たとえば、問い合わせテーブルの各行をAIモデルで要約するといった処理を、通常のSQL列操作に近い形で実行できます。
タスク特化型AI Functionsとの違い
Azure Databricksには、ai_summarizeやai_classify、ai_extractなど、用途が決まったAI関数も用意されています。
| 比較項目 | タスク特化型AI Functions | ai_query |
|---|---|---|
| 向いている用途 | 要約、分類、抽出、翻訳など定型処理 | 独自プロンプトや複雑な処理 |
| モデル指定 | 関数側で管理されることが多い | 対応モデルやエンドポイントを指定 |
| 出力制御 | 比較的簡単 | responseFormatなどで細かく制御可能 |
| カスタムモデル | 原則として用途が限定される | カスタムモデルや外部モデルを利用可能 |
| 運用負荷 | 小さい | モデル選定や出力検証が必要 |
Databricksは、目的に合うタスク特化型関数がある場合、まずそちらを検討することを推奨しています。モデル、プロンプト、パラメーター、出力形式を細かく制御したい場合にai_queryを選ぶのが実務的です。(Microsoft Learn)
今回の変更で影響を受ける利用者
Databricks SQLを利用するデータ分析担当者
SQLだけで、テーブル内の文章に要約、分類、情報抽出などのAI処理を適用できます。
ただし、SQL関数になったからといって、通常の文字列関数と同じ感覚で全件処理を始めるのは危険です。AI推論では処理時間と利用料金が発生するため、最初は対象行を限定して結果を検証してください。
バッチ処理を管理するデータエンジニア
ai_queryは、Databricks Workflows、Lakeflow Spark Declarative Pipelines、Structured Streamingなどの処理に組み込めます。AI Functions側で並列化、再試行、スケーリングが管理されるため、データを小さなバッチへ手動分割するより、まとまったクエリとして渡す方法が推奨されています。(Microsoft Learn)
Azure Databricksの管理者
管理者は、次の項目を確認する必要があります。
- 対象ワークスペースのリージョン
- SQL Warehouseの種類
- Azure Private Linkの設定
- Model Servingエンドポイントの権限
- 利用可能な基盤モデル
- Unity Catalogのモデル権限
- AI推論の利用量とコスト
特に、ユーザーがSQLを実行できても、Model Servingエンドポイントや基盤モデルの権限が不足しているとai_queryは失敗します。
すでにプレビュー版を利用している組織
既存コードを直ちに書き換える必要はありません。ただし、GA化を機に、プレビュー時の検証用設定をそのまま本番へ持ち込んでいないか見直す必要があります。
具体的には、低いRuntimeバージョン、Classic SQL Warehouse、エラー時に全体停止するSQL、利用量を追跡できない共有エンドポイントなどが確認対象です。
利用前に確認すべき設定と要件
公式リファレンスでは、ai_queryの利用条件として次の項目が示されています。(Microsoft Learn)
| 確認項目 | 判断基準 | 失敗しやすいポイント |
|---|---|---|
| SQL Warehouse | SQL Classicでは利用不可 | 古いWarehouseをそのまま使用している |
| Pro SQL Warehouse | Azure Private Linkが必要 | ネットワーク設定を確認せず実行する |
| Databricks Runtime | 15.4 LTS以上を推奨 | 15.3以下で処理が遅くなる |
| 本番バッチ処理 | 公式パイプライン手順では15.4 LTS以上が要件 | 開発環境と本番環境のRuntimeが異なる |
| リージョン | AI FunctionsとModel Servingの対応地域であること | Azure Databricks自体の対応地域と混同する |
| エンドポイント | 対応モデルが読み込まれていること | モデル名だけを指定し、対応地域を確認しない |
| 権限 | エンドポイントにCAN QUERYが必要 | SQLテーブルの権限だけを確認する |
| カスタム・外部モデル | 対応するModel Servingエンドポイントが必要 | エンドポイントを作成せず直接モデル名を指定する |
Databricksホストの基盤モデルでは、事前構成されたエンドポイントを利用できるため、通常は利用者が独自にエンドポイントをプロビジョニングする必要はありません。一方、カスタムモデルや外部モデルを利用する場合は、対応するModel Servingエンドポイントを作成します。(Microsoft Learn)
日本リージョンでは地域差に注意する
公式の地域対応表では、ai_queryのバッチ推論はJapan Eastに掲載されていますが、利用するモデルや設定によってはクロスジオルーティングが必要です。Japan Westには対応マークが掲載されていません。リージョンを選ぶ際は、Azure Databricksの提供地域ではなく、地域対応表の「ai_query（batch inference）」列を確認してください。(Microsoft Learn)
データ所在地に制約がある組織では、クロスジオルーティングを有効化してよいかを、セキュリティ部門や法務部門と確認してから利用する必要があります。
Unity Catalogのモデル権限も確認する
Foundation model Unity Catalog permissionsを有効にしている環境では、system.aiスキーマや個別モデルに対するEXECUTE権限によって、利用可能なDatabricksホストモデルを制限できます。
管理者がsystem.aiスキーマから既定のEXECUTE権限を削除すると、許可を再付与していないモデルへのAI Functions呼び出しは直ちに停止します。エンドポイント権限だけでなく、モデル側のUnity Catalog権限も確認してください。(Microsoft Learn)
日本語版ページのプレビュー表記に注意する
2026年6月15日更新の英語版リリースノートと関数リファレンスではai_queryがGAとされています。一方、2026年5月29日更新の日本語版リファレンスには、パブリックプレビューの表記が残っています。
提供ステータスが食い違って見える場合は、更新日が新しい英語版ページとリリースノートを確認してください。(Microsoft Learn)
ai_queryの基本的な使い方
次の例では、サポート問い合わせの本文をAIモデルで要約します。
SELECT
ticket_id,
ai_query(
'databricks-gpt-oss-120b',
CONCAT(
'次の問い合わせを日本語で80文字以内に要約してください。',
'\n本文: ',
message
)
) AS summary
FROM main.support.tickets
WHERE message IS NOT NULL
LIMIT 100;モデル名は例です。実際に利用できるモデルは、ワークスペースのリージョンやモデルの提供状況によって異なります。Databricksは、大規模なバッチ処理ではバッチ推論向けに最適化されたDatabricksホストモデルを選ぶことを推奨しています。(Microsoft Learn)
開発時はLIMITで行数を絞り、出力品質、処理時間、エラー率、利用量を確認してから対象を広げるのが安全です。
大量処理ではfailOnErrorを設定する
failOnErrorの既定値はtrueです。この状態では、モデルエンドポイントのエラーによってクエリが停止する可能性があります。
大量の行を処理する場合は、failOnError => falseを指定し、成功した行と失敗した行を分けて保存します。
WITH inference AS (
SELECT
ticket_id,
ai_query(
'databricks-gpt-oss-120b',
CONCAT(
'次の問い合わせを日本語で80文字以内に要約してください。',
'\n本文: ',
message
),
failOnError => false
) AS result
FROM main.support.tickets
WHERE message IS NOT NULL
LIMIT 100
)
SELECT
ticket_id,
result.response AS summary,
result.errorMessage AS error_message
FROM inference;failOnError => falseでは、応答とエラーメッセージを含むSTRUCTが返ります。モデルエンドポイント由来の行単位エラーは分離できますが、すべての種類のエラーを無視できるわけではありません。構文エラーや権限エラーなどでは、クエリ全体が失敗する場合があります。(Microsoft Learn)
主なオプション引数
| 引数 | 用途 | 主な注意点 |
|---|---|---|
returnType | カスタムモデルの戻り値型を指定 | モデルスキーマを推論できない場合に指定 |
failOnError | 行単位のモデルエラーを結果へ含める | Databricks Runtime 15.3以上 |
modelParameters | 温度や最大トークン数などを指定 | 値は行ごとではなく定数として指定 |
responseFormat | JSONやDDL形式で出力スキーマを指定 | 15.4 LTS以上、チャット基盤モデル向け |
files | 画像データをモデルへ渡す | JPEGまたはPNGに対応 |
responseFormatを利用すると、自由文ではなく、後続のSQL処理で扱いやすい構造化データを返せます。画像入力ではREAD_FILESのcontent列をfiles => contentとして渡します。(Microsoft Learn)
既存環境の更新・移行で確認すること
プレビュー版からGA版へ移行する場合
公式情報では、専用の移行コマンドや必須のSQL書き換えは示されていません。そのため、既存コードは次の順番で検証します。
- 開発環境のRuntimeを15.4 LTS以上へそろえる
- SQL Classicを利用していないか確認する
- 本番と同じリージョン、権限、ネットワークで少量テストする
failOnError => falseを追加して失敗行を記録する- AIの出力を既存の期待値と比較する
- 推論結果とエラーメッセージを別列で保存する
- 利用量を確認してから全件処理へ切り替える
GA化は、同じプロンプトに対して常に同一の文章が返ることを保証するものではありません。モデルの変更、パラメーター、入力内容によって結果は変化するため、正解データを用いた回帰テストを用意しておくと安全です。
REST API処理から移行する場合
既存のREST API呼び出しを、必ずai_queryへ移行する必要はありません。
テーブルの各行へ一括でAI推論を適用する処理では、ai_queryに置き換えることで、認証処理やリクエストの並列化を簡素化できます。一方、低遅延API、独自の再試行制御、複雑な会話状態が必要なアプリケーションでは、既存APIの方が適している場合があります。
置き換えを判断するときは、次の3点を同じデータで比較してください。
- 出力品質
- 全件処理にかかる時間
- 1件または1バッチ当たりの実利用量
モデルの廃止は別に確認する
ai_queryがGAになっても、指定している基盤モデルが恒久的に提供されるとは限りません。モデルごとに提供リージョンや廃止時期が異なるため、モデル名をSQLへ直接埋め込む場合は、設定テーブルやジョブパラメーターから変更できる設計が安全です。(Microsoft Learn)
料金と利用量の確認方法
ai_queryのGA化は無料化を意味しません。AI Functionのバッチ推論コストは、請求システムテーブル上でMODEL_SERVING製品のBATCH_INFERENCEとして記録されます。(Microsoft Learn)
次のSQLで、ワークスペースごとの利用量を確認できます。
SELECT
usage_date,
usage_metadata.endpoint_name AS endpoint_name,
SUM(usage_quantity) AS usage_dbu
FROM system.billing.usage
WHERE workspace_id = '<workspace-id>'
AND billing_origin_product = 'MODEL_SERVING'
AND product_features.model_serving.offering_type = 'BATCH_INFERENCE'
GROUP BY
usage_date,
usage_metadata.endpoint_name
ORDER BY
usage_date DESC,
usage_dbu DESC;system.billing.usageを利用するには、システムテーブルを参照できる環境と権限が必要です。Model Servingエンドポイントへ用途や部門を示すカスタムタグを設定すると、そのタグが請求システムテーブルへ引き継がれ、プロジェクト別の集計に利用できます。(Microsoft Learn)
料金超過を防ぐため、運用開始時は次の対策が有効です。
- 検証中は
LIMITで対象件数を制限する - 既に処理した行を再推論しない
- 成功結果をDeltaテーブルへ保存する
- 失敗行だけを再実行する
- 用途に合うタスク特化型関数がないか確認する
- エンドポイントやジョブへ管理用タグを設定する
- 日次のDBU利用量をダッシュボードで監視する
Databricks Runtime 16.1 ML以上では、クエリプロファイルから完了した推論数、失敗数、処理時間を確認できます。料金だけでなく、失敗率と処理速度も併せて監視してください。(Microsoft Learn)
移行期限や対応期限はあるのか
2026年6月15日付のリリースノートと関数リファレンスには、ai_queryの強制移行期限、旧構文の廃止日、利用者側の必須対応日は記載されていません。今回のGA化だけを理由に、既存処理を特定日までに変更する必要はありません。(Microsoft Learn)
ただし、次の期限は別に管理する必要があります。
- 使用中モデルの提供終了日
- Databricks Runtimeのサポート終了日
- 社内で許可されたモデルやリージョンの変更日
- プレビュー中の関連機能が変更される日
- ネットワークやセキュリティポリシーの適用日
関数のGA化とモデルのライフサイクルを分けて管理することが重要です。
ai_queryのGA化後に実施すべきこと
まず、現在のワークスペースが対応リージョンにあり、SQL WarehouseとDatabricks Runtimeが要件を満たしているか確認します。次に、実際の業務データを100件程度に絞り、出力品質、エラー率、処理時間、DBU利用量を測定してください。
検証結果に問題がなければ、failOnError、構造化出力、権限管理、コストタグを追加したうえで本番処理へ組み込みます。既にプレビュー版を利用している場合も、コードをそのまま本番扱いにするのではなく、GA時点の要件に沿って設定と運用監視を見直すことが確実です。
コメント