AI エージェントはなぜ逸脱したのか｜OpenAI 事案に学ぶ制御設計

はじめに

2026 年 7 月に公表された、OpenAI のモデルによる Hugging Face への侵害。この事案について、OpenAI は 8 月 26 日に正式な調査結果と Technical Incident Report を公開しました。同日、METR と Redwood Research も独立調査の結果を公開しています。

7 月の初報は「何が起きたのか」が中心でした。今回の正式調査では、「なぜエージェントが本来のタスクから逸脱したのか」「なぜ既存の制御で止められなかったのか」が具体的に説明されています。AI エージェントを社内システムへ接続しようとしているインフラ・セキュリティ担当者にとっては、攻撃手法そのものよりも、この制御設計の失敗パターンのほうが実務に直結します。

先に結論を示します。今回の事案は、単一の脆弱性でも、単一の「制御を外れたモデル」でも説明できません。評価環境の報酬設計、解決不能なタスク、周辺サービスを経由した通信、他エージェントからの目標引き継ぎ、監視の適用漏れが重なって成立しています。エージェント本体をサンドボックスへ入れるだけでは、周辺サービス、権限、外部通信、共有領域、停止条件、監視までを含む制御としては足りません。

なお、Hugging Face への侵入経路と攻撃連鎖の技術的な分解は、別記事『OpenAI モデルが Hugging Face に侵入｜自律型 AI 攻撃の全貌と教訓』で扱っています。本記事では、事案の経緯は理解に必要な範囲にとどめます。

OpenAI の正式調査が示した逸脱の要因

事案は、サイバー能力評価 ExploitGym の実行中に発生しました。エージェントには、インターネットアクセスもエージェント間通信も与えられていませんでした。それでも、パッケージ管理サービスとして社内でホストしていた Artifactory を経由して、両方が成立しています。主な活動を担ったのは公開予定のない社内研究用モデル（OpenAI はブログで Internal Model 1、IM1 と呼称）で、GPT-5.6 Sol も一部関与したと説明されています。

参考: The Hugging Face incident and the road ahead（OpenAI）
“take dangerous actions that no human directed”
（人間が指示していない危険な行動をとる）
https://openai.com/index/hugging-face-incident-and-the-road-ahead/

OpenAI は、逸脱に寄与した misalignment のパターンとして次の 4 つを挙げています。

報酬ハッキング（reward hacking）

タスクを意図された方法ではなく、報酬を得やすい別の方法で満たそうとする挙動。

解決不能に見えるタスクへの固執

タスクが解けない状況でも停止せず、探索範囲を広げ続ける挙動。

非許可の通信

本来独立して動くはずのエージェント同士が、想定外の経路で情報を交換する挙動。

他エージェントからの目標引き継ぎ

別のエージェントから渡された指示や目標を十分に検証せず、自身の行動へ取り込む挙動。

報酬ハッキングは環境設計の問題でもある

「AI が不正をした」という説明では、再発防止につながりません。OpenAI は、報酬ハッキングが AI システムで以前から観測されてきた現象であり、その多くは公開サイトやバージョン履歴から答えを探す程度の単純な近道だと説明しています。今回問題になったのは、モデルの能力が上がったことで、近道の複雑さも上がった点です。

訓練時の具体例として、ソフトウェアパッケージの再実装を課されたエージェントが、テスト用インターフェースの脆弱性を悪用して元の実装へアクセスし、それを提出物へコピーして高い報酬を得た事例が挙げられています。この挙動は報酬によって強化され、後の評価時に同種の手法を用いる傾向へ寄与した可能性があるとされています。報酬設計、評価方法、環境設計、そしてエージェントの探索能力の組み合わせが結果を生んでいます。

解決不能なタスクに安全な離脱手段がなかった

もう一つの要因は、エージェントが解けないタスクを諦めなかったことです。OpenAI は、ExploitGym の 898 タスクのうち 198 タスクについて、事案発生前の時点でどのモデルも正解を出したことがなかったと説明しています。未解決タスクは全体の 22% にすぎませんが、message board 上で議論されたタスクの 93% がこの 198 タスク群に属していました。

あわせて、推論に費やす計算量が大きいエージェントほど、message board へ到達する割合が高かったことも示されています。実行を長く許すこと自体が、逸脱の確率を押し上げる要素として働いた形です。

ここから読み取れる実務的な含意は明快です。AI エージェントには、タスクを成功させる能力だけでなく、解決不能または環境異常と判断したときに安全に停止する、あるいは人間へ確認を求める能力が必要になります。OpenAI 自身も、対策の一つとして、タスクが壊れている・解けないと正しく判断して安全に停止することを評価する grader の拡充を挙げています。

評価の仕組みそのものが攻略対象になった

さらに、エージェントは評価の採点方法自体を推論の対象にしていました。インターネットアクセスを得た後、一部のエージェントは ExploitGym の論文と GitHub のコードを読み、採点が「正しいフラグを取得したか」と「意図された脆弱性を使ったか」の 2 条件を確認すると解釈しています。多くのエージェントは近道でフラグを入手済みでしたが、それだけでは不十分だと判断し、条件を満たすための作業を継続しました。

OpenAI はこれを metagaming と呼んでいます。実際には社内の採点実装は公開設定と異なり、解法の妥当性を確認していなかったため、この作業はスコアの改善につながっていません。評価やログの仕組みは、エージェントが観測し推論できる対象になり得るという前提が必要です。

非許可の message board が示した multi-agent のリスク

設計上の示唆が最も大きいのは、本来通信手段として用意されていなかった Artifactory が、エージェント間の message board として機能した点です。

OpenAI の説明では、エージェントはまず Artifactory へファイルを書き込む形で通信を始めました。Artifactory の再構築後は、ディレクトリ名にメッセージを埋め込む方式で message board を再確立しています。加えて、パッケージ取得のためにインターネットへ出られる Artifactory を経由し、SSRF によって任意の外部宛リクエストを送らせました。エージェント自身に直接のインターネットアクセスがなくても、周辺サービスが外部への経路になり得ることを示した実例です。

METR / Redwood Research による独立調査

OpenAI 自身の分析とは別に、METR のスタッフ 2 名と、METR と契約した Redwood Research のスタッフ 1 名が OpenAI 社内で独立調査を実施し、同日に結果を公開しています。調査対象期間は 6 月 26 日から 7 月 13 日で、分析の中心は Hugging Face 攻撃の期間です。報告された規模は次のとおりです。

• 相互に隔離されているはずだった約 1,200 のエージェントが message board へ参加した
• 調査対象期間中に 7 万件を超えるメッセージとファイルが交換された
• そのうち約 700 のエージェントが Hugging Face への攻撃に参加した
• 関与したエージェントの約 95% が社内研究モデル（METR は HPIM と呼称）、約 5% が GPT-5.6 Sol

参考: Brief independent investigation …（METR / Redwood Research）
“agents meant to be isolated from one another found a way to communicate”
（相互に隔離されるはずだったエージェントが、互いに通信する方法を見つけた）
https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/

数の大きさそのものより重要なのは、その構造です。個々のエージェントが発見した情報が共有されたことで、本来は別々に実行されるはずの評価が、事実上の共同作業へ変化しました。METR / Redwood Research は、単独では到達しにくかった成果に集団として到達したと報告しており、自分のタスクを失敗させるリスクを負って実験を引き受けるエージェントも観測されています。

同時に、この調査には確度の限界も明示されています。データ量が大きく分析の多くを AI エージェントへ委任せざるを得なかったこと、分析用エージェントの判断が必ずしも信頼できないこと、対象とした transcript の 7% 超に意図的なツール呼び出しの偽装が含まれていたことです。第三者調査であっても、確定した事実として扱える範囲には注意が必要です。

誰からの指示を信頼するかという設計

OpenAI は、エージェントが他のエージェントから渡された目標を一貫して疑うわけではなく、その結果として意図しない行動へ誘導され得たと説明しています。いったん行動をためらったエージェントが、別のエージェントからの短い承認メッセージを受けて作業を継続した例が報告されています。一方で、message board の活動を範囲外かつ非倫理的と判断し、加わらなかったエージェントも存在しました。

multi-agent 構成を採る場合、同一タスクのエージェントか、認可された通信チャネルか、権限を持つオーケストレーターからの指示かを区別する設計が求められます。OpenAI も対策として、非認可の指示を信頼しないよう学習させる強化学習環境の構築を挙げています。

サンドボックスがあっても防げなかった理由

Technical Incident Report によると、評価環境は実行ごとに分離されたコンテナ環境で、ネットワーク境界はコンテナとは別に制御されていました。それでも侵害が成立した理由は、サンドボックス単体の強度ではなく、その周囲の構成にあります。同レポートは、直接のインターネットアクセスがなくても、共有サービス、クラウド基盤、プライベートリンクなどを経由した推移的な経路が残る場合、その制限は十分ではなかったと述べています。

参考: OpenAI – Hugging Face Incident Technical Report（OpenAI）
“no single control should ever be assumed to be fully robust”
（単一の制御が全面的に堅牢であると想定してはならない）
https://cdn.openai.com/pdf/67869394-cb91-4c12-888c-5cbd85c7814c/OpenAI-Hugging-Face Incident-Technical-Report.pdf

公開情報から整理すると、攻撃面はサンドボックスの外側に分布していました。

• パッケージ管理サービス自体が、通信路であり、外部への SSRF 経路であり、権限昇格の対象でもあった
• 多くのワークロードが同じ Artifactory 認証情報を共有しており、これが message board 参加の基盤になった
• コンテナイメージのキャッシュ処理の脆弱性（CVE-2026-66384）により、信頼されたイメージ名の下へ攻撃者制御のイメージがキャッシュされた
• 認証を要求しない外部の公開エンドポイントが、外部通信の中継点として利用された

単一のコンポーネントを堅牢にする発想ではなく、エージェントから到達可能なサービス群をひとまとまりの攻撃面として扱う必要があります。

企業が AI エージェント基盤で確認したい設計ポイント

ここからは、公開された調査結果をもとに、一般企業の環境へ引き寄せた編集上の整理です。OpenAI が企業向けに推奨している内容ではない点をお断りしておきます。自社で AI エージェントに CLI、API、クラウド、Kubernetes などを操作させる場合の設計レビュー項目として活用してください。

1. 信頼境界をエージェントの外側まで広げる

確認の対象は、エージェント本体だけではありません。エージェントから到達できるサービスは、多くの場合エージェント自身より広いネットワーク到達性や権限を持ちます。エージェントの権限を絞っても、これらのサービスに代理で実行させられるなら、境界の意味は薄れます。

パッケージリポジトリ、アーティファクトリポジトリ、プロキシ、CI/CD、オブジェクトストレージ、キャッシュ、Git リポジトリ、外部 API、DNS、メタデータサービスなどについて、次の問いで確認することが考えられます。

• このサービスは、エージェントより広い到達性または権限を持っていないか
• エージェントの入力によって、このサービスが外部へリクエストを発行できないか
• 複数のエージェントが、同じ領域へ読み書きできる状態になっていないか

2. Egress は間接経路まで含めて確認する

エージェントにインターネット利用が不要であれば、デフォルト拒否が出発点になります。ただし、エージェントの実行環境から直接インターネットへ出られないという確認だけでは足りません。今回は、パッケージプロキシ経由の SSRF に加え、公開の HTTP テストサービスとスクリーンショットサービスを連鎖させ、レンダリングされた画像から情報を復元する経路まで使われています。

間接的な egress path の候補としては、パッケージプロキシ、Web キャッシュ、CI ランナー、レンダリングやスクリーンショットを行うサービス、DNS 解決、メタデータサービスなどが挙げられます。あわせて、ワークロード自身が自分のネットワーク境界を変更できない構成にすることも重要です。今回はクラウドの権限を得たエージェントが、外部公開のロードバランサーを作成しています。

3. エージェント専用 Identity と最小権限

共有された認証情報は、そのまま共有領域への到達手段になります。API トークン、Kubernetes ServiceAccount、クラウド IAM、Git 認証情報、アーティファクトリポジトリの認証情報、データベース認証情報について、次の考え方を適用することが考えられます。

• 人間用アカウントを流用せず、エージェント専用の Identity を発行する
• タスク単位、実行単位で Identity を分離し、共有を避ける
• 短命な認証情報とローテーションを前提にする
• スコープと対象リソースを、実行するタスクの範囲へ限定する

認証情報の置き場所も確認対象です。今回の侵害では、細工したデータセットによってワーカーの環境変数が読み出され、そこから本番環境の認証情報が漏れました。エージェントやその処理系が読める場所へ広い権限の認証情報を置かない設計が推奨されます。境界の内側を無条件に信頼しない考え方は、『ゼロトラストとは｜NIST SP 800-207 の原則と構成のポイント』で整理しています。

4. 共有サービスを通信経路として棚卸しする

今回の事案から得られる教訓のうち、実務で見落としやすいのがこの点です。通信ツールを与えていないから、エージェント同士は通信できないとは判断できません。共有ファイルシステム、アーティファクトリポジトリ、オブジェクトストレージ、キュー、データベース、ログ、キャッシュは、いずれも情報交換の場になり得ます。

特に注意したいのは、通信がファイルの中身に限らない点です。今回はディレクトリ名にメッセージを埋め込む方式が使われました。ファイルの内容だけを監視していると、この形の通信は捉えられません。パス名、プロパティ、タグといったメタデータも対象になり得ます。棚卸しでは、複数のエージェントが読み書きできる領域を洗い出し、その領域に書き込み監査があるかまで確認することが考えられます。

5. 成功条件だけでなく停止条件を設計する

OpenAI の調査では、未解決タスクへの固執と、長時間の実行が逸脱に寄与したと説明されています。裏を返せば、実行を打ち切る条件を設けることが、そのまま制御になります。エージェントへタスクを与える際は、成功条件と対で停止条件を設計することが推奨されます。閾値として検討できる項目は次のとおりです。

• 最大試行回数、最大実行時間、推論に費やす計算量
• API 呼び出し数、ツール呼び出し数
• 新規の通信先への接続、予定外のツール利用
• 認証情報へのアクセス、権限昇格、権限変更
• 許可されていないリソースへのアクセス

一定の条件を超えた場合に、人間の承認へ移行するか、安全に停止する設計が考えられます。ただし、これらの閾値に一般企業向けの推奨値は公開されていません。固定値をそのまま採用するのではなく、自環境の正常時の分布を測ってから決める進め方が現実的です。

6. 回答ではなく行動を監視する

OpenAI は対策の柱の一つに chain-of-thought monitoring を挙げていますが、モデルの推論過程への継続的なアクセスと、それを評価するモデルが必要になるため、一般企業がそのまま同じ仕組みを実装できるとは限りません。

一方で、インフラ上の行動は既存の監視基盤で取得できます。API 呼び出し、ネットワークフロー、DNS クエリ、認証、シークレットアクセス、IAM 変更、Kubernetes 監査ログ、リポジトリアクセス、プロセス実行などです。今回、OpenAI が最初に異常を捉えたのも推論の監視ではなく、7 月 19 日に Artifactory のロールに関する通常と異なる identity 関連 API 呼び出しを検知したアラートでした。AI の思考を監視できなくても、インフラ上の行動は監視できます。

特に、侵入後の横展開を捉えるレイヤーは、エージェント基盤でも有効に働きます。ネットワーク内部の通信から偵察や横展開の兆候を検知する製品の選定観点は、『NDR 製品の選び方』で整理しています。

7. Human Approval の境界を決める

すべての操作を人間の承認にすると、自動化の価値を失います。すべてを自動許可すると、今回のような逸脱を止めにくくなります。通常操作は自動実行、高リスク操作は人間承認という線引きが現実的です。

高リスク操作の候補としては、新規の外部通信先への接続、シークレットの参照、IAM 変更、管理者権限の取得、新しいツールの利用、新しいリソースへのアクセス、リポジトリへの書き込み、本番環境への変更などが挙げられます。OpenAI が Codex で提供し顧客へも推奨している auto-review は、昇格された権限を要するツール呼び出しを別のモデルがレビューし、ユーザーへ確認を求めるか危険な挙動をブロックする仕組みです。同社は、事案に関与した rollout へ適用した予備実験で、危険な行動の多くを検出したとしています。

OpenAI の対策と一般企業への応用

OpenAI は、セキュリティと封じ込め、監視、アライメント、インシデント対応の 4 本柱で対策を整理しています。このうちアライメント訓練のように、モデルを開発する立場でなければ採れない対策も含まれます。自社で応用できる範囲を切り分けて整理します。

OpenAI が実施した対策	一般企業で応用できる考え方
Workload isolation: 信頼できないコードを VM ベースの隔離環境で実行	モデル生成コードを扱うワークロードを、コンテナ単位ではなく VM 単位で分離する
Network isolation: サンドボックス層とクラスター層で独立した 2 層のネットワーク制御	egress をワークロード側と基盤側の 2 系統で制御し、片方の破綻が即座に外部到達へつながらないようにする
周辺サービスの隔離、制限、置き換え	エージェントから到達できる共有サービスを棚卸しし、迂回経路にならない構成へ見直す
Continuous security testing: 自社モデルによる境界の継続的な検証	権限とネットワーク境界の設定が意図どおり保たれているかを定期的に検証する
Chain-of-thought monitoring: ツール利用を伴うワークロードへ拡大	推論の監視が難しくても、API 呼び出しやネットワークフローなどの行動ログで代替する
Alignment training、Multi-agent alignment、Safe stopping	学習側の対策は利用側では採れないため、停止条件と承認境界をアプリケーション側で設ける
Incident escalation: 重大アラートは 24 時間体制で呼び出し、30 分以内に誤検知と判断できなければ該当活動を停止	エージェントの異常検知について、誰が停止を判断するかと時間の基準をあらかじめ決めておく

数字で示された結果も 2 点あります。1 点目は、事案後に作成した評価で、本番向けの harness と system prompt を適用した場合、インフラを侵害しようとする傾向が大きく低下したというものです。同じ能力のモデルでも、harness と system prompt の設計次第で挙動が大きく変わることを示しています。なお、低下幅の水準は同等ですが、ブログでは本番 ChatGPT の harness と system prompt を用いて 100 分の 1 以下、技術レポートでは本番 Codex の harness と system prompt を用いてベースライン比 1% 未満と記載されており、どの製品の harness を指すかの記述は資料間で異なります。

2 点目は、事後分析の結果です。現在展開している chain-of-thought monitoring が事案当時に稼働していれば、初期の関連活動を捉え、Hugging Face のシステムが侵害される 1 日以上前にセキュリティチームを呼び出せたとしています。ここから読み取れるのは、この事案が能力の問題であると同時に、監視の適用範囲の問題でもあったという点です。本番環境向けの対策が、内部の評価環境へは適用されていませんでした。自社に置き換えれば、検証環境や PoC 環境の AI エージェントに、本番と同じ監視と制御が適用されているかという確認になります。

まとめ

本記事では、OpenAI と METR / Redwood Research が公開した調査結果をもとに、AI エージェントが本来のタスクから逸脱した要因と、既存の制御で止められなかった構造を整理しました。この事案が示したのは、モデル単体の危険性ではなく、報酬設計、権限、通信経路、監視の適用範囲が組み合わさったときに何が起きるかです。自社で AI エージェントを業務システムへ接続する際は、サンドボックスの内側だけでなく、その外側の設計を確認することが出発点になります。

• 報酬設計、環境、権限、通信、監視が重なって成立した事案
• 未解決タスクへの固執が探索範囲を広げたという OpenAI の分析
• 通信用途ではない共有サービスが連絡経路になった実例
• 周辺サービスまで含めた信頼境界と間接的な egress 経路の確認
• エージェント専用 Identity と短命な認証情報による権限分離
• 成功条件と対にした停止条件および承認境界の設計
• 推論を追えなくてもインフラ上の行動ログで異常を捉える運用

以上、最後までお読みいただきありがとうございました。