【SDD】仕様書駆動開発:VSCode+GithubCopilot+cc-SDD 実践メモ:2025/12/30

未分類

現状の問題

VSCode + GitHub Copilot + AI Assistant の環境では:

  1. GitHub Copilot: コード補完時に自動でコードを生成
  2. AI Assistant: 「完遂せよ」という指示により、仕様承認前に実装まで進めてしまう
  3. 結果: Spec → Design → Tasks → 承認 → Implementation の流れが守られない

完全なSDDを実現する方法

✅ 可能(技術的制約 + ワークフロー設計)

以下の組み合わせで実現可能です:

1. Steering強化による明示的禁止

tech.md に追加:

## AI実装ルール(厳格版)

### 実装禁止条件
- spec.json の `ready_for_implementation: false` の場合、**絶対に実装しない**
- 人間の明示的な `/kiro-spec-impl` コマンドなしでは実装しない
- `-y` フラグがない限り、各フェーズで必ず人間の承認を待つ

### 仕様フェーズ中の制約
- Requirements/Design/Tasks フェーズ中は:
  - コード生成を**一切しない**(例示も禁止)
  - 既存コードの読み取りのみ許可
  - 設計レビューのみ実施

### 実装フェーズ開始条件
以下の全てが `true` の場合のみ実装可能:
1. `spec.json` の `approvals.requirements.approved: true`
2. `spec.json` の `approvals.design.approved: true`  
3. `spec.json` の `approvals.tasks.approved: true`
4. `spec.json` の `ready_for_implementation: true`
5. 人間から `/kiro-spec-impl {feature}` コマンド実行

2. 検証スクリプトの追加

実装前チェックスクリプト:

#!/bin/bash
# .kiro/scripts/check-implementation-ready.sh

SPEC_FILE="$1"

if [ ! -f "$SPEC_FILE" ]; then
  echo "❌ spec.json not found"
  exit 1
fi

READY=$(jq -r '.ready_for_implementation' "$SPEC_FILE")
REQ_APPROVED=$(jq -r '.approvals.requirements.approved' "$SPEC_FILE")
DESIGN_APPROVED=$(jq -r '.approvals.design.approved' "$SPEC_FILE")
TASKS_APPROVED=$(jq -r '.approvals.tasks.approved' "$SPEC_FILE")

if [ "$READY" != "true" ] || \
   [ "$REQ_APPROVED" != "true" ] || \
   [ "$DESIGN_APPROVED" != "true" ] || \
   [ "$TASKS_APPROVED" != "true" ]; then
  echo "❌ 実装開始条件を満たしていません"
  echo "  ready_for_implementation: $READY"
  echo "  requirements.approved: $REQ_APPROVED"
  echo "  design.approved: $DESIGN_APPROVED"
  echo "  tasks.approved: $TASKS_APPROVED"
  exit 1
fi

echo "✅ 実装開始可能"
exit 0

3. カスタムコマンドの明確化

/kiro-spec-impl コマンド実行時に必ず検証:

/kiro-spec-impl の動作

  1. spec.json の全承認状態をチェック
  2. NG なら エラーメッセージのみ表示して停止
  3. OK なら実装開始

4. Git Hooks活用

Pre-commit hook で実装コードのチェック:

#!/bin/bash
# .git/hooks/pre-commit

# 変更されたファイルが実装コードの場合、仕様書の状態をチェック
changed_files=$(git diff --cached --name-only)

for file in $changed_files; do
  if [[ "$file" =~ ^(backend|frontend|scripts)/ ]]; then
    # 対応するspec.jsonを探してチェック
    # ...
  fi
done

5. GitHub Copilot設定

.vscode/settings.json:

{
  "github.copilot.enable": {
    "*": true,
    "markdown": true,
    "python": false,  // 仕様フェーズ中は無効化
    "typescript": false,
    "javascript": false
  }
}

仕様フェーズと実装フェーズでワークスペースを切り替える。

⚠️ 原理的な限界

完全には以下の理由で困難:

  1. AI Assistant の自律性: 「問題を完全に解決せよ」という指示と「実装するな」の矛盾
  2. GitHub Copilot: コードファイルを開いた瞬間に提案が表示される
  3. 人間の曖昧性: 「確認して」が「実装して」と解釈される余地
  4. コンテキストの連続性: 既にコードが存在する場合、仕様との境界が曖昧

推奨アプローチ

実用的な折衷案:3段階ワークフロー

Phase 1: 仕様策定(AI + Human)
  - AIは仕様書のみ作成
  - コード例は擬似コードのみ
  - 承認: 人間が明示的に承認

Phase 2: 設計レビュー(Human主導)
  - 既存コード分析のみ許可
  - 実装の影響範囲を特定
  - 承認: 人間が明示的に承認

Phase 3: 実装(AI + Human)
  - `/kiro-spec-impl` コマンドで開始
  - タスク単位で実装
  - 承認: 各タスク完了時にレビュー

具体的な運用ルール

## AI Assistant への指示明確化

### 仕様フェーズの質問例
❌ 「この機能を実装して」
❌ 「コードを作成して」
✅ 「この機能の要件を整理して」
✅ 「設計の妥当性をレビューして」

### 実装フェーズの質問例
✅ 「/kiro-spec-impl feature-name task-1」
✅ 「task-1 を実装して(承認済み)」

結論

原理的に可能だが、実用性とのバランスが重要

  • ✅ 技術的には実現可能: Steering強化 + 検証スクリプト + ワークフロー分離
  • ⚠️ 完全な強制は困難: AI の自律性と利便性を殺してしまう
  • 💡 推奨: 明示的な承認フローと検証スクリプトの組み合わせ

コメント

タイトルとURLをコピーしました