「仕様駆動開発(SDD)」って何ですかい？おじさんでも分かるように調べてみた

はじめに

前回、AIに仕事を安定して任せるための仕組みとして「ハーネス」について取り上げました。今回は、最近よく見かける「仕様駆動開発(Spec-Driven Development、以下SDD)」を。Claudeに教えてもらいつつまとめ上げました。

名前は難しそうですが、考え方は会社の仕事でよくある、次の場面と同じです。

外注先に頼んだ資料が届いたら、思っていたのと違った。「こういう意味で頼んだのに」と言っても、「いえ、口頭ではこう伺いました」と返される

こうなる原因は、外注先の腕ではなく、頼んだ内容が紙に残っていないことにあります。AIに開発を頼むときも、まったく同じことが起きます。SDDは、AIに頼む前に「発注書」をきちんと作っておく進め方のことです。

この記事では、会社の経費精算を例にして、専門用語をなるべく会社の書類に置き換えながら説明します。ITに詳しくない方でも、仕事で発注や稟議を経験したことがあれば、流れを追えると思います。

SDDって、そもそも何？

SDDは、作りたいものを文章(仕様書)にきちんと書き、その仕様書を「正しさの基準」にしてAIにプログラムを作らせる進め方です。

ポイントは、直したいことが出てきたときに、プログラムを直接いじらず、先に仕様書を直すことです。プログラムは仕様書から作られる成果物であり、「これで合っているか」の判断はいつも仕様書に照らして行います。

家づくりで例えると、大工さんに「いい感じの家を建てて」と口頭で頼むのが、これまでのやり方です。腕の良い大工さんほど、それらしい家を建ててくれます。ただ、窓の位置や部屋数が想像と違っていても、それを「間違い」と言い切る根拠がありません。設計図があれば「設計図と違います」と言えますし、変更したいときも、設計図を直してから工事に入れます。SDDは、AIとの開発に設計図を持ち込む考え方です。

会社の書類に置き換えると

この記事に出てくる用語を、会社の書類に置き換えると次のとおりです。

記事に出てくる言葉	中身	会社でいうと
CLAUDE.md	AIに毎回読ませておく決め事のメモ	業務マニュアル・申し送りノート
仕様書(spec.md)	何を・なぜ作るか	発注書・要件定義書
計画書(plan.md)	どうやって作るか	段取り表・設計書
タスク表(tasks.md)	作業を細かく分けたチェックリスト	工程表・作業指示書
プランモード	作業を始めず、段取りだけ考えさせる機能	着工前の打ち合わせ
受け入れ条件	「こうなっていれば完成」という合格基準	検収基準

「受け入れ条件」は、外注先から納品を受けるとき、「この条件を満たしていれば検収OK」と決めておく基準のことです。SDDでは、これを仕様書に書いておきます。

専用ツールがなくてもできる

SDDを調べると、GitHubの「Spec Kit」やAWSの「Kiro」といった専用ツールが出てきます。ただ、中身を見ると、やっていることは書類のひな形と手順を用意しているだけです。そのため、Markdown(文字だけで書く形式のファイル)と、普段のClaude Codeがあれば、専用ツールなしでも同じことができます。必要なのは次の3つです。

• 仕様書・計画書・タスク表を書くファイル
• 「仕様書を基準にする」という決め事
• 各段階で、次に進む前に人間が確認するという手順

今回の題材：経費精算の承認ルール

例として、社内の経費精算システムで、申請された経費を「誰の承認が必要か」に自動で振り分ける機能を作る場面を考えます。実際の会社でよくある、次のような悩みがあるとします。

• 金額によって、課長承認なのか部長承認なのかを、経理担当が毎回目で見て判断している
• 忙しい月末は見落としが出て、承認が抜けたまま支払われてしまうことがある

一見シンプルですが、実際に作らせると「ちょうど1万円のときはどっち？」といった細かい判断が必ず出てきます。こういう場面が、SDDの効き目を分かりやすく示せると思います。

この記事でやること

• 仕様書を置くフォルダ構成を用意する
• CLAUDE.mdに、仕様書を基準にするという決め事を書く
• 仕様 → 打ち合わせ → 段取り → 作業表 → 実装 → 変更 の流れを、Claude Codeへの指示文だけで回す

環境

項目	内容
AIエージェント	Claude Code
必要なもの	Markdownファイルのみ(追加のツールは不要)
題材	経費精算の承認ルール判定(想定した業務例)

1. フォルダ構成を用意する

まず、書類の置き場所を決めます。機能ごとにフォルダを分け、その中に3つのファイルを置きます。

project/
├── CLAUDE.md          ← 業務マニュアル(全体の決め事)
└── specs/
    └── 001-承認ルール判定/
        ├── spec.md    ← 発注書(何を・なぜ作るか)
        ├── plan.md    ← 段取り表(どう作るか)
        └── tasks.md   ← 工程表(作業のチェックリスト)

書類ごとに置き場所を決めておくのは、会社でファイルサーバーのフォルダを整理するのと同じ考え方です。あとから探しやすく、AIにも「ここを見て」と指示しやすくなります。

2. 業務マニュアル(CLAUDE.md)に進め方を書く

次に、CLAUDE.mdに「仕様書を基準にする」という決め事を書いておきます。Claudeは作業を始めるたびにこのファイルを読むので、毎回口頭で説明し直す必要がなくなります。新人に渡す業務マニュアルの1ページ目のようなものです。

CLAUDE.md

## 開発の進め方
- 機能追加は specs/ 以下の spec.md を基準とする
- spec.md に書かれていない機能は実装しない。必要なときは、先に spec.md の変更を提案する
- 実装の前に plan.md と tasks.md を作り、確認を取ってから着手する
- 完成の判断は、spec.md の受け入れ条件をすべて満たしているかで行う

「書かれていない機能は実装しない」という一文が大事です。頼んでいない機能まで気を利かせて作られてしまう、という困りごとを防げます。

3. 発注書(spec.md)を書く

作りたい機能のフォルダを作り、spec.mdに「何を・なぜ作るか」を書きます。自分で書いてもよいですし、Claudeに下書きしてもらっても構いません。

specs/001-承認ルール判定/spec.md に、次の機能の仕様書を書いてください。「ユーザーストーリー」「受け入れ条件」「対象外」の3つの見出しで構成し、プログラムの作り方には触れないでください。まだコードは書かないでください。
機能：経費精算で申請された金額に応じて、必要な承認者(課長・部長)を自動で判定する。

できあがる仕様書は、たとえば次のような形です。

specs/001-承認ルール判定/spec.md

# 機能仕様: 経費精算の承認ルール判定

## ユーザーストーリー
経理担当として、申請された経費に必要な承認者を自動で知りたい。
承認の抜けや、承認者の見落としを防ぐため。

## 受け入れ条件
- 1万円未満の申請は、承認不要と判定する
- 1万円以上5万円未満の申請は、課長承認が必要と判定する
- 5万円以上の申請は、部長承認が必要と判定する
- 領収書が添付されていない申請は、金額にかかわらず差し戻しと判定する
- 判定結果には、理由を表示する(例：「3万円のため、課長承認が必要です」)

## 対象外
- 会計システムへの仕訳データの連携
- 海外出張の外貨換算

書くときのコツは2つあります。1つ目は、使う技術の話を入れず、「業務としてどうなっていればよいか」だけを書くことです。2つ目は「対象外」を書いておくことです。これがないと、AIは気を利かせて、頼んでいない会計システムとの連携まで作り始めることがあります。

受け入れ条件は、後から「できているか」を○×で確認できる書き方にします。「使いやすいこと」のような曖昧な書き方より、「1万円以上5万円未満は課長承認」のように、数字で確かめられる形が向いています。

4. 打ち合わせ：曖昧な点を質問してもらう

仕様書ができたら、すぐに作らせずに、Claudeに質問させます。発注前の打ち合わせにあたる工程です。

spec.md を読んで、実装するうえで曖昧な点や、人によって解釈が分かれそうな点を質問してください。まだコードは書かないでください。

すると、次のような質問が返ってきます。実際の業務で必ず問題になるような点ばかりです。

• ちょうど1万円の申請は、承認不要ですか。課長承認ですか。
• 1件の申請に領収書が複数ある場合、合計金額で判定しますか。それとも1枚ずつですか。
• 課長が休みのとき、代わりに承認する人はいますか。

「1万円以上」と書いたつもりでも、口頭で頼んでいたら「1万円未満まで承認不要」と伝わっていたかもしれません。こういう境目の取り違えは、業務システムでは実際によく起きます。仕様書の段階で見つけておけば、直すのは文章1行で済みます。プログラムができてから見つかると、作り直しになります。

質問に答えたら、答えをspec.mdに書き足してもらいます。

いまの回答内容を spec.md の受け入れ条件に反映してください。

会議で決めたことを議事録に残しておくのと同じで、あとから「言った・言わない」にならずに済みます。会話の中だけで決めたことは、AIとの新しいやりとりを始めると消えてしまいますが、仕様書に書いておけば残ります。

5. 段取り表(plan.md)を作ってもらう

仕様が固まってから、「どうやって作るか」を決めます。ここで使うのがプランモードです。キーボードの Shift+Tab で切り替えると、Claudeは実際の作業には手を付けず、段取りを考えるだけの状態になります。工事の前に、現場監督と段取りを確認する打ち合わせと同じです。

spec.md をもとに、実装の段取りを plan.md にまとめてください。今あるプログラムとのつなぎ方、追加・変更するファイル、動作確認の方法を含めてください。

「何を作るか」と「どう作るか」を別のファイルに分けておくと、後から仕様を読み返すときに、技術の話に埋もれずに済みます。発注書と設計書を分けて管理するのと同じ考え方です。

6. 工程表(tasks.md)を作り、抜けを確認する

段取りができたら、作業を細かく分けてもらいます。

plan.md を作業単位に分けて、tasks.md にチェックリスト形式で書いてください。そのうえで、spec.md の受け入れ条件がすべて、いずれかの作業または動作確認でカバーされているか確認し、漏れがあれば教えてください。

後半の確認が大事です。たとえば「領収書がなければ差し戻す」という条件を確かめる作業が工程表に入っていなければ、ここで指摘されます。工事に入る前に、発注書と工程表を突き合わせて、やり忘れを見つける工程です。

7. 実装してもらう

ここまで整ってから、ようやく作らせます。

tasks.md を上から順に実装してください。1つ終わるごとにチェックを付けてください。

ここから先は、これまでのClaude Codeでの作業とほとんど変わりません。違うのは、Claudeが迷ったときに立ち返る場所が、会話の履歴ではなく仕様書になっていることです。作業の途中でやりとりが切れても、工程表のチェックを見れば、どこまで進んだかがすぐ分かります。

8. ルールが変わったとき

実際の会社では、ルールはよく変わります。たとえば、途中で「課長承認の上限を、5万円から10万円に引き上げることになった」と連絡が来たとします。

このとき、Claudeに「5万円を10万円に変えて」と直接頼むのではなく、まず仕様書を書き換えます。

spec.md の受け入れ条件を次のように変更しました。plan.md と tasks.md を更新し、プログラムにも反映してください。
変更：1万円以上10万円未満は課長承認、10万円以上は部長承認。

遠回りに見えますが、こうしておくと、仕様書とプログラムの内容がずれません。半年後に「なぜ10万円なのか」「この条件はいつ決まったのか」と聞かれたとき、仕様書を見れば答えが分かります。就業規則を変えるときに、まず規則の文面を改訂してから、運用を変えるのと同じ順序です。

9. 手順を型にまとめる(任意)

同じ指示文を毎回打つのが面倒になってきたら、この流れをClaude Codeの「スキル」(決まった手順を登録しておく機能)にまとめておくと楽になります。よく使う業務を、作業手順書にまとめておくのと同じ発想です。

最初から作り込む必要はありません。何度か手で回してみて、自分たちの仕事に合う形が見えてから、まとめるほうが使いやすいものになります。

手順のまとめ

段階	使う書類	やること	次に進む条件
準備	業務マニュアル(CLAUDE.md)	仕様書を基準にする決め事を書く	—
発注書	spec.md	何を・なぜ作るかを書く	受け入れ条件と対象外が書けている
打ち合わせ	spec.md	質問させて、答えを書き足す	曖昧な点がなくなった
段取り	plan.md	プランモードで、どう作るかを決める	内容を読んで納得できた
工程表	tasks.md	作業に分け、受け入れ条件との抜けを確認する	抜けがない
施工	tasks.md	上から順に作り、チェックを付ける	受け入れ条件をすべて満たした
変更	spec.md	先に仕様書を直してから反映させる	—

専用ツールとの比較

	ツールなし	Spec Kitなどの専用ツール
始めるまでの手間	なし(文書ファイルだけ)	導入と初期設定が必要
書類の分量	仕事に合わせて自由に減らせる	ひな形に沿って書く
手順の守りやすさ	自分たちで守る必要がある	決まった手順が自然と守られる
向いている場面	個人・少人数、小〜中規模の機能	複数人のチームで手順をそろえたいとき

まずはツールなしで回してみて、「仕様書を飛ばして、つい直接頼んでしまう」ことが増えてきたら、そのときに専用ツールを検討すればよいと思います。

前回の「ハーネス」との関係

前回のハーネスと、今回のSDDは、役割が違います。

	ハーネス	SDD
整えるもの	AIの働き方	作るものの中身
答える問い	どう働くか	何を作るか
会社でいうと	就業規則と検品体制	発注書と設計図

両方そろって初めて、「何を作るかがはっきりしていて、しかも毎回同じ品質で作ってくれる」状態になります。

before / after

	SDDなし	SDDあり
「思っていたのと違う」	完成してから分かりやすい	発注書の段階で気づける
境目の取り違え(1万円ちょうどなど)	運用が始まってから発覚する	打ち合わせの質問で先に見つかる
ルール変更の手順	プログラムを直接直す	仕様書を直してから反映する
「なぜこうなっているか」の説明	作った本人の記憶頼み	仕様書を見れば分かる
やりとりが途切れたとき	前提を最初から説明し直す	仕様書と工程表を見れば再開できる

注意したいこと

SDDは、何にでも使えばよいわけではありません。画面の文言を1つ直すような小さな変更にまで発注書を書いていたら、かえって時間がかかります。今回の承認ルールのように、複数の画面や既存の仕組みにまたがり、間違えたときの手戻りが大きい機能で使うのがよいと思います。

また、最初から完璧な仕様書を書こうとしなくても構いません。仕様書は、作りながら書き足していく文書です。一度作ったら変えない、昔ながらの進め方とは違います。

まとめ

SDDは、AIに渡す指示を、その場の口頭の依頼から、書類(仕様書)に置き換える考え方です。専用のツールがなくても、文書ファイルを3つ用意し、業務マニュアルに数行書き足し、各段階で確認を挟むだけで始められます。

外注先に仕事を頼むとき、発注書を出して、打ち合わせで疑問点をつぶし、検収の基準を決めておくのは、多くの会社で当たり前にやっていることです。SDDは、それと同じことをAIとの開発に持ち込んでいるだけです。前回のハーネスが「教えたことが積み上がる仕組み」だとすれば、SDDは「頼みたいことが正しく伝わる仕組み」だと思います。