進捗.mdで制作ログを残す — AI協働時代の作業記録術（連載㉒）

連載第22回です。前回（連載㉑）の最後で予告していた、「日本の測地系がわかる本」の制作中にずっと更新し続けていた 進捗.md というファイルの話です。派手な技術ネタではありませんが、AIと協働で長期の制作物を作るときに一番効いた運用だったと感じています。

なぜ記録が要るのか — AIは会話ごとに文脈を忘れる

Kindle本の制作は、企画から出版まで複数回のセッションに分かれて進みました。AIとの協働作業には、人間同士の共同作業にはない特有の問題があります。会話が終わると、それまでの経緯がリセットされることです。

「なぜ第4章と第7章を本文から外したのか」「なぜK-2（靴と靴下の比喩）は使わないと決めたのか」——こうした決定は、その場では明確な理由があっても、次のセッションが始まった瞬間には失われます。同じ説明を毎回やり直すのは非効率ですし、悪いことに「前回何を却下したか」を忘れたAIが、一度ボツにした案をまた提案してくることもあります。

そこで、制作の全決定事項を時系列で1つのMarkdownファイルに書き残し、新しいセッションの冒頭で必ず読ませる運用にしました。それが 進捗.md です。この考え方自体は、GPRM側で扱った「正典ファイル1枚でAIに文脈を渡す」運用（製品構成やURLをまとめるレジストリ方式）と発想は同じで、対象を「製品情報」から「1冊の本の制作工程」に絞ったものと言えます。

進捗.mdの構造

実際に使っていたファイルは、大きく次のブロックで構成されています。

ブロック	内容
状態サマリ	直近の更新内容・現在の工程・次のアクションを冒頭にまとめる
版方針	どの章を収録し、どの章を圧縮・統合するかの方針
章別状態表	各章の初稿・レビュー・画像・確定状況を一覧化
画像状態表	各図版が新規作図か流用か、生成済みかどうか
要確認リスト	数値・事実で裏取りが済んでいない項目と、暫定的にどう丸めたか
決定事項ログ	「いつ・何を・なぜ決めたか」を時系列で追記

たとえばこの本の場合、状態サマリの1行には「D統合案 §14（図の相互活用・1巻側）完了」のように、その日どこまで進んだかが1行で分かる書き方をしていました。章別状態表は◯✅△の記号で埋めるだけの簡単な表ですが、次のセッションを開始した瞬間に「あとどの章のレビューが残っているか」が一目で分かります。

要確認リストが特に効いた場面もあります。標高改定量のような具体的な数値について、「元記事では地点別の値までは確認できなかったため、本文は”最大約60センチ”に丸めて記載した」という判断の理由まで書き残しておくことで、連載⑯（数値は全部裏取りする）の方針を後から見返しても迷わずに済みました。

書き方のコツ — 結果だけでなく理由と却下案も

進捗.mdを書くうえで意識していたのは、「何をしたか」だけでなく「なぜそうしたか」「他にどんな案を検討して却下したか」まで残すことです。

たとえば、ある比喩を本文に使うかどうかで一度検討し、結局見送った判断がありました。その際は結果（見送り）だけでなく、判断した日付・理由（すでに別の理由で本文から削除済みの構成と衝突するため）まで1行に残しています。こうしておくと、後日「あの比喩、結局どうなったんだっけ」と再検討しかけたときに、決定事項ログを見るだけで「すでに検討済みで却下した」と分かり、同じ議論を繰り返さずに済みます。

まとめると、書き方のコツは次の3点です。

状態サマリは最新の1〜3行だけ更新し、詳細は下の決定事項ログに追記する（サマリが肥大化しない）
却下した案も理由つきで残す（同じ再検討を防ぐ）
数値・事実は「確認済み」と「未確認（暫定的にこう丸めた）」を明確に分ける（要確認リストの運用）

効果 — セッション再開が数分で済む

この運用を始める前は、セッションの冒頭でその都度「これまでの経緯」を説明し直す必要がありました。進捗.mdを読ませるようになってからは、AIに「進捗.mdを読んでから続きをやって」と伝えるだけで、章の状態・直近の決定・要確認事項まで一通り把握した状態から作業を再開できるようになりました。

体感としては、セッション再開のたびに数分〜十数分かかっていた説明のやり直しがほぼゼロになった、というのが一番大きな変化です。特に、連載⑭（AI辛口編集レビュー）のような複数回のレビューサイクルを回す工程では、「前回どこまで直したか」を忘れずに続きから着手できることが、そのまま作業速度に直結しました。

Kindle本『日本の測地系がわかる本』表紙

ブログ・開発にも使える汎用形

この運用は本の制作に限った話ではありません。ブログ記事の執筆規約や、アプリ開発のリポジトリ構成を扱う際にも、同じ発想の「正典ファイル」を使っています。実際、GCVP/GPRM/GDEのブログ規約・URL・命名規則をまとめた正典ファイルも、この進捗.mdと同じ「1ファイルに集約し、セッション開始時に必ず読む」という原則で運用しています。