こんにちは、ENECHANGEのEV Devチームの利廣です。
私は最近、"Kiroの仕様書駆動開発プロセスをClaude Codeで徹底的に再現した"という記事で紹介されているSpec-Driven Development（仕様駆動開発）の手法を実践してみました。この手法は、従来の実装からAIを取り入れるアプローチではなく、詳細な設計書の作成からAIを取り入れる体系的なAI駆動開発プロセスです。実際のプロジェクトに適用したワークフローを構築してみたところ、予想以上の効果を得ることができました。
実践した開発フロー
基本的なワークフロー
下記の全てをAIとのやりとりを通して作成していきます。
- 詳細設計書の作成
- タスク分解
- 各タスクの実装、適宜テスト作成
- PR作成
- レビュー
📝 コマンドの詳細: 各コマンドの詳細な設定方法や使用方法については、claude-code-spec GitHubリポジトリを参照してください。
コマンドの変更
今回の実践では、コマンドの内容を以下のように変更しています。 よって、参考にさせていただいた記事を完全に再現した内容ではないことをご了承ください。
- ビジネス関連の情報は適宜省略
- 英語を日本語で記載
- プロジェクトの情報をNotionとFigmaから取得できる(MCPサーバーを使用)
- いくつかのステップを省略
1. 詳細設計書の作成
詳細設計書作成の重要性
詳細設計書の作成は、この開発フローの最も重要な要素です。以下のような効果が期待できます：
🫵 ポイント
- 機能追加による懸念点や他の機能との兼ね合いなど、人間の手では思いついていない部分まで挙げてくれる → 手戻りが減る
- 変数名やエラーハンドリングなど、細かい部分まで提案してくれるので、タスク分解に移る際にとても楽になる
- レビューが必要な部分を明確にして、逐次確認するのでAIが暴走するリスクが少ない
詳細設計書作成の手順
ステップ1: ドキュメントとディレクトリの初期化
自動化フローの基礎となるファイルの作成をします。
使用コマンド：
/kiro:spec-init [feature-name]
ステップ2: 要件定義の作成
前のステップを元に、Claude Codeが理解しやすい形での要件定義を作成します。
使用コマンド：
/kiro:spec-requirements [feature-name]
ステップ3: 詳細設計書の作成
要件定義を元に、実装レベルの詳細設計書を作成します。この段階でClaude Codeは機能追加による懸念点や変数名、エラーハンドリングなど細かい部分まで提案してくれます。
使用コマンド：
/kiro:spec-design [feature-name]
2. タスク分解
詳細設計書が完成したら、次にタスク分解を行います。
🫵 ポイント
- 詳細設計書にかなり細かいところまで記載しているので、タスク分解が容易かつ詳細な指示を記載することができる
この段階では、/kiro:spec-tasksコマンドを使用して、設計書を元にした具体的なタスクに分解します。
使用コマンド：
/kiro:spec-tasks [feature-name]
3. 各タスクの実装、適宜テスト作成
分解されたタスクを実装していくフェーズです。
🫵 ポイント
- テストの作成や、既に実装済みのコンポーネントをできるだけ使うようになど細かい指示を出せる
- Perfect Commit（コード実装、テスト記載、ドキュメント更新）ができる
使用コマンド：
/kiro:implement-task [feature-name]
また、実装の進捗状況を確認するためのコマンドも提供されています。
4. PR作成
実装が完了したら、PRを作成します。
🫵 ポイント
- 大量の変更点があったとしても、コミットを細かく分けることができる
この段階では、通常のClaude CodeのPR作成機能を使用して、コミットしきれていない変更点も含めて適切にPRを作成します。
5. レビュー
最終段階では、以下の観点でレビューを行います：
- CIでの確認
- レビュー自体のチェック
- AIによるコードレビュー
各フェーズでレビュー&修正を行うことで、品質の高いコードを確保します。
このワークフローでは、各段階で人間によるレビューと承認が重要な要素となっています。
仕様駆動AI開発 vs コード駆動AI開発
今回のワークフローを検証する過程で、仕様駆動AI開発（今回実践した手法）とコード駆動AI開発（従来の手法）の違いが明確になりました。
仕様駆動AI開発（今回実践した手法）
仕様駆動AI開発では、設計段階からAIを活用して詳細な仕様書を作成し、その後の実装段階でも同じAIを使ってコードを生成します。設計と実装の両段階でAIを一貫して活用するのが特徴です。
メリット
実装精度の向上
- 詳細設計書により、実装すべき内容が明確化
- 修正対象ファイルの特定精度が大幅に向上
- 影響範囲の見落としが激減
- エラーハンドリングまで含めた包括的な実装案の提示
レビュー効率の向上
- 設計段階での十分な検討により、実装レビューの負担が軽減
- 第三者レビュワーにとっても理解しやすい実装
- 品質保証プロセスの標準化
デメリット
AI設計能力への過信リスク
- AIの設計能力を過信すると見当違いな実装になる可能性
- 常に批判的な視点でのレビューが必要
時間的コスト
- 設計書作成に時間がかかる場合がある
- 簡単なタスクには過剰な設計になる可能性
コード駆動AI開発（従来の手法）
コード駆動AI開発では、設計段階は人間が行い、実装段階からAIの活用を開始します。実装しながら要件を明確化していくアプローチです。
メリット
迅速な着手
- すぐに実装に取りかかれる
- 簡単な修正に適している
- 試行錯誤を通じた学習効果
デメリット
手戻りの多発
- 実装途中での仕様変更や見落としによる手戻り
- 影響範囲の見落としにより不具合が混入する可能性が高まる
レビュー負荷
- 実装意図が不明確でレビューに時間がかかる
- 品質保証に多くのリソースが必要
気づき
タスクの性質による使い分けの重要性
仕様駆動AI開発が適している場面
- 複雑な機能追加
- 既存システムへの影響が大きい修正
- チーム開発での実装
- 品質要求が高いプロダクション環境
コード駆動AI開発が適している場面
- 単純な修正作業
- 要件が不明確な探索的開発
AIとの協働における新しい発見
設計書の役割の変化
従来の設計書は人間同士のコミュニケーションツールでしたが、AIとの協働では「AIへの指示書」としての側面が強くなりました。この認識によって、より具体的で実装可能な設計書を作成する重要性が明確になりました。
品質保証プロセスの進化
設計段階でのAIとの対話により、従来の実装後品質チェックから、設計段階での品質確保へとシフトできます。これにより、さらに効率的な品質保証が可能になりました。
今後の展望
TDDとの組み合わせ
今後は、TDDの手法に沿ってより安全性が高く、かつAIにとって開発のしやすいフローでの開発を行っていきたいと考えています。テスト駆動と仕様駆動の組み合わせにより、さらに堅牢な開発プロセスが構築できそうです。
SOW（Statement of Work）の導入
SOW（Statement of Work）という概念に沿った仕様書駆動開発も取り入れていきたいと思います。より明確な作業範囲の定義により、AIエージェントとの協働がさらに効率化されることを期待しています。
結論
Kiroの仕様書駆動開発プロセスをClaude Codeで実践した結果、以下の成果を得ることができました：
- 実装時の手戻り - 大幅に減少
- 実装品質 - エラーハンドリングまで含めた包括的な実装の実現
- 複雑な要件に対する系統的なアプローチの確立
- 開発プロセスの標準化と知識の蓄積
ただし、このアプローチが真価を発揮するためには、開発者自身の調査と判断が不可欠です。AIの設計能力を過信せず、常に批判的な視点でレビューを行うことが成功の鍵だと感じています。
今後も、より効率的で品質の高い開発プロセスを追求していきたいと思います。
