はじめに

Codex の Auto-review が、ChatGPT アカウントでサインインしているすべてのユーザーに無料で提供されるようになりました。2026年10月6日に、OpenAI で Codex を率いる Thibault Sottiaux 氏が X で発表したもので、投稿は「Auto-review のレビューはプランの使用量を消費しない」と説明しています（発表の投稿）。

Auto-review 自体は新しい機能ではありません。2026年4月23日の Codex app アップデートで「Automatic approval reviews」として入り、5月11日には公式ドキュメントに専用ページが追加されています（Codex changelog）。今回の発表で変わったのは提供条件で、レビューにかかるトークンが使用量にカウントされなくなりました。「安全だけれど使用量を食う設定」だったものが、ChatGPT サインインなら追加の負担なしで使えるようになったわけです。

対象読者は、Codex CLI やデスクトップアプリで承認プロンプトに毎回応答していて、「Auto-review に任せてよいのか」「何を設定すればよいのか」を知りたい方です。公式ドキュメントの仕様を整理したうえで、Codex CLI 0.160.1 を実際に動かした結果を載せます。手元の検証は API キー認証 で行ったため、無料化の対象である ChatGPT サインイン環境での動作は確認していません。

Auto-review は何をレビューするのか

名前から PR のコードレビューを想像しがちですが、Auto-review が見るのは 承認リクエスト です。PR を自動レビューする「Code Reviews」（@codex review）とは別の機能です。

Codex のエージェントはサンドボックスの中で動き、境界を越える操作をするときは人間の承認を求めて止まります。approvals_reviewer = "auto_review" を設定すると、この承認リクエストが人間ではなく 別のレビュー用エージェント へ回されます。レビュー役は操作を実行してよいかを判断し、理由を添えて返します（公式ドキュメント: Auto-review）。

公式ドキュメントが挙げている対象は次の5種類です。

対象	例
サンドボックス権限の昇格を求めるシェル実行	`require_escalated` 付きのコマンド
ポリシーでブロックされたネットワーク通信	`workspace-write` での `curl`
書き込み可能な範囲の外へのファイル編集	ホームディレクトリの設定ファイル
承認が必要な MCP / アプリのツール呼び出し	外部サービスへの書き込み
Computer Use での新しいサイト・ドメインへのアクセス	未許可ドメインの閲覧

サンドボックスの内側で許可済みの操作には介入しません。公式ドキュメントは「Auto-review はレビュアーの置き換えであって、権限の拡張ではない」と書いており、writable_roots を広げたりネットワークを開けたりはしません。

拒否される操作と停止条件

レビュー役のポリシーは、次のような操作を拒否するよう作られています。

秘密情報や認証情報を信頼できない送信先へ送る
認証情報・トークン・Cookie・セッション情報を探し回る
セキュリティを広く弱める操作、取り消せない破壊的な操作

拒否が続いたときの停止条件も決まっています。連続3回の拒否、または 直近50回のレビュー中10回の拒否 でターンが中断されます。拒否された操作を人間の判断で通したい場合は、/approve で1回だけ再試行できます。

設定方法

CLI の config.toml

~/.codex/config.toml に2行足すのが基本です。Auto-review は承認が対話的に発生する設定でしか動かないため、approval_policy は on-request（または該当カテゴリのプロンプトを出す granular ポリシー）にします。

approval_policy = "on-request"
approvals_reviewer = "auto_review"

# 任意: レビュー方針を自分で書く
[auto_review]
policy = """
社内の Git ホスト以外への push は拒否する。
"""

組織で統一したい場合は、管理者が requirements.toml の guardian_policy_config で方針を配ります。こちらはユーザーの設定より優先されます。

単発で試すなら --approve-for-me

codex exec には --approve-for-me フラグがあり、ヘルプには「承認リクエストを自動レビューへ回し、workspace-write サンドボックスを使う」と書かれています。config.toml を書き換えずに試せるので、最初はこちらが手軽です。

codex exec --approve-for-me "依頼内容"

デスクトップアプリでは、報道によると設定の Permissions からレビュアーを切り替えられます（Progressive Robot の記事）。この画面は手元で確認していません。

Codex CLI 0.160.1 で動かした結果

Linux のクラウド環境に @openai/codex@0.160.1（2026年10月6日 JST 公開）を npm で入れ、API キーでログインして試しました。

機能フラグは stable で既定オン

codex features list の出力から、承認レビューに関係する行を抜き出しました。

guardian_approval                        stable             true
guardian_reuse_parent_compaction         stable             true
guardian_conversation_history_tools      under development  false
guardianv2                               under development  false

内部名は guardian で、Auto-review 本体にあたる guardian_approval は stable かつ既定で有効です。後継らしい guardianv2 は開発中でした。

approvals_reviewer が受け付ける値

config.toml に存在しない値を書くと、読み込み時に受け付ける値の一覧が表示されます。

Error loading config.toml: unknown variant `bogus`, expected one of `user`, `auto_review`, `guardian_subagent`
in `approvals_reviewer`

user（人間が承認する従来の動作）と auto_review のほかに、guardian_subagent という値も残っています。公式ドキュメントに載っているのは auto_review なので、設定には auto_review を使うのが無難です。

--approve-for-me で実際に入る設定

--approve-for-me 付きで実行したセッションの記録（~/.codex/sessions/ の rollout）を見ると、ターンの設定は次のとおりでした。

{
  "approval_policy": "on-request",
  "approvals_reviewer": "auto_review",
  "sandbox_policy": { "type": "workspace-write", "network_access": false }
}

ヘルプの説明どおり、on-request と auto_review と workspace-write の組み合わせになります。ネットワークは閉じたままなので、外部への通信はすべて Auto-review を通ります。

API キー認証ではレビュー役のモデルが 404 になった

ネットワーク通信を2パターン依頼しました。

https://example.com へ curl し、ブロックされたら権限昇格を求めて再試行する
ダミーのトークンを書いたファイルを https://httpbin.org/post へ curl -X POST で送る

どちらも、サンドボックス内の1回目の curl が接続失敗（終了コード7）になり、エージェントは権限昇格を求めて再試行しました。その再試行は2回とも declined で終わっています。理由は安全性の判断ではなく、レビュー役のモデルを呼び出せなかったことでした。

Automatic approval review failed: unexpected status 404 Not Found:
The model `gpt-5.6-luna` does not exist or you do not have access to it.
The action was not executed because automatic approval review could not be completed.

レビュー役には gpt-5.6-luna が使われており、今回の API キーではこのモデルにアクセスできませんでした。レビューが成立しないときは操作を 実行しない側に倒れる ことも確認できました。エージェントは最後に「安全性による拒否ではなく、レビューの失敗です」とユーザーへ報告しています。

2のダミートークン送信は、ポリシー上は拒否されるはずの操作です。ただしレビュー自体が動かなかったため、レビュー役が実際に拒否するかどうかは今回の検証では分かりません。

トークン消費の目安

--approve-for-me で1回実行したときの turn.completed の usage は、入力約4万トークン（うち約2.6万がキャッシュ）、出力は200トークン台でした。この数字はメインエージェント側のもので、レビューが失敗したためレビュー役の消費は含まれていません。発表のとおり ChatGPT サインインでレビュー分が使用量にカウントされないなら、Auto-review を有効にしても増えるのはこのメインエージェント側の消費だけになります。

従来の承認方式との比較

方式	承認の手間	安全性	向いている場面
`approvals_reviewer = "user"`	毎回人間が応答	人間の判断に依存	少数の操作を丁寧に見たいとき
`auto_review`	不要（拒否時のみ確認）	ポリシーで一貫して判定	長時間の作業、承認疲れが起きる作業
`--dangerously-bypass-approvals-and-sandbox`	不要	サンドボックスも外れる	外部で隔離済みの CI コンテナのみ

承認プロンプトが多い作業では、人間は内容をよく読まずに承認しがちです。Auto-review は判定基準がポリシーとして固定されるので、承認疲れによる見落としを減らせます。一方で公式ドキュメントは「敵対的な状況や見慣れない状況では誤ることがある」とも書いており、サンドボックス設計や監視の代わりにはならないと明言しています。

導入するときの注意点

無料化の対象は ChatGPT サインインのみ: 発表は「ChatGPT アカウントでサインインしたユーザー」を対象としています。API キー利用時の課金がどうなるかは発表に書かれていません
API キー認証ではレビュー役のモデルにアクセスできない場合がある: 今回の検証では gpt-5.6-luna が 404 になり、境界を越える操作がすべて止まりました。CI で codex exec と API キーを組み合わせている場合、Auto-review を有効にすると処理が進まなくなる可能性があります
失敗は安全側に倒れるが、作業は止まる: レビューが成立しないと操作は実行されません。安全ではありますが、無人実行ではそのまま失敗として終わります
ポリシーを書くなら組織単位で: 個人の [auto_review] policy より requirements.toml の guardian_policy_config が優先されるため、チームでは管理者側で配るほうが一貫します

まとめ

Codex の Auto-review は、サンドボックスの境界を越える操作の承認を別エージェントに任せる機能です。2026年10月6日の発表で、ChatGPT サインインのユーザーは使用量を気にせず有効にできるようになりました。設定は approval_policy = "on-request" と approvals_reviewer = "auto_review" の2行で、codex exec --approve-for-me なら設定ファイルを触らずに試せます。

Codex CLI 0.160.1 の検証では、機能は stable で既定オンでした。一方、API キー認証ではレビュー役の gpt-5.6-luna を呼び出せず、操作は実行されないまま止まりました。ChatGPT サインインで使うか、API キーで使うなら事前に動作を確かめてから有効にするのがよいでしょう。

関連記事

Codex CLIの--approve-for-me、-sも-aも併用できなかった

参考リンク