AIはプログラマーを不要にするのか?コードを書く人から、構造を考える人へ
繰り返される個の時代:第7回
最近、「プログラマーはAIに置き換わる」という話を聞くことが増えた気がしています。
Claude Code、Cursor、GitHub Copilot、OpenAI Codex。
少し前まではコード補完ツールと呼ばれていたものが、いまではコードを書き、テストを書き、ときにはPull Requestまで作るようになりました。
AIは、開発者の隣で助言する存在から、実際に開発工程へ参加する存在へ近づき始めているように見えます。
すると当然、こんな疑問が出てきます。
プログラマーは不要になるのでしょうか。
この問いは、AIが新しい領域へ入り込むたびに繰り返されてきました。
画像生成AIが広がったときにはデザイナーが、文章生成AIが広がったときにはライターが、そして今はプログラマーが、その問いの前に立たされています。
でも私は、この問いを聞くたびに少しだけ違和感があります。
本当に消えるのは、プログラマーなのでしょうか。
それとも、私たちが「プログラマー」という仕事に期待していた役割の方なのでしょうか。
今回は、AIがコードを書けるようになった時代に、人間の価値がどこへ移っていくのか、ということを考えたいと思います。
AIはどこまでコードを書いているのか
数年前まで、AIによるプログラミング支援といえば、「次の1行を予測する便利な補完機能」という印象が強かったと思います。GitHub Copilotが登場したときも、最初の驚きは「コメントを書いたらコードが出てくる」「関数の続きを予測してくれる」というものでした。
しかし、いま起きている変化は、それだけではありません。
AIはコードの続きを提案するだけではなく、既存のコードベースを読み、修正方針を立て、テストを書き、複数ファイルをまたいで変更を加える方向へ進んでいます。
OpenAIのCodexは、機能追加やバグ修正、コードベースへの質問回答、Pull Request提案などを行うソフトウェアエンジニアリング・エージェントとして説明されています。
Anthropicも、Claude Codeの利用状況を分析し、ソフトウェア開発におけるAIの役割が「補助」から「自動化」へ広がっていることを示しています。
もちろん、ここで言う自動化は、人間の確認や指示が不要になったという意味ではありません。ただ、AIが実際に手を動かす領域が広がっていることは、かなりはっきりしてきたように思います。
GitHubとMicrosoftの調査では、GitHub Copilotを使った開発者が、使わなかった開発者よりもタスクを速く完了したという結果も報告されています。
ただし、これは特定の実験条件下での結果です。すべての開発現場で同じように生産性が上がるとまでは言えません。
それでも、ここで重要なのは数字そのものよりも、AIがソフトウェア開発の周辺にいるのではなく、すでに開発工程の内側に入り始めているということだと思います。

プログラマーの仕事は、コードを書くことだけだったのか
ここで少し、問いをずらしてみたいと思います。
私たちは、プログラマーという仕事を「コードを書く人」と考えてきました。もちろん、それは間違いではありません。コードを書かないプログラマーという言い方には、どこか違和感があります。
ただ、実際のソフトウェア開発を考えると、プログラマーの仕事はコードを書くことだけではありません。
何を作るのかを理解し、仕様の曖昧さをほどき、既存システムとの関係を見て、将来の保守性を考え、バグが起きたときに原因を切り分ける。そこには、かなり多くの判断が含まれています。
つまり、コードを書くことは重要ですが、それは仕事全体の一部でもあります。
ここに、AI時代の見誤りやすさがある気がします。AIがコードを書けるようになると、私たちはすぐに「ではプログラマーはいらないのか」と考えます。しかし、それは「文章を書ける人が増えたから作家はいらないのか」と考えることに、少し似ているのかもしれません。
この連載で見てきたように、ブログが広がったとき、文章を書く人は減りませんでした。
むしろ増えました。
ケータイ小説が広がったとき、出版社の外側から物語を書く人が現れました。
YouTubeが広がったとき、映像を作る人は一部の専門職だけではなくなりました。
技術は、創作を奪うというより、創作への参加者を増やしてきた面があります。
もちろん、参加者が増えることと、質の高いものを作れることは同じではありません。
誰でもブログを書けるようになっても、良い文章を書くことは簡単ではありませんでした。
誰でも動画を投稿できるようになっても、良い映像を作るには別の力が必要でした。
同じように、AIがコードを書けるようになっても、良いソフトウェアを作る力が自動的に身につくわけではありません。
むしろ、コードを書くコストが下がるほど、
「何を作るのか」
「どう作るのか」
「それは本当に必要なのか」
という部分が、より見えやすくなっていくのかもしれません。

AIが代替しているのは「仕事」なのか、「作業」なのか
ここからが、今回の記事で一番考えたい部分です。
AIがコードを書けるようになった。
AIがテストを書けるようになった。
AIがPull Requestを作れるようになった。
これは、すでに起きている変化です。
では、AIはプログラマーの仕事を奪っているのでしょうか。
私はここで、「仕事」と「作業」を分けて考えた方がいい気がしています。
ソフトウェア開発の仕事には、さまざまな作業が含まれています。
調査する。
コードを書く。
テストを書く。
エラーを直す。
ドキュメントを整える。
これらは、AIがかなり得意になってきた領域です。
一方で、何を作るべきかを決めること、どの問題を解くべきかを見極めること、複数の設計案の中から選ぶこと、品質を評価すること、最終的な責任を引き受けることは、まだ人間の側に大きく残っています。
つまり、AIが代替し始めているのは、仕事そのものというより、仕事を構成していた一部の作業なのかもしれません。
ここを混同すると、「AIがコードを書く=プログラマーが不要になる」という短絡になってしまいます。しかし、実際にはもう少し複雑です。AIによって作業の一部が軽くなるほど、人間には、より上流の判断や構造理解が求められるようになる。
そう見る方が、現場の変化に近い気がします。

「コードを書けること」の価値は消えるのか
ここで、もうひとつ慎重に扱いたいことがあります。
「価値の重心が移る」と書くと、コードを書く力はもう不要になるのだと受け取られるかもしれません。でも、私はそうは思いません。
むしろ、コードを書いた経験がなければ、AIが出したコードの良し悪しを判断することは難しいと思います。
動いているように見えるけれど、保守しづらい。
短期的には便利だけれど、長期的には技術的負債になる。
そうした判断は、実際にコードを書き、失敗し、直してきた経験があってこそ見えてくるものです。
Stack Overflowの2025年調査でも、多くの開発者がAIツールを使っている、または使う予定がある一方で、「ほぼ正しいが完全ではないAI回答」への不満も示されています。
これは、AIが便利であることと、AIをそのまま信じられることが別問題であることを示しているように思います。
AIが出したコードを評価できないまま使うことは、かなり危うい。
だからこそ、コードを書く力は不要になるのではなく、AIを評価するための基礎能力として、むしろ別の重要性を持ち始めているのかもしれません。
これから価値が下がるのは、「コードを書くこと」そのものではなく、仕様を理解せず、構造を考えず、ただ実装だけを請け負うような仕事なのだと思います。
コードを書く人から、構造を考える人へ
では、人間の価値はどこへ移るのでしょうか。
私は、「構造を考える人」へ移っていくのではないかと感じています。
ここでいう構造とは、単にシステム設計図を書くことだけではありません。
何が問題なのかを見つけること。
どこまでをAIに任せ、どこからを人間が見るのかを決めること。
短期的な実装速度と、長期的な保守性のバランスを取ること。
利用者にとって本当に必要なものを見極めること。
そうした判断の全体です。
AIは、問いを与えられれば答えを出します。
コードも出します。
テストも出します。
しかし、そもそも何を問うべきなのか、どの答えを採用すべきなのか、どこまで責任を持つべきなのかは、まだ人間が考えなければいけない部分です。
そう考えると、AI時代のプログラマーは、「コードを書く人」から、「コードも理解したうえで、構造を考える人」へ変わっていくのかもしれません。
これは、少し前の時代にも似た変化がありました。
ブログが出たとき、文章を書くことの入口は下がりました。
しかし、読まれる文章を書くには、視点や構成や継続性が必要でした。
YouTubeが出たとき、動画投稿の入口は下がりました。
しかし、見られる動画を作るには、企画や編集や文脈理解が必要でした。
入口が下がるほど、表面的な作業ではなく、深い構造が問われるようになる。
AIによるプログラミング支援も、同じ方向へ進んでいるように見えます。

プログラマーは不要になるのか
では、最初の問いに戻ります。
AIはプログラマーを不要にするのでしょうか。
今の時点で、私は「不要になる」とは言えないと思います。むしろ、プログラマーという仕事の中身が変わっていく、と考えた方が自然だと思っています。
もちろん、なくなる作業はあると思います。
単純な実装、定型的な修正、よくあるテスト、簡単なドキュメント作成は、AIに任せる場面が増えていくでしょう。
すでにそうなり始めています。
一方で、ソフトウェア開発者の仕事が、ユーザーのニーズを理解し、設計し、テストし、保守し、他の人と協働する仕事であるなら、そのすべてが一気に消えるとは考えにくいと思います。
米国労働統計局も、ソフトウェア開発者・QAアナリスト・テスターの仕事には、ユーザーのニーズ分析、設計、保守、テスト、文書化、チーム協働などが含まれると説明しています。
つまり、AIによって問われているのは、プログラマーという職業の存続そのものではなく、その中でどの能力が中心になるのかということなのだと思います。
コードを書くことだけに価値が集中していた時代から、コードを理解し、AIを使い、構造を設計し、判断する時代へ。そうした移動が、いま静かに起きているのかもしれません。
繰り返される個の時代の中で
この連載では、ガラケー、mixi、ケータイ小説、GitHub、Hugging Face、AIエージェントをたどってきました。
一見すると、それぞれは別々の出来事です。
ガラケーは通信端末の話で、mixiはSNSの話で、ケータイ小説は投稿文化の話で、GitHubやHugging Faceは開発者コミュニティの話です。
でも、少し引いて見ると、そこには共通するものがあります。
個人が、大きなシステムへ近づいていくこと。
個人が、かつては組織や専門家にしかできなかったことへ手を伸ばしていくこと。
個人が、発信し、集まり、作り、流通させる力を持ち始めること。
AIによるプログラミング支援も、その流れの中にあるのかもしれません。
かつて、ガラケーの小さな画面から、個人の日記や小説やコミュニティが広がっていきました。いまは、AIの支援を受けながら、個人がソフトウェアやサービスや小さな事業を作ろうとしています。
もちろん、それは単純な希望の話ではありません。プラットフォームへの依存もあります。AI企業による囲い込みもあります。技術についていけない人が取り残される可能性もあります。
それでも、個人が巨大なシステムへ近づこうとする熱狂は、何度も形を変えて現れてきました。
プログラマー不要論の奥にあるのも、実はその熱狂なのかもしれません。
AIが人間の仕事を奪うのかどうか。そこだけを見ていると、不安だけが大きくなります。でも少し視点を変えると、いま起きているのは、「仕事の価値が置かれる場所」が変わっていく過程にも見えます。
コードを書く人から、構造を考える人へ。
その変化は、プログラマーだけの話ではないのだと思います。
次回は、AI時代に価値が残るものについて、もう少し広く考えてみたいと思います。私たちは何を仕事と呼んできたのか。そして、これから何を学び、何を手放さずにいるべきなのか。そこに、第8回の問いがあります。
連載一覧
関連マガジン
情報源・参考URL
GitHub Research:Quantifying GitHub Copilot's Impact on Developer Productivity and Happiness
Microsoft Research:The Impact of AI on Developer Productivity: Evidence from GitHub Copilot
U.S. Bureau of Labor Statistics:Software Developers, Quality Assurance Analysts, and Testers
いいなと思ったら応援しよう!
よろしければサポートお願いします! いただいたサポートは本財団としての活動費に使わせていただきます!