AIものさし
開発・プログラミング

SQLを書くならどのAI？

SQLを書くならどのAI？という視点で、用途や条件ごとに検討候補になるAIの考え方を整理します。結論だけでなく、向く条件と向かない条件も分けて整理します。

AIものさし編集部

SQLをAIに書かせると、短いSELECT文ならどれでもそれらしい形を返せます。差が出やすいのは、テーブル構造、SQL方言、既存クエリ、アプリ側の処理まで含めて考える場面です。

先に整理すると、BigQuery上のスキーマを使ってSQLを生成・説明・修正したいならGemini in BigQuery、アプリやデータ処理コードと一緒にSQLを直したいならCodex、ローカルのクエリファイルやコードベースをターミナルから追いたいならClaude Codeが候補です。SQLの正答率は同じスキーマ・同じ要件・同じデータで比較していないため順位を付けません。

目次

結論：SQLは「どのモデルか」より「どのデータ構造を見せられるか」で選ぶ

表は横にスクロールできます

SQLを使う環境まず見る候補
BigQueryでスキーマを見ながら生成・修正したいGemini in BigQuery
アプリ・API・マイグレーションと一緒にSQLを直したいCodex
ローカルのSQLやコードベースをターミナルから追いたいClaude Code
SQLだけを単発で作りたいChatGPT / Claude / Geminiいずれも候補
一番正しいSQLを書くAIを知りたい同一スキーマ・同一要件で実測

Gemini in BigQueryはBigQuery上のSQL作業に直結している

Gemini in BigQueryでは、自然言語からSQLを生成するだけでなく、既存クエリの説明、入力中の補完、エラーの修正まで案内されています。最近見たテーブルや指定したテーブルを使ってSQLを生成できるため、BigQueryを使っているならスキーマ文脈を別のチャットへ貼り直さなくて済むのが特徴です。

エラー後には修正案を表示し、差分を確認してから適用・実行する流れもあります。

ここはかなり分かりやすいです。BigQuery利用者なら、「SQLを書くAI」を単体で比べるより、実際のデータ環境の中で生成・説明・修正できることが判断材料になります。

ただし、Google自身も生成結果がもっともらしく見えて誤っている場合があるため、利用前の検証を推奨しています。

CodexはSQLがアプリコードとつながっているときに使いやすい

SQLは単独で存在するとは限りません。ORM、API、バッチ処理、データパイプライン、マイグレーションファイルの中に埋め込まれていることも多いです。

Codexはリポジトリを扱うコーディングエージェントなので、「このクエリだけ直して」ではなく、呼び出し元、型、テスト、関連するコードまで含めて変更を進める候補になります。

OpenAIが公開している社内データエージェントの事例でも、SQLの評価では文字列が同じかではなく、実際の結果が期待結果と一致するかを重視しています。SQLは見た目が違っても同じ結果になるためです。

つまり、アプリ開発ではSQLの文法だけでなく、最終的な結果と周辺コードまで確認する方が安全です。

Claude Codeは既存SQLとコードベースを追いながら直したい場合の候補

Claude Codeはコードベースを読み、ファイル編集、コマンド実行、テストなどをターミナルから進めるエージェントです。

既存プロジェクトに.sqlファイルやマイグレーション、クエリビルダーがあるなら、それらを探して処理の流れを説明させ、必要な箇所だけ変更する使い方ができます。

ただし、Claude Codeだから自動的にデータベースの意味を理解できるわけではありません。テーブル定義、カラムの意味、リレーション、利用しているSQL方言、期待する結果を確認させる必要があります。

SQL生成で最初に渡したい情報

AIへSQLを依頼するときは、最低限、

  • PostgreSQL / MySQL / SQLite / BigQueryなどの種類

  • テーブル定義と主要カラム

  • JOIN関係

  • 欲しい結果の例

  • NULLの扱い

  • 重複を許すか

  • 日付・タイムゾーンの扱い

  • 件数やデータ規模

を明示します。

同じ「売上を月別に出して」でも、注文確定日時を使うのか、決済日時を使うのか、キャンセルを除くのかでSQLは変わります。ここはAIが勝手に決める部分ではありません。

また、UPDATE、DELETE、DDLのような破壊的操作は、生成結果をそのまま本番で実行しません。まずSELECTで対象を確認し、必要ならトランザクションやバックアップを使い、実行計画やインデックスも確認します。

AIものさし編集部の判断

SQL用途では、モデル名よりスキーマと実行環境の文脈をどこまで渡せるかで選ぶ方が実用的です。

BigQuery内でSQLを生成・説明・修正するならGemini in BigQuery。SQLがアプリやデータ処理コードと密接ならCodex。ローカルの既存SQLやコードベースをターミナルで追うならClaude Code。

正答率、実行速度、クエリ最適化の質は同一条件で試していません。生成したSQLは、構文だけでなく結果セットと実行計画まで確認します。

例：イベント集計はSQLより先に粒度を決める

以下は説明用の架空スキーマです。実在のテーブルではありません。eventsにevent_timestamp（TIMESTAMP）、event_name（STRING）、user_id（STRING）があり、「直近7日のイベント別件数とユーザー数」を求めるとします。「イベントを数えて」だけでは、日付、重複、期間端点、タイムゾーンをAIに推測させます。

先に1行の粒度を「日付 × event_name」と決め、期間は開始を含み終了を含まない半開区間にします。日付がUTCか業務上のタイムゾーンか、user_idがNULLの行をどう数えるか、同じイベントの重複送信を除くかも指定します。出力はevent_date、event_name、event_count、distinct_usersです。

BigQueryのGoogleSQLで作る読み取り専用SELECTの例です。テーブル名と時刻は実際の条件へ置き換えます。


SELECT

  DATE(event_timestamp) AS event_date,

  event_name,

  COUNT(*) AS event_count,

  COUNT(DISTINCT user_id) AS distinct_users

FROM `project.dataset.events`

WHERE event_timestamp >= @start_ts

  AND event_timestamp < @end_ts

GROUP BY event_date, event_name

ORDER BY event_date, event_name

LIMIT 1000;

このクエリでは、1行が日付とイベント名の組み合わせです。COUNT(*)はuser_idがNULLでもイベント行を数え、COUNT(DISTINCT user_id)はNULLを数えません。業務上の「ユーザー数」が匿名IDを含むかは、列名からAIが判断できないため依頼で明示します。LIMITは結果表示の行数を制限しますが、集計対象そのものを減らす設定ではありません。

実行前の確認順

  1. 方言とテーブル：BigQuery GoogleSQLか、完全修飾名が正しいか。

  2. 列と型：event_timestampがTIMESTAMPか、列名が定義と一致するか。

  3. 期間：境界時刻の行が意図した側へ入るか。

  4. 粒度：GROUP BYが求める1行の単位と一致するか。

  5. NULLと重複：COUNTの意味が依頼と一致するか。

  6. 処理量：dry runで構文と処理量を確認したか。

  7. 権限：読み取りに必要な最小権限で実行するか。

BigQueryのdry runはクエリの検証と処理量の概算に使え、通常スロットを消費せず料金もかかりません。ただし外部データや行レベルセキュリティが関係する場合、見積もりの読み方に例外があります。dry runが通っても、抽出対象の業務上の意味が正しい証明にはなりません。必要なら匿名化した少量データで期待結果と照合します。

AIへ頼むときはこう書けます。

GoogleSQLで、eventsテーブルから日付×event_name単位のイベント件数とdistinct user_id数を集計してください。期間は@start_ts以上@end_ts未満です。まずSELECTだけを提案し、使用列、粒度、NULLの扱い、dry runで見る処理量を説明してください。テーブル定義や業務上の意味が不明なら質問してください。UPDATE、DELETE、DDLは作成しないでください。

Gemini in BigQueryはスキーマに基づくSQL生成・説明・修正を案内していますが、Googleも生成結果がもっともらしくても誤り得るとして、実行前の検証を推奨しています。BigQuery内で生成結果と差分を読み、dry run、サンプル実行、期待値との照合へ進めます。アプリやORM、マイグレーションと結びつくSQLなら、CodexやClaude Codeで周辺コードを確認する方が合う場合があります。どのAIも、業務上の指標定義は人が決める必要があります。

同じスキーマ、同じ要件、同じ期待結果で比較していないため、正答率や最適化能力のランキングは出しません。比較するなら固定データを使い、結果セット、NULL、境界日、重複、処理量を確認します。

引用・データ出典

公式情報を編集部が見た内容です。Hands-on未実施の記述は本文かここに分けています。

確認日：2026-10-07

自分の条件なら？

「SQLだけでなく、バックエンド、API、データ分析、デバッグまで含めてAIを選びたい」という場合は、AIものさしのかんたん診断で開発環境全体から候補を比較できます。

次に読む・使う

この記事の次に必要な情報へ進めます。

同じ工程のガイド

ツールの詳細