「さっき直したはずのレイアウトが、別の指示をしたらまた崩れている…」
「エラーを直して、と頼んだら、正常に動いていたコードまで消された」
もしあなたが、CursorやGeminiを使っていてこのような「AIとの終わりのないモグラ叩き」に疲弊しているなら、それはあなたのプロンプト力が低いからではありません。
原因はもっと構造的な、AIとのコミュニケーション手法そのものの欠陥にあります。
私たちはつい、AIを「優秀な人間のアシスタント」のように扱いがちです。「これやっておいて」「あ、やっぱここ直して」と、チャットで五月雨式に指示を出す。しかし、この「思いつきのチャット指示」こそが、開発を破綻させる最大の元凶なのです。
本記事では、非エンジニアである私が、数百時間の失敗を経てたどり着いた「Markdown設計図（PRD）」による開発手法を公開します。
これは、AIに「会話」させるのではなく「仕様書」を読ませることで、手戻りを9割減らす技術です。
記事の中盤では、コピペで使える「最強の設計図テンプレート」も配布します。
今日で、モグラ叩きは終わりです。
AIを「使いこなせない道具」から「最強の部下」に変える、その具体的な方法を始めましょう。
1. なぜあなたのチャット指示は、3ターン目で破綻するのか？
「完璧だ！天才か？」
1ターン目、AIが提示したコードは素晴らしかった。
「もう少し、ここを調整して」
2ターン目、微修正も難なくクリア。
「じゃあ最後に、この機能を追加して」
そして運命の3ターン目。出力されたコードを貼り付けた瞬間、画面は真っ白になり、コンソールには大量の赤いエラーログ。慌てて「直して！」と叫ぶと、今度はなぜか正常に動いていたはずのログイン機能まで消滅している……。
この現象には、技術的な理由があります。
「コンテキストの漂流（Context Drift）」という病
AI開発において、指示出しが重なるにつれて回答精度が落ちていく現象。専門用語ではこれを「Context Drift（コンテキストの漂流）」と呼びます。
LLM（大規模言語モデル）は、膨大な会話履歴の中から「今、何が重要か」を確率的に判断しています。しかし、会話が長く続けば続くほど、初期に伝えた重要な前提条件（例：「A機能とB機能は連動する」など）は、情報の海に埋もれていきます。
例えば、以下のような悲劇は日常茶飯事です。
- 初期指示: 「ショッピングカートの合計金額を計算するロジックを作って」
- 数ターン後: 「カートのデザインをもっとポップにして。ボタンを赤くして」
- AIの反応: 「了解しました！（デザイン修正に全集中）」
- 結果: ボタンは赤くなったが、裏側にあった「合計金額計算ロジック」がコードからごっそり抜け落ちている。
AIにとって、情報の優先順位は往々にして「古い情報 ＜ 新しい情報」になりがちです。あなたが直近で「ボタンの色」に言及した瞬間、AIの注意（Attention）はその「見た目」に一点集中し、過去の重要な約束を「ノイズ」として切り捨ててしまうのです。
「Vibe Coding（雰囲気開発）」の甘い罠
最近、元OpenAIのAndrej Karpathy氏らが提唱した「Vibe Coding」という言葉が話題です。「詳細な仕様なんて書かずに、自然言語でバイブス（雰囲気）を伝えればAIがコードを書いてくれる」というスタイルです。
確かにプロトタイプ作りには有効ですが、複数のファイルが連携するWebアプリ開発において、これを初心者が真似するのは地雷原を走るようなものです。
「いい感じのデザインにして」という曖昧な（Vibeな）指示は、AIに「勝手な解釈」を許すことになります。結果、見た目は綺麗だけどデータベースがつながっていない「ハリボテ」が量産されます。
失敗の9割は「コードを書く前」に起きている
私がAI開発にのめり込み始めた頃、ある生産管理ツールの開発で数百時間をドブに捨てたことがあります。
チャットで思いつくままに機能を追加し、コードが2000行を超えたあたりで、AIが完全に制御不能になりました。Aを直せばBが壊れ、Bを直せばCが壊れる。深夜3時、納期は翌日。目の前にあるのは「動かない巨大なゴミの山」だけ。
冷や汗と絶望の中で、私は理解しました。
AIがコードを壊すのは、私たちが「何を作るか」をAIに完全に伝えきれていないからだ、と。
チャット欄に直接コードの修正指示を書き込んでいる時点で、実はもう負けています。
では、どうすればAIに記憶を維持させ続けられるのか？
その答えは、流れて消えていく「会話（チャット）」に頼るのをやめ、動かない「ドキュメント（設計図）」を支配させることにあります。
2. AIは「会話」よりも「ドキュメント」に従う性質がある
前章で触れた「AIの記憶喪失」を防ぐ鍵は、AI（LLM）が生まれ持った「学習のルーツ」にあります。
結論から言います。
AIにとって、自然言語のチャットは「参考意見」に過ぎませんが、Markdownで書かれたドキュメントは「絶対的な命令」として認識されやすい性質があります。
LLMの母国語は「Markdown」である
私たち人間にとって、Markdown（マークダウン）は単なる記法ですが、CursorやGeminiの頭脳であるLLMにとっては、もっとも理解しやすい母国語です。
なぜなら、彼らはGitHubなどに公開されている世界中のコードと、それに付随するドキュメント（README.mdなど）を食べて育っているからです。
彼らが学習したデータの多くは、以下のような構造を持っています。
#（見出し）：機能の大きな塊-（リスト）：具体的な要件や手順```（コードブロック）：実際の実装
AIはこの構造を見た瞬間、「あ、ここは見出しだから重要だ」「ここはリストだから、手順を漏らしてはいけない」と、論理的な階層構造を瞬時に理解します。
私はよく、「MarkdownはAIへの『翻訳の手間』を省く行為」だと説明しています。曖昧な日本語をそのまま投げてAIに解釈させるのではなく、最初からAIが飲み込みやすい構造化データを渡す。これだけで、認識齟齬（ハルシネーション）のリスクは激減します。
「Single Source of Truth（聖書）」を作る
システム開発の現場には、SSOT（Single Source of Truth）という言葉があります。「信頼できる唯一の情報源」、要するに「プロジェクトの聖書」のことです。
非エンジニアのAI開発において、この「聖書」となるのが「Markdown設計図（PRD）」です。
チャット指示開発では、正解が「会話の履歴」の中に分散してしまい、AIも迷子になります。しかし、Markdownファイルを1つ作り、それをSSOTとして定義すると世界が変わります。
【私の開発ルール】
- 変更が生じたら、チャットで指示するのではなく、まずMarkdownファイルを書き換える。
- 書き換えたファイルをAIに再度読み込ませる。
- 「この設計図が最新です。これに合わせてコードを修正して」と指示する。
こうすることで、AIは迷ったときに必ずそのファイルを参照します。「会話」という流動的な記憶（メモ書き）ではなく、「ファイル」という固定された記録（契約書）に従わせるのです。
3日間のバグが「1分」で消えた夜
私が以前、地元の鉄工所向けに在庫管理システムを開発していた時の話です。これが私の転機となりました。
当初はチャットで指示を出していましたが、要件が複雑化するにつれ、AIが生成するコードは完全なスパゲッティ状態に。在庫数がマイナスになる怪奇現象まで発生し、3日間、不眠不休で修正を続けましたが、直すたびに別の場所が壊れる地獄のループでした。
「もう無理だ」と思った深夜3時、私は最後の賭けに出ました。
一度開発を止め、1時間かけて要件をすべてMarkdownに書き出し、spec.mdとして保存しました。そして、そのファイルをCursorに読み込ませ、「今までのコードは忘れていい。この設計図通りに作り直して」と指示しました。
エンターキーを押して約1分後。
AIが吐き出した新しいコードを実行した瞬間、私は鳥肌が立ちました。
あれほど直らなかった計算ズレが消え、複雑な在庫処理が嘘のようにスムーズに動いたのです。魔法を見ているようでしたが、種明かしは単純です。
「AIの能力不足ではない。私の指示の構造化不足だったのだ」
AIは超一流の大工です。しかし、図面がなければ犬小屋しか作れません。私たちがすべきは、ハンマーを振り回すことではなく、静かな部屋で正確な「設計図」を書くことだったのです。
3. 【コピペOK】要件・遷移・データを1枚にまとめる「開発テンプレート」
お待たせしました。私が鉄工所の在庫管理システム開発で窮地を救われた「魔法の設計図」。そのエッセンスを凝縮し、どんなアプリ開発にも応用できるように汎用化した「AI開発専用Markdownテンプレート」を公開します。
これをコピーして、必要な部分を埋めるだけで、あなたの曖昧なアイデアは「AIが実行可能な命令」に変わります。
AI開発専用 PRDテンプレート（v3.0）
以下のテキストをコピーして、メモ帳やVS Codeに貼り付けてください。ファイル名は prd.md として、プロジェクトのルート（一番上の階層）に保存することをおすすめします。
※注意: [ ] で囲まれた部分はプレースホルダーです。テンプレートでは例として「Next.js」や「在庫管理」を入れていますが、PythonやRuby、To-Doアプリなど、あなたが作りたいものに合わせて自由に書き換えてください。
# Project Requirements Document (PRD)
## 1. Project Overview (プロジェクト概要)
**プロジェクト名**: [アプリ名を入力]
**概要**: [解決したい課題と、このアプリが何をするものかを2-3行で記述]
**ターゲットユーザー**: [誰が使うのか]
## 2. Tech Stack (技術スタック)
※AIに技術選定を任せず、ここでバージョンまで固定します。
- **Frontend**: [例: Next.js 14 (App Router), Tailwind CSS]
- **Backend**: [例: Supabase, Python (FastAPI)]
- **Database**: [例: PostgreSQL (Supabase)]
- **Auth**: [例: Supabase Auth]
- **Deployment**: [例: Vercel]
## 3. Directory Structure (ディレクトリ構造)
※AIによるファイルの乱造を防ぐため、主要な構造を定義します。
root/
├── app/
│ ├── page.tsx
│ ├── layout.tsx
│ └── (routes)/...
├── components/
│ ├── ui/ (shadcn/ui components)
│ └── features/
├── lib/
│ └── utils.ts
└── prd.md (This file)
## 4. Features & User Stories (機能要件)
各機能における「ユーザーができること」を定義します。
### 4.1 [機能名A: 例 ログイン機能]
- ユーザーはメールアドレスとパスワードでログインできる。
- ログイン成功後、ダッシュボードへリダイレクトされる。
### 4.2 [機能名B: 例 在庫一覧表示]
- 在庫データはカード形式で表示する。
- 「在庫切れ」のアイテムは赤枠で強調表示する。
## 5. Data Model (データモデル)
データベースの構造を定義します。型と関係性を明確に。
### [Model A: 例 User]
- **id**: UUID (PK)
- **email**: String (Unique)
- **role**: Enum (admin, user)
### [Model B: 例 Item]
- **id**: UUID (PK)
- **name**: String
- **stock_count**: Integer (Default: 0)
- **user_id**: FK (User.id)
## 6. Non-Goals (やらないこと)
- [例: 今回はスマホ対応（レスポンシブ）は考慮しない]
- [例: 決済機能は実装しない]なぜ、この項目が必要なのか？ 運営者のこだわり解説
このテンプレートには、AIの暴走を防ぐための「安全装置」が仕込まれています。
1. Tech Stack（技術スタック）は「バージョン」まで縛る
Web開発の進化は早く、単に「Next.js」と指定すると、AIは学習データ内で最も多い（つまり古い）バージョンを提案しがちです。「Next.js 14」「App Router使用」や「Python 3.11以上」のようにガチガチに指定することで、最新の作法でコードを書かせることができます。
2. Directory Structure（ディレクトリ構造）で「AIの習性」を利用する
AIは「隣の家を真似て家を建てる」のが得意です。最初に「このフォルダ構成で作れ」という地図（ファイルツリー）を渡すと、AIはそのルールに従って綺麗にファイルを配置してくれます。これを書かないと、AIは迷子になり、変な場所にファイルを勝手に作り始めます。
3. Data Model（データモデル）は「型」で語る
ここが心臓部です。「値段」ではなく price: Integer と書くことで、AIは「あ、ここは数字しか入らないんだな」と理解し、入力フォームのバリデーション（チェック機能）を自動で実装してくれます。
4. Non-Goals（やらないこと）が「ハルシネーション」を殺す
これは裏ワザです。AIは気を利かせて「パスワード再発行機能も要りますよね？」とコードを肥大化させることがあります。「決済機能は作らない」「管理者画面は不要」と明記することで、AIの想像力にブレーキをかけ、今必要な機能だけに集中（Attention）させることができます。
4. Gemini 1.5 Proに「壁打ち」させて、設計図の矛盾を事前に潰す方法
テンプレートを埋めて、設計図（PRD）が完成しました。
「よし、これでCursorでコード生成だ！」……はやる気持ちは分かりますが、ここでストップです。
その設計図は、現時点では「素人の願望リスト」に過ぎません。これをそのまま実装AI（Cursor）に渡すと、途中で破綻します。
実装に入る前に、もう一人のAIを「辛口の技術顧問（CTO）」として召喚し、設計図の欠陥を叩いてもらうのです。
なぜ「Cursor」ではなく「Gemini」なのか？
AIモデルには明確な「適材適所」があります。
- Cursor (Claude 3.5 Sonnet / GPT-4o)
- 「大工」。コードを書くのは速いが、目の前の作業に集中しがち。
- Gemini 1.5 Pro
- 「建築士」。圧倒的な記憶容量（コンテキストウィンドウ）を持ち、長い仕様書全体を読み込んで論理矛盾を見つけるのが得意。
※Claude 3.5 Sonnetも推論能力が高いので、使い慣れている方はそちらでも構いません。重要なのは「実装前にレビューを挟む」ことです。
【コピペOK】Geminiを「辛口CTO」に変えるプロンプト
Gemini（またはClaude）に、先ほどの prd.md を貼り付け、以下のプロンプトを投げてみてください。
あなたは百戦錬磨のソフトウェアアーキテクト（CTO）です。
以下のMarkdown形式の要件定義書（PRD）を読み、実装フェーズで問題になりそうな「論理的矛盾」「不足している仕様」「エッジケース（想定外の事態）」を厳しく指摘してください。
コードを書く必要はありません。
「ここが曖昧で、実装時にエンジニアが困る」というポイントを箇条書きでリストアップし、それぞれの解決案を提示してください。
---
[ここに prd.md の中身を貼り付け]実録：私の設計図が「ボコボコ」にされた日
以前、私が在庫管理システムのPRDを自信満々でGeminiに見せた時、こんな指摘を受けました。
Gemini: stock_count（在庫数）がInteger（整数）ですが、鉄材の場合、「1.5メートル」のように小数を扱う可能性はありませんか？
背筋が凍りました。私は「本数」のことしか頭になく、現場では「長さ」で管理する場合があることを忘れていたのです。もしそのままCursorで作らせていたら、後からデータベースを破壊して作り直す大工事になるところでした。
指摘されたら、チャットで答えず「設計図」を直す
Geminiから指摘をもらったら、チャット欄で返事をしてはいけません。
必ず、元の prd.md ファイルを手動で書き換えてください。
この「修正ループ」を2〜3回繰り返し、Geminiから「致命的な論理矛盾は見当たりません」というお墨付きをもらった時こそが、本当の開発スタート地点です。
5. 実演：設計図1枚をCursorに渡して、アプリを「一発生成」する快感
長い下ごしらえ、お疲れ様でした。
すべての苦労が報われる瞬間がついにやってきました。ここからは、あなたの手元にある「最強の設計図」をCursorに渡し、アプリの土台を一気に構築します。
使うのは、Cursorの真骨頂「Composer機能」です。
使うのは「たった1行」の指示だけ
- Cursorを開き、
prd.mdを保存したフォルダを読み込みます。 Cmd + I（WindowsはCtrl + I）を押してComposerを開きます。- ※画面下部に出ない場合は、画面右上の「Composer」タブを探してください。通常のチャット（Cmd+L）とは別物です！
- 以下の指示を打ち込みます。
@prd.md の内容に基づいて、このプロジェクトの初期構築を行ってください。画面が緑色に染まる「魔法の時間」
エンターキーを押した瞬間、魔法が始まります。
Composerは単にコードを提案するだけでなく、あなたのPCの中に実際にファイルを作成し始めます。
サイドバー（ファイルツリー）を見てください。新規作成されたファイルを示す「緑色の文字」が滝のように流れていくはずです。
私が初めてこれを体験した時、ただ呆然と眺めていました。「おいおい、本当に全部作ってるよ……」。かつて数時間かけていたセットアップ作業が、ものの2分で完了しました。
成功の鍵は「Accept All（すべて承認）」
生成が終わると、Cursorは「作成・変更してもいいですか？」と確認を求めてきます。
迷わず「Accept All（すべて承認）」を押してください。
ここが最大の落とし穴です。 これを押さないとファイルは保存されません。「画面上ではコードが見えているのにファイルがない」というトラブルの9割はこれです。
もしエラーが出ても大丈夫
「npm install でエラーが出た」としても、焦る必要はありません。手元にはGeminiお墨付きの設計図があります。
エラーが出ました。[エラーログを貼り付け]
@prd.md の仕様を守りつつ、修正してください。こう指示すれば、AIは「あ、設計図ではこうなっていたな」と原点に立ち返り、仕様に即した正しい修正を行ってくれます。
6. 完成後の修正も「コード」ではなく「設計図」を直すべき理由
アプリが表示され、開発は成功しました！
しかし、ここから「文言を変えたい」「ボタンを赤くしたい」という要望が出てくるでしょう。
ここで99%の初心者が陥る最大の罠があります。
「ちょっとした修正だから」と、手動でコードを書き換えてしまうことです。
倒したはずのバグが蘇る「ゾンビバグ」の恐怖
もしあなたがコードだけを手動で直し、設計図（PRD）を放置したとします。
- コード: ボタンは赤（手動修正）
- 設計図: ボタンは青（元のまま）
1週間後、機能追加のためにCursorに指示を出すと、AIは真面目なので設計図を読み、「おや？ 実装ミスでボタンが赤くなっている。設計図通り『青』に直しておこう」と判断します。
結果、あなたの修正は上書きされ、バグが墓場から蘇ります。 私はこれを「ゾンビバグ（Zombie Bug）」と呼んでいます。
これを防ぐ唯一の方法は、「コードよりも先に、必ず設計図を更新する」ことです。
あなたは「プログラマー」ではなく「設計者」になる
成功するフローはこうです。
- バグを見つける。
prd.mdを書き換える（「ボタンは赤にする」と記述）。- Cursorに「
@prd.mdを更新しました。反映して」と指示する。
一見遠回りに見えますが、これが「ゾンビ」を防ぐ最短ルートです。
このスタイルを突き詰めると、あなたは一行もコードを書かずにアプリを作れるようになります。
これこそが、AI時代の新しい戦い方、「宣言的開発（Declarative Development）」です。
- 命令的（従来）: 「CSSファイルを開いて、ここを直して」と手順（How）を指示する。
- 宣言的（新時代）: 「ボタンの色は赤だ」と状態（What）を定義する。
あなたはハンマーを持つ大工ではなく、図面を描く「建築家（アーキテクト）」になればいいのです。
7. 【まとめ】設計図（PRD）さえあれば、私たちは何でも創れる
「プログラミングができないから、アイデアを形にできない」
そんな言い訳が通用する時代は終わりました。
最後に、これからの開発においてよくある疑問に答えつつ、まとめとさせていただきます。
よくある質問（FAQ）
- Q1. Markdownを書くのが難しそうです。
A.
第3章のテンプレートをコピペすれば大丈夫です。使うのは#（見出し）と-（箇条書き）だけ。箇条書きができるなら、あなたはもう書けます。 - Q2. 作ったアプリを公開するには？
A. Cursorのターミナルで
npx vercelと打つのが一番簡単です（Webアプリの場合）。ここでもprd.mdに「Vercelで公開」と書いておけば、AIが手順を教えてくれます。
「手仕事」から「設計」へ
私は普段、サイエンスコミュニケーターとして活動していますが、宇宙開発の現場には「上流工程（設計）が品質の8割を決める」という鉄則があります。ロケットは打ち上げ後に修理できないからです。
AI開発も同じです。チャットでいきなり作る（製造する）のは、図面なしでロケットを作るようなもの。
しかし、「しっかりとした設計図」さえ書ければ、誰でもロケット（アプリ）を飛ばせる時代になりました。
さあ、テキストエディタを開こう
あなたのPCには今、最強の製造マシーン「Cursor」と、最強の技術顧問「Gemini」がスタンバイしています。
足りないのは、彼らに渡す「最初の1ファイル（prd.md）」だけです。
今日、この記事を閉じた瞬間から、あなたは「非エンジニア」ではありません。AIという部下を率いる「プロダクトマネージャー（PM）」です。
まずはメモ帳を開き、# Project Overview と打ち込んでみてください。
何を書けばいいか分からなければ、Geminiに「私のアイデアはこれ。Project Overviewの下書きを書いて」と頼むところから始めましょう。
その一行が、あなたのアイデアを現実に変える最初の一歩になります。
もし素晴らしいアプリができたら、ぜひ #AIブログ運営術 で教えてください。あなたの「設計図」が見られる日を、心から楽しみにしています。
この記事へのコメントはありません。