「AIが書いてくれるなら、プログラミングを学ぶ意味ってあるんですか?」
最近いちばん多く聞かれる質問です。ポジショントークを抜きに答えます。学ばなくていい部分と、学ばないと詰む部分がはっきり分かれます。その線引きを説明します。
結論:文法は学ばなくていい。判断は学ばないと詰む
- 学ばなくていい:文法の暗記、書き方の作法、ライブラリの使い方の丸暗記
- 学ばないと詰む:何が正しく動いているかを確かめる力と、壊れたときに切り分ける力
前者はAIが肩代わりします。後者は肩代わりできません。AIは「あなたが望んだもの」ではなく「あなたが言ったもの」を作るからです。
学ばなくていいことは、本当に学ばなくていい
かつてプログラミング学習の大半は「書けるようになる」ことに費やされていました。セミコロンの位置、括弧の対応、ライブラリの呼び出し方。ここは正直、もう時間を割く価値が薄いです。
覚えていない構文をAIに書かせて、動いたらそれでいい。これは手抜きではなく、道具が変わったので割り当てを変えたというだけです。電卓が出た後に筆算の速度を競わないのと同じです。
「基礎からやらないと身につかない」という助言は、基礎の定義が更新されていないことが多いです。
学ばないと詰むこと(3つ)
1. 「動いている」を確かめる力
AIの出力は、間違っていてもエラーを出しません。画面は表示されるし、ボタンも押せる。でも保存されていない、別の人のデータが見えている、条件が1つ抜けている——こういう壊れ方をします。
必要なのは、「何が起きていれば正解か」を自分で定義して、確かめる力です。これはプログラミング知識というより、仕様を言語化する力に近いです。
2. 壊れたときに切り分ける力
動かなくなったとき、原因の候補を絞れるかどうかで所要時間が10倍変わります。
- 画面の問題か、データの問題か
- 自分の環境の問題か、コードの問題か
- 直前に何を変えたか
AIに聞くにしても、切り分けた情報を渡せる人と「動きません」としか言えない人では、返ってくる答えの質がまるで違います(→指示の書き方7つのコツ)。
3. 公開していい状態かを判断する力
これが一番シビアです。個人で遊ぶ分にはどう作っても自由ですが、他人に使わせた瞬間に責任が発生します。
- パスワードや鍵がコードに直接書かれていないか
- 他人のデータが見えてしまわないか
- 外部から来た入力を無条件に信用していないか
AIに「危ない点を挙げて」と聞くことはできます。ただし最終的に責任を取るのは自分です。判断できないなら公開しない、が正解です(→失敗7つ)。
では、何をどう学ぶのか
順番はこうです。
| 段階 | やること | 学ぶ深さ |
|---|---|---|
| 1 | AIに作らせて動かす | 文法は覚えなくていい |
| 2 | 出てきたコードを「説明して」と聞く | 読めるようになる |
| 3 | 自分で少し書き換えてみる | 触れる範囲を広げる |
| 4 | 壊して直す | 切り分けができるようになる |
「書ける」より先に「読める」を目指してください。AIが書いたものを読んで、意図と合っているか判断できれば、実務では十分に戦えます。
具体的な進め方は独学ロードマップにまとめました。
よくある反論への回答
「AIが完璧になれば、判断力も要らなくなるのでは?」
将来はそうかもしれません。ただし現時点では確実に必要です。そして「AIが完璧になるまで待つ」という選択は、その間に手を動かした人との差が開くだけです。
「結局スクールに行けということ?」
いいえ。無料で十分到達できる範囲は広いです(→教材の選び方)。伴走やフィードバックが欲しくなったときに、初めて検討すればいい話です。
「エンジニアの仕事はなくなるのでは?」
「書く仕事」の比重は下がります。一方で「これでいいと判断する仕事」の価値は上がっています。実際、私の受託の現場でも、実装より要件の詰めに時間を使う比率が上がりました。
まとめ
- 文法の暗記は不要。そこはAIが肩代わりする。
- 確かめる力・切り分ける力・公開判断の力は肩代わりできない。
- 目指すのは「書ける」より先に「読める」。
- 学ぶ順番は 作る → 説明させる → 書き換える → 壊して直す。
次に読む
- 3ヶ月の学習設計 → 独学ロードマップ
- 何が作れるのか → 作れるもの10例
- 仕事にするなら → バイブコーディングで副業はできる?
