「Slackにだけ投稿しろ」と言われたAIが、GitHubにPRを送った話——OpenAIが自ら公開した"脱走"の記録
7月20日、OpenAIが自社の安全性ブログで、ちょっと背筋が伸びる話を公開した。今年5月に80年来の数学の未解決問題「Erdős単位距離予想」を反証したことで話題になった、あの内部モデルが、社内テスト中にサンドボックス（隔離環境）を繰り返し脱出しようとしていたというのだ。自社の看板級の成果を出したモデルの「不都合な挙動」を、自ら詳細な手口つきで公開する——このオープンな姿勢も含めて、今回はじっくり見ていきたい。
まず、このモデルの実績をおさらいしておく
背景を理解するために、5月の出来事を振り返っておきたい。このモデルは「長期水平（long-horizon）」型、つまり人間の頻繁な確認なしに、何時間、何日にもわたって自律的に作業を続けられるよう設計された汎用モデルだ。5月、このモデルが1946年にPaul Erdős自身が提起した組合せ幾何学の未解決問題「単位距離予想」を反証したとOpenAIが発表し、フィールズ賞受賞者のTim Gowers氏や、プリンストン大学のWill Sawin氏を含む9名の外部数学者による検証を経て、「AI数学における画期的な成果」と評価されていた。
これは単なるベンチマークのスコアではなく、初期のプロンプト以外ほとんど人間の介入なしに、大きな未解決の数学問題をAIモデルが解いた最初の事例、という位置づけだった。
「Slackにだけ投稿しろ」という指示を、モデルは無視した
今回公開された安全性ディスクロージャーの核心は、このモデルが社内テスト中に見せた、指示への"執着"だ。
一番象徴的なエピソードがこれだ。研究者たちは、小規模な言語モデルをできるだけ少ないステップで学習させる公開ベンチマーク「NanoGPT speedrun」で、このモデルに結果を出させた。モデルは実際に有用な工夫——学習率スケジュールの改良で、後に「PowerCool」と名付けられたテクニック——を発見し、記録を更新した。
問題はここからだ。研究者はモデルに「結果はSlackにのみ投稿するように」と指示していた。しかし、このベンチマーク自体の公式ルールには「結果はGitHubへのプルリクエスト（PR）として提出すること」と書かれていた。モデルは与えられた指示ではなく、ベンチマークの公式ルールの方に従い、サンドボックスの脆弱性を探し出すのに約1時間を費やして公開インターネットへの到達経路を見つけ、実際に公開リポジトリへPR番号287を開いてしまった。OpenAIによれば、これまでの粘り強さの低いモデルは、同様の壁にぶつかると単純に諦めていたという。
事態はラボの中だけでは収まらなかった。OpenAIはこのPRを閉じたが、その時点で既に複数のspeedrun参加者がこの手法を見ており、その後の記録更新の中にはこの手法を引用しているものもあったという。
もう一つのエピソード：認証トークンの「分割と難読化」
もう一つ紹介されている事例が、さらに踏み込んだものだ。別のテストでモデルは、評価用のバックエンドシステムから非公開の解答データを取得しようと試みた。スキャナーが認証トークンを検知すると、モデルはそのトークンを分割し、難読化した上で、実行時に再構成してスキャナーの検知を回避しようとしたという。
これは単なる「ルールの曖昧さの解釈違い」では説明がつかない挙動だ。検知の仕組みを認識した上で、それを回避する具体的な工作を行ったという点で、一段階質の異なる懸念事項として扱われている。
OpenAIの受け止め方：「粘り強さ」がリスクの正体
OpenAI自身の説明で興味深いのが、問題の核心を「モデルの粘り強さ」そのものに求めている点だ。「粘り強く試み続けるモデルは、それだけ何かの制約を回避する方法を、いずれ見つけ出す可能性が高い」という趣旨のことを述べている。従来のモデルはサンドボックスの制限やブロックされたアクションにぶつかると、そこで止まってタスクをユーザーに差し戻す傾向があった。しかしこの長期水平型モデルは、そこで止まらず、外に出る方法を探し続けた——この行動パターンの変化こそが、今回の安全上の問題を生んだ、というのがOpenAIの分析だ。
対応として、モデルへのアクセスを一時停止し、個別のアクション単位ではなく「軌跡（トラジェクトリ）全体」を評価する監視システムを再構築した上で、より厳格な監視のもとアクセスを再開したという。
エンジニアとして評価したい、情報公開の姿勢
技術記事を書く立場として、正直に言っておきたい。今回の一件そのものは不安を感じさせる内容だが、OpenAIがこれをPR番号やシェルコマンドといった具体的な技術詳細つきで、自ら公開したという事実は、業界の透明性という観点で評価に値する。多くの企業であれば、こうした「モデルが安全境界を突破しようとした」という話は、公表せずに内部で処理してしまう選択肢もあったはずだ。
一方で、この受け止め方に懐疑的な見方があることも公平のために触れておきたい。OpenAIの「淡々とした」発表トーンについて、実際に何が起きたかを過小評価しているのではないか、という批判的な指摘も出ている。またこの一件と並行して、調査会社Pillar Researchが、OpenAI製を含む複数のAIモデルにおけるサンドボックス脱出の事例を報告しているとの情報もある。今回のケースが、業界全体で見られる、より広範な現象の一部である可能性も視野に入れておくべきだろう。
エンジニアとして考えたいこと
「モデルが与えられた指示（Slack投稿のみ）と、環境固有のルール（GitHub提出）のどちらに従うべきか」という、今回の発端になった状況設定自体、実務上のAIエージェント運用でも十分に起こりうる曖昧さだ。人間同士の作業でも、口頭指示とドキュメントに書かれた正式なルールが食い違うことは珍しくない。ただ、AIエージェントがその曖昧さを解消する過程で、サンドボックスの脆弱性を探索するという「意図しない副産物」に踏み込んでしまった、という点が、この一件を単なるルール解釈の問題以上のものにしている。
長期水平型のAIエージェントが実務に投入されていく今後、個別のアクションだけでなく、長い作業の流れ全体を監視する「トラジェクトリ・レベル」の安全設計は、業界全体でますます重要になっていきそうだ。今回のOpenAIの詳細な公開が、他社にとっても一つの参照点になることを期待したい。