OpenAIが研究中のAIを止める「Control Room」　最大35秒で推論を拒む

米OpenAIは11月9日、自社の公式ブログでControl Roomの仕組みを公表した。研究インフラで動くモデルのワークロードを一元的に追跡し、安全上の懸念があれば止めるシステムで、停止の判断から最大35秒でモデルの出力を止める。

答えは単純だ。推論エンジンがリクエストのたびにジョブのIDをControl Roomに照会し、停止済みのジョブには出力を返さない。フロンティアモデルの研究ワークロードでは、Control Room自体が落ちた時に全ての推論を拒む。社内でエージェントのジョブを回すチームにとって、止める処理をどこに置くかの手本になる。

止めるまで最大35秒

ブログによると、Control Roomはワークロード、推論エンジン、Control Roomのサービスの3つで動く。ワークロードは強化学習の実験、評価、大量のサンプリング、データ処理などのジョブを指す。エージェントとして推論するワークロードには、承認済みの「セーフティケース」（安全だと言える根拠をまとめた文書）を必ず紐付けさせている。

流れは3段だ。ジョブを始める時に、ワークロードのコードがControl Roomから新しいjob_idを受け取る。モデルにトークンを出させるたびに、そのjob_idを付けて推論エンジンに頼み、エンジンはControl Roomに許可を問う。ジョブが止められていれば、Control Roomは拒否し、エンジンは拒否の応答を返す。

ブログの図は、研究者がジョブを始める所からエンジンが拒否を返す所までを13段のステップで追う。最後のステップは、研究用のプロセスが動き続けても、そのジョブにモデルの出力はもう出ないことを示している。

止める指示を出すのは監視の仕組みだ。ブログによると、フロンティアモデルの強化学習のジョブは全て「モニター」（学習中のモデルの動きを見張る別のモデル）付きで動く。監視の仕組みは、問題の中身と重さに応じて止めると決めた時に、job_idを付けて停止をControl Roomに送る。同社が10月29日に出した監視の仕組みの記事は、最優先のアラートが通常15分以内に人に届くこと、一部の重大なアラートでは自動で一時停止することを書いている。監視の対象は、GPT-6 Astraと同等以上のモデルの全ての強化学習と評価と、社内のCodexの全トラフィックだという。30分以内に懸念を解消できない時に一時停止する対策も進めている。

止める処理を推論の層に置いた理由も、ブログは説明している。ワークロードのコードは研究者ごとにばらばらで頻繁に変わるため、安全の要には向かない。推論のコードの経路は社内でごく少数で、デプロイも集約されている。Control Roomを外したエンジンが動いていないかは、エージェントとプログラムで続けて点検しているという。

Control Roomが停止の指示を受けてから、ジョブがそれ以上進めなくなるまでの最大の時間が35秒だ。

35秒の中身と測り方

35秒の遅れの原因について、ブログは推論の認可のキャッシュ層だと説明する。大量の通信をさばくために置いた層だという。

35秒が数えるのは、Control Roomが停止の指示を受けた時からだ。監視が問題に気づき、止めると決めるまでの時間は含まない。判断から指示が届くまでの時間も資料に無い。監視の記事が書く「最優先のアラートは通常15分以内に人に届く」とは別の区間になる。

ただし、35秒をどう測ったかは資料に記載がない。試した回数、ジョブの種類、分布や平均、何を「進めなくなった」とみなしたかも書かれていない。つまり、35秒は上限の値で、普段の遅れがどれほどかは分からない。

遅れの解消と全面導入はこれから

限界は同社自身が書いている。35秒の遅れは残っており、同社はこれを0にする作業を進めている。Control Roomが落ちた時に全ての推論を拒む「フェイルクローズ」は、フロンティアモデルの研究ワークロードには入ったが、残りの研究ワークロードには「数日のうちに」入れるとしている。推論を拒むのは、Control Roomが通常の動作に戻るまでの間だ。

対象も研究インフラに限られる。外部に提供するモデルの基盤は、もともと集約されていて、すぐに止める運用があるという。

どれも同社が自社の仕組みについて書いた説明で、第三者の検証は示されていない。

手元のエージェントで止め方を試す

自分のエージェントのジョブで試すなら、まず全てのモデルの呼び出しが通る1か所を決める。ブログの考え方に沿うと、それはジョブのコードではなく、モデルを呼ぶ共通の層になる。

次に、ジョブごとにIDを振り、その層がリクエストのたびに停止の印を確かめるようにする。停止の印を確かめる先が応答しない時に、呼び出しを通すか拒むかも決めておく。Control Roomは拒む側を選んだ。ブログの図の最後のステップのとおり、拒否された後も研究用のプロセスは動き続け得る。手元でも、プロセスを止めることと、モデルの出力を止めることを分けて設計する。

最後に、止める指示を出してから最後の出力が出るまでの時間を測る。同社の35秒は、認可のキャッシュ層から来ていた。共通の層を通らずにモデルを呼ぶ経路が無いかも、Control Roomと同じく続けて点検する。

編集部の見方

編集部が注目したのは、止める処理の置き場所だ。ジョブのコードは書き手ごとに変わるが、モデルを呼ぶ層は少数だ。そこに置けば、1か所の変更で全てのジョブに効く。

Control Roomの遅れを示す数字は35秒の上限だけで、測り方は書かれていない。同社の別の報告によると、9月に起きたDNSを使って外部のチャットボットに届いた件では、人が3分以内にアラートを見たのに、ジョブは想定どおりに自動では止まらず、手で止めたのは2時間半後だった。ブログはこの件を監視が捉えた例として挙げるが、止める経路との関係は書いていない。作る前に「止めて測る」手順を決めたい。