「先月の売上を地域別に集計して、前月比も出して。」
Claude Codeにこう伝えるだけで、AIがSQLを自動生成し、実行してくれる。Text-to-SQLの進化で、自然言語からデータベースを操作できる時代が来た。
では、人間がSQLを学ぶ必要はなくなったのか？
答えはノーだ。
私はPM1人+AI社員の体制で商用プロジェクトを回している。その現場で痛感しているのは、AIが何でもやってくれるわけではないということだ。AIが生成するコードの裏側には、50年以上前に作られた技術が土台として存在している。その土台を理解していないPMは、AIの出力の良し悪しを判断できない。
本記事では、IT業界で50年以上生き残るSQLの本質と、AI時代だからこそその思想が重要な理由を、PMBOK-AIの視点から紐解く。
半世紀生き残るSQLの本質：数学的完成度と「宣言型」の力
地獄の迷宮探索から「宣言型」へ
1960年代、データベースは「階層型」と呼ばれるツリー構造が主流だった。この方式では、プログラムがデータの物理的な保存場所をすべて把握していなければならず、データ構造が少し変わるだけで、依存するプログラムを全部書き直す必要があった。
当時のエンジニアは、データを探すための「迷宮探索」に全エネルギーを注いでいた。
この混沌を数学的に解決したのが、1970年にIBMの研究所にいたエドガー・F・コッド博士が発表したリレーショナルモデルだ。彼の主張はシンプルだった。
「データが物理的にどこにあるかなんて、人間が気にしなくていいはずだ。」
「どうやって探すか」という手順をコードに書くのではなく、「何が欲しいか」を集合論に基づいて宣言するだけで、コンピューターが最適な方法でデータを持ってくる。この宣言型言語の思想こそが、SQLが50年変わらず生き残っている最大の理由だ。
ここで気づいた人もいるかもしれない。この「何が欲しいかを宣言する」という思想は、現在のAIへのプロンプト指示とまったく同じ構造だ。 50年前にコッド博士が描いた未来を、今AIが実現しつつある。
余談だが、コッド博士のこの革命的な論文に対し、当時のIBMは自社の階層型データベース製品の売上を懸念して製品化を後回しにした。その公開された論文を読み、いち早く商用化したのが、後にOracleを創業するラリー・エリソンだ。理論を軽視した大企業と、理論に賭けた起業家。 IT業界の原点とも言えるエピソードだ。
圧倒的信頼を生む「ACID特性」
SQLが世界中の銀行や基幹業務で絶対的に信頼されている理由は、ACID特性にある。
Aさんの口座から10万円を引き、Bさんの口座に10万円を足す。この処理の途中でサーバーが停電したら、どうなるか。中途半端にデータが消えては困る。
SQLはトランザクションという仕組みで、「全部成功するか、最初からなかったことにする（ロールバック）かの2択」を保証する。
| 特性 | 意味 | 具体例 |
|---|---|---|
| Atomicity（不可分性） | 中途半端な状態を残さない | 送金の引き落としと入金は必ずセットで実行 |
| Consistency（一貫性） | ルール違反のデータを許さない | 残高がマイナスになる取引を拒否 |
| Isolation（独立性） | 同時処理が互いに干渉しない | 2人が同時に同じ口座を操作しても矛盾しない |
| Durability（永続性） | 確定したデータは消えない | 障害後に復旧しても取引記録は残る |
この4つが、金融システムに求められる100%の正確性を50年間支え続けている。
コンビニでスマホ決済をする瞬間も、銀行口座の残高を確認する瞬間も、裏側ではこのACID特性を持つSQLが現役で動いている。AIがどんなに進化しても、この「正確にデータを扱う」という土台は変わらない。
NoSQLブームの痛い教訓
2000年代、インターネットの爆発的な普及に伴い、SQLでは複数サーバーへのスケールが難しいと批判された。そこで台頭したのがNoSQLだ。
「SQLはもう古い」「これからはNoSQLの時代だ」——業界全体がスケーラビリティに熱狂した。
しかし、ACID特性を捨てた代償は大きかった。
NoSQLが採用した「最終的整合性（いずれデータが揃う）」という考え方は、在庫管理や金融システムでは致命的だった。「在庫が残り1個」の商品を5人が同時に購入できてしまう。送金処理が片方だけ成功して宙に浮く。
結局、エンジニアたちはアプリケーション側のコードで自前でデータの整合性を担保する羽目になった。車輪の再発明、しかもバグ付きの。 SQLが数十年かけて完成させた堅牢性を、数ヶ月の自前実装で再現しようとして地獄を見たのだ。
その結果、2012年にGoogleが発表した「Spanner」を皮切りに、分散処理とACID特性を両立させた**NewSQL（分散SQL）**が登場。業界全体が再びSQLの思想へと回帰した。
技術のトレンドは一周した。しかしSQLの数学的な基盤は、一度も揺らがなかった。
現場で起きていること：内部構造を「気にしなくていい」時代
ここからは、私がAI社員と開発する現場で実感していることを書く。
SQL最適化の50年は「気にしなくていい」を積み上げた歴史
SQLの50年間は、ひたすら人間が気にしなければならないことを減らしてきた歴史だ。
| 年代 | 最適化の内容 | 人間が気にしなくてよくなったこと |
|---|---|---|
| 1970年代 | リレーショナルモデルの誕生 | データの物理的な保存場所 |
| 1980年代 | クエリオプティマイザの進化 | どのインデックスを使うか |
| 1990年代 | コストベースオプティマイザ | テーブルの結合順序 |
| 2000年代 | パーティショニング、並列処理 | データの分散配置 |
| 2010年代 | NewSQL、分散SQL | 複数サーバー間の整合性 |
| 2020年代 | Text-to-SQL、AI統合 | SQL構文そのもの |
初期のSQLでは「どのインデックスを使えば速いか」をエンジニアが手動で判断していた。今のデータベースエンジンは、クエリオプティマイザが統計情報をもとに最適な実行計画を自動選択する。そしてAI時代の今、SQL構文を書くこと自体をAIが肩代わりするようになった。
50年かけて、SQLは「何も気にしなくていい」の極限に近づいている。
AI開発の現場で「内部」が見えなくなっている
この「気にしなくていい」の流れは、SQL以外の開発全体にも広がっている。
私がClaude CodeでNext.jsのアプリケーションを開発するとき、以下のことを「気にしていない」。
- Webpackのバンドル設定 → Next.jsが自動最適化
- CSSの詳細なレイアウト計算 → Tailwind CSSで宣言的に指定
- APIルートの型定義 → TypeScriptの型推論とAIが自動生成
- テストコードの構文 → AIが仕様を元に自動生成
5年前なら手作業で設定していたものが、フレームワークとAIの進化によって抽象化された。開発者が気にすべきことは、「何を作るか」と「それは正しいか」だけに収束しつつある。
しかし、ここに落とし穴がある。
Vibe Codingの先にあるもの：AI生成コードの「責任」
弊社のブログでも書いた通り、商用開発はお金をもらう以上、「ノリ」だけでは動かせない。
AI社員の導入で私が痛感した失敗のひとつが、AIへの丸投げによる品質崩壊だ。
AIは自然言語から見事なSQLを生成してくれる。しかし、それが常に正しいとは限らない。
AIが生成するSQLの「見えない罠」
実際に遭遇した問題を挙げる。
1. 暗黙の型変換によるインデックス無効化
AIが生成したWHERE句で、文字列型のカラムに数値を直接比較していた。構文的には動くが、インデックスが使われず、本番データ量でフルスキャンが走った。100万行のテーブルで、0.01秒で返るはずのクエリが30秒かかった。
2. N+1問題の埋め込み
一覧画面でユーザー情報と関連データを取得する際、AIがループ内で個別クエリを発行するコードを生成した。10件なら問題ないが、1000件のデータで1001回のクエリが走る。JOIN一発で済む処理だ。
3. トランザクション境界の誤り
複数テーブルへの更新処理で、AIがトランザクションの範囲を狭く切りすぎた。片方のテーブルだけ更新されて、もう片方が失敗するケースが本番で発生。ACID特性のA（不可分性）が崩れた。
いずれも、SQLの基本思想を理解していれば5秒で気づく問題だ。しかし、AIの出力を「動いたからOK」で通してしまうと、本番環境で初めて顕在化する。
品質を担保するのは「人間のレビュー」
AIがSQLを自動生成できるようになったからこそ、そのクエリが本当に正しいのかを判断する人間の目が不可欠になった。
- ACID特性を担保できているか？
- 大規模データでパフォーマンスが劣化しないか？
- ビジネスロジックの意図と一致しているか？
AIの生成物の良し悪しを判断するためには、結局のところSQLの知識が必要だ。 内部構造を「気にしなくていい」時代になったからこそ、「何を気にすべきか」を知っている人間の価値が上がっている。
PMBOK-AIの実践：不変の基礎技術とAIのハイブリッド
当社が提唱するPMBOK-AIは、PM1人とAI社員で開発プロジェクトを回す新しいマネジメント手法だ。
この体制を成功させる鍵は、技術の適材適所を見極める力にある。
| データの性質 | 最適な技術 | 理由 |
|---|---|---|
| 基幹データ（顧客・取引・在庫） | SQL（RDB） | ACID特性による整合性保証 |
| ログ・センサーデータ | NoSQL（時系列DB） | スケーラビリティとスピード |
| 非構造化データ（チャット・画像） | NoSQL（ドキュメントDB） | スキーマレスの柔軟性 |
| 分析・集計 | SQL（分散SQL） | 集合演算の表現力 |
「SQLかNoSQLか」ではなく、「このデータにはどちらが適切か」を判断する。 これがAIプロジェクトマネジメントにおけるPMの仕事だ。
コッド博士の思想とPMBOK-AIの共通点
面白いことに、コッド博士が50年前に提唱した「宣言型」の思想は、PMBOK-AIの根幹と重なる。
| 概念 | SQL（1970年代） | PMBOK-AI（2020年代） |
|---|---|---|
| 人間の仕事 | 「何が欲しいか」を宣言する | 「何を作るか」を定義する |
| 機械の仕事 | 最適な方法でデータを取得する | 最適な方法でコードを生成する |
| 人間が気にしないこと | データの物理的な保存場所 | コードの具体的な実装方法 |
| 人間が気にすべきこと | 結果が正しいかの検証 | 生成物が仕様通りかのレビュー |
「人間は何（What）を定義し、機械がどう（How）を実行する。」
この分業構造は、コッド博士の時代もAI社員の時代も同じだ。変わったのは「機械」の能力だけで、「人間が判断する」という原則は50年間不変だ。
まとめ：基礎の上にAIは立つ
UIのトレンドは移り変わる。フレームワークは数年で入れ替わる。しかし、「データを正確に、安全に、永続的に扱う」という本質的な課題は50年間変わっていない。
AIがコードを書いてくれる時代だからこそ、その土台にあるSQLの思想——宣言型の設計、ACID特性、集合演算——を理解する価値がある。基礎技術を知っているPMは、AIの出力を検証できる。知らないPMは、AIの出力を祈りながらデプロイすることになる。
最新のAIエージェントと、50年残る不変の基礎技術。この2つを組み合わせることが、PM1人+AI体制を成功させる鍵だ。
AIがコードを書く時代に、基礎技術の理解をどう深めるべきか。PMが身につけるべきスキルの優先順位はAIプロジェクトマネジメント実践ガイドで詳しく解説している。AI社員の導入と活用についてはAI社員導入ガイドもあわせてご覧いただきたい。
関連記事: Vibe Codingの先にあるもの | AI活用で痛感した失敗と教訓 | PMBOK-AIとは