GUIDE / 学習の意思決定 / 更新 2026-10-27

AIがクエリを書く時代に、DB設計を学ぶ価値はどこにあるか

AIがクエリを書く時代に、DB設計を学ぶ価値はどこにあるか

「SQLはもうAIが書いてくれる。だからデータベース設計を今さら深く学ぶ必要はない」という声をよく聞く。一見すると筋は通っている。JOINの書き方もサブクエリの組み方も、AIに聞けばその場で返ってくる。テーブルを引き渡して「このデータから月次の売上を出したい」と頼めば、構文として正しいSQLはすぐに出てくる。だとすれば、人間が時間を割くべき場所は減っているはずだ。

だがこの話には、ひとつ重要な取り違えがある。「クエリを書く」ことと「スキーマを設計する」ことは、見た目が似ているだけで、根本的に別の種類の作業だという点だ。

クエリには正解があり、設計には正解がない

クエリを書くという作業は、「すでに決まっている構造の上で、望む結果をどう取り出すか」を解く問題だ。この問題には、答え合わせの基準がはっきりしている。実行すれば結果の行が返り、それが期待と一致するかどうかをその場で確かめられる。正解・不正解が速く判定できる問題は、AIが力を発揮しやすい領域そのものだ。間違っていれば書き直せばいいし、損失は小さい。

一方でスキーマ設計、つまりテーブルをどう分け、どの列にどんな制約を置くかという判断は、「今はまだ存在しない将来の使われ方にも耐える構造とは何か」を先取りして決める作業だ。この問いには、実行してすぐ分かる正解がない。良い設計だったかどうかは、半年後に新しい機能を足したときや、データが大きく増えたときに、初めてその答えが出る。目の前で結果が返ってこない判断は、AIが最も苦手とする領域でもある。AIは渡された要求には最適化できても、その要求の外側にある「まだ語られていない将来の使われ方」までは知りえない。

書き直せるものと、消せないものの非対称

クエリの間違いは、見つかった瞬間に書き直せば消える。テーブルには何の跡も残らない。ところがスキーマの間違いは、データが入ったあとでは同じように消せない。構造や制約を直すには、すでに溜まっているデータを壊さずに移す作業が挟まるため、設計のミスは発覚が遅れるほど高くつく。これが、設計という判断を軽く見てはいけない理由の技術的な土台だ。問題はここで終わらない。この土台の上で、設計の勘所を持たないまま学習を進めた人が、実際にどこで詰まるかにある。

学ぶ順番を入れ替える

クエリの書き方を後回しにして、先に設計の勘所に時間を使うべきだという話は、技術としての優劣の話ではない。学習に使える時間は有限で、どちらに先に投資するかという配分の問題だ。そして設計の勘所を後回しにしたまま進んだ学習者が、具体的にどこで詰まるかを見ていくと、この配分の答えは自然と見えてくる。

最初に詰まるのは、自分が作ったはずのテーブルを、自分の言葉で説明できない場面だ。AIに頼んでテーブルを用意してもらい、動くアプリができた。だが後で同僚やレビュー相手に「なぜこの列をこの型・この制約で持ったのか」と聞かれても、答えが出てこない。設計の判断そのものを自分で下していないので、自分が作ったものの「なぜ」が、自分の中に存在しないのだ。

次に詰まるのは、AIが出してきた設計を評価する基準を持てず、そのまま採用してしまう場面だ。クエリなら実行結果を見れば正誤がすぐ分かるが、設計には実行してすぐ分かる答えがない。だから「AIがこう作ったのだから、たぶん大丈夫だろう」という以上の判断ができず、提案を検証せずにそのまま通してしまう。設計の原則を知らない学習者ほど、この採用の場面でブレーキを持てない。

そして最後に、一番高くつく詰まりがやってくる。機能を増やそうとして既存のテーブルに手を入れたら、思わぬ場所でデータの矛盾が現れた――という場面に出くわしたとき、原因が設計そのものにあると気づけない。クエリの書き方やAIへの指示の出し方のほうを疑ってあちこち直そうとするが、根本の構造が歪んでいる限り、同じ種類の不具合は形を変えて出続ける。設計の勘所を持たない学習者には、不具合の「症状」は見えても、「どこに手を入れれば直るのか」という地図が見えない。

この三つの詰まりは、いずれも「クエリの書き方」をどれだけ練習しても解消しない。だからこそ、限られた学習時間をどちらに先に振るかを決めるなら、答えは一つだ。SELECT文の細部を覚える時間はいったん後ろに回し、正規化・制約・テーブルの境界という「設計を自分の頭で評価するための基準」をつくる方に、最初の時間を使うべきだ。AIに聞けばすぐ返ってくる知識を学ぶより、AIの答えを自分で検証できる判断力を先に育てる方が、限られた学習時間の使い方としてずっと効く。

次に自分のテーブルを設計するとき、「このテーブルに後から列を足したら、矛盾は生まれないか」「この制約を外したら、どんな壊れたデータが入り込めるか」と自分に問う習慣を持てるかどうか。この問いに答えられる力は、クエリの文法をいくら覚えても身につかない。AIが書く行数が増えるほど、むしろ価値を増していく判断力だ。

実際に手を動かして設計の感覚を掴みたいなら、PostgreSQLの入門から始めるのが近道だ。

https://s-tasklog.com/learn/postgresql

クエリを書く力そのものをAIにどこまで渡していいかという話は、こちらで別に整理している。

https://s-tasklog.com/guide/sql-still-worth-learning-ai

tasklogは、学習の優先順位に迷ったときに参照できる教材・技術書の集約サイトだ。設計の原則を学べる一冊を探すときの手がかりに使ってみてほしい。

https://s-tasklog.com/books/sql

スポンサーリンク

ほかのガイド