0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

サブエージェントとGit Worktreeの違いをゼロから理解する

0
Posted at

はじめに

はじめまして、テックバディ運営の大下です。

Claude Codeを使い込んでくると、必ず「並列で動かしたい」という欲が出てきます。そこで調べ始めると、2つの言葉にぶつかります。

  • サブエージェント(Subagent)
  • Git Worktree

どちらも「並列」「分離」「独立」という説明が付いてまわるため、多くの人がここで混乱します。

  • 「サブエージェントを使えばWorktreeは要らない?」
  • 「Worktreeを使えば並列になるなら、サブエージェントは何のため?」
  • 「両方使うの? どっちが先?」

結論を先に言います。この2つは競合しません。分離している対象がまったく違うからです。

何を分離するか 何のために
Git Worktree 作業領域(ファイル・ブランチ) 同じファイルを同時に編集して壊さないため
サブエージェント 文脈(コンテキストウィンドウ) メインの会話がログや検索結果で埋まらないため

この記事では、それぞれをゼロから説明したうえで、違い・使い分け・組み合わせ方を整理します。

本記事の内容は、2026年8月時点の Claude Code公式ドキュメント および Git公式ドキュメント を根拠にしています。


1. Git Worktreeとは何か(Claude Codeとは無関係のGitの機能)

まず押さえておきたいのは、Git WorktreeはClaude Codeの機能ではなく、Git本体の機能だということです。Git 2.5(2015年7月)で導入された、10年以上の歴史がある機能です。

1-1. 「1リポジトリ = 1作業ディレクトリ」をやめる仕組み

普段のGitでは、リポジトリと作業ディレクトリが1対1です。ブランチを切り替えると、同じディレクトリの中身が丸ごと入れ替わります。

これが困るのは、こういう場面です。

機能開発の途中で、緊急のバグ修正を頼まれた。
git stash して main に切り替えて…… ビルド成果物が吹き飛んで、npm install からやり直し。修正が終わったら元のブランチに戻して git stash pop。

Worktreeは、この「切り替え」自体をなくします。1つのリポジトリに対して、複数の作業ディレクトリを同時に持てるようにする機能です。

# 新しいブランチを切って、別ディレクトリに作業領域を作る
git worktree add ../project-feature-a -b feature-a

# 既存のブランチをチェックアウトした作業領域を作る
git worktree add ../project-bugfix fix-issue-456

# 一覧
git worktree list

# 不要になったら削除
git worktree remove ../project-feature-a

これで ../project-feature-a と ../project-bugfix という独立したディレクトリができ、それぞれ別のブランチをチェックアウトした状態になります。ターミナルを2つ開けば、両方で同時に作業できます。

1-2. 何が共有され、何が分かれるのか

Git公式ドキュメントによる整理はこうです。

共有されるもの

  • リポジトリの設定ファイル
  • refs/ 以下の参照(ブランチ、タグ)
  • ほとんどのオブジェクト(=コミット履歴そのもの)

Worktreeごとに分かれるもの

  • HEAD(いまどのコミットにいるか)
  • index(ステージングエリア)
  • refs/bisect、refs/worktree など一部の参照

つまり、履歴は1つのまま、作業状態だけが複数持てるということです。git clone を2回する(履歴も2つになる)のとは根本的に違います。

1-3. 1つだけ制約がある

同じブランチを2つのWorktreeで同時にチェックアウトすることはできません。 git worktree add は、そのブランチが他のWorktreeですでにチェックアウトされている場合、作成を拒否します(--force で上書きは可能ですが、通常は避けるべきです)。

Worktreeを増やすときは、必ずブランチも分けると考えておけば間違いありません。


2. サブエージェントとは何か(Claude Codeの機能)

こちらはClaude Code固有の機能です。Gitとは何の関係もありません。

2-1. 「別のコンテキストウィンドウで働く担当者」

サブエージェントは、メインの会話とは別のコンテキストウィンドウを持って動く、専門特化のClaudeです。

なぜこれが必要なのか。たとえば「テストを全部走らせて、失敗しているものを教えて」と頼んだとします。素直にメインの会話でやると、こうなります。

あなた: テストを全部走らせて、失敗しているものを教えて
Claude: [pnpm test 実行]
        → 800行のテスト出力がコンテキストに入る
        → さらにエラー箇所のファイルを5つ読む
        → 2,000行がコンテキストに入る
Claude: 3件失敗しています。auth.test.ts:42, ...

答えは3行なのに、そこに至る過程で数千行がコンテキストを占領します。 しかもその中身は、以降の会話で二度と参照しません。コンテキストが埋まると、要約(compact)が発生したり、以前の指示が効きにくくなったりします。

サブエージェントは、この汚れ仕事を別の部屋でやらせて、結果の要約だけを持ち帰らせる仕組みです。

2-2. 何が引き継がれ、何が引き継がれないのか

ここが最重要です。サブエージェントはまっさらな状態から始まります。

引き継がれる 引き継がれない
サブエージェント自身のシステムプロンプト メイン会話のメッセージ履歴
委譲時にClaudeが書いたタスク指示 出力スタイルの設定
CLAUDE.md の階層すべて メイン会話の auto memory
Gitステータスのスナップショット 他のエージェントのツール呼び出し履歴
skills フィールドで指定したSkillの中身

「メイン会話の履歴が引き継がれない」 というのが、実務で一番効いてきます。「さっき話した件、続きをやっておいて」はサブエージェントには通じません。指示は自己完結している必要があります。

なお例外として、フォーク(fork)されたサブエージェントはメイン会話のコンテキストをまるごと引き継ぎます。インタラクティブなセッションではフォークモードが既定で有効です。

2-3. 定義の書き方

サブエージェントは .claude/agents/ にMarkdownファイルとして置きます。

---
name: test-runner
description: テストスイートを実行し、失敗を報告する。コード変更後に積極的に使う
tools: Read, Grep, Glob, Bash
model: sonnet
maxTurns: 5
---

あなたはテスト担当です。テストスイートを実行し、失敗したテストを特定して、
ファイル名・行番号・失敗理由を含む簡潔なレポートを返してください。
成功したテストの出力は報告に含めないでください。

置き場所によってスコープが変わります。

置き場所 スコープ
.claude/agents/ このプロジェクト(gitにコミットしてチーム共有)
~/.claude/agents/ 自分の全プロジェクト

呼び出し方は3通りあります。

  1. 自然言語:「test-runnerサブエージェントを使ってテストを直して」(Claudeが判断して使う)
  2. @メンション:@agent-test-runner と入力(確実に呼び出せる)
  3. セッション全体:claude --agent test-runner で起動する

【スクショ指定】サブエージェントが動いている最中のClaude Code画面のスクリーンショットを掲載する。タスクリストにサブエージェント名と実行状況が表示されている部分が分かるように。/tasks の一覧画面でも可。


3. 決定的な違い:分離しているものが違う

ここまでを踏まえて、正面から比較します。

Git Worktree サブエージェント
提供元 Git本体 Claude Code
分離するもの ファイルとブランチ(作業領域) コンテキストウィンドウ(文脈)
解決する問題 並行作業でファイルが衝突する メインの会話がログで埋まる
単位 ディレクトリ 会話(セッション内のタスク)
並列性 人間が複数セッションを開いて並列にする Claudeが複数を同時に走らせる(既定で最大20)
コンテキスト 分離しない(同じセッションのまま) 完全に分離される
成果物 Worktree内のファイル変更・コミット メイン会話に返される要約テキスト

公式ドキュメントの位置づけが、この関係を端的に表しています。並列実行の手段を比較したページで、Worktreeは「手段そのもの」ではなく「それを支える道具」として紹介されています。

Three more tools support this work without being a way to run agents themselves: Worktrees give each session a separate git checkout, so parallel sessions never edit the same files.
(3つの道具が、それ自体はエージェントを走らせる方法ではないが、この作業を支える。Worktreeは各セッションに別々のgitチェックアウトを与え、並列セッションが同じファイルを編集しないようにする)

つまり、

  • サブエージェント=「誰が」やるかを分ける
  • Worktree=「どこで」やるかを分ける

という関係です。並列化そのものを担うのはサブエージェント(やセッション)側で、Worktreeはその足元を安全にする役割です。

判断のしかた

「調査だけさせたい」なら、ファイルを書き換えないのでWorktreeは不要です。逆に「自分が機能開発をしている裏で、別のリファクタを走らせたい」なら、ファイルが衝突するのでWorktreeが要ります。


4. 組み合わせて使う:isolation: worktree

2つは競合しないので、同時に使えます。 そして、それを1行で書けるようになっています。

4-1. サブエージェントに専用のWorktreeを持たせる

サブエージェントの定義に isolation: worktree を書くだけです。

---
name: refactorer
description: 多数のファイルにまたがる機械的なリファクタを適用する
isolation: worktree
---

要求されたリファクタを該当する全ファイルに適用し、テストを実行して結果を報告してください。

こうすると、このサブエージェントは一時的なWorktreeの中で動きます。メインのチェックアウトのファイルには一切触れません。大規模リファクタのように「試させたいが、失敗したときに巻き込まれたくない」作業に向いています。

セッション自体をWorktreeで動かしたい場合は、起動時にフラグを渡します。

claude --worktree feature-auth

既定では、リポジトリルートの .claude/worktrees/<name>/ に、worktree-<name> という新しいブランチで作成されます。

【スクショ指定】claude --worktree feature-auth を実行した直後の画面と、その状態で git worktree list を実行した結果を並べたスクリーンショットを掲載する。作業ディレクトリが .claude/worktrees/feature-auth になっていることが分かる。

4-2. 隔離は「お願い」ではなく強制される

ここが安心できる点。Worktreeで隔離されたセッションに対して、Claude Codeは4つのチェックを強制的にかけます。

  1. ファイル編集:メインチェックアウトのパスを対象とする Edit / Write / NotebookEdit をブロック
  2. コマンドの作業ディレクトリ:作業ディレクトリがメインチェックアウトに解決されるBashコマンドをブロック
  3. gitのリダイレクト:git -C、--git-dir、GIT_DIR などでgitをメインチェックアウトに向ける操作をブロック
  4. コマンドの形:Worktree内に留まると検証できないコマンド(追跡できないブレース展開やヒアドキュメントなど)をブロック

この4つ目のチェックはオフにできません。「Claudeが気をつける」ではなく「Claude Codeが弾く」仕組みになっています。

4-3. どのブランチから枝分かれするか

既定では、リポジトリのデフォルトブランチ(通常は main)のリモート最新から作られます。「いま自分が書いている途中のコード」の上で作業させたい場合は、設定を変えます。

// .claude/settings.json
{
  "worktree": {
    "baseRef": "head"   // 既定は "fresh"(デフォルトブランチから)
  }
}

進行中の作業に対してリファクタを走らせたいなら "head"、クリーンな状態から試させたいなら "fresh" です。


5. 初心者がハマるポイント

5-1. Worktreeには node_modules も .env も無い

Worktreeは新しいチェックアウトです。gitに追跡されていないファイルは1つも入っていません。作った直後に「動かない」と言われるのは、たいていこれです。

.env のようなgitignoreされたファイルを毎回コピーしたいなら、プロジェクトルートに .worktreeinclude を置きます。

.env
.env.local
config/secrets.json

.gitignore と同じ記法で書き、「パターンに一致し、かつgitignoreされているファイル」だけがコピーされます(追跡済みファイルが二重にコピーされることはありません)。依存関係のインストールは、Worktree内で自分で走らせるかClaudeに頼んでください。

5-2. .claude/worktrees/ を .gitignore に入れる

既定の作成先がリポジトリ内なので、これを忘れるとメインのチェックアウトで大量の未追跡ファイルとして見えてしまいます。公式ドキュメントでも推奨されています。

# .gitignore
.claude/worktrees/

5-3. サブエージェントには「何を報告してほしいか」まで書く

返ってくるのは要約だけです。サブエージェントの中で読んだファイルの中身は、メイン会話からは見えません。

そのため、「調べておいて」だけだと、必要な情報が返ってこないことがあります。定義やタスク指示に、報告フォーマットを明示してください。

レポートには必ず以下を含めてください:
- 失敗したテストのファイル名と行番号
- エラーメッセージの1行目
- 原因として疑われる箇所(該当ファイルのパスと行番号)
成功したテストは列挙しないでください。

5-4. 「さっきの話」は通じない

前述のとおり、サブエージェントはメイン会話の履歴を引き継ぎません。「先ほど決めた方針で進めて」は伝わらないので、判断の前提を毎回渡すか、そもそも CLAUDE.md に書いておく(これは引き継がれます)必要があります。

5-5. 並列はトークンを増やす

公式ドキュメントも注意喚起しています。

Running several sessions or subagents at once multiplies token usage.

サブエージェントは既定で最大20並列まで動きます。速くはなりますが、そのぶんトークン消費も増えます。「並列にできるから並列にする」ではなく、「メインのコンテキストを守りたいから分ける」「ファイル衝突を避けたいから分ける」という目的から選んでください。

5-6. 変更が残っているWorktreeは自動削除されない

サブエージェント用のWorktreeは、変更がなければ終了時に自動で片付けられます。変更が残っている場合は、作業を失わないようディスク上に残ります。

手動で消すときはこうです。

git worktree list                          # まず確認
git worktree remove .claude/worktrees/foo  # 削除
# 未コミットの変更がある場合は --force が必要

ロックされていて消せない場合は、先に git worktree unlock を実行してください。


まとめ

もう一度、核心だけを書きます。

サブエージェントは「文脈」を分離し、Git Worktreeは「作業領域」を分離する。

  • Git WorktreeはGit本体の機能。1つのリポジトリに複数の作業ディレクトリを持たせ、ファイルの衝突を防ぐ。履歴は共有され、HEAD と index だけが分かれる
  • サブエージェントはClaude Codeの機能。別のコンテキストウィンドウで作業し、要約だけを返す。メイン会話の履歴は引き継がない
  • 2つは競合しない。サブエージェントに isolation: worktree を付ければ、文脈も作業領域も両方分離できる
  • Worktree内での隔離は、Claude Codeが4つのチェックで強制する。お願いベースではない

最初の一歩としては、まずサブエージェントから試すことをおすすめします。ファイルを書き換えない調査タスク(「このリポジトリで認証はどう実装されている?」など)をサブエージェントに投げてみると、メインの会話がどれだけ軽く保たれるかがすぐ体感できます。

Worktreeが必要になるのは、書き込みが並行して走り始めてからです。そのタイミングが来たら、isolation: worktree を1行足すだけで済みます。

参考リンク


宣伝

最後に少しだけ宣伝させてください。

私たちは テックバディ という、フルスタックAIエンジニア育成コースを運営しています。

この記事で扱った「文脈の分離」と「作業領域の分離」は、カリキュラムのPhase 3で扱うテーマの1つです。AI駆動開発で成果を出せるかどうかは、AIに渡すコンテキストをどう設計・分割するかにかなりの部分がかかっています。

  • コンテキストウィンドウの仕組みと、サブエージェント・Worktreeによる分離設計
  • CLAUDE.md・Skills・hooks・パーミッションを組み合わせたガードレール設計
  • Next.js / TypeScript / FastAPI / PostgreSQL といった実務スタックでの開発演習
  • メンターとの週1回の1on1

といった内容で構成しています。

「AIを1人で使うことはできるが、複数を並行して動かす設計まではできない」という方は、ぜひ一度ご覧ください。

👉 テックバディの詳細・お問い合わせはこちら

最後までお読みいただきありがとうございました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?