Firefoxの脆弱性22件、2週間でClaudeが発見
AnthropicのClaudeは、Mozillaとのセキュリティ提携で2週間にFirefoxの脆弱性を22件見つけました。2026年3月6日に報告され、Mozillaはそのうち14件を重大度が高いと評価しています。大半はFirefox 148で修正されました。Anthropicによると、この14件は2025年に修正されたFirefoxの重大な欠陥のほぼ5分の1に相当します。ソフトウェア企業にとっては、AIが深刻なバグを素早く見つけられること、そして作業の中心がAIの報告を検証して直すことに移ることを示しています。
MozillaのブラウザがAIによるバグ探しの難しい試金石だった理由
Firefoxは世界で最もよくテストされているオープンソースプロジェクトの1つであり、Anthropicがこれを選んだ理由でもあります。同社は、Firefoxを選んだのは「複雑なコードベースであり、同時に世界で最もよくテストされ、安全なオープンソースプロジェクトの1つだから」と述べています。毎日数億人が使っており、ユーザーが絶えず信頼できないコンテンツを読み込むため、ブラウザの欠陥は危険です。
Mozillaのエンジニアが慎重になるのには理由がありました。Brian GrinsteadとChristian Hollerは、これまでのAI支援によるバグ検出システムでは結果にばらつきがあったと書いています。
AnthropicとMozillaが一緒に行ったこと
Anthropicのチームは2週間Claude Opus 4.6を使い、まずFirefoxのJavaScriptエンジンから始めて、ブラウザの他の部分へ広げました。このエンジンは単独で分析でき、Webから来る信頼できないコードを処理するため、出発点として好都合でした。
20分間の探索の後、Claudeは攻撃者がデータを上書きできるメモリの欠陥であるUse After Freeを報告しました。Anthropicの研究者3名が検証し、Claudeが書いた修正パッチを添えて、Mozillaの課題管理ツールBugzillaに登録しました。最初の報告を登録した時点で、Claudeはクラッシュを引き起こす固有の入力をさらに50件見つけていました。
報告がAIから修正へ進んだ流れ
Mozillaは対応に追いつくためプロセスを変えました。技術的な議論の後、Mozillaの研究者はAnthropicに、1件ずつ検証せずに発見をまとめて提出するよう依頼しました。チームは合計で約6,000個のC++ファイルをスキャンし、112件の固有の報告を提出しました。
「数時間のうちに、プラットフォームエンジニアが修正を取り込み始め、同じ手法をブラウザのコードベースの残りに適用するため、Anthropicと緊密な協力を始めました。」 — Brian GrinsteadとChristian Holler、Mozillaエンジニア
2週間のAIバグ探しで見つかったもの
結果は、22件のFirefoxの脆弱性と、22件のCVE発行でした。Mozillaはそのうち14件を重大度が高いと評価し、Anthropicはこれが2025年に修正されたFirefoxの重大な欠陥のほぼ5分の1に当たると述べています。2026年2月に見つかった22件は、2025年のどの月に報告された件数よりも多い数です。
修正の大半は2月にリリースされたFirefox 148に含まれ、残りは今後のリリースで提供される予定です。Mozillaの研究者はその後、社内のセキュリティ業務でClaudeを試し始めています。
Claudeが悪用よりバグ発見に強かった理由
Anthropicは、Claudeが欠陥を攻撃に変えられるかも試しました。テストを数百回実行し、APIクレジットに約4,000ドルを使いましたが、動作するエクスプロイトをClaudeが作れたのは2件だけでした。しかもそのエクスプロイトは、サンドボックスなどブラウザの保護機能の一部を外したテスト環境でしか動きませんでした。
Anthropicは2つの教訓を挙げています。Claudeは悪用よりバグ発見のほうがはるかに得意であること、そして欠陥を見つけるコストはエクスプロイトを作るコストより桁違いに低いことです。同社はまた、この差は長くは続かない可能性が高いと警告しています。
AIによるバグ探しがソフトウェア企業に意味すること
ソフトウェアを提供する企業にとっての課題は、攻撃者より先に深刻な欠陥を見つけることです。AIはその探索を速く安くしますが、メンテナーに報告が殺到する原因にもなります。Mozillaの答えは、どの発見が欲しいかをAnthropicに正確に伝え、まとめての提出を受け入れることでした。
Anthropicは、AIエージェントに「タスク検証器」、つまり自分の作業を確認できる信頼できる手段を与えることを勧めています。たとえば、バグがもう再現しないこと、修正が他に何も壊していないことを確かめるテストです。TechCrunchは、AIツールは有用なものと一緒に質の低いマージリクエストの洪水も持ち込みうると指摘しており、この確認の工程こそ、見込んでおくべき本当のコストです。
よくある質問
Claudeはいくつ脆弱性を見つけましたか?
Claude Opus 4.6は2週間で22件の脆弱性を見つけ、Mozillaはそのうち14件を重大度が高いと評価しました。大半はFirefox 148で修正されました。
Claudeは見つけたバグを悪用できましたか?
まれにしかできませんでした。数百回の試行の後、Claudeが粗いエクスプロイトを作れたのは2件で、しかもサンドボックスなどの保護を外したテスト環境だけでした。
MozillaはいまもセキュリティでClaudeを使っていますか?
Anthropicによると、Mozillaの研究者はその後、社内のセキュリティ目的でClaudeを試し始めています。
MOZGIIの視点
私たちならこう作ります
AIによるバグ発見は、いまや簡単なほうの半分です。難しいのはその後の待ち行列です。誰かが報告を1件ずつ確認し、重大度を判断し、修正を出さなければなりません。ソフトウェア企業向けに作るなら、モデルではなくこの待ち行列を中心にシステムを設計します。
モデルは、信頼できない入力が入ってくる場所から始めて、コードを一度に1か所ずつスキャンします。発見ごとに、クラッシュを再現するテストケースと修正案のパッチを付けます。人が目にする前に、別のツールがテストを再実行し、パッチでクラッシュが消えることを確かめ、既存のテストスイートを回してパッチが壊したものがないか調べます。通過した発見だけがセキュリティチームに届き、重大度の最終判断はチームが持ちます。
壊れるのは量の面です。人が1件を確認する間にモデルがクラッシュする入力を50件見つけるようでは、小さなチームは埋もれてしまいます。Mozillaがしたように、メンテナーがどの種類の発見を求めるかを最初に合意し、それ以外は自動で落とします。
追跡する指標は1つ、AIの報告のうちメンテナーが本物のセキュリティ欠陥と確認した割合です。下がったら、スキャンを広げる前にフィルターを直す必要があります。次に、同じ仕組みをパッチそのものに向け、バグを見つけたのと同じ厳しさで修正もテストします。
出典
この記事の事実の出典です。