この記事はすきま経営からの転載です。
私は現在、本業のFDE（AI導入支援）に加えて、storeforge・aerial-earth-studio・afflow・民泊・すきま経営ブログと、性質の異なる複数のコードベースをClaude Codeで並行運用している。結論から書くと、複数リポジトリを1人で回す上で効いているのは「タスク管理を1箇所に集約する」「リポジトリごとのルールをCLAUDE.mdに書き切る」「新規リポジトリはガードレールを自作せずsubmoduleで揃える」の3点だ。今回はこの運用の中身を具体的に書く。
なぜ横断運用が破綻しやすいか
複数事業のコードを1人で持つと、まず崩れるのはタスク管理だ。事業ごとにissueやTODOリストを別々の場所に置くと、「今どの事業に何が残っているか」を把握するためだけに複数のリポジトリを見て回る羽目になる。この確認コスト自体が、すきま時間の中では無視できない負担になる。
もう1つの崩れ方は、リポジトリごとのルールを自分の記憶に頼ってしまうことだ。「このリポジトリはmain直pushしていいんだっけ」「この事業は下書きまでが既定だっけ、即公開だっけ」を毎回思い出そうとすると、判断コストが積み重なり、結局どこかでルールを踏み外す。実際、運用を整理する前は、この手の確認漏れが何度かあった。
タスク管理はコードリポジトリに置かない
最初に決めたのは、issueをコードのリポジトリに分散させず、管理専用リポジトリ（life）に一元化することだ。ラベルで事業を色分けし、GitHub Projectsのボードで横断的に進捗を見る。
これには理由がある。issueがコードリポジトリに散っていると、Claude Codeのセッションを開くたびに「このリポジトリのissue一覧」しか見えない。複数事業を並行していると、今日どの事業に時間を使うべきかの判断材料が、リポジトリをまたいで存在してしまう。管理を1箇所に集約すると、その日最初にやることは「管理リポジトリのボードを開いて優先度を確認する」の1手順で済む。
具体的な運用ルールは次の形にしている。
- タスクの作成場所: 全事業共通で管理リポジトリにissueを立てる。コード側のリポジトリには作らない
- 紐付け方法: issue本文やコミットメッセージに、コードリポジトリ側の詳細を書きすぎない。issue側のコメントに関連ファイルパスを残す形で、コード側にはissue番号を書き込まない（コードリポジトリだけを見た第三者に、管理体制の内部事情が漏れないようにするため）
- ステータス反映: 着手した時点でProjectsのStatusを実態に合わせて更新する。完了してから一括更新すると、他のセッションを開いたときに「今何が進行中か」を誤認する
CLAUDE.mdにリポジトリ固有ルールを書き切る
Claude Codeはリポジトリ直下のCLAUDE.mdを自動で読み込む。これを「そのリポジトリで絶対に踏み外してはいけないルール」の置き場所として使っている。
例えば、あるリポジトリはmain直push禁止で全変更PR経由、別のリポジトリはmainへのマージが即座に外部プラットフォームへの公開に直結する、また別のリポジトリは本番公開に明示的なGOが必要で下書きまでが既定——というように、事業ごとに「危険な操作」の中身が違う。この差分を毎回思い出す前提で運用すると、複数リポジトリを横断するほど事故率が上がる。
CLAUDE.mdには「絶対ルール」という見出しで、番号付きの箇条書きとしてこれを明記している。人間の目で見ても数秒で読める分量に絞り込むのがポイントで、長文の運用ドキュメントをそのまま貼ると、結局読み飛ばされて機能しなくなる。守秘義務や秘密情報の扱いのような、事業をまたいで共通の項目も、リポジトリごとのCLAUDE.mdに重複して書いている。「共通ルールは別ファイルを参照」という間接参照にすると、参照先を読み忘れるリスクが出るため、多少の重複は許容してでも各リポジトリ単体で完結させている。
共通の仕組みはガードレール用リポジトリに集約する
もう1つ効いているのが、git hooksや事業運営上の原則のような「全リポジトリ共通で使うが、コードそのものではない」仕組みを、専用リポジトリに切り出してsubmoduleとして各事業のリポジトリに組み込む運用だ。
新しい事業のリポジトリを作るたびに、pre-commitでのシークレットスキャンやlint、main直push防止のpre-pushフックを個別に書いていくと、リポジトリが増えるごとにメンテナンスの手間が増える。さらに悪いことに、リポジトリごとに微妙に実装が違うhooksが量産され、どれが最新の正しい設定かわからなくなる。
これを避けるため、hooksとコンテンツマーケティングの運用原則をそれぞれ専用リポジトリにまとめ、新規リポジトリではsubmodule経由で導入する運用に統一した。新しい事業を立ち上げる際にゼロから仕組みを作らず、git submodule update --initで必要なガードレールが揃う状態にしている。これにより、どのリポジトリを開いても「最低限のガードレールは同じ水準で効いている」という前提でClaude Codeに作業を任せられる。
横展開できるチェックリスト
複数リポジトリを横断運用する上で、新しい事業のリポジトリを作る際に自分が確認している項目は次の4つだ。
- issueは管理専用リポジトリに立てる前提になっているか（コードリポジトリ側にタスク管理を作っていないか）
- CLAUDE.mdに「絶対ルール」を番号付き箇条書きで明記したか（長文の運用ドキュメントへの参照だけで済ませていないか）
- hooksやlint設定をガードレール用リポジトリからsubmoduleで導入したか（独自実装をゼロから書いていないか）
- 本番公開・機密情報の扱いなど、事故ると取り返しがつかない操作をCLAUDE.mdの冒頭に書いたか
まとめ
- 複数事業のコードベースを1人で運用する上で最も崩れやすいのはタスク管理の分散とルールの記憶依存
- issueは管理専用リポジトリに一元化し、コードリポジトリには作らない
- リポジトリ固有の絶対ルールはCLAUDE.mdに番号付きで書き切り、多少の重複は許容する
- hooksや運用原則のような共通の仕組みはガードレール用リポジトリに切り出し、submoduleで新規リポジトリに揃える
次回は、この横断運用の中でClaude Codeにどこまで判断を任せ、どこから人間の承認を挟んでいるかの線引きについて書く。