Sign in Subscribe
ai

AIがコードを書く時代になぜプログラミングを学ぶのか — 不安な若いエンジニアへ

AIに仕事を奪われるのではないか。自分の仕事に価値はあるのか。勉強会で会った若いエンジニアたちが抱えていた不安に、二十年以上この業界にいる立場から答えてみます。コーディングはそもそもボトルネックではなかった。実装は要求の解像度を上げる装置である——という仮説を、いくつかの調査データと共に。

AIがコードを書く時代になぜプログラミングを学ぶのか — 不安な若いエンジニアへ
Photo by Christopher Stark / Unsplash

先日、tamachi.go と Go Connect で立て続けに登壇しました。どちらも Go を書く人たちが集まる、LT 中心の勉強会です。話したのは状態遷移を型で潰す話と、rate.Limiter でレート制限に付き合う話。どちらも地味な話です。

面白かったのは、発表そのものより、そのあとの時間でした。若いエンジニアたちと話す機会があって、みんな驚くほど真っ直ぐで、気持ちのいい人たちでした。

同時に、彼らが抱えている不安の輪郭もはっきり見えました。AIに職を奪われるのではないか。自分のやっている仕事に、そもそも価値はあるのか。抽象的な議論としてではなく、生活のかかった、切実な恐怖として。

私が彼らくらいの歳だった頃（二十年以上前です）そんな心配はしていませんでした。私が心配していたのは、仕事がなくなることではありません。仕事がなくなる前に、自分のほうが壊れることでした。激務で。

どちらがマシだという話ではありません。ただ、彼らが向き合っている不安は、私が若い頃に向き合ったものとは種類が違う。だから「昔も大変だった」「なんとかなるよ」とは言いたくないし、言えません。

そのうえで、私に言えることを書いておこうと思いました。彼らから受け取った問いは、こういうものです。

AIがこれだけコードを書けるのに、なぜプログラミングを学ぶのか。

直感のレベルでは、私に迷いはありません。学ぶべきだと思っています。ただ、それをうまく言語化できていませんでした。「AIは間違えるから」では弱い。モデルが良くなるたびに弱まる論拠です。「基礎が大事だから」も、彼らの不安に対しては何も言っていないに等しい。

しばらく考えて、いま私が持っている答えはこうです。

プログラミングを学ぶのは、技術によって世界に何ができるのかの解像度を上げるためだ。

なぜそう考えるに至ったのか、順を追って書いてみます。

「学ぶ必要はあるか」が噛み合わない理由

まず前提を揃えます。この議論が噛み合わないのは、「プログラミング」の指すものが人によって違うからです。少なくとも四つに分けられます。

内容 AIによる代替可能性
① 構文を書く力 言語仕様を覚えて手で打つ 高い
② 読んで検証する力 出てきたコードを評価し、直す 中
③ 計算論的思考 問題を分解し、機械に落とし込む 低い
④ ソフトウェア工学 設計・運用・セキュリティ・変更容易性 低い

「もう学ばなくていい」という人はたいてい①の話をしていて、「学ぶべきだ」という人は②〜④の話をしています。①だけを指して不要と言うなら、私も特に反論はありません。以下で扱うのは②〜④です。

AIが下げたのは「コードを書くコスト」

生成AIによってコーディングの効率が上がったのは間違いありません。定型的なコードは短時間で生成できるようになり、ボイラープレートを書く時間は確実に減っています。私自身、いまのプロジェクトでAIがいなかったら相当苦労していたはずで、そこは正直にありがたいと思っています。

しかし、下がったのはコストであって、仕事そのものではありません。「この設計は妥当か」「本当に解くべき課題は何か」「この実装で運用できるか」「将来の変更に耐えられるか」・・・こうした問いは残ります。

以前に「コードを書くだけの仕事はなくなる」に感じる違和感という記事で書いたことですが、私は「コードを書くだけの仕事」がもともとほとんど存在しなかったと考えています。教科書には要件定義・設計・実装・テストという工程が並んでいますが、実際にコードを書き始めれば「この設計では実現できない」「APIを少し変えた方が自然だ」「この仕様だと運用で困る」といった発見が次々に出てきます。工程としては分かれていても、思考は分かれていない。

この点が、次の話につながります。

コーディングは、そもそもボトルネックではなかった

TOC(制約理論)の言葉を借ります。全体のスループットは、常にいちばん細いところ（「制約」）で決まります。

よくある理解はこうです。「AIがコーディングを高速化した。だから制約が判断や意思決定に移った」。

しかし前の節と合わせると、もう少し正確な言い方ができます。コーディングは最初から制約ではなかった。だから、そこを高速化しても全体のスループットは期待したほど上がらない。

測りにくさが、むしろ裏付けになる

面白いのは、この見立てが「AIの生産性効果が驚くほど測りにくい」という事実と整合することです。

METRのランダム化比較試験(2025年)では、熟練OSS開発者はAI利用時にタスク完了が19%遅くなりました。にもかかわらず、本人たちは20%速くなったと感じていた。認知と実測が逆方向に出たのです。

念のため補足しておくと、METRは2026年2月に、この実験には「AIなしで働くことを嫌う開発者が参加を辞退する」という深刻な選択バイアスがあることを認め、設計を変更すると表明しています。「AIは開発者を遅くする」という結論をそのまま引くことは、もうできません。いま使えるのは「主観的な生産性の感覚は、測定値と逆方向に出うる」という部分です。そして、これ自体が判断力を鍛えるべき理由でもあります。自分の感覚は錨にならない。

DORA 2025(約5,000人調査)も同じ方向を指しています。AI導入はスループットと正の相関を持つ一方で、不安定性（変更失敗、手戻り、復旧時間）とも相関しました。速くはなったが、下流のテスト・レビュー・品質保証がボトルネックとして露出した。

制約が消えたのではなく、制約が見えるようになった。私にはそう読めます。

打てる手は、二つある

制約が判断と検証に移ったとき、取れる手は二つあります。

  1. 判断する人間の能力を上げる
  2. 判断一件あたりに必要な負荷を下げる(型システム、テスト、可逆なデプロイ、影響範囲の限定、レビュー可能な粒度)

どちらか一方ではありません。DORA 2025の結論も、最大のリターンはAIツールそのものではなく、内部プラットフォームの品質・ワークフローの明確さ・チームの整合性への投資から来る、というものでした。個人を鍛えるだけでは足りない。

そしてTOCを素直に適用すると、もう一つ挑発的な結論が出ます。判断が制約なら、生成量を増やすのはむしろ害だということ。レビューできない量のコードを吐かせることは、制約の前に仕掛品を積み上げるのと変わりません。

「誰でも作れる」の正体

自然言語で誰でもアプリが作れる、と言われます。半分は本当です。ただし正確には、誰でも「動くもの」が作れるようになった、です。

Veracodeの2026年の調査では、AIのコード生成タスクの約44%が既知の脆弱性を混入させました。セキュリティ合格率は56%で、前回の55%からほぼ横ばい。2026年春の追跡調査でも約55%で変わっていません。コーディング能力のベンチマークが伸び続けている期間に、です。vibe codingで作られた約5,600のアプリを調べた調査では、2,000超の脆弱性と400超の露出したシークレットが見つかっています(Cloud Security Alliance)。

「動くこと」と「運用できること」の間には、いまも大きな落差がある。しかもその落差は、モデルの一般的な性能向上では自動的には埋まっていません。

洗濯機のたとえと、その限界

洗濯機は、内部構造を知らなくてもボタンを押せば動きます。だから内部構造の知識は、すべての人には必要ない。必要なのは、初期導入・運用・保守・トラブルシューティングを行う者です。ソフトウェアも同じ方向に向かっていて、そこがエンジニアの主戦場になっていくと私は考えています。

ただ、この比喩には限界があるので、先に自分で補足しておきます。

補足その一。洗濯機は量産品で、故障パターンが列挙可能です。 一方、ソフトウェアは一点物で、社会技術的で、故障パターンが列挙できません。運用の仕事量も難度も、洗濯機よりずっと大きい。この比喩は、むしろ残る仕事を過小に見せてしまっています。

補足その二。洗濯機の保守要員は、ユーザーに比べて圧倒的に少数です。 比喩を厳密に当てはめると「エンジニアの総数は大きく減る」という強い主張になってしまう。私が言いたいのは人数の話ではなく、仕事の中身が変わるという話です。ここは切り分けておきます。

実際、歴史はむしろ逆を示してきました。アセンブラ→高級言語→クラウドという抽象化は、プログラマの人数を減らさず増やしてきた。一本あたりの構築コストが下がれば作られるシステムは増え、結果として運用対象も増えます。

いずれにせよ、ボタンを押すだけの人はエンジニアではありません。

実装は、要求の解像度を上げる装置である

ここが、この記事でいちばん言いたいことです。

仕事には三つの層があると思っています。これはなぜ、まだ人間は働いているのかで書いた見立てです。いちばん上に、何を求めるかを決める「要求する」層。いちばん下に、身体で世界に触れる「動かす」層。そして真ん中に、要求を受けて頭で考え、手を動かして返す層。

AIが猛烈な速さで引き受け始めているのは、この真ん中です。そして真ん中こそ、私たちエンジニアの領分そのものでもある。AWSも、コードも、ドキュメントも、まるごと画面の中にあります。AIがいちばん得意なところに、私たちエンジニアはいる。

だから「上の層が残る」で話を終わらせたくなります。でも、そこで止めると大事なことを見落とします。

実装は、上の層への入力を生み出す装置でもある。

コードを書くから、設計の矛盾に気づく。データベースを触るから、その要求が現実的かどうかが分かる。技術を知らなければ、そもそも技術に何を頼めばいいのかすら分かりません。逆に、プログラミングやクラウドやネットワークを少しでも知っていれば、「これはAPIをつなげばできるんじゃないか」「この処理はAIに任せられるかも」と、要求そのものの解像度が上がる。

だから、中間層を丸ごと手放すと、残るはずの上位層のクオリティまで劣化する。

これは感覚論ではなく、実験で裏が取れつつある話です。

Shen & Tamkin, How AI Impacts Skill Formation (2026) は、職業開発者52人が新しいPythonライブラリ(Trio)を習得する課題を扱いました。AI利用群は理解度クイズのスコアが17%低く、概念理解・コード読解・デバッグ能力が損なわれ、しかも平均では有意な効率向上もありませんでした。速くもならず、理解も残らなかったということです。

Bastani et al., PNAS (2025) の高校数学の大規模RCTも似た結果です。ガードレールなしで生成AIを使った生徒は、練習中の成績こそ上がったものの、AIを取り上げた後のテストでは成績が下がりました。

ただ、どちらの研究にも希望があります。Bastaniらの実験では、答えではなくヒントを返すよう設計したAIチューターだと、悪影響がほぼ打ち消されました。Shen & Tamkinが観察した六つの利用パターンのうち、三つは認知的関与を保つことで学習成果を維持していました。

つまり分岐点は「AIを使うか否か」ではありません。丸投げするか、自分の頭を通すかです。

では、何をどう学ぶか

ここまでを踏まえると、やるべきことはかなり具体的になります。

学び方は、丸投げではなく「自分の頭を通す」こと。

  • 生成されたコードを、説明できるまで読む。「動いたからOK」で終わらない。
  • 先に自分の仮説を持ってから聞く。白紙で投げると、思考の機会そのものが消えます。
  • 詰まったとき、答えではなく手がかりを求めるプロンプトを習慣にする。
  • 定期的に、AIなしで小さいものを最初から書く。自分の実力の位置を測る方法は、たぶんこれしかありません。自己申告の感覚は当てにならない。

学ぶ対象は、壊れ方と、検証可能性。

  • 読む力を、書く力より優先する。これからのエンジニアは「全部を自分で書ける人」ではなく、どこを理解し、どこをAIに任せ、どこを疑うべきかを判断できる人です。
  • 壊れ方を知る。 性能特性、障害の伝播、データ整合性、セキュリティの典型的な穴。AIが最も苦手で、かつ漏れがあった場合に最もコストが高くつく領域です。
  • 機械的に検証できる仕組みに投資する。 型、テスト、静的解析、契約。これは「判断一件あたりの負荷を下げる」打ち手であり、AI時代のレバレッジそのものです。
  • 運用・保守・トラブルシューティング・初期導入。 地味ですが、ここがエンジニアの主戦場になります。

市場の話も、正直にしておく

きれいごとだけでは仕方がないので、数字も置いておきます。

厳しい面から。米NY連銀のデータで、CS新卒の失業率は約6.1%(コンピュータ工学は7.5%)。全新卒の約5.7%より高い。米国のCS専攻入学者は2025年秋に8.1%減、約659,700人から606,100人へと、全専攻中で最大の落ち込みでした(National Student Clearinghouse)。大学院ではさらに14%減。エントリーレベルの求人が絞られているという報告も各所から出ています。

一方で、そうでもない面もあります。同じNY連銀のデータで、CSの不完全就業率は16〜17%。全専攻平均の約42%より大幅に低い。就職できた人は、ちゃんと専攻に見合う仕事に就いています。BLSの職業別雇用予測では、ソフトウェア開発者・QA・テスターの雇用が2024–34年に15%成長(全職種平均3%の五倍)、年間約129,200件の求人が見込まれています。求人が堅いのは、AI/ML、クラウドインフラ、セキュリティ・・・まさに運用寄りの領域です。

「入口が狭い」と「職業として終わり」は、別の話です。

そしてもう一つ。地味であることと、待遇が悪いことは別です。私は今後、この十年ほど続いたエンジニア人気は陰り、二十年前のように「技術が好きな人間だけが残る」状態に戻っていくのではないかと見ています。ただしそれは、待遇が下がるという意味ではない。むしろ逆で、レアであることは高待遇の条件です。供給が減り、運用対象が増え続けるなら、待遇は上がってもおかしくない。

華やかさが減るのは、悪い話ばかりではないと思っています。

おわりに

現時点での私の仮説を、ひとつにまとめるならこうです。

AI時代にプログラミングを学ぶ意味は、AIより速くコードを書くためではない。AIという強力な道具を使って、自分の要求を世界に実現するためだ。AIが仕事を代替すればするほど、人間には「何を実現したいのか」を考えることが求められる。だからプログラミングを学ぶことは、技術によって世界にどう働きかけられるかを知ることなのだと思う。

補足するなら、五点です。

  1. AIが下げたのはコーディングのコストであって、エンジニアの仕事は減っていない。
  2. コーディングはそもそもボトルネックではなかった。だから制約は判断と検証に移った。というより、露出した。
  3. 「誰でも作れる」の正体は「誰でも動くものが作れる」。動くことと運用できることの落差は、まだ埋まっていない。
  4. 実装は要求の解像度を上げる装置である。手放せば、要求の品質も劣化する。
  5. だから分岐点は「AIを使うか否か」ではなく、丸投げするか、自分の頭を通すか。

まだ完成形ではありません。ここに挙げた数字は、どれも一、二年で古びるはずです。ただ、考え方の骨格のほうは、しばらく持つのではないかと思っています。

最後に、あの日会った人たちへ

不安は正当だと思います。数字を見ても、入口が狭くなっているのは事実です。だから「大丈夫だよ」とは言いません。二十年上の人間に軽く大丈夫と言われるのが、いちばん腹の立つことだというのも覚えています。

ただ、その不安のなかで毎日選べることが、一つだけあります。丸投げするか、自分の頭を通すか。生成されたコードを読むか、読まないか。理解するか、理解しないか。疑問を突き詰めるか、突き詰めないか。それだけです。派手ではないし、明日何かが変わるわけでもありませんが、一年後に自分の中に残っているものは、そこで決まります。

私が若い頃に心配していたのは、仕事がなくなることではなく、その前に自分が壊れることでした。二十年経って、心配の種類は変わりました。ただ、あのとき私を助けたのは見通しの明るさではなく、目の前の技術が面白いと思えたことでした。それは、いまも変わらず有用な資産だと思っています。

この記事の前にあった話

この記事は、次の二本の続きとして書いています。

参考

生産性・開発現場

AI生成コードの品質・セキュリティ

学習・スキル形成

労働市場

Read next

「コードを書くだけの仕事はなくなる」に感じる違和感

「コードを書くだけの仕事はなくなる」に感じる違和感

生成AIの話題になると「コードを書くだけの仕事はなくなる」とよく耳にします。でも私は、そんな仕事がもともとほとんど存在しなかったと考えています。実装は単なる入力作業ではなく、設計を検証し要件を見直す思考のプロセスだからです。AIが下げたのはコードを書くコストであって、エンジニアの本当の仕事——コードに至るまでの思考——はこれからも残る。そんな違和感を書いてみました。
SHINCHI, Takahiro

Comments ()