Codex権限と自動レビューの確認ポイント、安全な使い方

Codex権限自動レビューが混同される理由

Codexがファイルを読んだり編集したり、テストを実行したりすると、画面には「許可された」「確認が必要だった」という結果が現れます。この結果だけを見ると、作業範囲を決める仕組みと、確認を出す仕組みが一つの権限スイッチに見えます。しかし、実際には二つの軸があります。サンドボックスは、エージェントが触れてよいファイル、書き込み可能な場所、通信の可否を決める境界です。承認ポリシーは、その境界の内側で処理できる操作と、外側へ出る前に止める操作を分けます。自動レビューは三つ目の軸であり、承認が必要になったときに人が判断するのか、別のレビュアーが判断するのかを選ぶものです。

この三つを混ぜると、「自動レビューを選べばプロジェクト外にも書ける」「確認を減らすために全アクセスへ切り替える」といった誤解が生まれます。公式文書は、サンドボックスと承認は別の制御であり、自動レビューは許可の追加ではないと説明しています。設定を変える前に、どの操作を許したいのか、どの場所を守りたいのか、誰が判断するのかを一つずつ言葉にすると、変更の影響を小さくできます。

サンドボックスは作業範囲を決める

サンドボックスは、Codexが実行するコマンドだけでなく、そのコマンドから起動されるテストランナーやパッケージ管理ツールにも及びます。現在のワークスペースだけに書き込みを許す設定なら、作業の途中で別のフォルダーへ保存しようとしても、その要求は境界を越える操作として扱われます。ネットワークも同じで、通常のローカル確認は通せても、外部サイトへ接続する場面では別の判断が必要になります。境界を狭く保つことは、Codexの能力を否定することではなく、変更の影響範囲を読める大きさに保つ方法です。

承認ポリシーは止まる条件を決める

承認ポリシーは、毎回確認するか、境界を越えるときだけ確認するか、確認を挟まずに進めるかを決めます。on-request は、許可された範囲の作業を進め、追加の権限が必要になったときに止まる考え方です。untrusted はより慎重に、信頼できる操作以外を確認へ回します。never は確認を出さずに進める設定なので、境界と書き込み範囲を広くしたまま使うと、見落とした変更を止める機会まで失います。確認回数を減らす目的だけで、ポリシーを最も強い値へ変更するのは避けるべきです。

自動レビューは判断担当を変える

自動レビューは、メインのCodexが動く場所を別の環境へ移す仕組みではありません。メインのエージェントは同じサンドボックス内で動き、境界を越えたい操作が承認対象になったときだけ、設定されたレビュアーが判断します。レビューが許可しても、許可されたのはその依頼を実行することです。書き込み可能な場所、通信範囲、保護されたパスが自動で広がるわけではありません。したがって、導入の順番は自動レビューを先に選ぶことではなく、まず境界を決め、次に確認条件を決め、最後に判断担当を選ぶことになります。

公式仕様で読む三つの設定

Codexの設定を確認するときは、名前を個別に暗記するより、「どこまで」「いつ」「誰が」という三つの質問に当てはめると理解しやすくなります。sandbox_mode は技術的な範囲、approval_policy は停止条件、approvals_reviewer は承認時の判断者です。画面上の「Ask for approval」「Approve for me」「Full access」などの表示は便利ですが、表示名だけで安全性を判断せず、背後の組み合わせまで確認してください。OpenAIの公式文書では、デスクトップアプリ、CLI、IDE拡張で入口は違っても、この関係を同じ考え方で説明しています。

sandbox_mode は触れてよい範囲

代表的なサンドボックスの違いは次の通りです。read-only は調査や計画に向き、既存ファイルを読んで内容を説明する作業を安全に始められます。workspace-write は現在のプロジェクト内で編集や通常のテストを行うための現実的な初期値です。danger-full-access はファイルシステムと通信の境界を外すため、必要性を明確に説明できる一時的な確認に限るべきです。表示名が「Full access」でも、便利さと安全性を同時に得られる設定ではありません。

approval_policy はいつ止まるか

on-request は、境界の内側で進められる処理を止めず、外へ出るときに人の確認を求める設定です。untrusted は信頼できる操作の範囲を狭く考え、より多くの場面で確認します。never は確認を出さないため、操作の結果を人が読める状態にしておく責任が大きくなります。特に、削除、依存関係の変更、外部通信、書き込み先の変更は、確認を減らすよりも一件ずつ目的を明確にする方が安全です。日常の開発では、workspace-write と on-request を基準にし、必要な例外だけを狭く認める方が説明しやすいでしょう。

approvals_reviewer は誰が判断するか

承認が必要な場面では、user なら確認が利用者へ届き、auto_review なら対象の依頼がレビュアーへ渡ります。ここで大切なのは、レビュアーが「何でも許可する代理人」ではないことです。自動レビューは依頼の目的、対象、ツールの入力、既に出ている結果を見て、その操作が境界を越える価値があるかを判断します。危険性が高い依頼を拒否することもあり、拒否されたからといって別の経路で同じ結果を得ようとするのは適切ではありません。

三つの設定は組み合わせで読む

同じ workspace-write でも、確認ポリシーが on-request か never かで体験は変わります。同じ on-request でも、レビュアーが user か auto_review かで、確認が画面に届くかが変わります。設定のレビューでは一行だけを切り取らず、三つの値を横に並べて記録してください。さらに、書き込み可能なルート、ネットワークの設定、OSのサンドボックス方式も一緒に残すと、「前は動いたのに今は止まる」という差を追いやすくなります。

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"

この組み合わせは、人が承認を受け持つ初期例です。自動レビューを試すときは最後の値だけを auto_review に変え、同じ小さな作業で結果を比べます。複数の設定を一度に変更すると、どの値が挙動を変えたのか分からなくなるため、記録を一項目ずつ更新するのがコツです。

Auto-reviewが動く場面と動かない場面

Auto-reviewは、サンドボックスの境界で発生する承認依頼を扱います。公式文書では、昇格した権限を求めるシェル操作、現在の方針で止められた通信、許可されたルート外の編集、承認が必要なアプリやMCPの呼び出しなどが例として挙げられています。逆に、現在のサンドボックスで既に許された読み取りや編集は、毎回Auto-reviewへ送られません。この違いを理解すると、レビュー回数が少ないことを「監視が働いていない」と誤解せずに済みます。

境界を越える依頼が対象になる

たとえば、プロジェクト内のテストを走らせるだけなら、workspace-write の範囲で完結することがあります。一方、別のフォルダーへ成果物をコピーする、ネットワークから依存パッケージを取得する、許可された場所の外に設定ファイルを書き込む、といった依頼は追加の判断が必要です。Auto-reviewは、依頼が発生した時点で「何をしたいのか」「どこへ作用するのか」「なぜ現在の境界では足りないのか」を確認します。依頼文に対象のパス、必要な通信先、期待する出力を具体的に書くと、レビュアーが判断しやすくなります。

既に許可された操作は対象外

Auto-reviewはすべてのコマンドを二重に検査する機能ではありません。現在の境界の内側で実行できる操作は、メインのエージェントがそのまま進めます。そのため、レビューを導入した後も、読み取りや小さな編集の速度が大きく落ちるとは限りません。ただし、境界の内側で許可されているから無条件に採用してよいわけではなく、差分、テスト結果、生成されたファイルを人が確認するという別の点検は残ります。

「Full access」と同じではない

Auto-reviewと「Full access」は、変更する対象が異なります。Auto-reviewは承認が必要になった操作の判断者を変えるだけですが、「Full access」はサンドボックスの技術的な境界を外します。公式文書でも、danger-full-access と approval_policy = "never" の組み合わせは、確認の機会とファイル・通信の制限を同時に失うと説明されています。確認を減らしたいだけなら、まず許可されたルートを狭く追加し、頻繁に止まる安全なコマンドだけを個別に扱う方が、意味のある境界を残せます。

WindowsでCodex権限を確認する手順

Windowsでは、ChatGPTデスクトップアプリ、Codex CLI、IDE拡張の入口があり、PowerShellで動くネイティブ環境とWSL2ではサンドボックスの実装が異なります。公式のWindows文書には、ネイティブ方式として elevated と unelevated の二つが示され、前者が優先、後者が環境上の制約がある場合の代替とされています。画面上の権限メニューだけでなく、実際にどのOS方式と作業フォルダーが使われているかを確認してから、設定を変えましょう。

Step 1: 現在の権限プロファイルを記録する

最初に、Codexの入口、クライアント版、選択中のプロファイル、作業フォルダーをメモします。CLIでは /permissions を開いて現在の選択肢を確認でき、デスクトップアプリやIDE拡張では入力欄付近の権限メニューを見ます。ここで「Ask for approval」「Approve for me」「Full access」の表示だけを記録せず、可能なら sandbox_mode、approval_policy、approvals_reviewer の実値も併記してください。

1. Codexを起動した入口と版番号を記録する。
2. 対象プロジェクトのフォルダーが意図した場所か確認する。
3. 権限メニューと設定ファイルの値を照合する。

Step 2: 作業境界を小さなフォルダーで試す

いきなり本番リポジトリ全体へ権限を与えず、複製した小さな検証用プロジェクトで動作を見ます。読み取り、同じフォルダー内の編集、別フォルダーへの書き込み、通信が必要な操作を別々に依頼し、どの場面で確認が出るかを記録します。Windowsの公式文書が説明するネイティブサンドボックスでは、作業フォルダー外の書き込みと明示していない通信を止めることが初期の境界です。設定が期待と違うときは、全アクセスへ切り替える前にOS方式と作業場所を確認してください。

Step 3: 自動レビューを人の確認と比べる

approvals_reviewer = "user" で、まず同じ依頼を人の確認へ出します。次に auto_review を選び、同じ入力、同じパス、同じ版で試します。比較するのは単純な許可率ではありません。依頼の説明が正しく読まれたか、拒否理由が表示されたか、拒否後に安全な代替へ切り替えたか、実行後の差分とログを確認します。自動レビューが許可した結果も人が読み、意図しないファイル変更や通信がなかったかを点検します。

Step 4: Windowsのサンドボックス方式を確認する

ネイティブWindowsでは、elevated が専用の低権限ユーザーやファイル・通信の境界を使い、unelevated は現在のユーザーから制限付きのトークンを作る代替方式です。どちらを使っているかは、同じ権限プロファイルでも結果に影響します。管理上の制約で elevated が使えない場合、unelevated を採用するなら、動作確認の範囲を狭くし、ファイル変更と通信の結果をいつも記録してください。詳細はOpenAIのWindowsサンドボックス文書で確認できます。

安全な初期設定と権限を広げる判断

権限設定は「よく止まるから強くする」という順番で変えると、いつの間にか境界がなくなります。先に、Codexへ任せる仕事を読み取り、現在のプロジェクト内の編集、依存関係の取得、外部サービスへの接続、プロジェクト外への保存に分解してください。それぞれに必要な権限が違うため、作業内容を小さく分けるほど、設定を狭く保てます。初期値としては、読み取りだけなら read-only、小さな修正なら workspace-write と on-request、人が判断を続けるなら user の組み合わせが説明しやすいでしょう。

小さな修正に向く組み合わせ

アプリケーションのテスト、文書の更新、既存コードの一部修正なら、現在のワークスペースだけを書き込める状態を基準にします。ネットワークが不要な作業では通信を無効にしたままにし、依存パッケージが必要な場合だけ、目的と接続先を確認して一時的に扱います。自動レビューを使う場合も、まず user で操作が止まる場所を把握してから切り替えます。そうすれば、許可された操作とレビュー対象の操作を比較でき、設定の意味を失わずに済みます。

書き込み可能なルートを広げるとき

複数の関連フォルダーを同時に扱う必要がある場合、サンドボックス全体を外すのではなく、書き込み可能なルートを狭く追加する考え方があります。追加する前に、そこへ置かれる生成物、既存の設定ファイル、共有される可能性のある情報を確認してください。親フォルダーを丸ごと指定すると、無関係なリポジトリや個人用ファイルまで対象に入るおそれがあります。フォルダーの目的、所有者、不要になったときの削除方法を記録し、期間を決めて見直すと、例外が恒久的な広い権限へ変わりにくくなります。

Full accessを選ぶ前に考えること

Full accessは、エラーを解消する便利な近道に見えます。しかし、誤ったパス、不要な削除、意図しない通信を同じ操作で止められなくなります。使う必要がある場合でも、複製したプロジェクト、保存先の確認、変更前のバックアップ、実行後の差分確認を先に用意してください。問題の原因が権限不足ではなく、パスの間違い、依存関係の不備、設定ファイルの競合であることも多いため、エラー文を読まずに強い権限へ移るのは避けます。

ローカルの承認とコードレビューを分ける

「自動レビュー」という言葉は、ローカルの承認依頼を判断するAuto-reviewと、リポジトリの変更を読んで指摘するCode Reviewの両方を指すように見えます。両者は対象が異なります。前者は、Codexが今から実行しようとする操作を許すかどうかを扱います。後者は、変更後の差分、周辺コード、テスト結果などを見て、品質やリスクを指摘します。ローカル権限を広げてもCode Reviewの精度が上がるわけではなく、Code Reviewを有効にしてもローカルのファイル範囲が広がるわけではありません。

ローカルの権限レビュー

ローカルのAuto-reviewは、境界を越える一つの操作に対する判断です。許可された後にCodexがファイルを編集し、テストを実行したとしても、その変更を採用するかは別の確認です。レビュー結果、実行されたコマンド、変更されたファイル、テストの成否を一緒に見て、依頼の目的に合っているかを確認します。拒否された場合は、同じ結果を別のコマンドで得ようとせず、作業範囲を縮める、入力を変える、人に相談するという選択肢へ戻ります。

リポジトリのCode Review

OpenAIはCode Reviewについて、プルリクエストの意図と差分を比べ、依存関係やテストまで含めて重要な問題を探す機能として説明しています。設定を有効にしたリポジトリで、変更の段階に応じたレビューコメントを受け取り、必要なら同じ場所で修正を依頼できます。ただし、レビューが出した指摘は人が検証し、変更を取り込む前にテスト結果と差分を確認する必要があります。詳細はOpenAIのCodex更新説明を参照してください。

Codex Securityとの違い

Codex Securityは、接続したGitHubリポジトリを対象に、脆弱性の候補を特定し、再現を試し、修正案を人が確認できる形で提示する製品です。公式ヘルプでは、提案された修正がコードを直接変更するのではなく、確認後にプルリクエストへ進められると説明されています。EnterpriseやEduのワークスペースでは、利用権限と設定管理権限を役割やグループで分けられます。ローカルのAuto-review、Code Review、Codex Securityを比較するときは、「実行前の操作」「変更後の差分」「脆弱性の検証」のどこを見ているかを表にすると、説明がぶれません。

よくある問題と切り分け方

権限設定の問題は、許可が多すぎるケースだけでなく、少なすぎて作業が進まないケースにも現れます。大切なのは、表示されたエラーを「Codexが弱い」とまとめず、サンドボックス、承認、OS、対象フォルダー、通信の五つに分けて確認することです。次の切り分けを行うと、Full accessへ移る前に原因を狭められます。

自動レビューを選んでも通信できない

自動レビューは、ネットワークを有効にする機能ではありません。現在のサンドボックスで通信が止められているなら、レビューが許可して実行できる場合もありますが、通信方針や接続先の設定が必要なままです。ネットワークを使わずに済む作業へ分け、必要な場合は接続先を限定し、取得した内容を記録してください。自動レビューへ変えただけでネットワークが開くと考えると、設定の意図を見失います。

確認が多すぎる

安全なテストや決まった読み取りまで毎回止まる場合、レビュアーの判断を緩める前に、作業境界が狭すぎないか確認します。公式文書も、頻繁に確認を出す安全な操作については、書き込み可能な場所やコマンドの範囲を狭く追加する方針を示しています。例えばテスト専用の出力先だけを許可し、プロジェクト全体や親フォルダーを対象にしない方法です。追加後は同じテストを再実行し、確認回数だけでなく変更範囲も比べます。

拒否が続いて作業が止まる

Auto-reviewの拒否は、通常のサンドボックスエラーと同じではありません。公式文書では、同じターンで連続した拒否や一定範囲内の拒否が続くと、現在の処理を中断する仕組みが説明されています。拒否された結果を別の経路で繰り返し求めるのではなく、作業を小さく分け、必要な情報を依頼文に足し、ユーザーが判断すべき操作として引き取ります。CLIの現行文書には、直近の拒否に対して一回だけ再試行を選べる /approve の説明もありますが、同じ操作を恒久的に許可するものではありません（出典: Auto-review公式文書）。

Windowsだけ挙動が違う

Windowsのネイティブ方式とWSL2では、使われるサンドボックスの実装が異なります。同じ設定ファイルを読んでいても、PowerShellで起動した場合とWSL2で起動した場合に、書き込みや通信の結果が変わる可能性があります。まず入口、版番号、OS方式、作業フォルダーを揃え、同じ小さな依頼で比べます。管理者権限の不足が原因なら、設定を強くするのではなく、公式のWindows文書にある方式の要件と組織の制約を確認してください。

導入前に行う判断手順

自動レビューを使うかどうかは、好みだけで決めるより、作業の影響と確認の頻度を照らし合わせて判断します。設計確認や読み取り中心の仕事なら、人がすべての承認を受け取る構成でも負担は大きくありません。長いテストや低リスクの編集が多く、境界は十分に狭くできているなら、自動レビューを比較対象にできます。反対に、個人情報を扱う場所、削除や公開を含む作業、対象範囲を説明しにくい作業では、人の確認を残す方が安全です。

Step 1: 操作を分類する

依頼を、読み取り、現在のプロジェクト内の編集、依存関係の取得、別フォルダーへの保存、外部サービスへの接続に分けます。それぞれに必要な境界と確認条件を書き出し、全作業を一つの強い設定で処理しないようにします。

Step 2: 最小の境界を選ぶ

読み取りだけなら read-only、小さな編集なら workspace-write を基準にします。必要なルートや通信先が明確になってから、対象を狭く追加します。広い親フォルダーを指定して、後から差分を確認する方法は避けてください。

Step 3: 人の確認で基準を作る

最初の一件は user をレビュアーにして、どの操作が確認対象になるかを見ます。承認理由と実行結果を残せば、自動レビューへ切り替えた後に、判断の違いを比べられます。許可前後の差分も保存します。

Step 4: 自動レビューを小さく試す

同じ入力、同じ版、同じプロジェクトで auto_review を試します。許可率を目標にせず、拒否理由、変更されたファイル、テスト結果、通信の有無を見て、採用するかを判断します。許可後の差分とログも同じ基準で読みます。

Step 5: 設定と結果を定期的に見直す

プロジェクトが変わった、ルートを追加した、モデルやクライアントを更新した、という節目に、権限値と実際の挙動を再確認します。設定が残っていることだけで、現在も安全とは判断しません。変更前後の結果を残すと再確認が容易です。

FAQ

自動レビューなら承認は不要ですか？

不要になるのは、対象となる承認依頼を人の代わりにレビュアーが判断する場面です。サンドボックスの範囲、通信方針、書き込み可能なルートが広がるわけではありません。また、実行後の差分を人が読む責任も残ります。自動レビューを「全操作の無条件許可」と捉えず、境界を越える一件の判断担当を変える機能と考えてください。

Full accessにすれば問題は解決しますか？

権限不足が原因の問題は進むことがありますが、パスの誤り、依存関係の不足、通信先の制限、OS方式の差は解決しない場合があります。さらに、ファイルと通信の境界が外れるため、誤操作の影響が大きくなります。まず小さな検証用プロジェクトで原因を特定し、必要な例外だけを狭く認める方が、再現性のある解決になります。

Code Reviewを有効にするとローカル権限も変わりますか？

変わりません。Code Reviewはリポジトリの変更を確認する機能で、ローカルのサンドボックスや承認ポリシーとは別の層です。逆に、ローカルの自動レビューを有効にしても、プルリクエストの指摘が自動で良くなるわけではありません。利用する機能ごとに、対象、判断のタイミング、最後に人が確認する内容を分けて記録してください。

まとめ：Codex権限は境界から決める

Codex権限自動レビューを安全に使う要点は、許可を増やすことではなく、許可の意味を分解することです。サンドボックスはファイルと通信の境界、承認ポリシーは止まる条件、approvals_reviewer は承認時の判断担当です。Auto-reviewは便利な判断役になり得ますが、境界を広げる機能ではありません。まず workspace-write と on-request、人の確認を基準にし、同じ小さな作業で自動レビューを比べてください。Windowsではネイティブ方式とWSL2を分け、入口、版番号、設定、結果を一緒に記録します。Code ReviewやCodex Securityも別の目的として切り分け、変更を取り込む前には差分、テスト結果、通信先、保存場所を人が確認する。この順番を守れば、Codexの速度を活かしながら、判断できる範囲の中で権限を運用できます。

参照した公式情報: Sandbox、Auto-review、Windows sandbox、Codex 0.146.0、Codex Security。