生成AIがSQLを書いてくれる時代における人間（マーケター）がSQLを書けることの意味

この記事を書いているのが、2026年初頭ですが、ChatGPTは5.2が、Geminiは3Proが使えます。それらは、相当高いSQL記述能力（と、人間がプロンプトで指示した、「どんなSQL文を書いてほしいか」を察知する能力）を持っています。

2024年4月に『保存版？！生成AIにSQL文を書いてもらうときのコツ』という記事を書いた時の趣旨は「プロンプトをしっかり書くと、割と正確なSQL文が手に入るよ」ということだったのですが、今は、ある程度いい加減な（＝厳密性がそれほど高くない）プロンプトを書いても、しっかりとしたSQL文を書いてくれる印象です。（もちろん、業務上の本番で使う、間違いの許されないSQL文を得るのが目的であれば、プロンプトはしっかり書くべきです。）

例えば、以下を見てください。プロンプトは、適当という訳ではないですが、かなり自然な日本語で記述しています。この日本語であれば、エンジニアでなくとも誰でも記述可能でしょう。このプロンプトに対して、5秒程度で書いてくれたSQLは完全に意図に沿った結果を返すものでした。

その現状を踏まえつつ、このブログ記事では、「生成AIがSQLを書いてくれる時代における人間（マーケター）がSQLを書けることの意味」として、私なりに思うところを書いていきたいと思います。

最低限、書けなくても読める必要はある

まず、おそらく正しいのは「マーケターは最低限、書けなくても読める必要はある」だろうということです。以下は、Claude（Claude Desktopから、BigQueryのローカルMCPサーバーに接続した状態）に、コンバージョンするユーザーを増加させる施策を相談した画面です。Claudeは「データに基づくコンバージョン増加施策を提案するため、まず現状のコンバージョン状況を分析させていただきます。」と返事をして、やおらSQLを書き始めました。（青枠部分）

そして、その結果に基づいて、アドバイスをくれる訳です。と、言う事は、このSQL文がどんな分析をしているのか、トンチンカンなことをはしていないか、正しいテーブルを参照しているのか？ということは、どうしても、分かっていなければいけません。

この一つの出来事をとっても、マーケターは、（データベース上のデータをデータソースとして生成AIに分析、や相談をするのであれば）最低限、SQLは書けなくてもいいが、読めなくてはだめ。と言えると思います。

でも、読めるだけよりも、書けたほうが断然いい

最低限読めなければマズイけれど、さらに、書けたほうが断然いいと考える理由は以下です。

データの構造や全体像が把握できる

SQLが書けると、データの構造や全体像を把握できます。というのは、逆に、構造や全体像が分かっていないとSQLは書けないのです。SQLを書くトレーニングを通じて、さらには、本番テーブルから、意図通りの結果テーブルを得る試行錯誤を通じて、SQLを書けるマーケターはデータの構造と全体像を把握する力を身につけるでしょう。どんなカラムがあるのか、データ型は？欠損値はどれくらい存在するのか、集計するときにはどんな集計関数を使うべきなのか・・・などです。

そして、データの構造や全体像を理解している人は、もちろん適切なSQLを記述できますし、それらのデータの活用方法の勘所や、他のテーブルとのJOINをスムーズに行う方法など、ビジネス寄りの観点からそのデータを取り扱うことができるようになります。

結果テーブルに対する説明責任を果たせる

SQLを生成AIに書いてもらってデータプレップをしたとしましょう。SQLを読めなければ、怖くてそのデータプレップの結果テーブルは上司や同僚、お客様には提出できないでしょう。SQLを（書けないけれど）読めれば、「間違ったことはしていないです」とまでは、説明できるでしょう、しかし、書ければ、「こういう意図で、こういうフィルタを掛けて」、とか「この数値列は平均値だとミスリードするから、中央値を代表値として」、とか「このあと、別のテーブルとJOINすることを考えてこの粒度にした」など、自分が出した成果物である「プレップ済の結果テーブル」に対しての説明責任を果たせることになります。

自分の成果物に対して説明責任を果たせないのはビジネスマンとしてどうか？と思いますし、自分も仕事をしていて楽しくないはずです。

適切かどうかの判断が早く、修正も早くて、的確

自然言語のプロンプトで生成AIに書いてもらったSQL文をテーブルに対して実行してみたら、どうも結果が意図と違うことを発見した。よくあるシーンだと思います。そんな場合、SQL文が妥当だったかどうかをチェックすることになりますが、SQLを書ける人は、どこに修正点がありそうかを素早く見つけることができます。「あ、これは、WHERE句に誤字があるな」、とか「違った粒度でJOINしちゃったから、レコード数が爆増しちゃってるのでは？」などですね。

また、修正点が見つかったら、実際に修正が必要ですが、自分でSQL文を書けない場合、プロンプトを修正することになります。そして、プロンプトの修正でSQL文を修正するのは、結構時間がかかります。というのは、「生成AIが正しくSQL文を修正してくれたのか？」を確認する必要があるからです。自分でSQLを書ければ、意図通りではない現状に対して、どこを修正すれば良いか、ピンポイントで分かり、SQL文を直接修正することができます。結果的に修正が早く、的確に行えます。

一発で決まるような単純なSQLで、修正がほぼ不要であれば「読めるだけ」でもいいかもしれませんが、一定の複雑さを持つプレップや分析を行う場合、時間効率の観点から、SQLを書くスキルは必須でしょう。SQLを書ける人が、初期のSQLを生成AIに書いてもらって、実行して適切性を確認、必要があればSQL文を直接修正。というのが最も効率が良いです。

SQLは「学パ」の高いスキル

私の持論ですが、SQLは、学習パフォーマンス（←造語）、つまり、「どれだけのリソース（時間、エネルギー、認知パワー）を使ったら、どれだけのリターンがあるのか？」のバランスが非常に優れています。つまり、学び、マスターするために、超人的な努力や長期間の学習は必要ありません。その割に、データの構造がわかる、（プレップや分析を）自信をもってアウトプットできる、一定以上の複雑なSQL文でも時間効率よく書け、期待通りの結果を手に入れられるなどのリターンは甚大です。

つまり、学び得。なスキルではないかと私は思っています。