Codexに大きな開発作業を依頼するときは、いきなり「全部作って」と頼むより、先に目的・対象ファイル・完了条件を伝えて作業計画を作ると進め方を確認しやすくなります。計画はコードそのものではなく、何を調べ、どこを変更し、どう動作確認するかを整理した設計図です。
この記事では、Codexで作業計画を作る依頼文、計画を確認するポイント、短い作業と大きな作業での使い分け、実装途中に計画を見直す方法を紹介します。
初心者の疑問: Codexに計画を作ってもらえば、そのまま任せて大丈夫ですか？
Codexで作業計画を作るメリット
作業計画を先に作ると、変更範囲と確認方法を実装前に把握できます。特に、複数の画面を変更する機能追加や、既存コードを大きく整理する作業では、途中で目的がずれるリスクを減らせます。
計画に入れるとよい情報は次のとおりです。
| 項目 | 書く内容 | 例 |
|---|---|---|
| 目的 | 何ができるようにしたいか | 設定画面から通知を切り替える |
| 現状 | すでにある機能や制約 | 通知の表示処理はある |
| 対象 | 調査・変更してほしい範囲 | lib/settings とテスト |
| 完了条件 | 何を確認できれば終わりか | ON/OFFを切り替えて再起動後も保持 |
| 確認方法 | 実行するテストや操作 | flutter test と手動確認 |
ポイント: 「機能を追加する」だけでは完了条件が曖昧です。「設定を変更し、アプリを再起動しても値が残ることを確認する」のように、利用者が確かめられる状態まで書きます。
作業計画を依頼する前に整理すること
計画を依頼する前に、次の順番で情報をまとめます。
- 最終的に利用者が何をできるようにしたいかを書く
- 現在のコードで分かっていることと、まだ調べていないことを分ける
- 変更してよい範囲と、変更したくない範囲を決める
- 成功したと判断する条件を、画面操作やテストで書く
- 不明点がある場合は、計画の前に確認質問を出すよう指定する
たとえば「ログイン機能を改善する」では広すぎます。「ログイン失敗時に、利用者が次に取る行動を分かるようにする。認証方式は変更しない。既存の成功時の画面遷移を維持する」と書くと、調査範囲が絞られます。
そのまま使える依頼文
次の依頼文をコピーし、角括弧の内容を自分の作業に置き換えてください。
このリポジトリを調査し、実装前の作業計画を作ってください。
目的:
[利用者が最終的にできるようにしたいこと]
現状:
[すでに分かっていること。分からない場合は「未調査」と書く]
対象範囲:
[変更してよいファイルや機能]
制約:
[維持したい仕様、使ってはいけないライブラリ、対応OSなど]
完了条件:
[画面操作、テスト、ビルド結果など、確認できる条件]
まず関連ファイルを調査し、次の順番で説明してください。
1. 現在の構成と関係するファイル
2. 実装方針と変更箇所
3. テストまたは手動確認の方法
4. 想定されるリスクと未確定事項
情報が不足している場合は、計画を確定する前に確認質問を3つ以内で出してください。
実装は、私が計画を確認してから始めてください。この依頼文の大切な点は、「まず調査し、実装は後」と区切っていることです。計画を読んでから、対象範囲や完了条件を修正できます。
初心者の疑問: 対象ファイルが分からないときは、ファイル名を指定しなくてもいいですか？
最初から正確なファイル名を知っている必要はありません。「まずリポジトリを調査し、関係するファイルを理由付きで示してください」と依頼すれば、入口を探すところから始められます。ただし、変更してほしくない場所がある場合は、先に明記してください。
Codexが作った計画の確認ポイント
計画を受け取ったら、次の4点を確認します。
変更範囲が広がりすぎていないか
目的に関係しないリファクタリングや、不要なライブラリ追加が含まれていないかを見ます。初心者の場合は「今回の目的に必須でない変更は分けてください」と伝えると安全です。
各作業に完了条件があるか
「認証処理を修正する」だけでなく、「失敗時にエラーメッセージを表示し、既存テストが通る」のように確認可能な表現になっているか確認します。
前後関係が自然か
テストを先に直すのか、実装後に追加するのかなど、順序を確認します。設定ファイルやデータ形式を変える場合は、既存データとの互換性確認が計画にあるかも重要です。
実行するコマンドが安全か
削除、移行、外部サービスへの送信など、取り消しにくい操作が含まれていないか確認します。必要なら、まず読み取り専用の調査やバックアップ確認を計画に追加します。
チェックリスト: 目的が1文で説明されている／変更対象のファイルと理由が分かる／完了条件が操作またはテストで確認できる／不要な変更が分離されている／危険な操作の前提条件が書かれている
短い作業と大きな作業の使い分け
すべての作業に長い計画が必要なわけではありません。
| 作業の規模 | 依頼方法 | 計画の目安 |
|---|---|---|
| 文言変更や小さなバグ修正 | 目的と確認方法を直接依頼 | 数行の手順で十分 |
| 画面とデータ処理の変更 | 調査、変更、テストを分けて依頼 | 変更ファイルを一覧化 |
| 複数機能にまたがる改修 | 設計文書を作ってから実装 | 判断理由と進捗を残す |
OpenAIの公式Cookbookでは、長時間かかる複雑な作業向けに、PLANS.md のような実行計画をリポジトリに置く方法が紹介されています。これはCodexが後から再開するときにも、目的や進捗を確認しやすくする考え方です。ただし、記事内の方法は公式機能の必須設定ではなく、プロジェクトで採用する運用方法の一例です。
補足: PLANS.md は、作業計画を保存するためのMarkdownファイルです。短い修正ならチャット内の計画だけで十分な場合もあります。
計画を修正してから実装を始める
計画に問題がなければ、「この計画で実装を開始してください。各段階で変更内容と確認結果を短く報告してください」と続けます。
計画を変えたい場合は、実装開始前に具体的に伝えます。
失敗例: 「いい感じに進めて」とだけ返し、対象範囲やテスト方法を確認しないまま実装を始める。
改善例: 「管理画面の変更は今回含めないでください。まずデータ保存部分だけ実装し、既存テストを通したあとに画面側へ進んでください。」
実装中に新しい事実が分かり、当初の計画と合わなくなることもあります。その場合は、計画を黙って無視させるのではなく、「新しく分かったこと」「計画への影響」「変更後の完了条件」を整理してから続けてもらいます。
注意: Codexの計画は、リポジトリを調査した時点の提案です。実装前に差分、テスト、依存関係、機密情報の扱いを人が確認してください。計画に書かれたコマンドを、意味が分からないまま実行しないようにします。
よくある質問
計画だけ作ってもらい、コードは変更しないようにできますか？
できます。依頼文に「このターンではファイルを変更せず、調査結果と計画だけを返してください」と書きます。実装開始の合図を別にすることで、変更前の確認がしやすくなります。
計画はどのくらい細かくすればよいですか？
次の作業と確認方法が分かる程度が目安です。関数名まで決める必要はありませんが、対象ファイル、変更の理由、テスト方法がない計画は粗すぎます。反対に、まだ調査していない実装の細部まで断定する計画は、後で修正が増えます。
途中で計画を変更しても問題ありませんか？
問題ありません。仕様や既存コードの事実が変わったのではなく、調査で新しい情報が分かったために計画を更新することは自然です。変更理由を残しておくと、後から差分を見直すときにも役立ちます。
次にやること
次にやること: 小さな修正を1つ選び、「目的」「対象範囲」「完了条件」の3項目だけを添えて、まず計画作成を依頼してください。計画を読み、変更してよい範囲を確認してから実装へ進みます。
まとめ
Codexで作業計画を立てるときは、目的だけでなく、現在の状態、対象範囲、制約、完了条件を伝えます。まず調査と計画だけを依頼し、変更箇所とテスト方法を確認してから実装を始めると、初心者でも作業の全体像を追いやすくなります。
最初に試すなら、今抱えている小さな修正を1つ選び、完了条件を1文で書いてCodexに計画を作ってもらいましょう。
コメント