Spec First：AIに実装させる前に仕様書を書くと、なぜ結果が安定するのか
仕様書なしで実装を依頼すると何が起きるか
「このページにお問い合わせフォームを追加してほしい」——こう伝えてAIに実装を依頼した場合、AIは「お問い合わせフォーム」として一般的なものを実装します。必要なフィールド、送信後の動作、エラー表示の方法など、すべてAIが自分の解釈で決めます。
できあがったものを見ると、「メールアドレス入力欄がない」「送信後に確認画面ではなくサンキューページへ飛ぶ仕様になっている」「想定と別のデザインになっている」といった状況が起きます。修正を依頼するたびに新たな調整が必要になり、最終的に意図に近いものができるまでに数回のやり取りが必要になります。
この繰り返しは、最初の指示に「何を作るか」の定義が含まれていなかったことが原因です。
Spec First という考え方
Spec First は「実装を依頼する前に仕様書（specification）を書く」という原則です。仕様書といっても、正式な文書形式である必要はありません。「何を作るか」「どう動くか」「何をしないか」の3点を書き出すだけで、AIとの認識合わせが最初の段階で完了します。
私がこのサイトで新しい機能を追加するときは、実装の前に必ずこの3点を整理します。たとえばフォームの例であれば、次のように書きます。
## お問い合わせフォームの仕様
### 何を作るか
- 名前・メールアドレス・メッセージを入力できるフォーム
- 送信ボタンを1つ設置する
### どう動くか
- 送信後は同ページ内に「送信しました」というテキストを表示する
- バリデーション：名前・メールアドレスは必須、メールアドレスはフォーマットチェックあり
### 何をしないか
- 外部サービスへの連携はしない（この実装では送信後の処理は不要）
- デザインの変更は含まない（既存のスタイルをそのまま使う）仕様書があることで何が変わるか
AIとの認識合わせが最初に終わる
仕様書を渡すと、AIは実装を始める前に「理解した通りに進めます」または「この点を確認させてください」と返します。実装を始める前に認識のずれを検出できるため、「できあがってみたら違った」という状況が起きにくくなります。
レビューの基準が明確になる
実装が完了したあと、「仕様書に書いた通りに動いているか」を確認するだけでレビューができます。仕様書がない場合、「何が正しい動作か」の判断が毎回必要になります。
修正の範囲が限定される
仕様書があると、修正依頼も「仕様書のこの部分を変えたい」という形で出せます。仕様書なしで修正を重ねると、AIが前の修正との整合性を保てないまま変更を加えることがあります。
仕様書を書く手間との兼ね合い
「仕様書を書くのに時間がかかる」という点は、実際にそのとおりです。小さな修正（テキストを変える、色を変えるなど）に毎回仕様書は必要ありません。
仕様書が有効なのは、「複数の要素を含む実装」「AIが選択肢を持つ実装」「後で変更が生じる可能性がある実装」です。作業の規模と複雑さに応じて判断します。
まとめ
Spec Firstは「最初に仕様書を書くことで、実装後の修正回数を減らす」という原則です。書く内容は「何を作るか」「どう動くか」「何をしないか」の3点で十分です。AIへの指示精度を上げる前に、まず「何を作るか」を自分自身で整理する習慣が、AIとの作業を安定させる出発点になります。