仕様・実装共進化
仕様と実装を高速に往復しながら、フィードバックループを回し続ける開発アプローチ。バイブコーディングでも仕様駆動開発でもない第三の道。
核心的洞察
コーディングエージェントの本質は、「仕様を先に確定する」ことではなく、**「仕様と実装を高速に往復できる」**こと。
従来は仕様変更から実装更新まで時間がかかったため、「仕様を先に確定する」ことが重視された。しかし今は、仕様→実装の変換コストが劇的に低下した。だからこそ、何度でも往復できる。
ワークフロー
- 最小限の仕様から始める - 完璧を目指さない
- コードを生成させる - AIに実装させる
- 実装を読み、理解する - コードが何をしているか把握する
- 問題や改善点を発見する - 実装から学ぶ
- 仕様を更新する - 学びを仕様に反映
- 再実装 - 改善されたコードを生成
- 繰り返し
具体例:認証機能の実装
従来のウォーターフォール的アプローチ
- 認証の仕様をすべて確定(OAuth 2.0、JWT、リフレッシュトークン...)
- 詳細な設計書を作成
- 実装
- 実装段階で問題が噴出
- 仕様に戻って修正、再実装
仕様・実装共進化
- 最小限の仕様(「メールとパスワードでログイン」)
- 実装生成
- コードを見て「トークンの保存はlocalStorageか。XSS対策でhttpOnlyクッキーにすべきでは?」と気づく
- 仕様更新、再実装
- 「リフレッシュトークンは?」という新たな疑問
- 仕様追加、実装、検証...
高速サイクルを回すことで、仕様とコードが共進化する。
原則
実装からのフィードバックが不可欠
実際に動くコードレベルでなければ理解できない:
- 具体的な構造
- 状態遷移
- 振る舞い
これらからのフィードバックがなければ、良い仕様は書けない。
コードこそが真実
コンテキストウィンドウの制約下では、仕様書とコード両方をAIに読ませるのは非効率。
コードに十分な構造と意図が表現されていれば、AIはコードを読むことでユビキタス言語やドメインモデルを理解できる。ドキュメントは補助的存在。
DDDとの親和性
Domain-Driven Designが強調する「コードとモデルの深い結びつき」と整合する。仕様とコードが分離するのではなく、相互に影響を与えながら洗練されていく。
変わったこと vs 変わらないこと
変わったこと
- 仕様→実装の変換コストが劇的に低下
- プロトタイピングが爆速に
変わらないこと
- 良い仕様を書く難しさ
- 実装から得られるフィードバックの価値
- ドメインモデル構築の難しさ
- LLMの非決定性という新しい制約
認知的距離との関係
高速サイクルで仕様と実装を往復することは、較正ループを高頻度で回すことに等しい。各往復で仕様側のスキーマと実装側のスキーマの認知的距離が縮小し、共進化が進む。変換コストの劇的な低下はループ頻度の上昇を意味し、距離の管理がより精密になる。
関連
- 認知的距離 - 高速往復による距離の縮小
- 較正ループ - 仕様⇔実装の往復が較正ループそのもの
- フィードバック
- 仕様駆動開発
- バイブコーディング
- Domain-Driven Design
- ユビキタス言語
- コンテキストウィンドウ
- LLM
- アジャイル
- 翻訳方向の非対称性
- SSoT