Claude Code をはじめとするコーディングエージェントを日常の開発作業に組み込み、複数のタスクを並列で実行させる開発者が増えています。その際、エージェント同士のファイル競合を防ぐ標準的なアプローチとして広く使われているのが git worktree です。

コマンド一つで別の作業ディレクトリを生成でき、ブランチの切り替えに伴う git stash やコンテキストの混乱を回避できるため、「Worktree を分けたから、これで各エージェントは安全に独立して作業できる」と考えがちです。

しかし、結論から言うと git worktree は作業ツリー（作業ディレクトリ）を分離する仕組みであり、実行環境やセキュリティの分離境界（サンドボックス）ではありません。

本記事では、Linked Worktree が内部で共有しているメタデータの仕組みを解剖し、Worktree を安全な「隔離壁」だと過信したときに起こり得る具体的な事故シナリオ、自社開発での実体験、そして本当に必要な 4 つの隔離境界線について解説します。

1. 導入: 「worktree で分けたから安心」という前提の危うさ

CLI ツールやエージェントフレームワーク（Claude Code の -w / --worktree オプションや、各種ツールの isolation: "worktree" 設定など）の普及により、複数エージェントを動かす際の基盤として git worktree を利用するケースが急増しています。

開発者の視点からは、エージェント A とエージェント B にそれぞれ別のディレクトリ（例: /path/to/project-worktree-1 と /path/to/project-worktree-2）が割り当てられ、ファイルシステム上も独立した空間に見えます。そのため、「作業ディレクトリが完全に別々だから、お互いの変更が干渉せず、ホスト環境も汚さない」という心理的安心感が生まれます。

しかし、エージェントにシェルコマンドの実行権限やファイルの書き込み権限を与えている場合、この「別ディレクトリだから安全」という直感は脆くも崩れ去ります。

2. Linked Worktree の正体: .git が共有される内部構造

なぜ git worktree は分離境界にならないのでしょうか。その理由は Git の内部アーキテクチャにあります。

Linked Worktree を作成した際、作成された作業ディレクトリ内の .git は普通のディレクトリではありません。中身を開くと、親リポジトリのメタデータを参照する単なるテキストファイルであることが分かります 1。

$ cat ../my-worktree/.git
gitdir: /path/to/repo/.git/worktrees/my-worktree

Git はリポジトリの状態を「Worktree 固有の状態」と「全体で共有される共通状態（Common Directory）」に明確に分離して管理しています 2。実際にコマンドを実行してパスを確認してみましょう。

$ cd ../my-worktree
$ git rev-parse --git-dir
/path/to/repo/.git/worktrees/my-worktree    # Worktree 固有の領域

$ git rev-parse --git-common-dir
/path/to/repo/.git                          # 親および全 sibling で共有される共通領域

ここで重要なのは、Worktree 固有として分離される領域は極めて限定的である という点です。

分離されるもの (Per-Worktree)共有されるもの (Common Directory .git/)
HEAD (チェックアウト中の参照)objects/ (Git オブジェクト全般)
index (ステージング領域)refs/ (refs/heads/*, refs/tags/*, refs/stash)
ORIG_HEADconfig (リポジトリ設定)
一部の rebase / bisect 状態hooks/ (すべての Git フックスクリプト)

つまり、ワーキングツリーとインデックス以外のほぼすべてのメタデータ（設定・フック・Stash・全オブジェクト・全参照）は、親リポジトリとすべての Worktree の間で 完全に共有 されています 2。

3. worktree を「境界」と信じたときに起きる 4 つの事故シナリオ

この共有構造を理解しないままエージェントに自律的なコマンド実行権限を与えると、次のような問題が発生する可能性があります 3。

シナリオ 1: ホスト上でのコード実行（.git/hooks 共有）

最も危険なのが .git/hooks ディレクトリの共有です。

ある Worktree 内で動くエージェントが、プロンプトインジェクションを受けるか、あるいは自身のタスクを自動化しようとして Git フックを書き換えたとします 3。

# Worktree A 内でエージェントが共通フックを書き換える
cd ../hook-agent
cat > "$(git rev-parse --git-common-dir)/hooks/pre-commit" <<'EOF'
#!/bin/sh
echo "*** 悪意あるコードまたは予期せぬスクリプトが $(whoami) 権限で実行されました ***"
EOF
chmod +x "$(git rev-parse --git-common-dir)/hooks/pre-commit"

フックは親の .git/hooks/pre-commit に直接保存されます。その結果、親リポジトリで人間開発者が日常のコミットを行った瞬間、ホストOS上のユーザー権限でそのフックスクリプトが自動実行 されます。Worktree という「壁」は、ホスト権限の実行を一切防げません。

シナリオ 2: コミット著者のすり替え（.git/config 共有）

リポジトリ設定である .git/config も全 Worktree で共通です 3。

Worktree A 内でエージェントが git config user.email "agent@example.com" を実行すると、親リポジトリおよび他 Worktree の設定も即座に書き換わります。その後、人間開発者が自分のリポジトリでコミットを作成しても、著者がエージェントのアドレスにすり替わってしまうといった混乱が生じます。

シナリオ 3: 他エージェントの作業の誤奪取・破壊（refs/stash 単一スタック問題）

Git の Stash 機構は、リポジトリ全体で単一の参照 refs/stash を共有しています 3。

エージェント A が一時的に変更を退避させようと git stash を実行した直後、別 Worktree で作業中のエージェント B が git stash pop を実行すると、エージェント A の変更がエージェント B の作業ツリーに突然適用されます。これにより、コードの混入や修正の破壊が発生します。

シナリオ 4: 参照とオブジェクトの混乱（refs/heads や git gc）

ブランチ参照（refs/heads/*）やオブジェクトデータベースも共有されています。

Git は同一ブランチの複数 Worktree での同時チェックアウトを阻止する保護機構を備えていますが、エージェントが git update-ref や git branch -f を用いてブランチ参照を強制的に変更することは防げません。また、エージェントが強硬なクリーンアップ操作や git gc を実行した場合、別 Worktree で作業中の未コミットオブジェクトが孤立・消滅するリスクがあります 2。

4. 実録: 自社開発で実際に起きた worktree 並列運用の限界

当開発チームの日常的な開発運用（実測検証ログ 4）においても、git worktree による並列エージェント実行を取り入れています。その運用の中で実際に体験したインシデントと限界をご紹介します。

背景インシデント（worktree 導入の動機）

かつて Worktree を使わず、単一の作業ディレクトリで複数のエージェントセッションを並行実行していた時期がありました。

あるセッションが作業を中断している間に、同一ディレクトリで動く別セッションが git reset を実行したことで、未コミットでステージ済みだった重要なスキルの修正差分が無言で消滅する事故が発生しました 4。このファイル直接衝突事故を物理的に回避するために導入されたのが git worktree でした。

運用の限界インシデント（worktree 導入後の事故）

しかし、Worktree を導入した後も新たな限界に直面しました。

エージェントツール側で isolation: "worktree" オプションを明示し、専用 Worktree 内でサブエージェントを実行していたにもかかわらず、ツールのカレントディレクトリ（cwd）保持の制御がすり抜け、サブエージェントがメインブランチ側の作業ディレクトリに対して誤ってコミットを連発する事故が同一作業中に複数回発生しました 4。

復旧のために git cherry-pick と reset --hard を繰り返した結果、同一のコミットメッセージ・Author Date を持った重複コミット履歴が残り、プルリクエストとして統合されるという事態になりました 4。

この実例が示しているのは、git worktree はあくまでファイルパスを整理する手段であり、ツールやエージェントの誤操作・親領域へのアクセスを物理的に遮断するセキュリティ境界にはなり得ない という運用の現実です。

5. 「作業ツリーの分離」と「実行環境の分離」の境界を引き直す

エージェント並列運用を安全に行うためには、「作業ツリーの分離（Working Directory Isolation）」と「実行環境の分離（Runtime & Sandbox Isolation）」を明確に区別する必要があります。

本当に保護すべき境界線は、以下の 4 レイヤーに整理できます。

AIコーディングエージェントのための 4 つのセキュリティ分離レイヤー

コンテナマウントの罠 (The Container Mount Trap)

「Docker コンテナ内でエージェントを動かしているから安全だ」と考える開発者は少なくありません。しかし、ここにも大きな罠が存在します 5。

コンテナに対してホスト上の Worktree ディレクトリ（.git を含む）を生のままバインドマウント（-v /path/to/worktree:/app）して実行した場合、コンテナ内のエージェントが .git/hooks や .git/config を書き換えると、その変更はホスト側の共有 .git へ即座に透過 します 5。

結果として、コンテナ外のホストで開発者がコミットした際にフックが発火し、コンテナによる隔離が容易に突破されてしまいます。

ツール固有の暗黙共有仕様

また、Git 自体だけでなく周辺ツールチェーンの共有仕様にも注意が必要です。

例えば Claude Code の自動記憶機構（Auto memory）は、同一 Git リポジトリ配下であれば、どの Worktree やサブディレクトリから実行されても単一の記憶ディレクトリを暗黙的に共有する仕様になっています 4。作業ディレクトリを分けたとしても、ツール側のコンテキストや記憶は裏でつながっていることを認識しておく必要があります。

6. 安全な並列実行を実現する 3 つのアプローチ

では、エージェントを安全に並列実行するにはどのような構成をとるべきでしょうか。代表的な 3 つのアプローチをご紹介します。

アプローチ 1: 独立クローン (git clone --reference) の採用

最もシンプルかつ確実に Git メタデータを隔離する方法は、Worktree ではなく独立した git clone を使用することです 3。

メタデータが完全に独立するため、フックや設定、Stash の競合は原理的に発生しません。ディスク容量やクローン時間を節約したい場合は、ローカルのオブジェクトデータベースを参照する --reference オプションを併用します。

git clone --reference /path/to/main-repo https://github.com/user/repo.git agent-work-1

アプローチ 2: OSレベルの権限制御 (nono)

ホスト上で軽量に権限を絞る場合、カーネル層のアクセス制御を利用するアプローチが有効です。

nono (nolabs-ai/nono) は、Linux の Landlock や macOS の Seatbelt (sandbox.kext) を利用して、エージェントプロセスの権限を制限するツールです 6。

エージェントに対して Worktree 外部へのアクセス禁止はもちろん、.git/hooks への書き込み遮断、Docker ソケットの非表示、特定の GitHub API 操作制限などをカーネルレベルで強制的におこなうことができます。

アプローチ 3: 完全な仮想環境・サンドボックス (agentbox / MicroVM)

最も堅牢なアプローチは、エージェントを完全に分離された MicroVM やコンテナサンドボックス内で実行することです。

agentbox (madarco/agentbox) などのツールでは、エージェントを独立したサンドボックス環境で起動し、Git 資格情報や SSH キーなどの秘匿情報をサンドボックス内に直接持たせず、ホスト側のプロキシ経由で中継・調停する構成（Credential Relay）をとります 7。

7. まとめ: 自分の並列実行環境の点検チェックリスト

git worktree は、複数の作業文脈を効率的に並行管理するための優れた「生産性向上ツール」です。しかし、それ自体をエージェントの悪意や誤操作からシステムを守る「セキュリティ境界」として期待することはできません。

最後に、ご自身の並列エージェント実行環境を点検するためのチェックリストを掲載します。

  • 1. フックの保護: エージェント実行環境から .git/hooks への書き込みが遮断されているか？
  • 2. 設定の孤立: .git/config の書き換えや参照が保護されているか？
  • 3. マウントの透過性: ホストの .git ディレクトリを生のまま Docker/VM にバインドマウントしていないか？
  • 4. Stash / Ref の共有: 複数の並列エージェントが単一の refs/stash や共通ブランチ参照にアクセスできる状態になっていないか？
  • 5. 資格情報の保護: SSH キーや API トークン、Git 認証情報がエージェントの環境変数に直接露出していないか？

エージェントとの安全で快適な協働開発環境を構築するために、本記事をきっかけに足元の実行境界を見直してみてはいかがでしょうか。

AI エージェントの安全な並列実行構成や、開発ツールのセキュリティ境界設計についてのご相談・お問い合わせは コンタクトフォーム よりお気軽にご連絡ください。

参考文献

Footnotes

  1. Git Official Documentation: git-worktree(1) (https://git-scm.com/docs/git-worktree) ↩

  2. Git Official Documentation: gitrepository-layout(5) (https://git-scm.com/docs/gitrepository-layout) ↩ ↩2 ↩3

  3. Alex Chaplinsky, “Git worktrees are not an isolation boundary for coding agents” (https://fletch.sh/blog/git-worktrees-vs-clones-for-ai-agents/) ↩ ↩2 ↩3 ↩4 ↩5

  4. 当開発チームによる実測検証ログ ↩ ↩2 ↩3 ↩4 ↩5

  5. Hacker News Discussion #49110389 (https://news.ycombinator.com/item?id=49110389) ↩ ↩2

  6. nolabs-ai/nono (https://github.com/nolabs-ai/nono) ↩

  7. madarco/agentbox (https://github.com/madarco/agentbox) ↩