なぜnullは10億ドルの誤りと呼ばれるか

結論：不在を「値のふり」で表した一手が、全ての参照を疑わせた

横にスクロール

null参照の害は一言でいえば、「型が『ここに値がある』と約束しているのに、実体は不在でありうる」という嘘を言語が公認したことにある。ある変数の型が「文字列」なら、そこには常に文字列があるはずだ——この素朴な期待をnullは裏切る。結果、あらゆる参照に対して「本当に値があるか？」の検査が必要になり、その検査を書き忘れてもコンパイラは何も言わない。設計者Tony Hoare自身が後年これを「10億ドルの誤り」と呼んだのは、比喩ではなく、数十年分のクラッシュ・脆弱性・修正コストの総体を指した言葉である。

当時の状況と競合：1965年、ALGOL Wという実験場

1960年代半ば、Hoareはニクラウス・ヴィルト（Niklaus Wirth）とともにALGOL 60の後継言語 ALGOL W を設計していた。当時の新機軸はレコード（構造体）とそれを指すポインタ、すなわち参照の導入である。ここで生じたのが「まだ何も指していない参照」をどう表すかという問題だった。

Hoareが目指していたのは高い安全性だった。彼の理想は、コンパイラの型検査によってすべての参照の利用が絶対に安全であると保証することにあった。しかし「未初期化の参照」「連結リストの終端」のような不在状態を型の中でどう扱うかは、当時の型システムの語彙では自明ではなかった。選択肢は概念上ふたつあった。

決定打・経緯：「実装が簡単だったから」という一言

勝敗を分けたのは、思想ではなく手軽さだった。Hoareは2009年、ロンドンのQConでの講演「Null References: The Billion Dollar Mistake」で、その判断を率直に振り返っている。要点は、すべての参照を安全にするという目標を掲げながら、null参照という抜け穴を入れた理由が「実装がとても簡単だったから（simply because it was so easy to implement）」だった、というものだ。

nullは、あらゆる参照型に代入でき、どんなポインタのビット表現にも「ゼロ」という空席を一つ用意するだけでよい。型ごとに「不在」を表現する専用の仕組みを設計・実装する労力に比べ、圧倒的に安上がりだった。この手軽さゆえにnullはALGOL Wから後続言語へ雪だるま式に受け継がれ、C・C++のヌルポインタ、JavaのnullとNullPointerException（日本の開発者が「ぬるぽ」と呼ぶもの）、多くの言語の標準装備となった。

被害の性質は一貫している。user.getName() のような呼び出しで user がnullだと、Javaなら NullPointerException、C/C++なら未定義動作やセグメンテーション違反になる。厄介なのは、この誤りが型の上では完全に正しく見える点だ。user の型はきちんと「ユーザー」であり、コンパイラは通す。破綻は実行時、しばしば本番環境で初めて露見する。

今への影響と教訓：不在を型で表す設計へ

Hoareが本来望んだ「不在を型で分離する」道は、後の言語で本流になった。系譜はおおむね次の通りである。

• ML／Haskell（1970〜90年代）：Option（MLでは option）／Maybe 型が登場。値は Some x／Just x（あり）か None／Nothing（なし）のいずれか。「なし」を扱わないコードはコンパイルが通らず、検査漏れが型レベルで防がれる。
• Kotlin／Swift（2010年代）：型そのものに「null許容」を刻む。Kotlinでは String はnull不可、String? のみnull可。null可の値は安全呼び出し ?. や非null表明 !! を通さねば使えず、null安全（null safety）がコンパイラに強制される。SwiftのOptional（String?／if let によるアンラップ）も同思想だ。
• C#：後付けで nullable 参照型を導入し、string（非null想定）と string? を区別してnull由来の警告を出せるようにした。
• Rust：言語からnullを排除した。不在は標準ライブラリの Option<T>（Some／None）で表し、参照は常に有効。ヌルポインタ参照というクラス自体を型システムで消し去った点で、Hoareの理想に最も近い。

これらに共通する原則は明確だ。「不在という状態を、値のふりをさせず、型として第一級で表現する」。そうすればコンパイラが「不在の可能性を処理したか」を検査でき、null参照の害の本質——検査漏れが実行時まで隠れること——が根本から絶たれる。

型システムがなぜこうした保証を与えられるのかはプログラミングの型に関する解説を、堅牢なソフトウェアを支える基盤の考え方は開発運用（DevOps）を参照するとよい。

一段で言うと

nullは、不在という状態を「値のふり」で安く済ませた一手だった。手軽さと引き換えに、全ての参照へ「本当に値はあるか」という疑いを持ち込み、その検査漏れをコンパイラから隠した。だからHoareはそれを10億ドルの誤りと呼び、後の言語は不在を型で表すことでこの誤りを設計から締め出していった。教訓は普遍的だ——曖昧な状態は、別の値で兼ねず、型で語らせよ。