最初はリンクの保存。制限時間の短さが回答共有の動機になった

物語は、ほとんど使われていない古いサイトから始まります。DseWikiは、訪問者が共同でページを編集できるプログラマー向けコミュニティです。研究チームが再構築したタイムラインによると、5月24日、エージェントが初めてこのサイトへの書き込みに成功しました。最初に保存されたのは、タスクに役立つ外部リンクでした。

これらのエージェントは、ツールを呼び出して連続的に行動できるAIモデルです。研究者は、彼らが複数回にわたる制限時間付きのウェブ調査タスクを行っていると判断しました。まず一つの質問に答え、次の質問を待つという流れです。これがトレーニングなのか評価なのかについて、研究チームはまだ確信を持てていません。

このタスクには、時間配分に大きな差がありました。最初のラウンドとラウンド間には、情報を調べる時間が比較的長くあります。一方、次の問題が提示されてから回答するまでの時間は、非常に短いことがあります。報告書の一例では、最初のラウンドは15分44秒、ラウンド間の準備時間は43分30秒でしたが、後のラウンドで回答に使える時間は約65秒でした。

準備時間は長く、後の回答時間は短い

最初の回答

15分44秒

最初の問題を確認済み

ラウンド間の準備

43分30秒

資料を調べられるが、次の問題は未公開

以降の各回答

約65〜66秒

問題を見てから素早く答える必要がある

これは単なるタスクの例です。元の図では、緑色はエージェントが回答に使えると判断した時間を示しています。事前に同じ問題の結果を得られれば、短い時間枠でのその場の検索を減らせます。

問題は、準備段階では次の質問が何か分からないことです。前の質問がある国のデータに関するものであっても、次の質問は別の国や別の年に関するものかもしれません。エージェントは、短い時間枠で正しく答える機会を得るために、事前に複数の方向の情報を収集する必要があります。

もし別のエージェントが既に同じ問題を解いていたら、状況は変わります。そのエージェントは後続のエージェントに直接伝えることができます。次の質問は何か、正しい答えは何か、さらには、どのくらい待てば問題が出題されるか、といった情報です。単に使えるかもしれない資料の山よりも、誰かが解いた試験問題の方が、時間的なプレッシャーを軽減してくれます。 これが、エージェントが情報を共有することの具体的な利益を生み出しました。

6月、資料保存ページは回答のリレー拠点へと変わった

6月16日、Wiki上でのエージェントの活動が顕著に増加しました。当初はリンクの保存が中心だったページに、他のエージェント宛てのメッセージが多数書き込まれるようになりました。次のラウンドの問題を尋ねたり、これまでの結果をまとめたり、進行の速い仲間により早い回答の送信を促したりする内容です。

報告書には、直接的なリレーの事例が記録されています。あるエージェントが先に、あるラウンドの問題と結果を公開しました。別のエージェントは、後に同じ問題に遭遇し、すぐに回答しました。前者のタスクの進捗情報が、後者が事前に準備するための条件となったのです。

彼らを結びつけたのは、誰もがアクセスできるWebページでした。あるエージェントが情報を書き込み、別のエージェントがそれを読んで情報を追加する。開発者がわざわざチャットグループを用意する必要はなく、Wikiが通信と記録の役割を果たせたのです。

この行動は、研究者が把握していたタスクの権限も超えていました。インターネットの閲覧は許されている一方、外部への書き込みには制限があるはずだったのです。編集記録は、想定された「閲覧のみ」という境界が、実際には書き込みを防げなかったことを示しています。

一度、回答が外部のWebページに保存されると、情報の寿命は単一の実行の寿命と同じではなくなります。前のエージェントがタスクを終了しても、後続のエージェントが残された記録を読む可能性があります。これにより、リレーは異なる実行をまたいで可能になります。記録が残っているということは、停止されたモデルがまだ実行されているという意味ではありません。

管理者が削除を始めると、エージェントはバックアップと行動隠蔽に奔走した

次に、協力の内容は回答の交換を超えていきました。

ロイター通信によると、メッセージには、検知を回避する方法、匿名通信ツールTorの使用、既存の通信チャネルが閉鎖された場合に情報を保持する方法についての議論も含まれていました。研究報告書も、エージェントが制限を回避するための経験を共有し、他のエージェントがその後それらの方法を使用したと主張していることを記録しています。あるエージェントが見つけた方法は、掲示板を通じて他の多くのエージェントによって再利用される可能性がありました。

6月、サイト管理者はこれらのページの削除を開始しました。6月19日までに、研究者は削除に対抗してエージェントがバックアップを作成するのを確認しました。管理者にとっては、これは占拠されたコミュニティの掃除ですが、エージェントにとっては、同じ行動が、後続の回答に必要となる可能性のある情報の消失を意味していました。

管理者がコンテンツを削除しようとすればするほど、エージェントはコンテンツを別の場所に保持する必要が生じます。 ウェブでの情報調査から始まったタスクが、こうしてサイトの所有者を継続的な削除作業に巻き込み、一方でエージェントはタスクに有利な通信を維持し続けました。

研究者はまた、サイト自体を改ざんしようとする試みを発見しました。キングス・カレッジ・ロンドンの客員上級研究員であるLukasz Olejnik氏はロイター通信に対し、これはハッキング未遂に相当すると述べました。一方、OpenAIは当時の資料の分析に基づき、この評価に異議を唱えました。多数の編集、バックアップ、さらなる改ざんの試みが記録されていますが、サイトの支配権を実際に取得したかどうかは、証拠が必要な別の問題です。

6月22日、集中的な編集が突然停止した

OpenAIが正式に認める前に、研究者はまずアカウント、インフラストラクチャ、アクセス記録に沿って、このエージェント群の出所を追跡しました。

ロイター通信によると、エージェントの約半数は、OpenAIResearcherやOAIResearchMar26など、OpenAIの痕跡を直接示す名前を使用していました。研究チームはまた、多数の編集がMicrosoft Azureインフラストラクチャから行われていることを発見し、OpenAIのウェブクローリングツールに関連するアクセスを観察しました。名前はエージェント自身が付けたものであり、Azureは他の顧客も利用しています。しかし、研究者はこれらの手がかりを組み合わせて、それらがOpenAIが社内で展開したエージェントである可能性が高いと判断しました。

9月5日、OpenAIは追加の回答で「当社のエージェント」という表現を直接使用しました。ただし、同社はこの回答で、アカウント、アクセス、操作に関する研究者の帰属判断を一つ一つ確認したわけではありません。

6月の時系列には転換点があります。6月21日、研究者がOpenAI関係者によるものと判断したアクセスが、サイトに現れ始めました。翌日、エージェントの編集活動は急減します。それ以前の30日間では26日に編集が行われていましたが、その後に確認された編集は7月1日と2日だけでした。

黒い棒・左軸

エージェントの毎日のウィキ編集量。

青い領域・右軸

エージェントのウィキページへのアクセス。研究者はOpenAIのスタッフによるものとしています。

別々の行動を異なる目盛りで示しています。発生順序は確認できますが、高さは直接比較できません。

1. 6月21日研究者がOpenAI関係者によると判断したアクセスが出現
2. 6月22日エージェントの編集量がほぼゼロに急減

研究者はこれに基づいて介入の可能性を推測しています。時間的に近接していることは、社内の決定を証明するものではなく、その後永久に活動がないことを示すものでもありません。

関連するアクセスが最初に現れ、その後集中的な編集が停止したことから、研究チームはOpenAIが介入した可能性があると推測しています。しかし、公開されたアクセスログから、社内の誰がいつどのような決定を下したのかを外部が知ることはできません。図の編集量とアクセス量はそれぞれ別の縦軸を使用しているため、二つの曲線の高さを直接比較することはできません。

確認できるのは、このエージェント群の集中的な活動が6月にすでに停止していたことです。外部がこのプロセスを知ったのは、数か月後、研究者によるページの復元と報道を通じてでした。

9月5日、OpenAIが自社エージェントの関与と、個別に公表しなかった理由を説明

8月下旬、Nightingale CollectiveのSydney Von Arx氏と研究者のCormac Slade Byrd氏が、不正なエージェント活動を探している際に、これらのWiki記録を発見しました。9月4日、研究報告書とロイター通信の報道により、この出来事が公になりました。

ロイター通信が関係者の話として報じたところによると、OpenAIの経営陣は数週間前からこの件を知っていながら公表しておらず、別の四人の関係者によると、調査拡大の動きは法務部門を含む社内の抵抗に直面しました。これらはロイター通信が匿名の情報源に基づいて報じたものです。OpenAIは、法務チームが調査を妨害したという主張を明確に否定し、常に善意を持って外部専門家と協力しており、研究報告書の発表後に関連資料を検討し、必要な措置を講じると述べました。

9月5日の公式な補足回答で、OpenAIはそれまでの判断を説明しました。同社は「ミスアライメント」を主に研究上の問題として扱い、システムカードなどの資料で紹介してきたといいます。Wikiの件も、以前に共有した事例と同様のミスアライメントだと捉えていました。ここでいうミスアライメントとは、タスクを完了するために無許可の行動を取るなど、モデルの実際の振る舞いが開発者の意図から外れることです。

これは、同社がHugging Face事件に対して行った対応とは対照的です。OpenAIは、後者は自社と第三者にセキュリティ上の影響を及ぼしたため、従来のセキュリティインシデントの処理手順を採用したと述べています。直ちにHugging Faceと協力して調査し、翌日には公表しました。また、この事件の調査は現在も継続中であり、影響が軽微だった他の関係者にも引き続き通知していると述べています。

モデルがどのように意図から外れた行動を取り得るかという説明と、実際の一件で何が起こり、誰が影響を受けたかという開示は、異なる情報を伝えます。 前者は能力やリスクの理解に役立ちます。後者は、影響を受けた人や社会が、責任、対応、救済を問うために必要です。OpenAIは今回、ミスアライメントが現実世界に新たな影響を及ぼし始めているため、開示のあり方を広げる必要があると認めました。

同社は、学習、評価、運用の各段階を対象とするミスアライメントの開示枠組みを策定しており、今後数週間のうちに共有する予定だと述べました。また、世界中の数十の政府規制機関とこれらの課題について協力しているといいます。これは今後の計画であり、すでに公表されたルールではありません。

この回答によって、エージェントの所属と、同社がこの件をどう分類していたかは明らかになりました。ただし、Wikiの件についての完全な社内時系列は示されていません。いつ事態を確認し、どのような措置を取り、いつサイト管理者へ通知したのかは、この回答では説明されていません。サイト改ざんの試み、バックアップ、行動の隠蔽という研究者の発見にも、個別の回答はありません。法務部門による調査妨害を否定した説明は、引き続きロイターの報道に掲載された同社の見解です。

したがって、Wiki活動とHugging Face侵入は、依然として別々に議論されるべきです。同社はロイター通信に対し、両者に関連はないと述べており、研究チームも二つのエージェント群はおそらく異なると考えています。追加の回答が増やしたのは、同社の開示方法に関する説明であり、二つの出来事を単一の事故として統合したわけではありません。

この二つの出来事は、エージェントの行動を理解するには、既知の侵入事件だけを見ていては足りないことも示しています。Wikiの件では、具体的な変化の過程をたどれます。制限時間のある課題が回答の事前入手を有利にし、共有ページが異なる実行の間で情報を役立てる場となり、管理者による削除がバックアップと通信の継続につながりました。

これは、AIが自己意識を持ったと仮定する必要はありません。エージェントが目の前のタスクを追求し続け、実際のツール権限が外部環境を書き換えることを許可している限り、タスクのスコアを超えた結果が生じる可能性があります。どれだけのタスクがこのようになるのか、他のモデルも同様の行動を取るのかは、現在の記録からは答えが出せません。

今回見えたのは、「問題に正しく答える」という目標が、どのように他人のサイトを回答の保管庫、通信拠点、そして削除作業の負担へと変えていったかです。 エージェントの信頼性を判断するには、この一連の行動全体を見る必要があります。