最新AI「ミュトス」を使えても「バグマゲドン」に？ Firefox開発元に学ぶセキュリティ対策
4月、Webブラウザ「Firefox」を手掛ける米Mozillaが驚くべき成果を発表した。Firefoxの新バージョン「Firefox 150」において、271件の脆弱（ぜいじゃく）性を一気に発見し、修正したというのだ。
立役者となったのが、米Anthropicが同月7日に発表した最先端のAIモデル（フロンティアモデル）「Claude Mythos Preview」（以下、Mythos）だ。「神話（Mythos）」の名を持つこのモデルを活用し、Mozillaはこれまでになかったほど大量の脆弱性を発見できた。
Mozillaは、271件の脆弱性のうち、180件を最高レベルのsec-high（通常のWeb閲覧をしているだけでも発生してしまうほどの深刻度）、80件をsec-moderate、11件をsec-lowに分類する。
なかには15～20年間も隠れていたバグもあり、いずれも長年のファジング（ソフトウェアに大量の異常入力を与えて不具合や脆弱性を見つける自動テスト手法）と人間による監査をすり抜けてきたものだった。同月にMozillaが修正した脆弱性は計423件に達し、同社の2025年の月間平均修正件数を約14倍上回った。
MozillaのCTOであるBobby Holley氏は公式ブログで、最初の発見結果を見たときの感覚を「めまいを覚えた」と表現している。
「ハードニング済みのターゲット（後述する『多層防御アーキテクチャ』や継続的な脆弱性対応の積み重ねで、新たな攻撃経路を見つけにくい状態まで防御が強化されたソフトウェアを指す）なら、2025年であれば、こんなバグが1つ見つかっただけで赤色の警報レベルだった」（Holley氏）
この数字を受けて、業界には1つの“神話”が流れ始めている。それは「Mythosのような先端AIモデルのアクセス権さえ手に入れば安心」というものだ。これだけ大量の脆弱性を一気に発見できるようになったのは、ひとえにMythosの力であり、その力を手に入れられれば自社でも同じ対応が可能になる、というわけだ。
しかしMozillaが26年5月7日に公開した詳細なレポートを読み込むと、この物語が半分しか正しくないことが分かる。Mythosにアクセスできる組織は他にも多数存在するが、Firefox 150のような規模で修正できた例は、現時点では確認できていない。
サイバーセキュリティ専門メディアの「The Hacker News」は、Anthropicが一部企業にMythosを提供しながら進めるセキュリティ強化の取り組み「Project Glasswing」で発見された脆弱性のうち、実際にパッチが出たのは1％未満と指摘している。発見のフェーズはAIで爆発的にスケールしたが、修正フェーズでスケールできた組織はほとんどなかったわけだ。
なぜMozillaだけがそれを可能にしたのか。この記事では、Mozillaのレポートを読み解き、彼らの対応能力を「フロンティアAIモデル」「ハーネス」「パイプライン」の3層に分けて考えた上で、「自社でもMythos級のフロンティアAIモデルが利用できるようになる」時代に向けて、何を準備すべきかを考察してみたい。
Mozillaのレポートは「Claude Mythos Previewを活用したFirefoxセキュリティ強化の舞台裏」と題されている。執筆したのは、Mozillaのセキュリティやプラットフォーム基盤を担う3人の中心的エンジニア。彼らは同レポートで、AIによる脆弱性発見を支える要素を、次の3層に分けて記述している。
第1層は、推論能力そのものを提供するフロンティアAIモデル。Claude Mythos Previewのほか、AnthropicのAIモデル「Claude Opus 4.6」や米OpenAIの「GPT-5」などが該当する。
Mozillaはなぜ成功したのか
第2層は、第1層にあるモデルを駆動して、「コードに対する仮説を立て、再現可能なテストケースを書き、動的に検証する」ループを回す「ハーネス」。Mozillaは「適切なインタフェースと指示が与えられれば、ハーネスはコード内のバグに関する仮説を動的に検証するための、再現可能なテストケースを生成・実行できる」と説明する。
第3層は、ハーネスが吐き出すバグ候補を、最終的な対応完了にまで導く「パイプライン」。パイプラインは（a）既知バグとの重複排除、（b）優先度のトリアージ、（c）修正の実装、（d）テスト、（e）リリース、というステップで構成される。Mozillaは「発見系のサブシステムだけでは、必要条件を満たしたにすぎない」として、この一連の運用基盤こそがスケールの鍵だと明示している。
決定的に重要なのは、3つの層は「各社で再現できる難易度」が大きく異なる点だ。Mozillaは「ハーネスはプロジェクト間で横展開可能だが、パイプラインは本質的にプロジェクト固有のものだ」と説明する。
確かにフロンティアAIモデルは、発表当初は限られた企業・組織しか手にできないことが多いが、そうした制約は技術とは違う領域（政治や経済など）で生まれる。その意味でフロンティアAIモデルは、「API経由で誰でも入手できる」ものとして位置付けることができる。ハーネスも技術さえあればどんな企業でも開発できる。
しかしパイプラインだけは、各組織のコードベース、ツールチェーン、組織運用に深く根を張った固有の資産だ。簡単にまねしたり、移植したりできる類のものではない。
この3層構造と、それぞれの役割を理解することが、Mozillaの成功を読み解く鍵となる。MozillaがMythosで成果を出せた本当の理由は、最上層のモデルでも中間層のハーネスでもなく、最下層のパイプラインに長年投資してきたことにある。
各階層の詳細を順に見ていこう。
第1層――フロンティアAIモデルと「モデル幻想」のわな
最上層のフロンティアAIモデルは、半年程度のスパンで急速にコモディティ化が進む方向にある。英国の研究機関AI Security Institute（AISI）は、Mythosが「過去のフロンティアモデルから一段階の進化を示した」と評価しつつ、サイバー能力の急速な向上はMythos単独の現象ではなく、フロンティアAI業界全体で並行して進んでいる点を強調する。
AISIによれば、Mythosは32ステップから成る企業ネットワーク侵入シミュレーション「The Last Ones」を史上初めて完走し、Mythosの新しい版（さらに学習を進めたもの）では10回中6回成功した。OpenAIのAIモデル「GPT-5.5」も同シミュレーションを10回中3回クリアしており、AISIは「自律的に多段サイバー攻撃を実行できる」段階にこの2モデルが到達したと整理する。
米Googleでも、「Big Sleep」という、同社のAIモデル「Gemini」ベースのAIエージェントに人間のセキュリティリサーチャーの作業手順を模倣させ、過去バグの類似パターンを起点にコードを監査する仕組みが実世界の脆弱性を複数発見し、継続的な成果を上げている。フロンティアAIモデルを提供できる企業の数は、ますます増えていく可能性が高い。
一方、第1層にはわなが潜んでいる。「フロンティアAIモデルさえ手に入れられれば、あとは自動的に脆弱性が見つかり、修正される」という思い込みだ。ここでは、このわなを「モデル幻想」と呼んでみたい。
この幻想がいかに脆いかは、25～26年初頭のオープンソースコミュニティーの動向が雄弁に物語っている。代表的な例が、オープンソース開発プロジェクトの一つである、curlプロジェクトのバグバウンティ（バグ発見に報奨金を支払うプログラム）閉鎖だ。
押し寄せる「AIスロップ」
curl開発者のDaniel Stenberg氏は、AIで生成された低品質な「脆弱性報告」が大量に寄せられ、メンテナの限られた時間を浪費している状況を「死に至る千の汚泥」と表現し、26年1月末をもってバグバウンティを停止した。半年前の25年中旬時点のデータでは、curlに届く報告のうち真に脆弱性を指摘していたのは約5％、AI生成と疑われるものが約20％だったという。
高度なAIモデルが社会に普及した結果、「脆弱性を発見したように見える出力」を誰でも安価に生成できるようになった。そうした出力は、単体ではバグレポートにならない。再現可能なテストケース、つまり受け止め側で検証できる仕組みがなければ、出力は単なるノイズに転落する。
実はMozillaも、Anthropicから26年2月に最初のFirefoxバグ報告を受け取った際、AIスロップ（AIが大量生成する、もっともらしく見えるが内容の乏しい低品質コンテンツの総称）を警戒していた節がある。
ただMozillaの公式ブログでは、Anthropic側の報告を確認したところ、「最小化されたテストケースが添付されており、セキュリティチームが各問題を迅速に検証・再現できた」として、そのクオリティーを評価している。逆に言えば、そうした補足情報のない報告はMozillaにとっても「さばけない」のだ。
モデル幻想を回避するために必要なのは、モデル単体ではなく、モデルが吐く仮説をその場で検証する仕組み――次に述べる第2層、ハーネスだ。
第2層――「モデル幻想」対策のハーネス
Mozillaは、前世代のAIモデル「Claude 3.5 Sonnet」や「GPT-4」を用いた静的なコード解析実験では、各モデルが「いくらかの有望さは示したが、偽陽性率の高さからスケールが不可能だった」と説明する。コードを読ませて「脆弱性らしきもの」を列挙させるだけのアプローチでは、社内のセキュリティチームが受け止め側として疲弊するだけで、curlコミュニティーが外部から味わったのと同じ消耗を内部で繰り返すことになる。
ハーネスとは何か
一方、ハーネスとは、AIモデルを自律的なエージェントとして動作させるための制御基盤を指す。具体的には、AIモデルに「コードを読む→バグの仮説を立てる→テストケースを書く→実行する→次の仮説に進む」というサイクルを繰り返させ、ツール呼び出しやコード実行を組み合わせる。
Mozillaのハーネスは、コードの特定領域を指定して「ここにバグがあるはずだ、見つけてテストケースを書け」と指示する設計から始まったという。その核心は、Mozillaの設計通り「仮説と動的検証のループ」にある。具体的には次のような動作だ。
AIモデルにファイルを指定して、脆弱性の仮説を立てさせる同時に、その仮説を再現するテストケースを書かせる。次にそのテストケースをビルド・実行して、想定通りクラッシュや異常動作が発生するかを確認する。発生しなければ仮説を捨て、別の仮説に進む。発生すれば、最小化と詳細化を経てバグ候補として上に流す――この検証ループを高速で回し続けることで、AIスロップを「ハーネスから出る前」にふるい分けられる。
Mozillaはこの初期ハーネスをClaude Opus 4.6で動かし、まずは「サンドボックス・エスケープ」と呼ばれる種類の脆弱性の探索から始めた。
Firefoxを含む現代のWebブラウザは、Webサイトから読み込んだコードや描画処理を「サンドボックス」と呼ばれる権限の絞られた区画の内側で動かしている。仮に閲覧先に悪意のあるコードが仕込まれていても、その被害が利用者のファイルやOS、他のタブで開いているWebサイトにまで及ばないように、あらかじめ一段隔離しておく仕組みだ。
「サンドボックス・エスケープ」とは、この隔離区画の外にある親プロセスやOSへすり抜けるための脆弱性を指す。これが別の脆弱性と組み合わさると、攻撃者は最終的にPC全体の支配権を握れてしまうため、Webブラウザの中でも最もクリティカルな攻撃経路と位置付けられる。
Mozillaが最初の探索対象としてここを選んだのは、Firefoxの防御で最も重要な前線だからだ。当初はターミナル越しに人間が常時貼りつき、プロンプトの調整とエージェントの挙動の観察を繰り返しながら手探りで進めたという。動作が一定の品質で安定したところで、運用を一気にスケールさせる構成へ切り替えた。
具体的には、検査対象のFirefoxソースファイルを1つずつ割り当てた使い捨てのVM（処理が終われば破棄する仮想マシン、いわゆるephemeral VM）をクラウド上に多数立ち上げ、各VMで脆弱性探索ジョブを並列に走らせ、検出結果はそれぞれクラウドストレージへ書き戻すという構成だ。
Mozillaは後に、Mythosが利用可能になった時点で、モデルを差し替えるだけで同じハーネスを駆動できた。「end-to-endのパイプラインが整っていれば、新しいモデルの差し替えはささいな作業だ」とレポートでは明言している。
同様の構造は、他の事例でも報告されている。セキュリティ企業のPalo Alto Networksは社内テストで、MythosとOpenAIの最新モデルをハーネスに組み込んだ結果、生成した攻撃コードの70％以上が実際に動作したと発表。脆弱性発見の月間ペースは従来比で約7倍、3週間で「1年分のペネトレーションテスト相当」の成果が出たという。
ここで重要なのが、ハーネスは「自社固有」ではないという点だ。Mozillaは「ハーネスはプロジェクト間で再利用できる可能性がある」と報告しており、技術的な構造は他のソフトウェアプロジェクトでも横展開できると考えて良いだろう。GoogleのBig Sleepも、別系統だが同様のエージェント的な手法を使っている。
つまりハーネス層自体は、Mozillaが先んじて成果を上げられた決定的な要因ではない。フロンティアAIモデルにアクセスできる組織なら、エンジニアリングリソースを投じれば開発できるからだ。本当の決め手は、もう一段下、最下層のパイプラインにある。
第3層――パイプラインと「キャパオーバー」のわな
パイプラインとは、ハーネスが吐き出すバグ候補を、実際の修正リリースまで運ぶ運用基盤だ。Mozillaはパイプラインについて、「何を探すか、どこを探すか、出力をどう処理するかを決めること。最後の処理には、既知の問題との重複排除、バグの追跡、トリアージ、修正の出荷までが含まれる」と説明している。
パイプラインが重要なのは、前述の通り「Glasswingで大量の脆弱性が発見されたにもかかわらず、その発見の1％未満しかパッチされていない」状態が生じうるからだ。発見側はAIで桁違いにスケールするが、トリアージ・修正・出荷側のキャパシティーは変わらないので、ボトルネックが下流に移動するだけになる。
ここでは、この問題を「キャパオーバーのわな」と呼んでみたい。Mozillaがこのわなを回避できた理由は、過去数年間で次の3分野に投資を行ってきた背景がある。
1）ファジング基盤
Mozillaは、自社ハーネスを「既存のファジング基盤の上に構築した」としている。同社は長年にわたり、ブラウザに乱数的・変則的な入力を大量に与えてクラッシュを誘発する「ファジング」のための社内基盤を継続的に整備してきた。
Mozillaが「わな」を回避できた理由
19年に公開した「Grizzly」というブラウザ・ファジング用フレームワークを中核に、検出したクラッシュを自動で分類・整理する「FuzzManager」サーバ、再現の難しいバグでも実行を記録・再生できる「Pernosco」、テストケースを最小化する自動ツール群といった一連のツールが、長年の運用のなかに組み込まれている。
加えて、24年に本番投入されたスナップショット・ファジングという新しい手法もある。これは前述のサンドボックス・エスケープを効率的に探索する技術で、Mozillaのレポートでも、AIハーネスと並ぶ重要な手法として「このギャップを埋める新しい手法の開発で一定の成果を上げてきた」と言及している。
要するにMozillaは、「クラッシュを再現可能なバグレポートに変換する自動化」を10年以上磨き続けてきた。AIハーネスが出した仮説の検証結果を、この自動化の入口に流し込むだけで十分だったのだ。
2）多層防御アーキテクチャ
なぜここで防御アーキテクチャの話が出てくるのか。AIハーネスが吐き出す脆弱性候補は、放っておけば「どれもクリティカルに見える」という状態に陥りやすい。これを月数百件規模で実際の修正リリースまで運ぶには、「すでに設計で吸収済みで実害につながらないもの」と「コード修正が必要なもの」を切り分ける枠組みが必要だ。
Firefoxの場合、この切り分けの軸を提供したのが、過去数年で積み上げてきた多層防御の各層だった。
まずは、Mozillaが21年から段階的に展開し、Firefox 96でデフォルト有効化したサイト分離（Project Fission）だ。これはブラウザ内で開いている各Webサイトを、それぞれ独立したOSプロセスに分けて描画する仕組みで、1つのサイトに脆弱性があって攻撃者に突かれても、被害が他のサイトのデータに波及するのを防げる。
次に、21年のFirefox 95で導入した「RLBox」。Firefoxは内部でフォント描画やスペルチェック、音声・画像処理などのためにC言語製の高速ライブラリを多数利用しているが、これらは古くから脆弱性の温床として知られてきた。RLBoxは、こうしたライブラリを隔離する仕組みで、ライブラリ側に問題があってもFirefox本体には波及しない設計になっている。
22年のFirefox 100で本格化した「Win32k Lockdown」は、Webサイトを描画する必要最小限の特権を持つプロセスから、Windowsのカーネルの一部APIに直接アクセスできなくする仕組みだ。このAPIは過去にサンドボックス脱出の経路として頻繁に悪用されてきたため、遮断することで攻撃者の権限昇格を妨げる。
さらに同じ頃、親プロセスのプロトタイプ凍結（オブジェクトの原型となるプロトタイプの変更を禁止し、外部コードによるプロパティ改ざんや振る舞いの差し替えを防ぐ防御策）も実施し、「プロトタイプ汚染」と呼ばれる古典的な権限昇格手口を設計的に封じた。
ハーネスが「発見できなかったバグ」を観察
Mozillaのレポートから得られる重要な知見の一つが、この防御アーキテクチャに関する解説だ。Mozillaによると、AIハーネスが「発見できなかったバグ」、より正確には「発見しようとして既存の防御層に阻まれた経路」を観察できたという。
ハーネスの動作ログを監査したところ、AIモデルが脆弱性を見つけようと多種多様な攻撃経路を試みているなかに、プロトタイプ汚染を経由して親プロセスへ侵入しようとする試行が何度も含まれていた。その試行は、いずれも先に述べたプロトタイプ凍結によって阻まれていた。
「過去のハードニング作業からの直接的なペイオフを観測することは、より多くのバグを発見・修正することよりも報われた」（Mozilla）
これは単なる感慨ではない。多層防御の存在は、AIが大量に吐き出した発見を「設計で吸収済み」と「コード修正が必要」に仕分けるための座標軸として機能した。逆にこの座標軸がない組織にAIハーネスを動かすと、全ての発見が「クリティカル」扱いになり、優先度判定が崩壊する。Mozillaはトリアージの座標軸そのものを、5～7年前から準備していたということになる。
3）出荷力
最後が「バグをさばける組織体制」だ。Mozillaは「100人を超えるエンジニアがこの取り組みにコードで貢献した」としている。修正コードの執筆、レビュー、テスト、リリース管理といった多くの作業に対して、100人超のチームが動いて初めて月423件の修正を実現したわけだ。
加えてMozillaは、「Bugzilla」というオープンな課題追跡基盤、内部発見バグをまとめてCVE（脆弱のデータベース）を発行する「rollup CVE」運用、公開された重大度評価基準を整備している。
前述の通り、MozillaはFirefox 150で発見した脆弱性271件のうち、180件をsec-high、80件をsec-moderate、11件をsec-lowに分類している。大量の脆弱性に対しても正確にレベル分けし、優先順位を決められたのは、標準化された分類と管理の仕組みがあるからだ。
多くの組織は「第1層がボトルネック」と誤認し、フロンティアAIモデルのアクセス確保を目標に据えがちだ。しかし実際のボトルネックは第3層にあることが多い。アクセスを得ても、大量に発見される脆弱性を裁く体制がボトルネックなら、組織は「発見したけれど直せないバグの山」を抱えることになる。
業界の専門家の間では、近頃「バグマゲドン（Bugmageddon）」という言葉がささやかれるようになっている。コンピュータやプログラムの脆弱性を意味する「バグ」と、聖書で描かれる最終戦争「ハルマゲドン」を組み合わせた造語で、「AI支援による脆弱性発見の前例のない急増が、修正側のキャパシティーを超え、サイバーセキュリティに未曾有のリスクをもたらす」という意味だ。
企業は目前に迫るバグマゲドンの脅威を正しく捉え、対処しなければならない。
この半年のロードマップ
このようにMozillaのレポートは、フロンティアAIモデルを活用した脆弱性対策を検討する際に、3つの層から考えることが有益であると示している。ただし検討に使える時間はそう長くない。
Mythos級のフロンティアAIモデルが、自社で実用化可能な形で広く流通する時期について、Palo Alto NetworksのCPTOであるLee Klarich氏は「半年以内に高度なサイバー能力を備えたAIモデルが一般化する」と予測している。
同社は同時に「攻撃側がフロンティアAIの能力に広くアクセスできるようになるまでには3～5カ月しかない」とも推定しており、「半年」は防御側にとっての準備期間の上限として読むのが現実的だ。従ってこの期間は、「待機」ではなく「準備」に充てるべき時間だ。
では具体的に、どのような準備を進めれば良いのか。各層に対する準備項目を挙げてみたい。
第1層における準備
フロンティアモデルが到来してからセットアップを始めるのではなく、現行で利用可能なモデルで縮小版を回しながら、利用ポリシー、機密データの取扱い、ログ管理、コスト管理の運用ノウハウを獲得しておく。
必要な準備は？
Mozillaのレポートは「新しいモデルの差し替えはささいな作業」と述べているが、これは下流のパイプラインが整っているからこそいえる話で、ゼロから始める組織にとっては「モデルが来る」までの期間で準備を完了しておかなければならない。
第2層における準備
自社の高リスクコードベース（例えば認証、決済、IPC的境界、ファイル解析、第三者ライブラリ呼び出し）に対する小規模ハーネスを社内で試作する。最初のプロンプトは複雑な必要はなく、Mozillaが解説している初期プロンプト相当で十分だろう。
重要なのは「AIに仮説を立てさせて終わり」にせず、必ず「再現可能なテストケースをAI自身に書かせ、実行して検証させる」ループを組み込むこと。検証なしの仮説は社内に流通させないというルールを最初に決めておく。
第3層における準備
ここがフロンティアAI活用の核心部分であり、最も投資効果が大きい。主な作業は次の4点だ。
第1に、既存のセキュリティ投資（ファジング、SAST、DAST、外部監査、バグバウンティ）の棚卸し。それぞれが「どの攻撃経路に対して、どの粒度で機能しているか」を把握しておく。
第2に、設計的防御の明示化。自社のアプリケーション・スタックで「どの攻撃経路を、どのレイヤーで吸収する設計か」をマッピングする。多層防御がある組織なら、AIが指摘した仮説を「設計で吸収済み」「監視で検知可能」「コード修正が必要」のいずれかに切り分けられる。
第3に、月数百件規模のバグ流入を想定したインシデント・レスポンス演習。誰がトリアージし、誰が優先度を判定し、誰がパッチを書き、誰がレビューし、誰がリリースを承認するか――この一連のポイントを、演習を実施することで検証しておく。
第4に、パッチ・レビュー・リリースの自動化投資。回帰テスト、CI上での差分スキャン、リリースノート自動生成など、出荷側の処理能力を底上げする投資は、AIによる脆弱性発見急増の前夜にこそ効果を発揮する。
当然ながら、これら3層の対応は個々に独立したものではなく、それぞれを連携して行う必要がある。半年のロードマップを組み上げた上で、全体を統制するプロジェクトを立ち上げ、それを指揮する責任者を決めておかなければならない。
またそうした責任者には、プロジェクト外のステークホルダー（経営層のような内部の関係者から、各分野の規制当局、AnthropicのようなフロンティアAIモデルの提供者、あるいは同様の作業に取り組む同業他社など外部の関係者に至るまで）との調整や報告・情報共有も求められる。そのような対応力を持つ人材やチームを配置できるかも、大きな鍵になると考えられる。
「バグマゲドン」に向けた十分な備えを
「フロンティアAIモデルが脆弱性対応の世界をどう変えるか」という議論において、3層モデルの最上層だけを見ているうちは、半分の答えしか得られない。Mozillaのレポートが示しているのは、モデルは差し替え可能、ハーネスは横展開可能、しかしパイプラインだけは各組織で整備しなければならないという知見だ。
Mozillaの事例から得られる教訓は、皮肉にも「フロンティアAIをいかに使うか」ではなく、「フロンティアAIが来る前に、どのような環境を整備しておくか」という問題に行き着く。ファジング基盤の整備、多層防御の設計、バグ管理と出荷運用の標準化など、MozillaのMythos活用の成功を支えた要素は、彼らが過去5～10年がかりで築いてきた資産だ。
どれもAI登場以前から存在する領域に対し、地道な投資を続けてきた結果であり、他社で一朝一夕で築けるものではない。そのことを正しく認識し、迫る「バグマゲドン」に向けて今から準備を進めるしかない。
