クロスチェーン基盤は、ブロックチェーン同士をつなぐ「橋」としてWeb3の利便性を大きく押し上げる一方、攻撃者にとっては資産が集約する高価値ターゲットになりやすい領域です。Axelar Networkが公表したセキュリティインシデント対応では、脆弱性の原因がプロトコル本体ではなく「サードパーティーのトークンコントラクト」にあったことが示されました。この論点は、クロスチェーンに限らず、DeFiやトークン発行、上場、流動性提供など多様な場面で再現します。
本稿では、専門家の視点から、今回の事案が示すリスク構造、なぜ第三者コントラクトが弱点になりやすいのか、そしてプロジェクト運営者・取引所・開発者・投資家が取るべき実務対策を整理します。
インシデントの要点：原因は「プロトコル本体」ではなく外部コントラクト
Axelar側の説明の核心は、セキュリティ上の問題がAxelarの中核コンポーネントではなく、連携していたサードパーティーのトークンコントラクト設計・実装に起因していたという点です。クロスチェーンやブリッジは、複数チェーン間でトークンを移動させるために、ラップトークンやミント／バーン、ロック／アンロック、メッセージ検証などの仕組みを組み合わせます。ここで連携相手のトークンが標準仕様から外れていたり、特殊な転送ロジックや権限設計の癖を持っていた場合、想定外の挙動が連鎖的に発生し得ます。
つまり、強固な中核を持つプロトコルであっても、接続先の安全性が担保されなければ、利用者から見た全体の安全性は損なわれます。これはサプライチェーンリスクの一種であり、「自分が管理していないコード」が攻撃面を拡張する典型例です。
なぜサードパーティートークンは弱点になりやすいのか
ERC-20互換の“つもり”が落とし穴になる
トークンはERC-20等の標準に準拠しているように見えても、手数料課金（Fee-on-transfer）、ブラックリスト、ミント権限、リベース、フック（転送時コールバック）、メタトランザクション対応など、追加仕様が実装されていることが珍しくありません。ブリッジやクロスチェーン実装側が「標準的な挙動」を前提にしていると、転送量の差分や残高計算のズレ、予期せぬリバート、再入可能性、権限濫用の余地が生まれます。
権限設計（Owner/Role）が攻撃面を増やす
サードパーティートークンは、運営がアップグレード可能（プロキシ）であったり、管理者が強い権限（凍結、没収、ミント、パラメータ変更）を持つことがあります。これ自体が即脆弱性ではありませんが、クロスチェーン接続により「他チェーン側のラップ資産」や「流動性プール」へ影響が波及しやすくなります。鍵管理の不備や内部不正が起きた際に、単一チェーンの被害に留まらず、連鎖的に損失が拡大するのが特徴です。
統合テストの不足と“想定外”の組み合わせ
ブリッジ・メッセージング・DEX・レンディングなど複数コンポーネントを組み合わせるほど、状態遷移は複雑になり、形式検証や単体監査だけでは拾えない欠陥が残ります。特にトークンコントラクトは「発行主体が異なる」ため、統合前提のテストケースが欠けがちです。結果として、境界条件（最小単位、丸め、供給量上限、手数料差し引き、ブラックリスト該当、非標準リターン値など）で事故が起こります。
クロスチェーン環境における被害の広がり方
クロスチェーンでは、単一チェーンのバグが「他チェーン上の表象資産」に影響する可能性があります。例えば、あるチェーンでラップ資産が不正に増えれば、別チェーンのDEXで換金され、実質的に流動性や準備金が吸い上げられます。さらに、レンディングで担保評価に組み込まれていれば、過剰借入により二次被害が発生します。
この構造は、攻撃者の収益機会を大きくし、防御側の対応を難しくします。遮断（停止）判断が遅れるほど、複数チェーンへ素早く拡散され、追跡や回収の難度が上がります。
運営・開発者が取るべき実務対策
トークン受け入れ基準（Token Listing Policy）の明文化
ブリッジやクロスチェーン基盤は、統合するトークンに対して明確な受け入れ基準を設けるべきです。最低限として、(1) コントラクト監査の要否、(2) アップグレード可否と管理者権限の開示、(3) Fee-on-transferやブラックリストなど非標準挙動の申告、(4) 既知の脆弱性パターンの排除、(5) 権限鍵の保護要件（マルチシグ、タイムロック）をルール化し、例外がある場合はリスク説明を伴う形で合意形成する必要があります。
統合前の「仕様差分チェック」とフォーマルな互換性テスト
ERC-20互換を前提にせず、戻り値の形式、transfer/transferFromの挙動、手数料差し引き、イベント発火、リベース時の残高変動、permit対応の有無などをチェックする専用テストスイートを用意します。可能なら、ファジングや状態探索を含む統合テストをCIに組み込み、トークンの差し替えやアップグレード時に再検証が走る仕組みを作るべきです。
異常検知とフェイルセーフ設計（止められることが安全）
クロスチェーンは「止めないこと」より「止められること」が重要です。異常なミント量、ブリッジ入出金の急増、価格乖離、失敗率の上昇などを監視し、閾値を超えた場合は自動的に特定トークンだけを隔離・一時停止できる設計が望まれます。全停止は市場への影響が大きいため、トークン単位・チェーン単位での段階的な遮断が実務的です。
権限とアップグレードのガバナンス強化
サードパーティートークン側に強い管理者権限がある場合、統合条件としてマルチシグ化、タイムロック導入、緊急時の連絡系統、アップグレード手順の事前合意を求めるべきです。さらに、ブリッジ側も「管理者が単独で資産を動かせない」設計（分離された権限、監査ログ、操作の遅延実行）を徹底し、内部不正や鍵漏えい時の最大損失を抑える必要があります。
バグバウンティとインシデント対応計画の平時運用
脆弱性はゼロにできないため、早期発見の仕組み（バグバウンティ、外部研究者との連携）と、発覚後の対応手順（影響範囲の特定、停止判断、告知、復旧、補償方針）を平時から整備しておくことが重要です。特にクロスチェーンでは関係者が多いため、連絡遅延が被害拡大に直結します。
ユーザー・投資家が確認すべきポイント
利用者側も「ブリッジ＝危険」という単純な理解ではなく、リスクの所在を見極める必要があります。具体的には、(1) ラップ資産の発行・償還の仕組み、(2) トークンがアップグレード可能か、管理者権限は強すぎないか、(3) 監査とバグバウンティの有無、(4) 異常時の停止や補償に関するポリシー、(5) 流動性がどこに集約しているか、を確認しましょう。プロトコル本体が堅牢でも、接続先トークンが弱ければ全体の安全性が崩れるという点が今回の最大の教訓です。
まとめ：クロスチェーンの安全性は「最も弱い接続先」で決まる
Axelar Networkが示したように、インシデントの原因がプロトコル本体ではなくサードパーティートークンコントラクトにあるケースは、今後も増える可能性があります。クロスチェーン基盤は接続性が価値である一方、接続性が攻撃面でもあります。だからこそ、受け入れ基準の明確化、非標準挙動を前提としたテスト、異常検知と段階的停止、権限設計の強化、平時からの対応計画という「運用を含むセキュリティ」が不可欠です。
クロスチェーン時代のセキュリティは、単発の監査で完結しません。統合先を含めた継続的な評価と、止血を最優先できる設計・組織体制が、被害を最小化する現実的な解になります。
参照: Axelar Networkはセキュリティインシデントに対応し、脆弱性の原因がサードパーティートークンコントラクトにあることを明らかにしました – Bitget