ソフトウェアエンジニアリングの終わり

はじめに

Anthropic の アダム ウルフ ( Adam Wolff ) 氏 、が書いた記事がとても印象的だったので、翻訳・まとめをしてみました〜

元投稿

元記事

翻訳文

数週間前、私はOpus 4.5のパワーと精度について何気なくツイートしました。物事がいかに急速に変化しているかを伝えようとして、ソフトウェアエンジニアリングは「終わりに近い」 と言ったのです。このツイートはバズりましたが、良い意味ではありませんでした。

新しいモデルに触れる時間ができた今、より多くの人が私の言いたかったことを理解してくれていると思います。私が言いたかったのは、コーディングが終わる世界に向かっているということでした。近い将来、私たちはIDEを閉じて二度と戻らなくなるでしょう。しかし、その違いについて深く考えていなかったため、言葉を慎重に選びませんでした。私はFacebookでソフトウェアエンジニアリングを学びましたが、そこではそれはまさにコーディングと同じことだったのです。アーキテクチャレビューも設計書もありませんでした。文化は「PRを出すか黙るか」でした。

この出来事をきっかけに、「ソフトウェアエンジニアリング」 という用語が実際にどこから来たのかを掘り下げてみました。それは1968年 に生まれたことがわかりました。50人のコンピューター科学者がドイツのガルミッシュで開催されたNATO会議に集まり、新たな危機に対処しようとしたのです。ソフトウェアプロジェクトは大規模化し、重要性を増し、混沌としていました。彼らは会議を「ソフトウェアエンジニアリング」と名付けました—これは意図的に挑発的な名前でした。なぜなら、そのような分野は存在しなかったからです。命名することで実現させようという希望でした。それは成功しました—名前は定着し、一種の学問分野がそれを中心に育ちました。私はそこでキャリアを積みました。しかし、このようなものはどれくらい続くのでしょうか?

これについて考える驚くほどエレガントな方法があります:コペルニクス的方法です。これは天体物理学者J. リチャード・ゴットが1969年にベルリンの壁を訪れた際に考案したものです。彼の洞察はシンプルですが自明ではありませんでした:自分の訪問のタイミングには何も特別なことはない。おそらく壁の存在の最初でも最後でもなく、中間のどこかで見ているのだと。彼の計算では、1993年以降も存続する確率はわずか25%でした。壁は1989年に崩壊しました。

もしゴットが同じ旅行中、NATO会議からわずか1年後にソフトウェアエンジニアリングについて尋ねられていたら、これほど長く続く確率は2%未満だったでしょう。

それでも:おそらく今こそ、適切に定義されたソフトウェアエンジニアリングの時代に入ろうとしているのかもしれません。Claudeが単純作業を処理し、私たちは興味深い問題に集中します。退屈な部分—ボイラープレート、ググること、意図を構文に機械的に翻訳すること—はますます自動化されています。残るのは本来重要だったはずの部分です:システムと判断力、そして何をどう構築するかではなく、何を構築すべきかを知ること。それを楽しんでください。短い期間かもしれません。コーディングという足かせなしに、ソフトウェアエンジニアリングはかなり簡単になりそうです。

誰もがこのように考えているわけではありません。私が最もよく聞く反論は、「コンパイラは決定論的だ。LLMの出力を同じように信頼することはできない」 というものです。

これは理にかなっているように聞こえます。しかし間違っています。

決定論的であることは予測可能であることを意味しません。コンパイラは確かに決定論的です—同じ入力、同じ出力。しかし、実行せずに何を出力するかを知ることはできません。これはコンピューターサイエンスの初期の洞察の一つでした:一般的に、プログラムを実行せずにそれが何をするかを予測することはできないのです。

しかし、すべての行を検証したとしましょう。ケン・トンプソンは40年前、それでも十分ではないことを示しました。「信頼への考察(Reflections on Trusting Trust)」 で、彼はコンパイラにバックドアを隠し、それが自己増殖する方法を実証しました—コンパイラのバイナリには、コンパイラが自身をコンパイルする際に自分自身を再挿入する悪意のあるコードが含まれています。ソースがクリーンでも、バイナリは危殆化しています。ソースコードを読むことで検証から逃れることはできません。

教訓は 「自分が書いていないコードを信頼するな」 ではありません—それは不可能です。教訓は、信頼は完全に検証に基づくことはできないということです。ある時点で、信頼しなければなりません。常に見通せない信頼境界があるのです。

では、なぜコンパイラを信頼するのでしょうか?決定論的だからではありません。検証したからでもありません。何千人、何百万人ものユーザーによる長年の使用を通じて信頼を獲得したからです。バグが表面化し、修正されます。エコシステムが成熟します。

AI生成コードも同じ方法で信頼を獲得します—時間、使用、そして修正される失敗を通じて。あるいはもっと早く:モデルがコードと一緒に形式的証明を生成できれば、コンパイラで得られた以上の検証を手に入れられるかもしれません。

信頼は決定論から派生するものではありません。信頼は獲得されるものです。信頼は社会的なものです。

そして、AIと働くことは根本的に社会的スキルであることがわかります。研究者たちは、AIでの成功を予測するのは「心の理論」—他のエージェントの視点をモデル化し、その場で適応する能力—であることを発見しました。技術的な深さでもなく、プロンプトエンジニアリングでもありません。最高のエンジニアは常に効果的なコミュニケーターであり、思慮深い協力者でした。それはかつてチームメイトや同僚を意味していました。今ではClaudeも含まれます。

ツールが毎週変わるとき、仕事は「どう働くか」を理解することになります。具体的なテクニックの半減期は今や数か月単位です。残るのはメタスキルです:気づき続けること、適応し続けること、どんどん賢くなる何かと対話し続けること。

不安は理解できます。すべてがとても混乱を招きます。しかし、未来と戦うことはできません。未来は私たちが作るものです。そしてこの未来はすでに私たちを変えています。

新しいモデルがリリースされて約1か月後、人々はそれが「弱体化された」と不平を言い始めます—どういうわけか遅く、愚かで、生き生きとしていない。時には彼らが正しいこともあります!推論バグやハーネスの退行がありました。しかし、それらはまれで比較的軽微です。より多くの場合、変化しているのはあなた自身です。モデルを自分の中に蒸留する—そのパターンを吸収し、その推論を内面化します。あなたの基準が上がります。今では1か月前には認識すらできなかったギャップに気づきます。

おそらく私たちはこれに適応するよう進化しています。人間は他の人間を蒸留する能力—協働から学び、周りの人々のスキルを吸収する能力—を進化させたのだと思います。これは常に技術の原動力でしたが、今は何か新しいものでそれを行っています。

私たちはAIと競争しているのではありません。AIと共進化しているのです。Claudeと働くことで、私たちの考え方、重視すること、尋ねる質問が変わります。モデルが良くなると私たちも良くなります。限界は後退し続けます。

ソフトウェアエンジニアリングは1968年に、何か新しいものを表現するために生まれました。私たちが今開発しているスキル—そしてそれが属する仕事—も新しい名前が必要になるでしょう。何と呼ぶにせよ、私たちはおそらくその真っ只中にいます。それが面白くしているのです。

まとめ

1968年に生まれた「ソフトウェアエンジニアリング」は、58年
経つ2026年から2027年ぐらいまでには、変化が起きてきそうです。エンジニアは、コーディングすることから、AIと共にコーディングしていく、AIにコーディングさせるに変化しそうです。

システムエンジニアは、作るから、何を作るか？どう作るか？
AIと作ったものを検証しリリースしていく、大きな分岐点になりそうです。

今までは、手戻りを少なくするために、設計を行い、コーディングを行って、テストをして、リリースしていきました。しかし、AIがコーディングすることになり、コーディングが速くできるようになれば、手戻りを少なくする必要もなくなり、概念が変わってきそうです。

いかに、速く作るか？そして、いかに速く改善するか？
ビジネスにあったシステムに変化させていけるか？が、より重要になる世界が広がって行きそうです。

コーディングするモデルの精度が益々あがっていくAIの進化に、システムエンジニアリングする人の進化も試されていくのかもしれません。今後のAIの進化、AGI、ASIも楽しみにです！