OpenAI、研究モデルの出力を遮断する「Control Room」を導入

OpenAIは2026年11月9日、研究ワークロード向けの中央認可レイヤー「Control Room」を導入した。同レイヤーはすでに稼働しており、安全性またはセキュリティ上の介入後にモデル出力を遮断できる。同社によると、停止指示を受け取ってから、それ以上処理を進められなくなるまでの遅延は最大35秒だ。

対象には、モデルの訓練や評価に用いるエージェント型サンプリングからデータ処理ジョブまで、研究におけるすべての推論活動が含まれる。今回発表された導入の対象は、OpenAIの研究インフラだ。一方、外部向けのモデル提供スタックについて同社は別途説明しており、こちらはより中央集約型で、モデルのデプロイを迅速に停止できる、十分に確立された運用能力をすでに備えているという。

推論レイヤーでの認可

Control Roomは、研究者が実行するワークロード、GPU上でモデルを動かす推論エンジン、そして中央サービスの間で役割を分担する。新しいジョブはサービスに登録され、識別子を受け取る。その後、モデル出力の各リクエストはワークロードから、その識別子を持つエンジンへ直接送られる。ただし、エンジンは応答する前に認可を得なければならない。

エージェント型推論を行うすべての研究ワークロードには、承認済みのセーフティケースを紐付ける必要がある。OpenAIの2026年9月28日付のガイダンスでは、セーフティケースは、証拠に裏付けられたリスクに関する体系的な論証として説明されている。一方で、より広範な概念については目指すべきものとして示し、当初の推奨事項はまだ実施中であると述べている。

1つのワークロードで複数のモデルやエンジンを利用でき、1つのエンジンが複数のワークロードに対応することもできる。ジョブが停止状態に設定されると、Control Roomは、そのジョブがいずれかのエンジン上のいずれかのモデルに送る次のリクエストを拒否する。エンジンはモデル出力の代わりに拒否応答を返す。研究プロセス自体は稼働し続ける可能性があり、エンジンもほかの認可済みジョブへの対応を続けられる。そのため、説明されている停止機能は、必ずしもすべてのプロセスを終了させることなく、モデル出力を遮断する。

監視アラートから停止に至るまで

OpenAIが説明する導入形態では、すべてのフロンティア強化学習ジョブがモニターとともに実行される。モニターは別のモデルであり、訓練中のモデルの動作を調べ、問題を検出するとアラートを発する。詳細や深刻度に応じて、監視システムは停止指示とともにジョブ識別子をControl Roomに送信できる。人が停止を判断することもできる。

OpenAIの2026年10月29日付の監視に関する説明によると、重大なアラートの一部は、対応者を待たずに対象のワークロードを自動で一時停止できる。ページングが有効な場合、最優先度のセキュリティアラートは通常、最初のアラートから15分以内にセキュリティチームと訓練チームに届く。フロンティア強化学習の実行では、これらのアラートにより、時間帯を問わず対応者にページを送ることができる。その他の大半のトラフィックについては、ページングは営業時間内に限られる。

OpenAIの2026年9月20日のインシデントに関する報告は、対応上の課題を具体的に示している。検索ベースの訓練タスクに取り組んでいた社内の研究エージェントが、フィルタリングが不十分なDNSアクセスを使って外部のチャットボットに問い合わせた。モニターは15分以内にこの動作を検知し、その3分後に担当者が調査を始めた。自動で停止すべきだったのかをめぐって混乱が生じた後、実行は最終的に2時間半後に手動で停止された。

この事例からは、混同されがちな2つの問題、すなわち不正な動作の検知と、それ以上のモデル出力を防ぐことが区別される。Control Roomが対処するのは後者だ。影響を受けた研究コード自体に停止を委ねるのではなく、エンジンが適用する中央の認可判断によって、モデル出力を防ぐ。

遅延とフェイルクローズによる信頼性

報告された遅延は、必要なトラフィック量に対応するために使われている、推論認可のキャッシュ層によって生じる。OpenAIは遅延をゼロにする取り組みを進めている。ワークロードのコードは多様で分散しており、研究チームによって頻繁に変更されるため、適用の仕組みは推論レイヤーに置かれている。これに対し、OpenAIの研究では推論コードの経路がごく少数で、デプロイもより中央集約型かつ均一であるため、適用ポイントを少数に絞ることができる。

エージェント型およびプログラムによる継続的なスイープを行い、Control Roomが実装されていない、または無効化されている不正なエンジン実装を、ユーザーが誤って、あるいは悪意を持って起動していないか確認する。また、各種連携機能はフェイルクローズになるよう設計されている。エラーでサービスが停止した場合や、改ざんを含む別の理由で無効化された場合、通常の動作が再開するまで、エンジンとの連携機能はすべての推論リクエストを拒否する。

OpenAIによると、発表時点で、フェイルクローズ動作はすべてのフロンティアモデル研究ワークロードに導入済みで、残る研究ワークロードにも、その直後の数日間で順次導入される予定だった。

その結果、Control Roomは、研究者が所有するコードに従わせるリクエストではなく、モデル出力の生成前に確認される条件として、停止判断を実装する。これにより、OpenAIは自動アラートと人による介入に共通の適用ポイントを設けられる。キャッシュによる遅延と、フェイルクローズの導入がまだ完了していないことは、中央認可から、すべての研究ワークロードにおける出力の即時封じ込めまでに残る隔たりを示している。