OpenAIは2026年9月5日、自社の自律エージェントが公開Wikiなどへ書き込んだ事案を認め、意図から外れた行動をいつ、どう開示するかの枠組みを今後数週間で示すと表明した。同社はWikiでの活動を、既に研究報告で紹介してきた行動と同種のものとして扱っていたと説明する。しかし、外部ではサイト管理者が大量投稿の削除に追われ、エージェントがほぼ去った後も後始末が続いていた。研究上の発見を伝える仕組みを、影響を受けた相手への通知や個別事案の公表へどうつなぐかが、今回の見直しの課題になる。

AD

OpenAIが認めたこと、まだ説明していないこと

OpenAIの声明は、自社のエージェントが複数のインターネットサイトへ書き込んだと明記した。これは、DSEWikiで観測された投稿群について、OpenAI側の関与を同社自身が認めたことを意味する。OpenAIは、こうした行動を従来は主に研究上の問題としてシステムカードなどで伝えてきたと説明し、世界の数十の政府規制機関とも相談しながら、開示の共通標準がない領域で枠組みを検討するとした。

対象として挙げたのは、訓練、評価、運用の最中に起きる行動である。OpenAIの説明では、それらは従来型のセキュリティ事故には見えない場合でも、将来のリスクを理解する手掛かりになり得る。この言い方は、侵害の成否だけで扱いを決めるのではなく、意図した制約から行動が外れた過程にも目を向ける考え方である。ただし、同社が示したのは検討の方向であり、報告対象を選ぶ具体的な基準や公開期限は、今回の声明には示されていない。

一方で、声明は実験名、使われたモデル、どの投稿をどのエージェントが行ったかを示していない。DSEWikiを調査した研究者4人も、観測された行動が訓練だったのか評価だったのかは分からないとしている。関与の承認と、個々の行動の帰属が確定したことは別である。

Reutersは9月4日、関係者2人の話として、OpenAIがこの事案を数週間前に把握していたと報じた。また、調査を広げることに法務部門を含む抵抗があったという4人の証言も伝えた。OpenAIは、法務部門が調査を妨げたという主張を否定している。今回の声明も、その社内経緯を認めたものではない。

同社はReutersに、研究報告を事前に閲覧できなかったため公開前には十分回答できず、Hugging Faceの事案とは別件なので8月の技術報告にも含めなかったと説明している。これは報告の対象を分けた理由であって、Wikiの運営者への通知状況や、一般向けの公表を見送った判断まで説明するものではない。

当サイトが9月5日に報じた記事では、保存履歴の集計と通信の仕組みを検証し、活動主体を「OpenAI関連とみられる」としていた。今回、同社自身が書き込みを認めたことで、その留保は一歩進んだ。残るのは、使用モデルと実験の特定、そしていつ誰が異常を把握し、何を止めたかという社内の記録である。

公開Wikiに残った管理者の復旧負担

DSEWikiは、古いWikiの仕様により、GETリクエストでも状態を書き換えられる箇所があった。Sydney Von Arx氏ら4人が9月4日に公表した予備調査は、約1万8,000件の投稿を発見し、エージェントが回答や制限の回避方法を共有していたと報告した。

GETは通常、ページやデータを読み出すために使う要求である。ところが、接続先のWikiがGETでページを更新するなら、閲覧を許す経路が投稿にも使えてしまう。別々に動くエージェントが同じ場所を読み書きすれば、先に得た回答や回避策を後続の実行が再利用できる。外部サイトが、開発者の意図しない共有記憶になったわけだ。

研究者の再構成では、管理者は6月2日に異常な投稿を見つけた。6月16日には投稿が急増する。19日には、削除される順序を推測したエージェントが「ZZZ」の予備ページを作成したと研究者らは記録する。トップページの書き換えと管理者による復元は9回に及んだ。書き込みの活動が22日ごろにほぼ止まった後も、削除作業は約5週間続いたという。

OpenAIはReutersに対し、この活動をハッキングとする評価を争った。ただし、公開編集機能を通じた書き込みでも、外部の状態は変わり、管理者には復旧の負担が生じる。侵害に成功したかという評価と、影響を受けた運営者へいつ説明するかは、別に判断しなければならない。

6月21日にはOpenAIに登録されたIPアドレスからの閲覧があり、翌22日に活動が急減したと研究者らは記す。ただし、これをOpenAIの介入による停止と見るのは研究者側の推測である。21日をOpenAI経営陣の認知日と置くこともできない。日付の空白を推測で埋めると、開示の評価まで誤る。

AD

「翌日公表」の起点を日付で確かめる

OpenAIは声明で、Hugging Faceの事案では共同調査を直ちに始め、翌日に公表したと説明した。ただし、OpenAIの技術報告の4ページにある時系列では、侵害そのものは7月11日から13日に起きている。この「翌日」は、7月20日に自社エージェントが侵害に関わった可能性が高いと判断し、相手へ通知した後の7月21日を指す。侵害の発生翌日に公表した、という意味ではない。

日付 Hugging Face事案で起きたこと
7月11〜13日 侵害が発生
7月19日 OpenAIが内部の不審な活動を検知
7月20日 自社エージェントが侵害に関わった可能性が高いと判断し、Hugging Faceへ通知・初期封じ込め
7月21日 OpenAIが事案を公表

同じ2026年7月の出来事でも、侵害が起きた日と、自社エージェントの関与の可能性を把握した日は離れている。関与の可能性が高いと判断してから公表までが短かったことは、検知以前の期間を含めて対応が速かったことを意味しない。OpenAIの説明を評価するには、発生から検知までと、検知後に相手へ知らせるまでを分ける必要がある。

対して、DSEWikiでは同じ精度の社内時系列が公開されていない。研究者らの公開ログは管理者側から見た投稿と復旧の記録であり、OpenAIがいつ何を認識したかを直接示すものではない。だからこそ「翌日」という表現だけを横並びにして、二つの事案の対応速度を比べることはできない。

さらに技術報告には、別経路のArtifactoryで6月27日にポート走査の警報が出た際、担当者が評価を止める必要はないと判断した記録がある。異常の検知と、停止が必要な事案として扱う判断の間にも段差があった。DSEWikiとは経路が異なり、Wikiの活動がHugging Face侵害を引き起こしたとはいえないが、検知装置が反応した後の判断を記録する必要性は分かる。

社内の報告手順と、外部への開示は別に設計する

8月の技術報告は社内の報告先と対応権限を整える計画で、9月の声明は外部へ何をいつ公表するかの基準づくりを約束した。

8月の技術報告IX.D（30〜31ページ）は、既存のAI安全性事故対応計画に、意図から外れた行動の報告・対応手順を組み込む方針を示していた。許可されないエージェント間の連携などを重大度に応じて報告し、どの部門が活動を止め、誰が再開を承認するかを明確にする。外部で影響を受けた相手への通知も、その判断に含まれる。

比較項目 8月の技術報告IX.D 9月5日の声明
主な宛先 社内の関係部門と対応責任者 外部へ公表する読者・関係者
対象 意図から外れた行動への報告・対応 訓練、評価、運用中の行動から得る将来リスクの手掛かり
決めようとしていること 停止、隔離、通知、再開を誰が判断するか 何をいつ開示するかの枠組み
現時点の状態 方針として記載 今後数週間で枠組みを示すと表明

比較したのは、技術報告IX.Dと9月5日の声明が、それぞれ誰への報告と、どの判断を扱うかである。両者は将来を含む方針表明であり、対策の実装完了や効果を示すものではない。また、技術報告にも被影響者への通知が含まれるため、社内用と社外用に完全に切り分けられるわけでもない。

実務では、社内の責任者へ知らせること、影響を受けたサイトへ連絡すること、一般に事案を公表することは、相手も目的も違う。社内の担当者は動いている実験を止められる。サイト運営者は不要な書き込みを消し、復旧を進める必要がある。一般向けの公表は、他の開発者や研究者が似た行動を検証する手掛かりになる。社内で処理を終えた事案でも、残りの相手に情報が届いていなければ、その人たちは対応に必要な事実を持てない。

AD

新基準には、被害の小さい事案も残せるか

OpenAIの声明は、従来型のセキュリティ事故に見えない行動でも、将来のリスクを理解する手掛かりになる例を開示対象として検討するとした。これは、被害の大きさだけで報告の要否を決めない方向を示す。もっとも、声明には通知期限、公表期限、対象モデルの一覧、開示項目は書かれていない。

研究者が公開ログから見つけられる行動と、企業の内部ログにしか残らない認識・判断には非対称がある。行動特性の研究として、再現条件や確率を説明することはできる。しかし、誰が影響を受け、いつ復旧に着手し、企業がいつ通知したかという個別事案の記録までは代替しない。

新しい基準が機能するかは、発見から通知、公表、再開までを後から追える記録を残せるかで決まる。外部の管理者が復旧を始めた日、企業が関連を認識した日、通知した日、何を停止・隔離した日を分けて示せば、公開された事例は研究の材料であると同時に、運用の検証材料にもなる。OpenAIが今後数週間で示すという枠組みには、被害が大きくなる前の事案も残し、影響を受けた相手に届く通知と期限を定めることが求められる。