OpenAI Codex 0.159.0、実行中のステアリングを主役に

OpenAI Codex 0.159.0では、現在の応答や長時間実行コマンドが終わる前に、動作中のエージェントを別の方向へ導くオプトイン方式が導入された。一見すると限定的なインターフェース変更に見えるが、これはエージェント型コーディングにおける最も難しい課題の一つ、つまり有用な作業を捨てずに誤った方向を修正するという問題を対象としている。

このリリースは2026年9月29日に公開され、6つの機能群と広範な修正を含む。主要機能であるinstant_interruptは、新しい入力によってモデルの応答を先取りし、一部のコードモード呼び出しを早期にyieldさせることを可能にする。コードモードは、コマンドを実行し、継続中のプロセスを待機するためのCodexの実行経路だ。

これによりCodexは、GitHub Copilot CLIや他のコーディングエージェントとの直接的なインタラクション競争に加わる。競争はもはや、最も優れたパッチを記述するモデルがどれかという点に限られない。実際の作業が進む最中に、どのエージェントが理解しやすく、操作可能で、復旧しやすい状態を保てるかが、ますます重要になっている。

OpenAI Codex 0.159.0で実際に変わること

このリリースは、エージェントの制御を孤立したプロンプトの連続ではなく、継続的なインタラクションとして扱う。

完全なCodexリリースは、デフォルトでは無効のままであるものの、instant_interruptを中心としている。有効化すると、新しいユーザー入力によってモデル応答中のCodexを誘導できる。長時間実行されるコードモードのexecおよびwait呼び出しにも影響を与えられる。

従来、こうした呼び出しの最中に送信された入力は、その呼び出しが返るまでキューに残ることがあった。この挙動は予測しやすい一方、ユーザーが誤った前提に気づいた際には大きな遅延を生む。エージェントは修正を読む前に、テストの継続、出力の生成、あるいは誤った実装方針の追求を続ける可能性がある。

新しい仕組みは、各サンプリングリクエスト中にキューに入った入力を監視する。次に、対象となるツール呼び出しへ共有のプリエンプション信号を渡す。実行中のセルは終了せずに識別子をyieldでき、Codexは新しい指示を処理できる。

この違いは重要だ。yieldはコマンドの強制終了と同義ではない。基盤となる作業は継続でき、後続のwait呼び出しで結果を取得できる。Codexは、有用な実行状態を自動的に破棄せずに、次の行動を再考する機会を得る。

これに伴うモデル応答の変更が、そのループを完成させる。新しい入力は、背後で待機するのではなく、生成中の応答を先取りできる。このリリースでは、中断経路をまたいでキューに入ったメッセージとツール結果も保持される。

たとえば開発者が、認証サービスのリファクタリングをCodexに依頼したとする。エージェントがテストを実行している間に、開発者は古いクライアントが既存のトークン形式に依存していることに気づく。即時中断を有効にしていれば、その制約は元の計画が完了する前にCodexへ届く。

このリリースには、同じテーマを支える小規模なインターフェース変更も含まれる。新しいセッションではよりコンパクトなウェルカム画面が表示され、一貫したボーダーレスのヘッダーが使われる。ヒントは、作業中およびターン完了後に表示される場合がある。

警告ビューアは、閉じる前にユーザーが確認した警告を閉じる際に却下するようになった。kを押すと、選択した警告を後で確認するために残せる。これによりビューアは、繰り返しの確認を要求する一覧ではなく、軽量なトリアージキューとなる。

ユーザーは、計画実装ダイアログを開いたままでもトランスクリプトをスクロールできる。これにより、提案された変更を承認する前に根拠を読み直すという、基本的ながら重要なレビュー方法が可能になる。

これらのCodex 0.159.0の機能を合わせると、長時間のエージェントセッションを取り巻くインターフェース上の摩擦が軽減される。このリリースは新しいコーディングモデルを発表するものではない。すでに作業中のモデルに人間がどれだけ迅速に影響を与えられるかを変えるものだ。

即時中断が修正コストを変える

実行途中でのステアリングが重要なのは、通常、早期の修正の方が完成済みの誤りをレビューするよりも低コストだからだ。

コーディングエージェントは、プロンプトから完成したパッチへ直接進むわけではない。ファイルを調べ、計画を立て、ツールを呼び出し、結果を読み、コードを変更し、その変更を検証する。誤った前提は、あらゆる段階へ広がりうる。

従来のチャットインターフェースでは、新しいメッセージは現在の応答の後ろに置かれる。この順序は短い回答で済む質問には適している。しかし、エージェントが数分かかるコマンドを実行したり、完了時刻が不確かなプロセスを待機したりする場合には、制約となる。

OpenAIのyield実装は、すべての新規メッセージが現在の作業をキャンセルすべきだとは見なさずに、この遅延へ対処する。アクティブなセルは制御をyieldするが、実行は継続する。その後Codexは新しい指示を組み込み、進め方を決定できる。

これは、待機と中断の中間を生み出す。待機は作業を保持するが、修正を遅らせる。中断は即座に応答するが、実行の進捗を無駄にしたり、何が止まったのかをユーザーに分かりにくくしたりするおそれがある。

Codexの即時中断設計は、応答性と継続性の両方を維持することを目指している。これがリリースの中心的な仕組みであり、別のショートカットやビジュアル刷新よりも重要な意味を持つ。

この機能は、権限に敏感な作業にも影響を及ぼす。エージェントの方向性が見え始めた段階で、ユーザーは制約を追加できる。たとえば、依存関係を禁止する、編集範囲を一つのパッケージに限定する、後方互換性を求める、といった指定が可能だ。

ただし、その介入はタイミングに依存する。すでに発生した外部への副作用を、メッセージで取り消すことはできない。また、重要なコマンドに対する慎重な承認制御の代替にもならない。

その代わり、即時中断は、問題の認識からエージェントへの影響までの時間を短縮する。この短い時間枠は、コーディングタスクが長くなり、ツール呼び出しが増えるほど価値を増す。

オプトインである点にも注目すべきだ。OpenAIはこの挙動を普遍的なデフォルトとして提示してはいない。プリエンプションはメッセージの順序、実行タイミング、ユーザーの期待を変えるため、慎重な導入には合理性がある。

ユーザーは、この文脈における「中断」が何を意味するかも理解する必要がある。アクティブなコードモードのセルはyield後も継続する可能性がある。その状態がインターフェースで明確に伝わらなければ、緊急停止を期待する人はこの挙動を誤解しかねない。

応答プリエンプションの変更は、体験の別の部分を扱う。受信した入力は、現在のモデル応答を停止し、進行中のターンを誘導できる。このシステムは、コンテキスト圧縮中に到着するメッセージも考慮している。

圧縮は、会話が大きくなったときに、以前のセッションコンテキストを要約する。処理中に到着した入力は、失われたり一貫性のない順序で適用されたりするのではなく、延期され保持されなければならない。

これらの詳細は、一見単純な機能の背後にある難しさを示している。応答性の高いテキストボックスだけでは不十分だ。ステアリングは、モデル生成、キューに入った入力、バックグラウンド実行、ツール結果、会話履歴を連携させなければならない。

したがってOpenAI Codex 0.159.0は、知能の更新というよりオーケストレーションの更新を表している。有用な作業を維持しながら、エージェントループをより中断可能にするものだ。

コーディングエージェントは出力だけでなく制御でも競争している

主な競争は、自律的な完了から、実行中の有用な協働へと移りつつある。

GitHubは、コーディングエージェント製品において、ステアリングとキューイングの類似した違いを説明している。ステアリングメッセージは現在の作業を変更し、キューに入れたメッセージは次のターンを待つ。

GitHub Copilotのクラウドエージェントセッションでは、フォローアップのステアリングは現在のツール呼び出しが終了した後に適用される。GitHubのセッション制御では、ライブの進捗、セッションログ、停止、アーカイブも提供される。

GitHub Copilot CLIは、ローカルインターフェースでさらに踏み込んでいる。エージェントが思考中に入力した通常のメッセージは、デフォルトでステアリング入力になる。ユーザーは別途、後のターン向けに作業をキューに入れることもできる。

OpenAIの実装には重要な違いがある。オプトイン経路では、対象となる長時間実行のコードモード呼び出しが、基盤となるプロセスの終了前にyieldできる。これにより、ユーザーの介入からモデルによる再考までの遅延を短縮できる可能性がある。

ただし、これは一方の製品が必ず高速または安全だということを示すものではない。このリリースには、独立したレイテンシ比較、完了ベンチマーク、無駄な作業の削減に関する測定値は含まれていない。より広範な性能上の結論を導くのは時期尚早だ。

とはいえ、コーディングエージェントの競争がどこへ向かっているかは示している。モデル品質は引き続き重要だが、実用上の差別化は、すでに動き出した作業をどのように制御できるかから生まれる度合いを増している。

優れたエージェントでも、状態を隠し、修正を遅らせ、全か無かのキャンセルを強いるなら、使いづらくなりうる。性能の低いモデルでも、誤りが広がる前にユーザーが方向転換できなければ、かなりの時間を消費しかねない。

望ましいインタラクションは、ジョブキューよりもペアプログラミングに近い。一方がアプローチを始め、もう一方が根拠の出現に合わせて制約を追加できる。どちらの参加者も、修正のたびにタスク全体を最初からやり直す必要はない。

このパターンは、エンタープライズでの評価にも影響する。チームは、開発者が進行中の作業を確認し、保留中の操作を理解し、エージェントがプロジェクトの境界を越える前に介入できるかを知る必要がある。

監査可能性も製品の一部となる。コンテキストの追加、方向転換、別タスクのキューイング、実行停止の違いも同様だ。結果が異なるため、これらの操作が同じように見えるべきではない。

警告、トランスクリプトへのアクセス、セッション表示に関する変更は、その要件を支える。完了結果だけを示すのではなく、判断がまだ開かれている間に、ユーザーへより多くの情報を与える。

このインタラクションモデルは、優れたプロジェクトコンテキストにも報いる。ユーザーが既存のドキュメントに裏付けられた正確な制約を提示できるとき、ステアリングは最も効果を発揮する。検索可能なナレッジベースは、エージェントの計画を承認する前に、チームがそうした制約を見つける助けとなりうる。

OpenAI Codex 0.159.0は、制御をめぐる競争に決着をつけるものではない。しかし、より明確な製品の方向性を打ち出している。ツールが忙しいときであっても、エージェントは応答性を維持すべきだ。

小さな機能が長時間セッションの読みやすさを高める

インターフェースの変更は、ユーザーが情報をレビュー、承認、保持する必要がある場面での認知的負担を軽減する。

新しいセッション画面はよりコンパクトになり、セッションヘッダーは一貫したボーダーレスデザインに従うようになった。これらの変更はコード生成を変えるものではないが、ターミナルインターフェース全体の視覚的なばらつきを抑える。

Codexの作業中およびターン完了後には、ときどきヒントが表示されるようになった。これは必要な場面で有用な操作を示せる一方、繰り返されるガイダンスが新たなノイズ源とならないようにする必要がある。

警告ワークフローには、より実用的な変更が加えられた。ビューアを閉じると、ユーザーがすでに確認した警告は却下される。kで起動する保持して次へ進む操作では、重要な警告を残したまま選択を進められる。

この設計は、警告を馴染み深い受信トレイのパターンに対応付ける。確認済みの項目はアクティブキューから外れ、例外は引き続き利用可能な状態に保たれる。この変更により、複数の通知が発生するセッションで繰り返し確認する負担が減るはずだ。

トランスクリプトは、Codex が計画を実装すべきかを尋ねるモーダルダイアログが表示されている間も、スクロール可能な状態を維持できるようになりました。以前は、レビューが最も重要になるタイミングで、モーダルによって過去の議論を見直しにくくなることがありました。

計画の承認は、儀礼的なクリックではありません。有用な判断には、元の依頼、以前のツール出力、特定されたリスク、エージェントが示した前提を確認する必要がある場合があります。トランスクリプトにアクセスできれば、こうした比較が容易になります。

トランスクリプトからのコンテンツコピーも、より信頼性が高まりました。選択範囲では Markdown テーブル、書式設定、意味を持つ空白が維持され、追加のターミナル環境では選択時の自動コピー動作もサポートされます。

この修正は、ユーザーが生成された出力を課題トラッカー、コードレビュー、ドキュメント、インシデント記録へ移す際に重要です。書式が失われると、ログ、テーブル、コードに隣接するテキストの意味が変わる可能性があります。

ネイティブの Mermaid レンダリングでは、より幅広い構文がサポートされます。Mermaid は、簡潔なソーステキストを使ってフローや関係性を記述するテキストベースの図表言語です。

更新されたレンダラーは、ラベル内の句読点やセミコロンを保持します。また、より多くのフローチャート関係、エッジラベル、方向マーカー、グループ化されたノード構造を認識します。

これにより、エージェントが生成したアーキテクチャ図は、より有用なターミナル成果物になります。開発者は Codex にサービスフローの説明を依頼し、レンダリング結果を確認しつつ、基盤となる Mermaid ソースも保持できます。

Mermaid update は、繰り返し現れるインターフェース上の課題も浮き彫りにしています。生成された図表が有用であるためには、レンダラーがモデルによって一般的に生成される構文を受け入れる必要があります。

アプリサーバークライアントには、アイテムを基準としたスレッドページネーションという、より低レベルの機能が加わります。クライアントは、より大きなページだけを移動するのではなく、特定のアイテムを基準にスレッド履歴をリクエストできます。

これにより、アプリケーションは長い会話の関連部分を読み込みやすくなるはずです。また、クライアント開発者は再開可能なタイムラインや段階的な履歴ビューをより細かく制御できます。

これらの追加機能はいずれも、即時中断ほどの概念的な重みを持つものではありません。しかし総合すると、長時間のセッションに入り、確認し、移動し、再利用することを容易にします。

会話が長くなると、エージェントの使いやすさは低下するため、これは重要です。より優れたモデルだけでは、トランスクリプトのナビゲーション、警告疲れ、図表の失敗、書式の喪失を解決できません。

Windows とサンドボックスの修正が運用面で重要な役割を担う

このリリースでは、目に見えるインターフェース改善以上に重要となり得る、プラットフォームとセキュリティの隔たりも解消されています。

Windows では、Codex が複数種類の子プロセスを起動する際に、不要なコンソールウィンドウを抑制するようになりました。対象にはローカルの Model Context Protocol サーバー、コードモードのホスト、パイプ経由で接続されたコマンドが含まれます。

MCP は、モデルを外部ツールやデータソースに接続するためのプロトコルです。ローカル MCP サーバーはバックグラウンドの子プロセスとして実行される場合があるため、予期しないコンソールウィンドウはデスクトップ体験を妨げる可能性があります。

制限的な Windows ランチャーは、埋め込みモードへフォールバックできるようになりました。これにより、プロセス作成ルールによって優先アーキテクチャが動作しない場合に、別の実行経路が提供されます。

このリリースでは、Windows ジョブへの残留所属下でのデーモン起動動作も改善されました。別の修正では、不要な箇所でランチャーの入力および出力ハンドルが接続されたままにならないようにします。

これらの変更はモデルの挙動ではなく、信頼性に対応するものです。管理対象マシン、デスクトップ統合、複数のサブプロセスを作成するターミナルワークフローにとり、特に関連性があります。

セキュリティ境界にも個別の注意が払われています。承認済みコマンドは、コマンド準備時に明示的なファイルシステム拒否設定を失うことなく、その制限を維持するようになりました。

Codex は、書き込み可能なルート配下にある .aws ディレクトリもデフォルトで保護します。これらのディレクトリにはクラウド構成や認証情報が含まれる可能性があり、このデフォルト境界は重要です。

このリリースは、これらの変更によってサンドボックスのリスクがなくなるとは主張していません。ただし、ユーザーの承認と、実行時に適用される権限との間の引き継ぎを、OpenAI が強化していることは示しています。

承認済みのコマンドは、無制限のファイルシステムアクセスと同じではないため、この境界は精査に値します。コマンドの準備時に明示的な拒否設定が破棄されれば、ランタイムはユーザーがレビューした判断を反映しなくなります。

ネットワークが有効な macOS サンドボックスには、TLS 信頼に関する修正が適用されます。この更新により、プロセスの機能を制限する macOS のサンドボックスポリシーである該当の Seatbelt プロファイルで、システム信頼評価が許可されます。

プロキシを必要とするリモート環境でも、実行動作が修正されます。これらの修正は、開発ツールが名目上持つネットワークアクセスと、それをホストするマシンのルールとの間にある一般的な隔たりに対応します。

認証の脆さも改善されます。ローカルのアプリサーバーフローでは、ChatGPT サインイン用ブラウザがより確実に開くようになるはずです。オンボーディングでは、自動起動が適さない場合にログイン URL をコピーするショートカットも提供されます。

ユーザーがタスクを切り替えても、空白のセッションでは下書きが保持されます。スレッドは最初の完了ターンを含む前からアーカイブおよび一覧表示できるため、セッション管理が会話状態に依存しにくくなります。

これらの修正は、このリリースのより広い方向性を補強しています。長時間稼働するエージェントには、印象的な応答だけでなく、永続的な状態と予測可能なプロセス動作が必要です。

不要なウィンドウを開き、下書きを失い、拒否設定を誤って扱い、またはプロキシの背後で失敗するコーディングエージェントは、運用コストを課します。生成コードが許容範囲でも、こうした失敗は導入を阻害し得ます。

オプトインのステアリングには、依然として実環境での検証が必要

この機能の価値は、予測可能なタイミング、明確なステータス表示、そして負荷下での正しい動作に左右されます。

最初の不確実性はレイテンシです。このリリースでは、対象となる呼び出しが新しい入力の到着時に yield できると説明されていますが、時間計測値は公開されていません。ユーザーは、ステアリングがどれほど速く反映されるかを依然として観察する必要があります。

2つ目の不確実性はセマンティクスに関するものです。「interrupt」「preempt」「yield」「stop」は異なる操作を表します。Codex が制御を yield した後も実行中のプロセスは存続し得ますが、ユーザーは作業が終了したと想定するかもしれません。

明確なインターフェースでは、プロセスがアクティブなままか、その出力がまだ届いているか、エージェントがその出力を参照する予定かを示すべきです。この点の曖昧さは、重複コマンドや競合する編集を生む可能性があります。

3つ目の問題は導入です。instant_interrupt はデフォルトで無効であるため、初期の影響はこのフラグを見つけて有効化するユーザーに限られます。

オプトインでの展開はテストの余地を与えますが、利用可能なフィードバックも狭めます。経験豊富なユーザーは、初めてエージェント型コーディングに触れる開発者とは異なる形でこの機能を使う可能性があります。

4つ目の問題は競合状態に関わります。新しい入力は、モデル生成、実行、待機、コンテキスト圧縮の最中に届く可能性があります。各経路はメッセージ順序を保持し、ツール結果が誤った推論ステップに結び付かないようにしなければなりません。

OpenAI によれば、テストは有効時と無効時の動作、繰り返しのステアリング、圧縮中の遅延入力、同じ応答内での後続呼び出しをカバーしています。テストでは、キューイングされたメッセージと直接のツール結果が保持されることも確認しています。

これらのケースは必要ですが、本番セッションではより秩序のない組み合わせが生じます。開発者は1ターン内で繰り返しステアリングし、依頼ファイルの範囲を変更し、権限を拒否し、遅れて届くプロセス出力を受け取るかもしれません。

5つ目の問題は安全性です。より高速なステアリングは、発生しつつあるミスを止める助けになりますが、コマンド承認、サンドボックス制限、リポジトリレビューの代替ではありません。

有害なコマンドは、訂正が届く前に完了する可能性があります。外部サービスも、ローカルエージェントが方針を変えた後にリクエストを処理する場合があります。ユーザーは会話上の中断をトランザクションのロールバックとして扱うべきではありません。

過剰なステアリングのリスクもあります。特にエージェントが以前のコンテキストを保持し、複数の指示が優先度を競う場合、頻繁な訂正は目標を断片化させる可能性があります。

チームにはインタラクション上の慣習が必要になります。ステアリングメッセージでは、何が変わったのか、どの以前の指示を置き換えるのか、現在の実行を続行すべきかを明確に述べるべきです。

自動フォローアッププロンプト候補の削除も、ここでは関連します。Codex 0.159.0 は、それらの候補と関連設定の両方を削除します。OpenAI は、より直接的なユーザー制御を追加する一方で、求められていないプロンプト支援を減らしているように見えます。

このリリースでは、バンドルされた plugin-creator スキルも削除されます。このパッケージング変更をステアリング機能と混同すべきではありませんが、バンドル機能に依存しているユーザーは、アップグレード後にローカル環境を確認すべきです。

懐疑的な見方は明快です。OpenAI はより迅速な介入の仕組みを追加しましたが、それによってタスク成功率が向上するという証拠は、このリリースでは提示していません。

だからといって、この機能が重要でないわけではありません。次の評価課題を定義するものです。実行途中のステアリングは、追加される実行の複雑さを正当化できるほど、無駄な作業を防ぐのでしょうか。

Codex 0.159.0 の後に注視すべき3つのシグナル

次の検証点は、即時中断が実験的な制御機能から、日常のコーディングで信頼できる要素へ移行するかどうかです。

最初のシグナルはデフォルト設定です。OpenAI が後続リリースで instant_interrupt をデフォルトで有効化すれば、それは順序性、保持、インターフェースの明確さに対する自信を示すことになります。

複数のリリースにわたってオプトインを維持する場合は、エッジケースに依然として注意が必要であることを示すでしょう。また、既存のキューイングに関する期待を変える挙動に対し、OpenAI が明示的な同意を求めていることを意味する可能性もあります。

2つ目のシグナルは、繰り返しのステアリングに関する issue とリリースの動向です。メッセージの消失、コマンドの重複、孤立プロセス、遅延出力に関する報告は、即時中断の有用性を弱めます。

サポートされるツール経路を広げる修正は、その有用性を強化します。現在の設計は、モデル応答と長時間実行されるコードモードの exec または wait 呼び出しを具体的に対象としており、あらゆる外部操作を対象とするものではありません。

3つ目のシグナルは競合他社の挙動です。GitHub はすでに、自社製品と SDK を通じて即時ステアリングとキューイングされたフォローアップの両方を文書化しています。他のコーディングエージェントベンダーも、明確な実行途中の制御を提供する同じ圧力に直面しています。

重要な比較は、製品にステアリングと呼ばれる機能があるかどうかではありません。訂正がどれほど速く反映されるか、そしてシステムが残っている実行状態をどれほど正確に説明するかです。

開発者は、機密性の高い作業中に中断へ依存する前に、範囲が限定され元に戻せるタスクで OpenAI Codex 0.159.0 をテストすべきです。有用な試行としては、長いテスト実行、1回のスコープ訂正、存続しているプロセスの確認が考えられます。

Codex が新しい指示を速やかに受け取るかを確認してください。元のプロセスがアクティブなままかも確認してください。続いて、後から届く出力が正しいターンに紐付けられ、放棄したアプローチを復活させないことを検証します。

このリリースは、説得力のある製品上の判断を示しています。ユーザーには、エージェントが誤ったまま完了する前に介入する手段が必要です。実装は今後、より高速な介入が実際のワークロードでも理解可能であることを証明しなければなりません。

OpenAI Codex 0.159.0 を有効化するなら、まず実践的な問いを1つから始めてください。有用な進捗を失わず、何がまだ実行中か不明にならないまま、長いタスクの方向を変えられるでしょうか。この結果は、フラグそのものより重要です。