データウェアハウスでAI Functionsを活用する：主要ユースケース

多くの組織では、データウェアハウスに構造化データが保存され、非構造化データはデータレイクに置かれています。これは、既知のレポートを大規模に消費する分析ワークロードには適していますが、AI ワークロードは異なる入力を必要とします。AI モデルは、レビューやサポートチケット、PDF などの非構造化データを解析し、構造化データと組み合わせてモデルの学習・構築・推論を行うことが多いためです。従来、アナリストがサポートチケットの感情分析を行いたい場合、データ行を外部サービスに送信し、予測を待って、手作業でテーブルに結合する必要がありました。これは遅く、スキーマ変更で壊れやすく、セキュリティとガバナンスのリスクも伴います。

AI Functions は、データを別の AI 環境に移動するのではなく、AI をデータのそばに持ち込みます。標準 SQL クエリ内でモデルを呼び出せるため、推論プロセス全体を既存のパイプラインと Unity Catalog のガバナンス内に維持できます。Unity Catalog の権限を尊重するため、データは安全かつプライベートに保たれます。SELECT 文を書けるなら AI を利用でき、クラスタ管理や外部オーケストレーションを意識する必要はありません。課金は system.billing.usage に一元化され、ai_classify、ai_extract、ai_translate、ai_parse_document のようなタスク特化型関数は、汎用推論に過払いすることなく、特定のジョブに最適化されたモデルを利用できます。

記事では、6 つのユースケースが紹介されています。1 つ目はドキュメントインテリジェンスです。ai_parse_document が PDF や画像などの生のバイナリファイルを読み取り可能なテキストに変換し、ai_extract が特定のキーと値を抽出して構造化テーブルを作ります。従来は Python の OCR サービスと LLM 呼び出し、JSON 展開の手順を手作業で構築していましたが、それが 1 つのクエリプランに集約されます。2 つ目はカスタマーフィードバックの感情分析です。ai_classify はゼロショット分類を行い、トレーニングなしで自由形式のテキストをユーザー定義ラベルにマッピングし、BI ダッシュボードで即座に利用できる列に変換します。

3 つ目は多言語データのインライン翻訳です。ai_translate を使用すると、クエリレイヤー内で多言語データを単一のターゲット言語に正規化でき、データサイロを防ぎます。4 つ目は分類とルーティングです。サポートチケットや通話記録の自由入力を、取り込み時点で意図や緊急度に分類し、適切なチームや自動応答システムに振り分けます。5 つ目は営業通話からの構造化抽出です。ai_extract が通話記録から次のステップ、商談ステージ、リスクフラグ、リスク理由などを抽出し、定性情報を BI ツールでクエリ可能なメトリクスに変換します。6 つ目は生成的な下書き作成です。ai_query は最も汎用的な関数で、アクセス可能な Databricks ホストのファンデーションモデルにプロンプトを送り、行ごとに回答を返します。例えば、更新時期を迎えたアカウントに対して更新メールの下書きを生成できます。

本番運用のヒントとしては、初日からジョブにタグを付け、コストを適切なジョブに帰属させること、特定タスク用関数を優先し、どれも合わない場合のみ ai_query を使うこと、ai_query では構造化出力を求めること、モデル選択を意図的に行うこと、10,000 行でサンプル実行してから残りを実行すること、プロンプトをコードとして扱うことなどが挙げられています。サンプルノートブックも提供されており、各ユースケースをすぐに試せます。

これら 6 つのユースケースに共通するのは、AI がウェアハウスの他の部分と同じ場所、同じプラットフォーム、同じガバナンスモデル、同じ請求、同じパイプライン上で動作するという点です。既存の SQL ETL のどの行にも AI ステップを追加でき、翻訳やスコアリング、分類を行っていた Python スクリプトは 1 行の置き換え候補になります。まずは 1 つのカラムから始め、現在最も脆弱なサービスを SELECT で書き直し、10,000 行で実行して結果を確認すれば、フィットするかどうかすぐに判断できます。