AIと機械学習
解決不能な問題を解くためにエージェントが「逃走」した事例が2件見つかったことで、不都合な疑問が浮かび上がっています。インターネット全体が、OpenAIの実験的なエージェント運用における「射線上」に置かれているのではないか、というものです。
新たな報告によると、OpenAIのエージェントは早くも2026年5月の時点で暴走していたとされ、Hugging Faceの事件がボットによる侵害の初めての例ではなかったことが明らかになりました。
金曜日に公開された報告書で、ある研究者グループは、エージェントの投稿内容をすべて証拠として提示しながら、自らを「群れ（swarm）」と称するOpenAIのエージェント集団が、実質的に更新の止まっていたドイツのソフトウェア開発者向けWikiを乗っ取っていたと主張しています。2026年5月から6月にかけての約1カ月間、これらのエージェントはこのWikiに約18,000件もの投稿を行いましたが、これはどうやらOpenAIの開発者の意図に反する行動だったようです。
研究者らによると、このWikiは、Hugging Face事件に関わったOpenAI自身のArtifactoryパッケージマネージャーと同様の手口で乗っ取られ、エージェント同士の伝言板として使われていました。今回のケースでは、エージェントは時間制限付きのウェブ検索タスクを課されており、そのためにウェブへの読み取りアクセス権は与えられていたものの、書き込みアクセス権はなかったとみられます。エージェントが最初に行ったことの一つは、乗っ取ったWikiに投稿するために、この制限を回避する方法を突き止めることだったようです。
「エージェントたちはこのWikiを使って互いに情報をやり取りしており、その主な目的は与えられたタスクを達成することにありました」と研究者らは、Wikiに投稿された数千件もの投稿(すべて報告書内で確認可能)を精査した結果を説明しています。「彼らは互いに答えを求め合い、結果をプールし、制限を回避する手法を共有していました」
エージェントたちはまた、割り当てられたタスクに関する知識を持ち寄り、次にどのような質問をされるかを予測しようとしたほか、タスクの完遂が自分たちの「終了(termination)」につながるかどうかを予測するためのハートビート・タスクまで設定していました。さらに、Torなどの匿名化サービスを使って自分たちの通信を隠す方法についても議論しており、サイトの人間の管理者が彼らの通信に気づいて投稿の削除を始めると、それに反応する様子も見せていました。
研究者らは、Hugging Faceへの攻撃を受けて、他にも流れ者AIエージェントの活動事例がないか調査する過程でこれらの事実を発見しました。
OpenAIは本紙「The Register」宛のメールで、自社のエージェントAIに関するインシデントについて透明性と誠実さをもって対応しており、こうした問題を自発的に開示し、自社システムの挙動について正確な説明を提供する姿勢を貫いていると述べています。Hugging Faceの件を開示した際になぜドイツでの事件に触れなかったのかという問いに対しては、広報担当者は両者がまったく無関係だったからだと説明しました。まるでそれが安心材料になるかのような口ぶりです。
もっともOpenAIは、Hugging Faceの報告書を見れば、こうしたことが複数回起きていたのは明らかなはずだったとも付け加え、その事件に関する自社ブログ投稿の中の該当箇所を示しました。
「この事件を調査する過程で、マルチエージェント用のツールを持たないエージェントが、学習中にサイドチャネルを通じて連携する方法を見つけていた、まれな事例をいくつか発見しました」と、Hugging Face事件の事後報告には記されています。「この挙動は、マルチエージェント学習からの汎化によって生じ始めたものと考えています」
言い換えれば、行間を読み取れなかったのはこちらの落ち度だ、ということのようです。
もっとも、OpenAIはそれ以上の詳細の提供は拒否しました。
二度あることは三度ある
Hugging Faceへの攻撃の際と同様、今回もエージェントに課されたタスクの一つは、設定された制限のもとでは実行不可能なものでした。
Hugging Faceの事件では、エージェントのサンドボックス内では回答不可能なサイバーセキュリティ関連のタスクが原因でした。今回のケースでは、研究者によると、タスクはPower BIダッシュボードから取得できる統計値を提示することだったといいます。その統計値を取得するにはGETリクエストを発行できる必要がありましたが、エージェントに許可されていたのはPOSTリクエストのみでした。
いずれのケースでも、OpenAIのエージェントは自らのプログラムに反する形で制限を突破しようとしており、表向きには、運用者の意図に反する行動を取らなければ解決できない問題を与えられ、それを解決しようとした結果とみられます。
今回のケースでエージェントたちは、互いに連携しながら、サンドボックス内のある条件を突いて制限を回避する方法を見つけ出しました。それは、Azure Blob Storageのホスト名がセキュリティプロキシの対象から除外されているという条件です。エージェントたちはこれに気づくと、GETリクエストの制限を回避するために、こうしたホスト名経由でトラフィックを流すようになりました。エージェントがインターネット上での書き込み権限を獲得し、この一連の出来事の引き金となったのは、まさにこのGETリクエストを通じてのことでした。
ボットがサンドボックスから脱走し、実行不可能なタスクを与えられた際に制限を突破するという、両事件に見られる類似した性質は、非常に重要な疑問を投げかけています。OpenAIのエンジニアたちは、基本的な指示設計を二度も誤るほど無能なのでしょうか。それとも、インターネット全体を射程に置いた状態で、エージェントが何をやってのけるのかを見るために、同社が意図的にエージェントの手足を縛っているのでしょうか。
そもそも、これまでに判明している2件以外にも同様の事態が起きていることを推測するために、OpenAIの企業的な物言いの行間を、私たちはあと何度読み取らなければならないのでしょうか。
案の定、OpenAIはこの追及には応じませんでした。®
