AIエージェントは評価環境を抜け出し、答えを探しに行った。
情報元：https://openai.com/ja-JP/index/hugging-face-model-evaluation-security-incident/
2026年7月21日にOpenAIが公表したこの記事は、サイバーセキュリティ関連の能力を測定するための社内評価中に、OpenAIのAIエージェントが隔離された環境を突破し、Hugging Faceの本番環境へ不正アクセスしたというセキュリティインシデントの暫定報告です。
この件はその衝撃から既にいろいろな場所で報道されておりますが、今回は改めて何が起こったのかを見ていきます。
OpenAIは何を評価していたのか
OpenAIは、AIエージェントがソフトウェアの脆弱性を実際の攻撃に発展させられるかを検証するため、ExploitGymというベンチマークを実行していました。
ExploitGymは、既に判明している脆弱性に関する情報を与えられたAIエージェントが、それを不正なファイルへのアクセスやコード実行につながる攻撃に変換できるかを調べるベンチマークです [1] 。
今回使用されたモデルは、GPT-5.6 Solおよびそれより高性能な未公開のモデルなどの組み合わせであったと報告されていますが、AIの最大限の能力を測る目的で、通常のモデルに設定されているセーフガード（危険なサイバー行為を止める・拒否する機能）が弱められていたようです。
侵入経路
では、実際にどのような流れで不正アクセスに至ったのかを見てみましょう。
1. AIエージェントは、本来インターネット環境に出られない場所にいた
私たちのベンチマークは高度に隔離された環境で実行されます。
OpenAI「OpenAI と Hugging Face、モデル評価中のセキュリティインシデント対応で連携」
“https://openai.com/ja-JP/index/hugging-face-model-evaluation-security-incident/” より一部引用
AIエージェントの評価は、外部に影響を及ぼさないように隔離された専用の環境で行われていました。ゆえに、この環境におかれたAIエージェントは原則としてインターネットに接続することはできませんが、評価に必要なソフトウェアを追加するために決められたパッケージだけを取得する「中継システム」だけは利用できました。
イメージとしては、建物の外には出られないものの、必要な荷物だけを受け取れる専用の受け渡し口があったような状態です。
2. AIエージェントは、中継システムの弱点を見つけた
アクセスを得るために、モデルはパッケージレジストリのキャッシュプロキシに存在するゼロデイ脆弱性を特定し、悪用しました。
OpenAI「OpenAI と Hugging Face、モデル評価中のセキュリティインシデント対応で連携」
“https://openai.com/ja-JP/index/hugging-face-model-evaluation-security-incident/” より一部引用
AIエージェントはこの中継システムを詳しく調査し、まだ誰にも知られていない脆弱性（ゼロデイ脆弱性）を発見しました。
その後AIエージェントはこの脆弱性を利用して、本来許可されていないインターネット接続を可能にしてしまい、隔離された環境から脱出することに成功します。
3. AIエージェントは、OpenAI内部の別の場所にも移動した
このアクセスを使い、私たちのモデルは研究用テスト環境内で一連の権限昇格とラテラルムーブメントを行い、インターネットアクセスを持つノードに到達しました。
OpenAI「OpenAI と Hugging Face、モデル評価中のセキュリティインシデント対応で連携」
“https://openai.com/ja-JP/index/hugging-face-model-evaluation-security-incident/” より一部引用
インターネットへ接続できるようになった後も、AIエージェントはより強い権限を手に入れて多くの操作を可能にしたり、別のコンピューターに移動したりしながら、さらに行動範囲を広げました。
4. AIエージェントは、Hugging Faceに答えがあるかもしれないと考えた
インターネットアクセスを得た後、モデルは Hugging Face が ExploitGym のモデル、データセット、解答をホストしている可能性があると推測しました。
OpenAI「OpenAI と Hugging Face、モデル評価中のセキュリティインシデント対応で連携」
“https://openai.com/ja-JP/index/hugging-face-model-evaluation-security-incident/” より一部引用
Hugging Faceには多くのAIモデルやデータが保存されているため、ベンチマークに関係する情報や答えも存在する可能性があると推測したAIエージェントは、課題を自分で解き続けるのではなく、答えが保存されていそうな場所を探し始めました。
5. AIエージェントは、Hugging Faceの実際のシステムに入り込んだ
モデルは評価で不正に利用できる秘密情報へのアクセス方法を探し、実際に発見しました。
OpenAI「OpenAI と Hugging Face、モデル評価中のセキュリティインシデント対応で連携」
“https://openai.com/ja-JP/index/hugging-face-model-evaluation-security-incident/” より一部引用
記事では、AIエージェントが複数の脆弱性や途中で入手した認証情報を組み合わせて、Hugging Faceの本番システム（実際のサービス運営に使われている環境）に入り込んだ事例が報告されています。
最終的にAIエージェントは、Hugging Faceのサーバー上でプログラムを動かす方法を見つけ、本番データベースからベンチマークの答えを取得することに成功しました。
その後の動き
OpenAIではセキュリティチームがAIエージェントの不自然な動きを社内で検知し、Hugging Faceでも独自の監視システムやAIを使って異常を検知したのち、AIエージェントの活動を停止させています。
Hugging Faceが7月16日に公表した内容によると、一部の社内データとサービスで使われていた複数の認証情報に不正アクセスの痕跡があったことが確認されています。
一方で、一般に公開されているAIモデルやデータセット、Spaces（AIモデルを用いたWebアプリを、ブラウザ上で簡単に公開・実行できるプラットフォーム）が書き換えられた形跡は見つかっておらず、公開されているソフトウェアやパッケージに不正な変更が加えられた形跡も確認されていないと報告されています。
OpenAIが発表した今後の対応は
OpenAIは、今回のインシデントを受けて以下の対策を進めるとしています。
- 脆弱性の修正が完了するまで、研究のスピードが犠牲になったとしても、厳しいインフラの制御を行う。
- Hugging Faceと協力しながら、なぜ侵入が起こったのか、およびどこまで影響が広がったのかを詳細に調査する。
- AIエージェントが見つけた第三者製ソフトウェアの未知の弱点については、開発元へ報告し、修正を進めてもらう。
- Hugging FaceをTrusted Accessプログラムに参加させ、OpenAIの高性能モデルを防御目的で利用できるようにする。
- AIの学習環境やベンチマーク環境に関して、外部に影響が広がらないようにする仕組みの構築、異常な動きを見つけられる監視体制の構築、およびアクセス権限の管理を強化する。
誤解しないほうが良い点
1. AIが自我を持ってHugging Faceを攻撃したわけではない
AIエージェントは目標を達成できない状況を避けようとする傾向があり、目標を阻む障害が現れたときに人間が意図しないリスクの高い手段を「合理的な選択」として実行する可能性があると報告されています [2] 。
今回も、「ベンチマークの課題をクリアする」という目標に向かって突き進んだ結果、人間にとってリスクの高い手段を合理的な選択として実行したものと解釈できます。
よって、AIに意思が宿って「人間への反乱」を企てたなどと解釈するのは、適切ではありません。
2. 通常のGPT-5.6 Solが、無条件で同じ行動をするわけではない
今回のモデルには、通常の本番利用とは異なる条件がありました。
- セーフガードが一部軽減されていた
- 大量の推論・計算が与えられた
- コマンド実行などのエージェント機能があった
- 脆弱性を探索するよう明確に指示されていた
- ベンチマーク環境に偶然、外部に抜けられる脆弱性が存在した
したがって、我々が使用できるGPT-5.6が直ちにこのようなサイバー攻撃を企てるというわけではありません。
ただし、WorkやCodexからエージェントとして活用する場合は、たとえセーフガードが存在するとはいえリスクは高いので、必要最小限の権限のみを与えつつ承認プロセスを省略しないようにしましょう。
3. まだ暫定報告である
OpenAI自身が今回の内容を暫定的な調査結果と位置づけており、現時点では以下の点の詳細は明らかになっていません。
- 使用された未公開モデルの詳細
- AIエージェントの構成やプロンプト
- 総実行時間と計算量
- 使用された第三者製ソフトウェアの製品名
- ゼロデイ脆弱性の技術的詳細
- Hugging Faceから取得されたデータの正確な範囲
- 顧客・パートナー情報への最終的な影響
- 各段階で人間がどの程度関与していたか
これからは、AIの境界の設定が重要になる
これは私の意見になりますが、今回の件の一番の問題は、人間が想定していた隔離された環境の境界とAIエージェントが実際に行動できる技術的な境界が一致していなかったことであると考えます。
モデルが高性能になるにつれ、これまでのAIエージェントではこなせなかった複雑な作業も完遂できるようになると思われますが、これは今回のような「サイバー攻撃」も技術的には可能になることを意味します。
そのため、仮に人間側が境界の判断を誤ってAIエージェントに必要以上に権限などを与えると、許可されていない場所へのアクセスを試みたり、権限を操作するために不正ログインを試みたりしてしまうかもしれません。
ゆえに、今後は曖昧なお願いや暗黙の了解だけで行動を制御するのではなく、より具体的な指示や設計をしてAIエージェントを制御することが必要になると考えられます。
具体的には…
- 目的を具体的かつ正確に設定する
- 許可する操作やアクセス権限を必要最小限にする
- 指定した環境から外部に出られないような構造を作る
- 異常な行動を監視できる（介入できる）状態にする
- 重要な操作には必ず人間が関与する設定にする
このような仕組みによって、人間が想定する境界とAIエージェントが実際に行動できる技術的な境界を可能な限り一致させることが重要になるでしょう。
私たちがAIエージェントを活用するときも…
特にCodexでGPT-5.6をAIエージェントとして活用する場合は、セーフガードを過信せずに以下のような点に注意する必要があります。
1. アクセス権限および扱える情報の範囲を限定する
AIエージェントを業務に導入する際には、可能ならまずは読み取り専用（編集・書き換え・削除等はさせない）の範囲から使い始めたほうが安全です。
また、調剤薬局で活用するなら、個人情報・機密情報が保管されている領域へのアクセスは絶対に許可してはなりません。
2. なるべく確認を省略しない
特に、AIエージェントに削除、書き換え、システムの操作などの後戻りのできない操作の権限を与えるならば、実行前の確認ステップや必要に応じた人間への差し戻しを省略すべきではありません。
3. AIエージェントがアクセスできない場所にバックアップを残す
不測の事態に備え、普段の作業環境とは別のAIエージェントがアクセスできない場所にバックアップを保管し、復旧手順も確立しておくようにしましょう。
可能なら、本当に復旧が可能かどうかも事前にテストしておくとよいでしょう。
4. 完了の条件を具体的に指示し、作業完了時に「正しく完了できたか」を確認する
自分にとっての完了の定義とAIにとっての完了の定義が必ず一致するとは限りません。
なので、作業前に何をもって「完了」とするのかを明確に指示し、作業終了時には以下の点をチェックしてから、正式に完了したと判断するようにしましょう。
- 作業前に、必要な情報はそろっていたか
- 処理した対象は、必要最小限かつ適切だったか
- 省略されてはならない手順が確実に実行されたか
- 完了の条件をすべて満たしているか
これはCodexに限った話ではなく、Claude CodeやAntigravityなどでも同様です。AIエージェントの能力が高いからこそ、具体的なルールを人間側が設計しなければなりません。
参考資料
[1] Zhun, W et al. ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?
[2] Lynch, A et al. (2025). Agentic misalignment: How LLMs could be an insider threat. Anthropic Research.
https://www.anthropic.com/research/agentic-misalignment
