実践Claude Code入門に出てくるスペック駆動開発を整理してみた。

実践Claude Code入門に出てくるスペック駆動開発を整理してみた。

概要

『実践 Claude Code 入門』に出てくる スペック駆動開発 について、自分の学習・復習用のメモとしてまとめました。

https://www.amazon.co.jp/dp/4297153548

かなり実践的で、明日からでも開発に取り入れられそうな内容だったので、後で見返せるように要点を整理して残しておきます。

---

スペック駆動開発要点まとめ

このプロジェクトで使用している コマンド / スキル / エージェント の仕組みと、初回セットアップ〜機能開発までの実装フローを「最短で理解する」ための要点。

1. 全体像

3つの柱

• コマンド：ユーザーが叩く入口。ワークフロー全体を制御
• スキル：ドキュメント作成テンプレート/ガイド（専門知識のロード単位）
• エージェント：自律的にレビュー/検証するサブエージェント

┌─────────────┐
│  コマンド     │  ← 入り口（ワークフロー制御）
└──────┬──────┘
│ Skillをロード
v
┌─────────────┐
│   スキル      │  ← テンプレ/ガイドで資料生成
└──────┬──────┘
│ Agentを起動（必要に応じて）
v
┌──────────────┐
│  エージェント  │  ← レビュー/検証（品質保証）
└──────┬────────┘
v
📄 docs/*.md / .steering/* / 実装コード

---

2. 開発フロー

A) セットアップ：永続ドキュメントを固めていく（/setup-project(例)）

• docs/ideas/ を入力にして、**プロジェクト全体の仕様（永続）**を作る
• PRDのみユーザー承認、それ以降は自動で連鎖生成

B) 機能開発：作業単位のステアリングで実装する（/add-feature(例)）

• .steering/ に 今回の要求・設計・タスクを作る
• tasklist を完全消化し、検証→テスト→振り返りまで自動実行

---

3. 実装の流れ

3.1 初回セットアップ（/setup-project(例)）

要点

• PRDだけ承認、以降は自動
• 6つの永続ドキュメントを生成

---

3.2 機能開発（/add-feature 機能名）

要点

• ユーザー介入なしで走り切る（完全自動実行）
• 品質保証 = エージェント検証 + 自動テスト
• 作業の履歴は .steering に残る

---

4. コマンド / スキル / エージェントの役割（要点）

4.1 コマンド（Commands）

• 入口（ユーザー操作のトリガー）
• 何を読んで、どのスキル/エージェントを呼び、何を出力するかを決める

代表：

• /setup-project：永続ドキュメントを生成（PRD承認あり）
• /add-feature [機能名]：ステアリング作成→実装→検証→テスト→振り返り
• /review-docs [パス]：doc-reviewer による品質レビュー

---

4.2 スキル（Skills）

• テンプレ + ガイド + 前提条件 をセットにした「資料生成ユニット」
• 出力先（docs など）が明確で、フォーマットが揃う

構造：

.claude/skills/[skill]/
  SKILL.md
  template.md
  guide.md

代表スキル：

• prd-writing → docs/product-requirements.md
• functional-design → docs/functional-design.md
• architecture-design → docs/architecture.md
• repository-structure → docs/repository-structure.md
• development-guidelines → docs/development-guidelines.md
• glossary-creation → docs/glossary.md
• steering → .steering/*/（計画・振り返り）

---

4.3 エージェント（Agents）

• 自律的に レビュー / 検証 して品質を担保する役
• 人がやるとブレる/だるいチェックを固定観点でやる

代表：

• doc-reviewer：完全性/明確性/一貫性/実装可能性/測定可能性でレビュー
• implementation-validator：仕様との整合・コード品質を検証

---

5. 永続ドキュメントと作業ドキュメント

永続ドキュメント（docs/）

• プロジェクト全体の「何を作るか」
• 長期間参照される（仕様の軸）
• 更新頻度：中

例：

• PRD、機能設計、アーキテクチャ、ガイドライン、用語集

作業ドキュメント（.steering/）

• 今回の作業の「何をするか」
• 作業ごとに増える（履歴として保持）
• 更新頻度：高

例：

• requirements.md / design.md / tasklist.md（＋振り返り）

---

6. ディレクトリ構造

全体（主要フォルダのみ）

.
├── .claude/            # Claude Code設定（コマンド/スキル/エージェント）
│   ├── commands/
│   ├── skills/
│   └── agents/
├── docs/               # 永続ドキュメント（仕様の軸）
│   ├── ideas/
│   └── *.md
├── .steering/          # 作業単位のドキュメント（履歴）
│   └── YYYYMMDD-*/     # requirements/design/tasklist
├── src/                # 実装コード
├── CLAUDE.md           # プロジェクトメモリ
└── README.md

早見表

見たいもの	まず見る場所
プロジェクトの仕様（基準）	docs/*.md
直近作業の要求・設計・タスク	.steering/<日付-機能>/
コマンドの流れ	.claude/commands/
ドキュメントの作り方（テンプレ/ルール）	.claude/skills/
レビュー観点/検証ロジック	.claude/agents/

---

7. 感想

これまでも、コマンドで資料を作ったり、実装用・レビュー用・調査用のエージェントを作って動かしたり、永続化するために出力、といったことはやっていました。

ただ、今回の「スペック駆動開発」のように、スキル（テンプレート + ガイド）を前提にしてドキュメントを生成し、それをコマンド実行の一連の流れとして回して自動化！
いったところまでやれていませんでした。

このやり方を取り入れると、

• ドキュメントがテンプレートに沿って出力される
• 仕様書の書き方が統一される
• 作業単位の履歴（.steering）と、永続仕様（docs）が分離される

ので、長期で運用したときに効いてくる感じがします。1回の作業が「成果物（ドキュメント）」として積み上がるのが強い。

実務の中ではコードを慎重にレビューしたり、検証することが必要そうですが、資料作りの自動化とかはすぐに取り入れることができそう。

一方で、Claude Code の使い方自体が、体感として プログラミング言語を1つ学ぶくらいのスキルだなとも思いました。理解して、手に馴染ませて、身体化しないと回せない。

実務だけですべて慣れるのは難しいので、普段から小さくてもこの型で開発して、試行回数を増やした方が良さそうです。今は「作りたいものさえあれば作れる」時代になってきたので、アイデアが浮かんだら放置せず、形にしていくことでスキルも積み上がる。

「これ作った方が良くね？」みたいな違和感や興味を逃さないように、アンテナを張っておきたいと思いました。