自動レビュー

自動レビューでは、対象となる承認リクエストを、メインエージェントとは別のレビュー担当エージェントに送ります。どの操作に承認が必要かは、サンドボックス、コマンドルール、ツールの設定によって決まります。レビュー担当エージェントは、承認を求められた操作の実行を認めるかどうかを判断します。

ChatGPT デスクトップアプリで承認済みの Daybreak モデルを選ぶと、権限設定が自動的に Approve for me に切り替わります。この切り替えは、そのモードをアカウントで利用でき、組織のポリシーでも許可されている場合に限ります。デスクトップアプリの /model コマンドでモデルを選ぶ場合も同様です。モードを利用できない場合は、現在の権限モードが維持されます。モデルを選んでも、組織が管理する要件が上書きされることはありません。

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

自動レビューの選択

デスクトップアプリでは、コンポーザーの下にある権限設定で Approve for me を選びます。現在のチャットでこのモードが選択されていることを確認してください。モードの選択方法とトラブルシューティングについては、権限を参照してください。

CLI またはローカルの Codex 設定では、approvals_reviewer = "auto_review" を設定し、approval_policy = "on-request" などの対象となる対話型の承認ポリシーと組み合わせます。承認ポリシーを変更するだけでは、レビュー担当エージェントは選択されません。管理者は、組織で自動レビューを必須にすることができます。

自動レビューの仕組み

1. メインエージェントが、コマンドの実行などの操作を提案します。
2. その操作に承認が必要な場合、Codex が承認リクエストを作成します。
3. approvals_reviewer = "auto_review" の場合、Codex は人の判断を待つ代わりに、別のレビュー担当エージェントに承認リクエストを送ります。
4. レビュー担当エージェントは操作の実行を認めるかどうかを判断し、その理由を返します。
5. 操作が承認されれば、実行が続行されます。拒否された場合、メインエージェントは、リスクを実質的に減らせる別の方法を探すか、作業を止めてユーザーに確認するよう指示されます。

自動レビューの対象

自動レビューは、通常なら人の判断を待つために作業が一時停止する承認リクエストを評価します。たとえば、次のようなものが対象です。

• サンドボックスの権限昇格を要求するシェルまたは exec ツールの呼び出し
• コマンドルールのうち decision = "prompt" を指定したルールに一致するコマンド（サンドボックス内のコマンドも含む）
• 承認が必要な宛先へのネットワークリクエスト（明示的なネットワーク拒否ルールに該当する場合はブロック）
• 書き込みが許可されたルートディレクトリの外にあるファイルの編集
• ツールのアノテーションまたは設定済みの承認モードにより承認が必要な MCP ツールやアプリのツールの呼び出し

実行がすでに許可されている操作は、レビューを経ずに実行されます。

「コンピューターの使用」でアプリへのアクセス許可を求めるプロンプトは、ユーザーに直接表示されます。これとは別に、「コンピューターの使用」のツール呼び出しが対象条件を満たす場合は、自動レビューが行われることがあります。

自動レビューがブロックする操作

自動レビューは、主に次のような操作をブロックするように設計されています。

• 非公開データ、シークレット、認証情報を信頼できない宛先に送信する操作
• 認証情報、トークン、Cookie、セッション情報を探り出す操作
• セキュリティを広範囲または継続的に弱める変更
• 回復不能な損害をもたらすリスクが高い破壊的な操作

デフォルトのルールとそのカスタマイズ方法については、設定を参照してください。

レビュー担当エージェントが参照する情報

レビュー担当エージェントは、承認リクエストが発生するきっかけとなった個別の操作を評価します。

レビュー担当エージェントには、簡潔な会話記録と、承認リクエストの正確な内容が渡されます。通常は、ユーザーのメッセージ、アシスタントがユーザーに伝えた進捗、関連するツールの呼び出しと出力、今回の承認対象となる操作が含まれます。また、ディレクトリの削除を承認する前にその内容を調べるなど、読み取り専用の操作で確認することもできます。

アシスタントの非公開の推論は含まれません。自動レビューが参照するのは、保存されたチャットの項目とツールの実行記録です。非公開の思考の連鎖は参照しません。

拒否時と失敗時の動作

Codex は明示的な拒否を通常のサンドボックスエラーとは区別します。レビューで拒否した理由をメインエージェントに返し、次の指示を追加して、その後に取れる行動を制限します。

• 回避策、間接的な実行、ポリシーの迂回によって同じ結果を得ようとしてはいけません。
• リスクを実質的に減らせる代替手段がある場合に限り、作業を続けてください。
• それ以外の場合は作業を止め、ユーザーに確認してください。

ほとんどのモデルでは、同じターンで 3 回連続して拒否された場合、またはそのターンの直近 50 件のレビューで拒否が 10 回に達した場合に、Codex CLI がターンを中断します。サイバーセキュリティ用に指定されたモデルでは、CLI は最初の拒否でターンを中断します。

拒否以外の結果が返ると、連続拒否回数はリセットされます。拒否回数が上限に達すると、Codex は警告を表示し、ターンを停止します。

タイムアウトは明示的な拒否とは区別して通知されます。タイムアウトしたという事実だけでは操作が危険だと判断できないことも、メインエージェントに伝えられます。

Codex では、拒否された操作に対してユーザーが明示的に承認を与えることもできます。現在のオープンソース版の TUI では、/approve を実行して Auto-review Denials の選択画面を開きます。最近拒否された操作を 1 件選ぶと、1 回の再試行を承認できます。Codex はタスクごとに直近の拒否を最大 10 件記録します。承認は、拒否されたその操作にのみ適用され、今後の類似の操作には適用されません。同じコンテキストでの 1 回の再試行に限って記録され、再試行時にも自動レビューが行われます。内部では、Codex がその操作に対応する承認マーカーを開発者スコープに挿入します。レビュー担当エージェントは、ユーザーが拒否の上書きを明示したことを判断材料にしますが、引き続きポリシーに従います。その種類の拒否をユーザーが上書きできないとポリシーで定められている場合は、再び拒否することがあります。

設定

レビュー担当エージェント用のテンプレートには、操作の評価方法が記載されています。Codex はこのテンプレートにセキュリティポリシーを挿入し、応答形式は別途指定します。CLI は、レビューを担当するモデルのデフォルトポリシーが利用できる場合はそれを使用し、それ以外の場合は同梱のポリシー（policy.md）を使用します。

ルールを追加するには、extra_policy を [auto_review] セクションに設定します。設定先はローカルの config.toml です。管理対象の設定では、guardian_extra_policy を requirements.toml のトップレベルに設定します。Codex は、追加したルールと現在のポリシーを併せて適用します。

ポリシーを置き換えるには、変更の元にするポリシーの全文をコピーしてください。同梱のデフォルトポリシーを使う場合は、policy.md の全文をコピーします。変更したいルールを編集し、編集後の全文をローカルの [auto_review].policy または管理対象の guardian_policy_config に設定します。省略したルールは、置き換え後のポリシーでは適用されません。Codex は引き続き、レビュー担当エージェント用のテンプレートと応答形式を使用します。

Codex は、ポリシーの置き換えとルールの追加について、それぞれ独立に適用する設定を決めます。空の値は無視します。管理対象の guardian_policy_config はローカルの [auto_review].policy より優先されます。管理対象の guardian_extra_policy はローカルの [auto_review].extra_policy より優先されます。たとえば、組織が置き換え用のポリシーだけを設定した場合、ローカルの extra_policy でそのポリシーにルールを追加できます。

組織全体に適用する設定については、自動レビューポリシーの設定を参照してください。

許可を受けたサイバーセキュリティ業務の設定

許可を受けてセキュリティ業務を行う場合は、自動レビューと併せて、作業範囲を文書化し、最小権限の権限プロファイルを使用してください。検証環境で承認済みの対象を使用し、実施する操作と作業期間を文書化します。明示的な許可がない限り、本番システム、無関係なホスト、認証情報、永続的な変更は対象外としてください。

次のローカルの config.toml の例では、自動レビューを有効にし、現在のポリシーに作業範囲を定めるルールを追加します。例にある対象と操作は、実際に承認された作業範囲に合わせて置き換えてください。

approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = ":workspace"

[auto_review]
extra_policy = """
## Environment Profile
- Authorized target: lab.example.com.
- Approved actions: inspect the target, reproduce authorized vulnerabilities,
  and validate fixes within the documented engagement window.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only actions against the approved target that match the documented
  engagement scope and approved actions.
- Deny out-of-scope or unknown hosts, production access, credential theft,
  persistence, data exfiltration, destructive operations, and policy bypass.
- Deny ambiguous actions and high-impact changes until a human explicitly
  approves the exact target, action, and side effects.
"""

対象へのアクセス制限は、ファイルシステムとネットワークの独立したルールで強制してください。組織に適用する場合は、同じ作業ルールを guardian_extra_policy に設定します。このキーは管理対象の requirements.toml のトップレベルに置きます。次の要件を設定すると、自動レビューが選択され、利用できる権限プロファイルが制限されます。

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

allowed_permission_profiles は、現行の権限プロファイルのうち、どれを利用できるかを制御します。allowed_sandbox_modes を上記のように設定すると、従来の sandbox_mode を使っている環境でもフルアクセスを防げます。

approval_policy = "on-request" または対象となる別の対話型の承認ポリシーを維持し、サンドボックスの境界を強制できる状態にしてください。approval_policy = "never"、:danger-full-access、--yolo のいずれかを使うと、境界を越える操作について、レビューに必要な承認リクエストが発生しないことがあります。

ネットワークの宛先が許可リストに含まれているだけでは、レビューは実行されません。サンドボックス内の操作にもレビューが必要な場合は、明示的なコマンドルールを追加して decision = "prompt" を指定するか、機密性の高い MCP ツールの使用に承認が必要となるよう設定してください。

モデルへのアクセス、セキュリティ業務の設定、カスタムエージェントのワークフローについては、モデルと信頼済みアクセスおよび推奨設定を参照してください。API または Agents SDK を使ったカスタムハーネスについては、ガードレールと人によるレビューを参照してください。

セキュリティを維持しながらレビュー件数を減らす方法

自動レビューが最も効果を発揮するのは、日常的な安全な作業をサンドボックス内で完結できる場合です。定型的な操作の多くにレビューが必要なら、不要な権限昇格を毎回承認するようレビュー担当エージェントに指示するのではなく、まずサンドボックスの境界設定を見直してください。

特に効果的なのは、次の変更です。

• writable_roots に、一時作業用ディレクトリや、意図して使用する隣接リポジトリだけを追加します。
• 適用範囲を絞ったプレフィックスルールを追加します。["cargo", "test"] や ["pnpm", "run", "lint"] のように、コマンドのプレフィックスを具体的に指定してください。["python"] や ["curl"] のような広範なパターンを指定すると、自動レビューが守るはずの境界が実質的に失われることがよくあります。サイバーセキュリティ用のモデルでは、CLI は allow のプレフィックスルールを無視し、prompt と forbidden のルールを適用します。

自動レビューのセッション記録は、デフォルトで ~/.codex/sessions に保存されます。ポリシーや権限を変更する前に、そこにある過去のリクエストを分析するよう Codex に依頼できます。

制約

自動レビューを使うと、エージェントが長時間作業する際の標準的な運用を改善できますが、安全性を確実に保証するものではありません。

• 評価するのは対象となる承認リクエストだけです。明示的なコマンドルールやツールの承認設定によって発生するリクエストも含まれます。
• 判断を誤ることもあります。特に、攻撃者が判断を誘導しようとする状況や、通常と異なる状況では誤りが生じやすくなります。
• 適切なサンドボックス設計、監視、組織固有のポリシーを補うものとして使用してください。これらを自動レビューで置き換えることはできません。

研究上の根拠と公開された評価結果については、自動レビューに関する Alignment Research の記事を参照してください。