【仕様駆動開発】非エンジニアが確実にアプリを作る方法

AIに「こういうツールを作って」と頼めば、動くものはすぐに出てきます。けれど、それが自分の狙いどおりに正しく動いているかは、コードを読めない限り確かめようがありません。プロンプト仕様駆動開発（PSDD）は、仕様書とルールをAIに渡し、正しさを文書で確かめながらツールを作る進め方です。第7.0版でスキルとして配れるようになりました。一度用意すれば、あとは決まった言葉で呼ぶだけで回せます。

AIに任せれば動くものはできるが、正しいとは限らない

AIで、自然言語のままツールを作れるようになった

ここ数年で、AIによるコーディングの事情は大きく変わりました。コードを書かなくても、日本語の指示だけでツールが形になります。特にClaude Codeによるコーディングは実用の水準に達し、活用の幅が広いです。ただし、思いつくままに「作って」と頼むと、動きはするものの、要求とずれたものが出てきます。動くことと、狙いどおり正しく動くことは別です。そこで要るのが、先に仕様を決めてから作る仕様駆動開発（SDD）という考え方です。

エンジニアが使う仕様駆動開発

いまエンジニアの間では、思いつきで書くバイブコーディングから脱却し、仕様駆動開発で意図どおりのコードを作る流れが広がっています。エンジニア向けの道具として、GitHub Spec Kit や AWS Kiro があります。どちらも、作るものの要件をまとめ、Claude Codeなどのエージェントに渡して形にします。ただし、これらはエンジニアが使う前提で作られているため、非エンジニアには敷居が高く、細かい理解を求められます。

非エンジニアでもできる仕様駆動開発

非エンジニアにとって、仕様駆動開発の道具はなじみが薄いものです。とくに、仕様書として何を書けばよいかがわかりません。その問題を解決したのが、プロンプト仕様駆動開発（略してPSDD）です。問診という形で、どんなアプリを作りたいのかを対話しながら引き出し、要求仕様に落とし込んでいきます。この一連のやりとりだけで仕様書がそろうように作りました。

プロンプト仕様駆動開発（PSDD）の中身

PSDDの核心は、問診とドキュメント管理にあります。導入したら、まず問診で「何を作るか」を引き出し、それを仕様書に落とします。問診で具体化した困りごとが、以下の表の各仕様書に残るので、同じものを何度でも再現できます。さらに、要求・設計・テストをIDで結ぶことで、要求がコードとして具体化され、機械的なテストまで一貫してつながります。対応の抜けも、このIDをたどって検査できます。

コードが読めなくても、出てくる文書を読めば正しさを確かめられる。実装されているかはトレーサビリティマトリクスで確認できます。

AIは開発作業の大半を自律的にこなす。人がやるのは、問診で要求を伝えることと、仕様書や期待値の文書で正しさを確かめること。コードを書くことでも、読むことでもない。

PSDDの導入方法

PSDDは、2つのスキルに分かれています。1つはWeb Claudeに入れる「psdd」で、問診と仕様書づくりを担います。もう1つはClaude Codeに入れる「psdd-code」で、コードの実装とテストの実行を担います。この2つは別々に管理されるため、それぞれの環境にセットアップします。以下、環境ごとに手順を示します。

Web Claudeのセットアップ

Web Claude側は、仕様書づくりを担う「psdd」を登録します。配布用のZIPを設定画面から読み込みます。

Claude Codeのセットアップ

Claude Code側は、skill（psdd-code）+CLAUDE.md+pssd.pyを作業フォルダに配置するだけです。

親フォルダ/
　プロジェクトA/　　　*アプリを作るフォルダ
　プロジェクトB/　　　*アプリを作るフォルダ
　.claude/　　　　　 *skillが入っているファイル
　CLAUDE.md
　psdd.py

これで導入は完了。あとは合言葉を打つだけ。

新規アプリは問診から始める

導入後、新しいツールは4つの合言葉を順に呼んで作ります。Web Claude側でやるのは、問診に答えることと、出てきた仕様書を確認することだけです。コードはこの段階では書きません。Web Claudeでは仕様書やコードの作成を担当し、Claude Codeでは実装、テスト実行を担当するイメージになります。テストは設計とテストコードに分かれています。ちなみにWeb Claudeの推論モデルはOpus 4.6以上のモデルを使うことをおすすめしています。sonnet4.6でも実行できましたが、軽微な修正が多い印象でした。

4つの合言葉を、要求から順に呼ぶ

新しいチャットで /psdd と打ち、続けて合言葉を打つと、そのフェーズが立ち上がります。各フェーズは別チャットで動き、前のフェーズが出した文書だけを入力に取ります。会話の記憶ではなく文書を頼るので、同じ文書からは同じ結果が出ます。

/psdd
要求          ← 1つ目。ここから問診が始まる

「要求」の問診で、要求仕様書と版管理票を作る

合言葉「要求」は問診です。欲しいツールを対話で引き出し、要求仕様書にまとめます。特に入力データの様式（どんなファイルの、どこに何が入るか）を詰めます。ここが曖昧だと、後でテストに与える入力が作れません。

このとき版管理票も同時に発行されます。これは以降ずっと使う、案件の最新状態の管理表です。

砂糖さん

版管理票って、何を書いたデータなんですか？

MATSU

版管理票は「どの文書があって、それぞれ確定済みか未着手か」を1枚に記した一覧です。人・Web Claude・Claude Codeの三者が共通で読み、ドキュメントの管理をするために使います。

「設計」で、作り方と正解を決める

合言葉「設計」では、処理の流れと、各関数が何を受け取って何を返すかを設計仕様書にまとめます。ここでもコードは書きません。同時に、各入力の「正しい出力（期待値）」を人が決めて期待値表に記します。この正解の出所をオラクルと呼びます。

オラクル（正解）はAIに作らせないことが重要です。AIも全ての意図を汲み取れる万能装置ではなく、つくる人の正解はつくる人にしかわかりません。だからオラクルは、つくる本人が手計算・実測・規格を根拠に与えます。

「テスト設計」で、確かめる観点を組む

合言葉「テスト設計」では、要求仕様書と設計仕様書をもとに、壊れやすいかどうかの観点（しきい値ちょうど・月末・不備データなど）でテスト設計仕様書を組みます。実装コードを見せてしまうと、通るテストを設計してしまうから実装コードとは違う場所でテスト設計仕様書を作成します。あわせて、担当の無い要求（漏れ）が無いかをトレーサビリティマトリクスで確認します。

「テストコード」で、観点を動くコードにする

最後の「テストコード」で、観点を実際のテストコード（pytest）にします。入力は、テスト設計の観点・期待値表の正解・設計の入口出口を参照して、実装コードを見せずテストコードを作成します。これでWeb Claude側は完了です。

Web Claudeでやるのは、ドキュメント作りだけです。ドキュメント作りのために、要求を伝えることと、正解をユーザーが伝えます。

仕様書から実装・テスト実行

仕様書一式ができたら、Claude Code側でコードにします。ここで使うスキルは「psdd-code」です。実装とテスト実行は、あえて別々のチャットに分けて回します。作った本人がそのままテストまで通すと、テストや実装を甘くする方向に流れやすいためです。手を分けることで、それを構造で防ぎます。

実装は、設計仕様書からコードを書く

実装チャットに設計仕様書一式を渡すと、Claude Codeがそれを読んでコードを書きます。仕様書が正本であり、Claude Codeはそれを読みますが、書き換えることはしません。何が確定した文書かは、版管理票を見て判断します。

砂糖さん

Claude Codeが勝手に仕様を変えてしまうことはないんですか？

MATSU

ありません。常駐ルール（CLAUDE.md）で「仕様書は読むが書き換えない」と定めてあります。仕様を直したいときは、後述の変更フェーズでWeb Claude側から直します。

テスト実行は、別チャットで走らせる

実装が済んだら、別に立てたテスト実行チャットで、もう一度、「psdd-code」とうってスキルを呼び出し、用意しておいたテストを実コードに走らせます。ここでやるのは、テストを走らせて合否を見ることだけになります。テストコードの中身は修正せず、赤（不正解）か緑（正解）か、何件通ったかで判断します。

動かして、実際に動くところまで確認する

全部が緑（正解）になったら、いよいよアプリの起動です。実際に起動して動かします。デモ用のデータがあるならデモデータを読み込み、操作、結果表示までを一度通し、想定どおりに動くことを目で確かめます。

Claude Code側でやるのは、仕様書からコードを作ること、テストを走らせることです。実装されたアプリは自動テストではできない部分があり、それはトレーサビリティマトリクスに書かれます。実際に触るときは、トレーサビリティマトリクスに書かれる自動テストで評価できなかった項目を中心に触ってみましょう。

実装コードは仕様書とマトリクスで確認

テストが全部緑になり、実際に動いても、それで終わりではありません。テストが通ることと、狙いどおり正しいことは別だからです。最後に、人が自分の目で確かめます。確かめる相手はコードではなく、仕様書とマトリクス、そして期待値表です。コードは読めなくてかまいません。

トレーサビリティマトリクスで、要求に漏れが無いか見る

トレーサビリティマトリクスは、要求ID・設計ID・テストIDの対応を並べた表です。「どの要求が、どこで実装され、どこで検証されたか」を、IDをたどって目で追えます。ここで見るのは、担当の無い要求（漏れ）がゼロかどうかです。空欄があれば、その要求はまだ実装かテストのどちらかが欠けています。

期待値表の正解と、現物を突き合わせる

次に、実際に動かして出てきた結果を、期待値表の「正しい出力」と一つずつ突き合わせます。これは、設計のときに自分の手で決めた正解です。この正解と現物が一致し、触ってみて違和感がなければ、そのツールは正しく動いています。質問された内容がそのまま反映されたのか、確認する意識でやるとやりやすいと思います。

砂糖さん

マトリクスと期待値表、両方いるんですか？

MATSU

作るものの規模によります。機能が1つの小さなツール（単機能）ではマトリクスを作らないので、そのぶん期待値表の突き合わせを厚くして、人の目で補います。機能が複数ある場合（多機能）は、マトリクスで漏れを、期待値表で正しさを、両面から確かめます。

自動テストが緑（正解）になっただけでは、まだ「動く」だけ。トレーサビリティマトリクスで漏れが無いことや、期待値表で正解と一致することを、人が確かめて初めて正しく動くアプリと言えます。

完成した版はexeに固めて配る

確認まで済んで版を閉じたら、そのツールを実行ファイル（exe）にまとめて配れます。exe化はClaude Code側の仕事です。新しいチャットで /psdd-code と打ち、「配布」を指示すると、閉じた版のコードを1つのexeに固め、dist/ フォルダにバージョン付き（例：アプリ名_v1.0.exe）で出力します。

使う人は、このexeを受け取って起動するだけです。Pythonの用意も、コードの知識も要りません。開発の場所（コード・試し・次の版づくり）と、配ったexeは切り離されているので、配ったあとに開発を続けても、利用者の手元のexeには影響しません。

アイコンを付けたいときは、icon/ フォルダに画像を置けば自動で使われます。なお、配れるのは手元（ローカル）で動くアプリです。サーバーの構築は市民開発の範囲外になります（すでにあるサーバーへつなぐアプリは配れます）。

アプリを発展させる方法

一度作ったツールは、機能を足したり細かく直したりして育てていきます。新しい機能をはっきり足したいときは、合言葉「要求変更」から始め、Web Claudeで新しい版の仕様書を作ります（新規と同じ流れです）。一方、期待値の微調整や表示の変更といった細かい手直しは、次の「試し」から始めるのが向いています。

変更は、まず「試し（スパイク）」で探索する

「これを足したらどうなるか」「AとBのどちらがよいか」を確かめたいときは、Claude Code側で /psdd-code と打ち、試し（スパイク）で探索します。試しは、テストが全部緑になった版の上でだけ始めます。緑の版が土台なので、コードを直接いじって自由に試せます。「こうしてみたい」と自然言語で伝えれば、そのままコードが変わります。試した内容と結果は、CHANGELOGの「試行」欄に日付つきで自動で残るので、後から足跡をたどれます。仕様書・期待値表・版管理票は、この段階では書き換えません。

砂糖さん

コードを直接いじって、正しさは大丈夫なんですか？

MATSU

大丈夫です。土台が緑の版なので、試しでコードをいじっても、テスト実行にかければ「どこが変わって、どこがずれたか」を必ず捕まえられます。試しはあくまで探索で、「これでいく」と決めたら、次の手順で仕様書に落とし直してから正式に作ります。正しさは、最後まで仕様書から作ります。

ずれ（乖離）は、テスト実行が版管理票に刻む

試して「これでいく」と決めたら、テスト実行にかけて乖離箇所を特定します。変更でずれた箇所は、テスト実行チャットが版管理票の差し戻しセクションに、宛て先つきで刻みます。「どの文書を、どう直すべきか」が票に書き込まれるわけです。

ここで、要求フェーズで発行したあの版管理票が働きます。ずれを見つけて刻むのはClaude Code、それを読んで仕様書を直すのはWeb Claude。両者は直接やりとりせず、同じ1枚の票を介してつながります。だから、どちらのチャットも人の記憶に頼らずに、次にやることがわかります。

宛て先に応じて、変更の合言葉で仕様書を直す

版管理票に刻まれた宛て先を見て、Web Claude側で対応する変更の合言葉を呼びます。新規の4語と一対一で対応しています。要求から直すなら「要求変更」で、あとは新規と同じ流れ（設計→テスト設計→テストコード→実装→テスト実行）をたどります。

どこを直すべきかは、版管理票が機械的に判定します。使う側は、票の宛て先に応じた合言葉を呼ぶだけです。表示など目で気づける小さな手直しは、同じ版のまま枝番だけ進みます（フォルダは増えません）。新しい機能を足すような大きな変更だけが、新しい版になります。この探索と手直しを繰り返して、ツールを作り込んでいきます。

ドキュメントがそろえば、いつでも再現できる

PSDDでは、チャットは使い捨てで、資産になるのはドキュメントと版フォルダです。版フォルダに仕様書一式（要求・設計・期待値表・テスト設計・テストコード）がそろっていれば、実装とテストコードは何度でも同じように作り直せます。仕様書が正本で、コードはそこから導かれるものだからです。育てて確定したら、また版を閉じてexeにし直せば、配布物も最新になります。

v1/                    ← 版ごとにフォルダで分ける
　版管理票.md          ← 文書の一覧と状態
　docs/               ← 要求・設計・期待値表・テスト設計仕様書
　tests/              ← テストコード
　src/                ← 実装コード（docsから作り直せる）

操作の早見表と、開発の流れ

最後に、これまでの操作を一覧にまとめます。合言葉さえ手元にあれば、あとは呼ぶだけです。Web Claude側は仕様書を作る合言葉、Claude Code側はコードにする合言葉と、担当が分かれています。

Web Claudeの操作（仕様書を作る）

新しいチャットで /psdd と打ち、合言葉を続けます。新しく作るときは新規の4語、直すときは変更の4語を、直す文書に応じて呼びます。

Claude Codeの操作（コードにする・配る）

VS CodeのClaude Codeで /psdd-code と打ち、やることを続けます。実装とテスト実行は、それぞれ別のチャットで呼びます。

開発の流れ（新規・小さく直す・大きく直す・配る）

全体の流れは下の図のとおりです。新規で作って版を閉じたら、そこから枝分かれします。小さな手直しは「試し」から入って同じ版のまま枝番を進め、大きな変更は「要求変更」から新しい版を起こします。どちらも確認して版を閉じ直します。そして、閉じた版だけが別の矢印でexe化され、配布物になります。

Web Claudeで仕様書を作り、Claude Codeでコードにする。この2つを合言葉で呼び分けるだけ。作って、確認して閉じて、配る。育てるときは小さく直すか大きく直すかを選び、また閉じて配り直す。これがPSDDの一周。

過去のプロンプト

PSDD_v6