Claude Code時代の仕様書の役割 — ゼロトピック #337 から考える仕様駆動開発

ゼロトピック（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分で整理して伝えてくれる好エピソードだ。