【仕様駆動開発】非エンジニアが「作って」を卒業して確実にアプリを作る方法

2026年6月12日2026年6月14日

AIに「こういうツールを作って」と頼めば、コードが返ってくる。バイブコーディングのいちばん手軽なやり方です。でも、この一発勝負には弱点があります。動くけれど、正しいとは限らない。意図とずれていたり、見えない所で壊れていたり、規模が大きくなると崩れたり——。

この弱点を、プログラマーは「仕様駆動開発」という方法で防いでいます。本記事で紹介するエンジニア向けの仕様駆動開発（仮の名称として、プロンプト仕様駆動開発）は、その考え方をそのまま受け継ぎつつ、非エンジニアでも回せる形に翻訳した方法です。これが、この先ツールを作っていくための土台になります。

1. 結論：SDDの概念を受け継ぎ、非エンジニア向けに翻訳した

プロンプト仕様駆動開発を一言でいうと、「作って」の一発ガチャをやめ、要求 → 設計 → テストと段階を踏んで、AIと確実に作っていく方法です。骨格は、プログラマーが使う「仕様駆動開発（SDD）」を基本として作られています。「仕様駆動開発（SDD）」では専用のツールを使用することが多いのですが、プロンプト仕様駆動開発では決まったプロンプトを順に渡していくだけで回せるところです。使う道具は、Web版のClaudeと、Claude Codeの2つだけです。

この記事では、まず土台になっている「仕様駆動開発」とは何かを説明し、次に、それが非エンジニアにはそのままでは使えない理由、最後に、それをどう翻訳したのかを順に見ていきます。

2. プログラマーが使う「仕様駆動開発」とは

仕様駆動開発（SDD：Spec-Driven Development）は、いきなりコードを書き始めず、先に「何を作るか」の仕様を固めてから進める開発の進め方です。要求をはっきりさせ、それをもとに設計し、テストで確かめ、実装する——という段階を踏みます。

これは特別な流派ではなく、いま開発の現場で広く取り入れられている考え方です。AIと組み合わせる手法としても定着していて、GitHub の Spec Kit、AWS の Kiro など、SDDを支えるフレームワークが複数登場しています。バイブコーディングを含め、「AIにコードを書かせる」現場ほど、この「先に仕様を固める」やり方が重視されています。

AIは指示されたものを高速に作りますが、指示された情報が不完全な場合、情報を確率的に補完しながら作ってしまいます。補完したものが仕様にはまれば問題ないのですが、大抵の場合、意図したものではないです。確率的な補完を防ぐために、仕様としてきちんと書いておけば、確率的な補完を防ぎ、意図に沿ったものを作れる——これがSDDの中心にある考え方です。

MATSU

少ないテキストからアプリを作ろうとしても結果的にできてしまうことがAIの強みでもあり、弱みでもあるということですね。

3. なぜ、非エンジニアにはそのまま使えないのか

では、その優れたSDDを非エンジニアがそのまま使えるかというと、つまずきます。理由は2つあります。

SDDでつまずく理由①：入り口の問題

一つは、入り口の問題です。既存のSDDツールは、「自分で要求を書ける」ことを前提にしています。でも非エンジニアにとって、いちばんの難所はまさにそこ——「何を作りたいのか」を、きちんと言葉にすること自体が難しいのです。頭の中にぼんやりした困りごとはあっても、それを仕様の形に書き出せない。最初の一歩で止まってしまいます。

SDDでつまずく理由②：中身が見えない

もう一つは、中身が見えない問題です。専用ツールは、要求から仕様書や実装までを自動で進めてくれますが、その過程は非エンジニアにとってブラックボックスです。何がどう変換されて、なぜそのコードになったのかが見えない。見えないものは、確認も判断もできません。これでは「AIに丸投げ」と変わらず、結局「動くけれど正しいか分からない」状態に逆戻りしてしまいます。

MATSU

比較的新しいツールでもあるのでCLIで操作するなど、非エンジニアには難しい部分がやっぱりありますよね。

4. プロンプト仕様駆動開発：何を同じにし、何を変えたか

プロンプト仕様駆動開発は、この2つのつまずきを解くために作りました。ポイントは「SDDの良さは捨てず、非エンジニアの障壁だけを取り除く」ことです。

同じところ：フレームワークと概念はSDDのまま

骨格は、業界標準のSDDと一致しています。「要求を唯一の種とし、設計・テストへ段階を踏む」「各段階が前の成果物を読む」「仕様こそがプロンプト」——どれも共通です。だから、ここで身につけた考え方は、後で Spec Kit や Kiro のような専用ツールに移っても、そのまま通用します。我流ではなく、標準と地続きの方法だということです。

変更点①：要求仕様のプロンプトに「問診」を組み込んだ

3章の「入り口の問題」への答えが、これです。出発点である要求仕様（Phase 1）のプロンプト自体に、要求を引き出す「問診」の役割を持たせました。ここでは、Web版のClaudeを「聞き上手な相談相手」に仕立て、対話を通して要求を引き出してもらいます。曖昧なら掘り下げ、欲張りすぎたら「今回やらないこと」に回し、必要なら実態を調べる。質問に答えていくうちに、いつのまにか要求仕様の材料がそろい、そのまま要求仕様書になる——という仕組みです。「何を作りたいか書けない」、もっと言えばプログラムで何ができるかわからないという、非エンジニア最大の壁を越えるための入り口です。

変更点②：ブラックボックスを開いた

3章の「中身が見えない問題」への答えが、これです。専用ツールに自動で任せるのをやめ、各段階を決まったプロンプトで、手で順に回していく形にしました。一見、遠回りに思えます。でもこれには大きな意味があります。要求仕様書から設計、テスト、実装まで、各段階で何が作られ、どう次へ渡るのかが、すべて目に見えるのです。

見えるから、各仕様書を自分で確認し、場合によっては修正してから次に進める。舵を握るのは、最後まで人間です。これは、原理を体で理解するための「補助輪」のようなもの。中身が見える状態で一度回しておけば、後で自動化された専用ツールを使うときも、何が起きているかが分かるようになります。

5. 全体像：3つのフェーズと「種」

全体の流れを図にすると、こうなります。左から右へ、Phase 1（要求仕様）→ Phase 2（設計＋実装）→ Phase 3（テスト）と進みます。出発点の Phase 1 では、要求仕様のプロンプトが問診で要求を引き出しながら、そのまま要求仕様書を書き上げます。上段が Web Claude で行う「考える・決める」作業、下段が Claude Code で行う「実装する」作業です。