DeFiセキュリティガイド：AI時代におけるハッカー攻撃への効果的な防御法は？
TechFlow厳選深潮セレクト
DeFiセキュリティガイド：AI時代におけるハッカー攻撃への効果的な防御法は？
ハッカー攻撃は止まらない。AIがより賢くなるにつれて、攻撃も増加するばかりだ。
Web3業界の深掘り報道に専念し潮流を洞察執筆：sysls
翻訳：AididiaoJP、Foresight News
序論
多数のDeFiプロトコルに対するハッキング事件を調査する中で、「国家主体（State Actor）」という存在に強い恐怖を覚えました。彼らは高度な技術力と豊富なリソースを持ち、極めて長期的な視点で行動します。こうした「スーパーヴィラン」は、あなたのプロトコルおよびインフラストラクチャのあらゆる隅々までを丹念に検討し、脆弱性を探り出しますが、一方で一般のプロトコルチームは、6〜7もの異なる事業領域に注意を分散させざるを得ない状況にあります。
私はセキュリティの専門家を名乗るものではありませんが、軍隊や高額資金を扱う金融分野など、ハイリスクな環境においてチームを率いてきた経験があります。緊急事態への思考・計画には豊富な実績があります。
私は心から、「偏執的である者だけが生き残れる」と信じています。どのチームも初めから「セキュリティに対して無関心・いい加減な態度を取りたい」と考えているわけではありません。にもかかわらず、ハッキングは起こります。私たちは、より良い対応をしなければなりません。
AIは、今回が本当に「違う」ことを意味する
（出典：https://defillama.com/hacks）
ハッキングは珍しくありませんが、その発生頻度は明らかに増加しています。2026年第1四半期は、記録上もっとも多くのDeFiハッキングが発生した四半期であり、第2四半期はまだ始まったばかりですが、すでに前四半期の記録を更新する勢いです。
私の核心的な仮説は以下の通りです：AIによって脆弱性の探索コストが大幅に低下し、攻撃面（Attack Surface）が著しく拡大しました。人間が100のプロトコルの設定を精査して誤設定を発見するには数週間かかるところを、最新の基盤モデル（Foundation Model）であれば数時間で完了できます。
これは、私たちがハッキングについて考える方法および対応する方法を根本的に変えるべきことを意味します。AIの台頭以前のセキュリティ慣行に依存している従来型プロトコルは、次第に「一撃で倒される」リスクにさらされています。
表面（Surface）とレイヤー（Layer）による思考
（出典：https://defillama.com/hacks）
ハッキングの「表面積（Surface Area）」は、実際には以下の3つに集約されます：プロトコルチーム、スマートコントラクトおよびインフラストラクチャ、ユーザーの信頼境界（DSN、SNSなど）。
これらの表面を特定したら、防御レイヤーを重ねていきます：
- 予防（Prevention）：厳格に実施すれば、悪用される確率を最大限に低減できるプロセス。
- 緩和（Mitigation）：予防が失敗した場合に、被害の規模を制限する措置。
- 停止（Pause）：誰もが極度のストレス下では最善の判断ができません。攻撃が確認された時点で、即座に「総殺しスイッチ（Kill Switch）」を起動します。凍結により追加の損失を阻止し、冷静に考える余裕を確保します……
- 奪還（Reclaim）：有害または侵害されたコンポーネントの制御を失った場合、それらを放棄し、代替品に交換します。
- 復旧（Recovery）：失ったものを取り戻すための措置。資金の凍結・取引の取消・調査支援を行う機関パートナーとの連携体制を事前に整備しておきます。
原則
これらの原則は、各防御レイヤーにおける具体的な行動を導く指針です。
最先端AIを積極的に活用する
コードベースおよび設定を脆弱性からスキャンしたり、広範囲の表面に対してレッドチームテスト（攻撃模擬）を実施したりするために、最先端のAIモデルを積極的に活用してください。フロントエンドの脆弱性を探索し、それがバックエンドへと波及するかどうかを検証することも重要です。攻撃者はそうします。あなたが防御的スキャンで発見できたとしても、攻撃者の攻撃的スキャンはすでにそれを発見済みかもしれません。
pashov、nemesisなどのスキル、およびCantina (Apex) やZellic (V12) などのAIプラットフォームを活用し、正式な監査を依頼する前にコードベースを迅速にスキャンしてください。
時間と摩擦は優れた防御手段である
損害を引き起こす可能性のある操作には、複数段階のプロセスおよびタイムロック（時間遅延）を導入してください。異常を検知した際に介入・凍結できる十分な時間を確保する必要があります。
過去には、タイムロックや多段階設定がプロトコルチームに「摩擦」をもたらすという理由で反対されてきました。しかし今では、その懸念は軽減されます。AIがバックグラウンドで容易にこれらの「摩擦」を処理できるからです。
不変条件（Invariant）
スマートコントラクトは、不変の「事実」を明文化することで防御的設計が可能です。これらの事実が破られた場合、プロトコル全体のロジックが崩壊します。
通常、不変条件はごく少数しかありません。これらをコードレベルに持ち上げる際には慎重になりましょう。各関数内で複数の不変条件を強制すると、管理が困難になります。
権力のバランス
多くのハッキングは、侵害されたウォレットから発生します。マルチシグが侵害された場合でも、被害を素早く抑制し、プロトコルをガバナンスが意思決定可能な状態へと復元できる構成が必要です。
これは、「ガバナンス（すべてを決定する権限）」と「救済（ガバナンスの安定性を回復する能力だが、ガバナンス自体を置き換えたり否定したりすることはできない）」の間のバランスを取ることを意味します。
必ず問題が発生する
最初からこう想定すべきです：たとえあなたがどれほど優秀であっても、ハッキングを受けるでしょう。あなたのスマートコントラクトや依存モジュールが機能不全に陥るかもしれません。ソーシャルエンジニアリング攻撃を受けるかもしれません。新規アップグレードによって予期せぬ脆弱性が導入されるかもしれません。
こう考えれば、被害の拡大を制限するレートリミット（制限）や、プロトコルを停止するブレーカー（断路器）が、あなたの最も頼れる味方となります。被害を5〜10％以内に抑え、その後凍結し、対応策を計画しましょう。誰もが銃弾の雨の中では最善の判断ができません。
最良の準備時期は今です
ハッキングを受ける前に、既にその対応策を考えておく必要があります。可能な限りプロセスをコード化し、チームで訓練を重ねておけば、衝撃が訪れた際にパニックに陥ることはありません。AI時代においては、大量の情報を可能な限り速く提示するスキルとアルゴリズムを備え、その内容をサマリー形式および詳細形式でコアメンバーに共有できるようにすることが求められます。
完璧である必要はありません。ただ、生き残る必要があります。システムが初日から堅牢であることは決してありません。繰り返しの改善を通じて、学びから「反脆弱性（Antifragility）」を獲得していくのです。
ハッキングされていないという「証拠」は、ハッキングされないという「保証」にはなりません。最大の安心感が、往々にして最大の危険地点なのです。
予防措置
スマートコントラクト設計
不変条件を特定したら、それを実行時チェックとしてコード化してください。実際に強制する価値がある不変条件を、慎重に選別しましょう。
これはFREI-PI（Function Requirements, Effects, Interactions, Protocol Invariants）パターンです：価値に関係するすべての関数の終了時に、その関数が維持することを約束した「王冠不変条件（Crown Invariant）」を再検証します。CEI（Checks-Effects-Interactions）パターンを通過したドレイン攻撃（フラッシュローン・サンドイッチ、オラクル支援清算によるgrief攻撃、クロスファンクションでの支払不能によるドレイン）の多くは、関数終了時の不変条件チェックによって検出可能です。
優れたテスト
ステートフル・ファジング（Stateful Fuzzing）は、プロトコルの公開インターフェース全体に対してランダムな呼び出しシーケンスを生成し、各ステップで不変条件をアサーション（検証）します。本番環境で発生する脆弱性の多くは、複数のトランザクションにまたがるものです。ステートフル・ファジングは、攻撃者よりも先にこうした攻撃パスを発見できる、ほぼ唯一の信頼できる手法です。
不変条件テストを用いて、ファザーが生成可能なすべての呼び出しシーケンスにおいてその特性が成立することをアサーションします。形式検証（Formal Verification）を併用すれば、すべての到達可能な状態においてその特性が成立することを証明できます。「王冠不変条件」は、必ずこの処理を受けるべきです。
オラクルおよび依存モジュール
複雑さはセキュリティの大敵です。外部依存モジュールを1つ追加するごとに、攻撃面は拡大します。もしプリミティブを設計する立場にあるなら、ユーザー自身に「誰を信頼するか」「何を信頼するか」の選択権を与えてください。依存モジュールを排除できない場合は、それを多様化し、単一障害点（Single Point of Failure）がプロトコル全体を破滅させることのないよう配慮してください。
監査範囲を、オラクルおよび依存モジュールが故障するシナリオのシミュレーションまで拡大し、それらが故障した場合に発生しうる災害の規模にレートリミットを適用してください。
最近のKelpDAOの脆弱性がその一例です：彼らはLayerZeroのデフォルト設定であるrequiredDVNCount=1を継承しており、この設定は監査範囲外でした。最終的に攻撃されたのは、監査範囲外のオフチェーンインフラストラクチャでした。
表面攻撃
DeFiにおけるほとんどの表面攻撃は、すでにリストアップされています。各カテゴリを順に確認し、「この攻撃は我がプロトコルにも適用可能か？」と問いかけ、該当する攻撃ベクトルに対して適切な制御措置を講じてください。レッドチームスキルを育成し、AIエージェントに自社プロトコル内での脆弱性探索を積極的に指示しましょう。これは現在では必須要件です。
ネイティブな救済能力の保持
投票ベースのガバナンスでは、権力は当初チームのマルチシグに集中しており、時間が経過して初めて分散します。トークンの流通が広範囲に及んでいたとしても、委任（Delegation）はしばしば少数のウォレット（時にはn=1）に権威を集中させます。こうしたウォレットが攻撃された時点で、ゲームは終了します。
「ガーディアンウォレット（Guardian Wallet）」を展開し、その権限を極めて狭く限定してください：それはプロトコルの一時停止のみを許可し、かつ>=4/7の閾値で、極端な状況下において侵害された委任先を事前に定義された代替ウォレットへとローテーションすることができます。ただしガーディアンは、ガバナンス提案の実行を一切許可されません。
これにより、ガバナンスを覆す権限を持たずに、常に「ガバナンス可能な安定性」を回復できる救済レイヤーを確保できます。>=4/7のガーディアンを同時に失うという最悪のケースの発生確率は極めて低く（所有者層の多様性を考慮すれば）、ガバナンスが成熟・分散した後には、このレイヤーを段階的に廃止することも可能です。
ウォレットおよび鍵のトポロジー
マルチシグウォレットは必須要件であり、最低でも4/7の構成です。7つの鍵を1人が全て掌握してはいけません。署名者は頻繁にローテーションし、かつ静かに行う必要があります。
鍵は、日常的に使用されるデバイスとは一切接触させてはいけません。署名専用デバイスでインターネットを閲覧したり、メールを送受信したり、Slackを開いたりする行為があれば、その署名者はすでに侵害されているとみなすべきです。
用途別に複数のマルチシグを保有してください。少なくとも1つの完全なマルチシグが侵害される可能性を前提として計画を立てます。極端な状況（拉致、拷問など）においてさえ、単独の人物がプロトコルを侵害できるような権限を付与してはいけません。
バウンティ（報奨金）の検討
資源があるならば、プロトコルのTVL（Total Value Locked）に比例した高額の脆弱性報奨金を設定するのは非常に価値があります。比較的小規模なプロトコルであっても、報奨金は可能な限り寛大なものとすべきです（例：最低7〜8桁のUSD相当額）。
国家主体からの攻撃に直面している場合、彼らは交渉に応じない可能性がありますが、それでも「ホワイトハット・セーフハーバー（White Hat Safe Harbor）」プログラムに参加し、ホワイトハットが資金保護のためにあなたに代わって行動することを認めることが可能です。その対価として、発見された脆弱性の報酬の一定割合を支払います（実質的には預託者負担の報奨金です）。
優れた監査担当者を選ぶ
私は以前、大規模言語モデル（LLM）がさらに賢くなるにつれて、監査担当者を雇うことの限界効果（Marginal Value）は低下すると述べました。この見解は今も堅持していますが、若干の修正があります。
第一に、優れた監査担当者はトレンドの先を行きます。あなたが革新的な何かを試みている場合、そのコードおよびそれに伴う脆弱性は、まだ訓練データに含まれていない可能性があります。単にトークン数を増やすだけでは、未踏の脆弱性を発見できることは、まだ実証されていません。あなたは、そのような独自脆弱性の「最初の標的」になることを望まないはずです。
第二に、見落とされがちな利点があります：監査担当者を雇うことは、その「評判」を担保として利用することです。彼らが署名して承認したにもかかわらずハッキングを受けた場合、彼らは助けることに強いインセンティブを持ちます。セキュリティの専門家と信頼関係を築くことは、大きなアドバンテージです。
運用セキュリティ（OpSec）の実践
運用セキュリティを成功の指標の一つと捉えてください。フィッシング演習を実施し、（信頼できる）レッドチームにチームへのソーシャルエンジニアリング攻撃を試行させましょう。緊急時にすぐに使える予備のハードウェアウォレットおよびデバイスを準備し、マルチシグ全体を交換できるようにしておきます。D-Day当日になって慌てて購入することのないようにしましょう。
緩和措置
あなたの「退出ルート」こそが損失上限である
プロトコルから価値を移出するすべてのルートには、それぞれ明確なサイズ上限を設けるべきです。それが、そのルートが脆弱性によって悪用された場合の理論上の最大損失額となります。つまり、ブロックごとの上限がないミント関数は、無限ミント脆弱性に「白紙委任状」を与えているのと同じです。週ごとの上限がない償還関数は、資産残高の破損を招く「白紙委任状」を与えているのと同じです。
あなたの退出ルートの明確な数値を慎重に検討してください。この数値は、あなたが受け入れ可能な最大損害と、ユーザーの最も極端なUX要件の間のバランスを取る必要があります。万が一の際には、これが徹底的な破滅からあなたを救うものです。
ホワイトリスト（およびブラックリスト）
ほとんどのプロトコルには、「呼び出し・取引・受領可能なもの」のリストと、「ユーザーが絶対にしてはならないこと」のリストがあります。これらは暗黙的であれ、信頼境界であり、正式に文書化すべきです。
これを正式化することで、二段階のセッター（設定者）を導入し、有意義な「摩擦」を創出できます。攻撃者はまずホワイトリストへの登録（および／またはブラックリストからの除外）を行い、その後に行動を起こす必要があります。両方を併用することで、攻撃者が新たな攻撃ベクトルをこっそり導入する際には、市場への許諾（統合／上場）と、その行動の禁止（セキュリティレビュー）という、2つのプロセスを同時に突破しなければならなくなります。
奪還
アルゴリズム監視
誰も監視していないなら、キルスイッチは無意味です。オフチェーンの監視システムは、不変条件を継続的に監視し、問題が発生した場合には自動的にアラートを昇格させるべきです。最終的な通知先はガーディアンのマルチシグ担当者であり、彼らが数分以内に判断できるだけの十分な文脈情報が提供される必要があります。
一旦停止して再校正する
あなたが「銃撃」を受けたとき、まずやるべきは「止血」であり、カウントダウンの中で決断することではありません。プロトコルにとってのそれは、キルスイッチ（UI上にも表示すべき）です：1回のトランザクションで、すべての価値移動ルートを一時停止できるボタンです。すべての停止可能コンポーネントを列挙し、原子的に一括停止する「すべてを一時停止」補助スクリプトを事前に準備しておいてください。
一時停止の解除はガバナンスのみが行えるため、キルスイッチはガバナンスコントラクト自体を一時停止してはいけません。ガーディアンレイヤーがガバナンスコントラクトを一時停止できると、侵害されたガーディアンレイヤーが回復プロセスを永久にロックアウトしてしまうからです。
戦情室（War Room）を立ち上げる
凍結・止血後、あなたが信頼するすべての人（事前に合意済みの小規模なグループ）を1つのコミュニケーションチャンネルに集めます。情報が攻撃者・一般市民・悪意ある裁定取引者に漏れないよう、表面積を最小限に抑える必要があります。
チームメンバーの役割を事前に想定し、ロールプレイを行っておきます：意思決定を行う者、防御スクリプトおよび一時停止操作を熟練して実行するオペレーター、脆弱性を再構築し根本原因を特定する者、関係各所と連絡を取る者、観察事項・出来事・意思決定のタイムラインを記録する者。
全員が自分の役割を理解し、訓練を重ねていれば、最悪の瞬間に混乱せず、手順通りに反応できます。
連鎖反応を考慮する
あなたの攻撃者は極めて熟練していると想定してください。最初の脆弱性は、単なる「餌」あるいは後続攻撃の「種」である可能性があります。攻撃は、あなたにまったく間違った行動を取らせ、その結果として真の脆弱性を引き出すことを目的としているかもしれません。
一時停止は、十分に検討され、完全に制御可能で、それ自体が悪用されえないものでなければなりません。一時停止はプロトコル全体の凍結であるべきです：あるコンポーネントを一時停止させることで、別のコンポーネントが逆に開放されるといった状況を招いてはいけません。根本原因および攻撃ベクトルを特定した後には、隣接する露出面および連鎖反応を探索し、一度にすべてを修復する必要があります。
事前にコミットされた後継者のローテーション
後継者が事前に分かっているからこそ、ローテーションは安全です。私は「事前にコミットされた後継者登録簿（Pre-committed Successor Registry）」というアイデアが好きです：これにより、健全なガーディアン／ガバナンスウォレットが侵害されたものに置き換えられるリスクを攻撃者に難しくさせます。これは緩和措置における「ホワイトリスト／ブラックリスト」の考え方と一致します。
各重要な役割について、後継者アドレスを登録してください。緊急レイヤーが実行できるローテーションの基本操作は、「役割Xをその後継者に置き換える」だけです。これにより、平時においても後継者を評価できます：ゆっくりと尽責調査（Due Diligence）を行い、直接会って要請者と面談することも可能です。
アップグレード前の慎重なテスト
根本原因および影響範囲を特定した後、アップグレードをリリースする必要があります。これは、あなたがこれまでにデプロイした中で最も危険なコードとなる可能性があります：プレッシャー下で書かれ、すでにあなたのプロトコルを十分に理解し、脆弱性を見つける能力を証明した攻撃者を相手にします。
十分なテストが行われていない場合は、リリースを延期してください。監査の時間が取れない場合は、ホワイトハットとの関係を活用するか、デプロイ前に48時間のコンペティションを設定し、新鮮なアドバーサリアル・レビュー（対抗的レビュー）を受けるようにしてください。
復旧
迅速な行動
盗まれた資金には「半減期」があります。脆弱性が発動すると、資金は急速にマネーロンダリングパイプラインへと流れ込みます。Chainalysisなどのオンチェーン分析プロバイダーと事前に連携し、攻撃者のアドレスクラスターをリアルタイムで特定・マークし、クロスチェーンで移動する際に取引所に通知してマーク・追跡してもらえるよう準備しておいてください。
中央集権型取引所のコンプライアンス部門、クロスチェーンブリッジ管理者、カストディアン管理者など、クロスチェーンメッセージや特定の未処理預託金を凍結できる管理権限を持つ第三者のリストを、事前に準備しておいてください。
交渉
確かに辛いことですが、それでも攻撃者との対話は試みるべきです。人生の多くのことは、交渉によって解決できます。期限付きのホワイトハット報奨金を提示し、期限内に全額返金された場合、法的措置を取らないと公に宣言してください。
国家主体が相手の場合、うまくいく可能性は低いかもしれませんが、それほど熟練していない攻撃者と向き合う可能性もあります。彼らは単にあなたのプロトコルの弱点を見つけ、低コストで脱出したいだけかもしれません。
こうした行動を取る前に、必ず法務顧問の立ち合いを受けてください。
結論
ハッキングは止まりません。AIがさらに賢くなるにつれて、攻撃はさらに増加します。単に「防御者をより鋭敏にすること」だけでは不十分です。攻撃者が使うのと同じツールを用いて、自社プロトコルをレッドチームテストし、継続的な監視を行い、被害に硬性の上限を設けることで、最悪の状況においても生き残れるようにしなければなりません。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@systematicls
