はじめに
「Claude Codeで開発してるけど、1つずつ順番にIssueを片付けるのが遅い…」
そんな悩みを解決するために、Issue起票から並列開発、PR作成までを一気通貫で自動化するワークフローを構築しました。
具体的には、Claude CodeのSkillsを組み合わせて、以下を実現しています：
- 要件定義 — Claude Codeに「〇〇を作りたい。要件定義して」と伝え、対話しながら仕様を固める
-
/issue-create— 固まった要件からGitHub Issueを構造化して起票 -
/dev-plan— Issue群から依存関係を分析し、並列開発用の実行プロンプトを自動生成 -
/gtr-workflow— git worktreeで隔離された環境を作り、複数のClaude Codeセッションで同時に実装
このワークフローで一番大事なのは、実は最初の「要件定義」です。
実装・テスト・PR作成を自動化したことで、人間が本当に時間をかけるべき「何を作るか」の部分に集中できるようになりました。要件が曖昧なままIssueを作っても、AIは曖昧なまま実装してしまいます。逆に、要件さえしっかり固まっていれば、あとはプロンプトをコピペするだけで実装が完了します。
実行を自動化することで、思考に集中できる。 これがこのワークフロー最大のメリットです。
この記事では、各スキルの仕組みと実際の使い方を、プロダクト開発での実例とともに紹介します。
対象読者
- Claude Codeを日常的に使っている開発者
- 複数機能を効率よく並列開発したい人
- Claude CodeのSkills機能に興味がある人
この記事で得られること
- Issue駆動 × AI並列開発の具体的なワークフロー設計
- Claude Code Skillsの実践的な活用パターン
- git worktreeを活用した安全な並列開発の仕組み
目次
| 章 | 内容 |
|---|---|
| 1 | 全体像 — 3つのスキルが繋がるパイプライン |
| 2 |
/issue-create — 雑メモからIssueを構造化 |
| 3 |
/dev-plan — Issue群をWave構造に分解 |
| 4 |
/gtr-workflow — worktreeで並列開発 |
| 5 | 実例 — 10個のIssueを4Waveで並列開発した話 |
| 6 | 動作確認 — worktree環境での開発サーバー起動 |
| 7 | Skills の作り方 |
| 8 | まとめ |
1. 全体像 — 3つのスキルが繋がるパイプライン
まずワークフロー全体の流れです。
ポイントは「人間がやるのはプロンプトのコピペだけ」 ということです。
Issue起票の構造化も、依存関係の分析も、ブランチ作成も、実装も、PR作成も、すべてClaude Codeが自律的に実行します。人間は各ステップの出力を確認して、次のステップに進む判断をするだけです。
2. 要件定義 → /issue-create でIssueを構造化
まず要件定義に時間をかける
実際の開発では、いきなり /issue-create を使うことは少ないです。まずClaude Codeに「〇〇を作りたい。要件定義して」と伝え、対話しながら仕様を固めます。
> タスクのガントチャート表示機能を作りたい。要件定義して。
Claude Codeが質問してくるので、それに答えながら要件を詰めていきます。「表示単位は日/週/月？」「ドラッグで期間変更できる？」「依存関係の矢印は表示する？」——この対話が一番重要で、一番時間をかけるところです。
要件が固まったら /issue-create でIssueにします。
/issue-create は何をするスキルか
固まった要件をGitHub Issueとして構造化して起票してくれます。
使い方
Claude Codeで /issue-create と打ち、要件を伝えるだけです。
> /issue-create
タスク一覧画面に優先度カラムを追加したい。
あと操作列のUIがごちゃごちゃしてるから整理したい。
これだけで、以下のような構造化されたIssueが作成されます：
## 背景・目的
タスク一覧画面の優先度表示が不足しており、操作列のUIに改善の余地がある。
## 要件
### やること
- タスク一覧テーブルに優先度カラムを追加
- 操作列のUI整理（ボタン配置の見直し）
### やらないこと
- 優先度の自動算出ロジックの実装
## 完了条件（DoD）
- [ ] 優先度カラムがタスク一覧テーブルに表示される
- [ ] 操作列のボタンが整理され、主要操作が明確になる
- [ ] 既存のE2Eテストが通る
## 未確定事項・要確認事項
- 優先度の選択肢（High/Medium/Low の3段階 or 数値指定か）
設計のこだわり
このスキルの最大の特徴は**「推測しない」** ことです。
メモに書かれていない仕様は絶対に推測せず、不明点があれば AskUserQuestion で質問します。「たぶんこうだろう」でIssueを作ると、実装時に手戻りが発生するからです。
3. /dev-plan — Issue群をWave構造に分解
何をするスキルか
複数のIssue番号を渡すと、依存関係を分析してWave（実行順序）構造を決定し、各IssueをClaude Codeで実行可能なプロンプトとして出力します。
使い方
> /dev-plan #10-12
すると以下の流れで対話的に計画が作られます：
Wave構造の判断基準
スキルは以下のルールで依存関係を判断します：
| パターン | 判断 |
|---|---|
| DBスキーマ変更を含む | 最初のWaveに配置 |
| UI基盤（ナビ、レイアウト）の変更 | 早いWaveに配置 |
| 独立した画面・機能 | 並列可能 → 同じWaveに配置 |
| 明示的な依存（「〜の上に追加」） | 後のWaveに配置 |
出力例
実際に生成されるプロンプトファイルはこんな形式です：
# ガントチャート機能 — Claude Code 実行プロンプト
## 実行順序
```
Wave 1（直列）: #10 → #11 → #12
```
各WaveのPRがdevelopにマージ済みであること。
---
## Wave 1（直列）
### #10 タスクに開始日・終了日フィールドを追加
```
/gtr-workflow で develop ブランチから feature/task-date-fields
ブランチを作成して作業して。
まず gh issue view 10 でIssue内容を読んで。
既存の prisma/schema/models/Task.prisma を確認して。
Issue #10 の完了条件（DoD）を全て満たすように実装して。
確認できたら /pull-request スキルを使って develop に向けてPRを作成して。
コミットメッセージに "closes #10" を含めて。
```
### #11 ガントチャートUIコンポーネント
```
/gtr-workflow で develop ブランチから feature/gantt-chart-ui
ブランチを作成して作業して。
...
```
このプロンプトをClaude Codeにコピペするだけで、Issue読み込み → 実装 → テスト → PR作成が全自動で走ります。
補足ドキュメントの自動検出
Issue本文に docs/SPEC-xxx.md への参照や、既存コードへの言及がある場合、プロンプトに自動的に参照指示が追加されます。
補足として docs/SPEC-gantt-chart.md を参照して。
既存の src/app/projects/[id]/tasks/ のコードを参考にして。
これにより、Claude Codeが必要なコンテキストを漏れなく取得できます。
4. /gtr-workflow — worktreeで並列開発
なぜ git worktree なのか
通常のgitブランチ運用では、1つのディレクトリに1つのブランチしかチェックアウトできません。
複数のClaude Codeセッションが同じディレクトリで同時に作業すると、ファイルの競合が発生します。
git worktreeを使うと、ブランチごとに独立したディレクトリを作成できます。
~/dev/myapp/ ← 本体 (develop)
~/dev/myapp-worktrees/feature-auth/ ← worktree 1
~/dev/myapp-worktrees/feature-ui/ ← worktree 2
~/dev/myapp-worktrees/feature-api/ ← worktree 3
各ディレクトリは完全に独立しているので、複数のClaude Codeが安全に同時作業できます。
/gtr-workflow の動作
プロンプト内の /gtr-workflow が実行されると、以下が自動的に行われます：
.gtrconfig — worktree の自動セットアップ
プロジェクトルートに .gtrconfig を置くことで、worktree作成時の初期化を自動化できます。
[copy]
include = .env* # 環境変数ファイルをコピー
include = CLAUDE.md # プロジェクト指示をコピー
[hooks]
postCreate = npm install # 依存関係を自動インストール
これにより、worktreeが作成された瞬間から開発可能な状態になります。
並列実行の実際の流れ
Wave 2で3つのIssueを並列開発する場合の物理的な動きです：
人間がやることは「プロンプトのコピペ」と「PRのレビュー＆マージ」だけです。
5. 実例 — 10個のIssueを4Waveで並列開発した話
実際にこのワークフローで、通知システムの大規模リファクタリングを進めた例を紹介します。
プロジェクト構造
Wave 1: #30（通知共通基盤セットアップ）
Wave 2（2並列）: #31（メール通知）, #32（Slack通知）
Wave 3（5並列）: #33, #34, #35, #36, #38（各イベントトリガーの実装）
Wave 4（2並列）: #37（リアルタイム通知UI）, #39（統合テスト）
/dev-plan が生成したプロンプトの一部
Wave 3の5並列はこんな感じです。5つのターミナルを開いて、それぞれのプロンプトを貼り付けて実行しました：
/gtr-workflow で feature/notification-system ブランチから
feature/33-task-assigned-trigger ブランチを作成して作業して。
まず gh issue view 33 でIssue内容を読んで。
補足として docs/specs/SPEC-notification-system.md を参照して。
Issue #33 の完了条件（DoD）を全て満たすように実装して。
実装が完了したら /pull-request スキルを使って
feature/notification-system に向けてPRを作成して。
コミットメッセージに "closes #33" を含めて。
実際の worktree 状態
開発中の git worktree list の出力（イメージ）：
~/dev/myapp [develop]
~/dev/myapp-worktrees/feature-notification-base [feature/notification-base]
~/dev/myapp-worktrees/feature-email-notify [feature/email-notify]
~/dev/myapp-worktrees/feature-slack-notify [feature/slack-notify]
~/dev/myapp-worktrees/feature-task-assigned [feature/task-assigned-trigger]
~/dev/myapp-worktrees/feature-realtime-ui [feature/realtime-notification-ui]
6つのworktreeが同時に存在し、それぞれ独立したブランチで作業が進行しています。
6. 動作確認 — worktree環境での開発サーバー起動
worktreeの動作確認がめんどくさい問題
worktreeで並列開発すると、動作確認が地味にめんどくさいです。
通常の開発なら npm run dev で済みますが、worktreeでは：
- worktreeのディレクトリに移動しないといけない
-
npm installが必要（postCreateフックで済んでいればOKだが） - ポートが被らないように変更が必要（メインが3000を使っていると起動できない）
- 認証系の環境変数（
BETTER_AUTH_URL等）もポートに合わせて変更が必要
これを毎回手動でやるのはつらいので、wt-dev というシェル関数を作りました。
wt-dev — worktreeの開発サーバーをワンコマンドで起動
.zshrc に以下を追加します：
wt-dev() {
local name="${1//\//-}"
local port="${2:-3001}"
local dir="$HOME/dev/myapp-worktrees/$name"
if [ ! -d "$dir" ]; then
echo "worktree not found: $dir"
return 1
fi
local url="https://localhost:$port"
(cd "$dir" && npm install --silent && \
PORT=$port BETTER_AUTH_URL=$url NEXT_PUBLIC_APP_URL=$url npm run dev)
}
使い方はシンプルです：
# ブランチ名を指定するだけ（デフォルトポート: 3001）
wt-dev feature-auth
# ポートを指定することも可能
wt-dev feature-auth 3002
これで、メインの開発サーバー（ポート3000）を立ち上げたまま、worktreeの開発サーバーを別ポートで起動して動作確認できます。
並列開発時の動作確認イメージ
ターミナル 1: make dev → https://localhost:3000 (メイン)
ターミナル 2: wt-dev feature-auth → https://localhost:3001
ターミナル 3: wt-dev feature-ui 3002 → https://localhost:3002
ターミナル 4: wt-dev feature-api 3003 → https://localhost:3003
DBやMinIOなどのインフラはDocker Composeで共有しているので、開発サーバーだけ別ポートで立てれば各worktreeの動作確認ができます。
7. Skills の作り方
このワークフローは、Claude Codeの Skills 機能で実現しています。Skillsは .claude/skills/ ディレクトリに SKILL.md を配置するだけで作成できます。
ディレクトリ構造
.claude/skills/
├── issue-create/
│ ├── SKILL.md # スキル定義（プロンプト）
│ └── references/
│ └── output-structure.md # 出力フォーマットの参照資料
├── dev-plan/
│ ├── SKILL.md
│ └── references/
│ ├── prompt-template.md # プロンプトテンプレート
│ └── output-example.md # 出力例
└── pull-request/
├── SKILL.md
└── references/
└── pr-template.md # PRテンプレート
SKILL.md の構造
SKILL.md のフロントマターでスキルのメタ情報を定義し、本文にプロンプト（指示）を書きます。
---
name: issue-create
description: 雑な要件からGitHub Issueを生成
---
# Issue作成スキル
## あなたの役割
ユーザーから受け取ったテキストを分析し、
構造化されたGitHub Issueを作成してください。
## 手順
1. 入力テキストから要件を抽出
2. 不明点があれば質問（推測しない）
3. references/output-structure.md の形式でIssue作成
4. `gh issue create` で起票
## 制約
- 記載されていない仕様は推測しない
- コードは書かない
- 技術選定・実装方針は書かない
references/ の活用
references/ ディレクトリに参照資料を置くと、スキル実行時にClaude Codeが自動的に読み込みます。テンプレートや出力例を分離することで、SKILL.md本体をシンプルに保てます。
スキル連携のコツ
スキル同士を連携させるには、出力形式を統一することが重要です。
-
/issue-createの出力（Issue）を/dev-planが読む → Issueのフォーマットを統一 -
/dev-planの出力（プロンプト）に/gtr-workflowの呼び出しを含める → テンプレートで定型化 -
/gtr-workflowの実行結果を/pull-requestに繋げる → プロンプト内に指示を記載
8. まとめ
このワークフローで変わったこと
| Before | After |
|---|---|
| 実装に時間を取られて要件が雑になる | 実行を自動化し、要件定義に集中できる |
| Issueを手動で書く |
/issue-create で構造化して起票 |
| 1つずつ順番に実装 | Wave構造で並列開発 |
| ブランチ切り替えで作業中断 | worktreeで完全隔離 |
| PR作成が面倒 |
/pull-request で自動生成 |
| 開発計画を頭の中で管理 |
/dev-plan でプロンプトとして文書化 |
要点
-
/issue-create→ 推測しない。不明点は質問する。構造化されたIssueを起票 -
/dev-plan→ 依存関係を分析してWave構造に分解。実行可能なプロンプトを生成 -
/gtr-workflow→ git worktreeで隔離環境を作り、複数Claude Codeで並列開発 - 人間がやるのは「プロンプトのコピペ」と「PRレビュー」だけ
スキルを使ってみる
この記事で紹介したスキルは以下のリポジトリで公開しています。
以下のコマンドでインストールできます：
# 全スキルを一括インストール
npx skills add okazuki58/agent-skills -y
# 個別にインストール
npx skills add okazuki58/agent-skills --skill <skill-name> -y
参考リンク
株式会社シンシアでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
シンシアでは、年間100人程度の実務未経験の方が応募し技術面接を受けます。その経験を通し、実務未経験者の方にぜひ身につけて欲しい技術力（文法）をここでは紹介していきます。