こんにちは、コバヤシです。
前編では、書籍「実践Claude Code入門」のサンプルをベースに、仕様駆動AI開発のワークフローをチームで構築するまでの過程を紹介しました。
仕組みはできた。でも「本当に回るのか？」が一番の不安でした。ワークフローが複雑すぎて誰も使わなくなるかもしれないし、実案件の速度感に合わないかもしれない。
後編では、そのワークフローを実案件で全工程回した結果と、それを支えた仕組みについて紹介します。
実案件で全工程を回してみた
セットアップタスクと機能タスクを合わせて、PRD作成から外部設計書、ステアリング作成、実装、テスト、振り返りまで、全タスクをワークフローに沿って実行しました。
テスター指摘が減った
最も実感できた効果は、テスターからの指摘が明らかに減ったことです。
設計段階で仕様漏れを潰し、実装時に都度確認で軌道修正し、自動テストも通す。テスターに渡る前の品質が上がっているので、テスターの仕事が「バグ探し」から「最終確認」に近づきました。
実装完了時にテスト観点チェックリスト（詳しくは後述）をテスターに渡す運用も効果的でした。特に「実装時に判明した注意点」は仕様書だけでは絶対にわからない情報なので、テスターにとって「どこを重点的に見ればいいか」が明確になります。
フィードバックループが回った
全タスクを回した最大の収穫は、ワークフロー自体が改善提案を出してくれたことです。
/add-featureの最終ステップでは、各タスクの振り返りが記録されます。総合テストの振り返り分析ステップで、これらを横断的に集約してフィードバックレポートを自動生成しました。中身は「設計書にリライトルール記載がなかった」「フィールド名の食い違いが発生した」といった、複数タスクで繰り返し発生した問題の一覧です。
各タスクの振り返り → 総合テストで集約 → フィードバックレポート → 改善
このフィードバックは2つの方向に反映されます。1つはスキル自体の改善。設計段階でのチェック項目追加、実装前の実態照合ステップ新設など、ワークフローの仕組みを強化します。もう1つはプロジェクト固有の改善。CLAUDE.mdやRulesへの追記提案として、そのプロジェクトに必要なルールを補強します。
「推測」ではなく「実際に痛い目を見た問題」からの改善なので、的確にワークフローの弱点を補強できます。そして次の案件でまた回せば、新たなフィードバックが出てくる。使えば使うほどワークフローが良くなる仕組みです。
総合テストで見えた「前工程で潰せた問題」
総合テストのコードレビューでいくつかの指摘が出ましたが、分析してみると、大半は各機能の完了時に検出すべきものでした。
原因は、開発ガイドラインのチェック項目が足りていなかったことです。各機能の実装検証や自動テストで拾う基準が粗く、すり抜けていました。
この気づきから、チェック項目をルールとガイドラインに追加しました。各機能完了時のチェック精度を上げれば、総合テストには「機能間連携」や「全体整合性」といった本来の役割だけが残ります。
総合テストを「軽くする」のではなく、前工程で潰し終わっているから結果的に軽くなる。最後の砦としての役割はそのままです。
結果を支えた仕組み
実案件で品質が安定した背景には、運用を続ける中で個々のスキルが繋がっていったことがあります。
設計からテストまで繋げる
前編の「コーディング規約の適用忘れ」で紹介した、スキルを明示的に呼び出さないと適用されない問題と同じ構造が、ドキュメント更新やテストにもありました。結局、個別にやっていると忘れるので、全部ワークフローに組み込みました。
/add-featureのステップにリファクタリングチェックを組み込み、実装直後にコード品質チェックが自動で走ります。仕様駆動によらない小さな修正には/review-quickで軽量レビューも可能です。
リファクタリングスキル自体も、Claude Code標準のsimplifyスキル（3並列エージェントによる分析・修正）をベースに刷新しました。自前で分析ロジックを持つより、標準スキルに委譲してプロジェクト固有の役割だけを持つ方が、保守性も品質も高いという判断です。
ドキュメントの鮮度維持も同様です。実装中に仕様変更が発生したとき、どのドキュメントに影響するかを見落としがちです。update-docsスキルがGit差分から変更点を検知し、影響するドキュメントを特定して更新を提案します。
テスト仕様書との連携も追加しました。実装完了時にチェックポイント（変更点サマリー、テスト観点、境界値候補）を出力し、それを基にテスト仕様書を作成。/review-test-specで機能設計書と突合せし、テストケースの漏れを検出します。
こうして、設計→実装→品質チェック→ドキュメント更新→テスト仕様書作成→レビューという一連の流れが繋がりました。
外部設計書と「人が手直しする」意味
外部設計書（機能仕様書）のベースを自動生成するスキルも作りました。PRDや既存コード、手書きのメモなどから画面設計書のベースを作成します。
ここで重要なのは、AIが作ったベースを人が手直しするというフローです。
「AIが作るなら手直し不要では？」と思うかもしれません。しかし、人が手直しすることに大きな意味があります。ベースを直す過程で仕様を自分のものにできるからです。仕様を理解している人がいれば、制作への指示が具体的になり、実装中の「これ合ってる？」にも答えられます。
もしAIに丸投げしたら、一見それっぽいものが出てきますが、誰も中身を理解していません。実装で問題が起きても「何が正解か」を判断できなくなります。
AIが「ゼロから書く」負担を減らし、人が「正しく直す」。この分担がチーム全体の品質を底上げします。
まとめ
前後編を通じて、仕様駆動AI開発のワークフローをチームで構築し、実案件で回した結果を紹介しました。
このワークフローの一番のポイントは、個人の力量やClaude Codeの習熟度に関係なく、チーム全体で同じ品質・同じワークフローで開発できることです。Rulesの自動適用とコマンド化で品質基準が統一され、PRD・設計書・作業記録がプロジェクトに残るので属人化しません。フィードバックループがスキルとプロジェクトの両方を改善し、チームで使い続けるほどワークフローが育っていきます。
AIは漏らさないけど判断できない。人は判断できるけど漏らす。だからAIが土台を作り、人が判断して直す。それでも漏れたものは、ワークフローの後続ステップやフィードバックループが拾ってくれる。完璧な人間も完璧なAIもいないけど、組み合わせで一定のクオリティを担保する。それがチームで仕様駆動AI開発を回す意味です。
仕様駆動AI開発の考え方やスキルの設計思想を理解するには、ぜひ書籍を読んでみてください。
