Claude CodeでMonorepo内の複数プロジェクトを横断管理する設計パターン

はじめに

僕は一人法人で10個のプロダクトを同時に運用していた時期がある。SaaS 4つ、書籍、受託開発、マーケティング自動化……すべてをMonorepo的な構成で管理し、Claude Codeで横断的に操作していた。

結果として9事業が売上ゼロという大失敗を経験した。ただ、この過程で得た「複数プロジェクトをAIで横断管理する設計パターン」は、3事業に集約した現在も毎日使っている。

この記事では、Claude CodeでMonorepo内の複数プロジェクトを効率的に管理するための設計パターンを、実体験ベースで紹介する。

前提：なぜMonorepoでClaude Codeなのか

Monorepoの利点は「1つのリポジトリで全プロジェクトを見渡せる」こと。Claude Codeの利点は「コンテキストを与えれば横断的に判断・実行できる」こと。この2つを組み合わせると、1人で複数プロジェクトを回すという、従来なら不可能だった運用が現実になる。

当社の実績として、自動化率98%、launchdジョブ17個、記事自動公開3チャネル/日という運用を月約2万円のAI投資で実現している。

パターン1：CLAUDE.mdの階層設計

問題

CLAUDE.mdにすべてのルールを書き続けると、1,000行を超えたあたりでAIが混乱し始める。実際に僕が経験したのは、ルール同士が矛盾して指示と逆の動作を始めるという現象だった。

解決策：ルートCLAUDE.md + プロジェクト別CLAUDE.md

monorepo/
├── CLAUDE.md                     # 全体ルール（200行以内）
├── packages/
│   ├── frontend/
│   │   └── CLAUDE.md             # フロントエンド固有ルール
│   ├── backend/
│   │   └── CLAUDE.md             # バックエンド固有ルール
│   └── shared/
│       └── CLAUDE.md             # 共通ライブラリのルール
└── .claude/
    └── agents/                   # 専門エージェント定義
        ├── dev-architect.md
        ├── dev-coder.md
        └── dev-reviewer.md

ルートCLAUDE.mdには以下だけを書く：

• プロジェクト全体のアーキテクチャ概要
• 絶対禁止リスト（git push --forceなど）
• サブエージェントへの委任ルール
• 各プロジェクトCLAUDE.mdへのポインタ

# 絶対禁止リスト
- git push --force は絶対に実行しない
- 本番DBへの直接書き込みは禁止
- .envファイルをコミットしない

これは実際にgit push --forceの事故でブランチが消えた経験から導入したルールだ。

なぜ200行なのか

Claude CodeはCLAUDE.mdを毎回コンテキストに読み込む。行数が増えるほどトークンを消費し、本来の作業に使えるコンテキストが減る。200行は「必要十分なルールが収まり、コンテキスト使用率を10-15%に抑えられる」経験的な閾値だ。

パターン2：Thin Orchestrator（薄い統括層）

問題

Claude Codeに「全プロジェクトの状態を把握して、最適な判断をして」と頼むと、ファイルを片っ端から読み込んでコンテキストを使い果たす。

解決策：ファイルパスだけを渡す

Orchestrator（統括層）はファイルの中身を自分のコンテキストに読み込まない。パスだけを知っていて、必要に応じてサブエージェントに「このファイルを読んで処理して」と委任する。

# Orchestratorのルール
- ファイルの中身を読み込まず、パスだけを渡す
- 複雑なタスクは必ずサブエージェントに委任
- 自分で実作業（コーディング、文書作成等）を行わない

実際の運用では、朝のダイジェスト生成でも各部門のSTATE.mdを読むのはサブエージェントの仕事で、Orchestratorはその結果を集約するだけだ。

パターン3：STATE.mdによるプロジェクト状態管理

問題

複数プロジェクトの「今どうなっているか」をClaude Codeに毎回説明するのが面倒。gitの差分だけでは「ビジネス的な状態」がわからない。

解決策：プロジェクトごとにSTATE.mdを配置

.company/
├── STATE.md                    # 会社全体の状態
├── products/
│   ├── product-a/STATE.md      # プロダクトAの状態
│   ├── product-b/STATE.md      # プロダクトBの状態
│   └── product-c/STATE.md      # プロダクトCの状態
└── departments/
    ├── dev/STATE.md             # 開発部門の状態
    ├── marketing/STATE.md       # マーケ部門の状態
    └── sales/STATE.md           # 営業部門の状態

STATE.mdの中身は構造化されたMarkdownで、Claude Codeが解析しやすい形式にする：

# プロダクトA — STATE

## 基本情報
- フェーズ: 運用中
- 月間売上: ¥XXX
- 次のマイルストーン: v2.0リリース

## 直近のタスク
- [ ] 機能Xの実装
- [x] バグYの修正

## 注意事項
- APIレートリミットに注意（100req/min）

これにより、Claude Codeは**「今日の状況は？」**と聞かれただけで、全プロジェクトのSTATE.mdを巡回して横断レポートを生成できる。

パターン4：承認パイプライン（draft → 承認 → 実行）

問題

AIの出力をそのまま外部に送信してしまうリスク。実際に僕は、営業メールを確認なしで自動送信し、敬語がおかしいメールが取引先に届くという事故を起こした。

解決策：3段階の権限制御

# 権限レベル
- read-only: 分析・レポート系 → 自動実行OK
- draft: 対外アクション → approval-queue.mdに追加して承認待ち
- execute: 閾値内の内部アクション → 自動実行OK

対外に影響のあるアクション（メール送信、SNS投稿、デプロイなど）は必ずdraftモードで生成し、人間が承認してから実行する。

# approval-queue.md
- [AQ-001] マーケ部門: X投稿ドラフト | drafts/sns/x-2024-04-01.md
- [AQ-002] 営業部門: A社提案書 | drafts/proposals/company-a.md

「AIは実行に使う。判断は人間。」 これが自動化で最も重要な原則だ。

パターン5：エージェント分離パターン

問題

1つのClaude Codeセッションですべてをやろうとすると、コンテキストが足りなくなる。

解決策：専門エージェントを定義して委任

.claude/agents/ディレクトリに専門エージェントを配置する：

.claude/agents/
├── dev-architect.md    # 設計担当
├── dev-coder.md        # 実装担当
├── dev-reviewer.md     # レビュー担当
├── content-engine.md   # 記事生成担当
└── publisher.md        # 出版担当

各エージェントは自分の専門領域のファイルだけを読み、専門的な処理を行う。Orchestratorは結果を集約するだけなので、コンテキストを節約できる。

パターン6：自動化のガードレール

cronの落とし穴

macOSでcronジョブを使おうとしたら、フルディスクアクセスの問題で全滅した。解決策はlaunchdへの全面移行だった。

Monorepoで自動化を組む場合、以下のガードレールを推奨する：

# 自動化のガードレール
1. 絶対禁止リスト: push --force, rm -rf /, 本番DB直接操作
2. レートリミット管理: 外部API呼び出しはロックファイルで制御
3. エラー時の挙動: 最大3回リトライ → 失敗したら人間にエスカレーション
4. ログ: 全自動化処理のログをファイルに記録

Zennのレートリミットに複数回引っかかった経験から、ロックファイルで1日1コンテンツルールを自動で守るようにしている。

実運用の数字

これらのパターンを適用した結果：

指標	値
自動化率	98%
launchdジョブ数	17個
月間AI投資	約¥20,000
月間サーバーコスト	約¥2,000
朝の運用確認	5分

「朝の5分で全部門を把握し、承認ボタンを押すだけ」という運用が実現できている。

まとめ

パターン	解決する問題
CLAUDE.md階層設計	ルール肥大化によるAI混乱
Thin Orchestrator	コンテキスト枯渇
STATE.md状態管理	プロジェクト状態の把握
承認パイプライン	対外アクション事故
エージェント分離	単一セッションの限界
自動化ガードレール	自動化事故の防止

重要なのは、**これらは「AIの能力を制限する」ためではなく「安心して委任するための仕組み」**だということ。仕組みの初期投資は大きいが、一度作れば自動で回る。

コストは10分の1になるが、売上が10倍になるわけではない。プロダクト完成≠売上。作ることと売ることは別の能力。それでも、正しく設計すれば1人で複数事業を回せる時代が来ている。

関連書籍

Claude CodeやAI経営について、より体系的にまとめた書籍を公開しています。

👉 Zenn書籍一覧