AIアプリビルダーへのプロンプトの書き方（修正前後の例付き）

AIアプリビルダーへの良いプロンプトは、コードではなくプロダクトを説明します。誰が使うのか、どんな手順で何をするのか、どんなデータを保存するのか、誰が何を見られるのかです。最初のバージョンができたら、1メッセージにつき具体的な変更を1つだけ頼み、変えてはいけないものを伝え、問題は「Xをしたら、Yを期待したが、Zになった」という形で説明してください。この3つの習慣で、がっかりする結果の大半は解決します。

このガイドの残りでは、そのパターンを詳しく紹介します。自由に応用できる修正前後の例も載せています。

アプリビルダーへのプロンプトが、AIとのチャットと違う理由

チャットアシスタントに質問すると、曖昧なプロンプトには曖昧な答えが返ってきて、そこで終わります。しかしAIアプリビルダーにプロンプトを送ると、返ってくるのは動くプログラムです。説明の抜けはすべて推測で埋められ、その推測がコード、データベースのテーブル、画面になります。あなたは、それを受け入れるか、取り消す作業をすることになります。

そのため、プロンプトの目的は賢く聞こえることではありません。重要な判断を偶然に任せる部分を減らすことです。そのために専門用語は必要ありません。あなたしか知らないこと、つまり自分のユーザー、仕事の流れ、そしてルールを具体的に書けば十分です。

最初のプロンプトに含めること

何かを書く前に、次の質問に答えてください。どれもAIが推測してしまう抜けを埋めるためのものです。

最後の行は見落とされがちですが、重要です。「やらないこと」を伝えると、頼んでいないブログ、料金ページ、ニュースレターの登録フォームをAIが勝手に追加するのを防げます。

修正前後の例：最初のプロンプト

修正前：

私のジム用のアプリを作ってください。

ビルダーは何もかも推測しなければなりません。会員向けかスタッフ向けか？ クラスか個人トレーニングか？ 決済は必要か？ 結果として、ジムのウェブサイトのように見えて、必要な機能が何もないものができあがります。

修正後：

小さなヨガスタジオ向けのクラス予約アプリを作ってください。会員は今週のクラス（名前、講師、時間、残り枠）を見て、枠を予約し、開始の2時間前までキャンセルできます。会員はメールアドレスとパスワードで登録します。スタジオのオーナーはログインして、クラスを追加し、誰が予約しているかを確認し、出席を記録できます。クラス、会員、予約はデータベースに保存してください。落ち着いた明るいデザインで、スマートフォンでも見やすいものにしてください。決済はまだ不要です。

修正後のプロンプトも短いままです。上の表の質問に答えているだけです。

実装ではなく、振る舞いを説明する

作り方を指示するより、何が起きるべきかを説明したほうが、多くの場合うまくいきます。

修正前：

予約を取得するuseEffectと、編集用のモーダルコンポーネントを追加してください。

修正後：

オーナーが予約をクリックしたら、時間を変更したりキャンセルしたりできるパネルを開いてください。変更はすぐにリストに反映されるようにしてください。

最初のプロンプトは、アプリの構造に合わないかもしれない特定の手法にAIを縛りつけてしまいます。2つ目のプロンプトは、望む結果を伝え、すでに書かれているコードに合った適切な方法をAIに選ばせます。もしあなたが開発者で、強い希望がある場合は、そう伝えてかまいません。ただしその場合も、望む結果とあわせて伝えてください。

ルールは具体的に書く

AIで作ったアプリがもっともよく間違えるのは、業務上のルールです。あなたにとっては当たり前でも、AIには見えないからです。ルールは明文化してください。

• 上限： 「会員が持てる未来の予約は最大3件まで」
• タイミング： 「キャンセルはクラス開始の2時間前で締め切る」
• エッジケース： 「クラスが満員なら、予約ボタンではなくキャンセル待ちボタンを表示する」
• 権限： 「講師は自分のクラスの出席状況は見られるが、他の講師のクラスは見られない」

どれも1文で書けます。どれかを抜かすと、アプリはそのルールを適用しないか、勝手に別の解釈を作ってしまいます。

最初のバージョンのあと：1メッセージに1つの変更

プレビューで何かが動いたら、プロダクト全体を説明するのをやめて、小さく確認できる変更を頼むようにしましょう。

修正前：

デザインがずれています。予約もうまく動かないので、カレンダー表示とメール機能も欲しいです。

修正後（4つの別々のメッセージとして送る）：

1. クラスの最後の枠を予約すると、まだ「残り1枠」と表示されます。「満員」と表示して、予約ボタンは非表示にしてください。
2. スケジュールページに週表示のカレンダーを追加してください。1日につき1列です。現在のリスト表示もオプションとして残してください。
3. スマートフォンでクラスカードをもっとコンパクトにしてください。余白を小さくし、講師名を時間と同じ行に表示してください。
4. 予約が完了したら、会員に確認メールを送ってください。

この方法がうまくいく理由は次のとおりです。

• 各変更は、AIが1回の作業で正しく行えるほど小さいです。
• 次に進む前に、それぞれを確認できます。
• ひとつが失敗しても、その手順だけを取り消して、他の変更は失わずに済みます。

残すべきものを伝える

すでに動いている部分の変更を頼むときは、変えてはいけないものをAIに伝えてください。これは、回帰（以前は動いていたものが、編集後に壊れること）を防ぐ最も簡単な方法です。

ホームページのヒーローセクションを、見出しを大きくして右側に写真を置く形にデザインし直してください。ナビゲーション、配色、ヒーローより下の部分はすべて今のままにしてください。

データにも同じことが言えます。「会員に電話番号の項目を追加してください。既存の項目は削除も名前変更もしないでください。」

スクリーンショットと正確な文言を使う

「上の方にあるもの」のような言い方はあいまいです。多くのAIアプリビルダーは画像を受け付けるので、短いメモを添えたスクリーンショットのほうが、長い説明文よりも速く伝わります。

• スクリーンショットを添付して、「赤で囲んだボタンが、スマートフォンでメニューと重なっています」と書く。
• エラーメッセージは、言い換えずに正確な文言を貼り付ける。
• 画面上のラベルは正確に引用する。「設定ページの変更を保存ボタン」のように書く。

バグについては、特に次の形で伝えてください。

予約ページで、明日の予約のキャンセルをクリックしました。リストから消えると思っていました。ところが何も起こらず、再読み込みしても予約が残っています。修正して、キャンセルが動くことを確認してください。

AIで作ったアプリのデバッグ方法については、こちらのガイドで詳しく説明しています。

大きな変更は、先に計画を立てる

アプリの多くの部分に関わる変更（ユーザーアカウントがなかったアプリにアカウント機能を追加する、決済を追加する、データの構造を変えるなど）は、コードを変更する前に計画を求めてください。

何かを変更する前に、チームアカウントをどう追加するかを説明してください。新しく作るテーブル、変わるページ、既存のユーザーに何が起こるかを含めてください。まだコードは編集しないでください。

計画を読んでください。もし誤解があれば、完成した機能を直すより、1段落を直すほうがずっと安上がりです。多くのビルダーには、この用途のための専用モードがあります。Mythexでは、BuildやAskと並んでPlanモードがそれにあたります。

避けるべきこと

APIキーについて：決済やメールのサービスが必要な場合は、そのキーをプロンプトではなく、プロジェクトのシークレットに入れてください。もし不慣れであれば、環境変数とシークレットとは何かをご覧ください。

再利用できるプロンプトのテンプレート

角括弧の部分を置き換えて使ってください。

新しいアプリ：

〔誰〕向けの〔アプリの種類〕を作ってください。利用者は〔主な流れを手順で〕。〔2つ目の種類のユーザー〕は、〔すること〕のためにログインします。〔データ〕はデータベースに保存してください。〔見た目と雰囲気〕。〔今回は含めないもの〕は含めないでください。

新しい機能：

〔ページ〕に〔機能〕を追加してください。〔ユーザー〕が〔操作〕をしたら、〔起きるべきこと〕。〔誰〕だけが〔すること〕できます。〔既存のもの〕はそのまま残してください。

デザインの変更：

〔ページ〕で、〔特定の要素〕を〔具体的な変更〕にしてください。〔残すもの〕はそのままにしてください。スマートフォンの幅の画面でも正しく見えるか確認してください。

バグ：

〔ページ〕で、〔手順〕を行いました。〔期待すること〕を期待していました。実際には〔実際の結果と正確なエラー文言〕。修正して、操作の流れが動くことを確認してください。

変更を伴わない質問：

コードは変更しないでください。アプリの〔部分〕がどう動くか、〔データ〕がどこに保存されているかを説明してください。

より長い仕様書を書く

大きなプロジェクトでは、最初に1ページの概要を書いて、最初のプロンプトとして貼り付けると役立つことがあります。その概要には、ユーザー、主要な流れ、データ、ルール、そして対象外の内容を含めます。AIに下書きを手伝ってもらうこともできます。その方法は、AIでプロダクト要件定義書を書く方法で説明しています。最初のビルドの依頼は主要な流れだけに絞り、残りは段階的に追加してください。

Mythexでのプロンプト

上で紹介したことはすべてMythexで使えます。役立つ具体的なポイントをいくつか挙げます。

• Build、Plan、Askモード。 大きなまたはリスクのある変更にはPlanを使い、編集を伴わない説明がほしいときはAskを使ってください。
• チェックポイント。 変更が成功するたびに、Mythexはチェックポイントを保存します。返信のこの時点に戻すを選ぶと、プロジェクトをその時点まで巻き戻せます。また、前のメッセージを編集して再送信すれば、その時点から別のプロンプトを試すこともできます。
• シークレットのカード。 エージェントがAPIキーを必要とすると、チャット内のカードを通じて尋ねてきます。そのため、値はメッセージに書かずに、プロジェクトのシークレットとして保存されます。
• 画像。 スクリーンショットやモックアップを添付すると、エージェントがそれを確認します。

ドキュメントには、効果的なプロンプトと、再構築せずに繰り返し改善する方法の短いページがあります。ゼロから始めるなら、AIでアプリを作る方法が完全なプロジェクトの流れを説明しています。見栄えの良いデザインを求める場合は、AIで見栄えの良いアプリをデザインする方法で、見た目を整えるためのプロンプトを解説しています。

よくある質問