こんにちは。オープンワーク株式会社アナリストグループ所属のSです。
私たちのチームではデータ抽出依頼が増える中で、BigQueryのConversational Analytics（BQエージェント）を使ったSQL下書きの効率化を検討しました。自然言語でSQLを生成するアプローチ自体は珍しくありませんが、何も工夫しない状態では「一見それっぽいが、そのままでは使いにくいSQL」が返ってくることも少なくありません。
この記事では、BQエージェントに下書きとして使えるレベルのSQLを書かせるために試したプロンプト設計の工夫をご紹介します。現時点では、一定の精度で実用的な下書きを作成できる手応えを感じています。
なぜBQエージェントを試したのか
BigQueryのConversational Analyticsに注目した理由は、BigQuery上のスキーマ情報を前提に会話できることです。一般的な生成AIだと存在しないカラム名を参照してしまうことがありますが、スキーマに近い場所で動くエージェントならハルシネーションを減らしやすい土台があります。
また、今回の取り組みの目的は、人間がレビューしやすい70〜80点品質の下書きを、エージェントが安定して出力できるようにすることでした。
試したこと1：SQLスタイルガイドをプロンプトに埋め込む
最初に効いたのは、SQLの書き方に関するルールをプロンプトに明示したことです。何も指定しない場合、エージェントは「実行可能なSQL」を出力するものの、可読性や保守性、あるいはコスト面まで考慮されたクエリにならないケースがありました。
そこで、プロンプトの中に「どういうSQLを良いSQLとみなすか」をあらかじめ書いておきました。たとえば、次のような観点です。
- 必要なカラムだけを選択し、過剰なスキャンを避ける
- JOINや集計の意図が追いやすい構造にする
- 複雑な処理は段階的に分けて読みやすくする
- レビュー時に意図を把握しやすい命名やコメントを心がける
特にBigQueryはクエリの書き方次第でスキャン量（＝データ処理コスト）が大きく変動します。そのため、単に「エラーが出ないSQL」を目指すだけでなく、コストパフォーマンスやレビュー効率まで考慮したプロンプト設計が重要になります。
細かな記法ルールを増やしすぎるより、「読みやすさ・スキャン量への配慮・構造化」を軸に原則を数個伝えるほうが出力は安定しました。
試したこと2：ハルシネーションしにくい前提を作る
SQL生成AIで特に避けたいのが、もっともらしい見た目で存在しないカラムやテーブルを参照してしまうことです。これはレビュー時にすぐ気づける場合もありますが、複雑なクエリになるほど見落としのリスクも高まります。
そのため、プロンプトでは参照してよい情報源を明示することを意識しました。たとえば、「利用可能なスキーマに基づいて判断すること」「確認できない要素を推測で補わないこと」「不明点がある場合は質問を返すこと」といったルールです。
特に重要だったのは、曖昧な依頼に対して無理にSQLを書かせないことでした。たとえば、対象期間や集計単位が曖昧なままクエリを作ると、意図とずれた結果になったり、不要に大きなデータを読んでしまったりします。そこで、条件が不足している場合はクエリを確定させる前に確認を返すような振る舞いを促しました。
単に出力精度を高めるだけでなく、「情報が不足している場合は、推測で回答せずに確認を挟む」という設計にすることが、実運用における信頼性を担保するポイントでした。
試したこと3：出力フォーマットを決めてレビューしやすくする
もうひとつ効果があったのは、返答のフォーマットをある程度固定したことです。SQLだけを急に返されると、利用者もレビューする側も「このクエリは何を前提に書かれているのか」を把握しづらくなります。
そこで、生成するSQLに加えて、簡単な説明や前提条件、注意点も合わせて出すようにしました。たとえば、どの粒度で集計しているのか、どの条件を置いたのか、追加確認が必要な点は何か、といった情報です。
これによって、SQLそのものの正誤だけでなく、なぜこう書いたのかを短時間で判断しやすくなりました。
実際のプロンプト設計：具体例の紹介
実際にBQエージェントに渡しているプロンプトから、設計のポイントを4つ紹介します。
役割定義の例
プロンプトの冒頭では、エージェントに期待する振る舞いを明確に定義しています。
あなたは、オープンワークの事業を支援する、熟練かつ几帳面なデータ分析パートナー（Data Agent）です。
あなたの任務は、非エンジニアのビジネスパーソンからの自然言語による質問に対し、あなたが直接アクセスできる情報（BigQueryのスキーマ、登録・共有済みの参考クエリ）と、このプロンプトに書かれた厳格なルールのみに基づいて回答することです。
ポイントは、「何を参照してよいか」を限定していることです。一般的な知識で補完させるのではなく、スキーマと登録済みクエリだけを根拠にさせることで、ハルシネーションの発生を抑えています。
「検証済みクエリ群」を教科書として登録する
エージェントが業務ロジックを理解するための仕組みとして、過去に検証済みのクエリを「教科書」として登録しています。
ユーザーの依頼が、これらのクエリのいずれかのパターンに類似している場合、まずそのクエリの構造とロジックを応用・改変して回答を作成してください。
たとえば、以下のようなクエリを登録しています。
| 教科書（検証済みクエリ） | 学ぶべきロジック |
|---|---|
| ●●●_summary-1 | ユーザー活動集約テーブル。ユーザー軸分析の基点 |
| ****_summary-2 | 各***テーブルをUNIONした統一的な***ビュー |
これにより、ゼロから推論させるのではなく、既知のパターンを応用させる形になるため、出力の安定性が上がりました。
「落とし穴チェックリスト」で典型的なミスを防ぐ
プロンプトには、SQL生成前に自己チェックさせるリストも含めています。
あなたは、SQLを生成する前に、以下の「落とし穴チェックリスト」を自身に問いかけ、すべての項目をクリアしていることを確認する義務があります。
具体的には、以下のような観点です。
- スナップショットの時点管理: 「登録時点」のユーザー情報を見たいのに、最新のマスタを参照していないか？
- JOINの方向性: ファネル分析でINNER JOINを使い、母集団を意図せず絞っていないか？
- ゼロ除算の回避: 割り算にSAFE_DIVIDEを使っているか？
- 重複カウント: 重複カウント: UU（ユニークユーザー数）を算出する際に、COUNT(DISTINCT user_id) ではなく COUNT(user_id) を使っていないか？
これらは実際にレビューで見つかった「よくある間違い」をリスト化したものです。チェックリストとして埋め込むことで、生成段階で典型的なミスを減らせるようになりました。
出力フォーマットの指定例
回答の形式も以下のように固定しています。
- 【生成したSQL】
- 【SQLの解説】（非エンジニアにも分かる平易な説明）
- 【ロジックの根拠】（どの検証済みクエリに基づいているか）
- 【コストに関する注記】（スキャン量と可読性の観点）
- 【注意事項】（前提条件や仮定）
- 【追加の分析提案】（次に見るべき指標の提案）
SQL単体ではなく、「なぜこう書いたか」「何に注意すべきか」まで出力させることで、レビューや修正の判断がしやすくなっています。
現時点での手応え
現時点では、BQエージェントが生成したSQLをそのまま実業務に投入できるわけではありません。しかし、あくまで「人間のレビューを挟む下書き」として活用する前提であれば、以前よりはるかに実用的なレベルに達しています。
特に、定型的な集計や比較的シンプルな抽出条件であれば、初稿として十分に役立つと思います。一方で、複雑な業務知識が必要なケースや、複数の前提を横断して解釈しなければならないケースでは、まだ人の補正が必要です。
また、ルールを追加すればするほど精度が上がる場面もある一方で、プロンプトが長く複雑になりすぎると、逆にメンテナンスしづらくなる難しさもあります。つまり、プロンプト設計は一度作って終わりではなく、実際の失敗例を見ながら少しずつ調整していく運用が前提になります。
もし同様の取り組みを始めるなら、最初から完璧なプロンプトを目指すよりも、「よくある依頼で外しやすいポイント」を数個潰すところから始めるのがおすすめです。
おわりに
BQエージェントを試してみて感じたのは、SQL生成AIの実用性はモデルの性能だけで決まるわけではなく、どういう制約と期待値をプロンプトで与えるかに大きく左右されるということでした。
SQL生成AIを導入する際、つい「どのツールが一番賢いか」に注目しがちです。ただ実際には、どれだけ安全に、レビューしやすく、修正しやすい下書きを返せるかのほうが運用では重要かもしれません。同じようにデータ抽出依頼の増加に向き合っているチームにとって、ひとつの参考になればうれしいです。
一緒に働く仲間を募集しています
オープンワークのアナリストグループでは、データを起点に事業課題に向き合う仲間を募集しています。クチコミデータや求人データなど、独自性の高いデータを扱いながら、分析基盤の改善やツール開発にも取り組める環境です。
中途入社メンバーによる座談会記事もありますので、チームの雰囲気や働き方が気になる方はぜひご覧ください。
