OpenAIは8月17日（米国時間）、AIによる攻撃が現実化するなかで守る側が何をすべきかをまとめた投稿「The Defender's Window」を公開しました[1]。自社インフラを守るための4本柱と、他社が今日から着手できる手順を並べた内容で、実例として自身の個人サイトをAIに診断させたところ15分で13件の不備が見つかったと明かしています。

Hugging Faceの一件が突きつけたもの

きっかけは、7月に公表されたOpenAIとHugging Faceを巻き込んだ侵入事案です[2]。エージェントの集団が自律的に動き、OpenAIの研究インフラだけでなく他社の本番インフラにまで到達しました。使われたのは、まだ知られていなかった脆弱性と、インターネット上に流出していた利用者アカウントの認証情報を数珠つなぎにする手口です[1]。

OpenAIはこの一件を、典型的な攻撃者の能力が今後どう進化するかを覗かせた分水嶺だと位置づけています。投稿を書いたGreg Brockman氏は、多くの組織と話すなかで「前例のない速さでセキュリティ体制を底上げしなければならない」という認識が共通していたと述べています[3]。

気になるのは時間の余裕です。OpenAIは今年に入ってから、サイバー分野の能力を信頼できる防御側にのみ提供する方針へ切り替えました[4]。しかし各社がオープンウェイトのモデルを相次いで公開しており、その能力は最先端から数か月遅れる程度まで縮まっています。投稿では、直近のモデルが8月末に公開される見通しで、脅威の状況を一段と加速させる可能性が高いと指摘されています[1]。

個人サイトを15分診断、13件の不備が出た

説得力があるのは、Brockman氏が自分のサイトgregbrockman.comをChatGPT Workに診断させた話です。使ったのは一般提供されているGPT-5.6 Solで、対象はAWS上に置きCloudflareを前段に立てただけの静的サイトでした。攻撃対象になりそうな面積はほとんどないはず、というのが本人の見立てです[1]。

ところが約15分で13件の問題が挙がりました。なりすましメールを防ぐDNSレコードが設定されていないこと、古い安全でないバージョンのjQueryを読み込んでいること、CloudflareからAWSへの転送が暗号化されていないHTTPのままだったことなどです。単体では悪用しにくいものが多いものの、他の脆弱性と組み合わされば効いてくる類のものだと本人も認めています。

さらに修正まで任せたところ、1時間ほどで作業が終わりました。ブラウザでCloudflareの管理画面を開いてDNSとTLSと詳細設定を整え、jQueryをサイトから外し、AWSからCloudflare Pagesへ移し、DMARCの段階的な適用まで始めたといいます。設定項目の名前は知っていても正しい値まで即答できない、という領域を丸ごと引き受けてくれる点が肝です。

自社を守るための4本柱

OpenAI自身の取り組みは4つに整理されています[1]。

1つ目は、コードを守るためにモデルを使うことです。Codexとセキュリティ用プラグインがコード変更を検証し、脆弱性を特定して、デプロイ前に開発者が直せるようにします。人手で確認すべき指摘を増やすことは目的ではなく、出荷前に本物の脆弱性を捕まえ、発見から安全な修正の適用までを短くすることを狙いに置いています。

2つ目は、インフラの防御を継続的にモデルへ任せることです。初期のセキュリティアラートは、ほぼすべてが人間に回る前にAIで振り分けられています。そのうえで、範囲を区切った自動対応を検知に結びつけつつ、影響の大きい判断は人間が担う形を保つとしています。

3つ目は、攻撃経路の洗い出しです。脆弱性や設定ミス、権限が過剰なID、意図せず生まれた信頼境界を継続的に探し、悪用される前にふさぎます。自社が正しいと信じているセキュリティ上の前提を、製品とインフラの全体で検証し続ける狙いです。

4つ目は基礎の徹底です。多層防御と最小権限、ネットワーク分離、ワークロードの堅牢化、監視、安全なパッチ適用といった古典的な統制がAI時代にこそ重要になると強調しており、致命的な事故を起こすには複数の独立した統制が同時に破られる必要がある設計を目指すとしています。

今日から動くための手順

投稿の後半は、他組織向けの実践的なチェックリストになっています。特定の製品よりも、能力のあるAIを防御側の手に今すぐ渡すことが重要だという立場です[1]。

  • セキュリティチームにエージェントを与え、全社展開を待たずに優先度の高いシステムから着手する
  • 静的解析やサプライチェーン診断などのスキルを装備させ、自社の設計や脅威モデルに合わせて育てる
  • インターネットに面したサービス、認証フロー、デプロイ経路から順に診断をかける
  • 既存の脆弱性バックログを渡し、悪用可能なものとノイズを仕分けさせる
  • 検知のトリアージは読み取り専用の範囲から始め、信頼できる範囲を段階的に広げる
  • Trusted Access for Cyberに申請してGPT-Daybreak-Blueを使える体制を、必要になる前に整えておく

最後の項目にあるDaybreakは、OpenAIが防御側向けに広げているサイバーセキュリティの取り組みで、8月にはGPT-5.6-Cyberの投入とあわせて拡張が発表されています[4]。インシデント対応や検知エンジニアリング、マルウェア解析といった用途を想定しており、事が起きてから申請するのでは間に合わないという指摘は現実的です。

なお投稿は、AI研究所やセキュリティベンダー、企業、オープンソースの保守者が検証済みの発見や修正、実践的な手順書を共有し合うことも求めています。1社の発見が業界全体を強くする形に持ち込めるかが、この数か月の分かれ目になりそうです。

まとめ

OpenAIが公開した「The Defender's Window」は、AIが攻撃を自動化し始めた状況で守る側が取るべき動きを、自社の実践と他組織向けの手順の両面から示したものです。静的な個人サイトですら15分で13件の不備が出たという例は、多くの組織が抱える技術的負債の厚みを想像させます。攻撃側の能力が数か月で追いついてくる以上、防御側がAIを使いこなす猶予はそう長くないというのが投稿の主旨で、まずは読み取り専用の診断から小さく始められる点は押さえておきたいところです。

出典[1]:https://openai.com/index/the-defenders-window

出典[2]:https://www.axios.com/2026/07/28/hugging-face-openai-cybersecurity-defense

出典[3]:https://tech.yahoo.com/cybersecurity/articles/openai-greg-brockman-says-hugging-133920704.html

出典[4]:https://openai.com/index/expanding-daybreak-as-the-cyber-defense-window-narrows/