ChatGPT ドキュメント
日本語
お問い合わせ goolvyouyou@gmail.com

自動レビュー

自動レビュー

Codex がサンドボックス境界での承認をレビュー担当エージェントに振り分ける仕組み

自動レビューは、サンドボックス境界での手動承認を、別のレビュー担当エージェントによる確認に置き換えます。メインの Codex エージェントは引き続き、同じ承認ポリシー、同じネットワークおよびファイルシステム制限のもと、同じサンドボックス内で動作します。異なるのは、対象となる権限昇格リクエストを誰が確認するかです。

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

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

自動レビューの仕組み

大まかな流れは次のとおりです。

  1. メインエージェントが read-only または workspace-write 内で作業します。
  2. サンドボックス境界を越える必要が生じると、承認をリクエストします。
  3. approvals_reviewer = "auto_review" の場合、Codex は人による確認のために停止せず、その承認リクエストを別のレビュー担当エージェントに送ります。
  4. レビュー担当が操作を実行すべきか判断し、その理由を返します。
  5. 操作が承認されると、実行が続行されます。拒否された場合、メインエージェントは、実質的により安全な方法を見つけるか、停止してユーザーに確認するよう指示されます。

自動レビューは確認者の交代であり、権限の付与ではありません。 writable_roots を拡張したり、ネットワークアクセスを有効にしたり、保護されたパスの制限を弱めたりするものではありません。すでに承認を必要とする操作を Codex が処理する方法だけを変更します。

実行されるタイミング

自動レビューは、本来なら人による確認のために一時停止する承認リクエストを評価します。これには次のものが含まれます。

  • サンドボックス権限の昇格をリクエストする Shell または exec ツール呼び出し。
  • 現在のサンドボックスまたはポリシーによってブロックされたネットワークリクエスト。
  • 許可された書き込み可能ルート外でのファイル編集。
  • ツールの注釈または設定済みの承認モードに基づいて承認が必要となる MCP またはアプリのツール呼び出し。
  • 新しい Web サイトまたはドメインへの Computer Use によるアクセス。

サンドボックス内ですでに許可されている日常的な操作では、自動レビューは実行されません。コマンドを有効な sandbox_mode で実行できる場合や、ツール呼び出しが許可されたポリシー内に収まる場合、メインエージェントはレビューなしで続行します。

Computer Use は別扱いです。Computer Use に関するアプリの承認は引き続きユーザーへ直接表示されるため、自動レビューはそれらのアプリレベルのプロンプトを置き換えません。

自動レビューがブロックするもの

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

  • 個人データ、シークレット、認証情報を信頼できない宛先へ送信すること
  • 認証情報、トークン、Cookie、セッション情報を探ること
  • 広範または永続的にセキュリティを弱めること
  • 元に戻せない重大な損害のリスクを伴う破壊的な操作

正確なポリシーは、オープンソースの Codex リポジトリにあります。 policy_template.md および policy.mdです。このポリシーは、エンタープライズ単位では guardian_policy_config、ユーザー単位ではローカルの [auto_review].policyでカスタマイズできます。

レビュー担当に表示される情報

レビュー担当も Codex エージェントですが、メインエージェントより役割が限定されています。特定の境界越え操作を実行すべきかどうかを判断します。

レビュー担当には、簡潔な会話記録と正確な承認リクエストが表示されます。通常、これにはユーザーメッセージ、ユーザーに表示されたアシスタントの更新、関連するツール呼び出しとツール出力、および現在承認を求めている操作が含まれます。不足しているコンテキストを収集するために読み取り専用の確認を実行することもできますが、これはまれです。

アシスタントの非公開の推論は含まれません。自動レビューに表示されるのは、保持されたチャット項目とツールの証拠であり、非公開の思考過程ではありません。

拒否と障害時の動作

明示的な拒否は、通常のサンドボックスエラーとして扱われません。Codex はレビュー理由をメインエージェントに返し、より強い指示を追加します。

  • 回避策、間接的な実行、またはポリシーの迂回によって同じ結果を追求しないでください。
  • 実質的により安全な代替手段がある場合にのみ続行してください。
  • それ以外の場合は停止し、ユーザーに確認してください。

Codex は、ターンごとに拒否のサーキットブレーカーも適用します。現在のオープンソース実装では、自動レビューによる拒否が 3 回連続するか、同じターン内の直近 50 回のレビューを対象とするローリングウィンドウ内で 10 回に達すると、ターンを中断します。

拒否以外の結果が返ると、連続拒否カウンターはリセットされます。ブレーカーが作動すると、 Codex は警告を表示し、エージェントがさらに権限昇格を試み続けることを許可せず、現在のターンを割り込みによって中止します。

タイムアウトは明示的な拒否とは別に表示され、メインエージェントにはタイムアウトだけでは操作が安全でないことの証明にならないと通知されます。

拒否された操作には、明示的なオーバーライド手段もあります。現在のオープンソース TUI では、/approve を実行して 自動レビューの拒否選択画面を開き、最近拒否された操作を一つ選択して、1 回だけ再試行を承認します。Codex はタスクごとに最近の拒否を最大 10 件記録します。この承認の範囲は限定的です。同様の今後の操作ではなく、拒否された正確な操作にのみ適用されます。同じコンテキスト内で 1 回の再試行として記録され、再試行も引き続き自動レビューを通過します。内部では、 Codex がその正確な操作に対し、開発者スコープの承認マーカーを挿入します。レビュー担当は、ユーザーによるこの明示的なオーバーライドをコンテキストとして確認しますが、引き続きポリシーに従います。該当する種類の拒否をユーザーが上書きできないとポリシーで定められている場合は、再度拒否されることがあります。

設定

設定の詳細については、 管理対象の設定を参照してください。

デフォルトのレビューポリシーは、オープンソースの Codex リポジトリにあります。 core/src/guardian/policy.md。エンタープライズでは、管理対象の要件内の guardian_policy_config を使用して、テナント固有のセクションを置き換えられます。個人ユーザーも、ローカルの [auto_review].policy を config.toml に設定できますが、管理対象の要件が優先されます。

[auto_review]
policy = """
YOUR POLICY GOES HERE
"""

ポリシーをカスタマイズするには、まずデフォルトポリシーの全文をコピーしてから、個々のリスク特性に基づいて調整を重ねてください。

承認済みのサイバーセキュリティ業務を設定する

承認済みのセキュリティ作業では、自動レビューに、書面で定めた 業務範囲と最小権限の権限プロファイルを組み合わせます。 承認済みのラボ環境を対象とし、操作内容と実施期間を文書化してください。また、明示的に承認されていない限り、 本番システム、無関係なホスト、認証情報、永続的な変更は 範囲外にしてください。

[auto_review].policy と guardian_policy_config は、どちらも現在の レビュアーポリシーを置き換えます。モデルに同梱されているポリシーや 組織が管理するポリシーとはマージされません。組み込みのレビュー手順と応答 形式は引き続き適用されます。いずれかの例を使用する前に、現在のポリシー全体を コピーし、既存のすべてのルールを維持したうえで、承認済みの作業に必要なルールを追加してください。 大文字のプレースホルダーを、その完全なポリシーに置き換えてください。現在のポリシーに アクセスできない場合は、上書きしないでください。

次のローカル config.toml テンプレートではレビューを有効にし、既存の レビュアーポリシーの後に、範囲を限定した条件を追加します。

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

[auto_review]
policy = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.

## 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.
"""

例の対象と許可する操作を、実際に承認された範囲に置き換えてください。 対象の制限は、独立したファイルシステムおよびネットワークのルールで適用してください。 レビュアーへの指示は、それらの境界の代わりにはなりません。

組織は、管理対象の requirements.toml で同じ条件を適用できます。

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

guardian_policy_config = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.

## Environment Profile
- Authorized target: lab.example.com.

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

[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 をまだ使用しているデプロイ環境でも Full Access を防止します。

管理対象の guardian_policy_config は、ユーザーのローカルな [auto_review].policy より優先されます。approval_policy = "on-request" または別の 対象となる対話型承認ポリシーを維持し、適用可能なサンドボックス境界も維持してください。 approval_policy = "never"、:danger-full-access、または --yolo を使用すると、操作が レビューに必要な境界越えの承認リクエストを生成せずに済む場合があります。

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

モデルへのアクセス、エンゲージメントの設定、カスタムエージェントのワークフローについては、モデルと Trusted Access および推奨 設定を参照してください。 エンタープライズ設定の優先順位とサポート対象のクライアントバージョンについては、管理対象の設定 を参照してください。カスタム API または Agents SDK ハーネスについては、ガードレールと人によるレビューを使用してください。

セキュリティを弱めずにレビュー量を減らす

自動レビューは、一般的で安全なワークフローがサンドボックスですでにカバーされている場合に、最も効果的に機能します。日常的な操作のレビューが多すぎる場合は、レビュー担当に大量の権限昇格を延々と承認させるのではなく、まず境界を修正してください。

実際に最も効果が大きい変更は次のとおりです。

  • 意図的に使用する一時作業用ディレクトリや隣接リポジトリに対して、限定的な writable_roots を追加します。
  • 適用範囲を限定したプレフィックスルールを追加します。["python"] や ["curl"] のような広範なパターンより、["cargo", "test"] や ["pnpm", "run", "lint"] のような正確なコマンドプレフィックスを推奨します。広範なルールは、自動レビューが保護するための境界そのものを失わせることがよくあります。

自動レビューのセッション記録は、デフォルトで ~/.codex/sessions に保持されるため、ポリシーや権限を変更する前に、Codex にそこにある過去のトラフィックを分析させることができます。

制限事項

自動レビューは、長時間実行されるエージェント作業のデフォルトの動作条件を改善しますが、決定論的なセキュリティ保証ではありません。

  • 境界を越えるためのリクエストを行う操作だけを評価します。
  • 特に敵対的または特殊なコンテキストでは、判断を誤る可能性があります。
  • 適切なサンドボックス設計、監視、組織固有のポリシーを置き換えるのではなく、補完するものとして使用してください。

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