依頼文に何を書き、どこで計画を先に出させるか

ここまでで、どこで動かし、どれだけ考えさせ、どこまで触らせるかが決まりました。残っているのは、何を頼むかです。

依頼文はコードではないので、文法の間違いで止まることはありません。そのぶん、書き方の差がそのまま結果の差になります。ここでいう差は、うまい言い回しのことではなく、必要な情報が入っているかどうかです。

依頼に入れるのは3つ

OpenAI のベストプラクティスは、依頼文に入れる既定として3つを挙げています。文脈、制約、完了の条件です。

文脈は、どのファイル、どのフォルダ、どの資料、どの例、どのエラーが関係するかです。制約は、従うべき規約や慣習です。完了の条件は、何が真になれば終わりと言えるかです。

第3回で出した例を、この3つに当てはめてみます。

src/lib/date.ts の formatDate を、和暦にも対応させてください。    ← 文脈
既存の呼び出し側は変えず、第2引数で切り替える形にしてください。  ← 制約
テストは tests/unit/date.test.ts に追加し、
npm test が通ることを確認してください。                          ← 完了の条件

3行しかありませんが、3つとも入っています。長さは関係ありません。

抜けたときに一番困るのは完了の条件

3つのうち、省略されやすいのが完了の条件です。そして、省略したときの損が一番大きいのもここです。

文脈が足りなければ、関係ないファイルを読みに行く時間が増えます。制約が足りなければ、周りと違う書き方のコードが出てきます。どちらも、差分を読めば気づけます。

完了の条件が書かれていないと、終わりを判定するのが人の目だけになります。テストを走らせたかどうか、型検査を通したかどうかが、依頼した側からは見えません。「できました」と言われたものが実は壊れている、という一番面倒な形になるのはここです。

逆に「npm test が通ることを確認してください」の一文があると、Codex は自分でテストを走らせ、落ちていれば直し、通るところまで持っていきます。人が差分を読む前に、機械で判定できる部分は済んでいる状態になります。

完了の条件は、毎回書くには長くなりがちです。毎回同じなら、依頼文ではなく AGENTS.md に書きます。第9回で扱います。

ファイルは名指しする

文脈を渡すとき、Codex に探させるより、こちらから名指しするほうが速く確実です。公式ドキュメントによれば、@ に続けてファイル名やフォルダ名を書くことで、そのファイルを文脈として指定できます。

「認証まわりを直して」ではなく「@src/auth/session.ts の有効期限の扱いを直して」と書く。探す時間が減るだけでなく、こちらが場所を分かっているという情報自体が制約として効きます。見当違いのファイルを大きく書き換えられる事故が減ります。

場所が分からないときは、依頼の前に場所を聞くだけの往復を挟んでも構いません。読み取りだけなら、第5回の read-only の枠で足ります。

変更の前に計画だけ出させる

変更が複数のファイルにまたがるときは、いきなり書かせないほうが安く済みます。

プランモードは、大きめの作業を、読んで確かめられる手順の並びに分解してから着手するための状態です。公式ドキュメントによれば、/plan と入力するか Shift+Tab で切り替えられます。/plan このサービスの移行手順を提案して のように、切り替えと同時に依頼を書くこともできます。

使いどころは3つあります。

1. 変更が複数のファイルにまたがるとき
2. 手順の順番が結果を左右するとき（データの移行など）
3. 自分自身がまだやり方を決めていないとき

3つ目を挙げているのは、これが一番多いからです。やり方が決まっていないまま依頼を出すと、返ってきたものを評価する基準も決まっていないことになります。計画を先に見ると、少なくとも「この道筋でよいか」という1つの判断に絞れます。

逆に、直す場所も直し方も決まっている作業では、計画を挟むぶん往復が増えるだけです。

返ってきた計画の、どこを読むか

計画が出てきたとき、全部を同じ密度で読む必要はありません。見る場所は3つです。

ひとつ目は、手順の数です。10を超えていたら、依頼が大きすぎます。分けてください。

ふたつ目は、最初の1手です。ここが「既存の実装を調べる」で始まっているか、いきなり「新しいファイルを作る」で始まっているか。後者のとき、既存の似た仕組みを見落としている可能性があります。

みっつ目は、戻せない操作が入っていないかです。データの削除、外部への送信、本番への反映。入っていたら、その手順の前で必ず止まるように依頼を足します。

待っている間に、次を積んでおく

作業中の待ち時間に手が空くのは、思ったより邪魔です。気が散って別の作業を始めると、戻ってきたときに差分を読む集中が切れています。

公式ドキュメントによれば、Codex が作業している間に Tab を押すと、次の順番に回す依頼やコマンドを積んでおけます。差分を読みながら「次はこれを頼もう」と思ったものを、その場で入れておく。待ち時間を、次の依頼を組み立てる時間に使えます。

出てきたものを、もう一度見させる

自分で差分を読む前に、機械の目を1つ挟むこともできます。

/review は、作業ツリーの中の変更を見て、見つけた問題をまとめます。公式ドキュメントによれば、振る舞いの変化と、足りていないテストに重点が置かれます。正確な変更内容を見たいときは /diff を続けます。

自分が書いた依頼に自分で答えたものを、自分で確認させることになるので、これだけで十分とは言えません。ただ、「テストが足りていない」のような機械的に気づける指摘は、人が読む前に片づいているほうが読む側は楽です。人の目は、機械が気づけないところに使うという配分になります。

コマンドライン版なら、対話の外からも走らせられます。

codex review --uncommitted

長い会話が続いて、返答が的外れになってきたと感じたら /compact です。それまでのやり取りを要約した状態に畳みます。第4回で書いたとおり、話題が変わったところで畳むのが目安です。

依頼文を使い捨てにしない

ここまで書いてきたことを毎回手で打つのは続きません。

同じ依頼を繰り返すなら、依頼そのものを保存できます。よく使う手順に名前をつけて呼び出す仕組みが用意されていて、これは第10回で扱います。リポジトリ全体に効かせたい規約なら AGENTS.md に書きます。第9回です。

この講座の後半が「覚えさせる」に割かれているのは、依頼文の良し悪しを毎回の気合いで保つのが無理だからです。うまく書けた依頼は、書けたその日に置き場所を決めてください。

次の回

ここまでで、手元で Codex を動かす道具はそろいました。第7回からは土台に移ります。AIが書いたものを読み、戻し、他人に見せるための仕組みです。まず Git から始めます。

参照した公式情報

• OpenAI「Prompting」「Best practices」「Developer commands」「Codex CLI」（developers.openai.com/codex、2026年9月時点）
• コマンドライン版の引数は codex-cli 0.154.0 を執筆環境へ導入して取得