Codexに作業を依頼する文の書き方:目的・触る範囲・完了条件を先に決める
AIを使いこなすClaudeで執筆し、GPTで自動校閲・修正しています。
Codexへの依頼文で最初に決めるのは、「何を達成したいか(目的)」「どこまで触ってよいか(範囲)」「何をもって終わりとするか(完了条件)」の3点です。この3点が曖昧だと、Codexは足りない部分を推測で補うので、仕上がりが期待とずれたり、レビューしにくい大きな差分になったりします。 OpenAIのCodexベストプラクティスは、効果的なプロンプトの要素として Goal(目的)、Context(関連ファイルや資料)、Constraints(設計基準や安全要件)、Done when(完了条件)の4つを挙げています。これらを入れるとCodexが範囲を保ちやすくなり、仮定が減り、レビューしやすい成果物になる、という趣旨です。以下ではこの4要素を日本語の依頼文に落とし込み、悪い例と直した例を並べます。 なお、developers.openai.com の Codex 関連ページは、2026年10月27日の確認時点で learn.chatgpt.com に転送されました。本記事の公式情報はそのページを開いて確認した内容で、各ページに更新日や対象プランの明記は見当たりませんでした。
4要素を、依頼文では3つの問いにまとめる
公式の4要素は、依頼を書く側から見ると次の問いに置き換えられます。
- Goal、依頼文で答える問い：何が、どう変わればよいか
- Context、依頼文で答える問い：どのファイル・資料を見るべきか(触る範囲の入口)
- Constraints、依頼文で答える問い：触ってはいけないもの、守る規約は何か
- Done when、依頼文で答える問い：何が確認できたら終わりか
Codexのプロンプトガイドによると、IDE拡張では開いているファイルがコンテキストに自動で含まれます。CLIではパスを明示するか、/mention や @ のパス補完でファイルを指定できます。使う環境に応じて、必要なファイルをコンテキストに含めましょう。
そのまま使える依頼文テンプレート
次のテンプレートは、上の問いを埋める形にした編集上の提案です。角括弧の部分を置き換えて使ってください。
【目的】
[何が、どう変わればよいか。1〜2文。ユーザーから見た挙動で書く]
【見てほしい場所】
- [path/to/main-file] ← 主に変更する想定
- [path/to/related-file] ← 参照のみ(読むだけ)
【制約】
- 変更してよいのは [ディレクトリ/ファイル] のみ
- [公開API・設定ファイル・依存関係] は変更しない
- 既存の [命名規則・書式] に合わせる
- 迷う点は、推測で進めず質問または選択肢で返す
【完了条件】
- [実行するテスト/lint のコマンド] が通る
- [再現手順] を実行して [期待する結果] になる
- 変更したファイルと理由を一覧で報告する
【進め方】
まず該当箇所を調べて計画だけ提示してください。承認後に編集します。最後の「進め方」は、複数ステップの作業向けです。プロンプトガイドでは、複数ステップの作業で /plan を使い、編集前に調査と方針を提案させる方法を紹介しています。変更が小さく影響範囲が明らかなときは省いて構いません。
悪い例と直した例
以下は説明用の架空の例で、実際にCodexで実行した結果ではありません。プロジェクト名やファイル名も仮のものです。
悪い例
ログイン画面を使いやすくして。ついでに古いコードも整理しといて。目的が「使いやすく」では測れず、「ついでの整理」で範囲が際限なく広がります。終わりの基準もないため、Codexも人も完了を判断できません。
直した例(1タスク=1目的に絞った版)
【目的】
ログイン失敗時に、エラーメッセージがパスワード欄の下に表示されるようにしたい。
現状はページ上部にしか出ず、気づかれにくい。
【見てほしい場所】
- src/pages/Login.tsx ← 主に変更する想定
- src/components/FormField.tsx ← 参照のみ
【制約】
- 変更はログイン画面とそのテストに限る
- 認証APIの呼び出し部分は変更しない
- 「古いコードの整理」は今回は対象外
【完了条件】
- npm test のログイン関連テストが通る
- 誤ったパスワードでログインを試すと、パスワード欄の下にメッセージが出る
- 変更したファイルと理由を一覧で報告する
【進め方】
まず該当箇所を調べて計画だけ提示してください。「整理」は別のタスクに切り出します。2つの目的を1回で頼むと、どちらの差分か見分けにくくなるためです。
迷ったときの判断表
書けない項目があるときは、その項目自体を最初の依頼にするのが近道です。
- 触るファイルが分からない、対処の例：調査と計画だけを先に依頼し、編集は承認後にする
- テストで完了条件を書けない、対処の例：手動の再現手順と、期待する表示や出力を文で書く
- 目的が2つ以上ある、対処の例：タスクを分け、1依頼に1目的にする
- 毎回同じ規約を書いている、対処の例：依頼文ではなくAGENTS.mdに移す
- 仕様の判断が人に残っている、対処の例：「推測で決めず質問する」を制約に入れる
依頼の前後に人が確認すること
依頼前に確認するのは、テンプレートの空欄を自分で埋められたかどうかです。埋められない欄は、Codexに任せる前に自分で決めるか、調査依頼に変えます。機密情報(認証情報、顧客データなど)は依頼文に貼らず、必要なら説明用のダミーに置き換えてください。
依頼後は、完了条件の項目ごとに結果を見ます。公式のベストプラクティスは、変更の要求だけで終わらせず、テスト作成、関連チェックの実行、結果の確認、レビューまでを含めて頼むよう勧めています。Codexの「できました」という報告を見ただけで終わらせず、差分が「触る範囲」に収まっているかを確認するのは人の仕事です。
繰り返し書く内容はAGENTS.mdに移せます。このファイルはCodex向けの追加指示で、グローバルとプロジェクトのスコープがあります。プロジェクト内ではルートから作業ディレクトリまでのファイルが連結され、後から読まれる下位階層の指示が先の指示に優先します。読み込み対象の合計サイズ上限は既定で32KiB(project_doc_max_bytes)です。ビルド・テストのコマンドやコーディング規約はここに置き、依頼文には今回のタスク固有の目的・範囲・完了条件を書くと整理できます。
