インフラ攻撃(Infrastructure Attacks)とコードの脆弱性(Code Exploits)は、異なる2つのセキュリティリスクのカテゴリーだ。前者は秘密鍵管理、マルチシグの署名フロー、フロントエンドドメインなど、コントラクトの外側にある支援システムを狙う。後者はスマートコントラクトのロジック自体の欠陥だ。両者の攻撃対象、防御ツール、追跡可能なシグナルはまったく異なる。
この区分が重要なのは、業界がこの10年間セキュリティ投資をコード監査に大きく偏らせてきた一方で、TRM Labsのデータは実際の巨額損失の源泉がインフラ層であることを示しているからだ。これはリソース配分と実際のリスク源との間に明確なミスマッチがあることを意味し、修正するためにはまず指摘される必要がある。
実際の数値を見ると、2025年のインフラ攻撃は45件で損失22億ドル(全体の76%、1件あたり平均4850万ドル)、コードの脆弱性は52件で損失3.5億ドル(12.1%、1件あたり平均670万ドル)、プロトコル攻撃は25件で損失2.77億ドル(9.6%、1件あたり平均1110万ドル)だった。最も発生件数が多いカテゴリーが最も損失が大きいカテゴリーではない。この逆転現象こそが重要なポイントだ。
読者にとっての実際的な意味は、プロトコルや取引所の安全性を評価する際、「監査を受けたかどうか」だけで判断を止めず、秘密鍵の管理方法、マルチシグの閾値、署名者は誰か、フロントエンドが乗っ取られたことはないかを問うべきだということだ。これらは監査報告書には現れないが、2025年に実際に巨額損失をもたらした場所であり、同等の注意を払う価値がある。
暗号資産に詳しい人に「最大のセキュリティリスクは何か」と尋ねれば、答えの多くはスマートコントラクトに集中するだろう。リエントランシー攻撃、フラッシュローンの悪用、監査で見逃されたエッジケース。この直感は根拠がないわけではなく、実際に過去数年、著名なコントラクト脆弱性事件がいくつも起きている。しかしTRM Labsが発表した『2026年暗号資産犯罪レポート』は、実際の数字を見ると異なる順位を示している。
2025年通年で、インフラ層攻撃(Infrastructure Attacks)による損失は22億ドルに達し、年間総損失の76%を占め、発生件数は45件、1件あたりの平均損失は4850万ドルにのぼった。一方でコードの脆弱性(Code Exploits)は発生件数こそ最多の52件だったが、損失額は3.5億ドル、全体の12.1%にとどまり、1件あたり平均670万ドルだった。プロトコル層攻撃(Protocol Attacks)は25件、損失2.77億ドル、全体の9.6%、1件あたり平均1110万ドルだった。つまり、コードの脆弱性は最も頻繁に発生するが、実際に資金の大半を持ち去っているのはインフラ攻撃であり、1件あたりの破壊力はコードの脆弱性の7倍以上ということになる。
コードの脆弱性とは、スマートコントラクトのロジック自体の欠陥を指す。これはまさに監査、形式検証、バグバウンティが捕捉するために設計された対象であり、業界がこの10年間で最も多くのリソースを投じて防御してきた領域だ。インフラ攻撃はまったく異なる。コントラクトのロジックを狙うのではなく、コントラクトの外側でシステム全体を支えている層——秘密鍵管理、マルチシグウォレットの署名フロー、フロントエンドのドメインとDNS、クラウドサービスアカウント、社内従業員のデバイスと権限、署名サーバー——を狙う。これらはスマートコントラクトのコードに書かれることはほとんどなく、監査報告書の対象にもならないが、近年攻撃者が最も頻繁に、そして最も成功裏に狙ってきた侵入経路だ。
このギャップが長く十分注目されてこなかった理由の一つは、「監査済み」という言葉自体が「安全」の代名詞になりやすいからだ。あるプロトコルが「3社の監査法人による監査を通過した」と発表すれば、それだけで安心感を与えるが、監査の範囲には秘密鍵の保管方法、社内従業員のデバイスセキュリティ、フロントエンドサーバーへのアクセス制御はほぼ含まれない。これがリソース配分のミスマッチを生む。プロトコルはセキュリティ予算の大半を監査とコードレビューに投じる一方、署名プロセスの衛生管理や内部権限管理といった「インフラの衛生状態」への投資は相対的に限られている——そしてそここそが、攻撃者が実際に突いてきた場所なのだ。
オンチェーンデータでリスクを判断する人にとって、これはあるプロトコルが「安全」かどうかを監査報告書の有無だけで判断できないことを意味する。いくつかのインフラ層のシグナルにも注意すべきだ。マルチシグの署名者が少数に過度に集中していないか、マルチシグの閾値設定が妥当か、チームが署名サーバーの隔離方法など内部セキュリティプロセスを公開しているか、フロントエンドのドメインに乗っ取りやフィッシングの履歴がないか。これらはコード監査報告書には現れないが、オンチェーンのマルチシグ取引履歴、ドメイン登録情報、過去のセキュリティインシデント開示などから間接的な手がかりを得られることが多い。「監査を通過した」ことをそのまま「安全」と同一視することこそ、このデータが正そうとしている認識のズレだ。