なぜThe DAO事件は、単なる普通のハッキング事件ではなく、スマートコントラクトセキュリティ産業全体の出発点とみなされているのですか？
それが、スマートコントラクトが一度デプロイされると、コードに含まれるいかなる誤りも取り返しがつかなくなりうるという特性がどれほど危険であるかを、業界全体に初めて認識させた公開の事件だったからであり、しかも損失規模と影響範囲が無視できないほど大きかったからだ。それは資金の損失をもたらしただけでなく、イーサリアムコミュニティにとって前例のないガバナンス危機とチェーンの分裂を直接引き起こした。それ以前、スマートコントラクトのセキュリティはどちらかといえば理論上の議論にすぎなかった。この事件以降になって初めて、コード監査、形式検証、標準セキュリティライブラリの開発が、業界全体によって本当に必須の要件としてリソースを投じるべきものとみなされるようになった。
「コードこそが法である」という立場とハードフォークを支持する立場のこの議論は、今でも意味があるのですか？
ある。そしてこの議論の枠組みは今なお多くの新しい論争に当てはめられている——大規模なハッキング事件が発生し、コミュニティが資産を凍結すべきか、資金の回収を支援すべきかを議論するたびに、本質的には同じ問いに改めて向き合っていることになる。ブロックチェーンの不可変性は、いかなる例外もない絶対的な原則なのだろうか、という問いだ。The DAO事件が重要なのは、この哲学的な問いを初めて抽象的な議論から、数万人の利用者に影響を及ぼす実在する具体的な決断へと変えたからであり、しかもその決断には標準的な答えがなく、コミュニティが投票と行動によって下した選択があるだけだったからだ。この歴史を理解することは、読者がその後の類似の事件において「介入すべきかどうか」が常に論争を呼び、簡単な答えのない問題であり続ける理由をより明確に理解する助けとなる。
リエントランシー攻撃への対策手法が既に成熟しており、業界も知っているのであれば、なぜ2026年になってもSolv Protocolのような事例が発生するのですか？
これこそがこの事例を議論する価値がある点である——問題はしばしば「開発者がこの脆弱性を知らない」ことではなく、「防御策がプロトコルのあらゆる隅々まで完全に適用されていない」ことにある。多くの新しいプロトコルは開発時に大量のサードパーティのコードライブラリを統合したり、既存の基盤コントラクトのアーキテクチャを継承したりする。これらの外部コードが正しくリエントランシー対策を実装しているかどうかを、統合の際に全てのチームが1行ずつ再確認するわけではない。さらに市場競争のプレッシャーの下、プロトコルはしばしば時間的制約の中でローンチする必要があり、監査の深さとカバー範囲が圧縮されうる。これは技術自体の難易度の問題ではなく、プロセスとリソース配分におけるトレードオフを反映している——どう防ぐかを知っていることと、あらゆる箇所で実際に確実に実施されていることの間には、依然として実行上のギャップが存在するのである。
リエントランシー攻撃の完全な歴史を理解した上で、一般利用者は具体的にプロトコルが安全かどうかを判断する方法をどう調整すべきですか？
最も直接的な調整は、「この脆弱性は古いものであり、業界はもう理解しているはずだ」ということを警戒を緩める理由にしないことである。この記事が示している通り、古いことは根絶されたことを意味せず、それが単に最も主要な脅威の源ではなくなったことを意味するにすぎない。具体的に確認できることには、プロトコルの監査報告書がリエントランシー攻撃に対するテストを明確に実施したと言及しているか（reentrancyやchecks-effects-interactionsといったキーワードで検索できる）、プロトコルが独自実装ではなく業界標準の防御ライブラリを採用しているか、そしてプロトコルの核心コントラクトが新規開発されたものか、他のプロジェクトのコードベースを継承したものか（継承された部分も今回の監査範囲に含まれているかは、特に問う価値のある点である）が含まれる。この10年の歴史を理解することの価値は、攻撃原理の技術的な詳細を暗記することにあるのではなく、「とうに解決されているはずの」問題に対して常に「今回は本当に解決されているのか」ともう一言問う習慣を身につけることにある。
もしスマートコントラクトセキュリティ産業全体の出発点となる事件を1つ選ぶとしたら、業界関係者の多くは2016年のThe DAO事件を選ぶだろう。それはその規模（当時の価値で約6,000万ドル相当のイーサが盗まれた）だけが理由ではなく、今なお繰り返し検証され続けている結論を残したからだ——10年前のあの事故を引き起こしたコードのロジック上の欠陥は、2026年の今日でも新しいプロトコルに実際の金銭的な代償を払わせ続けている。この記事が試みるのは、この10年間の軌跡を完全に広げて見せることである。事故自体がどのように起きたのか、それがイーサリアムをどう変えたのか、そしてなぜ同じ脆弱性が今なお完全に根絶されていないのかを。
The DAOは2016年にローンチされた分散型ベンチャーファンドで、当時のブロックチェーンクラウドファンディング記録を樹立した調達額を集めていた。その引き出し関数には論理的な欠陥があった。コントラクトが引き出し者にイーサを送金すると同時に、引き出し者のアドレス上のコードの実行をトリガーしていたが、コントラクトは送金が完了した「後」になってようやく内部帳簿を更新し、その資金が引き出し済みであると記録していた。攻撃者が利用したのはまさにこの時間差だった。悪意あるコントラクトで送金を受け取り、コントラクトがまだ記帳する前の一瞬に、直ちに同じ引き出し関数を再び呼び出す。この時点で帳簿はまだ「未引き出し」を示していたため、資金は再び送金され、これが数十回再帰的に繰り返され、資金プールが枯渇するまで続いた。攻撃全体は1つの取引の中で発生し、わずか数分しかかからなかった。
事故発生後、イーサリアムコミュニティは今なお引用され議論される路線対立に陥った。ハードフォークを通じて、盗まれた資金を強制的に元の保有者に「返還」すべきかどうかである。フォークを支持する側は、ブロックチェーンの存在意義は全参加者の権益を犠牲にすることの上に成り立ってはならないと主張した。フォークに反対する側は、「コードこそが法である（code is law）」がブロックチェーンの譲れない核心原則であり、結果が気に入らないからといって集団の力を使って歴史を書き換えることは、不可変性そのものを否定することになると主張した。最終的に、大多数のマイナーと開発者はハードフォークの実行を選択し、今日私たちが呼ぶイーサリアム（ETH）が誕生した。フォークを拒否し、元のチェーンの履歴を貫いた少数のコミュニティは、イーサリアムクラシック（ETC）として存続した。この分裂は今なお、暗号資産のガバナンス史において最も頻繁に引用される事例の一つである——それは純粋に技術的な脆弱性が、最終的に「不可変性に例外があるかどうか」をめぐる哲学的な議論へと発展しうることを証明した。
損失の割合だけを見れば、リエントランシー攻撃には確かに明確な長期的改善傾向が見られる。ブロックチェーンセキュリティ企業Immunefiの6年間のDeFi損失データを対象とした調査によれば、エコシステムレベルの攻撃（フラッシュローンによる価格操作やリエントランシー攻撃を含む）は、DeFi総損失に占める割合が2022年の約19%から2025年には1%未満にまで低下した。この低下は業界の防御手段の成熟を大きく反映している——「チェック・エフェクト・インタラクション」パターンやリエントランシーガードといった標準的な防御策は、今や主流の開発フレームワークや監査チェックリストにおける基本項目となっており、静的解析ツールもこの種の論理的欠陥を比較的容易に検出できるようになっている。
しかし割合の低下は脆弱性が消えたことを意味しない。2026年1月、ビットコインイールドプロトコルのSolv Protocol傘下のあるボールトが、依然としてリエントランシー二重鋳造の脆弱性によって攻撃を受けた。攻撃者は鋳造操作を22回繰り返し実行し、135枚の合法的なトークンを何もないところから約5億6,700万枚の偽造トークンへと変換し、約270万ドル相当の資産に交換した。研究者たちは一様に、この種の事故が今なお発生する理由は、開発者がこの脆弱性パターンを知らないからではなく、プロトコルが時間的なプレッシャーの下で十分に監査されていない基盤コントラクトを継承したり、サードパーティのコードライブラリを統合する際にこれらの標準的な防御策が正しく適用されているかを再確認しなかったりすることにあると指摘している。
一般利用者にとって、リエントランシー攻撃のこの10年の歴史がもたらす実践的な教訓は、「この脆弱性は珍しくなったので安心できる」ということではなく、「この脆弱性の全体的な割合の低下は、攻撃者の関心の移動を反映しているのであって、この攻撃手法自体が淘汰されたことを意味するわけではない」ということである。近年最大規模の損失を出した事故、例えばブリッジ検証ロジックやガバナンス権限に関わる攻撃は、確かに単純なリエントランシーの脆弱性を上回るようになっている。しかしこれはリエントランシー攻撃が既に舞台から退場したことを意味しない。むしろそれは「トップの戦場」から、「依然として存在し、依然として発動されうるが、もはや攻撃者の第一選択ではない」背景リスクへと後退したと言える方が近い。新しく立ち上げられ、監査が十分徹底されていないプロトコルにとって、それは依然としていつでも起爆しうる旧式の罠なのである。あるプロトコルが信頼に値するかを判断する際には、監査報告書がリエントランシーのテストをカバーしているかを確認することに加え、そのプロトコルの基盤となっているコードベース自体が十分に検証されているかにも注意を払う価値がある。なぜなら10年前の教訓が証明しているのは、問題はしばしば新しく書かれたロジックの中にあるのではなく、当たり前だと見なされ、誰も再確認しなかった古いコードの中に潜んでいるということだからである。