Web 開発は将来「ニューラルネットの最適化処理」になるのか

Andrej Karpathy は、ニューラルネットの重みそのものをプログラムと見る 「Software 2.0」という見立てを示しました。人間がコードを書く代わりに、 データと損失関数を用意して最適化（勾配降下）に プログラムを探させる、という捉え方です。これを Web 開発に引きつけると、 「開発はいずれニューラルネットの最適化処理になるのか」という問いが立ちます。

先に結論を置きます。一部はそちらに寄っていきます。ですが全部が置き換わるわけではありません。 知覚・生成・順位付けは学習へ、決定性・整合性・説明責任が要る処理は明示コードへ —— その境界をどう引くかが、これからのエンジニアの腕の見せどころになります。 まずは下のデモで、機能ごとにその境界を引いてみてください。

Software 1.0 と 2.0 ―― Karpathy の見立て

出発点は Andrej Karpathy が 2017 年に書いたエッセイ “Software 2.0” です。彼はソフトウェアを 2 種類に分けました。

2.0 では、人間はコードを直接書きません。プログラムの空間を、データと損失で間接的に指定するのです。 「こういう入力にはこう答えてほしい」という例（データ）と、「正解からどれだけ外れたら罰するか」という基準（損失）を与えると、 最適化がその基準を満たす重みを探します。書かれるのはコードではなく、データと損失です。

Karpathy の観察はこうです。画像認識・音声認識・機械翻訳・囲碁といった、 かつて人間が手書きルールで頑張っていた領域は、すでに 2.0（学習された重み）に置き換わりました。 手で特徴量やルールを書くより、データから学習させたほうが精度が出る ―― そういう領域が広がった、という指摘です。

Software 3.0 ―― プロンプトが新しいプログラム

Karpathy は 2025 年の講演 “Software Is Changing (Again)” で、もう一段の見立てを足しました。 Software 3.0 です。大規模言語モデル（LLM）の登場で、 プロンプト（自然言語）が新しいプログラムになりつつある、という観察です。 日本語や英語といった自然言語が、プログラミング言語の一種になっていく、という見方をします。

重要なのは、これらが置き換わるのではなく併存するという点です。 どの機能を 1.0 で書き、どこを 2.0 のモデルに任せ、どこを 3.0 のプロンプトで動かすかを 選ぶ時代になる、という見立てです。Karpathy は LLM を「新しい種類のコンピュータ（OS）」になぞらえ、 私たちはまだその初期にいる、と語っています。

Web 開発に引きつけると ―― 3 段階の見方

この見立てを Web 開発に当てはめると、置き換わり方は段階で考えられます。 いま起きていること、その先、極端な姿、の 3 つです。

問いの「最適化処理になるのか」は、この極端の側を指しています。 では、それが何を意味するのかを次に整理します。

「最適化処理になる」とはどういう意味か

主張を一言にすると、エンジニアの仕事の重心が動く、ということです。 「明示的なコードを書く」から、 「評価関数（eval）を設計し、データとフィードバックループを整え、最適化を回す」へ。

2.0 の世界では、プログラムを決めるのはコードではなくデータと損失です。 だとすれば、品質を左右するのは「どんなコードを書いたか」より 「どんなデータを集め、何を良しとする評価関数を置いたか」になります。 つまりコードよりデータと評価が一級市民になる、という見方です。 この重心移動を指して「開発が最適化処理に近づく」と表現しているわけです。

賛成側の根拠

• すでに移行した実績がある。知覚（画像・音声）・生成・順位付けの領域は、 手書きルールから学習へ実際に置き換わってきた。これは予測ではなく観測された事実。
• 微分可能プログラミングと普遍近似。十分なデータと計算があれば、 明示的に書き下すのが難しい関数も、学習によって近似できる。ルールで列挙しきれない 「あいまいな入力の解釈」ほど学習が効く。
• 3.0 で指定コストが下がった。LLM により「自然言語で挙動を指示する」 コストが大きく下がった。これまでコードを書かないと無理だった処理の一部が、 プロンプトで届く範囲に入った。

反対側・留保 ―― ここが大事

一方で、「全部が最適化処理になる」という強い主張には、相応の留保が要ります。 ここを軽く見ると、決定的で安価に書ける処理まで無理にモデル化して事故を招きます。

決定性・検証可能性・説明責任

課金・残高・権限・トランザクション整合性・法規制対応は、確率的に「だいたい正しい」では困ります。 ニューラルネットは形式的な検証が難しく、再現性や監査の面で不利です。 「なぜその判断をしたか」を説明する必要がある領域 ―― 会計・金融・医療・法務では特に ―― では、答えが一意に決まり、根拠を追える明示コードのほうが向きます。

コスト・レイテンシ・エネルギー

明示コードの分岐は、たいてい 1 回の比較で終わります。一方ニューラルネットの推論は、 桁違いに高コストです。全部をモデルにやらせると、安く速く済むはずの処理まで割に合わなくなります。 「残高を足す」のような処理にモデル推論を挟むのは、コストの面で筋が悪いのです。

決定的な処理は当面 1.0 が残る

CRUD、認可、整合性、決済のような決定的処理は、当面は明示コードで残ります。 ニューラルネット化が向くのは「知覚・生成・順位付け・あいまいな入力の解釈」であって、 すべての処理ではありません。向き不向きの線引きが要ります。

Software 2.0 自体の弱点

Karpathy 自身も 2.0 の弱点を認めています。デバッグが難しいこと、 学習データのバイアスがそのまま挙動に出ること。2.0 は銀の弾丸ではなく、 「どこに効いて、どこで事故るか」を見極めて使う道具です。

Jevons パラドックス的な反論

経済学に Jevons パラドックスという観察があります。 資源を効率よく使えるようになるほど、かえってその資源の総消費量が増える、というものです。 これをソフトウェアに当てはめると、コードを書くコストが下がるほど、 作られるソフトの総量と多様性はむしろ増えるかもしれません。 「開発が消える」のではなく「開発の形が変わり、量は増える」可能性がある、という反論です。

どこが NN 化し、どこが明示コードで残るか

ここまでを、設計の指針としてまとめます。判断軸はデモの 5 つと同じです ―― 決定性・データ量・許容誤差・説明責任・コスト。

まとめ

「Web 開発は将来ニューラルネットの最適化処理になるのか」への答えは、 一部はそうなる、でも全部ではないです。 知覚・生成・順位付け・あいまいな入力の解釈は、すでに学習へ移っており、これからも広がります。 その領域では、エンジニアの仕事はコードを書くことより、 データを集め・評価関数を設計し・フィードバックループを回すことへ重心が動きます。

一方で、決定性・整合性・説明責任・コストが効く処理 ―― 残高・権限・課金・法令対応 ―― は、当面は明示コードで残ります。確率的な「だいたい正しい」では困るからです。 さらに Jevons パラドックス的に言えば、書くコストが下がるほどソフトの総量は増え、 開発の仕事は消えるより形を変える可能性が高いです。

だとすれば、これからのエンジニアの腕は、機能ごとに 「ここは学習、ここは明示コード、ここはプロンプト」と境界を引いて配置する力に 移っていきます。デモで機能カードを選んだときに感じた「落ち方の違い」を、 実際の設計でも引けるかどうか ―― そこが新しい難しさであり、面白さです。