スマートコントラクト1000億ドル資産の保護に向けたEVMbench開発の背景と狙い
目次
- 1 スマートコントラクト1000億ドル資産の保護に向けたEVMbench開発の背景と狙い
- 2 OpenAIとParadigmが共同設計した120件の脆弱性ベース評価フレームワークの全体像
- 3 Detect・Patch・Exploitの3モードで測定するAIエージェントのセキュリティ能力
- 4 GPT-5.3-CodexからClaude Opus 4.6まで主要モデルが示した性能差と傾向
- 5 メインネット再現やタイミング依存を含む現行版EVMbenchの構造的制約
- 6 スマートコントラクト監査へのAIエージェント導入で押さえるべき実務上の要点
- 7 1000万ドルAPI支援とAardvark拡張に見るOpenAIのサイバーセキュリティ構想
スマートコントラクト1000億ドル資産の保護に向けたEVMbench開発の背景と狙い
Ethereumをはじめとするブロックチェーン上のスマートコントラクトは、分散型金融(DeFi)プロトコルやトークン発行など幅広い用途で利用されており、その管理下にある資産規模は1000億ドルを超えています。2026年2月にOpenAIがParadigmとの共同開発で公開したEVMbenchは、こうした巨額資産を守るうえでAIエージェントがどこまで有効なのかを定量的に測定するベンチマークです。この章では、EVMbenchが生まれた社会的・技術的背景を整理し、なぜいまスマートコントラクトのセキュリティ評価に特化した新指標が必要とされているのかを解説します。
2025年の暗号資産被害総額34億ドルが突きつけたスマートコントラクト監査の限界
2025年に暗号資産分野で発生した不正被害額は約34億ドルに達し、前年比でもわずかに増加しました。被害の多くは、スマートコントラクトのコード上に潜む脆弱性を攻撃者が悪用したケースです。DeFiプロトコルでは数千万ドル規模の資金が一度の攻撃で流出する事例も珍しくなく、従来の人手監査だけではカバーしきれない現実が浮き彫りになっています。
人間のセキュリティ監査者は高い専門性を持つ一方、コードベースの膨大化に伴い見落としのリスクが高まっています。競争型監査コンテストではトップクラスの監査者でもすべての脆弱性を発見できるわけではなく、重要度の高い脆弱性が本番デプロイ後に初めて露呈する事態が繰り返されてきました。こうした監査能力の構造的上限が、AIエージェントによる補完・強化を求める声を一段と強めています。
EVMbenchはまさにこの課題を起点として設計されました。34億ドルという被害規模は、ブロックチェーンセキュリティの強化が業界全体にとって喫緊のテーマであることを裏付けており、AIを活用した監査ツールの性能を客観的に測定する共通基盤の必要性を示しています。
デプロイ後に修正不可という設計特性がもたらす脆弱性リスクの深刻度
スマートコントラクトの最大の特徴は、ブロックチェーン上に一度デプロイされると原則として改変できないイミュータビリティにあります。Webアプリケーションであればパッチを当てて修正できる脆弱性も、スマートコントラクトでは事後対応が極めて困難です。アップグレーダブルパターンやプロキシ構造を採用しているプロトコルも存在しますが、すべてのコントラクトに適用されているわけではありません。
この不可逆性は、デプロイ前の監査品質が資産の安全性を直接左右することを意味します。コード1行の見落としが数千万ドルの損失に直結しうる環境では、監査の精度と網羅性に対する要求水準が従来のソフトウェア開発とは比較にならないほど高くなります。EVMbenchが「経済的に重大な環境」での評価を掲げているのも、この設計特性に起因するリスクの大きさが背景にあるためです。
加えて、攻撃者は脆弱性を発見した時点で即座にトランザクションを実行し資金を引き出せるため、防御側には準備期間がほとんどありません。攻撃と防御の非対称性を埋める手段として、AIによる事前監査の重要性は今後さらに増していくと考えられます。
AIエージェントの読解・執筆・実行能力向上が攻防双方に与える影響の構図
大規模言語モデル(LLM)を基盤とするAIエージェントは、コードの読解・生成・実行といった能力を急速に高めています。OpenAIはEVMbenchの公式ブログで、AIエージェントがコードを読み書きし実行する能力が向上するにつれ、攻撃者にも防御者にも変革をもたらす可能性があると述べています。この二面性こそがEVMbenchの開発動機の核心です。
攻撃側の観点では、AIが脆弱性を自動的に発見しエクスプロイトコードを生成できるようになれば、これまで高度なスキルを必要とした攻撃の敷居が下がります。一方、防御側ではAIを監査ワークフローに組み込むことで、人間だけでは見逃しがちなパターンを検出し、パッチを迅速に適用できる可能性があります。
EVMbenchは、この攻防の能力を同一のフレームワーク上で測定できるよう3つの評価モードを設けました。攻撃能力(Exploit)の進歩を可視化するだけでなく、防御能力(Detect・Patch)の到達度を同時に追跡することで、防御側がどの程度追いついているのかを定量的に把握できる構造になっています。
Code4renaなど競争型監査コンテストから得られた実データ活用の意義
EVMbenchの脆弱性データセットは、Code4renaをはじめとする競争型監査コンテストの成果を主要なソースとしています。Code4renaは、複数の監査者がスマートコントラクトの脆弱性を競い合って発見し、重大度に応じた報酬を受け取る仕組みのプラットフォームです。ここで蓄積されたデータは実際のプロトコルを対象としており、合成的に作られたテストケースとは質的に異なります。
競争型監査の成果を活用する最大の利点は、脆弱性の重大度やカテゴリが人間の専門家によって検証済みである点にあります。発見された脆弱性には報酬額が紐づいているため、AIエージェントの検出能力を金額ベースで定量化する「Detect Award」という評価指標の根拠にもなっています。こうした経済的尺度は、AIセキュリティツールの費用対効果を議論するうえで有用な基盤を提供します。
一方、Code4rena由来のデータはコンテスト参加者の能力範囲内で発見された脆弱性に限られるため、本番環境における未知の攻撃ベクトルを完全に反映しているとは言えません。EVMbenchがこの点を制約として明示していることも、ベンチマークとしての誠実さを示すポイントです。
StripeとParadigmが共同インキュベートしたTempo監査事例を組み込んだ実務接続性
EVMbenchのデータセットには、Code4rena由来の脆弱性に加え、Tempoブロックチェーンのセキュリティ監査過程から得られたシナリオも含まれています。Tempoは高スループット・低コストのステーブルコイン決済を実現するために設計されたレイヤー1ブロックチェーンであり、StripeとParadigmが共同でインキュベートした独立企業として2025年9月に発表されました。Paradigm共同創業者のMatt Huang氏がリーダーを務め、Visa・Shopify・OpenAI・Deutsche Bankなどの企業がデザインパートナーとして設計に関するインプットを提供しています。
決済特化型ブロックチェーンの監査事例を組み込んだ意図は、今後拡大が見込まれるAIエージェントによるステーブルコイン決済領域にベンチマークの適用範囲を広げることにあります。DeFiレンディングやDEXとは異なる決済固有のスマートコントラクト設計に対しても、AIの監査能力を評価できるようにすることで、ベンチマークの実務的な接続性を高めています。
この設計方針は、EVMbenchが単なる学術的評価ツールではなく、実際の金融インフラに関わるセキュリティ課題を射程に入れていることを明確にしています。Tempoは5億ドルの資金調達を完了し評価額50億ドルとされるなど大規模なプロジェクトに成長しており、決済系コントラクト特有の脆弱性パターンに対するAI評価の需要は今後さらに高まると予想されます。
OpenAIとParadigmが共同設計した120件の脆弱性ベース評価フレームワークの全体像
EVMbenchは、OpenAIとParadigmの共同開発により、120件の厳選された高重大度脆弱性をベースに構築された評価フレームワークです。単にAIモデルにテスト問題を解かせるのではなく、実際のスマートコントラクト環境を再現し、検出から修正、攻撃実行までを一貫して測定できる設計になっています。この章では、データセットの選定基準からインフラ設計、品質管理、公開方針までフレームワーク全体の構造を解説します。
40件の監査レポートから厳選した120件の高重大度脆弱性の選定基準
EVMbenchのデータセットは、40件の独立したセキュリティ監査から抽出された120件の脆弱性で構成されています。これらの脆弱性はすべて高重大度に分類されたものであり、実際にエクスプロイト可能な資金流出リスクを伴うケースが選ばれています。大半はCode4renaなどの競争型監査コンテストで発見・検証されたものです。
選定にあたっては、各脆弱性に対して既存のProof-of-Concept(PoC)エクスプロイトテストやデプロイスクリプトが存在するかどうかが確認され、存在しない場合は新たに手動で作成されました。この作業により、すべてのベンチマークタスクが実行可能かつ検証可能な状態に整えられています。Patchモード用には、脆弱性がエクスプロイト可能でありながらコンパイルエラーを起こさずに修正可能であることも事前に確認されました。
Paradigmが提供するスマートコントラクト監査の専門知識に加え、自動化されたタスク監査エージェントも品質管理に活用されています。こうした多層的な選定・検証プロセスにより、ベンチマークデータの信頼性が担保されています。
Rust製ハーネスによる決定的コントラクトデプロイと再現可能性の確保手法
EVMbenchの評価基盤には、Rustで開発された専用のテストハーネスが採用されています。このハーネスは、スマートコントラクトを決定的にデプロイし、エージェントが発行したトランザクションを隔離されたグレーダーコンテナ内で再実行する仕組みを提供します。決定的デプロイとは、同じ入力に対して常に同一の結果が得られることを意味し、評価の再現可能性を保証する重要な要素です。
ハーネスはまた、安全でないRPCメソッドの呼び出しを制限する機能も備えています。これにより、エージェントがテスト環境を不正に操作してスコアを水増しするような行為を防止できます。トランザクションの再実行はローカル環境上で逐次的に行われるため、各エージェントの挙動を正確にトレースすることが可能です。
Rust言語が選択された背景には、メモリ安全性と高いパフォーマンスの両立があると考えられます。大量のトランザクションリプレイを安定的に処理しつつ、グレーディングの正確性を維持するうえで、Rustの特性は適しています。研究者が異なるマシン環境で同一の結果を再現できることは、ベンチマークとしての信頼性に直結します。
ローカルAnvil環境で本番ネットワークから隔離するサンドボックス設計の要点
EVMbenchのすべてのExploitタスクは、本番のブロックチェーンネットワークではなく、ローカルのAnvil環境上で実行されます。Anvilは、Foundryツールチェーンに含まれるローカルEthereumノードであり、テスト用途に特化した高速かつ軽量な実行環境を提供します。この設計により、実際の資産をリスクにさらすことなくエクスプロイトの実行を安全にテストできます。
チェーン状態はクリーンなローカルインスタンスとして初期化され、メインネットのフォーク状態ではありません。そのため、一部のタスクでは本番環境にデプロイされたコントラクトの代わりにモックコントラクトが使用されます。この制約はベンチマークの評価範囲を限定する要因でもありますが、テスト結果の決定性と安全性を優先した設計判断です。
サンドボックス環境を使用することで、研究者はEVMbenchを自由に繰り返し実行し、異なるモデルやエージェント構成を試すことができます。本番ネットワークに依存しないため、ネットワーク状態の変動によるスコアのゆらぎが排除され、純粋にAIエージェントの能力差を測定できる点が大きな利点です。
不正スコア取得を防ぐためのグレーダーレッドチーミングと品質管理工程
EVMbenchのExploitモードでは、エージェントの攻撃成否を判定するカスタムグレーダーが各タスクに用意されています。OpenAIの開発チームは、このグレーダー自体に対してレッドチーミングを実施し、エージェントがグレーダーを欺いてスコアを不正に取得する方法がないかを検証しました。発見された抜け穴は修正され、採点の堅牢性が高められています。
品質管理の工程は、Paradigmが提供するスマートコントラクトセキュリティの専門知識に支えられています。さらに、自動化されたタスク監査エージェントを活用して、テスト環境の健全性を体系的に検証しています。人間の専門家による審査とAIによる自動監査を組み合わせることで、ベンチマークの信頼性を多面的に確保しています。
ただし、OpenAIはグレーディングシステムが完全ではないことも認めています。特にDetectモードでは、エージェントが人間の監査者が見つけられなかった脆弱性を報告した場合、それが真の脆弱性なのか偽陽性なのかを判別する仕組みが現状では存在しません。この課題はベンチマークの今後の改善点として明示されています。
GitHubでのタスク・ツール・評価フレームワーク全公開によるオープンソース方針
EVMbenchのタスクデータ、ツールチェーン、評価フレームワークは、GitHubを通じてすべて公開されています。OpenAIはこのオープンソース方針について、AIのサイバー能力の測定と管理に関する継続的な研究を支援する目的であると説明しています。研究者やセキュリティチームが自由にベンチマークを実行し、モデル間の比較や新手法の検証に活用できる環境が整えられました。
公開リポジトリには、各ベンチマークタスクの脆弱性コード、デプロイスクリプト、グレーダー、ドキュメントが含まれています。これにより、第三者がOpenAIの公表した結果を独立に検証することも可能です。再現性の確保はベンチマークの信用に直結するため、このオープン化の判断はコミュニティからも評価されています。
一方、エクスプロイト手法を含むデータセットの公開にはデュアルユースのリスクも伴います。OpenAIは使用されている脆弱性がすべて過去に公開済みのものであることを強調しつつ、安全訓練やアクセス制御といった緩和策と併せて提供することで、防御目的での活用を促進する姿勢を示しています。
Detect・Patch・Exploitの3モードで測定するAIエージェントのセキュリティ能力
EVMbenchは、AIエージェントのスマートコントラクトセキュリティ能力を3つの独立したモードで評価します。Detectモードは脆弱性の発見力、Patchモードは修正の正確性、Exploitモードは攻撃の完遂能力をそれぞれ測定する設計です。この章では各モードの評価ロジックと、モード間で浮かび上がるAIの行動特性の違いを詳しく見ていきます。
Detectモードで監査報酬ベースのリコール率を測る脆弱性発見評価の仕組み
Detectモードでは、AIエージェントがスマートコントラクトのリポジトリ全体を監査し、既知の脆弱性をどれだけ正確に発見できるかが評価されます。採点の基準はリコール率、すなわち人間の監査者が過去に特定したグラウンドトゥルース脆弱性のうち、エージェントが正しく検出できた割合です。
さらに、EVMbenchでは各脆弱性にCode4renaの監査報酬額が紐づけられており、検出結果を金額ベースで定量化する「Detect Award」指標も導入されています。単に脆弱性の件数を数えるだけでなく、経済的インパクトの大きい脆弱性をどれだけ見つけられるかという観点で評価できるため、実務的な有用性の指標として機能します。
ただし、Detectモードにはエージェントが「想定外の脆弱性」を報告した場合の評価問題があります。グレーダーは人間の監査者が発見した脆弱性のみをグラウンドトゥルースとして扱うため、エージェントが人間の見落としを発見した可能性と、単なる偽陽性を区別できません。この制約はベンチマークの限界として明記されています。
Patchモードで既存テスト通過とエクスプロイト排除を同時に検証する採点基準
Patchモードは、AIエージェントに脆弱なスマートコントラクトのコードを修正させ、脆弱性の排除と既存機能の維持を同時に達成できるかを評価します。採点では、修正後のコードに対して自動テストが実行され、元のテストスイート(脆弱なロジックに依存するものを除く)がすべて通過すること、そしてエクスプロイトが失敗することの両方が確認されます。
この二重検証の仕組みは、実務におけるパッチ適用の難しさを反映しています。現実のスマートコントラクト修正では、脆弱性を塞ぐことに成功しても、別の機能が壊れるリグレッションが頻繁に発生します。EVMbenchのPatchモードは、まさにこの「直したつもりが壊れている」問題をAIがどの程度回避できるかを測定する設計です。
実験結果では、多くのモデルがPatchモードで相対的に低いスコアを記録しています。脆弱性の微細な修正には、コントラクト全体の設計意図やエッジケースへの深い理解が求められるため、現行のAIエージェントにとって最も困難なタスクの一つとされています。
Exploitモードでオンチェーン残高変動を判定する資金奪取攻撃の成否評価
Exploitモードでは、AIエージェントがサンドボックス化されたブロックチェーン環境上にデプロイされた脆弱なコントラクトに対し、実際に資金を奪取するエンドツーエンドの攻撃を実行します。成否はプログラム的に判定され、トランザクションリプレイとオンチェーンの残高変動やイベント発火といった決定的な指標に基づいて採点されます。
このモードでAIエージェントが最も高いスコアを記録している理由は、目標が明確であることにあるとOpenAIは分析しています。「資金を奪い取るまで反復する」という単純かつ明確なゴール設定が、AIの反復的な問題解決能力と相性が良いためです。Detectのように「すべてを網羅的に調べる」タスクや、Patchのように「壊さずに直す」タスクとは性質が異なります。
Exploitモードの評価環境はコンテナ化されており、異なるマシンやテスト実行間で結果を再現できるように設計されています。ただし、トランザクションはグレーダーコンテナ内で逐次的にリプレイされるため、精密なタイミングに依存する攻撃手法はスコープ外となっています。
3モード間でAIの得意・不得意が分かれる行動特性の違いと実務的示唆
EVMbenchの評価結果は、3つのモード間でAIエージェントの行動パターンに顕著な差異があることを明らかにしています。Exploitモードでは目標が明確なため高スコアを達成する一方、Detectモードではエージェントが1つの脆弱性を発見した時点で探索を停止してしまう傾向が観察されました。網羅的な監査よりも「見つけて終わり」の行動に陥りやすい点は、実務での活用における重要な注意事項です。
Patchモードでは、微妙な脆弱性を除去しつつコントラクトの意図した動作を完全に保持するという高度な要件が障壁となっています。エージェントは脆弱性自体を認識していても、修正によって既存機能を破壊してしまうケースが多く報告されています。この傾向は、AIが個々のコード変更の局所的な影響を把握できても、コントラクト全体の設計前提を理解する能力がまだ不十分であることを示唆しています。
実務への示唆として、AIエージェントはExploitベースのレッドチーミングには即座に活用しやすい一方、Detect・Patchの工程では人間の監査者との併用が現時点では不可欠という結論が導かれます。自動化と人手のハイブリッド運用を前提とした監査ワークフローの設計が、現段階では最も現実的なアプローチといえます。
ヒント付与による低・中・高レベル補助がスコアに与える影響の実験結果
EVMbenchの論文では、エージェントに異なるレベルのヒントを付与した場合の性能変化も検証されています。低レベルヒントは調査すべき特定のファイルを指示し、中レベルヒントは注目すべきメカニズムを示し、高レベルヒント(Exploitタスクのみ)はさらに具体的な攻撃方針を提供します。
実験結果では、ヒントの付与によりPatchモードとExploitモードのスコアが大幅に向上することが確認されました。この結果は、現在のAIエージェントにとって「脆弱性の発見」が最大のボトルネックであり、どこを見ればよいかが分かれば修正やエクスプロイト自体の遂行能力は相対的に高いことを示しています。
この知見は実務面でも重要な意味を持ちます。人間の監査者が大まかな調査範囲や疑わしい箇所を指定し、AIエージェントが詳細な分析と修正・攻撃検証を担当するという分業モデルが有効であることを裏付けているからです。ヒントの粒度とスコア向上の関係は、AI監査ツールの導入設計において最適な補助レベルを検討する際の参考データとなります。
GPT-5.3-CodexからClaude Opus 4.6まで主要モデルが示した性能差と傾向
EVMbenchでは、OpenAI・Anthropic・Googleの主要AIモデルが同一の評価基盤上で比較テストされました。モデルごとに得意なモードや行動傾向が異なり、スキャフォールド(エージェント実行基盤)の選択もスコアに大きく影響することが明らかになっています。この章では、公表されたスコアデータをもとに各モデルの性能差と、そこから読み取れる傾向を解説します。
Exploitモードで72.2%を達成したGPT-5.3-Codexと半年前31.9%からの急伸
Exploitモードにおいて最も高いスコアを記録したのは、OpenAIのGPT-5.3-Codexです。Codex CLIを通じて実行された同モデルは72.2%の成功率を達成しました。わずか半年前にリリースされたGPT-5のExploitスコアが31.9%であったことを考えると、2倍以上の性能向上が短期間で実現したことになります。
Paradigmのパートナーであるアルピン・ユクセログル氏も、プロジェクト開始時にはトップモデルでもCode4renaの重大脆弱性の20%未満しかエクスプロイトできなかったと述べており、現在の70%超えは劇的な進歩として位置づけられています。この急速な能力向上は、AIによるスマートコントラクト攻撃のリスクが加速度的に高まっていることを示す一方で、防御目的での活用ポテンシャルの大きさも同時に示しています。
GPT-5.3-Codexは高い性能を維持しつつ、トークン効率の面でも優位性を示しました。論文中のデータでは、出力トークン数あたりの正答率で効率的なパフォーマンスを発揮していることが確認されており、運用コストの観点からも実用性が高いと評価できます。
Detect報酬トップの37,824ドルを記録したClaude Opus 4.6の強みと特徴
Detectモードにおいて最も高い平均Detect Awardを記録したのは、AnthropicのClaude Opus 4.6でした。Claude Code経由で実行された同モデルは、平均37,824ドルのDetect Awardを獲得し、OpenAIのOC-GPT-5.2(31,623ドル)やGoogleのGemini 3 Pro(25,112ドル)を上回っています。
Claude Opus 4.6がDetectモードで優位に立った要因としては、長大なコードベースに対する網羅的な分析能力が挙げられます。Detectモードではエージェントが1つの脆弱性を見つけた後に探索を停止しがちであるという一般的傾向が報告されている中、Claude Opus 4.6は相対的に網羅的な監査を維持できた可能性があります。
また、Detectモードのリコール率でも45.6%と最高値を記録しています。ただし、すべてのモデルが獲得可能な報酬総額に対して大幅に低い水準にとどまっていることも論文で指摘されており、AIエージェントによる脆弱性検出は依然として改善の余地が大きい領域です。
GPT-5.2・Gemini 3 Proを含む主要6モデルの3モード横断スコア比較
EVMbenchの論文では、OpenAI o3、GPT-5、GPT-5.2、GPT-5.3-Codex、Claude Opus 4.6、Gemini 3 Proを含む主要モデルの3モード横断評価が実施されています。各モデルの得意領域は明確に分かれており、単一のスコアだけではAIのセキュリティ能力を総合的に判断できないことが示されました。
| モデル名 | Exploitスコア | Detect Award(平均) | 特記事項 |
|---|---|---|---|
| GPT-5.3-Codex | 72.2% | — | Exploit最高・トークン効率良好 |
| Claude Opus 4.6 | — | $37,824 | Detect Award最高・リコール率45.6% |
| OC-GPT-5.2 | — | $31,623 | Codex CLI使用時にスコア向上 |
| Gemini 3 Pro | — | $25,112 | Detect Award第3位 |
| GPT-5 | 31.9% | — | 約半年前のベースライン |
| OpenAI o3 | — | — | 論文内で比較対象として記載 |
上記の表は公開された主要データを整理したものです。Patchモードの個別スコアについては、GPT-5.3-Codexが41.5%を記録したことが論文に記載されていますが、全モデルの詳細なPatchスコアは部分的な公開にとどまっています。モデル選定の際は、ExploitだけでなくDetect・Patchの性能バランスを含めた総合評価が重要です。
Codex CLIとOpenCodeのスキャフォールド差がモデル性能に与える実測影響
EVMbenchの評価結果からは、同じモデルファミリーであってもスキャフォールド(エージェント実行基盤)の違いがスコアに顕著な影響を与えることが判明しています。具体的には、GPT-5.2をCodex CLI経由で実行した場合と、OpenCode経由で実行した場合とでスコアに明確な差が生じました。Codex CLIを使用した方がスコアが高く、ツールチェーンの設計がモデルの実力発揮に直結することが示されています。
この結果は、AIモデル単体の性能だけでなく、実行環境・ワークフロー・ツール連携の最適化がベンチマーク結果に大きく寄与することを意味します。論文でも、モデル品質とスキャフォールドを分離して評価することの重要性が強調されており、AIセキュリティツールの導入時にはモデル選定だけでなく実行基盤の選択が成果を左右するという実務的な教訓を提供しています。
開発チームや監査企業がEVMbenchの結果を参考にAIツールを選定する際は、公表スコアがどのスキャフォールドで取得されたかを確認し、自社の運用環境との整合性を検討することが推奨されます。同一モデルでもツール統合の質によって成果が変わるため、PoC段階での自社環境テストが不可欠です。
トークン効率と正答率の関係から見るコスト対効果の判断基準
EVMbenchの論文には、各モデルの出力トークン数とスコアの関係を示すデータが含まれています。GPT-5.3-Codexは高いExploitスコアを達成しながらもトークン消費量が比較的抑えられており、トークン効率の観点で優れたパフォーマンスを示しました。一方、他のモデルではスコア向上のために大幅に多くのトークンを消費する傾向が見られます。
AIエージェントをスマートコントラクト監査に導入する場合、APIの利用コストは無視できない運用上の要素です。1回の監査でどの程度のトークンが消費され、そのコストに見合う脆弱性発見・修正の成果が得られるかは、ツール選定における重要な判断基準となります。Detect Award指標と消費トークン数を組み合わせれば、1ドルあたりの脆弱性検出効率を試算することも可能です。
特に中小規模のプロジェクトでは監査予算に制約があるため、トークン効率の高いモデルを選択するか、ヒント付与で効率を上げるかといった戦略的な判断が求められます。EVMbenchのデータは、こうした費用対効果の検討に具体的な数値的根拠を提供する点でも価値があります。
メインネット再現やタイミング依存を含む現行版EVMbenchの構造的制約
EVMbenchはスマートコントラクトセキュリティにおけるAI評価の先駆的なベンチマークですが、OpenAI自身が複数の構造的制約を認めています。これらの制約を正確に理解することは、ベンチマーク結果を過大評価せず適切に解釈するために不可欠です。この章では、現行版EVMbenchが対応できていない領域と、それが評価結果にどのような影響を与えうるかを整理します。
タイミング依存型攻撃を再現できないトランザクション逐次リプレイの限界
EVMbenchのグレーダーは、エージェントが発行したトランザクションを隔離コンテナ内で逐次的にリプレイする方式を採用しています。この設計は再現性と安全性を確保する反面、トランザクションの実行順序やブロック生成のタイミングに依存する攻撃手法をスコープ外としています。
実際のブロックチェーン上では、フロントランニングやサンドイッチ攻撃、フラッシュローンを組み合わせた時間依存型のエクスプロイトが数多く発生しています。これらの攻撃は、特定のブロック内でトランザクションの順序を操作することで成立するものであり、逐次リプレイ環境では構造的に再現できません。
この制約は、EVMbenchのExploitスコアが実世界における攻撃能力の全体像を反映しているわけではないことを意味します。タイミング依存型攻撃への対応能力は別途評価する必要があり、今後のベンチマーク拡張において重要な改善領域の一つとなると見込まれます。
シングルチェーン環境のみ対応でクロスチェーン脆弱性が評価外となる制約
現行のEVMbenchはシングルチェーン環境のみをサポートしており、クロスチェーンブリッジやマルチチェーン間の相互作用に起因する脆弱性は評価対象外です。近年のDeFiでは異なるブロックチェーン間の資産移転が一般化しており、クロスチェーンブリッジの脆弱性を悪用した大規模な被害事例も複数報告されています。
クロスチェーン攻撃は、複数のチェーン上でのトランザクション状態の不整合や、ブリッジコントラクトのバリデーションロジックの欠陥を突くものが多く、単一チェーンの分析だけでは捕捉できない構造的なリスクを含みます。EVMbenchが将来的にマルチチェーン環境に対応すれば、より包括的なセキュリティ評価が可能になるでしょう。
現時点では、クロスチェーン関連のセキュリティ評価はEVMbenchのスコープ外であることを認識したうえで、別途の評価手段と組み合わせて総合的にAIの監査能力を判断する必要があります。特にブリッジプロトコルの開発・運用に関わるチームにとっては、この制約は留意すべきポイントです。
Detectモードで人間の見落としと偽陽性を区別できないグレーダー精度の課題
Detectモードのグレーダーは、人間の監査者が過去に特定した脆弱性をグラウンドトゥルースとして設定し、AIエージェントのリコール率を測定します。しかし、エージェントがグラウンドトゥルースに含まれない脆弱性を報告した場合、それが真の脆弱性なのか偽陽性なのかを現行のシステムでは判別できません。
この問題は双方向のバイアスを生みます。AIが本当に人間より優れた検出を行っていたとしても、それがスコアに反映されない可能性がある一方で、大量の偽陽性を出力するモデルに対してペナルティが十分に課されないリスクもあります。実務においては、偽陽性が多いツールは監査者の確認負荷を増大させるため、精度とリコールのバランスが重要です。
OpenAIはこの点をベンチマークの限界として明記しており、今後の改善では人間監査者のベースラインを超える発見を検証する仕組みの導入が課題となります。現段階では、DetectスコアはAIの「最低限の検出能力」を示す指標として解釈するのが適切です。
Code4rena由来データとメインネット本番コントラクトの難易度ギャップ
EVMbenchに含まれる脆弱性はCode4renaの監査コンテスト由来が中心であり、実際にメインネット上で大規模に運用されているプロトコルのコントラクトとは難易度が異なる可能性があります。OpenAI自身が論文で述べているように、広く利用されるDeFiプロトコルはコンテスト以上に厳格な精査を受けており、攻撃の難度も相応に高くなります。
コンテスト用のコードベースは、監査者が限られた時間内で脆弱性を発見する前提で提供されるものであり、本番環境のプロトコルが受ける複数回の監査・形式検証・長期間の運用実績による強化とは条件が異なります。したがって、EVMbenchで高スコアを記録したモデルが即座に本番レベルの監査品質を保証するわけではありません。
この難易度ギャップを認識したうえでEVMbenchの結果を参照することが重要です。ベンチマークは「AIモデル間の相対的な能力比較」と「性能の時系列的な進歩追跡」に最も適しており、絶対的な監査品質の保証としてではなく、能力測定のツールとして活用するべきものです。
モック状態依存のExploit環境が実際のDeFiプロトコルと乖離する具体的場面
Exploitモードで使用されるチェーン状態はクリーンなローカルAnvilインスタンスであり、メインネットのフォーク状態ではありません。そのため、一部のタスクではメインネット上に実在するコントラクトの代わりにモックコントラクトが使用されています。この設計は再現性を優先した結果ですが、実際のDeFiプロトコルが持つ複雑な状態依存性を完全には再現できません。
具体的には、大量の流動性プールや複数のプロトコル間の相互依存関係、ガバナンストークンの投票状態といったメインネット固有の条件が反映されないケースがあります。実際の攻撃では、これらの環境条件がエクスプロイトの成否を左右する要因となることも少なくありません。
モック環境に依存するExploitスコアは、エージェントの「攻撃ロジック構築能力」を測定するものとして有効ですが、メインネットの複雑な条件下で同等の結果を再現できるかは別問題です。今後、メインネットフォーク環境への対応が実現すれば、より実践的な評価が可能になると期待されます。
スマートコントラクト監査へのAIエージェント導入で押さえるべき実務上の要点
EVMbenchの評価結果は、AIエージェントがスマートコントラクト監査において一定の能力を示す一方で、単独での運用には課題が残ることを明確にしました。この章では、ベンチマークの知見を実務に応用する際に押さえておくべきポイントを、運用設計から費用対効果の試算までカバーします。
Detectの網羅性不足を補うために人間監査と組み合わせるハイブリッド運用設計
EVMbenchのDetectモードで観察された最大の課題は、AIエージェントが1つの脆弱性を発見すると探索を停止してしまう傾向です。この行動パターンは、コードベース全体の網羅的な監査が求められる実務では大きなリスクとなります。したがって、現段階ではAI単独の監査ではなく、人間の監査者と組み合わせたハイブリッド運用が推奨されます。
具体的な運用設計としては、AIエージェントによる初期スキャンで候補脆弱性を抽出し、人間の監査者がその結果を検証しつつ、AIが見落とした領域を補完するという二段階プロセスが考えられます。ヒント実験の結果からも、調査範囲を人間が指定することでAIのパフォーマンスが向上することが確認されており、この分業モデルの有効性を裏付けています。
ハイブリッド運用では、AIの検出結果に含まれる偽陽性の確認負荷も考慮する必要があります。偽陽性率の高いモデルを使用した場合、人間の確認コストがAI導入で削減されるはずだった工数を上回る可能性もあるため、モデル選定と運用フローのバランス設計が鍵となります。
Patch適用時に既存機能を破壊しないためのテスト戦略と回帰検証の手順
Patchモードで顕在化した課題は、AIが脆弱性を修正する際に既存の機能を意図せず破壊してしまうリグレッションの発生です。この問題を実務で管理するためには、AIが生成したパッチを適用する前に包括的なテスト戦略を整備しておく必要があります。
- 既存の単体テスト・統合テストスイートをすべて通過することを確認する
- エクスプロイトテスト(修正対象の脆弱性を突く攻撃)が確実に失敗することを検証する
- ファジングツールによるエッジケースの自動探索を実行する
- 形式検証が適用可能な箇所では数学的な正当性証明を併用する
- ステージング環境で一定期間の挙動監視を行い、予期しない状態遷移がないか確認する
上記の手順を体系化しておくことで、AIが提案したパッチの安全性を段階的に検証できます。EVMbenchのPatch採点でも、既存テスト通過とエクスプロイト排除の二重検証が行われており、実務での検証プロセスもこの考え方を踏襲することが合理的です。
Exploit能力を防御側に転用するレッドチーム演習の導入ステップと効果測定
EVMbenchのExploitモードで最も高いスコアが観察されたという事実は、AIエージェントの攻撃遂行能力が防御能力を上回る段階にあることを示しています。しかし、この攻撃能力は防御側にとっても強力な武器になります。AIエージェントを自社プロトコルに対するレッドチーム演習に活用することで、デプロイ前に脆弱性の悪用可能性を検証できます。
導入ステップとしては、まずサンドボックス環境を構築し、自社コントラクトをデプロイしたうえでAIエージェントにエクスプロイトを試行させます。成功した攻撃パターンを分析し、対応するパッチを開発してから再度エージェントに攻撃させるという反復サイクルを回すことで、セキュリティの堅牢性を段階的に高められます。
効果測定の指標としては、エージェントが成功する攻撃ベクトルの数、攻撃成功までの所要時間、修正後の再攻撃での成功率低下幅などが有用です。EVMbenchのExploitスコアリング手法を自社の評価プロセスに応用すれば、客観的な指標に基づいたセキュリティ改善サイクルを確立できます。
監査コンテスト報酬モデルに学ぶAIエージェント費用対効果の試算方法
EVMbenchのDetect Award指標は、AIエージェントの検出能力を金額ベースで評価する仕組みです。この指標は、Code4renaなどの監査コンテストで脆弱性の発見に対して支払われる報酬額に基づいています。実務でAIエージェントの導入を検討する際、このモデルを応用した費用対効果の試算が可能です。
試算の基本的な考え方としては、AIエージェントの利用にかかるAPIコスト(消費トークン数×トークン単価)を分子に、期待されるDetect Award相当額を分母に置いて投資対効果を算出します。EVMbenchのデータでは、Claude Opus 4.6の平均Detect Awardが37,824ドルと記録されており、これを基準に想定コストとの比率を検討することで導入判断の材料となります。
もちろん、Detect Awardは競争型監査の報酬体系に基づいた理論値であり、実際の損失回避額とは直接等しくありません。しかし、AIエージェント間の費用対効果を相対比較する指標としては十分に機能します。予算制約のあるプロジェクトでは、トークン効率の高いモデルやヒント付与による効率向上を組み合わせた運用が費用対効果を最大化する戦略となります。
ステーブルコイン決済拡大に伴う決済特化型コントラクト監査の優先項目
EVMbenchがTempoブロックチェーンの監査シナリオを組み込んだ背景には、AIエージェントによるステーブルコイン決済の拡大という将来予測があります。決済特化型のスマートコントラクトは、DeFiのレンディングプロトコルやDEXとは異なる設計パターンを持ち、監査においても固有の視点が求められます。
決済系コントラクトで優先すべき監査項目としては、送金ロジックの正確性、手数料計算の整合性、マルチシグやタイムロックなどのアクセス制御機構、そして高スループット環境下での並行処理における競合状態の有無が挙げられます。これらはDeFiプロトコル全般に共通する要素もありますが、決済特有の即時性要件やコンプライアンス対応との兼ね合いが加わる点が特徴的です。
EVMbenchにTempoシナリオが含まれていることは、こうした決済固有の脆弱性パターンに対するAI評価のニーズを先取りしたものといえます。ステーブルコイン決済の利用拡大に伴い、決済系コントラクトの監査需要は今後さらに増加すると予想され、AIエージェントの活用余地も大きい領域です。
1000万ドルAPI支援とAardvark拡張に見るOpenAIのサイバーセキュリティ構想
OpenAIはEVMbenchの公開と同時に、サイバーセキュリティ分野への包括的な投資計画を発表しました。1000万ドル規模のAPI支援やセキュリティ研究エージェントAardvarkの拡張は、ベンチマーク公開を単発のイベントではなく長期的なエコシステム構築の一環として位置づけていることを示しています。この章では、OpenAIのサイバーセキュリティ構想の全体像と、業界へのインパクトを分析します。
2023年開始のCybersecurity Grant Programから追加1000万ドル投資への発展経緯
OpenAIは2023年にCybersecurity Grant Programを立ち上げ、セキュリティ研究者やオープンソースプロジェクトへの支援を開始しました。EVMbenchの公開に合わせて追加された1000万ドルのAPIクレジットは、この既存プログラムの延長線上に位置づけられるものです。支援対象はオープンソースソフトウェアと重要インフラの防御研究に重点が置かれています。
1000万ドルという規模は、AIモデルのAPIを大量に活用するセキュリティ研究において実質的な推進力となります。スマートコントラクトの監査や脆弱性スキャンは大量のトークンを消費するタスクであり、APIコストが研究のボトルネックになるケースも少なくありません。この支援により、資金力に乏しい独立研究者やオープンソースコミュニティでもフロンティアモデルを用いた高度なセキュリティ研究を実施しやすくなります。
2023年の初期プログラムから今回の大規模追加投資への発展は、OpenAIがサイバーセキュリティを一時的な取り組みではなく戦略的な事業領域として位置づけていることを明確にしています。善意のセキュリティ研究に従事する組織はプログラムへの応募が可能であり、業界全体の防御力向上を目指す構想です。
プライベートベータ拡張中のAardvarkが担うセキュリティ研究エージェントの役割
EVMbenchの公開と並行して、OpenAIはAardvarkと呼ばれるセキュリティ研究エージェントのプライベートベータを拡張しています。Aardvarkは、OpenAIのAIモデルを活用してコードベースの脆弱性を自動的に検出・分析するための専用ツールであり、EVMbenchで測定されるような能力を実務に直接応用する製品と位置づけられます。
プライベートベータの拡張は、AardvarkがまだOpenAIの管理下でアクセスを制限された状態にあることを意味します。セキュリティツールの特性上、無制限の公開は攻撃目的での悪用リスクを伴うため、信頼されたセキュリティ研究者やパートナー組織に段階的にアクセスを広げるアプローチが採用されています。
Aardvarkの役割は、EVMbenchがベンチマークとして示した「AIエージェントのセキュリティ能力」を実運用レベルのツールに昇華させることにあります。ベンチマークで能力を測定し、Aardvarkで実務に展開するという二段構えの戦略は、研究と実用化の橋渡しとして機能しています。
オープンソースメンテナへの無償コードスキャン提供が狙う防御側エコシステム強化
OpenAIはEVMbenchの公開と合わせて、オープンソースプロジェクトのメンテナに対する無償コードベーススキャンの提供も発表しています。広く利用されているオープンソースプロジェクトのセキュリティ強化を支援することで、ブロックチェーンエコシステム全体の防御力を底上げすることが狙いです。
スマートコントラクトの多くはオープンソースとして公開されており、1つの基盤ライブラリに存在する脆弱性が複数のプロトコルに波及するリスクがあります。OpenZeppelinのようなスマートコントラクトライブラリは数千のプロジェクトで使用されているため、基盤レベルの脆弱性発見は影響範囲の大きさに直結します。
無償スキャンの提供は、オープンソースコミュニティとの協力関係を構築し、AIによるセキュリティ支援の実績を蓄積する意味もあります。防御側のエコシステムを強化することで、EVMbenchで明らかになった攻撃能力の進歩に対抗するための産業基盤を整えるという長期的な視点が反映されています。
安全訓練・アクセス制御・脅威インテリジェンスを組み合わせたデュアルユース対策
サイバーセキュリティ技術は本質的にデュアルユース(攻防両用)の性質を持つため、OpenAIはEVMbenchの公開にあたって複数の安全対策を併せて導入しています。具体的には、安全訓練による不正利用の抑制、信頼されたアクセス制御による高度機能の段階的開放、自動監視システム、そして脅威インテリジェンスを含む強制パイプラインが挙げられます。
EVMbenchに含まれるエクスプロイトデータやツールチェーンは、攻撃者にとっても有用な情報となりうるため、公開にあたっては過去に公開済みの脆弱性のみを使用するという制約が設けられています。未公開のゼロデイ脆弱性は含まれておらず、データセットの公開によって新たな攻撃ベクトルが生まれるリスクは抑制されています。
OpenAIがエビデンスベースかつ反復的なアプローチを掲げているのは、セキュリティ分野における完全な安全保証が困難であることを前提に、防御側の能力向上を加速しつつ悪用リスクを段階的に低減する戦略を採っているためです。この姿勢は、AI技術の責任ある発展を求める業界全体の潮流とも合致しています。
EVMbenchの長期標準化が業界のAI監査評価基準にもたらす変化の見通し
OpenAIはEVMbenchがスマートコントラクトセキュリティにおけるAI能力追跡の長期的な標準になることを期待しています。現状では、AI監査ツールの性能を客観的に比較する共通基盤が業界に存在しなかったため、EVMbenchの普及はツール選定や品質評価の透明性向上に寄与する可能性があります。
ベンチマークが標準化されることの最大のメリットは、モデルの進歩を時系列で追跡できることにあります。GPT-5からGPT-5.3-Codexへの急激なスコア向上が示すように、半年単位でAIのセキュリティ能力は大きく変化します。定期的にEVMbenchで測定を行うことで、どのモデルがどの時点でどの程度の能力を持つかを業界全体で共有できるようになります。
一方で、EVMbenchが唯一の評価基準となると、ベンチマーク最適化(ベンチマークのスコアだけを上げるための調整)のリスクも生じます。実務に即した多面的な評価を維持するためには、EVMbenchと並行して独自の評価プロセスを持つことが、監査企業やプロトコル開発チームにとって重要な判断となるでしょう。