AI駆動開発の現在地（2/3）設計編 — 企画書から実装までのワークフローをどう設計するか

はじめに

前回の記事では、cc-sddとAgent Teamsの組み合わせが2026年3月時点での有力な選択肢であることを示しました。しかし、この2つを素朴に組み合わせると「企画書を全部分解→全Issue起票→順番に実装」というウォーターフォールになり、AI駆動開発の利点を活かしきれません。

本記事では、企画書から実装までのワークフローをどう設計するか、3つの懸念とその解決策、そしてアジャイルSDDという考え方を提案します。

シリーズ記事:

第1回: ツール編 — cc-sdd、takt、Agent Teams、Code Reviewは何が違うのか
第2回（本記事）: 設計編 — 企画書から実装までのワークフローをどう設計するか
第3回: 実践編 — GitHub Issue起点のアジャイルSDDパイプラインを構築する

素朴なアプローチとその問題点

cc-sddとAgent Teamsを組み合わせた最も素朴なワークフローは、こうなります。

企画書
  → Agent Teamsで全機能に分解
    → 全GitHub Issue起票
      → Issue単位でcc-sdd（仕様生成）
        → Agent Teamsで実装
          → 統合テスト

一見すると合理的ですが、3つの構造的な問題を抱えています。

問題1: 仕様書の膨張

cc-sddでは1つの機能仕様に対してrequirements.md、design.md、tasks.mdがそれぞれ単一ファイルとして生成されます。企画書全体を1つのスペックとして投入すると、requirementsだけで数十項目に膨れ上がり、AIの処理限界を超えます。

かといって「人間が機能単位に分割してから投入する」というのは、かなりのスキルが求められます。アーキテクチャの全体像を把握し、適切な粒度で分割し、依存関係を整理する——これこそ幅広い知見を持つAIにやらせたい仕事です。

問題2: Issue間の整合性

機能Aの仕様書と機能Bの仕様書が矛盾する問題です。cc-sddは「機能内」の整合性は保てますが、「機能間」の整合性を自動で保証する仕組みを持っていません。

例えば、機能Aのdesign.mdではユーザーIDをUUIDと定義したのに、機能Bではint型のAUTO_INCREMENTで定義してしまう。こうした食い違いは、個別にcc-sddを回すだけでは防げません。

問題3: 実装順序の信頼性

cc-sddが生成するtasks.mdは依存関係を考慮した順序になっていることが多いですが、完全には信頼できません。後の工程を終わらせないと完了しないタスクが前の工程に存在するケースが実際に報告されています。

さらに深刻なのは、大きめの機能を一気に依頼するとタスクが分解されても品質が低下する傾向があるという点です。

ウォーターフォールの罠

これら3つの問題の根底にあるのは、**「最も情報が少ない時点で、最も多くの決定をしている」**という構造的な問題です。企画書の段階では、技術的な制約も外部APIの挙動もわかっていません。それなのに全機能を分解し、全仕様書を作り、全タスクの順序を決めている。

これは紛れもなくウォーターフォールです。

「Phase 1を軽くする」という解決策

解決の方向性は明確です。最初に全部決めず、少しずつ作りながら設計を進化させる。

具体的には、企画書から最初に作るものを2つだけに絞ります。

1. 進化するアーキテクチャビジョン

完成形のarchitecture.mdではなく、現時点での方針を書いた薄いドキュメントです。技術スタック、データモデルの大枠、ディレクトリ構造の方針、認証方式など。

これは実装が進むたびに更新される前提のもの。cc-sddのsteering（.kiro/steering/）がまさにこの役割を果たせます。

2. 次にやる2〜3個のIssueだけ

企画書全体を20個のIssueに分解するのではなく、「まず最初に作るべきコア機能」を2〜3個だけ特定します。残りは後で決める。

アジャイルSDD: イテレーティブ開発ループ

この考え方を構造化すると、Planning → Build → Review & Learn の3フェーズからなるイテレーティブなループになります。

Planning（Agent Teamsで実施）

企画書（初回）または前サイクルの学び（2回目以降）をインプットに、Agent Teamsが以下を行います。

アーキテクチャビジョンの更新
次の2〜3 Issueの決定
依存関係と優先順位の整理

人間はAgent Teamsの成果物を確認し、承認・修正してからIssueを起票します。

Build（Issue単位のループ）

起票されたIssue（2〜3個）に対して、順番にcc-sddで仕様を生成し、承認を経て実装します。

Issue → cc-sdd（仕様生成）→ 人間承認 → 実装 + テスト → 次のIssueへ

Review & Learn（Agent Teamsで実施）

2〜3 Issueの実装が完了したら、Agent Teamsで振り返りを行います。

validate-gapで仕様と実装の乖離を確認
機能間の整合性チェック
steeringの更新
「何がわかったか」「次に何を変えるべきか」の明文化

このReview & Learnの結果が、次のPlanningサイクルのインプットになります。

ウォーターフォールとの決定的な違い

このループの核心は、「学び」が次のサイクルに反映されることです。

Issue 1〜3を実装してみたら「このデータモデルだと認証周りが複雑になりすぎる」とわかった。ウォーターフォールなら既に起票済みの残り17 Issueの仕様書を全部修正する羽目になります。

アジャイルSDD方式なら、次のPlanningサイクルでsteeringとarchitecture.mdを更新し、Issue 4〜6をその時点の最新知見で計画すればいい。まだ存在しないIssueの仕様書を修正する必要はありません。

MVPとの関係

「これはMVPのことですか？」という疑問が浮かぶかもしれません。近いですが、2つのループは異なる問いに答えるものです。

MVP的ループ（外側）: ユーザーからの学び

最小限の機能で → リリース → ユーザーの反応 → 方向転換？

問い: 「これはユーザーが本当に求めているものか？」サイクル: 数週間〜数ヶ月

イテレーティブ計画ループ（内側）: 実装からの学び

次の2〜3 Issueだけ計画 → 仕様化 + 実装 → 技術的な発見・課題 → steering更新

問い: 「この設計で次の機能も破綻しないか？」サイクル: 数時間〜数日

この2つは入れ子の関係にあります。内側のイテレーティブ計画ループが、外側のMVPループの中で何度も回ります。

企画書の確度が高い場合（何を作るかは決まっている）は、内側のループだけで十分です。企画書が仮説的な場合は、外側のMVPループも意識して、最初のサイクルで作るIssueを「ユーザー検証に必要な最小セット」にします。

cc-sddとの相性

「ミニウォーターフォールであるcc-sddとアジャイルは矛盾しないか？」

矛盾しません。cc-sddが「ミニウォーターフォール」なのは機能レベルの話です。スクラムでも1スプリント内ではrequirements→design→impl→testと順番にやります。

cc-sddが罠にはまるのは「プロジェクト全体を最初にcc-sddで仕様化しようとした時」です。それをやめて**「1サイクル2〜3 Issue分だけcc-sddを回す」**にすれば、cc-sddの強み（構造化された仕様、承認ゲート、validate-gap）を活かしつつ、アジャイルの強み（学習と適応）も得られます。

各PhaseでのAgent Teams構成

「Agent TeamsはPhase 1だけでいいのか」という問いに対する回答は、**「全Phaseで使うべきだが、チーム構成は変える」**です。

Phase 1: Planning — Agent Teams必須（3名構成）

エージェント	役割
Architect	共通基盤の抽出（データモデル、技術スタック、認証方式）
PM	機能分割と優先順位付け
QA	分割の検証（漏れ・矛盾の指摘）

複数視点の議論が分割品質を決定的に左右するフェーズ。ここでのミスは全後工程に波及するため、コスト対効果が最も高い。

Phase 2a: 仕様生成 — 単体で十分

cc-sddのrequirements→design→tasksという逐次的なワークフローは、1エージェントが順番に深掘りしていく構造に最適化されています。1つの頭脳が一貫して考えるほうが、1機能の仕様としてはまとまりが良い。

人間の開発でも、1機能の設計書は1人のリードが書くのが普通です。

Phase 2b: 実装 — Agent Teams有効（2〜3名構成）

エージェント	役割
Implementer	コード実装
Tester	テスト作成・実行
Reviewer	コード品質チェック

特にMaxプランでCode Reviewが使えない環境では、Reviewer役がCode Reviewの代替として重要。ただし小規模なIssue（バグ修正等）なら単体実装で十分。Issueのサイズラベルで使い分ける。

Phase 3: Review & Learn — Agent Teams推奨（2〜3名構成）

エージェント	役割
Integration Tester	機能間の結合テスト
Consistency Checker	仕様書間の矛盾、architecture.mdとの乖離検証

毎Issue後ではなく、2〜3 Issue実装ごとにバッチ的に回す。

保守のためのナレッジ保存

開発の過程で蓄積されるナレッジは、現状の仕組みでも相当カバーされています。

既に残るもの:

保存先	内容
steering	方針、規約、技術スタック
cc-sdd specs	requirements.md, design.md, tasks.md
GitHub	Issues、commits、変更履歴
CLAUDE.md	AIへの指示

失われるもの:

「なぜそうしたか」の判断根拠
「試したけどダメだった」知見
外部サービスの罠（レートリミットの実態、ライブラリのバグ等）
Agent Teamsでの議論内容

ADR（Architecture Decision Records）の導入

追加すべき仕組みは1つだけ。ADRです。1つの設計判断について短いMarkdownファイルを1つ書くだけのシンプルなものです。

# ADR-0001: 認証方式にJWTを採用

## 状態: 採用

## 背景
SPAとモバイルアプリの両方に対応する必要がある。

## 検討した選択肢
- セッションベース認証: サーバー側の状態管理が必要、スケーリング時に課題
- JWT: ステートレス、複数クライアント対応が容易
- OAuth2のみ: 自前ログインが不要な場合は良いが、今回は自前も必要

## 決定
JWTを採用。リフレッシュトークンはhttpOnly cookieで管理。

## 影響
全APIエンドポイントにBearer認証ミドルウェアが必要。
トークン失効の仕組みが必要（ブラックリスト方式）。

ADRの運用ポイント

AIに書かせる: Agent Teamsへの指示に「設計判断があったらADRを出力すること」と含めるだけ
Phase 1 Planning時: 技術選定の判断をADRとして残す
Build中: 設計変更が発生したらADRを追加
Review & Learn時: 振り返りで得た知見をADRとして記録

steeringが「今どうなっているか」を伝えるのに対し、ADRは「なぜそうなったか」を伝えます。この2つが揃うと、半年後の保守時にAIにプロジェクトを理解させる際のコンテキスト復元がかなり確実になります。

懸念事項

このワークフローには、従来の人間主体の開発と比較して特有の懸念があります。

コンテキストの断絶

人間のチームでは、アーキテクトが設計した内容を開発者が「覚えている」状態で実装に入ります。しかしAIエージェントはセッションが切れるとコンテキストを失います。

だからこそsteering、architecture.md、ADRによる明示的なコンテキスト受け渡しが必要です。逆に言えば、暗黙知が文書化されるので「あの人しか知らない」問題が起きないという利点もあります。

仕様のドリフト

Issue 1を実装した後に「やっぱりデータモデルを変えたほうがいい」と気づいた場合、イテレーティブループなら次のPlanningで反映できます。ただし、既に実装済みのIssue 1のコードとの不整合は残ります。

これをReview & Learnフェーズで検出し、必要であればリファクタリングのIssueを起票するのが現実的な対処です。

レビューの質

人間のシニアエンジニアは「この設計、半年後に辛くなる」といった経験則ベースの判断ができます。AIのReviewer役は論理的な矛盾は見つけられますが、プロジェクト固有の政治的・ビジネス的判断はできません。人間の承認ポイントがあるのは、この判断を補うためです。

まとめ

素朴な「cc-sdd + Agent Teams」の組み合わせはウォーターフォールになる
Phase 1を軽くし、2〜3 Issueずつ探索的に進めるアジャイルSDD方式を提案
Planning → Build → Review & Learnのイテレーティブループを回す
Agent TeamsはPhase 2aの仕様生成以外の全フェーズで活用
保守のためにADR（Architecture Decision Records）を1つだけ追加

次回の第3回では、このワークフローをGitHub Issue起点のパイプラインとして具体的に構築する方法を解説します。