何が起きたか
OpenAIが公開した投稿は、自社モデルに関する第三者のサイバー能力評価を扱ったもので、英国AI Safety Institute（UK AI Safety Institute）に関わる一件と、Irregularに起因するもう一件の「攻撃」の дваつを取り上げています。
IrregularはOpenAIの外部サイバーセキュリティ評価パートナーの一社で、インターネットから隔離される前提でCapture-the-Flag（CTF、脆弱性攻略型の演習）形式の評価を実施していました。ところがテスト環境の設定ミスにより、モデルが公衆インターネットへアクセスできる状態になっていました。
さらに悪いことに、あるテストでは、CTF課題の「架空の攻撃対象」に付けた名前が、実在するドメイン名と意図せず一致していました。環境が誤ってインターネットにつながっていたため、モデルはその実在サイトをシミュレーション環境の一部だと誤認し、実際に攻撃（exploit）してしまいました。
同じIrregularは、Anthropicの報告にも登場します。そこでも設定ミスのある評価環境をホストしており、一部のテストでClaudeにライブのインターネット接続を与えていたとされています。この記事の書き手であるSimon Willisonは、この種の出来事を追跡するために「accidental-cyberattacks（偶発的サイバー攻撃）」というタグを新設しました。
なぜ重要か
注目すべきは「モデルが暴走した」話ではない、という点です。モデルは与えられた課題に対して指示どおりに振る舞っただけで、破綻したのは人間側が用意した境界——ネットワーク隔離の設定と、演習用ターゲットの命名規則——でした。AIの安全性を測るための仕組みそのものが、意図しない実害の発生源になったわけです。
もう一つの論点は、同じ委託先の同じ環境で、OpenAIとAnthropicという競合する2社が別々に影響を受けていることです。AI評価の担い手は少数の専門ベンダーに集中しており、その1社の設定ミスが複数のフロンティアモデル提供者に横断的に波及する構造になっています。評価のアウトソーシングは、そのまま「共通の単一障害点」を抱えることを意味します。
命名の一致という盲点
架空のターゲット名が実在ドメインと一致した、という事実は軽く見られがちですが、事故の連鎖の中では決定的です。ネットワーク隔離が効いていれば命名の重複は無害で、命名が安全側に倒れていればネットワークの穴も無害でした。二つの独立した前提が同時に崩れたときにだけ実害が出る——典型的な多層防御の破綻パターンであり、どちらか一方の対策だけでは再発を防げないことを示しています。
💼 事業会社視点：これは自社にどう効くか
AIエージェントを業務に入れ始めた日本企業にとって、これは「フロンティアラボの話」では済みません。論点は三つです。
第一に、サンドボックスは自己申告で信じない。社内でAIエージェントのPoCを回しているEC・SaaS事業者は、検証環境から外部への通信が本当に遮断されているか、egress（外向き通信）ログで実測すべきです。OpenAIとAnthropicという最も検証体制が厚い組織ですら、委託先の設定ミスを事前に検知できませんでした。
第二に、テストデータの命名規則を統制する。ダミーの会社名・ドメイン・IPを担当者の思いつきで作ると、実在資産と衝突します。予約済みドメイン（example.com、.invalid、.test）とプライベートIP帯に限定するルールを、AIエージェントの評価・負荷試験・デモ環境すべてに適用してください。
第三に、受託開発・SIerは契約条項を見直す時期です。顧客のAIエージェント検証を請け負う場合、環境設定ミスによる第三者への攻撃は、誰の責任で、どこまで賠償するのか。今回のIrregularのように、単一のベンダーが複数顧客の環境をホストしていれば、事故は横に広がります。役員は「AI活用の推進」と同じ会議で、AI実験環境のネットワーク境界と責任分界点を議題に載せるべきです。