Codexの権限とサンドボックス｜承認の注意点

こんにちは。Osukeラーニング、運営者の「osuke」です。

Codexに仕事を任せて席を離れたら、承認待ちで止まっていた。今後も許可したはずなのに、また確認される。そんな場面では、全部許可すれば解決するのでは、と考えたくなりますよね。ただ、確認回数だけを減らすと、変更してよいファイルや送信先まで広がってしまうことがあります。

Codexの権限とサンドボックスは、実行できる範囲と、範囲を超える際の承認を分けて考えると整理できます。この記事では、ネット接続、自動レビュー、定期実行の注意点まで、判断の順番をまとめます。2026年9月27日に確認したOpenAI公式資料とXの公開投稿に基づく調査記事で、私自身の実機検証や事故体験ではありません。作業例は説明用の架空例です。

記事のポイント

• サンドボックスと承認ポリシーの違い
• ファイル・通信・外部ツールの権限の切り分け
• 繰り返される承認で確認したい項目
• 定期実行を安全に試し、完了を確かめる方法

Codexの権限とサンドボックスの基本

最初に押さえたいのは、権限が一つのスイッチではないことです。ファイルを変更できる場所、通信先、承認の判断者を分けると、何を許可しようとしているのかが見えやすくなります。

承認と実行範囲を分けて考える

サンドボックスは、コマンドが触れられるファイルやネットワークなどに技術的な境界を設ける仕組みです。一方、承認ポリシーは、どの場面で確認を求めるかを決めます。OpenAIの資料でも、この二つは別の制御として説明されています。「編集はこの作業場所まで」と決めることと、「そこから外へ出る操作を誰が確認するか」を決めることは違う、という整理ですね。境界内の作業まで毎回手動操作に戻す必要はありません。

たとえば、架空の資料整理で、指定フォルダのメモを読み、同じフォルダに要約を保存するところまでは任せるとします。その途中で、別の個人フォルダに保存したり、外部サービスへ資料を送ったりする必要が出れば、最初に想定した範囲が変わります。ここで出る承認は、単に作業の続きを応援するボタンではなく、追加される操作を確認する機会です。「資料をまとめて」と頼んだ事実だけで、あらゆる保存先や送信先が適切になるわけではありません。

もう一つ分けたいのが、承認を出さない設定と、制限そのものを外す設定です。確認が出ないことだけを見て、すべての操作が許可されているとは判断できません。制限に阻まれて失敗する場合も考えられます。逆に、広い権限を与えていても、接続先の認証や別の安全確認までなくなるとは限りません。まず現在の実行範囲を把握し、承認回数ではなく「頼んだことだけができる状態か」を見ていきましょう。

• 実行範囲：どこを読み、どこを変更し、どこへ接続できるか
• 承認ポリシー：どの操作で確認が必要になるか
• 判断者：利用者が見るのか、対象となる自動レビューへ渡すのか
• 完了確認：許可した操作が本当に成功したか

Codex全体の使い道がまだ曖昧なら、Codexでできることと使い方の基本から整理すると、必要以上に広い権限を選びにくくなります。最初から万能な設定を探すより、今回の一つの仕事に必要な範囲を言葉にする方が判断しやすいですね。

読み取りと書き込みの境界

ファイルの権限では、読むことと書き換えることを別々に確認します。作業場所に保存できないからといって、その場所を読めないとは限りません。また、編集できない設定だから秘密情報を扱う心配が一切ない、とも言えません。読むだけでも、内容が会話や処理結果に含まれる可能性を考える必要があります。最初に「このフォルダだけを調べる」「認証情報や個人情報のファイルは対象外」と範囲を限定することが大切です。

公式資料では、読み取り中心の設定や、作業領域への書き込みを許す設定などが区別されています。ただし、具体的なアクセス範囲は有効な設定や組織の管理によって変わります。「プロジェクトとして開いたから必ずどこにでも保存できる」と考えず、保存予定の場所を先に確認しましょう。例として、元資料を置く場所と成果物を出す場所を分けるなら、出力先が許可された範囲に入っているかを、本文作成より前に確かめると手戻りを減らせます。

必要な出力先が境界外だった場合、すぐホームフォルダ全体へアクセスを広げる必要はありません。許可済みの作業場所へ出力する、管理者へ特定の保存先の利用を相談する、といった選択肢を比べます。公式資料には書き込み可能な場所を限定して追加する考え方もありますが、追加は対象と必要性を確認してからです。場所の名前が似ているだけで別の仕事の資料を混ぜないよう、依頼文にも保存先を明示しておきましょう。

• 入力：必要な資料だけを指定し、秘密ファイルを混ぜない
• 出力：変更してよいフォルダとファイル名を決める
• 既存ファイル：上書きか新規保存かを区別する
• 範囲外：全体を開放せず、必要な場所だけを検討する

Gitのワークツリーで変更場所を分けても、それだけで通信や認証情報まで隔離されるとは限りません。変更の整理と実行権限は別の問題です。作業場所の選び方については、Codexワークツリーの使い方と注意点で補足しています。どちらを使う場合も、既存の変更を確認してから小さな作業を任せるのが出発点です。

ネット接続と外部ツールの違い

インターネットへアクセスする操作も、一括りにしない方が分かりやすくなります。コマンドで外部の情報を取得する処理、検索ツールでウェブを調べる処理、接続済みアプリでデータを更新する処理は、同じ経路とは限りません。検索ができるのにコマンドの通信が止まったとしても、それだけで不具合とは判断できないのです。まず「どの機能が、どの相手へ、何を送ろうとしているか」を確認しましょう。

架空の月次レポートなら、公開統計を読むだけの通信と、完成した資料を取引先の共有場所へアップロードする通信では影響が違います。どちらもネット接続を使いますが、後者には送信する内容と公開範囲の確認が必要です。さらにアプリ側のログインや権限が切れていれば、Codex側の設定を広げても解決しない場合があります。ファイルへの書き込み、外部への送信、接続先の認証を、一つの「許可エラー」として処理しないことが重要です。

通信先を絞る設定を使う場合も、許可するドメインを書けば必ず制限が働く、と自己判断しないでください。現行の公式資料では、通信を許す設定と、接続先ルールを適用する仕組みが区別されています。設定例の一部分だけをコピーするより、適用対象と有効状態を確認することが先です。本記事では、読者の環境が不明なまま通信制限を一括解除する手順は勧めません。必要な接続先を一つずつ洗い出す方が、安全性と実用性を両立しやすくなります。

• 取得だけか、送信・更新も含むかを区別する
• 公開情報か、内部資料や個人情報かを確認する
• 接続先のアカウントと対象データを確認する
• エラーの種類を確かめてから、必要な設定だけを検討する

承認画面で見るべき4項目

承認画面に長いコマンドが出ると、細かい意味を読まずに許可したくなりますよね。そんなときは、何をするか、何を対象にするか、どこへ送るか、どこまで許可が続くか、という四項目に分けると整理できます。これは本記事で提案する確認方法で、すべての画面に同じ四つの欄があるという意味ではありません。説明から分からない項目があれば、承認前にその点を聞き直すのが自然な進め方です。

例として「テストを実行する」という説明でも、実際には依存パッケージの取得や、出力ファイルの作成を伴う場合があります。目的の名前だけで判断せず、実行場所と副作用も確認してください。資料の公開なら、対象が下書きなのか本番サイトなのか、既存記事を更新するのか新規作成するのかで意味が変わります。「今回だけ許可」と「同じ種類の操作にも適用する許可」が選べる場合は、将来どこまで対象になるかも見ます。

分からないコマンドを、読みやすくするために説明してもらうのは遠回りではありません。「変更するファイル、外部へ送る情報、元に戻せる範囲を先に説明してください」と頼めば、判断材料を揃えられます。逆に、説明と実際の対象が一致しない、対象パスが広すぎる、知らない送信先が含まれる、といった場合は、そのまま進めず範囲を絞る相談が必要です。安心できる言い方かどうかではなく、操作の内容を見ましょう。

1. 動作：読む、作る、上書きする、削除する、公開するのどれか
2. 対象：ファイル・フォルダ・アカウント・記事IDは意図どおりか
3. 送信先：どのサービスへ、どの情報が渡るか
4. 範囲：今回だけか、現在の作業か、今後の類似操作にも及ぶか

たとえば「指定した一つの成果物を所定の保存先へ置く」ことが目的なら、関係のないフォルダまで変更できる許可は不要かもしれません。必要最小限の範囲で続けられる案を選び、承認後には保存結果も確かめます。承認は成功の証明ではないので、ファイルの存在や公開状態など、結果側の確認まで一組にしておくと安心です。

今後も許可で止まらなくなる？

今後も許可する選択肢が表示されても、その仕事に関係するあらゆる操作が永久に承認されるとは限りません。公式資料では、承認の適用範囲は一回、現在のチャット、より広い範囲など、要求内容や実行環境によって異なるとされています。画面に出た範囲を確かめずに「もう何も聞かれない」と期待すると、次の保存や通信で止まったときに混乱しやすくなります。まず何に対する許可だったかを確認しましょう。

コマンドの先頭部分に基づくルールが使われる場合も、単に言語名や通信ツール名を広く許すことと、限定した処理を許すことは違います。たとえば、決まったテストを実行する用途と、任意のプログラムを動かす用途では影響範囲が変わります。私は、説明できる定型操作だけを候補にし、対象や引数が大きく変わったら再確認する考え方が分かりやすいと思います。承認を減らすために広いルールを増やすこと自体を目的にしない方がよいですね。

また、「今後も許可」が出ない画面だから、今後すべての実行で必ず同じ手動承認が必要、と一律には言えません。その操作で選べる範囲、利用しているアプリ、組織の制約、別途設定されたレビュー方式などを確認する必要があります。少なくとも、表示されていない継続許可を会話の一言だけで作れたと考えるのは避けましょう。希望する運用と、実際に保存・適用された権限を分けて扱うことがポイントです。

• 今回の許可が何に一致するのかを読む
• 対象ファイルや送信先が変わったら別の判断として扱う
• 広い実行許可を「確認が面倒」の理由だけで追加しない
• 継続許可が選べない場合は、利用環境の条件を確認する

一度許可した処理が再び止まった場合も、すぐに別の方法へ迂回させるのではなく、前回と今回の操作を比べてください。違う保存場所や別サービスが増えているなら、新たな確認が合理的なこともあります。同じに見える場合は、後半の切り分け手順で、適用範囲と現在の状態を整理しましょう。

Codexの権限とサンドボックスの運用

ここからは、作業が止まったときの対処と、定期実行へ進む前の確認を扱います。判断を急がず、必要な承認だけを分かりやすくすることを目指します。

自動レビューは全許可ではない

現行のOpenAI公式資料で説明されるAuto-reviewは、対象となる承認要求を別のレビュー担当エージェントが判断する仕組みです。主な作業をするエージェントのサンドボックスを取り除く機能ではありません。つまり、確認を誰が担当するかが変わるのであって、ファイルや通信の範囲が無条件に広がるわけではないのです。画面では利用環境により「Approve for me」などの表示が使われますが、提供条件や組織の設定も関係します。

レビュー対象の操作が承認されれば進み、拒否されれば、より安全な方法を検討するか、利用者へ確認する流れになります。拒否された処理を別ツールや別コマンドへ言い換えて、同じ影響を出そうとするものではありません。また、Computer Useのアプリ単位の承認など、自動レビューでは置き換えられない確認も公式に説明されています。「自動」という名称から、無人ですべての工程が通ると期待しないことが大切です。

レビューの判断にも限界があるため、仕事に必要な範囲を狭く保つことや、成果物を確認することは引き続き必要です。たとえば、許可されたフォルダの中に誤った内容の資料ができても、権限の仕組みだけで内容の正しさまでは保証されません。自動レビューの詳しい対象と限界は、OpenAI公式ドキュメント「Auto-review」で確認できます。利用者が判断する方式と比べる場合も、確認回数だけでなく、失敗したときに気づけるかを見てください。

• 通常の承認：対象となる要求を利用者が確認する
• 自動レビュー：対象となる要求を別のレビュー担当が評価する
• 共通点：許可の判断と、出力の正しさの確認は別
• 注意点：拒否や対象外の確認があり、無停止を保証しない

今回のような日常業務で大切なのは、どの方式が最も強いかではなく、どの範囲なら安心して任せられるかです。まだ内容を理解できない処理まで自動判断へ広げる前に、まず一度、人がいる状態で入力・処理・出力を確認する方が、設定の意味をつかみやすくなります。

承認が繰り返される時の確認順

同じような承認が続く場合は、最初に止まっている工程を特定します。本文やコードを作る段階なのか、ファイルの保存なのか、外部サービスへの送信なのかで、見るべき場所が変わります。エラーメッセージが出ているなら、秘密情報を除いた必要部分だけを使って、権限・認証・通信・処理内容のどれに近いかを整理しましょう。単に「動かないから全部許可」へ進むと、原因が残ったまま範囲だけが広がることがあります。

次に、前回許可した操作と今回の操作を並べます。実行場所、対象ファイル、コマンドの内容、接続先、許可の有効範囲のうち、変わったものはないでしょうか。名前が同じスクリプトでも、実行する場所や渡す対象が違えば、同じ影響とは限りません。一方、同じ条件なのに繰り返されるときは、画面の状態、利用クライアント、バージョン、適用されている設定を確認し、必要ならサポートへ説明できる情報を揃えます。

ここで大切なのが、拒否とタイムアウト、権限不足とログイン切れを区別することです。処理の完了前に応答が途切れた場合には、操作が実行されていないとは限りません。記事公開やメール送信など、繰り返すと困る処理なら、再実行前に相手側の状態を確認してください。保存された成果物や公開済みの記事を調べ、未実行の工程だけを再開する方が、最初から全部やり直すより二重処理を防ぎやすくなります。

• 記録するもの：日時、工程、対象、画面の説明、結果
• 記録しないもの：パスワード、認証情報、無関係な私的データ
• 再開条件：未完了部分と、安全に続けられる範囲が分かったこと

Xの不満と安全重視の声

Xでは、権限の説明だけでは見えにくい使いづらさも見つかります。2026年9月27日の蒼志（@aoshisss1）の公開投稿では、一つのターミナルで発生した承認が、並列実行中の複数のターミナルに表示されることへの不満が述べられていました。ここからは、並列作業でどの操作の承認なのかを把握しづらい、という困り方が読み取れます。ただし、投稿だけでは環境や再現条件は分からず、すべての利用者に起きる仕様とは扱えません。

同日の@uncle_vaperの投稿には、長く続けた会話で、今後の許可を与えてもファイル作成の確認が繰り返される、という報告がありました。投稿者は会話の長さとの関係を推測していますが、私はそれを原因が確定した情報としては採用しません。読者が同じような症状に遭遇した場合も、会話を短くすれば必ず直ると考えるより、保存先、許可範囲、実行内容などを比較する材料にするのが適切だと思います。

一方、同日のテツメモ（@tetumemo）の公開投稿には、MCP連携を最小権限・承認・ログから始めるという提案が含まれていました。これは利用提案であり、特定の設定を試した比較結果ではありません。それでも、確認を減らすことだけを目標にしない視点として参考になります。今回見た少数の投稿から、承認の不具合が増えている、ある設定なら安全、といった全体傾向は判断していません。

• 不満の投稿：読者が困る場面を把握する材料
• 原因の推測：再現条件がなければ確定事項にしない
• 運用の提案：自分の仕事に必要な範囲を考える材料
• 仕様の確認：現行の公式資料と実際の設定で行う

私がこの記事で重視したいのは、承認画面の数を競うことではなく、どの作業が止まったか説明できる状態です。並列の仕事には用途が分かる名前を付け、対象と進捗を分けておく。繰り返し承認には、前回との差分を残す。こうした小さな整理は、特定の不具合の有無にかかわらず、操作を取り違えないために役立つ考え方です。

定期実行を小さく試す手順

定期実行で止まりにくくしたいなら、最初から本番の公開処理を丸ごと無人で試すより、工程を分けて確認する方法をおすすめします。例として、毎朝の情報収集からレポート公開までを任せる場合、調査、本文作成、保存、外部への公開、公開後の検証という五段階に分けます。どこに権限が必要かを先に整理すれば、途中で止まったときにも、すでにできた部分を無駄にせず再開しやすくなります。

初回は人が確認できる時間帯に、秘密情報のないサンプルを使い、読み取りとローカル保存までを試すのが一案です。次に、本番の送信や公開を行う権限が明示されているかを確認し、対象を一つに絞って進めます。公開後はURLや状態を取得して、実際に公開されたかを確認します。この手順は本記事の運用提案であり、設定しただけで実行を保証する機能ではありません。認証切れやサービス障害など、別の要因で止まる可能性も残ります。

繰り返す仕事ほど、成功条件と停止条件を具体的にしておきましょう。「記事を作る」だけなら、下書きができた段階で終わる解釈もあり得ます。「指定カテゴリへ一件公開し、公開状態と画像を確認してURLを報告する」まで決めると、完了の判断が明確になります。失敗時には、公開済みかを先に確認し、未完了工程を報告する、と決めておくことも大切です。止まった処理を無条件に最初から再実行させない方が安全ですね。

1. 工程を分け、必要な保存先と送信先を洗い出す
2. 人がいる時間帯に、小さなサンプルで試す
3. 本番の操作は対象と件数を明示する
4. 実行後の状態を確認してから成功とする
5. 失敗時は重複を確認し、未完了部分だけを再開する

共通の手順を文章に残すなら、CodexのAGENTS.mdで指示を整理する方法も参考になります。ただし、AGENTS.mdは作業方針を伝えるもので、技術的なアクセス制限の代わりではありません。依頼文、実行権限、結果確認の三つを揃えることが、継続運用の土台になります。

Codexの権限とサンドボックスまとめ

Codexの権限とサンドボックスを理解するときは、何ができるか、いつ確認するか、誰が判断するかを分けることから始めましょう。確認が少ないほど優れた設定、というわけではありません。必要な範囲の作業は進み、想定外の変更や送信は確認できることが大切です。最初は、今回の目的、触ってよい場所、送ってよい相手を一つずつ書き出すだけでも、承認画面を読むための基準になります。

今後も許可する選択肢があっても、対象や有効範囲を確かめます。自動レビューを使う場合も、全アクセスの付与や、無停止の保証とは区別してください。承認が繰り返されるときは、前回と今回の操作、保存先、接続先、認証状態などを比べます。X上の体験談は困り方を知る材料にはなりますが、個人が推測した原因を、そのまま自分の環境の原因と決めないことも大切ですね。

定期実行では、実行できたことと、目的を達成したことを分けて確認します。コマンドが終わっただけでは、正しい資料が保存されたか、予定どおり一件だけ公開されたかまでは分かりません。結果のファイル、公開状態、対象件数などを確かめて、初めて完了とする流れを用意しましょう。途中で止まっても、状況を把握して安全に再開できるなら、ただ広い権限で走らせ続けるより管理しやすい運用になります。

• 最初の確認：現在の作業場所と許可範囲を整理する
• 承認前：動作・対象・送信先・有効範囲を見る
• 停止時：原因の種類と実行済みの範囲を確かめる
• 完了時：成果物や公開状態を確認し、結果を残す

今日できる小さな一歩は、普段止まる操作を一つ選び、「何をしようとして、どの範囲で止まるのか」を書くことです。その説明ができれば、必要な許可を限定するのか、出力先を変えるのか、接続状態を直すのかを考えやすくなります。全部許可か全部手動かの二択ではなく、仕事に必要な範囲を見極めながら、任せられる部分を少しずつ増やしていくのがよいかなと思います。