【Claude Code】趣味で「手順書駆動開発（PDD）」作ってみたら意外と面白くなった
1. はじめに
Claude Pro を契約して、趣味でアプリ開発を始めた。
エンジニアとしての経歴はある。ただ、本格的に開発をやっていたのはもう 10 年以上前の話で、今の現場からはかなり離れている。Vue.js？ React？「何それおいしいの？」レベルから始まった。
そんな状態で「とにかく Claude に任せながら作ってみよう」というノリで動き出した。人間はコードを書かない。設計も Claude と話しながら決める。とにかく 人間の役割は「何を作るか」を考えること で、「どう作るか」は Claude に任せる ——そういう方針でやっていた。
最初はそれで楽しかった。でもすぐに問題が起きた。
2. きっかけ：3日でクレジットを使い切った
Pro を契約したその週、たった 3 日でクレジットを使い切った。
原因は「会話コストの高さ」だ。
長い会話を続けていると、AI は同じような指摘を繰り返したり、以前に話したはずのルールをまた一から確認しようとする。そもそも「どういうルールでやるか」自体をチャットの中で決めていくから、そのルール策定にかけるコストが馬鹿にならない。
そして、Claude Code に限らず AI は注意しないとすぐに「全容を出力」し始める。長い出力が次々と来る。それがクレジットを消費する。
クレジットを使い切ると、次の作業を続けるのに数時間待たないといけない。開発の勢いが完全に止まる。これが地味に辛かった。
「もっと効率的にやれないか」——そう思い始めた。これは Claude Pro で開発している人なら、多かれ少なかれ引っかかる問題だと思う。
3. 壁打ちの中で生まれたもの
VibeCoding の欠点は知っていた。
仕様がないわけではない。ただ、それが AI の記憶の中にあるだけで、きちんと定義・管理されていない。その状態で実装が進むから、機能追加のたびに前の実装と矛盾が生まれ、スケールすると破綻する。エンジニア出身として、仕様を曖昧なまま進めることはどうしても許せなかった。
だから「仕様書は作る」は前提で、「AI にどういう形で任せるか」を Claude と相談しながら整理していった。
ただ、相談していくうちに、気づいたことがある。これは単に「どう作るか」を決める作業ではなかった。人間側にも Claude 側にも、それぞれ暗黙の判断基準やルールがある。その擦り合わせをしていたのだと、今なら思える。
たとえば仕様書の作り方一つとっても、Claude には Claude なりの「標準」とも言えるものがある。そこに僕の要望や制約を乗せていく工程が必要だった。そしてその擦り合わせを繰り返すうちに、お互いの理解が深まって、後の工程がどんどんスムーズになっていった。
いろいろなことをすり合わせた。仕様書の作り方、ブランチの切り方、PR の作り方、テストの粒度などなど。やっていくうちに、「これって手順書を作ってるのと変わらないな」と気づいた。だったら最初からきちんと手順書として整備して Claude に渡すほうがいいんじゃないか。Claude に聞いてみると、そのほうがいいという回答だった。
そこから「Procedure-Driven Development（PDD）」という名前が浮かんだ。手順書が開発を駆動する。我ながらいい名前だと思った。
4. PDD とは何か
基本コンセプト
PDD を一言で言うと：
人間の感覚としてはバイブコーディングで行きたい。でも、それだと絶対破綻する。だから、バックエンドの仕組みとして、仕様駆動開発（SDD）が回るようにした。
これが核心だ。
表から見ると、人間のやることはシンプルだ。「こういう機能が欲しい」と話せばいい。技術的な詳細を考える必要はない。まるで VibeCoding のように気軽に進む。
でも裏側では、あらかじめ定めたフローに沿って Claude が自律的に動いている。要件定義書の作成、実装、テスト、仕様書の更新——これらが手順書に従って実行される。フロー内には人間が必ず確認するステップも組み込まれているので、品質のチェックが自然に入る。
なぜ「手順書」なのか
AI は一貫性がある。疲れない。指示通りに動く。でも、指示がバラバラだと出力もバラバラになる。
手順書があれば、AI の強みを最大限に活かせる。「この手順に従って動いてくれ」と言えば、毎回同じ品質で動いてくれる。
そして、もう一つ重要なことがある。Claude.ai と Claude Code、2 つの AI が同じ手順書・仕様書を参照できるという点だ。
PDD では要件定義と計画は Claude.ai が担い、実装と仕様書の更新は Claude Code が担う。仕様書は実装後に Claude Code が自動で作成・更新する。つまり仕様書は開発の前提ではなく、開発を通じて育っていく中間成果物だ。これは Spec を起点とする SDD とは根本的に異なる点でもある。
この 2 つをつなぐのが GitHub だ。Claude.ai で決めた要件や手順書を GitHub に置いておけば、Claude Code がそれを読んで実装し、仕様書を更新する。人間が「さっきこう決めたから」と改めて伝え直す必要がない。GitHub を「唯一の正しい情報源」にするのはそのためだ。
5. 他の手法との比較
PDD を理解するには、他の手法との違いを見るのがわかりやすい。
| 要素 | VibeCoding | SDD（仕様駆動開発） | PDD |
|---|---|---|---|
| 人間の負担 | 最小（思い付きを伝えるだけ） | 大（Spec 作成に責任） | 小（要件を Claude と整理する） |
| AI の自由度 | 高（ほぼ自由） | 小（Spec に従属） | 中（手順書に従う） |
| 品質の担保 | 低（運任せ） | 高（Spec で保証） | 高（手順書で保証） |
| AI の作業スピード | 最速 | 速（Spec 以降のみ） | 中（全工程を実行） |
| Spec 作成 | なし | 人間（品質は人次第） | 自動（品質統一） |
| 仕様書の位置づけ | なし | 起点（これがないと始まらない） | 成果物（手順書の実行結果として生成） |
VibeCoding との違い
VibeCoding は速い。思い付きをすぐ実装できる。でも、規模が大きくなると破綻する。仕様書がないまま機能が増えていくので、どこかで必ず矛盾が生まれる。
PDD のスタートは VibeCoding と同じだ。「こういうのが欲しい」と話すところから始まる。ただ、そこから先が違う。手順書に沿って Claude が質問を重ね、曖昧だった要件が明確な形に整理されていく。人間は Claude の助けを受けながらその工程に付き合う必要がある。だから人間の負担は「最小」ではなく「小」だ。
でもその工程を経るからこそ、一段高い精度の要件定義ができあがる。そして裏側では仕様書が実装のたびに自動で生成・更新される。規模が大きくなっても破綻しにくいのはそのためだ。
SDD との違い
SDD は仕様書が起点だ。人間が Spec を作り、AI はそれに従って実装する。Spec の品質が高ければ、実装の品質も高くなる。
PDD では仕様書の位置づけが根本的に異なる。仕様書は起点ではなく、手順書に沿って実装した結果として生成される成果物だ。Claude Code が実装を終えたあと、手順書に従って仕様書を自動で作成・更新する。人間が仕様書を書く必要はない。
本質的な違いはここだ：
- SDD：人間が Spec を作り、AI が Spec に従う
- PDD：手順書が開発を駆動し、仕様書はその結果として生まれる
Agent SOPs について
ここまで意気揚々と説明しておいてなんだが、実は似たような考え方の先行事例がある。Agent SOPs というもので、AWS が開発・公開した仕組みだ。自然言語で書かれた Markdown 形式の手順書を AI エージェントに渡し、複雑なワークフローを一貫して実行させるという考え方で、Python ライブラリなども整備された本格的なものだ。
この記事を書くにあたって調べてみて初めて知った。やっぱり同じことを考える人はいるものだ（笑）。
そういう意味では、PDD は Python ライブラリ不要で Web だけで使えるお手軽版とも言えるかもしれない。個人・小規模チームが開発ワークフローですぐに使えるミニセットとして整理し、人間の検証プロセスを組み込みつつ、最初の SOP を GitHub に置くところまでまとめた、という位置づけだ。
6. 実際の使い方
気を取り直して、実際の使い方を説明しよう。PDD では、Claude.ai のプロジェクトを 2 つ作成し、段階的に使用する。
「Project Ideation」プロジェクト
新しいアプリを作るとき、最初にここで話す。アイデアを元に、Claude と一緒にグランドデザインをまとめていく。どんなモジュール構成にするか、技術スタックは何か、全体の骨格をここで決める。
Claude は質問を重ねながら整理してくれるだけでなく、こちらが知らないことも調べて提案してくれる。「こういう構成にするならこのライブラリが向いている」「同じような課題にはこういう解決策がある」——漠然としていたアイデアが、会話を通じて具体的な設計に育っていくのはそのおかげだ。最終的には初期ファイル一式の生成から、次に説明する個別の開発プロジェクトを立ち上げるための初期設定まで、まとめてやってくれる。
なお、このプロジェクトには全てのアプリの設計や検討内容が蓄積されていく。使い込むほどに成熟していくのも、地味ながら大きな利点だ。
個別の開発プロジェクト
Ideation で生成した初期ファイルをもとに作成するプロジェクトで、アプリ 1 つにつき 1 プロジェクト作成する必要がある。日常の開発はここで進める。
Ideation で決めたグランドデザインを土台に、機能ごとの詳細をここで作り込んでいく。「こういう機能を追加したい」と話すと、Claude と一緒に要件を整理しながら要件定義書にまとめる。その後は Claude Code が引き受けて、手順書に従って実装・テスト・仕様書更新まで自律実行する。人間は実装結果を確認して、問題なければ承認するだけ。
開発の流れ（概要）
- 機能のアイデアを話す
- Claude と要件を整理する
- Claude Code が自律実行（実装・テスト・仕様書更新）
- 人間が確認・検証
- マージして完了
- 繰り返す
人間がやることは「何を作るか」を Claude と一緒に考えることと、最終確認だけ。「どう作るか」は Claude と Claude Code に任せる。
7. やってみて引っかかったこと
理論はよくできていた。でも、実際にテストプロジェクトで動かしてみると、3 つの問題にぶつかった。
① ブランチ命名の問題
最初、機能ブランチは feature/REQ-001-xxx という命名にしていた。一般的な Git Flow の慣習だ。
ところが実際に動かしてみると 403 エラーが出てプッシュできない。調べてみると、Claude Code にはプッシュできるブランチの形式に制約があり、claude/<説明>-<セッションID> の形式でなければならなかった。僕も Claude も把握していなかった仕様だ。
解決策はシンプルで、すべて claude/REQ-001-xxx に統一した。手順書を更新して、以降は全部このルールで動くようにした。
② GitHub CLI が使えない
最初に Claude が提示した手順は GitHub CLI（gh コマンド）を使うものだった。
ところが外出先でも開発したいというわがままから、ローカル環境は使わずブラウザだけで完結させると決めていた。完全に僕のエゴだ。そのことを事前に擦り合わせていなかったせいで、Web 版の Claude Code では CLI が使えず詰まってしまった。
どうするか Claude と相談した結果、Web の GitHub UI で PR を作る手順に書き直してもらった。僕のエゴを通した形だ。「CLI くらい使えばいいのに」という声は聞き入れないことにしている。これくらいはいいよね？
③ 「完了」の定義が曖昧だった
最初の設計では、Claude Code だけで完結するフローになっていた。人間がどこでどう介入するかを、Claude と明確に擦り合わせていなかったのが原因だ。
そもそも、自分が欲しくて作っているものの出来栄えを自分で確認しないなんてありえない。でもそれは僕のこだわりであって、きちんと伝えなければ Claude には伝わらない。
フローの中に「人間が実装を検証するステップ」を明示的に設けた。このステップで問題が見つかれば同じ Claude Code のチャットで継続して修正できる。問題なければ、そこで初めてマージ承認に進む。
テストプロジェクトをやってよかった
3つの問題を振り返ると、原因は大きく 2 つに分かれる。①は僕も Claude も把握していなかった仕様の問題で、動かして初めてわかったことだ。②③は僕と Claude の擦り合わせが足りていなかったことが根本原因だった。
開発環境の制約も、人間がどこで介入するかも——きちんと伝えていなければ Claude には伝わらない。そして Claude に頼るだけでは、こちらの前提やこだわりまでは汲み取ってもらえない。人間側も能動的に関わらないと、うまく回らないのだ。
テストプロジェクトをやってよかったのはそのためだ。理論の段階では「うまく動くはず」と思っていたものが、動かすことで「知らなかった仕様」も「伝えていなかったこと」も、全部見えた。そもそもテストプロジェクトをやること自体、Claude の提案がなければ、やろうとは思わなかった。こういった細かいところは本当に Claude に助けてもらえて良かったと思っている。ありがとう、Claude。
8. 現時点での PDD の位置づけ
できること
- 要件定義書の自動生成（Claude.ai）
- 実装・テスト・仕様書更新の自律実行（Claude Code）
- 英語・日本語バイリンガルでの仕様書維持
- Git Flow に沿った標準化されたワークフロー
まだできないこと
- CI/CD の自動化（GitHub Actions 連携は Phase 2 以降）
- PR のプレビュー環境の自動生成（Firebase Preview Channels は計画中）
- タグベースの仕様書分類・検索（方針は固まっており、Phase 2 で実装予定）
- 手順書・資料のさらなる整備（継続的に進める予定）
誰に向いているか
- 少人数（1〜5人）のチーム
- Claude.ai / Claude Code を使って開発している
- 品質は保ちたいけれど、仕組みの整備には時間をかけたくない
厳密な監査が必要な業界にも、むしろ相性がいいと思っている。「手順書に従って実行し、その結果を記録に残す」——これは QMS の基本的な考え方そのものだ。PDD のワークフローの根底には、もともとその発想がある。すべての作業が手順書に従って実行され、記録が GitHub に残るこの構造は、監査対応の観点からも理にかなっているはずだ。
言い換えれば、QMS にも対応できるバイブコーディングを目指している、ということかもしれない。
9. 今後の展望
Phase 2（これから始める）
- タグベースの仕様書分類・検索の実装
- Firebase Preview Channels の統合（PR ごとにプレビュー環境を自動作成）
- GitHub Actions との連携
- 手順書・資料のさらなる整備
Phase 3（その先）
- 大規模プロジェクトへの対応
- チームでの協働機能
- コミュニティへの展開
10. まとめ
伝えたかったこと
VibeCoding は楽しい、でも品質が担保できない。仕様駆動開発は品質が高い、でも人間のコストが大きい。
PDD はその両方を両立しようとしている。人間の感覚はバイブコーディングのまま、裏側で SDD が回る。速さと品質を同時に手に入れるための仕組みだ。
ただ、7章で触れたように、Claude に丸投げするだけでは足りない。こちらの前提やこだわりを能動的に伝えて、一緒に作り上げていく姿勢が必要だ。それができれば、Claude はかなり頼りになるパートナーになってくれる。
最後に
PDD という発想自体、非エンジニアだからこそ思いついた部分が大きいと思っている。
現役の開発者はコード自体の品質を上げることに目が向く。でも僕はコードの品質を自分で評価できない。だから「コードの品質も含めて Claude に任せるには、どうすればいいか」という方向で考えるしかなかった。その発想が「手順と記録で品質を担保する」という構造を自然に生み出した。
結果的には車輪の再発明だったかもしれない。でも、車輪の作り方を自分で体得したからこそ、個人開発に使いやすい形に整理できたとも思っている。Agent SOPs という先人の知恵があることを知った上で、PDD を自分なりに育てていけばいい。
クレジットを 3 日で使い切ったあの体験が、結果的にここまで連れてきてくれた。高い授業料だったかもしれないが、悪くない投資だったと思っている。
PDD はまだ発展途上だ。でも、趣味プロジェクトとしてはかなり面白い方向に進んでいる。引き続き試行錯誤しながら育てていこうと思う。
PDD_Template はこちらで公開中です → https://github.com/renyuhki/PDD_Template