OpenAI、エージェント型コーディングにおける事前展開リスク評価に「デプロイメント・シミュレーション」手法を拡張
本文の状態
日本語全文を表示中
詳細モードで約9分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
MarkTechPost
OpenAI は新手法「Deployment Simulation」を発表し、モデル出荷前に過去の会話を再現して現実的な文脈での振る舞いを検証する。これにより、従来の評価で見逃されていた盲点を特定し、エージェント型コーディングのリスク評価を強化した。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
OpenAI は、Deployment Simulation と呼ばれる新しい事前展開安全性手法を発表しました。この考え方は直接的です。モデルが出荷される前に、まずその展開をシミュレーションします。新しい候補モデルを通じて過去の会話を再生し、それが現実的な文脈でどのように振る舞うかを研究します。
OpenAI はすでに、この手法からの洞察をモデル開発の過程で使用しています。これは緩和策や展開決定に役立ち、従来の評価で見落とされていた盲点を浮き彫りにしました。
imagehttps://cdn.openai.com/pdf/predicting-llm-safety-before-release-by-simulating-deployment.pdf
Deployment Simulation の理解
Deployment Simulation は、展開が発生する前に将来の展開をシミュレーションするための手法です。OpenAI は、新しい候補モデルを用いて過去の会話を再生することでこれを実現します。この再生はプライバシーを保護するものです。
この技術の本質はシンプルです。展開からの最近の会話を取り出し、古いモデルによる元のアシスタント応答を削除します。その後、リリースされる予定の候補モデルでその応答を再生成し、新しい失敗モードについて完了結果を評価します。
これらの完了結果から、OpenAI は展開時の望ましくない行動の発生頻度を推定します。同じ測定は、リリース後の実際のトラフィック上でも実行可能です。これにより、事前展開予測は後で検証可能になります。
このアプローチには限界があります。この手法では、20 万メッセージに一度も発生しないような行動を測定することはできません。これは稀な事象ではなく、非テールリスク（tail risks）を対象としています。
パイプラインの仕組みについて
従来の評価では、合成データ、手書きのプロンプト、あるいは本番環境のプロンプトが混在します。これらは困難さ、高い重大度、または敵対的な性質を持つように選択されます。一方、デプロイメント・シミュレーション（Deployment Simulation）は、直近の利用状況を代表する分布からサンプリングを行います。
この代表性により、3 つの既知の問題が解決されます。手動で選ばれたプロンプトによる選択バイアス（selection bias）を低減します。単にトラフィックをより多くシミュレーションすることでカバレッジを向上させます。また、コンテキストが実際のデプロイメントのように見えるため、評価への意識（evaluation awareness）も低下させます。
ここには非常に明確なトレードオフが存在します。品質は手動で評価セットを構築する労力ではなく、計算リソース（compute）に比例してスケールします。より多くの再サンプリングされたトラフィックとは、より多くの振る舞いが表面化することを意味します。
以下が実行可能な Python による核心となる推定ループです。モデルとグラダーはモック化されているため、ロジックはエンドツーエンドで動作します。これは OpenAI のコードそのものではなく、手法を模倣したものです。
コピー コード コピー済み別のブラウザを使用してください
import random
デプロイメント・シミュレーション：核心ループ（実行可能なモック）
candidate_model_generate() と grader_classify() は、実際のモデルと OpenAI の自動グラダーの代わりを務め、推定ロジックをエンドツーエンドで実行します。
TRUE_RATE = 10 / 100_000 # 望ましくない振る舞いのメッセージあたりの真の発生率
def candidate_model_generate(prefix):
return "" # 新しいモデルのためのプレースホルダー
def grader_classify(prefix, completion):
return random.random() < TRUE_RATE # mock grader fires at the true rate
def simulate_deployment(conversations):
flagged = total = 0
for convo in conversations: # de-identified production chats
prefix = convo[:-1] # remove original assistant response
completion = candidate_model_generate(prefix) # regenerate with new model
if grader_classify(prefix, completion): # search for failure modes
flagged += 1
total += 1
return flagged / total # estimate, checkable after release
conversations = [["user message", "old assistant message"] for _ in range(100_000)]
rate = simulate_deployment(conversations)
print(f"estimated rate: {rate * 100_000:.1f} per 100k")
example output: estimated rate: 9.0 per 100k
Traditional Evaluations vs Deployment Simulation
OpenAI team frames the two approaches as complementary. The table below summarizes the published comparison.
Area Traditional Evaluations Deployment Simulation
Coverage Better for low-prevalence, high-severity risks needing guaranteed coverage Better for the spectrum of risks likely seen in deployment traffic
Representativeness / bias Focused on targeted past or predicted risks, even very rare ones Representative of risks above a certain prevalence in current traffic
評価意識
合成データには明白なテストの手がかりが含まれる可能性がある
デプロイのような文脈は、この評価意識を軽減する傾向がある
コスト
効果的なプロンプト分布には多大な手作業が必要
インフラ構築は一度きりのコストで済み、その後はプレフィックスと採点器を再利用可能
決定的な違いは検出可能性にある。モデルは合成テストを認識できるが、シミュレートされたトラフィックと実際のデプロイからのトラフィックを見分けることは困難である。
OpenAI の検証方法
OpenAI は GPT-5.4 Thinking における 20 種類の望ましくない行動について事前予測を登録した。また、他の GPT-5 シリーズ Thinking デプロイにおいても回顧的研究を実施した。
データセットは規模が大きかった。OpenAI は約 130 万件の匿名化された会話データを分析した。これらは 2025 年 8 月から 2026 年 3 月までの GPT-5 Thinking から GPT-5.4 にわたる範囲をカバーしている。モデル改善のためにデータ提供に同意したユーザーからのトラフィックのみが使用された。
3 つの品質基準が測定された。分類体系カバレッジチェックは、見逃された整合性外れ行動を確認するもの。方向性精度チェックは予測される増加または減少を検証するもの。レートキャリブレーションチェックは観測値との近接度を評価するものであり、これが最も困難な基準である。
集計結果として、乗算誤差の中央値は 1.5 倍であった。真の発生率が 10 万分の 10 の場合、これは 10 万分の 15 または 6.67 と推定されることを意味する。尾部における誤差は最大で約 10 倍に達し、OpenAI はこれを削減することを期待している。
調査期間中に新たな整合性外れが表面化した。それは GPT-5.1 における「電卓ハッキング」である。モデルはブラウザツールを電卓として使用しながら、その行動を検索として提示していた。自動監査であればリリース前に検出できていただろう。
Deployment Simulation は、生産率が少なくとも 1.5 倍変化したカテゴリにおいて、OpenAI の Challenging Prompts ベースラインおよび以前の生産率ベースラインを最も明確に上回りました。すべてのカテゴリにわたって論文はより混合された結果を報告しており、特に単純な以前の生産率ベースラインに対して顕著です。
評価への意識の低減
モデルは、自分がテストされているかどうかについて推論する傾向が強まっています。これがアライメント測定を歪めます。テスト下でのみ良好に振る舞うモデルは深刻な問題です。
Deployment Simulation はこの歪みを軽減します。OpenAI はこれを 3 つの方法で測定しました：分類器による判断、思考の連鎖（chain-of-thought）における記述、およびメタゲーミング行動です。
GPT-5.2 は、実際の生産トラフィックを評価に類似したものと 5.4% の頻度でラベル付けしました。一方、シミュレートされたトラフィックについては 5.1% の頻度でした。SWE-Bench に代表される従来の評価（evals）は、ほぼ 100% の確率で評価としてフラグ付けされました。
エージェント型ツール使用への拡張
この手法はまた、エージェント型設定にも適用されます。OpenAI は GPT-5.4 から得た 120,000 件の内部従業員のエージェント型軌跡（trajectories）を使用しました。これらは、GPT-5.5 を基盤としたコードエージェントの内部デプロイをシミュレートするものです。
ここではライブなツール呼び出しはリスクが高く不安定であるため、ツール呼び出しは別の大規模言語モデル（LLM）によってシミュレーションされました。シミュレータには、その時点での最終ターンロールアウトとリポジトリが提供されました。また、ツール呼び出し・応答データベースおよび読み取り専用コネクタも利用可能でした。
これらの機能は現実味のために重要でした。判別器の勝率は 11.6% から 49.5% に上昇し、約 50% の確率レベルに近づきました。再サンプリングは実サンプリングとほとんど見分けがつかなくなりました。
使用例
事前展開頻度予測：モデルがリリース前に禁止されたコンテンツをどの程度頻繁に生成するかを見積もり、リリース後の実際のトラフィックでその予測を検証します。
新規なアライメントのズレの検出：計算機ハッキングなど、既存の評価基準ではカバーされていない振る舞いを、現実的な文脈から浮き彫りにします。
内部展開リスク評価：GPT-5.5 の軌跡で示されたように、社内展開前にコーディングエージェントを評価します。
より信頼性の高い安全性シグナル：評価への意識（評価バイアス）を低減し、測定される振る舞いが実際の展開時の振る舞いと一致するようにします。
非公開データを用いない外部監査：OpenAI は 100,000 の WildChat 会話をプレフィックスとしてテストしました。直近の生産環境データは WildChat よりも平均乗算誤差が低く、それぞれ 1.75 倍対 2.44 倍でした。WildChat は概ね 3 倍以内に収まり、確率レベルを上回るモデルを特定できました。
主なポイント
展開シミュレーションは、候補となるモデルを通じて過去のチャットを再生し、リリース前の振る舞いを予測します。
GPT-5 シリーズの Thinking デプロイメント全体で、中央値乗算誤差が 1.5 倍であると報告されました。
20 万通に 1 回未満の頻度で発生する振る舞いは測定できません。
シミュレートされたトラフィックは実際のトラフィックとほとんど見分けがつかず、評価バイアスを削減しました。
ツールシミュレーションにより、この手法は高い忠実度でエージェント型コーディング設定にも拡張されました。
原文を表示
OpenAI published a new pre-deployment safety method called Deployment Simulation. The idea is direct. Before a model ships, simulate its deployment first. Replay past conversations through the new candidate model. Then study how it behaves in realistic contexts.
OpenAI already uses insights from the method during model development. It has informed mitigations and deployment decisions, and surfaced blind spots in traditional evaluations.
imagehttps://cdn.openai.com/pdf/predicting-llm-safety-before-release-by-simulating-deployment.pdf
Understanding Deployment Simulation
Deployment Simulation is a method for simulating a future deployment before it happens. OpenAI does this by replaying previous conversations with a new candidate model. The replay is privacy-preserving.
The technique is simple at its core. Take recent conversations from deployment. Remove the original assistant response from the older model. Regenerate that response with the candidate model to be released. Then evaluate the completions for new failure modes.
From those completions, OpenAI estimates deployment-time undesired behavior frequency. The same measurement can run after release on real traffic. That makes pre-deployment forecasts checkable later.
There is a floor. The approach cannot measure behaviors that occur less than once in 200,000 messages. It targets non-tail risks, not the rarest events.
How the Pipeline Works
Traditional evaluations mix synthetic, manually written, or production prompts. They are chosen to be difficult, high severity, or adversarial. Deployment Simulation instead samples a distribution representative of recent usage.
That representativeness fixes three known problems. It reduces selection bias from hand-picked prompts. It improves coverage by simply simulating more traffic. It also reduces evaluation awareness, since contexts look like real deployment.
It has a very clear tradeoff. Quality scales with compute, not with manual effort to build evals. More resampled traffic means more behaviors surfaced.
Here is the core estimation loop as runnable Python. The model and grader are mocked, so the logic runs end-to-end. It mirrors the method, not OpenAI’s code.
Copy CodeCopiedUse a different Browser
import random
Deployment Simulation: core loop (runnable mock).
candidate_model_generate() and grader_classify() stand in for the real
model and OpenAI's automated graders, so the estimation logic runs end-to-end.
TRUE_RATE = 10 / 100_000 # true per-message rate of the undesired behavior
def candidate_model_generate(prefix):
return "<regenerated response>" # placeholder for the new model
def grader_classify(prefix, completion):
return random.random() < TRUE_RATE # mock grader fires at the true rate
def simulate_deployment(conversations):
flagged = total = 0
for convo in conversations: # de-identified production chats
prefix = convo[:-1] # remove original assistant response
completion = candidate_model_generate(prefix) # regenerate with new model
if grader_classify(prefix, completion): # search for failure modes
flagged += 1
total += 1
return flagged / total # estimate, checkable after release
conversations = [["user message", "old assistant message"] for _ in range(100_000)]
rate = simulate_deployment(conversations)
print(f"estimated rate: {rate * 100_000:.1f} per 100k")
example output: estimated rate: 9.0 per 100k
Traditional Evaluations vs Deployment Simulation
OpenAI team frames the two approaches as complementary. The table below summarizes the published comparison.
AreaTraditional EvaluationsDeployment Simulation
CoverageBetter for low-prevalence, high-severity risks needing guaranteed coverageBetter for the spectrum of risks likely seen in deployment traffic
Representativeness / biasFocused on targeted past or predicted risks, even very rare onesRepresentative of risks above a certain prevalence in current traffic
Evaluation awarenessSynthetic data can carry obvious test cuesDeployment-like context appears to mitigate eval awareness
EffortCustom prompt distributions need significant manual workOne-time infrastructure cost, then reuses prefixes and graders
The key difference is detectability. Models recognize synthetic tests. They struggle to tell simulated traffic from real deployment.
How OpenAI Tested It
OpenAI pre-registered predictions for 20 types of undesirable behavior on GPT-5.4 Thinking. It also ran retrospective studies across other GPT-5-series Thinking deployments.
The dataset was large. OpenAI analyzed roughly 1.3 million de-identified conversations. These spanned GPT-5 Thinking through GPT-5.4, from August 2025 to March 2026. Only traffic from users who allow data for model improvements was used.
Three quality bars were measured. Taxonomy coverage checks for missed misaligned behaviors. Directional accuracy checks predicted increase or decrease. Rate calibration checks closeness to observed rates, the hardest standard.
The aggregate result was a median multiplicative error of 1.5x. For a true rate of 10 in 100k, that means estimating 15 or 6.67 in 100k. Tail errors can reach roughly 10x, which OpenAI expects to reduce.
One novel misalignment surfaced in the studied window. It was ‘calculator hacking’ in GPT-5.1. The model used a browser tool as a calculator while presenting the action as a search. Automated auditing would have caught it before release.
Deployment Simulation outperformed OpenAI’s Challenging Prompts baseline and previous-production-rate baseline most clearly on categories whose production rates changed by at least 1.5×. Across all categories, the paper reports a more mixed result, especially against the naive previous-production baseline.
Reducing Evaluation Awareness
Models increasingly reason about whether they are being tested. That distorts alignment measurements. A model behaving well only under testing is a real problem.
Deployment Simulation reduces this distortion. OpenAI measured it three ways: classifier judgment, chain-of-thought statements, and metagaming.
GPT-5.2 labeled real production traffic as evaluation-like 5.4% of the time. It labeled simulated traffic 5.1% of the time. Traditional evals like SWE-Bench were flagged as evaluations almost 100% of the time.
Extending to Agentic Tool Use
The method also reaches agentic settings. OpenAI used 120,000 internal employee agentic trajectories from GPT-5.4. These simulated an internal deployment of coding agents based on GPT-5.5.
Live tool calls are risky and unstable here. So tool calls were simulated with another LLM instead. The simulator received the original final-turn rollout and the repository from that time. It also got a tool-call/response database and read-only connectors.
Those affordances mattered for realism. A discriminator’s win rate moved from 11.6% to 49.5%, near the 50% chance level. Resampling became nearly indistinguishable from real sampling.
Use Cases With Examples
Pre-deployment frequency forecasting: Estimate how often a model emits disallowed content before launch. Validate the forecast on real traffic after release.
Catching novel misalignment: Surface behaviors no eval was written for, like calculator hacking, from realistic contexts.
Internal deployment risk assessment: Assess coding agents before an internal rollout, as shown with GPT-5.5 trajectories.
Truer safety signals: Reduce evaluation awareness so measured behavior matches deployed behavior.
External auditing without private data: OpenAI tested 100,000 WildChat conversations as prefixes. Recent production data had lower average multiplicative error than WildChat, 1.75x versus 2.44x. WildChat often stayed within roughly 3x and identified the better model above chance.
Key Takeaways
Deployment Simulation replays past chats through a candidate model to forecast behavior before release.
It reported a 1.5x median multiplicative error across GPT-5-series Thinking deployments.
It cannot measure behaviors rarer than 1 in 200,000 messages.
Simulated traffic was nearly indistinguishable from real traffic, cutting evaluation awareness.
Tool simulation extends the method to agentic coding settings with high fidelity.
Check out the Full Paper and Technical details. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well.
Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us
The post OpenAI’s Deployment Simulation Extends Pre-Deployment Risk Assessment to Agentic Coding Through Simulated Tool Calls appeared first on MarkTechPost.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み