Claude Code複数プロジェクト管理とバックアップ戦略
Claude Codeで仕事をしていると、扱うプロジェクトはあっという間に増えます。コーポレートサイト、SaaSプロダクト、クライアント案件、記事制作、スキル開発、SEO実験、どれも別物ですが全部Claude Codeで動かしていると「この20個近いプロジェクトをどこに、どう保存するのか」という問題に必ずぶつかります。
私は現時点で20プロジェクトをまとめて1つのディレクトリで動かしていますが、ここに辿り着くまでに「リポジトリを分ける」「サブモジュールで共有」「Google Driveで同期」など、いくつもの構成を試しました。この記事では、最終的に採用したコードとアセットの保存場所を分けて管理する設計を、フォルダ構造とバックアップ戦略の両面から解説します。
Claude Codeでプロジェクトが増えると必ず起きる3つの問題
まずは、プロジェクトが5個を超えたあたりから実際に私のローカルで起きていた問題を整理します。同じ壁にぶつかっている方には、かなり既視感のある話のはずです。
1. git管理がバラバラになる
プロジェクトごとに独立してgit initした結果、上の階層にも誤って.gitが存在し、親の.gitの中に子プロジェクトの.gitがネストしている不整合状態が発生していました。どのリポでcommitすべきかが毎回あいまいになり、未push状態のまま数日放置されるプロジェクトも出てきます。
2. 共有したいナレッジが複数箇所にコピーされる
実績データベース・プロンプトテンプレート・ルールファイルなど「全プロジェクトで使いたいファイル」を各所にコピーして持ち回るうちに、同じファイルが3箇所に存在し、どれが最新版か分からなくなる状態になっていました。1箇所を更新しても他の2箇所が古いまま、という事故が普通に起きます。
3. 重いファイルがGitHubに載せられない
画像・動画・モックアップ・デザイン素材など、クライアントワークでは必ず大容量のバイナリファイルが出ます。合計で数百MBを超えるため、普通にgit commitするとリポジトリがすぐ肥大化します。かといってGit LFSを使うと帯域課金が発生し、個人規模には重すぎる運用になります。
この3つが絡み合った結果、「コードベースのバックアップ」と「アセットの保管」を同じ場所で扱おうとすると破綻するというのが私の結論でした。
解決の前提：保存場所を2つに分けて考える
Claude Codeのプロジェクトを長く運用するなら、最初に割り切るべきなのは「1箇所に全部まとめよう」という発想を捨てることです。
保管したいデータは性質が違います。コードは軽くて差分管理に向いているのでGitHubが最適、アセットは重くてバイナリなのでクラウドストレージが最適。両方の性質を1つのインフラで賄おうとするから無理が出ます。
私の最終構成は以下の2階建てになっています。
- コード側: 全プロジェクトを1つのディレクトリに集約し、モノレポとして1つのGitHubリポジトリにpushする
- アセット側: 画像・動画は全プロジェクト分を別の中央フォルダに集約し、Google Driveで同期する
- 繋ぎ: 各プロジェクトからはシンボリックリンクで中央のアセットフォルダを参照する
この3点セットで「コードは差分管理・どこからでもgit cloneで復元」「アセットはクラウドで常時同期」「各プロジェクト内では普通のフォルダに見える」という3つの要件を同時に満たせます。
コード側：モノレポで1つのGitHubリポジトリに集約する
コードの保管先は最初から全プロジェクトまとめて1つのGitHubリポジトリ、いわゆるモノレポ構成にしています。ここに辿り着くまでには遠回りもありました。
検討した3案と、最終的にモノレポを選んだ理由
実際に検討した案は以下の3つです。
- 案A: プロジェクトごとに個別リポジトリ（独立
.gitを各フォルダに持つ） - 案B: 共有ファイルをGit submoduleで繋ぐ（
_shared/を独立リポ化） - 案C: 全プロジェクトを1つのモノレポで管理
最初は案Aで始めて、次に共有ナレッジをsubmoduleで繋ぐ案Bに寄せていきました。しかし、submoduleは各プロジェクトに「別々のコピー」が展開されるため、ナレッジを更新するたびに全プロジェクトでgit submodule updateが必要になります。1人で20プロジェクトを回している状況では、この同期コストは無視できません。
そこで改めて「そもそも個別にcloneしたいのはどのプロジェクトだけか？」を考え直しました。デプロイ対象のWebサイトやSaaS（VercelにpushするNext.jsのアプリなど）は単独で動く必要がありますが、それ以外の記事制作・スキル開発・ナレッジ管理プロジェクトは、ローカルで個別clone可能である必要はありません。
結論として、デプロイ対象だけ独立gitで切り離し、それ以外はモノレポにまとめるのがいちばんシンプルでした。
モノレポ化を実行した時の実数値
実際にモノレポ化を実行した時の初回コミットは775ファイル、59,400行でした。内訳は20プロジェクト、5つの既存.gitを削除し、4つのリポジトリ（モノレポルート・コーポレートサイト・SaaSアプリ・クライアント納品用アプリ）を独立gitとして維持しています。
削除したローカルの.gitはGitHub上ではそのまま残してあります。過去のスナップショットとして残しておけば、いつでも必要な時に参照できるので、急いでアーカイブ化する必要はありません。
.gitignoreで独立gitとアセットを除外する
モノレポのルートに置く.gitignoreでは、以下を必ず除外します。
**/assets/— Google Drive管理なのでgitには載せない**/node_modules/— 依存パッケージは各プロジェクトでnpm install**/output/— スキル実行による生成物**/.env,**/.env.*— 環境変数（クライアント情報の事故防止）- 独立gitで管理しているデプロイ対象のパス（例:
website/,saiten/など）
モノレポとして1つにまとめつつ、独立デプロイしたいサブプロジェクトだけ.gitignoreで切り離す。これで「コードベース全体のバックアップ」と「独立デプロイ可能な単位」を両立できます。
アセット側：中央フォルダに集約してGoogle Driveで同期する
アセットは全プロジェクト分を1つの中央フォルダに集約しています。これが今回の設計でいちばん効いている工夫です。
各プロジェクトにassets/を置いてはいけない理由
最初は普通に各プロジェクトの直下にassets/フォルダを置き、それぞれをGoogle Driveで同期させる案を検討しました。しかしこれは20プロジェクトあると20箇所でGoogle Drive同期の個別設定が必要になり、新規プロジェクトが増えるたびに設定作業が発生します。
管理を煩雑にしたくないので、思い切って構造を反転させました。
中央フォルダにアセットを集約する構造
モノレポのルート直下にassets/を1つだけ置き、その中に全プロジェクトのサブフォルダをミラー配置します。
projects/assets/fyve/— コーポレート系のアセットprojects/assets/toC-AI/— 個人ブランド系のアセットprojects/assets/client-app/— クライアント案件のアセット
そして各プロジェクトディレクトリには、中央の該当フォルダへのシンボリックリンクだけを置きます。
projects/fyve/assets→../assets/fyveへのsymlinkprojects/toC-AI/assets→../assets/toC-AIへのsymlink
各プロジェクトからは普通のassets/フォルダに見えるので、スクリプトやアプリ側のコードには一切影響がありません。実体は中央に1つだけあり、それをみんなで共有している状態です。
中央フォルダだけをGoogle Driveに同期する
Google Drive for desktopには「パソコンのフォルダ」機能があり、指定したローカルフォルダだけをGoogle Driveへ同期できます。ミラーリングではなく、ローカルの特定フォルダを選択的にクラウドへ上げる方式です。
ここで同期対象として指定するのは、先ほど作ったprojects/assets/だけ。1箇所登録すれば全プロジェクトのアセットが自動的にクラウド同期されます。新規プロジェクトが増えても、中央フォルダの下にサブフォルダを作ってsymlinkを貼るだけなので、同期設定の追加作業はゼロです。
私の環境では、この中央フォルダの総容量は約137MBでした。画像・動画・スクリーンショット・モックアップが含まれていますが、Google Driveなら軽く捌ける量です。
フォルダ構成：全プロジェクトを同じテンプレートに揃える
保存戦略と並んで重要なのが、20近くあるプロジェクトの中身の構造を統一することです。プロジェクトごとに構造がバラバラだと、Claude Codeから見た時に「どこに何があるか」の予測がつかず、毎回ルール読み込みから説明し直すことになります。
共通テンプレートを1つ決めて全プロジェクトに適用する
私が採用しているテンプレートは以下の構造です。
CLAUDE.md— プロジェクトの概要・方針を書くClaude Code用ファイル.gitignore/.mcp.json— git除外とMCP接続設定.claude/rules/— 記事執筆・コーディング・ビジネス文脈など、常時読み込むルール.claude/skill-components/— スキル実行時に必要に応じて読む詳細仕様.claude/skills/— 業務自動化スキル本体.claude/commands//.claude/agents//.claude/learnings/data//output//scripts//assets/（symlink）
新規プロジェクトを作る時はこの雛形を丸ごとコピーして始めます。中身が空でも構造は同じにしておくと、どのプロジェクトに入っても「.claude/rules/にルール、data/にデータ、output/に生成物」というメンタルモデルが通用します。
rules/とskill-components/の2層アーキテクチャ
試行錯誤の中で見つけた工夫が、ルールを「常時読む層」と「必要な時だけ読む層」の2層に分けることです。
.claude/rules/— セッション開始時に自動読み込みされる。常にコンテキストを消費する.claude/skill-components/— スキル実行時に手動でReadされる。必要な時だけ消費する
この分離をしていないと、詳細な仕様書まで全部rules/に入れてしまい、セッション開始直後からコンテキストが圧迫される状態になります。SKILL.mdの中では具体的な手順を書かず「このファイルを読んで従え」と参照パスだけ書いておけば、スキルを起動した時だけ必要な仕様が読み込まれます。
Claude Codeのコンテキストは有限なので、「いつ読むか」を設計に組み込んでおくと長時間セッションでの安定性が変わります。
CLAUDE.mdの書き方自体のコツは以下の記事で整理しています。
親子の入れ子構造はCLAUDE.mdで親ルールを参照させる
私のコーポレート管理プロジェクトの中には、出品管理・ポートフォリオ・AIチェッカーなど、さらに小さな子プロジェクトが入れ子になっています。ここで起きる問題が「子プロジェクトでclaudeコマンドを起動すると、親のルールが読まれない」ことです。
Claude Codeは起動ディレクトリの.claude/rules/だけを自動読み込みするため、親子でルールを共有したい場合は子プロジェクトのCLAUDE.mdで明示的に親を参照する必要があります。
具体的には、子プロジェクトのCLAUDE.mdに「親の../.claude/rules/article-writing.mdも必要に応じて読み込め」と書いておきます。モノレポ内なのでReadで普通にアクセスできます。構造は親子で完全に一致させつつ、空でもいいのでフォルダだけは全部配置しておくのがコツです。
未commit漏れ対策：launchdで毎日自動push
モノレポとして集約しても、commit・pushを忘れるとバックアップになりません。1人で20プロジェクトを回していると「1日の終わりに全部commitして回る」のは現実的ではなく、自動化の仕組みが必要になります。
4つの方法を比較してlaunchd一択になった理由
候補として検討したのは以下の4つです。
- macOS launchd（cron相当）: OSレベルで定期実行。APIコストなし。PCが起きている必要あり
- Claude Codeの
/loop: セッションを維持したままループ実行。APIを消費する - Claude Codeの
/schedule（リモートエージェント）: Anthropicサーバーで動く。ローカルファイルには触れない - SessionStart hook: Claude Codeセッション開始時にだけ発火。常時走らない
ここで意外と重要なのが/scheduleの制約です。リモートエージェントはAnthropicのサーバー上で動くため、ローカルの.gitには触れません。自動commit用途には使えないので選択肢から外れます。
/loopはローカルで動きますがClaude Codeセッションを維持する必要があり、API消費もあります。「未commitファイルを夜中に自動でpushしておく」という単純な定型作業には過剰です。
結論として、ローカルの未commitファイルを自動でpushする用途にはlaunchd一択でした。APIコストゼロ、Claude Codeセッションも不要、スリープ中はスキップして復帰時に未実行分を走らせる挙動も、個人のMacbook運用に合っています。
なおClaude Codeの/loop・/schedule・cronの使い分け自体は別記事で詳しく比較しています。
実装：シェルスクリプトとlaunchdのplistで完結
自動化の実装はprojects/scripts/git-autocommit.shという1枚のシェルスクリプトと、~/Library/LaunchAgents/配下のplist設定だけです。
スクリプトがやることはシンプルで、モノレポ本体・独立gitの各デプロイ対象を順番にチェックし、変更があればgit add→git commit→git pushを走らせるだけ。ログはprojects/scripts/logs/git-autocommit.logに追記していきます。
plist側ではStartCalendarIntervalで毎日23:00に発火するように設定しています。スリープ中で発火時刻を逃しても、復帰時に未実行分を走らせてくれる挙動なので、外出から戻った時に自動で巻き取られます。
この構成で実際に楽になったこと
この設計に落ち着いてから運用上のメリットがはっきり出ています。
- バックアップの二重保全: コードはGitHub、アセットはGoogle Driveに自動同期され、ローカルが飛んでも両方から復元できる
- 新規PCへの移行が1コマンド:
git clone一発でコード一式が揃い、アセットはGoogle Driveから同期で流れてくる - commit漏れゼロ: 寝る前に忘れていても、23:00に自動commit/pushされている
- 新規プロジェクト追加がテンプレート適用だけ: 構造が統一されているので、雛形コピー→symlink作成→完了
- Claude Codeのコンテキスト消費が安定: 2層アーキテクチャで常時読み込み量を抑えられる
私の場合は記事執筆・提案書作成・ファイル整理・調査・スキル開発など、Claude Codeをビジネスのほぼ全範囲で使っているため、ここが安定しているかどうかで1日の生産性が大きく変わります。
プロジェクト管理の構造化そのものについては、以下の記事でも実務視点から整理しています。
最後に：小さいうちから保存戦略を決めておく
Claude Codeは使い込むほどにプロジェクトが増えます。AIツールに自社の業務を任せる領域が広がれば、ナレッジファイル・スキル・自動化スクリプトがどんどん育ち、それぞれが別々のバックアップ対象になっていきます。
プロジェクトが3〜5個のうちは個別管理でも回りますが、10を超えたあたりで必ず破綻します。「コードはGitHubに1つのリポジトリとして集約、アセットはGoogle Driveに中央集約してsymlinkで繋ぐ」という二階建ての発想を早めに採用しておくと、後から並べ直す手間がかかりません。
中小企業で自社のAI業務効率化を内製していく場合も、同じ設計は有効です。業務マニュアル・データベース・スキル・プロンプトなどのナレッジ資産が増えてきたら、保管場所の戦略は早めに決めておく価値があります。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。