Claude Codeの複数セッションをGit worktreeで並行運用する方法｜AI駆動開発を安全に並列化する設計
生成AIを使った開発では、1つのClaude Codeセッションにすべての作業を任せるよりも、
- フロントエンド担当
- バックエンド担当
- テスト担当
- ブラウザ実測担当
- レビュー担当
といった形で、複数のAIエージェントを並行して動かした方が開発速度を上げやすくなります。
一方で、実際に複数のClaude Codeセッションを同時に動かしてみると、別の問題が発生します。
「どのセッションがどのコードを触っているのか」
「別セッションが検証したコードは、本当に最新版なのか」
「同じブラウザやテスト環境を複数AIが同時に操作しないか」
「AI同士の『確認しました』をどこまで信用してよいのか」
という、いわばAIエージェント間の交通整理です。
そこで有効なのが、
Claude Codeの複数セッション + Git worktree + Git commit + Issue / PR / CI
を組み合わせた並列開発です。
本記事では、実際に複数のClaude Codeセッションを並行運用した経験をもとに、AI駆動開発を安全にスケールさせるための構成を紹介します。
Claude Codeは複数セッション間でメッセージを送れる
2026年8月、Claude Codeにcross-session messagingが追加されました。
これは、独立して起動しているClaude Codeセッション同士でテキストメッセージをやり取りできる機能です。
Claude Codeでは主に、
ListAgents
で到達可能なセッションを探し、
SendMessage
で別セッションへメッセージを送ります。
同一マシン上ではセッションごとのローカル通信経路が利用され、メッセージそのものはAnthropicのサーバーを経由しない構成も公式ドキュメントで説明されています。
例えば、次のようなやり取りができます。
バックエンド担当 →
フロントエンド担当
APIレスポンス仕様を変更しました。
最新HEADを取り込んで再確認してください。
あるいは、
テスト担当 →
他セッション
これから共有ブラウザを使用します。
完了するまでブラウザ操作を避けてください。
といった使い方です。
従来は人間がターミナル間を行き来し、Claude Codeの回答をコピー＆ペーストする必要がありました。
cross-session messagingを利用すると、この調整そのものをClaude Codeに任せられます。
ただし「メッセージだけ」で並列開発するのは危険
ここで重要なのは、
Claude Code同士が会話できる = 安全に並列開発できる
ではないということです。
cross-session messagingで渡されるのは、基本的にテキストです。
会話履歴やファイル一式がそのまま別セッションへ移動するわけではありません。
例えば、
修正終わりました。
確認お願いします。
というメッセージだけでは、受信側からすると、
「どのコード？」
「どのブランチ？」
「いつの状態？」
「その後変更されていない？」
という問題が残ります。
そのため、Claude Codeの並列運用では、会話ではなくGitを状態管理の基準にすることが重要です。
Git worktreeでAIごとの作業場所を分離する
そこで役立つのがGit worktreeです。
Git worktreeを使うと、1つのGitリポジトリに対して複数のWorking Treeを作成し、それぞれ異なるブランチを同時にチェックアウトできます。
Git公式ドキュメントでも、1つのリポジトリから複数のworking treeを持ち、複数ブランチを同時に扱える仕組みとして説明されています。
例えば、
project/
project-agent-a/
project-agent-b/
project-test/
という作業ディレクトリを用意します。
そして、
Agent A
↓
project-agent-a
Agent B
↓
project-agent-b
Test Agent
↓
project-test
のようにClaude Codeセッションごとに担当worktreeを固定します。
こうすることで、複数のClaude Codeが同じファイルを直接上書きし合うリスクを大きく減らせます。
「セッション」と「レーン」を分けて考える
複数AIを運用するときに特に重要なのが、
Claude Codeセッションと作業レーンを同一視しないこと
です。
例えば「フロントエンドレーン」という作業区画を作ったとします。
このレーンには、
- 専用worktree
- 専用Gitブランチ
- 担当画面
- テスト対象
- 実測結果
などが紐づきます。
一方、Claude Codeセッションはあくまで、そのレーンで現在作業しているAIプロセスです。
Claude Codeセッションを終了しても、Git worktreeやcommitは残ります。
そのため、
Issue
↓
何を解決するか
レーン
↓
どこで誰が作業するか
Claude Codeセッション
↓
現在動いているAI
と分けて管理すると、長期間のAI開発でも状態が崩れにくくなります。
Claude Code並列開発の基本構成
実際の運用では、次のような構成が扱いやすいです。
人間 / 司令塔
│
┌──────────┼──────────┐
│ │ │
Claude A Claude B Claude C
│ │ │
worktree A worktree B worktree C
│ │ │
└────── Git ──────────┘
│
Issue / PR
│
CI
│
最終マージ
役割はそれぞれ異なります。
| 層 | 主な役割 |
|---|---|
| Claude Codeセッション | 実装・調査・テスト・連絡 |
| Git worktree | 作業場所の分離 |
| Git commit / HEAD SHA | コード状態の固定 |
| Issue / plans / PR | 判断・証跡の保存 |
| CI | 自動検証 |
| 人間 | 優先順位・承認・最終マージ |
ポイントは、
AIに全部任せるのではなく、責務ごとに管理手段を分離すること
です。
AI間のコード受け渡しはHEAD SHAを基準にする
複数エージェント運用で、特に効果が大きかったのが、
依頼時にGitのHEAD SHAを必ず指定する
というルールです。
例えば、
検証対象HEAD:
d73ca3c5
変更内容:
共通コンポーネント修正
対象:
画面A / 画面B / 画面C
依頼:
ブラウザで再実測してください
のように送ります。
すると受信側は、
git checkout d73ca3c5
あるいは対象commitを自分のworktreeへ取り込むことで、同じコード状態を再現できます。
「最新版を確認しました」
より、
「d73ca3c5を確認しました」
の方が圧倒的に再現性が高くなります。
Claude Code同士のメッセージは「調整」に使う
cross-session messagingは便利ですが、Gitの代わりとして使うものではありません。
向いているのは、
- 作業依頼
- 状況共有
- リソース予約
- ブロッカー通知
- 再検証依頼
などです。
一方、
- 実装そのもの
- 正式な検証結果
- 変更履歴
- 承認記録
はGitやIssue、PRなどに残した方が安全です。
つまり、
メッセージはリアルタイム調整、Gitは再現性
という役割分担です。
共有ブラウザ・テスト環境には「ロック」が必要
複数のAIエージェントを動かしていると意外と問題になるのが、コードではなく外部リソースです。
例えば、
- Playwright用ブラウザ
- ローカル開発サーバー
- テストDB
- ステージング環境
- 共通アカウント
などです。
複数のClaude Codeが同時に操作すると、
「別エージェントが画面遷移した」
「テストデータを書き換えた」
「ログイン状態が変わった」
といった現象が発生します。
するとAIは、
コードの不具合なのか、他エージェントによる状態変更なのか
を判断できません。
そこで、
これからブラウザを使用します。
対象:
管理画面
用途:
回帰テスト
完了後:
結果を共有します
のように、使用開始・終了をメッセージで宣言します。
かなりアナログに見えますが、並列AI開発ではこの仕組みが非常に重要です。
共通ファイルの変更は影響範囲を先に調べる
AI並列開発で危険なのが、共通処理の変更です。
例えば、
共通コンポーネント
共通API
共通テストRunner
共通型定義
などです。
1行しか変更していなくても、10画面に影響する可能性があります。
そのため共通ファイルを変更する場合は、
変更
↓
影響範囲調査
↓
担当レーン特定
↓
各レーンへ再検証依頼
という流れにします。
AIが高速にコードを書くほど、この「影響範囲管理」の重要性は上がります。
Subagent・Agent Teams・Cross-session messagingの違い
Claude Codeには複数の並列化方法があります。
大きく分けると、
| 方式 | 特徴 |
|---|---|
| Subagent | 親エージェントが一時的に作業を委任 |
| Agent Teams | リーダーが複数のTeammateを管理 |
| Cross-session messaging | 独立して起動したClaude Code同士が通信 |
という違いがあります。
Anthropicの資料でも、Claudeの新しいモデルはsubagentによる作業分割を積極的に利用でき、独立性の高い作業や並列可能な作業をsubagentへ割り当てる考え方が説明されています。
Agent TeamsではリーダーとなるClaude CodeがTeammateを生成し、共有タスクを管理する構成になります。
一方、cross-session messagingは、
もともと独立して起動していたClaude Codeセッション同士を連携させる
ための仕組みです。
長期間担当を持つAI開発では、
独立セッション
+
Git worktree
+
cross-session messaging
という構成が非常に扱いやすくなります。
AIエージェントを増やすほど「ハーネス」が重要になる
Claude Codeを1セッションだけ使う場合、多少管理が曖昧でも人間が把握できます。
しかし、
2セッション
3セッション
5セッション
10セッション
と増やしていくと、人間の頭だけでは管理できなくなります。
ここで重要になるのが、AIそのものではなくAIを囲む開発ハーネスです。
例えば、
Issue
↓
担当レーン決定
↓
worktree作成
↓
Claude Code実装
↓
commit
↓
別Claude Codeで検証
↓
結果保存
↓
PR
↓
CI
↓
人間がマージ
という流れを標準化します。
生成AIの性能が上がれば上がるほど、
「コードを書く速度」
より、
「複数AIが安全に働ける仕組み」
の方がボトルネックになっていきます。
AI同士の「確認しました」を信用しすぎない
AI駆動開発で非常に重要なのが、AIの返答を証跡と混同しないことです。
例えば、
確認しました。
問題ありません。
という回答が返ってきても、
- どのcommitを見たのか
- どの環境なのか
- どのテストを実行したのか
- いつ確認したのか
が分からなければ、正式な検証結果としては弱いものになります。
そのため、
HEAD SHA
テスト対象
実行コマンド
結果
残課題
まで残します。
AI開発では、
会話ではなく証跡を見る
という考え方が重要です。
実際に使いやすいセッション間メッセージ
例えば別AIへ作業を依頼するときは、次のような形式にします。
件名:
UI再検証依頼
基準HEAD:
<commit SHA>
変更内容:
共通コンポーネント修正
対象:
画面A / 画面B / 画面C
依頼:
対象画面を再実測
共有資源:
ブラウザ使用予定
返却してほしい内容:
・実測結果
・確認したHEAD
・変更ファイル
・残課題
単に、
確認お願いします
と送るよりも、作業の曖昧さをかなり減らせます。
並列AI開発で起きやすい問題
複数Claude Codeを運用していると、いくつか典型的な問題が発生します。
古いHEADをテストしてしまう
あるAIがテストを開始したあと、別AIが共通処理を変更すると、テスト結果がすぐに古くなります。
対策として、
テスト開始時のHEADを必ず記録する
ようにします。
worktreeとClaude Codeセッションを間違える
セッション名が「Frontend」でも、実際に開いているディレクトリがFrontend用worktreeとは限りません。
作業開始時に、
git status
git branch --show-current
git rev-parse HEAD
などで確認します。
AIのメッセージを承認として扱ってしまう
別Claude Codeが、
問題ありません
と答えても、それは人間の承認ではありません。
AI同士の通信はあくまで調整です。
正式な受入や本番マージは、プロジェクトのルールに従って行います。
最終マージは人間が持つ設計も有効
AIに、
- 実装
- テスト
- PR作成
- CI確認
まで任せても、
mainへのマージ
本番デプロイ
重要な仕様変更
は人間が判断する設計にしておくと、AIの速度とガバナンスを両立しやすくなります。
特に複数AIが並列で動く環境では、
「誰が最後に責任を持つのか」
を明確にしておくことが重要です。
Claude Code × Git worktreeはAI駆動開発の基本構成になりそう
Git worktree自体は新しい技術ではありません。
しかし、
Claude Code
+
複数セッション
+
Cross-session messaging
+
Git worktree
+
GitHub
+
CI
を組み合わせることで、Git worktreeの価値が大きく変わってきています。
以前のworktreeは、
「人間が複数ブランチを同時に触るための便利機能」
という位置付けでした。
AI駆動開発では、
「AIエージェントごとの作業領域を分離するための基盤」
として非常に相性が良い仕組みになります。
まとめ
複数のClaude Codeを並行運用する場合、
単純にAIの数を増やすだけでは安定しません。
重要なのは、
- Claude Codeセッションを独立させる
- Git worktreeで作業場所を分離する
- commit SHAで作業対象を固定する
- cross-session messagingは調整に使う
- Issue / PRへ判断を残す
- CIで自動検証する
- 共有ブラウザや環境を排他制御する
- 最終判断者を明確にする
という構造です。
Claude Codeを1人の優秀なエンジニアとして使う段階から、
複数のAIエンジニアをどう組織化するか
という段階へ、AI駆動開発は少しずつ移りつつあります。
今後モデルのコーディング能力がさらに上がれば、ボトルネックになるのはコード生成速度ではありません。
「誰が何を担当しているか」
「どのコードを検証したか」
「その結果を信用できるか」
という、エージェントを制御するハーネス設計の方が重要になってくると考えています。
弊社でもAI駆動開発では、単純に生成AIへコードを書かせるだけではなく、複数エージェントを安全に並列化しながら、Git・テスト・CIを使って検証可能な開発フローを構築しています。
