AI時代、エンジニアの価値はどこへ移ったのか
はじめに
少し前に、Amazonで機械学習システムを開発しているMarina Wyss氏が、Mediumでこんなことを書いていました。
"I rarely write code anymore. AI writes nearly every line I commit."
「自分はもうほとんどコードを書いていない。コミットするほぼすべてのコードをAIが書いている。」
私自身もClaude Codeを毎日使っていますが、以前と比べると、自分の手でコードを書く時間はかなり減っています。新しい機能を実装するときも、まずAIにたたき台を作ってもらい、それをレビューして修正する──そんな開発スタイルが当たり前になってきました。
ここまでAIがコードを書けるようになると、ふとこんな疑問が浮かびます。
「では、エンジニアが技術を学ぶ意味はどこにあるのだろうか。」
アメリカではすでに、AIの普及によってエンジニアの働き方や採用市場が変わり始めています。
では、日本はどうなのでしょうか。
この記事ではWyss氏の記事を参考にしながら、日本の採用市場では実際にどのような変化が起きているのかを客観的なデータで確認し、その変化を開発現場の視点から考えてみます。
実際の日本の採用市場はどう変化したのか
「AIでエンジニアの仕事がなくなる」という話題は以前からよく耳にします。
では、日本の採用市場では実際に何が起きているのでしょうか。
dodaのITエンジニア採用レポートによると、2026年3〜5月の求人数は前四半期比で95%まで減少しています。一方で求人内容を見ると、「未経験者を育てる採用」よりも、「すぐに現場で活躍できる経験者」を求める傾向が強くなっています。IT人材市場全体は依然として売り手市場ですが、企業が求める人材像は少しずつ変わり始めています。[1]
もちろん、この変化をすべて生成AIだけで説明することはできません。景気や採用予算など、さまざまな要因が影響しています。
ただ、開発現場にAIが入り始めたことで、「実装を速くこなせる人」を増やすよりも、「AIを活用しながら設計・レビュー・運用まで任せられる人」を採用したいという流れが強まっているのは間違いないでしょう。
とはいえ、「エンジニアが余っている」という状況でもありません。
IPAのDX白書でも、多くの企業がAIやDXを推進できる人材不足を課題として挙げています。[2]
つまり、需要そのものが減ったというより、「コードを書ける人」が求められているのではなく、「AIを前提に価値を出せる人」が求められるようになってきた、と考えるほうが実態に近そうです。
では技術を学ぶ意味は本当にあるのか
ここまで見てきたように、日本でも採用市場は少しずつ変わり始めています。
求められるのは「実装が出来る人」ではなく、「AIを前提に設計・レビュー・運用まで担える人」。実際の求人も、未経験者やポテンシャル採用より、実務経験のあるエンジニアへと重心が移りつつあります。
では、この変化は「技術を学ぶ意味がなくなった」ということなのでしょうか。
「AIがここまでコードを書いてくれるなら、もう技術を学ぶ意味はないのでは？」と考えたことがある人も少なくないと思います。
しかし、Wyssさんの記事はそういう結論ではありません。
記事の中では、「Computer Programmer」の求人は大きく減っている一方で、「Software Developer」の求人はほぼ横ばいで、今後も成長が見込まれていることが紹介されています。つまり、減っているのは「コードを書く人」の需要であって、「ソフトウェアを作る人」の需要ではない、ということです。
AIは実装だけでなく、「この設計で本当にいいのか」「既存システムへの影響はないか」といった確認まで行えるようになっています。しかし、その回答をそのまま信用できるわけではありません。AIのレビューも一つの意見として参考にしつつ、最終的にコードを理解し、品質を確認し、本番へ出す責任を負うのは開発者です。AIは判断を補助できますが、判断の責任まで代わってくれるわけではありません。
実際、2025年のStack Overflow Developer Surveyでは、84%の開発者がAIを利用または利用予定と回答した一方で、46%はAIの出力を信用していないと回答しています。利用は急速に広がっているものの、「AIが書いたコードは必ず人が確認する」という考え方が現場では一般的です。[3]
さらにSonarの調査でも、AIが生成するコード量は増え続けている一方で、38%の開発者が「AIのコードレビューは、人が書いたコードより時間がかかる」と回答しています。コードを書く時間は減っても、「レビューして品質を保証する仕事」はむしろ増えているという結果です。[4]
つまり、技術を学ぶ意味がなくなったのではなく、学ぶ目的が変わったということです。
以前は「コードを書くため」に技術を学んでいました。
これからは、「AIが書いたコードを理解し、その品質を評価し、本番環境へ出してよいか判断するため」に技術を学ぶことが求められます。
コードを書くこと自体の価値がなくなったのではありません。そのコードに責任を持ち、品質を保証できることの価値が、これまで以上に高くなっているのだと思います。
価値が移ったのは、コードを書く前と後
ここまで読むと、「結局AIはコーディングを代替しただけでは？」と思う人もいるかもしれません。
でも、Claude Codeを使い続けていると、実際には「コードを書く仕事」がなくなったというより、「エンジニアが時間を使う場所」が変わっただけだと感じます。
Wyssさんは、ソフトウェア開発を大きく3つの工程に分けています。
- 何を作るか決める
- コードを書く
- 品質を確認して本番へ出す
AIが圧倒的に速くしたのは、この真ん中部分です。
一方で、「何を作るべきか」を考える工程と、「本当にこのコードを出していいのか」を判断する工程は、ほとんど短くなっていません。
むしろ、AIの実装速度が上がったことで、前後の工程の重要性は以前より高くなっています。
これは個人の感覚だけではなく、実際にレポートとしても報告されています。
Google CloudのDORAレポートでは、AIを利用している開発者の90%以上が「生産性は向上した」と回答しています。しかし同時に、AIによって開発が速くなるほど、レビューや検証に時間を使う傾向も明らかになっています。DORAはこの現象を、「AIは作業時間をなくしたのではなく、実装から監査・検証へ時間を再配分した」と表現しています。[5]
AIが1時間で5,000行のコードを書けるようになったとしても、その5,000行を本番環境へ出してよいか判断する責任は、人間からなくなりません。
実装が速くなればなるほど、
- 要件が正しいか
- 設計は妥当か
- 既存機能への影響はないか
- セキュリティ上の問題はないか
といったレビューの重要性はむしろ増えていきます。
実際、DORAのレポートでも、AIは個人の生産性を向上させる一方で、組織としては品質や安定性が必ずしも改善するわけではないと報告されています。AIは強力なツールですが、基盤となる設計やレビューの品質が低ければ、その問題も一緒に増幅してしまいます。
つまり「コードを書く能力の価値がなくなった」のではなく、正確には「価値の中心が移った」のだと思います。
以前は「どれだけ速く、正しくコードを書けるか」が評価されていました。
これからは、「何を作るべきかを整理し、AIへ適切に依頼し、その成果物をレビューして責任を持てるか」が評価される時代になっていくのではないでしょうか。
学習の中身が変わっている
ここまでの話をまとめると、AIによって「技術を学ぶ必要がなくなった」のではありません。
変わったのは、「何のために技術を学ぶのか」です。
少し前までのプログラミング学習は、「自分でコードを書けるようになること」がゴールでした。
文法を覚え、フレームワークを覚え、ライブラリの使い方を覚える。そうして一人で実装できるようになることが、エンジニアとして成長することだと考えられていました。
でも今は違います。
AIが数百行、数千行のコードを書いてくれる時代に、「コードを書くこと」そのものは以前ほど希少な能力ではなくなりました。
一方で、そのコードが正しいかを判断する難しさは、むしろ大きくなっています。
例えばAIが生成したコードをレビューするとき、
- このSQLは性能劣化を起こさないか
- 並行処理で競合しないか
- 例外処理は十分か
- セキュリティ上の問題はないか
- この設計は半年後も保守できるか
こうしたことを判断するには、文法だけでは足りません。
実際、Stack Overflowの2025年調査では、69%の開発者がこの1年間で新しいプログラミング技術や言語を学び続けており、36%はAIツールそのものの使い方も学んでいます。AIが普及した今でも、多くの開発者は「もう勉強しなくていい」とは考えておらず、学ぶ対象を広げていることが分かります。[6]
もう一つ印象的だったのは、AIによって「基礎」が不要になったわけではないという点です。
O'Reillyの分析では、AIの普及によってGitやアジャイルなど基礎的なテーマを学ぶ時間は減っている一方で、「AIを使う前に基礎を身につけることは依然として重要だ」と指摘しています。AIは理解を代替するものではなく、理解を前提に生産性を高める道具だからです。[7]
以前は「どう実装するか」を学んでいましたが、今は「どう判断するか」を学ぶことが重要だと言えそうです。
学ぶ対象がプログラミング言語からソフトウェアエンジニアリング全体へ広がっただけで、学ぶことそのものの価値は、むしろ以前より高くなっているように感じています。
Claude Codeを使って減ったものと、減らなかったもの
ここまでは調査結果や市場の話を書いてきました。
最後に、自分がClaude Codeを日常的に使うようになって、一番変わったことを書こうと思います。
結論から言うと、「コードを書く時間」は確かに減りました。
例えば、新しいAPIを追加したり、CRUDを実装したり、テストコードを書いたりするような作業は、以前より圧倒的に短時間で終わります。
数時間かかっていた実装が、数十分で終わることも珍しくありません。
一方で、減らなかった仕事があります。
- 要件を整理する時間
- AIへ適切に指示を書く時間
- AIが生成したコードをレビューする時間
- 動作確認や障害調査をする時間
などです。むしろ、この時間は以前よりはるかに重要になりました。
Google CloudのDORAレポートでは、90%以上の開発者がAIによって生産性が向上したと回答しています。しかし同時に、「AIで短縮された時間は、監査・レビュー・検証へ再配分される」と分析されています。AIによってコードを書く時間は減る一方で、そのコードを検証し、品質を保証する仕事は依然として人間の役割だからです。
Claude Codeを使えば考えなくても開発できるようになったわけではありません。
むしろ逆で、AIは非常にもっともらしいコードを書きます。
だからこそ、「なぜこの実装なのか」「もっと良い設計はないか」「既存仕様を壊していないか」を以前より意識してレビューする必要が大きくなりました。
最近では、この傾向を裏付ける調査も出ています。GitLabの調査では、AIによってコード生成は高速化した一方で、85%の回答者が「現在のボトルネックはコードを書くことではなく、レビューや品質保証になっている」と答えています。 また、73%がAI生成コードの長期的な保守性に懸念を持っていることも報告されています。[8]
コードを書くことから、コードを判断することへ時間の使い方が変わりました。
Claude Codeを使うようになってから、自分はコードを書く量よりも、「考える量」が増えたと感じています。
終わりに
AIはプログラミング学習を不要にしたわけではなく、不要になりつつあるのは「コードを書くこと」そのものがエンジニアの価値だった時代です。
歴史を振り返ると、似たような議論は何度も繰り返されてきました。
アセンブリ言語からFORTRANやCOBOLのような高級言語が登場したときも、コンパイラが普及したときも、「これでプログラマは不要になる」と言われました。その後も、IDEの補完機能、フレームワーク、OSSの発展によって、一人のエンジニアが書くコードの量は減り続けています。
それでも、ソフトウェアエンジニアという仕事はなくなりませんでした。
なぜなら、ソフトウェアエンジニアリングとは「コードを書くこと」ではなく、「ソフトウェアを継続的に動かし、品質を保証すること」だからです。近年の研究でも、LLMはコード生成を大きく支援する一方で、大規模システムの保守や信頼性の確保といったソフトウェアエンジニアリング全体を代替するものではないと指摘されています。
最近も、「コーディングはもう終わった」という意見を見かけます。
一方で、GoogleでKerasを開発し、現在はAI研究やARC-AGIベンチマークの設計で知られる François Chollet 氏は、「ソフトウェアエンジニアリングにはAIが自動化しやすい作業も多いが、仕事全体が完全に検証可能なわけではない。そのため、『多くの作業を自動化できる』ことと、『仕事そのものを置き換えられる』ことの間には大きな隔たりがある」と述べています。[9]
この記事を書くために日本の採用市場や各種調査を調べてみても、見えてきたのは「エンジニアが不要になる未来」ではありませんでした。
企業が求める人材像は、「コードを書ける人」から、「AIを使いながら設計・レビュー・運用まで責任を持てる人」へと変わり始めています。
AIが進化するほど、人間に求められるのは「書く力」ではなく、「理解する力」「判断する力」「責任を持つ力」になっていくのだと感じました。
脚注
-
Stack Overflow’s 2025 Developer Survey Reveals Trust in AI at an All Time Low ↩︎
-
State of Code Developer Survey report: The current reality of AI coding ↩︎
-
Balancing AI tensions: Moving from AI adoption to effective SDLC use ↩︎
-
The challenge now is making sure the next generation develops those same foundations before relying too heavily on AI’: Devs are swerving fundamental skills like Git and Agile because of AI – but there’s a good reason ↩︎
-
Speed without control is a liability, not an advantage': GitLab study reveals AI code generation is outpacing controls ↩︎
Discussion