AIにコードを書かせてもいい？ ― 熟練者のAI活用と「丸投げ」の違い
生成AIに「こんなアプリを作って」とお願いすると、かなりのところまでコードを書いてくれるようになりました。
実際に、自分でコードを一行ずつ書くのではなく、AIエージェントに実装を任せる開発者も増えています。
では、プログラミングを勉強している人も、
「AIが全部書いてくれるなら、自分でコードを書けなくてもいいのでは？」
と考えてよいのでしょうか。
この記事では、Ruby on Railsの作者として知られるDavid Heinemeier Hansson（DHH）のような熟練した開発者によるAI活用と、プログラミング初学者がAIに「丸投げ」する場合の違いから考えてみます。
1. AIにコードを書かせること自体が問題なのではない
まず大切なのは、AIにコードを書かせること自体が悪いわけではないということです。
開発では以前から、次のようなものを利用して、人間がすべてを一文字ずつ書かなくてもよいようにしてきました。
- IDEのコード補完
- IntelliSense
- コード生成
- ライブラリ
- フレームワーク
生成AIも、その流れをさらに大きく進めたものと考えることができます。
これからは、
人間が全部コードを書くだけでなく、
人間が指示する
↓
AIがコードを書く
↓
人間が確認するという開発も普通になっていくでしょう。
問題になるのは、AIに書かせた後です。
2. 熟練者もAIにコードを書かせている
Ruby on Railsの作者として知られるDHHも、近年はAIエージェントを積極的に開発へ取り入れています。
ここだけを見ると、「Railsを作るほどの人でもAIに書かせている。それなら初心者も全部AIに任せればいいのでは？」と思うかもしれません。
しかし、両者には大きな違いがあります。
DHHのような熟練者は、自分でキーボードを打っていなくても、次のように判断できます。
この設計でよいか？
このクラス分けは自然か？
このコードには問題がないか？
もっと単純にできないか？
将来変更しにくくならないか？つまり、「コードを書く作業」をAIに任せているのであって、「考えること」までAIに任せているわけではありません。
3. 初学者の「丸投げ」は何が違うのか
一方、まだプログラミングを学び始めたばかりの段階では、AIが生成したコードを見ても、
public event EventHandler DataChanged;というコードについて、次のようなことを判断できないことがあります。
- なぜ必要なのか
eventとは何なのか- 誰が通知するのか
- 誰が受け取るのか
- ほかの方法ではダメなのか
それでも実行して期待どおり動けば、「動いたから完成」と思ってしまうかもしれません。
ここに「AIを使うこと」と「AIに丸投げすること」の違いがあります。
4. WinFormsで考えてみよう
例えば、次のような機能を作りたいとします。
Form1
↓
Form2を開く
↓
Form2でデータを変更
↓
Form2を閉じる
↓
Form1の表示を更新AIに「Form2を閉じたときにForm1を更新するコードを書いて」とお願いすれば、コードを生成してくれるでしょう。
しかし、実現方法は一つではありません。例えば、次のような複数の方法が考えられます。
- Form1の参照をForm2へ渡す
- FormClosedイベントを利用する
- 独自イベントで変更を通知する
- データを共有してForm1側で読み直す
AIが最初に出した方法が、必ずしもそのアプリにとって最適とは限りません。
5. 熟練者は「動いた」の先を見る
熟練者がAIのコードを見るときは、
動く？だけでは終わりません。例えば、
Form2がForm1を直接操作しているな
↓
これだとForm1とForm2の結び付きが強すぎないか？
↓
Form2は「変更された」というイベントだけを通知して、
Form1側で処理したほうがよいのでは？という判断ができます。
そしてAIに「Form1を直接操作しない構造に変更して」と指示することもできます。
AIがコードを書いていても、設計の主導権は人間側にあります。
6. 危険なのは「お願い → 動いた → 完成」
初学者がAIを使うとき、注意したいのが次の流れです。
人間
「○○を作って」
↓
AI
コードを生成
↓
実行
↓
動いた！
↓
完成これでは、コードの中身をほとんど理解しないままアプリが完成してしまうことがあります。
その状態で次のように言われると、自分では変更できないかもしれません。
- 「ボタンをもう1個増やしてください」
- 「データを3件ではなく10件にしてください」
- 「Form2を使わない構成にしてください」
7. 目指したいAIの使い方
目指したいのは、こちらです。
人間が考える
↓
AIに指示する
↓
AIが実装する
↓
人間が読む
↓
人間が判断する
↓
必要ならAIに修正させる
↓
もう一度確認するAIにコードを書かせることは同じです。しかし、AIの出力を人間がコントロールしています。
ここが大きな違いです。
8. 「自分で書ける？」だけでなく「説明できる？」へ
これまでプログラミング学習では、「このコードを自分で書けますか？」が重要でした。
もちろん、基礎を学ぶ段階では今でも大切です。
しかし生成AIが普及した現在は、それに加えて、「このコードを説明できますか？」も重要になっています。
例えばAIを使って作ったプログラムなら、次のような質問に答えられるでしょうか。
| 確認すること | 質問の例 |
|---|---|
| コードを読める | この3行は何をしていますか？ |
| 理由を説明できる | なぜこのクラスが必要ですか？ |
| 変更できる | ボタンを2個にするにはどこを変更しますか？ |
| エラーに対応できる | この行を消すとなぜ動かなくなりますか？ |
| 別の方法を考えられる | ほかの書き方はありますか？ |
全部すぐ答えられる必要はありません。
分からなければAIに「この部分を初心者向けに説明して」と聞いても構いません。
重要なのは、分からないコードを分からないままにしないことです。
9. AIに作ってもらった後、少し変更してみよう
AIでプログラムを作ったら、そのまま終わりにせず、自分で小さな変更を加えてみるのもよい練習になります。例えば、次のような変更です。
ボタンの文字を変更する
↓
ボタンを追加する
↓
処理内容を少し変更する
↓
入力項目を増やす
↓
エラー処理を追加するコードをゼロから書けるかどうかだけではなく、「すでに存在するコードを読んで変更できるか」も、実際の開発では重要な能力です。
10. AIを使ったことは隠さなくてよい
作品を作るときに生成AIを使ったのであれば、「生成AIを使いました」と言って構いません。
むしろ、次のように説明できるほうが、学習の状態がよく分かります。
ここはAIに作ってもらいました。
最初は意味が分からなかったので調べました。
この部分は自分の目的に合わなかったので変更しました。
ここはまだ完全には理解できていません。AIを使ったかどうかよりも、AIを使って何を理解したのかが大切です。
11. AI時代のプログラミング学習
これからのプログラマーは、すべてのコードを暗記して、一文字ずつ自分で入力する人ではなくなっていくかもしれません。
しかし、だからといってプログラミングの知識が不要になるわけではありません。
むしろAIが大量のコードを書いてくれるほど、次の力が重要になります。
読む力
考える力
間違いに気付く力
設計を選ぶ力
変更する力AIがコードを書いてくれる時代だからこそ、基礎知識がAIの答えを判断するための力になります。
まとめ
熟練した開発者がAIにコードを書かせることと、初学者がAIに丸投げすることは、一見すると同じように見えます。
しかし、その中身は違います。
危険な丸投げ
お願いする
↓
AIが作る
↓
動いた
↓
完成ではなく、
AIを道具として使う
考える
↓
AIに作らせる
↓
読む
↓
理解する
↓
判断する
↓
変更するを目指しましょう。
大切なのは、「誰がコードをタイプしたか」ではありません。
そのコードについて、「なぜこうなっているのか」を説明でき、必要になったときに変更できること。
生成AIを使う時代のプログラミング学習では、そこが一つの大切な目標になります。