つまずく原因はだいたい決まっています。決めるべきことを決めないまま先に進むか、決めたことを書き残さないまま進むか、このどちらかです。以下はそれを防ぐための順番です。
工程
- 00
スコープを決める
誰の何を解決するかを決める。同時に「今回は作らないもの」も書き出す。 ここが無いと、仕様がどこまでも膨らむ。
- 01
壁打ちする
どんな機能が要るかをAIと会話しながら洗い出す。判断に迷うところは「詰めて」と言って、質問攻めにしてもらう。
- 02
仕様書を作る
機能一覧・画面一覧・業務フローまで。実装方法は書かせない。 仕様と設計が混ざると、後から見直せなくなる。
- 03
モックアップを見る
主要画面をHTMLで出してもらう。必ず気づくことがあるので、仕様書に反映してから次へ進む。
- 04
DB設計を確定する
テーブル定義だけを先に固める。詳細設計より前に。 ここが後から変わると、全部やり直しになる。
- 05
詳細設計書を作る
仕様書とDB設計をもとに、技術的な設計書を作る。ファイル構成と開発フェーズの分割まで含める。
- 06
設計書をレビューさせる
別チャットで設計書だけ読ませ、セキュリティ・金額・難易度・将来の変更しやすさを見てもらう。 同じチャットだと、自分が書いたものを甘く見る。
- 07
本番サーバーに疎通確認する
コードを書く前に、空のページを本番に上げておく。PHPバージョン、DB接続、パーミッションをここで潰す。 環境の問題は、コードが増えるほど切り分けが難しくなる。
- 08
フェーズを実装する
機能単位で依頼する。設計書から外れる必要が出たら、実装前に確認を取らせる。
- 09
動作確認して直す
エラーは原因を特定してから直す。いきなり修正コードを書かせない。 当てずっぽうの修正は、別の場所を壊す。
- 10
設計書を更新する
実装中に変えた点を設計書に戻す。 実物と食い違った設計書は、次のチャットで害になる。
08〜10を、フェーズの数だけ繰り返す
- 11
本番公開する
デバッグ表示オフ、ファイルのパーミッション、バックアップを確認してから公開。
全体を通して効くこと、ひとつだけ挙げるなら
ステップが変わったら、チャットも変える
ひとつのチャットで仕様検討から実装まで走らせると、後半でAIが前提を見失います。話が長くなるほど、最初に決めたことの輪郭がぼやけていくためです。人間側も、どこで何を決めたのか追えなくなります。
工程ごとにチャットを分け、決まったことは会話ではなくファイルに残す。次のチャットは、そのファイルを読ませるところから始める。仕様書や設計書を作るのは、AIのためでもあり、未来の自分のためでもあります。
- 壁打ち・仕様持ち出すもの：仕様書
- DB設計・詳細設計持ち出すもの：テーブル定義、詳細設計書
- レビュー持ち出すもの：指摘と修正した設計書
- 実装（フェーズごと）持ち出すもの：更新済みの設計書
- デプロイ持ち出すもの：公開手順とチェックリスト
ほかに外せないこと
- 「何を作るか」と「どう作るか」を、同じ書類に書かない。
- 一括で作らせない。必ずフェーズに割って、動く単位で確認する。
- 設計書と実物がずれたら、その場で設計書を直す。あとでまとめて直そうとすると、まず直らない。
各ステップのプロンプト例
そのまま貼って使えます。〇〇や空欄は自分の案件に置き換えてください。細かい言い回しより、書いてある「やらせないこと」の指定のほうが効きます。
00スコープを決める
これから〇〇というWebサービスを作りたい。 まだ仕様は固まっていないので、壁打ち相手になってほしい。 ・利用者：誰 ・解決したい課題：何 ・規模感：想定ユーザー数、データ量 まずは「このサービスの必須機能」と「今回は作らない機能」を 分けたいので、質問しながら整理してください。
方向性が曖昧なうちに「詰めて」と言うと、判断を一つずつ潰してくれる。
02仕様書を作る
ここまでの議論をもとに仕様書を作ってください。 含めてほしい項目： - サービス概要／解決する課題 - 利用者の種類と権限 - 機能一覧（優先度つき：必須／あとで／作らない） - 画面一覧と各画面の役割 - 主要な業務フロー - 非機能要件（想定規模、対応ブラウザ、スマホ対応の有無） まだ技術的な実装方法は書かないでください。 Markdownファイルで出力してください。
「実装方法は書くな」の一行が効く。書かせると設計が仕様に混ざる。
03モックアップを見る
仕様書の「（画面名）」のモックアップをHTMLで作ってください。 デザインは仮で構いません。項目の配置と情報量の確認が目的です。 スマホ表示も確認したいのでレスポンシブで。
04DB設計を確定する
仕様書をもとに、データベース設計だけを先に作ってください。 - テーブル定義（カラム名、型、NULL可否、デフォルト、コメント） - 主キー・外部キー・インデックス - テーブル間のリレーション図（Mermaid） - なぜこの構造にしたかの理由 環境：MySQL、共有サーバー
05詳細設計書を作る
仕様書とDB設計をもとに詳細設計書を作ってください。 - システム構成（サーバー、PHPバージョン、使用ライブラリ） - ディレクトリ構成とファイル一覧（各ファイルの役割） - 画面遷移図 - 主要機能の処理フロー - 認証・セッション設計 - 外部連携（あれば） - 開発フェーズ分割（何から作るか、動く単位で） 制約：フレームワークは使わない。素のPHPで。 共有サーバーなのでComposer・cron・SSHは前提にしない。
06設計書をレビューさせる
この詳細設計書を、以下の観点で厳しくレビューしてください。 1. セキュリティ：SQLインジェクション、XSS、CSRF、権限まわりの穴 2. コスト：サーバー・外部サービスで月額いくらかかるか 3. 難易度：詰まりそうな箇所と、その回避案 4. 設計上の懸念：後から変更が効かなくなる決定はどこか 問題があれば修正案も併せて。
必ず別チャットで、設計書だけ読ませて実行する。
07本番サーバーに疎通確認する
本番サーバーに疎通確認だけ先にやりたい。 ・サーバー： ・確認したいこと：PHPバージョン、DB接続、 ファイルパーミッション、必要な拡張モジュール 最小限の確認用PHPファイルと、確認手順を教えてください。
08フェーズを実装する
詳細設計書のフェーズ1「〇〇機能」を実装してください。 対象ファイルは設計書の通り。 守ってほしいこと： - 設計書のテーブル定義・ファイル名から外れない - 外れる必要があるなら、実装前に理由を説明して確認を取る - コメントは日本語で
09動作確認して直す
〇〇機能でエラーが出ました。 ・やった操作： ・期待した動作： ・実際の動作： ・エラーメッセージ： （そのまま貼る） 原因の候補を挙げて、確認方法を教えてください。 いきなり修正コードを出さず、原因を特定してから直したい。
「いきなり直すな」を書かないと、当てずっぽうの修正が始まる。
10設計書を更新する
フェーズ1の実装が完了しました。 実装中に設計から変更した点を洗い出して、 詳細設計書を更新してください。 変更点は差分がわかる形で示してください。
11本番公開する
完成したので本番に公開したい。 ・サーバー： ・ドメイン： ・本番用DB：作成済み／未作成 手順を、実際に押すボタン・打つコマンドのレベルで教えてください。 公開前チェックリスト（デバッグ表示オフ、パーミッション、 バックアップ等）も出してください。
