最新AI「ミュトス」を使えても「バグマゲドン」に？　Firefox開発元に学ぶセキュリティ対策（3/5 ページ）

公開 2026年05月28日 12時00分

[ITmedia]

印刷する連載新着通知を受け取る

　一方、ハーネスとは、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分野に投資を行ってきた背景がある。