CLAUDE仕様駆動ワークフロー

Claudeによるコード生成は十分に高速なため、ボトルネックはもはやタイピングではない。ボトルネックは、Claudeが書く前に正確に何を求めているかを知ることだ。仕様駆動ワークフローは思考を前倒しするため、実装フェーズは探索ではなく実行になる。

Claudeとの連携がうまくいくチームは、AI ツールが存在する前から仕様規律を構築していたチームだ。苦労しているチームは、Claudeに「これを何とかしろ」と言わせることで仕様をスキップしようとするチームだ。

問題をClaude に3～4文で説明する。次に、その答えが設計を変えるであろう5つの質問を表面化させるようClaudeに頼む。それに答える。その後、結果として得られた製品仕様を200語で要約するようClaude に頼む。

このステージは30〜60分かかり、その後の作業全体の基盤となる書面仕様書を生成します。5つの質問は、通常であればコードに直進する際にスキップしてしまう内容ですが、ブレインストーミングステージを通じてそれらを浮き彫りにすることが、全体の価値です。

仕様書を手に、Claudeに下流での影響度が最も大きいアーキテクチャの選択肢を特定するよう依頼します。データベース設計、APIサーフェス、レンダリング戦略、デプロイメントモデルです。それぞれについて、Claudeはトレードオフを含む2〜3つの選択肢を提案します。

私が選択します。決定は同じドキュメントに記録されるため、ビルドフェーズは単一の情報源を持ちます。このステージで下した決定は、実装中に発見される決定よりも修正コストが10分の1です。

コード生成は最後のステージで、仕様書が既に完成しているため最も高速です。Claudeはスキーマ、クエリ、コンポーネント、ルート、テストを大体この順序で書きます。私はコミット毎にレビューします。

ほとんどのレビューでは小規模なリファクタリングまたは見落とされたエッジケースが浮かび上がります。仕様書が明確であれば、フルリライトは稀です。このペースは、ゼロからのエンジニアリングと比較して2〜5倍高速です。

ブレインストーミングからリリースまでの間に3つのレビューゲートがあります。

仕様書ゲート：コード記述前に、200語の仕様書が最初から最後まで読まれます。曖昧な点は明確化され、希望的観測は削除されます。

アーキテクチャゲート：データベースマイグレーションが実行される前に、アーキテクチャの決定がスペックに対してレビューされます。スペックに適さないものは再検討されます。

コミットゲート：Claude が作成したすべてのコミットは、マージ前に人間によるレビューを受けます。このレビューはコードを自分で書くよりも高速ですが、スキップすることはできません。Claude は自身のプルリクエストを承認しません。

既知のものを構築するのではなく、何が可能であるかを学ぶことが目標である探索的または研究ベースの作業。これらの場合、スペックの段階では Claude を不当に制約する曖昧なスペックが生成されます。代わりに、具体的な成果物を伴う反復的なチャットが適切なパターンです。

原因が不明なバグ修正。スペックの段階は目的地を知っていることを前提としています。デバッグは現在地を把握することです。デバッグの場合は、系統的なデバッグパターン（再現、分離、診断、修正）にまっすぐ進み、スペックをスキップしてください。

すべての反復が小さく、視覚的なフィードバックがシグナルである UI ポーランド。これらの場合、ホットリロードとサイドバイサイド diff を備えた Cursor 内の Claude が、記述されたスペックではなく、適切なツールです。