なぜ私はナヴィエ・ストークス方程式の解決後もLLMに対して弱気なのか

なぜ私はナヴィエ・ストークス方程式の解決後もLLMに対して弱気なのか （この記事へのコメントとして、クロード・フェイブル 5.1、ホールデン・セイバーヘイゲン、ガブリエル・カマー、アンドレス・エルブセン、アリス・マッケアン、トリスタン・ワイルド＝ラルーに感謝します） 読者の皆さんに考えていただくために、いくつかの仮説から始めます。 最先端の研究機関は、ほとんどの知識労働者を完全に自動化するドロップイン代替品をすでに生み出した、あるいはごく近い将来に生み出すという物語に基づいて評価されていますが、現在の最先端モデルは、たとえ最も単純なタスクであっても、多大な監督とガードレールを必要とします。見出しを飾るような力技（ナヴィエ・ストークス方程式、FreeBSDのRCE、Hugging Faceのインシデント）や、最先端研究機関のレトリックに惑わされ、実質的な自律性が達成されたと信じている人は、現在でもモデルが監督している者よりもベンチマークで遥かに低いスコアを出すであろう、下位四分位のソフトウェアエンジニアを雇用し続けているソフトウェア企業に目を向けるだけで十分です。モデルは、訓練された特定のタスクの小さな近傍内のタスクに対してはよく汎化しますが、それでも重大な注意点があります。最先端の研究機関は、明確に定義されたタスクパフォーマンスレベルを持つほぼあらゆる特定のタスクをモデルに教えるための一般的なレシピを開発しました。多くのタスクは訓練データに含まれています。しかし、カバーされているタスククラス内でのわずかな変動でさえ、完全な失敗や報酬ハッキングにつながります。 現在の報酬ハッキングの問題は、ドメイン専門家による厳密な仕様定義によってのみ解決できます。ドメイン専門家の時間は高価です。厳密な仕様定義自体がスキルであり、特定の専門分野外の専門知識を必要とします。多くの熟練したソフトウェアエンジニアでさえ、それを行うのが下手です。大多数のドメインでは、ドメイン専門家と仕様定義専門家の交差点は、ばかばかしくほど小さいです。 厳密な仕様定義の労働コストは、非公式な仕様定義の直接実装のコストを大きく上回る可能性があります。ハードウェアエンジニアリングの世界は、その素晴らしいケーススタディを提供しています。そこでは、典型的なCPUプロジェクトは、設計エンジニアの約3倍の仕様定義および検証エンジニアを擁し、5:1の比率も珍しくありません。さらに悪いことに、多くのタスクは、一度仕様を書いて忘れることができる便利な仕様定義・実装レジームを許容しません。厳密な形式仕様は、非公式な仕様定義に従って実装中に発見された洞察との対話で頻繁に進化します。高レベルのワンアンドダン（一度きりの）仕様定義（例えば、CPUアーキテクチャファミリーの実行可能ISA仕様）を楽しむタスクの場合、そのような高レベル仕様に対する検証のコストは、現在の技術では克服不可能であり、構築がより高価で設計の変動に対してはるかに壊れやすい低レベル仕様の使用を必要とします。 ナヴィエ・ストークス方程式や、それと同様の純粋数学における記述は、厳密な仕様定義に対するエージェント的な作業の絶対的な最良のシナリオです。定理の記述自体がすでに厳密な仕様定義です。それは数学コミュニティによって数十年にわたる監査を受けており、Leanでのそのレンダリングは、Mathlibからの実績のある数学オブジェクトの観点から定義された直接的な翻訳です。検証ツールであるLean定理証明器は、広範に監査されており、報酬ハッキングに対して脆弱にするような不健全さの種類を回避するように特別に設計されています。Leanやそれに類する定理証明器でさえ無敵ではありません。健全性のバグにより、LLMが証明カーネルを通過して偽の証明を洗浄することが以前にあり、さらに多くのバグが存在する可能性は低いとは言えません。これは最も楽観的なセットアップです。人間の知識労働の大多数はこれとは似ていません。私は以下で、この点で純粋数学に似ている知識労働の数少ない分野についてコメントします。厳密な仕様定義の最良の代替手段は、人間のレビューです。人間のレビューは、言語モデルが生成する出力量にはうまくスケールしません。さらに悪いことに、専門家による人間のレビューでさえ、報酬ハッキングに対して非常に脆弱です。XZバックドアや、Linuxに組み込まれた悪名高いUMNの偽コミットを考えてみてください。人間のレビューがエージェント的な生産ループの重要な部分であり続ける場合、生産ペースは必然的に人間の時間と注意の限界のような要因によってボトルネックになります。これは、データセンターの最先端研究機関のCEOが常に数ヶ月先だと信じている、天才たちの国にとっては全く現実的ではありません。 これらを総合すると、ほとんどのドメインにおいてLLMは、有能だが完全には自律しない「ひび割れたインターン」のような存在であり続けるように見えます。ほとんどの企業は、スキル不足や技術普及の遅れの問題からではなく、現在のアーキテクチャに固有と思われる構造的な理由から、完全に自律的なAIを採用することはできません。完全に自律的なLLMの使用を受け入れられる企業のクラスは、私の数えではわずか3つです。 失敗を安価に受け入れられる企業：インターンを雇用するであろう企業、迅速なプロトタイピング作業に関わる企業など。 既存の明確なガードレールを持つ、狭く定義された少数のタスクを完了する必要がある企業：制御された環境での反復的な肉体労働、コールセンターやカスタマーサービスのチャット業務など。 厳密な仕様定義と検証のコストを受け入れられる、または本質的にすでにそれを行っている企業：チップ設計、創薬、および展開時の失敗が存亡に関わるその他のドメイン。 最初の2つのクラスは価格に敏感であり、安価なモデルから最先端モデルへの推論品質の向上を必ずしも必要としません。これらの企業のほとんどは、安価なハードウェアで実行されるオープンモデル、場合によっては使用場所でローカルに実行されるモデルによって最もよくサービスされます。最初のクラスと3番目のクラスでは、数学やセキュリティ研究における見出しとなる結果を生み出したような、あいまいな組み合わせ探索の種類は、推論能力よりもエージェント的なスワーム幅（swarm width）に敏感であるように思われます。2026年春のハイプサイクルを牽引したMythos CVEを再現した小さなオープンモデルを参照してください。もしそれが事実であれば、より広いスワームで同じワークロードを実行できる安価なオープンモデルを使用する理由がさらに増えます。 3番目のクラスの企業は、依然として最先端モデルを使用するかもしれませんが、DeepSeek v4.1 Flashのような安価なモデルでその作業ができないとは限りません。そして、私が仮説を立てたスワーム幅の利点は、より安価なモデルを推進するさらなる理由を与えます。このクラスの企業にもう一つ興味深い特性があります。それは、一般的に知的財産（IP）について非常に秘密主義であり、ユーザーデータのトレーニングを行わないという想定された合意があったとしても、AnthropicやOpenAIにすべてを送信することに満足していない可能性が高いということです。 さて、最先端の研究機関が煮詰まったとしても、データセンターいっぱいの脳みそ（brainlets）というシナリオが、人工超知能（ASI）のシナリオと同じくらい多くのAIコンピューティングを駆動するという提案があるかもしれません。違いは、天才たちのデータセンターは自己駆動であり、消費できるコンピューティング量によってのみ制限されるのに対し、脳みそ集団は人間のオーケストレーターによって大きくボトルネックになるということです。私の個人的な賭けは、その爆発半径は最先端研究機関をはるかに超えるだろうということです。