2026年8月17日、OpenAIはGreg Brockman氏による「防御側に開かれた好機」を公開しました。AIモデルが現実のサイバー攻撃の一部を自動化できるようになりつつある一方、防御側にも同じ能力を弱点の発見や修正へ生かす余地があるという現状認識を示しています。
資料では、OpenAI自身の防御戦略と、他の企業や組織が取り得る具体策を紹介しています。AI時代のサイバー対策で、従来から必要な基本対策とAI活用をどう組み合わせ、どの範囲から自動化を進めるかを考える材料になる内容です。
AIがサイバー攻撃と防御の双方を速め始めている
OpenAIは、世界各地で開発されたAIモデルが、現実のサイバー攻撃の一部を自動化できるようになりつつあると説明しています。人が作ったソフトウェアの奥に長年残ってきたバグや忘れられた権限など、セキュリティ上の欠陥を発見し、悪用することが容易になっているという認識です。
一方で、同じ能力は防御にも使えます。AIに弱点を探させ、対応の優先順位を付け、修正を支援させることで、防御側もこれまでより速く行動できるとOpenAIはみています。
その転換点として挙げているのが、OpenAIとHugging Faceのインシデントです。OpenAIの説明では、複数のAIエージェントからなる集団が、OpenAIの研究インフラだけでなく、別企業の本番インフラにも自律的に侵入しました。攻撃には、未知のセキュリティ上の欠陥や、インターネット上に流出したユーザーアカウントの認証情報など、複数の手法が組み合わせられたとしています。
この出来事を踏まえ、OpenAIは、既存システムに長年残ってきた欠陥を攻撃者より先に見つけ、修正する必要性を強調しています。
また、OpenAIは2026年初めから、高度なサイバー能力を信頼できる防御担当者に限定して提供し始めたとしています。その後、複数企業から、フロンティア水準からわずか数か月遅れたサイバー能力を持つオープンウェイトモデルが公開されているとも説明しました。2026年8月17日の資料公開時点では、そのうち最新のモデルが8月末に公開される予定とされ、脅威環境を急速に変化させる可能性が高いとの見方が示されていました。
OpenAIは、AIが攻撃側と防御側の両方に使われるなか、防御側が活用を進めれば攻防の力学を変えられる可能性があるとみています。ただし、「AIが必ず防御側を有利にする」と確定しているわけではなく、OpenAIが示している見解です。
約15分で13件を発見、約1時間で修正 既存AIを防御に使った実例
AIを防御に使う具体例として、Greg Brockman氏は自身の個人サイト「gregbrockman.com」で行った検証を紹介しています。
対象はAWSでホストし、Cloudflareをフロントエンドに置いた単純な静的サイトでした。Brockman氏は、一般公開されているGPT-5.6 Solを使うChatGPT Workにセキュリティ評価を依頼したとしています。
その結果、約15分で13件の問題が見つかったということです。例として、メールのなりすまし対策に必要なDNSレコードが設定されていなかったこと、安全でないバージョンのjQueryを使っていたこと、CloudflareからAWSへのリクエストが暗号化されていないHTTPで転送されていたことなどが挙げられています。
ただし、資料では13件の多くについて、単独では悪用できないと思われるとしています。そのため、13件すべてを重大な脆弱性とみなすのは適切ではありません。
Brockman氏は続いてChatGPT Workに修正を依頼し、約1時間ですべて対応したと説明しています。Cloudflareの管理画面でDNSやTLS、高度なセキュリティ設定を変更し、jQueryを削除しました。さらに、AWSからCloudflare Pagesへ移行し、DMARCの段階的な導入も始めています。
この事例は、既存のAIモデルが、人では時間や専門知識が足りず手を付けにくい細かな問題について、発見から修正までを支援した一例です。
ただし、約15分、13件、約1時間という数字は、Brockman氏の個人サイト1件の事例に限られます。大規模な企業システムでも同じ速度や精度で対応できると一般化することはできません。
OpenAIの防御戦略は「AI活用」と「基本対策」の4本柱
OpenAIは、自社の防御戦略を4つの柱で説明しています。共通しているのは、AIによる能力強化と、従来から必要な基本対策の両方を進めることです。
1つ目は、モデルを使ってコードの安全性を高めることです。OpenAIは、セキュリティプラグインを含むCodexでコード変更を検証し、脆弱性をデプロイ前に特定して、開発者が問題を修正できるよう支援しています。
狙いは、単にセキュリティ上の指摘を増やすことではありません。実際に問題となる脆弱性をリリース前に見つけ、問題の特定から安全な修正をデプロイするまでの時間を短縮することです。
2つ目は、AIを使ったインフラの継続的な防御です。OpenAIでは現在、ほぼすべてのセキュリティアラートをまずAIがトリアージし、その後に人が対応へ加わるとしています。ここでいうトリアージは、多数の警告について内容を確認し、対応の優先順位を整理する作業です。
これにより、防御担当者の単純作業を減らし、対応時間を短縮するとともに、人が状況の見極めや判断、専門知識の活用に時間を使えるようにする狙いがあります。
ただし、影響の大きい意思決定は引き続き人が担います。OpenAIは、自動対応についても対象範囲を限定しながら進めていると説明しています。
3つ目は、フロンティアAIを使い、潜在的な攻撃経路を継続的に探すことです。脆弱性、設定ミス、過剰な権限を持つID、意図せず生まれた信頼境界などを特定し、攻撃者に悪用される前に解消することを目指しています。
4つ目は、多層防御や最小権限、ネットワーク分離、監視、安全なパッチ適用とデプロイなど、従来型の基本対策を大規模に徹底することです。OpenAIは、こうした統制はAI時代に不要になるどころか、むしろ重要性が増すとしています。
| 防御の柱 | 主な対象 | OpenAIが示した取り組み | 位置づけ |
|---|---|---|---|
| コードの安全性 | ソフトウェア開発 | AIでコード変更を検証し、脆弱性の発見や修正を支援 | リリース前の発見と、安全な修正までの時間短縮を目指す |
| インフラ防御 | セキュリティアラート | AIが初期トリアージを行い、限定した範囲で自動対応も進める | 影響の大きい意思決定は人が担う |
| 攻撃経路の探索 | 脆弱性、設定、権限など | AIで潜在的な攻撃経路を継続的に発見・検証 | 攻撃者に悪用される前の発見と解消を目指す |
| 基本対策 | 組織全体のシステム | 多層防御、最小権限、ネットワーク分離、監視、パッチ適用などを徹底 | AI時代にも重要性が高まる基礎的な統制 |
OpenAIはさらに、人が書いたソフトウェアを上回る安全性を備えたコードを書くことに特化して、モデルのトレーニングを始めているとしています。
また、モデルの数学的証明能力を応用することで、人の手では極めて難しかったソフトウェアの安全性の形式検証が可能になるとの見通しにも触れています。いずれも、すでに完成・実用化された成果ではなく、トレーニング中の取り組みや将来的な応用可能性として示された内容です。
企業はどこから始める？ AI防御を3段階で導入する考え方
OpenAIは他の組織に対し、AIを防御へ取り入れるための10項目の具体策を示しています。ただ、10項目を同列に読むだけでは、自社が最初に何をすべきか判断しにくい面があります。
そこでFocus4では、OpenAIが示した「最初から全面的な自動化を目指さない」という考え方を軸に、複数の提言を実行順の3段階に整理します。
この3段階は、OpenAIが公式に定義したフレームワークではありません。資料に示された複数の提言を、企業が導入の順番を判断しやすいようFocus4が再整理したものです。
第1段階 最優先システムで読み取り中心の評価から始める
最初に必要なのは、AIツールそのものだけではなく、組織として取り組む合意と、優先して守る対象を決めることです。
OpenAIは、セキュリティ部門とエンジニアリング部門が迅速に対応できるよう、支援、連携、リソースを確保することを提言しています。机上演習を行い、こうした攻撃が自社でどのように表れ、どう対応するかをシミュレーションすることも挙げています。
そのうえで、全社展開を待つのではなく、最優先のシステムからAIエージェントを使い始めます。
評価対象として挙げられているのは、インターネットに公開されたサービス、認証フロー、Infrastructure as Codeなどのインフラ構成、デプロイパイプライン、機密情報を扱うシステムなどです。
AIエージェントには、評価に必要なコードベースやインフラ構成、技術文書へのアクセスを認めます。また、自社のアーキテクチャ、セキュリティ基準、脅威モデル、対応手順に合わせた独自のスキルを構築することも提言されています。
一方、自動化は最初から広い範囲へ進めるのではありません。OpenAIは、1つのリポジトリに対する読み取り専用のセキュリティスキャンや、既存ログへの読み取り専用アクセスから始める方法を示しています。
第2段階 脆弱性対応と開発プロセスへAIを組み込む
次の段階では、AIを「新しい問題を探す道具」だけでなく、すでに分かっている問題の整理と修正にも使います。
コードスキャナーの検出結果、依存関係のアラート、セキュリティチケット、バグ報奨金プログラムの報告、過去の評価結果などをAIに与え、悪用可能な問題とノイズを切り分けます。そのうえで、関連する脆弱性を探し、修正の優先順位を付けさせます。
さらに、開発工程にもAIを組み込めます。OpenAIは、コード変更をマージする前にエージェントへレビューさせ、CIでセキュリティチェックを実行することを提言しています。
確認済みの問題については、対象を絞ったパッチの生成と検証、回帰テストの作成、脆弱性が再現しなくなったことの確認もAIに支援させます。
ここでも、人の役割をなくすわけではありません。重大な変更では人によるレビューを維持し、実際の問題を特定してから安全な修正案をエンジニアへ提示するまでの不要な遅れを減らす考え方です。
第3段階 信頼性を確かめながら自動化範囲を広げる
OpenAIが明確に避けるよう求めているのが、「最初から自律型のセキュリティオペレーションセンターを構築すること」です。
最初は、1つのリポジトリへの読み取り専用のセキュリティスキャンや、既存ログへの読み取り専用アクセスから始め、すでに解決したアラートをAIに確認させます。
この段階では、AIには証拠の要約と対応方針の提案を任せ、意思決定はすべて人が行います。
結果の信頼性を確認できるようになったら、提案のみを行うプルリクエストのスキャン、実運用のアラートトリアージ、さらに対象を厳密に限定した誤検知の自動クローズへと広げます。
OpenAIは、インシデント対応、検知エンジニアリング、マルウェア分析などでAIを利用するフォレンジック調査能力についても、必要になってから準備するのではなく、事前にログやセキュリティアラートを分析する練習をしておくことを提言しています。
また、ハックウィークなどを設け、新しいツールや小さな自動化を試し、結果を確かめながら改善することも勧めています。大きな仕組みを一度に完成させるのではなく、小さな改善を繰り返し、自動化への信頼が高まるにつれてAIへ任せる範囲を広げる考え方です。
自社の現在地を確認するなら、次の項目が一つの目安になります。
経営・現場でAIを防御業務に試す合意があるか
優先して評価するシステムを決めているか
まず読み取り権限を中心に試せるか
未対応の脆弱性情報をAIに分析させられる状態か
重大な判断を人が担う運用になっているか
結果の信頼性を確認してから自動化範囲を広げているか
AI時代でも、防御の基本を飛ばして全面自動化しない
OpenAIの提言を通して一貫しているのは、高性能なAIをできるだけ早く防御担当者へ渡し、攻撃者より早く弱点を見つけ、発見から修正までの時間を短縮しようという考えです。
ただし、それはセキュリティ業務をAIへ丸ごと移すことを意味しません。
OpenAI自身、ほぼすべてのセキュリティアラートを最初にAIへトリアージさせながら、その後は人が対応へ加わり、影響の大きい意思決定は人が担うとしています。他の組織に対しても、最初から全面的な自律化を目指すのではなく、読み取り中心の小さな範囲から始め、信頼性を確かめてから自動化を広げるよう求めています。
同時に、多層防御、最小権限、ネットワーク分離、監視、パッチ適用、安全なデプロイといった従来型の基本統制を維持することも重要です。AI活用と基本対策は、どちらか一方を選ぶ関係ではありません。
そのため、企業にとっての次の一手は、既存の基本統制を保ちながら、影響を限定できる領域でAIを防御業務へ取り入れ、結果への信頼を確認したうえで自動化の範囲を広げることだと整理できます。
OpenAIは、今後数か月を防御側にとって重要な期間とみており、あらゆる組織がセキュリティプログラムの大幅な自動化に着手する必要があると主張しています。
また、AI研究機関、セキュリティベンダー、企業、メンテナーが、検証済みの知見や修正策、実践的なプレイブックを共有し、エコシステム全体の防御力を高めることも求めています。
特定のAI製品を導入すること自体がゴールではありません。OpenAIの提言から見えるのは、AI時代の防御では、基本を固めたうえでAIを早く使い始め、人が重要な判断を担いながら、信頼できる範囲から自動化を積み上げていくことが重要だという考え方です。
出典：防御側に開かれた好機
