こんにちは。ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。
ファインディではClaude CodeのSkillやカスタムコマンドなどをPlugins経由で社内展開しています。
AIに実装を任せる場面が増えるほど、開発者は複数のタスクを並列で進めたくなります。
レビュー待ちの間に別のIssueに着手したり、hotfixを即座に対応したりが良い例です。
ファインディでもGit worktreeを活用した並列開発を実践しています。
Git worktreeは非常に便利な機能ですが、実際にチームで使おうとすると「コマンドが多い」「クリーンアップを忘れる」「環境ファイルのコピーが面倒」といった運用上のハードルが立ちはだかります。
本記事では、Git worktreeの操作をClaude Codeのスキルに閉じ込めて、チーム全員が簡単に並列開発できるようにした取り組みを紹介します。スキルの設計判断や、他のスキルとの連携についても触れるので、Claude Codeでの効率化に興味がある方の参考になれば幸いです。
Git worktreeとは
Git worktreeは、1つのリポジトリに対して複数の作業ディレクトリを作成するGitの機能です。
通常、あるブランチで作業中に別のブランチへ切り替えるにはgit stashやgit switchが必要ですが、worktreeを使えばディレクトリごとブランチを分離できます。
# メインの作業ディレクトリ（feature/auth ブランチ） ~/project/MyApp/ # worktreeで作った別の作業ディレクトリ（fix/login-bug ブランチ） ~/project/MyApp/.claude/worktrees/fix-login-bug/
それぞれのディレクトリが独立したブランチを持つので、片方でコードを書きながら、もう片方でレビュー修正を進めるといった使い方ができます。
手動でworktreeを使った場合
Git worktreeの概念はシンプルですが、実際の運用では手順が多くなります。新しいworktreeを作って作業を始めるまでに必要なコマンドを並べてみます。
# 1. worktreeを作成してブランチを切る git worktree add .claude/worktrees/fix-login-bug -b fix/login-bug # 2. 作成したディレクトリに移動 cd .claude/worktrees/fix-login-bug # 3. 環境ファイルをコピー（.envやSSL証明書など） cp ../../.env . cp ../../.env.local . cp ../../localhost.pem . cp ../../localhost-key.pem . cp ../../.claude/settings.local.json .claude/ # 4. 依存パッケージのインストール npm install # or bundle install, etc.
4ステップ、コマンドにして8行以上。しかもこれは「worktreeを作る」だけの話です。
作業が終わったあとのクリーンアップも忘れてはいけません。
# 5. 元のディレクトリに戻る cd ~/project/MyApp # 6. worktreeを削除 git worktree remove .claude/worktrees/fix-login-bug # 7. 不要なブランチを削除（オプション） git branch -d fix/login-bug
これだけの手順を毎回正確にこなすのは、慣れた開発者でも面倒です。
チームに導入しようとすると「手順書を読む気にならない」「クリーンアップを忘れてworktreeが残り続ける」という問題が起きます。実際、社内でworktreeを勧めても「便利そうだけど、手順が多くて複雑に見えてしまい重い腰が上がらない」という反応が大半でした。
スキルに閉じ込めた
Claude Codeには「スキル」という仕組みがあります。Markdownファイルにワークフローを記述しておくと、スラッシュコマンドとして呼び出せます。
スキルの作り方や基本的な考え方については、次の記事で詳しく紹介しています。
実はClaude Code自体にも--worktreeフラグがあり、worktreeの作成とセッション切り替えはできます。ただし、これだけでは足りませんでした。--worktreeが担うのはworktreeの作成のみで、.envのコピーや依存パッケージのインストールといった環境セットアップは含まれません。プロジェクトごとにセットアップ要件が異なる点や、他のエージェントやスキルからワークフロー的に呼び出したい点を考えると、スキルとして設計する必要がありました。
そこで今回は、Git worktreeの複雑な操作をスキルに閉じ込めることにしました。
使い方はシンプルです。Claude Codeで次のように入力するだけで、worktreeの作成から環境セットアップまでが完了します。
> /git-worktree feature/add-auth
先ほどの8行以上のコマンドが、この1行に集約されます。裏側では次の処理が自動で実行されています。
- メインリポジトリのパスを記録
EnterWorktreeで.claude/worktrees/feature-add-auth/にworktreeを作成- セッションの作業ディレクトリを自動で切り替え
.envやSSL証明書など、必要な設定ファイルをコピー
ここで重要なのが、Claude Codeが提供するEnterWorktreeとExitWorktreeという2つのツールです。
EnterWorktreeはworktreeの作成とセッションのディレクトリ切り替えを一度に行います。通常のgit worktreeコマンドでは作成後にcdで移動する必要がありますが、EnterWorktreeならClaude Codeのセッション自体が新しいworktreeに切り替わるため、その後のすべての操作が自動的にworktree内で実行されます。
作業が終わったらExitWorktreeを呼ぶだけです。元のディレクトリに戻りつつ、セッション終了時にworktreeを残すか削除するかを選べます。「クリーンアップを忘れてworktreeが溜まり続ける」問題は、このライフサイクル管理で解消されました。
スキル設計の工夫
このスキルは、worktreeの作成を担当するスキルと、環境セットアップを担当するスキルの2つに分離しています。
作成スキルはworktreeの作成とコンテキスト切り替えを担当します。セットアップスキルは作成されたworktreeに環境ファイルをコピーする処理を担当します。
なぜ分けたのか。理由は、プロジェクトごとにセットアップ要件が異なるからです。
あるプロジェクトでは.envと.env.localだけコピーすれば十分かもしれません。別のプロジェクトではSSL証明書が必要で、さらに別のプロジェクトではデータベースのマイグレーションまで走らせたいかもしれません。
セットアップスキルはプロジェクトローカルでオーバーライドできる設計にしました。
プロジェクトのルートにセットアップ用のシェルスクリプトを置けば、プラグインのデフォルトスクリプトの代わりにそちらが実行されます。
# プロジェクトに固有のセットアップスクリプトがあればそちらを使う .claude/skills/setup-worktree/setup-worktree.sh ← プロジェクト固有（優先） # なければプラグインのデフォルトを使う ~/.claude/plugins/.../setup-worktree.sh ← デフォルト
worktreeの作成ロジック自体はプロジェクトによって変わらないので、作成スキル側は共通のまま維持しています。変わる部分と変わらない部分を分離したことで、各プロジェクトは自分に必要なセットアップだけをカスタマイズできるようになりました。
他のスキルとの連携
このスキルが本領を発揮するのは、他のスキルと組み合わせたときです。
社内ではGitHubからIssueを読み取り、実装してPull requestを作成するエージェントを使っています。このエージェントは内部で今回紹介したgit-worktreeスキルを呼び出して、Issue単位でworktreeを作成します。
- GitHub Issueを取得
- git-worktreeスキルでworktreeを作成 ← ここで活用
- Issueの内容に基づいて実装
- Pull requestを作成
- worktreeをクリーンアップ
複数のIssueを並列で処理する場合、Issue1つにつきworktreeが1つ作られます。それぞれが独立したディレクトリで動くので、コンフリクトを気にせず並列実行できます。
git-worktreeスキルを単体で作っておいたことで、エージェントは「worktreeの作り方」を知らなくても並列開発が実現できています。もしworktreeの作成手順が変わっても、git-worktreeスキルだけを修正すれば済み、エージェント側に手を入れる必要がありません。
スキルの粒度を意識しておくと、こうしたエージェンティックなワークフローを組みやすくなります。1つのスキルに機能を詰め込みすぎず、再利用可能な単位に分けておくことで、他のエージェントやスキルなどから自在に組み合わせられるようになります。
「複雑さはスキルに閉じ込める」という考え方
今回の取り組みで実感したのは、ツールの複雑さは必ずしも排除しなくてよいということです。Git worktreeの操作が複雑なのは、それだけ柔軟性があるからです。問題は、その複雑さが毎回ユーザーに露出することにあります。
Claude Codeのスキルは、この課題に対する有効なアプローチです。複雑な操作手順をMarkdownファイルに記述してスキルとして登録すれば、ユーザーはスラッシュコマンド1つで呼び出せます。
スキルに閉じ込める対象は、Git worktreeに限りません。プロジェクト固有のデプロイ手順、複雑なテスト実行コマンド、環境構築の手順書など、「手順が多くて面倒だけど、やることは毎回同じ」という操作が候補になります。
ポイントは、スキルを設計するときに「変わる部分」と「変わらない部分」を見極めることです。今回でいえば、worktreeの作成ロジックは変わらない部分、セットアップ処理は変わる部分でした。変わる部分だけをオーバーライド可能にしておくと、汎用性と柔軟性を両立できます。
まとめ
チーム内で「worktreeは難しい」と敬遠されていた並列開発が、Git worktreeの複雑な操作をClaude Codeスキルに閉じ込めることで、誰でも気軽に使えるものになりました。
設計面では、worktree作成と環境セットアップを分離し、プロジェクトごとにセットアップをカスタマイズできるようにしました。この分離によって、他のエージェントやスキルからも再利用しやすくなっています。
「手順が多くて面倒な操作」を見つけたら、スキルに閉じ込められないか検討してみてください。Claude Codeのスキルは、チームの開発体験を底上げする強力な手段です。
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。
