AIとの開発、なぜ「続きから」がうまくいかない?4つのファイルで防ぐ方法

AI活用術

課題

ChatGPT、Claude Code、Codexなどを使って開発していると、会話や日をまたいだ瞬間に「あれ、何を決めたっけ?」「どこまで進んでたっけ?」となりがち。そのたびに前回の話を思い出す・説明する時間がかかって、地味にしんどい。

この記事でわかること

  • AIとの会話が途切れるたびに「続きから」がうまくいかない理由
  • 4つのファイル(PLAN/TASKS/MILESTONES/PROGRESS)で迷子を防ぐ具体的なやり方

解決できたこと

自分のProjectにPLAN.mdTASKS.mdMILESTONES.mdPROGRESS.mdという4つのファイルを用意するだけで、次に開くAIチャットが迷わず「続きから」を再開できるようになる。

本文

AIとの開発、なんで「振り出しに戻る」のか

ChatGPTやClaude Codeとの会話って、Windowを閉じたり日をまたいだりすると、それまでの決定事項も作業の途中経過もキレイに忘れられてしまう。こっちも「前回どこまで進んだっけ」「何を決めて、何をまだ決めてないんだっけ」を毎回思い出すハメになる。地味に一番時間を食ってるのは、実はこの「思い出す作業」だったりする。

原因はシンプルで、決定事項と進捗を会話の中だけに置いているから。会話の外に置き場所(普段更新する基準になるファイル)を用意しておけば、AIも自分も同じ場所を読むだけで再開できるようになる。

自分もAIと一緒に個人開発しているモバイルアプリのProjectで、実際にこの仕組みを使っている。ここからは、その運用で実際に起きたこと(うまくいった話も、やっちゃった失敗の話も)を記録ベースで紹介していく。

workspace/を、AIの「記憶」代わりにする

やることは意外とシンプル。Project直下にworkspace/というDirectory(フォルダ)を作り、そこに今の方針・進行中の作業・進捗の記録をファイルとして書き出しておくだけ。AIに新しい会話で作業を頼むときは、まずworkspace/の中を読んでもらうところから始める。

これはAI Tool側の特別な機能じゃなくて、こちら側で用意する「読んでもらう場所」のルールにすぎない。ChatGPTでもClaude Codeでも、Codexでも同じ考え方で使える。

最小限、この4つのファイルだけでいい

workspace/には、最低限次の4つのファイルを置く。役割を分けておくと、AIも自分も「今どれを見ればいいか」で迷わなくなる。

ファイル役割更新するタイミング
PLAN.md現在の方針、今合意していること方針が変わったとき
TASKS.md進行中・未着手の作業(Ticket)と、その時点での進捗メモ作業が進んだとき
MILESTONES.md大きな区切りごとの進捗(正の記録)Ticketの状態が変わったとき
PROGRESS.md決定と作業結果を時系列で追記する記録(追記のみ、書き換えない)決定・完了のたびに

PROGRESS.mdだけは少し特殊で、過去の記述を書き換えず、常に末尾に追記していくのがポイント。後から読み返したときに「いつ何を決めたか」を辿れるようにするための工夫で、これから紹介する実例も全部、自分のProjectのPROGRESS.md(2026年7月28日〜29日の記録)から確認したもの。

実例1: テストが直らないまま、作業を中断した話

共通のHome画面を追加している最中に、あるテスト(app_smoke_test.dart)が原因不明のまま失敗する問題にぶつかった。原因を調べ始める前に、AIツールの利用制限が近づいてきて、その場で作業を中断せざるを得なくなった。

こういうとき、AIには次の3点だけTASKS.mdの該当TicketとPLAN.mdに書き残してもらうようにしている。

  • 何を実装済みか
  • 何が未解決か(今回なら、失敗しているテストの内容)
  • 次のセッションで何から再開すべきか

次にAIと話し始めたとき、この記録を読むだけで「app_smoke_test.dartの失敗原因調査から再開する」とすぐ分かり、そのままTicketを完了させられた。完了時点でテストは全件PASSしている(ちなみに、失敗していたテストが具体的にどう直ったかの経緯までは記録に残っていない)。

ここから言えるのは、「中断はいつ起きるか予測できない」という前提で動くこと。作業がきれいに終わる瞬間だけを想定して記録を後回しにしていると、想定外の中断に弱い。中断しそうな作業ほど、その都度「今何が済んでいて、何がまだなのか」を書き出しておくと安心できる。

実例2: 「決めたこと」を書く前に、実装を始めてしまった話

ある機能(回数制限付きの取り消し機能)の仕様をAIとのやり取りで決めたすぐ後、AIはTASKS.mdにその決定を書き込む前に、そのままコードの実装へ進んでしまった。

これに気づいたのは自分自身。「今回の実装方針、Taskに起票してから作業できてる?」とAIに聞いたことで発覚した。さらに「なんで守れなかったのか、ルール自体を見直してほしい」と伝えた。

AIが原因を分析してくれた結果分かったのは、「新しいTicketを起票する場面」と「既存Ticketの中で未決事項を決める場面」を同じ重みで扱えていなかったこと。前者は起票という行為そのものが記録になるけど、後者は「決めた」という事実だけが会話の中に残ってしまい、ファイルへの反映を忘れやすい。この分析を踏まえて、AI運用ルールに「既存Ticket内の決定も、新規起票と同じ重みで扱い、決定した直後にファイルへ反映してから実装する」という一文を追記した。次の作業では、決定した直後にファイルを更新してから実装に進めたことを確認できている。

これはAI側が起こしたやらかしと、その場での修正の記録。大事なのは「なぜ先に書かなかったのか」で反省するより、「どの場面でルールが漏れやすいか」を具体的に特定して直したこと。次に同じ失敗を防ぐには、こっちの視点が効く。

実例3: 「直す作業」と「確認する作業」、順番を変えたら結果が変わった話

このProjectでは、実装が終わったあとに「ドキュメントを実装に合わせて直す作業(同期)」と、その区切りで問題が残っていないか見る「監査」を、別の工程として設けていた。

あるTicketでは、監査を同期より先にやってみた。すると監査が見つけた問題は「ドキュメントが実装に追いついていない」という、同期をまだやっていないから当然出てくる指摘だけ。一方、別のTicketで同期を先にやってから監査をしたら、同期作業そのものが生成した内容の誤りを監査が見つけられた。

この2件を比べて、AI運用ルールに「実装・検証 → 記録への追記 → 文書の同期 → 監査 → Commit確認」の順番を明記した。監査を「同期できてるかの確認」で終わらせず、「同期した内容が正しいかの確認」までちゃんと機能させるための順番。

AIが作った文書やコードは、作った工程の中だけで正しさを確かめるより、別工程の目(ここでは監査)を通したほうがいい。ただ、その効果は工程の順番次第で変わってくる、というのがこの実例から見えてくるポイント。

今日から使える、最小のTemplate

自分のProjectでも、workspace/に次の4ファイルを置くところから始められる。内容は自分のProjectに合わせて書き換えてよい。

workspace/
├── PLAN.md        # 現在の方針
├── TASKS.md        # 進行中・未着手の作業と進捗メモ
├── MILESTONES.md    # 大きな区切りごとの進捗
└── PROGRESS.md      # 決定と結果の時系列記録(追記のみ)

PLAN.md の最小例

# PLAN

## 現在の方針
(今合意していることを書く。方針が変わったら古い記述を残さず書き換える)

## 未決事項
(まだ決めていないことを書く)

TASKS.md の最小例

# TASKS

## T-001: (作業名)
- status: in-progress
- 次にすべきこと: (再開するときに最初に読む一文)

PROGRESS.md の最小例

# PROGRESS

## 2026-08-04
- (決めたこと・起きたこと・結果を書く。過去の記述は書き換えず追記する)

新しい会話をAIに頼むときは、最初に「workspace/PLAN.mdworkspace/TASKS.mdを読んで、続きから進めてください」と伝えるだけでOK。

運用をしんどくしないための、ちょっとしたコツ

記録を残すこと自体が目的になってしまうと、AIとの作業のたびに記録のコストがかさんでいく。今回の3つの実例から言えそうなのは、次の2点(ここは記録に残っていた事実そのものではなく、実例を振り返って見えてきたAIなりの気づき)。

  • 中断しそうな作業ほど、こまめに「今の状態」を書き残す。逆に見通しよく進んでいる作業なら、区切りのタイミングでまとめて記録すればいい
  • 「決めた直後にファイルへ書く」を徹底する対象は、新規に起票する作業だけじゃなく、既存の作業の中で決めたことも含める

workspace/の4ファイルは、完璧な記録の仕組みを作るためのものじゃない。次にAIと作業を始めるとき、会話の続きを説明する時間が減れば、それだけで十分効果がある。


この記事は、筆者が実際に個人開発しているアプリ(モバイルアプリのProject)の開発記録(2026年7月28日〜29日)を基に、独自調整したAIが下書きを作成し、筆者が事実確認・編集を行った上で公開しています。

PAGE TOP
タイトルとURLをコピーしました