AIがプログラムを書く時代になって得するのは誰？
最近の生成AIの進歩はすさまじいもので、ここ数年でプログラミングの世界をすっかり変えてしまいました。
かつては、プログラマが仕様を理解し、クラスを設計し、アルゴリズムを考え、コードを書き、デバッグする…という一連の作業を自分自身で行うのが当たり前でした。
しかし、現在は違います。
ChatGPTやGitHub Copilot、Claude Codeなどを使えば、自然言語で指示するだけで、かなり複雑なプログラムまで生成してくれて、単にコードを書くだけではなくエラーの原因を調べ、修正案を提示し、テストコードまで作成してくれます。
もはや、プログラマがすべてのコードを自分で書く必要はなくなりつつあります。
これは、間違いなく素晴らしい進歩です。
ただし、ここで一つ、大きな問題があると感じています。
AIによるプログラミングの恩恵を、本当の意味で受けられるのは、プログラミングの実力を持った人間だけなのではないか。
ということです。
AIが書いたコードの問題点に気が付けるか
例えば、AIに業務アプリケーションの作成を依頼したとします。すると、AIは驚くほど短時間で、それらしいコードを生成してくれます。
しかし、そのコードが本当に正しいのかどうかは、別の問題です。
- 一見正常に動いているが、特定の条件で誤動作する
- データ量が増えると、極端に処理速度が低下する
- メモリ管理に問題がある
- セキュリティ上の脆弱性が含まれている
- 将来的な機能追加が困難な構造になっている
このような問題は、プログラミング経験が豊富なエンジニアであれば、コードを見た段階で違和感を覚えることがあります。
「この処理は危ないのではないか」
「ここは、もう少し別の構造にした方がよいのではないか」
そうした直感は、長年の経験によって培われたものです。
もちろん、ベテランであってもすべての問題を発見できるわけではありません。しかし、少なくとも何を疑い、どこを確認すべきかという判断力があります。
一方、プログラミング未経験者や、経験の浅い若手エンジニアの場合はどうでしょうか。AIが生成したプログラムが動いてしまえば、それで正しいと判断してしまうかもしれません。
問題が存在すること自体に、気が付けないのです。
AIはコードを書く能力を大幅に高めてくれました。しかし、コードの品質を評価する人間の能力まで、自動的に高めてくれるわけではありません。
若手エンジニアは、どこで経験を積むのか
そのような状況で考えなくてはならないのが、これからの若手エンジニアが、どのようにしてプログラミングの実力を身につけるのか、という問題です。
これまで、多くのエンジニアは、実際の開発現場で経験を積んできました。
簡単なプログラムを書き、失敗し、原因を調べ、修正する。さらに、先輩の書いたコードを読み、自分のコードをレビューしてもらう。
時には、何時間もかけて、たった一つのバグを修正する。
こうした経験を積み重ねることで、少しずつプログラムの構造や問題点を理解できるようになっていきました。
ところが、AIによって簡単なプログラムの作成や修正が自動化されると、事情が変わってきます。
従来、若手エンジニアが担当していた比較的簡単な作業を、AIが代わりに行うようになるからです。
つまり、経験を積まなければ実力が身につかないのに、その経験を積む機会そのものが減ってしまう可能性があるのです。
これは、エンジニアに限らず、あらゆる分野の職業で出てくる問題でしょうが、特にプログラマーに関しては、それが顕著だといえるでしょう。
もちろん、AIを活用した新しい学習方法も生まれるでしょう。しかし、AIに任せるだけでは身につかない能力があることも、忘れてはいけないと思います。
8ビットパソコンの時代を振り返る
ここで、少し昔の話をしたいと思います。
私がプログラミングを学び始めた頃、パソコンといえば8ビットパソコンでした。
NECのPC-8001やPC-8801、シャープのMZシリーズ、富士通のFMシリーズなどが使われていた時代です。
当時、個人が利用できるプログラミング言語の代表格はBASICでした。
いうまでもないことですが、現在のような高機能な開発環境などありません。
インターネットもなければ、もちろん生成AIもありません。わからないことがあれば、マニュアルや雑誌を調べるしかありませんでした。しかも、雑誌や専門書も高くて、どこででも手に入るわけではありませんでした。
プログラムを作るときには、まず紙にフローチャートを書いて、処理の流れを整理しました。現在でしたら、ドキュメントもPCのツールを使って作るので、それを考えたら、実に原始的なやり方です。
そして、そのフローチャートを見ながら、BASICのコードを入力していきます。
ところが、そのころマイコンに標準で内蔵されていたBASICは、お世辞にも高速な言語とは言えませんでした。
ゲームなど、処理速度が要求されるプログラムを作ろうとすると、BASICだけでは限界がありました。
そこで登場するのが、マシン語です。
マシン語を16進数で直接入力していた
現在では、アセンブリ言語ですら、一般的なアプリケーション開発で使用する機会は少なくなりました。
しかし、当時は処理速度を上げるために、マシン語を使うことがありました。
しかも、アセンブラは誰もが気軽に使えるものではありませんでした。ソフトウェア自体が高価だったり、入手が難しかったりしたのです。
そのため、ハンドアセンブルという方法を使うこともめずらしくありませんでした。
ハンドアセンブルとは、アセンブリ言語の命令を紙に書き、それを自分で機械語の命令コードに変換するのです。
例えば、Z80であれば、
LD A, 05H
ADD A, 03H
RET
という処理を、
3E 05 C6 03 C9
という16進数のバイト列に変換し、メモリに直接入力します。今考えれば、なんとも原始的な作業です。
当然、入力を一文字間違えただけでも、プログラムは正常に動きません。
場合によっては、パソコンが暴走してしまうこともありました。
そのうえ、デバッグ環境も貧弱です。エラーメッセージも、現在のように親切ではありません。特にマシン語の場合、たった1文字の打ち間違いでプログラムが暴走してしまい、デバッグどころか、パソコンを再起動させなくてはならないというひどい環境でした。
それでも、マニュアルを読み、命令コードを調べ、メモリの内容を確認しながら、なんとかプログラムを完成させていました。
当時は苦労の連続でしたが、今になって振り返ると、非常に貴重な経験だったと思います。なぜなら、コンピュータが内部で何をしているのかを、嫌でも意識せざるを得なかったからです。
C言語が使えるようになったときの感動
その後、16ビットパソコンが普及し、C言語を使える環境が身近になってきました。
もちろん、C言語自体は16ビットパソコンの登場以前から存在していました。しかし、個人が所有するパソコンでもC言語による開発ができるようになったことは、大きな変化でした。
ハンドアセンブルで苦労していた人間にとって、C言語は本当にありがたい存在でした。
変数が使え、配列が使え、関数が使える。
さらに、条件分岐や繰り返し処理を、わかりやすく記述できる。しかも、コンパイラが機械語に変換してくれるのです。現在の感覚では当たり前のことですが、当時は画期的でした。
おまけに、使用するPCやOSが違っても、C言語の文法自体は変わらないのもありがたいものでした。
なぜなら、昔、BASIC言語は、使用するPCの機種によって、文法が全く違う、というのが当たり前だったからです。
そして、C言語にはもう一つ、大きな特徴がありました。
それは、コンピュータの内部構造を意識しながら、実用的なプログラムを書くことができるという点です。
C言語は、今でもプログラミング教育に適している
現在、C言語は必ずしも新規のアプリケーション開発に最適な選択肢ではありません。
特に、メモリ安全性の観点では注意が必要です。
ポインタの誤用、バッファオーバーフロー、解放済みメモリへのアクセスなど、重大な問題を引き起こす可能性があります。
安全性を重視する新規開発では、Rustなどのメモリ安全性を考慮した言語が適している場合もあります。
それでも私は、プログラミングの基礎教育において、C言語は今なお非常に優れた選択肢の一つだと考えています。
なぜなら、C言語では、プログラムの内部構造を隠しすぎないからです。
例えば、次のようなことを学べます。
- 変数の値がメモリに格納される仕組み
- 配列とメモリアドレスの関係
- ポインタによる間接参照
- 関数呼び出しと引数の受け渡し
- 動的なメモリ確保と解放
- データ構造とアルゴリズムの関係
高水準言語では、こうした仕組みの多くが抽象化されています。
それ自体は、開発効率を高めるための重要な進歩です。
しかし、抽象化された仕組みを利用することと、その仕組みを理解していることは、同じではありません。
C言語では、メモリの扱いを間違えると、プログラムが正常に動かなくなることがあります。
教育の場では、こうした失敗そのものが、重要な学習材料になります。
そして、C言語は、低水準の仕組みを学ぶだけの言語でもありません。
ファイル処理やデータ構造を利用して、簡単な業務アプリケーションを作ることもできます。
つまり、コンピュータの内部構造を理解するための低水準な要素と、実用的なアプリケーションを開発するための高水準な要素を、両方備えているのです。
この絶妙な位置にあることが、C言語の教育的な価値だと思います。
あえて、昔の不便な環境に戻してみる
ここで、最初の話に戻ります。
AIがプログラムを書いてくれる時代に、どのようなプログラミング教育が必要なのでしょうか。
私は、一つの方法として、あえて昔の不便なプログラミング環境を再現することを考えています。
例えば、次のような学習環境です。
- インターネットに接続しない
- スマートフォンも使用しない
- 生成AIによるコード生成は禁止する
- 最初に紙と鉛筆でフローチャートを書く
- C言語を使って、自分でコードを入力する
- エラーが発生したら、マニュアルを読んで原因を調べる
- デバッガなどの支援機能も、学習段階に応じて制限する
もちろん、これを実際の開発現場で行う必要はありません。
あくまでも、基礎教育のための環境です。
現在の開発環境は、非常に親切です。
入力補完をしてくれますし、構文エラーもその場で指摘してくれます。AIを使えば、修正案まで提示してくれます。
しかし、あまりに親切な環境では、学習者が自分で考える前に答えが出てしまいます。
なぜ、そのエラーが発生したのか。
なぜ、そのアルゴリズムでは正しく動かないのか。
なぜ、メモリの内容が書き換わってしまったのか。
こうした問題に、自分自身で向き合う時間が必要なのではないでしょうか。
重要なのは、単に不便な環境を押し付けることではありません。
不便さを通じて、普段は意識しないコンピュータの仕組みを理解させることです。
AIを使わない教育は、AIを使いこなすための教育でもある
誤解してほしくないのですが、私はAIによるプログラミングを否定しているわけではありません。
むしろ、これからのソフトウェア開発において、AIの活用は不可欠になると考えています。
ただし、AIを使いこなすことと、AIに依存することは違います。
AIが生成したコードを理解し、問題点を発見し、必要に応じて修正する。
そのためには、プログラミングの基礎力が必要です。
そして、その基礎力を身につけるには、AIに頼らず、自分の頭で考え、自分の手でコードを書き、失敗を繰り返す経験が役に立つはずです。
例えば、教育を二つの段階に分けてもよいかもしれません。
第一段階は、AIを使わないプログラミング教育。
ここでは、アルゴリズム、データ構造、メモリ、プログラムの実行原理などを、自分の手を動かしながら学びます。
第二段階は、AIを活用したプログラミング教育。
ここでは、AIにコードを生成させ、その内容を理解し、レビューし、テストし、改善する方法を学びます。
この二つを組み合わせることで、単にAIにコードを書かせるだけではない、本当の意味でAIを活用できるエンジニアを育てられるのではないでしょうか。
不便さを教育資源にできないだろうか
現在のプログラミング教育は、いかに短期間で成果を出すか、いかに簡単にアプリケーションを作れるようにするか、という方向に進んでいるように感じます。
それは、それで大切なことです。
しかし、完成したアプリケーションが動くことと、その仕組みを理解していることは、別の問題です。
AIによってコード生成が容易になればなるほど、この違いは大きな意味を持つようになると思います。
昔のプログラミング環境には、不便なことが山ほどありました。
マニュアルを何度も読み返し、紙にフローチャートを書き、エラーの原因がわからず、何時間も悩む。
当時は、そんな苦労をしなくて済む時代が来ることを夢見ていました。
そして、実際にその時代がやってきました。
ところが、今度は、その便利さによって、基礎を学ぶ機会が失われるかもしれないのです。
なんとも皮肉な話です。
もちろん、昔の教育方法がすべて優れていたわけではありません。意味のない苦労を繰り返させても、学習効果は期待できません。
大切なのは、昔の環境をそのまま復活させることではなく、当時の不便さの中にあった教育的な価値を、現代に合わせて再構成することでしょう。
例えば、ネットワークから切り離されたPCと、C言語のコンパイラ、簡素なエディタ、紙のマニュアルだけを用意する。
そこで、簡単なプログラムから始め、少しずつ複雑な処理を作らせる。
必要に応じて、メモリの内容や機械語の動作も確認させる。
そして、最後にAIを使って同じ課題を解かせ、自分の書いたコードと比較してみる。
そんな教育環境があってもよいのではないでしょうか。
AIがコードを書いてくれる時代だからこそ、あえてAIを使わずにコードを書く時間が必要なのではないか。
最近、そんなことを考えています。
そして、いつか、そのような教育ができる環境を作れたら面白いのではないか、とも思っています。