トリアージこそが成果物：イーサリアムプロトコルコードに対するAIエージェントの実行

イーサリアム財団のプロトコルセキュリティチームは、調整されたAIエージェントを実行して実際のプロトコルコードを監査した経験についての技術記事を公開しました。記事はチームリーダーのNikos Baxevanis氏によって2026年7月9日に執筆されました。チームは、AIエージェントが実際の脆弱性を発見したこと（例：libp2pのgossipsubにおけるリモートトリガー可能なパニック、CVE-2026-34219として修正・開示）を認めつつも、真の課題は大量の候補結果から効率的に本物のセキュリティ問題を選別することにあると強調しています。

記事は、AIエージェントを本質的にファザーに似た探索ツールと位置づけていますが、ファザーがクラッシュとスタックトレースを返すのに対し、エージェントはコールチェーン、影響評価、深刻度の提案、実行可能な概念実証（PoC）など、より豊富な結果を返します。しかし、この豊富さゆえにノイズの問題が生じます——ほとんどの候補は誤りであるか、重複しているか、範囲外です。したがって、AIエージェントの効果を測る重要な指標は、生成された候補の数ではなく、そのうちどれだけが真の脆弱性として確認されたかです。

チームは分散型の協調アプローチを採用しました。複数のエージェントが並行して実行され、バージョン管理を通じて状態を共有し、中央調整者は不要です。ワークフローは4つの動的な役割で構成されます：偵察（攻撃面を具体的でテスト可能な仮説に変換）、狩猟（単一の仮説についてコードパスを追跡し再現器の構築を試みる）、ギャップ補填（受け入れられた結果と拒否された結果に基づいて新しい仮説を生成し、カバレッジを追跡）、検証（各候補を独立して再確認し、重複を排除し、最終判断を下す）。このアーキテクチャは、AnthropicがCコンパイラを構築する際に使用した「エージェントフリート」アプローチと、Cloudflareがセキュリティ研究で説明した類似のパイプラインに触発されたものです。

各候補が有効な発見と見なされるためには、厳格なスキーマを満たす必要があります：攻撃者が実際に到達可能なターゲット、保持すべき不変条件、具体的な破壊メカニズム、観察可能な失敗の証明、そして独立して実行可能な再現成果物。チームは特に再現性を最優先事項として強調しています——候補が実際のコード上で独立して実行できる再現プログラムを持たなければ、発見とは見なされません。一般的な偽陽性には、デバッグビルドでのみ発生するパニック、手動で構築された到達不能パスによるクラッシュ、形式検証における空虚な定理証明が含まれます。

信号対雑音比が作業の中心です。チームは独立した再確認、攻撃者のコストとネットワークへの影響の評価、既知の問題リストとの照合によって候補をフィルタリングします。受け入れ率はターゲットによって大きく異なります：成熟し十分に監査されたコードではほとんど候補が残りませんが、それ自体が価値のある結果です。記事はまた、AIエージェントが得意とする分野（仕様とコードの連携読み取り、実際の不変条件の表明と検証、単一のアイデアからの再現器の作成、根本原因の提案）と誤解を招きやすい分野（見かけ上到達可能なコールチェーン、成功チェックのゲーミング、深刻度の誇張、複数ステップのシーケンスにまたがるバグの検出困難）を列挙しています。後者については、エージェントはステートフルテストハーネスの提案者として適しており、その代替として使用してはいけません。

最後に、チームは結果の信頼性を確保するための実践をまとめています：すべてのアーティファクトに来歴を記録する、環境の決定性を確保する、スクリプトではなく規範でエージェントを導く、そして人間が最終判断を下す。著者は、AIがセキュリティ研究者を置き換えたのではなく、焦点をバグの発見からバグの信頼に移したと述べています——ボトルネックは依然として存在しますが、今や人間の判断が真に意味を持つ場所にあります。ツールの能力が急速に向上する中（著者はNicholas Carliniの指数関数的成長の見解を引用）、判断側の能力もそれに伴って向上しなければ、生成される候補と実際に検証されるものの間のギャップは広がる一方です。