この記事のサマリ
- 現状: SnowflakeやBigQueryなどを筆頭に、「SQLから直接AI（LLM）を呼び出す機能」の実装がすごいスピードで進んでいます。
- 変化: 今までPythonやETLツールで苦労して書いていた「データ整形」や「表記揺れ対応」が、これからはSQL関数（UPDATE文など）だけでサクッと終わる時代になりそうです。
- 戦略: とはいえ、何でもかんでも最強のAI（GPT-4など）に任せると、コストも時間もかかりすぎます。**「単純作業はDB内の軽量モデル」「難しい考察は外部の高性能モデル」**という使い分けがカギになります。
- セキュリティ: 業務で使うなら、やっぱりデータがどこにあるかが大事。データを外に出さない「内部ホスティング型」か、同じクラウド内で完結する「連携型」を選ぶのが安心です。
はじめに
これまで、データベースにあるテキストデータをAIで解析しようとすると、「DBからデータを抽出して、PythonでAPIを叩いて、結果をまたDBに戻して…」なんていう、ちょっと面倒なパイプラインを作る必要がありましたよね。
でも今、**「SQLの関数として、そのままAIを呼び出す」**機能が、主要なデータプラットフォームで標準になりつつあるんです。これによって、データベースは単なる「データの保管庫」から、自律的にデータを加工したり解釈したりする「考える場所」へと進化しようとしています。
今回は、主要なRDBMSやDWHが今どうなっているのかをサーベイ（調査）してみました。その結果をもとに、エンジニアとして気になる**「セキュリティ」や「コスト」**の観点から、これからのデータ基盤はどうあるべきか、私なりの考えをまとめてみます。
いろんなRDBMSで「SQL×AI」がどう実装されているか調べてみました
調査してみると、データベースにおけるAI統合は、大きく3つのパターンに分かれていることが分かりました。
クラウドDWH / マネージドサービス（内部・エコシステム統合型）
この分野が一番進んでいます！インフラ管理なしで、すぐに関数が使えるのが魅力です。
| 製品/サービス | AI機能名 | 特徴 | 実行場所 |
|---|---|---|---|
| Snowflake | Cortex |
COMPLETE() や SUMMARIZE() といった専用関数が用意されています。SQLを書くだけで、裏側を気にせずサーバーレスに使えます。 |
内部 (Snowflake管理下) |
| Google BigQuery | BigQuery ML |
ML.GENERATE_TEXT 関数で、GoogleのVertex AI (Gemini等) を呼び出せます。Googleのエコシステムならではの連携が強力です。 |
連携 (Google Cloud内) |
| MySQL HeatWave | Generative AI | HeatWaveクラスタの中でLLMを動かしたり、OCI上のAIサービスと連携したりできます。In-Database処理に強いのが特徴です。 | 内部 / 連携 |
商用RDBMS / エンタープライズ（ハイブリッド・エージェント型）
既存のしっかりしたDB機能に加え、「自然言語でデータを問い合わせる」機能などに力を入れています。
| 製品/サービス | AI機能名 | 特徴 | 実行場所 |
|---|---|---|---|
| Oracle DB | Select AI | 自然言語で「〜の売上教えて」と聞くとSQLを書いてくれる機能に注力しています。裏側のAIはCohereやOpenAIなどから選べます。 |
外部連携 (OCI/Azure等) |
| Databricks | AI Functions |
ai_query() 関数を使います。自社環境でホストしたモデルと、外部APIの両方を使い分けられる柔軟さがあります。 |
ハイブリッド |
OSS / 拡張機能（自作・組み込み型）
PostgreSQLのエコシステムを中心に、自分で自由に構成できるのが楽しいところです。
| ツール・拡張 | 特徴 |
|---|---|
| PostgresML | PostgreSQLの拡張機能です。なんとDBのプロセス内で直接機械学習モデルを動かせます。データの移動コストがゼロなのが凄いです。 |
| pgvector | ベクトル検索といえばこれ、というくらいデファクトスタンダードですね。RAG（検索拡張生成）の基盤によく使われます。 |
| pg_ai / pg_net | SQLからOpenAIなどのAPIを叩くためのクライアント的な拡張機能です。 |
見えてきた「賢い使い分け」の方向性
「SQLでAIが使える！」といっても、どういう使い方か、どういったLLMを使うのかというのは様々です。いろいろと見てみると、タスクの重さに応じて「モデルと実行場所を使い分ける」のが良いのではと思ってきました。
A. 単純処理：データの「お掃除」や「整形」
例えば「表記揺れの統一」「住所の正規化」「個人情報のマスキング」のようなタスクです。
- 要件: データ量がすごい（数百万行とか）ので、とにかく安く、速く処理したい。複雑な「思考」は要りません。
-
おすすめ: In-Databaseのローカル/軽量LLM
- 例: Snowflake Cortex, PostgresML, MySQL HeatWave (In-Database)
- 理由: 外部への通信待ち時間がないですし、コストも抑えられます。
実際に、Snowflake Cortexの COMPLETE 関数を使って住所をきれいにするSQLはこんな感じです。
-- Snowflake CortexでのCOMPLETE関数を使用した例
UPDATE customers
SET clean_address = SNOWFLAKE.CORTEX.COMPLETE(
'llama3-8b', -- ★ここがポイント！軽量モデルを指定してコストと速度を最適化
'以下の住所を整形してください。郵便番号、都道府県、市区町村、番地の順に正規化し、建物名は削除してください: ' || address
)
WHERE clean_address IS NULL;
補足: なぜ llama3-8b なの？
この COMPLETE 関数では、あえて llama3-70b のような高性能モデルではなく、llama3-8b のような軽量モデル（Small Language Model）を指定しています。
住所の整形のような決まり切ったタスクに、GPT-4のような「天才」を使うのはオーバースペックでもったいないですよね。DBの中で動く軽量モデルなら、大量のデータでもバッチ処理のように高速にさばけます。正規表現やPythonコードなどで頑張って置換ルールを書いていたあの苦労が、自然言語の指示ひとつで解決するのはすごいですよね。
B. 高度な推論：分析して「考えて」もらう
こちらは「売上データからの傾向分析」「複雑な相関の発見」「レポート作成」などが当てはまります。
- 要件: データ量は集計後の数百行くらい。でも、高い論理性や知識が必要です。
-
おすすめ: 外部の高性能LLM（API連携）
- 例: GPT-4, Claude 3.5 Sonnet, Gemini 1.5 Pro (BigQuery経由)
- 理由: ここはコストがかかっても、圧倒的に賢いモデルに頼るべきところです。
実践例: 売上データから「考察」を引き出す
ここでは標準的なベンチマークデータ（SSB）を使って、「SQLでガッツリ集計」して、「AIに考察してもらう」例を作ってみました。
-- SnowflakeなどのAI関数対応DBを想定したイメージ
WITH yearly_trend AS (
-- 1. まず通常のSQLで、必要な粒度（年次・カテゴリ別）までデータをギュッと集計します
-- （いきなり数億行をAIに渡すと、コストもトークンも爆発しちゃうので）
SELECT
d.d_year AS year,
p.p_category AS category,
SUM(l.lo_revenue) AS total_revenue
FROM
lineorder AS l
INNER JOIN dates AS d ON l.lo_orderdate = d.d_datekey
INNER JOIN part AS p ON l.lo_partkey = p.p_partkey
WHERE
p.p_category = 'MFGR#12' -- 今回見たいカテゴリ
GROUP BY
1, 2
ORDER BY
1
),
formatted_context AS (
-- 2. 集計結果をAIが読みやすいテキスト形式（"1992: 500M, ..."）に変換
SELECT
category,
LISTAGG(TO_VARCHAR(year) || ': ' || TO_VARCHAR(total_revenue), ', ')
WITHIN GROUP (ORDER BY year) AS trend_data
FROM
yearly_trend
GROUP BY
category
)
-- 3. AI関数を呼び出して、数字の羅列から「ビジネス的な考察」を書いてもらいます
SELECT
category,
SNOWFLAKE.CORTEX.COMPLETE(
'llama3-70b', -- ★ここは高度な推論が必要なので、賢いモデルにお願いします
'以下の売上データ（Year: Revenue）のトレンドを分析してください。'
|| '特に売上が急落または急増している年があれば指摘し、'
|| '一般的な製造業の市場動向やビジネスサイクルに照らして、'
|| '考えられる仮説を3点挙げてください。: '
|| trend_data
) AS analysis_report
FROM
formatted_context;
これだけで、「ダッシュボードの数字を睨んで人間が考える」というプロセスの一部を、SQL一発で自動化できてしまいます。すごい時代になりましたね。
セキュリティとデータの場所について
データ管理やAIの利用で一番気になるのは、「データがどこにあるか」「データがどこで処理されるか」ですよね。ここは慎重に選ぶ必要があります。
-
内部ホスティング型 (Snowflake, HeatWave等)
- AIモデルがデータ基盤の中（セキュリティ境界の内側）にいます。
- 判定: 安心！ データが外に出ないので、個人情報や機密データの処理にも使いやすいです。
-
同クラウド連携型 (BigQuery + Vertex AI等)
- データはサービス間を移動しますが、同じGoogle Cloudの中（閉域網）で完結します。
- 判定: これも安心。エンタープライズ用途でも十分選択肢に入ります。
-
外部API呼び出し型 (PostgreSQL + OpenAI API等)
- インターネット経由でAIプロバイダにデータを送ります。
- 判定: 注意が必要。「学習に使わない設定」を確認したり、Azure OpenAIなどのプライベート接続を使ったりと、一工夫必要です。
これからどうなる？
以上のようにいろいろと調べて分かってきたSQLでのAI利用ですが、ここからは「今後こうなっていくんじゃないか？」という私の予想です。
1. データ処理の「標準機能」になるかも
かつてJSON型やWindow関数がSQL標準になったように、そのうち VECTOR_SEARCH や AI_GENERATE みたいな機能も、SQLの標準規格っぽくなっていく気がします。エンジニアが正規表現を書くのと同じ感覚で、SQLの中にプロンプトを書くのが当たり前になるかもしれません。
2. ETLがもっと楽になる（ELT + AIへ）
「Pythonスクリプトでちまちま正規化ロジックを書く」という作業は激減するでしょう。とりあえず生のデータをDBに放り込んで（Load）、SQLとAI関数で整形する（Transform）ほうが圧倒的に楽だからです。
3. 「自然言語で問い合わせ」はDBの外側へ？
「自然言語でDBに質問する (Text-to-SQL)」機能については、DBエンジン自体が持つというよりは、MCP (Model Context Protocol) などを介して、外部のAIエージェントやBIツールが「通訳」としてDBに接続する形が主流になるのでは？と思っています。DBはあくまで「高速処理」に専念するイメージですね。
まとめ
最後に、今回の調査を通じて分かったことと、私が感じたことをまとめます。
調査を通じて分かったこと
各社のRDBMSは、もはや単なるデータストアではなく、「AIを内包したデータ処理基盤」へと進化していました。
SnowflakeやBigQueryを使えば手軽かつセキュアにAIが使えますし、OSSのPostgreSQLでも拡張機能を組み合わせれば自由自在です。「SQLの中からAIを呼ぶ」環境は、もう整っています。
これからの進化についての私の予想
今後は、以下のスキルがエンジニアにとって大切になってきそうです。
-
「AIモデルの使い分け」
何でもかんでも高性能AIに投げるのではなく、タスクの重さやデータの機密性に合わせて「DB内の軽量モデル」と「外部の賢いモデル」を設計レベルで使い分ける力。 -
「AI前提のデータパイプライン設計」
泥臭いデータ整形をコードではなく、SQLとプロンプトで解決する発想の転換。
これからは、SQL＋AIで、データエンジニアリングがますます楽しく、楽になっていく可能性があるのではと思ってきました。ここまで読んでくださってありがとうございました！