Claude Code で複数プロジェクトを1人で運用するための memory システム設計🧠
はじめに
Claude Code を使って複数のプロジェクトを並行運営し始めると、ある時点で「memory システムが破綻している感じ」が出てくる。
僕は4つのプロジェクト（音×映像のエンタメアプリ、デジタルガーデン型データベース、パーソナル AI、キャリア構築エージェント）を Claude Code で並行運営している。半年間運用した結果、memory ファイルが50近くに達し、自分でも何がどこにあるか分からなくなった。
最初はツール（Obsidian、HTML 可視化など）に逃げようとしたが、別の Claude セッションをコンサル役として呼び出して相談したところ、こう返ってきた。
あなたの本当の課題はファイル配置でも可視化でもない。memory の所有権モデルが未定義であることだ。
これが核心だった。本記事では、この「所有権モデル」を明文化して memory を再設計した過程を共有する。
問題：複数プロジェクトで Claude Code を使うと起きる3つの破綻
複数プロジェクトを Claude Code で運営すると、以下の3層の問題が必ず発生する。
-
所有権の不在
プロジェクト A 固有の決定に見えるが、実はブランド全体の思想にも関わる、というケース。両方に書くと食い違い、片方にしか書かないと存在を忘れる。 -
発見性の欠如
各プロジェクトの Claude Code セッションは、自プロジェクトの memory しか自動で読まない。他プロジェクトに書いた重要事項は「存在することすら忘れられる」。 -
規模超過
memory ファイル50超え。人間の作業記憶（マジカルナンバー7±2）を完全に超える。Claude が context に注入する負荷も増える。
「なんとなく memory が機能してない」の正体はこの3層。
解決：母艦＋サブの2層構造
アーキテクチャ
母艦プロジェクト（1つ）
├── 戦略・ロードマップ・ブランド・思想・横断資産
└── ~/Documents/Business/
サブプロジェクト（複数）
├── 個別の事業・プロダクト
├── 技術仕様・実装ログのみ
└── 母艦の memory を symlink で参照
母艦が単一ソースオブトゥルース。各サブプロジェクトは自分専用の技術ファイルだけ持ち、横断的な情報は母艦から symlink で参照する。
横断 vs 固有の判定基準
memory ファイルを作る時、最初にやるのは「横断か固有か」の判定。
横断（母艦に置く）の条件
戦略・ロードマップ・フェーズに関わる
ブランド全体に関わる
自分の内面・価値観・過去の体験に関わる
思考の OS・フレームワーク
複数プロジェクトを横断する判断
固有（プロジェクト側に置く）の条件
そのプロジェクトでしか使わない技術仕様
実装ログ・コード判断
そのプロジェクト固有の進捗・タスク
二重所属の symlink 解決
「横断的だが、特定プロジェクトと深く関わる」ケースは symlink で解決する。
ln -s ~/.claude/projects/-Users-kodai-Documents-Business/memory/project_a_principle.md
~/.claude/projects/-Users-kodai-Documents-ProjectA/memory/
母艦が単一ソース、プロジェクト側からも参照可能、編集はどちらからでも同じファイルが更新される。食い違いが構造的に発生しない。
3種類のファイル設計
各プロジェクトに3種類のファイルを配置する。
-
CLAUDE.md：プロジェクト憲章
Claude Code がセッション開始時に自動で読む。プロジェクトのルール・目的・関連プロジェクトをコンパクトに記述。 -
MEMORY.md：Claude が自動読込する索引
memory ディレクトリのファイル一覧と一行要約。Claude はここを見て、必要なファイルだけ読みに行く。
最上部に「⚠️ 未処理ハンドオフ」セクションを置くのが重要。後述の /handoff で自動更新される。
- INDEX.md：人間が運用ルールを確認する地図
横断 vs 固有の判定基準、カテゴリ分類、ハンドオフ規約、メンテナンスルールをまとめた「memory システムの憲法」。
このファイルを書く作業自体が、所有権モデルを確立する作業そのもの。30分〜1時間で書ける。
スラッシュコマンドで仕組み化
ファイル設計だけだと運用が人間の規律に依存する。最小限のスラッシュコマンドで半自動化する。
/handoff <project>
母艦の会話で深く議論した内容を、プロジェクト側セッションに引き継ぐためのファイルを自動生成する。
~/.claude/commands/handoff.md にプロトコルを記述
実行すると以下を生成：
project_handoff_to_<project><topic_slug><date>.md
生成されたファイルは母艦に保存され、プロジェクト側にも symlink で参照される。次回プロジェクト側セッションで「⚠️ 未処理ハンドオフ」セクションから優先読み込みされる。
/coldview
判断前の現実性レビュー。コミットメント前に「数字の根拠」「顧客獲得経路」「時給換算」「機会コスト」を冷徹にチェックする。
ただし冷徹なだけだと心が折れるので、2段構造にする。
Phase 1：コールドレビュアー（VC 審査担当人格、温度ゼロ）
Phase 2：リカバリーコーチ（事実ベースの希望を語る）
「事実は厳しく、人は支える」というコーチング構造。
運用ルール3つ
ルールは3つまでに削る。判断が必要なルールはルールではなく負債。
迷ったら母艦に作る
プロジェクト側で memory を新規作成しない
セッション開始時に未処理ハンドオフを最優先で読む
これだけで運用が成り立つ。
ツールに逃げる誘惑への警告
まとめ
Claude Code で複数プロジェクトを回す時の本当の課題は、技術ではなく所有権モデル。
完全版
本記事は概念の骨格のみ。以下は完全版（note）にまとめている：
/handoff /coldview のスラッシュコマンド完全コード
50ファイル超え時の対処パターン
ハンドオフ完了儀式の詳細（処理済みハンドオフを「真実の唯一の住所」にしないための運用）
コンサル役 Claude が指摘した「所有権モデル未定義」の発見プロセス
実際の /coldview 適用例（3シナリオ計算・時給換算・機会コスト分析）
失敗パターン4種と回避策
今日から始める実装ステップ（30分・1時間・2〜3時間の段階別）
Claude Code 完全実装ガイド：個人事業家が複数プロジェクトを1人で回す memory システム
僕の独立計画と背景：AIと2人で生きていく｜大学生が独立するまでの5年計画
X：@nekokichi_jp
Discussion