Codexはい・いいえの選び方｜承認範囲と拒否後の確認手順

Codexの「はい・いいえ」は何への回答なのか

開発中に表示される確認は、見た目が似ていても役割が異なります。「この操作を進めてもよいですか」という問いは、実際にファイルや接続先へ働きかけるための承認です。一方、「この画面に検索欄を付けますか」という問いは、作るものの仕様を確定するための質問です。後者に「はい」と答えても、あらゆる場所への書き込みや、外部サービスへの送信をまとめて認めたと解釈するべきではありません。どちらの確認か分からなければ、直前の説明に操作名、対象ファイル、接続先があるかを探します。

OpenAIの承認と安全性に関する公式文書は、技術的に触れられる範囲と、操作の前に確認する条件を別々に説明しています。これを画面の判断に置き換えると、「作業をお願いした」と「今表示された追加操作を認める」は別の確認になります。ここでは、画面に必ず日本語の「はい」「いいえ」が出るという意味ではなく、許可と拒否、肯定と否定を求める場面全般を扱います。

操作の承認は対象と影響を読む

例えば、依頼したのが説明文の修正なのに、別のフォルダーにある設定も変更する確認が出たとします。この場合は「修正を頼んだから」と一括して許すより、追加の設定変更が必要な理由を確認します。対象が明示されていれば、依頼した作業との関係を自分で比べられます。判断材料が足りない場合は、変更する前に目的と影響を説明してもらう方が、後から変更を追い直す負担を減らせます。

仕様への回答は完成条件を伝える

仕様への質問なら、単に「はい」と返すより、必要な条件を短く添えると意図が伝わります。「検索欄を付けてください。対象は記事タイトルだけです」のように答えれば、検索機能を採用することと、その範囲を同時に示せます。ただし、この回答は設計の条件を伝えるものです。外部へのデータ送信など、別の操作が提案された際は、その目的と対象を改めて読む必要があります。

10月7日の更新で承認画面を確認する理由

2026年10月7日の「ChatGPT for iOS 1.2026.272」について、OpenAIは承認選択画面を見直し、権限の選択肢を分かりやすくしたと案内しています。同じ更新には、状態の通知が回答を求める質問のように見えなくなる修正も含まれます。根拠は公式Changelogの10月7日掲載項目です。画面が変わった直後は、以前の位置を覚えて操作するより、今の選択肢に書かれた範囲を読み直す意味があります。

これはiOS版の変更として掲載された情報です。Windowsの画面、CLI、IDE拡張も同じ日に同じ表示になったと、この掲載項目だけから判断することはできません。更新情報を読むときは、製品名と版、変更点を一緒に確認します。承認画面が改善されたことと、利用者の作業範囲が広がったことも別です。見た目が分かりやすくなっても、依頼した対象や許可の有効範囲を確認する習慣は必要です。

通知と質問を見分ける

「処理中です」「接続を待っています」といった表示は、進み具合を知らせるものかもしれません。回答を求める選択肢がない状態で会話欄に「はい」と送っても、承認が成立するとは限りません。まず、回答用のボタンや入力欄があるか、何への回答を待っているかを見ます。表示だけでは分からないときは、「いま私の回答が必要ですか。必要なら対象を説明してください」と尋ねると、状況の説明を求められます。

「今回だけ」と広い許可の違いを読む

承認の選択肢が複数あるときは、許可の有効範囲を確認します。OpenAIのサンドボックス公式文書では、一度だけの許可やセッション中の許可が提示される場合、作業を続けられる最も狭い範囲を選ぶよう説明しています。したがって、初めて見る操作や対象がはっきりしない操作では、繰り返し使える許可を選ぶ前に、今回必要な範囲が分かっているかを考えます。

例えば、開発用の確認で一つの接続先を使いたい場合でも、今後のすべての接続まで必要とは限りません。確認回数が少なくなることは便利ですが、許可した範囲をあとから説明できることも大切です。選択肢の文言は利用画面や設定によって異なるため、「一番上の項目が一度限り」「二番目は常に安全」といった位置だけの覚え方は避けます。何に、どれくらいの期間、どの範囲で許可を与えるのかを文章として読んで判断します。

一度限りの許可が向く場面

初めて試す処理、今回だけ必要な保存先、目的が限定された外部接続では、一度限りの選択肢があれば判断しやすくなります。許可の前に対象を確かめ、結果を見てから次の作業を考えられるためです。ただし、一度限りなら内容を読まなくてよいという意味ではありません。操作そのものが依頼と合っていることを確認する必要は、許可の期間が短くても変わりません。

継続する許可は条件を説明できるときに選ぶ

同じ開発用フォルダーで繰り返す確認など、対象と目的を理解している場合は、より長く有効な許可を検討する余地があります。その場合も、どこまでが同じ操作として扱われるかを読みます。範囲を説明できないまま確認を減らすと、別の対象への操作に気づきにくくなります。迷う場合は今回だけで進め、何度も必要になる理由が分かってから、利用画面の設定を確認します。

判断に迷ったときの確認手順

以下は本記事で提案する確認手順です。公式の画面を一律に再現した手順ではありません。利用画面によって操作方法が異なるため、特定のボタンの位置ではなく、読む情報の順番をそろえています。最初に対象を確かめ、次に影響を読み、最後に許可の範囲を選べば、何を理由に判断したかを振り返れます。急いでいる場合でも、この順番を短い言葉で確認すると、意味の違う質問に同じ答えを返すことを避けられます。対象の説明が省略されていたら、回答前に補足を求めてください。

Step 1: 確認の対象を一文にする

画面の説明を読み、「どのファイルをどう変えるか」「どこへ何を送るか」「どの仕様を採用するか」のいずれかを一文にします。例えば「開発用フォルダー内の説明文を修正する」であれば、依頼した作業との一致を見られます。一文にできない場合は、対象や目的が不足している可能性があります。そのまま肯定せず、操作の説明を求めてから判断します。

Step 2: 依頼との関係と変更後の確認方法を読む

その操作が完成に必要か、代わりに狭い範囲で済ませられるかを考えます。コードの修正なら差分で確認できるか、外部接続なら送る情報を事前に把握できるかが判断材料です。例えば表示の誤字修正に大きな追加変更が提案された場合は、先に誤字だけ直す方法を尋ねられます。変更後に何を確かめるかまで分かると、許可する理由が具体的になります。

Step 3: 選択肢の範囲を確認して回答する

一度限り、セッション中、その他の範囲が表示されている場合は、今回の依頼に必要なものを選びます。操作を認めるための画面があるなら、その画面の選択肢を使います。仕様への質問であれば、採用する条件を会話欄で伝えます。入力欄に「はい」と書けばどの確認にも対応できるとは考えず、表示が求めている回答の方法を確かめてください。

Step 4: 回答後の状態と成果物を確認する

回答した後は、操作が開始されたか、別の確認を待っているか、拒否されたままかを読みます。編集作業では、変更されたファイルと差分を見て、依頼した範囲に収まっているかを確認します。テストが必要なら、その結果が報告されたかも確かめます。許可したのに処理が失敗した場合は、承認の成否と処理結果を分け、表示された理由に沿って次の対応を決めます。

「いいえ」を選んだ後は何を確認するか

拒否することは、依頼全体を必ず取り消すことや、すでに行った変更を元に戻すことと同じではありません。例えば、一部の編集を終えた後に追加の接続を求められ、その接続を拒否したなら、編集済みのファイルが残っている可能性を確認します。逆に、変更前に止まっていたなら、その操作について成果物はまだ作られていないかもしれません。どちらかを決めつけず、実際の報告と差分を読みます。

拒否後の依頼は、禁止した対象と、続けてほしい範囲を分けて伝えると具体的になります。「外部への送信は許可しません。手元の資料だけで修正案を示してください」のように書けば、別の方法を検討する条件を示せます。別の方法で進められるかは作業次第なので、できたと報告されるまでは未完了として扱います。検証できなかった項目があるなら、その項目を完成報告に残してもらうことも有効です。

拒否と取り消しを分ける

「いいえ」は、画面が確認している操作への拒否として読みます。過去の変更まで戻したい場合は、戻す対象を別に伝えます。例えば「今回の接続は拒否します。すでに変更した説明文は残してください」なら、残す変更を明示できます。戻す依頼をする場合も、利用者が途中で加えた編集まで消えないよう、どの変更を対象にするかを確認してから進めます。

同じ確認が続くときは理由を尋ねる

拒否した操作が再び提案された場合は、確認を通す前に、なぜ別の方法では進められないかを尋ねます。必要な資料が外部にしかない、保存先が指定範囲の外にあるなど、理由が分かれば依頼を変えられます。説明が不十分なまま何度も肯定するより、「接続しない条件で可能な部分と、できない部分を分けて報告してください」と伝える方が、残りの作業を把握できます。

WindowsやCLIで二択が見えないとき

Windows、CLI、IDE拡張では、利用画面や設定が違うため、iOSの更新案内と同じボタンを探しても見つからない場合があります。公式サンドボックス文書は、CLIでは /permissions で権限の選択画面を開けると案内しています。これは現在の権限を確認・変更する入口であり、会話中のすべての質問へ「はい」と回答するための命令ではありません。個々の確認に答えたいのか、作業の権限を調べたいのかを分けて使います。

二択が出ないことだけでは、確認が不要な状態なのか、別の制約で止まっているのか、処理が進んでいるのかは判別できません。現在の状態、直前のメッセージ、対象ファイルの変化を見ます。組織で使っている場合は、利用者が変えられる設定と管理側が決める条件が異なることもあります。押せる項目を探すために広い権限へ切り替えるより、どの条件で止まっているかを説明してもらう方が、必要な対応を絞れます。

承認できたことと正しく完成したことを分ける

操作を認めたことは、操作の結果が正しいという評価ではありません。修正を許可した後でも、意図した表示になったか、余分なファイルが変わっていないか、必要な検証が終わったかを確認します。「はい」を選ぶ判断と、完成品を受け取る判断を別に持つと、許可する範囲を小さく保ちながら開発を進められます。迷ったときは、対象、影響、許可範囲、結果の四つを順に読み直してください。