TL;DR
- Claude Codeの運用を「会話」ではなく「プロジェクトの仕様ファイル」に寄せる動きが加速
- 仕様・設計・禁止事項をMarkdownで固定し、セッションが変わっても前提がズレにくくなる
- ソロでも“毎日回せる”レベルに落とすには、まず Spec-first（仕様→実装） を習慣化するのが勝ち筋
何が起きたか
Claude Codeでよく起きる失敗は、同じ指示をしているのに毎回アウトプットが微妙にズレることだ。
そこで「プロジェクトメモリ」として、リポジトリ内に“前提ファイル”を置き、毎回そこを読み込ませてから作業する運用が推奨され始めた。
たとえば、最低限これだけでも効果が出る。
product.md: 誰の何を解決するか、非目標は何かtech-stack.md: 技術スタック、採用理由、禁止技術workflow.md: SDD/TDD、PR粒度、レビュー観点、禁止事項styleguide.md: コード規約、命名、例外処理の方針
なぜ今重要か
AIコーディングは「モデルが賢いほど勝つ」ではなく、前提がズレないほど勝つ局面に入っている。
ソロは特に、同じ場所を何度も行き来する余裕がない。仕様が固定されるだけで、修正ループ（作って→壊して→戻す）が大幅に減る。
さらに、複数ツール併用（IDE補完 + CLIエージェント + レビュー）が一般化し、“人間が覚えている前提”は破綻しやすい。前提をファイル化して共有するのは、チームだけでなくソロにも効く。
ソロビルダー視点（どう使うか）
最短で効くのは「この2つ」を固定すること:
- 仕様（何を作るか / 作らないか）
- 変更ルール（どういう粒度で、何を禁止するか）
コツは、分厚いドキュメントを作らないこと。
“AIに守らせたいことだけ” を短いMarkdownに書き、毎回読ませる。
関連プロダクト
スコア内訳
| 評価軸 | スコア |
|---|---|
| SNS反応量 | 14/20 |
| メディアカバレッジ | 14/20 |
| コミュニティ反応 | 16/20 |
| 技術的インパクト | 18/20 |
| ソロビルダー関連度 | 18/20 |
| 合計 | 80/100 |
所見: 「AIに何をやらせるか」より、「AIに何を守らせるか」に焦点が移った。毎日回す運用の実戦論として、ソロビルダーへの効きが強い。