SQLはもうAIに書かせていい?それでも人が握るべき一線

「このテーブルから、先月の新規顧客ごとの平均注文額を出して」とAIに頼むと、数秒でSQLが返ってくる。JOINもGROUP BYも書かずに、だいたい動く。ここまでは誰もが体験している話で、驚きはない。だから「SQLはもう暗記しなくていい」という結論に流れたくなる。実際、構文を一文字ずつ覚える必要性は、確かに下がった。

ただ、ここで立ち止まって考えたいのは「暗記が不要になった」ことと「学ばなくていい」ことは同じではない、という点だ。AIがSQLを書けるようになったことで消えたのは、構文を思い出す手間だけで、それ以外にまだ人間に残っている仕事が2つある。

ひとつは、どんなテーブルをどう設計するか──つまりスキーマだ。AIは「このテーブル構造に対して、この質問に答えるクエリ」は得意に書けるが、「このビジネスにとってどういうテーブル構造が妥当か」は、現場の業務ルールや将来の変更可能性を知っている人間の判断抜きには決められない。注文と顧客を1対多にするか多対多にするか、ステータスを別テーブルに切るか列に持たせるか。これは構文の知識ではなく、データの形をどう捉えるかという設計思考の領域で、ここをAIに丸投げすると、後から取り返しのつかない歪みが積もっていく。

もうひとつは、出てきた結果が本当に正しいかを見抜く力だ。AIが書いたSQLは、たいてい「それっぽく動く」。だが見た目が正しいクエリほど、静かに間違っていることがある。たとえばJOINで行が意図せず増えて平均値が薄まっている、日付の範囲指定が「以上」と「超」を間違えていて境界の1件がずれている、NULLを含む列の集計で件数が合わない。これらは構文エラーにはならず、画面には涙目になるくらい自然な数字が出てくる。それを「変だ」と気づけるかどうかは、SQLが何をしているかを読んで理解できるかどうかにかかっている。

ここに、AI時代のSQL学習がどこに比重を移すべきかという、ひとつの非対称が見えてくる。学ぶべき力の中心が「書く力」から「読み、検証する力」へ移っているということだ。書けなくても生成はできる。しかし読めなければ、生成された結果が正しいのか間違っているのかを判断する手段がない。これは「使うか使わないか」という二択の話ではなく、どこに学習の時間を割くかという配分の問題として捉えたほうが実用的だ。

この見方を裏づける小さな手がかりが、tasklogで開発者の技術記事の引用データを見ていたときに見つかった。SQL関連の書籍の中で、最も多く引用されていたのは『達人に学ぶSQL徹底指南書 第2版』だった(49件)。この本は、SELECTの書き方やJOINの構文を一から教える本ではない。むしろ「集合としてデータをどう捉えるか」「このクエリは筋が良いか悪いか」を判断する思考を鍛える本で、構文を覚えた後の人が読むタイプの一冊だ。次点には構文を一から教える入門書も入っていて、覚える本そのものが無価値になったわけではない。それでも、最も多く手に取られていた1冊が構文リファレンスではなく「このクエリは筋が良いか」を判断する力を鍛える本だった、という事実は示唆的だ。SQLを使い込んでいる開発者たちが実際に参照してきたのは、構文の引き方そのものより、設計と検証の考え方だったのかもしれない。AIがクエリを書く時代になっても、ここで鍛えられる判断力の価値は薄まらない。

だとすれば、これから学ぶ人がSQLに割く時間の使い方も自然と見えてくる。SELECT文の書き方を何十問も繰り返して覚えることに時間を使うより、まず簡単なクエリを自分で書いて動かし、その結果が「なぜその数字になったのか」を一行ずつ説明できるところまで確認する練習に時間を使ったほうがいい。書く練習そのものが無意味になったわけではなく、書いてみることは結局、読んで検証する力を鍛える一番手っ取り早い道でもある。自分で書けないものを、他人(やAI)が書いたコードの正しさを判定することはできないからだ。

その上で、JOINの結合条件を変えたら行数がどう変わるか、集計関数がNULLをどう扱うか、ウィンドウ関数が何を基準に区切っているか──このあたりを手を動かして確かめておくと、AIが出してきたクエリを読んで「これは信じていい」「ここは一度自分で検算する」と判断できるようになる。これが、AIにSQLを書かせる時代に人が握っておくべき一線だ。

手を動かして確かめたい人は、SQLを演習ベースで学べる講座や、データ分析の実践を積める学習プラットフォームを足がかりにするのもいい。

tasklogでは、開発者の技術記事が実際にどのSQL書籍を引用しているかを被引用ランキングとして集計している。SQLに限らず、次に何を学ぶか迷ったときの参考に覗いてみてほしい。