LLM-discovered Zero-days ― AIのVulnerability Discoveryが「人間の処理能力」を超え始める
Executive Summary
Anthropicは2026年2月5日、Claude Opus 4.6をOpen Source Softwareへ適用し、500件超のHigh-severity Vulnerabilityを発見・Human Validationしたと報告しました。1
注目すべき点は、特殊なHarnessやTask-specific Toolingを大量に作り込まず、ModelがCode、Commit History、Debugger等を使って脆弱性を探索したことです。Anthropic自身も、90日Disclosure Windowのような従来の運用が、LLMによるFindingの速度・量に耐えられない可能性を指摘しています。
本Libraryでは、これは「AIが500件のZero-dayを完全自律でPatchした」という意味ではなく、AIによるDiscoveryのScaleがHuman Validation / Disclosure / Patch Capacityを新しいBottleneckへ変え始めた観測として扱います。
なぜ今なのか
脆弱性管理ではこれまで「どう見つけるか」が大きな課題でした。AIがDiscoveryを高速化すると、課題は「見つけた後に、どう検証し、責任ある開示を行い、Patchを作り、展開するか」へ移ります。
何が変わったのか
- Well-tested Open Source Codebaseから新規脆弱性を探索
- Commit HistoryやCode PatternをReasoningに利用
- Traditional Fuzzingで到達しにくいPathを分析
- Human ResearcherがFindingをValidation
- Initial PatchはHuman Reviewを伴って作成
- Finding増加に伴いPatch Development自動化も検討
経営インパクト
| 観点 | 影響 |
|---|---|
| Vulnerability Management | Finding件数ではなくValidation / Patch Throughputが制約になる |
| Open Source | 小規模Maintainerへ大量Findingが集中する可能性 |
| Product Security | Vendor自身がAI-assisted Discoveryを使う必要性が高まる |
| Disclosure | 既存の90日等の慣行を見直す議論が必要になる |
日本企業への示唆
AIによるVulnerability Discoveryを自社で使うかどうかに関係なく、VendorやResearcher側のFinding速度が上がる前提で、Critical AssetのPatch PriorityとEmergency Change Processを見直す必要があります。
推奨アクション
- Critical AssetごとのPatch / Mitigation SLAを定義する
- 大量Finding発生時のTriage Ruleを事前に決める
- Product SecurityでAI-assisted Reviewを評価する
- Open Source DependencyのOwner / Maintainer情報を把握する
- Compensating ControlをEmergency Patch Processへ組み込む
- 「Discovery件数」ではなくRemediation ThroughputをKPIに追加する
用語解説
Patch Capacity
発見された脆弱性を検証し、修正し、Testし、利用環境へ安全に展開できる組織・Vendorの処理能力。