Databricks ai_decide、ガバナンス管理されたデータを分析からアクションへ
Databricksは9月30日、ガバナンス管理されたデータを確率、選択、スコアに変換するベータ版SQL関数「Databricks ai_decide」を公開した。ここには直ちに緊張関係が生まれる。企業はデータと同じ速度でAI支援の意思決定を行いたい一方、業務上の判断には通常のテキスト生成以上の説明責任が求められる。
この新機能は、ユーザーが指定したルーブリックに照らして、構造化レコードまたはテキストを評価する。イベントに注意が必要かを推定し、あらかじめ定義した結果から選択し、あるいは順序付けられた尺度でケースを採点できる。その出力は別のSQLクエリ、ワークフロー、アプリケーションへ渡せる。
このため、今回の発表は単なるモデルエンドポイントの追加以上の意味を持つ。Databricksは、チームが既にテーブル、権限、パイプライン、ビジネスロジックを管理しているデータワークフロー内に、モデルに基づく判断を持ち込もうとしている。Google CloudはBigQueryで関連する生成AI関数を提供しており、汎用モデルAPIを使えば開発者は類似のシステムを手作業で構築できる。今問われているのは、不確実性を隠さずに確率的な意思決定を業務運用へ組み込めるのは誰かという点だ。
Databricks ai_decide、1回のSQL呼び出しを複数の意思決定へ変える
重要なのは、DatabricksがSQLからモデルを呼び出せることではない。同じレコードについて、1つのガバナンス管理された関数が複数の意思決定可能な評価を返せることだ。
同社のローンチ記事によると、Databricks ai_decideは、ガバナンス管理された企業データに基づく迅速な意思決定を目的としている。この関数は、同社のタスク特化型AI Functions群に含まれる。
構文は、state、質問の集合、任意のバージョン設定という3つの要素から成る。stateには評価対象となる根拠が含まれる。通常のテキスト、JSONエンコードされたオブジェクト、JSON配列、あるいは別のAI Functionが生成したVARIANTを指定できる。
質問は呼び出しごとに1回定義され、各入力行に適用される。すべての質問には指示と応答タイプが含まれる。一部のタイプでは、利用可能な結果を説明する基準も必要となる。
関数リファレンスでは、3種類の応答タイプが説明されている。
noulは、ある文が真である確率を推定し、0から1までの数値を返す。
choiceは、最大255件の名前付き基準から1つのラベルを選択し、すべてのラベルの確率を返す。
scoreは、2〜10件の基準を含む順序付き尺度に対して入力を評価する。
独特な用語であるnoulは、確率的なイエス・ノー評価を指す。Booleanの答えを強制するのではなく、この関数は推定された可能性を報告する。下流システムが絶対的な断定ではなくしきい値を必要とする場合、この違いは重要になる。
たとえばサポート組織では、チケットに即時エスカレーションが必要かを尋ねられる。同時に、どのチームがそのケースを担当すべきか、状況がどれほど緊急かも判断できる。これら3つの評価はすべて、同じチケットを根拠として利用できる。
結果は、応答、メタデータ、エラーフィールドを含むVARIANTとして返される。VARIANTは、ネストしたJSONのような半構造化値に対応する柔軟なデータ型である。成功した呼び出しでは関数バージョンが特定され、失敗した呼び出しではエラーの説明を返すことができる。
choiceの質問では、選択されたラベル、可能な各ラベルの確率、信頼度が出力に含まれる。scoreの質問では、数値スコア、元の尺度の説明、確率、信頼度が含まれる。
この設計により、アナリストは単一の生成ラベル以上の情報を得られる。ワークフローは高信頼度の判断を自動的に受け入れ、不確実なケースを人に振り分け、後のレビューに備えて確率分布を記録できる。
Databricksは、生成された回答が呼び出しごとに異なる場合があるとも警告している。この記述は見落としやすいが、業務運用上の中核的な課題を定義している。SQL構文はこの関数を使いやすく、組み合わせやすくする。しかし、基盤となる判断を決定論的なものにするわけではない。
ガバナンス管理されたAI意思決定がデータチームに圧力をかける
Databricks ai_decideは、データチームに対し、モデルの判断をチャットボットからコピーした実験的な出力ではなく、本番ロジックとして扱うよう迫る。
多くの企業の意思決定は、すでにデータウェアハウスやレイクハウスから始まっている。サポートチケット、商品リスト、保険書類、インシデント報告、申請、取引記録は、最終的にパイプラインで処理される行データになる。
判断を厳密なルールとして記述できる場合、従来のSQLは適切に機能する。一定額を超える取引をレビュ―キューに入れたり、既知のエラーコードを持つチケットを特定のチームへ送ったりできる。
より難しいケースは意味に依存する。顧客は、企業の正式なインシデント用語を使わずにサービス停止を説明するかもしれない。商品リストは、管理された分類体系に一致せずに適合性を示唆するかもしれない。1つのケースが複数の競合する優先事項を同時に満たす場合もある。
組織はこうした状況を、手作業のキューや外部モデルサービスで処理することが多い。手動レビューは遅くなり得る。外部サービスでは、追加のコード、データ移動、認証情報、監視、ガバナンス作業が必要になる。
Databricks ai_decideはこの経路を短縮する。チームはデータの横に定性的なルーブリックを記述し、SQL内で構造化された評価を受け取れる。その評価は、フィルター、結合、ダッシュボード、Lakeflowパイプライン、Workflows、アプリケーションロジックに組み込める。
より広範なAI Functionsの概要では、文書解析、抽出、分類、検索準備、その他の変換のための組み込み関数が説明されている。Databricks ai_decideは、これらの準備ステップの後に明示的な意思決定レイヤーを加える。
文書ワークフローを考えてみよう。ai_parse_documentは、アップロードされた文書を構造化コンテンツへ変換できる。ai_extractは、指定されたフィールドを特定できる。Databricks ai_decideは、その後、得られたVARIANTをビジネスルーブリックに照らして評価できる。
この一連の流れは、誰がワークフローを構築できるかを変える。データエンジニアは、すべての判断をカスタムサービスでラップする必要がなくなる。アナリストは、使い慣れたデータツールを通じてstate、基準、回答、確率、エラーを確認できる。
同時に、誰が責任を負うかも変わる。AI生成スコアが振り分けや優先順位付けを制御するようになると、データチームはクエリ性能以上の責任を負う。許容可能なエラー率、エスカレーションのしきい値、監視ルール、フォールバック動作の定義を支援しなければならない。
ガバナンスは製品設計の一部となる。Databricksによると、文書データは同社のセキュリティ境界内にとどまる。同社は、AI Function呼び出しに渡されたパラメータを保存しない一方、ランタイムバージョンなどの実行メタデータは保持するとしている。
アクセスが自動的に限定されるわけではない。Databricksのドキュメントによると、関連するプレビューが有効な場合、ユーザーにはデフォルトでsystem.aiスキーマに対するEXECUTE権限が付与される。管理者は、選択した関数またはグループにアクセスを付与する前に、そのスキーマレベルの権限を削除する必要がある。
これらのアクセス制御自体もパブリックプレビュー段階であり、有効化が必要だ。これらはsystem.ai配下のタスク特化型関数に適用されるが、汎用のai_query関数は対象としない。
この境界は重要だ。企業は、1つのガバナンス機構を有効化すればモデルへのすべての経路をカバーできると考えることはできない。管理者には、タスク特化型AI Functionsと直接のModel Serving呼び出しに対する個別のポリシーが必要となる。
したがって今回のローンチは、プラットフォーム所有者、セキュリティチーム、業務リーダーに同時に圧力をかける。プラットフォーム所有者は関数を信頼できるものにしなければならない。セキュリティチームは意図的にアクセスを設定する必要がある。ビジネスリーダーは、確率的な自動化が許容される領域を定義しなければならない。
構造化ルーブリックこそが本当の仕組み
中心となる仕組みは、自由形式のプロンプトから、構造化された不確実性を備える明示的なルーブリックへの移行だ。
汎用モデルのプロンプトでは、「このケースにどう対応すべきか」と尋ねられる。回答は巧みな文章になるかもしれないが、別のシステムがそれを解析しなければならない。モデルがカテゴリーを作り出したり、形式を変えたり、信頼できるフィールドを生成せずに判断を説明したりする可能性もある。
Databricks ai_decideは、このやり取りを限定する。開発者は名前付きの質問、指示、許可された基準を定義する。この関数は、下流のSQLが参照できる予測可能な応答形式を返す。
この制約は統合作業を減らす。また、意思決定の契約をレビュー担当者に可視化する。コンプライアンス担当者はエスカレーションの定義を確認できる。運用マネージャーはカテゴリーの説明を精査できる。データエンジニアは、確率がどのようにワークフローのアクションへ変換されるかを検証できる。
choiceタイプはこのアプローチをよく示している。たとえばサポート組織が、配送、請求、技術サポートだけを振り分けラベルとして定義したとする。この関数はそれらの名称から選択し、それぞれの確率を返さなければならない。
選択されたラベルは有用だが、分布の方がより多くを示す場合がある。請求と技術サポートの間で結果が拮抗していれば、曖昧さを示す。ワークフローは、最上位ラベルが確実であるかのように扱う代わりに、そのケースを一般キューへ送ることができる。
scoreタイプは、自由形式の数値ではなく順序付けられた基準を使う。チームは、通常の依頼から重大なブロッカーまで、3段階の緊急度を定義できる。返されるスコアは、基準インデックスの確率加重平均となる。
この手法は、競合する評価に関する情報を保持する。モデルが複数レベルに確率を割り当てる場合、結果は小数になることがある。出力には、スコアの背後にある凡例と確率も保持される。
複数の質問で同じstateを共有できる。これにより、カテゴリー、緊急度、エスカレーション、その他の判断のために、同じ根拠を別々のプロンプトへ渡す必要が減る。関連する回答をまとめて保持することもできる。
ただし、入力を共有しても、すべての質問が独立した評価になるとは限らない。チームは、指示が予期しない形で相互作用しないかをテストすべきだ。また、質問を組み合わせることで、対象ワークロードの品質、レイテンシ、コストが変化しないかも検証すべきである。
Databricksによると、別のモデルが社内ベンチマークでより良い性能を示した場合、基盤モデルが変更される可能性がある。現行ドキュメントでは、利用可能なモデルをApache 2.0ライセンスと関連付け、顧客を適用されるモデル利用規約へ案内している。
マネージドモデルの選択は設定の負担を減らす。一方で、安定したSQLインターフェースの下で関数の挙動が変化し得ることも意味する。バージョンメタデータは関数契約の特定に役立つが、チームには代表的なデータに基づく回帰テストが依然として必要だ。
ここで、この仕組みは業務運用上重要になる。決定論的な条件で構築されたストアドプロシージャは、正確に期待された出力に対してテストできる。確率的な関数には、分布チェック、しきい値チェック、反復評価が必要となる。
チームは、重要なルーブリックごとにラベル付けされた評価セットを維持すべきだ。そうしたセットには、一般的な例、境界事例、根拠が不足するケース、根拠が矛盾するケース、常に人へ回すべき入力を含める必要がある。
また、推奨と実行を分けるべきだ。意思決定関数は、影響が限定的な範囲でサポートキューの優先順位付けを行える。同じ信頼度だけで、返金の承認、応募者の却下、アカウントの停止、安全対応の開始を自動的に許可すべきではない。
SQLインターフェースによって構成は容易になる。優れたシステム設計では、重大な結果を伴うアクションを意図的に難しく保たなければならない。
Databricks ai_decide、汎用モデル呼び出しおよびWarehouse AIと競合
主な競争は、タスク特化型のマネージド関数と、汎用モデルエンドポイントを中心に意思決定ロジックを構築する柔軟性との間で繰り広げられる。
Databricksはすでに、Model Servingエンドポイントを呼び出す汎用関数ai_queryを提供している。開発者は対応モデルを選択し、独自のプロンプトを記述し、パラメータと戻り値の型を制御できる。
ai_queryのドキュメントでは、目的に合致する場合はまずタスク特化型AI Functionから始めることをチームに推奨している。ai_queryは、モデル、プロンプト、パラメータ、または出力をより細かく制御する必要があるケース向けと位置付けられている。
この違いは、明確なトレードオフを生む。
タスク特化型関数はセットアップの負担を減らし、構造化された契約を課す。Databricksは処理の背後にあるシステムを管理し、その実装を改善できる。チームは証拠、質問、基準に集中できる。
汎用モデル呼び出しは柔軟性を提供する。開発者はカスタムモデルを使い、デコーディング設定を調整し、異なるスキーマを定義し、フォールバックエンドポイントを実装し、特定のモデルバージョンを維持できる。その一方で、より多くのエンジニアリングと評価作業を担うことになる。
Databricks ai_decideは、意思決定が利用可能な3つの形式に収まる場合に最も強みを発揮する。確率、名前付き選択肢、順序付きスコアは、多くのルーティングおよび優先順位付けタスクをカバーする。ただし、すべての意思決定構造を網羅するわけではない。
企業によっては、マルチラベル分類、制約付きの数値推定、証拠への引用、ルールベースの除外、あるいは依存関係を持つ一連の質問が必要になる場合がある。そうしたケースでは、開発者は依然としてai_query、カスタム関数、または外部アプリケーションを必要とする可能性がある。
競争領域はDatabricksの外にも広がっている。Google Cloudは、Boolean結果、応答の詳細、ステータス情報を返すBigQuery向けのAI.GENERATE_BOOL関数を文書化している。これはGeminiを通じてテキストおよび参照された非構造化コンテンツを処理できる。
GoogleのBoolean関数は、モデルおよびリクエストのパラメータをサポートしている。そのドキュメントは、プロンプト設計が結果に影響すること、またクエリプランニングによってモデル推論が予想以上の行を処理する可能性があることも警告している。
Googleは別途AI.IFも提供しており、ドキュメントではプロンプト最適化と最適化モードをサポートすると説明している。このモードでは、規模拡大時のコストとレイテンシを抑えるために蒸留モデルをトレーニングできる。
Databricksは、1回の呼び出しでより広範なルーブリック指向のアプローチを採る。Databricks ai_decideは複数の質問に回答し、名前付き選択肢または順序付きスコアの確率を返せる。Googleが文書化しているBoolean関数は真偽値の生成に焦点を置くが、BigQueryには追加のスカラー関数と生成AI関数がある。
どちらのアプローチもアプリケーション設計を不要にはしない。WarehouseネイティブAIはデータと推論の距離を縮めるが、チームは依然としてしきい値を選び、入力を具体化し、権限を制御し、出力を評価しなければならない。
したがって競争は、構文だけでなく運用上の証拠によって左右される。購入者は、関数が自社のレコード、地域、コンプライアンス要件、そして本番規模でどのように動作するかを知る必要がある。
統合作業を削減しても予測不能なコストを生む関数は苦戦する。日常的な分類タスクごとに専門チームを必要とする柔軟なエンドポイントも同様だ。
Databricksは、多くのエンタープライズの意思決定には、マネージドプリミティブに値するほど十分な共通構造があると見込んでいる。その成否は、組織がそれらを実際のアクションに接続したときにも、こうしたプリミティブが理解しやすいままであるかにかかっている。
迅速な意思決定にも、慎重な検証が必要
ベータというラベルこそ最も明確な警告だ。Databricksは実装を簡素化したが、不確実性、地域的な制約、人間の説明責任を取り除いたわけではない。
Databricks ai_decideはベータ機能として提供されている。ワークスペース管理者はPreviewsページからアクセスを制御し、この関数は対応地域でのみ利用できる。
Databricks SQL Classicでは実行できない。ドキュメントではDatabricks Runtime 15.4 LTS以降が必要とされ、現行機能とパフォーマンスのためにはRuntime 18.2以降が推奨されている。
こうした前提条件は、直ちに導入できる範囲を狭める。古いランタイム、Classic warehouse、非対応地域、または厳格なプレビュー方針を持つ組織は、インフラを変更するか待つ必要がある。
モデル層も別の不確実性をもたらす。Databricksによれば、内部ベンチマークでより良い選択肢が確認された場合、基盤となるモデルを変更する可能性がある。このマネージドな進化は結果を改善しうるが、顧客の観点からはモデルドリフトも生む。
意思決定パイプラインは、関数名が安定していることだけに依存できない。チームには、ベースライン評価、リリース管理、監視対象のしきい値、プラットフォーム変更後に結果を比較する能力が必要だ。
ルーブリック自体も失敗する可能性がある。指示に重要な例外が含まれていないことがある。カテゴリーが重複する場合もある。順序尺度は、証拠が裏付けない精度を示唆することがある。
信頼度には慎重な解釈が必要だ。高いconfidenceフィールドは、関数のプロセスにおいて状態が評価をどの程度裏付けているかを示す。回答が事実として正しい、あるいは公正であることを保証するものではない。
確率出力にも同様のリスクがある。0.9という値は精密に見えるが、キャリブレーションの証拠なしに、比較可能な予測の90パーセントが正しいと利用者は想定すべきではない。キャリブレーションは、組織独自のラベル付きケースでテストする必要がある。
データ品質は依然として決定的だ。状態に古い、不完全な、または誤解を招くレコードが含まれていれば、適切に構造化されたルーブリックでも不適切な意思決定を生みうる。ガバナンスは誰がデータを使えるかを制御するが、すべての入力が適切であることを保証するものではない。
バイアスは、例や基準を通じても入り込む。カテゴリー説明には、盲点を含むチームの過去の慣行が埋め込まれる可能性がある。スコアは、評価セットに含まれる一貫性のない人間の判断を再現することがある。
影響の大きい用途には、より強い保護策が必要だ。雇用、信用、医療、保険、法務、安全に関する意思決定には、モデル出力を超える義務が伴う。組織はアクションを自動化する前に、対象領域、法務、セキュリティ、リスクのチームを関与させるべきだ。
低リスクのワークフローにも障害処理が必要である。この関数はnull応答とエラーメッセージを返す場合がある。パイプラインは、再試行するか、一時停止するか、決定論的なフォールバックロジックを使うか、あるいはケースを人に回すかを決めなければならない。
ドキュメントによると、生成された回答は呼び出しごとに異なる場合がある。そのため、繰り返し評価すると、境界的なレコードに対して異なるラベルやスコアが生成される可能性がある。下流のアクションを一度だけ実行すべき場合、チームには冪等性ポリシーが必要だ。
コストも同様に精査する必要がある。モデルに支えられた各評価は推論リソースを消費する。大規模テーブルのすべての行に対して複数の質問を実行すれば、便利なクエリが高コストな処理へと変わりうる。
開発者は、関数を呼び出す前に対象となる行を絞り込むべきだ。安定した入力セットを具体化し、意図しない全表再評価を防ぎ、推論を繰り返しても価値が加わらない場合は出力を保存すべきである。
これらの懸念は、製品の方向性を否定するものではない。生成要約よりも、ガバナンスの効いたAI意思決定に異なる基準が必要である理由を説明している。弱い要約は読者に不便を与える。弱いルーティングまたは優先順位付けの判断は、その後に何が起きるかを変えてしまう。
この賭けが機能するかを示す3つのシグナル
次の試金石は、Databricksが有望なSQL抽象化を、測定可能でガバナンス可能な本番機能へと変えられるかどうかだ。
第1のシグナルは、文書化された評価性能である。Databricksは、代表的な意思決定タスク全体における精度、キャリブレーション、レイテンシ、コストを示す独立したベンチマークを提示していない。顧客に必要なのは、速度に関する一般的な約束ではなく、ワークロード固有の証拠だ。
有用な検証では、Databricks ai_decideをai_query、決定論的ルール、確立された人手レビューと比較することになる。ラベル精度、確率のキャリブレーション、繰り返し呼び出し時の安定性、処理時間、エスカレーションを必要とするケース数を測定すべきだ。
チームが管理されたエラー率で再現可能な改善を公表できれば、タスク特化型アプローチの信頼性は高まる。すべての呼び出しを広範な補正ロジックで包む必要があるなら、この抽象化が節約する作業は構文が示唆するほど大きくない。
第2のシグナルは、より広い本番環境での可用性である。この機能は現在ベータラベルを持ち、プレビューの有効化を必要とし、Classic SQL warehouseを除外し、対応地域も一部に限られている。
より幅広い提供へ進めば、Databricksがサービスの信頼性、ガバナンスのカバー範囲、運用サポートに自信を持っていることを示すだろう。プレビュー制限が続けば、この関数は実験や低リスクのワークフローに限定される。
ガバナンスの成熟度も同じシグナルに含まれる。管理者には、実行権限、モデルアクセス、監査証跡、地域処理、基盤モデルの変更に関する明確な制御が必要だ。これらの制御は、クラウドプラットフォームとワークスペース構成をまたいで一貫して機能しなければならない。
第3のシグナルは、デモンストレーションを超えた顧客利用である。製品カテゴリー分けやサポートチケットのルーティングは理解しやすい例だ。より強い証拠は、公表されたレビューしきい値と測定可能なビジネス成果を伴う本番ワークフローから得られるだろう。
確率が単にダッシュボードを装飾するのではなく、ワークフローを変えるケースに注目したい。企業は明確な意思決定を自動化し、曖昧なレコードを専門家に送り、その結果生じる修正を使ってルーブリックを検証するかもしれない。
競合他社にも注目すべきだ。Google CloudはすでにWarehouseネイティブの生成AI関数を公開しており、他のデータプラットフォームもガバナンスされたデータの近くでモデルアクセスを追加し続けている。より明確なキャリブレーション、より広い入力サポート、またはより低い運用負荷を備えた競合関数が現れれば、Databricksの優位性は弱まる。
Databricks ai_decideは重要な変化を捉えている。エンタープライズは、情報を説明するだけのモデルではもはや満足しない。既存のデータ制御の内部にとどまりながら、選択、ランク付け、ルーティング、エスカレーションを支援するシステムを求めている。
慎重な次の一手は、この関数を直接、重大なアクションへ接続することではない。範囲を限定したキューを1つ選び、明示的なルーブリックを定義し、ラベル付き評価セットを構築する。関数の出力を現行の意思決定と比較し、その後、自動化と人手レビューのしきい値を選択する。エラー、不確実性、レイテンシ、ドリフトをそれぞれ別に追跡する。
あなたの組織には、評価できるほど反復的でありながら、安全にテストできるほど可逆的な意思決定があるだろうか。それがDatabricks ai_decideの適切な出発点となる。この製品の持続的な価値は、確率的な出力を確実性として扱うことではなく、透明性のある運用規律から生まれる。
