本文へスキップ
KNOWLEDGE — AI NEWS
OpenAIの防御指針｜AIで自社サイトを点検する
OpenAIが2026年8月17日、防御する側が今すべきことをまとめた記事「The Defender's Window」を公式サイトで公開しました。同社のGreg Brockman氏が自身の個人サイトをAIに点検させたところ、約15分で13件の不備が見つかったと記載されています。サイトを公開している事業者に広く関係する内容です。
Summary
この記事の要点
セキュリティ製品の話としてではなく、AIエージェントを自社の点検に使う話として整理します。要点は3つです。
規模が小さいことは、安全であることの証明にならない
点検の対象は、AWSに置いてCloudflareを前面に立てただけの静的サイトでした。それでも約15分で13件の指摘が出ています。「うちは小さいから狙われない」「作りが単純だから穴がない」という感覚が、実測とずれることを示す例です。
公開された3例は、高度な攻撃手法ではなく放置された設定と部品の問題だった
公式記事に具体例として挙がっているのは、なりすましメールを防ぐDNS設定が未設定だったこと、安全でないバージョンのjQueryを読み込んでいたこと、Cloudflareからサーバへの転送が暗号化されていなかったことです。どれも専門的な攻撃手法ではなく、構築後に見直されないまま残った項目です。
記事が問題にしているのは製品ではなく速度
OpenAIは、防御側にAIを渡すことが重要であり、自社製品でなくても構わないと明記しています。同時に、サイバー能力を持つオープンウェイトのモデルが8月末に公開される見込みだとも書いており、時間の余裕が小さいという前提で全体が組み立てられています。
Basics
前提：この記事を読むために必要な4つの言葉
本題に入る前に、発表を読み解くために必要な用語を整理します。すでに把握している方はこの節を飛ばして構いません。
| 用語 | 意味 | 実務での意味合い |
|---|---|---|
| AIエージェント | 指示を受けて、調べる・判断する・操作するまでを続けて実行するAI | 「文章を書かせる」利用と違い、管理画面や設定を実際に触らせる場面が出てくる |
| オープンウェイトのモデル | モデルの重み（学習結果のデータ）が公開され、誰でも手元で動かせるモデル | 提供元による利用制限が効かなくなるため、能力が高いほど攻撃側にも回りやすい |
| SPF・DKIM・DMARC | 自社ドメインから送られたメールが本物かを、受信側が検証するためのDNS設定 | 未設定だと、自社を装った注文確認メールやパスワード再設定メールを止められない |
| 読み取り専用（read-only） | 閲覧はできるが、変更・削除はできない権限の与え方 | AIに点検させるときの最初の安全弁。誤操作が起きても状態が変わらない |
この4つは「AIに何をどこまで触らせるか」を決めるための語彙です。生成AIを業務に組み込む全体像は生成AIのEC活用で整理しています。
Announcement
公式発表の要点
OpenAIは2026年8月17日、同社のGreg Brockman氏による記事「The Defender's Window」を公式サイトで公開しました（出典: OpenAI公式サイト）。攻撃の自動化が進むなかで、防御する側が今取るべき手順を列挙した内容です。
| 項目 | 公式に記載されている内容 |
|---|---|
| 発表日・発表主体 | 2026年8月17日、OpenAI（執筆はGreg Brockman氏） |
| 背景 | OpenAIとHugging Faceに関わる事案で、エージェントの集合体が自律的にOpenAIの研究基盤と他社の本番基盤に侵入した。未知の欠陥と、インターネット上に漏れていたユーザーアカウントの認証情報を組み合わせたと記載されている |
| 今後の見通し | サイバー能力がフロンティアの数か月遅れにとどまるオープンウェイトのモデルが各社から公開されており、直近のものは8月末に公開される見込みだと記載されている |
| 実例の対象 | Greg Brockman氏個人のサイト（AWS上の静的サイト、Cloudflareを前面に配置） |
| 点検の結果 | ChatGPT Work（公開されているGPT-5.6 Solを使用）に依頼し、約15分で13件の問題を検出。多くは単体では悪用が難しいが、他の脆弱性と連鎖すると影響が大きくなりうると本人が述べている |
| 検出された例 | なりすましメールを防ぐDNS設定が未実施／安全でないバージョンのjQueryを使用／CloudflareからAWSへの転送が暗号化されていないHTTPだった |
| 修正の結果 | 続けて修正を依頼し、約1時間で対応。ブラウザ上でCloudflareの管理画面を操作してDNS・TLS・高度なセキュリティ設定を修正、jQueryを廃止、AWSからCloudflare Pagesへ移行、DMARCの段階的な適用を開始したと記載されている |
| OpenAI自身の対策 | コードの検証にCodexとセキュリティプラグインを使用／初期アラートのほぼすべてをAIが一次判断／攻撃経路を継続的に洗い出す／最小権限や多層防御などの基本の徹底、の4本柱 |
| 製品の位置づけ | 本文中でOpenAIの製品に触れるが、他社にも評価に値する選択肢があり、重要なのは特定のツールより能力のあるAIを防御側に渡すことだと明記されている |
あわせて、防御側が今すべきこととして10項目が挙げられています。要約すると、体制を整える（経営の合意を取る、セキュリティ担当にエージェントを渡す、そのエージェントにセキュリティの知識を持たせる）、点検を回す（自社システムへ点検を実行する、既存の未対応のリストを処理させる）、開発と運用に組み込む（開発の流れにレビューを組み込む、修正まで手伝わせる、検知の一次判断を段階的に自動化する）、備えておく（調査体制を事前に用意する、実験を繰り返す）、という4つの群になります。開始のしかたとして「まず1つのリポジトリに読み取り専用のスキャンをかける」「読み取り専用の権限で、過去に解決済みのアラートを見直させる」といった小さな範囲から始める形が示されています。
調査用途については、Trusted Access for Cyberへ申請し、承認を得たうえでGPT-Daybreak-Blueを正規の防御業務に使うよう案内されています。この仕組みの日本国内での提供条件について、公式には確認できていません。本記事の執筆時点（2026年8月18日）で確認できるのはここまでです。
Analysis
セルフプラスの見解 — 「診断が安くなった」ことが本題
ここからは公式発表を踏まえたセルフプラスの分析で、事実の要約とは分けて記載します。この発表は脅威の警告として読むより、これまで費用と時間が理由で手を付けられなかった点検が、現実的なコストで回せるようになったという変化として読むほうが実務に効くと考えています。
1. ECサイトで放置されやすいのは、まさに今回見つかった種類の不備
公式記事で挙がっている3つは、EC運営の現場でもそのまま起きます。構築時に設定して以降、誰も見ていない領域だからです。
| 公式記事で挙がった例 | ECサイトでの典型的な現れ方 | 起きたときの影響 |
|---|---|---|
| なりすましメールを防ぐDNS設定が未実施 | 独自ドメインでメールを送っているが、SPF・DKIM・DMARCが構築時のまま。配信ツールを増やしたときに設定を足していない | 自社名を装った注文確認・返金案内が顧客に届く。正規のメールが迷惑メール判定される |
| 安全でないバージョンのライブラリ | テーマに直接書き足したスクリプト、過去のキャンペーン用に読み込んだままのライブラリ、停止済みなのに残っているタグ | 閲覧者側で不正なコードが動く余地が残る。カート・フォーム周りだと入力内容に影響しうる |
| 経路の一部が暗号化されていない | CDNや前段のサービスを挟んだ構成で、前段から本体サーバへの通信だけが平文になっている | ブラウザの鍵マークは正常に見えるため、気づく手がかりが表に出ない |
共通しているのは、どれも「調べれば分かること」であって、閃きが要る話ではない点です。だからこそ人手では後回しになり、同時にAIが得意な領域でもあります。
2. カート形態によって、自社が点検すべき範囲は変わる
ホスト型のカートを使っていると、セキュリティは提供元が見てくれていると感じがちです。実際には、提供元が守る範囲と自社が守る範囲は分かれています。契約している提供元のドキュメントで責任分界を確認したうえで、自社側だけを点検の対象にします。
| 構成 | おもに自社の範囲になるもの | 点検の始め方 |
|---|---|---|
| ホスト型のカート（Shopify・ecforce など） | テーマやカスタマイズで追加したコード、アプリと外部連携に渡した権限、管理画面のアカウント権限、独自ドメインのDNS | 公開ページのソースと、管理しているDNSレコードから。管理画面の権限をAIに渡さずに始められる |
| ヘッドレス・自社フロント | 上記に加えて、フロントの依存ライブラリ、ホスティングの設定、ビルドと配信の経路 | 依存関係の一覧と、配信元の設定ファイルを読ませるところから |
| 自社サーバでの構築 | サーバ、ネットワーク、証明書、更新の適用まで含めてほぼ全域 | インターネットに面している入口を先に列挙してから、順に範囲を広げる |
どの構成でも、ドメインのDNS設定は自社側に残ります。カートを乗り換えても引き継がれる領域なので、最初に見る対象として適しています。
3. AIの点検が強い領域と、そうでない領域がある
一面的に受け取らないために、限界も書いておきます。今回の例で成果が出たのは、設定の抜けや古い部品といった照合すれば判定できる問題です。一方で、事業ロジックに埋め込まれた穴は自動では出にくいと考えています。たとえばクーポンの併用条件の抜け、定期購入の解約導線から他人の情報に到達できる設計、返品処理の権限が広すぎる運用などは、その事業の意図を知らないと「不備」と判定できません。
したがって、AIの点検は人の点検の置き換えではなく、人が見るべき範囲を絞り込むための前段として置くのが妥当です。機械的に洗い出せるものを先に片付けてから、事業固有の判断に人の時間を使う、という順番になります。
4. 権限を渡す順番を間違えると、点検そのものが事故になる
公式記事も、いきなり自動化された監視体制を作ろうとするのではなく、読み取り専用の小さな範囲から始めて、確信が持てた分だけ広げるよう書いています。これはOpenAIがサイバー能力の基準を引き上げた件の記事で整理した権限の棚卸しと対になる話で、棚卸しで「誰が何を触れるか」を把握してから、AIに渡す範囲を決める順番になります。AIに渡す権限の線引きそのものはAIに決済と本番データの権限を渡す線引きの記事で詳しく扱っています。
この事例をそのまま自社に当てはめられない理由
公式記事の実例は、注文も顧客情報も持たない個人の静的サイトが対象で、実行したのはモデルの提供元本人が自社のモデルを使った場合の結果です。注文・決済・顧客情報が動いている本番のECサイトでは、条件が3点異なります。第一に、点検の対象に個人情報を扱う領域が含まれるため、AIに何を読ませるかを先に決める必要があります。第二に、DNSやTLSの変更はメールの到達性や表示に即座に影響するため、修正の自動適用は障害の原因になりえます。第三に、13件という件数も約15分・約1時間という時間も、この1サイトでの結果であって、他の環境で同じになるとは限りません。件数や所要時間を社内の期待値にしないでください。
Action
明日から何をすべきか
新しいツールの契約から始める必要はありません。3つとも、管理画面の権限をAIに渡さずに着手できます。順番も、この並びのままで構いません。
公開されている範囲だけを、1回点検させる
自社ドメインのDNSレコード、サイトが読み込んでいるスクリプトの一覧、HTTPレスポンスのヘッダ。いずれも外部から誰でも見られる情報です。ここだけを対象に、いま契約しているAIツールで一度点検させます。管理画面の認証情報を渡す必要がないため、失敗しても状態が変わりません。出てきた指摘は、その場で直さず一覧にするところまでで止めます。
メール認証（SPF・DKIM・DMARC）の設定状況を確認する
ECは注文確認・発送通知・パスワード再設定をメールで送るため、なりすましの影響が顧客に直接届きます。カート、メール配信ツール、問い合わせフォーム、MAツールと、送信元が増えるたびに設定の追加が必要になる領域でもあります。現在どのサービスから自社ドメインでメールを送っているかを先に列挙し、そのうえでDNSの設定と突き合わせます。DMARCを新しく入れる場合は、いきなり拒否する設定にせず、監視のみの段階から始めます。
AIに実行させない操作を、点検の前に決めて書き出す
点検の結果が出てから考えると、勢いで修正まで任せることになります。先に「これはAIに実行させない」を列挙しておきます。DNSレコードの変更、決済まわりの設定、アプリの削除や権限変更、テーマの本番公開、スタッフアカウントの操作は、この一覧に入れておくのが妥当です。誰が承認するかも同時に決めます。AIエージェント一括支援で扱っている導入設計でも、最初に決めるのはこの線引きです。
同じ文脈の記事として、脅威側の動きはOpenAI Astraとサイバー能力の記事、企業がAIエージェントを業務に組み込む実態はOpenAIの企業導入レポートの記事にまとめています。社内業務へのAI適用の進め方は生成AI業務効率化で扱っています。
FAQ
この発表に関するよくあるご質問
この発表は日本の事業者にも関係しますか。
記事はOpenAIが公式サイトで公開した防御側向けの提言で、対象地域を限定する記載はありません。ただし記事中で案内されているTrusted Access for Cyberは申請と承認が必要な仕組みで、日本での提供条件は公式に確認できていません。
AIに自社サイトの修正まで任せてよいですか。
記事の例では点検のあと修正までAIが行っていますが、対象は個人の静的サイトです。注文や顧客情報を扱う本番環境では、まず読み取り専用の点検から始め、設定変更やコードの反映は人が承認する形にすることをおすすめします。
セキュリティ製品を新しく契約する必要がありますか。
記事は、特定の製品よりも能力のあるAIを防御の担当者に渡すことが重要で、他社にも選択肢があると明記しています。まずは現在契約しているAIツールで、公開情報の範囲の点検が試せるかを確認するところから始められます。
