Claude Codeの/branchコマンドで会話を分岐する使い方
/branchは現在の会話をその時点で分岐し、別の方向性を試せるコマンドです。gitのブランチとは無関係で、/fork・/subtaskとは役割が違います。
Claude Codeの/branchコマンドとは
/branch [name]は、現在の会話をその時点で分岐し、それまでの流れを失わずに別の方向性を試せるコマンドです。実行すると分岐した会話に切り替わり、元の会話はそのまま保存されて/resumeで戻れます。
名前からgit branchを連想しますが、gitのブランチ操作とは無関係です。/branchが分岐させるのはClaude Codeとの会話そのもので、ファイルシステム上のgitブランチを新規作成するコマンドではありません。「実装方針Aで進めた会話」と「方針Bを試した会話」を両方残しておきたいときに使う、会話版のスナップショット分岐と考えると実態に近くなります。
似た響きのコマンド名がClaude Codeの世界とgitの世界の両方に存在するのは珍しくありません。コマンド名だけで判断せず、「今操作しようとしているのはClaude Codeとの会話なのか、gitのリポジトリなのか」を一度切り分けて考えるのが確実です。
やり方 — 分岐して、必要なら/resumeで元に戻る
/branch try-vitest名前を渡すと、その名前がついた新しい会話に切り替わります。名前を省略すると、会話の最初の実プロンプトから自動で名前が付きます。会話が長くなって一度圧縮(compact)されたあとでも、圧縮後の要約ではなく最初のプロンプトから名前が作られる仕様です。分岐が作られると、新しい会話のセッションIDが表示されるので、あとで/resume <id>を指定して直接開き直せます。
元の会話に戻りたくなったら、/resumeでセッション一覧を開いて選び直します。分岐前の会話は消えているわけではなく、/branchを実行した時点の状態のまま止まっているだけです。名前を付け忘れた、あるいは後で分かりやすい名前に変えたいときは、/rename [name]でいつでも付け直せます。これは/branch専用の機能ではなく、どのセッションにも使える汎用コマンドです。
/branch・/fork・/subtaskの使い分け早見表
似た名前のコマンドが3つあり、どれも「今の会話を複製して何かする」という点は共通していますが、作業がどこで続くかがそれぞれ違います。
| コマンド | 何をするか | 作業の続き先 | 元の会話 |
|---|---|---|---|
/branch [name] | 何をするか現在の会話をこの時点で分岐する | 作業の続き先分岐した会話にあなた自身が切り替わる | 元の会話そのまま保存、/resumeで戻れる |
/fork [prompt] | 何をするか会話をコピーして新しいバックグラウンドセッションを作る | 作業の続き先コピーがバックグラウンドで動き、あなたは元の会話に残る | 元の会話変更なく続く |
/subtask <task> | 何をするか会話全体を引き継いだサブエージェントを起動する | 作業の続き先サブエージェントが作業し、結果はこの会話に戻ってくる | 元の会話完了を待たず並行して使い続けられる |
自分がその場を離れて別方向を試したいなら/branch、元の会話にいながら別コピーを裏で走らせたいなら/fork、side taskを任せて結果だけ受け取りたいなら/subtaskという切り分けです。3つとも「今の会話をもとに何かを始める」という入り口は同じでも、あなた自身がどこにいるか、結果がどこに返ってくるかがそれぞれ違います。なお、agent viewをオフにしている場合は/forkが従来のフォークされたサブエージェント挙動のままとなり、/subtaskは使えません。/subtaskが起動するのは会話全体を引き継いだ特殊なサブエージェントで、一般的なサブエージェントの委譲パターンはSub-agents完全ガイドで扱っています。
なぜ紛らわしいのか — 改称と再定義の経緯
/branchという名前自体は、v2.1.77で/forkから改称されたものです(/forkはエイリアスとして残されました)。ここまではシンプルですが、その後/forkの方だけが別の意味に変わりました。
v2.1.212で/forkは「会話をバックグラウンドセッションへコピーする」という現在の意味に再定義され、それまで/fork(および当時のエイリアス経由)が担っていた「会話を引き継いだサブエージェントを起動する」という挙動は/subtaskという新しいコマンドに引き継がれました。つまり同じ/forkという文字列が、時期によって指す動作が変わっています。/branchだけはこの改称以降ずっと「会話を分岐して切り替える」という意味を保っているので、迷ったら/branchは名前どおりの動作をすると考えて差し支えありません。
補足 — worktreeによるファイル隔離はされない
/forkのコピーには、編集を始める前に自分専用のgit worktreeを作成する指示が明記されています。一方/branchの定義には、worktreeへの言及がありません。会話は分岐しても、作業ツリー自体は元のまま続く可能性が高いという点は、複数の方向性を並行してファイル編集まで試したい場面では意識しておく価値があります。
これが実際に問題になるのは、分岐した会話でファイルを編集したあと、/resumeで元の会話に戻ってそちらでも同じファイルを編集してしまうケースです。同じ作業ツリーを共有しているなら、あとから戻ってきたときに片方の変更が残っていて驚く可能性があります。ファイルの競合を避けたいなら、/branchで会話だけ分けるより、/forkでバックグラウンドセッションとして走らせ、worktree隔離の恩恵を受ける方が安全です。会話の分岐だけで十分なとき(まだ実装に入る前の相談段階など)は、/branchの手軽さがそのまま利点になります。
過去の制限は現行バージョンで解消済み
/branchは2.1.77で今の名前になったあとも、細かな修正が積み重なってきました。2.1.116より前は、トランスクリプトが50MBを超える会話を分岐しようとすると失敗する制限がありましたが、これは撤廃されています。2.1.122では、巻き戻し(rewind)を使ったあとの会話を分岐すると内部的な整合性エラーで失敗するケースが直りました。2.1.129より前は、分岐に成功しても新しい会話のセッションIDが表示されず、/resumeで呼び出すには一覧から名前を探すしかありませんでした。さらに2.1.144では、worktreeに入った状態やバックグラウンドセッションの中から/branchを実行すると「No conversation to branch」というエラーで失敗する不具合が修正されています。
これらはいずれも過去のバージョンで既に直っている制限です。以前/branchを試して失敗した経験がある場合は、claude updateで最新版に更新してから改めて試す価値があります。
こんなときに使う
- 実装方針で迷ったとき、片方を
/branchで試し、うまくいかなければ/resumeで分岐前に戻って別の方針を試す - レビュー指摘への対応方針を2通り試したいが、どちらも会話の文脈(それまでのやり取り)を引き継ぎたいとき
- 大きな変更に着手する前に、現在の会話をチェックポイントとして分岐しておき、後から比較したいとき
たとえば、あるAPIのレスポンス形式を変える実装で、後方互換を保つ案と破壊的変更にする案の2通りが浮かんだとします。ここまでの調査結果や制約の議論を引き継いだまま両方を試したいなら、片方を/branchで分岐させ、実装してテストを走らせてみます。結果が思わしくなければ/resumeで分岐前の会話に戻り、同じ文脈のまま別案を試せます。会話を最初からやり直して同じ背景を説明し直す必要がない点が、単に新しいセッションを開くのとの違いです。
いずれの場面でも共通しているのは、「会話の文脈を失いたくないが、この先の判断だけ分けたい」という状況です。ファイルへの実際の変更まで並行して走らせたい場合は、前述のとおり/forkかagent view経由のバックグラウンドセッションの方が向いています。
よくある質問
分岐した会話は元の会話と同じディレクトリで動きますか
はい、基本的には同じ作業ツリーで続きます。前述のとおり/branchの定義にworktree隔離への言及はなく、/forkのコピーのように専用の作業ツリーが自動で用意されるわけではありません。同じチェックアウトの上で会話だけが分かれる、という理解を持っておいてください。ディレクトリを分けて試したい場合は、あらかじめ自分で別のgit worktreeを用意しておく方が確実です。
/branchで分岐した会話は、/resumeの一覧でどう見分けられますか
名前を付けていれば、その名前で一覧に並びます。/resumeのセッション一覧では、バックグラウンドセッションだけにbgというラベルが付きます。/branchは分岐した会話にその場で切り替わる操作なので、あとから/backgroundで切り離さない限りbgラベルは付きません。
何回でも分岐できますか
回数の上限は公式ドキュメントに明記されていません。分岐するたびに新しい会話が1本増えるだけなので、試したい方向性の数だけ/branchを重ねても仕組みとしては成立します。ただし分岐が増えるほど/resumeの一覧も長くなるので、都度/renameで分かりやすい名前を付けておくと後から迷いません。名前を揃えるルールを自分の中で決めておくと、一覧が長くなっても目的の会話をすぐに見つけられます。
分岐した会話をさらに分岐できますか
はい、分岐した会話も普通のClaude Codeの会話なので、その中でもう一度/branchを実行すれば、さらに枝分かれした会話を作れます。ただし枝が増えるほど「どの会話がどの方針を試したものか」を追いにくくなるので、深く枝分かれさせるより、方針が固まった時点で不要な枝を/resumeの一覧から整理する方が扱いやすくなります。1階層だけ分岐して比較し、結論が出たらどちらかを本流として続ける使い方が、実務では扱いやすい落としどころです。
まとめ
/branch [name]は会話をその場で分岐し、あなた自身が新しい会話へ切り替わるコマンドです。gitのブランチ操作とは無関係で、元の会話は/resumeでいつでも戻れます。/forkはコピーをバックグラウンドで動かして元の会話に残るコマンド、/subtaskは結果が元の会話に戻ってくるサブエージェント起動コマンドという違いがあり、v2.1.212の再定義以降この3つの役割分担が定着しました。
判断に迷ったときの基準はシンプルです。あなた自身がその場を離れて別方向を試すなら/branch、元の場所に残りながら別コピーを裏で走らせたいなら/fork、任せた結果だけ受け取りたいなら/subtask。ファイル編集まで並行させたいなら、/branchではなく/forkや前述のagent viewを検討してください。名前が似ているだけで挙動は大きく違うので、迷ったらまず「会話をどこで続けたいか」を基準に選んでください。