「作って」と一度で頼むと、なぜ途中で崩れるのか
アプリを1つのプロンプトで指示する行為を、建築に例えると「基礎・柱・内装・配線・外壁を一日で全部やって」と大工に頼むようなものです。それぞれの作業が互いに影響し合うため、一方を直すともう一方が狂います。AIによるコード生成でも、まったく同じ構造的問題が起きます。
単発プロンプト開発で起きやすい3つの現象
まず、要件の解釈ずれです。「ログイン機能付きのタスク管理アプリ」という指示に対して、AIは解釈の余地を埋めるために無数の仮定を置きます。データはどこに保存するか、認証はメールかGoogleかSNSか、モバイル対応は必要か——これらが全て暗黙のデフォルト値で埋められたコードが生成されます。後から「そういうつもりじゃなかった」と分かっても、すでに全体がその前提で組み上がっています。
次に、技術的負債の即時発生です。単発で完成形を急ぐと、AIは整合性よりも動作優先のコードを出す傾向があります。変数の命名がバラバラ、同じ処理が複数箇所に散在、エラーが起きたときに何が起きているか追えない構造——これらが最初のコードに混入します。機能を追加するたびに、この負債の利子が膨らんでいきます。
3つ目は、修正の連鎖崩壊です。UIが崩れたので直すと、今度はAPIの呼び出しが壊れる。APIを直すとデータベースの構造と整合しなくなる。こうした連鎖は、全体設計が存在しないまま部分最適の修正を重ねた結果として起きます。最終的に「全部消して最初から」という判断が最も早い、という状況に至ります。
崩れる原因は「実装の速さ」ではなく「段取りの欠如」にある
「AIのコード生成が遅い」あるいは「AIのコードの質が低い」から崩れるのではありません。「何を作るかの合意形成」と「どの順番で作るかの設計」が欠けているから崩れます。
段取りが欠けると何が起きるか
要件が曖昧なまま実装に進むと、AIは要件を補完しながらコードを書きます。この補完は多くの場合、正確ではありません。「ユーザーがよく使う画面から先に作る」「データモデルを確定してからAPIを作る」「フロントエンドとバックエンドの接続点を最初に決める」——これらの順序を守らないと、後から手を入れるたびにコストが大きく増えます。
一方で、段取りを先に決めると何が変わるか。AIへの指示が小さく・具体的になります。「このAPIが受け取るJSONの形はこれ。このエンドポイントのみ実装して」という粒度まで落とせれば、AIの出力は格段に安定します。プロンプトの言い回しを磨くのではなく、問いの粒度が適切になることが鍵です。
プログラミングの世界では長年、設計を先に固めるやり方と、小さく作って直し続けるやり方のどちらがよいかが議論されてきました。AIコード生成の登場によって、この問いは個人開発者にも降ってきています。結論として、全部一気に作る誘惑に乗ることが最もコストが高くなります。
relmeaが使う「段階を分ける開発」の考え方
relmeaでは、8本のアプリを1人で開発・運用してきた経験から、独自の開発フレームワークを整備しました。大きな特徴は2つです。開発を14のフェーズに分けること、そして人間が判断する確認ゲートを7箇所に設けることです。
14フェーズとは何か
フェーズは大きく「定義系」「構築系」「検証系」「デプロイ系」の4ブロックに分かれます。定義系では、要件定義・ページ構成・データモデル・API設計を個別に固めます。構築系では、フロントエンドとバックエンドを別フェーズで実装します。検証系では、単体テスト・結合テスト・E2Eテストを段階的に走らせます。デプロイ系では、セキュリティ診断・本番環境確認・リリース後検証を経て完了とします。
各フェーズは独立したタスクとして扱います。前のフェーズの成果物が確定しないと次に進まない、というルールを守ることで、修正の連鎖崩壊を防いでいます。
7つの確認ゲートとは何か
確認ゲートは「人間（relmea）が判断しなければ次に進んではいけない」チェックポイントです。要件定義が完了した時点でのゲート、UIデザインの方向性を承認するゲート、本番環境の接続先を確認するゲート、API設計を承認するゲート、セキュリティ診断結果を承認するゲート、デプロイ直前のゲート、本番稼働後の動作確認ゲート——これらを7箇所設けています。
ゲートがあることで、AIが誤った方向に大量のコードを書き続ける事態を防げます。また、何か問題が起きたとき「どのゲートまでは正常だったか」が明確になるため、問題の特定が早くなります。
エージェントの役割分担
実装においては、AIエージェントを細分化しています。全体の統制役、個別の実装ワーカー、完成物を敵対的に検品する検品役——この3層に分けることで、実装者と検証者が同じコンテキストを共有しない状態を作ります。実装したエージェントが自分の成果物を「たぶん大丈夫」と見なすバイアスを、構造的に排除する設計です。
非エンジニアでも回せる理由と、それでも人が担う部分
この仕組みを聞いて「自分には無理」と感じた方がいるかもしれません。しかし、この開発設計においてコードを書く必要はありません。人が担うのは、AIへの指示と確認です。
自動化できる部分
コードの記述、テストの実行、エラーの検知と修正サイクル——これらはAIに任せられます。適切なフェーズ設計があれば、「このフェーズのタスクをやって」とAIに伝えるだけで、相当量の作業が進みます。
人が担う部分——これを正直に書きます
AIに丸投げで完璧なアプリが出てくるわけではありません。コードは書かなくても、次の3つは人が担います。
- 要件の言語化。「何を作るか」「誰が使うか」「どういう操作ができるべきか」を具体的に言葉にする作業は、現時点ではAIに代替させることが難しい部分です。AIは「曖昧な要件を補完する」のが得意ですが、その補完が正しいかどうかを判断できるのは事業者本人だけです。
- 各段階での確認。フェーズが完了するたびに「これで合っているか」を見ます。画面の見た目、データの流れ、実際の操作感——これらを目で確認する作業は省けません。
- 継続的な運用判断。「この機能を追加すべきか」「今は機能追加より安定化が先か」という優先順位判断は、事業全体を見ている人間が担います。
また、Claude Code などのAIコーディングツールには月額の利用料が別途必要です。ツールを使うことで開発速度は上がりますが、費用対効果を判断する前提として、自分がどのくらいの頻度・規模でアプリを作るかを見積もっておくことをお勧めします。
段階設計は「AIの制御」のためではない
段階設計の目的は、AIを管理することではありません。「人間が小さな判断を繰り返しながら前に進む」ための構造を作ることです。一気に全部作ろうとすると、最初の判断ミスが最後まで尾を引きます。小さく進んで確認する、この繰り返しがアプリ開発の実態です。
最初の1本をどう始めるか
理屈は分かった。では実際にどこから始めるか。relmeaが実践から導いた手順を整理します。
ステップ1: 「1文で説明できるアプリ」から始める
「タスクを管理できるアプリ」ではなく「チームのタスクを期限・担当者・ステータスで管理し、毎朝Slackに未完了タスクを通知するアプリ」まで具体化してから着手します。機能が多い最初のイメージは、まず半分に削ってください。小さく作って動かし、使ってみて初めて「本当に必要な機能」が分かります。
ステップ2: データの形を先に決める
画面の見た目より先に、「どんなデータを保存するか」を書き出します。ユーザーのID・名前・メールアドレス、タスクのID・タイトル・期限・担当者ID・ステータス——これをテキストで箇条書きにするだけで構いません。データの形が決まれば、AIへの指示が具体的になります。
ステップ3: 画面を1枚ずつ作って確認する
全画面を一気に作らず、最も使う1画面から始めます。AIに「この画面だけを作って。データはダミーでよい」と指示し、実際にブラウザで動かして確認します。「これで合っている」と感じてから、次の画面に進みます。
ステップ4: 動くものができたら壊してみる
本番に出す前に、意図的に変な操作をしてみます。必須項目を空欄で送信する、存在しないURLに直接アクセスする、ログインせずに操作しようとする——これらを試してエラーが出るか、出た場合にどう表示されるかを確認します。AIに「この操作を試してエラーが起きる箇所を探して」と頼むと、検証の入口を任せられますが、最終的に問題ないと判断するのは人の役割です。
この4ステップは、relmeaの14フェーズ設計を非エンジニアが実践できる粒度まで圧縮したものです。「段階を分ける」「確認してから進む」という原則は変わりません。
最初の1本を作り終えたとき、次に感じる問いはおそらく「この開発の流れをもっと体系的に整理したい」というものになります。そのときに、フェーズ設計の全体像と、各フェーズでAIに何を指示するかの設計図が手元にあると、2本目以降が格段に速くなります。