btw` と `.worktreeinclude`¶

作成日: 2026-07-16 更新日: 2026-07-17（英語圏の実践知・GitHub Issue の一次情報・並行開発の運用知見を追加）出典 / きっかけ: 鹿野壮「【Claude Code】鹿野さんに聞く私の推しの並行開発環境大公開」（2026-07-15 connpass / Offers 主催）のスライド。各機能は Claude Code 公式ドキュメント（+ 手元の v2.1.210）で裏取りし、英語圏の一次情報を追加調査した関連: cmux_並列aiエージェント用ターミナル_整理 / Fable5_3日間で300万円課金_並列エージェント運用の物理的課題 / loop_engineering_入門 / llm_agent_sandbox_隔離技術

0. 要点¶

4つの機能は「コンテキストを引き継ぐか」×「誰が動くか（自分が移る / 別働隊が背後で走る）」×「ツールを使えるか」の座標で一意に決まる。個別に暗記するものではない。
決定的な対比は公式の一文 — 「/btw はサブエージェントの逆。/btw は会話の全部が見えるがツールがなく、サブエージェントはツールが全部あるが空のコンテキストから始まる」。この両極の間に /branch（自分が移る）と /fork（別働隊が背後で走る）が位置する。
⚠️ 名前は git の直感と逆 — 「/fork は帰ってくる（親の会話に結果を返す）、/branch は帰ってこない（merge-back が無い）」。ここを取り違えると設計を誤る。
.worktreeinclude は「gitignore されたものだけ」を新 worktree にコピーする。追跡済みは対象外。ただし WorktreeCreate hook を置くと黙って処理されなくなる罠がある。
並列度の上限を決めるのは技術ではなく人間。独立した実務者が揃って「能動管理は3〜4スレッドが上限」に着地している。ボトルネックは生成でもレビューでもなく「生成1分 : レビュー数十分」という非対称性であり、効く対策は「速く回す」ではなく「レビュー総量を減らす」方向にある。

1. 全体像 — 4つの分身術を座標で捉える¶

Claude Code の並行作業は「本流（いま自分がいる会話）をどう扱うか」で整理できる。

                    コンテキストを引き継ぐ
                            ▲
                            │
        /btw                │        /branch      /fork
   （全部見える・            │   （全部引き継ぐ・   （全部引き継ぐ・
     ツール無し・            │     ツール有り・      ツール有り・
     履歴に残らない）        │     自分が移る）     別働隊が背後で走る）
                            │
   ツール無し ◀─────────────┼─────────────▶ ツール有り
                            │
                            │        サブエージェント
                            │      （空のコンテキストから
                            │        始まる・ツール有り）
                            ▼
                    コンテキストは空

早見表（これだけ覚えればよい）¶

機能	コンテキスト	ツール	誰が動くか	本流はどうなるか
`/branch [name]`	全部引き継ぐ	あり	自分が分岐先へ移動	保存される。`/resume` で戻れる
`/fork <directive>`	全部引き継ぐ	あり	別働隊がバックグラウンド	止まらない。結果だけ返ってくる
`/btw <question>`	全部見える	なし	誰も動かない（オーバーレイ）	履歴に一切残らない
サブエージェント	空	あり	別働隊	止まらない

公式の言い回し（重要）: 「/btw is the inverse of a subagent: it sees your full conversation but has no tools, while a subagent has full tools but starts with an empty context. Use /btw to ask about what Claude already knows from this session; use a subagent to go find out something new.」 — 訳すと「このセッションで Claude がもう知っていることを聞くなら /btw、新しく調べに行かせるならサブエージェント」。この使い分けが芯である。

⚠️ 名前に騙されるな — git の語感と逆¶

git での語感 Claude Code の実際

fork 独立して戻ってこない ❌ 逆。親の会話に結果を返してくる

branch 後で merge して戻す ❌ 逆。戻る経路が無い（merge-back 無し）

覚え方は「/fork は帰ってくる、/branch は帰ってこない」。詳細は §8。

2. `/branch` — 自分が分岐先へ移る¶

項目	内容
構文	`/branch [name]`（名前は任意）
動作	現時点の会話を分岐させ、自分がその分岐先へ切り替わる。元の会話は保存される
戻り方	`/resume`、またはセッションピッカーで選択
表示	実行時に2つのセッション ID（新ブランチと元セッション）が出る
注意	分岐時に「このセッション用に承認」した権限は新ブランチに引き継がれない

使いどころ: 本流を汚さずに別方向を試したいとき。git のブランチと同じ発想で、「失敗しても元に戻れる」ことが担保される。

落とし穴: 権限が引き継がれないので、承認済みのはずのコマンドで再度プロンプトが出る。これは仕様である。

3. `/fork` — 別働隊をバックグラウンドで走らせる¶

項目	内容
構文	`/fork <directive>`
動作	会話全体を引き継いだサブエージェントをバックグラウンドで生成し、directive の作業をさせる。自分は本流の作業を続けられる
結果	終わると結果だけが会話に返ってくる
バージョン	v2.1.161 以降。それ以前は `/fork` は `/branch` の単なるエイリアスだった

/branch との違いは「誰が移動するか」の一点。

/branch : 自分 ──────▶ 分岐先へ移動（本流は置いてくる）
/fork   : 自分 ───────────────────▶ 本流を続行
              └─ 別働隊 ──▶ 背後で作業 ──▶ 結果だけ戻る

使いどころ（公式の指針）: 「named subagent では背景説明が多すぎて役に立たないとき」「同じ開始点から複数アプローチを並行して試したいとき」。AI の待ち時間を潰すのが目的である。

公式の例 — 実装を続けながらテストを書かせる:

/fork draft unit tests for the parser changes so far

バージョン注意: 手元は v2.1.210（2026-07-16 時点）なので /fork と /branch は別物として機能する。古いバージョンの記事を読むと「/fork = /branch」と書かれている場合があるが、それは v2.1.161 未満の話である（v2.1.117〜2.1.160 は CLAUDE_CODE_FORK_SUBAGENT=1 が必要）。

走行中の fork は「見る」だけでなく「操縦」できる（重要）¶

fork はプロンプト下のパネルに行として現れる（1行目がメインセッション、以降が各 fork）。ここが「使い方が分からない」の急所である。

キー	動作
`↑` / `↓`	行を移動
`Enter`	選択した fork のトランスクリプトを開き、フォローアップメッセージを送れる
`x`	終わった fork を片付ける / 走行中の fork を止める
`Esc`	プロンプト入力へフォーカスを戻す

fork のトランスクリプトを開いている間、フォローアップメッセージとスキルはその fork に届くが、組み込みコマンドはメイン会話で走る（v2.1.199 以降は /model や /fast を打つと「これはメイン会話の設定を変える」という注意が出る）。

コスト構造 — fork は「fresh subagent より安い」が「安い」ではない¶

公式いわく、fork は system prompt とツール定義が親と同一なので、最初のリクエストが親の prompt cache を再利用する。よって「同じコンテキストを必要とするタスクでは、fresh subagent を spawn するより fork の方が安い」。

実測の裏付け（buildthisnow.com の分析・信頼度中〜高）:

項目	実測値
共有プレフィックス	~48,500 tokens
fork 1体目	~48,700 tokens
fork 2体目以降	~5,050 tokens のみ（cache hit）
5体構成の総計	素朴に計算すると ~243,500 → 実際は ~48,700 + ~20,200 に圧縮
cache read の単価	input の 0.1 倍

自分の実測（2026-07-17）: 長い会話（本ノートの調査セッション）から /fork を撃ったところ、182,874 tokens を消費した。「1体目は会話全体のサイズをそのまま食う」ということである。長い会話ほど fork の初弾は重い。逆に言えば、同じ会話から複数体投げるなら2体目以降は激安になる。

制約¶

fork はさらに fork を spawn できない（ネストは1段まで）
fork モードを明示制御するなら CLAUDE_CODE_FORK_SUBAGENT を 1（有効）/ 0（無効）に。headless（claude -p）や SDK でも効く
fork モードを有効にすると、fork だけでなく全てのサブエージェント spawn がバックグラウンド実行になる（同期に戻すなら CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1）
Claude 自身に fork を spawn させるのはexperimental（公式に「将来変わりうる」と明記）
Claude が Agent tool 経由で fork を spawn するとき、isolation: "worktree" を渡せばファイル編集を別 worktree に隔離できる
VS Code 拡張には /fork が無い（Issue #46451 は Not planned でクローズ）。拡張ユーザーは「コンテキストを捨てて新チャット」か「ターミナルに戻る」の二択

4. `/btw` — 履歴を汚さない脇道質問¶

項目	内容
構文	`/btw <question>`
動作	現在の作業についてさっと質問する。会話履歴には一切追加されない（ephemeral な overlay に出るだけ）
コンテキスト	現在の会話への完全な可視性がある。Claude が既に読んだコードや、さっき下した判断について聞ける
ツール	使えない。「answer only from what is already in context」— ファイル読み・コマンド実行・検索はできない
実行中でも可	Claude が処理中でも実行できる。脇道質問は独立して走り、本流のターンを中断しない
1往復のみ	フォローアップ不可。続けたいときは `f` で新セッションに fork する
コスト	親会話の prompt cache を再利用するので追加コストは最小

オーバーレイのキー操作¶

キー	動作
`Space` / `Enter` / `Escape`	閉じてプロンプトに戻る
`Up` / `Down`	回答をスクロール
`Left` / `Right`	同一セッションの過去の `/btw` 回答を行き来（v2.1.187 以降）
`c`	回答を raw Markdown でクリップボードへコピー（マウス選択だと折り返し済みの表示がコピーされてしまうので、こちらを使う）
`f`	新セッションへ fork。親会話＋この Q&A を実トランスクリプトとして引き継ぐので、ツール付きで続行できる。元セッションは `/resume` に保存される
`x`	上部に並ぶ過去の `/btw` 履歴をクリア

使いどころ: 長い作業を回している最中に「あの設定ファイル名なんだっけ」「さっきの CSS 仕様どうなってた」を、本流を止めずコンテキストも汚さずに聞く。

開発者本人の説明¶

Claude Code リードの Boris Cherny による要約（Threads 2026-03-29）:

"A slash command for side-chain conversations while Claude is actively working. Single-turn, no tool calls, but has full context of the conversation."

内部実装（リバースエンジニアリング・変わりうる）¶

独立した2名（sorrycc 2026-03-12 / ZhangHanDong 2026-03-13）が静的解析とワイヤキャプチャで検証し、内容が相互に整合している。

項目	実装
機能フラグ	`tengu_marble_whisper2`
ターン数	`maxTurns: 1`（公式の「Single response」の実体）
キャッシュ	`skipCacheWrite: true` — 親の cache を汚さない設計。「コストが最小」の理屈がここにある
ツール禁止の実装	システムプロンプトに "You have NO tools available - you cannot read files, run commands, search, or take any actions" と明示。さらにツール定義9個はワイヤ上には送信されるが、クライアント側の `canUseTool` コールバックが `deny` を返して遮断している（API レベルの制限ではない）

※ 内部実装なのでバージョンで変わりうる。ただし「なぜツールが使えないか」「なぜキャッシュを汚さないか」は公式ドキュメントに書かれておらず、ここでしか確認できない。

余談 — `/btw` は公式ドキュメント公開の2ヶ月前から仕込まれていた¶

Issue #14804（2025-12-20）で、ユーザー Taywee が strings でバイナリを解析し「ヒント文言は v2.0.73 で出現しているのに機能が動かない」（v2.0.67 では未出現）と報告。これに Boris Cherny 本人が返信している（2026-01-06）:

"A thing that we're experimenting with, more to come. Removing it from hints for now, sorry for the noise."

同 Issue でユーザー zsxkib が「aww i was so excited about branching chats!」とコメントしており、当時は /btw を会話分岐機能だと誤解されていたことが分かる（実際は無関係）。この「名前から機能を誤解する」問題は、次節の /fork と /branch の意味論の話につながる。

5. `.worktreeinclude` — worktree に `.env` を連れて行く¶

解く課題: worktree は git の fresh checkout なので、gitignore されている .env などは存在しない。毎回手でコピーするのが面倒、という問題である。

項目	内容
ファイル名	`.worktreeinclude`
置き場所	プロジェクトルート（`.git` と同じ階層）
書式	`.gitignore` 構文（パターンマッチ）
対象	gitignored なファイルのみ。git 追跡済みファイルは複製されない
コピーのタイミング	worktree 作成時（`--worktree` / subagent worktree / Desktop の並列セッション）
記述例	`.env` / `.env.local` / `config/secrets.json`

重要な性質: 追跡済みファイル（例 package.json）を .worktreeinclude に書いても複製されない。git の fresh checkout で最初から入るからである。「git が運んでくれないものだけを運ぶ」のが役割で、この線引きが安全性を担保している。

実ファイル例（centminmod/my-claude-code-setup）: .env / .env.local / .env.* / **/.claude/settings.local.json。

⚠️ 罠 — `WorktreeCreate` hook を置くと `.worktreeinclude` が黙って死ぬ¶

公式に明記されている:

Because the hook replaces the default git behavior, .worktreeinclude is not processed when you use --worktree. Copy any local configuration files inside your hook script instead.

これは非 git VCS（SVN / Perforce / Mercurial）専用の話ではない。公式は「worktree の置き場所を変えたいなら WorktreeCreate hook を設定せよ」「worktree 作成を細かく制御したいなら WorktreeCreate hook を設定せよ（デフォルトの git worktree ロジックを完全に置換する）」とも書いている。つまり:

「置き場所を変えたいだけ」で hook を置くと、副作用で .worktreeinclude が処理されなくなり、.env が worktree に来なくなる。 hook スクリプトの中で自分でコピーする必要がある。

公式 worktree 運用の要点（`.worktreeinclude` の前提）¶

項目	内容
起動	`claude --worktree <name>`（`-w`）。名前を省くと `bright-running-fox` のような名前が自動生成される
既定の置き場所	リポジトリルートの `.claude/worktrees/<name>/`、ブランチ名は `worktree-<name>`
公式 Tip	`.claude/worktrees/` を `.gitignore` に追加せよ（worktree の中身がメインの checkout で untracked として現れるのを防ぐ）
分岐元	`origin/HEAD`（デフォルトブランチ）から切る。24時間 fetch されていなければ5秒上限で fetch する。ローカル `HEAD` から切りたいなら設定で `worktree.baseRef: "head"`
PR から切る	`claude --worktree "#1234"` で `pull/<number>/head` を fetch して `.claude/worktrees/pr-<number>` に作る
サブエージェント隔離	frontmatter に `isolation: worktree`、または「use worktrees for your agents」と頼む。変更が無ければ終了時に自動削除
headless の落とし穴	`-p` と併用した `--worktree` は自動クリーンアップされない（終了プロンプトが無いため）。`git worktree remove` で手動削除が要る
定期掃除	`cleanupPeriodDays` を過ぎたサブエージェント / バックグラウンドセッションの worktree を掃除する（未コミット変更・untracked・未push コミットが無いものだけ）。`--worktree` で自分が作ったものは掃除しない
権限の共有	v2.1.211 以降、worktree で「Yes, don't ask again」した承認はメイン checkout の `.claude/settings.local.json` に保存され、他の worktree にも効き、worktree 削除後も残る。それ以前は worktree 内に保存され、削除で消えていた

自分の運用への含意: cron / headless（claude -p）で worktree を使うなら、掃除は自分で書く必要がある。issue-work ループのように worktree を切る運用では、放置すると .claude/worktrees/ が溜まり続ける。

6. remote control と `pmset` — スライドの記述には注意が要る¶

remote control（公式に存在する）¶

項目	内容
概要	ローカルマシンで走る Claude Code セッションを、スマホ / タブレット / ブラウザからリモート操作する
実行場所	あくまでローカル（MCP・tools・ファイルシステムはローカルのまま）
起動	`claude remote-control` / `claude --remote-control` / `/remote-control`
接続	QR コード、`claude.ai/code`、Claude モバイルアプリ
前提条件（公式）	① Pro / Max / Team / Enterprise プラン（API キー不可）② claude.ai の OAuth ログイン ③ ワークスペース信頼ダイアログの受け入れ
ネットワーク断	自動再接続（最大 ~10 分。超えると終了）
非サポート	Amazon Bedrock / Google Vertex AI / Microsoft Foundry。`ANTHROPIC_BASE_URL` が `api.anthropic.com` 以外だと無効（v2.1.196+）

⚠️ 「`pmset` は remote control の前提条件」は公式には書かれていない¶

スライド（および元メモ）は sudo pmset -a disablesleep 1 を「remote control を使うための前提条件」として紹介している。しかし公式ドキュメントの前提条件リストに pmset の記載はない（上表の①〜③のみ）。

正確には「前提条件ではなく、実務上の工夫」と捉えるべきである。理屈は単純で、セッションはローカルマシンで走り続けるのだから、Mac が寝てしまえば当然止まる。フタを閉じて持ち歩きたいなら、スリープを止める必要がある、という運用上の話である。

スリープ抑止の2択（自分の環境向けメモ）¶

手段	仕組み	sudo	元に戻す	フタを閉じたとき
`sudo pmset -a disablesleep 1`	カーネルの `SleepDisabled` フラグ。`IOPMrootDomain` がスリープの拒否権として解釈し、lid-close イベントを貫通する	必要	`0` に戻す or 再起動	✅ 寝ない
`caffeinate -dimsu`（自分の `mac-stay-awake` スキル）	power assertion（一時的な抑止プロセスを足すだけ）	不要	プロセスを kill すれば確実に原状復帰	❌ 効かない

両者はレイヤーが違う。caffeinate は power assertion なので「アイドルで寝る」は止められるが、フタを閉じる操作には勝てない。一方 pmset -a disablesleep 1 はカーネルレベルのフラグなので lid-close を貫通する。「フタを閉じても動かす」には後者が要る、というのが結論である（2026-07-16 裏取り済み）。

⚠️ `pmset -a disablesleep 1` の副作用¶

閉じたフタの下で内蔵ディスプレイが全輝度のまま点灯し続け、バッテリーを焼く場合がある
明示的にクリアするか再起動するまで持続する。放置すると夜間も飛行機の中でも一切寝なくなる

自分の環境での結論¶

マシン	フタ	必要な対処
Mac mini（`Mac16,10`）	無い	この問題が原理的に存在しない。caffeinate（`mac-stay-awake`）だけで十分
MacBook Air	ある	閉じて持ち歩くなら `sudo pmset -a disablesleep 1` が必要（`sudo` は deny 設定なのでターミナルで手打ち）＋上記の副作用を許容する

運用としては「常時起動の mini をリモート先のホストにして、スマホから remote control する」のが素直である。Air のフタを閉じて持ち歩く構成より、フタ問題を回避でき電池も焼かない。cf. mac2台同期_chezmoi_dotfiles設計_設計書

7. スライドで紹介された他の道具¶

道具	位置づけ
cmux	GPU 駆動ターミナル。並列エージェント運用の可視化（→ cmux_並列aiエージェント用ターミナル_整理）
サブエージェント	個別作業の並列化
git worktree	同一リポジトリで複数機能を同時開発（例: 検索機能とお気に入り機能）
`/autofix-pr`	PR 自動修正（※スライドの言及のみ。公式ドキュメントでの裏取りは未実施）

発表者の思想: 「AI の待ち時間を活用し、複数タスクを監督することで開発速度を上げる」。また「複数クローン方式 → worktree へ移行」「専用管理ツールはネイティブターミナルに敗北」という変遷も語られている。

元メモに残された総括が芯を突いている:

最新のチェンジログ情報だけ見て喜ぶんじゃなくて、こういう基本的なものを実践で使っていかないといけないよね

8. 英語圏の実践知 — ブログではなく GitHub Issue に一次情報がある¶

前提: この領域は「ブログを読めば分かる」が成立しない¶

2026-07 時点で英語圏を調査した結論から書く。/fork・/btw・/branch を主題にした質の高いブログはほとんど存在しない。

検索上位を占める記事群（wmedia.es / claudcod.com / techtimes.com / asksurf.ai / claudekit.app / howdoiuseai.com / Medium の複数記事等）は、ほぼ同一のフレーズを使い回す AI 生成コンテンツファームだった。個別に取得して確認したところ、多くが「Claude Code is mid-task refactoring auth middleware...」のような架空のシナリオ例で、実体験の裏取りができない
Simon Willison は Claude Code を頻繁に扱っているが、この3機能を主題にした記事は無い
Anthropic 公式エンジニアリングブログにも該当記事は無い
Hacker News にも3機能単体の専用スレッドは無い

理由は明快で、/fork・/btw は 2026年3月前後に入ったばかりの新機能だからである。実践記事が蓄積するだけの時間が経っていない。

代わりに、遥かに質の高い一次情報が GitHub Issue にあった — 実ユーザーの生の報告と、Anthropic 社員（Boris Cherny = Claude Code リード）の直接返信である。以下はそこからの収穫。

最大の落とし穴 — `/fork` と `/branch` は名前の直感と逆¶

Issue #69712（cameronsjo, 2026-06-20・コメント0件＝現状未対応）が、公式ドキュメントを読んだだけでは気づきにくい設計上の罠を突いている:

"the three fork primitives use 'fork'/'branch' in confusingly opposite ways. /fork <directive> spawns a background subagent that returns its result into the parent conversation... while /branch and claude --continue --fork-session are clean, independent forks that never talk back."

git の語感で捉えると間違える、というのが芯である。

	git での語感	Claude Code の実際
fork	独立した別物になる。戻ってこない	❌ 逆。親の会話に結果を返してくる
branch	後で merge して戻す	❌ 逆。戻る経路が無い（never talk back）

覚え方は「/fork は帰ってくる、/branch は帰ってこない」。

`/branch` の実運用上の不満（同 Issue より）¶

merge-back が無い

"There's no merge-back. Once you branch to explore an alternative direction, there's no way to fold the branch's conclusions/work back into the original... a manual export-and-reread or git-commit chore."

分岐先で得た結論を本流に戻す公式の道が無く、手で export して読み直すか、git commit を経由するしかない。「試して良ければ取り込む」を期待すると裏切られる。

/branch は agent view に現れない

"A /branch never appears in the agent view... interactive sessions don't show up in claude agents until they're separately backgrounded."

並列運用を claude agents で俯瞰する運用だと、branch だけが見えない。別途バックグラウンド化（/bg 等）が要る。

セッションを fork する2つの道（Boris Cherny 本人）¶

"People often ask how to fork an existing session. Two ways: 1. Run /branch from your session 2. From the CLI, run claude --resume <session-id> --fork-session"

つまりセッションを複製したいなら /branch か --fork-session。/fork は「複製」ではなく「別働隊への委譲」で、目的が違う。

9. 並行開発の実践知 — 上限を決めるのは技術ではなく人間¶

/fork 等の単体機能と違い、並行開発の運用については英語圏に厚い実践知がある。以下は実務者の一人称記述に限定して集めたもの（量産ブログは除外）。

9-1. 実数は「能動管理 3〜4」に収斂する¶

立場も文脈も違う実務者が、独立に同じ数字に着地しているのが最大の発見である。

実務者	数値	出典
Addy Osmani	"My ceiling for a typical session is somewhere around three to four threads"	Your parallel Agent limit（2026-04-07）
Kilo の7エンジニア	「20並列」の実態はフォアグラウンドで能動管理 2〜4体、残りは PR 待ちの背景タスク	Kilo Blog（2026-05-26）
Daniel Williams（25年超の経験）	2〜3プロジェクト・数時間後に自分の判断が信頼できなくなる。1日4〜5時間に自主上限	Your Agents Can Run Parallel. You Can't.（2026-04-09）
incident.io	同時 4〜5エージェント（時に7会話）	Shipping faster with Claude Code and Git Worktrees（2025-06-27）

⚠️ 注意: 巷でよく見る「並列3〜5が限界」という数値は、出典を辿ると量産ブログの同一文言の使い回しで一次的な裏付けが取れなかった。上の数字は独立した実務者の一人称記述のみを採用している。結論が近いのは偶然ではなく、認知の上限という同じ壁に各自がぶつかっているからと解釈すべきである。

Osmani による認知負荷の内訳が具体的で有用:

コンテキスト切替のたびの再ロード
キューイングできない判断割込み（エージェントが待っている）
スレッドごとの信頼度の較正（このエージェントはどこまで信じられるか）
背景監視の慢性的な不安

そして結論:

「6スレッドを半分監督するより、3スレッドを丁寧にレビューする方が成果物が多い」

9-2. 芯 — ボトルネックは「生成とレビューの非対称性」¶

Flask 作者 Armin Ronacher の指摘が本質を突いている（Agent Psychosis 2026-01-18）:

生成は1分、待機は数分、まっとうなレビューはその何倍 — この非対称性を「完全に残酷（completely brutal）」と表現

生成:    ▌ 1分
待機:    ▌▌▌ 数分
レビュー: ▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌ その何倍
          ↑ ここだけ並列化できない（人間が1人だから）

並列度を上げるほどレビュー債務が線形に積み上がる。Uber の実務者の証言がこれを裏付ける（HN、月 $3,000 消費・3〜6エージェント並列）:

「開発サイクルは劇的に速くなったが、自分自身がボトルネックになった」

したがって効く対策は「速く回す」ではなく「レビュー総量を減らす」方向になる:

対策	出典
1回のレビューで確認しきれる大きさにタスクを限定する	Kilo
Plan Mode で人間が事前確認してから走らせる（衝突回避の要）	incident.io
別エージェントにレビューさせる（Boris Cherny「品質2〜3倍改善」）	Kilo
6を半分見るより3を丁寧に	Osmani

Ronacher は夜中3時に10並列で「生産性が最高」と言う人々について、こう書いている:

「生産性ではなく、一歩引くべき人間を見ている」

9-3. 隔離はコードだけでは足りない — 真の競合点は DB・ポート・プロセス¶

worktree はファイルを隔離するが、実際の障害はその外側で起きる。

競合点	実例
ポート	ブランチ名の MD5 でポートを決定論的に割当。57000番以降は Spotify と競合して EOF エラー（barnacle.ai 2026-02-07）
DB	「migrations from feature-A break feature-B」が実際に発生。worktree 削除後も DB が残存（同上 / Damian Galarza）
RAM	Supabase スタック1つで 500MB〜1GB → 実用上限は 2〜3スタック（barnacle.ai）
テスト	2エージェントが同時にテスト実行して DB 競合（Damian Galarza が回避スクリプトを全掲載）
git 履歴	`.claude/worktrees/` の gitignore 忘れで履歴汚染（Damian Galarza）

.worktreeinclude は .env 問題を公式に解決したが、DB / ポート隔離は依然として自作スクリプトの領域である。

💡 自分に刺さる点: 「.claude/worktrees/ の gitignore 忘れで履歴汚染」は、claude-config リポで踏んだ #38（teams/ 追跡でマシン間衝突）・#41（auto-sync がブランチに無関係ファイルを巻き込む）と完全に同じ型の事故である。「実行時生成物を追跡してしまう」という一般的な罠。公式も Tip として .claude/worktrees/ の gitignore を明記している。

9-4. 計画への投資が並列度の前提条件¶

Kilo のエンジニア全員が「遅い思考モデルで計画 → 速いモデルで実装」に収斂し、「良い計画さえあればほぼ一発で実装が通る」と証言している。incident.io も Plan Mode を衝突回避の要にしている。

計画が曖昧なまま並列度を上げると、レビュー債務が爆発する。cf. rules/common/requirements-first.md

関連する観測値: Igor（Kilo）「コンテキスト 60% 充填で品質劣化が始まる」／ Osmani「単体エージェントは複雑タスクの 60% 程度で進行が止まる」。

9-5. 測るものを間違えると自壊する¶

独立した3ソースが同じことを言っている:

ebiester（HN）: 「トークン使用量そのものを生産性指標にする組織文化が根本問題」
Osmani: 「活動量と価値は相関しない」
Ronacher: 「生産性ではなく、一歩引くべき人間を見ている」

並列度もトークン消費もコストであって成果ではない。 参考値として Uber の実態は「平均 $150〜250/月、ヘビーユーザー $500〜2,000/月、CTO の2時間セッションで $1,200」「並列実行で 5〜20倍のトークン消費増」（Forbes 2026-05-17）。

cf. Fable5_3日間で300万円課金_並列エージェント運用の物理的課題

9-6. 並列運用は「見失う」という新しい失敗モードを生む¶

Simon Willison は並列運用に懐疑的で、worktree を採用していない（/tmp への都度フレッシュチェックアウトを使う）。用途を「PoC / コード理解 / 低リスク保守 / スペック駆動」に4分類してリスク別に使い分けている（Embracing the parallel coding agent lifestyle 2025-10-05）。

その彼が前日に作った機能を完全に見失った（2026-02-19）。/tmp のプロトタイプがクラッシュで消え、branch にも worktree にも cloud にも無く、~/.claude/projects/ のセッションログから復元したという顛末である。

逐次開発には存在しなかった失敗モードなので、並列度を上げるなら成果物の所在管理を先に決めておく必要がある。

10. まとめ — 状況 → 使うもの¶

状況	使うもの	理由
本流を汚さず別方向を試したい。自分がそっちに集中する	`/branch`	自分が移り、本流は `/resume` で戻れる
本流を止めたくない。裏で作業させて結果だけ欲しい	`/fork`	別働隊がコンテキストごと引き継いで背後で走る
作業中に「あれ何だっけ」を聞きたい。履歴は汚したくない	`/btw`	全コンテキストが見える・履歴に残らない・処理中でも撃てる
新しいことを調べに行かせたい	サブエージェント	ツール有り。ただし空のコンテキストから始まる
worktree に `.env` を連れて行きたい	`.worktreeinclude`	gitignored なものだけコピー。追跡済みは対象外
外出先のスマホから指示したい	remote control ＋スリープ抑止	セッションはローカルで走るので Mac を起こしておく必要がある
分岐先の結論を本流に取り込みたい	公式の道は無い	`/branch` に merge-back は無い。手で export するか git 経由
並列度を上げたい	まず計画に投資する	計画が曖昧なまま並列度を上げるとレビュー債務が爆発する

機能選択の芯: 迷ったら「コンテキストは要るか」「ツールは要るか」「自分が移るか、任せるか」の3問に答えれば、機能は一意に決まる。

運用の芯: 並列度の上限は人間側で決まる（能動管理3〜4）。並列度を上げることではなく、レビュー総量を減らすこと（タスクを1回で見切れる大きさに / 事前に Plan Mode / 別エージェントにレビューさせる）が効く。トークン消費も並列度もコストであって成果ではない。

参考リンク¶

出典（きっかけ）¶

スライド: 【Claude Code】鹿野さんに聞く私の推しの並行開発環境大公開（鹿野壮 / Ubie Staff Product Engineer / @tonkotsuboy_com）
イベント: 【Claude Code】並行開発、どう回してる？（2026-07-15 12:00-13:00 / 主催 Offers / モデレーター大西政徳）
元メモ: yamamoto_obsidian Issue #19

公式ドキュメント¶

コマンド一覧 — /branch /fork /btw の構文
セッションと分岐 — /branch の詳細・権限を引き継がない旨
interactive mode — /btw の side questions・ツール不可・キー操作
sub-agents — /fork の詳細・fork パネルの操作・fork と named subagent の比較表・制約
worktrees — .worktreeinclude の仕様・WorktreeCreate hook との相互作用・クリーンアップ規則
remote control — 前提条件・非サポート環境

一次情報（GitHub Issue・開発者本人）¶

Issue #69712 — /fork と /branch の意味論が逆・merge-back が無い・agent view に出ない（2026-06-20・未対応）
Issue #14804 — /btw のヒントが機能より先に出荷されていた件。Boris Cherny 本人が返信（2025-12-20 提起 / 2026-06-13 クローズ）
Issue #46451 — VS Code 拡張に /fork が無い（Not planned でクローズ）
Boris Cherny の Threads 投稿（2026-03-29） — セッションを fork する2つの道・/btw の要約
howborisusesclaudecode.com — Boris Cherny の Tips 収集ファンサイト（運営者不明・引用元は明記）

`/btw` 内部実装のリバースエンジニアリング（独立2件・相互に整合）¶

sorrycc の Gist（2026-03-12）
ZhangHanDong の Gist（2026-03-13）

並行開発の実践知（実務者の一人称記述）¶

Addy Osmani: Your parallel Agent limit（2026-04-07） — 3〜4スレッドが上限・認知負荷の内訳
Armin Ronacher: Agent Psychosis（2026-01-18） — 生成とレビューの非対称性（Flask 作者）
incident.io: Shipping faster with Claude Code and Git Worktrees（2025-06-27） — 4〜5エージェント・$8で18%高速化・Plan Mode で衝突回避
barnacle.ai: Isolated Worktree Databases（2026-02-07） — ポート衝突・DB 競合・RAM 上限の実測
Damian Galarza: Extending Claude Code Worktrees for DB Isolation（2026-03-10） — 隔離スクリプト全掲載・gitignore 忘れの罠
Simon Willison: Embracing the parallel coding agent lifestyle（2025-10-05） — worktree を使わない立場・用途4分類
Simon Willison: Recovering lost code（2026-02-19） — 並列運用で成果物を見失った顛末
Kilo Blog: 7 Engineers Run Up to 20 Parallel Agents（2026-05-26） — 「20並列」の実態・コンテキスト60%で品質劣化
HN: Uber torches 2026 AI budget on Claude Code — 月$3,000・「自分自身がボトルネックになった」
Forbes: Uber burns its 2026 AI budget in four months（2026-05-17） — コスト実態
buildthisnow.com: Fork Subagents in Claude Code（2026-04-22） — fork のトークン圧縮の実測（信頼度中〜高・著者の素性不明）
Daniel Williams: Your Agents Can Run Parallel. You Can't.（2026-04-09） — 認知負荷はベテランほど深刻という逆説

調査上の限界（2026-07-17 時点）: ① Hacker News の複数スレッドは WebFetch が 429 で取得できず、コメント内の実体験は未確認 ② .worktreeinclude の失敗談・ポストモーテムは発見できず（仕様・機能要求・ツール紹介のみ） ③ ossama.is / mejba.me は 403 で検証不能 ④ 「並列3〜5が限界」という広く流通する数値は、出典を辿ると量産ブログの同一文言の使い回しで一次的裏付けが取れなかったため不採用

作成: 2026-07-16 ／最終更新: 2026-07-17

	git での語感	Claude Code の実際
fork	独立して戻ってこない	❌ 逆。親の会話に結果を返してくる
branch	後で merge して戻す	❌ 逆。戻る経路が無い（merge-back 無し）

Claude Code の並行開発 — /branch /fork /btw と .worktreeinclude¶