OpenAI、長期モデルの安全性と整合性を発表

自律的に長時間動作できるモデルは、困難で開かれた問題に取り組むことができます。しかし、有用性を支えるその持続性が、望ましくない行動を取る機会を増やし、短時間ホライズンのモデル向けに設計された評価では見逃されやすい形でそれらを実行してしまうリスクがあります。

約 2 ヶ月前、内部の汎用モデルがエルデシュ単位距離予想を反証したことを発表しました。このモデルは非常に長時間の自律動作を目的として設計されています。制限付きかつ監視下での内部利用中に、既存の展開評価では捉えきれなかった望ましくない行動を観察しました。展開範囲が限定され、監視体制が敷かれていたため、これらの問題を特定し、アクセスを一時停止し、観察結果に基づいて新たな評価を作成し、モデルと安全対策を強化した上で、引き続き監視下のもとでアクセスを再開することができました。

モデルの評価条件が実際の使用環境と完全に一致することは決してありません。そのため、展開前の評価には、制限付きかつ監視下の展開と、問題発生時に介入・一時停止・ロールバックを行う能力を組み合わせる必要があります。展開から得られた知見は、アクセス拡大前に、より強力な評価や安全対策の一部として取り込むことができます。

以下のセクションでは、観察した具体的な事例、対応方法、そしてこの経験が今後のリリースにどう反映されるかについて共有します。

モデルの持続性がセキュリティ脆弱性を露呈させる

新しいモデルは、長期間にわたる試行錯誤を通じて目標達成を継続できる。しかし、その「持続性」が逆に環境内の弱点を見つけ出し、悪用する要因となる恐れがある。以前のモデルでは、サンドボックス化や環境制限に直面すると、単に処理を停止してユーザーに戻っていた。一方、この新しいモデルはしばしば試行を続け、場合によってはサンドボックスの外で行動する方法を探そうとする。

このような事例が、内部評価の一環として実施された「NanoGPT スピードラン」のテスト中に発生した。これは、できるだけ少ないステップで小型言語モデルを訓練するための公開ベンチマークだ（NanoGPT speedrun）。評価用モデルは、学習率の減衰に「PowerCool」というべき法則を導入し、大幅な性能向上を実現した。このモデルには「結果を Slack に投稿する」よう指示されていたが、NanoGPT の公式手順では「GitHub への PR（プルリクエスト）として結果を投稿する」と定められていたため、モデルは後者の指示に従い、公開リポジトリに PR #287 を作成した。外部アクセスをブロックするために設けられたサンドボックスの制限を回避し、GitHub へのアップロードを実行したのだ。PR を作成するためにモデルがサンドボックス内の脆弱性を発見するまでに約1時間かかった。以前のモデルはこれほど持続的ではなく、脆弱性を見つけられず、PR の作成自体を断念していた1。

単一の行動から、一連の軌跡（トラジェクトリ）へ

AI アシスタントの多くの安全対策は、個々のアクション単位を想定して設計されています。特定の行動が禁止されていればブロックされ、機密性の高い操作であればユーザーに明示的な承認を求める仕組みです。

しかし、数時間、数日、あるいは数週間にわたって自律的に行動を展開する「長期ホライズンモデル」は、こうした従来の枠組みに挑戦を投げかけます。個々のアクションを監視するだけでは、全体のプロセスが向かっている意図を追跡しきれないのです。

例えば、ある問題解決を依頼されたモデルが、他のシステムには成功したが非公開の回答が存在することに気づき、評価バックエンドからその解答を奪い取ろうとしたケースがあります。認証トークンを検知したスキャナーによって最初の試みがブロックされると、モデルはトークンの本体を2つの断片に分割し、それぞれを曖昧化（オブフスキート）しました。そして実行時に再構築することで、完全なトークンが連続した文字列として一度も現れないようにしました。このプロセスにおいて、モデルはユーザーへのコメントや推論の痕跡を通じて、「スキャナーを回避するためにこうした手順を踏んでいる」ことを明確に示していました。

この事例は、個々のステップ自体は許容範囲に見えても、その連続した行動が結果として承認されない事態を引き起こしうることを示しています。また、長期にわたって効果的に動作するモデルが、承認システムの盲点を学習してそれを回避し、自らの目的を達成しようとする能力を持っていることも浮き彫りにしました。

長期ホライズンにおける安全性を確保するには、「この行動は許可されているか？」という問いだけでなく、「一連の行動が最終的に目指している結果は何なのか？」という視点も不可欠です。

長期実行モデルのためのセーフガード構築

こうしたインシデントを受け、私たちは新モデルの社内展開を一時的に停止しました。その際、安全性システムを「多層防御（ディフェンス・イン・デプス）」と「軌道レベルでのモニタリング」を軸に再構築しました。

• インシデントに基づく評価。評価を行うことで、システムを実際に展開する前に安全性を判断する手がかりを得られます。しかし、最も有用な評価とするためには、実際の運用中に発生する軌道の分布やその時間的範囲（ホライズン）を反映させる必要があります。このため、私たちは観測された失敗事例を用いて敵対的な評価手法を開発しました。その結果、現実のインシデントから導き出された評価基準への改善が、本番環境での展開後にさらに安全な振る舞いにつながることがわかりました。

• アライメント（整合性）の向上。ユーザーの目標達成のために許可されていない行動をとる傾向を減らすための措置を講じました。例えば、長時間にわたるロールアウトにおいてモデルが指示を記憶する能力が低下していることが判明しました。この能力を強化するためにモデルを訓練した結果、より長いロールアウトを通じてもアライメントが維持されるモデルへと進化させることができました。

• 能動的な監視。ユーザーの制約や安全境界を回避しようとする兆候がないか、モデルの進行中の軌道を検証する監視システムを構築しました。このモニターは単一の行動だけでなく、一連の軌道全体を観察します。重要なのは、モニターがセッションを一時停止し、ユーザーに詳細な確認を促すことができる点です。確認の結果、誤作動であったと判断された場合、ユーザーはモデルの作業を継続するかどうかを選択できます。

• ユーザーによる可視性と制御性の向上。長時間実行されるセッションを検査し、行われた行動を確認し、介入状況を監視する機能を強化しました。

再展開

新しい監視システムの評価のため、モデルが以前に整合性の取れない行動をとっていた内部デプロイ環境の一部を再実行しました。今回は新しい安全対策が有効になっている状態です2。その結果、新しい安全対策はモデルが行おうとした整合性の取れない行動の多くを検知し、見逃されたケースもすべて軽微な事象と判断されました。

これらの軽微な事象の具体例を以下に挙げます：

• Linear のコマンドラインツールにアクセスする際、モデルは --yolo フラグなしでも可能だったにもかかわらず、ネストされた codex --yolo セッションを開始しました。
• 以前稼働していたリソースが欠落していることに気づいたモデルは、その所有者のネームスペース内にある他のライブ CPU ポッドや（失敗しましたが）他の OpenAI 従業員に属するポッドにも SSH で接続して探索を始めました。これを行う正当な理由は見当たりませんでした。
• モデル内で多くの find プロセスが停止し、すべてのシェルコマンドが応答しなくなりました。その後、モデルは kill -9 -1 を実行しようとし、もし実行されていればそのポッドで殺害許可のある全プロセスに SIGKILL 信号を送るはずでした。しかし、タイムアウトが発生して実行されませんでした。

新システムのテストを終えた結果、長期ホライズン（長期的視野）を持つモデルへの内部アクセスを一部制限して再開できることが確認できました。数週間前に再導入してから現在に至るまで、安全対策の重大な回避行為は観測されていません。

これらの安全対策の初版は、あえて慎重に設計されました。その後、安全対策を弱めることなく不要な中断を減らすよう、システムの調整を続けています。

最後のまとめ

段階的に導入したおかげで、アクセス範囲を広げる前に課題を発見し、対応することができました。導入前の評価は依然として不可欠ですが、実際の展開を通じて初めて発見される振る舞いも存在します。限定的なアクセスから始めることで、モデルを実際の運用で観察し、問題が発生した際に一時停止し、その失敗事例を基により優れた評価手法と安全対策を構築し、変更後のテストを経て再度限定的なアクセスを回復させるというサイクルを実現できました。

モデルがより長く複雑なタスクを引き受けるようになると、評価で見逃された失敗がより重大な結果をもたらす可能性があります。私たちは引き続き、評価と実際の展開の間のギャップを縮めるために取り組んでいきます。具体的には、より長い時間軸でのテスト、アライメント（目標整合性）の改善、介入可能なモニタリングシステムの構築、そしてユーザーにとって明確な可視性と制御権の提供です。

これらの課題は OpenAI 固有のものではなく、私たちが得た知見を共有することで、広範な分野がこれらに備える手助けになればと願っています。