こちらの記事はクリエーションライン Advent Calendar 2025 8日目の記事です。
はじめに
この記事を読んだらわかること
- Cursorを利用して並行開発の始め方
- Issue駆動開発でAI駆動開発をするためのやり方
この記事の対象の方
- Cursorの基本操作がわかっており、少し発展的な使い方をしてみたい方
- Cursorを使って並行開発を始めたいが、何から手をつければ良いのかわからない方
- Git Worktreeを使ってみたが、AIがコンフリクトを起こしまくって沼にハマってしまった方
動作確認をした環境
- OS : MacOS 15.6.1
- IDE : Cursor 2.1.48
1. 背景
みなさんは、CursorなどのAIエディターを利用して開発を進めているとき、以下のような不満が出たことはありませんか？
- 開発の初期段階ではサクサク開発が進んだけど、機能追加やリファクタリングを重ねていくうちに重複コードや意味のないインポートが増えてきた...
- 指示していない機能までを追加してきて、作業を止めなければならないことが増え始めた...
- 仕様駆動開発をしているけど、今の開発規模に対しては過剰すぎるかも...
上記で挙げたように、AIエディターを利用した開発は開発スピードが上がる一方、
AIエディター特有の課題を多く感じられている方が多いと思われます。
とくに、最近流行している仕様駆動開発ではこれらの課題が解決できる一方で、多くの開発状況においては過剰とも言える準備をしてから開発を始めることになります。
そこで、これらの課題が解決できないかと模索していた結果、当記事で紹介する
Cursor + Git Worktree + Issue駆動開発に辿り着いたため、ご紹介させていただきます！
今回はCursorの機能を利用してGit Worktreeを使用しています。
Cursor以外のIDE/エディタで並行開発がしたい方でも、手法自体は参考になると
思います！
2. 開発の準備
まずはじめに、これらの開発を上で必要な準備を説明していきます。
前提として、以下の条件はすでに準備済みであるとします。
- Cursor 2.0が利用できる
- Git Worktreeの超基礎的なことがわかっている。（Git Worktreeの概要がわかればOK）
- GithubにIssueが登録できる（Issueが立てられなくても、ローカルで管理をすれば再現可能です）
2.1 開発の流れ
Issue駆動開発を行う流れは、以下のようになります。
1. 追加したい機能を言語化し、AIに壁打ちをしながらIssueを作成する。
2. 作成したIssueをもとに、AIと壁打ちしながら並行開発の方針を立てる。
3. 立てた方針をもとにGit Worktreeの準備をする。
4. 実装を開始する。
補足
AIによる並行開発は、人間側のレビュー負担が非常に大きいものとなっています。
並行開発の方針を立てず、Issue駆動開発を行うのみでも十分効果は高いため、
ご自身の環境に合わせて利用してみてください！
これらの流れをコマンド化し、必要なファイルをコンテキストとして渡すことで開発を進めていきましょう！
今回は、以下の画像のようなカレンダーの日付をクリックすることで、タスクを追加できるタスク管理アプリへ機能を追加しながらこの手法を解説していきます。
2.2 Issueテンプレート作成~機能の壁打ち~Issue作成
2.2.1 Issueテンプレートの作成
まずは、Issue駆動を始めるためのIssueテンプレートを作成していきます。
GithubへIssueテンプレートを登録する場合には、こちらを参照して設定してください。
この記事では、GithubのIssueテンプレートを作成し、プロジェクトルートに配置した.github/ISSUE_TEMPLATE.yamlに記述をします。
Issueの記法に関しては各プロジェクトごとに設定しても大丈夫ですが、テンプレートは必ず設定をしておいてください。
2.2.2 機能の壁打ち
Issueテンプレートを作成したら、まずは追加したい機能の壁打ちをAIで行なっていきます。
以下のようなプロンプトを投げて、軽めの壁打ちから始めます。
# 目的
- Issue駆動開発を行うために、追加機能の要件を洗い出す。
- 以下の機能の概要セクションを読み、実装のために必要な情報をユーザーから引き出す。
- Issue作成にはまだ進まず、機能要件を洗い出すためだけに作業をすること。
# 機能の概要
- （実装したい機能について、思いついたことをとりあえず箇条書きで書く）
- （実装の際の注意事項や、ドメイン固有の情報もここに書いておく）
# 用語集
- (ドメイン特有の用語や、プロジェクト特有の用語がある場合にはここに記述する）
- 用語集ドキュメントなどを作成し、それをコンテキストとして渡しても大丈夫です。
# 技術スタック
- 技術スタックのドキュメントを作成し、それをコンテキストとして渡しても大丈夫です。
今回のタスク管理アプリに、タスクの詳細を追加する機能を追加したいので、以下のようなプロンプトを投げて対応してみます。
なお、CursorのモードはPlanモードを利用して行います。
個人的な感覚ですが、思いつかなかった観点の質問を実施してくれるため利用しています。
モデルに関してはなんでも大丈夫ですが、こういった方針決定にはOpusやCodexなどのモデルを利用しています。
↓こういった質問を追加で行なってくれるため、要件の詰め具合を上げることができます。
質問に答えていくと、以下のようなドキュメントが作成されました。
# タスク詳細機能 要件ドラフト
## 1. 対象フィールドと前提
- 本文: Markdown対応（太字/斜体/リンク/リスト/コードブロック）。空許容。最大長候補: 4000文字（要確定）。
- 期限: 日付+時刻。保存形式は ISO 8601（オフセット込み）。初期は未設定。過去日時の扱いは要確認（警告許容 or 保存不可）。
- 優先度: high / medium / low（表示: 高/中/低、既定: medium）。
- タグ: 複数可。重複不可。前後空白はトリム。最大件数候補: 8件、1件最大長候補: 24文字（要確定）。全体長も上限設定想定（例: 200文字）。
- 入力タイミング: タスク作成後に任意で追加・編集できる。既存タスクにも編集導線を用意。
- 保存タイミング: 明示的な「保存」ボタンで確定。未保存状態で閉じる場合は確認ダイアログ。
## 2. UI方針（モーダル）
- トリガー: タスクリスト行の「詳細を追加/編集」ボタンからモーダルを開く。
- モーダル構成:
- ヘッダー: タスク名 + 閉じる(X)
- 本文:
1. 本文フィールド（Markdownエディタ: ツールバー/プレビュー切替）
2. 期限（日付ピッカー + 時刻入力、クリアで未設定へ）
3. 優先度（ラジオまたはセレクト: 高/中/低）
4. タグ（トークン入力: Enter/カンマで確定、重複禁止）
- フッター: 「保存」(primary) / 「キャンセル」(secondary)。未保存変更があれば閉じる際に確認。
- 挙動:
- 初期値: 保存済みデータを反映。新規は本文空、期限なし、priority=medium、tags=[]。
- バリデーションエラー: フィールド下に表示。保存時にトースト併用も検討。
- Markdown表示時はサニタイズを実施。
## 3. データモデル案（フロント）
type Priority = 'high' | 'medium' | 'low';
type TaskDetail = {
body: string; // Markdown, 0〜4000文字(要確定)
dueAt: string | null; // ISO 8601 (with offset), nullable
priority: Priority; // default 'medium'
tags: string[]; // unique, trimmed
};
## 4. バリデーション案
- body: length <= 4000（要確定）。表示時はXSS対策でサニタイズ。
- dueAt: ISO 8601形式のみ許容。null可。過去日時の扱いを要決定（警告許容 or 禁止）。
- priority: high/medium/low のみ。未指定は medium。
- tags:
- 件数: 0〜8件（要確定）
- 文字数: 各1〜24文字（要確定）
- 重複不可、空白のみは無効。全体長も上限設定を想定（例: 200文字）。
## 5. 未確定事項（要決定）
- 本文最大長（4000で問題ないか）
- 期限の過去日時: 許容+警告 or 保存不可
- 期限のタイムゾーン: ローカル固定か、選択可能か
- タグ: 最大件数・文字数の確定
- エラーメッセージ文言ルール（日本語短文で統一するか）
## 6. テスト観点下書き
| Case ID | Input / Precondition | Perspective (Equivalence / Boundary) | Expected Result | Notes |
| --- | --- | --- | --- | --- |
| TC-N-01 | 本文空、期限なし、priority=medium、tagsなし | Equivalence – normal | 保存成功、既定値で保持 | |
| TC-N-02 | 本文にMarkdown(太字/リンク/コード)、期限=将来日時、tags=3件 | Equivalence – normal | 保存成功、表示時にMarkdownレンダリング/サニタイズ | |
| TC-B-01 | 本文長=最大値 | Boundary – max length | 保存成功 | max値要確認 |
| TC-B-02 | 本文長>最大値 | Boundary – max+1 | バリデーションエラー | |
| TC-B-03 | タグ数=上限(8) | Boundary – max count | 保存成功 | 上限要確認 |
| TC-B-04 | タグ数=上限+1 | Boundary – max+1 | エラー（件数超過） | |
| TC-B-05 | タグ1件長=上限(24) / >上限 | Boundary – max length | 24は成功、25はエラー | 上限要確認 |
| TC-A-01 | dueAtが不正文字列 | Equivalence – invalid format | エラー（形式不正） | |
| TC-A-02 | 過去日時を入力 | Boundary – past | ①許容なら警告付き保存、②禁止ならエラー | 要決定 |
| TC-A-03 | priorityに許容外値 | Equivalence – invalid enum | エラー | |
| TC-A-04 | タグ重複/空白のみ | Equivalence – invalid tag | エラー（重複禁止/空白無効） | |
## 7. 次ステップ候補
- 未確定事項の確定（本文長/過去日時扱い/TZ/タグ上限/文言）。
- 上記を確定後、Issue起票とUI/バリデーション仕様反映、テストケース確定。
ここで出てくるドキュメントのテンプレートなども設定しておき、より必要な情報を入れる・必要のない情報を除外するといった作業をすることによって、生成されるものの精度が向上します。（今回は手法の紹介ですので、このあたりは割愛させていただきます。）
2.2.3 Issueの作成
さて、少し長くなりましたが、ここからはこのドキュメントを利用してIssueテンプレートに基づいたIssueを作成していきます。
Issueに含める情報もプロジェクトによって最適なものを見つけていく必要はありますが、今回は以下の情報を含めます。
# 機能の概要
# 機能を実装する目的・期待される効果
## スコープ
### スコープでやること
## フロントエンド関連のこと
- 例1
- 例2
## バックエンド関連のこと
- 例1
- 例2
## テスト関連のこと
- 例1
- 例2
### スコープでやらないこと
- スコープ外の機能
- なぜスコープ外なのかという理由
### 受け入れ条件
- [ ] 受け入れ条件
## 実装タスク
- フロントエンド関連
- [ ]
- バックエンド関連
- [ ]
- テスト関連
- [ ]
## 他Issueとの依存関係
- 前提条件 : このIssueを進めるために必要な条件（例:Issue番号#XXが実装済みである）
- 並行開発の可能性 : 並行開発が可能なIssueと注意事項
Issueテンプレートを設定したら、以下のプロンプトを投げて実際にIssueを作成してもらいましょう！
# やること
- 並行開発を実施するために、渡された機能をIssueに分割する。
- コンフリクトが発生しないように、Issue同士の依存関係や並行開発の可能性を検討してIssueを立てる。
- IssueはISSUE_TEMPLATEに従って作成する。
- Issue作成後、統一可能なIssueは統一をして、極力Issue数を減らすこと。
- Issueはマークダウンファイルでも作成し、``issue/{機能名}/``に保存すること。
## 実装したい機能
@{2.2.3で作成した、実装したい機能を説明したマークダウンファイル}
今回はこのようなIssueが作成されました。（分割の度合いが高すぎたため、少し減らしています。）
2.3 並行開発のための方針を立てる
2.3.1 並行開発のためのテンプレート
Issueを立てたら、並行開発のための方針を記載したドキュメントを作成します。
ドキュメントには、以下のようなものを記述すると効果的です。（検証中）
## 1. 依存関係と前提
- ### 1.1 機能依存
- ### 1.2 並行開発の可能性
- ### 1.3 想定変更ファイル
## 2. コンフリクト分析
- ### 2.1 競合ポイント
- ### 2.2 他機能との競合リスク
- ### 2.3 競合を避ける設計方針
## 3. ブランチ戦略（Issue駆動）
- ### 3.1 推奨ブランチ構成
- ### 3.2 worktree 構成
## 4. git worktree セットアップ手順
- ### 4.1 前提
- ### 4.2 worktree 作成
## 5. 実装フェーズと並行開発の詳細
- ### 5.1 フェーズ構成
- ### 5.2 実装順序の詳細
## 6. マージ戦略
- ### 6.1 推奨マージ順序
- ### 6.2 rebase 手順（worktree 側）
このテンプレートをParallel_Plan_Template.mdのような名前でドキュメントをプロジェクト内に配置しておきます。
テンプレートを設定したら、以下のようなプロンプトを投げて方針を作成します。
# やること
- ユーザーから渡されたIssueをもとに、並行開発のための方針を立てる。
- 並行開発方針のテンプレートは @Parallel_Plan_Template.md にあるので、これに基づいて作成する。
- コンフリクトや並行開発の可能性を徹底的に検討して作成すること。
- 最後に、ユーザーに並行開発が可能なIssueを伝え、次にやることを簡潔に伝える。
## Issueファイル
- @{作成したIssueファイル群をコンテキストとして渡す}
今回は実行すると以下のようなファイルが作成されました。
これで、方針ファイルを作成することができました。
続いては、作成したファイルを用いてGit Worktreeの作成へ進みましょう！
2.4 Git Worktreeの準備をしよう
Git Worktreeの作成にも生成AIを利用することができます。
先ほど作成した方針ファイルをコンテキストとして渡して、以下のプロンプトを入力しましょう。
# やること
- ユーザーから受け取った並行開発のための方針ファイルを読み、Git Worktreeの準備を実施する。
- Git Worktreeの準備をする以外の作業はしないこと。
- 準備を終えたら、ユーザーに次にやるべきことを簡潔に伝える
## 並行開発方針のファイル
@ {作成した並行開発のファイル}
今回は、以下のようなディレクトリが作成されました。
現段階のディレクトリ構成はこのようになっています。
project-name/
├─ main/
│ └─ project-name/
│ ├─ doc/ # ルール/ガード系
│ ├─ docs/ # タスク手順・テンプレ・技術メモ
│ ├─ issue/
│ │ └─ task_detail/ # 00〜04 仕様・検討
│ ├─ public/ # vite.svg 等
│ ├─ src/ # (詳細省略)
│ ├─ README.md, index.html
│ ├─ package.json, pnpm-lock.yaml
│ ├─ tsconfig*.json, vite.config.ts, eslint.config.js
├─ worktrees/
│ ├─ task-detail-01/
│ ├─ task-detail-02/
│ ├─ task-detail-03/
│ └─ task-detail-04/
│ └─ (各フォルダ内は qiita_calendar と同型構成: doc/docs/issue/src など)
Git Worktreeのディレクトリの配置などに関しては、別途Git Worktreeに関する情報をご覧ください。
これで、Git Worktreeの準備ができました！
次はCursorのWorktree機能を利用して実装を進めていきましょう！
2.5 実装を進める
ここからは、いよいよ実装に入ります！
実装の際には、CursorのWorktree機能を利用して開発を進めます。
2.5.1 CursorのWorktree機能の使い方
CursorのAIパネルを開き、チャットの左下を確認すると以下の画像のようなボタンがあります。
こちらをクリックして、Worktreeを選択し、先ほど作成したGit Worktreeが作成されていることを確認します
それぞれのブランチと、機能ごとのIssue番号が一致しているため、それぞれのブランチを選択して以下のプロンプトを投げます。
# やること
- ユーザーから渡されたIssueを解決する。
- 並行開発に関する注意事項と、その方針が書かれたファイルも渡されるため、それを確認してから実装を開始する。
- 実装の際には、コンフリクトを最小限に抑えるために、並行開発の方針を確認してから実装を進める。
## 実装の進め方
- Issueファイルには
- 実装タスク
- 受け入れ基準
が書かれているため、このタスクと受け入れ基準のチェックリストを埋める形で作業を進めていく。
- 作業が完了後、実装内容とチェックボックスを照らし合わせ、チェックボックスが埋められるならチェックボックスにチェックマークを入れる。
- 全てのチェックマークが入れられた時点で、作業完了の報告を行う。
### あなたが解決するIssueファイル
@ {対応するIssueファイルまたはGithubのIssueリンク}
### 並行開発の方針
@ {並行開発方針を記述したファイル}
Issue-01の例では、このようなプロンプトを投げることで作業が開始できます。
ここからは、確認が必要なコマンドが出力されるたびにCursorから通知音が鳴るため、内容を確認して進めていきます。
今回の例で言うと、03は01/02が前提になっていて、04は03が前提となっているため、
- 01/02を並行開発→03→04
と言う流れで作業を進めていきます。
作業中の画像は割愛させていただきますが、
- 実装完了→rebaseを行い変更を取り込む→コンフリクトが発生した場合には、コンフリクト解消のプロンプトを投げる
といった作業を繰り返します。
# やること
- 並行開発の方針を確認し、rebaseを実施する
# やること
- コンフリクトが発生しているため、並行開発の方針を確認してコンフリクトを解消する。
実装の際には、Planモードを利用することでより精度の高い出力が期待できます！
実際に、ブラウザで開くとこのような機能が追加されていることがわかりました！
今回程度の機能であれば、簡単なプロンプトのみで実装ができるため、ここまで重厚なIssue駆動開発を行うメリットが小さかったと思います。
しかし、長くAI駆動開発を進めていくときにはこの手法が大きく力を発揮します！
3.まとめ
今回のAI+Issue駆動開発の手法は、従来通りの仕様駆動開発を使って開発をするほどでもない機能追加などに対して有効な手法だと考えています。
まだ途中のプロンプトや、レビューの方法に関しては検証している最中ですので、実際にこの手法を利用して開発をしてみた方がいらっしゃれば、ぜひコメントの方へ感想や改善案をいただけると幸いです！