仕様書駆動開発とは？AI時代の開発で仕様書が主役になる理由

当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。

仕様書駆動開発とは？

仕様書駆動開発では、まず「何を、なぜ作るか」を仕様書に書きます。次にその仕様書を元に技術的な計画を立て、作業に分けて、実装していきます。

ここで大事なのは、仕様書が「最初に書いて終わり」の書類ではないことです。計画も作業もコードも仕様書から生まれるので、仕様を変えたい時は、まず仕様書を直すところから始めます。

「仕様書 駆動開発」はテスト駆動開発と何が違う？

『テスト駆動開発なら聞いたことがある』という方もいるはずです。テスト駆動開発は、先にテストを書いてから、それに通るコードを書く進め方です。

仕様書駆動開発は、その手前の「何を作るか」から先に書く、という点が違います。仕様書の中に確かめ方まで書いておけば、テストも仕様書から作れるので、2つは一緒に使えるんです。

「コードから書く」と「仕様書から書く」の違い

『結局、どっちがいいの？』と迷いますよね。2つの進め方を並べてみると、向いている場面が見えてきます。

その場の指示だけで進めると何が起きる？

AIにその場その場で指示を出して作ると、最初は速く進みます。ところが、指示が積み重なるうちに、最初に決めたことと後の指示が食い違い始めることがあります。

例えば、こんなやり取りに覚えはありませんか。

「さっき、ログインしなくても見られるようにって言いましたよね？」
「その後に、会員だけが見られるようにと指示がありました」

どの指示が正しいのかを決める場所が無いのが、困りごとの元です。仕様書駆動開発では、その「決める場所」を仕様書にしておくわけです。

どちらで進めるかを決める目安

すべての開発を仕様書から始める必要はありません。次の問いに「はい」が多いほど、仕様書から書く進め方が向いています。

逆に、使い捨ての小さな試作なら、コードから書いて速く試すほうが合っていることもあります。場面で使い分けて大丈夫ですよ。

仕様書に書く4点：目的・振る舞い・制約・確かめ方

『仕様書と言われても、何を書けばいいの？』という方のために、編集部では書く中身を4点にまとめました。

振る舞いは「どんな時に、何をする」の形で書く

振る舞いを書く時は、「どんな時に」と「何をする」をセットにするのがコツです。公開されている開発ツールの中には、「WHEN [条件や出来事] THE SYSTEM SHALL [期待する振る舞い]」という EARS と呼ばれる型で受け入れの基準を書くものもあります。

日本語なら、「〜の時、システムは〜する」の形で書けば同じように伝わります。主語と条件があいまいな文は、AIも人も読み違えやすいんです。

仕様書の記入例：訪問予定を見る機能

編集部が作った架空の例で、先ほどの「訪問予定を見る」機能の振る舞いと確かめ方を書いてみますね。

振る舞いと確かめ方を同じ行に書いておくと、AIに実装を頼む時も、できあがりを確かめる時も、同じ表を見れば済みます。

AI駆動開発で設計書はどう変わる？

AI駆動開発でも、設計書が要らなくなるわけではありません。むしろ、AIに渡す設計書は「人が読んで分かる」だけでなく「AIが読み違えない」書き方が求められます。

APIの決めごとなら OpenAPI Specification（2026年10月時点で確認できた版は v3.2.1）、文書の書き方なら Markdown の仕様の CommonMark のように、決まった形で書いておくと、AIも人も同じ読み方ができます。API仕様書の書き方はAPI仕様書の書き方で、Markdownでの書き方は仕様書・設計書をMarkdownで書くで紹介しています。

公開されているツールキットの流れ

仕様書駆動開発の考え方を、道具として公開している例を2つ紹介しますね。どちらが良いという話ではなく、流れの参考として見てみてください。

前者は公開時、仕様・計画・作業のそれぞれをコマンドで進める形でした。2026年10月時点の説明では、コマンドの名前が変わっています。後者は、要求を requirements.md、設計を design.md のような文書として作る形です。

道具を使わなくても始められる

『新しい道具を入れないと、仕様書駆動開発はできないの？』と思った方もいますよね。実は、考え方だけなら今日から試せます。

Markdownのファイルに4点を書き、それを生成AIに渡して「この仕様書に沿って計画を作ってください」と頼むだけでも、流れは同じです。生成AIへの頼み方は仕様書をAIで作る｜生成AIに下書きさせる手順で紹介しています。

初めて試すなら、社内の小さな業務ツールのように、失敗しても困らない物から選ぶのがおすすめです。1回やってみると、『仕様書のどこが足りないと、AIの計画がずれるのか』が体でつかめます。

ずれた所は、仕様書に書き足して次に生かしましょう。書き足した仕様書そのものが、チームの財産になっていきます。

AIに任せるほど、人が書く仕様書が大事になる

AIに任せる作業が増えると、人の仕事が無くなるように感じるかもしれません。でも実は、人が決める所はかえってはっきりしてくるんです。

IPAの「超上流から攻めるIT化の原理原則17ヶ条」には、「要件定義書はバイブルであり，事あらばここへ立ち返るもの」という一条があります。仕様書駆動開発の考え方は、この原則をAIとの開発に持ち込んだもの、と見ることもできます。

同じ17ヶ条には、「機能要求は膨張する。コスト，納期が抑制する」という一条もあります。AIで作るのが速くなっても、何を作り、何を作らないかを決めるのは人の役目のままです。

仕様書を確かめる時の観点

AIが下書きした仕様書を読む時は、次の観点で見てみてください。書いてあることより、書いていないことに気づけるかが大事です。

要件定義書の書き方の基本は要件定義書とは？目的・書く内容・作る流れで紹介しています。仕様書駆動開発の仕様書も、この考え方が土台になります。

仕様書駆動開発でよくある相談

仕様書駆動開発に近い話題で、知恵袋で多く読まれている相談を要約して答えてみますね。

相談1：仕様が明確でないものを、バグを出さずに作るには？

『仕様がはっきりしないまま作ることになった。バグを出さずに作るにはどうすればいい？』という相談です。

結論から言うと、あいまいな所を作る前に書き出して、決めてもらうことです。「ここは〜と考えて作ります。違っていたら教えてください」と、自分の考えを仕様書に書いて確かめてもらう形にすると、話が進みやすくなります。

仕様書駆動開発は、まさにこの「書いてから確かめる」を毎回やる進め方なんです。

相談2：テスト仕様書は、プログラムを作る前と後のどちらで作る？

『テストケースはプログラムを作る前に用意するもの？』という相談です。

仕様書駆動開発の考え方なら、答えは「前」です。仕様書に確かめ方まで書いておけば、それがそのままテストの元になります。テスト仕様書の書き方はテスト仕様書とは？書き方・項目とテンプレートの使い方で紹介しています。

相談3：テスト駆動開発は、現場で本当に使われている？

『テスト駆動開発という言葉は聞くけれど、実際の現場でやっているの？』という相談です。

使い方は現場によってさまざまで、全部の開発で取り入れている所もあれば、大事な部品だけに使う所もあります。仕様書駆動開発も同じで、まずは小さな機能1つから試してみるのが始めやすい方法です。

相談4：設計の細かい所を、作る人に任せたい

『設計者がプログラムの細かい所まで決めず、作る人に任せる進め方はできる？』という相談です。

できます。その時は、任せる所と任せない所の線を仕様書に書いておくのがコツです。目的・振る舞い・制約・確かめ方の4点さえ決まっていれば、作り方の細かい所は作る人に任せても、できあがりを判定できます。

AIに作業を任せる時も、考え方はまったく同じなんです。

仕様書を書ける力は、これからの仕事でも生きる

AIと一緒に開発する場面が増えるほど、目的や振る舞いを言葉にできる人の役目は大きくなります。今の職場で要件定義や設計に関わる機会を増やすのも、資格を取ってから動くのも、どちらもよい道です。

要件定義や設計書を書く経験は、上流工程を任される職場で評価されやすいものです。今の担当工程から一歩進みたい方は、求人の仕事内容を比べてみると道が見えてきます。

仕様書を書く仕事そのものについては、仕様書を書く仕事とは？SE・PM・社内SEの仕事内容と違いで紹介しています。

よくある質問

まとめ

あわせて読みたい

仕様書をAIで作成する｜生成AIに下書きさせる手順と確かめる所

要件定義書とは？目的・書く内容・作る流れをやさしく解説

仕様書とは？意味と目的、設計書・要件定義書との違い