AI ソフトウェア 公開日 2026.04.19 更新日 2026.04.19

生成AIにアプリ作成を頼むプロンプトのコツ|要件・画面・制約の伝え方

生成AIにアプリを作ってもらうとき、どんなプロンプトを書けば精度が上がるのか。要件、画面、データ、制約、優先順位、段階的な依頼方法まで実務向けに整理します。

先に要点

  • 生成AIにアプリ作成を頼むときは、技術名を並べるより、何を作るか・誰が使うか・何をさせたいかを先に書く方が精度が上がります。
  • 良いプロンプトは魔法の一文ではなく、要件定義の軽い版です。
  • 特に重要なのは、目的、対象ユーザー、主要画面、必要データ、制約、優先順位、やってほしくないことです。
  • いきなり `完成版を全部作って` と投げるより、画面設計、データ設計、MVP、実装、レビューの順で分けた方が失敗しにくいです。
  • AIは前提不足だと、それっぽいけれどズレたアプリを作りやすいので、曖昧な部分を減らすのがコツです。

生成AIにアプリを作ってもらいたいけど、どう頼めばいいか分からない という人は多いです。
実際、同じAIでも、依頼文の質で返ってくるものはかなり変わります。

ありがちなのは、Reactで家計簿アプリを作って。かっこよくして。ログインもつけて。 のような頼み方です。
これでも何かは返ってきますが、使いたいものとズレやすいです。

この記事では2026年4月19日時点で、OpenAIAnthropic、Googleの公式プロンプト設計ガイドを確認しながら、生成AIにアプリ作成を頼むときのプロンプトのコツを、実務寄りに整理します。
ここでいうアプリは、Webアプリ、業務ツール、社内管理画面、簡単なSaaS試作までを想定しています。

結論:アプリ作成プロンプトは「軽い要件定義」として書く

まず大事なのは、アプリ作成プロンプト気の利いた命令文 だと思わないことです。
実際には、AIに渡すための簡易な要件整理です。

OpenAIは、指示を先頭に置き、コンテキストを分け、望む結果や形式を具体的に書く方がよいと案内しています。
Anthropicも、複雑な依頼では instructions context input のように情報を構造化した方が誤解しにくいと説明しています。
Googleも、プロンプト設計では目的、文脈、期待する出力を明確にする考え方を案内しています。

つまり、アプリ作成で効くのは、派手な言い回しではなく、AIが迷わない材料を先に渡すこと です。

まず入れるべき7項目

アプリを作らせるとき、最低限これだけは入れた方がかなり変わります。

項目 ないと起きやすいこと
目的 顧客問い合わせを一覧管理したい 技術デモっぽいものになる
ユーザー 社内スタッフ3人が使う UIや権限が過剰になる
主要機能 登録、検索、更新、ステータス変更 不要機能が増える
主要画面 ログイン、一覧、詳細、編集 画面構成がぶれる
データ 顧客名、問い合わせ内容、担当者、期限 DB設計が雑になる
制約 Laravel + MySQL、PC利用中心、1週間で試作 勝手に別構成へ広がる
優先順位 まずMVP、通知や分析は後回し 最初から重いアプリになる

この7項目があるだけで、AIは どこまで作ればよいか を判断しやすくなります。

悪い依頼の典型

まず、ズレやすい依頼文の例です。

売上管理アプリを作って。
おしゃれで使いやすくして。

これだと、AIは次のことが分かりません。

  • 誰が使うのか
  • Webアプリスマホアプリ
  • 何を売上として記録するのか
  • 日次なのか案件単位なのか
  • 認証が要るのか
  • どの技術を使うべきか
  • MVPでよいのか完成版が欲しいのか

人間の開発者でも困る内容は、AIでも当然ぶれます。

良い依頼は「使う場面」が見える

良いプロンプトは、機能一覧だけでなく、使う場面が想像できます。

たとえば、次の方がかなり作りやすいです。

中小企業の営業チーム向けに、案件進捗を管理するWebアプリのMVPを作りたいです。

目的:
- Excelで管理している案件一覧をWeb化したい
- 営業3人が案件状況を共有できるようにしたい

利用者:
- 社内スタッフのみ
- PC利用が中心

必要機能:
- ログイン
- 案件一覧
- 案件の新規登録
- ステータス変更
- 担当者ごとの絞り込み

主要データ:
- 会社名
- 案件名
- 金額
- ステータス
- 担当者
- 次回連絡日

制約:
- Laravel + MySQL
- まずは管理画面だけ
- 通知、分析、権限の細分化は後回し

依頼:
まずは画面一覧、DBテーブル案、MVP範囲を提案してください。
その後に実装へ進めたいです。

この形だと、AIは完成コードをいきなり出すより前に、画面、データ、MVPを整理しやすくなります。

いきなり実装させない方がいい理由

ここはかなり大事です。
アプリ作成依頼で失敗しやすいのは、最初から全部実装させることです。

たとえば、次の順で分けると精度が上がりやすいです。

  1. 目的と対象ユーザーを整理する
  2. 主要画面を出す
  3. データ項目とテーブル案を出す
  4. MVPと後回し機能を分ける
  5. 技術構成を決める
  6. 実装する
  7. テスト観点とレビュー観点を出す

この流れなら、途中でズレを修正しやすいです。
逆に、最初から 全部入りで作って と頼むと、AIは見栄えのいい広い提案をしがちで、必要以上に大きくなります。

技術選定をどう書くか

技術選定は、最初から完全に固定してもよいですが、分からないならこう書く方が安全です。

Webアプリを作りたいです。
要件に合う技術構成を2案出してください。
ただし、個人開発で保守しやすく、日本語情報が多い構成を優先してください。

すでに決まっているなら、はっきり書きます。

Laravel + MySQLで作ってください。
フロントはBlade中心で、最初はSPAにしないでください。

AIは、技術が未指定だと勝手にモダン寄りへ広げることがあります。
それが悪いわけではありませんが、保守性や自分の学習コストとズレることがあります。

画面の伝え方

アプリ作成依頼では、画面の説明がかなり効きます。

たとえば、次のように画面単位で書けます。

必要画面:
- ログイン画面
- 一覧画面: 検索、絞り込み、並び替え
- 詳細画面: 履歴を表示
- 編集画面: ステータス、担当者、メモを更新
- 設定画面: 自分のプロフィールだけ変更

画面を書かないと、AIは機能はあっても、どこで何を操作するかが曖昧なまま進めがちです。
逆に画面が見えていると、UI、導線、権限、必要データまで整いやすくなります。

「やってほしくないこと」を書く

これはかなり実用的です。
AIは積極的に盛ることがあるので、禁止事項や後回し事項を書くと安定します。

たとえば、こうです。

やってほしくないこと:
- 最初から外部決済を入れない
- リアルタイム通知を入れない
- マイクロサービスにしない
- Docker前提の複雑な構成にしない
- 権限は管理者と一般ユーザーの2種類だけにする

この一文があるだけで、過剰設計をかなり減らせます。

デザイン依頼は別で書く

アプリ作成でよくある失敗は、機能要件とデザイン要件が混ざることです。
かっこいい感じで おしゃれに だけだと、実装優先順位がぼやけます。

デザインを頼むなら、次のように分ける方がよいです。

  • 情報量を優先した管理画面
  • 落ち着いた配色
  • PC中心で表を見やすく
  • 装飾より操作の分かりやすさ重視

アプリの種類によっては、派手さより操作の速さが大事です。
業務アプリなら、見た目の印象より、一覧、検索、入力しやすさを優先した方が満足度が高いことが多いです。

実務でよくある失敗

1. 用途より機能数を盛る

AIに 売上、在庫、顧客管理、分析、通知、権限、チャット、レポートも全部 と乗せると、試作のはずが大きな業務システムになります。
まずは最小限の流れを通せるMVPを決める方が先です。

2. データ項目を書かない

アプリは見た目より、データ設計で失敗しやすいです。
何を登録するかを書かないと、後で画面もDBも手戻りしやすくなります。

3. 誰が使うかを書かない

個人向けアプリと社内管理ツールでは、必要なUIも認証も全然違います。
ユーザー像が抜けると、便利そうだけど使いにくいものが返ってきやすいです。

4. いきなり完成版を求める

AIは一気に大きいものを頼まれると、整って見える雛形を出しがちです。
でも、実際に必要な細部は後からズレが出ます。

そのまま使いやすいテンプレート

あなたはWebアプリのプロダクト設計と実装を支援するAIです。
次の条件で、まずはMVP設計を手伝ってください。

<目的>
- 何を解決したいか:
- なぜ必要か:

<対象ユーザー>
- 誰が使うか:
- 利用人数:
- PC中心かスマホ中心か:

<必要機能>
- 
- 
- 

<主要画面>
- 
- 
- 

<登録したいデータ>
- 
- 
- 

<制約>
- 使用したい技術:
- 期間:
- 予算感:
- 後回しにしたい機能:

<やってほしくないこと>
- 
- 

<出力してほしい内容>
1. MVPの範囲
2. 主要画面一覧
3. データ設計案
4. 実装順序
5. 想定リスク

最初はこのテンプレートを埋めるだけでも、かなり変わります。

まとめ

アプリを作成してもらうときの生成AIプロンプトのコツは、難しいテクニックより、曖昧さを減らすことです。
目的、ユーザー、主要機能、画面、データ、制約、優先順位、禁止事項まで書けると、AIはかなり働きやすくなります。

特に効果が高いのは、いきなり完成版を頼まず、設計、MVP、実装、レビューへ分けることです。
このやり方に変えるだけで、それっぽいけれど使えないアプリ案 をかなり減らせます。


参考リンク

あとで見返すならここで保存

読み終わったあとに残しておきたい記事は、お気に入りからまとめて辿れます。