Codexに計画を立ててもらう

「よい感じに直して」と頼むと、思っていた範囲より大きな変更が返ってくることがあります。そんなときは、変更前にCodexと完成条件をそろえると、結果を判断しやすくなります。

この記事では、実装へ入る前に小さな計画を作り、確かめてから作業を始める依頼方法を紹介します。特定の画面にある計画モードの操作説明ではなく、普段の依頼文で使える方法です。

計画が役立つ場面を選ぶ

複数のファイルにまたがる修正、原因がまだ分からない不具合、完成後の見た目に複数の案がある作業では、先に計画を作る価値があります。誤字一文字など、対象と答えが明らかな変更に長い計画書を作る必要はありません。

計画で決めるのは、主に「何を変えるか」「何を保つか」「どう確認するか」の三つです。作業時間の予測だけで完成を判断しないようにします。

例：案内ページに目次を付けたい

ここでは、次の構成の小さな案内ページを想定します。実際の自分のファイル名に置き換えて使ってください。

guide-sample/
  index.html
  styles.css
  README.md

最初の依頼は、たとえば次のようにできます。

index.htmlの案内ページに、見出しへ移動できる目次を付けたいです。
まずindex.htmlとstyles.css、README.mdを読み、変更前の計画を出してください。
この段階ではファイルを編集しないでください。

完成条件：
- ページ上部から各見出しへ移動できる。
- スマートフォンでも目次が画面からはみ出さない。
- 既存の本文と見出しの意味は変えない。

計画には、変更するファイル、既存リンクへの影響、確認方法を書いてください。
確認できない前提があれば、事実と分けて示してください。

計画を受け取ったら、次の図の順で確かめます。実装の前に完成条件を見直すことで、後から「そこまで変えてほしくなかった」を減らせます。

各段階で確認してから、次の操作へ進みます。

1. 1完成条件読者が確認できる結果を決める
2. 2調査と計画対象ファイル・影響・確認方法を整理
3. 3実装合意した範囲を変更する
4. 4結果を確認操作・表示・差分を完成条件と比べる

具体的な依頼と、結果の確かめ方は本文にあります。

計画を了承しただけではファイルは完成していません。実装後の確認までを一つの作業として考えます。

計画のどこを読めばよいか

「調査→実装→テスト」だけでは、今回の変更を判断する材料が足りません。目次の例なら、次のような具体性を求めます。

たとえば既存の見出しIDを付け直す計画なら、「今ある見出しリンクを保ってください」と修正を依頼します。表の内容は計画の見本であり、自分のサイトで確認された結果ではありません。

合意した範囲を明示して作業へ進む

計画が目的に合えば、次のように続けます。

その計画で実装してください。
既存の本文と見出しIDを維持し、目次に必要な変更へ絞ってください。
実装後は各目次リンクと狭い画面の表示を確認してください。
変更したファイル、確認結果、未確認の項目を最後に示してください。

途中で新しい問題が分かった場合は、当初の範囲で解決できるものかを分けます。小さな実装判断まで毎回止める必要はありませんが、公開先の変更や本文の大幅な書き換えなど、目的に影響する変更は計画を見直します。

計画が長すぎる・曖昧なとき

長い専門用語の説明が続くなら、「今回変更するファイルと完成条件だけを、五項目以内で説明してください」と依頼できます。

調査前から「問題ありません」と断定する計画なら、「どのファイルを読んで判断したか、未確認の点は何か」を確認します。計画は予想を含むため、実装前にすべての成功を保証するものではありません。

逆に計画だけが繰り返し更新され、実装へ進まないなら、合意済みの範囲を示して「この範囲は実装と検証まで進めてください」と伝えます。

完成の判定まで残す

作業後には、目次をクリックして目的の見出しへ移動するか、自分でも一つ確かめます。Gitを利用しているなら変更差分の確認で、関係のない本文が変わっていないかを見られます。

最初の依頼を整理したい場合は作業依頼の書き方、そもそもプロジェクトの構成が分からない場合はプロジェクトの読み解き方へ進めます。この記事の目次追加は説明用の課題であり、Codexによる実装成功の実測報告ではありません。