【ITニュース解説】Git worktree + Claude Code: My Secret to 10x Developer Productivity

システムエンジニアを目指す皆さんにとって、日々の開発作業をいかに効率的に進めるかは非常に重要な課題である。特に、複数のタスクを同時に抱え、それらを切り替えながら作業を進める際に生じる「コンテキストスイッチング」という問題は、多くの開発者の生産性を低下させる要因となっている。

コンテキストスイッチングとは、ある作業から別の作業に切り替える際に、それまで集中していた内容を一度頭の中から出し、新しい作業の内容を入れ直すという精神的な負担を指す。例えば、ある機能の開発中に緊急のバグ修正依頼が入ったとする。開発者はまず、作業中の変更を一時的に保存するか、慌ただしくコミットする必要がある。次に、バグ修正用のブランチに切り替え、頭をバグの状況に合わせ直し、修正作業を行う。そして、修正が完了したら元の機能開発に戻り、どこまで作業が進んでいたかを思い出す必要がある。この一連の作業は、集中力と時間の両方を大きく消費し、元の作業に戻ったときには、失われた思考の流れを取り戻すのに時間がかかってしまう。このような状況が頻繁に発生すると、開発者の生産性は大きく損なわれてしまう。

この問題を解決するため、ある開発者が発見したのは、「Git worktree」と「Claude Code」という二つの強力なツールを組み合わせるワークフローである。この方法は、開発者が複数のコーディングタスクに同時に取り組むことを可能にし、コンテキストスイッチングによる精神的な負担を劇的に軽減する。具体的には、それぞれのタスクに対して独立したGit worktreeを作成し、その中で専用のClaude Codeセッションを開始するというものだ。

まず、Git worktreeについて説明する。Git worktreeは、一つのGitリポジトリに対して複数の作業ディレクトリを持つことを可能にする機能である。これは、プロジェクトのコピーを複数持っているようなものだと考えられるが、それらのコピーはすべて同じGitの変更履歴を共有している点が特徴だ。例えば、メインのプロジェクトディレクトリから、特定の機能開発用のワークツリーや、バグ修正用のワークツリーを別々のディレクトリとして作成できる。それぞれのワークツリーは完全に独立した作業環境となり、そこで変更を加えたり、テストを実行したり、コミットを行ったりしても、他のワークツリーには影響を与えない。これにより、開発者は物理的に異なる場所で異なるブランチの作業を同時に進めることが可能になる。例えば、ある作業ディレクトリでユーザー認証機能の開発ブランチに取り組み、別の作業ディレクトリでログイン検証のバグ修正ブランチに取り組む、といったことが可能になるのだ。

次に、Claude Codeの役割についてである。Claude Codeは、Anthropicが開発した大規模言語モデル「Claude」をベースにしたAIコーディングアシスタントである。このワークフローでは、それぞれのGit worktreeに対して個別のClaude Codeセッションを立ち上げる。iTerm2のようなターミナルエミュレータの複数ペイン機能を利用し、各ペインで異なるワークツリーに移動し、そこでClaude Codeを開始する。それぞれのClaude Codeセッションは、その特定のタスクに関する独自のコンテキストを維持する。つまり、AIエージェントは、自分が今どのブランチで作業しているのか、どのファイルを扱っているのか、そしてその特定のチケットに関連するこれまでの会話履歴を記憶している。

この組み合わせによって得られるメリットは計り知れない。まず、「高いスループット」が実現される。開発者は3つから4つの異なるタスクに並行して取り組むことができる。例えば、あるペインでClaude Codeが解決策を実装している間に、別のペインでその作業内容をレビューしたり、全く別の問題について議論を開始したりできるのだ。次に、「最小限のコンテキストスイッチング」が可能となる。各Claude Codeセッションは、これまでの会話履歴をすべて記憶しているため、開発者がタスクを切り替えるたびに問題を最初から説明し直す必要がない。これにより、開発者の入力が最小限で済み、精神的な負担が大幅に軽減される。さらに、「完璧なコンテキスト分離」も重要なメリットだ。各ワークツリーとClaude Codeセッションは完全に独立しているため、認証機能に取り組んでいるAIエージェントが、別のペインで取り組んでいるバグ修正に関する混乱を抱えることはない。そして、「どこからでも作業を再開できる」という点も大きな利点である。開発者は、会話の途中でタスクを離れ、数時間後や数日後に戻ってきても、Claude Codeセッションは中断した場所や目標、これまでに試したアプローチなどを正確に記憶しているため、すぐに作業を再開できる。

このワークフローを自身の環境で設定するには、まずメインのプロジェクトディレクトリから、各チケットやタスクに対応するGit worktreeを別々のディレクトリとして作成する。次に、iTerm2のようなターミナルエミュレータを開き、水平分割（Cmd+Shift+D）や垂直分割（Cmd+D）を使って複数のペインに分割し、好みの配置にする。そして、各ペインで対応するワークツリーに移動し、Claude Codeセッションを開始する。最後に、それぞれのClaude Codeセッションに、特定のタスクについて説明し、関連するコードファイルを示し、何を達成しようとしているのかを伝えることで、コンテキストを確立する。

このワークフローから得られた重要な教訓は、コンテキストの保持が予想以上に価値があるということだ。Claude Codeと複数の並行した会話を維持し、それぞれを特定の課題領域に集中させる能力は、常にコンテキストを再確立するという認知的オーバーヘッドを排除する。この組み合わせは、Git worktreeが技術的な分離問題を解決し、Claude Codeがコンテキスト維持問題を解決し、そして複数ペインが切り替えの問題を解決しているからこそ機能する。

ただし、このワークフローには考慮すべきトレードオフも存在する。複数のClaude Codeセッションを同時に実行することは、より多くのシステムリソースとAPI呼び出しを消費する可能性がある。また、コンテキストスイッチングの負担は軽減されるものの、複数のタスクを精神的に追跡する必要は依然として残るため、ある程度の認知負荷は伴う。さらに、構成要素が増えることで、複雑性が増し、問題が発生する可能性もわずかながら高まる。

いくつかの疑問も提起されているが、その解決策も提示されている。Claude Codeセッションの再開については、単にターミナルペインを閉じないことで、セッションがコンテキストを永続的に維持するという。ブランチの同期やマージの競合については、各ワークツリーのブランチが最終的にメインブランチに対してプルリクエスト（PR）を開くというワークフローを前提としており、分離されているためPRの時点まで同期を心配する必要はないとされる。Claudeのコンテキストウィンドウの制限は課題であり、コンテキストが大きくなりすぎた場合は、新しくセッションを開始したり、見せるファイルを厳選したりする必要がある。このワークフローは、事前に要件が明確に分解された機能開発やバグ修正に適しており、探索的な作業や要件が曖昧な場合には過剰になる可能性がある。テストは各ワークツリーで独立して実行されるため、ハードコードされたポートや共有リソースを使用しない限り、並行テスト実行は問題なく機能する。iTerm2のCmd+Iショートカットを使って、各ペインにチケット番号や機能名を割り当てることで、どのペインがどのタスクに対応しているかを管理できる。古いワークツリーのクリーンアップは今後の課題であり、git worktree pruneコマンドは削除されたブランチに対応するが、手動でのクリーンアップも必要となる。

このワークフローは、開発作業へのアプローチを根本的に変える可能性を秘めている。割り込みやコンテキストスイッチングを恐れるのではなく、複数のフロントで並行して進捗を生み出す機会と捉えることができるようになる。シェルエイリアスの作成、tmuxを活用したセッション管理、設定プロセスの自動化スクリプトの開発、ワークツリーのクリーンアップルーチンの構築など、さらなる最適化の可能性も探求されている。