MemoryLake
すべての記事に戻る
Tutorial2026年11月3日·10 分で読了

CodexでSteerするかQueueするか?タスク中に入力したメッセージの行方とEnterキーの動作 (2026)

Codexにタスクを与えて作業が始まった後で、「テストは別のフォルダにある」とか「設定ファイルには触れてほしくない」といったことを思い出すことがあります。Codexがまだ作業している間に入力した場合、そのメッセージが現在の実行を「Steer(操縦)」するのか、それとも「Queue(キュー)」に待機するのかによって、その後の展開が変わります。

OpenAIのドキュメントでは、この2つをそれぞれ1行で定義しています。「Steerはメッセージを現在の実行に追加します。方向転換、不足している詳細の追加、または新しい情報の共有に使用します。」そして「Queueはメッセージを次の実行のために保存します。現在の作業が終わるまで待つべきフォローアップに使用します。」

このガイドでは、それぞれが会話にどのような影響を与えるか、CLI、IDE拡張機能、デスクトップアプリでEnterキーがどちらの動作をするか、ターミナルの保留メッセージエリアの読み方、そして開いていないセッションに対してメッセージをキューに入れる方法について解説します。チャットをリダイレクトするのではなくリセットしたい場合は、Codexの /clear と /new に関するガイドをご覧ください。

Steer(ステアリング)がすること

Steerを行うと、メッセージはCodexがすでに取り組んでいるターンに参加します。何も再起動されません。Codexは新しい指示を同じ実行の一部として読み取り、次に行う動作を調整します。

CLIのドキュメントでは、このキーについて次のように説明されています。「Codexの作業中にEnterを押すと、現在のターンに新しい指示を注入(inject)します。」

クライアントアプリがCodexと通信するために使用するCodexのアプリサーバーにも、対応するメソッドがあります。そのドキュメントには次のように記載されています。「turn/steer を使用して、アクティブな実行中のターンにユーザー入力を追加します。」Steerであるものとそうでないものを示す2つの詳細があります。このメソッドは「新しい turn/started 通知を発行しない」ため、新しいターンは始まりません。また、「ターンレベルのオーバーライド(model、cwd、sandboxPolicy、または outputSchema)を受け付けない」ようになっています。Steerは現在のターンに言葉を追加するものであり、途中でモデルや作業ディレクトリを変更することはできません。

SteerがCodexに届くタイミング

Steerはコマンドの途中でCodexを中断させることはありません。ターミナルでは、保留中のSteerは「次のツール呼び出しの後に送信される」という見出しの下のプレビューリストに表示され、すぐに中断して送信するためのキーを示すヒントが表示されます。そのため、通常はCodexが現在のステップを完了してから、次のステップを決定する前にあなたのメッセージを読み取ります。

Codex自体の変更履歴によるタイミングの例外が1つあります。以前は、Codexが最終回答をストリーミングしている間にEnterを押すと、セッションがスタックしたままになることがありました。2026年2月にマージされた修正により、そのウィンドウではメッセージが代わりにキューに入れられ、回答が終わった後に実行されるようになりました。

Queue(キューイング)がすること

キューに入れられたメッセージは待機します。現在の実行は計画通りに終了し、あなたのメッセージが次のターンを開始します。

CLIのドキュメントには次のように記載されています。「Codexの作業中にTabを押すと、次のターンのためのフォローアッププロンプト、スラッシュコマンド、またはシェルコマンドをキューに入れます。」複数をキューに入れることができ、それらは順番に実行されます。

スラッシュコマンドをキューに入れた場合の挙動は少し異なります。「キューに入れられたスラッシュコマンドは実行時に解析されるため、コマンドメニューやエラーは現在のターンが終了した後に表示されます。」タイポのあるコマンドをキューに入れた場合、そのターンの番が来たときにそれが判明します。

一部のコマンドは、すでに動作中のセッション向けに設計されています。OpenAIのスラッシュコマンドガイドによると、/model、/fast、/permissions、/approve、/raw、/agents、/subagents、/status などのコマンドを使用して「アクティブなセッションをSteerする」方法が示されています。同ガイドでは、コマンドをキューに入れる前でもスラッシュ補完が機能するため、Tabを押す前に名前を確認できると記されています。これにより、Codexの作業中に3つのツールが使えます。言葉によるSteer、次のステップのためのキューメッセージ、そして設定のためのコマンドです。

ターミナルでは、キューに入れられたメッセージはプレビューリスト内で保留中のSteerとは別のセクションに表示され、最後にキューに入れたメッセージを編集するためのキーヒントが表示されます。デスクトップアプリでは、OpenAIは「キューに入れられたメッセージはコンポーザーの上に表示され、そこで編集、並べ替え、送信、または削除が可能です」としています。

Enterキーがどちらの動作をするか

ここで驚く人が多いのですが、デフォルトの動作はCodexを使用する場所によって異なります。

CLIの場合

EnterがSteerで、TabがQueueです。これは、2026年2月の変更以来のデフォルトです。その変更ログには「Steer機能をExperimental(実験的)からStable(安定)に昇格させ、デフォルトで有効にする」と記されています。それ以前は、タスク実行中のEnterはQueueでした。それ以前にCodexを習得した方は、古い挙動を期待する習慣が残っているかもしれません。

IDE拡張機能の場合

拡張機能のデフォルトは逆です。設定項目 chatgpt.followUpQueueMode のデフォルトは queue であり、リファレンスでは「次の実行を待つ(queue)か、現在の実行を操縦する(steer)か」の選択肢として説明されています。また、拡張機能は古い値もマッピングしており、「拡張機能はレガシーな interrupt 値を steer として扱います」としています。単発のメッセージについては、Cmd または Ctrl + Shift + Enter を押すことで、設定とは逆の動作をさせることができます。

デスクトップアプリの場合

アプリにはそのための設定があります。OpenAIの設定リファレンスでは、「General(一般)」の下に「Follow-up behavior(フォローアップの動作)」オプションがあり、Codexの作業中に送信されたメッセージが現在の実行をSteerするか、次の実行を待つかを選択できます。プロンプティングガイドには、「この設定には、デフォルトを変更せずに1つのメッセージに対してもう一方の動作を使用するためのショートカットも表示されます」と付け加えられています。

つまり、同じキーでもターミナルではSteerを意味し、エディタではQueueを意味することがあります。入力した修正が無視されたように感じた場合は、どのインターフェースを使用していたかを確認してください。

Steered conversation(操縦された会話)の意味

Codexで「steered conversation」が検索されるのは、タスクの途中で送信したメッセージが、新しいターンを開始することなくCodexの動作を変更したためです。それがSteer(操縦)の本質です。会話は1つのターンのままで、途中であなたの指示が追加されます。

オープンソースのコードも同様に処理します。Codexが会話の要約(recap)を作成する際、コード内では隣接するユーザーメッセージが1つのリクエストの一部としてSteerの状態を保持するように記されており、Steerとその修正対象のリクエストは一緒に読み取られます。

コンテキスト(context)の観点では、SteerもQueueも最終的には同じ場所に収まります。どちらもCodexが読み取る会話の一部になります。違いはタイミングです。Steerは現在のターン内に到着し、キューメッセージは次のターンとして到着します。どちらの場合も、メッセージは入力した他の内容と同様にチャットのコンテキストとしてカウントされます。Codexの context left の数値に関するガイドで、それがどのように蓄積されるか説明しています。

セッション外からメッセージをキューに入れる

Codexには、開いていないセッションに対してメッセージを送信するコマンドもあります。CLIリファレンスでは、codex queue をIDまたは正確な名前によって「既存のセッションに対してテキストメッセージをキューに入れる」方法として説明しています。

これにはいくつかのルールがあります。「キューに入れられたメッセージはセッションのモデルを使用します。コマンドはテキストのみを受け付けます。」また、ロードされていないセッションについては、「--resume を追加してメッセージをキューに入れ、セッションがまだロードされていない場合は再開します。」再開ステップには、実行中のローカルデーモンまたはリモートサーバーが必要です。失敗した場合、「警告を表示しますが、正常に終了(exit successfully)します」。そのため、終了コードに頼るのではなく、後でセッションを確認してください。この resume オプションは Codex 0.166.0 で導入されました。

Steeringの目標とサブエージェント

長時間実行される作業には、独自のSteeringオプションがあります。OpenAIのゴール(goal)ドキュメントによると、インタラクティブなCLIセッションでは「同じインタラクティブセッション内でフォローアップメッセージを送信して、コンテキストを追加したり制約を調整したりできる」とされています。Codexのゴールモードに関するガイドでは、ゴールがタスクに何を付随させ続けるかについて解説しています。

委任された作業について、OpenAIはCodexに直接依頼して、実行中のサブエージェントをSteerしたり、停止させたり、完了したエージェントスレッドを閉じたりできると述べています。Codexのサブエージェントに関するガイドでは、各サブエージェントが何を持って開始されるかを説明しています。

よくある間違い

IDEでEnterを押し、Steerを期待する。 拡張機能のデフォルトはQueueです。設定を変更するか、1回限りのショートカットを使用しない限り、メッセージは次の実行を待ちます。

Steerが現在のコマンドを停止させると期待する。 保留中のSteerは次のツール呼び出しの後に入ります。すぐに送信するには、ヒントに表示されている割り込みキーを使用してください。

Steerでモデルを変更しようとする。 Steerはターンレベルのオーバーライドを保持できません。コマンドでモデルを変更するか、次のターンのためにキューに入れてください。

スラッシュコマンドをキューに入れ、実行されたと思い込む。 キューに入れられたコマンドは自分のターンの番が来たときに解析されるため、エラーは後から表示されます。

--resume を付けた codex queue の終了コードを過信する。 再開に失敗しても正常終了します。セッションを確認してください。

解決策:各指示をどこに送るべきか決定する

ステップ1:インターフェースごとにデフォルトを決める

EnterでSteerしたいのかQueueしたいのかを決め、IDE拡張機能とデスクトップアプリの設定をCLIの使い方に合わせます。もう一方の動作をさせるための1回限りのショートカットを覚えましょう。

ステップ2:修正にはSteer、新しい作業にはQueue

現在のタスクでCodexが間違った方向に向かっている場合はSteerを使用します。変更後のチェック実行や要約の作成など、別のステップとなるものはすべてQueueに入れます。実行がすでに行き過ぎてしまった場合、CLIでは空のコンポーザーでEscapeを2回押すことで、前のメッセージを編集してその時点からチャットをフォーク(分岐)させることができます。Codexチャットのフォークに関するガイドでオプションを解説しています。

ステップ3:繰り返されるSteerをチャットの外に出す

テストの場所や触れてはいけないファイルなど、すべてのセッションで同じ修正をSteerしていることに気づいたら、それはチャットで再入力するメッセージではなく、プロジェクトの AGENTS.md や管理しているメモに記載すべき内容です。

MemoryLakeでのセットアップ

Steerは現在の実行を修正します。頻繁に行う修正は別の問題です。それらはプロジェクトに関する事実であり、すべてのセッションでそれらを再入力することは、それらが反映されない原因になります。

MemoryLake は、それらの事実を1か所にまとめて管理し、ChatGPT、Claude Code、Codexなどの接続されたアシスタントが利用できるようにするための記憶(memory)レイヤーです。

エントリーは自分自身の言葉で作成します。Codexセッション、そのトランスクリプト、AGENTS.md ファイル、Codexの記憶、またはベンダーのストアから何かが読み取られたり、書き込まれたり、削除されたりすることはありません。SteerとQueueはOpenAIが説明している通りに機能し続けます。

ステップ1:APIキーを作成する

サインインし、ダッシュボードからキーを生成します。このキーは MemoryLake ワークスペースに属し、ChatGPT や Codex のアカウントとは別個のものです。

新しいキーが作成され、エージェントで使用するためにコピーされるAPIキー画面を表示するMemoryLakeコンソール
新しいキーが作成され、エージェントで使用するためにコピーされるAPIキー画面を表示するMemoryLakeコンソール

ステップ2:最初の記憶をアップロードする

解決策のステップ3で挙げた、繰り返される修正から始めましょう。物の場所、触れてはいけないもの、繰り返し伝えている規約などです。1つのエントリーにつき1つのポイントを記述します。

最初のドキュメントがアップロードされ、各ファイルが検索可能な記憶としてリストされているMemoryLakeワークスペース
最初のドキュメントがアップロードされ、各ファイルが検索可能な記憶としてリストされているMemoryLakeワークスペース

ステップ3:AIとエージェントを接続する

使用しているアシスタントを接続します。複数のツールをまたいで作業する場合は、Claude CodeとCodexを併用するガイドで、共有コンテキストを1か所に保持する方法を解説しています。

記憶レイヤーに接続可能なAIクライアントとエージェントフレームワークをリストしたMemoryLake統合画面
記憶レイヤーに接続可能なAIクライアントとエージェントフレームワークをリストしたMemoryLake統合画面

実践で何が変わるか

第一の違いは、Enterキーによる不意打ちが減ることです。どのインターフェースがSteerで、どれがQueueかを知ることができます。

第二に、ターンが整理されます。修正は意図した実行に反映され、別の作業は自分の番を待つようになります。

第三に、全体的なSteerの回数が減ります。繰り返していた修正はすでに書き留められているため、Codexはそれらを把握した状態で開始します。

SteerとQueueのベストプラクティス

インターフェースのデフォルトを確認する。 CLIはEnterでSteerします。IDE拡張機能はQueueします。

早めにSteerする。 次のステップに進む前に修正することで、後で元に戻す手間を省けます。

別のタスクはQueueに入れる。 チェック、要約、フォローアップは次のターンまで待つことができます。

保留エリアを注視する。 何がSteerを待機しており、何がQueueされているかが表示されます。

設定をSteerしない。 モデルやディレクトリの変更にはSteerではなくコマンドが必要です。

codex queue の配信を確認する。 再開に失敗しても正常終了します。

繰り返される修正を書き留める。 AGENTS.md や管理しているメモに記載しましょう。

結論

Codexにおいて、Steerはすでに進行中の実行にメッセージを追加し、Queueは次の実行を開始するために待機します。CLIではEnterがSteerでTabがQueue、IDE拡張機能はデフォルトでQueue、デスクトップアプリでは選択可能です。保留中のSteerは次のツール呼び出しの後に挿入され、どちらの種類のメッセージもCodexが読み取る会話の一部になります。

修正にはSteerを、別の作業にはQueueを使用しましょう。同じ修正が何度も発生する場合は、チャットから切り離して、自分で管理する指示(instructions)に移動させてください。

よくある質問

CodexにおけるSteerとQueueの違いは何ですか?

OpenAIによると、Steerはメッセージを現在の実行に追加し、Queueは次の実行のために保存します。Steerは方向転換のため、Queueは待機すべきフォローアップのために使用します。

CodexではEnterキーでSteerされますか、それともQueueされますか?

CLIではEnterがSteerでTabがQueueです。IDE拡張機能はデフォルトでQueueであり、デスクトップアプリにはそのための設定があります。

Codexにおける「steered conversation」とはどういう意味ですか?

Codexが作業中にメッセージを送信し、それが新しいターンを開始するのではなく、現在のターンに参加した会話のことを指します。

SteerはCodexが実行中のコマンドを中断しますか?

デフォルトでは中断しません。ターミナルでは、保留中のSteerは次のツール呼び出しの後に送信されます。すぐに中断して送信するためのキーを示すヒントが表示されます。

Steerでモデルを変更することはできますか?

いいえ。OpenAIのアプリサーバーのドキュメントによると、Steerはモデルや作業ディレクトリなどのターンレベルのオーバーライドを受け付けません。

開いていないCodexセッションにメッセージを送信するにはどうすればよいですか?

セッションのIDまたは正確な名前を指定して codex queue を使用します。キューに入れた後にセッションをロードするには --resume を追加します。これには実行中のローカルデーモンまたはリモートサーバーが必要です。