ゼロトピック（Zero Topic）の #337「Claude Code時代の仕様書の役割」 が話題になっている。10X の矢本氏が、生成 AI が開発プロセスに与える影響と、仕様書の役割がどう変わるかを整理した回だ。
バイブコーディングの限界と仕様駆動開発
Claude Code のようなAIコーディングエージェントの登場で、コード生成速度は飛躍的に向上した。しかし「バイブコーディング」— AI に任せて探索的にコードを生成するアプローチ — には問題がある。
- 検証負債の蓄積: AI の生成速度が人間の理解・検証速度を上回る
- 意図不明なコード増殖: 内部構造を精査せず先に進み、誰も理解していない領域が広がる
- デバッグ困難化: コードの意図が不明では根本原因の特定が難しい
こうした課題に対する解が 仕様駆動開発（Spec-Driven Development: SDD） だ。Thoughtworks Technology Radar Vol.32（2025年4月）で Trial に採用されたこの手法は、「仕様を先に定義し、その仕様に基づいて AI にコードを生成させる」という原則に立つ。
仕様書の役割の変化
従来の設計書は人間同士のコミュニケーションツールだった。AI との協働では「AI への指示書」としての側面が加わる。
SDD における仕様書の構成は、Kiro が提唱する3層モデルが分かりやすい:
| ファイル | 役割 |
|---|---|
requirements.md | ユーザーストーリーと受け入れ基準 |
design.md | アーキテクチャ、シーケンス、設計上の注意 |
tasks.md | 実装計画とタスク分解 |
重要なポイントは、仕様は 「唯一の情報源（Single Source of Truth）」 として機能し、プロセス駆動はルールブック（プロセスルール）が別途担当するという区別だ。
Claude Code での実践
基礎レベル: CLAUDE.md + ステアリングファイル
CLAUDE.mdに制約・規約・コンテキストを定義.steering/配下に作業バッチフォルダを作成- 要件定義書・設計書・タスクリストを生成・保存
- タスクに沿ってコード生成・テスト実施
応用レベル: カスタムコマンドの活用
2026年1月に plansDirectory 設定が追加され、/plan モードで作成した計画書を Git 管理できるようになった。さらにカスタムコマンドを使えば、ドメイン知識を埋め込んだ独自のワークフローを構築できる。
例えば /feature-plan のようなコマンドで、以下を自動生成する:
- plan.md: 設計判断と代替案検討
- action-plan.md: 実装ステップと対象ファイル
意図と実装の齟齬を事前に検知でき、セッション中断時の進捗追跡も容易になる。
高度なレベル: AI-DLC ワークフロー
AI-DLC（AI Development Life Cycle）は、仕様駆動開発をエンタープライズ規模で運用するためのフレームワークだ。バイブコーディングが生む「検証負債」— 技術的負債とは異なり、そもそも何が問題なのかわからないまま積み上がった構造 — を防ぐことを目的としている。
フェーズと承認ゲート
ワークフローは INCEPTION（計画） と CONSTRUCTION（実装） の2大フェーズに分かれ、全14ステージのうち13ステージに人間の承認ゲートが設けられている。各ステージは DO NOT PROCEED until user confirms の制約で、AI が勝手に先に進むことを防ぐ。
中核ファイル構成
| ファイル | 役割 |
|---|---|
core-workflow.md | ワークフロー定義。Requirements → Design → Tasks → Code の順序制約をフレームワークレベルで固定 |
aidlc-state.md | 現在フェーズ・完了ステージ・保留タスクなどの進捗状態を記録 |
audit.md | ユーザー入力と AI 応答をタイムスタンプ付きで原文記録。監査証跡として機能 |
二層構造ルールブック
aws-aidlc-rule-details/ ← ベースレイヤー（標準、変更不可）
ga-aidlc-rule-details/ ← 拡張レイヤー（組織カスタマイズ）
ベースレイヤーはフレームワークの標準プロセスを定義し、拡張レイヤーで業界固有の規制要件や社内の品質基準を追加する。標準プロセスを壊さずにカスタマイズできる設計だ。
Adaptive Depth（深度調整）
タスクの複雑度に応じて、プロセスの重さを3段階で自動調整する:
- Minimal: 小規模な修正。最小限の仕様で素早く実装
- Standard: 通常の機能開発。標準的な仕様書一式を作成
- Comprehensive: 大規模・高リスクな変更。包括的な検証と詳細な監査証跡
「仕様駆動開発は重い」という批判に対し、タスクに合わせてプロセスが伸縮する仕組みで応える。
実践のポイント
仕様駆動開発を始めるのに、新しいツールの導入は必須ではない。Claude Code の標準機能と CLAUDE.md だけで小さく始められる。
- まず
CLAUDE.mdを書く — プロジェクトの制約と規約を明示する - 仕様を先に定義する — コードを書く前に要件・設計・タスクを文書化する
- 計画書を Git 管理する —
plansDirectoryで計画書を永続化する - 段階的に高度化する — チームの成熟度に応じてワークフローを進化させる
AI が高速にコードを生成する時代だからこそ、「何を作るか」を仕様として明確にすることが品質保証の基本になる。ゼロトピック #337 は、この考え方を16分で整理して伝えてくれる好エピソードだ。