レンダラーは落ちる前提で ― MozillaがAIで見つけた271個のバグがブラウザセキュリティに意味すること
Claude Mythosの初期バージョンが、Mozillaが単一のFirefoxリリースで271個のセキュリティバグを見つけるのに役立ちました。正しい反応はパニックでも祝福でもありません。自分たちが出荷する、使う、あるいはその上に構築するすべてのブラウザについて、今なお何を前提とすべきかを、静かに再調整することです。
より賢い監査者は、より多くのバグを見つけます。しかしそれは、レンダラーが3500万行の敵対的バイトのパーサーであるという事実を変えません。Mythosへの正しい反応は、安堵でも恐れでもありません。次のバグが通り抜けてくるものだと仮定して、設計し続けることです。
4月21日、Mozillaは「The zero-days are numbered」(「ゼロデイの日数は尽きた」)と題された 記事を公開しました。その中で同財団は、Firefox 150 が 271件のセキュリティ修正とともに出荷されたことを認めました。これらは、Anthropicの Claude Mythos(脆弱性リサーチ向けにチューニングされたフロンティアモデルで、Project Glasswing と呼ばれる管理されたパートナープログラムを通じて配布されている)の初期バージョンの評価中に発見されたものです。先行するFirefoxのリリース(バージョン148)では、Claude Opus 4.6 によって見つかった22個のバグがすでに含まれていました。単一のバージョンサイクルで22から271への跳躍は、まさに人々が最上級表現に手を伸ばしたくなる種類の数字です。
Mozillaは、その名誉のために言えば、そうしませんでした。CTOのBobby Holleyは The Registerに対し、これらの発見は自分のチームに「目まい」をもたらし、「そもそも追いつくことが可能なのか」という問いを投げかけた、と述べました。しかし彼はそれに、聞き逃しやすく、しかしとても重要な、抑制のきいた一文を並べました。「励みになることに、エリートな人間のリサーチャーが見つけられなかっただろうバグは、一つも見ていない。」
この一文こそが物語のすべてであり、本記事の主張そのものです。
この発表が実際に語っていること
見出しを取り除くと、Mozillaは3つのことを報告しています。
第一に、機械は今や、ごく少数のエリートな人間がすでに人間のペースでできていたことを、工業的なペースでできるようになっています。ブログはこのように直接的に述べています。「人間が見つけられる脆弱性のカテゴリや複雑さで、このモデルが見つけられないものはない。」これは能力の宣言です。「何が見つけられるか」の革命ではなく、「見つけられるものがどれほど速く見つかるか」の革命です。
第二に、AIツールが開発パイプラインにも浸透するにつれ、バグの複雑さが発見能力を上回る現実的な可能性があります。Mozilla自身の言葉を借りれば、「開発プロセスにおけるAIの増加の結果として、コードベースが人間の理解を超え始めるリスクがある」とのことです。人間にとっての理解可能性そのものが、ひとつのセキュリティ特性である、と記事は論じています。
第三に――そして誰もが投影しようとする地点ですが――Mozillaは楽観的です。「トンネルの向こうに光がある」とHolleyは語りました。「ディフェンダーはついに、決定的に勝てるチャンスを手にしている。」
我々は、第一の主張は正しく、第二の主張はそれが受けるであろう注目以上に注目に値し、第三の主張は監査の軍拡競争については正しく、その軍拡競争が実際に解決することについては誤っている、と考えています。
良いニュース、率直に言って
良いニュースを埋もれさせるのは不誠実なので、そのまま述べます。エリートな脆弱性リサーチの能力を、GPU時間でスケールするものに変えるツールは、ここ10年でブラウザセキュリティに起こったもっとも有用なことの一つです。C++で書かれた数百万行のコードベースに対して、たった1回のリリースサイクルで22から271への跳躍は、他のブラウザベンダーが真剣に受け取る種類のシグナルです。Chromiumのエンジニアたちは受け取るでしょう。WebKitのエンジニアたちも受け取るでしょう。libxml2、ICU、HarfBuzz、libwebp、そしてあらゆるブラウザが引き入れる他の100種類のパーサーをメンテしているチームも、時間が取れさえすれば、受け取るでしょう。
リリース前に修正されたバグが多いことは、少ないことより単純に良い。この271個のバグは、すべて内部での発見であり、パッチが出るまで誰にも開示されておらず、いずれかが実環境で悪用された形跡もありません。セキュリティリサーチの古い言い回しを借りれば、これらは「歩く死バグ」でした。Mozillaは、それが誰にもコストをかける機会を持つ前に、葬ったのです。
つまり、本物の前進です。ひそかに数字を埋めるのではなく、オープンに開示したMozillaには、本物の称賛を送るべきです。Mythosをサブスクリプション料金を払える誰にでも一般提供するのではなく、パートナープログラムの背後に置いておくAnthropicにも、本物の称賛を送るべきです。
そして、より難しい問い
一次の効果が「出荷前にはるかに多くのバグが修正される」だとすれば、二次の効果は「同じ能力が、Anthropicがアクセスを与えると決めた他の誰にとっても利用可能になっており、おおむね同等の能力は数四半期のうちに誰にでも利用可能になる」というものです。この二次の効果こそ、先行の記事ブラウザのゼロデイがなくならない理由が詳しく論じようとしたものです。ここで蒸し返すことはしません。その議論のうち今日関連する部分はこれです――ブラウザはあなたのコンピュータ上で動作する、信頼できないコンテンツのパース機構として単一最大のものであり、その種の機構におけるバグ探しの経済学は、全員の足元で同時にシフトしつつあります。
十分にリソースを持つディフェンダーが今や良い道具を手にしている、というMozillaの指摘は正しい。十分にリソースを持つオフェンダーも同様です。問題は、それがユーザーが実際に気にする数字――リリースごとに修正されるバグ数ではなく、誰かのメールボックスに実働のエクスプロイトとして落ちてくるバグ数――に対して、何をするか、です。
左の列がMythosの住処です。監査は――両側で――加速します。この加速は、ディフェンダーが先にそのツールを動かせるときに限り、ディフェンダーに非対称に有利です。Mozillaはそれをやりましたし、Chromiumもおそらくやっていますが、何百という小規模なブラウザやブラウザベースのアプリはおおむねやっていません。右の列の加速は存在しません。どれだけ監査しようと、モノリシックなインプロセスのレンダラーがそうでなくなることはありません。どれだけ監査しようと、レンダラーをキーチェーン、ファイルシステム、ウェブカメラ、ネットワークスタックから切り離すことはありません。問題の形は不変です。
依然として理にかなった姿勢
Mozillaは記事を、穏当な希望で締めくくっています――人間にとっての理解可能性をブラウザの第一級のセキュリティ特性として保ちつつ、バグ探しには機械の助けを借りよう、というものです。これは我々も共有する希望です。しかしそれは、このブログが立脚する希望ではありません。
Bromureが軸にしてきた姿勢は、レンダラーにいくつバグがあるかを予言しません。それが予言するのは、レンダラーには、誰もまだ見つけていないバグが常に少なくとも1つある――時にディフェンダーが先に到達し、時に攻撃者が先に到達する――ということ、そして、レンダラーの周囲のアーキテクチャがその不確実性を生存可能にしなければならない、ということです。
これはブラウザベンダーの売り文句ではありません。脅威モデルの選択です。Mythosが監査したレンダラーも、依然として敵対的入力に対してC++を実行するレンダラーです。メモリ安全なツールチェーンに関する次の論文、次世代のファザー、次のMythosは、レンダラーが今日侵害されたときにコンピュータ上で起こることを変えはしません――すでに人々のラップトップに入っている、そのバージョンのChromeやSafariやFirefoxの上では、です。
両方の図はいずれも本物の防御です。左の図は、ブラウザ業界全体が20年間投資してきたもので、いまやMythosとともに加速しています。これは本当に改善しつつあります。しかしそれは――構造的に――ベンダーが攻撃者より先にレースを終えることに依存する防御でもあります。そのレースが数ヶ月単位から数時間単位に圧縮されつつある今――実際そうなっています――防御は、あなたの機器がたまたまその窓の中で更新されたかどうか、という問いに狭まります。この窓は両側で同時に縮んでいます。
右の図はアーキテクチャ的です。バグをMozillaが見つけたのか、Anthropicが見つけたのか、2025年のOperation ForumTrollを動かしたのと同じ攻撃者集団が見つけたのか、まだ誰も見つけていないのか、を気にしません。異なる問いを立てます――レンダラーのバグが発火したとき、その「発火」は攻撃者が実際に何に触れる、という意味なのか?
Bromureが実際にやっていること、ひと息で
あらゆるタブが、Apple Silicon上の使い捨てLinux仮想マシンの中で動きます。レンダラー――V8、Blink、WebPデコーダー、Dawn、Mythosクラスの監査者がバグを見つけているどのパーサーも――は、そのゲストの中で動き、決してホスト上では動きません。レンダラーの侵害が発火したとき、攻撃者はそのゲストの中にいます。そのゲストにはあなたのDocumentsフォルダ、キーチェーン、iCloud Drive、ローカルネットワーク、カメラ、マイクは含まれていません。含まれているのは、ブラウザと、プロファイルと、そのプロファイルが蓄えた状態だけです。ウィンドウが閉じれば、ゲストは破棄されます。始まるすべてのブラウザセッションは、まっさらな状態から始まります。
これはレンダラーのバグが重要でない、という主張ではありません。重要です。侵害されたタブに入力されたパスワードは、依然としてそのタブに入力されます。侵害されたプロファイルが保持するクッキーは、依然としてそのプロファイルの侵害によって手が届きます。エクスプロイトの窓の間にセッションに渡された入力は、射程内です。射程にないのは、それが同じVMの中にないからこそ、コンピュータの残りの部分です――そしてコンピュータの残りこそが、永続化、横方向移動、そして実際のダメージの大半が住む場所なのです。
この記事が言っていない2つのこと
以上を読んで犯しがちな誤解が2つあります。いずれも先回りして潰しておきたい。
「我々のレンダラーはより良い」ではない
BromureはChromiumのアップストリームを使っています。MozillaでMythosが監査したパーサーたちは、Bromureを含むあらゆるChromiumベースのブラウザに同等物を持っています。我々は自分たちのレンダラーが他の誰のものより少ないバグを持っている、と主張しているわけではありません。主張しているのは、我々の姿勢が、自分たちのレンダラーに少ないバグしかないことに依存していない、ということです。
「AI監査はむしろ悪い」ではない
Mythosクラスのツールは、ディフェンダーにとって明確な純プラスです――すべてのブラウザと、バンドルされたすべてのサードパーティパーサーがこのペースで監査されれば、世界はより安全になります。我々の主張はもっと狭いものです――この種の進歩はレンダラー品質の天井を上げますが、それでもレンダラーが悪用されたときにどうするか、という設計上の問いを変えはしません。その問いこそ、Bromureが答えるために作られた問いです。
次に注視すべきこと
Mozillaの発表の誠実な読み方は、これは長い会話の幕開けだ、というものです。次の数四半期に重要になるものが、少なくとも3つあります。
第一に、ChromiumとWebKitが自身のMythos支援監査を出荷するときに、似たような発見件数を確認するかどうか。Firefoxの数字は印象的ですが、業界全体の姿はまだぼやけています。 第二に、同じツールが開示後の攻撃者の手に現れ始めるかどうか。Mozillaは271個のバグが悪用可能なゼロデイだったとは主張しないよう、注意深くしています。あれは修正です。問いは、同じクラスのツールを、次のStableリリースの翌朝のChromeに向けた、パッチを当てていない誰かが使ったら、どう見えるか、ということです。
第三に、そしてこれはMozilla自身の懸念ですが、AI支援開発とAI支援監査の相互作用が、理解可能性の純増加をもたらすのか、それとも純減少をもたらすのか、ということです。モデルにしか監査できないコードベースは、そのセキュリティがモデルへの継続的アクセスに依存しているコードベースです。それは我々が20年付き合ってきたものとは異なる故障モードであり、明らかにより良いものではありません。
我々の側は、発展に合わせて書き続けていきます。そして同じ設計上の賭けを続けます――タブごとの使い捨てVMは、ブラウザのバグの最悪の結果を、再起動が必要なセッションであって、再構築が必要なコンピュータではない、ものにする、という賭けです。この賭けは、レンダラーがより良くなっても悪化しません。もっとも狭く役に立つ意味で、わずかに冗長になります――それは我々が大いに喜んで抱えたい問題です。
Bromureをインストールしてください。他のブラウザも更新し続けてください。そして次に「AI支援監査が[製品]に数百の脆弱性を発見」という見出しを目にしたとき――今年、何度もそうなるでしょう――それを、その通りに読んでください。つまり、天井が上がっている証拠であって、床が変わった証拠ではない、と。