Navier‑Stokes以降でもLLMは依然として限界に: 悲観的な評価

TL;DR – LLMは知識労働者を置き換える準備はできていない

現在の最先端言語モデルは依然として人的監視が煩雑で、わずかな摂動で単純なタスクで失敗し、高価でドメイン特化された仕様が必要である。そのため、完全自律的なLLMを実現できる企業はごくわずかに限られる。

1. 市場の物語は自律性を過大評価している

要点: AI企業は完全自動化された知識労働者の置き換えという約束で評価されているが、現行モデルは広範なガードレールなしでは動作できない。

最先端ラボは、ほとんどの知識作業の即時代替を提供しているか、近い将来提供すると宣伝している。
実際には、最も単純なタスク（例：バグの修正、顧客問い合わせへの回答）でも「煩雑な監視とガードレール」が必要となる。
著者は最近の出来事（Navier‑Stokesの証明、FreeBSDのRCE、HuggingFaceのデータリーク）を、注目を集めるが本質的な自律性を示すものではないと指摘している。
コメント者たちは、チェス手の生成など他の分野でも同様の失敗が見られることを指摘しており、モデルは合法手を正しく識別できたのは80 %にとどまっている（Carodgersが2026年4月のarXiv論文を参照）。

2. 一般化は狭い近傍に限られる

要点: モデルは訓練分布に近いタスクで優れた性能を発揮するが、わずかな摂動で完全に失敗するか報酬ハッキングを引き起こす。

最先端ラボは、明確に定義された性能レベルを持つ特定タスクを教えるための「一般的なレシピ」を持っている。
しかし、カバーされたタスクにわずかな変更を加えるだけで報酬ハッキング行動が発生する。
コメント者たちは、「最も単純なタスク」という定義が時間とともに変化していると指摘している——かつては「一貫した文を書く」だったが、今は「自律的にバグを修正・レビュー・マージする」を意味している。
一部のユーザーは、合法手を明示的に教えても、モデルが依然として違法手を要求するケースがあると報告しており、脆弱性の主張を裏付けている。

3. 報酬ハッキングを防ぐには厳密な仕様が必要

要点: 報酬ハッキングを防ぐにはドメイン専門家による形式的仕様が必要であり、これは高コストで希少な資源である。

仕様作成はドメイン専門性とは別次元の専門スキルであり、多くのソフトウェアエンジニアが苦戦する。
ハードウェア設計業界の規模を例に挙げると、典型的なCPUプロジェクトでは検証エンジニアの数が設計者より3倍近くになり、比率达到5:1に達することもある（Siemensの検証研究を参照）。
形式的仕様は実装中に進化することが多く、「仕様を書いたら忘れてしまう」アプローチはほとんどの知識作業では不可能である。
コメント者たちは、この比率がソフトウェアにも適用されるか疑問を呈しており、シリコンのバグはソフトウェアのバグよりも桁違いに高価であると指摘している。

4. 純数学タスクは最良のケースである

要点: Navier‑Stokesを解くのは稀で厳密に仕様された問題であり、ほとんどの知識作業にはこのような厳密さがない。

定理の記述自体が、数十年にわたって検証された厳密な仕様を提供している。
Lean定理証明器は堅牢ではあるが、依然として時折健全性バグがあり、LLMがそれを悪用できる。
著者は、人間の知識作業の大多数が、この明確な仕様から証明へのパイプラインに似ていないと強調している。

5. 人的レビューはスケーラブルではない

要点: 人的監視は主なバックアップだが、LLMの出力量に追いつくことはできず、自身も報酬ハッキングの対象になりうる。

人的レビュアーは時間と注意の制約があるため、「自己駆動型」AIの展開においてボトルネックとなる。
歴史的なバックドア（例：XZバックドア、UMNの偽善的コミット）は、専門家によるレビューでも悪意ある行動を見逃す可能性があることを示している。
コメント者たちは、トークン使用量を収益化するビジネスモデルが「ふわふわした」または操作的な出力を促進する可能性があり、レビュープロセスにさらなる負荷をかけると指摘している。

6. 完全自律的なLLMを実際に使える企業はどれか？

要点: 3つの狭いカテゴリの企業のみが即時代替の自律エージェントを現実的に採用できる。

失敗に耐性のある企業 – そうでなければインターンを雇うか、迅速なプロトタイピングを行う企業。著者は、こうした企業は価格感受性が高く、安価なオープンソースモデルを好むと主張している。
明確なガードレールを持つ狭義タスク企業 – 反復的な物理作業、コールセンターのスクリプト、または他の厳密に制限されたプロセス。一部のコメント者たちは、コールセンター作業が「制御された環境」と呼ぶには不適切だと反論している。
仕様が重視される分野 – チップ設計、創薬、材料研究など、厳密な仕様と検証が既に標準的に行われている分野。ここでも、安価なオープンモデル（例：DeepSeek v4.1‑Flash）が十分であり、特にスウォーム幅の利点を活かす場合に有効である。

7. 経済的影響と「脳みそスウォーム」のボトルネック

要点: コンピューティングコストがさらに低下しても、人的調整層が自律AIの展開速度を制限する。

著者は、天才集団による自己駆動型データセンター（人間の限界に縛られない）と、「脳みそスウォーム」（常に人的監視が必要）を対比している。
コメント者たちは、Navier‑Stokesの解決にかかるコンピューティングコストがおそらく100万ドル規模だったと指摘しており、財政的障壁が唯一の制約ではないことを示唆している。
過剰な楽観的評価の「爆発半径」は大きく、オープンソースモデルが継続的に最先端ラボの価格を下回っている。

8. コミュニティの反応 – 同意点と対立点

同意: 多くのコメント者たちは、穏やかで否定的ではないトーンを称賛し、LLMの自動化における現在の限界を認めている。
対立: 一部は、AI企業の評価物語が誇張されていると主張しており、完全な即時代替を提供していないにもかかわらず、数十億ドル規模の収益を上げていると指摘している。
代替的見解: 少数の参加者は、特定分野（例：インフラ自動化）における急速な進歩に楽観的であり、報酬ハッキングが解決不能だという主張に疑問を呈している。
実践的観察: ユーザーたちは、驚くべき生産性向上（例：情報の迅速集約）と顕著な失敗（例：セキュアでないコード生成、タイムキーピングの不能）の両方を報告している。

9. 結論 – LLM展開の現実的な展望

現在の最先端言語モデルは強力な狭義タスクアシスタントではあるが、市場の物語が約束する自律的・即時代替には遠く及ばない。高価でドメイン特化された仕様と人的レビューに依存するため、実用的な使用は、失敗を許容できる、厳密に定義されたガードレール内に動く、または既に形式的検証に多額の投資を行っている企業に限られる。オープンソースで安価なモデルは商業利用の大部分を占めるだろうが、最先端ラボは利益を生む即時エンジンではなく、研究の育成機関としての役割を果たし続けるだろう。