Lecture 20requirements、plan、progressをMarkdownで管理する
コンテキストを使い切らないために、作業を3つのMarkdownへ分けて引き継ぎます。
3つのMarkdownを作る一番の理由は、きれいな設計書を残すためではありません。 AIとの作業を小さく分け、コンテキストを使い切らないためです。
ワンショットでCodexに「このアプリを作って」と頼むと、要件の精査、コードベース調査、 実装計画、実装までを1つのセッションで抱えることになります。 そのぶん会話が長くなり、AIが使う作業材料であるコンテキストを大量に消費します。
1ワンショット依頼が重くなる理由
たとえば予約アプリに「キャンセル待ち機能」を追加したいとします。 一度に全部頼むと、Codexは次の作業を同じ会話の中で続けて行います。
- 何を作るべきかを質問し、要件を整理する。
- 既存の画面、API、データベース、関連ファイルを調べる。
- どの順番で実装するかを考える。
- 実際にコードを書き、テストし、必要なら修正する。
これは人間で言えば、打ち合わせ、現地調査、作業計画、工事を休憩なしで一気に進めるようなものです。 できなくはありませんが、途中から情報が混ざりやすくなります。
23つのMarkdownでセッションを分ける
そこで、作業の区切りごとに結果をMarkdownへ保存します。 そして次の作業は、新しいセッションを立ち上げて、そのMarkdownを読ませてから始めます。
- requirements.md：何を作るか。ユーザー、課題、必要な機能、やらないことを書く。
- plan.md：どこを調べ、どう作るか。触るファイル、実装順序、確認方法を書く。
- progress.md：どこまで終わったか。完了、未完了、次の依頼内容を書く。
3まずは空のファイルを作る
実際のプロジェクトでは、最初に3つのファイルを作っておくと迷いにくくなります。 置き場所はチームで決めればよいですが、ハンズオンではプロジェクト直下に置く想定で進めます。
- requirements.md：目的、ユーザー、解決したい課題、必要な機能、今回はやらないことを書く。
- plan.md：調査結果、触る予定のファイル、実装順序、確認方法を書く。
- progress.md：完了したこと、確認したこと、残っていること、次の依頼文を書く。
Codexへの依頼例
「このプロジェクト直下に requirements.md、plan.md、progress.md を作ってください。 それぞれ初心者があとから読んでも続きが分かる見出しだけ先に入れてください。 まだ決まっていない内容は未定と書いてください」
4各セッションで頼むことを絞る
ポイントは、1つのセッションに全部やらせないことです。 それぞれのセッションでは、Codexに依頼する範囲をはっきり絞ります。
- セッション1：要望を聞き出してもらい、requirements.mdにまとめる。
- セッション2：requirements.mdを読ませ、コードベースを調査してplan.mdにまとめる。
- セッション3：requirements.mdとplan.mdを読ませ、実装しながらprogress.mdを更新する。
新しいセッションで始める依頼
まず requirements.md と plan.md を読んでください。 その内容だけを前提に、今回の実装を進めてください。 作業が終わったら progress.md に、完了したこと、確認したこと、次に残っていることを追記してください。
5理解確認チェックリスト
- 3つのMarkdownを作る理由が、コンテキスト消費を抑えるためだと説明できる。
- requirements.md、plan.md、progress.mdに何を書くかを説明できる。
- 要件整理、コードベース調査、実装計画を1セッションに詰め込みすぎない判断ができる。
- 新しいセッションでMarkdownを読ませて、続きから依頼できる。