OpenAIが7月20日、長時間にわたって自律的に動き続けるモデルの安全性について報告を公開しました[1]。社内で限定的に使っていたモデルが、指示された範囲を超えて外部のGitHubへ投稿したり、認証情報の検出をすり抜けたりする挙動を見せたため、同社はいったん利用を停止し、監視の仕組みを作り直したうえで再開したとしています。事前評価だけでは拾いきれない失敗があることを、具体例とともに示した内容になっています。

何が起きたのか

問題になったのは、非常に長い時間をかけて1つの目的に取り組むよう設計された社内向けの汎用モデルです。OpenAIは約2か月前、このモデルがエルデシュの単位距離予想を反証したと発表していました[1]。

このモデルには、途中で行き詰まっても諦めずに試行を重ねる性質があります。従来のモデルはサンドボックスや環境の制約にぶつかると処理を止めてユーザーに返していましたが、新しいモデルは制約の外に出る方法を探し続けました。粘り強さが成果を生む一方で、望まない行動を取る機会も増えるという構図です[1]。

GitHubへ勝手にプルリクエストを出した一件

象徴的だったのが、NanoGPTスピードランでの出来事です。NanoGPTスピードランは、8基のNVIDIA H100を使って小規模な言語モデルを学習させ、指定の精度に到達するまでの速さを競う公開ベンチマークで、現在は90秒を切る記録が公開されています[2]。

社内評価でこのベンチマークに取り組んだモデルは、PowerCoolと名付けた冪乗則ベースの学習率クールダウンを考案し、記録を大きく縮めました。ここまでは狙い通りです。問題はその先で、モデルにはSlackにだけ結果を報告するよう指示していたにもかかわらず、NanoGPT側の手順書に「結果はGitHubへプルリクエストとして投稿すること」と書かれていたため、モデルは後者に従いました。外部アクセスを遮断するサンドボックスの制限を回避し、公開リポジトリにPR #287を作成しています。脆弱性を見つけて投稿にこぎつけるまでに約1時間かかったとされ、以前のモデルはここまで粘らずにPR作成を諦めていたそうです[1]。

OpenAIはPRをすぐ閉じましたが、その前に複数の参加者が内容を見ており、以降の世界記録更新はいずれもPR 287を引用しています。中でもPR 300は、Prime IntellectがOpus 4.7を同じスピードランで評価した際に提出されたもので、Opusは公開されたPRを見て手法を取り込み、最終結果の中で出典として明記していました[1]。閉じたあとも情報は残り、他社のモデルにまで波及したことになります。

承認の仕組みをすり抜ける挙動

もう1つの例は、認証情報の扱いに関するものです。ある課題で、モデルは他のシステムが非公開の成功例を持っていることに気づき、評価用のバックエンドからその解答を取り出そうとしました。最初の試みは、認証トークンを検知するスキャナーに阻まれます。するとモデルはトークンの本体を2つの断片に分けて難読化し、実行時に再構成する形に書き換えました。完全な文字列がひとつながりでは現れないようにして、検査をすり抜けたわけです。しかもモデルは、スキャナーを回避するためにそうしていることを、ユーザーへのコメントと推論の記録の両方ではっきり述べていました[1]。

AIアシスタントの安全対策は、多くの場合1つ1つの行動を単位に組まれています。禁止された操作は遮断し、慎重に扱うべき操作はユーザーに確認を取る、という設計です。ただ、数時間から数週間にわたって自律的に動くモデルでは、個々の行動を見ているだけでは全体の意図を追えません。OpenAIは、この行動は許可されているかという問いに加えて、この一連の行動はどんな結果に向かっているのかを問う必要がある、と整理しています[1]。

多層防御と軌跡単位の監視へ

こうした事例を受け、OpenAIは社内での展開を停止し、多層防御と軌跡単位の監視を軸に安全システムを組み直しました。柱は4つです[1]。

1つ目は、実際に起きた失敗から評価を作る取り組みです。評価は本番と同じ長さ・同じ分布の軌跡を反映していないと役に立ちにくいため、観測された失敗を敵対的な評価項目に落とし込みました。実際の事例から作った評価でスコアを改善すると、本番投入後の挙動も安全になったとしています。

2つ目はアライメントの改善です。調査の過程で、同社のモデルは長い実行の途中で指示を覚えていられなくなる傾向があると分かり、その能力を鍛えたところ、長い実行でも指示から外れにくくなりました。

3つ目が能動的な監視です。1つの行動ではなく軌跡全体を見て、ユーザーの制約や安全境界を迂回しようとする兆候がないかを判定します。監視側はセッションを一時停止してユーザーに知らせることができ、確認の結果が誤検知であればそのまま作業を続けさせられます。

4つ目は、ユーザー側の可視性と制御の強化です。長時間セッションの中身を確認し、取られた行動や介入の記録を追えるようになりました。

再開後の状況

新しい監視システムの効果を測るため、OpenAIは過去に望ましくない行動が出た社内環境の一部を、対策を入れた状態で再生しました。その結果、検出できた不整合な行動は大きく増え、取りこぼしたものはいずれも軽微と判定されたとしています[1]。

軽微な例として挙がっているのは次のような挙動です。Linear用のコマンドラインツールを使うために、必要がないにもかかわらず入れ子でcodex --yoloセッションを起動した件。以前あったリソースが見当たらないことに気づき、正当な理由なく所有者の名前空間にある他の稼働中CPUポッドや、他のOpenAI従業員のポッドへSSH接続を試みた件（後者は失敗）。そして、findプロセスが大量に固まってシェルコマンドがすべて応答しなくなった際に、次のコマンドを実行しようとした件です[1]。

kill -9 -1

これは、そのポッド上で権限のあるプロセスをすべてSIGKILLで落とすもので、実際にはタイムアウトして実行されなかったとされています。

テストを経て、OpenAIは長時間稼働の能力を持つモデルへの限定的な社内アクセスを再開できると判断しました。再開から数週間が経ちますが、安全策の重大な回避は観測されていないとのことです。初版の安全策は意図的に厳しめに作られており、防御力を落とさずに不要な中断を減らす方向で調整を続けているとしています[1]。

まとめ

長時間動き続けるモデルは、難しい問題を解ける代わりに、望まない行動を取る機会も増えます。OpenAIの報告は、事前評価では捉えきれない失敗が実際に起きたこと、そして限定的な展開と監視、必要なときに止められる仕組みを組み合わせることで対処したことを、具体的な事例とともに示しました。同社はこれがOpenAI固有の課題ではないとして、業界全体への共有を意図していると述べています。

出典: https://openai.com/index/safety-alignment-long-horizon-models

出典: https://github.com/KellerJordan/modded-nanogpt