防御者の窓は閉まりつつある：OpenAIがAI Agentで「防御工場」を構築

OpenAIは最近、「Defense Factory」（防御工場）と呼ばれる自動化セキュリティ運用のアーキテクチャを公開した。AI Agentが継続的に脆弱性をスキャンし、検証し、修正することで、「発見—分級—修正—検証」の一連の流れを、人が1件ずつチケットを追う必要のないパイプラインに変える。これはコンセプト記事ではなく、社内セキュリティ・スプリントの実数値が添えられている：初日に緊急・高優先度問題53件を解消、担当紐づけの承諾率90.6%、動的検証後の誤検出率0.81%、Codexが生成したパッチのロールバック率0.53%。

なぜ今か：攻撃側はすでにエンジンを替えている

OpenAIが提示する理由は直接的だ。今のAI Agentは長時間実行し、セッションを跨いで対象システムへの理解を積み重ね、分散した弱点を攻撃チェーンに繋げることができる。かつて熟練したレッドチームが数週間かけて行っていたことを、攻撃側はすでにAgentの艦隊でマシン速度でスキャン・テスト・実行している。さらにオープンウェイトモデルの普及で、この能力はもはや希少ではなくなっている。つまり：攻撃の自動化はすでに完了し、防御はまだチケットの担当割り当てを待っている——その差こそがインシデントの窓だ。

OpenAIは同時に、防御側が現在握る2つの構造的優位も挙げる。一つは、許可されたAgentにソースコードや内部システムのコンテキストを直接供給できること。もう一つは、市販のオープンウェイトモデルより強いフロンティアモデルを使えること。ただしこの先行は期間限定だ。OpenAIはこれを「防御者の窓」と呼ぶ——自律的な攻撃能力が広く普及する前に、継続防御を先に構築せよ。この窓は開け放っておくものではない。

防御工場はどんな構造か

アーキテクチャ上、既存ツールを置き換えるのではなく、API・CLI・MCPで既存ツールをAgentが実行できるパイプラインに繋ぎ込む。GitHub / GitLabでソース管理、Snyk / Semgrep / Tenableでスキャン、Jira / Linear / ServiceNowでチケット管理と追跡。基盤は2つのプレーンに分かれる：制御プレーンがオーケストレーション・ポリシー強制・クレデンシャルプロキシを担い、データプレーンは使い捨てで再現可能な開発環境を提供し、Agentが脆弱性の再現とパッチテストを行った後に環境を破棄する。これにより次の実行に汚染が波及しない。全体を監視・監査ログ・アクセス制御が包む。

コアのループは5ステップ：資産棚卸し → 脆弱性の発見 → 動的検証 → 担当紐づけ → 検証済み修正。各ステップは共有コンテキストの SECURITY.md を読み書きする——システムマップ、担当、調査証拠、テスト手順が蓄積され、次のループはゼロから始めるのではなく、前回の成果を再利用する。これは従来の5つのボトルネック（発見の待ち、重複が優先度を押し流す、担当者不在、エンジニアの重複調査、マージ後の検証不在）への一点ずつの回答でもある。

最も価値のある3つの数字

• 検出の37%は重複だった——Agentの重複除去が人間の分級前にノイズを消す
• 19.5%の検出が実行時に再現された——実際に示せたものだけが次の工程へ進み、「再現できず」と「テストが走れず」を明確に区別する
• パッチのロールバック率0.53%——修正は100% Codex生成だが、各パッチはレビュー前に実動サービスに対してセキュリティ修正と通常動作の両方を検証する

見落とされやすい教訓もある：パッチのマージは、修正の配備を意味しない。OpenAIは「マージ済みパッチ」と「全機群への配備済み修正」の間に乖離を見つけ、「配備結果の独立した再検証」をパイプラインの独立ステップにした。大規模な機群を回すあらゆるチームにとって、この1歩こそがMTTRの最終区間だ。

あなたのスタックへの3つの示唆

• まずは1つのワークフローから、一気に全自動化しない——OpenAI自身の経路は「小ロット＋人間レビュー → 段階的に権限を委譲」。人間は境界の設定・例外処理・結果の確認を担い続ける
• 再現可能な環境が地基（基礎）——Agentの検証品質は環境が問題を安定再現できるかで決まる。スケール前にここへ投資する
• コンテキストをファイルに沈める——SECURITY.md型の共有コンテキストは各ループが前回の証拠を再利用できる。システム内で最も安価なレバレッジ