Claude Code の worktree で個人開発を並列化する

個人開発の「順番待ち」問題

個人開発で Issue が10個溜まっていて、1つずつ順番にやっていくと全然進まない。チーム開発なら分担できますが、1人だとそうもいかないんですよね。

Claude Code の worktree 機能を使うと、この問題をある程度解決できます。

git worktree は、1つのリポジトリから複数の作業ディレクトリを作る git の機能です。ブランチごとに別のディレクトリで同時に作業できます。

my-project/            ← main ブランチ
my-project-worktree-1/ ← feature/auth ブランチ
my-project-worktree-2/ ← fix/api-error ブランチ

Claude Code はこの worktree に対応していて、各 worktree で別々のセッションを立ち上げて並列に開発できます。

各セッションは独立しているので、プロジェクトの文脈を知りません。CLAUDE.md がちゃんと書かれていないと、各セッションが的外れなことを始めます。

書いておくべきことはこのあたりです。

特に品質チェックは重要です。各セッションが独立してコードを書くので、lint やテストの実行を CLAUDE.md で義務付けておかないとマージ時にカオスになります。

個人開発の Web アプリで MVP 完成後、Issue が10個近く溜まっていたので worktree で並列に進めてみました。結論から言うと、いくつかハマりました。

AWS CDK を使っていたんですが、2つのセッションから同時に cdk deploy を走らせたら CloudFormation のスタック更新が競合して失敗しました。

CDK deploy は CloudFormation 経由でインフラを更新するので、同時に走ると「前の更新が完了していない」エラーになります。これは当たり前なんですが、Claude Code の各セッションはお互いの存在を知らないので、勝手にデプロイしようとするんですよね。

対策: CLAUDE.md に「デプロイは1セッションからのみ。他のセッションでは cdk deploy を実行しないこと」と明記しました。

API のルーティングが handler.ts の1ファイルに全エンドポイントまとまっている構成でした。2つのセッションが別々の API エンドポイントを修正しようとすると、同じファイルを触ることになるのでコンフリクトが確定します。

対策: worktree を始める前に、API の修正と UI の修正で分けるなど、同じファイルを触らないタスクの組み合わせを選ぶようにしました。本質的にはファイルを分割するのがベストですが、既存コードのリファクタは別タスクにしました。

翻訳ファイル (ja.json) に新しいキーを追加する作業が複数セッションで発生すると、JSON ファイルの同じ箇所にキーが追加されてコンフリクトします。

対策: 翻訳キーの追加は1つのセッションに集約しました。UI の文言を仮のテキストで先に実装して、翻訳は後でまとめて入れる流れです。

失敗ばかりではなくて、こういう組み合わせはうまくいきました。

要するに「変更するファイルが被らない」ことが一番大事です。

もう1つ学んだのは、セッションに対してスコープを明確に伝えることです。

「Issue #9 を修正して」だけだと、関連する別の問題も一緒に直そうとすることがあります。親切ではあるんですが、並列開発中にスコープが広がるとコンフリクトの元になります。

「この Issue のスコープだけやって、他は触らない」と伝えるほうが安全です。

…で、結局ほぼ使わなくなりましたw

理由はシンプルで、自分の頭がついていかない んですよね。2つのセッションが並列で動いていると、それぞれ何をやっていて、どこまで進んでいて、マージ順はどうするか、を人間側が管理しないといけない。コードを書くのは AI が速くなっても、判断するのは自分なので、結局ボトルネックは自分の頭でした。

とはいえ、「UI の修正を流しつつ、裏でテストを書かせる」みたいな明確に独立したタスクでは今でもたまに使います。万能ではないけど、使いどころを選べば便利な機能です。