Pentium FDIVバグ：CPUの割り算が間違っていた

何が起きたか

横にスクロール

コンピュータのCPUが四則演算を間違える——普通なら考えにくいことが、1994年に現実に起きた。Intelが自信作として市場に投入した初代Pentiumが、ある特定の値の割り算で、正しい答えからわずかにずれた結果を返していたのだ。

きっかけは、素数の研究をしていた数学者Thomas Nicelyだった。双子素数にまつわる計算を続けるうち、彼はどうしても説明のつかない数値のずれに気づく。原因を切り分けていくと、行き着いたのは自分のプログラムでも計算方法でもなく、Pentiumそのものだった。Intelへ問い合わせても当初は明確な回答が得られず、1994年の終わりに彼がこの事実を公表すると、話は一気に広がった。

「割り算を間違えるCPU」という見出しは、当時立ち上がりつつあったインターネットと既存のメディアを通じて世界中を駆けめぐった。誤差そのものは微小で、多くのユーザーが日常的に踏むものではない。それでも、計算機の根幹である算術が信用できないという事実は、技術に詳しくない人々にも強い不安を与えた。当時のPentiumはIntelの旗艦であり、パーソナルコンピュータの高性能機へ広く採用されつつあった。誤りが指摘されたのがまさにその主力製品だったことも、騒動を大きくした一因である。

具体的には、次のような割り算で誤差が観測された。フェンス内の値は当時よく引用された例である。

4195835 / 3145727

正しい答え     : 1.333820449136...
欠陥のある結果 : 1.333739068902...

検算 x - (x / y) * y は本来 0 だが、
欠陥のあるPentiumでは 256 が返った

一見わずかな差だが、答えは5桁目あたりから静かに狂っていく。検算のつもりで行った引き算が0にならないことで、多くの技術者がこの欠陥に気づいた。膨大な回数の除算を重ねる用途ほど、小さなずれが積もって結果を蝕んでいく。

技術的な根本原因

問題は、除算を高速に行うためのアルゴリズムに潜んでいた。Pentiumの浮動小数点ユニットは、割り算にSRT法と呼ばれる方式を採用していた。SRT法は、商を一気に求めるのではなく、1回の繰り返しで商の複数ビットずつを確定させていく「桁ごとの繰り返し」型のアルゴリズムだ。これにより、素朴な方式より少ない回数で割り算を終えられる。

その核心にあるのが、次にどの商の桁を選ぶかを決めるルックアップテーブルである。各ステップで、途中の余り（部分剰余）と割る数のおおよその値を手がかりに、テーブルを引いて「次の商の桁」を予測する。この予測が正しければ、割り算は正確かつ高速に進む。SRT法は本来、多少の予測のずれなら次のステップの部分剰余で吸収し、あとから取り戻せる冗長さを備えている。だからこそ高速化が成り立つのだが、その前提はテーブルが正しく埋まっていることにある。

Pentiumの欠陥は、このテーブルの中身にあった。商を予測するためのセルのうち、わずかな数のエントリが値を持たず、空になっていたのだ（欠損したのは5個ほどとされることが多いが、正確な数の扱いには諸説ある）。テーブルを回路へ書き込む工程での取りこぼしが原因だったとされる。欠損セルを踏んだときだけは、SRT法本来の取り戻しが効かず、誤差が最終的な商にそのまま残ってしまう。

普段の割り算では、この空のセルを引き当てることはまずない。だからこそ長期間見逃された。しかし、特定のオペランドの組み合わせがちょうど欠損したセルを指すと、プロセッサは本来あるべき商の桁の代わりに誤った値を読み、その割り算の結果が下位の桁でずれる。日常のアプリケーションでは滅多に顕在化しないが、膨大な計算を積み重ねる科学技術計算では、無視できない実害になり得た。

浮動小数点がそもそもどのように数を表すのかは、IEEE 754の可視化で確かめられる。有限のビットで実数を近似するこの仕組みでは、末尾の桁のわずかな誤りが、後段の計算で思わぬ形に膨らむことがある。だからこそ、割り算という基本演算の正しさは、数値計算全体の信頼を支える前提になっている。

教訓

第一の教訓は、ハードウェアの検証には網羅的な難しさがあるということだ。テーブルの全セルを一つずつ確かめていれば、欠損は出荷前に見つかったはずだった。だが除算の入力の組み合わせは膨大で、通常のテストでは「たまたま欠損セルを踏む入力」に当たる確率は低い。この事件以降、業界は算術回路を数学的に証明する形式検証へ大きく舵を切った。テストで「バグが無いことの証拠」を集めるのではなく、設計が仕様どおりであることを証明するアプローチだ。

第二に、より高くついたのはリスクコミュニケーションの失敗だった。Intelは当初、この欠陥を「実用上ほぼ影響はない」と説明し、交換にも消極的な姿勢を取った。技術的には誤差の頻度が低いという主張に一定の根拠はあった。しかし、ユーザーが求めていたのは確率論ではなく、「自分のCPUは正しく計算するのか」という信頼だった。影響を軽視する説明は火に油を注ぎ、批判は日を追って拡大した。

最終的にIntelは方針を転換し、希望するユーザーへ無条件で交換に応じることを表明した。この対応にかかった引当は約4億7500万ドルにのぼったとされる。もし最初から誠実に影響を認め、交換に応じていれば、失う信頼も費用も小さく済んだ可能性が高い。

まとめ

Pentium FDIVバグは、たった数個のテーブルの欠損が、数億ドルの損失と「CPUは正しい」という信頼への傷につながった事件だ。技術的な核心はSRT除算のルックアップテーブルの欠損という一点にあり、教訓はハードウェア検証の網羅性と、ユーザー影響を軽視しないリスク対応という二点に集約される。物理に刻まれた誤りは後から直せない——だからこそ、出荷前の検証と、問題が起きたときの誠実な対応が決定的に重要になる。ほかの事例は工学の大惨事から、プログラミングの基礎はプログラミングから辿れる。