「ウォレット／鍵の侵害」と「スマートコントラクトの脆弱性」は似ているように聞こえますが、実際には何が違うのですか？
違いは攻撃が力を加える箇所にある。スマートコントラクトの脆弱性は、攻撃者がコードのロジックそのものに欠陥を見つけ、設計者が想定していなかった動作をコントラクトに行わせるものであり、理論上は監査が最も得意とするはずのカテゴリーの問題である。ウォレット／鍵の侵害が狙うのは全く別の層である——鍵の生成、保管、署名プロセス、そしてプロトコルがデータの真偽を検証するために依拠する基盤（オラクルやクロスチェーン検証ネットワークなど）である。これらの部分は、コード自体が完全に正しくても突破されうる。なぜなら問題はそもそもコードのロジックにあるのではなく、コードが「信頼」している外部入力が信頼できるかどうかにあるからだ。CertiKがこの2つを分けて統計を取っているのは、まさにこれらが異なる防御手段を必要とする2種類のリスクだからである。
Kelp DAOとDrift Protocolの2つの事件がこれほど近い間隔で発生したのは、偶然ですか、それとも共通の原因があるのですか？
タイミングという点では偶然である（両方とも2026年4月に発生した）が、攻撃のロジックという点では偶然ではなく、同じ業界トレンドの2つの独立した表れである。両事件の共通点は、コントラクトコード自体はどちらも既に監査を通過しており、設計通りに完全に実行されていたこと、そして脆弱性は監査が従来あまり踏み込んで検証してこなかった部分にあったこと（Kelp DAOは外部検証機構、Drift Protocolはガバナンス機能）である。これは攻撃者という集団が、「コードにバグがあるかどうか」から「このプロトコルの信頼の前提はどこに置かれており、どこが最も脆弱か」へと、組織的に関心を移しつつあることを反映している。この2つの事件がほぼ同時に発生したことは、ある程度、これがすでに攻撃者コミュニティの中で比較的成熟し広く認識された攻撃の考え方であり、単一のチームによる独立した発見ではないことを示唆している。
CertiKのような権威ある機関が行った監査でさえ守り切れないとしたら、それは監査業界自体に問題があるということですか？
ここで整理しておくべき紛らわしい点がある。Kelp DAOとDrift Protocolの両事件において、問題が発生した部分はどちらも監査チームが実際に検証した範囲内にはなかった——言い換えれば、監査チームが「検証したが見逃した」のではなく、これらの部分は「そもそも今回の監査の委託範囲に最初から含まれていなかった」ということである。これはむしろ委託範囲の設定の問題であり、監査の実行品質の問題ではない。本当に検討されるべきなのは、監査チームが職務を尽くしたかどうかではなく、業界が「監査」という言葉に対して抱く理解と期待が、「今回の監査が具体的に何をカバーしていたか」をより正確に区別すべきかどうか、そして監査をあらゆるリスクをカバーする万能の保証として扱うべきではないという点かもしれない。
この記事のデータは、一般的な個人投資家にとって実際どう活用すべきですか？
最も直接的な活用法は、判断の優先順位を調整することである。「このプロトコルは監査を受けているか」だけを問うのではなく、監査報告書の範囲要約を具体的に確認し、特にプロトコルが単一のオラクル、単一の検証者、または単一のマルチシグ署名グループに大きく依存していないかに注意を払うべきである——これらはまさに近年の損失が最も集中している突破口である。もしプロトコルの公開情報の中にガバナンス機構、鍵管理プロセス、クロスチェーン検証方式についての説明が全く見当たらない場合、それ自体が注意すべき警告サインである——それが必ずしもそのプロトコルが安全でないことを意味するからではなく、監査がカバーしていない部分のリスクがどれほど大きいかを判断するための十分な情報がないことを意味するからだ。資金を複数のプロトコルに分散させ、単一の依存点を持つプロトコルに大きなポジションを集中させないことも、このデータが示す実践的な示唆の一つである。
「このプロジェクトは監査を受けているから安全なはずだ」というのは、暗号資産業界で最もよく聞かれる安心の呪文の一つである。しかしブロックチェーンセキュリティ企業CertiKが発表した2026年上半期（H1 2026）のHack3Dレポートによれば、この呪文は今年上半期、現実によって繰り返し裏切られた。この記事が試みたいのは、「監査は絶対的な安全を保証できない」というすでに使い古された決まり文句を繰り返すことではなく、監査が本来持つべき保護力を失うとき、問題は具体的にどの部分にあるのか、そしてこの部分が近年どのように攻撃者に組織的に狙われているのかを具体的に解きほぐすことである。
CertiKのH1 2026レポートによれば、Web3業界全体が2026年上半期にセキュリティ事件で被った損失は13.1億ドルを超え、344件の事件にまたがっている。事件件数だけを見れば、「コードの脆弱性」（code vulnerability）は依然として最も一般的な攻撃タイプで合計204件だが、この種の事件による損失は約1億5,200万ドルにとどまり、1件あたりの平均額は特別大きいわけではない。真に壊滅的な損失をもたらしたのは「ウォレット／鍵の侵害」（wallet compromise）である——わずか33件の事件で4億4,400万ドルを超える損失が発生し、1件あたりの平均額は1,300万ドルを超え、年間を通じて損失額が最も大きい単一の攻撃カテゴリーとなった。言い換えれば、2026年上半期のセキュリティの構図は明確に逆転している。攻撃者はもはやコードの粗を探すことに主力を置いておらず、人、鍵管理プロセス、署名インフラを突破することに主力を移している。
2026年4月、DeFiイールドプロトコルのKelp DAOのクロスチェーンブリッジコントラクトが攻撃を受け、約2億9,100万ドルの損失が発生した。この事例が特に解剖する価値がある点は、ブリッジコントラクトとrsETHコントラクトが以前に2回独立した監査を受けており、コード自体は設計通りに完全に実行され、ロジックエラーは一切発生していなかったことである。攻撃者が実際に利用したのは、プロトコルが依拠する分散型検証者ネットワーク（DVN）のフェイルオーバー機構だった。この検証プロセスを操作することで、コントラクトに偽造されたクロスチェーン取引データを本物だと誤認させ、コントラクトはこの汚染されたデータに基づいて完全に「正常に」動作した結果、116,500枚のrsETHが引き出し尽くされた。この事件は、監査が何を証明でき、何を証明できないかを的確に示している。監査が証明するのは「このコードが設計通りに書かれている」ということであり、「このコードが依拠する外部の検証機構自体が信頼できるかどうか」までは証明できない——後者は通常、1回の合約監査の範囲を超えている。
ほぼ同時期、パーペチュアル取引プロトコルのDrift Protocolが2026年4月1日に攻撃を受け、約2億8,500万ドルの損失が発生した。この事件のコントラクトコードも同様に監査を受けていたが、脆弱性は通常監査範囲に含まれないガバナンス機能にあり、攻撃者はこの十分に監査されていなかった部分を利用してインサイダー型の攻撃を仕掛けた。わずか数週間の間に発生したこの2つの事件は、合わせて2026年第2四半期の損失総額の7割以上を占め、CertiKのレポートでも、損失が少数の大規模事件に集中していることは、攻撃者の関心がスマートコントラクトのコード自体ではなく鍵管理インフラへと意図的にシフトしていることを反映していると直接指摘されている。
2014年から2024年までの世界最大級のセキュリティ損失事件トップ100を対象とした別の研究も、このパターンをさらに裏付けている。総額約107.7億ドルの損失のうち、監査済みのアプリケーションが占める損失総額の割合はわずか10.8%だったが、同時期に悪用されたアプリケーションのうち専門的な監査を受けたことがあったのはわずか20%だった。この2つの数字を合わせて読んでも矛盾はない——両者は共に、監査が「ある特定の種類」のリスク（コードレベルのロジックエラー）を確かに効果的に低減できる一方で、監査範囲外のリスク（ガバナンス、鍵管理、外部依存関係、運用プロセス）に対してはほとんど発言力を持たないこと、そして攻撃者が組織的に火力を後者に集中させつつあることを示している。
もしあなたがある特定のプロトコルに資金を投じるかどうかを判断する利用者であるなら、「監査を受けているかどうか」という問い自体はもはや十分ではない。より参考になる問いは次のようなものである。この監査の範囲は具体的にどのコントラクトと機能をカバーしていたか（ガバナンス機構は含まれていたか）、監査報告書の公開以降プロトコルはコードを更新したか（更新された部分は最新の監査でカバーされていないのと同じである）、プロトコルは単一の検証者や単一のオラクルを重要なデータソースとして依存していないか（まさにKelp DAOの事例における抜け穴だった）、そしてプロトコルは監査以外に継続的な監視やバグバウンティ制度を事後の防御線として備えているか。監査を健康診断報告書として理解すること——それが証明するのは特定の時点、特定の範囲内で既知の問題がなかったということであり、そのプロトコルが以後永遠に安全であるということではない。攻撃者はすでに監査がカバーしていない部分がどこかを明確に把握している。利用者の判断ロジックも、それに合わせて更新される必要がある。