Databricks Predictive AI Functions、予測をSQLへ移行。ただし真の試練は信頼性
Databricksは、予測および関連する機械学習タスクをSQL、ダッシュボード、Genieに直接組み込む、5つのPredictive AI Functionsをベータ版としてリリースした。同社によれば、アナリストは個別のモデルを構築・保守しなくても、予測に関する問いに答えられるようになるという。この構想は根強いボトルネックを狙う一方で、責任の所在をデータサイエンティストからプラットフォームとその利用者へ移すものでもある。
今回のリリースには、改良版のai_forecastと4つの新機能が含まれる。対象は要因分析、異常検知、数値予測、分類だ。このためDatabricks Predictive AI Functionsは、売上予測にとどまらず、ビジネスチームがデータ部門に繰り返し持ち込むさまざまな問いに対応する。
重要な対立軸は、Databricksと単一の競合データウェアハウスとの競争ではない。セルフサービス型の予測と、従来のモデル開発プロセスとの競争である。Google BigQueryとSnowflakeもすでに機械学習をデータウェアハウスの利用者に近づけており、SQLベースの予測自体は新しいものではない。Databricksは、より限定された管理型関数群によって、通常の分析業務でも利用できるほどプロセスを身近にできると見込んでいる。
この利便性には、より大きな責任が伴う。予測が正常に実行されても、誤ったビジネス判断につながる可能性はある。基盤となるモデルをプラットフォームが管理する場合でも、チームはデータ品質、評価期間、不確実性、市場環境の変化を理解しなければならない。
Databricks Predictive AI Functions、5つのMLタスクをSQLに変換
今回のリリースでは、アナリストが日常的にデータを確認する場所で呼び出せる5つの管理型関数により、複数のカスタムモデリング依頼を置き換える。
Databricksは2026年10月14日にベータ版を発表した。同社のPredictive AI Functionsの発表によると、これらの関数はSQL、AI/BIダッシュボード、そしてプラットフォームの対話型分析インターフェースであるGenieで利用できる。
5つの関数は、それぞれ異なる分析上の問いに対応する。ai_forecastは時系列を将来に向けて予測する。ai_top_driversは、指標の変化に関連するセグメントを特定する。ai_detect_anomaliesは、想定範囲から外れた観測値を検出する。
残る2つの関数は、一般的な予測タスクを担う。ai_predict_valueは需要や配送時間などの連続値を推定する。ai_predict_classは、想定される結果や顧客セグメントなどのカテゴリを割り当てる。
Databricksは各関数を、中央で保守される機械学習モデルに支えられたネイティブなSQL操作として位置付けている。アナリストはデータを別のモデリング環境にエクスポートする代わりに、クエリやパイプライン内に出力を組み込める。また、ダッシュボードを通じて結果を公開したり、自然言語の質問を通じてGenieに関数を呼び出させたりすることもできる。
この配置は重要だ。多くの予測依頼は、日常的なレポーティングの中から生じる。経営幹部が売上グラフを見て、次にどこへ向かうのかを尋ねる。オペレーションマネージャーが急増に気付き、それが異常かどうかを問う。プロダクト責任者がコンバージョンの低下を見て、どのセグメントが変化をもたらしたのかを尋ねる。
こうした問いは、しばしばデータサイエンスチームへのチケットになる。チームは対象を定義し、データを準備し、手法を選定し、検証し、提供プロセスを構築しなければならない。表現するのに数秒しかかからない依頼でも、技術的な作業には数日を要することがある。
Databricksは、その工程をクエリへ圧縮しようとしている。同社の例では、ニューヨーク市のタクシー乗車データセットを用い、乗車件数を予測し、異常な観測値を特定し、既存の分析画面内で予測に関する問いに答えている。
改良版のai_forecastは、事前学習済みのTransformerベース時系列基盤モデルを使用する。時系列基盤モデルは、顧客固有の系列を受け取る前に、多数のデータセットから繰り返される時間的パターンを学習する。Databricksによれば、この設計はタスク固有のモデルチューニングを必要としない予測を支援する。
この関数は、予測を変化させ得る情報も受け取る。祝日設定は繰り返し現れるカレンダー効果の表現に役立つ。ターゲットに影響することが分かっている関連変数を意味する外生共変量には、プロモーション、価格、マーケティング支出などを含められる。
この組み合わせにより、今回のリリースはダッシュボード上に置かれた対話型アシスタントより広いものとなる。これらの関数は、ガバナンスの効いたデータに対して分析操作を実行し、他のSQLステップで利用できる構造化出力を返す。
ただし、ベータ版という表記は重要だ。Databricksは管理型予測レイヤーを導入しているのであって、モデル開発の終わりを宣言しているわけではない。実務上の問いは、標準化された関数がどこまでカスタムプロジェクトを置き換えられるほど有効かという点にある。
当面の圧力は分析チームとデータサイエンスチームにかかる
Databricksは、どの予測依頼にカスタムモデルがふさわしく、どれをアナリストの日常業務にすべきかを組織に判断するよう促している。
データサイエンティストがこのワークフローからいなくなるわけではない。その役割は、評価、ガバナンス、難しいケースへと移る。管理型関数が繰り返し発生する予測を処理するなら、専門家は部署ごとに似たパイプラインを再構築する時間を減らせる。
この変化は、分析エンジニアにも圧力をかける。変換処理やビジネスロジックと並んで予測出力を含む、本番クエリへの責任を担うようになる可能性がある。それは、信頼できるデータプロダクトの定義を広げる。
従来のSQLチェックでは、レコードが到着しているか、列が想定どおりの型か、変換が正しく計算されているかを確認する。予測関数には追加のテストが必要となる。チームは、予測誤差、予測区間、誤検知、ドリフト、そしてビジネスセグメントごとの性能を検証しなければならない。
ビジネスアナリストには別の圧力がかかる。予測へより速くアクセスできる一方で、モデル出力が何を意味するかについて、より的確な判断も必要になる。見慣れたグラフの隣に表示されているからといって、その結果が信頼できるとは限らない。
四半期売上予測を考えてみよう。過去のパターンは季節性を捉えられるかもしれないが、市場からの撤退計画によって、そのパターンは無関係になる可能性がある。プロモーションは販売量を増やす一方で、利益率を下げる場合がある。入力データに現れない突然の供給制約を、予測が見逃すこともある。
外生共変量が役立つのは、チームが適切に選択・維持した場合に限られる。外生共変量は、過去の期間と予測期間の両方で利用可能でなければならない。過去の売上と高い相関を持つ変数でも、将来には入手できない、あるいは知り得ないことがある。
要因分析にも関連する課題がある。関数は、指標の変化に最も寄与したセグメントを特定できる。しかし、それだけでそのセグメントが変化の原因だったことが自動的に示されるわけではない。寄与と因果関係は異なる問いに答える。
分類と値予測には、それぞれ固有の安全策が必要だ。学習ラベルには、古いビジネスルールや不平等な扱いが埋め込まれている可能性がある。欠損値の予測は、特定のグループに対する根拠が弱いことを隠しながら、精密に見える場合がある。
したがって今回のリリースは、基準そのものではなく、依頼の待ち行列を変える。単純な依頼はセルフサービスへ移行できる一方、曖昧な問いや影響の大きい問いには、なお専門家によるレビューが必要となる。
この区分は、結果の重大性に基づくべきだ。初期計画に使う大まかな人員配置予測と、与信、医療、雇用の判断を変える予測とでは、リスクが異なる。呼び出しやすさが同じだからといって、承認プロセスまで同じであるべきではない。
チームには所有権に関するルールも必要になる。どのソーステーブルが適切か、出力をどう監視するか、いつ結果をエスカレーションするかを、誰かが決めなければならない。その構造がなければ、セルフサービス型予測はボトルネックを解消するどころか、一貫性のない回答を増やしかねない。
有用な運用モデルでは、探索と業務利用を分ける。アナリストはパターンを素早く探索し、その後、価値あるクエリをレビューとテストを経て昇格させられる。これにより、すべてのアドホックな予測を本番の根拠として扱うことなく、スピードを維持できる。
今回のリリースは、データプラットフォームへの期待も高める。予測が通常のSQLの一部になるなら、管理者は従来のクエリと並行して、アクセス、コスト、リネージ、再現性を管理しなければならない。
これらの結果を利用するナレッジワーカーにとっても、文脈は不可欠だ。前提、対象期間、評価履歴が伴わない予測は、異議を唱えることが難しい。チームは、こうした判断を分析に結び付けて保持するために、検索可能なknowledge baseを利用できる。
管理型予測がカスタムモデルのパイプラインに挑む
中心となる競争は、即時かつ標準化された回答と、ある組織固有の問題に合わせて構築される時間のかかるモデルとの間にある。
カスタムの予測パイプラインは制御性を提供する。データサイエンティストは、アルゴリズムを選び、特徴量を設計し、損失関数を定義し、ビジネス目標に合わせてモデルをチューニングできる。また、疎なデータ、製品ローンチ、構造的変化、特殊なカレンダーに対する専門的な処理も構築できる。
その柔軟性にはコストがある。モデルを追加するたびに、開発と保守の作業が増える。チームは依存関係、コンピューティング環境、定期的な再学習、監視、結果を提供するためのインターフェースを管理しなければならない。
Databricks Predictive AI Functionsは、このトレードオフを反転させる。プラットフォームがモデリング手法を選択し、維持する。ユーザーはデータとパラメータを渡し、使い慣れた分析インターフェースを通じて結果を受け取る。
一般的な依頼では、標準化が価値を持ち得る。複数の部署が個別のバージョンを依頼する代わりに、同じ管理型実装を利用できる。ダッシュボードから呼び出される関数とGenieを通じて呼び出される同じ関数は、共通の分析経路に従うべきである。
中央での保守は、すべての顧客にパイプラインの再構築を強いることなく、モデル改善を提供できる可能性もある。この利点は、Databricksが安定した動作を維持し、変更を文書化し、チームが新しいバージョンを評価するのに十分な情報を提供することに依存する。
予測関数はその仕組みを示している。事前学習済みモデルは、幅広い時系列の集合から学習したパターンを出発点とする。その後、従来のデータセットごとの学習を行わずに、新しい系列から予測を生成できる。
この手法は、しばしばゼロショット予測と呼ばれる。「ゼロショット」とは、その予測タスクに特化して学習することなく、モデルが過去の学習を対象系列に適用することを意味する。
Databricksによれば、改良版の関数は季節性とトレンドを自動的に認識する。また、祝日効果と共変量にも対応しており、汎用的な過去パターンでは見落とし得るビジネス固有の要因に対処する。
同社はfev-benchを用いてai_forecastを評価し、有力なクラウドデータウェアハウスと従来の同社関数を上回るタスク勝率を報告した。fev evaluation libraryは、再現可能な予測タスク、確率的予測、共変量、複数の誤差指標をサポートしている。
Databricksは、報告した勝率をスケーリングされた分位点損失で定義している。分位点損失は、複数の確率水準にわたって予測を評価し、観測結果からの距離に応じて予測にペナルティを与える。スケーリングにより、単位の異なる系列間で比較しやすくなる。
ただし、ローンチ投稿には、その結果をすべてのワークロードへ一般化するために十分な公開情報がない。読者には、正確なタスクセット、競合製品の構成、入力制約、モデルバージョン、完全な誤差分布が必要となる。勝率だけでは、個々の勝ち負けの大きさは分からない。
この区別は重要です。予測の品質は領域によって異なるためです。モデルは多くのベンチマーク課題で高い性能を示しても、小売業者の短命な商品やメーカーの断続的な需要には苦戦する可能性があります。
事業目標が汎用的な統計指標と異なる場合、カスタムパイプラインには依然として優位性があります。在庫チームは平均予測誤差の最小化よりも、欠品回避を重視するかもしれません。別のチームでは、需要を過大評価することにより大きなコストを割り当てる可能性があります。
マネージド機能は、そうしたチームにとってもベースラインとして役立ちます。専門家がカスタム手法と比較できる即時の結果を提供するからです。特注モデルが、保守負担を正当化できるほどマネージドのベースラインを上回れないなら、標準化の魅力は高まります。
これが今回のリリースを最も的確に解釈する方法です。Databricksはすべての予測モデリングを置き換えようとしているのではありません。データウェアハウス内で利用できる最低限の能力を引き上げ、カスタムプロジェクトに付加価値の証明を求めているのです。
BigQueryとSnowflakeは、これがプラットフォーム競争であることを示している
Databricksは、機械学習を独立したソフトウェアプロジェクトではなく、ネイティブなデータ操作として感じられるものにしようとする、より広範な競争に加わっています。
Googleはすでに、SQLを通じてBigQueryにモデル学習と推論を導入しています。そのプラットフォームは、予測、異常検知、回帰、分類、寄与分析など、さまざまな機械学習タスクをカバーしています。
BigQueryは、TimesFMを基盤とするマネージド予測機能も提供しています。Googleの組み込みTimesFMドキュメントでは、ユーザーが別個のモデルを作成せずに単変量および多変量の予測を行えると説明されています。
BigQueryの機能は、複数の時系列を識別するための識別子、予測区間、コンテキストウィンドウの制御、将来の共変量をサポートします。Googleは、より細かな制御を必要とするチーム向けに、従来型のモデル構築手段も維持しています。
Snowflakeは、そのプラットフォーム内で予測機能と異常検知機能を提供しています。文書化されているGBM異常モデルは、観測値を予測と比較し、勾配ブースティングマシンを用いて外れ値を特定します。
こうした競合アプローチには、重要な共通の方向性があります。クラウドデータプラットフォームは、管理下にあるデータを別のスタックへ移動させずに、顧客が分析、予測、行動できるようにしたいのです。
違いは、モデル品質、使いやすさ、ワークロード要件、統合性、透明性に現れるでしょう。チームは、あるベンダーのベンチマークだけから優劣を推測するのではなく、同じ事業時系列を複数のプラットフォームでテストすべきです。
すでにSQLウェアハウス、ダッシュボード、Genieを利用している顧客にとって、Databricksには統合面での優位性があります。同じ機能が、対話形式の質問を再現可能なSQLや可視化されたダッシュボード出力につなげられます。
Googleは、BigQuery MLが成熟した幅広いモデル構築ワークフローを持つ点を訴求できます。これらのワークフローにより、SQL実務者は単一のマネージド機能よりも多くの制御を保持しながら、複数のモデルタイプを学習・評価できます。
Snowflakeも、機械学習機能を自社のデータ環境に統合しています。その異常検知ワークフローは、分析出力を提供しつつも、モデル開発プロセスの大部分をデータウェアハウスプラットフォームが隠せることを示しています。
その結果は、単純な機能チェックリストではありません。「forecast」と呼ばれる機能であっても、受け入れるデータ、コンテキストの制限、欠損値の扱い、不確実性の出力、説明変数のサポートは異なり得ます。
ガバナンスの仕組みも重要です。エンタープライズの購入者は、管理者がアクセスを制限できるか、各結果をそのデータまで追跡できるか、サービス変更後も予測を再現できるかを問う必要があります。
自然言語によるアクセスは、別の次元を加えます。Genieは、SQLを書かない人にも機能を利用可能にできます。これは導入の裾野を広げる一方で、意思決定者から重要なクエリの詳細を隠してしまう可能性もあります。
したがって、会話型インターフェースは生成されたクエリ、選択された列、フィルター、時間軸、不確実性を提示すべきです。そうでなければ、ユーザーは実際の分析手順ではなく、流暢な説明を評価してしまうかもしれません。
Databricksは、専門化された予測手法によって、汎用的な言語モデルでは信頼性高く扱えない質問にもGenieが答えられるようになると主張しています。この区別は原理的には妥当です。言語モデルはテキストを生成しますが、予測には順序付けられた観測値と評価指標に結び付いた数値手法が必要です。
ただし、正しい手法を呼び出す前に、インターフェースが要求を誤解する可能性は残ります。収益が変化した理由を尋ねるユーザーは、地域別の寄与、価格・数量分解、因果的影響のいずれかを意味しているかもしれません。これらは交換可能な分析ではありません。
したがって、プラットフォーム競争は、単に機能を呼び出せるようにするだけでは決まりません。勝つ製品は、適切な問いを設定し、計算を検証し、結果が結論を支えない場合を認識できるようユーザーを支援しなければなりません。
ベータ版の制約により、検証は製品の一部になる
最大の不確実性は、セルフサービスのユーザーが、専門家がカスタムモデルに適用するのと同じ注意深さで予測を検証するかどうかです。
少なくとも1つの機能には、すでに具体的なベータ版の制約があります。Databricksのドキュメントによると、ai_detect_anomaliesにはProまたはServerless SQL warehouseと、Predictive AI Functionsプレビューへの登録が必要です。
この機能は各値より前の履歴を調べ、期待範囲を推定し、異常スコアを割り当てます。ユーザーは、行に異常フラグを付与する条件を制御するしきい値を調整できます。
現在の異常検知の制限には、時系列あたり最大8,192行の入力という上限があります。各系列には一意のタイムスタンプも必要で、1回の呼び出しで分析できる値列は1つだけです。
最初の8行は履歴コンテキストを提供するため、通常の異常出力を受け取りません。短い系列を用いるチームは、これがカバレッジに及ぼす影響を理解する必要があります。
この機能は平滑化も提供しており、近接するアラートを1つの異常エピソードにまとめることができます。平滑化によりインシデントは読みやすくなるかもしれませんが、短い間隔内の正常値までマークされる可能性があります。
こうした詳細は、「管理するモデルがない」ことが「分析上の選択がない」ことを意味しない理由を示しています。しきい値、グループ化列、共変量、休日、スコアリングウィンドウはいずれも結果に影響します。
偽陽性は運用コストを生みます。日常的な変動までフラグ付けするアラートシステムは、ユーザーを疲弊させかねません。偽陰性は、重大な変化がレビューされずに通過する可能性があるため、別のリスクを生みます。
予測にはバックテストが必要です。これは、モデルから隠しておいた過去の期間に対して予測を評価する手法です。7日間での精度が1四半期での精度を保証するわけではないため、チームは複数の予測期間をテストすべきです。
また、マネージドモデルを単純なベースラインと比較すべきです。前期の値、季節平均、確立された統計手法は、しばしば有用な比較基準になります。高度なモデルは、関連する成果を改善することで信頼を得るべきです。
予測区間にも注意が必要です。点予測は1つの期待値を示す一方、区間はもっともらしい範囲を伝えます。中間点だけに基づく意思決定は、誤った確実性を生みかねません。
セグメントレベルでの評価も同様に重要です。高ボリュームの商品が指標を支配するため、全体予測は正確に見えることがあります。一方で、より小規模な地域や新発売の商品では、性能が低いままかもしれません。
データリークも別の危険です。リークは、予測時点では利用できなかったはずの情報をモデルが受け取ると発生します。共変量は過去データ上では有効に見えても、将来の評価を非現実的なほど容易にする可能性があります。
ドライバー分析には、規律ある表現が必要です。上位にランク付けされたセグメントは、変化への算術的な寄与を説明できても、顧客行動がなぜ変化したかを証明するものではありません。チームは、因果効果を特定できる設計に対してのみ因果的な主張を留保すべきです。
分類の出力も、過去の問題を増幅する可能性があります。ラベルが一貫しない人間の判断を反映している場合、それらのラベルを自動化すると、その不整合がより大規模に再現されかねません。
モデル更新は再現性に関する問題をもたらします。中央で維持されるモデルは自動的に改善される可能性がありますが、同じクエリが将来的には異なる結果を返すかもしれません。企業には、重要な意思決定のためにバージョン記録と変更通知が必要です。
ベータ期間では、Databricksが機能の周辺に十分な評価ツールを提供するかどうかが明らかになるはずです。有用な追加機能には、組み込みバックテスト、ベースライン比較、性能サマリー、精度悪化のアラートなどがあります。
それまでは、チームは運用用途にコンパクトなモデルカードを添付すべきです。そこには、対象、データウィンドウ、予測期間、入力変数、既知の制限、検証方法、責任者を記載すべきです。
その文書化は、実験の速度を落とす必要はありません。出力が計画、自動化された行動、経営報告に組み込まれる際には必要になります。
簡潔なAIワークフローも、前提と後続の意思決定を保持できます。目的は、一時的な予測が文書化されていない組織上の事実になることを防ぐことです。
この賭けが機能するかを示す3つのシグナル
次の検証点は、アナリストが機能を呼び出せるかどうかではなく、組織がその出力を繰り返し信頼し、運用に組み込むかどうかです。
1つ目のシグナルは、顧客ワークロードから得られる証拠です。Databricksは公共のタクシーデータを用いた例を示し、ベンチマーク比較を報告しています。現在、購入者が必要としているのは、小売、金融、製造、ソフトウェアなどの実運用環境から公開される結果です。
最も強力な証拠には、予測期間、ベースラインモデル、不確実性のキャリブレーション、導入後の誤差変化が含まれます。また、マネージド機能が失敗する場面も示すべきです。
幅広い顧客からの証拠は、1つの維持管理されたモデルレイヤーが多様なビジネス上の問いに対応できるという主張を強めます。狭い範囲、あるいは強く選別された事例は、その主張を弱めるでしょう。
2つ目のシグナルは、より深い評価とガバナンス支援です。運用クエリを対象に、ネイティブなバックテスト、モデルバージョンの可視性、リネージ、モニタリング、承認管理が提供されるかを注視してください。
こうした能力は、Databricksが予測を単なるSQL式以上のものとして扱っていることを示します。また、迅速な分析とガバナンスされた本番プロセスの隔たりを縮めます。
評価ツールが不足していれば、より多くの作業が顧客に戻されます。その結果、モデル学習そのものが容易になっても、当初のボトルネックの一部は残るでしょう。
3つ目のシグナルは、BigQuery、Snowflake、その他の分析プラットフォームの反応です。競合ベンダーは、新機能、より強力なベンチマーク、より優れた会話型統合、より明確なコントロールで応じることができます。
競争相手からの迅速な反応は、マネージド予測SQLがデータプラットフォームの中核カテゴリになったことを裏付けるでしょう。ベンダー全体で導入が低調なら、深刻な予測ニーズの大半には依然としてカスタムツールが使われていることを示唆します。
チームは市場の決着を待つ必要はありません。意思決定が可逆的で、成果がすぐに得られる限定的なユースケースから始められます。
週次の需要予測は、複数年にわたる戦略的予測より評価しやすいものです。人間がレビューする異常アラートは、顧客アクセスを自動変更するアラートより安全です。
まず、出力が支援する意思決定を書き出してください。その後、結果を比較する前に、ベースライン、評価期間、許容誤差、エスカレーションルールを定義します。
マネージド機能を過去のウィンドウに対して実行し、セグメント別の性能を記録してください。予測区間を含め、平均スコアだけでなく、最も大きな失敗も調べます。
機能が十分に機能する場合は、その前提条件を明示した既存のダッシュボードに組み込む。チームが季節変動や異常事象における結果の挙動を理解するまでは、専門家によるレビュー工程を維持する。
Databricks Predictive AI Functions により、高度な分析の依頼と導入が容易になる。その持続的な価値は、チームが評価も同じように利用しやすいものにできるかどうかにかかっている。
今回のリリースにより、アナリストはデータから予測までをより短い経路で進められるようになる。また、これまで組織がモデルを運用に移す前に立ち止まる要因となっていた摩擦の一部も取り除かれる。だからこそ、規律あるレビューの重要性は増しており、決して低下してはいない。
現在、データチームの時間を最も消費している反復的な問いは何だろうか。1つを選び、管理型の結果をシンプルなベースラインと比較してテストし、どこで成功し、どこで失敗するかを記録する。その比較によって、Databricks が実際のボトルネックを解消したのか、それとも単に下流へ移しただけなのかが明らかになる。
