Claude Codeタスク管理・Agent Teams時代にSDDツールは必要か
この記事について
対象読者: Claude Code、Cursor、GitHub CopilotなどのAIコーディングアシスタントを使っている開発者で、「SDD（仕様駆動開発: Spec-Driven Development）ツールって必要？Planモードで十分じゃない？」と感じている方
この記事を読むと: Claude Code標準機能（Planモード・タスク管理・Agent Teams）でどこまでカバーできるかを理解し、SDDツールが本当に必要な場面を見極められるようになります
SDDツールとは
SDD（仕様駆動開発: Spec-Driven Development）ツールとは、AIコーディングアシスタントに「いきなりコードを書かせる」のではなく、まず仕様ドキュメントを作成し、それに基づいて実装を進めるワークフローを提供するツール群です。OpenSpec、GitHub Spec Kit、Kiroなどが代表的なツールで、2025年後半から急速に広がっています。
Claude Code標準機能の進化
Claude Codeには「まず計画を立ててから実装する」ための機能がすでに備わっています。SDDツールを検討する前に、標準機能でどこまでできるかを整理しましょう。
Planモード
- AIがコードベースを探索し、計画をファイル（plan.md等）に書き出す
- ユーザーが計画を確認・修正してから実装に進む
-
Shift+Tab×2 で切り替え、Ctrl+Gでプランを直接編集可能 -
--continue/--resumeでセッション再開が可能
タスク管理システム（v2.1.16〜）
Claude Code v2.1.16で導入されたタスク管理システムは、SDDツールの守備範囲にかなり近づいています。
- TaskCreate / TaskGet / TaskList / TaskUpdate の4つのツールでタスクを管理
- タスクに依存関係を設定でき、前提タスク完了まで自動ブロック
-
CLAUDE_CODE_TASK_LIST_ID環境変数で複数セッション間でタスクリストを共有 - 複数ターミナルでタスクを分担し、並列実行が可能
# 複数セッションで同じタスクリストを共有
CLAUDE_CODE_TASK_LIST_ID=my-feature claude
これにより、「セッションをまたいだ進捗管理」や「タスクの並列実行」といった、以前はSDDツールでしかできなかったことが標準機能で実現可能になっています。
Agent Teams（実験的機能）
さらに最近追加されたAgent Teamsは、リードエージェントが複数のチームメイトを起動し、並列で作業を進める仕組みです。
// settings.json で有効化（split panesモードも一緒に設定）
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1",
"CLAUDE_CODE_SPAWN_BACKEND": "tmux"
}
}
split panesモードでのAgent Teams。リード（@main）が調査完了後に@implementerと@testerを起動し、並列で作業を進めている
- リードエージェントがタスク分割・割り当て・結果統合を担当
- 各チームメイトは独立したコンテキストウィンドウを持つため、コンテキスト圧迫の問題を回避できる
- チームメイト同士が直接メッセージで連携可能（サブエージェントとの違い）
-
Delegateモード（
Shift+Tabで切り替え）でリードを調整専任にし、実装はすべてチームメイトに委譲できる - タスクの依存関係を自動管理し、ブロック解除も自動
-
表示モード: in-process（1ターミナル内で
Shift+↑↓で切り替え）とsplit panes（tmux / iTerm2で各チームメイトを別ペインに表示）の2種類。CLAUDE_CODE_SPAWN_BACKEND環境変数で指定可能
| サブエージェント | Agent Teams | |
|---|---|---|
| コンテキスト | 親セッションに結果を返す | 各自独立したコンテキスト |
| 通信 | 親にのみ報告 | チームメイト間で直接通信 |
| 適性 | 結果だけ必要なフォーカスタスク | 議論・協調が必要な複合タスク |
| コスト | 低い | 高い（各チームメイトが別インスタンス） |
サブエージェントの永続メモリ
サブエージェントにmemoryフィールドを設定することで、会話をまたいで知識を蓄積する永続メモリが利用できるようになりました。コードベースのパターン、デバッグの知見、アーキテクチャの判断などを.claude/agent-memory/<agent名>/に書き出し、次回以降のセッションで自動的に読み込みます。
# サブエージェント定義（.claude/agents/code-reviewer.md のfrontmatter）
---
name: code-reviewer
description: Review code for quality and best practices
memory: project
---
| スコープ | 保存先 | 用途 |
|---|---|---|
user |
~/.claude/agent-memory/<agent名>/ |
全プロジェクト共通の知識 |
project |
.claude/agent-memory/<agent名>/ |
プロジェクト固有（バージョン管理可能） |
local |
.claude/agent-memory-local/<agent名>/ |
プロジェクト固有（バージョン管理しない） |
サブエージェントのシステムプロンプトに以下のような指示を含めることで、能動的に知識をアップデートさせることができます：
Update your agent memory as you discover codepaths, patterns, library
locations, and key architectural decisions. This builds up institutional
knowledge across conversations. Write concise notes about what you found
and where.
これにより、SDDツールの強みの1つだった「設計判断の永続的な記録」に近い機能が、Claude Code標準のサブエージェント機構でも実現可能になりつつあります。
ここまでの標準機能で何ができるか
Planモード + タスク管理 + Agent Teams + 永続メモリの組み合わせで、Claude Codeの標準機能はかなり強力になっています。
Planモード → 計画の立案とファイルへの書き出し
タスク管理 → 複数セッションでの進捗管理と依存関係
Agent Teams → 並列実行とコンテキスト分離
永続メモリ → セッションをまたいだ知識の蓄積
標準機能でも「何を・なぜ作るか」を計画段階で扱うことはできます。Planモードのplan.mdに設計理由を書くことも、タスク管理で進捗を追うことも、永続メモリで知見を蓄積することも可能です。
それでもSDDツールが活きる場面
SDDツールの本質的な価値は、設計判断を構造化して永続的に残し、チームで共有・検証できる点にあります。
1. 仕様の構造化と関心の分離
Planモードのplan.mdにも「なぜやるか」「どう作るか」は書けます。ただし1つのフラットなファイルなので、「要件だけレビューしたい」「設計を変えてタスクを再生成したい」といった部分的な操作には向きません。
SDDツールでは、要件・設計・タスクが関心ごとに分離された複数のアーティファクトになります：
標準機能: plan.md（計画全体を1ファイルで管理）
SDDツール: 要件定義 → 技術設計 → タスク分解（関心ごとに分離）
この構造があることで、「要件はそのままで設計だけ見直す」「設計変更に応じてタスクだけ再生成する」といった部分的な操作が可能になります。
2. 設計判断の永続的な記録
Planモードの計画はセッションに紐づくため、完了後に参照しづらくなります。git historyを掘れば残っていますが、「3ヶ月前のあの設計判断の理由」を探すのは現実的ではありません。
サブエージェントの永続メモリで知見の蓄積は可能になりましたが、これはAIが自身の作業から学んだパターンや知識を保存する仕組みです。SDDツールは「要件→設計→タスク」という構造化された仕様ドキュメントをリポジトリ内に永続的に保存します。変更ごとにドキュメントが残るため、「なぜこの設計にしたか」を人間が後から追跡でき、新メンバーのオンボーディングにも役立ちます。
3. 仕様とコードの整合性検証
Claude Codeには「実装が仕様に沿っているか」を体系的に検証する仕組みはありません。SDDツールの多くは、仕様と実装の整合性をチェックする機能を提供しています。完全性（すべての要件が実装されているか）、正確性（設計通りに実装されているか）、一貫性（仕様間に矛盾がないか）といった観点での検証が可能です。
4. チーム（人間）での仕様共有
Agent TeamsはAIエージェント間の協調です。一方、SDDの仕様ドキュメントは人間のチームメンバー間での共有に強みがあります。PRレビューで「なぜこの設計にしたか」を仕様ドキュメントで参照できること、設計レビューを要件レビューと分離して行えることは、SDDならではの利点です。
使い分けの目安
| 状況 | 推奨 |
|---|---|
| 1セッションで完結する変更 | Planモードで十分 |
| 複数セッション・並列実行が必要 | タスク管理 / Agent Teamsで対応可能 |
| 大規模で独立性の高い並列タスク | Agent Teamsが効果的 |
| 仕様・設計の構造化と履歴管理が必要 | SDDツール推奨 |
| 設計判断を後から振り返りたい | SDDツール推奨 |
| 人間のチームで仕様を共有・レビューしたい | SDDツール推奨 |
| バグ修正や小さなリファクタリング | Planモードで十分（SDDは過剰） |
SDDツールの比較
SDDが必要だと判断した場合、どのツールを選ぶべきでしょうか。2025年後半から2026年にかけて、複数のSDDツールが登場しています。
OpenSpec（⭐ 22.7k）
OpenSpecは、デルタ仕様と柔軟なワークフローが特徴の軽量フレームワークです。
- アプローチ: デルタ仕様（変更差分のみ記述）
- 対応ツール: 22種（Claude Code, Cursor, GitHub Copilot 等）
- ワークフロー: proposal → specs → design → tasks（順序変更・スキップ可）
-
特徴:
- 「Fluid not rigid」— フェーズゲートなし
- 並行開発（changes/フォルダで複数変更を管理）
- アーカイブ機能（タイムスタンプ付きで履歴保存、デルタ仕様の自動マージ）
- 既存コードベースに強い（Brownfield-first）
詳しい使い方は「OpenSpec実践ガイド」を参照してください。
cc-sdd（⭐ 2.5k）
cc-sddは、Kiroスタイルのコマンド（/kiro:*）で仕様駆動開発を行うNPMパッケージです。
npx cc-sdd@latest --claude --lang ja
- ワークフロー: requirements → design → tasks → 実装
- 対応ツール: 8種（Claude Code, Cursor, Gemini CLI, Codex CLI, GitHub Copilot, Qwen Code, OpenCode, Windsurf）
-
特徴:
- EARS形式の要件定義を採用
-
.kiro/ディレクトリに仕様を配置 - 13言語対応（日本語含む）
- テンプレートカスタマイズ可能
- Spec-firstを厳格に強制（承認後に実装を開始）
Agent OS（⭐ 3.7k）
Agent OSは、コードベースの標準管理と仕様作成を組み合わせた**「標準に基づくSDD」システム**です。
- 4つの機能: Discover Standards → Deploy Standards → Shape Spec → Index Standards
- 対応ツール: Claude Code, Cursor, Antigravity 等
-
特徴:
- 既存コードからパターン・規約を自動抽出してドキュメント化
- 作業コンテキストに応じて関連する標準をAIに自動注入
- Shape Specで標準に基づいた仕様を作成し、より良い実装計画を生成
- 「AIが自分（開発者）のやり方で作る」ことにフォーカス
GitHub Spec Kit（⭐ 68.1k）
GitHub Spec Kitは、GitHub公式のSDD向けCLIツールキットです。
- ワークフロー: Specify → Plan → Tasks → Implement（4段階ゲート式）
- 対応ツール: GitHub Copilot, Claude Code, Gemini CLI
-
特徴:
- Constitution（憲法） で不変の原則を定義
- Research Agentによるコンテキスト自動収集
- ブランチング探索（複数の実装アプローチを比較検討）
- 最もカスタマイズ性が高いが、生成されるドキュメントが冗長になりやすい
Kiro（IDE — 非公開リポジトリ）
Kiroは、AWSが提供するSDD機能を内蔵した専用IDE（VSCodeフォーク）です。
- ワークフロー: Requirements → Design → Tasks（IDE内蔵）
-
特徴:
- IDE自体にSDD機能が統合されている
- Agent Hooks（ファイル保存時等のイベント駆動自動化）
- Vibe CodingモードとSDD両対応
- 最も手軽に始められるが、IDE自体の切り替えが必要
比較表
| 観点 | OpenSpec | cc-sdd | Agent OS | Spec Kit | Kiro |
|---|---|---|---|---|---|
| GitHub ⭐ | 22.7k | 2.5k | 3.7k | 68.1k | ―（IDE） |
| アプローチ | デルタ仕様 | Kiro式厳格SDD | 標準+仕様作成 | ゲート式SDD | IDE統合SDD |
| ワークフロー厳格さ | 低（スキップ・順序変更可） | 高（承認ゲート必須） | 低（標準注入が主） | 高（4段階チェックポイント） | 中〜高（IDE内で順序管理） |
| 出力の重さ | 中（4ファイル/変更） | 中（3ファイル/変更） | 軽（標準ドキュメント） | 重（8+ファイル/仕様） | 中（3ファイル/変更） |
| 既存コードベース | ◎ | ○（steering） | ◎ | △ | △ |
| 対応ツール数 | 22種 | 8種 | 汎用 | 3種 | Kiro専用 |
| セットアップ | npm install |
npx |
Shell | CLI | IDE導入 |
| アーカイブ/履歴管理 | ◎（自動マージ+タイムスタンプ保存） | ― | ― | △（議論中） | ― |
| 日本語対応 | ― | ◎（日本人開発、テンプレート・出力の日本語品質が高い） | ― | ― | ― |
| 得意なプロジェクト | 既存コードへの機能追加 | 厳格な品質管理が必要な開発 | コーディング規約の統一 | 新規プロジェクトの包括的仕様策定 | SDD入門・手軽に始めたい |
| 学習コスト | 低〜中 | 低 | 低 | 中〜高 | 低 |
どのツールを選ぶべきか
| シナリオ | 推奨ツール |
|---|---|
| 既存の大規模コードベースに新機能を追加したい | OpenSpec（デルタ仕様でBrownfield対応） |
| Kiro風の厳格なワークフローを好むが、IDEは自由に選びたい | cc-sdd |
| コーディング規約をAIに守らせたい（仕様管理というより標準管理） | Agent OS |
| GitHub Copilotメインで公式ツールを使いたい | GitHub Spec Kit |
| IDEごと新しい開発体験に移行してよい | Kiro |
SDD全般の注意点
Martin Fowlerの記事やThoughtworksの分析では、SDD全般に対する以下の懸念が指摘されています：
- ドキュメント過多 — 特にSpec Kitは冗長になりやすく、Markdownを読む時間が増える
- スケーラビリティの問題 — 小さなバグ修正にSDD全体のフローを回すのは過剰
- AIの準拠問題 — エージェントが仕様を無視したり、逆に過剰に従ったりする場合がある
- MDD（モデル駆動開発）との類似性 — 「硬直性＋非決定性」の組み合わせに対する警鐘
OpenSpecの「Fluid not rigid」「Easy not complex」という設計原則は、これらの懸念に対する1つの回答と言えます。とはいえ、すべてのタスクにSDDが必要なわけではないという認識は、どのツールを使う場合でも重要です。
まとめ
AIコーディングの仕様管理は、以下の3層で整理できます：
| 層 | 担うもの | 手段 |
|---|---|---|
| 計画・実行管理 | 何を・どう進めるか | Planモード、タスク管理、Agent Teams |
| 知識の蓄積 | AIが学んだパターンや知見 | サブエージェント永続メモリ |
| 仕様の永続化・検証 | 構造化された設計判断の記録と共有 | SDDツール（OpenSpec, cc-sdd, Spec Kit 等） |
| 標準管理 | AIがどう振る舞うべきか | Agent OS, CLAUDE.md, カーソルルール |
すべてのプロジェクトにSDDが必要なわけではありません。 1セッションで完結する変更ならPlanモードで十分ですし、並列実行が必要ならタスク管理やAgent Teamsで対応できます。
SDDツールの価値が出るのは、設計判断を構造化して永続的に残し、チームで共有・検証したい場面です。1セッションで完結する変更ならPlanモードで「何を・なぜ」まで十分カバーできますが、大きな変更で設計の経緯を後から追いたい場合にはSDDの構造が活きてきます。
まずは自分のプロジェクトの規模とチーム体制を見て、適切なレイヤーから始めてみてください。
参考リンク
Claude Code標準機能
SDDツール
- OpenSpec 公式リポジトリ / 公式サイト
- OpenSpec実践ガイド — セットアップからワークフローまでの実践解説
- cc-sdd — Kiroスタイルの仕様駆動開発フレームワーク
- Agent OS — コードベース標準の管理・注入システム
- GitHub Spec Kit — GitHub公式のSDD向けツールキット
- Kiro — AWSのSDD統合IDE
Discussion