スペック駆動開発をClaudeと考えてみた｜自然言語→スペック→実装の流れ
この記事でわかること
- スペック駆動開発って何だっけ？
- スペックの「具体的な形」
- スペック ≠ プロンプトエンジニアリング
- 制作会社でのリアルな使い方
- 自然言語→スペック→実装のループ
- まとめ
「スペック駆動開発」という言葉、書籍でよく見かけるけど抽象的でピンとこない——そんなモヤモヤをClaudeと一緒に整理してみた。
スペック駆動開発って何だっけ？
一言でいうと「実装の前に仕様（スペック）を明確に定義してから作る」アプローチ。
でもそれだけだと「当たり前では？」と思うかもしれない。実は制作現場でこれが抜けることが多くて、それが手戻りの温床になっている。
よくある失敗パターンはこんな感じ：
- クライアント：「SNS連携できる会員管理システム作ってよ」
- エンジニアA：「TwitterとGoogle対応しとこ」
- エンジニアB：「UIはMaterial Designにしよう」
- クライアント：「え、Facebookはないの？UIのイメージと違う…」
→ 修正祭り・工数追加・納期延長
スペックを先に定義して確認を取れば、このループはかなり防げる。
スペックの「具体的な形」
書籍によく出てくる説明は抽象的なので、実際の形に落とすとこうなる。
曖昧なスペック（NG例）
「Obsidianの日次ノートから自動的にWordPressの下書き記事を生成する」
これだとどのセクション？タグは？失敗したら？がすべて曖昧。
明確なスペック（OK例）
入力:
ファイルパス: ~/Obsidian/Daily/YYYY-MM-DD.md
抽出対象: ## 📌 今日の気づき セクション
出力:
API: POST /wp-json/wp/v2/posts
ステータス: draft
タグ: #tag から自動抽出
エラーハンドリング:
ファイルなし → 処理停止・ログ出力
セクションなし → 処理停止
API 401 → 停止
タイムアウト → 3回リトライ（5秒待機）
「誰が読んでも同じものを作れる」状態になって初めてスペックといえる。
スペック ≠ プロンプトエンジニアリング
これは混同しやすいポイント。
| スペック | プロンプト | |
|---|---|---|
| 目的 | 何をするかを定義 | AIに何をさせるかを指示 |
| 対象 | 人間にもAIにも通じる | 特定のAIツール向け |
| 寿命 | 再利用・更新して使い続ける | 1回きりのやりとり |
| 活用先 | 実装・テスト・ドキュメント・次プロジェクトへ | そのセッション内のみ |
スペックは「元ネタ」で、プロンプトは「AI向けに翻訳したもの」。毎日繰り返す自動化なら、スペックを先に書いてからプロンプト化する流れが有効。
制作会社でのリアルな使い方
Claude Codeを使った制作会社の次世代フローはこんなイメージ：
クライアント（自然言語）
↓
Claude Code → スペック複数案を自動生成
- 機能要件・非機能要件
- APIスペック
- エラーハンドリング
- テストケース
↓
PM（確認・修正） ← ここが人間の価値
↓
クライアント承認
↓
Claude Code → 実装コード生成
スペック作成が1〜2週間 → 1〜2日に短縮できる可能性がある。PMの役割は「スペックを書く」から「スペックの品質を管理する」にシフトしていく。
自然言語→スペック→実装のループ
実際に動かしてみて気づいたのは、このフローが成立するということ：
- 自然言語で「こうしたい」と投げる
- Claude Codeが「こんなスペックですか？」と提案
- 「ここを直して」とフィードバック
- 確認後、実装→実行→結果報告
自分がやることは「説明と確認」だけ。スペック構築そのものをAIに委ねられる。
ただし注意点もある。AIは業界特有の要件（金融のコンプライアンスなど）を自力で補完できないし、詰め込みすぎたスペックを生成することもある。「ドメイン知識で見直す」人間の役割はなくならない。
まとめ
- スペック駆動開発 ＝「言った通りに作る仕組み」
- 大切なのは「何と言うか」——スペック自体の品質
- AIはスペック生成を加速できるが、要件の精度は人間が担保する
- 制作会社では「スペック作成」から「スペック品質管理」への役割シフトが起きつつある
Claude Codeを使う目的は「実装を速くする」だけじゃなく、「要件の曖昧さを減らす」ところにもある。そう考えると、ツールの使い方も少し変わってくるかもしれない。
