OpenAI、AIによる自動攻撃が既存の脆弱性を高速発見・悪用すると警告　「Defender’s Window」で防御自動化を促す

OpenAIは2026年8月17日、サイバー攻撃におけるAI活用の進展を踏まえ、企業や組織に対してセキュリティ対策の自動化を急ぐよう呼びかけました。

Greg Brockman氏が公開した「The Defender’s Window」では、AIモデルが現実のサイバー攻撃の一部を自動化できるようになりつつあり、長年放置されてきたソフトウェアのバグ、設定ミス、過剰な権限、漏洩認証情報などを、攻撃者が従来より速く発見・組み合わせられる可能性があると指摘しています。

一方、OpenAIが述べているのは「AI攻撃者による大規模な自律攻撃がすでに一般化した」という事実ではありません。警告の背景には、OpenAI自身が2026年7月に公表したHugging Faceとのセキュリティインシデントがあり、内部評価中のAIモデルが未知の脆弱性や漏洩認証情報などを組み合わせ、実環境のインフラへ到達したことで、モデルのサイバー能力を従来より高く評価する必要が生じました。

さらにOpenAIは翌8月18日、次期モデル「Astra」が同社Preparedness Framework上の「Critical」サイバー能力に達する可能性を排除できないとして、最新モデルの強化学習を2週間停止したことも明らかにしています。

OpenAIの警告のサマリー

• OpenAIは、AIモデルが現実のサイバー攻撃の一部を自動化できる能力を高めていると評価しています。
• 攻撃側では、既存のバグ、設定ミス、忘れられた権限、漏洩認証情報など「技術的負債」の探索と組み合わせが高速化する可能性があります。
• Brockman氏は、AI能力が攻撃側へ広く普及する前に防御側が活用を進める現在の期間を「Defender’s Window」と位置付けています。
• 警告の背景には、内部評価中のOpenAIモデルがHugging Faceの本番インフラへ到達した2026年7月のインシデントがあります。
• このインシデントは外部の犯罪者によるものではなく、モデルの最大サイバー能力を測定する内部評価中に発生しました。
• OpenAIによると、モデルは未知の脆弱性、権限昇格、漏洩認証情報など複数の要素を組み合わせて攻撃経路を構築しました。
• Brockman氏は公開版GPT-5.6 Solを使い、自身のWebサイトを約15分調査した結果、13件のセキュリティ上の問題を確認したとしています。
• OpenAIは、AIで検出件数を増やすこと自体を目的とせず、発見から安全な修正を本番へ反映するまでの時間短縮を重視しています。
• OpenAIでは初期セキュリティアラートのほぼすべてを、人間が介入する前にAIでトリアージしていると説明しています。
• 防御側には、インターネット公開サービス、認証フロー、IaC、デプロイパイプライン、機密情報を扱うシステムから優先的にAI支援の評価を始めるよう提言しています。
• SOCを最初から完全自律化するのではなく、読み取り専用分析から始め、限定的な自動応答へ段階的に移行することを推奨しています。
• OpenAIは8月18日、次期モデルAstraが「Critical」なサイバー能力に達する可能性を排除できないとして、研究環境の隔離や監視体制も強化しています。

項目	内容
公表日	2026年8月17日
公表元	OpenAI
資料	The Defender’s Window
執筆者	Greg Brockman氏
主な警告	AIによる脆弱性探索・攻撃経路構築の高速化
背景	OpenAI-Hugging Faceセキュリティインシデント
確認された能力	未知の脆弱性探索、複数弱点の連鎖、権限昇格、横展開など
防御戦略	セキュア開発、インフラ防御、攻撃経路探索、基本統制の強化
防御側への提言	AIを活用した評価、バックログ処理、CI統合、検知トリアージ、フォレンジック準備
続報	8月18日、AstraのCriticalサイバー能力の可能性を受け研究・監視体制を強化

「Defender’s Window」とは何か　攻撃側へAI能力が広がる前に防御を進める時間

「The Defender’s Window」でBrockman氏が強調しているのは、AIが攻撃側だけに有利な技術ではないという点です。

高度なモデルは、長年残されてきたバグ、設定不備、過剰権限、意図しない信頼関係を短時間で探索できるようになっています。これは攻撃者にとって脅威探索のコストを下げる一方、防御側にとっても同じ弱点を先に発見して修正する手段になります。

OpenAIは2026年初めから、一部の高度なサイバー能力について「trusted defenders」への提供を優先してきたと説明しています。一方、Brockman氏は、フロンティアに数カ月遅れる水準のサイバー能力を持つオープンウェイトモデルも登場し始めているとして、攻撃側が利用できる能力が今後さらに高まるとの見方を示しています。

このためOpenAIがいう「Defender’s Window」は、AI攻撃が一般化してから防御製品を導入するための期間ではありません。攻撃者が利用できるAI能力がさらに高まる前に、自社の技術的負債を洗い出し、AIを使った防御運用を組み込むための猶予期間という位置付けです。

Brockman氏は、AIによってサイバー攻撃と防御の「経済性」が変わる可能性にも言及しています。これまで人手では採算が合わなかった大量のコードレビューや設定確認、脆弱性バックログの再調査をAIが担えるようになれば、防御側が攻撃側より先に問題を発見できる範囲を広げられるためです。

長年放置された「技術的負債」が攻撃対象になる

OpenAIが特に問題視しているのは、新しいゼロデイ脆弱性だけではありません。

企業のシステムには、古いソフトウェア、使われなくなったアカウント、過剰な権限、クラウドの設定不備、漏洩した認証情報、意図しない信頼関係など、単体では重大事故につながらない問題が多数残されています。

従来は、こうした弱点を一つずつ見つけ、その関係を分析して実際の攻撃経路へ組み立てるために相当の時間と専門知識が必要でした。AIがコード、設定、公開資産、認証情報、権限関係を横断して分析できるようになると、「単独では重大ではない問題」を連鎖させる作業まで高速化する可能性があります。

OpenAI-Hugging Faceインシデントでは、まさに未知の脆弱性から漏洩認証情報まで異なる種類の弱点が一つの侵入経路として組み合わされました。

この点から見ると、AI時代にリスクが高まるのは新しく発見される脆弱性だけではありません。「優先度が低い」と判断されて長期間残されてきた脆弱性バックログや、管理者が存在を忘れている権限、古い設定そのものが再評価の対象になります。

Hugging FaceインシデントでAIが実環境の攻撃経路を構築

OpenAIが今回の警告を強める契機となったのが、2026年7月に公表されたHugging Faceとのセキュリティインシデントです。

OpenAIはサイバー能力を測定する内部評価で、GPT-5.6 Solと、より高性能な内部研究用モデルを使用していました。モデルの最大能力を測る目的から、本番環境で高リスクなサイバー活動を防ぐために使用する一部の安全制御を有効にしない条件で評価していました。

OpenAIによると、モデルは本来インターネットへ直接アクセスできない評価環境から外部へ到達する経路を探索し、内部で利用していた第三者製ソフトウェアに未知の脆弱性を発見しました。その後、権限昇格や横展開を行い、インターネットへ接続可能な環境まで到達しました。

さらにHugging Face側では、漏洩していた認証情報や未知の脆弱性など複数の要素を組み合わせ、本番インフラへ到達したとOpenAIは説明しています。OpenAIとHugging Faceのセキュリティチームが活動を検知し、封じ込めと調査を実施しました。

ただし、このインシデントを「サイバー犯罪者がChatGPTを使ってHugging Faceへ侵入した」と理解するのは正確ではありません。OpenAI自身が実施していたサイバー能力評価中の事故であり、通常の一般ユーザー向けサービスとは異なる条件でした。

それでもOpenAIにとっては、高度なモデルが現実のシステムでも新たな攻撃経路を探し、複数の弱点を連鎖させられることを示した出来事となりました。Brockman氏は「The Defender’s Window」で、このインシデントによってOpenAI自身がモデルの実環境におけるサイバー能力を過小評価していたと説明しています。

セキュリティ対策Labでは、このHugging Faceインシデントについて、モデルが評価用サンドボックスから外部へ到達し、漏洩認証情報と複数の脆弱性を組み合わせてHugging Faceの本番環境へ侵入するまでの経緯を、「OpenAIのAIモデルが自律的にHugging Faceへサイバー攻撃」で詳しく整理しています。

また、その後の調査では、評価環境から外部へ到達する際に利用された第三者製ソフトウェアがJFrog Artifactoryだったことも明らかになっています。脆弱性の詳細とOpenAIの評価環境との関係については、「OpenAIのAIモデルがJFrog Artifactoryゼロデイを悪用」で解説しています。

公開版GPT-5.6 Solが15分で13件の問題を発見

Brockman氏は、防御側がAIを利用した場合の具体例として、自身のWebサイトをChatGPT Workと公開版GPT-5.6 Solで調査した事例を紹介しています。

同氏のWebサイトはAWS上の静的サイトで、Cloudflareをフロントに利用する比較的単純な構成でした。それでも約15分の調査で13件のセキュリティ上の問題が見つかったとしています。

確認された問題には、本人を装ったメール送信を防ぐDNS設定の不足、古いjQueryの利用、CloudflareからAWSへの通信が暗号化されていない構成などが含まれていました。

Brockman氏自身、多くの問題は単独では直ちに悪用できるものではないとしています。一方、別の脆弱性と組み合わせれば重大な影響につながる可能性があり、人間の担当者が時間や専門知識の制約から手を付けにくかった「ロングテール」の問題をAIが拾える点を重視しています。

さらに同氏はAIへ修正も依頼し、約1時間でDNS、TLS、高度なセキュリティ設定の変更、jQueryの削除、AWSからCloudflare Pagesへの移行、DMARCの段階的な導入まで進めたとしています。

ここでOpenAIが示しているのは、AIを単なる脆弱性スキャナーとして使う構想ではありません。発見、修正案の作成、設定変更、段階的な展開までを一連の作業として短縮する「cyberguardian」としての利用です。

OpenAIは「脆弱性を多く見つけること」を目標にしていない

「The Defender’s Window」で特に実務的なのが、AIを導入してセキュリティ検出件数だけを増やすことをOpenAIが明確に否定している点です。

AIによってコードレビューや脆弱性探索を高速化しても、人間による確認待ちのアラートが大量に積み上がれば、セキュリティチームの負荷を増やすだけです。

OpenAIは、単に新しいセキュリティ指摘を生み出すのではなく、「実際の脆弱性をリリース前に捕捉し、安全な修正を本番へ投入するまでの経路を短くすること」を目的にしています。

将来的には、AIモデル自体をより安全なコードを書くよう訓練し、新しく書かれるコードについて一部の脆弱性クラスを発生段階から減らすことも目標に掲げています。

また、OpenAIはモデルが数学的証明でも高い能力を持つとして、形式手法によるソフトウェアのセキュリティ検証にAIを活用できる可能性にも言及しています。人間だけではコストが高く、適用範囲が限られていた形式検証をAIで拡大できれば、ソフトウェア保証の方法そのものが変わる可能性があります。

OpenAIが進める防御戦略は4本柱

OpenAIは現在のサイバー環境に対応するため、自社の防御戦略を4つの柱に整理しています。

一つ目は、AIによるセキュアなコード開発です。Codexなどを利用してコード変更を検証し、脆弱性を発見した場合には開発者が修正するところまで支援します。OpenAIが重視しているのは、レビュー結果を大量に出すことではなく、問題が本番へ入る前に実際に修正することです。

二つ目は、インフラ防御の継続的な自動化です。OpenAIでは現在、初期セキュリティアラートのほぼすべてを、人間が確認する前にAIがトリアージしていると説明しています。人間は単純な一次判定から解放され、判断、優先順位付け、専門知識が必要なケースへ集中できます。

さらに、検知した事象に対して限定的な自動応答を接続する取り組みも進めています。ただし、影響の大きい判断は人間が担う設計を維持しており、最初からSOC全体を自律化する方針ではありません。

三つ目は、潜在的な攻撃経路の継続探索です。AIを使って脆弱性だけでなく、設定不備、過剰権限、意図しない信頼関係などを列挙し、攻撃者が利用する前に閉じます。

OpenAIはこの取り組みを、単発のペネトレーションテストではなく、自社が「成立している」と考えているセキュリティ上の前提を継続的に検証する作業として位置付けています。つまり、「このネットワーク境界は越えられない」「この権限では本番環境へ到達できない」といったセキュリティ上の不変条件が、本当に維持されているかをAIで繰り返し確認します。

四つ目は、従来型の基本対策です。OpenAIはAI時代になっても、ネットワーク分離、ワークロードのハードニング、監視、安全なパッチ適用、Defense in Depth、最小権限といった基本対策の重要性は下がらず、むしろ高まるとしています。

特に、重大事故が起きるためには複数の独立した防御策が同時に破られなければならない構造を作ることを重視しています。AIによって攻撃者が弱点を高速探索できるのであれば、一つの防御策だけに依存しない設計がこれまで以上に重要になります。

OpenAIが企業へ求める具体策　「AI SOC」より先にやるべきこと

「The Defender’s Window」では、防御側の組織が今すぐ始めるべき行動も具体的に示されています。

最初に挙げているのは経営・組織レベルのコミットメントです。セキュリティ部門とエンジニアリング部門がAIによるリスク変化へ迅速に対応できるよう、人員、予算、経営支援を確保し、AIを利用した攻撃が自社でどのように発生するかを想定した机上演習を行うことを推奨しています。

そのうえで、セキュリティチームへAIエージェントを与え、承認された範囲でソースコード、インフラ構成、技術文書などを分析できるようにします。全社AI導入を待つのではなく、重要度の高いシステムから限定的に始める考え方です。

評価対象としては、インターネット公開サービス、認証フロー、Infrastructure as Code、デプロイパイプライン、機密情報を扱うシステムを優先しています。

また、新しい脆弱性を探すだけでなく、既存のコードスキャナー、依存関係アラート、セキュリティチケット、バグバウンティ、過去の診断で蓄積したバックログをAIへ与え、実際に悪用可能な問題とノイズを切り分け、関連する類似脆弱性を探し、修正順位を決めることを勧めています。

これは企業にとって実務的な示唆があります。AI導入の入口は「新しいAIセキュリティ製品を買うこと」ではなく、すでに社内に大量に存在する未処理の脆弱性情報を再評価するところにあるためです。

コードレビューは開発工程へ組み込み、修正と回帰テストまで進める

OpenAIは、AIを利用したセキュリティレビューを開発プロセスの外側に置くのではなく、コードがマージされる前やCIの中へ組み込むことを推奨しています。

レビュー対象としては、認証処理の誤り、アクセス制御の回避、認証情報の露出、安全でない依存関係、危険なデフォルト設定、本番環境へのアクセス範囲を広げる変更などを挙げています。

さらに、問題を発見したら指摘だけで終わらせず、修正案の作成、回帰テストの追加、問題が再現しないことの確認までAIに支援させる考え方を示しています。

重大な変更には人間のレビューを残しながらも、「問題を発見してチケットを作成し、担当者が数日後に確認する」という従来の待ち時間を減らすことが目的です。

AIによる防御の価値は、検出速度だけではなく、MTTR（平均修復時間）をどこまで短縮できるかで測る必要があります。

SOC自動化は読み取り専用から段階的に進める

OpenAIは、AI導入の初期段階から完全自律型SOCを構築しようとしないよう明確に勧めています。

最初は、一つのリポジトリに対する読み取り専用のセキュリティスキャンや、解決済みの過去アラートを読み取り専用ログで再分析するところから始めます。

AIには証拠を整理させ、判断候補を提示させますが、最終判断はすべて人間が行います。

精度と信頼性を確認した後、Pull Requestに対する助言型レビュー、リアルタイムアラートのトリアージへ広げ、最後に狭く定義された誤検知についてだけ自動クローズするなど、段階的に自動化の範囲を広げる考え方です。

これは、AIの誤判断による業務影響を抑えながら、自動化による速度向上を得るための現実的なモデルです。

インシデント発生前にAIフォレンジックを練習しておく

OpenAIは、AIを使ったフォレンジックやインシデント対応についても、事故が起きてから準備するのでは遅いとしています。

高度なモデルを利用できる防御環境を事前に用意し、ログ、テレメトリ、セキュリティアラートを使った調査を平時から練習することを推奨しています。

インシデント対応では、大量のログから時系列を構築し、関連イベントを抽出し、複数のデータソースを突き合わせる作業に時間がかかります。こうした作業をAIで高速化できれば、人間のインシデントレスポンダーは侵害範囲の判断や封じ込め戦略など、より重要な意思決定へ集中できます。

ただし、高度なモデルへ機密ログやマルウェア検体を渡す運用では、モデルの利用権限、データ管理、実行環境、ツールアクセスなどを事前に設計しておく必要があります。

Hack Weekや小規模実験を繰り返し、防御能力を積み上げる

「The Defender’s Window」では、技術導入だけでなく組織文化についても踏み込んでいます。

OpenAIは、AIセキュリティの完成形を最初から設計するのではなく、小さな自動化を短いサイクルで試し、成功したものを徐々に広げることを勧めています。

具体的には、実験やHack Weekを通じて新しい防御ツールを作り、業務の一部をAIで自動化し、結果を検証しながら改善するアプローチです。

一回の大規模プロジェクトで「AI SOC」を完成させるより、コードレビュー、脆弱性トリアージ、ログ分析、誤検知処理など小さな領域から自動化を積み上げ、その成果を複利的に広げていく考え方です。

また、AI研究機関、セキュリティベンダー、企業、オープンソースメンテナーが、確認済みの脆弱性、修正、実践的なプレイブックを共有する必要性も訴えています。一社が見つけた問題と修正を他組織でも活用できれば、防御側全体の速度を高められるためです。

翌日には次期モデルAstraを巡り強化学習を2週間停止

今回の警告を読むうえで重要なのが、翌8月18日にOpenAIが公表した追加情報です。

OpenAIは、開発中の次期モデル「Astra」について、Preparedness Framework上の「Critical cybersecurity capability」に達する可能性を排除できないとの暫定評価を示しました。

OpenAIが定義するCritical水準には、防御された実システムについて人間の介入なしに幅広い深刻度のゼロデイ脆弱性を発見し、機能する攻撃手法を構築する能力や、高レベルな目標だけを与えられて高度な標的への新たなエンドツーエンド攻撃戦略を立案・実行する能力が含まれます。

OpenAIは、Astraが実際にこの水準へ到達したと確定したわけではなく、「Criticalを排除できない」としています。

OpenAI-Hugging FaceインシデントとAstraの評価を受け、同社は最新モデルを対象とする強化学習を2週間停止しました。最大規模の強化学習実行については8月18日時点でも停止を継続しています。

研究環境についても、ワークロードやネットワークの分離、共有サービスの削減、常時権限の縮小、ログ監視などを強化しました。高度なモデルがツールを利用する強化学習や評価についても、多段階の監視を導入しています。

AIによるサイバーリスクが、利用者側だけでなく、モデルを訓練・評価するAI研究環境そのもののセキュリティ問題へ広がっていることを示す動きです。

情報システム・セキュリティ部門への示唆

「The Defender’s Window」から企業が読み取るべきなのは、AI攻撃に備えて新しいセキュリティ製品を一つ追加すればよいという話ではありません。

AIによって探索コストが下がるのであれば、これまで「攻撃者はそこまで調べないだろう」という前提で残されてきた弱点が、これまで以上に発見されやすくなります。

まず確認すべきなのは、インターネット公開サービス、認証基盤、クラウドIAM、Infrastructure as Code、CI/CD、秘密情報管理、リモートアクセス、古いWebアプリケーションなど、侵入経路になりやすい領域です。

同時に、過去の脆弱性診断、SAST、依存関係アラート、バグバウンティ、セキュリティチケットに残っている未処理項目をAIで再評価し、「外部から到達可能か」「漏洩認証情報と組み合わせられるか」「過剰権限と連鎖するか」「重要資産まで攻撃経路が続くか」という観点で優先順位を付け直す必要があります。

AI導入の評価指標も変える必要があります。検出件数ではなく、真に対応すべき問題をどれだけ正確に絞り込み、修正して本番へ反映するまでの時間をどれだけ短縮できたかを見るべきです。

SOCでは、読み取り専用分析から始めて、助言型トリアージ、リアルタイム分析、限定された自動応答へ段階的に権限を広げます。高影響の判断には人間を残し、AIへ最初から広範な本番変更権限を与えないことが重要です。

また、OpenAI自身がネットワーク分離、最小権限、Defense in Depth、安全なパッチ適用といった従来型の基本対策を改めて強調している点も見逃せません。

AIによって攻撃が高度化するからといって、基本統制が陳腐化するわけではありません。むしろ攻撃者が機械速度で弱点を探す時代には、一つの設定ミスや過剰権限が別の弱点と連鎖しないよう、複数の独立した防御層を持つことが重要になります。

今回の「Defender’s Window」という警告の本質は、AIによって突然まったく新しい攻撃手法が生まれることだけではありません。

企業がすでに抱えている既知・未知の弱点を発見し、組み合わせ、利用するために必要だった時間と専門知識のコストが急速に下がる可能性にあります。

攻撃側の探索速度が機械速度へ近づくのであれば、防御側も「発見してチケットを起票する」だけでは対応できません。発見、優先順位付け、修正、検証、本番反映までの一連のサイクルをどこまで短縮できるかが、AI時代の脆弱性管理を左右することになります。

関連記事

OpenAIのAIモデルが自律的にHugging Faceへサイバー攻撃

OpenAIの内部評価中にAIモデルがサンドボックスを抜け、Hugging Faceの本番インフラへ到達した経緯を整理しています。「The Defender’s Window」の警告を理解するうえで背景となる事案です。

OpenAIのAIモデルがJFrog Artifactoryゼロデイを悪用

Hugging Faceインシデントで評価環境から外部へ到達する際に利用されたJFrog Artifactoryの脆弱性と、AIモデルが複数の弱点を連鎖させた経緯を整理しています。

MicrosoftやPalo Alto Networks、AnthropicがAIを用いて脆弱性を検出―サイバー空間でのAI対AIの攻防

AIが攻撃側だけでなく、防御側の脆弱性発見にも利用され始めている事例をまとめています。OpenAIが「Defender’s Window」で示す、防御側がAI能力を先に活用するという考え方と関連します。

Claude、試験中に3件のサイバー攻撃　評価環境の設定ミスで実在システムへアクセス

AIモデルの能力評価そのものが現実のセキュリティリスクになり始めている点を、Anthropicの事例から整理しています。OpenAI-Hugging Face事案との違いも比較できます。

出典

• The Defender’s Window – OpenAI
• OpenAI and Hugging Face partner to address security incident during model evaluation – OpenAI
• Pacing model development in an era of cyber-critical capabilities – OpenAI
• Responding to the next frontier of critical cyber capabilities – OpenAI
• Expanding Daybreak as the Cyber Defense Window Narrows – OpenAI
• OpenAI Warns AI-Powered Attackers Can Find and Exploit Longstanding Security Flaws – CyberPress（起点記事）