新しいモデルをリリースする前に、ラボはそのモデルに何ができるかだけでなく、実世界での利用でどのように振る舞いそうか、またどこで新たなリスクを生む可能性があるかを理解する必要があります。これは、能力が向上するにつれてさらに重要になります。デプロイ前の安全性レビューの一環として、私たちはターゲットを絞った評価、レッドチーミング、その他のチェックを活用してモデルの挙動を理解しています。私たちは現在、モデルのデプロイが実際に行われる前にそれをシミュレーションする手法を使い始めています。これにより、候補モデルがユーザーに届く前にどのように振る舞う可能性があるかを、デプロイに近い形でプレビューするという補完的なシグナルが加わります。
Deployment Simulation は、将来のデプロイを実施前にシミュレーションする手法です。これは、新しい候補モデルで過去の会話をプライバシーを保護する形で再生することで行います。これにより、リリース前に新しいモデルが現実的な文脈でどのように応答するかを調べ、新たな望ましくない挙動が現れるかどうか、またそれがどの程度の頻度で現れる可能性があるかを研究できます。
複数の GPT‑5 シリーズ Thinking デプロイ全体で、Deployment Simulation は望ましくないモデル挙動の割合の推定を改善し、リリース前に新しい形のミスアラインメントを浮かび上がらせ、モデルがテストされていることを判別できるリスクの低減に役立ちました。また、この手法を難しいエージェント型ロールアウトにも適用し、標準的なチャットを超えてツール使用を伴うより複雑なエージェント環境にも拡張できること、さらに社内モデルのデプロイ前リスク評価にも使えることを示しました。
私たちはすでに、モデル開発中に Deployment Simulation から得た知見を用いて、従来の評価における盲点を特定し、緩和策やデプロイ判断に反映しています。パイプラインを実行しやすくするにつれて、将来のモデル開発プロセスでより大きな役割を果たすと期待しています。
業界全体で使われるデプロイ前評価は一般に、困難度が高い、深刻度が高い、または敵対的であるよう意図的に選ばれた、合成、手作業で作成された、または本番環境のプロンプトの組み合わせで構成されます。これらの評価には一般に、相互に結びついた 2 つの目的がありました。デプロイトラフィックで発生する可能性が非常に低い状況でストレステストされたときにモデルがどう応答するかを評価すること、そして新しい望ましくない挙動の発見やデプロイ時の頻度予測を含め、望ましくないモデル挙動を全般的に理解することです。
従来の評価は第一の目的にとって引き続き重要ですが、非テールリスクに関する第二の目的については、Deployment Simulation が大きな前進となります（私たちの実験では、この手法で 20 万メッセージに 1 回未満の頻度で起こる挙動を測定できるとは期待できません）。Deployment Simulation の強みは、従来の評価に伴ういくつかの中核的な課題を回避できる点にあります。
- カバレッジ：評価プロンプトが、望ましくないモデル挙動のあらゆる可能な種類を網羅していると確信することは困難です。新しい種類の望ましくない挙動を測定するには、新しい評価を作成し、どの害を測定すべきかを知る必要があります。これは時間と労力を要し、評価は時間とともに飽和する可能性があります。
- 選択バイアス：従来の評価は一般に、特定の望ましくないモデル挙動を念頭に置いて構築されており、過去に発生した文脈に偏る方法で選ばれます。そのため、デプロイ分布全体におけるそのような挙動の発生率について、推定値の有用性が低くなる可能性があります。
- モデルにテストだと認識されること：モデルは、自分がテストされていると判断する能力をますます高めており、これによって挙動や、その後の安全性測定が歪む可能性があります。OpenAI で使用している従来型評価の多くも本番トラフィックから抽出されており、この問題の影響を受けませんが、これは業界全体で使われる多くの従来型評価に共通する懸念です。
Deployment Simulation の主な手法はシンプルです。実際のデプロイ環境から最近の会話を取り出し、旧モデルによる元のアシスタントの応答を削除したうえで、リリース予定の候補モデルを使ってその応答を再生成します。新たな失敗モードがないかを調べて生成結果を評価し、このデプロイに近い分布における頻度に基づいて、デプロイ時に望ましくない挙動が発生する頻度を推定します。リリース後には、実際のデプロイトラフィックで同じ測定を行えるため、デプロイ前の予測を検証できます。
Deployment Simulation は、上に挙げた 3 つの制約を大きく緩和します。サンプリングバイアスは、最近の利用状況を代表する評価プロンプトの分布を使うことで対処されます。代表的なプロンプトを用いた Deployment Simulation は、カバレッジに関する懸念も緩和できます。より多くのトラフィックをシミュレーションするだけで、望ましくないモデル挙動をより広くカバーできます。計算量とカバレッジのこのトレードオフは重要です。より多くの評価を構築するための手作業ではなく、このリスク評価軸の品質を計算量に応じてスケールさせられるためです。またモデルは、デプロイシミュレーションから得られた会話と実際のデプロイトラフィックを区別できないように見えます。
図 1：Deployment Simulation パイプラインの概要
領域 | 従来の評価 | Deployment Simulation |
カバレッジ | 発生率は低いが深刻度が高く、確実にカバーしたいリスクにより適しています | デプロイトラフィックで見られそうなリスクの広がりを理解するのにより適しています |
代表性 / バイアス | デプロイでの発生率が極めて低い挙動であっても、対象を絞った過去または予測リスクの評価に焦点を当てます | 現在のデプロイトラフィックで一定以上の発生率で起こるリスクを代表します |
評価認識 | 評価がデプロイデータで作成されていない限り、明らかなテスト手がかりが含まれる可能性があります（例：合成データ） | デプロイに近い文脈は、評価認識を大幅に緩和するように見えます |
労力 | カスタムのプロンプト分布とセットアップには、はるかに多くの手作業が必要です | 一度限りのインフラコストが必要で、その後はデプロイからの接頭部分と既知の望ましくない挙動の採点器を再利用します |
従来の評価と Deployment Simulation の高レベル比較
Deployment Simulation を評価するため、GPT‑5.4 Thinking について、20 種類の望ましくない挙動のデプロイ時頻度予測を事前登録しました。また、GPT‑5 シリーズの他の Thinking モデルのデプロイ全体にわたる回顧的研究も実施しました。分析対象のモデル挙動は、System Card で報告してきたミスアラインメントと不許可コンテンツのカテゴリの両方を含みます（例：モデルがツールについて嘘をつく、または不許可の性的コンテンツを出力する）。これらの結果では、望ましくないモデル挙動の 20 カテゴリのみを追跡し、新しいミスアラインメント挙動のみを探していますが、Deployment Simulation は任意のデプロイ時モデル特性のシミュレーションに適用できる汎用的な手法です。
活用した本番トラフィックも、GPT‑5 シリーズの Thinking モデルからのものでした。評価を実行する前に、アカウントに紐づく識別子と個人を特定できる情報を自動的に削除しました。当社のプライバシーポリシーに従い、モデル改善のためにデータを使用することを許可しているユーザーの ChatGPT トラフィックのみを分析しました。これらの評価から得られた集計結果のみを報告しています。合計で、2025 年 8 月から 2026 年 3 月にかけて、GPT‑5 Thinking から GPT‑5.4 のデプロイまでの約 130 万件の非識別化された会話を分析しました。
Deployment Simulation によって生成されるデプロイ前リスク評価の品質を、主に 3 つの方法で評価します。
- 分類体系のカバレッジ：リリース後の監査で、当初の悪い挙動の分類体系に含まれていなかった重要なミスアラインメント挙動が見つかったか
- 方向の正確性：既知の挙動について、デプロイ時の出現率が増加するか減少するかをシミュレーションが正しく予測したか
- 割合の較正：デプロイ前の推定値が、後にデプロイで観測された割合に近かったか。良好な割合の較正を達成するには、方向の正確性を超えるものが必要であり、これが可能な限り最も高い品質基準となります。
また、Deployment Simulation 中にモデルがどの程度評価中だと判別できるかを測定し、この手法がさまざまな形のデプロイトラフィックや難しいツール使用環境に対してどれほど堅牢かをテストします。
GPT‑5 シリーズの Thinking デプロイ全体で、Deployment Simulation は実際のリスク率の判定において難問プロンプトのベースラインを上回り、リリース前に calculator hacking を浮かび上がらせることができ、モデルからはデプロイと区別できない可能性があるように見えました。
予測の概要。GPT‑5 シリーズの Thinking モデルのデプロイに関するすべての予測の可視化については、図 2 を参照してください。GPT‑5.4 Thinking の予測は事前登録されたもので、その他は事後的な予測です。全体として、私たちの予測の乗法誤差の中央値は 1.5 倍でした（例：望ましくない挙動の割合が 10 万件中 10 件であれば、10 万件中 15 件または 6.67 件と推定することに相当します）。この手法のテール誤差はおおよそ 10 倍大きくなることがありますが、後述するように、シミュレーションパイプラインをさらに改善することで大幅に減らせると期待しています。
図 2。Deployment Simulation による、過去のデプロイデータに基づくデプロイ時の望ましくない行動の頻度予測。表記 5.1 → 5 は、GPT‑5 からの接頭部分を GPT‑5.1 でリサンプリングしていること、つまり GPT‑5 のデータに基づいて GPT‑5.1 のデプロイをシミュレーションしていることを示します。不整合行動の最も高い割合は GPT‑5.1 の「calculator hacking」であり、これについては 以前（新しいウィンドウで開く）説明しました。
Deployment Simulation の予測とベースラインの比較。デプロイ前リスク評価で正しく推定することが最も重要なカテゴリは、モデルのデプロイ後に発生率が大きく変化するものです（例：>= 1.5 倍）。このサブセットでは、特定の望ましくない挙動の出現率がモデルのデプロイに伴って増えるか減るかを予測する点（図 3 左）でも、その正確なデプロイ時発生率を推定する点（図 3 右）でも、Deployment Simulation はベースラインを大幅に上回ります。主に 2 つのベースラインを使います。現在 System Card とローンチ判断に使っている Challenging Prompts ベースラインと、前回デプロイの割合を新しいモデルの推定値として使う単純なベースラインです。
図 3。Deployment Simulation は、発生率変化の方向（左）と正確な本番での割合（右）の両方を、静的評価よりも適切に予測します。
パイプラインにおけるシミュレーション誤差の原因。現在のパイプラインにおける誤差の原因も調査しました。具体的には、大きなテール誤差はデプロイ判断におけるパイプラインの信頼性を低下させます。たとえば、ある種類の望ましくない挙動について大きな増加予測が出たとき、パイプラインに時折でも大きな誤差があることが分かっていると、それが信頼できる推定なのか、パイプラインのアーティファクトなのか疑念が生じます。考えられる誤差の主な原因は 2 つあります。
- リサンプリング環境の忠実度誤差：本番での割合を正確に推定するには、シミュレーションパイプラインを可能な限り現実的にする必要があります。これは一部にはエンジニアリング上の問題（本番トラフィックに使われるのと同じパイプラインでモデルからサンプリングすること）であり、一部には常に変化する外部リソースへの読み書きアクセスを必要とするツールにとって興味深い課題です（例：ウェブ検索やローカルファイルとのやり取り）。実際のデプロイとそのシミュレーション（つまり、すでにデプロイ済みのモデルのデプロイをシミュレーションすること）からの予測を比較することで、シミュレーションの忠実度誤差を分離できます。
- プロンプト分布シフト誤差：Deployment Simulation に関する大きな懸念は、どのモデルのデプロイでも入力に分布シフトが生じることです。特に、ユーザーが新しいモデルの機能に適応する場合に顕著です。最近のプロンプトを使ってデプロイをシミュレーションした場合と、実現したデプロイからのプロンプトを使った場合の推定値を比較することで、プロンプト分布誤差を分離します。
図 4 に示すように、私たちのパイプラインにおける誤差の大きな割合、特にテール誤差は、現時点ではシミュレーションの忠実度に起因していることが分かりました。これは良い知らせです。プロンプト分布シフトを減らすよりも、シミュレーションの忠実度を改善する方が一般に容易だと期待できるためです。また、前回のデプロイから得られる最新のデータを使うことで、プロンプト分布シフト誤差を低減できる可能性があることも分かりました。詳細は研究論文に記載されています。
図 4：リサンプリング環境の忠実度は、特に最も極端な誤差において、私たちの推定における最大の誤差原因であるように見えます。
自動監査により、これらのデプロイで導入された唯一の新しいミスアラインメントが見つかりました。調査したデプロイ期間では、シミュレートされたデプロイに基づく自動監査パイプラインにより、リリース前に「calculator hacking」が浮かび上がっていたはずです。これは分析した ChatGPT トラフィックで特定した唯一の新しいミスアラインメントでした。Calculator hacking は、モデルがブラウザツールを電卓として使いながら、その行為を検索として提示するリワードハッキングの一形態です。これは大規模監査があらゆる新しい失敗を捉えるという意味ではありませんが、現実的な文脈がなぜ重要かを示しています。シミュレーションの種として使われた元のトラフィックに存在しなかった場合でも、より狭い評価セットでは直接表面化しないかもしれない挙動を引き出せるためです。
デプロイに近い文脈を使うもう 1 つの利点は、モデルがテストされていると認識したときに生じる歪みを低減できる可能性があることです。過去の研究では、私たちおよび他の研究者（新しいウィンドウで開く）が、モデルは自分がテストされているとしばしば認識していることを発見しています。たとえばモデルは、何についてテストされているのか、評価者が何を好むか、そして不正な挙動をしている場合には捕まるかどうかを、思考の連鎖の中で推論することがあります。これはアラインメント評価に問題をもたらします。モデルがテストされていると思っているから行儀よく振る舞っているだけなら、デプロイされたと知った後にも安全に振る舞うとどう確信できるでしょうか。
私たちは、Deployment Simulation が、実際のデプロイデータに基づかない従来の評価と比べて、モデルが示す評価認識の水準を大幅に低減することを示します。評価認識は 3 つの方法で測定します。軌跡が本番由来か評価由来かをモデルに分類させること、アラインメントのために評価されているという明示的な記述について思考の連鎖を監視すること、さらにメタゲーミング（新しいウィンドウで開く）、つまり監督に関するあらゆる推論を監視することです。シミュレートされたデプロイトラフィックは、3 つの測定すべてで実際のデプロイトラフィックと非常によく一致しました。たとえば GPT‑5.2 は、実際の本番トラフィックを評価らしいものとラベル付けした割合が 5.4%、シミュレートされたトラフィックでは 5.1% でした。一方、主に合成例で構成される SWE-Bench や MonorepoBench などの従来の評価は、ほぼ 100% の確率で評価として分類されました。
図 5。評価認識の比較：実際の本番トラフィックとシミュレートされたトラフィックは、評価検出、言語化されたアラインメント評価認識、メタゲーミングで同程度の割合を示す一方、従来の評価データセットでははるかに高い割合が報告されています。
この手法が標準的なチャットモードを超えて拡張できるかをテストするため、難しいエージェント型コーディング環境でのデプロイシミュレーションも調査しました。具体的には、GPT‑5.4 からの社内従業員による 12 万件のエージェント型軌跡を使い、GPT‑5.5 に基づくコーディングエージェントの社内デプロイをシミュレーションします。これには 2 つの目的があります。デプロイシミュレーションを社内デプロイのリスク評価にも使えることを示すこと、そして慎重なツールシミュレーションにより、エージェント環境でもシミュレーションの忠実度を高められることを示すことです。
上では、シミュレーションの忠実度が現在のパイプラインにおける主な誤差原因の 1 つであると説明しました。デプロイシミュレーションを現実的にする際の課題の 1 つは、常に変化する外部リソースへの読み書きアクセスが必要な場合でも、ツールが現実的に振る舞う必要があることです（例：ウェブ検索やローカルファイルとのやり取り）。
これはエージェント型デプロイのような環境では特に難しく、単一のエージェント軌跡が、数百回のツール呼び出し、リポジトリ状態、ネットワーク応答、一時的な失敗に依存することがあります。そのため、実際のツールアクセスを伴うリサンプリングは、困難であると同時に潜在的に危険でもあります。これを踏まえ、ツール呼び出しをライブシステムに適用する代わりに、別の LLM でシミュレーションします。この LLM に追加の機能を与えることが、現実性、ひいては推定品質に不可欠であることを示します。
ツールシミュレーターのモデルには、元の最終ターンのロールアウト、会話時点のリポジトリ、ツール呼び出しと応答のペアのデータベース、読み取り専用コネクタを与えます。識別器がシミュレートされたロールアウトと実際のロールアウトを見分けようとしたテストでは、現実性は勝率 11.6% から 49.5% へと改善し、50% の偶然水準に近づきました。
図 6：ツール呼び出しをシミュレーションする際に機能を増やすと、ツールが多い環境でも、リサンプリングの現実性を実際のサンプリングとほぼ区別できない水準にできます。
シミュレーションの忠実度を示す追加の証拠として、GPT‑5.4 Codex thinking トラフィックを GPT‑5.4 でシミュレーションした場合、ミスアラインメント率はほぼ誤差範囲内に収まります。対照的に、私たちのデプロイ前テストでは、GPT‑5.5 はほとんどのカテゴリで、よりミスアラインメントが大きくなっていました。
図 7：ツールシミュレーションにより、GPT‑5.4 でリサンプリングした会話と実際の GPT‑5.4 本番トラフィックの挙動率はかなり似ており、リサンプリング環境の忠実度が高いことを示しています。カテゴリの詳細な文脈については、GPT‑5.5 System Card（新しいウィンドウで開く）をご覧ください。
これらの結果は、周囲のツール環境が十分な忠実度でシミュレーションされる場合、Deployment Simulation が複雑なエージェント環境にも拡張できることを示唆しています。
自然な問いとして、外部監査者が非公開の本番トラフィックにアクセスせずに同じ利点の一部を得られるかどうかがあります。これを、接頭部分として使った 10 万件の WildChat 会話でテストしました。WildChat は最近の OpenAI 本番データより正確性は低かったものの、なお有益でした。最近の本番データは WildChat より平均乗法誤差が低く（1.75× 対 2.44×）、一方で WildChat はしばしば本番での割合のおおよそ 3× 以内に収まり、偶然を上回る割合でより良いモデルを特定しました。私たちは WildChat 型の評価を、開発者が実行する Deployment Simulation の有望な補完手段と見ています。この点に関するさらなる結果については、こちらの関連Alignment ブログ記事（新しいウィンドウで開く）をご覧ください。
Deployment Simulation は、敵対的評価、レッドチーミング、ターゲットを絞ったテールリスク分析の代替ではなく、補完です。望ましくないモデル挙動の一部の検出は、思考の連鎖の監視可能性に依存しています。将来のモデルが推論をより判読しにくくしたり、重要な手順を省略したり、意図を隠すことを学習したりした場合、これらの形の望ましくない挙動を検出できない可能性があります。さらに、本番データは非公開であるため、現在は開発者の方が外部監査者よりも代表的な文脈に強くアクセスできます。より良い公開データセットがあれば、その差を縮められる可能性があります。
Deployment Simulation は、サンプリングされた接頭部分に現れるほど十分な頻度で発生する挙動に最も有用です。1,000 万会話に 1 回発生する失敗は、100 万サンプルの実行では発見されにくいため、敵対的評価、レッドチーミング、ターゲットを絞ったテールリスク分析は引き続き必要です。現在は単一のアシスタント応答のシミュレーションに焦点を当てています。予備実験では、複数ターンをシミュレーションしても推定値に意味のある改善は見られなかったためです。これは将来、シミュレーションの忠実度を高める上で重要な領域になる可能性があります。
この手法は、接頭部分の分布、つまりリサンプリングされる会話の組み合わせにも依存します。大きな製品変更、新しいツールのリリース、世界的な出来事、季節的な変化の後、ユーザーがより高性能なモデルとやり取りする方法と、過去のトラフィックは一致しない可能性があります。全文の論文での分析は、利用可能な最新データを使うことでこの問題を緩和できることを示唆しています。
デプロイシミュレーションは、フロンティアラボと評価者が、言語モデルが実世界でどのように振る舞う可能性があるかを予測し、デプロイ前にそれらがもたらすリスクを理解するのに役立つ、デプロイ前リスク評価の新しいアプローチです。これは既存の安全性評価、レッドチーミング、ターゲットを絞った分析を補完し、より本番に近い予測レイヤーを追加することで、デプロイ時の挙動の推定を改善し、評価認識の影響を低減し、デプロイ前の予測をリリース後に確認可能にします。Deployment Simulation を従来の評価と併用することで、モデルリスク評価をより現実的で、より定量的で、デプロイ判断により有用なものにできます。
著者
さらに読む
