AIが実装する時代、人間 は仕様と検証を設計する Spec-Driven Development で今取り組んでいること Gota / 2026-02-13 

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. 自己紹介 

AIでコードもSpecも書ける。PRマージは2倍 速い。なのに、なぜレビューが終わらない？ DORA 2025 が答えを出している 

+98% PRマージ数 +91% レビュー時間 +154% PRサイズ ±0% デリバリー性能 DORA 2025 が突きつける逆説 出典: DORA Report 2025 個人は速くなった。組織は止まっている 

開発者の実コーディング時間は1日 52分 開発サイクルの71%はレビュー待ち Amdahl's Law（並列計算の限界法則） が示す教訓: 非ボトルネックをいくら速 くしても全体は変わらない ボトルネックは最初からレビューだった 出典: IDC 2024（25万人）/ LinearB 2024（2.6万人） コーディングは全体の16%。AIが10倍速くしても全体は+8% 

1. なぜレビュー が地獄になるのか 仕様駆動開発に潜む「二重レビュー」の構造 

ロジック・正確性エラー +75% セキュリティissue 最大2.74倍 78%の開発者がレビュー完了まで1日 以上待つ AI生成コードは速いが壊れやすい AI生成コードは1.7倍のissueを生み、レビューで止まる 

不⼗分 Pass Pass Reject Spec 修正から やり直し Spec 作成 Spec レビュー （Review ①） AI 実装 Spec ⼤ → コード量も膨⼤ コードレビュー （Review ②） マージ 差し戻し Specが膨らむほどコードレビューが地獄になる 

コードレビューを限りなく簡素にする 仕組みが要る = Specを検証可能な「契約」にし、機械に正しさを判定させる 

2. Specを検証可能 な「契約」にする 機械検証でコードレビューの負荷を消す 

本質は計画ではなく、正しさを機械的に判定できること 「先に仕様を書いてから実装」→ それだけならウォーターフォールと同じ Specを機械が検証できる契約にする → コードレビューを自動ゲートに置換 Design by Contractの現代的再解釈 SDDは「先に計画する」だけではない 

Testable 検証を自動化 → レビュー時間を削減 Observable 正常/異常の境界をSpecに定義する Decomposable タスク分解 → PRサイズを構造的に縮小 検証に落ちるSpecの3つの性質 Testable / Observable / Decomposable で契約にする 

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で判定する 

API応答 正常系 2xx バリデーション 4xx ビジネスルール違反 システムエラー 5xx 200 OK 201 Created 400 必須フィールド⽋落 422 値域外 409 在庫不⾜ 403 権限不⾜ 500 Internal Error 503 Service Down Specに含まれていれば 境界値テストを⾃動⽣成できる Observable: エラー分類で異常を検出する Error Taxonomyがなければ、何が正常か分からない 

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: タスクに分解して独立実行する 仕様があってもタスクに分解できないと反復できない 

3. 契約をタスクレベルで 強制する 実際に取り組んでいる boundary × checks × depends_on 

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は勝手にスコープを広げる。境界で止める 

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 で二層の検証を自動発火させる 

Phase 3 Phase 2 ( 並列) Phase 1 ( 並列) Task A API 設計 Task B DB スキーマ設計 Task C API 実装 Task D フロントエンド Task E 統合テスト depends_on: Decomposableを依存グラフにする 巨大な1PRではなく、小さい検証済みタスクの連鎖にする 

boundary + checks + depends_on = 人間レビューの最小化 Boundary AIの逸脱を防ぐ Checks 決定論的に検証する depends_on レビュー範囲を最小化 3要素の統合 レビューゼロが目標ではない。レビューをボトルネックにしない状態が目標 

Pass Fail コード変更 LLM テスト⽣成 テスト実⾏ 結果 マージ ⼈間レビュー JiTTests: コード変更 → Mutant生成 → テスト自動生成・実行 → コードベースに保存し ない テストのメンテコストゼロ。checksの方向性と同じ 検証の自動化はスケールする 出典: Meta Engineering Blog "The Death of Traditional Testing" (2026/2/11) Metaはテスト自体をLLMに生成させる研究を進めている 

/plan 仕様を構造化して書く /decompose タスクに分解（boundary/checks/depends_on付き） /execute タスク完了まで自律実行。checks通過で次へ進む Plan → Decompose → Execute Specからタスクへ、タスクから検証済み実装へ 

Signal の例 - テスト失敗 / 型エラー - boundary 逸脱検出 - 依存タスクとの競合 異常を検出 Approve Reject 次 の タ ス ク へ Task 実⾏ Signal 検出 /analyze Proposals /adapt Task Plan 更新 checks/boundary の失敗を signal として捕捉 → /analyze → /adapt → タスク計画を動的 に修正 長時間の自律実行を可能にする鍵。signal がなければ停止か暴走の二択 Signal-Based Adaptation Loop 検証の失敗を自律的に軌道修正する仕組み 

4. GPT-5.3-Codex という示唆 モデル能力がSDDの前提を揺さぶる 

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は「エージェント自律性」で前世代を大きく超えた 

従来: ハーネス制御 ハーネスがSpec→Task→検証を制御 人間がchecksの成否を確認 ツール固有のラッパーが必要 Codex: モデル自律 モデル自身が指示追従+検証 Terminal-Bench 77.3%（Opus 4.6: 65%） SW開発の現場では指示追従の"質"が異な る体感 Specをそのまま渡すだけで動く仮説 ハーネスで作ったSpec/Taskをそのまま渡すだけで動く可能性 

SDDのハーネスは足場。 身軽に作ろう 長期タスク成功率はまだ約50% 品質が最大障壁（32%が課題に挙 げる） AIタスク持続時間は4ヶ月ごとに倍 増中 ハーネスは足場。でも今はまだ必要 

1 レビュー時間+91%はAIの副作用 Specを「検証に落ちる契約」に変えろ。Testable / Observable / Decomposable 2 3つのメカニズムで人間レビューを絞ろう boundary x checks x depends_on 3 ハーネスは足場。身軽に作ろう モデルが足場なしで立てる日に備えて、捨てやすく設計する まとめ Specを契約に変えて、レビューから解放されよう 

Q&A 

Thank You! X: @gota_bara GitHub: @gotalab cc-sdd: github.com/gotalab/cc-sdd