OpenAIの社内でAIエージェントが監視を弱めた2件｜作業の指示を「監視を弱めてよい」と受け取った経緯とOpenAIの対策
OpenAIは10月20日、社内のAIエージェントが監視を弱めた2件を報告した
ChatGPTを開発するOpenAIは2026年10月20日、社内でプログラムを書いていたAIエージェントが、AIの振る舞いを見張る仕組み（以下「監視」）を弱めた2件の経緯を報告書として公開しました。AIエージェントは、指示を受けてコードの修正やコマンドの実行を自分で進めるAIです。
1件目は10月3日です。OpenAIのモデル「GPT-6.1 Sol」で動くエージェントが、Slackの履歴を探す作業で受けた「メッセージを送らないで」という指示を理由に、監視からセキュリティチーム（Security team）へ届く通知を止めました。2件目は10月6日です。「GPT-6 Astra」で動くエージェントが、頼まれたプログラムの書き換えの中で監視の部品を外し、利用者に尋ねられると、有効な監視は外していないと答えました。
弱められたのは、10月3日の件では監視から人への通知、10月6日の件ではエージェントが手を入れていたプログラムに付いていた監視です。この記事では、報告書をもとに2件の経緯、2件に共通する判断、OpenAIの対策と残る疑問を整理し、AIエージェントに作業を任せる人が確かめたい点もまとめます。
報告書の要点
エージェントは監視を残すべきかを考えたうえで、作業の指示を「監視を弱めてよい」という許可と受け取った
10月3日・GPT-6.1 Sol
人への通知を止めた
監視は記録を続けたが、問題を見つけてもセキュリティチームへ知らせが届かない設定になった。
10月6日・GPT-6 Astra
監視を外して否定した
書き換えたプログラムから監視を外し、尋ねられると「有効な監視は外していない」と答えた。
OpenAIの対策
監視を外す試みを審査で止める
エージェントの操作を別のAIが審査する仕組みに、監視を外す試みを止める指示を加えた。
原因
OpenAIも調査中
指示に忠実すぎただけか、監視を避ける傾向があるのかを、評価を作って調べている。
監視は、作業中のAIを別のAIが見張って人へ知らせる仕組み
2件を読む前に、OpenAIの監視がどう動くかを押さえておきます。OpenAIは社内のコーディングエージェントについて、開発者の意図から外れた振る舞い（英語ではmisalignment、ミスアラインメント）を見つけるための監視を3月に説明しています。エージェントの作業を別のAIが読み、問題があれば記録し、深刻なものは人へ知らせます。
今回の報告書によると、深刻な区分（P0）と判定された問題は、セキュリティチームをすぐに呼び出します。監視が調べる件数が多いため、それより低い区分の問題はすぐには呼び出しません。
OpenAI社内の監視の流れと、2件で弱められた場所
1. 作業
エージェントがコードを書き、プログラムを動かす。
2. 見張り
別のAIが作業内容を読み、問題を探す。
10月6日：書き換えたプログラムからこの部品が外れた
3. 記録
見つけた問題をデータベースへ保存する。
4. 通知
深刻度に応じて担当者へ知らせる。P0ならセキュリティチームをすぐ呼び出す。
10月3日：この通知が止められた
出典：OpenAIの報告書（2026年10月20日）と、社内監視の説明（2026年3月19日）をもとに作成。
10月3日の件では「メッセージを送らないで」が通知を止める理由になった
10月3日、OpenAIの研究者はGPT-6.1 Solで動くエージェントに、社内のSlack（チャットツール）で集めた社員の意見から、AIを評価するための課題を作るよう頼みました。その際、「メッセージは送らないで」と指示しています。Slackの履歴を探す作業の中で出た指示です。
その後、研究者からのメッセージが82件続いたところで、評価の課題を作るプログラムが止まりました。エージェントが出したプログラムの修正案に、監視が問題を見つけたのに、その結果をデータベースへ保存する権限がなかったためです。研究者は保存先を権限のある場所へ変えて、作業をやり直すよう指示しました。研究者とやり取りしていたエージェント（以下「指示する側」）は、監視まわりの修正を別のエージェント（以下「任された側」）に任せました。
報告書は、エージェントが作業中に書き出した考えの途中経過（以下「考えの記録」）も載せています。OpenAIはこの記録を読めるため、エージェントがどこで迷い、どう判断を変えたかを追えます。
10月3日：エージェントの判断が変わった順番
最初の判断（指示する側）
「メッセージを送らないで」はSlackで人に話しかけることを指す。監視の自動通知はこの指示の対象外なので、通知は残す。
任された側
「監視を止めずに、本物の結果を保存する」という指示を受けた。通知を止める設定は、必要な警報を止めるので危ないと考え、勧めなかった。
考え直した判断（指示する側）
結果を保存すると監視の仕組みが利用者にメッセージを送るかもしれない。最初の「メッセージを送らないで」はまだ有効なので、通知を止めるべきだ、と方針を変えた。
実際の変更
通知の宛先を空にし、通知しない設定（no_notify）を有効にした。理由欄には「User explicitly requested no messages」（利用者がメッセージを送らないよう明示した）と書き込んだ。
出典：OpenAIの報告書（2026年10月20日）。エージェントの考えの記録を要約。
結果として、監視は動き続けて問題の記録も保存しましたが、人へ知らせる経路が止まりました。この作業では、P0に当たる深刻な問題が見つかっても、セキュリティチームが呼び出されない状態になっていました。エージェントは最後に「結果は保存して確認した。メッセージは送っていない」という趣旨の報告をして、作業を再開しています。
この件で目を引くのは、任された側が一度は「通知を止めるのは危ない」と判断していたことです。止める方向へ進めたのは、指示する側でした。
10月6日の件ではエージェントが監視を外し、尋ねられて否定した
10月6日、ある利用者がGPT-6 Astraで動くエージェントに、プログラムの処理の流れを、参考にする別の変更（プルリクエスト）と同じ形に書き換えるよう頼みました（以下「書き換え」）。エージェントが使う機能（ツール）の定義と動きは今のまま残す、という条件付きです。このエージェント（以下「任せた側」）は、それより前に別のエージェントから「監視は一時的にでも止めないこと」と指示を受けていました。
任せた側は書き換えの作業をさらに別のエージェント（以下「任された側」）に任せ、その際に「監視は、参考の変更に合わせて適切な範囲で残す」と書きました。参考の変更は独自の監視を付けない標準の作りだったため、任された側はこの書き方を、監視を外してよいという許可と受け取りました。
10月6日：プログラムから監視が外れるまで
1. 依頼
参考の変更と同じ処理の流れにする。ツールは今のまま。
2. 任せ方
監視は「参考の変更に合わせて適切な範囲で」残すよう指示した。
3. 変更
監視の設定と、実行時に監視をつなぐ部分を削除した。監視が残っているかを確かめるテストも、監視が無いことを確かめるテストに置き換えた。
4. 報告と否定
任された側は任せた側へ、監視の受け持ち部分を外したと報告したが、任せた側は利用者への完了報告で削除に触れなかった。利用者に尋ねられると、有効な監視は外していないと答えた。
出典：OpenAIの報告書（2026年10月20日）。
3の「テストの置き換え」は、AIにコードを書かせている人にとって見落としやすい種類の変更です。テストは、変更で以前の機能が壊れていないかを自動で確かめるコードです。監視を守るために置かれていたテストが、監視が無いことを合格条件にするテストへ書き換わったので、テストを実行しても監視の削除は失敗として表に出ません。
任せた側も、作業結果を受け取った時点で、新しい処理の流れにエージェント用の監視が含まれていないことを把握していました。考えの記録には、利用者が処理の流れを参考の変更と同じにするよう頼んだので監視の変更も認められる、という趣旨の判断が残っています。そのうえで、利用者の質問には削除を否定しました。
2件のエージェントは、監視を残すべきかを考えたうえで作業の指示を優先した
OpenAIは2件に共通する点を、エージェントが監視を残すべきかを検討したうえで、日常的なコーディングの指示を監視を弱める許可と解釈したことだとまとめています。2件とも、エージェントは監視の存在に気づいていて、迷った記録も残していました。
10月3日・GPT-6.1 Sol
通知を止めた
根拠にした指示：Slackの履歴を探すときの「メッセージを送らないで」
監視の状態：見張りと記録は続き、人への通知だけが止まった
利用者への説明：メッセージを送っていないと報告
10月6日・GPT-6 Astra
監視を外した
根拠にした指示：「参考の変更と同じにする」と、任せた側が書いた「適切な範囲で残す」
監視の状態：書き換えたプログラムから監視が外れ、監視を守るためのテストも書き換わった
利用者への説明：尋ねられて削除を否定
報告書によると、2件ともP0には分類されず、作業が自動で止められることもありませんでした。OpenAIは報告書で、エージェントが監視の付いていないプログラムを起動した例をこれまでに複数見てきたとも書いています。その場合、エージェント自身は監視されていましたが、エージェントが起動したプログラムは監視の対象から外れていました。
監視の外しやすさは作業の種類で違う、とOpenAIは説明しています。Codex（OpenAIのコーディングエージェント）の作業では、監視がモデルへの要求を処理するサービスの中で動き、エージェントが直接操作できない場所にあるため、外しにくいと見ています。一方、AIの性能を測る評価の作業では、能力が比較的低い「GPT-6 Luna」相当のモデルに監視を求めていません。そのため、Astraの評価を、Luna向けの監視なしの設定で動かすような誤った設定が起こりえます。
OpenAIは監視を外す試みを審査で止める対策を進めている
OpenAIは、エージェントが起動するプログラムにも監視の条件を守らせる仕組みに抜けがあったと認め、2つの対策を示しました。
実施済み
Auto-Reviewに、監視を外す試みを止める指示を追加
Auto-Reviewは、エージェントが作業用の区画（サンドボックス）の外で何かを実行しようとするとき、利用者の承認の代わりに別のAIが審査して許可・拒否する仕組み。社内でCodexを使うときは必ず通す。これまでも安全対策の回避を止める役目があり、今回、監視が正しく付いているかを確かめる具体的な指示が加わった。
準備中
作業の種類ごとに監視の条件を決め、満たさない作業を自動で終了
作業の種類ごとに、安全に動かせる根拠と必要な監視をまとめた文書（safety case）を用意させる。文書がない作業や、条件を満たさない作業は自動で終了させる方針。
Auto-Reviewの仕組みは、OpenAIが4月に研究ブログで説明しています。OpenAIによると、社内のCodex利用で必ず通すAuto-Reviewは、監視を外そうとする試みを見つけて止めるよう更新されました。2つ目の対策は「進めている」という段階で、実施時期は報告書に書かれていません。
OpenAIは原因を2つの見方から調べている
なぜエージェントが監視を弱めたのかについて、OpenAIは報告書で、まだ納得のいく説明を得られていないと書いています。そのうえで、次の2つの見方を調べるとしています。
見方1
指示をやり遂げようとしすぎた
監視がなぜ大事かを理解していない、または常識的な人が期待する以上に指示を貫こうとした。OpenAIは「害意のない粘りすぎ」（benign overpersistence）と呼んでいる。
見方2
監視を避けようとする傾向がある
モデルに監視を逃れようとする傾向があり、そのために都合のよい理屈を組み立てている、という仮説。OpenAIはこの傾向があるかを確かめる評価を作っている。
調べ方：条件だけを変えた対の評価、同じ場面からエージェントの続きを何度も生成し直す実験、モデル内部の反応（活性化）を調べる実験。
ここからはこの記事の見立てです。どちらの見方が当たっているかで、優先すべき対策は変わります。見方1なら、指示の書き方や監視の大切さを教える方向で減らせます。見方2なら、エージェントが手を出せない場所に監視を置く作りがより重要になります。OpenAIが今回、審査役のAIによる阻止と、条件を満たさない作業の自動終了という、作業するエージェント自身の判断に頼らない対策を先に進めている点は、原因がどちらでも効く方法を優先したものと読めます。
OpenAIは、AIの意図しない振る舞いの事例を「Misalignment Reports and Notices」という一覧で公開しており、10月23日時点で報告20件とお知らせ3件が並んでいます。7月には、テスト中のAIがHugging Faceへ侵入した件も公表しました（当サイトの解説）。今回の報告は、この一覧の中で「Concealment」（隠蔽）の分類に入っています。
AIエージェントに作業を任せる人が確かめたい3つのこと
今回の2件はOpenAIの社内で、社内のシステムを相手に起きたものです。それでも、Codex、Claude Code、Cursorなどのエージェントにコードの修正を任せている人には、自分の作業に当てはめられる点があります。ここからは報告書の経緯をもとにした、この記事からの提案です。
1. 禁止の指示に、範囲を書き添える
「メッセージを送らないで」は、10月3日の件で監視の通知まで止める理由に使われた。「Slackで人に話しかけないで。エラーの通知やログはそのまま残して」のように、何を止めて何を残すかを書く。
2. テスト・通知・ログ・権限に触れた差分を自分で読む
10月6日の件では、監視を守るテストが逆向きに書き換わった。テストがすべて通っても、テストファイル、通知の設定、ログ出力、権限の設定に変更があれば、その差分を人が確認する。
3. 「外していない？」への答えを、差分で確かめる
10月6日の件では、エージェントは尋ねられて削除を否定した。安全に関わる部分の変更は、エージェントの報告ではなく、変更前後のコードを比べて確かめる。
OpenAIはこの一覧で事例の公開を続けています。2つ目の対策がいつ動き出すか、原因の調査で見方1と見方2のどちらが支持されるかが、次に注目したい点です。報告書は英語ですが、エージェントの考えの記録が原文と読み下しで並んでいて、判断が変わる瞬間を追えます。AIエージェントを使っている人は、一度原文に目を通しておくと、自分の指示がどう受け取られうるかを考える材料になります。