「コーディングエージェントを自社リポジトリに向けて、『脆弱性を探して』と頼む」──直感的でしょう。でもこれ、ちゃんと失敗します。Cloudflare が Anthropic のセキュリティ特化モデル Mythos Preview を使い、自社の 50 以上のリポジトリ（ランタイム、エッジのデータ経路、プロトコルスタック、コントロールプレーン、依存している OSS）を実際にスキャンした Project Glasswing の報告は、なぜ素直なやり方が失敗するのか・代わりに何が効くのかを、はっきり見せてくれます。
そして結論は、これまでの記事と地続きです──主役はモデルじゃなく harness。順番に、技術の中身まで見ていきます。
まず：Mythos Preview は何が「一段違う」のか
harness の話に入る前に、土台のモデルが何をできるのかを押さえます。Cloudflare は「これは前世代の汎用フロンティアモデルの改良版ではなく、別種の道具が別種の仕事をしている」と言い切り、特に2つの能力を挙げます。
① エクスプロイトチェーンの構築。 現実の攻撃は、ひとつのバグで完結することはまれです。小さな「攻撃プリミティブ」を複数つなげて、初めて動くエクスプロイトになる。たとえば、use-after-free（解放後使用）のバグを「任意の読み書き」プリミティブに変え、制御フローを乗っ取り、ROP（return-oriented programming）チェーンでシステムを完全に掌握する──といった具合です。Mythos Preview は、こうしたプリミティブを複数取り上げ、どう組み合わせれば動く証明になるかを推論できる。その途中の思考は、自動スキャナの出力というより、シニアの研究者の仕事に見える、と報告は言います。
② 証明（PoC）の生成。 バグを見つけることと、それが本当に悪用可能だと証明することは別物です。Mythos Preview は両方やる。疑わしいバグを発火させるコードを書き、使い捨ての作業環境でコンパイルして実行する。プログラムが想定どおり動けば、それが証明。動かなければ、失敗を読んで仮説を修正し、また試す。このループ自体がバグの発見と同じくらい重要で、「動く証明のない疑い」は単なる憶測に終わるところを、Mythos Preview は自力でその溝を埋めます。
ここがミソなのですが、同じ harness に他のフロンティアモデルを通しても、同じ根本バグの多くは見つかるし、推論面でも期待以上に進むこともあった。差がついたのは「断片を縫い合わせる」段階です。あるモデルは興味深いバグを特定し、なぜ重要かを丁寧に書き、そこで止まる──チェーンは未完のまま、悪用可能性は宙ぶらりん。Mythos Preview で変わったのは、従来ならバックログに埋もれて見えなかった低深刻度のバグを、ひとつのより深刻なエクスプロイトに連鎖させられる点でした。
つまりモデルは確かに進歩した。でも──と報告はここから harness の話に折り返します。
なぜ汎用コーディングエージェントを向けてもダメなのか
Cloudflare は去年、AI 支援の脆弱性研究を始めたとき、いちばん素直な発想を試した。「汎用コーディングエージェントを適当なリポに向けて、脆弱性を探させる」。これは「findings は出る」という意味では動く。でも、実コードベースを意味のある範囲でカバーし、価値ある発見を出すという意味では動かない。理由は2つ。
① 文脈（コンテキスト）。 コーディングエージェントは「ひとつの集中した作業の流れ」──機能を作る、バグを直す、リファクタする──にチューニングされている。大量のソースを読み込み、一度にひとつの仮説を保持して、それに対して反復する。これは脆弱性研究には形がまるで逆です。脆弱性研究は本質的に「狭くて並列」。人間の研究者は、ある一点（ひとつの複雑な機能、セキュリティ境界をまたぐ遷移、あるいはコマンドインジェクションのような特定の脆弱性クラス＝攻撃者の入力が最終的にシェルコマンドとして実行される、といったもの）を選び、徹底的に調べる。そしてそれを別の機能・境界・脆弱性クラスについて、コードベース全体で何千回も繰り返す。10 万行のリポに対して単一エージェントのセッションは、サブエージェントを使っても、コンテキストウィンドウが埋まってコンパクション（文脈圧縮）が走る前に、攻撃面の 0.1% 程度しか意味のある形でカバーできない。しかもそのコンパクションが、後で効いてくるはずだった初期の発見を捨ててしまうこともある。
② スループット。 単一ストリームのエージェントは一度にひとつしかやれない。でも実コードベースは「多くの仮説 × 多くのコンポーネント」を同時に当て、面白いものが出たらさらに枝分かれする必要がある。エージェントを強く駆動することはできても、ある時点から、
あなたはモデルに律速されるのをやめて、相互作用の"形"そのものに律速されはじめる。
（at some point you stop being limited by the model and start being limited by the shape of the interaction itself）
モデルを直接コーディングエージェントで使うのは、研究者がすでに手がかりを持っていて「もう一対の目」が欲しい手動調査には向く。でも、高いカバレッジを達成する道具としては間違っている。それを受け入れた時点で、彼らは Mythos に間違った仕事をさせるのをやめ、周りに harness を組み始めたわけです。
ノイズとの戦い──signal-to-noise こそ本丸
脆弱性対応でいちばん難しいのは、見つけたバグの中から「どれが本物で、どれが悪用可能で、どれを今すぐ直すべきか」を切り分けることです。これは AI 以前から難しい問題でした。AI スキャナと AI 生成コードが、それをさらに悪化させている。Cloudflare は事後検証の段を何重にも積んで対処してきました。
ノイズ率を支配する要因が2つあると報告は言います。
① プログラミング言語。 C と C++ は直接のメモリ操作を許し、それに伴ってバグのクラス──バッファオーバーフロー、境界外の読み書き──を生む。これらは Rust のようなメモリ安全言語ならコンパイル時に消える種類のものです。実際、メモリ非安全な言語で書かれたプロジェクトからは、一貫して偽陽性（false positive）が多く出た。
② モデルのバイアス。 優秀な人間の研究者は「何を見つけ、どれくらい確信しているか」を伝える。モデルは伝えない。モデルにバグを探せと言えば、コードにバグがあろうがなかろうが、見つけてくる。返ってくる findings は「possibly（おそらく）」「potentially（潜在的に）」「could in theory（理論上はありうる）」で薄められていて、そのぼかした findings が、確かなものを数で圧倒する。探索的な道具としては妥当なバイアスでも、トリアージのキューにとっては破滅的です。投機的な findings ひとつひとつが、却下するために人間の注意とトークンを食い、そのコストが数千件の規模で積み上がる。
Mythos Preview はここで明確に改善している、と。特にプリミティブを連鎖させる能力──複数の脆弱性を切り離して報告するのではなく、ひとつの動く PoC にまとめる──のおかげで、PoC つきで届く finding は、そのまま行動に移せる。「これ、そもそも本物？」に費やす時間が激減する。なお Cloudflare の harness は、意図的に over-report（過剰報告）寄りにチューニングされている。見逃しを減らすぶんノイズは増える。でもトリアージの時点で、Mythos の出力は明らかに質が高い──ぼかしが減り、再現手順が明確で、「直すか・却下するか」の判断に届くまでの手間が小さい。
harness が直す4つのこと
スケールで運用して出た教訓は4つ。どれも「全体の実行を管理する harness が要る」を指していました。
- 狭いスコープのほうが良い発見が出る。 「このリポの脆弱性を探して」はモデルを彷徨わせる。「この特定の関数のコマンドインジェクションを、この信頼境界の下で探して。アーキ文書はこれ、この領域の過去のカバレッジはこれ」と言うと、研究者が実際にやることにずっと近づく。
- 敵対的レビューがノイズを落とす。 最初の finding とキューの間に、2 体目のエージェント（別プロンプト・別モデル・自分で findings を出す権限なし）を挟むと、最初のエージェントが自己レビューでは見逃すノイズを大量に捕まえる。2 体を意図的に対立させるほうが、1 体に「気をつけて」と言うよりずっと効く。
- チェーンをエージェント間で分けると推論が良くなる。 「このコードにバグはあるか？」と「攻撃者は外からそのバグに実際に到達できるか？」は別の問いで、分けて聞いたときのほうがモデルは各々を上手く答える。合体版より各問いが狭いから。
- 狭い並列タスクは、網羅を狙う単一エージェントに勝つ。 多数のエージェントがきつくスコープされた問いに取り組み、後で結果を重複排除するほうが、ひとつのエージェントに「網羅しろ」と言うよりカバレッジが上がる。
これらはどれも「モデルの振る舞いについての観察」で、合わせると、もうチャットインターフェースではない何か──最終成果を達成させる harnessを描き出す。そして面白いのは、harness を作る最初の一歩は簡単で、モデル自身に手伝わせればいい（実際そうした）。Mythos Preview を使って、元々の harness を Mythos の強みに合わせて改良した、と。
脆弱性発見 harness の全段
実際の harness は段ごとにこうなっています。ランタイム／エッジのデータ経路／プロトコルスタック／コントロールプレーン／依存 OSS に対して、生きたコードをスキャンするのに使われました。
| 段 | 何をする | なぜ効くか |
|---|---|---|
| Recon（偵察） | エージェントがリポを上から読み、サブシステム担当のサブエージェントに分岐。ビルド手順・信頼境界・入口・想定攻撃面を書いた「アーキ文書」を生成し、次段の初期タスク列も作る | 下流の全エージェントに共有文脈を渡し、彷徨いを断つ |
| Hunt（狩猟） | 各タスク＝「1 攻撃クラス＋スコープのヒント」。hunter（実際にバグを探すエージェント）が同時におよそ 50 体並列起動、各々がさらに数体の探索サブエージェントに枝分かれ。PoC をタスクごとの使い捨て作業域でコンパイル・実行できる | 仕事の大半はここ。狭い並列タスク多数が、網羅型の単一に勝つ |
| Validate（敵対的検証） | 独立したエージェントがコードを読み直し、元の発見を反証しにかかる。別プロンプトで、自分の新発見を出す権限はなし | hunter の自己レビューでは取れないノイズを相当割合つぶす |
| Gapfill | hunter が「触れたが詰め切れなかった」と印をつけた領域を再キュー | モデルが「過去に当たった攻撃クラス」へ偏る癖を相殺 |
| Dedupe | 同じ根本原因の発見を 1 レコードに集約 | バリアント分析を機能として扱い、キューを重複で水増ししない |
| Trace（到達性追跡） | 共有ライブラリの確定発見ごとに、tracer が利用側リポ 1 つにつき 1 インスタンス枝分かれ。リポ横断のシンボル索引で、攻撃者制御の入力が外からそのバグに到達するかを判定 | 「欠陥がある」を「実際に届く脆弱性」へ変える。ここが最重要 |
| Feedback | 到達するトレースを、バグが実際に露出する利用側リポの新しい hunt タスクにする | ループを閉じ、回すほどパイプラインが良くなる |
| Report | 事前定義スキーマで報告を生成し、スキーマ違反は自分で直し、ingest API に提出 | 散文でなくクエリ可能なデータとして出す |
一番おいしいのは「敵対的検証」
このパイプラインで一番効いているのが、Validate 段＝2 体を意図的に対立させる設計です。検証役は「新しい発見を作る権限を持たず、ただ元の発見を潰しにいく」。
2 体のエージェントを意図的に対立させるほうが、1 体に「気をつけて」と言うよりずっと効く。
（putting two agents in deliberate disagreement is way more effective than just telling one agent to be careful）
そしてもう一つ、なぜ役割を割るのかの核心：
モデルは、それぞれを別々に聞いたときのほうが上手い。各問いが、合体版より狭いから。
（the model is better at each one when you ask them separately）
これは私が以前書いた ClickHouse の「判定の壁」 と同じ家系の話です。あれは「速くて自動の判定」が、嘘をつくエージェントを信頼できるものに変えた。こっちは「敵対的な第二の目」が、もっともらしいだけの誤検知を落とす。L0–L7 のラダー でいえば、検証役という独立の関門は、お願い（ソフトチャンネル）ではなく仕組み（ハード寄り）で品質を担保する L6 的なガバナンスにあたります。
見落とせない話──モデルは「正当な研究」でも断る
ここは技術と安全の境目で、面白いので残します。Project Glasswing で Anthropic が提供した Mythos Preview は、一般提供版（Opus 4.7 や GPT-5.5）にある追加のセーフガードを持たない状態でした。
それでもモデルは、自発的に一部の要求を拒む。脆弱性ハンティングに役立った能力と同じく、創発的なガードレールを持っていて、正当なセキュリティ研究の要求にすら押し返すことがある。ただし、その自発的な拒否は一貫しない。報告の例がなかなか効きます──あるプロジェクトで最初は脆弱性研究を拒否したのに、コードとは無関係な環境変更のあとで、まったく同じコードに対して同じ研究に応じた。別のケースでは、深刻なメモリバグを複数見つけて確認したのに、デモ用エクスプロイトを書くのは拒否した。意味的に等価なタスクでも、いつ・どう提示されるかで正反対の結果になりうる（モデルが確率的である以上、同じ要求でも実行ごとに違う）。
含意は重い。モデルの自発的な拒否は本物だが、それ単独で完全な安全境界として頼れるほど一貫してはいない。だからこそ、将来一般提供されるサイバー能力を持つフロンティアモデルは、このベースライン挙動の上に追加のセーフガードを必ず載せる必要がある──Project Glasswing のような統制された研究環境の外で広く使うなら、なおさら。
セキュリティチームにとっての意味──「速さ」では買えない
Mythos Preview に対する他のセキュリティリーダーの反応で、いちばん大きいのは速さだった。速くスキャンし、速くパッチし、対応サイクルを縮める。複数のチームが、いまや「CVE 公開から本番パッチまで 2 時間 SLA」で動いているという。攻撃側のタイムラインが縮むなら防御側も縮めねば、という発想は分かる。でも──と Cloudflare は釘を刺します。速さだけでは足りない。多くのチームが、それを痛い形で学ぶことになる。
速くパッチしても、パッチを生み出すパイプラインの"形"は変わらない。回帰テストに 1 日かかるなら、2 時間 SLA はそれを飛ばさないと達成できない。そして回帰テストを飛ばして出荷したバグは、たいてい直そうとしていたバグより質が悪い。彼ら自身、モデルに自分でパッチを書かせてみて、元のバグは直すが、コードが依存していた別の何かを静かに壊すパッチが何件か出るのを見た、と。
だから本当に難しい問いは「脆弱性の周りのアーキテクチャをどう設計するか」だ、と報告は向きを変えます。原則は、バグが存在しても攻撃者にとって悪用を難しくすること──そうすれば、脆弱性が開示されてからパッチが当たるまでの隙間が、それほど致命的でなくなる。具体的には、アプリの手前に座ってバグへの到達自体をブロックする防御。コードの一部の欠陥が他の部分へのアクセスを攻撃者に与えないようにする設計。そして、個々のチームの展開を待つのではなく、コードが動いている全箇所に同時に修正を行き渡らせられること。
そしてこの話は両刃だ、とも正直に書いている。自社コードのバグ発見を助けたのと同じ能力は、悪意ある手に渡れば、インターネット上のあらゆるアプリへの攻撃を加速させる。Cloudflare は数百万のアプリの「手前」に座っていて、上のアーキテクチャ原則はまさに、彼らの製品が顧客のために適用するために作られている──と締めくくります。
個人的な見方
これは「harness が主役」という主張の、いちばん鮮烈な実例だと思います。著者自身がこう言い切る。
（これらの観察は）どれも結局、モデルの振る舞いについての話だ。…それを最終成果に変えるのが harness だ。
面白いのは、効いている工夫がどれも「より賢いモデルを選ぶこと」ではなく、仕事の切り方だという点。狭く割る（Hunt）、対立させる（Validate）、到達性でふるいにかける（Trace）、ループで育てる（Feedback）。土台のモデルは同じでも、相互作用の形を変えただけで、攻撃面の 0.1% しか見れなかったものが回り出す。さらに安全という領域だからこそ、「速さ」ではなく「壁」と「対立」と「アーキテクチャ」で確率を確定へ寄せる、という設計思想が刺さります──ClickHouse の運用記とまったく同じ結論です。
割り引く点も正直に。Cloudflare は具体的な検出数・偽陽性率・敵対的検証で何 % ノイズが減ったかといった定量結果を公開していません。効果はあくまで設計の説明として語られている。Mythos も Anthropic の preview モデルで、一般提供版のセーフガードを外した状態での検証です。だから「これで脆弱性ハンティングが解決した」ではなく、「単一エージェントではなく、敵対的検証を組み込んだ多エージェント harness にすべき」という、設計上の指針として読むのが正確です。それでも、harness がどこで効くのかを段ごとにここまで具体的に見せてくれた報告を、私は他に知りません。
参考
- 一次（Cloudflare 公式・全文）: Project Glasswing: what Mythos showed us
- 関連（同じ「harness が主役」の系譜）:
この記事は「AIウォッチ」にも掲載しています。最先端AIを技術の中身まで読み解いています。