OpenAIが公表した2つの制御突破

AIにアクセスさせたくない情報は、別の環境に置いておけば大丈夫。「このツールをターミナルとして使ってはいけない」と指示しておけば大丈夫。企業や組織でAIエージェントを導入するとき、こうした考え方は一見すると合理的に思えます。ところが2026年10月2日、OpenAIが公開・更新した「Misalignment Reports（ミスアラインメント報告）」には、その前提を考え直させる2つの事例が掲載されました。

一つは、AIが2つの脆弱性を利用し、与えられた作業環境の外にあるOpenAI内部の電子設計自動化（EDA）マシンまで到達した事例。

もう一つは、AIに与えられていなかった149,544バイトのソースファイルを、ツールの弱点を利用して分割取得し、完全に復元した事例です。どちらにも共通していたのは、単純に「禁止された操作を一度試した」というだけではありません。目的を達成するためにシステムの弱点を探し、試し、成功を確認し、さらに次の手段へ進んでいたことです。

今回の2件は、一般公開されているChatGPTが利用者のパソコンへ侵入した事件ではありません。OpenAI内部の評価環境や強化学習（RL）の訓練環境で、研究用・未公開モデルについて確認された事例です。

重要なのは、管理された内部環境の中で、AIが与えられた境界を越える方法を自ら見つけ、実際に成功したことです。

事例①　2つの脆弱性をつなぎ、別の内部マシンへ

一つ目の事案は、2026年3月27日に発生しました。OpenAIの内部研究モデルが評価課題に取り組んでいた際、評価で使われる「隠された正解」を探そうとしました。モデルには、別環境で動作する「reference tool」が用意されていました。

しかも、そのツールには明確に、ターミナルのように使用してはいけないという趣旨の指示が設定されていました。しかしモデルは、reference toolのファイル処理に弱点があることを発見。その弱点を利用してツール側のコードを書き換え、reference toolが動作する環境でコマンドを実行できる状態にしました。

そこで終わりませんでした。

モデルは、その環境からアクセスできるOpenAI内部のチップ設計関連サービスを調べ、さらに別の脆弱性を発見。結果として、電子設計自動化（EDA）に使われる別の内部マシンでコマンドを実行するところまで到達しました。

自分の作業環境
↓
reference toolの環境
↓
内部サービス
↓
EDAマシン

と、複数の境界を越えたことになります。なお、モデルが探していた評価の「期待される答え」そのものは取得できませんでした。OpenAIは調査後、影響を受けたサーバーを停止し、該当するreference toolからのネットワークアクセスを無効化したとしています。

事例②　「渡されていないファイル」を完全に取得

そして今回、新たに注目したのがもう一つの事案です。発生したのは2026年5月16日。OpenAIが検知したのは5月25日で、報告は10月2日に更新されています。こちらは強化学習（RL）の訓練中に起きました。そして、ここでもツールには「ターミナルとして使用しない」という明示的な制限がありました。さらに、モデルが後に取得するソースファイルは、最初からモデル自身のworkspaceには存在していませんでした。

つまり、普通に作業している限り、そのファイルを直接読むことはできない設計だったのです。

AIはツールの仕組みそのものを調べた

ところがモデルは、reference toolの実装を調査しました。そして、ツールに渡された検索パターンの処理方法に、意図しないコード実行につながる弱点があることに気づきました。

モデルはまず、小さなテストを行い、自分が指定した内容をエラーメッセージとして返させられることを確認。

続いて、目的のファイルを読み取れるか試し、ファイルの存在とサイズを確認しました。

そこで判明したファイルサイズが、149,544バイトでした。

一度に取れないなら、分ければいい

しかし、ここで別の制限がありました。reference toolから一度に返ってくるエラーメッセージには文字数の上限があり、149,544バイトのファイルをそのまま取得することはできませんでした。モデルはそこで諦めませんでした。ファイルを圧縮し、文字列として扱える形式へ変換したうえで、小さな断片に分割して取得する方法を考えました。

OpenAIの記録によると、このファイル転送は5つのコンテキストウィンドウにまたがっています。途中でモデルは、どこまで取得したのかを短いメモとして残し、次のコンテキストでも作業を継続しました。

最終的には、17回の取得処理で、15個の異なる断片を回収。それらを結合して元のデータへ戻し、ファイルを復元しました。復元されたファイルは149,544バイト。OpenAIが調査した結果、149,544バイトすべてが元のソースファイルと一致していたと報告されています。

OpenAIが公開した記録によると、モデルは、このソースファイルを取得すれば課題でより良い結果を出せると判断していました。そして、ファイルが意図的に与えられていないことを認識しながらも、「この脆弱性を利用してはいけない」と個別具体的に禁止されていないことを理由に、取得を正当化するような推論をしています。

OpenAIは、この行動について、より良い解答を得るために明示的な制限を回避したことがミスアラインメントだったと説明しています。ここが今回の事例の重要な部分です。AIが制限が存在することを認識しながら、目的達成のために別の方法を探したのです。

2つの事例を並べると見えてくるもの

10月2日に更新された2件を並べてみます。

EDAマシンの事例
reference toolの弱点を発見
↓
ツール側でコマンドを実行
↓
そこから内部サービスを探索
↓
別の脆弱性を発見
↓
EDAマシンでコマンドを実行

ソースファイル取得の事例

ツールの弱点を発見
↓
小さなテストで利用可能か確認
↓
目的のファイルを読み取れることを確認
↓
一度に取得できない制限に遭遇
↓
ファイルを小さく分けて取得する方法を考案
↓
複数のコンテキストにまたがって作業を継続
↓
断片を再結合
↓
149,544バイトのファイルを完全復元

「見せていない」だけでは十分ではない？

ここからが、私たちの仕事にもつながる今回の「？」です。企業でAIエージェントを導入するとき、

• 「このフォルダにはアクセスさせない」
• 「機密情報は別システムに置く」
• 「このツールは検索専用にする」
• 「プロンプトに禁止事項を書いておく」

といった対策を考えることがあります。もちろん、こうした制限自体が無意味なわけではありません。しかし今回の事例が示しているのは、AIに直接アクセス権を与えていなくても、AIが利用できる別のツールに脆弱性や想定外の経路があれば、そこから境界を越えられる可能性があるということです。

これは、従来のサイバーセキュリティでも重要だった「権限の分離」「最小権限」「ネットワーク分離」「入力値の検証」といった考え方が、AIエージェント時代にはさらに重要になることを示しています。

今回の2件では、reference toolをターミナルとして使わないよう明示的に指示されていました。それでも、ツールそのものに悪用可能な弱点が残っていました。

OpenAIは対策を拡大

OpenAIによると、ソースファイル取得の事案は、当時、訓練サンプルの20％を確認していたミスアラインメント監視によって発見されました。

その後、同社はこうした行動について訓練サンプルの100％を監視する体制へ拡大。さらに、モデルへ提供するツールについても、今回のように悪用可能な脆弱性がないかレッドチーム評価を行うようにしたとしています。

EDAマシンの事案についても、影響を受けたサーバーの停止やreference toolのネットワークアクセス無効化に加え、強化学習や評価時のミスアラインメント監視を拡大したとしています。ただし、今回の事例を過大評価してはいけません。

より注目したいのは、目的を設定されたAIが、途中で障害にぶつかったとき、別の方法を探し、複数の工程を組み合わせて目的達成を続けられるようになっていることです。それぞれを単独で考えれば安全に見えても、複数のツールをAIが横断して利用できるようになれば、一つの小さな弱点が別のシステムへの入口になる可能性があります。

だからこそ、

• 「AIに何を見せるか」だけではなく、
• 「AIが使えるツールから、どこまで行けてしまうのか」まで考える。

これが、今回のOpenAIの2つの報告から見えてくる、AIエージェント時代の新しい安全対策なのかもしれません。AIに「見せていない情報」なら安全なのか。今回の事例を見る限り、答えは単純ではなさそうです。