あなたのチームは今日、何時間を「考えること」に使えましたか?
先月、Anthropic社のエンジニア Adam Wolff氏が、Xへの投稿で「ソフトウェアエンジニアリングは終わる」と発言し、海外のエンジニアコミュニティで大きな注目を集めました。
この発言は即座に誤解されました。
多くの人が「エンジニアが不要になる」と受け取ったのです。
しかし数週間後、実際に新モデル(Claude Opus 4.5)を使った人々は、彼の真意を理解し始めました。
終わるのは、エンジニアリングではなく、「コーディング」という作業です。
今回は、この論考を起点に、エンジニアリングの重心移動について考えます。
「コーディングが終わる」という言葉の本当の意味
Wolff氏は、Meta(旧Facebook)で「プルリクを出すか、黙るか」という文化の中で育ちました。
そこでは、コーディング=エンジニアリングでした。
アーキテクチャレビューも設計ドキュメントもなく、すべてはコードで語られました。
だからこそ、彼は当初「ソフトウェアエンジニアリング」という言葉を深く考えずに使っていました。
しかし今回の騒動をきっかけに、彼はこの言葉の起源を調べ直しました。
そして気づいたのです。
定型コードの実装、ボイラープレートの作成、調査結果を構文へ落とし込む作業――。
こうした「書くこと自体が目的になっていた時間」が、生成AIによって限りなくゼロに近づいていると。
では、その先に何が残るのでしょうか?
1968年に「ソフトウェアエンジニアリング」という名前だけが先に生まれた
「ソフトウェアエンジニアリング」という言葉は、1968年にドイツのガルミッシュで開かれた
NATO国際会議で初めて使われました。
当時、ソフトウェアプロジェクトは巨大化して混沌としており、制御不能になりつつありました。
会議の主催者たちは、意図的に存在しない学問分野に「ソフトウェアエンジニアリング」という名前を与えました。
命名することで、秩序を生み出そうとしたのです。
その思惑は見事成功して名前は定着し、一種の規律が育ちました。
Wolff氏はこう問いかけます:
「では、こうした名前は、いつまで続くものなのでしょうか?」
なぜ「AIは信頼できない」という反論は間違っているのか
AIの登場による時代の変化に対して、最もよく聞かれる反論があります。
「コンパイラは決定論的だ。同じ入力なら、同じ出力が保証される。だから信頼できる。
一方、LLMは非決定論的だ。だから信頼できない」
一見、筋が通っているように見えますが、これは間違っています。
決定論的であることと、予測可能であることは、別です。
コンパイラは確かに決定論的ですが、それが何を出力するかは、実際に実行してみなければ分かりません。
これは、計算機科学の最も初期に得られた重要な洞察の一つです。
では、すべての行を検証すれば安全なのでしょうか?
Ken Thompsonが40年前に示した「信頼の限界」
それでも不十分だと、UNIX開発者 Ken Thompson は40年前に示しました。
1984年のチューリング賞受賞講演”Reflections on Trusting Trust”で、
彼はこう実証しました:
コンパイラのバイナリに悪意あるコードを仕込み、それが自己増殖するようにすれば、ソースコードがどれだけクリーンでも、バイナリは汚染され続けると。
ここでの教訓は「自分が書いていないコードを信頼するな」ではありません。
それは不可能だからです。
本当の教訓は「信頼は、検証だけでは完結しない」ということです。
どこかの時点で、私たちは信頼せざるを得ません。
では、なぜ私たちはコンパイラを信頼しているのか
それは、決定論的だからではありません。
検証したからでもありません。
答えは単純です。
何年もの使用実績があり、何千人、何百万人が使い続けてきたからです。
バグは発見され、修正されます。
エコシステムは成熟します。
信頼は、理論から生まれるのではなく、時間と使用の積み重ねから生まれます。
信頼は、技術的なものではなく、社会的なものです。
AIが生成したコードも、同じ道を辿ります。
あるいは、もっと早く信頼を得るかもしれません。
モデルがコードと同時に形式証明を生成できれば、コンパイラ以上の検証可能性を持つことになるからです。
AIとの協働は、「社会的スキル」である
興味深い研究結果があります。
2025年に発表された研究によれば、AIを使いこなせる人を分けるのは、技術的知識でもプロンプトエンジニアリングでもなく、Theory of Mind(心の理論)――相手の視点をモデル化し、適応する能力でした。
優れたエンジニアは、常に効果的なコミュニケーターであり、思慮深い協働者でした。
以前は、その相手はチームメイトや同僚でした。
しかし今は、その相手にはAIも含まれます。
ツールが週単位で変わる時代では、特定のテクニックの寿命は数ヶ月単位です。
残るのは、メタスキルです:
- 気づき続けること
- 適応し続けること
- 賢くなり続ける何かと対話し続けること
変わっているのは、モデルではなく、あなた自身
この変化に不安を感じるのは当然です。
しかし、未来と戦うことはできません。
未来は、私たちが作るものだからです。
そして、この未来はすでに、私たちを変え始めています。
新しいモデルがリリースされて1ヶ月ほど経つと、必ずこんな声が上がります。
「モデルが劣化した。前より遅く、前より愚かになった気がする」
時には、それが正しいこともあります(Anthropic社も過去に推論バグがあったことを認めています)。
しかし、そうしたケースは稀です。
ほとんどの場合、変わっているのは、モデルではなく、あなた自身です。
あなたはモデルを「蒸留」しています。
そのパターンを吸収し、推論を内面化しています。
あなたのベースラインが上がっているのです。
1ヶ月前には気づけなかったギャップに、今は気づけるようになっています。
人間は他者を蒸留するように進化してきた
他者を蒸留する能力――すなわち協働から学び、周囲の人々のスキルを吸収する能力。
これこそが、人間の技術進化の原動力でした。
今、私たちは何か新しいものと協働しています。
私たちはAIと競争しているのではなく、AIと共に進化しています。
AIと働くことで、私たちの思考は変わり、重視するものが変わり、問いかける質問が変わります。
モデルが良くなれば、私たちも良くなる。
限界は、後退し続けます。
もしかすると 今が「本当の始まり」なのかもしれない
Wolff氏は、こう続けます。
むしろ今こそ、本来の意味での「ソフトウェアエンジニアリング」が始まろうとしているのではないかと。
Claudeが雑務を引き受けてくれることで、私たちは本質的な問題に集中できる。
定型処理、調査、意図を構文へ機械的に翻訳する作業――。
こうした作業は、すでに「自動で起きること」になりつつあります。
残るのは、本来ずっと重要だったはずの部分です。
システム設計、判断、そして「何を作るべきか」を知ること。
「どう作るか」ではなく、「何を作るか」。
コーディングという負荷が消えた先にこそ、本当のソフトウェアエンジニアリングがあるのかもしれません。
ただし、それも長くは続かないかもしれません。
新しい名前が必要になる
1968年に生まれた「ソフトウェアエンジニアリング」は、何か新しいものを記述するために必要でした。
私たちが今、身につけつつあるスキルやそれが属する職業にも、新しい名前が必要になるでしょう。
それを何と呼ぶにせよ、私たちはおそらく、その真ん中にいます。
だからこそ、面白いのです。
では、明日から何をすべきか
この変化を前に、立ち止まる必要はありません。
小さく始めましょう:
- 次のコードレビューで、AIに下書きさせてみる
どこまで任せられるか、境界を探ってみてください。 - 設計ドキュメントを、AIと対話しながら書く
思考の整理に、新しいパートナーを加えてみてください。 - 「この実装は本当に必要か?」と問い直す時間を作る
コードを書く時間が減った分、考える時間を増やしてください。
変化は、小さな習慣から始まります。
【参考資料(一次情報)】
Adam Wolff, “The End of Software Engineering” (2025)
NATO Software Engineering Conference, Report 1968
Ken Thompson, “Reflections on Trusting Trust” (1984)
Riedl & Weidmann, “Quantifying Human-AI Synergy” (2025)
この記事の著者：H.W.
電巧社 SI事業部 エンジニア
