BigQuery の自律型埋め込み生成（Autonomous Embedding Generation）を試してみた

こんにちは！エノカワです。

RAG やセマンティック検索を BigQuery で実現しようとすると、テキストを埋め込みベクトルに変換する処理が必要になります。
AI.EMBED 関数を使えば SQL でベクトル化できますが、データが追加・更新されるたびに埋め込みを再計算する運用は意外と手間がかかります。

2026 年 6 月 17 日、BigQuery に 自律型埋め込み生成（Autonomous Embedding Generation） が GA となりました。

• BigQuery release notes > June 17, 2026

Autonomous embedding generation is now generally available (GA).

CREATE TABLE や ALTER TABLE の時点で埋め込み列を宣言しておくだけで、ソース列への INSERT / UPDATE に合わせて BigQuery が非同期で埋め込みを生成・更新してくれる機能です。
生成された埋め込み列に対しては AI.SEARCH によるセマンティック検索もそのまま使えます。

今回は、この自律型埋め込み生成を日本語のサンプルデータで実際に試してみましたので、その内容をご紹介します。

なお、BigQuery の AI 関数全般については以前、カテゴリ別に整理した記事を執筆しています。
埋め込み・類似カテゴリの AI.EMBED や AI.SEARCH の位置づけも、そちらで触れています。

https://dev.classmethod.jp/articles/bigquery-ai-functions-overview/

自律型埋め込み生成とは

自律型埋め込み生成は、ソース列（STRING または ObjectRef）をもとに、埋め込み列を BigQuery が自動で維持する仕組みです。

テーブル定義時に次のような生成列（Generated Column）を宣言します。

description_embedding STRUCT<result ARRAY<FLOAT64>, status STRING>
  GENERATED ALWAYS AS (
    AI.EMBED(description, model => 'embeddinggemma-300m')
  ) STORED OPTIONS(asynchronous = TRUE)

asynchronous = TRUE を指定すると、ソース列へのデータ追加・変更をトリガーに、バックグラウンド DML ジョブで埋め込みが非同期生成されます。
INSERT 時に埋め込み列を明示的に指定する必要はありません。

生成される埋め込み列の型は STRUCT<result ARRAY<FLOAT64>, status STRING> です。
result にベクトル本体、status に行ごとの生成結果（エラー時はメッセージ）が入ります。

• Autonomous embedding generation | BigQuery

従来方式との違い

以前の AI 関数整理記事 では、AI.SIMILARITY を使ってクエリ実行のたびに類似度を計算しました。
自律型埋め込み生成は、ベクトルをテーブルに永続化し、データ更新に追従させる点が大きな違いです。

埋め込みモデルの2つの指定方法

AI.EMBED では、埋め込みの生成先として 2 つの方式 から選びます。
公式ドキュメントでは、ビルトインモデル（built-in model）と Agent Platform エンドポイントの 2 種類が用意されています。

model と connection_id / endpoint は同時に指定できません。
ビルトインモデル以外（text-embedding-005 や画像向けの multimodalembedding@001 など）を使いたいときに、Cloud リソース接続の作成が必要になります。

環境準備

今回の主デモではビルトインモデルを使うため、Cloud リソース接続の作成は不要です。
BigQuery でデータセットを作成・クエリ実行できる環境があれば、そのまま試せます。

前提

• BigQuery でデータセットを作成できる権限（roles/bigquery.dataEditor など）

テーブルを作成する

検証用のデータセットと、日本語の商品説明を持つテーブルを作成します。

CREATE SCHEMA IF NOT EXISTS embedding_demo;

CREATE TABLE embedding_demo.products (
  name STRING,
  description STRING,
  description_embedding STRUCT<result ARRAY<FLOAT64>, status STRING>
    GENERATED ALWAYS AS (
      AI.EMBED(description, model => 'embeddinggemma-300m')
    ) STORED OPTIONS(asynchronous = TRUE)
);

テーブル作成直後は、埋め込み列はまだ空の状態です。
バックグラウンドジョブが走り始めるのは、ソース列にデータが入ってからです。

データを投入する

INSERT ではソース列（name, description）だけを指定します。
description_embedding は指定不要で、BigQuery が非同期で生成します。

同様に、既存行の description を UPDATE した場合も、変更された行の埋め込みが非同期で再生成されます。

INSERT INTO embedding_demo.products (name, description) VALUES
  ('リラックスチェア', 'くつろげる快適な椅子です。'),
  ('スーパースリンガーズ', '家族みんなで楽しめるボードゲームです。'),
  ('百科事典セット', '知識を深めるための参考書のセットです。'),
  ('ぬいぐるみセット', '子どもが喜ぶかわいいぬいぐるみの詰め合わせです。'),
  ('学習タブレット', '小学生向けの知育アプリがプリインストールされたタブレットです。');

例えば、説明文を更新する場合は次のように UPDATE します。埋め込み列は指定しません。

UPDATE embedding_demo.products
SET description = '家族全員で盛り上がれるパーティーゲームです。'
WHERE name = 'スーパースリンガーズ';

更新後も進捗確認クエリで、対象行の埋め込みが再生成されたことを確認できます。

埋め込み生成の進捗を確認する

非同期生成の進捗は、次のクエリで確認できます。

SELECT
  COUNT(*) AS total,
  COUNTIF(description_embedding IS NOT NULL
          AND description_embedding.status = '') AS generated
FROM embedding_demo.products;

5 行すべてで status が空文字（正常生成）となれば完了です。
執筆環境では、INSERT から完了まで 約 1〜2 分 程度かかりました（行数・リージョンにより変動します）。

生成前後の状態を確認したい場合は、個別行を SELECT してみます。

SELECT
  name,
  description,
  description_embedding.status AS embed_status,
  ARRAY_LENGTH(description_embedding.result) AS vector_dim
FROM embedding_demo.products;

vector_dim は、埋め込みベクトルの次元数（description_embedding.result 配列の長さ）です。
embeddinggemma-300m では 768 次元で、テキストが 768 個の数値からなるベクトルに変換されたことを示します。
次元数はモデルごとに決まっており、次元数の大小が直接的に精度の高低を決めるわけではありません。

status に値が入っている行は、その行だけ生成に失敗しています。
正常生成時は embed_status が空のまま表示されます（上表のとおり）。
ソース列が NULL の場合は NULL value is not supported for embedding generation などのメッセージが入ります。

セマンティック検索（AI.SEARCH）

埋め込みが生成されたテーブルに対して、AI.SEARCH でセマンティック検索ができます。
今回は ベクトルインデックスなし で試します（小規模データならそのまま動作します）。

SELECT base.name, base.description, distance
FROM AI.SEARCH(
  TABLE embedding_demo.products,
  'description',
  '家族で楽しめるおもちゃ'
);

実行結果は以下のとおりでした。

distance は小さいほど意味的に近いことを表します。
検索クエリに「おもちゃ」という言葉は出てきませんが、1 位の「家族みんなで楽しめるボードゲーム」、2 位の「ぬいぐるみ」が上位に来ており、キーワード一致ではなく意味的な近さで並んでいることが分かります。
一方で、百科事典セットは 5 位で最も distance が大きく、検索意図から遠い結果になっています。

検索語を変えると順位も変わる

同じテーブルでも、検索語を変えると 1 位の商品が変わります。
先ほどの「おもちゃ」検索と対比しやすいよう、別の意図でも試してみます。

まず「くつろげる家具」で検索します。

SELECT base.name, base.description, distance
FROM AI.SEARCH(
  TABLE embedding_demo.products,
  'description',
  'くつろげる家具'
);

1 位だったスーパースリンガーズが 3 位に下がり、リラックスチェアが 1 位になりました。

次に「小学生の宿題や学習に使えるもの」で検索します。
先ほどの「おもちゃ」検索では 4 位だった学習タブレットが 1 位に来ています。

SELECT base.name, base.description, distance
FROM AI.SEARCH(
  TABLE embedding_demo.products,
  'description',
  '小学生の宿題や学習に使えるもの'
);

検索語ごとの 1 位をまとめると次のとおりです。

いずれもキーワードの完全一致ではなく、説明文の意味に基づいて順位が決まっていることが分かります。

ベクトルインデックス（任意）

データ量が増える場合は、埋め込み列にベクトルインデックスを作成すると検索が高速化されます。

CREATE VECTOR INDEX products_index
ON embedding_demo.products(description_embedding)
OPTIONS(index_type = 'IVF');

インデックスのトレーニングは、全行の 80% 以上で埋め込みが生成された後 に開始されます。
今回の 5 行規模の検証では必須ではありませんが、数千行以上のデータセットや検索レイテンシが重要な用途では、ベクトルインデックスの導入を検討する価値があります。

• Introduction to vector search | BigQuery

Agent Platform モデルを使う場合

ビルトインモデル以外の埋め込みモデルを使う場合は、Cloud リソース接続が必要です。
例えば次のようなケースです。

• text-embedding-005 など、GA の埋め込みモデルを使いたい
• ObjectRef 列から画像の埋め込みを生成したい（multimodalembedding@001 など）

SQL は次のように connection_id と endpoint を指定します。
以下は接続あり方式の別テーブル定義例です（検証で使った products とは別名にしています）。

CREATE TABLE embedding_demo.catalog_items (
  name STRING,
  description STRING,
  description_embedding STRUCT<result ARRAY<FLOAT64>, status STRING>
    GENERATED ALWAYS AS (
      AI.EMBED(
        description,
        connection_id => 'PROJECT_ID.asia-northeast1.ai-embed-connection',
        endpoint => 'text-embedding-005'
      )
    ) STORED OPTIONS(asynchronous = TRUE)
);

接続の作成手順と、接続のサービスアカウントへの roles/aiplatform.user 付与については、以前執筆した AI.AGG 記事で詳しく紹介しています。

https://dev.classmethod.jp/articles/bigquery-ai-agg/

接続を使う場合、クエリを実行する側には roles/bigquery.connectionUser も必要です。
権限不足だと INFORMATION_SCHEMA.COLUMNS の async_generation_status に blocking error が記録され、埋め込み生成全体が止まります。

• Permissions for AI functions | BigQuery

既存テーブルへの追加（ALTER TABLE）

すでにデータがあるテーブルにも、後から自律型埋め込み列を追加できます。

ALTER TABLE embedding_demo.products
  ADD COLUMN description_embedding_alt
    STRUCT<result ARRAY<FLOAT64>, status STRING>
    GENERATED ALWAYS AS (
      AI.EMBED(description, model => 'embeddinggemma-300m')
    ) STORED OPTIONS(asynchronous = TRUE);

ALTER TABLE 実行後、既存行に対してもバックグラウンドで埋め込み生成が始まります。
新規テーブル作成と同様、進捗確認クエリで完了を待ってから AI.SEARCH を使います。

運用上のポイント

向いているケース

• 商品カタログ・FAQ・社内ドキュメントなど、テキストが定期的に追加・更新されるデータ
• RAG の前処理として、BigQuery 内で埋め込みを一元管理したい場合
• Composer 等の別ジョブで埋め込みパイプラインを組みたくない場合

注意が必要なケース

公式ドキュメントに記載されている主な制限は以下のとおりです。

• ソース列は drop / rename 不可（埋め込み列を先に drop すればソース列の drop は可能）
• 生成列への直接書き込み不可（DML、ストリーミング、bq load など）
• 列レベルセキュリティ（ポリシータグ）非対応
• 埋め込み未生成の行は AI.SEARCH / VECTOR_SEARCH でスキップされる

モデル方式の選び方

ビルトインモデルはデータが BigQuery 外に送信されず、Agent Platform の API 課金も発生しません。
一方、Agent Platform 方式はクォータの影響を受けるため、生成が遅い場合は クォータ引き上げ を検討してください。

コスト

ビルトインモデルを使う場合、課金は主に BigQuery バックグラウンド DML（オンデマンドスロット、または job_type = BACKGROUND の予約）です。
Agent Platform モデルを使う場合は、Agent Platform の API 呼び出し料金が加算されます。

まとめ

以上、BigQuery の自律型埋め込み生成を、接続不要のビルトインモデルで日本語データに試してみました。

CREATE TABLE 時に GENERATED ALWAYS AS (AI.EMBED(...)) STORED OPTIONS(asynchronous = TRUE) で埋め込み列を宣言しておけば、ビルトインモデル（embeddinggemma-300m）なら接続なしで INSERT 後に BigQuery が非同期で埋め込みを生成します。
生成が完了したテーブルに対しては、そのまま AI.SEARCH でセマンティック検索も試せました。
text-embedding-005 など別のモデルを使う場合は、Cloud リソース接続が必要になる点だけ押さえておけば十分だと感じました。

RAG や類似検索の前処理を BigQuery に寄せたい方は、まずビルトインモデルで仕組みを試し、接続ありの Agent Platform モデルへ切り替える、という進め方が現実的だと感じました。

参考

• Autonomous embedding generation | BigQuery | Google Cloud Documentation
• BigQuery release notes > June 17, 2026
• The AI.EMBED function | BigQuery | Google Cloud Documentation
• The AI.SEARCH function | BigQuery | Google Cloud Documentation
• Permissions for AI functions | BigQuery | Google Cloud Documentation
• Introduction to vector search | BigQuery | Google Cloud Documentation
• BigQuery の AI 関数を自分なりに整理してみた | DevelopersIO
• BigQuery の AI.AGG 関数で非構造化データを意味的に集約してみた | DevelopersIO