同じ作業場に案を2つ3つ重ねると、だいたいどこかでぶつかる。ファイルが上書きされる、差分が汚れる、どの変更がどの案のものか分からなくなる。ここを雑にやると、Claude Code はむしろ便利さより手戻りを増やす。
だから先に作業場所を分ける。複数案を別作業場所で進める、要するに並走作業の整理だ。これだけで衝突の大半は消える。
Claude Code で複数案を同じリポジトリに並べたいとき、まずやるべきなのは「同じ場所で頑張ること」ではない。案ごとに作業ディレクトリを分けることだ。Git の worktree を使うのが一番きれいで、次点で単純に別ディレクトリへ複製するやり方でも足りる。
筆者は最初、ひとつの作業ディレクトリで「案Aを少し直して、戻して、案Bを試す」をやって、diff がぐちゃぐちゃになった。Claude Code 自体が悪いのではなく、作業場の切り分けが甘いだけだった。後から見ても、どの変更がどの案だったか判別しづらい。あれは本当にだるい。
Git を使っているなら、git worktree が本命だ。同じリポジトリを、別のディレクトリとして複数開ける。しかも履歴は共有されるので、複製より軽い。
たとえば案A、案Bを並走させたいならこんな感じだ。
git worktree add ../repo-idea-a main
git worktree add ../repo-idea-b main
この例では、main ブランチをそれぞれ別の作業場所に出している。実際には、どのブランチを切るかは用途次第だ。新しい機能案なら、ベースブランチから枝を切ってそれぞれ作るほうが分かりやすい。
git switch -c idea-a
git worktree add ../repo-idea-a idea-a
git switch -c idea-b main
git worktree add ../repo-idea-b idea-b
こうしておけば、Claude Code をそれぞれのディレクトリで起動し、案ごとに別の指示を投げられる。ひとつの案で大きく書き換えても、もう片方には触れない。これが大きい。
もし Git を使わない、あるいは非エンジニア寄りの作業であれば、フォルダを丸ごとコピーして案A、案Bを分ければいい。たとえば文書作成なら、案件書類_A と 案件書類_B を作り、片方は要約強め、もう片方は説明厚め、という切り分けにする。
ディスクは少し食うが、迷子になるよりずっとマシだ。
作業場所を分けても、指示が曖昧だと混ざる。ここはかなり大事だ。Claude Code には、最初に「この作業ディレクトリは何案目か」をはっきり伝える。
案Aのディレクトリでなら、こんな頼み方が扱いやすい。
このディレクトリでは案Aだけを進めてください。
既存ファイルの構成は維持し、必要な変更は最小限にしてください。
案Bのことは考えず、案Aの差分が追いやすい形で進めてください。
案Bでは、まったく逆の指示を出す。
このディレクトリでは案Bだけを進めてください。
案Aの内容やファイルには触れないでください。
案Bとして独立して読めるように、必要なら別ファイルを追加してください。
ここで重要なのは、「複数案を同時に覚えさせる」のではなく、「この作業場ではこの案だけ」と割り切ることだ。Claude Code は与えたコンテキストの中で動く。案を横断させると、説明が長くなり、肝心の差分がぼやける。
筆者はこれを一度やって、案Aの文体と案Bの文体を同じセッションで行き来させたことがある。結果、修正提案が中間案みたいになって、どっちつかずの文章ができた。並走させたいなら、会話まで混ぜないほうがいい。
同じリポジトリで複数案を並走させるとき、ぶつかりやすいのはコードそのものより、生成物の置き場だ。たとえば以下は危ない。
output.md にそれぞれ書き出すこういうのは、案が違っても最後に残るファイル名が同じなので、簡単に上書き事故になる。
やるなら、最初から案ごとに名前を分ける。
案Aでは output-a.md を使う。
案Bでは output-b.md を使う。
一時ファイルも案ごとに分けてください。
もっと雑にやるなら、案ごとにサブディレクトリを切るのもありだ。
mkdir -p drafts/a drafts/b
非エンジニアの作業でも理屈は同じだ。たとえば契約書の下書きを2案並べるなら、01_相手強め と 02_柔らかめ に分ける。最終版の名前で途中保存しない。これをやらないと、あとで「どっちが最新版だっけ」で止まる。
並走させると、つい片方を「本命」、もう片方を「比較用」にしたくなる。気持ちは分かるが、比較用の案を雑にすると、どこが本質的に違うのか見えなくなる。
だから案ごとに「何を変える案か」を一つだけ決めておくといい。文言、構成、ファイル分割、処理順、見た目。このうち一つだけを軸にする。
たとえば Claude Code にこう言う。
案Aは文章のトーンだけを変える。
事実関係、見出し構成、文字数は極力維持する。
案Bは構成だけを変える。
内容の核は保ちつつ、順番と見出しを組み替える。
こうすると、後で見比べたときに「何が違うのか」が一目で分かる。逆に、あれもこれも変えると、案の比較ではなく別作品の比較になる。これでは並走の意味が薄い。
ここを混同すると、だいたい面倒になる。ブランチは変更の履歴を分ける道具で、作業場所は同時に触る場所を分ける道具だ。
複数案を本気で並べるなら、案ごとにブランチを作り、そのブランチを worktree で別ディレクトリに出す。これがいちばん素直だ。
git switch -c draft-a
git worktree add ../draft-a draft-a
git switch -c draft-b main
git worktree add ../draft-b draft-b
この形にしておくと、案Aの修正と案Bの修正が物理的に分かれる。Claude Code にも「今いる作業ディレクトリの案だけ扱う」と伝えやすい。
中途半端に同じディレクトリでブランチだけ切ると、切り替え忘れで事故る。タブをまたぐだけ、と思っていると痛い目を見る。人間はそこまで賢くない。
worktree を分けても、全部が完全独立ではない。Git の履歴は共有されるし、リポジトリ外のキャッシュや、IDE の設定、生成物の置き場は別問題だ。
ここを勘違いすると、片方で作った一時ファイルがもう片方に見えたり、逆に見えてほしいものが見えなかったりする。
だから、次のものは案ごとに分離して考える。
逆に、共通でよいものもある。
この整理を先にやるだけで、後の混乱がかなり減る。筆者は一度、同じ tmp を両案で使ってしまい、片方の検証結果がもう片方の下書きに混ざった。地味だが、こういう事故がいちばん時間を食う。
複数案を並走させる目的は、最後に比べることだ。だから作業ファイルだけでなく、評価メモも案ごとに分けると強い。
たとえば各案のフォルダに notes.md を置き、Claude Code にその案の狙いと気づきを書かせる。
この案では、変更の理由を notes.md に追記してください。
他の案と比較しやすいように、変更点を3行以内で書いてください。
これをやると、あとで「どの案がどの意図でこうなったか」が追える。差分だけ見ても分からないことは多い。特に文章作成や整理作業では、意図を書いておく価値が高い。
最後に一つだけはっきり言う。
同じリポジトリで複数案を並走させるときは、Claude Code の賢さより、作業場の分け方が勝つ。worktree で分ける、フォルダ名を分ける、出力先を分ける。この三つを押さえるだけで、衝突の大半は起きなくなる。
あとは各案に「これは何の案か」を言い切ってやればいい。曖昧に混ぜるほど、後で自分が困る。