AIはどのようにスマートコントラクトのセキュリティを強化するのか？汎用モデルから三重監査モデルへの実践的共有

原文出典：Beosin

近年、GPT-4、Claude、Geminiなどの大規模言語モデルは、Solidity、Rust、Goなどのスマートコントラクト言語を読解する能力や、リエントランシー攻撃、整数オーバーフローなどコード特徴が顕著な古典的な脆弱性を識別する能力を強めてきている。これにより、業界では大規模モデルを用いて人手によるコントラクト監査を補助、あるいは代替できるのではないかという考察が始まっている。

しかし、汎用モデルは特定プロジェクトのビジネスロジックに対する理解が不足しており、複雑なDeFiプロトコルを前にすると誤検知率が高く、複数のコントラクト間の相互作用や経済モデルを組み合わせて初めて発見できるような脆弱性を見逃しやすい。その後、業界では「Skill」メカニズムを導入する解決策が提案された——汎用大規模モデルの基盤に、スマートコントラクトセキュリティに特化した専門知識ベース、検出ルール、ビジネスコンテキストを注入し、モデルが監査時に汎用的な能力だけでコードに問題があるか判断するのではなく、より明確な判断根拠を持たせるというものだ。

Skillによる強化を加えたとしても、AI監査には依然として明確な適用範囲がある。既知の脆弱性パターンのスキャンやコード規約チェックは得意とするが、プロトコル全体の設計、コントラクト間の相互作用ロジック、経済モデルを深く理解する必要がある複雑な脆弱性については、現在でも効果的に対処することは難しい。この種の問題は依然として経験豊富な監査専門家が担当する必要があり、複雑な計算ロジックが関わるシナリオでは、より強力な保証を提供する形式検証の導入も必要となる。このような背景から、BeosinはSkill強化AIベースライン検査＋人手による深度監査＋形式検証という三層監査モードを構築した。三者はそれぞれ重点が異なり、相互に補完し合う。

一、汎用AIモデルの監査能力限界：制御対照テストとケーススタディ

本稿では、既に人手による監査が完了したプロジェクトライブラリから、複雑さの異なる二種類のコントラクトをテストケースとして選出した。一つはロジックが比較的独立しており、機能境界が明確なシンプルなコントラクトで、この種のプロジェクトは通常、AI監査ツールのトレーニングデータが最も豊富で、理論上最も優位性を持つシナリオである。もう一つは、複数のコントラクト間相互作用、複雑な状態機械、またはプロトコル間依存関係を伴う複雑なコントラクトで、これはまさに業界で「AIは人手監査を代替できるか」と議論される際に、最もよく引き合いに出される高リスクシナリオである。

比較にあたり、全く同じコードベースを用い、まずAIに独立して監査を実行させ、レポート生成後、人手監査レポートと項目ごとに突き合わせた。二つのレポートの作成プロセスは完全に独立しており、相互に干渉しない——人手監査員がレポートを作成する際、AIの結果は全く知らされておらず、相互影響を避けた。最終的に、以下の四つの観点から結果を分析する：

ケース A · 標準トークンコントラクト（BSC-USDT / BEP20USDT.sol）

最初のテストでは、Solidity 0.5.16で記述された標準的なBEP-20トークンコントラクトを選んだ。そのロジックは比較的独立しており、機能境界が明確で、いかなるコントラクト間相互作用も含まず、主なセキュリティリスクはいくつかの一般的で既知の脆弱性パターンに集中している。この種のコントラクトは、現在理論上AI監査が最も優位性を持つシナリオである——トレーニングデータにはこの種の標準トークンコントラクトが非常に多く、ルールベースの脆弱性特徴も比較的明らかだからだ。

AIは合計6件の警告を出力した（高リスク2件、中リスク1件、低リスク/提案3件）。数値的にはかなりの量である。低リスクと提案項目は基本的に正確で、Solidityバージョンの古さ、状態変数の公開方法など、一般的なコード規約上の問題をカバーしており、一定の参考価値がある。しかし、AIが出力した二つの「高リスク」はすべて誤判定であった。AIはownerの鋳造権限と権限集中を高リスク脆弱性としてマークした——実際には、中央集権型ステーブルコイン（USDTタイプ）において、ownerが鋳造権限を持つことは想定された設計であり、リスク評価はマルチシグ制御、権限ガバナンスメカニズム、コントラクトアップグレード戦略などを総合的に考慮して判断されるべきである。この種の権限構造の合理性は、根本的にはプロジェクトのビジネスモデルに依存し、コード自体には依存しない。AIはこのレベルのコンテキストを欠いており、パターンマッチングに基づいて判断するしかない。

このテストケースは、AIが権限構造を識別できるが、ビジネスコンテキストと組み合わせて権限が合理的か判断できないことを示しており、そのためUSDTタイプコントラクトのowner鋳造権限を直接「高リスク脆弱性」とマークしてしまった。これは典型的なビジネス実ロジックから乖離した誤判定である——この種の誤検知は、プロジェクト側の真のリスク判断を妨げる可能性がある。

ケース B · 複雑ビジネスコントラクト（IPC Protocol / 2025-02-recall）

二つ目のテストでは、Code4renaプラットフォームの公開レポートからIPC Protocolプロジェクトを選出した（レポートリンク：code4rena.com/reports/2025-02-recall）。このプロジェクトにはGateway、SubnetActor、Diamondプロキシパターンなど、相互依存する複数のコアコンポーネントが含まれており、その安全性はプロトコル全体のアーキテクチャとコンポーネント間相互作用ロジックに対する深い理解に大きく依存している。これはDeFiエコシステムにおいて高価値な攻撃が発生する典型的なシナリオである。以下がAI監査の結果である：

複雑なコントラクトに対して、AI監査は合計3件の高リスク、6件の中リスク警告を出力し、出力量の点では遜色ない。しかし、そのうちのかなりの割合が監査員によって誤検知と判定された——AIはコンテキストを欠いたコード断片に対して誤ったリスク判断を下したのである。同時に、監査員が確認した9件のHighレベル脆弱性のうち、AIが完全にカバーしたのはわずか1件で、他に2件は発見されたが重大度が明らかに低く評価されていた（実際はHighだが、AIレポートではMedium）。残り6件は完全に見逃されていた。4件のMediumレベル脆弱性のうち、AIは1件をカバーし、3件は完全に欠落していた。

これらの脆弱性に共通する特徴は、単一関数のパターンマッチングではなく、プロトコルを跨いだコンポーネント間の状態遷移パス全体の推論に依存している点である。人手監査レポートのH-01（署名リプレイ）を例にとると、この脆弱性の悪用パスは、マルチシグ検証の設計意図、攻撃者がどのように重複署名セットを構築するか、そしてこの行為がどのように重み付け閾値を回避するかを理解する必要がある。H-06（leave()関数リエントランシー攻撃）も同様である：この脆弱性はサブネットのbootstrap臨界状態でのみ存在し、ステーキングの流転、bootstrapトリガー条件、外部呼び出しのタイミングの三者間の相互依存関係を理解する必要がある。同様の深層論理脆弱性は、AIの警告リストには一切記録されていなかった。

この結果は、複雑なコントラクト監査において、AIの監査能力は局所的なコードのパターン認識にあり、プロトコルレベルの脆弱性は全体のビジネスロジックに対する理解の偏りが存在する可能性があることを示している。脆弱性のトリガー条件が複数のコントラクト、複数の状態、複数の呼び出し階層にまたがる場合、AIの現在の推論能力では効果的にカバーすることはまだできない。

二つのケースを総合すると、AI監査には価値がないわけではない——既知の脆弱性パターンのカバレッジ、コード規約チェック、および一部の独立した視点からの発見において、実質的な貢献をしている。しかし、その価値の境界は非常に明確である：ベースラインスキャンとして利用できるが、セキュリティ結論として直接利用することはできない。複雑なプロトコルに対して、AIレポートのみに依存してセキュリティ判断を下すと、リスクの高い脆弱性を見逃すだけでなく、大量の低品質な警告がチームのスクリーニング時間を大量に奪うことになる。これがまさに、Beosinが専用Skill知識ベースを構築し、監査プロセスに三層監査モードメカニズムを導入した核心的な理由である。

二、専用Skill知識ベース：AIベースライン検査の品質向上に向けたエンジニアリング的アプローチ

AI監査をベースライン検査の監査プロセスに組み込むためには、実際のDeFiプロトコルを監査する際の誤検知率と見逃し率の高さという問題を解決しなければならない。権限管理、AMM流動性メカニズム、クロスチェーンブリッジのメッセージ検証、あるいはレンディングプロトコルの清算ロジックなど、AIは現在、コード表面の特徴に基づいた単純なマッチングしかできず、具体的なビジネスシナリオや攻防ロジックを組み合わせて、あるコードに実際に問題があるかどうかを判断することは難しい。この問題を解決する核心は、監査専門家が長年蓄積してきた経験を構造化された形でAIの判断プロセスに注入し、一定のビジネス理解能力を持たせることにある。

ただし、明確にすべきは、Skill強化を導入したとしても、監査におけるAIの位置づけは変わらないということだ。複数のコントラクト間相互作用、経済モデル分析、および新種の攻撃手法が関わる複雑な問題については、人手監査は依然として代替不可能である。Skillの役割は、AIが処理可能な範囲内（例えば、一般的な脆弱性パターンの識別、および限定的なビジネスロジックの理解）において、予備スキャンの品質を真に有用なレベルまで引き上げ、人手監査により価値のある予備結果を提供し、何度も精査する必要がある無効な警告を大量に生成しないことにある。

2.1 監査実戦から抽出：Skillルールの構築メカニズム

BeosinのSkill知識ベースは、4000件以上の人手指導監査が完了したスマートコントラクトプロジェクトに由来し、監査専門家による大量の帰納、要約、そして項目ごとの抽出と検証を経て整理されたものである。各ルールの形成は、脆弱性発見からルール実装までの全プロセスを完全に踏んでいる：監査担当者は実際のプロジェクトでセキュリティ問題を発見した後、攻撃パスを完全に再現し、根本原因を深く分析し、修正案が有効かどうかを検証し、最終的にこの一連の攻防認識をコンテキスト判断条件付きのルール項目として整理し、Skillライブラリに組み込み、今後の監査で呼び出せるようにする。

以下はSkillライブラリ内の一つのルールサンプルで、脆弱性パターン、攻撃パス、根本原因、修正提案の四つの次元における構造を含んでいる：

[Beosin-AMM_Skill-1] 流動性追加検出を送金順序で回避

脆弱性パターン：コントラクトは、Pair内のWBNB残高が準備金を超えているかどうか（balanceOf >= reserve + required）をチェックすることで、流動性追加操作かどうかを判断している。この検出は、WBNBがトークンより先にPairに到着するという仮定に依存しているが、RouterのaddLiquidityETH関数は固定で先にERC-20トークンを送金し、その後WETHを送金する。また、addLiquidity関数の送金順序はパラメータ順序によって決定される。

攻撃パス：攻撃者はaddLiquidityETH（トークン固定先送金）を使用するか、addLiquidity(Token, WBNB, ...)を呼び出してTokenをWBNBより先にPairに送金すればよい。検出時点ではWBNBはまだ到着しておらず、balanceOf == reserveとなり、検出関数はfalseを返し、「no add liquidity」制限を完全に回避できる。

根本原因：Pair残高スナップショットに基づく検出方式は、設計レベルにおいて本質的にswap操作とadd liquidity操作を確実に区別することができず、実装上のバグではなくアーキテクチャ上の欠陥に属する。

修正提案：ホワイトリスト外アドレスによるPairへの直接送金を禁止し、すべての取引をコントラクト内蔵関数を通じて完了するように変更し、アーキテクチャレベルで残高スナップショット検出の根本的欠陥を根絶する。

このルールは、単一のコードパターンに対する単純な注釈ではなく、ある種の攻撃に対する体系的な整理である：トリガー条件がどのように構成されるか、攻撃者がどのパスに沿って検出を回避するか、検出メカニズムのどの段階にアーキテクチャ的欠陥が存在するか、そして修正がどのレベルで介入する必要があるか。

2.2 知識ベースのカバレッジ範囲

Beosinは現在、Web3の主流技術スタックをカバーする特化型skill脆弱性ライブラリを形成しており、Solidity、Rust、Motoko、FunC、Go、ZKなどの主要カテゴリを含む。その核心内容は内部コア資