コーディングAIに画面を作ってと伝えると、それらしいものが出てきます。ただ、次のセッションで前提が消え、直すたびに別の解釈が混ざります。DeepLearning.AI の講座では、これをバイブコーディングの限界として扱い、先に仕様を書く進め方を示しています。仕様は、AIに渡す指示書であり、人が意図を保つための記録でもあります。
手順1：プロジェクトの憲章を書く
最初に、目的、技術の構成、これから作るものの順番を1枚にまとめます。講座ではこれを憲章と呼び、AIと相談しながら作る形を取ります。毎回の指示に含めなくても、参照先として置ける点が利点です。憲章は短く保ち、決めた理由も1行ずつ添えます。理由があると、後から変更するときに判断がぶれません。
手順2：機能を1つ選び、仕様に落とす
憲章のうち、次に作る機能を1つ選びます。入力、出力、例外の扱い、完了の条件を書きます。ここが曖昧なままだと、AIは足りない部分を推測で埋めます。講座でも、機能仕様を先に書く段階が独立して置かれています。書き終えたら、その仕様だけで第三者が作れるかを自問します。
手順3：計画を立てさせてから実装させる
仕様を渡し、まず変更するファイルと手順を挙げさせます。こちらが確認してから実装に進みます。講座の流れも、計画、実装、検証の3段階で、実装の前に計画を置いています。計画の段階で、触ってほしくない範囲を明示すると、余計な変更が減ります。ここで止めるのが、いちばん安く済む介入です。
手順4：検証の条件を先に決める
何が通れば完了かを、実装の前に書きます。テストの有無、画面の確認項目、既存機能への影響の3つを決めておくと、AIの自己申告に頼らずに済みます。確認は、人が見る項目と、自動で回す項目に分けます。分けておくと、変更のたびに全部をやり直さずに済みます。
手順5：次の機能の前に仕様を更新する
1つ作り終えたら、憲章と仕様を更新してから次に進みます。講座は、機能の間で計画を引き直す工程を置いています。既存のコードに適用する場合は、いまの文書から仕様を起こす形になります。仕様をためておくと、担当するAIを替えても前提が残ります。関連する用語はコンテキストエンジニアリングのページにまとめています。
FAQ
Q. 小さな修正でも仕様を書く必要がありますか？
A. 1行の修正なら不要です。判断が分かれる変更、複数ファイルに触る変更、あとで理由を聞かれそうな変更は書いたほうが速く済みます。
Q. 仕様を書くと、かえって時間がかかりませんか？
A. 最初の1回はかかります。ただし、同じ説明を何度もし直す時間と、意図と違う実装を戻す時間が減ります。講座も、意図のずれと認知的な負債を減らす効果として説明しています。
出典
出典：DeepLearning.AI「コーディングエージェントと進める仕様駆動開発」（原題 Spec-Driven Development with Coding Agents、Paul Everitt、2026年4月18日更新、2026年10月27日参照）
あわせて使いたいツール
本記事の手順を実際に回すときに、候補になるツールを挙げます。いずれも無料から試せる範囲があり、料金や機能は各サービスの公式情報で確認してください。
関連ガイド
同じ時期に公開した実務ガイドと、用語の定義ページです。手順の前提が分からない場合は、用語ページから確認してください。コピーして使える依頼文が欲しいときは、プロンプト集も参照してください。
- AIの出力を型で受ける：スキーマを決めて検証する5手順
- Webhookの受け口を先に作る：他サービスからの通知を自動化する5手順
- コンテキストエンジニアリング（用語辞典）
- AI用語辞典（五十音順の一覧）
- はじめての LLM 活用（学習ルート）
- ガイド一覧（実務手順をまとめて読む）
- AIツール一覧（道具から探す）
- 比較記事一覧（料金と機能で比べる）
- レビュー一覧（使った記録を読む）
編集部の見解
仕様を書く価値は、AIのためより人のためだと思います。うちでも、口頭で頼んだ変更が3回目で別物になり、どこで解釈がずれたのかを追えなくなりました。憲章を1枚置いてからは、判断が分かれたときに戻る場所ができます。ただ、憲章を立派にしようとして止まるのがよくある失敗で、最初は10行もあれば足ります。書くことより、更新して残すことのほうが効きます。
最新のAI情報をメールで受け取る
新着のAIツール比較・ランキング・ニュースを、まとめてお届けします。
ご登録後、確認メールをお送りします。配信停止はいつでも可能です。