コンパイラもプログラミングを終わらせるはずだった

2031 年、ある火曜日の朝 7 時 40 分。あなたはまだ 1 行もコードを書いていない。今日もおそらく書かないだろう。それでいい。

あなたが眠っている間に、4 つの agent が昨日の午後に整理しておいた ToDo を片づけた。3 つは完了していて、pull request があなたの承認を待っている。それぞれに新しいテスト、機能が動く様子の短い画面録画、そして判断に迷った点を列挙したメモが付いている。4 つ目の agent は午前 2 時 13 分に停止し、質問を 1 つだけ残した。

仕様には、返金は元のカードに戻すと書かれています。この顧客のカードは 3 月に期限切れになっています。この場合はどう処理すべきでしょうか。

返金処理のコードなら、agent はいくらでも書ける。できないのは、カードの期限が切れた顧客に対して会社がどんな責任を負うかを代わりに決めることだ。だから止まって聞いてきた。これもまた、新しい社員に期待する動きだろう。あなたの朝はおそらくこうなる。pull request を 3 つ読み、カスタマーサポートの担当者と話し、ルールを明文化する。誰も（人間かどうかを問わず）二度と推測しなくて済むくらい明確に。

あの火曜日の話は私が作ったものだ。だが、その中に SF 的な要素は一つもない。今では夜間に無人で働く agent が実在する。そのうちの一つは毎晩 10 時に私のマシン上で動いている。自分で小さなプロジェクトを思いつき、作り、テストまでして、私が朝食を食べている頃には何ができたのかが分かる。最初の朝、それが何を作ったのか私は皆目見当がつかなかった。そのプロジェクトは今 Rule Safari という名前で、本サイト上のオンラインプロジェクトとして公開されており、仕組みを解説した記事もある。

では、これはプログラミングの終わりなのか。この問いは 70 年以上前から繰り返し投げかけられてきた。私はそれを心強く思うと同時に、どこか胡散臭くもある。

プログラミングは 1954 年からずっと終わりつつある

1954 年 11 月 10 日、IBM の Programming Research Group は新言語 FORTRAN に関する予備報告書を仕上げた。その中に、FORTRAN は「コーディングとデバッグをほぼ撲滅するはずだ」という一節がある。

この一文が私は気に入っている。自信満々で、しかも予算の話まで付いてくる。FORTRAN を使えば問題を解く「コストは半分以下」だ、と。当時、こうしたものには呼び名があった。アセンブラやコンパイラは自動プログラミングと呼ばれていた。欲しいものを記述すれば、機械がプログラムを書いてくれる。

FORTRAN は 1957 年にリリースされ、実際に一種のコーディング作業を撲滅した。今日、数式を手作業で機械語命令に翻訳する人はほとんどいない。デバッグは無事に生き残った。（今月私は Scry のバグを追いかけ、たどり着いた原因はブックマークが 12 時間ごとにしか保存されないというものだった。デバッグが健在であることは間違いない。）

FORTRAN が本当にやったのは、仕事の退屈な部分を取り除き、仕事全体を一段上に引き上げることだった。人はレジスタのことを考えなくなり、より大きな問題を考えるようになった。プログラムを書くコストが下がり、誰もがもっと多くのプログラムを欲しがった。それ以来、同じことが何度も繰り返されている。

私が一番好きなのは 1981 年の段階だ。D.J. “AI” Systems という英国の会社（本当にその名前だった）が、The Last One という BASIC プログラム生成器を売っていた。名前がそのまま売り文句だった。すべてのプログラムを代わりに書き上げてくれる、だからこれが人生で最後に買うプログラムになる、と。

レビュアーは、一部の業務プログラムには確かに役立つと認めていた。だが最後の一本にはならなかった。

どの段階でも法則は同じだ。何かが自動化され、手でやっていた人は手を動かさなくなり、それでもその分野は拡大を続ける。GitHub は 2025 年のレポートで 1 億 8000 万人を超える開発者を数え、そのうち 3600 万人以上が過去 12 か月に加わった新顔だった。

だから AI がプログラミングを終わらせるとは思わない。ただ、この段階には一つだけ違うところがある。速度だ。GitHub Copilot のプレビューは 2021 年 6 月に出た。2025 年には、Stack Overflow の調査で 84%の開発者が AI ツールを使っているか使う予定があると答えた。4 年で、目新しい玩具が既定の選択肢になった。

2026 年の実際の風景

今は雰囲気が盛り上がっているので、まず数字から始めよう。（雰囲気といえば、Andrej Karpathy が 2025 年 2 月に作った「vibe coding」という言葉がある。感覚に完全に任せるプログラミングのことだ。Stack Overflow はその年さっそくこれを質問した。72%の開発者が自分の仕事ではないと答え、さらに 5%は断固として違うと答えた。この選択肢をわざわざ用意したところがいい。）

Stack Overflow の調査は手元にある中で最大規模の定期健診で、採用曲線は急だ。2023 年には 70%の開発者が AI ツールを使っているか使う予定があると答え、2025 年には 84%に上がった。うち半分のプロ開発者は毎日使っている。

これだけ使われているなら、開発者はこれらのツールを気に入っているのだろうと思うかもしれない。そうではない。好感度は 2023 年の 77%から 2025 年には 60%まで下がり、今年ようやく 62%に戻した。2025 年には、AI の出力の正確さを信頼しない開発者（46%）が信頼する開発者（33%）を上回った。最も厄介な問題として 66%が選んだのは「AI の答えはだいたい合っているが、完全には合っていない」だった。

身に覚えがありすぎる。「だいたい合っている」は高くつく間違いだ。どこが違うのか、一行ずつ読んで探さなければならない。（45%が、AI 生成コードのデバッグにはより時間がかかると答えている。）

AI ブームの中で私が最も好きな研究はこれだ。何しろ容赦がない。2025 年初頭、非営利の研究機関 METR がきちんとしたランダム化比較試験を行った。経験豊富なオープンソース開発者 16 人が、自分が何年も保守してきたリポジトリで実際の issue を 246 件処理した。各 issue は、AI ツールの使用を許可するか禁止するかにランダムに割り振られた。

作業前、開発者たちは AI を使えば作業時間が 24%短縮できると見積もっていた。作業後、彼らは実際に 20%短縮できたと信じていた。ところが計測結果はこうだ。AI を使うと、かえって 19%余計に時間がかかった。

19%も余計に！しかも作業を終えた彼らは、AI が役に立ったと固く信じていた。

スクリーンショットを撮って暴論を垂れ流す人が出る前に言っておく。あれは 16 人を対象にした研究で、使ったのは 2025 年初頭のツールで、コードベースも彼らがどのモデルよりも熟知しているものだった。

しかも METR は再実験を試みている。2025 年 8 月に 57 人の開発者、800 以上のタスクという大規模な研究を始めたが、2026 年 2 月の時点で、METR はデータが信頼できず根拠にできないと述べている。主な理由は開発者が参加を拒み続けたことで、彼らは「AI なしで働きたくない」と思っていた。初期の数字では、復帰した開発者は 18%速くなったことを示唆していた（その範囲は、まったく速くなっていない場合を含むほど広い）。

史上最も「2026 年」らしい実験の失敗の仕方だと思う。人々が AI なしの群への参加を拒んだのだ。

METR から得られる結論は、どんな見出しよりも狭く、そして役に立つ。速く感じることは測定ではない。 AI がチームを速くしたか知りたければ、他のあらゆるものを測るときと同じように測ればいい。

右肩上がりの一本の線

METR のもう一つの大きなプロジェクトは、AI agent が単独でどれだけ長いタスクをこなせるかを追跡している。専門家に一連のソフトウェアタスクの所要時間を計測してもらい、agent が半分の確率で成功するタスクの長さを割り出す。2019 年、GPT-2 は人間がおよそ 3 秒で終えるタスクをこなせた。2023 年には GPT-4 が約 4 分に到達。2025 年 2 月、Claude 3.7 Sonnet が 1 時間に達し、その 1 年後、Claude Opus 4.6 は約 12 時間に達した。

この系列全体を通じて、この数字はおよそ 6 か月ごとに倍になっている。2023 年以降は、4 か月ごとの倍増に近い。

破線で終わる対数グラフこそ、多くのひどい予測の出発点だ。だから慎重にいきたい。「半分の時間」という表現は、その定義の中で大きな重みを背負っている。ベンチマークのタスクは、あなたのコードベースよりずっと整っている。しかも METR は 9 月にそのページの更新を止めた。それでもこの線がおおよそ続くなら、2028 年前後には agent が人間の 1 か月分の仕事を半分の時間でこなせるようになる。私の「2031 年の火曜日」はそこから来ている。でっち上げたわけではない。対数グラフから引っ張り出したのだ。そしてグラフとは、座標軸の付いたでっち上げにすぎない。

こうしたものを作っている会社は、すでにこの版の現実の中に生きている。Google は 2024 年 10 月、新規コードの 4 分の 1 超が AI 生成だと述べ、6 か月後にはその数字は「30%を大きく超える」になった。2025 年 3 月、Anthropic の Dario Amodei は、AI が 3〜6 か月以内にコードの 90%を書くようになると予測した。それは早すぎた。だが 2026 年 5 月までに、Anthropic は自社コードベースにマージされるコードの 80%超を Claude が書いていると明かした。

コードが安くなれば、行列は前に詰まる

工程のどこか一歩が速くなれば、仕事は次に遅い場所の手前で詰まる。土曜の夜にレストランの厨房で働いたことがある人なら分かるはずだ。グリルが速くなると、皿はパスに並び始める。

ソフトウェアチームが今まさに経験しているのはこれだ。2025 年、Faros AI は 1,255 チーム、1 万人を超える開発者のテレメトリを分析した。AI 採用率の高いチームでは、開発者が完了したタスクは 21%増え、マージされた pull request は 98%増えた。そしてレビュー時間は 91%伸びた。

Faros は 2026 年にもう一度やった。対象は 22,000 人の開発者。1 人あたりのタスク完了数は 34%増。残りを読むまでは悪くない話に聞こえる。レビュー時間の中央値は 5 倍になった。pull request の 31%はレビューが一切ないままマージされ、インシデントと pull request の比率は 3 倍以上に跳ね上がった。

コードは安くなり、コードを読むことは高くなり、いくつかのチームはこっそり読まなくなった。これは効く。コードはいつも良いとは限らないからだ。Veracode は 2025 年、80 のプログラミングタスクで 100 以上の言語モデルをテストし、45%の結果にセキュリティ上の脆弱性があった。GitClear によれば、コピー＆ペーストされた行が変更コードに占める割合は 2021 年の 8.3%から 2024 年には 12.3%に上がり、移動されたコード（リファクタリングで生まれる類のもの）は約 4 分の 1 から 10%未満に落ちた。

メンテナーの身にもなってほしい。curl の責任者 Daniel Stenberg は 2025 年 5 月から、「AI スロップ」の脆弱性報告を送ってくる人間をブロックし始めた。プロジェクトは「事実上 DDoS 攻撃を受けている」と彼は書いている。2026 年 1 月、curl はバグバウンティプログラムを終了した。

Fred Brooks は 1986 年の時点で、この話のある種の姿をすでに見抜いていた。『銀の弾丸はない』で彼はアリストテレスの言葉を借り、ソフトウェアの難しさを 2 つに分けた。本質と偶有性だ。偶有性とはツールがもたらす厄介事で、文法やボイラープレート、ビルドシステムとの格闘がそれにあたる。本質とは彼の言う「この概念構造の仕様記述、設計、テスト」、要するに、この代物が一体何をすべきなのかを突き詰めて考えることだ。AI は偶有性の領域でどんどん得意になっている。本質は、午前 2 時 13 分のあの返金の問題で、今もあなたの机の上に載っている。

私たちが今、切り倒そうとしている梯子の段

データの中で一番気に入らない部分だ。

2025 年 8 月、Erik Brynjolfsson とスタンフォードデジタル経済研究所の同僚 2 人は ADP の給与データを使い、誰が採用されているのかを調べた。22〜25 歳のソフトウェア開発者の雇用者数は、2022 年末のピークから 20% 近く減った。年長の開発者には目立った変化がない。

今年 8 月、彼らはこの研究を更新し、データを 2026 年 6 月まで延ばした。AI の影響を受ける職種では、若年労働者の雇用水準は「影響の小さい同世代と歩調を合わせていた場合」に比べて 19% 低い。経験のある労働者には比較できるほどの差がない。効果の大半は、企業が最初から若者をあまり採らなくなったことによる。

市場の残りも景気がいいとは言えない。Indeed のソフトウェア開発求人指数は 2020 年 2 月より約 21% 低く、2025 年 5 月には 39% 低いところまで底を打っていた。

スタンフォードの著者たちは慎重に、この発見は記述的なもので因果的ではないと断っている。2022 年以降は他にもいろいろあった。金利は上がり、パンデミック中に採りすぎた企業も多い（Indeed 指数は 2022 年初頭に 2020 年水準の 2 倍超まで上がっていた）。それでもこのパターンは、agent が得意とする仕事と嫌なほど一致している。かつてチームの新人に回していた、小さくて輪郭のはっきりしたチケットだ。

シニアエンジニアは仕事の中で育つ。主に本物のチームで junior をやることで。退屈なチケットをこなし、一度本番環境を落とし、誰かが親切に理由を説明してくれる。agent が退屈なチケットを全部引き受けてしまったら、次のシニアエンジニアはどこから来るのか。コードをあまり書いていなければ、コードレビューをうまくやるのは難しい。

簡単な答えは持ち合わせていない。私の推測はこうだ。2035 年にうまくいっているチームは、2026 年にも junior を採用し続け、別のかたちの見習い期間を与えたチームだろう。junior がシニアの隣で agent の成果物をレビューし、小さなシステムを端から端まで担当し、agent がそれに従って作る仕様とテストを書く。この仕様とテストを書くのはれっきとした仕事であり、あの仕事になるかもしれない。

2031 年についての 5 つの推測

さて、推測の時間だ。このページをブックマークして、2031 年に戻ってきて笑ってほしい。

チームは小さく、数はずっと多く。 Y Combinator の Jared Friedman によれば、2025 年冬のバッチの 4 分の 1 は、コードベースのおよそ 95% が AI 生成だった。今年 2 月、Block は約 4,000 人を削減し、Jack Dorsey はその理由を AI ツールと「より小さく、よりフラットなチーム」に求めた。ここは読み違えているかもしれないが、それでもこれらを合計してもソフトウェア職の総数が減るとは思わない。米国労働統計局もそうは見ていない。2025 年から 2035 年にかけて、ソフトウェア開発者、QA アナリスト、テスターの職が 10% 増えると予測している。

安くなれば、たいていはもっと欲しくなる。経済学者はこれをジェヴォンズのパラドックスと呼ぶ。1865 年に William Stanley Jevons が、効率のよい蒸気機関は英国でより多くの石炭を燃やすことになると論じたのが由来だ。これまでチームで 1 四半期かかっていたソフトウェアが、1 人で 1 週間でできるようになる。そして、以前は誰も費用をかけられなかった多くの問題が、突然、解決する価値のあるものになる。

仕様とテストが源になる。 今は手書きのコードを自分のものとみなし、仕様は誰も読まない文書とみなしている。これは逆転すると思う。仕様とテストがレビューし議論する対象になり、コードはどちらかといえばコンパイラの出力に近づく。開いて確認はするが、手で編集することはほとんどなくなる。（そう、また 1954 年のあの約束だ。今度は持つかもしれない。）

1 人のためのソフトウェア。 毎晩動いている私の agent は、誰も頼んでいないものを作る。私自身も頼んでいない。中にはなかなか気の利いたものもある。使えるツールが 1 四半期ではなく一晩でできるなら、人は今日スプレッドシートを作るのと同じようにソフトウェアを作るだろう。1 つの問題、1 人のために作り、使い捨てる。

コードを読むことが職業になる。 私たちのキャリアはほぼすべてコードを書くことを土台にしてきた。コードを読むことを土台にしたキャリアはほとんどない。これは変わると思う。求人サイトには「検証エンジニア」のような職種が現れ、ツールはずっとよくなり、画面録画、リスクのあるコード行、agent が書かなかったテストをレビュー担当者の目の前に直接並べるようになる。Faros のデータが示すのは、2031 年を待たず、今それが要るということだ。

すべての変更にラベルが付く。 pull request には今後、誰が、あるいは何が書いたのか、誰が確認したのか、実際に何が検証されたのかが当たり前に書かれるようになると思う。私はもう小規模にやっている。夜間の agent が作ったプロジェクトには、README とこのサイトにその旨を記している。

火曜日の話に戻る

FORTRAN は確かに一種のコーディング作業を消したが、プログラマーを消しはしなかった。ずっと多くのプログラマーを生み、より難しい問題に当たらせ、デバッグも一緒に連れてきた。

AI がやっているのも同じことだと思う。ただ速くて、雑なだけだ。2031 年の開発者は、一日を「何が存在すべきか」の判断に使い、それを機械がそのまま作れるレベルまで言葉にして、上がってきたものが正しいかを確かめる。難しいのは昔からそこだ。これまではコードを書くのに忙しくて、そこに割く時間が足りなかっただけだ。

あなたの火曜日は今どんな感じだろう。レビューするコードのほうが、書くコードよりも多くなっている？コメントで教えてほしい。上の見立てがすでに外れているのかどうか、知りたいのだ。