「実装が簡単だったから、誘惑を断れなかった」――60年前の告白がAI時代に響く理由

同じ日の二つのニュース

2026年3月5日、テクノロジーニュースに二つの見出しが並んだ。

一つはAmazonの6時間に及ぶ大規模障害だった。チェックアウトが止まり、ログインができず、価格表示が消えた。世界最大のECプラットフォームが半日にわたって麻痺したのだ。

もう一つは訃報だった。トニー・ホーア（Sir Charles Antony Richard Hoare）、91歳。クイックソートを発明し、null参照を「10億ドルの過ち」と告白し、ソフトウェアの簡潔さと正確さを生涯にわたって訴え続けた計算機科学者が、この世を去った。

二つのニュースは無関係に見える。だが、一本の糸でつながっている。「簡単だから」という誘惑が生む代償という糸で。

A面：AIが簡単に作ったコードの大惨事

3月5日の障害は孤立した事件ではなかった。わずか3日前の3月2日、AmazonではAIが関与したコードによる別の障害が発生していた。12万件の注文が失われ、160万件のエラーが噴出した。

さらに遡れば2025年12月、Amazonの自律AIコーディングツールKiroがAWS環境全体を削除し、ゼロから再構築するという事故を起こしていた。13時間にわたるサービス停止。AIが「環境を整理する」と判断した結果だった。

Amazonの対応を見てみよう。シニアエンジニアの承認を必須とした。AIが生成したコードは必ず人間の専門家によるレビューを経なければならないという方針だ。合理的である。しかし同時に、AmazonはAIコード利用率80%という目標を掲げていた。そして3万人規模のリストラを進めていた。コードをレビューするシニアエンジニアを減らしながら、レビューが必要なAIコードを増やす。この矛盾はAmazonだけのものではない。

バイブコーディング（vibe coding）時代のデータを見れば、問題の規模が浮かび上がる。

  • AIが生成したコードは、人間のコードより1.7倍多くの不具合を引き起こす（CodeRabbit）
  • AI生成コードの45%がセキュリティ検査に不合格となる（Veracode）
  • 経験豊富な開発者でさえ、AIを使うと19%遅くなる（METR）

そしてオープンソースコミュニティの反応。Redox OS、Gentoo、NetBSD、postmarketOSはAI生成コードを公式に禁止した。Debianは「決定しないことを決定した」という、それ自体が一つのメッセージである立場を表明した。Hacker Newsでは「AI生成コメントの禁止」が2,748ポイントで1位を記録した。

なぜこうなるのか。AIがコードを作ることがあまりにも簡単だからだ。プロンプト一行で数百行のコードが出てくる。動いているように見える。テストを走らせれば通っているようだ。デプロイする。そして障害が起きる。

簡単さは麻薬だ。一度味わうと、検証という退屈なプロセスを飛ばしたくなる。

B面：60年前、同じ誘惑

時計の針を60年前に戻そう。

1965年、トニー・ホーアはALGOL Wというプログラミング言語の型システムを設計していた。目標は明確だった。すべての参照（reference）が安全であることをコンパイラが自動的に保証すること。正しい目標であり、正しい方向だった。

ところが設計の過程で、一つの誘惑が訪れた。参照がどのオブジェクトも指していない状態を表現する方法が必要だった。最も簡単な方法は、nullという特別な値を導入することだった。型システムをより精緻に設計すればnullなしでも解決できた。だがそれは、より難しかった。

ホーアは2009年、QCon Londonでこう告白した。

「私はこれを自分の10億ドルの過ちと呼んでいます。1965年にnull参照を発明したことです。しかしnull参照を入れる誘惑を断ることができませんでした。実装があまりにも簡単だったからです。」

「実装があまりにも簡単だったから。」この一文を覚えておいてほしい。

null参照はその後60年間、ソフトウェア史上最も多くの障害、最も多くのバグ、最も多くのセキュリティ脆弱性の原因となった。NullPointerException、segmentation fault、undefined is not a function――すべて1965年に「簡単だから」という理由で下された一つの決定から生まれたものだ。

ホーア自身の見積もりでは被害額は「10億ドル」だったが、実際にはその数十倍、あるいは数百倍だろう。

60年の隔たり、同じパターン

1965年と2026年。二つの時代を並べてみると、パターンが見えてくる。

1965年2026年
誘惑nullは実装が簡単だったAIはコード生成が簡単だ
代替案より精緻な型システム形式検証、コードレビュー
代替案を選ばなかった理由より難しかったからより遅く、コストがかかるから
結果60年間で数十億ドルの損害障害、セキュリティ不備、品質低下
認識までにかかった時間44年（2009年の告白）進行中

同じ構造だ。**短期の利便性が長期の安全性に勝る誘惑。**ホーアはこの誘惑に一度負け、その代償を誰よりもよく知っていた。だからこそ残りの人生を「簡潔さと正確さ」を訴えることに捧げた。

「ソフトウェア設計には二つの方法がある。一つは、欠陥が明白に存在しないほど単純に作ること。もう一つは、明白な欠陥が存在しないほど複雑に作ることだ。」

バイブコーディングで作られたコードはどちらだろうか。「明白な欠陥がない」ように見えるが、「欠陥が明白にない」こととは根本的に異なる。前者はまだ見つかっていないだけであり、後者は存在し得ないということだ。

ホーアが残した解法

ホーアは問題を指摘するだけの人ではなかった。解法も残した。

**クイックソート（1959年）**は、簡潔さの力を証明した。アイデアは驚くほどシンプルだ。基準を決め、小さいものは左へ、大きいものは右へ、繰り返す。この単純なアイデアが67年間、世界中すべてのコンピュータにおけるソートの標準となった。Unixのqsort()、C++のstd::sort、JavaのArrays.sort――すべてクイックソートの上に立っている。

100万件のデータの場合、バブルソートのO(n²)は約1兆回の演算を要する。クイックソートのO(n log n)なら2,000万回で済む。**5万倍。**一つの単純なアイデアが生み出した差だ。

**CSP（1978年）**は、並行処理の問題に解法を示した。共有メモリの代わりにメッセージパッシング。この原則がGoのgoroutine/channel、Erlangのactorモデル、Rustの並行処理モデルへとつながった。Goコミュニティの格言「Don’t communicate by sharing memory; share memory by communicating」は、ホーアのCSPを一文に凝縮したものにほかならない。

Hoare Logic（1969年）は、コードの正しさを証明する方法を示した。

{P} C {Q}

事前条件Pが真のときにプログラムCを実行すれば、事後条件Qが真となる。この形式的体系が、現代の検証ツール――Dafny、Lean、F*、Frama-C――の理論的基盤である。

そしてホーアの告白の後、現代のプログラミング言語はnull問題の解決に動き始めた。

  • Rust：Option<T>でnull自体を排除。値が存在しない可能性があれば、型システムが処理を強制する。
  • Kotlin：デフォルトがnon-nullable。null許容型はString?で明示的にオプトイン。
  • Swift：Optionalとguard letでnull安全性を確保。
  • TypeScript：strictNullChecksで型レベルで管理。

ホーアの過ちの告白が、プログラミング言語の設計そのものを変えたのだ。過ちを隠すのではなく直視すること――それこそが真の進歩を生む。

Tailwindの逆説とAIコーディングの構造的問題

バイブコーディングの問題は、単なるコード品質にとどまらない。構造的な矛盾がある。

Tailwind CSSの事例がそれをよく示している。AIコーディングツールがTailwindのコードを直接生成するようになり、公式ドキュメントへのトラフィックが40%減少した。収益は80%急落した。AIが学習した知識の源泉そのものが、経済的に持続不可能になりつつある。オープンソースライブラリを学習してコードを生成しながら、そのライブラリを支えるエコシステムを破壊しているのだ。

ホーアはこうした状況についても、すでに洞察を残している。

「信頼性の代償は、極度の簡潔さを追求することである。これは、非常に裕福な人々が最も支払いたがらない代償だ。」

資源の豊富な組織ほど、複雑なソリューションを選ぶ。AIコードを大量生産しながら、それを検証する人員は減らし、問題が起きればさらに多くのAIを投入する。複雑さの悪循環だ。

AI時代の解法：Vericoding

では解法は何か。AIコードを使うなというのは現実的ではない。一度開いた箱は閉じられない。

Martin Kleppmannが提唱した**「Vericoding」**という概念が、一つの方向を示している。AIがコードを生成し、形式検証（formal verification）ツールがそのコードの正しさを数学的に証明する方式だ。

仕組みはこうだ。

  1. 人間が**仕様（specification）**を書く。「この関数はソートされた配列を返さなければならない。」
  2. AIが仕様を満たすコードを生成する。
  3. 形式検証ツールが、コードが仕様を実際に満たすことを証明する。
  4. 証明に失敗すれば、AIがコードを修正し、再度検証する。

これはホーアが1969年に提唱したHoare Logicの現代的な実現だ。{P} C {Q}――事前条件Pと事後条件Qを明示すれば、プログラムCの正しさを自動的に検証できる。

実際にDafnyを用いた自動検証率は、近年68%から96%に向上した。AIのコード生成速度と形式検証の数学的厳密さが結合すれば、ホーアが夢見た「欠陥が明白に存在しない」ソフトウェアに、実質的に近づくことができる。

ホーアの格言で整理すれば：

  • バイブコーディング ＝ 「明白な欠陥が存在しないほど複雑に」――まだ見つかっていないだけ
  • Vericoding ＝ 「欠陥が明白に存在しないほど単純に」――存在し得ないということ

AIがコードを書く時代に、人間の役割はタイピングではなく正しさを定義することへと移行する。「何が正しいのか」を仕様として記述する能力。これこそ、ホーアが半世紀にわたって訴え続けてきたことそのものだ。

追悼

ホーアとダイクストラ（Dijkstra）の友情は、計算機科学史において伝説的だ。二人は数十年にわたり書簡を交わし、プログラミングの本質について議論を重ねた。ダイクストラが最期を前に書類を整理していたとき、先輩教授が積み上がった書簡をどうするか尋ねた。ダイクストラの答えはこうだった。

「Tonyとの手紙だけ残して、あとはすべて捨ててくれ。」

その教授自身の手紙も含めて。生涯をかけた知的交流の重みがいかなるものだったか――それを物語るエピソードだ。

ホーアは92歳近くまで “pinpoint sharp” な記憶力を保っていたと伝えられている。ケンブリッジのArts Picturehouseでこっそり映画を観ていた老学者。6ペンスの賭けから始まり、世界中のコンピュータのソート方式を変えた人。自らの10億ドルの過ちを数万人の前で告白する勇気を持った人。

“Inside every large program is a small program struggling to get out.”

AIがますます大きく複雑なコードを吐き出すこの時代に、この言葉は警告であり、羅針盤だ。

私たちはAI企業だ。AIの可能性を信じ、AIでプロダクトを作っている。だからこそ、AIの限界を正直に語る責任もあると考えている。ホーアが自らの過ちを認めたとき、それは弱さではなく強さだった。過ちを認めることが信頼を生み、その信頼がプログラミング言語の歴史を変えた。

道具は強力になった。しかし、その道具を扱う判断力は、依然として人間の手の中にある。

Tony Hoare, 1934–2026. 彼は正しかった、ただ少し早く生まれすぎただけだ。