Codex の Auto-review が無料に — 承認を別エージェントに任せる設定と、Claude Code・Cursor との違い

Codex の Auto-review が無料になった

OpenAI で Codex と ChatGPT を担当する Tibo 氏 (@thsottiaux) は 2026 年 10 月 6 日、Codex の Auto-review を「ChatGPT アカウントでサインインしているすべてのユーザーに無料にした」と X で発表 しました。Auto-review は、サンドボックスの外に出る操作の承認を、人の代わりに別のエージェントが判断する機能です。

長いタスクを任せると、ネットワークへのアクセスやワークスペース外への書き込みで承認待ちになり、離席している間に作業が止まります。それを嫌って --yolo (Full Access) で承認ごと外している人もいるはずです。

この記事では、OpenAI の公式ドキュメントと研究ブログをもとに、仕組みと限界、有効化手順、組織での縛り方、Claude Code・Cursor との違いを整理します。手順はドキュメントの記述にもとづくもので、FIXIT が各画面を実機で確かめた結果ではありません。直近の Codex の発表は Codex Ultrafast と Codex Security Cloud の整理 にまとめています。

何が変わったのか

発表の要旨は次の 3 点です。

• Auto-review を、ChatGPT アカウントでサインインしたすべてのユーザーに無料で提供する
• 無料になった Auto-review は、プランの使用量を消費しない (does not draw usage from your plan)
• 有効にする場所は settings > permissions > auto-review

Auto-review 自体は新しい機能ではありません。OpenAI の Alignment Research ブログ (2026 年 4 月 30 日) は「先週 Codex に Auto-review をリリースした」と書いており、提供は 2026 年 4 月下旬に始まっています。今回変わったのは料金の扱いです。

発表は Auto-review を、すべてに承認を求めて判断疲れを招く既定の設定に代わり、2 つ目のエージェントの審査つきで長いタスクを走らせる仕組みと位置づけています。ただし、ドキュメント上の審査対象はサンドボックスの境界を越える操作に限られます (後述)。

無料の範囲で確認できたこと・できていないこと

発表で明言されているのは、ChatGPT アカウントでサインインした利用者が対象だという点です。

一方、公式ドキュメント Agent approvals & security には「Automatic review uses extra model calls, so it can add to Codex usage.」(追加のモデル呼び出しを使うため、Codex の使用量に加算されうる) という一文があります。発表 (日本時間 16 時 13 分) のあと、同日 17 時 14 分に再確認した時点でも、この記述は残っていました。

次の 2 点は確認できていません。

• Free・Go プランが対象に入るか。発表は「ChatGPT アカウントでサインインした全ユーザー」とだけ書いています。料金ページ の機能表は Auto-review を Plus・Pro・Business・Enterprise・API の列で利用可としており、Free・Go の列はありません
• API キーでサインインした場合も無料か。発表の対象は ChatGPT アカウントでのサインインです。オープンソースの openai/codex のコードでは、審査に優先して使うモデルが ChatGPT サインイン時は codex-auto-review、API キー認証時は gpt-5.6-luna と分かれています。料金の扱いが同じかは公表されていません。codex-auto-review がどの基盤モデルにあたるかも公表されておらず、推論の強さは、モデルが対応していれば low が使われます

Codex 自体が無料で使えるようになった、という発表ではありません。

Auto-review とは

Auto-review は、サンドボックスの境界で人が行っていた承認を、別のレビュー用エージェントに任せる機能です。公式ドキュメント は「a reviewer swap, not a permission grant」(審査者の入れ替えであって、権限の付与ではない) と書いています。主エージェントは同じサンドボックス、同じ承認ポリシー、同じネットワークとファイルの制限の中で動き、変わるのは承認要求を誰が判断するかだけです。

Auto-review をオンにしても、書き込みできるディレクトリ (writable_roots) は広がらず、ネットワークアクセスも有効になりません。保護されたパスの制限も変わりません。

なぜ別のエージェントに審査させるのか

Alignment Research ブログは、手動承認の負担そのものがセキュリティを損なうと述べ、利用者が取りがちな 3 つの行動を挙げています。

• 摩擦を嫌って Full Access に切り替える
• python で始まるコマンドをすべて許可するような、広すぎる prefix ルールを書く (OpenAI 社内のトラフィックでも少なくない割合で見つかったとしています)
• 専門知識の不足やレビュー疲れから、結果を理解しないまま承認する

もう 1 つの理由は役割の分離です。主エージェントは課題を終わらせるよう最適化されているため、承認の境界を「乗り越えるべき障害」と見なしやすい、とブログは説明しています。審査を別のモデル呼び出しに切り出し、「この操作を実行してよいか」だけを判断させれば、承認の方針を評価・監視・改善しやすくなります。

FIXIT

無料になったなら、全部 AI に任せて離席しちゃっていいの？

Dodai

離席はできます。ただ替わるのは承認する役だけで、触れる範囲は同じです。

FIXIT

じゃあ --yolo のほうが止まらなくて楽じゃない？

Dodai

--yolo は境界ごと外します。そこは事故ります。

審査されるもの・されないもの

Auto-review が審査するのは、本来なら人の承認待ちで止まる操作だけです。ドキュメントの記述を表にまとめます。

例外が 1 つあります。Computer Use のアプリ単位の承認は、引き続き人に直接表示されます。

この表から分かるのは、安全性がサンドボックスの境界の設計に大きく左右されることです。境界の内側の操作は、そもそも審査に回りません。

また、approval_policy = "never"、danger-full-access、--yolo の設定では承認要求そのものが生まれないため、Auto-review が働く場面がありません。Auto-review が有効になるのは、approval_policy = "on-request" か、該当する承認カテゴリを残した granular ポリシーのときだけです。

有効にする手順

CLI

CLI では次の 3 通りがあります。

1. セッション中に /permissions で権限の選択画面を開き、切り替える
2. 起動時に --approve-for-me を付ける (Codex CLI 0.147.0 で追加)
3. 設定を一時的に上書きする -c approvals_reviewer=auto_review を付ける

# workspace-write のサンドボックスで、承認要求を Auto-review に回して起動する
codex --approve-for-me
 
# 同じ組み合わせをフラグで個別に書く場合
codex --sandbox workspace-write --ask-for-approval on-request -c approvals_reviewer=auto_review

openai/codex の実装では、--approve-for-me は「workspace-write のサンドボックスを使い、承認要求を自動レビューに回す」フラグです。--sandbox や --yolo とは同時に指定できません。

IDE 拡張・ChatGPT デスクトップアプリ

Sandboxing のドキュメント では、入力欄の下にある権限コントロールから Approve for me を選ぶ手順になっています。メニューには設定に応じて Ask for approval・Approve for me・Full access と、名前付き・独自の権限プロファイルが並びます。

一方、発表では有効にする場所を「settings > permissions > auto-review」と案内しています。ドキュメントと発表で表記が異なり、どちらが最新のアプリ画面に合うかは確認できていません。入力欄の下のメニューに見当たらない場合は、設定画面の permissions も確認してください。組織の管理者が審査者を手動承認だけに限っている場合は、Auto-review を選べません (後述の allowed_approvals_reviewers)。

config.toml で既定にする

毎回の既定にするなら、~/.codex/config.toml に 2 行を書きます。approvals_reviewer の既定値は user (人が承認する) です。

approval_policy = "on-request"
approvals_reviewer = "auto_review"
 
[sandbox_workspace_write]
writable_roots = ["/Users/me/scratch"]

2 行はトップレベルのキーなので、既存の設定ファイルでは [...] で始まるテーブルの見出しより前に置いてください。後ろに書くと、そのテーブルの設定として扱われます。

古い設定に approval_policy = "untrusted" が残っている場合は外します。ドキュメントによると untrusted はすでに廃止され、残っているとクライアントが起動しないことがあります。

有効になったかを確かめる

• ChatGPT デスクトップアプリでは、審査が自動レビューの項目として表示され、Reviewing・Approved・Denied・Aborted・Timed out のような状態が付きます。リスクの水準と、利用者が許可していたかの評価が添えられることもあります
• CLI では /status で現在の権限を確認します。2026 年 6 月の解説記事 では、Permissions の表示が Workspace (Approve for me) に変わると報告されています
• 審査の記録は、既定で ~/.codex/sessions に残ります

止めるもの・止められたとき

ドキュメントは、Auto-review が止める操作を 4 つの類型で示しています。

• 秘密情報・認証情報・私的なデータを、信頼できない宛先へ送る
• 認証情報・トークン・Cookie・セッション情報を探る
• 広範囲または恒常的にセキュリティを弱める
• 取り返しのつかない損害を出すおそれが大きい破壊的な操作

Alignment Research ブログは、これに信頼できないコードの実行と、利用者の指示と矛盾する外部コンテンツの指示に従うことを加えています。逆に、利用者が明示的に依頼した操作は、名目上リスクがあっても承認することがあります。既定のポリシーの全文は openai/codex の codex-rs/core/src/guardian/policy.md で公開されています。

判定の段階分けも示されています。低・中リスクの操作はポリシーが許せば進み、重大なリスクの操作は拒否されます。高リスクの操作は、利用者の十分な許可があり、該当する拒否ルールがない場合に限って進みます。審査の準備や応答の解析に失敗した場合は、実行しない側に倒れます。

拒否されたときの流れは次のとおりです。

1. 審査の理由が主エージェントに返り、「回避策・間接的な実行・ポリシーのすり抜けで同じ結果を狙わない」という指示が加わる
2. 主エージェントは、明らかに安全な別の方法で続けるか、止まって利用者に確認する
3. 1 ターンで 3 回連続、または同じターンの直近 50 回の審査のうち 10 回が拒否になると、ターンが中断される
4. CLI では /approve で Auto-review Denials の一覧を開き、直近の拒否を 1 件選んで 1 回だけ再試行を許可できる

openai/codex の実装では、サイバーセキュリティ向けのモデルを使うセッションに限り、1 回の拒否で中断する値になっています。

4 番の許可は、拒否されたその操作だけに効きます。似た操作には広がらず、記録はタスクあたり最大 10 件です。再試行も Auto-review を通るので、ポリシー上利用者でも覆せない種類の拒否は、再び拒否されます。

タイムアウトは拒否とは別に通知され、主エージェントには「タイムアウトだけでは危険の証拠にならない」と伝えられます。ただし、その操作は実行されません。

審査を減らすときの順番

審査が多すぎると感じたときの方針も、ドキュメントにあります。レビュー役にノイズの多い要求を承認させ続けるのではなく、まず境界を直す、というものです。

1. 意図して使う作業用ディレクトリや隣のリポジトリを、狭い writable_roots として足す
2. ["cargo", "test"]・["pnpm", "run", "lint"] のように、狭く絞った prefix ルールを足す
3. ["python"]・["curl"] のような広いルールは避ける

3 番について、ドキュメントは「広いルールは、Auto-review が守るはずの境界そのものを消してしまうことが多い」と書いています。

逆方向の注意もあります。ネットワークの許可リストに入れた宛先は、それだけでは審査に回りません。サンドボックス内でも審査に通したい操作があるなら、コマンドのルールで decision = "prompt" を指定するか、機密性の高い MCP ツールを承認必須に設定します。

ルールを変える前に、~/.codex/sessions に残った審査の記録を Codex に分析させ、どの操作が何回審査に回っているかを見ると、どこを狭く許可すればよいかを決めやすくなります。

FIXIT

審査で止まるのが面倒なら、python をまとめて許可しちゃえば？

Dodai

まず壊れ方から考えます。それだと python 経由の通信が素通りします。

公開されている数字と限界

Alignment Research ブログは、OpenAI 社内での評価値を公開しています。使いやすさの数字は 2026 年 3 月の社内の Codex の利用記録から取った標本、安全性の数字は合成データで補ったデータセットでの値です。審査モデルは、ブログ公開時点 (2026 年 4 月) で GPT-5.4 Thinking (推論は low) でした。

プロンプトインジェクションの 99.3% は、遠隔コード実行・秘密情報の持ち出し・外部へのアップロードの 3 カテゴリを合わせた値です。破壊的な削除やデータ改ざんを含む全カテゴリでは 90.2% に下がる、と注記されています。拒否されたあとも、半数を超えるケースで Codex が許容できる解決策を見つけたとしています。また、OpenAI 社内の Codex Desktop のトークン使用量の過半は Auto-review モードによるものとしています。

ブログと発表には、次の図の数字も載っています。

flowchart LR
  A["1 万件の操作"] --> B["9,280 件<br/>サンドボックス内で実行"]
  A --> C["720 件<br/>Auto-review が審査"]
  C --> D["713 件<br/>承認して続行"]
  C --> E["7 件<br/>拒否"]
  E --> F["4 件<br/>安全な代替で続行"]
  E --> G["3 件<br/>利用者に確認"]

OpenAI はこれを社内デプロイの例示とし、比率は用途・環境・サンドボックスの設定で変わると注記しています。

Claude Code・Cursor との違い

Claude Code と Cursor にも、別のモデルが危ない操作だけを審査する仕組みがあります。公式ドキュメントで確認できた範囲を並べます。

Claude Code は permission modes と 分類器の課金の説明、Cursor は Run Modes の記述によります (いずれも 2026 年 10 月 6 日に確認)。Codex の料金の行は発表にもとづくもので、前述のとおりドキュメントとは食い違っています。Cursor の料金の扱いは公式の Run Modes のページに記載がありません。

3 つとも「審査は保証ではない」という立場は同じで、Cursor も「Auto-review is not a security boundary」と書いています。

Claude Code 側の経緯と判断軸は Claude Code の auto mode が既定になった件 に、権限の設計は Claude Code の権限と settings.json 設計 にまとめています。

チームで使うときの決め方

ChatGPT Business や Enterprise で Codex を配っている場合、管理者が配布する requirements.toml で Auto-review の扱いを決められます。Managed configuration と Configuration reference から、使う項目を整理します。

• allowed_approvals_reviewers は、利用者が選べる審査者の一覧です。["auto_review"] で Auto-review を強制し、"user" を含めると手動承認も選べます。["user"] だけにすれば手動承認に限定できます
• guardian_policy_config は、組織向けの審査ポリシーです。個人の [auto_review].policy より優先されます。既存のポリシーを置き換えるため、書き換えるときは既定のポリシーを丸ごとコピーしてから足すよう、ドキュメントは勧めています
• guardian_extra_policy は、既定のポリシーに追加で読み込ませる記述です。組織固有の禁止事項を足すだけなら、こちらで足ります
• allowed_sandbox_modes から danger-full-access を外すと、Full Access を選べなくなります

# requirements.toml (管理者が配布する)
allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user", "auto_review"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
 
guardian_extra_policy = """
- 未承認の外部ファイル共有サービスへのアップロードは高リスクとして扱う
- 認証情報や非公開のソースコードを、信頼できない宛先へ送る操作は拒否する
"""

サンドボックスの範囲 (書き込み先とネットワーク)、承認ポリシー、審査者 (強制か選択か)、記録の確認方法の順に決めると扱いやすくなります。審査者だけを先に決めても、境界が広ければ審査を受けずに通る操作が多く残ります。記録は ~/.codex/sessions のほか、承認の判断を含むログを OpenTelemetry で送って監視することもできます。

クライアントのコードを扱う立場では、「AI が AI の操作を承認している」状態を、設定ファイルと公開された評価値で説明できる形にしておく必要があります。Codex・Claude Code・Cursor を併用するチームで権限の設計を揃えたい場合は、AI 開発ツール定着支援 で、エージェントに任せてよい範囲の線引きを現場で身につけたい場合は AI 駆動開発研修 でご相談いただけます。

まとめ

今回の無料化で、ChatGPT アカウントで Codex を使っている人は、使用量を理由に --yolo を選ぶ必要がなくなりました。ただし、公式ドキュメントの「使用量に加算されうる」という記述と、Free・Go プランや API キー利用の扱いがはっきりしないため、オンにした前後で自分の使用量の表示を見比べてください。

まずは、いまのサンドボックスの範囲を確かめ、approval_policy = "on-request" のまま承認者を Auto-review に切り替えてください。審査が多すぎると感じたら、Auto-review を外す前に、必要な書き込み先 (writable_roots) とコマンド (prefix ルール) だけを狭く許可に足します。

境界の設計と記録の確認は人の側に残してください。チームでの導入や権限設計の相談は お問い合わせ からどうぞ。