目次
OpenAIは2026年11月1日、刷新したCodex の機能を改めて案内しました。主な変更は、音声でタスクを始めたり進行を修正したりできること、複数のエージェントを追跡するビュー、 worktreeを使った並列作業、の再開や分岐を扱いやすくしたことです。ターミナルで一つの依頼を完結させる道具から、複数の作業を分けて監督する入口へ役割が広がっています。
この記事は、Webアプリやを日常的に保守する開発者を対象に、刷新されたCodex CLIを実務へ入れるときの設計を整理します。新機能をすべて同時に有効化するのではなく、単一セッション、サブエージェント、worktree、レビューをどの順で組み合わせるかを決めることが重要です。機能の提供状況はプラン、クライアント版、組織設定、段階的な展開によって異なるため、2026年11月3日時点の公式資料を基準にしています。
スポンサーリンク
刷新で変わったのは操作画面より仕事の分け方
| 機能 | 公式資料で確認できる役割 | 導入時に決めること |
|---|---|---|
| 音声 | タスク開始、進捗確認、方向修正 | 音声で決める範囲と文字で残す受け入れ条件 |
| エージェント表示 | 複数タスクの作業状況を追跡 | 並列化する仕事と統合責任者 |
| サブエージェント | 独立した調査や実装を分担 | 入力、成果物、終了条件、重複範囲 |
| worktree | 同じGitで作業場所を分離 | 開始点、化、統合、破棄の手順 |
| 再開・分岐 | 保存した会話を続ける、別案を派生させる | どのとセッションを対応させるか |
重要なのは、エージェント数を増やすこと自体ではありません。調査、実装、テスト、レビューのを見て、同時に進めても互いの前提を壊さない部分だけを分けます。公式のサブエージェント資料も、コードベース探索や複数工程の機能実装など、並列性が高い作業を例に挙げています。一方で各エージェントは個別にモデルとツールを使うため、単一実行よりトークン消費が増えると明記されています。
最初は単一セッションの基準を作る
並列化の前に、対象リポジトリで一つのタスクを最後まで通します。Codex CLIはプロジェクトのディレクトリでcodexを起動し、ファイルの調査、編集、ローカルコマンドの実行を同じセッションで扱えます。公式CLIガイドでは、モデル、推論量、権限、コマンドをタスクに合わせて選び、作業の前後にGitのチェックポイントを作ることを勧めています。
- 対象ブランチと開始コミットを記録する。
/statusでセッション構成を確認する。/permissionsで編集・コマンド実行の境界を確認する。- 受け入れ条件と実行するテストを指示へ含める。
/reviewまたはcodex reviewで差分を別工程として読む。
この基準がないまま複数エージェントへ分けると、失敗の原因がモデル、指示、環境、統合のどこにあるか分かりません。まず一つの小さな不具合修正で、変更範囲、テスト時間、レビュー指摘、手戻りを記録します。次に、同程度の仕事を分担したときに完了時間や品質が改善するかを比べます。未実施のテストを成功扱いせず、エージェントの要約よりコマンド結果と差分を優先します。
スポンサーリンク
サブエージェントは独立した成果物へ分ける
分担しやすいのは、同じファイルを同時に書き換えず、結果を明確に受け渡せる作業です。例えば、エージェントAが既存仕様と呼び出し箇所を調査し、Bがテストケースを列挙し、Cが移行資料を確認する構成です。主担当は三つの結果を受け取り、実装方針を決めます。調査結果を統合する前から三者に実装させると、互いに異なる前提で同じ箇所を編集しやすくなります。
現在の公式資料では、DevDayの案内に「/agentsビュー」という表現がある一方、サブエージェント資料は対話中の確認に/subagentsを示し、CLIリファレンスはcodex agentsをエージェント用のコマンドセンターとして掲載しています。名称や入口がクライアント版で異なる可能性があるため、記事のコマンドをそのまま打つのではなく、更新後にcodex --helpと利用中のCLI内ヘルプで確認してください。
指示には「調べて」の一語ではなく、入力と出力を定義します。調査なら対象ディレクトリ、確認する仕様、返すファイル名と行番号、未確認事項を指定します。テスト担当なら再現条件、期待値、実行コマンド、環境依存の条件を求めます。主担当が必要とする形式を揃えると、長い会話を読み直す時間を減らせます。
同時編集はworktreeで作業場所を分離する
複数のタスクがコードを書き換える場合は、会話を分けるだけでは不十分です。同じ作業ディレクトリを共有すると、一方の未コミット変更を別のエージェントが前提にしたり、ファイルを上書きしたりします。CodexのworktreeはGit worktreeを使い、同じリポジトリから別のチェックアウトを用意します。各作業場所はファイルを分けながらGitのを共有できます。
CLIリファレンスでは--worktreeを、対話セッション、codex fork、codex execなどで利用できる安定機能として掲載しています。worktreeはGitリポジトリが前提です。公式のworktree資料では、Codex管理のworktreeは通常一つの会話専用で、開始ブランチのHEADを基準に作られ、既定ではdetached HEADになると説明されています。成果を残す場合は、統合前にコミットやブランチの扱いを決めます。
- 基準ブランチを最新にし、未コミット変更の扱いを決める。
- 依存しないタスクごとにworktreeを作る。
- 各タスクで変更、テスト、コミットを完了する。
- 主担当が差分とテスト結果を読み、統合順を決める。
- 統合後の状態でテストを再実行する。
- 不要になったworktreeを確認して整理する。
worktreeは競合を消す機能ではありません。別々の場所で同じ関数を変更すれば、統合時に競合します。の移行、共有型定義、依存関係の更新など、他の作業が前提にする変更は先に一本化した方が安全です。並列化する単位はファイル数ではなく、仕様上の依存関係で決めます。
スポンサーリンク
音声は方向修正に使い、合否条件は文字で残す
音声は、作業を開始する、進捗を聞く、優先順位を変えるといった短い監督に向きます。長いエラーログ、正確なパス、設定値、受け入れ条件まで口頭だけで渡すと、聞き間違いや確認漏れを見つけにくくなります。最初の目的と途中の方向修正を音声で行っても、最終的な合否条件、変更禁止箇所、実行すべきテストはテキストで残します。
OpenAIの音声資料は、利用できるプラン、段階的な展開、ワークスペース設定、クライアント更新が提供状況に影響すると説明しています。既存タスク内の音声が表示されない場合は、デスクトップアプリとCodexホストの更新を確認します。CLI刷新の案内だけを根拠に、すべての端末や組織で同じ音声操作が使えると判断しないでください。
再開・分岐・レビューを一つの記録に結び付ける
codex resumeは保存した対話を続け、codex forkは元の履歴を保ったまま別案を派生させます。分岐は、二つの実装案を比較するときに便利ですが、会話が同じでも作業ツリーの状態が同じとは限りません。セッション名、開始コミット、worktree、成果コミットを対応付けます。「昨日の続き」ではなく、「コミットabc123を基準にした処理の修正」のように識別できる状態を残します。
最終レビューは、各エージェントの自己申告を集めるだけでは完了しません。CLIのレビュー機能は、未コミット変更、基準ブランチとの差分、特定コミットを対象にできます。統合後の差分を対象に、受け入れ条件から外れた変更、テスト不足、不要な依存関係を確認します。レビューが指摘を返さなかったことは、品質保証や本番動作の証明ではありません。人が仕様と影響を確認する工程を残します。
導入判断は速さと手戻りを同時に測る
試行では、開始から最初の差分までの時間だけでなく、統合後にテストが通るまでの時間、競合解消、レビュー指摘、再実行回数、利用量を記録します。三つのエージェントが早く差分を作っても、統合に長くかかるなら分け方を見直します。逆に、調査とテスト設計を先に並列化して主担当の判断が速くなるなら、コードを書かせなくても効果があります。
並列化しない方がよい作業も先に決める
要件がまだ一つに定まっていない機能、同じ中心ファイルを触る小さな修正、順番どおりにしか検証できないデータ移行は、複数エージェントへ分けるほど調整が増えます。障害対応でも、複数の担当が同じ環境へ修正を加えると観測条件が変わります。この場合は一つのセッションで仮説、確認、変更を順に進め、ログの読み取りや資料確認だけを別担当へ切り出します。
また、成果物が「調査メモ」「テスト一覧」「実装差分」のように区別できない仕事は分担に向きません。各担当の終了条件が「よい案を考える」だけでは、主担当が同じ検討を繰り返します。成果物の受取人、保存場所、必要な根拠、未解決項目の書き方まで決め、統合できる形式にします。
比較用の記録を一枚にまとめる
対象タスク：
開始コミット：
使用したセッションとworktree：
各担当の入力と成果物：
実行したテストと結果：
統合時の競合：
レビューで見つかった問題：
再実行回数：
完了までの時間：
次回は分ける／分けない作業：この記録はモデルの性能順位を作るためではなく、自分たちのリポジトリで再現できる手順を探すために使います。モデルやCLIの版、権限、依存関係が違えば結果も変わります。速さだけで採用を決めず、統合後の修正量と人が確認した時間まで含めます。
おすすめの導入順は、単一セッションで基準作成、読み取り中心のサブエージェント、worktreeを使う小さな並列実装、音声による監督の順です。各段階で、結果の確認方法と停止条件を増やします。刷新されたCodex CLIの価値は、エージェント数を最大化することではなく、ターミナルから作業を分け、隔離し、再び一つの差分として評価できる点にあります。
関連記事
CodexとClaude Codeを比較｜用途別の選び方とモデルの使い分け・併用・連携
スポンサーリンク
