Codexを使うなら、/goalとサイドチャットを押さえておきたい

記事の概要

OpenAI Codex CLIを長い開発作業で使い倒すための機能解説記事。長い仕事を続ける /goal、途中の質問を分けるサイドチャット（/side）、実行中の指示変更と予約送信という3つの操作を軸に、「作業を続ける条件」「質問する会話」「指示を送るタイミング」を切り分けて使う方法を、認証処理の修正という具体例で丁寧に説明しています。9月のCLI更新で追加された「下書きを残したままCodexからの質問へ答える」機能にも触れています。

作業中に送る文章を3つに分ける

Codexが期限切れセッションの不具合を調査している途中で送りたい文章は、意図によって3種類に分けられます。

• CLIのデフォルトでは、実行中の Enter は現在のターンへの追加指示、Tab は次のターンへの予約（キー設定を変更している場合はその割り当てに従う）
• 変更してはいけない仕様を次のターンまで待たせると、修正が進んでから戻す作業が増える。文章の内容に合わせて送るタイミングを選ぶ

注意: Enterで追加指示を送っても、実行済みの変更は取り消されない

実行中の追加指示で、完了した編集やコマンドが自動的に取り消されるわけではありません。「変更しないで」と送るなら、何がすでに変わったかも確認します。

エラー応答のJSON形式は、既存のクライアントが使っています。
この形式を保ったまま修正してください。
すでに変更していれば、その差分を確認して対応してください。

「待って」だけより、何を止めたいのかが伝わります。全部取り消したいのか、特定の変更だけ取り消したいのかで必要な操作が変わります。Tabで予約するときも「それもお願い」のような曖昧な依頼ではなく、現在の作業が終わった後でも読める依頼にします。

/side で説明を聞く場所を分ける（サイドチャット）

• /side は現在の会話から一時的に分岐した別の会話を開く。主会話の内容を参照しながら、説明や検討だけを進められる（/btw でも開ける）
• 質問への返答と修正のやり取りを別々に追えるため、主会話が汚れない
• 制限: サイドチャットの中からさらにサイドチャットは開けない。CLIのレビュー中も利用できない
• これはファイル分離の操作ではない。別実装案を編集して比較したい場合は Worktree を使う仕事として分ける

/side 期限切れセッションの判定について、境界時刻の前後で動作が変わる理由を説明してください。コードは変更しないでください。

Claude Code の /btw との違い

• Claude Codeにも /btw があるが、ツールを使う権限がない。既に読んだコードや実行結果からは答えられるが、ファイルを新しく読んだりテストを実行したりはできない
• 「今のコードでもそうなっているか」を確かめたいなら、主会話やSubagentへ依頼する
• 脇の質問へ答えてもらっただけでは作業の指示は変わらない。/btw で仕様を決め直したなら、採用する条件を主会話へ送り直す必要がある

説明に納得した後、条件を変えて考えられるか

• 説明を聞いた後に「比較演算子を変えたら、一致時刻の結果はどう変わるか」を自分で予想してから、コードとテストで確かめる
• 「時刻の取得元が変わっても、このテストだけで確かめられるか」のように、自分の予想と異なる結果になる条件も質問する
• 主会話が未決の仕様に依存する編集を進めているなら、調査だけ進めてもらい編集は待ってもらう
• 実装を任せて空いた時間の一部を「自分が見落とした条件を調べる」ことに使う。その時間まで次の依頼で埋めると、判断を担いながら判断を覚える機会を減らすことになる

サイドチャットで決めた仕様を主会話へ伝える

• 疑問が解消しただけならそのまま主会話へ戻る。実装の条件を変えたいなら、作業へ反映したい結論と、それによって変わる検証だけを主会話へ渡す
• サイドで話した文章を全部貼る必要はない

境界時刻の仕様は、期限と一致した時点で拒否する方針です。
期限の直前、一致、直後をそれぞれ検証してください。
既存の許容時間を増やして通す変更はしないでください。

• 別案を継続して実装するなら /fork が候補。説明を聞くだけか、別案の実装と検証まで依頼するかで使い分ける

Codexからの質問には、下書きを残して答えられる

• 9月のCLI更新で、作業中に表示された質問に主会話へ送る途中の下書きを残したまま回答できるようになった（選択肢または自由入力）
• 下書きが消えてしまう手間が減り、Codex側も回答と独立して進められる調査を続けられる
• ただし下書きを残して回答できても、仕様を決める必要は変わらない。影響調査は進められても、エラー形式を変える判断には回答が必要
• 選択肢が意図に合わなければ自由入力で条件を補う（例: 「HTTPステータスとJSONのキーは維持してください。内部の関数分割は変更して構いません」）

/goal には修正内容と完了条件を書く

/goal は、その会話で達成したい目的を状態として残す機能。調査・修正・検証を何度も往復する仕事で、「続けて」と送る回数を減らせます。

悪い例（終わり方が曖昧）：

/goal 認証の実装を改善する

良い例（満たす状態と確かめ方を書く）：

/goal 期限切れセッションを受け入れる不具合を修正する。
境界時刻の直前、一致、直後を対象に再現テストを用意し、修正後に成功させる。
有効なセッションの動作と、既存のエラー応答形式は保つ。
テストを削除したり、時刻の許容範囲を広げたりして成功扱いにしない。
検証環境が不足するなら、試した手順と不足している条件を報告する。

• どう直すかはすべて決めず、原因調査の結果に応じて次の作業を選べる。一方で何をもって成功とするかは固定する
• 単発の編集を何でもゴールにする必要はない。結果によって次の調査先が変わる不具合修正や、検証を繰り返す仕事で使いやすい

Claude Code の /goal との違い

• Claude Codeでも /goal に完了条件を書くと継続できるが、通常はターン終了時に別の評価用モデルが会話を読んで達成判定し、未達成なら次のターンへ進む
• 評価用モデルはファイルを読んだりテストを実行したりしない。作業したClaudeが会話に示した結果だけが判断材料なので、ゴールには「どのテストで何を確かめるか」まで書く
• 一定間隔で確認する /loop とは「次に動く理由」が違う
• 操作: 引数なし /goal で状態確認、/goal clear で解除、条件変更は設定し直す
• ゴールが解除されるのは達成時だけではなく、達成不能と判断された時や人が対処すべきエラーでも解除される。権限モードは変わらない

ゴールは「待ち時間ごとに動く予定」ではない

• ゴールは現在の会話に属する。プロジェクト全体に毎回適用する AGENTS.md や、定時に始める定期タスクとは役割が違う
• Codexはターン終了・会話が待機状態になったところで継続を判断する。別処理が残っていたりユーザー入力待ちの状態で際限なく次の仕事を始める仕組みではない
• 「明朝もう一度CIを見て」のような時刻条件の依頼は定期タスクの方が適切
• 予算上限で止まったことはゴール達成と同じではない。何を確認できて何が残っているかを受け取り、終了状態だけ見て修正成功と読み替えない

目的を変える・止める・再開する

• ゴールの文章は最大4,000文字。調査資料や長い仕様はファイルに書いてゴールから参照する
• 目的を編集したら、できた差分と新しい完了条件を突き合わせる（「JSON形式を変えてよい」→「既存形式を保つ」に変えたなら応答の差分と検証を見直す）。指示の変更は実行済みの編集まで自動で戻すわけではない

1つの修正で順番に使ってみる（実践フロー）

1. 不具合の再現方法と修正後の確認方法を決め、/goal で目的を残す
2. 修正の途中で理由を知りたくなったら /side へ質問する
3. サイドチャットで仕様の判断が必要だと分かったら、採用する条件を主会話へ返す
4. 現在の修正へ影響する条件は実行中（Enter）で送り、修正後の文章作成は次ターン（Tab）へ予約する
5. Codexからの質問には選択肢や自由入力で答える
6. 最後に、ゴールに書いた条件・差分・テスト結果を突き合わせる。返事を送ったことと、その条件が実装へ反映されたことは別だから

この記事から学べること

• Enter（追加指示）/ Tab（予約）/ /side（質問）という入力タイミングの使い分けで、エージェントとの協調作業が整理される
• /goal には「何を修正し、どの検証が成功したら完了か」を書く——完了条件の明示が長時間タスクの品質を守る
• 「説明を聞いて納得した」だけでなく条件を変えた時の動作を自分で予想して検証するという、AI時代の理解確認の姿勢が学べる
• サイドチャット（/side・/btw）の権限差や、Claude Codeの /goal の評価モデル挙動など、ツール間の違いも押さえられる