1. Therac-25 放射線事故（1985-1987年）
放射線治療装置Therac-25のソフトウェアバグにより、患者に致死量の放射線が照射される事故が複数回発生した。レースコンディション（競合状態）が原因で、少なくとも6人が過剰照射を受け、3人が死亡した。
ハードウェアの物理的なインターロックを外し、ソフトウェアだけで安全性を担保しようとした設計が悲劇を生んだ。
教訓：ソフトウェアの安全性はハードウェアのフェイルセーフに依存してはならない、というよりもむしろ、ハードウェアとソフトウェアの多層防御が必要だということ。人命に関わるシステムの検証は徹底すべきだ。
2. アリアン5ロケットの爆発（1996年）
欧州宇宙機関（ESA）のアリアン5ロケットは、打ち上げ37秒後に爆発した。原因は、64ビット浮動小数点数を16ビット整数に変換する際のオーバーフロー。
この変換処理はアリアン4から流用されたもので、アリアン5の高速な飛行パラメータには対応していなかった。損失額は約5億ドルに達し、欧州の宇宙開発に深い傷を残した。
教訓：コードの再利用には、新しい環境での動作検証が不可欠。型の安全性は命に関わる。仕様書に「前提条件」を明示的に残すことの重要性を示した古典的な事例だ。
3. Mars Climate Orbiter の墜落（1999年）
NASAの火星探査機Mars Climate Orbiterは、ヤード・ポンド法とメートル法の変換ミスにより火星の大気圏に突入して消失した。
ロッキード・マーティンがポンド力秒で計算した推力データを、NASAがニュートン秒として処理した。3億2,800万ドルの損失。
教訓：インターフェースの仕様を明確に文書化し、単位の不一致を自動検出する仕組みを導入すべきだ。現代のプログラミング言語における型システムや単位付きの数値型（units-of-measure）の発想は、こうした事故への応答でもある。
4. Y2K（2000年問題）
西暦2000年を迎える際、年を2桁で管理していたシステムが「00」を1900年と誤認識する問題。世界中で推定3,000億ドル以上の対策費用が投じられた。
大規模な障害は結果的に発生しなかったが、その背景には膨大な修正工数と、世界中のCOBOLプログラマーの再動員があった。
教訓：短期的な最適化（メモリ節約のための2桁年）が、長期的に巨大なコストを生む。設計時にスケーラビリティを考慮すべきだ。同じ構造の問題は、2038年問題（UNIX時刻の32ビット整数限界）として再来する。
5. ナイトキャピタルの45分間4.6億ドル損失（2012年）
米国の高頻度取引会社ナイトキャピタルは、ソフトウェアのデプロイミスにより、45分間で4億6,000万ドルの損失を出した。
古いテストコードが本番環境で実行され、意図しない大量の取引が発生した。8台のサーバーのうち1台でデプロイ手順を誤った、というほぼヒューマンエラーに近い失敗が、会社を事実上の破綻に追い込んだ。
教訓：デプロイプロセスの自動化と、ロールバック手順の整備が不可欠。テストコードが本番に混入しない仕組みを。Feature flagやカナリアデプロイが業界標準となった転機でもある。
6. Heartbleed（2014年）
OpenSSLの深刻な脆弱性Heartbleedは、TLSのハートビート機能の実装バグが原因だった。バッファの境界チェックが欠落しており、サーバーのメモリ内容（パスワード、秘密鍵を含む）が漏洩する可能性があった。全世界のWebサーバーの約17%が影響を受けた。
教訓：セキュリティクリティカルなコードには厳密なコードレビューと自動テストを。オープンソースの重要インフラには十分なリソースを。この事件後、Linux Foundationの「Core Infrastructure Initiative」など、OSSの資金支援の枠組みが整備された。
7. Cloudflareの大規模障害（2019年）
Cloudflareの正規表現ルールのデプロイにより、全世界のCDNが約30分間ダウン。「.*.*=.*」という正規表現が、バックトラッキングによりCPU使用率100%を引き起こした。
教訓：正規表現の計算量爆発（ReDoS）に注意。カナリアデプロイやステージドロールアウトの重要性を再認識する事例だ。同社はこの事件の後、ポストモーテムを詳細公開し、業界の模範となった。
8. 東京証券取引所のシステム障害（2020年）
2020年10月1日、東京証券取引所のarrowheadシステムが終日停止した。共有ディスク装置の故障時にバックアップへの切り替え（フェイルオーバー）が正常に作動しなかったことが原因。
一日の売買機会が丸ごと失われ、日本の資本市場のレピュテーションにも影響を与えた。
教訓：フェイルオーバーの動作は、定期的に本番に近い環境でテストすべき。冗長構成は「設定しただけ」では不十分。カオスエンジニアリングの必要性を象徴する事例でもある。
9. Log4Shell（2021年）
Javaの広く使われたログライブラリLog4jにリモートコード実行の脆弱性が発見され、世界中のサーバーが影響を受けた。JNDI Lookupの入力値を適切にサニタイズしていなかったことが原因。
教訓：依存ライブラリの脆弱性は自社のリスク。SBOM（Software Bill of Materials）による依存関係の管理が重要だ。米国では大統領令でSBOMの導入が義務化される契機にもなった。
10. CrowdStrikeのブルースクリーン障害（2024年）
セキュリティ企業CrowdStrikeのFalconセンサーアップデートにより、世界中のWindows PCがブルースクリーンでクラッシュ。航空会社、病院、銀行など社会インフラに大きな影響を与えた。
教訓：カーネルレベルで動作するソフトウェアのアップデートには、より慎重なテストとロールアウト戦略が必要。単一障害点の排除を。
10件を貫くパターン——バグの「家系図」
10件の事例を並べると、発生の構造に共通パターンがあることに気づく。
| パターン | 代表事例 | 現代の対策 |
|---|---|---|
| 型・単位の取り違え | アリアン5、Mars Orbiter | 強い型システム・契約ベースの設計 |
| コードの再利用ミス | アリアン5、ナイトキャピタル | CI/CDと不変なアーティファクト |
| 境界・入力検証の欠落 | Heartbleed、Log4Shell | 静的解析・ファジング・SBOM |
| フェイルオーバーの未検証 | 東証、Cloudflare | カオスエンジニアリング |
| デプロイ時のヒューマンエラー | ナイトキャピタル、CrowdStrike | 段階的ロールアウト・自動ロールバック |
興味深いのは、これらの「現代の対策」のほとんどが、各事件のポストモーテムから生まれている点だ。業界のプラクティスは、失敗を共有する文化の上に成立している。
バグは避けられない。だからこそ
バグを完全に防ぐことは不可能だ。しかし、過去のバグから学ぶことで、同じ失敗を繰り返すリスクは大幅に減らせる。
型安全性、コードレビュー、自動テスト、カナリアデプロイ、フェイルオーバーテスト、SBOM。これらは「面倒な作業」ではなく、歴史が教えてくれた「保険」だ。
AIが生成するコードの比率が増える時代にこそ、この保険の価値はむしろ高まる。人間がレビューしきれない量のコードが本番に流れ込むということは、過去のバグパターンが再び顔を出すリスクも同時に拡大するということだ。
あなたのコードベースには、十分な保険がかけられているだろうか。
## 関連記事 - [テック企業エイプリルフール伝説——Googleが本気で世界を騙した20年の歴史](/articles/10000355) - [宇宙で使われているプログラミング言語は何か](/articles/10000369) - [なぜキーボードはQWERTY配列なのか？——150年続く「非効率」の歴史](/articles/10000263)
