Codex CLI プロンプトと複雑なタスクの分割手法

安定したエンジニアリングプロンプトは、少なくとも目標動作、現在の証拠、許容範囲、遵守すべき制約、検証方法を説明する。停止条件も同じく重要で、プロトコルの曖昧さ、依存関係の変更、破壊的操作に直面した際は、Codex に先に質問させるべきである。

未検証の実装案を要件のように偽装しないこと。再現手順とユーザーが観察できる振る舞いを提供し、Codex にまず既存の設計を調査させた上で、リポジトリと整合する実装を選ばせる。

根本原因が不明な場合は、まず読み取り専用のサンドボックスを使う。Codex にエントリーポイントの特定、データフローの追跡、問題の再現、候補案の列挙を求め、計画を確認した後に書き込み可能なセッションを開始する。

この分割は計画が必ず正しいことを保証しないが、ファイルが変更される前に人間が範囲の誤判断、プロトコルの破壊、情報の欠落を発見できるようにする。

「フロントエンド半分、バックエンド半分」と機械的に分割してはいけない。より確実な分割順序は、事実の調査、契約の確認、最小の縦断パスの実装、例外パスの補完、検証とレビューである。各ステップには独立した成果物と継続条件がある。

あるステップでユーザーによる API の選択、データベース移行、新規依存関係の追加が必要な場合は一時停止し、モデルにビジネスオーナーの代わりに不可逆な決定をさせないこと。

ファイルパス、シンボル名、再現コマンド、既存の用例を明確に示すことで、無関係なファイルの読み取りを減らせる。ログやコードベース全体を一度に貼り付けず、まず最小の再現を残し、Codex に必要に応じて読み取らせる。

長期的なリポジトリの事実は AGENTS.md に置き、専用フローは Skill に置き、現在のタスクの受け入れ基準はプロンプトに残す。すべてを1つのプロンプトに詰め込むと、矛盾が増えコンテキストを消費する。

「修正後に知らせて」では、品質判断が自然言語の要約に委ねられる。より良いプロンプトは、Codex が実行できるチェックを指定し、コマンド、終了ステータス、まだ未検証の部分を提示するよう求める。

UI タスクには比較可能なスクリーンショットを、データ変換には固定の入出力を、並行処理の問題にはストレステストやレーステストを提供する。検証シグナルが明確であるほど、エージェントは自律的に反復できる。

方向の逸脱に気づいたら即座にスコープの拡大を止め、具体的な不一致を指摘して制約を再確認する。誤った方案の上に新たな要件を連続で追加してはいけない。

タスク完了後、繰り返し現れるリポジトリの事実は AGENTS.md に定着させる。一時的な選択を永続化してはいけない。有効なプロンプトは、実際の失敗に対する継続的な修正から生まれる。