Codex Auto-reviewの仕組み──サンドボックス境界越えの承認を別レビュアーに任せる

Codexが「サンドボックスの外に出る」操作を求めるたびに人間が承認ボタンを押す運用は、Goal modeのような長時間タスクとは相性が悪い。OpenAI公式ドキュメントによると、Auto-reviewはこの承認作業そのものを「省略する」のではなく、別のCodexエージェント（レビュアー）に判断を委譲するという設計になっている。この記事は公式ドキュメント原文だけを根拠に、何が起きているのかを具体的に整理する。

• Auto-reviewは権限そのものを広げるのではなく、境界越えの承認リクエストの審査役を人間から別のCodexエージェントに切り替える仕組み。writable_rootsが広がったりネットワークアクセスが有効化されたりすることはない
• 拒否は「1ターン内で連続3回」または「直近50件中10回」でターンを強制中断するサーキットブレーカーが組まれており、拒否されたアクションは/approveから1件だけ1回限りの再試行が可能
• 設定キーはapprovals_reviewer（既定値はuser、auto_reviewに切り替えるとレビュアーサブエージェントを使う）で、組織管理者はallowed_approvals_reviewersを["auto_review"]だけに絞ることで、全ユーザーに自動レビューを強制できる

サンドボックスは変わらない、判断する主体が変わるだけ

公式ドキュメントが最初に明記しているのは、Auto-reviewが「権限の付与」ではなく「レビュアーの入れ替え」だという点だ。メインのCodexエージェントは、Auto-reviewが有効でも無効でも同じサンドボックス・同じ承認ポリシー・同じネットワーク／ファイルシステム制限の中で動く。writable_rootsが広がることも、ネットワークアクセスが有効化されることも、保護パスが緩むこともない。変わるのは「境界越えのリクエストを誰が審査するか」だけだ。

Auto-reviewが機能するのは承認が対話的なとき、つまりapproval_policy = "on-request"のとき（または該当するプロンプトカテゴリを表示する粒度の承認ポリシー）に限られる。approval_policy = "never"ではそもそもレビューする対象が存在しない。

動作の流れ

公式ドキュメントが示す流れは次の5段階。

1. メインエージェントがread-onlyまたはworkspace-writeの範囲内で作業する
2. サンドボックス境界を越える必要が生じ、承認をリクエストする
3. approvals_reviewer = "auto_review"が設定されていれば、その承認リクエストは人間ではなく別のレビュアーエージェントに回される
4. レビュアーが実行可否を判断し、根拠を添えて返す
5. 承認されれば実行を継続。拒否された場合、メインエージェントは「より安全な代替手段を探すか、停止してユーザーに確認する」よう指示される

Auto-reviewが評価するのは、シェル・実行ツールが昇格権限を要求する場合、サンドボックス・ポリシーでブロックされたネットワークリクエスト、書き込み許可範囲外へのファイル編集、承認が必要なMCP／アプリのツール呼び出し、新しいドメインへのComputer Useアクセスなど。すでにサンドボックス内で許可されているルーティン操作にはAuto-reviewは介入しない。なお、Computer Use自体の承認は人間に直接表示される別枠で、Auto-reviewはこれを置き換えない。

レビュアーが見えるもの・見えないもの

レビュアーは「本体より狭い仕事」を持つ別のCodexエージェントだと明記されている。見えるのは、コンパクトな会話履歴と、実際の承認リクエストそのもの——ユーザーのメッセージ、表示済みのアシスタント更新、関連するツール呼び出しと出力、そして今まさに承認を求めているアクション。必要なら読み取り専用のチェックを自分で行うこともあるが、頻度は低いとされる。非表示のアシスタント推論(chain-of-thought)はレビュアーには渡されない。

拒否されたときの挙動：サーキットブレーカー

拒否は通常のサンドボックスエラーとは異なる扱いを受ける。Codexはレビュアーの判断理由をメインエージェントに返し、次のように強く指示する——同じ結果を回避策や間接的な実行、ポリシーの迂回で狙わないこと。より安全な代替手段がなければ停止してユーザーに聞くこと。

さらに、公式ドキュメントは具体的な数値を伴う「拒否サーキットブレーカー」を明記している。オープンソース実装では、1ターン内で連続3回の拒否、または直近50件のレビューのうち10回の拒否のいずれかに達すると、Codexはそのターンを警告付きで中断する。拒否以外の判定（承認など）が返ると、連続拒否カウンターはリセットされる。またタイムアウトは明示的な拒否とは別に扱われ、「タイムアウトだけでは、そのアクションが安全でないことの証明にはならない」とメインエージェントに伝えられる。

拒否には明示的な上書き経路もある。現行のオープンソースTUIでは/approveを実行すると「Auto-review Denials」ピッカーが開き、直近の拒否済みアクションから1件を選んで1回だけ再試行を承認できる。この上書きは狭い範囲に限定される——対象は完全に同一のアクションのみ、同一コンテキスト内で1回の再試行として記録される、そして再試行も通常どおりAuto-reviewを通る。Codexは直近10件までの拒否を記録する。

設定キーで見る、サンドボックスとAuto-reviewの役割分担

公式ドキュメント「Sandboxing」によると、サンドボックス自体とAuto-reviewは別のレイヤーの制御だ。「サンドボックスは技術的な境界を定義し、承認ポリシーはその境界を越える前にエージェントを止めて確認を求めるかどうかを決める」と明記されている。Config referenceページで確認できた、関係する設定キーを整理する。

approvals_reviewerの既定値はuser、つまりAuto-reviewは自分で明示的に有効化しないと動かない。企業アカウントでは、管理者がallowed_approvals_reviewersを["auto_review"]だけに絞ることで、ユーザー側の選択肢をなくし、組織全体にAuto-reviewを義務付けることもできる。

Daybreakモデル選択時の自動切り替え

Auto-reviewのページには、この記事の他の節では触れていないもう1つの挙動が書かれている。ChatGPTデスクトップアプリで、承認済みのDaybreakモデル(セキュリティ研究向けモデル)を選択すると、アカウントと組織ポリシーがそのモードに対応している場合、権限コントロールが自動的に「Approve for me」(Auto-review相当)に切り替わる。/modelコマンドでモデルを切り替えた場合も同様の挙動になる。対応していないアカウント・組織ポリシーの場合は、現在の権限モードのまま変わらない。

また、承認済みのセキュリティモデルで「Full Access」を有効にする前には、危険な操作についてのモデル固有の警告がデスクトップアプリに表示され、その警告は「Approve for meを使うことを推奨」しレビュアーポリシー設定へのリンクを示す、と明記されている。ただしこの警告自体はサンドボックスの境界を復元したり組織ポリシーを上書きしたりするものではない、とも明記されている。

ポリシーはオープンソースで公開されている

Auto-reviewが何をブロックするよう設計されているかは、公式ドキュメントに大枠が書かれている——機密データ・シークレット・認証情報の信頼できない宛先への送信、認証情報・トークン・Cookie・セッション情報の探索、広範囲または恒久的なセキュリティの弱体化、取り返しのつかない重大なリスクを伴う破壊的操作。

正確なポリシー本文はCodexのオープンソースリポジトリで公開されており（policy_template.mdとpolicy.md）、エンタープライズはguardian_policy_configで、個人ユーザーはconfig.tomlの[auto_review].policyでテナント固有の部分を差し替えられる。公式ドキュメントは「カスタマイズする際は、まず完全な既定ポリシー全文をコピーしてから追記すること」と注意している。

限界：これは決定論的なセキュリティ保証ではない

Auto-review自身のドキュメントが「Limits」として明記している点は重要だ。Auto-reviewは長時間稼働のエージェント作業における既定の運用ラインを改善するものであって、決定論的なセキュリティ保証ではない。境界を越えようとするアクションしか評価しない。敵対的・非定型な文脈では誤判定もありうる。サンドボックス設計・監視・組織固有のポリシーを補完するものであり、代替するものではない。

判定精度・誤検知率は公式ドキュメントでは確認できず

限界を先に書く。

実際の判定精度・誤検知率。 公式ドキュメントは「研究の根拠と評価結果」をAlignment Research公式ブログの別記事に案内しているが、本記事ではその評価結果そのものまでは確認していない。

エンタープライズ向けguardian_policy_configの詳細な優先順位。 「Managed configuration」という別ページに詳細があるとされているが、本記事では深掘りしていない。

サンドボックスの実装差（macOS/Linux/Windows）による影響。 Auto-reviewの判断そのものより、その前提となるサンドボックス強制の実装差（Seatbelt／bubblewrap／Windows sandboxing）は、本記事の範囲では扱っていない。

policy.md本文そのもの。 公式ドキュメントがリンクしているオープンソースのpolicy_template.md・policy.mdは、実際にGitHub上のそのパスを直接取得しようと試みたが、404で取得できなかった(リポジトリ内でパスが変わっている可能性がある)。そのため、この記事の「Auto-reviewが何をブロックするか」の記述は、公式ドキュメントページ側の要約に基づくものであり、ポリシーファイルの原文そのものは確認できていない。

関連記事

• CodexのGoal Modeが実験段階を終えた
• AGENTS.mdだけでは危ない──Codex Permission Profilesの仕組み
• Claude Computer Useで事故を防ぐには──公式ドキュメントが挙げる4つの対策