AIが実装する時代、人間は仕様と検証を設計する

cc-sddの開発者が、仕様駆動開発 (Spec-Driven Development) で現在取り組んでいることや考えていることについて話す。
SDDの検証をどう行えば人間レビューを減少させることができるかや長時間自律性を高めるための取り組みやハーネスの概念について解説する。

Transcript

1. AIが実装する時代、人間 は仕様と検証を設計する Spec-Driven Development で今取り組んでいること Gota / 2026-02-13
2. gota X: @gota_bara / GitHub: @gotalab 職種 Agentic AI Engineer & データアナリスト やってること 小売向けデータプロダクト / AIエージェント開発 / データ整備 興味 AI x 体験 / 音声AI / LLM Evals / DSPy / 山登り (夏以外) cc-sdd ★ 2,580 Spec-driven development (SDD) for your team's workflow. Kiro style commands that enforce structured require... skillport ★ 305 Bring Agent Skills to Any AI Agent and Coding Agent — via CLI or MCP. Manage once, serve anywhere. 自己紹介
3. AIでコードもSpecも書ける。PRマージは2倍 速い。なのに、なぜレビューが終わらない？ DORA 2025 が答えを出している
4. +98% PRマージ数 +91% レビュー時間 +154% PRサイズ ±0% デリバリー性能 DORA 2025 が突きつける逆説 出典: DORA Report 2025 個人は速くなった。組織は止まっている
5. 開発者の実コーディング時間は1日 52分 開発サイクルの71%はレビュー待ち Amdahl's Law（並列計算の限界法則） が示す教訓: 非ボトルネックをいくら速 くしても全体は変わらない ボトルネックは最初からレビューだった 出典: IDC 2024（25万人）/ LinearB 2024（2.6万人） コーディングは全体の16%。AIが10倍速くしても全体は+8%
6. 1. なぜレビュー が地獄になるのか 仕様駆動開発に潜む「二重レビュー」の構造
7. ロジック・正確性エラー +75% セキュリティissue 最大2.74倍 78%の開発者がレビュー完了まで1日 以上待つ AI生成コードは速いが壊れやすい AI生成コードは1.7倍のissueを生み、レビューで止まる
8. 不⼗分 Pass Pass Reject Spec 修正から やり直し Spec 作成 Spec レビュー （Review ①） AI 実装 Spec ⼤ → コード量も膨⼤ コードレビュー （Review ②） マージ 差し戻し Specが膨らむほどコードレビューが地獄になる
9. コードレビューを限りなく簡素にする 仕組みが要る = Specを検証可能な「契約」にし、機械に正しさを判定させる
10. 2. Specを検証可能 な「契約」にする 機械検証でコードレビューの負荷を消す
11. 本質は計画ではなく、正しさを機械的に判定できること 「先に仕様を書いてから実装」→ それだけならウォーターフォールと同じ Specを機械が検証できる契約にする → コードレビューを自動ゲートに置換 Design by Contractの現代的再解釈 SDDは「先に計画する」だけではない
12. Testable 検証を自動化 → レビュー時間を削減 Observable 正常/異常の境界をSpecに定義する Decomposable タスク分解 → PRサイズを構造的に縮小 検証に落ちるSpecの3つの性質 Testable / Observable / Decomposable で契約にする
13. acceptance_criteria: # EARS形式 - "When 注文金額 ≥ 10,000円, the system shall 送料を0円にする" - "If 在庫 = 0, then the system shall カート追加を拒否する" specs_covered: # どのREQをカバーするか - "specs/order.md#REQ-001" - "specs/order.md#REQ-002" scenarios_covered: # どのシナリオを証明するか - "specs/order.md#SCN-REQ-001-01" checks: # 決定論的ゲート - "npm test -- --coverage" Testable: 決定論と確率論の二層で検証する EARS形式のACをchecks + soft_checksで判定する
14. API応答 正常系 2xx バリデーション 4xx ビジネスルール違反 システムエラー 5xx 200 OK 201 Created 400 必須フィールド⽋落 422 値域外 409 在庫不⾜ 403 権限不⾜ 500 Internal Error 503 Service Down Specに含まれていれば 境界値テストを⾃動⽣成できる Observable: エラー分類で異常を検出する Error Taxonomyがなければ、何が正常か分からない
15. Spec (spec.md) AC (受⼊条件) Examples (実例) Error Taxonomy Boundary 定義 /decompose Generated Tasks Task 1: API設計 boundary: src/api/ checks: 型エラーなし Task 2: DB設計 boundary: src/db/ checks: マイグレーション通過 Task 3: 機能実装 boundary: src/feature/ depends_on: [1, 2] checks: テスト全通過 depends_on Decomposable: タスクに分解して独立実行する 仕様があってもタスクに分解できないと反復できない
16. 3. 契約をタスクレベルで 強制する 実際に取り組んでいる boundary × checks × depends_on
17. Boundary: 編集スコープ制御 編集許可 src/feature-a/ handler.ts schema.ts tests/feature-a/ 編集禁⽌ src/feature-b/ config/ .env docs/ task_lock: 排他制御 Agent A (書込中) handler.ts LOCKED Agent B (待機) BLOCK 同⼀ファイルへの並列書込を防⽌ Boundary: AIの編集範囲を契約で縛る 制約なしのAIは勝手にスコープを広げる。境界で止める
18. checks: # 決定論的ゲート - "npx tsc --noEmit" - "npm test -- --coverage" soft_checks: # 確率論的ゲート（LLM-as-judge） - kind: llm.judge prompt: "ACの網羅性とエッジケースを検証" threshold: 0.8 # agent hooks がタスク完了時に両方を自動実行 # → pass しないと「完了」にならない Checks: Testableを自動ゲートにする agent hooks で二層の検証を自動発火させる
19. Phase 3 Phase 2 ( 並列) Phase 1 ( 並列) Task A API 設計 Task B DB スキーマ設計 Task C API 実装 Task D フロントエンド Task E 統合テスト depends_on: Decomposableを依存グラフにする 巨大な1PRではなく、小さい検証済みタスクの連鎖にする
20. boundary + checks + depends_on = 人間レビューの最小化 Boundary AIの逸脱を防ぐ Checks 決定論的に検証する depends_on レビュー範囲を最小化 3要素の統合 レビューゼロが目標ではない。レビューをボトルネックにしない状態が目標
21. Pass Fail コード変更 LLM テスト⽣成 テスト実⾏ 結果 マージ ⼈間レビュー JiTTests: コード変更 → Mutant生成 → テスト自動生成・実行 → コードベースに保存し ない テストのメンテコストゼロ。checksの方向性と同じ 検証の自動化はスケールする 出典: Meta Engineering Blog "The Death of Traditional Testing" (2026/2/11) Metaはテスト自体をLLMに生成させる研究を進めている
22. /plan 仕様を構造化して書く /decompose タスクに分解（boundary/checks/depends_on付き） /execute タスク完了まで自律実行。checks通過で次へ進む Plan → Decompose → Execute Specからタスクへ、タスクから検証済み実装へ
23. Signal の例 - テスト失敗 / 型エラー - boundary 逸脱検出 - 依存タスクとの競合 異常を検出 Approve Reject 次 の タ ス ク へ Task 実⾏ Signal 検出 /analyze Proposals /adapt Task Plan 更新 checks/boundary の失敗を signal として捕捉 → /analyze → /adapt → タスク計画を動的 に修正 長時間の自律実行を可能にする鍵。signal がなければ停止か暴走の二択 Signal-Based Adaptation Loop 検証の失敗を自律的に軌道修正する仕組み
24. 4. GPT-5.3-Codex という示唆 モデル能力がSDDの前提を揺さぶる
25. OSWorld: 38.2% → 64.7% (+26pt) Terminal-Bench: 64.0% → 77.3% SWE-Bench Proは56.8%で漸進的改善 SWE-Bench VerifiedではClaude Opus 4.5/4.6が80%台 Codex のエージェント能力が飛躍した Codexは「エージェント自律性」で前世代を大きく超えた
26. 従来: ハーネス制御 ハーネスがSpec→Task→検証を制御 人間がchecksの成否を確認 ツール固有のラッパーが必要 Codex: モデル自律 モデル自身が指示追従+検証 Terminal-Bench 77.3%（Opus 4.6: 65%） SW開発の現場では指示追従の"質"が異な る体感 Specをそのまま渡すだけで動く仮説 ハーネスで作ったSpec/Taskをそのまま渡すだけで動く可能性
27. SDDのハーネスは足場。 身軽に作ろう 長期タスク成功率はまだ約50% 品質が最大障壁（32%が課題に挙 げる） AIタスク持続時間は4ヶ月ごとに倍 増中 ハーネスは足場。でも今はまだ必要
28. 1 レビュー時間+91%はAIの副作用 Specを「検証に落ちる契約」に変えろ。Testable / Observable / Decomposable 2 3つのメカニズムで人間レビューを絞ろう boundary x checks x depends_on 3 ハーネスは足場。身軽に作ろう モデルが足場なしで立てる日に備えて、捨てやすく設計する まとめ Specを契約に変えて、レビューから解放されよう
29. Q&A
30. Thank You! X: @gota_bara GitHub: @gotalab cc-sdd: github.com/gotalab/cc-sdd