Microsoftによると、Frontier Offensive Research & Generative Exploitation（略称FORGE）ラボは、AIが難しい脆弱性を発見できるかどうかの検証から、こうした発見を出荷可能な修正へと変えるために必要なことの研究へと移行した。2026年5月から9月にかけて、同ラボはWindowsの脆弱性の発見を支援し、それらには140件のCVE識別子が割り当てられ、そのうち52件が2026年9月のセキュリティ更新プログラムで修正された。
取り組みはオープンソースソフトウェアにも広がり、FORGEのチームはLinuxカーネルを含む23のプロジェクトを対象に、内部で検証された約155件の報告を提出した。Microsoftによれば、14のプロジェクトまたはプロジェクトファミリーにまたがる93件の報告が、記事作成時点でメンテナーから確認または受理の記録を得ていた。また、Linux FoundationのAkritesイニシアチブを通じて提出されたLinuxの報告の一つは、同イニシアチブからの報告として初めて、Linuxカーネルへの修正の取り込みに至った。
最大能力から大規模運用へ
第一の教訓は、複雑な欠陥を発見するモデルの成功が、同じペースで修正を生み出せることを保証するわけではないということだ。検証担当者の数を増やせば候補数は増える可能性があるが、確認済みの結果や公開される修正の数が必ずしも増えるわけではない。Microsoft Security Response Centerがレビューできる速度を上回って報告が到着すると、待ち行列が積み上がり、専門家の時間を消費する。特に、報告が重複していたり、再現可能な証拠を欠いていたりする場合はそうである。
そのためFORGEは、スキャンや報告の件数だけでなく、再現可能な結果に重点を置いている。同ラボは、作業を調整するために複数モデルのプラットフォームMDASHを使用し、さらにエクスプロイト可能性の証明または概念実証の生成、テストハーネスの構築、欠陥のある挙動を引き起こす入力の発見を行う。Microsoftは、ある内部プロジェクトが抽象構文木解析などの決定論的アルゴリズムを採用した結果、同じコードに対する複数回のスキャンで重複報告が約45%減少したと述べている。
テキストの増加ではなく、不確実性の除去に投資する
Microsoftは、効率をモデルが生成するトークン数だけで測ると、誤解を招く基準になると考えている。短い報告は曖昧で調査コストが高い可能性がある一方、より長い分析は実行経路を裏付け、総コストを削減することがある。実務上の判断は、調査担当者に何が不足しているのか、すなわち関数の呼び出し元、ビルド設定、実行可能な再現用プログラム、因果関係の説明のいずれかを特定し、次のステップをそのギャップを正確に埋める方向へ導くことである。
MDASHは、高度なモデル、蒸留モデル、専門の検証担当者、コード解析ツールを組み合わせ、定型的なタスクを低コストのモデルに割り当て、未解決の問題をより強力なモデルへエスカレーションできるようにしている。ただしMicrosoftは、この方針は依然として測定を必要とする仮説であり、早期のフィルタリングによって本物の脆弱性が除外される可能性があると強調している。
継続的な学習ループとしての検証と修正
この考え方によれば、検証と修正は脆弱性発見の後に行う別個の段階として扱うべきではない。すべての結果は、自動検証、人によるレビュー、修正の開発、リグレッションテストを経るべきであり、各段階の証拠をシステムに戻す必要がある。検証の失敗でさえ、パスに到達できない、ビルド設定が正しくない、攻撃者が入力を制御できない、報告が重複しているなど、失敗の理由を記録すれば有用になり得る。
Linuxカーネルを対象とした実験では、検証エージェントが627件の結果を裏付ける証拠を生成した。一方、確認済みのクラッシュ182件について概念実証を作成する平均コストは、モデルコスト3.61ドル、成功した各ケースにつき21.5分だった。自動エクスプロイト生成を通じてローカルでの権限昇格の可能性をテストした6件では、平均8.56ドル、25.4分だった。評価にはGPT-5.5を使用し、初期スキャン、失敗したケース、人による調査、修正の準備にかかるコストは含まれていない。
セキュリティチームにとって何を意味するのか
これらの結果から得られる最も重要な読み取りは、エージェント型脆弱性発見システムの成功指標を結果の件数だけにすべきではないということだ。Microsoftは、確認済みの欠陥数、重複・却下された報告、待ち行列の経過時間、発見から修正までの移行時間に加え、モデルコストと人によるレビュー時間を追跡することを提案している。また、オープンソースプロジェクトで作業するには、より多くの報告を送るだけでなく、各プロジェクトの開示、レビュー、修正のプロセスを尊重する必要がある。
実務的には、情報源はボトルネックの中心が変化したことを示している。欠陥を発見する能力は問題の一部となり、研究をビルド環境、バイナリ、設定、テストツール、CI/CDシステムに結び付けることの重要性が増している。結果の限界も明確である。検証コストに関する数値は重要な人的段階を除外しており、研究結果を受け入れられる修正へと変えることは、メンテナーと各プロジェクトの文脈に依存する。そのため、この記事は自動化がエンジニアリングレビューに取って代わることを証明するものではなく、人間がセキュリティ上の判断と修正の責任を維持しながら、反復的な作業を減らす手段として自動化を提示している。