AIアプリビルダーのプロンプトの書き方【ビフォー・アフター実例付き】
同じAIアプリビルダーを2人が1時間使う様子を観察してみてください。1人は動くアプリを手にし、もう1人は散らかったプロジェクトと「AIコーディングは過大評価だ」という意見を手にします。ツールは同一でした。違ったのはプロンプトです。
アプリビルダーへのプロンプトは、チャットボットへのプロンプトとは別のスキルです。あなたは質問をしているのではありません。あなたが言ったこと・言わなかったことに基づいて何十もの判断を下すエージェントに、作業指示書を渡しているのです。ここでは実際に効くテクニックを、ビフォー・アフターの実例とともに紹介します。
最初のプロンプト:決定事項を前もって詰め込み、実装の話はしない
冒頭のプロンプトがプロジェクトの土台を決めます。あなたが残した空白を、エージェントはすべて推測で埋めます。良いエージェントの推測は妥当ですが、どの推測もあなたの意図に当たるかどうかはコイントスです。
ビフォー:
フィットネスアプリを作って。
アフター:
ウェイトリフター向けのワークアウトトラッカーを作ってください。データ:ワークアウトには日付があり、各ワークアウトにはエクササイズ名、セット数、レップ数、重量の記録があります。画面:(1) クイック入力付きの今日の記録、(2) 週ごとにグループ化された履歴、(3) エクササイズ別の進捗チャート。ユーザーは1人、ログイン不要。ダークでミニマルなデザイン。
「アフター」版は、対象ユーザー、データモデル、画面、認証の範囲、ビジュアルの方向性を決めています——後から変更するとコストが高くつく5つの判断です。そして含めていないものにも注目してください。技術スタックも、データベースの選択も、コンポーネントライブラリもありません。良いプラットフォームはそうした判断をプロンプトよりも上手に下しますし、生半可に理解した技術用語でブリーフを埋めるのは逆効果です(プラットフォームが Postgres を中心に作られているのに「MongoDB を使って」と書けば、摩擦を生むだけです)。
一貫して機能する構成はこうです。
- それが何なのかを1文で、対象ユーザーとともに。
- データを、平易な名詞とフィールドで。
- 画面を、番号付きで。
- 明示的な除外事項——「ログイン不要」「決済なし」。除外を書いておくと、エージェントが良かれと思って勝手に発明するスコープを防げます。
イテレーションのプロンプト:1つの変更を、場所に固定して
最初のビルドが終わると、プロンプトの性格が変わります。設計から外科手術へ。仕事の大半は2つのルールで片付きます。
1メッセージにつき1つの変更。 まとめた要望は一蓮托生で失敗します。5つの変更のうち1つが外れると、残り4つを壊さないように再プロンプトすることになります。
すべての変更を場所に固定すること。
ビフォー:
日付の表示がおかしい。
アフター:
履歴ページの週ヘッダーが「Week 32」と表示されています。代わりに「8月4日〜8月10日」のような日付範囲を表示してください。
画面を名指しし、間違っているテキストを引用し、正しいテキストを説明する。エージェントは探し回ることなく正確な場所を見つけます——誤った推測が減り、クレジットも減ります。
実装ではなく、結果を説明する
開発者のように話したくなるはずです。あなたが開発者でないなら、我慢してください。
ビフォー:
マウント時に再フェッチする useEffect を追加して、リストのレンダリングをメモ化して。
アフター:
支出を追加してからダッシュボードに戻ると、リロードするまで合計が古い数字のままです。常に最新であってほしいです。
前者はエージェントをあなたの診断に縛り付けます。その診断は間違っているかもしれません。後者は実際の欠陥——あなたが確信を持てること——を渡し、原因の特定はエージェントに任せています。症状はユーザーとしての自信を持って説明し、診断はコードを読める側に任せましょう。
参照例を使う——形容詞より雄弁です
「モダンでクリーン」は何も意味しません。2010年以降のすべてのデザインがそう名乗ってきました。参照例は桁違いの情報量を運びます。
料金セクションを Linear の料金ページのような雰囲気にしてください:たっぷりの余白、細いボーダー、アクセントカラーは1色。
さらに良いのはスクリーンショットの添付です——気に入っているアプリ、手描きのスケッチ、あなたが説明しようとしている壊れたレイアウトそのもの。画像添付に対応したプラットフォーム(Massvai は対応しています)は、文章よりもはるかに速く、1枚の画像からビジュアルの曖昧さを解消します。バグのスクリーンショットに1行のキャプションを添えたもの——これが存在する中で最も価値の高いプロンプト形式です。
うまくいかないとき:掘るのをやめる
プロンプトで最も高くつく失敗は、下手なプロンプトではありません。根本的にずれた方向を、4回連続で継ぎ接ぎしようとすることです。
同じ修正を2回試してだめだったら、戦略を変えましょう。
- ロールバックする。 散らかる前のチェックポイントを復元し(Massvai はすべての生成でスナップショットを取ります)、別の説明でアプローチし直してください。後戻りは損した気分になりますが、たいてい前進への最短路です。
- ズームアウトする。 修正内容を再説明する代わりに、目的を説明してください。「フィルタードロップダウンについての以前の指示は忘れてください。ユーザーにさせたいのはこういうことです:……」。エージェントは、積み重なった継ぎ接ぎの指示よりも、新鮮な目的のほうをうまく扱えます。
チートシート
| 状況 | やること | やらないこと |
|---|---|---|
| プロジェクト開始 | 対象ユーザー+データ+画面+除外事項 | 「Xのアプリを作って」 |
| 変更の依頼 | 1つの変更を、画面に固定して | 1メッセージに5つの変更 |
| バグの報告 | 症状、場所、期待する動作 | コードレベルの原因の推測 |
| デザインの方向性 | 参照アプリとスクリーンショット | 形容詞の羅列 |
| 2回試して行き詰まった | ロールバックして目的を再説明 | 5回目の「もう一度やって」 |
どれも特別なことではありません。人間の外注先に対して当然示すべき明晰さと同じです——ただしこの外注先は、注意深く読み、細かい指示に苛立つことがなく、数秒で作業を始めます。それに見合うブリーフを渡してあげましょう。
