著者：ベオシン
近年、GPT-4、Claude、Geminiといった大規模言語モデルは、高いコード理解能力を発揮し、Solidity、Rust、Goなどのスマートコントラクト言語を効果的に読み取り、再入攻撃や整数オーバーフローといった特徴的なコード特性を持つ古典的な脆弱性を特定できるようになった。このことから、業界では、大規模モデルを手動によるコントラクト監査の補助、あるいは代替として活用できるかどうかを検討する動きが広がっている。
汎用モデルは特定のプロジェクトのビジネスロジックを十分に理解していないため、複雑なDeFiプロトコルを扱う際に誤検出率が高く、コントラクト間の相互作用や経済モデルによる検出が必要な脆弱性を見逃しやすい。その後、業界では「スキル」メカニズムを追加することが提案された。これは、スマートコントラクトのセキュリティに関する専門的な知識ベース、検出ルール、ビジネスコンテキストを汎用モデルに注入することで、コードに問題があるかどうかを判断する際に一般的な機能だけに頼るのではなく、監査時の判断基準をより明確にするというものである。
スキル強化が進んだとしても、AI監査の適用範囲は依然として明確に定義されています。既知の脆弱性パターンのスキャンやコードスタイルのチェックには優れていますが、プロトコル全体の設計、契約間の相互作用ロジック、経済モデルなどに関する深い理解を必要とする複雑な脆弱性を効果的に処理するには、現状では課題があります。こうした問題には、経験豊富な監査専門家が必要であり、複雑な計算ロジックが関わるシナリオでは、より強力な保護策を提供するために形式検証が必要となります。こうした背景を踏まえ、Beosinは、スキル強化型AIベースラインチェック、詳細な人間による監査、形式検証という3段階の監査モデルを開発しました。各コンポーネントはそれぞれ独自の焦点を持ち、互いに補完し合います。
I. 一般的なAIモデルの監査能力の限界：制御された比較テストと事例分析
本稿では、既に手動監査が実施されているプロジェクトライブラリから、複雑さのレベルが大きく異なる2種類の契約をテストケースとして選定する。1つは、比較的独立したロジックと明確な機能境界を持つシンプルな契約である。これらのプロジェクトは通常、AI監査ツールが最も豊富な学習データを持ち、理論的に最も有利なシナリオとなる。もう1つは、複数の契約間の相互作用、複雑なステートマシン、またはプロトコル間の依存関係を含む複雑な契約である。これは、業界でAIが手動監査に取って代わることができるかどうかを議論する際に最も頻繁に取り上げられる、リスクの高いシナリオでもある。
比較にあたっては、全く同じコードベースを使用し、まずAIに独立して監査を実行してレポートを生成させ、次にそれを人間の監査レポートと一行ずつ照合しました。2つのレポートの作成プロセスは完全に独立しており、人間の監査担当者はレポート生成時にAIの結果を一切知らなかったため、相互の影響は回避されました。最後に、以下の4つの側面から結果を分析します。
ケースA：標準トークン契約（BSC-USDT / BEP20USDT.sol）
最初のテストでは、Solidity 0.5.16で記述された標準的なBEP-20トークンコントラクトを選択しました。このコントラクトはロジックが比較的独立しており、機能境界が明確で、コントラクト間の相互作用もありません。主なセキュリティリスクは、よく知られている脆弱性パターンに集中しています。理論的には、このタイプのコントラクトは現在、AI監査にとって最も有利なシナリオと言えます。トレーニングデータにはこのような標準的なトークンコントラクトが多数存在し、ルールベースの脆弱性特性も非常に明確だからです。
AIは6件の警告（高リスク2件、中リスク1件、低リスク/推奨3件）を生成しましたが、これはかなりの数です。低リスクおよび推奨の警告は概ね正確で、古いSolidityバージョンや不適切な状態変数の公開といった一般的なコーディングスタイルの問題を網羅しており、参考になる価値があります。しかし、AIの「高リスク」警告はどちらも判断ミスでした。AIは所有者の発行権限と中央集権的な権限を高リスクの脆弱性としてマークしましたが、実際には、中央集権型ステーブルコイン（USDTなど）の場合、所有者の発行権限は想定される設計機能であり、リスク評価はマルチシグネチャ制御、権限ガバナンスメカニズム、コントラクトアップグレード戦略などを考慮した総合的な判断に基づくべきです。このような権限構造の合理性は、コード自体ではなく、プロジェクトのビジネスモデルに根本的に依存します。AIはこの文脈を欠いており、パターンマッチングに基づく判断しかできませんでした。
このテストケースは、AIが権限構造を認識できるものの、ビジネスコンテキストと照らし合わせて権限が妥当かどうかを判断できないことを示しています。そのため、USDT型契約の所有者の発行権限を「高リスクの脆弱性」と直接的に判定してしまいました。これは、実際のビジネスロジックからかけ離れた典型的な誤判断です。このような誤報は、プロジェクトチームによる真のリスク判断を妨げる可能性があります。
ケースB：複雑なビジネス契約（IPCプロトコル／2025-02-リコール）
2番目のテストでは、Code4renaプラットフォームの公開レポート（レポートリンク：code4rena.com/reports/2025-02-recall）からIPCプロトコルプロジェクトを選択しました。このプロジェクトには、ゲートウェイ、サブネットアクター、ダイヤモンドプロキシパターンなど、相互依存する複数のコアコンポーネントが含まれています。そのセキュリティは、プロトコル全体のアーキテクチャとコンポーネント間の相互作用ロジックを深く理解することに大きく依存しており、DeFiエコシステムにおける高価値攻撃の典型的なシナリオを表しています。以下に、AI監査の結果を示します。
複雑な契約の場合、AI監査は高リスクの警告を3件、中リスクの警告を6件生成し、出力量はまずまずでした。しかし、これらのうちかなりの割合が監査人によって誤報と判断されました。AIはコンテキストのないコードスニペットに対して誤ったリスク評価を行っていたためです。一方、監査人が確認した9件の高レベルの脆弱性のうち、AIが完全にカバーしたのは1件のみで、2件は発見されたものの評価が大幅に低下し（実際には高レベルでしたが、AIによって中レベルと報告されました）、残りの6件は全く検出されませんでした。4件の中レベルの脆弱性のうち、AIがカバーしたのは1件のみで、3件は全く検出されませんでした。
これらの脆弱性には共通の特徴があります。それは、単一の関数のパターンマッチングではなく、プロトコルのコンポーネント間の状態遷移パスに関する包括的な推論に依存している点です。手動監査レポートのH-01（署名リプレイ）を例にとると、エクスプロイトパスでは、マルチ署名検証の設計意図、攻撃者が重複署名のセットをどのように構築するか、そしてこの動作が重みしきい値をどのように回避するかを理解する必要がありました。H-06（leave()関数再入攻撃）も同様です。この脆弱性はサブネットブートストラップのクリティカルな状態でのみ存在するため、ステーキングフロー、ブートストラップのトリガー条件、および外部呼び出しのタイミング間の相互依存関係を理解する必要があります。このような深層ロジックの脆弱性は、AIのアラートリストには記録されていません。
結果によると、複雑な契約の監査において、AIの監査能力はローカルコードのパターン認識に頼っている一方、プロトコルレベルの脆弱性は、全体的なビジネスロジックの誤解に起因する可能性がある。脆弱性の発生条件が複数の契約、複数の状態、複数の呼び出しレベルにまたがる場合、AIの現在の推論能力ではそれらを効果的に網羅するには不十分である。
2つの事例に基づくと、AI監査には確かに価値があります。既知の脆弱性パターンの網羅性、コードスタイルのチェック、そして独自の視点の発見に大きく貢献します。しかし、その価値の限界は非常に明確です。ベースラインスキャンとしては機能しますが、セキュリティの結論として直接使用することはできません。複雑なプロトコルの場合、セキュリティ判断をAIレポートだけに頼ると、高リスクの脆弱性を見逃すだけでなく、質の低いアラートが大量に発生するため、チームのスクリーニング時間を大幅に消費することになります。まさにこれが、Beosinが専用のスキル知識ベースを構築し、監査プロセスに3段階監査モデルメカニズムを導入した根本的な理由です。
II. 専門スキル知識ベース：AIベースライン検査を強化するためのエンジニアリングの道筋
AI監査をベースライン監査プロセスに統合するには、実際のDeFiプロトコルを監査する際のAIの高い誤検出率と誤検出率に対処することが不可欠です。アクセス制御、AMM流動性メカニズム、クロスチェーンブリッジメッセージの検証、レンディングプロトコルの清算ロジックなど、AIは現在、表面的なコード機能に基づいた単純なマッチングしか実行できません。これらの機能を特定のビジネスシナリオや攻撃/防御ロジックと組み合わせることで、コードに問題があるかどうかを判断することは困難です。この問題を解決する鍵は、監査専門家が長年蓄積してきた経験を構造化された方法でAIの判断プロセスに組み込み、一定レベルのビジネス理解を与えることです。
しかし、スキル機能の強化があっても、監査におけるAIの役割は変わらないことを明確にしておくことが重要です。複数の契約が絡む複雑な問題、経済モデル分析、新たな攻撃手法などにおいては、人間の監査は依然として不可欠です。スキル機能強化の役割は、AIの能力の範囲内（一般的な脆弱性パターンを特定したり、ビジネスロジックをある程度理解したりするなど）で、初期スキャンの質を真に役立つレベルまで高め、人間の監査にとってより価値のある初期結果を提供することです。そうすることで、何度も精査する必要のある無効なアラートを大量に生成するのを防ぐことができます。
2.1 監査実務からの抽出：スキルルールの構築メカニズム
Beosinのスキル知識ベースは、手動監査を受けた4,000件以上のスマートコントラクトプロジェクトから構築されています。監査専門家がこれらのルールを詳細に要約・精緻化し、一つずつ検証・整理してきました。各ルールの作成は、脆弱性の発見からルールの実装まで、完全なプロセスを経て行われます。監査担当者は、実際のプロジェクトでセキュリティ上の問題を発見した後、攻撃経路を完全に再現し、根本原因を詳細に分析し、対策の効果を検証し、最終的にこの攻撃と防御に関する知識全体を、状況に応じた判断条件付きのルールエントリとして整理し、スキルライブラリに組み込んで、以降の監査に活用します。
以下は、スキルライブラリからのサンプルルールです。このルールには、脆弱性パターン、攻撃経路、根本原因、および修復推奨事項という4つの側面にわたる構造が含まれています。
[Beosin-AMM_Skill-1] 振替注文による流動性検出バイパス機能を追加
脆弱性パターン：このコントラクトは、ペア内のWBNB残高が準備金を超えているかどうか（balanceOf >= reserve + required）を確認することで、流動性追加操作が行われているかどうかを判断します。この検出は、WBNBがトークンよりも先にペアに到着するという前提に基づいています。しかし、ルーターのaddLiquidityETH関数は常にERC-20トークンを先に転送し、次にWETHを転送します。また、addLiquidity関数の転送順序は、orderパラメータによって決定されます。
攻撃経路：攻撃者は、`addLiquidityETH`（トークンが先に転送される）を使用するか、`addLiquidity(Token, WBNB, ...)`を呼び出してWBNBより先にトークンをペアに転送するだけで済みます。攻撃が発生した時点では、WBNBはまだ到着しておらず、`balanceOf == reserve`となり、検出関数はfalseを返すため、「流動性の追加禁止」制限を完全に回避できます。
根本的な原因は、ペア残高スナップショットに基づく検出方法が、設計段階でスワップとアドの流動性操作を確実に区別できないことにある。これは実装上のバグではなく、アーキテクチャ上の欠陥である。
推奨される修正策：ホワイトリストに登録されていないアドレスがPairに直接資金を送金することを禁止するようシステムを変更する。すべての取引はコントラクトに組み込まれた関数を通じて完了するようにすることで、アーキテクチャレベルでの残高スナップショット検出における根本的な欠陥を解消する。
このルールは、単一のコードパターンを単純に分類するものではなく、攻撃の種類を体系的に分析したものです。つまり、攻撃のトリガー条件がどのように形成されるか、攻撃者が検出を回避するためにどのような経路をたどるか、検出メカニズムのどの段階でアーキテクチャ上の欠陥が生じるか、そしてどのレベルで修正を実装する必要があるか、といった点を分析するものです。
2.2 知識ベースの適用範囲
Beosinは、Solidity、Rust、Motoko、FunC、Go、ZKなどのカテゴリを含む、主要なWeb3テクノロジースタックを網羅する専門的なスキル脆弱性データベースを開発しました。そのコアコンテンツは内部で保持され、一般には公開されていません。ディレクトリ構造は以下のとおりです。
各専門リポジトリ内のスキルは、脆弱性の種類に応じて個別に管理されます。各ルールには、番号、トリガー条件、攻撃経路の再構築、状況判断ロジック、および修復提案が含まれます。スキルリポジトリ全体は、新たな攻撃イベントの発生と監査インスタンスの蓄積に伴い継続的に更新され、ブロックチェーン上の現実世界の脅威環境との同期が維持されます。
2.3 スキル介入後のベースライン検査品質の比較
Skillライブラリがベースラインのスキャン品質に及ぼす実際の影響を定量化するために、第2章の2つのテストケースをベンチマークとして使用し、同じコードベース上で汎用AIとSkill強化AIをそれぞれ実行し、結果を項目ごとに比較しました。
ケースA：標準トークン契約（BEP-20）の比較結果
ケースB：複雑なビジネス契約の比較結果（IPCプロトコル）
比較結果から、Skillの導入により、両タイプの契約における検出精度が大幅に向上したことが示されました。標準的なトークン契約シナリオでは、ビジネスコンテキスト判断機能の追加により、高リスクの誤検出が完全に排除されました。複雑なビジネス契約シナリオでは、既知の脆弱性パターンのカバー率が11%から44%に増加し、誤検出率が約55%から約30%に低下し、深刻度レベルの判断精度も大幅に向上しました。このレポートはベースラインチェックとして機能し、プロジェクトチームがコード内の既存の欠陥を事前に特定するのに役立ちます。これらの問題は短期的には直接的な金銭的損失にはつながりませんが、その後のプロジェクトの保守やアップグレードに重要なプラスの効果をもたらします。
しかしながら、このデータはAIの能力に内在する限界も明確に示しています。スキル強化後も、複雑な契約における高レベルの脆弱性の検出率はわずか44%にとどまります。契約間の状態パス推論、経済的インセンティブモデル分析、あるいは特定の時間的条件を必要とするような深刻な脆弱性は、AIのベースラインスキャンでは依然として検出できません。これが、スキル強化後も監査ワークフローに完全な手動監査プロセスを残している根本的な理由です。
2.4 ホワイトペーパーを監査のインプットとして活用する：コード実装と設計意図の一貫性の検証
脆弱性シグネチャデータベースに加えて、監査プロセスに重要な機能を追加しました。それは、プロジェクトのホワイトペーパーを追加の入力として使用し、AIがコードの実装とホワイトペーパーの設計との整合性を検証できるようにすることです。
具体的には、コード監査の開始前に、AIはプロジェクトのホワイトペーパー、技術仕様書、要件定義書を体系的に分析し、役割と権限モデル、コアビジネスプロセス、信頼境界の定義、想定される行動制約を抽出して、構造化されたプロジェクトコンテキストの概要を作成します。その後、コード監査プロセス全体を通して、AIはこのコンテキストを継続的に相互参照して比較します。このメカニズムは、実用上、2つの貴重な成果をもたらしました。
まず、コード内の権限構造がリスクをもたらす可能性がある場合、ホワイトペーパーでその設計意図と制約が明確に説明されていれば、AIはそれに応じて判断を調整し、誤検知を効果的に削減します。
第二に、コードの実装とホワイトペーパーに記載されている内容との間に重大な相違がある場合（例えば、ドキュメントに記載されている遅延防止メカニズムがコードに実装されていない場合や、ガバナンスプロセスの時間制約が正しく実行されていない場合など）、AIが警告を発します。このようなコードとドキュメントの不整合は、通常のコードスキャンでは見落とされがちですが、多くの場合、潜在的なセキュリティ脆弱性となります。また、これにより、プロジェクトチームは、実際のデプロイ後にプロジェクトが期待と異なる動作を示す事態を回避することができます。
III．トリプル監査モデル：スマートコントラクトのための完全なセキュリティ保証を共同で構築する
スマートコントラクトがブロックチェーン上に展開されると、脆弱性の影響は多くの場合、取り返しのつかないものとなります。Beosinは、契約監査の基盤として、綿密な人的監査と形式検証を組み合わせた手法を採用し、金銭的損失や異常なロジック動作につながる可能性のある問題の特定と報告に重点を置いています。同時に、専用のスキル知識ベースに基づいた高度なAIベースラインチェックを導入し、現時点では欠陥に過ぎず、まだ実際の被害をもたらしていないコードの問題をクライアントが発見できるよう支援しています。Beosinは、この基盤の上に、綿密な人的監査、形式検証、高度なAIベースラインチェックという3層構造の監査モデルを構築しました。これら3つの要素が階層的に連携することで、より包括的なセキュリティシステムが構築されます。
3.1 詳細な手動監査と形式検証：セキュリティ保証の中核となる柱
手動監査の最大のメリットは、プロトコル全体の設計を深く理解し、攻撃者の視点から潜在的なリスクを積極的に分析できる点にあります。経験豊富な監査専門家は、契約間の相互作用ロジックの検証、ファンドセキュリティの攻撃対象領域分析、極端な市場状況下でのプロトコルの論理分析、新たな攻撃手法の特定と判断など、プロジェクトの包括的なプロトコルレベル監査を実施する責任を負います。このようなプロトコルレベルでの攻撃と防御の理解は、Web3エコシステムにおける長期的な蓄積と実践経験に大きく依存しており、現状ではツールレベルで単独で達成することはできません。
この基盤の上に、Beosin は内部ツールチェーンを使用して、手動監査の判断を定量化可能な数学的保証に変換します。監査専門家によって確認されたコアビジネスロジック、例えば資金の流れや価格計算などの最もリスクの高いクリティカルパスについては、Beosin は LLM 駆動の形式仕様生成機能を内部検証ツールチェーンに深く統合し、「AI 仕様生成 → 形式的網羅的検証 → 反例駆動による改良」のクローズドループエンジンを構築します。ツールチェーンはまず、Beosin の蓄積された監査コーパスを知識ベースとして使用し、手動で確認された高リスクパスの攻撃対象領域をモデル化し、形式的不変条件とセキュリティ属性仕様の初期候補セットの生成を支援します。続いて、自動形式検証エンジンが契約の完全な状態遷移空間を網羅的に検証します。検証エンジンが反例を発見すると、システムは自動的に 2 つのシナリオを区別します。反例が仕様定義とビジネスセマンティクスの間の逸脱に起因する場合、反例のコンテキストが仕様改良のために AI モジュールにフィードバックされ、次の反復が駆動されます。反例が契約コード内の実際に悪用可能なパスに対応する場合、監査担当者が確認および修正のフォローアップを行うために、完全な攻撃パスの再現とともに脆弱性証拠として直接出力されます。2つのパスは連携して閉ループ収束を促進し、すべての可能な入力に対して目標特性が真であることが数学的に確認されるまで続きます。この閉ループ機構によって検証されるクリティカルパスは、契約セキュリティシステム全体の中で最も決定論的な防御となり、攻撃対象領域を極めて狭い範囲に圧縮します。
3.2 強化されたAIベースラインチェック：開発者向け継続的リスク警告サービス
一方、Beosinは、スキル知識ベースに基づいた強化されたAIベースラインチェックをスタンドアロンサービスとして提供しています。高リスクの脆弱性の発見に重点を置く詳細な人的監査とは異なり、このサービスは開発チーム向けのコード健全性レポートのような位置づけです。AIベースラインスキャンは、契約コードを完全に網羅し、現時点では直接的な経済的損失を引き起こさないものの、その後のプロジェクト保守や反復作業中に開発者の注意が必要となる潜在的な問題を体系的に特定します。例としては、古い依存ライブラリの使用、重要なイベント宣言の欠落、ベストプラクティスに反する状態変数公開方法、さらに最適化可能なガス使用パターンなどが挙げられます。これらの問題は通常、現在のビジネスロジックでは攻撃者によって直接悪用されることはありませんが、プロトコル機能が拡張されたり、コードがリファクタリングされたり、外部依存関係が更新されたりすると、これらの問題の一部が徐々に実際のセキュリティ脆弱性へと発展する可能性があります。これら3つのレイヤーはそれぞれ独自の焦点を持ち、段階的に進展することで、Web3プロジェクト向けの完全なセキュリティ保護システムを構築します。
