こんにちは。最近は生成AIと一緒に開発するスタイルが増えてきましたね。
私もこれまでにGitHub Copilot、Cursor、Claudeなど、いろんなツールを試してきましたが、現在は Claude Code を中心に開発を行っています。
この記事では、Claudeとペアプロを行うような感覚で進めている 「人間×生成AI協調型」の開発フロー を紹介します。
単なる便利ツールではなく、チームメンバーのようにClaudeと働くために整えた実践的なフローです。ジュニアエンジニアとのペアプロを意識した構成になっているので、導入時の参考になれば嬉しいです。
🎯 この記事の対象読者
この記事は、以下のような方に特におすすめです：
- 生成AI（ClaudeやCopilotなど）を開発にどう活かすか模索しているエンジニア
- AIとうまく役割分担する開発スタイルを探している方
- ジュニアメンバーとペアプロをしている、あるいは開発指導の立場にある方
- 開発フローを整備したいが、ドキュメントの作成や運用に悩んでいる方
- Claudeに興味があるけど「何から始めればいいか分からない」という方
「生成AIを活用したいけど、いまひとつしっくりくる運用が見つからない…」という人にとって、"実務ベースで運用しているフロー"をそのまま紹介するこの記事がヒントになれば嬉しいです。
👣 Claudeと組む前提
いろんなツールを試して感じたのは、以下の2つです：
- まだAIにすべての権限は委ねられない（設計判断・レビューは人間が必要）
- 一方で、情報収集やコーディングなどの作業は圧倒的にAIが速い
そのため私は「ジュニアクラスのエンジニアとペアプロしている」感覚でClaudeと開発をしています。
| 担当領域 | 人間（開発者） | Claude |
|---|---|---|
| 設計判断・要件調整 | ✅ | ❌ |
| 実装方針の決定 | ✅ | 補助的に提案 |
| コーディング | ❌ | ✅ |
| 振り返り・記録 | 監修 | ✅ |
| Git操作（push, PR, merge） | ✅ | ❌ |
この分担がちょうど良く、結果として開発効率もナレッジの再利用性も上がりました。
🧭 Claudeとの開発フロー（全体像）
運用では、以下のようなフローを定義したMarkdownファイルを毎回Claudeに読み込ませた上でスタートします。
📄 Claudeに渡している開発フローの原文
クリックして開く（全文展開）
# 開発ワークフロー
このドキュメントは、Claude Code を使用した開発タスクの進行フローを定義します。
## 開発フローの概要
### 1. 要望の受け取りと質問
- ユーザーから開発要望を受け取る
- **計画済みタスクの確認**: ユーザーが「次のタスクを確認したい」と要望した場合は `docs/plan_index.md` を参照し、進行予定の次のアイテムを提示
- 要望に対して不明な点があれば質問する
- 要望の内容を正確に理解するまで確認を行う
### 2. 情報収集と開発計画立案
- 要望を実現するために必要な情報を収集
- 既存のコードベースを分析
- 要望を実現するための開発計画を立案
- **開発計画書**：わかりやすい名前を付けてMarkdown形式で保存
- 例：`plan_new_feature.md`、`plan_ui_improvements.md`など
- **開発順序管理**：複数の機能開発時は`docs/plan_index.md`で順序を管理
- 完了済み機能、進行予定機能を明確に区分
- 開発の優先順位と依存関係を整理
### 3. 開発計画の確認と調整
- ユーザーが開発計画を確認
- 必要に応じてユーザーから質問や修正依頼
- 開発計画の内容を調整・最終化
### 4. フェーズ分けによる段階的開発
- 軽微な要望：一気に開発を進める
- 複雑な要望：いくつかのフェーズに分割して段階的に開発
- **フェーズ分割の粒度**：3-5人日程度のボリュームを目安とする
- レビュー・振り返り・コミットはフェーズ単位で実施
- 細かすぎる分割は管理コストが高く、大きすぎる分割は問題発見が遅れる
- 作業の自然な区切りと適切な管理負荷のバランスを考慮
## 開発実装フロー
### 5. ブランチ作成
- 開発計画が確定したら新しいブランチを作成
- **命名規則**：Git Flow の命名規則に従う
- 新機能：`feature/機能名`
- バグ修正：`hotfix/修正内容`
- リリース：`release/バージョン`
### 6. フェーズ毎のコーディング
- 各フェーズに沿ってコーディングを実施
- 段階的にコードを実装
### 7. コードレビュー（必須）
- **重要**：コーディング完了後、必ずユーザーのレビューを受ける
- **レビュー方法**：
- 基本的にはチャットでの質問・修正依頼
- ユーザーがターミナルやエディタで実際のコードを確認
- 大規模な修正や指摘がある場合はファイルに書き起こすことも
- ユーザーからの質問や修正依頼に対応
- **レビュー完了前のコミットは禁止**
### 8. Git コミット
- レビューが完了してからコミットを実行
- 適切なコミットメッセージを作成
### 9. 開発計画書への追記
- コミット完了後、開発計画書に進捗を記録
- 実装内容、問題点、改善点などを記載
### 10. 次フェーズへの移行
- ユーザーからの指示に基づいて次の行動を決定
- 次フェーズの開発継続
- 開発計画の見直し
- その他の作業
## 開発完了と振り返り
### 11. 開発完了の確認
- 予定された全フェーズが完了
- 要望が全て実現されたことを確認
### 12. 振り返りの実施
- 各フェーズの進捗や問題点、改善点を話し合い
- 振り返り内容をドキュメントに記録
- **重要なやり取りの必須記録**：
- フェーズ完了後にチャットセッションがクリアされることを前提とする
- 技術的な議論、設計判断、問題解決プロセスなど重要なやり取りを振り返り時に記録
- 特に最終振り返り時には、将来の改善に活用すべきやり取りを必ず記載
- 記録が不十分だと貴重な知見が失われるため、過度に簡潔にしない
- 次回開発に活かすための知見を蓄積
## Git 操作の責任分担
### Claude Code が行う操作
- コードの実装
- コミットの実行
- 開発計画書への追記
### ユーザーが行う操作
- Git へのプッシュ
- Pull Request の作成
- マージ作業
- その他明確な指示がない限りの Git 操作
## 重要な注意事項
1. **レビュー完了前のコミット禁止**
2. **ブランチ命名規則の遵守**
3. **各フェーズでの進捗記録**
4. **振り返りのための問題点・改善点の記録**
---
## 振り返りプロセス
### 振り返りの目的
- 技術的判断と学習内容の体系的記録
- プロセス改善点の抽出と標準化
- チャットセッションクリア前の重要情報保持
- 将来プロジェクトで活用可能な知見の蓄積
### 振り返り実施タイミング
1. **フェーズ完了時**: 各開発フェーズ完了後の短時間振り返り
2. **開発完了時**: プロジェクト全体の包括的振り返り
3. **問題解決時**: 重要な技術的課題解決後の知見記録
### 振り返り観点（4つの視点）
#### 1. 技術的観点
- **実装方法の評価**: 選択した技術・アーキテクチャの妥当性
- **ライブラリ選定**: 選定基準と結果の適切性
- **設計品質**: パフォーマンス、セキュリティ、保守性の評価
- **代替案検討**: 他の選択肢との比較と判断根拠
#### 2. プロセス観点
- **計画精度**: 見積もりと実績の乖離分析
- **フェーズ分割**: 分割粒度と移行タイミングの適切性
- **レビュー効率**: レビュープロセスの品質と効率性
- **ドキュメント管理**: 作成・更新・活用の効率性
#### 3. コミュニケーション観点
- **要件理解**: 初期要件の理解精度と確認プロセス
- **技術説明**: 提案・説明の分かりやすさと適切性
- **フィードバック対応**: レビュー指摘への対応品質
- **進捗報告**: 報告内容の適切性とタイミング
#### 4. 学習・改善観点
- **新規習得技術**: 今回新しく学んだ技術・手法
- **再利用可能パターン**: 他プロジェクトで活用できる手法
- **回避パターン**: 今後避けるべき失敗・非効率パターン
- **プロジェクト固有知見**: 特定環境・制約での対応方法
### 振り返り記録方法
#### 記録すべき内容
1. **技術的議論・設計判断の詳細**
- 判断に至った根拠と検討プロセス
- 採用・却下した選択肢と理由
- 将来参照すべき技術的知見
2. **問題解決プロセス**
- エラー・課題の発生経緯と原因分析
- 解決アプローチと手順の詳細
- 効果的だった調査・対処方法
3. **重要なやり取り**
- レビューフィードバックと対応経緯
- 技術的質問・回答の詳細
- 設計・実装に影響した議論内容
#### 記録品質の基準
- **具体性**: 抽象的でなく、具体的な行動指針として記録
- **再現性**: 同様の状況で再利用可能な形で整理
- **判断根拠**: 単なる結果でなく、なぜその判断をしたかを明記
- **学習価値**: 将来の改善に活用できる形で知見を抽出
### 振り返り結果の活用
#### ドキュメント更新への反映
- **project-structure.md**: 技術設計指針への知見統合
- **development_workflow.md**: プロセス改善の標準フローへの反映
- **CLAUDE.md**: 重要な技術的注意事項の追加
#### 開発プロセスへの適用
- フェーズ分割粒度の最適化
- レビュー観点の改善
- 技術選択基準の明確化
- 問題解決手順の標準化
🧩 運用イメージとステップ概要
主なステップは以下のとおりです：
| ステップ | 内容 |
|---|---|
| 1. 要望の受け取りと質問 | 目的を明確にし、疑問は徹底的に潰す |
| 2. 情報収集と開発計画 | ClaudeがMarkdown形式で計画を作成 |
| 3. 計画レビュー | 人間がチェックし、必要に応じて修正 |
| 4. フェーズ分割 | 粒度3〜5人日で分ける（過不足なく） |
| 5. ブランチ作成 | Git Flowに準拠、Claudeが自動で命名 |
| 6. 実装とレビュー | Claudeが実装 → 人間がレビュー |
| 7. コミットと記録 | 承認後にClaudeがコミット、進捗記録 |
| 8. 振り返り | Claudeに記録を書かせ、ナレッジ蓄積 |
💡 やってみてよかったこと
✅ 人間の思考に集中できる
手が止まりがちな部分（検索・比較・タイピング）をClaudeに任せて、私は設計や判断に専念できるようになりました。
✅ 記録が残る
開発の終わりには「今回の学びと改善点をまとめて」と指示するだけで、振り返りドキュメントが完成します。
✅ 並列開発にも強い
複数プロジェクトを並行していても、フローが明文化されているのでコンテキストの切り替えが容易。ジュニアとClaude、同時に2人とペアプロしてる気分になります。
🚀 導入のコツ
最初から全てを任せる必要はありません。
おすすめは 「振り返り記録だけClaudeに任せる」 ことです。
- なぜその技術を選んだ？
- 解決までにどんな手順を踏んだ？
- 次回避けたい落とし穴は？
これらをAIに書かせるだけでも、開発ナレッジの見える化が進みます。
✍️ おわりに
AIは、単なる自動化ツールではなく、正しく使えば開発体験そのものを進化させてくれる存在です。
人間とAIが得意なことを補い合う、そんなフローがもっと広まっていけば嬉しいです。
👋 この記事はChatGPTと協力して執筆しました。Claudeとの開発フローも、ChatGPTとの執筆も、人間が主導です（笑）
📨 コメント・フィードバック歓迎！
生成AIを使った開発に興味がある方、すでに試している方、ぜひコメントで知見をシェアしていただけたら嬉しいです！