AIコーディングを「個人技」から「チームの標準」へ：チームへの仕様駆動開発の導入

この記事が想定する読者

• AIコーディングを行っているが、狙ったアウトプットが得られず苦心している人
• 仕様駆動開発に興味がある人

こんなことありませんか？

• AIエージェントから思ったアウトプットが得られない
• 人によりアウトプットが異なるので、レビューが大変

本記事では、これらの課題に対して仕様駆動開発（SDD）を取り入れ、どのように対処していくかを解説します。

はじめに

チームメンバーが個々にCursorやClaude Codeを使い始めると、直面するのが「品質のばらつき」です。「いい感じで」作ったコードは、作成者本人以外にはメンテナンスが難しく、レビューコストも増大しがちです。
AI開発を個人技からチーム開発の標準プロセスへと昇華させるためにチームで仕様駆動開発を導入し、どのようなフローで開発していくかを紹介します。

なぜチーム開発で「Vibe Coding」はつらいのか

CursorやClaude Codeに任せたVibe Codingは個人開発や小さなスクリプトでは有効ですが、チーム開発では以下のリスクが致命的です。

• コンテキストの属人化: チャット履歴の中に仕様が埋もれ、他のメンバーが意図を追えない。
• レビューの形骸化: 生成された大量のコードがいきなりPRに出され、レビュアーがロジックを追いきれない。
• 無限の修正ループ: 仕様の合意がないまま実装が進むため、手戻りが多発する。

これらを解決するのが、仕様駆動開発 (Spec-Driven Development: SDD) です。

今回は数ある仕様駆動開発のツールキットの中から、 cc-sdd を利用した場合の開発ワークフローを見ていきます。

cc-sddが提供するチーム開発ワークフロー

cc-sddは、AIとの対話を「仕様書（Markdown）」として永続化し、それを契約書として開発を進めるアプローチです。

チーム導入における最大のメリットは、「Spec First Review（仕様先行レビュー）」 のプロセスを導入できる点です。

cc-sddを取り入れた際の理想的な開発フローは以下の図です。

開発速度と品質のバランスを考慮した理想的な開発フロー

1. ステアリングを作成 /kiro:steering
2. 要件定義を実施 /kiro:spec-requirements
3. 設計を実施 /kiro:spec-design
4. チームレビュー #1（仕様・設計レビュー）
5. タスク計画を作成 /kiro:spec-tasks
6. 実装 /kiro:spec-impl
7. チームレビュー #2（実装レビュー）
8. 進捗追跡 /kiro:spec-status

ポイントは「4. チームレビュー #1」です。 実装の前にAIが生成した design.md (設計書) をPRとして提出し、チームレビューします。実装が終わってから気付くエンジニアとPdMの認識齟齬をこのタイミングで無くし、手戻りのリスクを減らした上で、実装に着手します。
また、単にドキュメントを書くだけではなく、各フェーズで人間が承認を行わない限り、AIは次のコマンドを実行しても拒否されます。この強制力こそが『契約』であり、チーム開発における品質の最後の砦となります。

なぜ「全ステップ」でチームレビューをしないのか？

要件定義やタスク計画のたびにチームレビューを挟むフローも考えられますが、それではレビュー待ち時間が増大し、AI開発のメリットである「速度」が失われてしまいます。

本フローでは、エンジニア自身による「セルフレビュー（要件・タスク）」と、チームによる「チームレビュー（設計・実装）」を明確に使い分けています。 エンジニアはAIのパイロットとして微調整を高速に行い、チームは設計という「要所」を抑える。これにより、最もコストパフォーマンス良く、速度と品質を両立させています

設計、実装を行っていく中で、steeringに追加すべきこと、考慮漏れなどは随時アップデートします。

cc-sddを取り入れる２つの理由

1. cc-sddを取り入れる最大の理由： Steeringによる暗黙知の資産化

チーム開発で特に有効なのが、Steering 機能です。これはプロジェクトの「憲法」を明文化する仕組みです。

Steering フォルダに以下のようなルールを配置することで、誰がAIを使っても統一された品質のコードが出力されるようになります。

• 基盤ルール: 言語バージョン、使用ライブラリ、Linter設定など
• 設計規約: 設計手法、ディレクトリ構造、エラーハンドリングの方針、認証パターンの統一など

これにより、新しく参画したメンバーでも、プロジェクト固有の「暗黙知」に従った実装をAIに指示できるようになります。
steeringドキュメントがそのままプロジェクトの知識となり、ドキュメント作成の省力化も期待できます。

2. Shift Left Testing（テストのシフトレフト）

コードが出来上がってからのレビューはコストがかかります。cc-sddでは、コードを書く前に設計レビューを行うことで、バグの温床となる「要件の誤解」を早期に発見します。（requirements.md、design.mdのレビュー）

• 高速: コードを読むより、日本語/英語のドキュメントを読む方が圧倒的に早い。
• 網羅性: ロジックの実装詳細に入る前に、コーナーケースの考慮漏れを指摘できる。
• 参加障壁の低下: エンジニア以外のプロダクトマネージャーやデザイナーもレビューに参加しやすくなる。

実際のsteeringの例（バックエンド）

• コーディングスタイル、規約

コーディングスタイル、規約の例

# コードスタイル規約


[Purpose: コードの可読性と保守性を向上させるためのスタイル規約を統一]

## 基本原則

**可読性と変更容易性を最優先**: フロントエンド、バックエンドともに、ソースコードは可読性と変更容易性を重視してください。

### 可読性の原則
- **明確な命名**: クラス名、メソッド名、変数名は意図が明確に伝わる命名を心がける
- **適切なコメント**: 複雑なロジックやビジネスルールには説明を追加
- **ガード節と早期リターン**: 深いネストを避け、正常系の処理をフラットに保つ
- **単一責任の原則**: クラスやメソッドは1つの責務に集中

### 変更容易性の原則
- **依存関係の最小化**: 不要な依存関係を避け、疎結合な設計を心がける
- **インターフェースの活用**: 実装の詳細を隠蔽し、変更の影響範囲を限定
- **値オブジェクトの徹底**: プリミティブ型を直接使用せず、値オブジェクトとして型安全性を確保
- **テスト容易性**: 単体テストが容易な設計を心がける（依存性注入、モック可能な設計）

• 採用してほしい設計手法

採用してほしい設計手法の例 #1

[Purpose: ドメイン層の設計原則と実装方針を統一]

## ドメイン駆動設計（DDD）の原則

### レイヤー分離
- ドメイン層、アプリケーション層、インフラストラクチャ層、プレゼンテーション層を明確に分離
- 外側のレイヤーから内側のレイヤーへの一方向の依存関係を維持
- ドメイン層は他のレイヤーに依存しない

### ビジネスロジックの配置
- **バックエンドの重要なビジネスロジックはドメインモデル（エンティティ・値オブジェクト）が保持する**
- ビジネスルールやドメインロジックはアプリケーション層やインフラストラクチャ層ではなく、ドメイン層に実装する
- エンティティや値オブジェクトにメソッドとしてビジネスロジックを集約する
- アプリケーション層はドメインモデルのメソッドを呼び出すだけの薄い層として実装する

#### 実装方針
- ビジネスルールの判定や計算ロジックはエンティティのメソッドとして実装
- 値オブジェクトにはその値に関するバリデーションや変換ロジックを実装
- ドメインサービスは複数のエンティティにまたがるロジックや、エンティティに配置すると不自然な場合のみ使用

採用してほしい設計手法の例 #2

# Package Structure Standards

[Purpose: パッケージ構造の設計原則と実装方針を統一]

## 基本原則

**可読性と変更容易性を最優先**: パッケージ構造は、コードの可読性と変更容易性を向上させるために設計します。

- **関心事による分割**: 機能やドメインごとにパッケージを分離し、関連するクラスをまとめることで、コードの可読性を向上
- **変更の影響範囲の限定**: パッケージ分割により、変更時の影響範囲を明確にし、変更容易性を向上
- **明確な責務**: 各パッケージは明確な責務を持ち、単一責任の原則に従う

## パッケージ分割の原則

### 原則
- **コントローラー、サービス、値オブジェクトは関心事ごとにパッケージに分割すること**
- 機能（feature）やドメイン（domain）ごとにパッケージを分離し、関連するクラスをまとめる
- 単一責任の原則に従い、各パッケージは明確な責務を持つ

役割分担の明確化

cc-sddを導入することで、プロダクトマネージャーとエンジニアの責務も明確になります。

ロール	担当領域	チェックポイント
プロダクトマネージャー	Requirements / Design	ユーザーの課題を解決しているか？期待する挙動か？
エンジニア	Design / Tasks / Steering	可読性・保守性は担保されているか？Steeringのルールが守られているか？

実装の安定性を高めるタスク分解

実装フェーズでは、tasks.md に基づいて作業が進みます 。

1. Task: 最小単位の実装
2. Test: そのタスクのテスト通過を確認
3. Next: 次のタスクへ

この Task -> Test -> Next のサイクルを順守することで、大規模な変更でもデグレ（退行）を防ぎながら着実に進捗させることができます。また、実装中に「なんか違う」となった場合でも、手戻りをタスク単位に留められます。

Vibe Coding vs cc-sdd（チーム視点）

項目	通常のAIコーディング	cc-sdd (チーム導入)
コンテキスト	個人のチャット履歴（共有困難）	リポジトリ内の仕様書（永続的）
レビュー	最終コードの一発勝負	仕様書レビュー + コードレビュー
スケーラビリティ	個人開発向け	大規模・チーム開発に対応

運用上のポイント：仕様書の肥大化を防ぐ

導入時に注意すべき点は、design.md のサイズ管理です。一度に巨大な機能を実装しようとすると、設計書が肥大化し、AIのコンテキストあふれやレビュー困難を引き起こします。

• 解決策: /kiro:spec-requirements の段階で、機能を「1回のPRで消化できるサイズ」に適切に分割することが、スムーズな開発の鍵となります。これは人間が普段行っている「タスク分割」と同じ要領です

まとめ：新しい開発標準を始めよう

AIのエージェント化が進む今、人間に求められるのは「コードを書くこと」から「仕様を定義し、品質をゲートする（レビューする）こと」へシフトしています。

cc-sddは、その転換をスムーズに行い、チーム全体でAIの恩恵を享受するためのフレームワークです。

まずは小規模な機能追加から、チームで試してみませんか？

npx cc-sdd@latest