先に要点
「生成AIにアプリを作ってもらいたいけど、どう頼めばいいか分からない」という人は多いです。実際、同じAIでも、依頼文の質で返ってくるものはかなり変わります。
ありがちなのは、「Reactで家計簿アプリを作って。かっこよくして。ログインもつけて。」のような頼み方です。これでも何かは返ってきますが、使いたいものとズレやすいです。
この記事では2026年6月時点の各社プロンプト設計ガイドと現行のAIコーディングツール事情を踏まえて、生成AIにアプリ作成を頼むときのプロンプトのコツを、実務寄りに整理します。ここでいうアプリは、Webアプリ、業務ツール、社内管理画面、簡単なSaaS試作までを想定しています。
そして本記事の主眼は、後半の「テンプレートを埋めてもAIがズレる5箇所と、直すための一文」です。一般論ではなく、実際に投げたときに起きるズレと、その場で足す具体的な一文を載せます。
結論：アプリ作成プロンプトは「軽い要件定義」として書く
まず大事なのは、アプリ作成プロンプトを「気の利いた命令文」だと思わないことです。実際には、AIに渡すための簡易な要件整理です。
OpenAIは、指示を先頭に置き、コンテキストを分け、望む結果や形式を具体的に書く方がよいと案内しています。Anthropicも、複雑な依頼では指示・文脈・入力データのように情報を構造化した方が誤解しにくいと説明しています。Googleも、プロンプト設計では目的、文脈、期待する出力を明確にする考え方を案内しています。
つまり、アプリ作成で効くのは、派手な言い回しではなく、AIが迷わない材料を先に渡すことです。プロンプトの良し悪しは語彙ではなく情報の構造で決まります。
まず入れるべき7項目
アプリを作らせるとき、最低限これだけは入れた方がかなり変わります。
| 項目 | 例 | ないと起きやすいこと |
|---|---|---|
| 目的 | 顧客問い合わせを一覧管理したい | 技術デモっぽいものになる |
| ユーザー | 社内スタッフ3人が使う | UIや権限が過剰になる |
| 主要機能 | 登録、検索、更新、ステータス変更 | 不要機能が増える |
| 主要画面 | ログイン、一覧、詳細、編集 | 画面構成がぶれる |
| データ | 顧客名、問い合わせ内容、担当者、期限 | DB設計が雑になる |
| 制約 | Laravel + MySQL、PC利用中心、1週間で試作 | 勝手に別構成へ広がる |
| 優先順位 | まずMVP、通知や分析は後回し | 最初から重いアプリになる |
この7項目があるだけで、AIは「どこまで作ればよいか」を判断しやすくなります。
悪い依頼の典型
まず、ズレやすい依頼文の例です。
売上管理アプリを作って。
おしゃれで使いやすくして。
これだと、AIは次のことが分かりません。
人間の開発者でも困る内容は、AIでも当然ぶれます。
良い依頼は「使う場面」が見える
良いプロンプトは、機能一覧だけでなく、使う場面が想像できます。たとえば、次の方がかなり作りやすいです。
中小企業の営業チーム向けに、案件進捗を管理するWebアプリのMVPを作りたいです。
目的:
- Excelで管理している案件一覧をWeb化したい
- 営業3人が案件状況を共有できるようにしたい
利用者:
- 社内スタッフのみ
- PC利用が中心
必要機能:
- ログイン
- 案件一覧
- 案件の新規登録
- ステータス変更
- 担当者ごとの絞り込み
主要データ:
- 会社名
- 案件名
- 金額
- ステータス
- 担当者
- 次回連絡日
制約:
- Laravel + MySQL
- まずは管理画面だけ
- 通知、分析、権限の細分化は後回し
依頼:
まずは画面一覧、DBテーブル案、MVP範囲を提案してください。
その後に実装へ進めたいです。
この形だと、AIは完成コードをいきなり出すより前に、画面、データ、MVPを整理しやすくなります。
いきなり実装させない方がいい理由
ここはかなり大事です。アプリ作成依頼で失敗しやすいのは、最初から全部実装させることです。次の順で分けると精度が上がりやすいです。
この流れなら、途中でズレを修正しやすいです。逆に、最初から「全部入りで作って」と頼むと、AIは見栄えのいい広い提案をしがちで、必要以上に大きくなります。
このテンプレでAIがズレる5箇所と、直すための一文（本記事の核心）
ここからが本題です。後半に載せるテンプレートは便利ですが、埋めて投げてもAIがズレやすい箇所はだいたい決まっています。原因と、その場で足す一文を Before/After で示します。すべて、テンプレートを埋めた状態からの追記で直せます。
ズレ1：「MVPでいい」と書いたのに全機能の雛形を出してくる
- 現象：「まずMVP」と書いたのに、通知・権限・分析まで含む大きなディレクトリ構成とコードが一気に返る。
- 原因：MVPの「中身」を範囲として言語化していない。AIは「MVP=それっぽい完成形の最小版」と解釈し、盛る方向に倒れます。
Before（ズレる）
「まずはMVPでお願いします。」
After（足す一文）
「MVPは『ログイン → 案件一覧 → 新規登録 → ステータス変更』の1本の流れだけです。検索・絞り込み・通知・権限・分析はこの段階では実装せず、画面にも置かないでください。MVPに含めない機能は『後回し一覧』として箇条書きで返すだけにしてください。」
ズレ2：技術を指定したのに勝手にモダン構成へ広げる
- 現象：「SPAにしないで」と書いても、Reactや状態管理ライブラリ前提のコードが出る。あるいはサーバーサイドのテンプレートを頼んだのに、APIとフロントを分離した構成が返る。
- 原因：「しないでほしいこと」を1回しか書いていないと、AIは学習データ上で多数派の構成（モダンSPA寄り）に引っ張られます。
最後の「反するなら確認して」の一文が効きます。AIに勝手に判断させず、分岐をこちらへ戻させるためです。
ズレ3：データ項目を書いたのに、型・必須・リレーションが曖昧なまま進む
- 現象：「会社名・案件名・金額・担当者」と書いたのに、すべて文字列カラムのテーブルが出て、金額が文字列、担当者が外部キーになっていない。
- 原因：項目名だけでは、AIは型と関連を推測で埋めます。推測は当たることもありますが、後でマイグレーションのやり直しになりがちです。
Before（ズレる）
「主要データ：会社名、案件名、金額、ステータス、担当者、次回連絡日」
After（足す一文）
「各データの型と制約も決めてください。金額は整数(円)、ステータスは enum(商談中/受注/失注)、担当者は users テーブルへの外部キー、次回連絡日は date 型でNULL許可。会社は別テーブルにして案件と1対多にしてください。確定したらテーブル定義(カラム名・型・NULL可否・キー)を表で返してください。」
ズレ4：「やってほしくないこと」が無視されて過剰実装になる
- 現象：「Docker前提にしないで」「外部決済を入れないで」と書いても、docker-compose.yml や決済の雛形が混ざってくる。
- 原因：禁止事項を本文の途中に1行だけ置くと、長いプロンプトの中で埋もれます。AIは「全体として良いものを」を優先し、禁止を上書きしがちです。
Before（ズレる）
「Docker前提にしないでください。決済はまだ入れません。」
After（足す一文）
「次は厳守してください（破ったら作り直しになります）。Dockerやdocker-composeのファイルは生成しない。外部決済・課金は一切入れない。マイクロサービス化しない。権限は管理者と一般の2種類だけ。これらに該当するコードや設定ファイルが出力に含まれていないか、最後に自分でチェックしてから返してください。」
禁止事項は「最後に自分でチェックして」とセルフレビューを促すと、抜けが減ります。
ズレ5：設計だけ頼んだのに、勝手に全実装まで走る
- 現象：「まず画面一覧とDB案を提案して」と書いたのに、提案を飛ばして完成コードが返ってくる。
- 原因：依頼の最後に「その後に実装へ進めたい」と書くと、AIは「最終的に実装が要る」と読み、先回りします。
Before（ズレる）
「まずは画面一覧、DBテーブル案、MVP範囲を提案してください。その後に実装へ進めたいです。」
After（足す一文）
「このターンではコードを一行も書かないでください。出力は『画面一覧・DBテーブル案・MVP範囲』の3点だけ。私がレビューしてOKを出してから、次のターンで実装に入ります。実装を始めてよいか、最後に確認の質問をしてください。」
「このターンでは書かない」「OKを出してから」と段階を明示するのが要点です。最近のモデルは指示に忠実なので、こう書くだけで先走りを止められます。
技術選定をどう書くか
技術選定は、最初から完全に固定してもよいですが、分からないならこう書く方が安全です。
Webアプリを作りたいです。
要件に合う技術構成を2案出してください。
ただし、個人開発で保守しやすく、日本語情報が多い構成を優先してください。
それぞれ、学習コストと保守のしやすさを一言で添えてください。
すでに決まっているなら、はっきり書きます。
Laravel + MySQLで作ってください。
フロントはBlade中心で、最初はSPAにしないでください。
AIは、技術が未指定だと勝手にモダン寄りへ広げることがあります。それが悪いわけではありませんが、保守性や自分の学習コストとズレることがあります。SSR中心で十分なのに、不要なSPA構成を提案されると学習・保守コストが跳ね上がるので、ここは明示しておくのが安全です。
画面の伝え方
アプリ作成依頼では、画面の説明がかなり効きます。たとえば、次のように画面単位で書けます。
必要画面:
- ログイン画面
- 一覧画面: 検索、絞り込み、並び替え
- 詳細画面: 履歴を表示
- 編集画面: ステータス、担当者、メモを更新
- 設定画面: 自分のプロフィールだけ変更
画面を書かないと、AIは機能はあっても、どこで何を操作するかが曖昧なまま進めがちです。逆に画面が見えていると、UI、導線、権限、必要データまで整いやすくなります。
デザイン依頼は別で書く
アプリ作成でよくある失敗は、機能要件とデザイン要件が混ざることです。「かっこいい感じで」「おしゃれに」だけだと、実装優先順位がぼやけます。デザインを頼むなら、次のように分ける方がよいです。
- 情報量を優先した管理画面
- 落ち着いた配色
- PC中心で表を見やすく
- 装飾より操作の分かりやすさ重視
業務アプリなら、見た目の印象より、一覧、検索、入力しやすさを優先した方が満足度が高いことが多いです。なお、最近のモデルは指定がないと特定の「お決まりの見た目」（クリーム色背景にセリフ体など）へ寄せる傾向があるので、業務系では配色や余白の方針を具体的に指定するか、「4案出して」と提案させてから選ぶと安定します。
実務でよくある失敗
1. 用途より機能数を盛る
AIに「売上、在庫、顧客管理、分析、通知、権限、チャット、レポートも全部」と乗せると、試作のはずが大きな業務システムになります。まずは最小限の流れを通せるMVPを決める方が先です。
2. データ項目を書かない
アプリは見た目より、データ設計で失敗しやすいです。何を登録するかを書かないと、後で画面もDBも手戻りしやすくなります。
3. 誰が使うかを書かない
個人向けアプリと社内管理ツールでは、必要なUIも認証も全然違います。ユーザー像が抜けると、便利そうだけど使いにくいものが返ってきやすいです。
4. いきなり完成版を求める
AIは一気に大きいものを頼まれると、整って見える雛形を出しがちです。でも、実際に必要な細部は後からズレが出ます。
そのまま使いやすいテンプレート
あなたはWebアプリのプロダクト設計と実装を支援するAIです。
次の条件で、まずはMVP設計を手伝ってください。
【目的】
- 何を解決したいか:
- なぜ必要か:
【対象ユーザー】
- 誰が使うか:
- 利用人数:
- PC中心かスマホ中心か:
【必要機能】
-
-
-
【主要画面】
-
-
-
【登録したいデータ（型・必須・関連も）】
-
-
-
【制約】
- 使用したい技術:
- 期間:
- 予算感:
- 後回しにしたい機能:
【やってほしくないこと（厳守）】
-
-
【このターンの出力範囲】
- コードは書かない / 設計のみ など、ここで段階を指定する
【出力してほしい内容】
1. MVPの範囲（含めない機能の一覧も）
2. 主要画面一覧
3. データ設計案（テーブル定義を表で）
4. 実装順序
5. 想定リスク
最初はこのテンプレートを埋めるだけでも、かなり変わります。そして、前述の5つのズレが出たら、その箇所だけ「足す一文」を追記してください。
AIアプリ作成プロンプトに関するよくある質問
Q. AIにアプリを作らせる場合、どの程度の規模まで現実的ですか？
A. 個人向けツール、CRUDの単純Webアプリ、社内集計ツール、デモアプリなら数時間〜数日で動くレベルまで作れます。決済、認証基盤、複雑な業務ロジックを含む本格アプリは、人間の設計とレビューが必須です。目安として、テーブル数が数個・画面が10前後までなら一気に進めやすく、それを超えると機能ごとに分割して依頼する方が安定します。
Q. どのツール・モデルが向いていますか？
A. 2026年時点の定番は、ターミナルで動くエージェント型のClaude Code（Anthropic、料金は月20〜200ドル帯のプラン）、AI特化IDEのCursor、どのIDEでも使えるGitHub Copilot（個人向けで月10ドル前後）の3つです。経験者ほど、日常の編集はCursorかCopilot、込み入った複数ファイル横断の作業はClaude Code、というハイブリッド運用が多いです。共通して言えるのは、コード生成・ファイル直接編集・コマンド実行までできる「エージェント／IDE統合型」が、チャット欄にコードを書かせて貼る方式より圧倒的に速いことです。なお本記事のプロンプト設計のコツは、どのツールでも同じように効きます。
Q. プロンプトが長いと品質は上がりますか？
A. 必要な情報を網羅すれば上がります。逆に、関係ない情報を大量に貼ると重要情報が埋もれて無視されることもあります。「必要十分」を意識し、禁止事項と出力範囲は文末にまとめて目立たせるのが効果的です。
Q. AIが作ったコードの著作権・権利関係はどうなりますか？
A. ここは2026年時点で誤解が多い点です。主要なAIサービスの利用規約は、出力に対する権利を利用者に帰属させる形になっています（OpenAIは出力の権利を利用者へ譲渡、Anthropicも商用規約で出力の権利を顧客が保持できると規定）。一方で重要な前提が2つあります。1つ目は、純粋にAIだけが生成した成果物は、人間の創作的関与が乏しいとパブリックドメイン扱いになり得るという点で、編集・取捨選択・改変といった人の判断を加えることが保護の鍵になります。2つ目は、規約が権利を渡してくれても「第三者の権利を侵害しない保証」までは付かないのが一般的という点です（Anthropicのように一定条件下で侵害請求を防御する規定を設ける例もあります）。商用利用前には、使うサービスの最新規約と、競合モデルの開発に出力を使わない等の制限を必ず確認してください。
Q. AIに作らせたコードのテストは誰が書きますか？
A. AIにも書かせますが、必ず人が確認します。AI生成テストは正常系に寄りがちなので、境界値、エラーケース、認証・認可、入力バリデーションといった観点を人間が補強するのが安全です。テスト観点の一覧自体をAIに列挙させ、それを人がレビューする手順が現実的です。
Q. プロンプトで失敗するパターンは？
A. 要件が曖昧、対象ユーザー不明、技術スタック未指定、出力形式未指定、評価軸未指定、の5つが典型です。「一回で完璧」を目指すのではなく、「一回出す → ズレた箇所に一文足す → 直す」を前提に進める方が現実的です。本記事の「ズレる5箇所」がまさにこのパターンに対応しています。
Q. プロンプトをチームで共有する価値はありますか？
A. 大いにあります。同じ依頼で同じ品質のコードが出やすくなり、生産性のばらつきが減ります。社内Wikiやリポジトリ内のドキュメント（CLAUDE.mdのような規約ファイルや、PRテンプレート、コーディング規約）に、良いプロンプトと「足す一文」をストックしておくと、レビュー基準も揃いやすくなります。
Q. AIは設計どおりに作ってくれないことがあるのはなぜですか？
A. AIは「全体として良いものを」優先する傾向があるため、こちらの制約より一般的なベストプラクティスを上書きしがちです。だからこそ、本記事のように「禁止事項を文末にまとめる」「このターンの出力範囲を区切る」「最後にセルフチェックさせる」「反するなら確認させる」といった、行動を縛る一文が効きます。語彙を盛るより、分岐をこちらに戻す指示の方が結果を安定させます。
まとめ
アプリを作成してもらうときの生成AIプロンプトのコツは、難しいテクニックより、曖昧さを減らすことです。目的、ユーザー、主要機能、画面、データ、制約、優先順位、禁止事項まで書けると、AIはかなり働きやすくなります。
そのうえで、テンプレートを埋めても残る5つのズレ（MVPが膨らむ、技術が広がる、データ型が曖昧、禁止が無視される、設計だけのはずが全実装に走る）は、本記事の「足す一文」でその場で直せます。いきなり完成版を頼まず、設計、MVP、実装、レビューへ分け、ズレたら一文足す。このやり方に変えるだけで、「それっぽいけれど使えないアプリ案」をかなり減らせます。
参考リンク
- OpenAI API Docs: Prompt engineering
- OpenAI Help Center: Best practices for prompt engineering with the OpenAI API
- Anthropic Docs: Prompt engineering overview
- Anthropic News: Expanded legal protections and improvements to our API
- Google AI for Developers: Prompt design strategies