Claude Codeで複数プロジェクトを効率運用するTips集

Claude Codeを使い始めて数ヶ月。気がつけば手元のプロジェクトは15を超えていました。Webアプリ、モバイルアプリ、MCPサーバー、個人サイト、分析スクリプト——それぞれ技術スタックも規約も違います。

最初はプロジェクトごとにCLAUDE.mdを書いていましたが、同じことを何度も書く非効率に気づきました。そこから試行錯誤を重ねて、複数プロジェクトを横断的に管理する仕組みが固まってきました。

この記事では、実際に使っている10個のTipsを紹介します。

1. グローバルCLAUDE.mdで開発哲学を統一する

課題: プロジェクトごとにCLAUDE.mdを書くと、「シンプル第一」「根本原因を見つける」といった基本姿勢を毎回書くことになります。書き忘れたプロジェクトではエージェントの振る舞いがブレます。

解決策: ~/.claude/CLAUDE.md にグローバルな開発哲学を書きます。これは全プロジェクトで自動的に読み込まれます。

具体例: 自分のグローバルCLAUDE.mdには4つの原則だけを書いています。

## Core Principles
- シンプル第一: 最もシンプルな解決策をまず試す。過剰設計しない
- 根本原因を見つける: 表面的な対処ではなく、根本原因を特定して修正する
- 影響を最小化する: 変更の影響範囲を最小限にとどめる
- "スタッフエンジニアはこれを承認するか？" という自問を習慣化する

最後の一行がポイントで、エージェントに「品質基準」を意識させる効果があります。プロジェクト固有の事情はプロジェクト別CLAUDE.mdに委ねて、ここには普遍的な原則だけを置きます。

2. ~/.claude/rules/ でトピック別にルールを分離する

課題: グローバルCLAUDE.mdが肥大化します。コーディング規約、技術スタック、テスト方針、デプロイ手順——全部をひとつのファイルに書くと見通しが悪くなります。

解決策: ~/.claude/rules/ ディレクトリにトピック別のMarkdownファイルを配置します。Claude Codeはこのディレクトリ配下のファイルも自動で読み込みます。

具体例: 自分は以下のように分けています。

~/.claude/rules/
├── code-quality.md    # ESM, strict TS, 命名規則, テスト方針
├── tech-stack.md      # Node.js, Expo, Supabase, Vercel の共通設定
└── supabase-shared.md # 共有DBのスキーマ分離ルール

code-quality.md には「ES Modulesを使う」「anyは使わない」「テストはVitest」といった、どのプロジェクトでも適用したいルールを書きます。tech-stack.md にはVolta、EAS Build、Vercelデプロイの注意点など、技術スタック固有の知識を集約します。

ファイルを分けることで、特定のルールを探すのも更新するのも楽になります。

3. 共有リソース（DB、Auth）の境界をルールで明示する

課題: 複数プロジェクトがひとつのSupabaseプロジェクトを共有していると、あるプロジェクトの作業中に別プロジェクトの設定を壊すリスクがあります。特にAuth設定やmigrationは危険です。

解決策: 共有リソースの境界と注意事項を専用のルールファイルに書きます。

具体例: supabase-shared.md に以下のような内容を書いています。

## Schema Separation
- megulus: `public` スキーマを使用
- entrepreneur-diary: `diary` スキーマを使用
- powerspots: `powerspots` スキーマを使用

## Config Push の注意
`supabase config push` は auth 設定を含むため、一方のプロジェクトから
実行すると他方の設定を上書きするリスクがある。

これがあると、エージェントがmigrationを作るときにスキーマを間違えません。config push の前に確認を促してくれることもあります。共有リソースの「地雷」を事前にマップしておく感覚です。

4. プロジェクト別CLAUDE.mdは「新メンバーへの引き継ぎ」の感覚で書く

課題: プロジェクト別CLAUDE.mdに何を書けばいいかわかりません。書きすぎると冗長、書かなすぎるとエージェントがプロジェクトの文脈を理解できません。

解決策: 「新しいチームメンバーに初日に渡す引き継ぎ資料」を書く感覚で作ります。プロジェクトの全体像、技術スタック、開発・デプロイ手順、主要ドキュメントへのポインタがあれば十分です。

具体例: 自分のプロジェクト別CLAUDE.mdは以下の構成にしています。

# プロジェクト名
一行の説明。

## クイックリファレンス
- デプロイ: コマンドと手順
- 本番URL
- 開発: ローカル起動コマンド

## 技術スタック
箇条書きで列挙

## 主要ドキュメント
- AGENTS.md … デプロイ詳細
- その他の重要ファイルへのリンク

ポイントは「クイックリファレンス」を冒頭に置くことです。エージェントが最初に読む部分なので、頻繁に使う情報を上に持ってきます。詳細はAGENTS.mdや他のファイルに分離します。

5. Memoryで会話を跨いだコンテキストを蓄積する

課題: Claude Codeの会話はセッションごとにリセットされます。前回の会話で決めたことや発見した事実が、次の会話では失われます。

解決策: Claude CodeのMemory機能を活用します。重要な決定事項や発見は、会話中にMemoryに保存するよう依頼します。次の会話で自動的に参照されます。

具体例: 自分のプロジェクトのMemoryには以下のような情報が蓄積されています。

## ブログ記事のソース
- WordPress移行: `source: "wordpress"`
- note移行: `source: "note"` — ファイル名が `note-nxxxxxx.md` のハッシュ形式
- 新規: `source: "original"`

## SEO改善 (2026-03-09実施)
- `/blog/tech/` 404 → `/blog/category/tech/` リダイレクト追加
- 高インプレッション記事4件の draft解除

「なぜこのslug形式なのか」「なぜこのリダイレクトがあるのか」といった文脈が、会話を跨いで保持されます。新しい会話でブログ記事を扱うとき、エージェントはこのMemoryを参照して適切な判断ができます。

6. サブエージェントでコンテキストウィンドウを節約する

課題: 大規模なコードベースの調査や、複数ファイルの横断的な変更で、コンテキストウィンドウが圧迫されます。長い会話の後半ではエージェントの精度が落ちることがあります。

解決策: 独立したタスクはサブエージェントに委任します。サブエージェントは独自のコンテキストウィンドウを持つため、メインの会話のコンテキストを消費しません。

具体例: グローバルCLAUDE.mdに以下のルールを書いています。

## Workflow
- サブエージェントを使ってコンテキスト圧迫を防ぐ

これだけで十分です。「全ファイルのimport文をES Modulesに変換して」のような大量の機械的変更は、エージェントが自動的にサブエージェントを活用する判断をします。メインの会話ではアーキテクチャの議論に集中できます。

7. Planモードで複雑なタスクの手戻りを防ぐ

課題: 3ステップ以上の複雑なタスクで、エージェントがいきなりコードを書き始めて方向を間違えると、大きな手戻りが発生します。

解決策: 複雑なタスクはPlanモードで開始します。エージェントに実行計画を立てさせ、承認してから実装に入ります。

具体例: グローバルCLAUDE.mdに以下を書いています。

## Workflow
- 複雑なタスク（3ステップ以上）は Plan モードで開始する
- 途中でうまくいかなくなったら、無理に進めずすぐに立ち止まって再計画する

「途中で立ち止まって再計画する」の一文が重要です。計画通りに進まないとき、エージェントが無理やり元の計画に固執して泥沼にはまるケースを防げます。Plan → 実行 → 問題発生 → 再Plan、というサイクルを回します。

8. AGENTS.mdにデプロイ手順を分離する

課題: CLAUDE.mdにデプロイ手順を書くと、日常的な開発タスクでもデプロイ情報がコンテキストに入ります。情報が多すぎるとエージェントの注意が分散します。

解決策: デプロイ手順やCI/CD関連の情報はAGENTS.mdに分離します。CLAUDE.mdからはポインタだけ残します。

具体例: CLAUDE.mdには最小限のリファレンスだけ書きます。

## クイックリファレンス
- **デプロイ**: `git push origin master` → Vercel が自動デプロイ（詳細は AGENTS.md）

AGENTS.mdにはVercelの制限事項（Hobbyプランのファイルアップロード上限など）、--archive=tgz オプションの必要性、手動デプロイの手順などを詳しく書きます。デプロイ関連のタスクのときだけ、エージェントがAGENTS.mdを参照します。

9. Voltaでランタイムバージョンを固定する

課題: プロジェクトによってNode.jsのバージョンが異なります。nvmだと手動で切り替える必要があり、エージェントが間違ったバージョンで実行するリスクがあります。

解決策: Voltaを使ってプロジェクト単位でNode.jsバージョンを固定します。package.json に volta フィールドを書くだけで、そのディレクトリに入ると自動でバージョンが切り替わります。

具体例: tech-stack.md に以下を書いています。

- Runtime: Node.js (Volta でバージョン管理)

各プロジェクトの package.json には以下が入っています。

{
  "volta": {
    "node": "22.14.0"
  }
}

エージェントがnvmを使おうとしたり、グローバルのNode.jsバージョンに依存したりすることがなくなります。新しいプロジェクトを作るときもVoltaの設定を入れる習慣がつきます。

10. git worktreeで並行作業する

課題: ひとつのブランチで作業中に、別の急ぎのタスクが入ります。stashして切り替えて、終わったら戻して——という手順は煩雑で、エージェントとの会話も中断されます。

解決策: git worktreeを使って、同じリポジトリの別ブランチを別ディレクトリにチェックアウトします。Claude Codeの複数セッションをそれぞれ別のworktreeで開けば、並行作業が可能になります。

具体例: 実際に自分はこの記事を書いている今もworktreeを使っています。masterブランチの作業ディレクトリとは別に、記事執筆用のブランチをworktreeとして切り出しています。

git worktree add ../site-feature feat/new-feature
cd ../site-feature
# ここで別のClaude Codeセッションを開いて作業

mainブランチでの作業を中断せずに、機能ブランチの作業を並行して進められます。作業が終わったら git worktree remove で片付けます。ブランチの切り替えコストがゼロになります。

まとめ

10個のTipsを振り返ると、共通するテーマが見えます。

• 分離: ルールをファイル分割し、デプロイ手順を分離し、worktreeで作業を分離する
• 蓄積: Memoryで知識を蓄積し、CLAUDE.mdで哲学を蓄積する
• 境界: 共有リソースの境界を明示し、コンテキストウィンドウの使い方を制御する

Claude Codeは便利ですが、プロジェクトが増えるほど「エージェントへの指示体系」の設計が重要になります。ルールを書くのは面倒に思えますが、一度整備すれば全プロジェクトで効いてきます。初期投資としてのリターンは大きいです。