Codexの承認をスキップするには？設定手順と危険なバイパスの見分け方

Codexで毎回承認が求められるのはなぜか｜approval_policyの基本

Codexの承認とは、AIエージェントが提案したコマンド実行やファイル変更を、実行前に人間が許可する確認の仕組みです。まずはこの仕組みが何を守っているのかを押さえると、どこまで減らしてよいかの判断がしやすくなります。

承認プロンプトはAIの暴走を防ぐ安全装置

Codexは指示を受けると、コードの修正やコマンド実行を自律的に進めます。その際、ファイルの書き換えや外部への通信など影響の大きい操作の前に「実行してよいですか」と確認を挟むのが承認プロンプトです。AIの判断は常に正しいとは限らないため、意図しない削除や誤ったコマンドの実行を人間が止められるように設計されています。

一方で、確認のたびに作業が止まるため、利用者からは毎回の承認がわずらわしいという声も多く聞かれます。承認の頻度は設定で調整できるので、仕組みを理解した上で自分の作業に合わせて最適化していきましょう。

approval_policyで選べる設定値

承認の頻度を決めるのが、設定項目のapproval_policy（承認ポリシー）です。次の4種類から選べます。

既定では慎重側の設定になっており、書き込みを伴う操作には確認が入ります。まずon-requestに変えるだけでも承認回数は目に見えて減るため、最初の調整先としておすすめです。

承認を安全に減らす鍵はサンドボックスとの組み合わせ

承認を減らすと聞くと危険に思えますが、Codexには承認とは別にもう1つの安全装置があります。それがサンドボックス（AIの操作範囲を制限した隔離実行環境）です。

関連記事：Codexのサンドボックスとは？仕組み・3つのモード・安全な設定を整理

sandbox_modeで実行範囲を隔離する

sandbox_modeは、Codexが操作できる範囲そのものを制限する設定です。承認が「操作のたびに人間が確認する」仕組みだとすれば、サンドボックスは「そもそも触れる範囲を狭めておく」仕組みにあたります。

調査やコードリーディングだけならread-only、コードを書かせるならworkspace-writeが基準になります。danger-full-accessは後述するリスクを理解するまで選ばないでください。

「隔離を広げるほど承認は厳しく」が使い分けの基本

approval_policyとsandbox_modeは掛け算で効く関係にあります。実行範囲を狭く隔離しているなら承認を減らしても被害は限定的ですし、逆に制限を外すなら承認は厳しく残すべきです。たとえばworkspace-writeとon-requestの組み合わせは、影響を作業フォルダ内に閉じ込めたまま承認回数を減らせるため、多くの利用者にとって出発点になります。

なお—full-autoオプションは、workspace-writeのサンドボックスで自動実行し、失敗時のみ承認を求める組み合わせを1つのフラグで呼び出す省略形です。名前の印象ほど無防備な設定ではなく、サンドボックスによる隔離は維持されます。

Codexの承認を安全にスキップする設定手順【5ステップ】

ここからは、承認の回数を安全に減らす具体的な設定手順を5つのステップで説明します。いきなり承認をすべてオフにするのではなく、段階的に緩めながら自分の作業に合う設定を見つける流れです。

関連記事：Codexの設定方法｜利用形態の選び方から権限・おすすめ構成まで

ステップ1: 現在の設定と作業環境を確認する

まず、いま何が設定されているかを把握します。Codexのセッション中に/statusと入力すると、現在のapproval_policyとsandbox_modeを確認できます。あわせて、対象のリポジトリが壊れても復元できる状態か、つまりGitで管理されていて未コミットの変更が残っていないかを確認しておきます。承認を減らす前提として、いつでも巻き戻せる環境を用意しておくことが何よりの保険になります。

ステップ2: config.tomlでapproval_policyを変更する

恒久的な設定は、ホームディレクトリの~/.codex/config.tomlに記述します。

approval_policy = "on-request"

sandbox_mode = "workspace-write"

上記のように書くと、次回の起動から適用されます。設定ファイルを編集せずに試したい場合は、セッション中に/approvalsコマンドを使うと、その場で承認モードを切り替えられます。まず一時的に切り替えて使用感を確かめ、良ければconfig.tomlに書き込む順序が安全です。

ステップ3: sandbox_modeを作業内容に合わせて選ぶ

次に、承認とセットでサンドボックスの範囲を見直します。コードを書かせる作業が中心ならworkspace-writeを選び、書き込み先を作業フォルダ内に限定します。逆に、リポジトリの調査や仕様の確認だけならread-onlyのままで十分です。作業フォルダの外に書き込みたい事情がある場合も、いきなりdanger-full-accessに切り替えるのではなく、必要なフォルダだけを追加で許可できないかを先に検討してください。

ステップ4: CLIオプションで一時的に切り替える

恒久設定を変えるほどではないものの、今回の作業だけ承認を減らしたい場面では、CLI（コマンドラインインターフェース）の起動オプションを使います。

codex --full-auto

—full-autoは、workspace-writeのサンドボックス内で自動実行し、問題が起きたときだけ承認を求める設定の組み合わせです。config.tomlを書き換えないため、その作業が終われば次回からは通常設定に戻ります。定型作業のときだけ承認を緩める、といった使い分けに向いています。

ステップ5: full-autoを検証用の環境で試す

設定を緩める最終段階として、まず本番に影響しない検証用リポジトリでfull-autoの挙動を観察します。数日運用して、意図しない変更が起きないか、diff（変更差分）のレビューで問題を拾えるかを確認できたら、日常の作業にも段階的に広げていきます。承認を減らした分は、実行後のコードレビューやテストで品質を担保する運用に切り替えるのがコツです。

設定しても承認が求められ続けるときの確認ポイント

設定を変えたのに承認が出続ける場合は、設定の優先順位から確認します。Codexは起動時のCLIオプションが設定ファイルの内容を上書きするため、config.tomlを書き換えてもオプション指定が残っていれば反映されません。次の順に見直してみてください。

• config.tomlの記述場所は正しいか（該当項目をファイルの先頭側のトップレベルに書いているか）
• 起動時のオプションやプロファイル指定が設定を上書きしていないか
• 作業フォルダの外への書き込みなど、サンドボックスの範囲外の操作を依頼していないか
• Windowsのネイティブ環境で実行していないか（詳しくは後述のFAQを参照）

特に多いのは、サンドボックスの範囲外の操作を頼んでいるケースです。この場合はapproval_policyを変えても、範囲外の操作である限り確認は残ります。承認を減らしたいのか、それとも操作できる範囲を広げたいのかを切り分けてから、対応する設定を見直すのが近道です。

—dangerously-bypass-approvals-and-sandboxの危険性

—dangerously-bypass-approvals-and-sandboxは、その名のとおり承認とサンドボックスの両方を同時に無効化する起動オプションです。最も手軽に確認をなくせる一方で、リスクの質が他の設定とはまったく異なります。

関連記事：Codexのセキュリティリスクと対策｜情報漏洩・脆弱性・CLI脆弱性を整理

すべての安全装置が同時に無効になる

このオプションを付けると、Codexは確認なしであらゆるコマンドを実行でき、ファイルの削除・上書き・外部への通信を止めるものがなくなります。プロンプトインジェクション（外部の文章に埋め込まれた不正な指示でAIを操作する攻撃）を受けた場合、機密情報の送信や破壊的な操作がそのまま実行される恐れがあります。

approval_policyをneverにする設定との違いは、サンドボックスの有無です。neverでもサンドボックスが有効なら操作範囲は制限されたままですが、このオプションは範囲の制限ごと取り外します。

使ってよい場面と避けるべき場面

利用が許容できるのは、壊れても影響がない使い捨ての環境に限られます。たとえばコンテナや仮想マシンの中だけで完結する検証作業です。逆に、業務データのある端末・本番につながる環境・チームで共有しているリポジトリでの利用は避けてください。会社の端末で使う場合は、社内のセキュリティルールに反しないかを事前に確認しておくと安心です。

AI活用実態調査レポート

全国8,000人調査で、AI活用方法によって生産性向上に約3.8倍の差が生まれることが判明。

無料ダウンロード →

GitHub Copilot・Claude Codeとの承認管理の違い

AIコーディングエージェントの承認管理は、ツールごとに名称と設計が異なります。下表は、Codex・Claude Code・GitHub Copilotの3つを、承認設定の名称・承認を減らす方法・完全バイパスの手段・実行環境の隔離という4つの観点で整理したものです。複数のツールを併用する場合は、安全装置の違いを押さえた上でチームとして同じ方針をそろえると管理しやすくなります。

考え方はどのツールも共通で、自動化の範囲を広げるほど隔離とレビューで補うという原則に行き着きます。Codexで身につけた承認設計の考え方は、他のツールにもそのまま応用できます。

Before/Afterで見る承認設定見直しの業務インパクト

承認設定の見直しは、体感の快適さだけでなく作業時間の数字にも表れます。ここでは、例えば次のような2つのケースが考えられます。

シナリオ1: 日常のコード修正が承認対応で細切れになるケース

AIコーディングツールを使い始めて3ヶ月の開発担当者が、1タスクあたり10回前後の承認に毎回応答しているケースです。1回の応答と文脈の切り替えに約30秒かかるとすると、1日10タスクで約60分が承認対応に消えます。approval_policyをon-requestに変えて読み取り系の操作を自動化すると、承認は1タスク2〜3回まで減り、対応時間は1日約15分、およそ75%の削減になります。月20営業日では15時間相当の作業時間を取り戻せる計算です。

シナリオ2: 検証用リポジトリでの定型修正を一括実行するケース

もう1つは、100ファイル規模の定型的な修正を1件ずつ承認しているチームのケースです。一括修正のたびに承認が約50回発生し、完了まで約40分かかっていたとします。書き込み先を作業フォルダに限定したfull-autoで一括実行し、完了後にdiffをまとめてレビューする方式に変えると、承認は0回、実行10分とレビュー10分の計20分で終わります。時間の削減率は50%ですが、細切れの中断がなくなることで集中が保てる利点も見逃せません。

承認をスキップする前の安全チェックリスト

最後に、承認を減らす設定へ切り替える前の確認項目をチェックリストにまとめました。上から順に確認していけば、リスクを抑えたまま移行できます。

• 対象リポジトリはGitで管理され、いつでも巻き戻せる状態か
• 未コミットの変更や、共有ブランチへの直接作業が残っていないか
• sandbox_modeは作業に必要な最小限の範囲になっているか
• 認証キーや顧客データなど、機密情報に触れる作業ではないか
• 実行後のdiffレビューやテストなど、承認に代わる品質確認の手段があるか
• 会社やチームのセキュリティルールに反していないか

すべてにチェックが付くなら、承認を減らしても安全性は大きく損なわれません。逆に1つでも引っかかる項目があるなら、その作業に限っては承認を残す判断が賢明です。

Codexのような AIエージェント導入で陥りがちな3つの落とし穴

Codexの承認設計は、AIエージェントを業務に組み込むときの縮図でもあります。ここでは、AIエージェント導入の現場でよく見られる3つの落とし穴を紹介します。

落とし穴1: いきなり全てをやろうとする

最初からすべての作業をAIに任せ、承認も一気に外すという進め方は失敗のもとです。適用範囲を一度に広げると、問題が起きたときに原因の切り分けができなくなります。

落とし穴2: 壮大なAI戦略から考えて手が止まる

全社的な計画や完璧なルール作りから着手すると、検討ばかりが続いて導入が進みません。小さく試して学ぶほうが、ルールも実態に合ったものになります。

落とし穴3: 既製品のチャット型AIでは業務フローに組み込めない

チャットに質問して答えをもらう使い方だけでは、日々の業務フローに定着しません。自社の手順やデータに合わせてカスタマイズでき、業務の流れに組み込めるエージェント型の仕組みが必要になります。

スモールスタートで1業務をAIエージェントに任せる

遠回りに見えても、まず1つの業務をAIエージェントに任せ、承認や隔離の設定を調整しながら運用を固めるスモールスタートが定着への近道です。Codexの承認設計で行ったように、小さな範囲で安全装置の塩梅を確かめてから広げる進め方なら、失敗しても影響は限定的です。1業務で得た設定・レビュー・運用ルールの知見は、次の業務への展開にそのまま生かせます。

自社業務でAIエージェント活用を進めたい方へ

ここまでで紹介した「スモールスタートで1業務から自動化する」アプローチを、自社で実践したいとお考えの方もいらっしゃるかもしれません。

GiftXでは、AIエージェントの構築支援サービス「GiftX AIエージェント構築支援」を提供しています。1業務単位のスモールスタートから、業務フローに組み込めるレベルのAIエージェント構築までを伴走します。

詳細はGiftX AIエージェント構築支援のサービスサイトでご覧いただけます。

Codexの承認に関するよくある質問

最後に、Codexの承認まわりでよく寄せられる質問と回答をまとめます。

承認を完全にオフにしても安全ですか？

approval_policyをneverにしても、サンドボックスが有効なら操作範囲は制限されたままなので、一定の安全性は保たれます。危険なのは、サンドボックスまで同時に無効化するオプションとの併用です。オフにする場合も、隔離された検証用の環境に限定することをおすすめします。

GitHub Copilotでも承認を省略できますか？

GitHub Copilotのコーディングエージェントにも承認の仕組みがあり、設定によって一部のワークフロー承認を省略できます。ただし設定箇所や挙動はCodexと異なるため、利用中のプランの公式ドキュメントで最新の仕様を確認してください。

Windows環境で承認まわりの挙動が違うのはなぜですか？

Codexのサンドボックスは、macOSやLinuxのOS機能を利用して実現されています。Windowsのネイティブ環境では同等の隔離が働かないケースがあるため、WSL（Windows Subsystem for Linux、Windows上でLinuxを動かす仕組み）経由での利用が推奨されています。承認や隔離の挙動が想定と違うときは、まず実行環境を確認してください。

まとめ｜承認は消すのではなく設計する

Codexの承認は、単にわずらわしい確認作業ではなく、サンドボックスと組み合わせて安全性を担保する仕組みの一部です。approval_policyとsandbox_modeが掛け算で効く関係を理解すれば、承認回数は安全に減らせます。完全にバイパスするオプションは使いどころを使い捨ての環境に限定し、日常の作業ではon-requestやfull-autoといった段階的な設定を使い分けてください。承認を消すのではなく、どこに残すかを設計すると捉えることが、AIエージェントと安心して協働するための土台になります。

AIエージェントの業務活用を検討している方へ

本記事で紹介したようなAIエージェントの活用を、自社の業務でも具体的に進めたい・相談したいとお考えの方は、ぜひGiftX AIエージェント構築支援までお問い合わせください。

GiftX AIエージェント構築支援では、貴社の業務に合わせて1業務単位のスモールスタートから本番運用まで、AIエージェント構築をワンストップで支援します。ユースケースの洗い出しから、PoC（Proof of Concept、概念実証）、本番運用、社内ナレッジ化まで伴走します。

AI活用にご関心のある方は、ぜひ一度ご相談ください。

▶ GiftX AIエージェント構築支援の詳細・お問い合わせはこちら

関連記事

• Codexとは？OpenAIコーディングAIの仕組みやChatGPTとの違い、導入の落とし穴を解説
• Codex CLI とは？できること・料金・Claude Code との違いを整理
• Codex を Windows で使う方法｜セットアップ手順と基本の使い方を整理
• Claude Code と Codex の違い｜5 つの観点で整理し用途別に選び分ける