結論から書く。私はClaude Codeのメモリを「1個の巨大なメモ」として使うのをやめ、プロジェクトごとにファイルを分割し、ユーザーレベルのメモリには各プロジェクトの要約と参照先だけを置く、という2階層構成にしている。本業のFDE（企業のAI導入支援）と複業を同時並行で回している以上、1つのセッションで扱う文脈がプロジェクトをまたいで頻繁に切り替わる。この切り替えコストをメモリ設計でどう下げるかが、今回のテーマだ。
なぜ1つのメモリファイルでは破綻したか
最初は素直に、Claude Codeのユーザーメモリ（~/.claude配下）に、進行中の案件やプロジェクトの情報をすべて時系列で書き足していた。これは早い段階で破綻した。
理由は単純で、本業のクライアントワーク、storeforge（ドロップシッピング）、aerial-earth-studio（空撮動画）、afflow（SNSアフィリエイト）、民泊、マイクロ法人運営、家計管理——性質もフェーズも全く違う複数の文脈が1つのファイルに混在すると、セッションを開くたびにAIが読み込むコンテキストが肥大化する。しかも「今日は民泊の話をしたいのに、AIの応答にstoreforgeの前提が混ざる」というノイズが起き始めた。人間側も同じで、1つの長いメモを毎回スクロールして自分が今どこにいたか思い出すのは、すきま時間の運用と相性が悪い。
今の構成: インデックス1枚＋プロジェクトごとのファイル
今の運用は、MEMORY.mdという1枚のインデックスファイルに、各プロジェクト・各関心事のリンクと1行要約だけを並べ、詳細は個別ファイル（project_fde.md、project_storeforge.mdのような命名）に分離する形にしている。
- インデックス（MEMORY.md）: 「何がどこにあるか」の目次だけを持つ。1プロジェクト1行、詳細ファイルへのリンク付き
- プロジェクトファイル: そのプロジェクト固有の確定事項・運用ルール・進行中の論点だけを持つ。他プロジェクトの情報は書かない
- フィードバックファイル: 「PRはマージ後ブランチ自動削除」のような、プロジェクト横断で効くルールはプロジェクトファイルと分けて独立させる
この分離のポイントは、AIがセッション開始時に読むのはインデックスの薄い一覧であり、個別プロジェクトの詳細は「今回の作業に関係がありそうだ」と判断されたときだけ読みに行く、という段階構造にしたことだ。結果として、storeforgeの作業をしているときに民泊やaerial-earth-studioの詳細情報でコンテキストが埋まることがなくなった。
プロジェクトファイルに何を書き、何を書かないか
分割しただけでは不十分で、各ファイルに「何を書くか」の基準を決めないと、結局また肥大化する。私が実践している基準は次の3つだ。
- 確定事項だけを書く: 検討中・未決定の内容は書かない。「〜すべきか検討中」のようなメモは古くなった瞬間にノイズになる。決まったことだけを残し、検討過程はissue側に置く
- 運用ルールは短く命令形で: 「PRのみ・main直push禁止」のように、AIが次回そのまま従える形で書く。背景説明は最小限にする
- その事業固有の情報しか書かない: 事業横断のルール（コミットメッセージの書式、issue管理の一元化ルールなど）はフィードバックファイル側に集約し、プロジェクトファイルには絶対に重複させない
この3つ目が地味に効いている。最初のうちは「念のため」で横断ルールを各プロジェクトファイルにもコピーしていたが、ルールを1つ変えるたびに複数ファイルを直す羽目になった。今は横断ルールの置き場所を1箇所に決め切ったことで、更新コストが1箇所で済むようになった。
セッションをまたいだ一貫性をどう担保するか
複数事業を並行運用していると、「先週このプロジェクトでどう決めたか」をAIが覚えていないと同じ議論を繰り返すことになる。これを防ぐために、意思決定が発生したセッションの終わりには、その場でプロジェクトファイルへの追記まで済ませることをルールにしている。
具体的には、「これは今後も踏襲する運用にする」という判断が出た瞬間に、そのセッション内で該当ファイルを直接編集させる。後でまとめて書こうとすると必ず抜け漏れが起きるので、決定と記録を同じセッション内で完結させるのがポイントだ。これにより、次に別のプロジェクトのセッションを開いたときも、インデックスを見れば「ああ、あの件はこうなったんだった」とすぐ辿れる状態を維持できている。
まとめ
- ユーザーメモリを1つの巨大ファイルにすると、無関係なプロジェクトの文脈が混ざりコンテキストが肥大化する
- インデックス1枚＋プロジェクトごとの個別ファイルという2階層構成にし、必要なときだけ詳細を読みに行く設計にした
- プロジェクトファイルには確定事項・命令形の運用ルール・そのプロジェクト固有の情報のみを書き、横断ルールはフィードバックファイル側に一元化する
- 意思決定が出たその場でファイルに反映することで、セッションをまたいだ一貫性を保っている
次回は、この本業側のAI活用知見を踏まえた、複業それぞれでのAIツール運用の違いについて書く予定だ。
