Claude Code に長期タスクを任せて初日に方針が7回変わった話と、そのあと固定した3ファイル

Claude Code に長期タスク、セッション切断で方針が7回変わった。その後、たどり着いた解決策は「記憶」ではなく「記録」だった。SESSION が切れた瞬間に文脈は消える。ここを「AI の記憶機能」で埋めようとするのは幻だ。代わりに CLAUDE.md に読む順番を固定し、ops/STATE.md に現在地を集約する。つまり、セッション再開時は「前と同じ AI」が覚醒するのではなく、「別のインスタンスが引き継ぎ資料を読む」という前提に立つ。これは実務的には重要な転換だ。なぜなら、社内の属人化も全く同じ構造だからだ。「あの人がいないと回らない」というのは、その人の頭に手順があって、書いてないところが問題なのだ。記事では STATE.md の 7 つの項目（一行サマリ、数字、完了、進行中、次の一手、待ち、未解決の問題）を実例で示している。特に「この数字が取得できず、と書くこと。0 ではなく測定不可」という指摘は、引き継ぎを読む側の誤読を防ぐ実装設計だ。次のセッションで「ゼロだったから計測の仕組みを作らなくていい」と誤読されるのを防ぐ。さらに ops/DECISIONS.md に「棄却した案と理由」を必ず残すこと。SaaS から受託に切り替え、またそれも撤回——初日で 7 回も方針が動いた。同じ検討を二度やらないためには、削除した判断の理由が不可欠だ。中小企業のシステム刷新でも、レガシー VBA から自動化ツール移行のときと同じ。道具を変える前に、「記録する仕組み」を作ることが全てを決める。手順書ではなく「何を読めば再開できるか」から逆算する設計は、実務ではめったに見ない。セッションが切れてもそこから再開できるのは、それがセッションに依存しない記録の設計だからだ。