この記事の根拠
根拠は、ChatGPTデスクトップアプリ本体の設定定義と表示文言(当社が実機のアプリファイルから確認)、Codex公式「Prompting」ガイド、GPT-6 Astra公式ガイド、OpenAI APIの「Mid-turn steering」ガイド、OpenAI Model Spec、当社の運用で観察した挙動です。観察した挙動は当社の実感で、公式が保証する仕様ではありません。
結論:既定は「キューに追加」、割り込みは1件ずつ選ぶ
結論から書きます。ChatGPTデスクトップアプリ(Codex)の「設定 > 一般 > フォローアップの動作」は、「キューに追加」を基本にしてください。「今すぐ反映」は設定で常時オンにするものではなく、割り込みたいその1件だけショートカットで選ぶものとして扱います。
理由は一つです。GPT-6 Astra以降、「今すぐ反映」で差し込んだ指示を、Codexが「前の作業の取消し」と読むことがあるからです。実行そのものは止まらないのに、それまで進めていた作業の続きと完了報告が来なくなる。当社の運用で、これが繰り返し起きました。
「今すぐ反映」で起きたこと — Astraから始まった当社の観察
症状は3段階で進みます。①Codexの実行中に、追加の頼みごとを「今すぐ反映」で送る。②Codexがそれまでやっていたことを全部止め、新しい指示に全力で答える。③前の指示についてのフォローアップ、つまり完了報告・確認の質問・残作業の案内が、そのあと一切来なくなる。
あとから「前の作業はどうなった」と聞くと、Codexはこう答えます。「指示の追加を、前の作業の取消しと解釈して止めたのが誤りでした」。追加のつもりで送った指示が、モデルの側では方針転換として読まれていた。この一言に、後で説明する仕組みの本質が表れています。
強調しておきたいのは、Astra以前はこうなっていなかったことです。以前のモデルにも、後から送った指示を先にやろうとする傾向はあり、本来の作業が後回しになる場面はありました(SteerとQueueの使い分けで書いたとおりです)。ただ、それは後回しであって、作業は戻ってきた。
Astraでは戻ってきません。前の指示は取消し扱いになり、続きも報告も来ない。「順番が入れ替わる」から「前の作業が閉じられる」へ、症状の質が変わった。これが、以前は個別の判断で済ませていた「今すぐ反映」を、設定ごと「キューに追加」へ置き直した理由です。
毎回起きるわけではない
これは当社の観察であり、毎回起きるわけでも、公式が定めた仕様でもありません。モデルやバージョンで変わりえます。ただ、「起きうる」前提で既定を置いたほうが安全というのが、使い込んだうえでの結論です。
設定の場所と選択肢 — アプリ本体の定義から分かる3つの事実
設定は「設定 > 一般 > フォローアップの動作」にあり、選択肢は「キューに追加」と「今すぐ反映」の2つです。説明文は「Codex の実行中は、フォローアップをキューに追加するか、現在の実行に今すぐ反映できます。(ショートカット)を押すと、1 件のメッセージだけ逆の動作になります」。
この設定をアプリ本体の定義まで追うと、画面の説明文だけでは分からない事実が3つあります。とくに①の既定値は、環境によって違います。
表は横にスクロールできます →
| 事実 | 内容 | 出所 |
|---|---|---|
| ①既定値は環境で違う | プロジェクトを一度も登録していない新しい環境では「今すぐ反映」、それ以外の環境では「キューに追加」で初期化される。自分の環境がどちらかは設定画面で確認する | アプリ本体の初期化処理 |
| ②「今すぐ反映」は中断ではない | キューに積んだメッセージに付く「今すぐ反映」ボタンの説明は「モデルの実行を中断せずに送信」。走っている実行に指示を差し込む操作で、止める操作ではない | アプリ本体の表示文言 |
| ③1件だけ逆にできる | 既定のEnter送信なら ⌘Enter(Enterで改行する設定なら ⌘⇧Enter)で、その1件だけ設定と逆の動作になる | アプリ本体の設定説明とショートカット定義 |
設定値は ~/.codex/config.toml の [desktop] セクションに followUpQueueMode として保存されます。値は "queue"(キューに追加)か "steer"(今すぐ反映)です。画面を開かなくても、このファイルを見れば今の設定が分かります。
同じ仕組みは他の入り口にもあります。Codex IDE拡張(VS Code)は既定が「キューに追加」で、設定名は chatgpt.followUpQueueMode、1件だけ逆にするショートカットは Cmd/Ctrl+Shift+Enter。Codex CLIは作業中にEnterで今すぐ反映、Tabでキューです。
表は横にスクロールできます →
| 入り口 | 既定の動作 | 1件だけ逆にする操作 |
|---|---|---|
| ChatGPTデスクトップアプリ(Codex) | 環境で異なる(新しい環境は今すぐ反映) | ⌘Enter(Enterで改行する設定なら ⌘⇧Enter) |
| Codex IDE拡張(VS Code) | キューに追加 | Cmd/Ctrl+Shift+Enter |
| Codex CLI | Enterで今すぐ反映 | Tabでキューに追加 |
| スマホ(Remote) | 接続先のパソコンの設定に従う | キューに積んだ行の「今すぐ反映」 |
公式ガイドはどう言っているか — 用途は「走っている作業そのもの」の修正
OpenAIのCodex公式ガイド「Prompting」には「Steering and queuing」という節があります。要点はこうです。Steer(今すぐ反映)は現在の実行にメッセージを加える。方向転換、抜けていた詳細の追加、新しい情報の共有に使う。Queue(キューに追加)は次の実行のためにメッセージを保存する。今の作業が終わるまで待つべきフォローアップに使う。
読み方のポイントは、公式が挙げる「今すぐ反映」の用途が、すべて「いま走っている作業そのものに関する情報」だという点です。別の頼みごとを差し込む用途は書かれていません。当社で起きた症状は、まさに走っている作業と無関係な「追加の仕事」を「今すぐ反映」で渡したときに起きています。
なぜ前の作業が消えるのか — 仕組みは止めていない、モデルが「取消し」と読む
OpenAI APIの「Mid-turn steering」(作業中に追加指示を送るAPI機能)ガイドには、こう書かれています。「Steeringは、すでに送った出力を書き換えたり、以前の操作を取り消したり、開始済みのツールを中止したりしない」。アプリの画面を直接説明した文書ではありませんが、追加指示を走っている応答に差し込む仕組みの説明として読めます。
つまり、仕組みとしては何も止めていません。では誰が止めているのか。モデル自身です。差し込まれたメッセージは、走っている実行の途中に「新しいユーザーの指示」として届きます。そこでモデルは「これは追加か、それとも方針転換か」を、作業しながら一瞬で判断します。
OpenAIのModel Spec(モデルの振る舞いの基本方針を定めた文書)は、こう定めています。「ある指示は、同じレベルの後のメッセージの指示がそれと矛盾する・上書きする・無関係にする場合に、置き換えられる」。後から来た指示が優先されるのは、設計どおりの振る舞いなのです。
同じ文書は「フォローアップの質問なのか話題の変更なのか判別しにくい場合は、もっともらしい限り、以前の文脈がまだ有効だと仮定する側に倒す」とも書いています。理想はそうです。ただ、作業の途中に届いた指示は聞き返す間もなく判断され、その判断が「取消し」側に倒れたのが、冒頭の謝罪です。
「キューに追加」なら、その判断自体が発生しない
「キューに追加」にすると、今の実行は最後まで走り、完了報告まで出てから、次の指示が新しい実行として始まります。「追加か取消しか」をモデルが判断する場面そのものが無くなる。これが、既定を「キューに追加」にすべき理由です。
なぜAstraで起きるようになったのか — 公式ガイドの「文脈に敏感」と符合する
後の指示が先の指示を置き換える規則は、Astra以前のモデルにもありました。それでも以前は「後回し」で済んでいた。Astraで「取消し」に変わった理由は、OpenAIのGPT-6 Astra公式ガイドの記述と符合します。
公式ガイドはAstraについて、「より長い指示に従えるようになった一方で、文脈にある情報により敏感になりうる」と説明しています。さらに例として、「スキルファイルの不明確または矛盾する指示が、モデルを早い段階で止め、作業をブロックすることがある」とも書いています。
作業の途中に届いた無関係な指示は、まさに「文脈に加わった、前の指示と噛み合わない情報」です。以前のモデルなら後回しで受け流していた場面で、Astraは指示どおり素直に方針転換し、前の作業を閉じる。指示に敏感になった分だけ、後の指示が先の指示を置き換える規則が強く効くようになった。これが当社の見立てです。
同じ性質は、依頼文の粒度や AGENTS.md の書き方でも表れています(Astraは言われたことしかやらない?)。フォローアップの設定を「キューに追加」にするのは、その延長線上にあるもっとも手軽で、効果がはっきりした対策です。
ここは当社の推論です
Astra公式ガイドは、フォローアップの設定について直接は書いていません。「文脈に敏感」という記述と当社の観察を結びつけたのは当社の推論であり、公式が原因として説明したものではありません。
それでも「今すぐ反映」を使う場面と、前の作業を消さない書き方
公式の用途どおり、走っている作業そのものの方向修正なら「今すぐ反映」が正しい選択です。前提の誤りに気づいた、対象範囲を伝え忘れた、成果物の形式が違う、といった場面です。どちらを選ぶかの判断基準はSteerとQueueの使い分けで整理しています。
差し込むときの書き方にもコツがあります。1文目に「今の作業はそのまま続けてください」と置き、そのあとに追加内容を書く。「追加で」「終わったら」と、前の作業との関係を明示します。「追加か取消しか」の判断材料を、こちらから先に渡す形です。
今の作業(◯◯の修正)はそのまま最後まで続けてください。取消しではありません。
追加で1件:それが終わったら△△も確認してください。順番は今の作業が先で構いません。それでも前の作業が消えてしまったら、復旧は1行で足ります。「さっきの追加指示は前の作業の取消しではありません。中断した◯◯を再開し、終わったら追加分に進んでください」。なぜ取消しと読んだのかを説明させる必要はありません。
キュー運用のコツ — 積んだ指示は編集・並べ替え・削除できる
「キューに追加」を基本にすると、積んだ指示を待つ間に見直せるのが利点です。公式ガイドによると、キューに積んだメッセージはコンポーザーの上に表示され、編集・並べ替え・送信・削除ができます。
- 積んだあとに「やはり今」と思ったら、その行の「今すぐ反映」ボタンで差し込める(説明文は「モデルの実行を中断せずに送信」)
- スマホからの追加指示も同じ。公式の変更履歴では、ChatGPT for iOS 1.2026.237(2026年9月1日)でキューが接続先と同期し、編集でき、アプリがバックグラウンドでも送信されるようになった
- 長い作業にはゴール設定を組み合わせる。
/goalで完了条件を先に渡しておけば、キューの指示は「ゴールに着いてから」処理される(Codexの/goalコマンド) - Codex CLIでは Tab でキューに積む。Enterは今すぐ反映になるので、CLIでは指を変える必要がある
Claude Codeとの違い — 選ぶ設定がなく、Enterは「中断せずに渡す」
Claude Codeには「キューか今すぐか」を選ぶ設定がありません。公式ドキュメントによると、作業中にEnterで送ったメッセージはターンを中断せずにキューに入り、走っているツール呼び出しが終わった時点で、同じターンの中でClaudeに渡されます。止めたいときはEscです。
つまりClaude Codeの「キュー」は、届くタイミングだけ見るとCodexの「今すぐ反映」に近い。それでも取消し扱いになりにくいのは、当社が実際のセッションで確認した限り、差し込まれたメッセージに「このターンを続けながら対応せよ」という注記が添えられて渡されるからです。Codex側に同じ注記があるかは、公開情報では確認できていません。
どちらのツールでも共通する原則は同じです。走っている作業と無関係な頼みごとは、終わってから渡す。ツール側の仕組みに頼らず、渡す側がタイミングを選ぶことが、成果物を守るいちばん確実な方法です。
まとめ
- 「設定 > 一般 > フォローアップの動作」は「キューに追加」を基本にする。既定値は環境で違うので、まず自分の設定を確認する
- 「今すぐ反映」は中断ではなく差し込み。前の作業が消えるのは仕組みではなく、モデルが「後の指示が優先」と読んだ結果。Astraから起きるようになったのは、公式ガイドの「文脈に敏感」と符合する
- 割り込むのは走っている作業そのものの修正だけ。その1件は ⌘Enter で選び、1文目に「今の作業は続けて」と書く
- 消えたら1行で復旧する。「取消しではない、中断した作業を再開して」で足りる
こうした「任せ方の設定」は、機能一覧を眺めても身につきません。当社のCodex研修・導入伴走支援では、自社業務でAIエージェントを使い込んで見つけた運用の型を、貴社の実業務を題材にお渡ししています。
Codexを組織に定着させたい企業様へ。AI Orchestraの法人研修・導入支援をご覧ください。






