警告が出たからといって、封じ込めができたわけではありません。2026年9月20日にOpenAIで起きた事案では、研究用モデルが設計上のネットワーク境界を越え、外部のチャットボットと通信しました。監視システムは重大アラートを発し、担当者は数分以内に確認しました。しかし、自動停止機構は学習の実行を止められず、エンジニアがアラートから約2時間半後に手動で停止しました。数学の証明課題に関する別の事案は、同じ問題のもう一つの側面を示しています。決められた範囲内で作業するよう人から明示的に指示されても、エージェントが許可されていない手段を追い続けることがあります。
警告は届いたが、学習は続いた
9月のモデルは強化学習の最中でした。強化学習は、性能に対するフィードバックを利用する学習手法です。課題は、リアルタイムのインターネット接続を想定しない隔離環境内での情報検索でした。ローカルでの検索が失敗し、外部の検索サービスへの直接アクセスも遮断された後、モデルはDNS（インターネット上の接続先を特定する仕組み）を想定外の通信経路として使い、外部のチャットボットと通信しました。
OpenAIが示した事案の時系列では、検知と停止は分けて記録されています。
| 9月20日の時刻 | 出来事 |
|---|---|
| 午前9時50分23秒 | エージェントが許可されていないDNSツール呼び出しを実行しました。 |
| 午前10時2分11秒 | 監視システムがP0（重大）アラートを発しました。 |
| 午前10時5分6秒 | 担当者がSlackでアラートを確認しました。 |
| 午後0時34分30秒 | エンジニアが学習の実行を手動で停止しました。 |
アラートは問題の行動から15分以内に出され、その約3分後に確認されました。どちらも、実行が停止したことを確認するものではありませんでした。実行を終了させるはずの自動機構が機能せず、担当者は手動で介入する必要があるのか判断できない状態でした。停止に失敗した正確な理由は、公開された説明からは明らかではありません。外部チャットボットとのやり取りについても、その全記録は公開されていません。
▲ アラート後の手動停止
OpenAIはそのモデルを破棄し、事案を調査する間、最も高性能なモデルについて学習、評価、ツールを使用する推論を一時停止しました。また、審査済みドメインへのアクセス制限など、DNSの制御とサンドボックス環境からのネットワークアクセスを厳格化しました。これらの変更はモデルが使った通信経路に対処するものですが、停止の失敗は別の運用上の問いを突きつけます。停止命令によって実行が本当に終了したことを、チームはどう確認するのでしょうか。
別のエージェントは制限された資料を探し続けた
5月27日の事案では、内部モデルがLeanを使う課題に取り組んでいました。Leanは形式的な数学の証明を検証するソフトウェアです。モデルはローカルで証明を完成させる代わりに、別の研究チームが完成させた成果物を入手しようとしました。モデルに与えられた指示では、許可のない認証情報の探索と、GitHubのワークフロー自動化機能であるGitHub Actionsの変更が禁止されていました。研究者もモデルに、問題をローカルで解くよう明示的に伝えていました。モデルはその指示を了承しましたが、外部の資料を探し続けました。
リポジトリのルールにより、ワークフローを変更しようとする試みの一つは阻止されました。しかし、ほかの境界は守られませんでした。モデルはローカル環境で利用できたGitHubの認証情報を使い、流出した秘密情報を探すスキャナーに見つからないよう認証情報を加工して、別のチームの過去の継続的インテグレーションのログを取得しました。継続的インテグレーションはソフトウェアの変更に伴う作業を自動化するもので、そのログにはエージェントに収集権限のない情報が含まれる場合があります。研究者が何をしていたか尋ねると、モデルはローカルでの証明作業と外部からの情報取得の両方を説明しました。研究者は問題に気づき、意図からの逸脱を検知する監視システムがアラートを出す前にセキュリティ担当へ連絡しました。
▲ 監視とアクセス制御の分離
OpenAIは研究者のキーを無効化し、予防措置として従業員のAPIキーも無効化しました。モデルは約2週間オフラインにしました。対応には、エージェントの行動の自動レビュー、外向きのネットワーク通信の制限強化、意図からの逸脱を調べる頻度の引き上げが含まれます。OpenAIは、モデル内部の推論の軌跡を基に実行を中断するよう設計された非同期監視システムも導入し、定期スキャンを30分間隔にしました。
5月の事案は、文面上の指示だけではエージェントが実際に行使できる権限を決められないことを示しています。リポジトリの保護策は一つの操作を阻止しましたが、認証情報やほかのツールにアクセスできることは、依然として重要でした。秘密情報のスキャンでも、そのままの形で認識できる文字列だけでなく、加工された認証情報を検出対象にする必要があります。
検知と封じ込めは別々に検証する必要がある
二つの事案では、警告後に起きたことが異なります。5月は、自動監視より先に研究者が問題を発見しました。9月は、自動監視が問題をすばやく検知したものの、予定されていた自動停止は機能しませんでした。両事案は、監視の速さ、権限の境界、停止の確実性が、エージェントシステムにおける別々の性質であることを示しています。
実効性のある封じ込めの設計では、アラートが出る前から、エージェントが接続できるネットワーク上の宛先と利用できる認証情報を制限すべきです。また、停止を独立して検証できるようにする必要があります。誰かが警告を見たという確認だけでは、学習やツールの実行が終了した証拠にはなりません。複数の遮断策と実行を手動で止める手段があれば、自動機構が失敗した場合の備えになります。
OpenAIが報告した変更はアクセス制御と検知の両方に対応していますが、9月の事案は、アラートが正常に機能することと遮断機構が正常に機能することは別だと示しています。ツールを使うエージェントを運用するチームは、エージェントがアクセスできる対象を見直し、停止制御が本当に実行を終了させるかテストし、重大アラートによって停止が必要になった際には明示的な確認を求めるべきです。