ゲートセキュリティ講座 03|Gate & GoPlus:AI時代にツールでセキュリティを守る方法
- 核心的な見解:暗号セキュリティは動的かつ継続的なプロセスであり、一度きりの監査ではAI時代の攻撃に対応できません。業界はコントラクトのライフサイクル全体をカバーする継続的なセキュリティ体系へ転換し、AIでAIに対抗する必要があります。
- 重要な要素:
- 従来の監査には四つの構造的欠陥があります:スナップショット型チェック、将来の予測不能、外部依存の制御不能、旧コントラクトの集中的な破綻。
- 攻防のコストは著しく非対称であり、AIは脆弱性の発見を専門家の手作業から自動化されたパイプラインへとアップグレードしました。短期的には攻撃側が半歩リードしています。
- 防御側には先手、コスト、知識の複利という三つの構造的優位性があります。AI監査は数分以内に実際の攻撃事象の脆弱性を検出できます。
- 業界が取り組むべき四つのこと:旧コントラクトの即時再検査、ローンチ済みコントラクトの定期スキャン、AI監査の追加、上場プロセスへのツール化されたレビューの組み込み。
- 一般ユーザーの六つの強化アクション:Tokenセキュリティの確認、承認の整理、アカウントの強化、フィッシング対策、階層的な保管、セキュリティ意識への関注。
安全は静的ではなく動的なものです。暗号資産業界でコードを攻略されたプロジェクトの中には、大手企業の監査を受けていたものも少なくありません。もちろん、これは監査が無意味だという意味ではなく、監査が答えられる問題は、大多数の人が思っているよりも小さいということです。
コントラクトはアップグレードされ、権限は変更され、依存するオラクルやクロスチェーンブリッジは変わり、新しい攻撃手法は毎週のように登場します。しかし、あの報告書は納品された日のまま止まっています。AI はこの矛盾を増幅させました。攻撃者は今や数分で一つのコントラクトをスキャンし、何年も前にデプロイされ、とっくに誰もメンテナンスしていない旧コードを一括で再検査できます。防御側が依然として「ローンチ前に一度監査を受ける」だけにとどまっているなら、その差は広がる一方です。
これは Gate 特別企画『大門安全課』の第三回です。Web3 セキュリティサービスプロバイダーの GoPlus Security と Gate セキュリティチームをお招きし、セキュリティサービスプロバイダーと取引プラットフォームという二つの視点から、AI 時代の暗号セキュリティの新たな変化について語り合います。なぜ監査済みのプロジェクトでも事故が起きるのか、攻防両端でどちらがより速く走っているのか、そして一般ユーザーがツールを活用して、署名する前にどのようにリスクを回避できるのかについてです。

ゲスト紹介
GoPlus パートナー Adam:Adam は GoPlus パートナー兼セキュリティ研究院責任者です。
GoPlus Security は Web3 と AI のための初の分散型セキュリティレイヤーを構築しており、ブロックチェーンと最先端の人工知能セキュリティソリューションを活用することで、ユーザーにスマートで効率的かつ分散型のセキュリティ製品とサービスを提供しています。2022 年以来、GoPlus は指数関数的な成長を遂げ、1 日あたりの API 呼び出し量は 3000 万回に達し、ユーザーのために約 1000 億ドル近い潜在的な損失を防いできました。
Gate セキュリティチーム:Gate セキュリティ部門は、プラットフォームのアカウント、取引、資産セキュリティ体系の構築を担当すると同時に、長年にわたりユーザーの異常アカウントに関する異議申し立てや協査依頼にも対応しています。
Gate は 2013 年に設立され、業界で初めて 100% 準備金証明を導入した取引プラットフォームであり、現在世界で 6000 万人以上のユーザーにサービスを提供しています。セキュリティは私たちにとって付加機能ではなく、このビジネスが成立するかどうかの前提です。私たちは『大門安全課』を通じて、これらの真のリスクの背後にある共通のメカニズムを明らかにしたいと考えています。
Q1. なぜ多くのプロジェクトは監査に合格した後も盗難に遭い、権限の悪用が依然として発生するのですか?
GoPlus パートナー Adam:「一度の監査」は「永遠の安全」を意味しません。従来のコントラクト監査サービスには現在、四つの構造的失効が存在します:
1)スナップショット型検査。監査は本質的に、監査エンジニアがある時点で行う半人工的な検査であり、その効果はツールの品質、個人のスキル、作業状態に依存します。しかしコントラクトコードはアップグレードされ、管理権限は変更され、パラメータ設定は調整されます。一度きりの監査報告書は納品された瞬間から「期限切れ」が始まります。
2)未来を予測できない。新しい脆弱性の種類、新しい攻撃手法は次々と登場し、過去の監査では将来のリスクをカバーできません。
3)外部依存の制御不能。プロジェクトは一般的にオラクル、クロスチェーンブリッジ、サードパーティプロトコルに依存しており、これらの依存項目のリスク変化は従来の監査範囲外です。
4)旧コントラクトの集中的な暴落。数年前にデプロイされ、当時「監査済み」だったコントラクトが、AI によって一括で脆弱性を再発掘されています。例えば Balancer、Yearn のような正式リリースから数年経っても発見されなかった深層的な脆弱性です。
権限の悪用については、それはむしろコントラクトコード自体ではなく運用段階で発生します。原因には以下が含まれます:Owner 権限が過大(随意に増発、ブラックリスト登録、取引停止が可能)、管理者秘密鍵の漏洩、マルチシグ管理の不備、悪意ある提案とガバナンス攻撃……これらはすべて運用段階で発生しやすいセキュリティ問題です。監査報告書に権限リスクが記載されていても、その後誰が監視するのか?操作が安全で合理的かどうかは答えられません。
コントラクト監査後のローンチは安全活動の終点ではなく、起点です。プロジェクトが必要としているのは、コントラクトの全ライフサイクルをカバーする継続的なセキュリティであり、一度きりの監査報告書ではありません。
Gate セキュリティチーム:監査はコードが何をできるかをユーザーに伝えることはできますが、プロジェクト側が何をするつもりかを伝えることはできません。これは上場審査で最も痛感している点です。多くの事故の根源は意図にあります。あるコントラクトは技術的に完全に準拠し、所有者権限の設計も正常範囲内であっても、プロジェクト側はある時点でこれらの権限を行使することを選択できます。例えば取引ルールの変更、ブラックリストの有効化、トークンの増発などです。これらの操作はコードレベルではすべて合法的であり、監査報告書はそれらを脆弱性としてマークしません。なぜならそれらはもともと設計の一部だからです。
したがって、技術監査以外にもう一層の制約が必要です。Gate のアプローチは、上場段階で厳格なプロジェクト選別と審査を行い、同時にプロジェクト側と非悪意声明に署名し、履行状況を監督することです。この層が解決するのはまさに監査では解決できない問題です:コードに脆弱性がなくても、このチームがユーザーの利益を損なう選択をしないとは限りません。
「その後誰が監視するのか」については、上場は私たちにとって始まりに過ぎません。Gate は上場済みプロジェクトに対して定期的なセキュリティ監査を行い、同時にオンチェーンイベント監視を通じてコントラクトの状態を継続的に追跡し、ユーザーもいつでもあるコントラクトの現在のリスク項目を照会できます。
ユーザー側に対しては、私たちは Gate AI にコントラクト監査機能を実装しました。ユーザーが見慣れないコントラクトに遭遇した場合、コントラクトアドレス、ソースコードファイル、または GitHub リンクを直接提出すると、数分以内に構造化されたリスクレポートを取得でき、57 種類以上の脆弱性タイプをカバーし、所有者権限、ブラックリストメカニズム、鋳造権限、転送税という最もよく詐欺に使われる設計を重点的に指摘します。
この機能を作った出発点はシンプルです:監査報告書は通常プロジェクト側の資産であり、ユーザーは入手できず、読み解くこともできません。そしてユーザーが署名ボタンの前に立っているとき、本当に知る必要があるのは、この瞬間のこのコントラクトの状態なのです。
Q2. AI ツールの応用がこれほど広がった後、サイバーセキュリティの課題の深刻さは著しく増大しました。業界はこれらの AI 駆動の脅威に対応するためにどのように調整すべきですか?今すぐやるべきことは何ですか?
GoPlus パートナー Adam:まず一つの現実を認める必要があります:攻防のコストはすでに深刻に不均衡です。ハッカーが AI を利用して効率的に脆弱性を発掘する攻撃パラダイムはすでに形成され急速に蔓延しており、攻撃は「専門家による手作業の研究」から「自動化された流水ライン」へと変わりました。防御側が依然として「ローンチ前に監査会社に報告書を出してもらう」、あるいはリスクを発見してからセキュリティ会社に「後手の補修」を求めるだけでは、弓矢で機関銃に対抗するようなものです。AI で AI に対抗することが、唯一有効な道です。
業界レベルの調整方向は、「一度きりの監査」や「問題発生後に専門家を探す」から「全ライフサイクルの継続的セキュリティ」へアップグレードすることです。GoPlus DeepScan の「コントラクトセキュリティ三種の神器」を例にとると、これは実行可能な閉ループです:
ローンチ前、Token セキュリティ自己チェック:数分で貔貅盤/ハニーポット、悪意ある増発(Mint)、ブラックリスト、異常取引税、Owner 権限などのバックドアリスクを迅速に自己検査;
ローンチ時、AI コントラクト監査:AI がソースコード、権限管理、ビジネスロジックを深く分析し、構文層とビジネスロジック層の脆弱性をスキャンし、構造化された監査報告書を納品;
ローンチ後、継続的なセキュリティ監視と定期検診:新たな脆弱性情報、攻撃事件、外部依存(オラクル、クロスチェーンブリッジ、サードパーティプロトコル)のリスクをリアルタイムで追跡し、AI がプロジェクトが影響を受けているかどうかを継続的に判断し、常態的な警告を実施。定期的にコントラクトのセキュリティ検診を行い、継続的に監査。
「今すぐやるべき」四つのこと:
1)既存の旧コントラクトを直ちに再検査。数年前にデプロイされたコントラクトは現在最大の「地雷原」であり、AI 監査は再検査コストを極限まで下げ、1 回のスキャンは数分から数十分で、コストは従来の人手監査よりはるかに低く、これは旧コントラクト暴落の波における必須のニーズです。
2)ローンチ済みコントラクトを定期的なスキャンのリズムに組み入れる。毎日または毎週 1 回スキャンし、LLM の不断のアップグレードによる知能とセキュリティナレッジベース(Security LLM Wiki)の不断の更新による知識を利用して、攻防の対抗で後れを取らないようにする。
3)従来の監査に加えて AI 監査を重ねる。両者は代替関係ではなく補完関係であり、「もう一層の防御、もう一層の安心」です。
4)取引所が上場プロセスにツール化された評価を組み込む。既存の上場プロセスを変えることなく、Token セキュリティ自己チェックと AI コントラクト監査で評価効率を高め、上場後は継続的な監視を常態的なリスク管理とし、「上場後の事故」の確率を下げる。
もう一つ注目に値するシグナル:2026 年 2 月に OpenAI が EVMbench を発表し、GoPlus は同時期に DeepScan V1 をリリースし、AI Auditing Benchmark をオープンソース化しました。AI 監査はすでに「概念」から「業界標準の構築」段階に入っており、より早く導入するプロジェクト側ほど、攻防の非対称性が解消されるメリットをより早く享受できます。
Gate セキュリティチーム:AI は攻撃者の行動速度を速め、攻撃規模を拡大しやすくしました。彼らはより早く脆弱性を見つけ、工業的な規模でフィッシング攻撃を展開し、ディープフェイクを利用してソーシャルエンジニアリングをより察知されにくくすることができます。これは暗号資産業界への衝撃が特に大きく、その理由は業界自体の構造にあります:ビジネスの大部分、特に DeFi は、モジュール型金融に近い運営モデルで、各種プラットフォームは共有コンポーネントで構築されています。コントラクト、ソフトウェアライブラリ、ウォレット、価格オラクル、クロスチェーンブリッジ、接続サービスプロバイダー、ウェブインターフェース、そして更新をプッシュするためのシステムです。
したがって、自分のコントラクトが安全かどうかだけでなく、依存する一つ一つの环节が依然として信頼できるかを問う必要があります。上流のあるコンポーネントに障害が発生すると、損失はチェーンに沿って下流に伝播します。多くの重大な攻撃の問題は、プロトコルロジックよりも早い段階で発生しています:サプライヤー、開発ツール、ソフトウェアがユーザーに到達する方法、あるいはユーザーが転送を承認するプロセスです。AI はこれらの弱点を発見し、それらを連鎖させて利用するコストを下げ、この種の攻撃の敷居はますます低くなるばかりです。
実行可能なレベルに具体化すると、今すぐやるべきことが三つあると考えています。
1)依存項目を明確にする。依存するコントラクト、ライブラリ、ウォレット、サプライヤー、クラウドアカウント、リリースシステム、フロントエンド、マルチシグウォレット、管理者鍵、バリデータを記録した動的なリストを継続的に維持し、定期的にレビューする。これは基本的に聞こえますが、大多数のチームはできていません。なぜなら依存はひっそりと成長するからです:一時的に導入したライブラリ、工期を間に合わせるために開設したクラウドアカウント、元同僚が残した鍵、これらは正式に記録されたことがなく、したがってレビューされたこともありません。
2)単一の障害が引き起こしうる損害を制限する。いかなる個人、鍵、ノートパソコン、クラウドログインアカウント、サプライヤーも、単独でシステム全体を麻痺させる能力を持つべきではありません。方法は、制御権を異なる人員とシステムの間に分散させ、変更提案権と実行権を分離し、同時に操作制限を設け、待機期間を予約し、緊急停止権限を明確にすることです。この原則は私たち自身の資産アーキテクチャでもこのように実装されています:コールドウォレットとホットウォレットの分離、資産の绝大部分はオフラインのマルチシグコールドウォレットに保存され、ホットウォレットはマルチシグとマルチパーティ計算(MPC)メカニズムを採用しています。設計時に私たちがデフォルトで前提としているのは:いつか必ず事故が起きるということ、だから事故時に損失が一定範囲内に制限されることを保証する必要があります。
3)ウェブサイトとリリースプロセスを金庫の一部として扱う。ユーザーが見てクリックするコンテンツ自体が金融インフラです。プロダクションビルドは再現可能かつ署名済みであるべきで、ウェブサイト、コンテンツ配信、ドメイン設定、ソフトウェアサプライチェーンの変更には、二人承認、時間制


