Claude Code に書かせた設計文書を 5 か月後に読んだら、「なぜ作ったか」が逆になっていた

AI コーディングエージェント（Claude Code）に設計文書を書かせると、５か月後に読み直したとき、「なぜ作ったか」が現在の用途で上書きされていた。これは単なる「古い情報」ではなく、意図の反転だ。自作の OpenClaw というエージェント内で、YouTube 字幕の要約が二度要約される問題を解くために、2 月 17 日に `__PASSTHROUGH__` というマーカーで囲んだ出力は加工しない仕組みを実装した。当初の目的は「ツールの出力を そのまま通す」——トークン消費を 800 から 50 に削減する、明快な目的だった。ところが 3 月 3 日、同じ仕組みの使途が逆になる。マーカーの内側は要約だけをユーザーに、外側は全文を LLM だけに持たせるという、反対の配置になった。

そこまでは仕組みの進化で済む話だ。問題は、翌日 3 月 4 日の削除事故から復旧するセッションで、設計文書に「なぜこの仕組みが必要か」という節が追加されたことだ。その時点で Claude Code が目にしたのは、現在のコード、その前日に変わったばかりの用途、そして直前の削除事故だけ。実装時の会話や人間の記憶は、セッションが違うので引き継がれない。そのため、現在の状態から「筋の通った理由」を逆構成した——結果、その説明が「最初の実装理由」の位置に入ってしまった。実装時は「ツール出力を加工させない」が本命だったのに、設計文書には「要約だけ見せるため」と書かれていた。同じマーカーが、目的は逆のまま、名前だけ残った。

これは生産側のミスではなく、エージェント型開発の本質的な課題だ。AI に設計を書かせる場合、「前のセッションで何を考えていたか」という文脈は、明示的に読ませなければ継承されない。履歴や開発日誌を渡さなければ、現在のコードから見える「必要性」だけが「本来の理由」の位置に入る。中小企業が内製でこうしたツールを運用するなら、「created: 2026-02-17」「用途が 3 月 3 日に逆転」という時点を明記することが、後の混乱を防ぐ唯一の手だ。AI の効率と人間の記憶の断層——そこに生じた歪みを、ドキュメント規律で埋める他に方法はない。