AIモデルは現在、複雑なソフトウェアにおける高重要度の脆弱性を独立して特定できるようになりました。最近文書化したように、Claudeは十分にテストされたオープンソースソフトウェアで500以上のゼロデイ脆弱性（ソフトウェアの保守担当者に知られていないセキュリティ欠陥）を発見しました。
この投稿では、Claude Opus 4.6が2週間の間に22の脆弱性を発見したMozillaの研究者との協力の詳細を共有します。これらのうち、Mozillaは14を高重要度脆弱性として分類しました。これは2025年に修正されたFirefoxの高重要度脆弱性全体のほぼ5分の1に相当します。
言い換えれば、AIは深刻なセキュリティ脆弱性を大幅に加速された速度で検出することを可能にしています。
![Firefoxセキュリティ脆弱性報告（全ソース）月別グラフ。Claude Opus 4.6は2026年2月に22の脆弱性を発見し、これは2025年の任意の単月で報告された数を上回りました。]
この協力の一環として、Mozillaは私たちから大量の報告を受け取り、どのような種類の発見がバグレポートの提出に値するかを理解する手助けをし、Firefox 148.0で数億人のユーザーに修正を提供しました。彼らの提携と私たちが学んだ技術的教訓は、AI対応のセキュリティ研究者と保守担当者がこの瞬間に対応するために協力する方法のモデルを提供します。
モデル評価からセキュリティパートナーシップへ
2025年後半、Opus 4.5がCyberGym（LLMが既知のセキュリティ脆弱性を再現できるかをテストするベンチマーク）のすべてのタスクを解決に近づいていることに気づきました。現代のWebブラウザに存在するような、技術的に複雑な脆弱性がより高い濃度で含まれる、より困難で現実的な評価を構築したいと考えました。
そこで、Claudeがそれらを再現できるかを確認するために、過去のFirefoxの共通脆弱性識別子（CVE）のデータセットを構築しました。Firefoxを選んだのは、複雑なコードベースであると同時に、世界で最も十分にテストされ安全なオープンソースプロジェクトの一つだからです。これにより、モデルをテストするために以前使用したオープンソースソフトウェアよりも、AIの新規セキュリティ脆弱性発見能力のより困難なテストとなります。
数億人のユーザーが日常的に依存しており、ユーザーが信頼できないコンテンツに定期的に遭遇し、安全を保つためにブラウザに依存するため、ブラウザの脆弱性は特に危険です。
最初のステップは、Claudeを使用してFirefoxコードベースの古いバージョンで以前に特定されたCVEを見つけることでした。それぞれが発見に重要な人的努力を要したにもかかわらず、Opus 4.6がこれらの歴史的CVEの高い割合を再現できたことに驚きました。
しかし、これらの歴史的CVEの少なくとも一部がClaudeの訓練データに既に含まれている可能性があったため、この結果をどの程度信頼すべきかは不明でした。
そこで、Firefoxの現在のバージョンで新規の脆弱性、つまり定義上以前に報告されたことがないバグを見つけるタスクをClaudeに課しました。最初はFirefoxのJavaScriptエンジンに焦点を当て、その後ブラウザの他の領域に拡大しました。
JavaScriptエンジンは便利な最初のステップでした。Firefoxコードベースの独立したスライスで、単独で分析でき、広い攻撃面を持つため（ユーザーがWebを閲覧する際に信頼できない外部コードを処理する）、セキュリティ確保が特に重要です。
わずか20分の探索後、Claude Opus 4.6はJavaScriptエンジンでUse After Free（攻撃者が任意の悪意のあるコンテンツでデータを上書きできるメモリ脆弱性の一種）を特定したと報告しました。
私たちの研究者の一人が最新のFirefoxリリースで独立した仮想マシンでこのバグを検証し、それを他の2人のAnthropic研究者に転送し、彼らもバグを検証しました。その後、脆弱性の説明と根本原因のトリアージを支援するための提案パッチ（Claudeによって書かれ、報告チームによって検証された）とともに、MozillaのイシュートラッカーであるBugzillaにバグレポートを提出しました。
この最初の脆弱性をFirefoxに検証・提出している間に、Claudeは既に50以上のユニークなクラッシュ入力を発見していました。これらのクラッシュをトリアージしている間に、Mozillaの研究者が私たちに連絡してきました。
それぞれのプロセスについての技術的議論と、手動で検証したいくつかの脆弱性を共有した後、彼らは、すべてのクラッシュテストケースにセキュリティ上の影響があると確信していなくても、各発見を検証せずに一括ですべての発見を提出することを奨励しました。
この取り組みの終わりまでに、私たちはほぼ6,000のC++ファイルをスキャンし、上記の高・中重要度脆弱性を含む合計112のユニークなレポートを提出しました。ほとんどの問題はFirefox 148で修正され、残りは今後のリリースで修正される予定です。
外部ソフトウェアでこの種のバグハンティングを行う際、発見を偽陽性にするコードベースについて重要な何かを見逃している可能性があることを常に意識しています。バグを自分たちで検証するデューデリジェンスを行うよう努めていますが、常にエラーの余地があります。
Mozillaがトリアージプロセスについて非常に透明性を保ち、私たちが関心を持つテストケースのみを提出するようアプローチを調整する手助けをしてくれたことに非常に感謝しています（すべてがセキュリティに関連するものではなかったとしても）。
Mozillaの研究者は、その後内部でセキュリティ目的でClaudeを実験し始めています。
脆弱性の特定から原始的なエクスプロイトの作成まで
Claudeのサイバーセキュリティ能力の上限を測定するため、私たちが発見したバグのいずれかをClaudeが悪用できるかを判断する新しい評価も開発しました。言い換えれば、Claudeがハッカーがこれらのバグを利用して悪意のあるコードを実行するために使用するようなツールも開発できるかを理解したかったのです。
これを行うため、私たちがMozillaに提出した脆弱性へのアクセスをClaudeに与え、それぞれに焦点を当てたエクスプロイトを作成するよう求めました。脆弱性の悪用に成功したことを証明するため、実際の攻撃を実演するよう求めました。
具体的には、攻撃者が行うように、ターゲットシステムでローカルファイルを読み書きすることを要求しました。異なる開始点で数百回このテストを実行し、約4,000ドルのAPIクレジットを費やしました。
それにもかかわらず、Opus 4.6は実際に脆弱性をエクスプロイトに変えることができたのは2つのケースのみでした。これは2つのことを教えてくれます。
- Claudeはこれらのバグを悪用するよりも発見する方がはるかに優れている
- 脆弱性を特定するコストは、それらのエクスプロイトを作成するよりも桁違いに安い
しかし、Claudeが少数のケースでのみとはいえ、粗雑なブラウザエクスプロイトを自動的に開発できたという事実は懸念されます。
「粗雑」はここで重要な注意点です。Claudeが書いたエクスプロイトは、現代のブラウザに見られるセキュリティ機能の一部を意図的に削除した私たちのテスト環境でのみ動作しました。これには最も重要なものとして、この種の脆弱性の影響を軽減することを目的とするサンドボックスが含まれます。
したがって、Firefoxの「多層防御」はこれらの特定のエクスプロイトを軽減するのに効果的だったでしょう。しかし、サンドボックスを回避する脆弱性は前例がないわけではなく、Claudeの攻撃はエンドツーエンドエクスプロイトの必要な構成要素の一つです。
ClaudeがこれらのFirefoxエクスプロイトの一つをどのように開発したかについては、私たちのFrontier Red Teamブログで詳しく読むことができます。
AI対応サイバーセキュリティの次のステップ
AI対応エクスプロイト開発のこれらの初期兆候は、防御者の発見・修正プロセスを加速することの重要性を強調しています。その目的に向けて、この分析を実行している間に見つけた技術的・手続き的ベストプラクティスをいくつか共有したいと思います。
まず、LLMを使用してバグ修正を開発・検証する「パッチングエージェント」を研究する際、保守担当者がClaudeのようなLLMを使用してセキュリティレポートをより迅速にトリアージ・対処するのに役立つことを期待するいくつかの方法を開発しました。
私たちの経験では、Claudeは他のツールで自分の作業をチェックできる場合に最も効果的に動作します。私たちはこのクラスのツールを「タスク検証器」と呼んでいます。AIエージェントの出力が実際にその目標を達成するかを確認する信頼できる方法です。
タスク検証器は、エージェントがコードベースを探索する際にリアルタイムフィードバックを提供し、成功するまで深く反復することを可能にします。タスク検証器は上記のFirefox脆弱性の発見に役立ち、別の研究では、バグ修正にも有用であることがわかりました。
優れたパッチングエージェントは少なくとも2つのことを検証する必要があります：
- 脆弱性が実際に除去されたこと
- プログラムの意図された機能が保持されたこと
私たちの作業では、提案された修正後に元のバグがまだトリガーできるかを自動的にテストし、別途テストスイートを実行してリグレッション（他の何かを誤って壊す変更）をキャッチするツールを構築しました。
保守担当者は自分のコードベースに対してこれらの検証器を構築する方法を最もよく知っていると期待しています。重要な点は、エージェントにこれらの両方の特性をチェックする信頼できる方法を与えることで、その出力の品質が劇的に向上することです。
これらのテストに合格するすべてのエージェント生成パッチが即座にマージするのに十分良いことを保証することはできません。しかし、タスク検証器は、生成されたパッチが特定の脆弱性を修正しながらプログラム機能を保持する、つまり妥当なパッチの最小要件と考えられるものを達成するという信頼性を高めてくれます。
もちろん、AI作成のパッチをレビューする際、保守担当者は外部作成者によって作成された他のパッチに適用するのと同じ精査を適用することをお勧めします。
バグとパッチの提出プロセスにズームアウトすると、保守担当者が手一杯であることを知っています。したがって、私たちのアプローチは、保守担当者がレポートを信頼・検証するために必要な情報を提供することです。
Firefoxチームは、私たちの提出の3つの構成要素が結果を信頼するために重要であることを強調しました：
- 付随する最小テストケース
- 詳細な概念実証
- 候補パッチ
私たちは、LLM駆動の脆弱性研究ツールを使用する研究者に、そのようなツールの出力に基づくレポートを提出する際に、同様の検証と再現性の証拠を含めることを強く奨励します。
私たちはまた、保守担当者と協力する際に使用する手順を説明する協調脆弱性開示運用原則も公開しました。ここでの私たちのプロセスは当面標準的な業界規範に従いますが、モデルが改善されるにつれて、能力に歩調を合わせるためにプロセスを調整する必要があるかもしれません。
この瞬間の緊急性
フロンティア言語モデルは現在、世界クラスの脆弱性研究者です。Firefoxで特定した22のCVEに加えて、私たちはClaude Opus 4.6を使用してLinuxカーネルなどの他の重要なソフトウェアプロジェクトの脆弱性を発見しました。
今後数週間・数ヶ月にわたって、私たちのモデルをどのように使用し、オープンソースコミュニティと協力してセキュリティを改善しているかについて報告を続けます。
Opus 4.6は現在、脆弱性を悪用するよりも特定・修正する方がはるかに優れています。これは防御者に優位性を与えます。そして、限定的な研究プレビューでのClaude Code Securityの最近のリリースにより、私たちは脆弱性発見（およびパッチング）機能を顧客とオープンソース保守担当者に直接提供しています。
しかし、進歩の速度を見ると、フロンティアモデルの脆弱性発見と悪用能力の間のギャップが長く続く可能性は低いでしょう。将来の言語モデルがこの悪用の壁を突破した場合、私たちのモデルが悪意のある行為者によって悪用されることを防ぐために、追加の保護措置やその他の行動を検討する必要があります。
私たちは開発者に、ソフトウェアをより安全にする努力を倍加させるためにこの機会を活用することを強く求めます。私たちの側では、開発者と協力して脆弱性を検索すること（上記のCVDプロセスに従って）、支援ツールの開発を含む、サイバーセキュリティの取り組みを大幅に拡大する予定です。