1.前回の振り返りと今回のテーマ
前回の記事では、BigQueryの AI.GENERATE 関数について、そのメリットと利用方法を解説しました。理解が深まりやすいように、デモとして、レビューデータを直接AIに渡して「要約」や「感情分析」をしました。また、最後には、Search Consoleのデータを元に、「検索意図」とコンテンツについての「改善アドバイス」をもらいました。
SQLからGeminiを呼び出せたこと自体でBigQuery Loverの私は感動しましたが、この技術を使うと、以下もできるよね、と欲が出てきました。
- 「1つのデータに対して、複数のプロンプトを投げて一気にアウトプットを得たい」
- 「TemperatureやTop-Pなどのパラメータを変えたときのアウトプットを得たい」
今回は、これらを解決する「プロンプトテーブル管理」と「パラメータ検証」のテクニックを紹介します。
2.複数のプロンプトを同一のデータに対して投げる
ブラウザ版のGeminiでは、1つのレビューに対して「要約して」「SNS用に書き換えて」と異なった指示（プロンプト）をしたい場合には、何度も入力する必要があります。しかし、BigQueryならプロンプトを「データ」として扱うことで、一瞬で複数のプロンプトを投げ、処理した結果を得ることができます。
2.1 メリット
複数のプロンプトを一括で投げることで、以下のメリットが生まれると思います。
- 運用の効率化: プロンプトを修正したい時、SQLを書き直すのではなくテーブルの値を書き換えるだけで済みます。人間が記述するプロンプトは同じ趣旨でもどうしても揺らいでしまいますが、テーブルに格納することで、同じプロンプトは一言一句、同じものを投げることができます。また、プロンプトの修正版も試したいな。という時には、オリジナルのプロンプトと、修正したプロンプトをテーブルに格納すれば良いだけです。
- 圧倒的なスケーラビリティ: 100件のレビューに3種類の分析（例えば、要約、翻訳、感情分析）を行う場合、300通りの結果が1回のクエリで得られます。
2.2 実装方法
以下に、皆さんが再現できるよう、ステップ・バイ・ステップで実装方法を紹介します。まずは、プロンプトをテーブルとして用意するところから始めましょう。
2.2.1 プロンプトテーブルの準備
まず、AIへの指示書（プロンプト）を格納するテーブルを作成します。今回は以下のようなテーブルを用意しました。テーブル名はanalysis_promptsです。4種類のプロンプトがあるのが確認できますね。
2.2.2 データテーブルの確認
対象となるレビューデータ（demo_reviews）は、以下です。紐付け用の review_id を付与しておくとあとから絞り込みに使えるので、便利です。
2.2.3 クエリとその解説
プロンプト、データ、両方のテーブルが揃ったところでクエリ（SQL文）を実行しましょう。実行するのは以下です。
WITH base AS (
SELECT *
FROM
`bq-verification.ai_demo_us.demo_reviews` AS r
CROSS JOIN
`bq-verification.ai_demo_us.analysis_prompts` AS p
)
SELECT
base.review_id,
base.task_name,
gen.analysis_result
FROM
base
CROSS JOIN
UNNEST([
AI.GENERATE(
CONCAT(base.prompt_instruction, '\nレビュー: ', base.comment),
endpoint => 'gemini-2.5-flash',
output_schema => 'analysis_result STRING',
model_params => JSON '''
{
"generation_config": {
"temperature": 0.5,
"top_p": 0.5,
"max_output_tokens": 2048
}
}
'''
)
]) AS gen
ORDER BY
base.review_id, base.task_id;
WITH句では、生成AI(Gemimi）に投げる対象のテーブルを作成しています。CROSS JOIN を使うのがポイントです。CROSS JOINは２つのテーブルのすべての行同士の組み合わせを作る、特殊な結合です。これにより、「全てのレビュー」×「全てのプロンプト」の組み合わせが生成されます。どのようなテーブルが生成されるのかを確認したい場合も、
SELECT * FROM base
で確認できますね。
本体SQL文で何を記述しているかは、前回の記事を読んでいただければ理解できると思います。WITH句で作成したレビューとプロンプトの全組み合わせをGeminiに投げて、回答を得ています。こちらもCROSS JOINがポイントになっていますね。
全体的には、クエリを2つのブロックに分けるのがコツです。まず base 部分で『どのレビューにどのプロンプトを渡すか』という組み合わせを全て作り、最後にそれらをまとめてAI（Gemini）に一気に渡しています。こうすることで、複雑な処理も頭の中ですっきり整理できますね。WITH句バンザイ、CROSS JOINバンザイ！
2.3 実行結果
以下がクエリを実行した結果です。このように、1つのレビューに対して4つのタスクが走り、それぞれの結果が縦に並びます。もちろん、クエリにWHERE句を追加すれば、review_idやtask_nameでの絞り込みは簡単にできます。こんな使い方はブラウザからGeminiを利用していたのではできません。
3.パラメータを変えて異なった出力を得る
ここから別のテーマになります。
AIの出力の「遊び」や「正確性」を調整するのが temperature（温度）や top_p といったパラメータです。どれが最適か、SQLで一気に検証してみましょう。
3.1 メリット
「どの設定が一番面白いコピーを書くか」を勘ではなく一覧比較で判断できるため、自分たちの目的に合った最適解を高速に特定できます。また、同時にパラメータを変えても、アウトプットが大きく崩れず安定しているか（≒日本語として成立しているか）といった、生成結果の一貫性もあわせて確認することが可能です。
3.2 クエリ
今回は、1つのレビュー（review_id=3）に対する1つのプロンプト（4番の「SNS投稿文」タスク）を対象にして、9パターンの設定を UNION ALL で繋いで一括実行します。9パターンもあるのは、以下の3×3の組み合わせがあるからです。
temperatureは、回答の創造性の度合いを調整します。0がいちばん創造性がなく、1が最大の創造性です。
top_pは、回答の候補となる語彙の範囲を指定することで、結果的に多様性をコントロールします。0以上、1以下の値を取ります。0に近い値は確率的に最も高い語彙を使い、1に近いほど確率が低い語彙も候補に加わり、多様でランダムな回答になります。
- Temperature : 0、0.5、1
- Top-P：0、0.5、1
あまり美しくない、いかにも「力技」なクエリですが、temperatureやtop-pといったパラメータは、レビューのデータやプロンプトのようにテーブルで与えることはできず、1回のGemini呼び出しに対し、固定で指定する必要があるので、この書き方となりました^^;
3.3 実行結果
実行結果を整理すると、パラメータの影響が確認できます。お題は、以下のレビューをもとに140字程度のXへの投稿文生成でした。
結果は以下の通りです。このお題では、temperatureが0（創造性最低。最上段）だと、いくらtop-p（ボキャブラリーの豊富さ）を上げてもまったく効いておらず、まったく同じアウトプットが出てきていますね。逆に、top-pを0に固定（１番左の列）してしまうと、temperatureを上げても、こちらもまったく同じアウトプットです。
創造性がほしい局面では、temperatureもtop-pも両方それなりに上げるべき。という結論が、この検証からは導けます。
もちろん、投入するデータ（レビュー）やプロンプトが違えば違ったアウトプットになるでしょう。また、モデルは、今、Gemini 2.5 Flashを使っていますが、モデルを変えればまた別のアウトプットになるはずです。
大事なのは、このブログで紹介したテクニックを使えば、パラメータを変更させたパターンごとのアウトプット結果を比較できる。ということです。ぜひみなさんも、ご自分のデータでやってみてください。
4. まとめ（BigQueryからGeminiを利用するメリット）
今回紹介した手法を使えば、以下の3つのメリットがあると思います。
- データとプロンプトの完全分離: 前回の記事では、プロンプトはクエリ（SQL文）の中にハードコードしていました。そのため柔軟性がなかったです。今回の記事では、指示内容（プロンプト）をテーブル化することで、さまざまなプロンプトを同一のデータに対して投げることができます。
- 高速なA/Bテスト: どのプロンプト、どのパラメータが最適かをSQL一発で判定できます。しかも必要とされるのはちょっとしたSQLの知識だけです。
- 「次アクション」への近さ: 分析結果がそのままテーブルに入るため、他のテーブルとのJOINや、Looker StudioなどのBIツールでの可視化など、次のアクションへ即座に繋げられます。
「チャットUIで、人間が思いついた単一のプロンプトをお仕着せのAIに対して投げる」段階から一歩進み、「プロンプトやパラメータのA/Bテストを通じて、生成AIからベストのアウトプットを引き出す」。これこそが、みなさんの「生成AI活用リテラシー」を上げてくれるかもしれません。
5.この記事に関連した学習リソース
この記事をここまで読んでいただいた方は、もれなく、BigQuery(SQL)って、素敵なことができるな！！と思っていただいたんじゃないかと思います。
SQLについて、学習用の良い動画講座を紹介します。たくさんのレビューを頂き、5点満点中4.6点と、お陰様で評判も良いようです。よろしければどうぞ。（画像をクリックするとUdemy.comにジャンプします。）
書籍で学習したい場合には、以下の拙著を推奨します。こちらをどうぞ。（アマゾンのアフィリエイトリンクです。画像をクリックするとアマゾンにジャンプします）
自分のSQLライティング能力を確認したい、同僚や上司や転職先にアピールしたい。という場合には、ぜひ、こちらのサービスをご利用ください。私が開発した、SQLリテラシーを診断するテストです。
