OpenAI Defense Factoryとは？脆弱性対応の5工程と企業導入の注意点

OpenAIは、AIエージェントを使って脆弱性の発見・検証・修正・再確認を継続する「Defense Factory」の仕組みを公開しました。

AIによるサイバー攻撃が速くなる一方、防御側もAIを使って調査・修正を早められます。ただし、「AIに脆弱性を探させれば完成」という仕組みではありません。

Defense Factoryでは、資産の棚卸しから脆弱性の発見、実環境に近い検証、担当者の割り当て、修正後の再確認までを一つのループとして設計します。

この記事では、Defense Factoryの5工程、OpenAI社内で確認された成果、企業が導入する際に人へ残す判断を整理します。

この記事でわかること（結論）

• Defense Factory：AIエージェントを使って脆弱性対応を継続的に回す運用方式
• 5工程：棚卸し→発見→動的検証→担当割当→検証済み修正の順で循環する
• 重要な前提：AIを本番環境へ自由に接続するのではなく、隔離された再現可能な環境で検証する
• 人の役割：重要な変更、本番反映、曖昧な判断、最終確認は人が担当する
• 始め方：全工程を最初から自動化せず、1つのワークフローを小規模に検証してから広げる

OpenAI Defense Factoryとは？

Defense Factoryは、AIエージェントを中心に脆弱性を継続して発見・検証・修正するセキュリティ運用モデルです。

OpenAIは、従来の定期的な脆弱性診断だけでは、長時間動くAIエージェントによる攻撃速度へ対応しにくくなるとして、自社で構築したアーキテクチャと運用方法を公開しています（出典：OpenAI「Defense Factory」）。

新しいセキュリティ製品を1つ導入する話ではない

Defense Factoryは、「Defense Factory」という製品を契約すれば利用できる仕組みではありません。

GitHubやGitLabなどのソース管理、SnykやSemgrepなどのセキュリティツール、Jira・Linear・ServiceNowなどの課題管理、AIエージェント、再現可能な開発環境をつなぎ、既存の脆弱性対応を一つの流れとして運用します。

AIの役割は発見だけではない

AIエージェントは、脆弱性候補を見つけるだけでなく、重複の整理、再現確認、担当チームの特定、修正案の作成、修正後の再確認まで関わります。

一方、OpenAIは重要な変更について人がレビューし、本番へ反映した修正も独立して確認する設計を残しています。

Defense Factoryを構成する5つの工程

OpenAIが示す防御ループは、次の5工程です。

工程	役割	AIエージェントが行うこと
1. Inventory	守る対象を把握する	システム・コード・担当者などを結び付ける
2. Discovery	脆弱性候補を探す	コードや既存スキャン結果から候補を集める
3. Dynamic validation	本当に問題か確かめる	隔離環境で再現し、重複・誤検知を整理する
4. Ownership assignment	担当者を決める	システム情報や履歴から適切な担当チームへ割り当てる
5. Verified remediation	修正して直ったことを確認する	修正案を作り、人の承認後に再検証する

発見しただけでは完了にしない

Defense Factoryでは、セキュリティツールからアラートが出ただけで「脆弱性」とは確定しません。

候補を隔離環境で再現し、本当に影響があるかを確かめます。静的なコード上の経路だけではなく、実行時に再現できる証拠を残す設計です。

修正しただけでも完了にしない

コードへ修正を入れてマージしただけでは、実際のサービスへ反映されているとは限りません。

OpenAIは、デプロイ後にも修正が有効かを再確認し、検証できなければ対応を完了扱いにしない考え方を示しています。

AIエージェントを安全に動かす仕組み

Defense Factoryで重要なのは自動化率だけではありません。AIが強い権限を持つほど、実行環境・認証情報・監視を分離する必要があります。

検証は一時的な隔離環境で行う

脆弱性を再現するときは、必要なコード・依存関係・サービスを用意した再現可能な開発環境を使います。

OpenAIは、実行ごとに新しく作成して終了後に破棄する一時環境を重視しています。前回の操作や変更が次の検証へ残らないようにするためです。

ポリシーと認証情報を実行環境から分ける

OpenAIの参考アーキテクチャでは、実行環境を動かす部分とは別に、ワークロード管理、ポリシー適用、認証情報の仲介を行うControl planeを置いています。

AIへ本番用の秘密情報を直接渡しっぱなしにするのではなく、必要な操作に応じてアクセスを制御する考え方です。

AIの操作を監査できる状態にする

ホスト上の活動、インフラの状態、AIエージェントの操作を記録し、後から確認できる構成を取ります。

AIエージェント全体の最小権限・隔離・Human-in-the-Loopについては、AIエージェントのセキュリティ対策の記事でも整理しています。

OpenAI社内ではどこまで自動化できた？

OpenAIは、250人超が参加し100以上のサービス領域を対象とした社内セキュリティスプリントを、Defense Factoryの起点として紹介しています。

公開されている主な結果は次のとおりです。

指標	OpenAIが公表した結果
初日に対応した緊急・高優先度Issue	53件
AIによる担当割当の受理率	90.6％
重複と判定された候補	37％
実行環境で再現できた候補	19.5％
動的検証後の偽陽性率	0.81％
修正後にロールバックされた割合	0.53％

この数字を自社の効果予測には使わない

これらはOpenAI自身のシステム、ツール、モデル、セキュリティチームで得られた結果です。

「Defense Factoryを導入すれば偽陽性率0.81％になる」「初日に53件直せる」という一般的な性能保証ではありません。自社で導入する場合は、自社の既存スキャン結果や対応時間を基準に比較する必要があります。

最初から完全自動ではなかった

OpenAIは、小さなバッチと人のレビューから始め、結果の信頼性が確認できた工程から手作業を減らしたと説明しています。

AIが「できること」と「自動で変更してよいこと」を分離し、人は境界設定、例外処理、結果確認へ役割を移しています。

企業がDefense Factory型の運用を始めるには？

OpenAIは、最初から5工程すべてを自動化するのではなく、一つのワークフローから始めることを案内しています。

まず1工程を選ぶ

たとえば、既存の脆弱性スキャン結果から重複を整理する、修正候補を担当チームへ振り分ける、修正案を隔離環境でテストするといった範囲から始めます。

効果を確認する前に、AIへ本番システムの変更権限まで渡す必要はありません。

既存のセキュリティツールを捨てない

Defense Factoryは、従来のセキュリティ製品をAIへ置き換える考え方ではありません。

既存のソース管理、スキャナー、Issue管理、社内の担当情報を、MCP・CLI・APIなどからAIが利用できる状態へつなぎます。

高度なサイバーモデルは別途アクセス条件を確認する

OpenAIは高度な防御業務向けにDaybreakの利用申請を案内していますが、関心表明を行っただけでモデルアクセスや提供時期が保証されるわけではありません。

一般的な脆弱性対応では、まず既存環境と通常のCodex Securityワークフローから検証する方が現実的です。

実務上の注意

Defense Factoryは自動化の事例として有用ですが、「AIへセキュリティを丸投げする仕組み」と理解すると逆にリスクが増えます。

本番変更を最初からAIへ完全委任しない

修正案の生成と、本番環境への反映は分けます。OpenAIの運用でも、影響の大きい変更は人がレビューし、承認された後にデプロイしています。

検証環境を本番環境から分離する

脆弱性の再現では意図的に危険な挙動を試す場合があります。

本番用の認証情報や自由な外部通信を持たせず、用途ごとに隔離された環境を準備します。評価環境の分離が不十分だった事例は、OpenAIとHugging Faceのセキュリティ事故でも確認されています。

自動化率より「完了条件」を先に決める

Issueを作った、PRを作った、コードをマージしただけで対応完了としないようにします。

何をもって「脆弱性が再現できた」「修正が本番へ反映された」「再発しないことを確認した」とするかを決めてから自動化してください。

まとめ

OpenAI Defense Factoryは、AIエージェントを使って脆弱性の棚卸し・発見・検証・担当割当・修正確認を継続的に回すセキュリティ運用モデルです。

特徴はAIが脆弱性を見つけることだけではなく、隔離環境で本当に問題かを確かめ、担当者へつなぎ、修正後まで再検証するところにあります。

企業が取り入れる場合は、全工程を一度に自動化するより、一つのワークフローを小さく始め、人のレビューと明確な完了条件を残しながら自動化範囲を広げる方が安全です。

よくある質問

関連する用語・出典

• Defense Factory：AIエージェントを中心に脆弱性の発見から修正確認までを継続する運用方式
• Dynamic validation：候補となる脆弱性を隔離された実行環境で再現・検証する工程
• Verified remediation：修正案を作るだけでなく、本番反映後に問題が解消したことまで確認する工程
• Codex Security：脆弱性の発見・検証・修正などを支援するOpenAIのセキュリティ向けCodex機能
• 一次情報：OpenAI「Defense Factory」

※本記事は2026年9月11日朝時点のOpenAI公式情報をもとにしています。掲載した数値はOpenAI社内でのセキュリティスプリント・運用結果であり、他社環境で同じ成果を保証するものではありません。DaybreakやCodex Securityの利用条件、モデル、提供範囲は変更される可能性があります。