顧客レビューが BigQuery のテーブルにある。これを Gemini に読ませたい。でも、アプリケーションは書きたくない。
BigQuery のリモートモデルを使えば、ML.GENERATE_TEXT という SQL 関数 1 つで、テーブルの各行を Gemini に渡して結果を受け取れます。当記事では、コーヒーショップの顧客レビュー 50 件と画像 5 枚を題材に、キーワード抽出、感情分析、返信文の生成、画像の要約までを SQL だけで実行します。自分の Google Cloud プロジェクトで実際に動かした結果と、その過程で見つかった注意点をあわせて解説します。
概要
SQLからGeminiを呼び出すということ
生成 AI をデータ分析に組み込む場合、通常はテーブルからデータを取り出し、アプリケーションで API を呼び出し、結果をテーブルに書き戻すという往復が必要です。BigQuery のリモートモデルは、この往復を SQL の中に閉じ込めます。
仕組みは 3 つの要素で構成されます。
| 要素 | 役割 |
|---|---|
| Cloud リソース接続 | BigQuery が Agent Platform（旧 Vertex AI）や Cloud Storage にアクセスするための ID（サービスアカウント） |
| リモートモデル |
CREATE MODEL … REMOTE WITH CONNECTION で作成する、Gemini を指すモデル |
ML.GENERATE_TEXT |
テーブルの各行のプロンプトをモデルに送り、結果を列として返す関数 |
画像を扱う場合は、さらにオブジェクトテーブルを使います。Cloud Storage 上のファイルを、BigQuery のテーブルとして参照できるようにする仕組みです。
当記事は、BigQuery の基本的な SQL と gcloud / bq コマンドの操作を前提としています。
構築するもの
Cloud Storage（customer_reviews.csv、画像 5 枚）
│ LOAD DATA / CREATE EXTERNAL TABLE
▼
BigQuery テーブル customer_reviews オブジェクトテーブル review_images
│ │
└──────────── ML.GENERATE_TEXT ───────┘
│ Cloud リソース接続 us.gemini_conn
▼
リモートモデル gemini_flash（gemini-3.5-flash）
│
┌──────────┬─────────┼──────────┬──────────────┐
▼ ▼ ▼ ▼ ▼
キーワード 感情分析 マーケティング カスタマー 画像の要約と
返信 サービス返信 キーワード
題材とデータの出典
当記事の題材は、Google Skills のラボ「Analyze Customer Reviews with Gemini Using SQL」（ID: GSP1246）です。ラボは一時的なプロジェクトで動作しますが、当記事では同じ内容を自分のプロジェクトで実行しました。
出典：ラボで使用されている Google 提供のサンプルデータ（gs://spls/gsp1246/）です。2026年9月の執筆時点では、認証なしで読み取れることを確認しました。ただしライセンスは明記されていないため、当記事ではファイル自体は再配布せず、取得元のパスと手順のみを記載しています。
| オブジェクト | 内容 |
|---|---|
gsp1246/customer_reviews.csv |
顧客レビュー 50 件（ヘッダなし、7 列） |
gsp1246/images/*.png |
レビューに添付された想定の画像 5 枚 |
事前準備
環境
- 課金が有効な Google Cloud プロジェクト
- Cloud Shell、または
gcloudとbqの認証が済んだローカルシェル - 2026年9月現在、Agent Platform の API 名は
aiplatform.googleapis.comのままです。ラボが「Agent Platform ユーザー」と呼ぶ IAM ロールも、ロール ID はroles/aiplatform.userのままです
gcloud services enable \
bigquery.googleapis.com \
bigqueryconnection.googleapis.com \
aiplatform.googleapis.com \
storage.googleapis.com
新規プロジェクトで不足しがちなのは bigqueryconnection.googleapis.com です。これがないと接続の作成で失敗します。
変数の設定
export PROJECT_ID=$(gcloud config get-value project)
export BQ_LOCATION="US"
export BUCKET="${PROJECT_ID}-reviews"
ロケーションはすべてUSに揃える
接続、データセット、リモートモデルは同じロケーションにある必要があります。当記事ではすべて US マルチリージョンで作成します。オブジェクトテーブルは接続を通してバケットを読むため、バケットも US にしておくと、ロケーションの不一致を気にせずに済みます。
データの準備
サンプルデータをバケットにコピーする
gcloud storage buckets create "gs://${BUCKET}" \
--location="${BQ_LOCATION}" \
--uniform-bucket-level-access
gcloud storage cp -r gs://spls/gsp1246 "gs://${BUCKET}/"
ラボと同じ gsp1246/ の構成でコピーされるため、以降の SQL はバケット名だけを変えれば動きます。
図1 コピー後のバケット。gsp1246/ の下に customer_reviews.csv と images/ が並ぶ。赤枠：コピーした CSV と画像フォルダ
コピー先のバケットは公開されていないことも確認しておきます。均一なバケットレベルのアクセスが有効で、allUsers / allAuthenticatedUsers のバインディングはなく、認証なしのアクセスは 403 になりました。
Cloud リソース接続とIAM
接続を作成する
bq mk --connection \
--location="${BQ_LOCATION}" \
--connection_type=CLOUD_RESOURCE \
gemini_conn
接続を作成すると、Google が管理するサービスアカウントが自動で作られます。以降の権限付与に使うため、ID を取得します。
export CONN_SA=$(bq show --format=json --connection "${PROJECT_ID}.us.gemini_conn" \
| jq -r '.cloudResource.serviceAccountId')
echo "${CONN_SA}"
bqcx-<プロジェクト番号>-xxxx@gcp-sa-bigquery-condel.iam.gserviceaccount.com の形式の ID が返ります。
図2 接続情報。接続タイプは「Agent Platform リモートモデル、リモート関数、Lakehouse、Spanner（Cloud リソース）」。赤枠：自動で作成されたサービスアカウント ID
詳細：公式ドキュメント（Cloud リソース接続を作成して設定する）
2つのロールを付与する
接続のサービスアカウントには、2 つの権限が必要です。
| 付与先 | ロール | 目的 |
|---|---|---|
| プロジェクト |
roles/aiplatform.user（Agent Platform ユーザー） |
Gemini を呼び出す |
| バケット |
roles/storage.objectViewer（Storage オブジェクト閲覧者） |
オブジェクトテーブル経由で画像を読む |
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
--member="serviceAccount:${CONN_SA}" \
--role="roles/aiplatform.user" \
--condition=None
gcloud storage buckets add-iam-policy-binding "gs://${BUCKET}" \
--member="serviceAccount:${CONN_SA}" \
--role="roles/storage.objectViewer"
ラボではバケットに Storage オブジェクト管理者を付与しますが、今回の処理は読み取りだけです。**オブジェクト閲覧者で、オブジェクトテーブルの作成も Gemini による画像の分析も問題なく動作しました。**最小権限の原則に従い、閲覧者で十分です。
図3 IAM 画面。bqcx- でフィルタすると、接続のサービスアカウントだけが表示される。赤枠：付与した Agent Platform ユーザー ロール
IAM の変更が反映されるまで 1〜2 分かかることがあります。
データセットとテーブルの作成
以降の SQL は、BigQuery Studio のクエリエディタでも、bq query --use_legacy_sql=false でも実行できます。
データセット
bq --location="${BQ_LOCATION}" mk --dataset "${PROJECT_ID}:gemini_demo"
レビューをテーブルに読み込む
LOAD DATA OVERWRITE gemini_demo.customer_reviews
(customer_review_id INT64, customer_id INT64, location_id INT64, review_datetime DATETIME, review_text STRING, social_media_source STRING, social_media_handle STRING)
FROM FILES (
format = 'CSV',
uris = ['gs://YOUR_BUCKET/gsp1246/customer_reviews.csv']);
CSV にはヘッダ行がないため、列名と型を LOAD DATA の中で指定しています。
図4 customer_reviews のスキーマ。赤枠：LOAD DATA で指定した 7 列と型
読み込み後に件数と内容を確認しました。
SELECT
COUNT(*) AS n,
COUNT(DISTINCT customer_id) AS customers,
COUNTIF(ENDS_WITH(social_media_handle, "\r")) AS trailing_cr
FROM gemini_demo.customer_reviews;
n = 50, customers = 50, trailing_cr = 0
この CSV の改行コードは CRLF（\r\n）です。シェルで 1 行ずつ処理すると最終列に \r が残りますが、BigQuery の CSV 読み込みは CRLF を正しく扱い、\r は残りませんでした。
画像のオブジェクトテーブルを作成する
CREATE OR REPLACE EXTERNAL TABLE
`gemini_demo.review_images`
WITH CONNECTION `us.gemini_conn`
OPTIONS (
object_metadata = 'SIMPLE',
uris = ['gs://YOUR_BUCKET/gsp1246/images/*']
);
オブジェクトテーブルが保持するのは、URI、サイズ、コンテンツタイプなどのメタデータだけです。画像のバイト列そのものはテーブルに入りません。Gemini が画像を読むときは、接続のサービスアカウントの権限で Cloud Storage から直接取得します。バケットへの権限が必要なのはこのためです。
SELECT uri, content_type, size
FROM gemini_demo.review_images
ORDER BY uri;
図5 オブジェクトテーブルの中身。5 枚の画像の URI とサイズが並ぶ。赤枠：コンテンツタイプ image/png
Geminiのリモートモデルを作成する
CREATE OR REPLACE MODEL `gemini_demo.gemini_flash`
REMOTE WITH CONNECTION `us.gemini_conn`
OPTIONS (endpoint = 'gemini-3.5-flash');
**ラボの SQL をそのまま実行してはいけない箇所です。**ラボのページでは endpoint = 'model_id | disablehighlight' と表示されますが、これはページのテンプレートの変数が漏れ出たもので、実在するモデル ID ではありません。
モデルは、BigQuery がサポートするモデルの一覧から選びます。当記事では gemini-3.5-flash を使用しました。2026年9月時点で、モデルバージョンのページでは退役日が「2027年5月19日以降」とされています。一方、gemini-2.5-flash は 2026年10月20日に退役予定です。これから記事や手順書を書く場合は、退役日を確認してからモデルを選んでください。
図6 リモートモデルの詳細。モデルタイプは「Unknown」と表示されるが、リモートモデルとしては正常。赤枠：リモートエンドポイント
CLI で確認する場合は、--model フラグが必要です。付けないと bq show はテーブルを探し、Not found になります。
bq show --model --format=prettyjson "${PROJECT_ID}:gemini_demo.gemini_flash"
詳細：公式ドキュメント（リモートモデルの CREATE MODEL ステートメント・英語）、公式ドキュメント（モデルのバージョンとライフサイクル）
キーワードと感情を分析する
キーワード抽出
ML.GENERATE_TEXT に渡すクエリで、行ごとに prompt 列を組み立てます。
CREATE OR REPLACE TABLE
`gemini_demo.customer_reviews_keywords` AS (
SELECT ml_generate_text_llm_result, social_media_source, review_text, customer_id, location_id, review_datetime
FROM
ML.GENERATE_TEXT(
MODEL `gemini_demo.gemini_flash`,
(
SELECT social_media_source, customer_id, location_id, review_text, review_datetime, CONCAT(
'For each review, provide keywords from the review. Answer in JSON format with one key: keywords. Keywords should be a list.',
review_text) AS prompt
FROM `gemini_demo.customer_reviews`
),
STRUCT(
0.2 AS temperature, TRUE AS flatten_json_output)));
50 件の処理は、ジョブとしては数秒で完了しました（ラボの記載は約 30 秒）。失敗した行は 0 件です。
図7 キーワード抽出の結果。赤枠：「JSON で答えて」と指示したにもかかわらず、回答が ```json のコードブロックで囲まれている
ここで回答の形式に注目してください。**50 件すべてが ```json … ``` の Markdown コードブロックで囲まれていました。**そのままでは JSON としてパースできません。後述の返信生成で LTRIM / RTRIM を使って取り除くのはこのためです。
感情分析
CREATE OR REPLACE TABLE
`gemini_demo.customer_reviews_analysis` AS (
SELECT ml_generate_text_llm_result, social_media_source, review_text, customer_id, location_id, review_datetime
FROM
ML.GENERATE_TEXT(
MODEL `gemini_demo.gemini_flash`,
(
SELECT social_media_source, customer_id, location_id, review_text, review_datetime, CONCAT(
'Classify the sentiment of the following text as positive or negative.',
review_text, "In your response don't include the sentiment explanation. Remove all extraneous information from your response, it should be a boolean response either positive or negative.") AS prompt
FROM `gemini_demo.customer_reviews`
),
STRUCT(
0.2 AS temperature, TRUE AS flatten_json_output)));
ラボは「ピリオドや余分な空白が混ざることがある」と説明しています。実際の値を TO_JSON_STRING で確認しました。空白や改行も見える形で表示されます。
SELECT TO_JSON_STRING(ml_generate_text_llm_result) AS raw_value, COUNT(*) AS n
FROM gemini_demo.customer_reviews_analysis
GROUP BY raw_value
ORDER BY n DESC;
| raw_value | n |
|---|---|
"positive" |
40 |
"negative" |
6 |
"Negative" |
3 |
"Positive" |
1 |
gemini-3.5-flash では、ピリオドや空白は混ざりませんでした。表記の揺れは大文字と小文字だけで、50 件中 4 件です。モデルやバージョンによって揺れ方は変わるため、実際の値を一度確認してからクリーニングの方法を決めるのが確実です。
クリーニング用のビュー
CREATE OR REPLACE VIEW gemini_demo.cleaned_data_view AS
SELECT
REPLACE(REPLACE(REPLACE(LOWER(ml_generate_text_llm_result), '.', ''), ' ', ''), '\n', '') AS sentiment,
REGEXP_REPLACE(REGEXP_REPLACE(REGEXP_REPLACE(social_media_source, r'Google(\+|\sReviews|\sLocal|\sMy\sBusiness|\sreviews|\sMaps)?',
'Google'), 'YELP', 'Yelp'), r'SocialMedia1?', 'Social Media') AS social_media_source,
review_text,
customer_id,
location_id,
review_datetime
FROM
gemini_demo.customer_reviews_analysis;
今回の結果に対して実際に効いたのは LOWER() です。
図8 クリーニング後のビュー。赤枠：positive / negative に揃った sentiment 列
件数のレポート
SELECT sentiment, COUNT(*) AS count
FROM `gemini_demo.cleaned_data_view`
WHERE sentiment IN ('positive', 'negative')
GROUP BY sentiment;
結果は positive 41 件、negative 9 件で、合計は 50 件です。positive / negative 以外の値はなく、WHERE 句で除外された行もありませんでした。クエリ結果の 可視化 タブを開くと、BigQuery が自動で棒グラフを作成します。
図9 可視化タブの棒グラフ。negative 9 件、positive 41 件
ソーシャルメディア別に集計すると、ネガティブなレビューの出どころに偏りがあることがわかります。
SELECT sentiment, social_media_source, COUNT(*) AS count
FROM `gemini_demo.cleaned_data_view`
WHERE sentiment IN ('positive') OR sentiment IN ('negative')
GROUP BY sentiment, social_media_source
ORDER BY sentiment, count;
| sentiment | 内訳 |
|---|---|
| negative（9） | Twitter 6、Google 2、Yelp 1 |
| positive（41） | Facebook 18、Twitter 8、Instagram 7、Google 6、TikTok 1、TripAdvisor 1 |
ネガティブ 9 件のうち 6 件が Twitter です。サンプルデータではありますが、「どのチャネルで不満が出ているか」が SQL 1 本でわかるのが、この構成の利点です。
詳細：公式ドキュメント（ML.GENERATE_TEXT 関数・英語）
レビューへの返信を生成する
マーケティング向けの返信
ポジティブなレビューを書いた顧客（customer_id = 5576）に対して、次回来店につながる返信を生成します。
CREATE OR REPLACE TABLE
`gemini_demo.customer_reviews_marketing` AS (
SELECT ml_generate_text_llm_result, social_media_source, review_text, customer_id, location_id, review_datetime
FROM
ML.GENERATE_TEXT(
MODEL `gemini_demo.gemini_flash`,
(
SELECT social_media_source, customer_id, location_id, review_text, review_datetime, CONCAT(
'You are a marketing representative. How could we incentivise this customer with this positive review? Provide a single response, and should be simple and concise, do not include emojis. Answer in JSON format with one key: marketing. Marketing should be a string.', review_text) AS prompt
FROM `gemini_demo.customer_reviews`
WHERE customer_id = 5576
),
STRUCT(
0.2 AS temperature, TRUE AS flatten_json_output)));
回答はコードブロックで囲まれているため、取り除いてから JSON の値を取り出します。
CREATE OR REPLACE TABLE
`gemini_demo.customer_reviews_marketing_formatted` AS (
SELECT
review_text,
JSON_QUERY(RTRIM(LTRIM(results.ml_generate_text_llm_result, " ```json"), "```"), "$.marketing") AS marketing,
social_media_source, customer_id, location_id, review_datetime
FROM
`gemini_demo.customer_reviews_marketing` results )
図10 マーケティング向けの返信。赤枠：次回来店時のコーヒー 1 杯無料を提案する返信文
カスタマーサービス向けの返信
ネガティブなレビューを書いた顧客（customer_id = 8844）に対して、返信文と店舗への改善アクションを生成します。プロンプトの中で、コーヒーへの不満とサービスへの不満それぞれに使う定型文を指定しています。
CREATE OR REPLACE TABLE
`gemini_demo.customer_reviews_cs_response` AS (
SELECT ml_generate_text_llm_result, social_media_source, review_text, customer_id, location_id, review_datetime
FROM
ML.GENERATE_TEXT(
MODEL `gemini_demo.gemini_flash`,
(
SELECT social_media_source, customer_id, location_id, review_text, review_datetime, CONCAT(
'How would you respond to this customer review? If the customer says the coffee is weak or burnt, respond stating "thank you for the review we will provide your response to the location that you did not like the coffee and it could be improved." Or if the review states the service is bad, respond to the customer stating, "the location they visited has been notified and we are taking action to improve our service at that location." From the customer reviews provide actions that the location can take to improve. The response and the actions should be simple, and to the point. Do not include any extraneous or special characters in your response. Answer in JSON format with two keys: Response, and Actions. Response should be a string. Actions should be a string.', review_text) AS prompt
FROM `gemini_demo.customer_reviews`
WHERE customer_id = 8844
),
STRUCT(
0.2 AS temperature, TRUE AS flatten_json_output)));
CREATE OR REPLACE TABLE
`gemini_demo.customer_reviews_cs_response_formatted` AS (
SELECT
review_text,
JSON_QUERY(RTRIM(LTRIM(results.ml_generate_text_llm_result, " ```json"), "```"), "$.Response") AS Response,
JSON_QUERY(RTRIM(LTRIM(results.ml_generate_text_llm_result, " ```json"), "```"), "$.Actions") AS Actions,
social_media_source, customer_id, location_id, review_datetime
FROM
`gemini_demo.customer_reviews_cs_response` results )
図11 カスタマーサービス向けの返信。赤枠：2 つの定型文を連結した Response と、店舗向けの Actions
このレビューは「コーヒーが薄い」と「接客が悪い」の両方に触れています。そのため Response には、指定した2 つの定型文が連結されて返りました。Actions には「接客の改善、待ち時間の短縮、コーヒーを濃く、ペストリーを新鮮に、店内レイアウトの見直し」といった、レビューの不満点に対応する改善案が並びます。
なお、ラボはこの手法を few-shot と呼んでいますが、プロンプトに含まれているのは入出力の例ではなく、返信の定型文です。厳密には、定型文を指示に埋め込んだ zero-shot のプロンプトと言えます。
画像の要約とキーワードを生成する
オブジェクトテーブルをそのまま ML.GENERATE_TEXT に渡します。
CREATE OR REPLACE TABLE
`gemini_demo.review_images_results` AS (
SELECT
uri,
ml_generate_text_llm_result
FROM
ML.GENERATE_TEXT( MODEL `gemini_demo.gemini_flash`,
TABLE `gemini_demo.review_images`,
STRUCT( 0.2 AS temperature,
'For each image, provide a summary of what is happening in the image and keywords from the summary. Answer in JSON format with two keys: summary, keywords. Summary should be a string, keywords should be a list.' AS PROMPT,
TRUE AS FLATTEN_JSON_OUTPUT)));
テキストの場合との違いは、プロンプトの渡し方です。オブジェクトテーブルには prompt 列がないため、全行に共通のプロンプトを STRUCT の中で指定します。テキストの場合は、行ごとに CONCAT でプロンプトを組み立てていました。
ラボの記載は約 3 分ですが、5 枚の処理は十数秒で完了しました。キーワードと同じ方法で JSON を取り出します。
CREATE OR REPLACE TABLE
`gemini_demo.review_images_results_formatted` AS (
SELECT
uri,
JSON_QUERY(RTRIM(LTRIM(results.ml_generate_text_llm_result, " ```json"), "```"), "$.summary") AS summary,
JSON_QUERY(RTRIM(LTRIM(results.ml_generate_text_llm_result, " ```json"), "```"), "$.keywords") AS keywords
FROM
`gemini_demo.review_images_results` results )
図12 画像の分析結果。5 枚すべてに要約とキーワードが付いた。赤枠：フードトラックの前でコーヒーを持つ女性の画像に対する要約
| 画像 | Gemini による要約（抜粋） |
|---|---|
| image_1462 | 長い茶色の髪の若い女性が紙コップのコーヒーを持って立ち、背景には客のいる黄色いコーヒーのフードトラック |
| image_1474 | 黒いハイネックの女性が黒い蓋の白い紙コップから一口飲んでいる。背景は明るい屋内 |
| image_5492 | 真上から撮影したエスプレッソ。厚いクレマと、周囲に散らばった焙煎豆 |
| image_7230 | 街中のコーヒーカートの前で、スーツの男性がコーヒーを持っている |
| image_769 | 白黒写真。コートとマフラーの人物が、黒い蓋の白い紙コップを持っている |
5 枚ともパースに失敗した行はなく、要約はいずれも画像の内容を正しく捉えていました。
落とし穴
ラボのモデル指定は実在しない値
ラボの endpoint = 'model_id | disablehighlight' は、ページのテンプレートから漏れた文字列です。そのまま実行すると失敗します。BigQuery のサポート一覧からモデルを選び、退役日も確認してください。2026年9月時点で gemini-2.5-flash は 2026年10月20日に退役予定です。
「JSONで答えて」でもコードブロックで返る
キーワード抽出では、50 件すべてが ```json … ``` で囲まれて返りました。JSON_QUERY の前に取り除く処理が必要です。
ラボの LTRIM(x, " ```json") は、先頭の文字列ではなく、文字の集合（空白、バッククォート、j、s、o、n）を左端から取り除きます。JSON オブジェクトは { で始まるため結果的に正しく動きますが、{ 以外で始まる出力に使うと、意図しない文字まで削られます。
JSON_QUERYは引用符付きの値を返す
JSON_QUERY(…, "$.marketing") の結果は "Thank you for…" のように、JSON の引用符を含んだ文字列です。画面表示には問題ありませんが、メール本文などに差し込むと引用符も入ります。プレーンな文字列が欲しい場合は JSON_VALUE を使ってください。
感情ラベルの揺れはモデル次第
ラボはピリオドや空白の混入を想定してビューを作りますが、gemini-3.5-flash で起きたのは大文字と小文字の揺れ（50 件中 4 件）だけでした。TO_JSON_STRING で実際の値を確認してから、必要なクリーニングを決めると確実です。
バケットの権限はオブジェクト閲覧者で足りる
ラボは Storage オブジェクト管理者を付与しますが、オブジェクトテーブルと画像の分析はいずれも読み取りだけです。オブジェクト閲覧者で動作しました。
接続のIAMはデータセットを消しても残る
プロジェクトに付与した roles/aiplatform.user のバインディングは、データセットや接続を削除しても IAM ポリシーに残ります。クリーンアップで明示的に削除してください。
bq showでモデルを見るには--modelが必要
bq show <dataset>.<model> はテーブルとして探しに行き、Not found を返します。モデルの場合は bq show --model です。
費用について
当記事の処理で Gemini を呼び出したのは、テキスト 102 回（キーワード 50、感情 50、返信 2）と画像 5 回です。時間単位で課金されるリソース（Endpoint や常時起動のインスタンス）はないため、放置しても費用は増えません。発生するのは、Gemini の呼び出しごとの料金と、BigQuery のクエリ・ストレージの料金です。
クリーンアップ
作成したリソースを、依存関係の順に削除します。
bq rm -r -f -d "${PROJECT_ID}:gemini_demo"
gcloud projects remove-iam-policy-binding "${PROJECT_ID}" \
--member="serviceAccount:${CONN_SA}" \
--role="roles/aiplatform.user" \
--condition=None
bq rm -f --connection "${PROJECT_ID}.us.gemini_conn"
gcloud storage rm -r "gs://${BUCKET}"
データセットの削除で、テーブル、ビュー、オブジェクトテーブル、リモートモデルがまとめて消えます。IAM のバインディングは、接続を削除する前に外してください。接続を先に消すと、サービスアカウントの ID がわからなくなります。
データは BigQuery に置いたまま、SQL で Gemini に読ませる。 テキストも画像も同じ ML.GENERATE_TEXT で扱えるため、分析基盤の上に生成 AI の処理を自然に追加できます。一方で、LLM の出力形式は完全には制御できません。コードブロックの除去や表記揺れのクリーニングなど、出力を検証して整える SQL までを含めて設計してください。