仕様駆動開発(SDD)とは｜AIへの口頭依頼をやめる4つのファイル

AIにスクリプトを頼んだら、動くけれど欲しかったものと違う。そんな経験はありませんか。何度言い直しても、少しずつズレていくこともあります。

この記事では、2026年9月末にQiitaやZennで解説記事が出た「仕様駆動開発(SDD)」のしくみと、運用の現場での使いどころがわかります。結論から言うと、AIへの依頼を「会話」ではなく「書いた仕様書」を基準に進めるやり方です。

仕様駆動開発(SDD)とは?仕様書を「正しさの基準」にする進め方

仕様駆動開発(Spec-Driven Development、略してSDD)とは、作りたいものを先に文章にまとめ、それを基準にAIに作らせる進め方です。

理由はシンプルで、AIは指示のすき間を自分で埋めて実装するからです。書いていないことは、AIが「たぶんこうだろう」と決めてしまいます。

たとえるなら、工事を電話一本で頼むのと、発注書と工程表を渡すのとの違いです。電話だと、あとから「口頭ではこう伺いました」と言われても反論できません。

つまりSDDは、AIとの「言った・言わない」をなくすために、依頼内容を形に残す考え方です。

仕様駆動開発が求められる背景

SDDが求められる理由は、AIがコードを書くようになり、これまで人の頭の中やコードを書く過程で決めていた設計が、どこにも残らなくなってきたことにあります。

GMOコネクト株式会社の方が2026年9月29日にQiitaへ投稿した解説記事は、外注先に頼んだ資料が思っていたのと違う原因を「頼んだ内容が紙に残っていないこと」とし、AIへの依頼でも同じことが起きると説明しています。GitHubの「Spec Kit」やAWSの「Kiro」といった専用ツールにも触れ、中身は書類のひな形と手順を用意するものだと整理しています。

同じ9月29日に公開された、ソフトバンクのエンジニアによるZennの記事は、さらに一歩進んでいます。人がコードを書いていた頃は設計判断の多くが書く過程で行われていたのに対し、AI時代はその設計をコードの外に書き出す必要が増した、と述べています。

仕様駆動開発で使う4つのファイル

SDDでは、依頼の中身を役割ごとに別のファイルへ分けて書きます。分けることで、どこがあいまいなのかを見つけやすくなるからです。

Qiitaの記事では、次の4つのファイルが紹介されています。

• CLAUDE.md:業務マニュアル。どの作業でも守る決まりごと
• spec.md:発注書・要件定義書。何を、なぜ作るのか
• plan.md:段取り表・設計書。どうやって作るのか
• tasks.md:工程表・作業指示書。作業のチェックリスト

ポイントは、spec.mdに「なぜ作るのか」まで書くことです(記事の例では、ユーザーストーリーの欄に目的を書いています)。目的が書いてあれば、AIが迷ったときに的はずれな判断をしにくくなります。

もう1つの利点は、途中でやりとりが切れても再開できることです。仕様書と工程表を見れば、どこまで進んだかがわかります。

仕様駆動開発の発展形:仕様をテストで確かめる

SDDの次の課題は「コードが本当に仕様どおりか」を誰が確かめるかです。Zennの記事は、ここを人ではなくプログラムに任せる方法を示しています。

記事では、処理の順番を図(Mermaidのシーケンス図)としてMarkdownに書きます。記事の例では「在庫を確保する→注文を作成する→決済する」という順番で、決済に失敗したときは在庫を戻して注文を取り消す流れも図にしています。

そしてテストの実行中に、実際に呼ばれた関数を記録します(記事ではPython 3.12のsys.monitoringを使っています)。図に書いた呼び出しがその順序で記録に現れるかを、プログラムで自動判定するしくみです。

記事によると、こうすることで人のレビューは、コードを1行ずつ確認するだけでなく「この仕様でよいか」という図の差分にも時間を使えるようになります。AIの出力が増えるほど、仕様を確かめる比重を上げるのは理にかなった考え方です。

筆者の考察:仕様駆動開発はインフラの変更作業とよく似ている

SDDの4つのファイルを見て、運用・インフラの人ほど「見覚えがある」と感じるはずです。本番環境の変更作業で書く書類と、ほぼ同じ構造だからです。

筆者なりに対応関係を表にまとめました。

SDDのファイル	インフラ現場での近いもの
CLAUDE.md(決まりごと)	運用ルール・作業時の禁止事項
spec.md(何を・なぜ)	変更申請書の「目的・影響範囲」
plan.md(どう作るか)	作業計画書・切り戻し方針
tasks.md(チェックリスト)	作業手順書・確認項目

本番の変更を口頭の指示だけで進めることは、ふつうは避けます。事前に書いて、レビューして、手順どおりに進めます。SDDは、この当たり前をAIへの依頼にも持ち込んだものだと言えます。

つまり、手順書をきちんと書ける人は、AIに仕事を頼むのも上手になれます。手順書の書き方は実行できる手順書LC4RIの記事、AIへの指示を手順に落とす考え方はAIへの指示が守られない理由の記事が参考になります。

ただし注意点もあります。Qiitaの記事が書くとおり、画面の文言を1つ直すような小さな変更にまで仕様書を作ると、かえって時間がかかります。また同記事は、最初から完璧な仕様書を書こうとせず、作りながら書き足していけばよいとしています。

筆者のおすすめは、目安として1時間以上かかりそうな依頼だけspec.mdを書くことです。監視スクリプトや定型作業の自動化など、あとで直す可能性がある作業から試すとよいでしょう。

AIが作ったテストの見極め方は、AI生成テストが全部通る理由の記事で詳しく扱っています。

まとめ:仕様駆動開発はAIへの「発注書」を書く習慣

• 仕様駆動開発(SDD)は、先に書いた仕様書を正しさの基準にしてAIに作らせる進め方
• 決まりごと・発注書・段取り表・工程表の4ファイルに分け、「なぜ作るか」まで書く
• インフラの変更申請や手順書と同じ構造なので、運用の経験がそのまま活きる

次にAIへ作業を頼むときは、まず「目的」と「完了の条件」を3行だけ書いてから渡してみましょう。

参考リンク

• 「仕様駆動開発(SDD)」って何ですかい?おじさんでも分かるように調べてみた(Qiita) ― 2026-09-29。4つのファイルの役割・小さな変更には向かない点
• AI 駆動開発で「設計」はどこに書くのか ― 振る舞いをテストで検証できる「仕様」にしてみる(Zenn) ― 2026-09-29。シーケンス図とテスト時の呼び出し記録を照合する方法