プロジェクトが大きくなると、1つのAIが一度に1つずつ作業するだけでは物足りません——もっと速く進めたい、いくつものことを同時に試したい。ここで、本気で作っている人たち(そして私たち)が使っている裏技があります。複数のAIセッションを並列で開き、それぞれがプロジェクトの隔離されたバージョンを持つのです。1つは機能を作り、もう1つは別の何かを直し、もう1つは新しいアイデアを試す——3つが同時に進み、互いに邪魔せず、メインのバージョンには触れません。そして各セッションは、終わったら C-A-R プロトコルで監査され、完璧になって初めてプロジェクトに統合(マージ)されます。結果:3倍のスピードで、セーフティネット付きで進めます。この生きたコピーは worktree と呼ばれ、VS Code の中の Claude なら作成はコマンド一発です。ここでそのメリット、専門用語なしの仕組み、そしてそれを組む prompt を理解できます。
その瞬間は、プロジェクトが大きくなり、1つのAIが一度に1つずつ作業するだけでは物足りなくなった時にやってきます。もっと速く進めたい:あるセッションが機能を作っている間に、別のセッションがバグを直し、3つ目が新しいアイデアを試す——すべて同時に。また、2つの道で迷った時(「こうするか、ああするか?」)、決める前に両方を見たい時も。あるいは、すでに動いているものに触れずに、リスクのある何かを試したい時も。こうしたケースすべてで、たった1つのバージョンの上で一度に1つずつ進めるのは、遅くて脆いのです。
GitHub ガイドでブランチを見ました:プロジェクトの並列コピーです。worktree はそれをさらに一歩進めます:それらのブランチのいくつかを同時に開いて生きたまま持てるようにし、それぞれが自分専用のフォルダにあり、互いに触れません。1つのAIが「アイデアA」で作業している間、別のAIが「アイデアB」にいられて、メインのバージョンは無傷のままです。一度に1つずつではなく——全部を同時にです。
Claude Code には VS Code 向けの公式拡張機能があります(Cursor や互換ツールでも動きます)。そこから複数のAIセッションを並列で開き、それぞれ自分専用の worktree で動かし、提案された変更をビジュアル diff(横並び)で見て、承認したり却下したりできます。何より、隔離された worktree の作成はコマンド一発です。
claude --worktree mi-idea-arriesgada
これでプロジェクトの隔離コピーが(.claude/worktrees/mi-idea-arriesgada/ に)新しいブランチの上に作られ、メインのバージョンには触れません。そこでアイデアを試し、うまくいけば統合し、ダメなら削除して何事もなかったことに。claude --worktree otra-idea で別のセッションを開き、2つを同時に競わせることもできます。
これが最大のメリットで、まさに私たちが構築している方法です:1つのAIが一列縦隊で進むのではなく、複数のセッションが並列で作業し、それぞれが自分専用の worktree にいます。セッション1が製品の一部を作り、セッション2が別の何かを組み、セッション3は新しいアイデアを試しているかもしれない——3つが同時に進み、互いに邪魔しません。1人ではなく3人の従業員を、それぞれ自分の机で、邪魔し合わずに持つようなものです。
VS Code の中で、AIがファイルを変更したい時、横並びの比較を見せてくれます:元々あったもの vs 提案するもの。あなたが決めます:受け入れる、却下する、または何を変えるか伝える。あなたの知らないところで何も変更されません。従業員が変更を適用する前に一つ一つ見せてくれるようなもので、全部に触ってから後で気づく、ということがありません。
これをコピーしてコードエージェントに貼れば、コマンドを覚えなくても、複数の戦線で同時に働くよう導いてくれます:
複数のセッションを並列で(それぞれ自分専用の隔離バージョン=worktreeで)動かして、プロジェクトをもっと速く進めたい。互いに邪魔せず、メインのバージョンを壊さずに。gitを知らない前提で、簡単な言葉で導いて。 1. worktreeとは何か、一文で説明して(プロジェクトの生きた隔離コピー)。 2. 私はこれらの戦線を同時に進める:[タスクを列挙、例:「1) ホーム画面を作り直す、2) ログインを直す、3) 新しいアイデアを試す」]。安定バージョンから分岐して、それぞれに専用のworktreeを作って。 3. 各worktreeでVS Codeを開いて、diffを見て変更をビジュアルに承認/却下する方法を教えて。 4. 重要なルール:各セッションは自分専用のブランチにpushすること、決してメイン(main)にはしない。メインはマージ経由でのみ受け取る。 5. あるタスクがそのworktreeで終わったら、統合する前に:C-A-Rプロトコルを適用して(監査、デバッグ、完璧に仕上げる)。その時初めてそのブランチをメインにマージし、コンフリクトは自然言語で解決して。 6. あるアイデアが実らなかったら、メインプロジェクトが気づかないうちにそのworktreeを捨てる手伝いをして。 黄金律:並列で進めるが、メインブランチにはマージ経由で監査済みのものだけが入る——決して中途半端には入れない。
Join 4,200+ builders. No credit card. Build your first app with AI in minutes.