Claude Codeのモノレポ戦略｜世界3派と15プロジェクト実運用
Claude Codeで複数プロジェクトを扱うとき、ワークスペースをどう組むべきか──この問いに対し、世界では大きく3つの流派に分かれています。単一モノレポで束ねる派、Docker等で物理的に隔離する派、全業務を1フォルダに集約する派。私は15以上のプロジェクトを1つのモノレポで運用する立場から、それぞれの強みと限界を整理します。
Claude Codeのワークスペース戦略は、世界で3派に分かれている
2025年末から2026年にかけて、Claude Codeで複数プロジェクトを管理する方法について、海外・国内の実践者たちが議論を重ねてきました。統一された「正解」は2026年4月時点でまだ存在しません。ただし、ゆるく収束しつつある方向性は見えています。
大きく分類すると、エンジニア寄りのVirtual Monorepo派と物理隔離派、非エンジニア寄りの単一フォルダ派という3つの潮流です。それぞれが想定する運用規模・ユースケース・重視する価値観が異なります。
派閥1：Virtual Monorepo派 — 独立gitをゆるく束ねる
Virtual Monorepo派は、独立したgitリポジトリを複数維持しつつ、ひとつの親ディレクトリから横断的に参照できるようにする方式です。親ディレクトリ自体もgit管理されますが、子ディレクトリの実体は別リポジトリとして切り離されています。
Owen Zanzal氏の「Virtual Monorepo Pattern」
Owen Zanzal氏は35個のリポジトリを対象に、ルートに.reposというスクリプトを配置し、必要なタイミングで各リポジトリを束ねる運用を提唱しました。ルート階層には「システムマップ」としてのCLAUDE.md、各リポジトリの物語的コンテキストをまとめたREADME.mdを配置します。
スローガンは「context beats structure for AI effectiveness」──AIの活用においては、厳密な構造よりもコンテキストが勝る、という思想です。
Kieran Klaassen氏の「The Folder Is the Agent」
Cora社のKieran Klaassen氏は、44個のフォルダそれぞれを独立したエージェントとして扱う手法を実践しています。モデル自体は汎用のまま、フォルダごとに読み順（conventions→architecture→reports→prompts→agents）を明示することで、コンテキストの積層がスペシャリストを作るという考え方です。
この派閥は、エンジニアが複数プロジェクトを並行して進める実務に最も適合します。
派閥2：物理隔離派 — クライアント案件をコンテナで切り分ける
物理隔離派は、Dev ContainerやDocker Volumeを使い、プロジェクトごとに実行環境そのものを分離する方式です。
Zennで発信しているyahsan2氏は、個人作業はbind mount、クライアント案件ごとにclaude-client-aのような専用Docker volumeを用意し、認証情報・メモリ・履歴のすべてを物理的に隔離する運用を公開しています。コンテナを切り替えるだけでアカウントも切り替わる仕組みです。
物理隔離が効く場面
物理隔離派が真価を発揮するのは、NDA（秘密保持契約）を結んだ案件が複数並行する場面です。1つのClaude Codeインスタンスからすべてのクライアントデータにアクセスできる状態では、プロンプトインジェクションが発生したときに被害が全案件に及びます。環境を分けることで、この「セキュリティ境界」が明確になります。
トレードオフ
起動・切替のコストは高くなります。複数クライアントを同時進行するときに「別のクライアントの資料を参照したい」といった横断的な作業はできなくなります。セキュリティと引き換えに、横断参照の利便性を手放す構造です。
派閥3：単一フォルダ派 — 非エンジニアの実用解
単一フォルダ派は、全業務を1つのフォルダに集約し、Markdownの集合体をAIの「脳」として扱う方式です。noteで発信している梶谷健人氏や、個人のCRMをClaude Codeで構築したShiv Sakhuja氏らが提唱しています。
クライアントのミーティングログ、提案書ドラフト、契約書、コンテンツ制作、請求書、個人のメモまで、すべてが同じ階層に並びます。Agentic RAGを前提とすれば、AI側がファイルを横断的に参照できるので、人間側は「どのフォルダに何が入っているか」を覚える必要がありません。
最大のメリットは「認知切替コストがゼロ」
梶谷氏の言葉を借りれば、これは「認知切替コストがゼロになる」運用です。どのプロジェクトに移動するかを考えずに、ひとつの場所に情報を集め続けるだけで、AIが文脈をまたいで答えを返してくれます。
限界
プロジェクト数が数十を超えると、さすがに管理が破綻します。セキュリティ境界も曖昧なため、NDA案件や機密性の高いデータには向きません。個人〜小規模の業務に最適化された思想です。
15以上のプロジェクトを1モノレポで運用して学んだこと
私自身は気付けばVirtual Monorepo派に近い構造を採用していました。明確な思想を持って設計したというより、運用しながら少しずつ辿り着いた形です。
単一git + 独立gitの.gitignore除外
親ディレクトリ全体が1つのgitリポジトリになっており、その中にVercelデプロイ対象のアプリやサイト、クライアントへの納品用リポジトリといった「独立git」を含みます。独立gitのディレクトリは親の.gitignoreに記載し、親からは追跡しない構造です。
この構造の利点は、Claude Codeから全プロジェクトを横断的に参照できる一方で、デプロイ対象のコードは独立したライフサイクルで管理できることです。
assets/のシンボリックリンク集約
画像・動画・モックアップなどのアセットは、親ディレクトリのassets/に集約し、Google Drive for desktopで同期します。各プロジェクトからはassets -> ../assets/{project}のようにシンボリックリンクで参照します。
この工夫は世界中のClaude Code運用事例を調べても、ほぼ言及されていません。重いバイナリをgitに乗せずに、AIからは通常ファイルに見えるようにする、地味ですが効果の大きい設計です。
launchdでの日次autocommit
macOSのlaunchdを使い、毎日23時に全リポジトリを自動でcommit・pushしています。意図せずブランチが進行するリスクはありますが、「institutional memory」としてのgit logが日々積み上がります。1ヶ月後に「この案件はいつ頃どう動いていたか」を思い出すとき、コミットログが最高のジャーナルになります。
CLAUDE.mdを2層に分割
各プロジェクトの.claude/配下を、自動読み込みされるrules/と、手動Readされるskill-components/に分けています。常時適用したい普遍ルールは前者、スキル実行時だけ必要な手順書は後者、という分担です。
これはAnthropic公式ドキュメントが推奨する「ルートCLAUDE.mdは200行・2,500トークン以内」の制約を守りつつ、詳細情報は必要なときだけロードするための工夫です。
失敗談：autocommitが4日間静かに止まっていた
つい先日、autocommitが4日間動いていないことに気付きました。原因はmacOSのTCC（プライバシー保護機構）が、launchd経由で起動する/bin/bashに対して~/Desktop/配下のスクリプト実行をブロックしていたためです。
Desktopに置いたスクリプトは、Terminal.appから実行する分にはFull Disk Accessが付与されているので動きます。しかしlaunchdから起動するbashはその権限を持っていません。結果、失敗ログは記録されるが、誰も見ていないという状態が生まれました。
気付いたきっかけは「そういえば最近ログを確認していないな」という、ただの思い付きでした。62ファイルが未commitで浮いている状態を見て、はじめて事態に気付いたのです。
教訓はシンプルで、失敗を失敗として見える化する仕組みを入れない限り、どれだけ自動化しても意味がないということです。Slack通知、週次のgit status確認、何でもいいので「見える化」の1段は挟むべきでした。
スケール時に壊れる4つのポイント
世界の事例を調べた中で、共通して警告されていた「壊れる場所」を4つ整理します。自分の構造に当てはめて確認しておくと、将来のトラブルを先回りできます。
1. ルートCLAUDE.mdの肥大化
複数プロジェクトを1つのワークスペースで運用すると、ルートのCLAUDE.mdに情報が集中しがちです。Anthropic公式の推奨は200行・2,500トークン以内。47,000ワードまで肥大化して性能劣化した事例もレポートされています。
対策はシンプルで、ルートCLAUDE.mdは「システムマップ」の役割に限定し、詳細ルールは.claude/rules/配下のファイルに分離することです。
2. ancestor CLAUDE.mdの汚染
Claude Codeはサブディレクトリで起動しても、親ディレクトリのCLAUDE.mdを自動的に読み込みます。これが意図しない文脈の混入を引き起こすことがあります。
対策としては、.claude/settings.local.jsonでclaudeMdExcludesを使って特定のCLAUDE.mdを除外することです。案件ごとに厳密な文脈分離が必要な場面では、これを意識する必要があります。
3. 並列エージェントツールがマルチプロジェクト非対応
2026年に入って、Superset、Conductor、Crystalといった「Claude Codeを複数並列で動かすためのオーケストレータ」が次々に登場しました。
これらはいずれも「単一リポジトリ内でgit worktreeを使って並列化する」前提で設計されています。複数プロジェクトを横断して並列動作させる用途は想定されていません。Virtual Monorepo派の運用をしていると、これらのツールはプロジェクトごとに個別に立ち上げる必要があります。
4. NDA案件の物理隔離不足
Virtual Monorepo派の弱点は、セキュリティ境界が論理的なもの（.gitignoreやディレクトリ分離）に依存している点です。NDA案件・機密性の高い案件については、別途Dev Container化などの物理隔離を検討する必要があります。
個人事業主・経営者がいま取るべき構造
これまでの整理を踏まえ、20〜30プロジェクト規模までの個人事業主・経営者に対して現実的な推奨を示します。
基本はVirtual Monorepo派
管理単位のプロジェクトは1つの親ディレクトリに集め、独立gitとして管理したいもの（デプロイ対象アプリ、クライアント納品物）は.gitignoreで除外する。親側はMarkdown中心の知識ベース＋管理ファイルとして運用する。この組み合わせが、現時点で最もスケールする構造です。
NDA案件だけDev Container化を検討
クライアント案件のうち、NDAを結んでいるもの・機密性の高いものについては、物理隔離派の発想を部分的に採用します。全案件を隔離する必要はありません。「物理隔離に値する案件」と「そうでない案件」を仕分けし、境界線を引くだけで十分です。
AGENTS.mdを併置する
Linux Foundation傘下のAgentic AI Foundationが採択したAGENTS.md規格は、2026年4月時点でGitHub上6万リポジトリ以上が採用しています。ツール中立の指示ファイルとしてCursor、Codex CLI、Gemini CLI、GitHub Copilotなどからも読まれます。
Claude Code以外のツールを将来使う可能性があるなら、ルートにAGENTS.mdを置き、CLAUDE.mdはClaude固有の補足だけに絞るのが賢明です。
一番効くのは「境界ルールの明文化」
最終的に、私が15プロジェクト以上を1モノレポで運用する中で感じているのは、「何をこの1つのgitに入れ、何を入れないか」が1行で書けるなら運用は安定するという事実です。
たとえば私の境界ルールはこうなります。
- 入れるもの：Markdown、JSON、CSV、管理スクリプト、
.claude/配下、data/、messages/。つまり「動かないもの・書き物・設定」 - 入れないもの：デプロイ対象アプリ・サイト、外部から取り込んだコード、
node_modules、assets/（Google Drive管理）
この1行ルールがあれば、新しいプロジェクトが増えたときに「どう扱うか」の判断が即座に下せます。ルールが曖昧だと、毎回.gitignoreを更新したり、ネストgitの事故が起きたりします。
まとめ：正解はまだない、ただし方向性は見える
2026年4月時点で、Claude Codeのワークスペース戦略に「これが正解」という答えは存在しません。ただし世界的には、独立したリポジトリをゆるく束ねる方向（Virtual Monorepo派）に緩やかに収束しつつあります。
問うべきは「モノレポか、分離か、1フォルダか」ではなく、「この1つのgitが何のためにあるのか」です。管理と実装、書き物と動くもの、を明確に分ける境界を自分のビジネスに合わせて引くこと。これが、複数プロジェクトをAIと共に運用するうえで最も効きます。
私自身もこの構造を完成形と思ってはいません。スケールの過程で見えてきた壊れポイントを先回りして直しながら、運用し続けています。この記事が、同じ課題を抱える方の参考になれば幸いです。
関連する話題として、CLAUDE.mdの書き方や複数プロジェクト管理の実務を扱った記事も書いていますので、合わせて参考にしてください。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。