Google Cloud が AlloyDB にプロキシモデルを搭載：データベースがローカルで AI 判断、最速で 2.3 万倍の高速化

AlloyDB とは何か、AI をデータベースに組み込むとはどういうことか

今回のアップデートの重みを理解するには、まず2つのことを押さえる必要がある。AlloyDB とは何なのか、そして「Gemini を組み込む」ことが実際に何を変えたのかだ。

AlloyDB は Google Cloud 上のリレーショナルデータベースで、PostgreSQL（世界で最も普及しているオープンソースデータベースの一つ）と互換性がある（Google Cloud 版の強化型 PostgreSQL とイメージしてもらえばいい）。企業はこれを使って注文、ユーザー、商品レビュー、システムログといった業務データを保存し、SQL でクエリをかける。

従来型のデータベースには生まれつきの限界がある：文字通りの完全一致しかできない。「価格が100未満の商品」「ステータスが完了の注文」なら簡単に検索できるが、「バッテリーについての不満が書かれたレビュー」「怒りの口調のチケット」を直接検索することはできない。これは文章の意味を理解する必要があるからで、データベースはそもそも意味を理解しない。以前はこうした「意味ベース」の分析をするには、データを外部に取り出し、専用の AI パイプラインに通し、結果をまた取り込むしかなかった。遅い上に自前でパイプラインを保守する必要もあった。

今回 AlloyDB が実現したのは、Gemini の理解力を一連の SQL 関数（つまり AI 関数）として作り込み、データベース本体に組み込むことだ。これにより、1行の普通の SQL の中で「意味」の判断を書き下せるようになり、データベース自身がそれを理解し、条件に合う行を選び出す。データを一切外部に移す必要がない。

これが今回のアップデートの意義だ：データベースが「文字通りの完全一致しかできない」ものから、「意味でクエリできる」ものへと進化し、しかもセマンティック検索、構造化クエリ、AI 判断がすべて同じ SQL の層で完結するようになった。能力は大きく広がったが、新たな問題も生んだ：1行ごとに大規模モデルを呼んでいては、行数が増えるほど遅く高くつく。だからこそ今回の発表の本当の見どころは、これらの関数そのものではなく、それらをいかに「強く、速く、安く」するかという点にある。

今回具体的に追加された AI 関数

まずこの AI 関数一式が何をできるのかを見てみよう。最もわかりやすい使い方の一つは、雑然として解析しづらい生テキストを、SQL の中でそのまま構造化された検索可能なデータに変換することだ。

例えば ai.generate を使って1行のエラーログを自動で構造化フィールドに分解する場合：

雑然としたログ1行が、エラーコード・サービス名・根本原因という3つのフィールドに自動分解され、そのまま検索・絞り込みが可能になる。今回新たに追加されたのは以下の3つの関数だ：

• ai.analyze_sentiment：文章の感情がポジティブ・ネガティブ・中立のどれかを判定する。
• ai.summarize：長文を要約し、原文の語調とニュアンスを保つ。
• ai.agg_summarize：集約関数。複数行のコンテンツ（GROUP BY と組み合わせて使用）を1つの統一した要約にまとめる。

これに既に GA 済みの ai.generate、ai.rank、ai.if、ai.forecast を合わせたものが、この AI 関数一式の全体像だ。例えば ai.agg_summarize は、ある商品のレビュー群を1本の総評にまとめられる：「多くのユーザーが 4K 画質、120Hz フレームレート、人間工学に基づいたコントローラーを高く評価している。一方で長時間プレイ時のファンノイズが大きいという不満も見られる。全体としては最上級の据え置き機で、発熱とノイズは小さな瑕疵にとどまる。」

これまでなぜ遅く高コストだったのか

大規模モデルの判断力を表全体に適用する最も素直な方法は、全行に対して1回ずつモデルを呼び出すことだ。しかし行数が増えると、この方法は破綻する。

InfoQ はこの問題を具体的に説明している：10万件の商品を持つ1つのテーブルに全表判断を1回行うと、それだけで Vertex AI への往復通信が10万回発生する。しかも毎回同じシステムプロンプトを一緒に送り、毎回モデルの推論を待ち、毎回トークン数に応じて課金される。

数値は Google の今年5月の技術ブログによるものだ。結論は明快：運用系データベースにとってこの速度は遅すぎる。分析シナリオにとっては、コストが高すぎて多くの全表セマンティック分析はそもそも実行できない。

Google はこの壁を2つの手法で突破した。まず全体像を見て、これらの手法が1行ずつの呼び出しとどう違うのかを把握しよう。右に行くほど、クラウドの大規模モデルへの依存が減り、より速く安くなる：

以下、この2つの手法を個別に見ていこう。

手法1：多くの行を1回の呼び出しにまとめる

スマートバッチ処理（Smart Batching）の発想はシンプルだ：毎回同じシステムプロンプトを送っているのなら、多くの行を1つのリクエストにまとめて、そのプロンプトを1回だけ送信すればいい。

なぜアプリケーション層で自前でバッチ処理をしないのか？バッチサイズの見極めが非常に難しいからだ。小さく見積もれば、コストやレイテンシはさほど削減できない。大きく見積もれば、詰め込むプロンプトが膨れ上がり、幻覚を誘発したりモデルのトークン上限を超えたりしかねない。AlloyDB はリクエストごとの最適なバッチサイズを自動で算出し、リトライも自動で処理する。

数値制約を理解できる点も見逃せない。単に意味が近いものを探すだけではない。例を挙げよう：ユーザーがデジタル商品モールで「水深60メートル以上に潜れる」カメラを探しているとする。通常のハイブリッド検索は意味とキーワードで最も近いものを探すだけで、数値的なハード制約を捉えられず、水深20メートルまでしか対応していない製品を推薦してしまうかもしれない。ai.if でスマートフィルタリングを行えば、データベースは「深さ」という制約を本当に理解し、条件を満たす、あるいは上回る製品だけを返す。ai.if を使う場合、バッチサイズを自分で指定する必要もない。AlloyDB が裏側で最適化をすべて行っている。

手法2：データベース自身が判断用の代役モデルを訓練する

バッチ処理が削減するのは重複するオーバーヘッドだ。プロキシモデル（proxy model）はさらに一歩踏み込む：データベース自身にローカルで動く小型モデルを訓練させ、判断の大部分を引き継がせる。もはや大規模モデルに問い合わせる必要すらなくなる。

プロキシモデルは、ある特定の問題と特定のデータに向けて専用に訓練された小型モデルであり、「Yes / No」のような判定問題にのみ高速に答える。判断できない問題に遭遇した場合は、自動的に大規模モデルへ処理を回す。

全体のフローは2段階：まず訓練、次に実行

これは2つの SQL 文で役割分担する：PREPARE がバックグラウンドでモデルの訓練を担当し、EXECUTE が訓練済みモデルを使ってオンラインクエリを実行する。

訓練はバックグラウンドの PREPARE 段階で行われ、このステップの大規模モデルのコストは1回限りだ。オンラインの EXECUTE 段階では、訓練済みのローカルモデルでそのまま判断する。モデルの確信度が低い場合、あるいは対応するモデルが見つからない場合にのみ、自動的に大規模モデルの呼び出しにフォールバックして処理を担保する。以下は公式が示す2段階の SQL 例だ：

-- 第一阶段：用数据样本 + 云端大模型，训练本地代理模型
PREPARE underwater_suitability_proxy FROM
SELECT description FROM products;

-- 第二阶段：用本地代理模型，以数据库速度执行查询
SELECT * FROM products
WHERE ai.if(description, 'suitable for underwater use deeper than 60 meters')
USING proxy(underwater_suitability_proxy);

2つ目の文にある英語の判定条件 suitable for underwater use deeper than 60 meters は、「水深60メートル以下での水中使用に適している」という意味で、これが先ほどの水中カメラが満たすべき判定条件だ。

InfoQ はこのパターンを、データベースと大規模モデルの関係の逆転として要約している：以前はデータベースがクライアントで、判断を1回行うたびに外部モデルを1回呼び出していた。今はデータベースがまるで生徒のようになり、まず一連のサンプルでモデルがどう判断するかを学び、その後データベース本来の速度でローカルに適用する。大規模モデルの役割は、クエリのたびに依存されるランタイムから、訓練時にのみ登場する教師へと変わった。

この代役モデルはなぜ意味を理解できるのか

ロジスティック回帰というこれほどシンプルなモデルが、なぜ「ストーリーが面白い」といった意味を読み取れるのか。鍵は、入力するのが生のテキストではなく、すでに意味情報を帯びたベクトル埋め込みだという点にある。

この2つをつなげて考えると：Gemini や Gecko といった埋め込みモデルは、ベクトルを生成する時点で「面白いストーリー」「優れた撮影」「退屈」「つまらない」といった意味概念を、ベクトルの異なる次元の組み合わせにエンコードしている（「撮影」専用の次元が単独で存在するとは期待しないでほしい）。ロジスティック回帰を訓練するというのは、これらの埋め込みが構成する（超）球面上に平面を1つ切り込み、意味を2つに分けることに相当する：片側は TRUE、もう片側は FALSE と判定される。平面をどの方向に切るかは、訓練時に大規模モデルがサンプルに付けたラベルによって決まる。

これは Google のブログにある代表的な模式図でもある。緑色の平面が青色の埋め込み球面を切り分けている：

プロキシモデル（緑色の平面）は埋め込み空間（青色の球面）を切り分けることで、タスクに関連する意味を隔てている。図：Google Cloud

これを踏まえると、超低レイテンシと低コストの理由も理解しやすくなる：埋め込みは1回だけ生成され、以降のクエリはそれを繰り返し再利用する。意味をデータに持ち込むというコストは1回限りの支出に圧縮される。そしてロジスティック回帰そのものは一般的な CPU 上で動作し、専用ハードウェアを必要としない。

どれくらい正確か？どんな場合にうまくいかないか

プロキシモデルは一種の近似手法であり、能力は大規模モデルよりも制限される。埋め込みの意味パターンだけで判断できる問題では良好な性能を発揮するが、複雑な推論やサンプルが極端に偏っているケースには向かない。

まず精度について。SIGMOD 2026 論文は10種のベンチマークで比較し、プロキシモデルの F1 は大規模モデルの F1 の90%〜102%だった。Amazon レビューの感情分類テストでは、プロキシモデルの F1 が0.860に達し、大規模モデルの0.739を上回った。つまり116%だ。論文が示す説明はこうだ：プロキシモデルは一連のサンプルで訓練されており全体像を把握している一方、大規模モデルは各行を毎回まったく新しい問題として一から判断している。

F1 スコアは0から1の値を取り、「判定の正確さ」と「該当するものを漏れなく見つけられているか」を同時に測る指標で、1に近いほど良い。以下は論文で公開されているいくつかの具体的なテスト結果だ。

次に、どんな場合にうまくいかないか。主に2つのシナリオがある：

もう1つ混同しやすい点：プロキシモデルはベクトル検索とイコールではない。プロキシモデルは分類器であり、各行に TRUE / FALSE（あるいは何らかのカテゴリ）を判定する。一方ベクトル検索がやっているのは別のことで、汎用的な距離関数（例えばコサイン距離）で結果に順位をつける。しかもプロキシモデルは、あなたの具体的なデータと具体的な問題に向けて訓練されたものであり、ベクトル検索だけで ai.if を模倣しようとしても、うまく構築するのは難しく効果も落ちる。この2つは別物だ。

データ規模が大きいほど、優位性が際立つ

プロキシモデルによるコストと時間の節約効果は一定ではない：データ量が多いほど優位性が際立つ。訓練は1回限りなので、そのコストは以降のクエリすべてに分散され、クエリすればするほど割に合う。

論文が示すオンライン訓練シナリオ（BigQuery）のデータは以下の通り：

規模が百万行から数千万行に増えると、コスト削減幅とレイテンシの高速化幅がともに拡大する。AlloyDB に当てはめると、この論理はさらに有利に働く：PREPARE 段階の大規模モデルのコストは、以降何回でも実行されるクエリに分散できる。事前に用意したモデルが多く使われるほど、1回あたりのコストは下がる。以下の図は SIGMOD 2026 論文によるもので、横軸はテーブルの規模、コスト削減幅とレイテンシ高速化幅は規模とともに右肩上がりに増加し、数千万行時点で約600倍のコスト、約300倍のレイテンシに近づく：

コスト削減幅（トークン消費量）とレイテンシ高速化幅（クエリ高速化）はテーブル規模の拡大とともに増加し、1000万行時点で約600倍のコスト／300倍のレイテンシとなる。図：Google Cloud / SIGMOD 2026 論文

現状どこまで使えるのか、他のデータベースにとって何を意味するのか

この一連の機能が現状どこまで使えるかを見るには、何が GA 済みで何がまだプレビュー段階なのかを区別する必要がある。

プロキシモデルを使うには、手動でデータベースのスイッチ（google_ml_integration.enable_ai_function_acceleration）をオンにする必要がある。デフォルトはオフだ。InfoQ も注意を促している：23,000倍、6,000倍といった数値は社内テストの数値であり、プレビュー中の ai.if にのみ当てはまるもので、すべての AI 関数の一般的な性能を代表するものではない。本番導入前には自分のデータ分布とクエリパターンで実測すべきだ。

実務者はどう使っているか

Starburst のアーキテクト Raimundas Juodvalkis 氏は LinkedIn で1つの位置づけを示した：これらを「ガバナンスの効いたデータベース拡張機能」として扱うべきで、「魔法の WHERE 句」ではないと。彼が挙げた3つの助言は以下の通り：

• まず読み取り中心のレビュー分析シナリオから始め、いきなり重い処理に使わないこと。
• モデルから派生したフィールドをコアシステムに書き戻す前には慎重を期すこと。
• モデルのコストとクエリのコストは別々に追跡すること。

他のデータベースにとって何を意味するのか

InfoQ は、行ごとの判断のたびに外部モデルを呼び出すあらゆるデータベースが、同じコストとレイテンシの壁にぶつかっていると指摘する。Aurora、Azure SQL、CockroachDB、PlanetScale といった競合が同様の「クエリ時蒸留」方式を追随させるのか、それとも引き続きユーザー自身にアプリケーション層でこの最適化を構築させるのか、現時点ではまだ不明だ。

今回の発表では、AlloyDB はマネージド MCP サーバーも用意し、AI エージェントが Model Context Protocol（AI が外部のツールやデータを直接呼び出せるオープンプロトコル）経由でデータベースの内容にクエリをかけられるようにした。自前で MCP インフラを構築する必要はない。さらに既存の ScaNN ベクトルインデックス（最大100億ベクトルに対応）も加わる。InfoQ は、AlloyDB が構造化クエリ、セマンティック検索、AI 判断を同じ SQL の層に共存させる PostgreSQL 互換データベースとしての立ち位置を築こうとしていると見ている。