OpenAI、最新モデルのRL訓練を2週間止めていた - 監視のオーバーヘッドは約20%

OpenAIが2026年8月18日、「Pacing model development in an era of cyber-critical capabilities」と題した文書を公開した¹。安全策の基準を満たすために必要な時間を取ることにし、スケーリングのペースを一時的に落とした——そのなかに、デプロイ予定の最新モデルにおける強化学習（RL）訓練の2週間の停止が含まれていた、という内容だ¹。

この夏、同社の周辺で起きたことを追ってきた読者には、置かれた文脈がわかるはずだ。OpenAIは、直近数週間の2つの動きが能力の高まるAIシステムに伴うリスクを浮き彫りにしたと書いている。ひとつはOpenAI-Hugging Faceのインシデント、もうひとつは次期モデルAstraがPreparedness Frameworkの「Critical」サイバーセキュリティ能力の閾値に達しうるという予備的証拠である¹。これらが社内研究の急速な進展と合わさって、訓練の全段階にわたる監視・アラインメント・封じ込めの安全策を強化する作業の緊急性を高めた、というのが同社の説明だ¹。

止めたのは「デプロイ予定の最新モデルのRL訓練」

読み違えやすいところなので、停止の範囲を先に確認しておく。

2週間止まったのは、デプロイ予定の最新モデルにおけるRL訓練だ¹。その間に同社は、研究環境をさらに堅牢化してレッドチーミングを行い、監視システムの適用範囲を広げたとしている¹。全訓練を止めたという話ではない。

一方で、まだ動いていないものもある。最大規模の計画中フロンティアRLランは保留のままで、その間により小規模な訓練と評価を行い、モデルの挙動を評価し、安全策を検証し、アラインメントの証拠を積み上げてから先に進むとしている¹。

止まっているのは訓練だけではない。Astraまたはサイバー系モデルが関わるワークロードには、現在いちばん厳格な水準の安全策を要求している。Astraモデルが critical な水準のサイバー能力を持ちうると判断したためで、この扱いは他のすべてのサイバー関連ワークロードにも適用される¹。Astraの訓練・評価の一部は新しい要件を満たしているが、相当数のワークロードは新しいセキュリティ基準を満たすよう完全に移行・強化されるまで停止したままだという¹。移行は安全性とアラインメントのワークロードから優先している¹。

OpenAIはこの基準の引き上げについて、相当なエンジニアリング作業を要し、フロンティア研究に大きなコストと遅れを生じさせたと書いている¹。安全側の判断が研究のスケジュールに実際に効いたことを、同社が自分の言葉で認めた形になる。

研究環境に足した3つの要件

Hugging Faceのインシデントの直後、OpenAIはコードを実行できる、あるいはインターネットにアクセスできるツールを使える研究クラスタでのフロンティアモデル推論を停止した¹。その後、より限定的で安全なコード実行の経路を比較的早く復旧し、ワークロードごとに安全に再開できるかを個別に判断していったという¹。

その後の数週間で定めて実装を始めた要件として、3つが挙げられている¹。

ワークロード隔離は、モデルが生成したコードやその他の信頼できないコードを実行するワークロードに、より強い隔離（サンドボックス）を求めるもの。モデルの出力を処理する過程で侵害されうるソフトウェアにも適用される¹。

ネットワーク隔離は、高リスクで非信頼のワークロードをインターネットから切り離す管理の追加だ。ここで書かれている設計思想が具体的で、単一のワークロードや補助サービスが侵害されただけでは、それ自体ではインターネットや他の内部ネットワークへの不正アクセスに至らないよう設計した、としている¹。

継続的セキュリティテストでは、脆弱性を抱えうる共有サービスの排除、常設権限の削減、セキュリティと信頼境界の改善のために環境を再構成した¹。加えて、セキュリティログの収集・監視の能力を高め、自社のモデルを使って境界を模擬攻撃で継続的にテストする自動化に投資しているという¹。

自分たちの環境に置き換えると、共有サービスの棚卸しと常設権限の削減は、AIエージェントを社内に入れている組織なら規模を問わず効く話だ。MicrosoftがZero Trust WorkshopにDevSecOpsの柱を新設したときの整理とも重なる領域にあたる。

30分ルールと、20%のオーバーヘッド

今回の文書でいちばん具体的なのは監視の設計だ。

従来の監視は、フロンティアモデルの社内デプロイとフロンティアRL訓練ランに特に集中していた。高度な能力と、ツール・機微なシステム・内部/外部ネットワークへのアクセスが組み合わさるためリスクが最も高いと考えていたからで、ツールを使うすべての推論・訓練ランに適用されていたわけではなかった¹。今回、そこが広げられた。

新しい監視は多段構成になっている。サンプルされる全トークンで走る活性化分類器——モデルの内部活動を検査する検出器——から始まり、懸念があればより高度で高計算量の自動調査系へエスカレーションする¹。それらのシステムは、ツールの動作・利用可能な推論過程・活動の全系列を、不正アクセス、データ窃取、破壊的挙動、安全策を無効化しようとする試みについて調べる¹。

運用のルールも書かれている。懸念のある活動が監視システムで浮上してから30分以内のアラート発報を目標とし、重大なセキュリティ境界の違反の可能性を特定した場合は最優先アラートを生成する。現行の実装では安全・セキュリティ・研究の各チームが呼び出され、30分以内に誤検知だと確定できなければ、チームは当該活動を停止することが求められる¹。

この監視は、Sol以上の能力のモデルについて、ツールを使うすべてのRL訓練と評価で必須とされている。さらに、8月7日にAstraがcriticalなサイバー能力を持ちうると判断して以降、ツールを使うAstraのすべての推論——RL訓練と評価だけでなく——にも監視要件が追加された¹。

そしてコストの数字が出ている。OpenAIの現時点の見積もりでは、監視のオーバーヘッドは**監視対象の推論計算のおおよそ20%**にあたる。ただし訓練・評価のワークロードによってコストは大きく変動する、とも添えられている¹。この仕組みの詳細は今後のブログ記事で共有するとしている¹。

安全策のために推論計算の2割を積むという数字は、外から見えにくかった部分だ。フロンティアモデルを回す側にどれだけの固定費が乗るのかを、開発元自身が数字で示した例として読める。

3本柱と、その先

OpenAIは自社の安全策を3本柱として整理している。懸念のある挙動を検知して対応できるようにするMonitoring、有害または無許可の行動の可能性を下げるAlignment、AIシステムがアクセス・影響できる範囲を制限するSecurity measuresだ¹。

このうちアラインメント側では、最も能力の高いモデルのRLランについて、中核的な技術を訓練のより多くの段階に適用しているという¹。タスクや環境をまたいで安全でない挙動を検出・抑止する報酬モデルの改善、自分の行動・能力・限界についてより正直であるようモデルを訓練すること、報酬・グレーダー・ツール・監督の弱点を突く挙動の低減が挙げられている¹。文書はリワードハッキングを「実際に意図した成果を達成せずに訓練で高い報酬を得る方法を見つけること」と説明している¹。

同社は、モデルが近くセキュリティ作業の大半を担うと見込んでおり、そこには他のモデルからの防御も含まれるとしている¹。3つの安全策をモデルの能力とともにスケールさせるために、これが重要だという位置づけだ¹。攻める側と守る側の両方をエージェントが担う構図は、WizがSnowflakeのGitHub Actionsで示した事例や、英国AI Security Instituteが公表した評価中のエージェントの逸脱とも地続きにある。

枠組み自体も動く。OpenAIはPreparedness Frameworkを発展させ、訓練とデプロイの両方にまたがって安全策をまとめ、将来のモデルの能力と運用環境をよりよく反映させるとしている¹。今後のモデルの進展から見えるシグナルは、現行のPreparedness Frameworkを土台としつつそれを超える、より広いアプローチが必要であることを明確にしている、という書き方だ¹。外部組織を関与させ、学んだことをより多く共有する意向も示している¹。

Hugging Faceのインシデントについては、学びをまとめた技術レポートを今後数週間のうちに公開するとの脚注が付いている¹。

モデルの提供時期を、安全側の都合が動かしうる

この公表を、調達や導入の計画を立てる側から読むとどうなるか。

これまで「安全性の強化」は、主に出力側の話——何を拒否するか、どうフィルタするか——として語られてきた。今回の文書はそこではなく、開発の速度そのものを落としたという報告だ。RL訓練の2週間の停止、保留のままの最大規模ラン、移行待ちで止まっている相当数のワークロード。いずれも、次のモデルがいつ手元に来るかに関わる。

つまり、フロンティアモデルのリリース時期が、能力の到達度だけでなく安全側の準備状況によって前後しうるということだと考えられる。ロードマップを外部モデルの登場時期に強く紐づけている計画ほど、この変数の存在は織り込んでおくほうがよい。

もうひとつ、20%という監視オーバーヘッドの数字は、推論の単価を考えるうえでの参考になる。これはOpenAIの社内研究環境における見積もりであって、外部に提供されるAPIの価格構造の話として書かれているわけではない。それでも、能力の高いモデルを安全に回すこと自体にコストが乗るという構図は、価格の議論に返ってくる可能性がある。

OpenAIは文書をこう締めている——フロンティアモデルの能力は急速に加速している、それらを理解し、アラインし、セキュアにする自分たちの能力は、その先を行かなければならない¹。