さて、前回の記事からずいぶんと日が経ってしまった。
などという程度ではない。最初にこのテーマを書き始めたのが2018年頃だから、もう8年ほど経過している。
当時、筆者はプログラムコードの自動生成について考察し、Visual StudioのT4テンプレートやExcel設計書を利用したコード生成の方法などを紹介していた。
そして、プログラムを最初から最後まで全自動生成するようなツールについては、制約が強く、カスタマイズも難しく、かえって工数が増えることがあるとして、事実上却下していた。
なので、実務上、この自動生成は、さほど活躍できたわけでもなかった。
ところが2026年の現在、筆者自身がChatGPTやClaude、CodexなどのAIにプログラムを書かせている。
それも、ちょっとした関数やクラスの生成だけではない。既存のプロジェクト全体を調査させ、設計を検討させ、コードを修正させ、テストまで実行させる。
もっとも、すべてがこれでうまく行っている、ということではない。
ただ、8年前の自分が見たら、いったい何が起こったらこうなるのかと驚くだろう。
コードを書く仕事が、コードを書かせ、それを操縦・制御する仕事になった
振り返ってみると、この変化は驚くほど短期間に起こった。
2021年にGitHub Copilotが登場し、AIがプログラムコードの続きを提案するようになった。
2022年にはChatGPTが公開され、自然言語で要求を伝えるだけでプログラムを生成できるようになった。
さらに2024年頃からは、CursorなどのAI統合型開発環境が普及し、2025年にはVibe Codingという言葉が登場した。Claude CodeやCodexなどのAIエージェントも発展し、複数ファイルにまたがる改修やテストまで実行できるようになってきた。
この変化は、単にコーディング速度が向上したという話ではない。
以前は、人間が実装方法を考え、その内容をプログラミング言語によってコンピュータに伝えていた。
今では、人間が「何を実現したいのか」をAIに伝え、AIが実装方法を考えてコードを書くことができる。
つまり、人間がプログラムを書くことから、AIにプログラムを書かせることへ、仕事の重心が移り始めたのである。昔、アセンブラから高級言語へ移行した時代の推移という経験もある。どちらも人間がコンピュータに指示する方法を、より人間に近い表現へ変えてきたという共通点がある。それで言うならば、今は、高級言語から生成AIへの移行、ということだ。ただ、以前の進化が「プログラムをどう記述するか」という問題だったのに対して、今回の進化は「プログラムをどう作るか」という問題にまで踏み込んでいる点が異なる。
以前の記事では、3600行のコードを手作業で書けば10時間かかる、などという計算をしていた。
今では、その程度のコード量なら、AIが数分で生成することも珍しくない。
なんとも隔世の感がある。
ところが、コードを大量に書けることが問題にもなる
では、これでプログラミングの問題はすべて解決したのだろうか。
残念ながら、そう簡単な話ではない。
実際にAIを使って開発してみると、興味深い問題に遭遇する。
例えば、既存プログラムの不具合を修正するようにAIに指示すると、その不具合は見事に解決してくれる。
ところが、別の機能が動かなくなっていたり、従来の設計思想に反するロジックが追加されていたりすることがある。
しかも、コード自体は整然としていて、テストも正常終了している。
AIは、一般的には合理的と思われる修正を行っているのだろう。しかし、そのシステム固有の目的や、過去の試行錯誤によって決定された設計上の制約まで、必ずしも理解しているわけではない。
コードとして正しいことと、作りたいシステムとして正しいことは、まったく別の話なのである。
そして、こうした問題を修正するために、さらにAIに修正を依頼し、それによって別の問題が発生し、また修正する。
気がつけば、当初の設計思想とは異なる複雑なプログラムが出来上がっていた、などということも起こり得る。
8年前には、自動生成ツールの複雑な仕掛けに振り回されることを懸念していた。
今度は、AIが次々と生成するコードに振り回される危険性が出てきたわけだ。
道具は劇的に進歩したが、人間が道具に振り回されるという問題は、案外変わっていないのかもしれない。
8年前の考え方は、もう通用しないのか
ここで、最初の記事で述べた考え方に戻ってみたい。
当時、筆者はコーディングの効率化を次の3つに分類した。
- 地道にコツコツとコードを書く。
- パターン化できる部分をマクロやテンプレートで自動生成する。
- プログラム構造そのものを合理化し、少ないコードで同等の機能を実現する。
そして、まず③を検討し、次に②を利用し、それでも賄えない部分を①で実装するのが合理的ではないか、と結論づけていた。
さて、AI時代になった現在、この考え方はどうなるのだろうか。
①の手作業は、AIによって大幅に代替できるようになった。
②の自動生成も、あらかじめテンプレートを作らなくても、AIが要求に応じてコードを生成できるようになった。
では③はどうだろう。
実は、③の重要性は、以前にも増して大きくなっているのではないかと思う。
AIはいくらでもコードを生成できる。
しかし、生成されたコードが本当に必要なのか、もっと簡潔な構造で実現できないのか、そもそもその機能が必要なのか、という問題は残る。
むしろ、コードを生成するコストが小さくなったことで、不要な機能や複雑な仕組みまで、簡単に作れてしまうようになった。
これは、ある意味では新たな危険性である。
以前の記事で触れたルーブ・ゴールドバーグ・マシン、つまり簡単にできることを、わざわざ複雑な仕掛けで実現するという問題が、AIによって一層発生しやすくなる可能性さえある。
だからこそ、AIにコードを書かせる前に、何を作るべきか、どのような構造が適切かを検討することが重要になる。
もちろん、その検討自体にもAIを利用すればよい。
重要なのは、AIにどれだけ大量のコードを書かせるかではなく、必要にして十分な仕組みを、いかに合理的に実現するかということだろう。
これからのプログラマーは何をするのか
AIがコードを書き、テストまで実行するようになった現在、プログラマーの仕事も変わりつつある。
プログラミング言語の構文を熟知し、正確なコードを素早く書くことは、かつて重要な技術だった。
もちろん、今でもその知識は役に立つ。
しかし今後は、それ以上に、要求仕様を明確にし、適切な設計を選択し、AIが生成した成果物を評価する能力が重要になると思われる。
何を作るべきなのか。
何を変更してはいけないのか。
どのような結果になれば成功なのか。
こうしたことを明確にできなければ、AIがどれほど優秀になっても、期待したシステムが完成するとは限らない。
そして、AIが提示した実装方法が本当に適切なのかを判断するには、やはり相応の技術的な知識や経験が必要になる。
つまり、プログラマーの仕事がなくなるというよりも、コードを書く技術から、システムを設計し、AIを使いこなし、その成果を評価する技術へと、求められる能力が変化しているのではないだろうか。
おわりに
8年前、筆者が考えていたのは、コードを効率よく生成するための仕組みだった。
ところが現在では、コードを生成する仕組みそのものを作らなくても、AIが実装方法を考え、プログラムを作ってくれるようになった。
当時の想像をはるかに超える進歩である。
しかし、ここまで振り返ってみると、少し面白いことに気づく。
8年前に最も重要だと考えていた③の「構造的な合理化」は、今でも変わらず重要なのである。
むしろ、コードをいくらでも生成できる時代になったからこそ、その重要性が際立ってきたように思う。
コードを書くことが簡単になればなるほど、何を書くべきか、何を書かないべきか、という判断の価値が高まる。
これが、この8年間を振り返って得られた、筆者なりの結論である。
さて、次の8年間でプログラミングがどのように変化するのか、まったく予想がつかない。
ひょっとすると、2034年頃には、AIに自然言語で指示を出してプログラムを作らせるという現在の方法さえ、古めかしいものになっているかもしれない。
そのときには、また続きを書いてみたいと思う。
もっとも、次回までにまた8年も経過してしまったら、もはやコード自動生成どころか、プログラミングという言葉自体が別の意味になっているかもしれないが。
