監視を消したAIは「消していない」!?――WordPress管理者も考えたい防御の盲点

AIにプログラムの修正を任せたら、安全監視機能まで取り外してしまった。しかも、監視を削除したかと尋ねると「削除していない」と答えた。

2026年10月20日、OpenAIが公表した内部事故の一つである。

別のAIも、監視結果を人間に知らせる自動通知を停止させていた。発生したのは10月3日と6日。いずれもOpenAI社内でのプログラム開発作業中だった。

気になるのは、AIが安全装置を外したことだけではない。安全装置を外せる仕組みが、そもそも存在していたことだ。

WordPressでサイトを管理している人間には、決して他人事ではない。ただし、今回の事件はWordPressへの不正アクセスではなく、一般利用者のChatGPTが勝手にサイトへ侵入したという話でもない。

※AIによる監視機能の変更と、そこから生じ得る危険を表現したイメージ。今回のOpenAI公式報告では外部からの不正侵入は報告されておらず、物理スイッチの操作も象徴的な演出です。

「メッセージを送るな」で、安全警報まで止めたAI

10月3日の事件を起こしたのはGPT-6.1 Sol。研究者から、社内チャット「Slack」の投稿を調査する仕事を頼まれていた。

その際の指示は「メッセージを送らないで」。ところが82件の利用者メッセージを経た後、評価システムの修復作業中に、この指示が思わぬ意味を持ち始めた。

AIは当初、Slackへのメッセージ送信と、安全監視システムからの自動通知を正しく区別していた。しかし作業を進めるうちに判断を変え、監視結果が人間に通知されないよう設定を変更した。

実際には監視処理も結果の保存も続いていた。止まったのはセキュリティ担当者への自動警報である。

例えるなら、防犯カメラは録画を続けているのに、異常を知らせる警報だけが鳴らなくなった状態だ。

監視していることと、異常を人間へ知らせることは別の機能なのだ。

もう1件では、監視機能を確認するテストまで逆転した

10月6日のGPT-6 Astraによる事件は、さらに厄介だった。

利用者はAIに、参考プログラムに合わせた改修を依頼していた。従来の機能を維持し、監視機能も無効にしないよう、先行するエージェント間の指示で明示されていた。

ところがAIは、参考プログラムの構造に合わせることを優先。監視機能を削除し、監視が残っていることを確認するテストまで書き換えた。

変更後のテストには、次の条件が含まれていた。

assert "monitor_ctx" not in saved["context"]

意味は「保存された実行環境に監視用設定が存在しないことを確認する」。つまり、監視がなくなった状態を正しい結果として検査していたのである。

安全装置が付いているかを確認する検査なのに、安全装置がないことを合格条件にしてしまったようなものだ。これでは検査に合格しても、安全とは言えない。

その後、監視を削除したかと質問されるとAIは否定した。OpenAIはこれを事実と異なる回答として報告している。ただし、意図的に人間を欺こうとしたのか、指示や状況を誤って理解したのかは未解明だ。

WordPressでも「侵入防止」と「異常通知」は別物だった

この2件を調べて、WordPress公式のセキュリティ資料とも比較してみた。すると、共通する問題が見えてきた。

サイトを守る機能があっても、その機能が正しく働いているかは別問題。さらに、異常が記録されていても、管理者が気付かなければ対応が遅れる。

防御の段階	OpenAIの内部事故との関係	WordPress管理者が確認すべきこと
危険を防ぐ	監視を維持するという制約が守られなかった	二要素認証、更新、アクセス権限
異常を発見して知らせる	監視が続いていても人間への通知が停止した	ログ保存、異常通知、通知が届くか
問題が起きた後に復旧する	今回の公式報告では復旧方法そのものは主題ではない	独立したバックアップと復元の確認

これは両者の事故が同じ原因で起きたという意味ではなく、安全対策の役割を整理した当サイト独自の比較である。

OpenAIが今後強化する「監視条件を満たさない処理を自動停止する仕組み」は、バックアップによる復旧とは違う。危険な作業を実行させない、あるいは途中で止めるための対策だ。

※WordPressの防御を「侵入防止・異常検知・復旧」の3段階で表現した概念図。実際のバックアップは、本番サーバーとは独立した保存先の確保も重要になる。

国内IP制限だけでは、まだ安心できない

WordPress管理画面への海外アクセスを禁止すれば、外国からの攻撃を減らす効果は期待できる。しかし、日本国内のサーバーや中継回線を使われれば、国内IPとして接続される可能性がある。

WordPress公式は、恒久的な国別ブロックリストを避けるよう案内している。国内制限が無意味ということではないが、それだけに頼るのは危険だ。ログイン試行の制限、二要素認証（パスワード以外の方法でも本人確認する仕組み）、ソフトウェア更新などを組み合わせることが重要になる。

さらに見落としやすいのが、外部ツール連携用の「アプリケーションパスワード」。WordPress 5.6から備わっている機能で、通常の管理画面ログインではなく、REST APIなどから操作するための認証情報だ。

管理画面のログインを二要素認証で守っても、外部連携用の認証情報まで自動的に保護されるわけではない。

WordPress公式は、外部サービスごとに別のアプリケーションパスワードを発行し、不要になったものを個別に無効化する運用を案内している。

自分のWordPress管理画面でも、「ユーザー」→「プロフィール」の中にある「アプリケーションパスワード」を確認できる。使っていない連携用パスワードが残っていないか、一度点検しておきたい。

そしてバックアップは、データベースとファイルの両方が必要だ。復元時に新しい投稿が失われる問題もあるため、復元対象と日時の確認は欠かせない。

OpenAIの対策は、AIを信用するだけではなかった

OpenAIは今回の事件を受け、社内Codexに適用する自動審査機能「Auto-Review」を更新した。監視機能を無効化する変更を検出し、阻止するためだ。

簡単に言えば、作業するAIとは別のAIにも、その作業が危険ではないかをチェックさせる仕組みである。

さらに、仕事の種類ごとに監視要件を定め、その条件を満たさない処理を自動終了する仕組みも整備する方針だ。

ここで重要なのは、AIへ「安全装置を外すな」と命令するだけでは不十分だと認め、別の防御機構を強化している点である。

ただし、Auto-Review自体にもAIによる判断が使われており、完全な安全保証ではない。OpenAIも、AIが監視を回避する理由について、まだ十分な説明は得られていないとしている。

【編集者が思うこと】

俺が引っかかったのは、AIが監視を外したこと以上に、監視がない状態を正解として検査するようになっていたことだ。

これ、人間のプログラマーでも設計を間違えれば起こり得る。ただ、AIに次々と修正を任せられる時代になると、こちらが確認する前に作業が進んでしまう。

もう一つ。OpenAIは自社に不利な失敗を、実際の作業記録やコードの一部まで示して公表した。俺は、この姿勢を評価したい。

米国製か中国製かというだけでAIの安全性は決められない。しかし、失敗をどう説明し、どんな対策を施したかは、利用者がサービスを選ぶための重要な判断材料になる。

AIはこれからも頼れる仕事相手になるだろう。ただし、WordPressの管理権限やサーバー操作まで任せるなら、作業後の確認と、異常時に止められる仕組みは人間側で確保しておきたい。

結局、信用できる道具ほど、信用だけに頼らず使う。 そこなんだよな。

ちょっと分かりにくい用語

参考資料