Cursor Worktreeとは?git worktreeで並列エージェントを動かす完全ガイド【2026年最新】
室谷今回はCursorのWorktree機能を取り上げましょう。これ、.AI(ドットエーアイ)コミュニティでも「Cursor 3になってから設定の仕方が変わった」という声が増えてきているんですよね。
テキトー教師ですよね。Cursor 2の時代からworktreeを使ってる人は設定の変化に戸惑いつつも、Cursor 3になって「/worktreeコマンド」が追加されたことでむしろ使いやすくなったという声も聞きます。
ただ、そもそもworktreeが何なのかわからないまま使ってる人も多いですね。
ただ、そもそもworktreeが何なのかわからないまま使ってる人も多いですね。
室谷まずgit worktreeの基本から入りましょうか。git worktreeって要は、1つのリポジトリに対して複数の作業ディレクトリを持てる機能なんですよ。
普通はブランチを切り替えるときに
普通はブランチを切り替えるときに
git checkoutするじゃないですか。でもworktreeを使うと、複数のブランチを同時に別々のディレクトリで展開できる。
テキトー教師そこが重要ですよね。
cloneは全オブジェクトをコピーするのでディスクをたくさん使いますが、worktreeは同じリポジトリのオブジェクトデータベースを共有しつつ、作業ディレクトリとインデックスだけを分離する仕組みです。だからcloneより圧倒的に速いし、容量も少なくて済む。
git cloneで複製するのとは違います。cloneは全オブジェクトをコピーするのでディスクをたくさん使いますが、worktreeは同じリポジトリのオブジェクトデータベースを共有しつつ、作業ディレクトリとインデックスだけを分離する仕組みです。だからcloneより圧倒的に速いし、容量も少なくて済む。
室谷それがAIエージェントの並列実行と相性抜群なんですよ。1つのCursorウィンドウで複数のAIエージェントを走らせたとき、全員が同じファイルを同時に編集したら衝突しますよね。
でもworktreeで各エージェントに独立した作業ディレクトリを与えれば、互いに干渉せずに並列で動ける。
でもworktreeで各エージェントに独立した作業ディレクトリを与えれば、互いに干渉せずに並列で動ける。
テキトー教師「エージェントAがsrc/auth.tsを編集している間に、エージェントBがsrc/notification.tsを編集する」という並列作業が安全にできるようになるわけです。これ、コミュニティのメンバーさんに実感してもらうために「工場のライン」で例えることが多いです。
1本のラインに作業員を詰め込むより、並列ラインで分業した方が速いでしょう、と。
1本のラインに作業員を詰め込むより、並列ラインで分業した方が速いでしょう、と。
git worktreeの基本コマンド:Cursor使用前に押さえておくこと
室谷Cursorでworktreeを使う前に、まずgit worktreeのコマンドを把握しておきましょう。ここを理解していないと、Cursor側の設定を変えても何が起きているのか追えなくなります。
テキトー教師整理するとこうなります。基本操作はほぼ4つで完結します。
# 既存のブランチからworktreeを作成
git worktree add ../feature-auth feature/auth
# 新しいブランチを作りながらworktreeを作成
git worktree add -b feature/notifications ../feature-notifications
# 全worktreeの一覧を表示
git worktree list
# 使い終わったworktreeを削除
git worktree remove ../feature-auth
室谷git worktree addの引数が「ディレクトリパス」→「ブランチ名」の順になっているのがポイントですよね。../feature-authというのは親ディレクトリにfeature-authというフォルダを作るという意味で、プロジェクトの外に置くことが多いです。
テキトー教師ここ、最初に混乱するポイントです。worktreeのフォルダは元のプロジェクトフォルダの中に作るのではなく、並列に置くイメージです。
例えばプロジェクトが
例えばプロジェクトが
~/dev/my-appにあるなら、worktreeは~/dev/my-app-feat-authみたいな場所に作るわけですね。
室谷-bオプションをつけると新規ブランチを同時に作成できます。既に作成済みのブランチに対してworktreeを張る場合は-bは不要です。MYUUUでも複数フィーチャーを同時に走らせるときはこのパターンをよく使います。
テキトー教師git worktree listを実行すると、メインの作業ディレクトリとworktreeが一覧表示されます。どのディレクトリがどのブランチと紐づいているかも確認できるので、並列作業中に「どこで何をやっていたか」を確認するのに便利です。
室谷使い終わったworktreeは
git worktree removeで削除します。ただしプッシュ・マージ済みであることを確認してからやらないと変更が消えます・・・講座でこれをやらかした人、いましたっけ(笑)
テキトー教師いました(笑)。なのでworktreeを削除する前に、必ず
git worktree listでステータスを確認して、変更が取り込まれているかを確認するように指導してます。Cursor 3のWorktree機能:/worktreeと/best-of-nコマンド
室谷Cursor 3(2026年4月リリース)でWorktreeの扱い方が大きく変わりましたよね。Cursor 2では設定UIがあったんですが、3ではより「エージェント的」なアプローチになりました。
テキトー教師具体的には2つのコマンドが追加されました。
これがCursor 3の目玉機能でもあります。
/worktreeと/best-of-nです。これがCursor 3の目玉機能でもあります。
室谷/worktreeはチャットで使うスラッシュコマンドで、実行するとCursorが自動的に独立したgit worktreeを作成してその中で作業します。例えばこんな感じです。/worktree 認証テストの失敗を修正して、ログイン画面のコピーも更新して
と打つと、エージェントがworktreeで作業して、完了後に/apply-worktreeでメインブランチに変更を取り込む流れになります。
テキトー教師/best-of-nはさらに面白い機能で、同じタスクを複数のAIモデルで同時に実行して、それぞれの結果を比較できます。例えば、/best-of-n sonnet, gpt, composer フラキーなログアウトテストを修正して
と打つと、各モデルが別々のworktreeで同じ問題に取り組んで、親エージェントが結果を比較してくれる。
室谷これ、複数のモデルの「得意不得意」を実際のタスクで比較できるので、「どのモデルが自分のコードベースに合っているか」の判断材料になるんですよ。MYUUUでもバックエンド系のタスクとフロントエンドのスタイリング系でベストなモデルが違うかを検証するのに使えます。
テキトー教師ただ、Cursor 3のこの変更に対してはユーザーコミュニティから賛否両論もあります。Cursor 2のUIベースの設定の方が「何が起きているか見えやすくてよかった」という声もありますね。
スラッシュコマンドベースはシンプルですが、透明性はやや下がる。
スラッシュコマンドベースはシンプルですが、透明性はやや下がる。
室谷トレードオフですよね。コマンドベースの方がプロンプト内で完結するので、エージェントから呼び出しやすいという利点はあります。
でも慣れるまでは確かにCursor 2の方が直感的だったかもしれないですね・・・
でも慣れるまでは確かにCursor 2の方が直感的だったかもしれないですね・・・
Cursor AgentsウィンドウのエージェントLocation設定:Local・Worktree・Cloud
テキトー教師: Cursor 3で新たに追加されたAgentsウィンドウの話もしておきましょう。Cmd+Shift+P → Agents Windowで開けるやつですね。
室谷これが今のCursorのworktree並列実行の中心になっています。エージェントをどこで動かすか「Location」を選べるんですが、選択肢が3つあります。
| Location | 概要 | ファイル分離 | 設定の手間 |
|---|---|---|---|
| Local | 今開いているプロジェクトディレクトリで直接実行 | なし | ゼロ |
| Worktree | 自動生成されたgit worktreeで分離実行 | あり(完全分離) | 少ない |
| Cloud | クラウド環境で実行(現在はAgentsウィンドウ専用) | あり | 要設定 |
テキトー教師Localは設定が要らない代わりに、複数エージェントを同時に走らせると同じファイルを競合して編集するリスクがあります。Worktreeは少し設定が必要ですが、完全に分離されるので安心です。
室谷Cloudは以前Editorのチャットからも選べたんですが、Cursor 3でEditorからは削除されて、Agentsウィンドウ専用になりました。ここは注意が必要です。
テキトー教師実際の開発フローとしては、単一タスクを素早く処理したいときはLocal、独立した複数フィーチャーを並列で走らせたいときはWorktree、という使い分けが自然ですね。
室谷Cursor 3では複数のエージェントを並列実行できます。公式ドキュメントには上限数の明示はありませんが、現実問題としてメモリが16GB以下のマシンだと3〜4個が限界です。
MYUUUのエンジニアは16GBのMacでも実用上は3個同時が快適な上限、という感じですね。
MYUUUのエンジニアは16GBのMacでも実用上は3個同時が快適な上限、という感じですね。
テキトー教師受講生さんには「欲張って8個走らせるより、3個をしっかり動かした方が速い」と言っています。CursorウィンドウはRAMを結構食いますから、数を増やしすぎるとかえって全体が遅くなります。
.cursor/worktrees.jsonの設定:マルチエージェントの自動タスク分配
室谷worktreeを使う上でキモになるのが
.cursor/worktrees.jsonの設定ですよね。これを正しく書くと、エージェントが起動したときに自動でセットアップ処理を走らせることができます。
テキトー教師プロジェクトルートの
.cursor/フォルダにworktrees.jsonを置くんですが、ここに書けることがいくつかあります。OSごとのセットアップコマンド、環境変数ファイルのコピー、DBのマイグレーション実行などです。
室谷基本的な構造はこんな感じです。
{
"setup-worktree-unix": "npm install && cp .env.example .env.local",
"setup-worktree-windows": "npm install; Copy-Item .env.example .env.local"
}
テキトー教師setup-worktree-unixがmacOS・Linux用、setup-worktree-windowsがWindows用のPowerShellコマンドです。worktreeが作成されるたびにこれが実行されます。npm installを書いておけば、新しいworktreeでも依存パッケージが揃った状態で作業を始められます。
室谷並列エージェントのタスク分配まで自動化するなら、もう少し複雑にする必要があります。要はエージェントが起動したときに「自分は何番目のエージェントか」を把握して、対応するタスクだけを実行する仕組みを作るんですよ。
テキトー教師具体的にはこういうアプローチです。セットアップスクリプト内でタイムスタンプ付きのセッションIDを生成して、ロックファイルで競合を防ぎながら、各エージェントがタスク番号をクレームする。
その番号が
その番号が
.agent-idファイルに書き込まれます。{
"setup-worktree-unix": "SESSION=$(date +%s%N); AGENT_ID=1; while [ -f .task-claim-$AGENT_ID ]; do AGENT_ID=$((AGENT_ID+1)); done; echo $AGENT_ID > .agent-id; touch .task-claim-$AGENT_ID; echo 'Agent ID: '$AGENT_ID",
"setup-worktree-windows": "..."
}
室谷そしてエージェントへのプロンプトを「
.agent-idファイルを読んで、その番号に対応するタスクだけを実行してください」と書けば、4つのエージェントが起動した瞬間にそれぞれ1〜4番のタスクを自動で割り振ってくれます。MYUUUでAPIエンドポイントを一気に4つ追加するときにこれをやったんですが、通常の4倍のスピードで完了しましたよw
テキトー教師ただ、この自動タスク分配は「タスクが完全に独立している場合」に限ります。あるエージェントの変更が別のエージェントの作業範囲に影響するような場合は、分配が難しい。
例えば
例えば
shared/utils.tsを複数のエージェントが編集する可能性があるなら、ファイルレベルで担当を切り分ける設計が必要です。
室谷そこが腕の見せ所なんですよね。worktreeで並列化するには、タスクの設計段階から「このタスクは独立して実行できるか」を意識する必要がある。
それができると、エンジニアリングの生産性が本当に変わります・・・
それができると、エンジニアリングの生産性が本当に変わります・・・
worktrees.jsonで設定できる内容の一覧
| 設定項目 | 内容 |
|---|---|
setup-worktree-unix | macOS/Linux用のセットアップコマンド |
setup-worktree-windows | Windows用のPowerShellコマンド |
| 依存インストール | npm install / pip install -r requirements.txt など |
| 環境変数コピー | cp .env.example .env.local |
| DBマイグレーション | npx prisma migrate dev など |
| エージェントID割り当て | カスタムスクリプトで番号を/agent-idに書き込み |
Cursor worktreeの実践的なセットアップ手順
テキトー教師ここで実際の手順を通して見ていきましょう。ゼロから「worktreeで並列エージェントを使いたい」という状態から始めるとすると、大きく3ステップです。
室谷手順としてはこうなります。
ステップ1:worktreeを作成する
# メインプロジェクトのディレクトリで実行
cd ~/dev/my-app
# 2つのworktreeを並列で作成
git worktree add -b feat/auth ../my-app-auth
git worktree add -b feat/notification ../my-app-notification
# 作成されたか確認
git worktree list
テキトー教師このコマンドを実行すると、
~/dev/my-app-authと~/dev/my-app-notificationというフォルダが新しく作られます。それぞれが独立したブランチで、同じリポジトリを参照しています。ステップ2:各worktreeに依存パッケージをインストール
# worktree1のセットアップ
cd ~/dev/my-app-auth
npm install
cp .env.example .env.local
# worktree2のセットアップ
cd ~/dev/my-app-notification
npm install
cp .env.example .env.local
室谷.cursor/worktrees.jsonを設定していれば、Cursorがworktreeを作った時点でこの作業を自動でやってくれます。ただし手動でworktreeを作った場合は、自分でセットアップする必要があります。ステップ3:各worktreeをCursorで開いて並列実行
# ターミナルから2つのCursorウィンドウを開く
cursor ~/dev/my-app-auth
cursor ~/dev/my-app-notification
テキトー教師または、Agentsウィンドウ(
Cmd+Shift+P → Agents Window)からLocationをWorktreeに選択してエージェントを起動する方法もあります。Cursor 3ではこのUIベースの方法と、/worktreeコマンドベースの方法の両方が使えます。
室谷開発中のポートが被る問題も意識しておく必要があります。例えばNext.jsのdev serverがデフォルトで3000番ポートを使う場合、2つのworktreeを同時に動かすと衝突します。
.env.localでそれぞれ3001番、3002番を使うように設定しておくか、起動コマンドでPORT=3001 npm run devと指定するのが現実的です。
テキトー教師これはコミュニティのメンバーさんが最初につまずくポイントです。worktreeを作ったはいいけど「なぜかdev serverが起動しない」ってなって、ポートの競合だったというパターンが多いです。
cursor worktreeの削除とクリーンアップ
室谷worktreeを使い終わった後の後処理も大事です。削除しないとどんどん積み重なって管理が大変になりますし、使い終わったworktreeはHDDの容量も食います。
テキトー教師削除の手順はシンプルです。まずマージを完了させて、それからworktreeを削除する流れです。
# 1. worktreeのブランチの変更をメインにマージ
cd ~/dev/my-app
git merge feat/auth
# 2. worktreeディレクトリを削除
git worktree remove ../my-app-auth
# 3. ブランチも削除(任意)
git branch -d feat/auth
# 4. 古いworktreeの参照を整理
git worktree prune
室谷git worktree pruneは、worktreeのフォルダを手動削除してしまったときなどに、gitの参照情報だけが残ってしまう状態をクリーンアップするコマンドです。これを知らないと「worktree listに幽霊が出る」状態になります(笑)
テキトー教師git worktree removeは未コミットの変更がある場合はエラーになります。強制削除したい場合は--forceオプションをつけますが、変更が消えるので慎重に使ってください。worktreeのステータス確認コマンド早見表
| コマンド | 用途 |
|---|---|
git worktree list | 全worktreeと紐づきブランチを一覧表示 |
git worktree remove <path> | worktreeを安全に削除 |
git worktree remove --force <path> | 変更があっても強制削除 |
git worktree prune | 無効なworktree参照を整理 |
git worktree move <src> <dst> | worktreeのディレクトリを移動 |
cursor devcontainerとworktreeの組み合わせ
室谷devcontainerとworktreeを組み合わせる話も触れておきましょうか。devcontainerは開発環境をDockerコンテナの中に閉じ込めて「どのマシンでも同じ環境」を実現する仕組みですよね。
テキトー教師これ、worktreeとの組み合わせで注意が必要な点があります。devcontainerのカスタマイズ設定は
.devcontainer/devcontainer.jsonに書くんですが、Cursorがこのファイルを読む際に、VS CodeとCursorでは拡張機能のIDの扱いが違うんです。
室谷Cursorは実質VS Codeをフォークしたものなので、同じ
特にWSL2(Windows Subsystem for Linux 2)とdevcontainerを組み合わせたケースで、worktreeのパスが正しく解決されない問題があります。
devcontainer.jsonの記法が使えます。ただ、2026年現在でも拡張機能の自動インストールに若干バグがある報告があります。特にWSL2(Windows Subsystem for Linux 2)とdevcontainerを組み合わせたケースで、worktreeのパスが正しく解決されない問題があります。
テキトー教師devcontainerの基本的な構造はこうです。
{
"name": "My App Dev Container",
"image": "mcr.microsoft.com/devcontainers/typescript-node:18",
"customizations": {
"vscode": {
"extensions": [
"esbenp.prettier-vscode",
"dbaeumer.vscode-eslint"
]
}
},
"postCreateCommand": "npm install"
}
室谷このdotnet、
postCreateCommandをうまく使えばworktrees.jsonのセットアップスクリプトと役割が重複することがあります。どちらに書くかは「毎回実行したいか(worktrees.json)」か「コンテナ作成時だけ実行したいか(devcontainer.json)」で判断するのがいいと思います。
テキトー教師WSL2環境でのバグについては、2025年末時点でCursorのコミュニティフォーラムに報告が上がっていて、回避策として「worktreeはコンテナ外で管理して、コンテナ内にマウントする」アプローチを取っている人もいます。完璧な解決策はまだない状態なので、WSL2ユーザーは注意が必要です。
室谷これ、まさにgit worktreeの価値を象徴したツイートなんですが・・・個々のツールは誰でも使える。でもどう組み合わせるかが本質だよ、という話です。
devcontainerとworktreeの組み合わせも同じで、それぞれ単体では普通の開発ツールですが、AIエージェントの並列実行と組み合わさると、開発速度が質的に変わります。
devcontainerとworktreeの組み合わせも同じで、それぞれ単体では普通の開発ツールですが、AIエージェントの並列実行と組み合わさると、開発速度が質的に変わります。
cursor worktree agentの実践例:複数機能を同時開発するワークフロー
テキトー教師実際のワークフローをイメージしてもらうために、具体的なシナリオで話しましょうか。例えばECサイトに「商品検索機能」と「カート機能」を同時に追加するケースです。
室谷この場合、まずタスクが完全に独立しているかを確認します。検索とカートは基本的に別のコンポーネント・別のAPIエンドポイントなので、分離できます。
src/shared/utils.tsみたいな共通ファイルを両方が触るなら、その部分だけ先にメインブランチで実装してから並列化するのがベストです。
テキトー教師フローとしてはこうなります。
git worktree add -b feat/search ../my-app-searchgit worktree add -b feat/cart ../my-app-cart- Cursorで両方のworktreeを開いて、それぞれにエージェントを起動
- エージェント1には「検索機能をsrc/features/searchに実装して」
- エージェント2には「カート機能をsrc/features/cartに実装して」
- 両方が完了したらdiffを確認してマージ
室谷この流れで、通常1〜2日かかる作業が数時間に縮まることがあります。MYUUUでやってみて一番驚いたのが、エージェント同士が干渉しないから、片方のエージェントの失敗がもう片方に影響しないことですよ。
1つのブランチで全部やってると、エージェントが変なコードを出力したときのリカバリーが大変ですが、worktreeなら「そっちは捨てて、こっちだけマージ」みたいな使い方もできる。
1つのブランチで全部やってると、エージェントが変なコードを出力したときのリカバリーが大変ですが、worktreeなら「そっちは捨てて、こっちだけマージ」みたいな使い方もできる。
テキトー教師マージ戦略の話で言うと、Cursor 3のworktreeでエージェントが完了すると、フルdiffが表示されます。そこで「全部Accept」か「部分的にAccept」を選べます。
「この実装はいいけど、この部分は自分で書き直したい」という場合は、ファイル単位でAccept/Rejectを使い分けることもできます。
「この実装はいいけど、この部分は自分で書き直したい」という場合は、ファイル単位でAccept/Rejectを使い分けることもできます。
室谷/best-of-nを使ったケースも面白くて、「TypeScriptのレガシーコードをモダンな書き方にリファクタリングして」というタスクを3つのモデルに同時に投げると、モデルごとにアプローチがまったく違ったりします。どのアプローチが自分たちのコードスタイルに合っているかを比較して、いいとこ取りができる。cursor worktree vs cursor local:どっちを使うべきか
テキトー教師「結局worktreeとlocalどっちがいいの?」という質問、コミュニティでよく出ます。これ、シンプルに使い分けの基準があります。
室谷まとめるとこうなります。
| ケース | 推奨モード | 理由 |
|---|---|---|
| 単一タスク・シンプルな修正 | Local | 設定不要、即座に始められる |
| 独立した複数フィーチャーの並列開発 | Worktree | ファイル競合なし、安全 |
| モデル比較・ベスト実装の選択 | Worktree (/best-of-n) | 隔離された比較環境 |
| 既存ブランチへの小さな変更 | Local | シンプルで十分 |
| 大規模リファクタリング | Worktree | 元のコードを保持しながら安全に作業 |
テキトー教師「単一エージェントで完結する作業をworktreeでやる意味はほぼない」です。worktreeはセットアップのオーバーヘッドがあるので、1つのタスクだけならLocalで十分です。
worktreeの価値は「並列」にあります。
worktreeの価値は「並列」にあります。
室谷でも本当に面白いのは、/worktreeコマンドを使うと単一エージェントでも「メインのコードを汚さずに実験的な実装を試せる」点ですよね。実験してみて気に入ったら
Git stashよりクリーンに使えます・・・
/apply-worktreeでマージ、気に入らなければそのまま捨てる。Git stashよりクリーンに使えます・・・
テキトー教師大規模なリファクタリングでworktreeを使う場合は特に効果的です。メインブランチで普段の開発を続けながら、worktreeブランチでリファクタリングを進められるので、「リファクタリングが終わるまで新機能を止める」という状況を避けられます。
cursor worktreeのよくあるエラーと対処法
室谷worktreeを使い始めると必ず一度は遭遇するエラーをまとめておきましょうか。
テキトー教師まず多いのが
fatal: 'branch-name' is already checked outというエラーです。
室谷これは既にメインのworktreeでチェックアウトしているブランチを、別のworktreeでも使おうとしたときに出ます。解決策は新しいブランチを作るか、そのブランチを使っているworktreeを先に削除することです。
テキトー教師次は
cursor running in worktree問題。これはCursorがworktreeの中で起動しているときに、ツールやプラグインがメインリポジトリのパスを期待しているのにworktreeのパスが来てズレるケースです。
室谷WSL2+devcontainerの組み合わせでこれが起きやすいんですよね。Cursorが内部でパスを解決するときに、コンテナ内のパスとホスト側のパスが混在して、
cursor running in worktree状態で期待どおりに動かないことがあります。
テキトー教師実用的な回避策としては「worktreeはWSL2の外(Windowsのネイティブファイルシステム)に作る」か「devcontainerを使わずにWorktreeだけ使う」のいずれかです。両方を同時に使う場合は、Cursorのコミュニティフォーラムの最新情報を確認するのが確実です。
室谷あとは
git worktree not foundエラーですが、これはworktreeのディレクトリを手動で削除した後にgitの参照が残っているときです。さっき紹介したgit worktree pruneで解消できます。cursor worktreeエラー早見表
| エラー | 原因 | 対処法 |
|---|---|---|
already checked out | 同じブランチを2つのworktreeで使おうとした | 新ブランチを作成するか既存worktreeを削除 |
cursor running in worktree | パス解決の混在(WSL2+devcontainer) | WSL2外にworktreeを作成 |
not found / prune関連 | ディレクトリを手動削除後の参照残り | git worktree pruneを実行 |
| ポートの競合 | 複数worktreeがデフォルトポートを使用 | .env.localでポートを分ける |
まとめ
室谷今回はCursorのworktree機能を一通り解説しましたね。git worktreeの基本から、Cursor 3の新コマンド、worktrees.jsonの設定、実際の並列開発ワークフローまで。
テキトー教師大事なポイントを整理するとこうなります。
- git worktreeはcloneと違い、同じリポジトリを共有しながら作業ディレクトリだけを分離する仕組み
- Cursor 3では
/worktreeコマンドと/best-of-nコマンドでworktreeを簡単に使えるようになった - AgentsウィンドウでLocationを「Worktree」に設定すると、複数のエージェントを安全に並列実行できる
.cursor/worktrees.jsonでworktree作成時のセットアップを自動化できる- worktreeは「タスクが独立している」場合に最大限の効果を発揮する
- WSL2+devcontainerとの組み合わせには既知の制限がある
室谷ここで本質を言うと、worktreeはツールじゃなくて「開発の設計思想」なんですよ。「どのタスクが独立していて、どのタスクが依存しているか」を整理する力がそのままworktreeの活用力に直結します。
この整理ができると、AIエージェントの使い方も根本的に変わります。MYUUUのチームでも、worktreeを導入してからタスクの切り方が変わりましたね。
この整理ができると、AIエージェントの使い方も根本的に変わります。MYUUUのチームでも、worktreeを導入してからタスクの切り方が変わりましたね。
テキトー教師受講生さんには「まず1つのworktreeを手動で作って、小さな機能追加をやってみてください」と言っています。最初からフル並列化を目指さなくていい。
1つのworktreeで「メインを汚さずに実験できる」という体験をするだけで、開発フローが変わりますよ。
1つのworktreeで「メインを汚さずに実験できる」という体験をするだけで、開発フローが変わりますよ。
FAQ
Q. worktreeを使うとCursorの課金が増えますか?
室谷課金はCursorのプランに依存しますが、worktreeを使ったからといって追加料金はありません。エージェントのリクエスト数がプランの上限に影響するのは変わりませんが、「worktreeを使ったから余計に課金された」ということはないです。
テキトー教師ただ、並列実行するとエージェントが同時に複数動くので、その分リクエスト消費は速くなります。MaxプランやTeamプランで使うのが安心です。
Q. Cursor worktreeはWindows(PowerShell環境)でも使えますか?
室谷使えます。
ただしWSL2を使っているケースはパスの問題が出やすいので、Windows Nativeの環境で使う方がスムーズです。
worktrees.jsonでsetup-worktree-windowsにPowerShellのコマンドを書く必要がありますが、git worktree自体はWindowsでも動作します。ただしWSL2を使っているケースはパスの問題が出やすいので、Windows Nativeの環境で使う方がスムーズです。
Q. cursor worktrees(複数形)と worktree(単数形)は同じものですか?
テキトー教師同じ機能を指します。複数形の「worktrees」は複数のworktreeをまとめて指す場合に使われます。
.cursor/worktrees.jsonというファイル名も同様で、複数のworktreeの設定を1つのファイルで管理するためにworktreesという名前になっています。Q. cursor worktree mergeのタイミングはいつがいいですか?
室谷エージェントの作業が完了して、diffを確認してOKだと判断したタイミングです。ただ、マージ前に「そのworktreeのブランチで自分のローカルでテストする」時間を取ると品質が上がります。
エージェントが正しいコードを書いてくれても、インテグレーション上の問題は実際に動かさないと見えないことがあります。
エージェントが正しいコードを書いてくれても、インテグレーション上の問題は実際に動かさないと見えないことがあります。
テキトー教師大きな機能追加の場合は、worktreeブランチをそのままPRとして出して、CI/CDのテストを通してからマージするフローも自然です。worktreeのブランチはそのままGitHubにプッシュできますから。
