Rork で作るモバイルアプリのためのプロンプト設計ブループリント

Rork で初めてアプリを作った時、私は驚きと困惑を同時に味わいました。「ToDo アプリを作って」と書くだけで、それなりに動くアプリが数分で生成される驚き。一方で、欲しい機能を細かく言語化しても期待通りに実装されない困惑。この差を分けるのが、プロンプト設計の質です。

私はこの一年、Rork で複数のアプリを商用レベルまで仕上げる中で、プロンプト設計の試行錯誤を重ねてきました。ここではその経験から導いた『モバイルアプリ開発に最適化されたプロンプト設計』を体系的にお伝えします。

なぜモバイルアプリのプロンプトは特殊なのか

汎用的なコード生成と、モバイルアプリ開発のためのコード生成には、決定的な違いがあります。モバイルアプリには『画面遷移』『状態管理』『プラットフォーム慣習』という三つの特殊な制約があるためです。

画面遷移は、Web よりも厳格です。タブバー、スタックナビゲーション、モーダルといった構造を、ユーザーは無意識に期待します。これを言語化せずに「画面を作って」と頼むと、Rork はそれぞれ独立した画面を作ってしまい、連携が取れない実装になります。

状態管理も同様です。モバイルアプリでは、画面間でデータを共有する場面が頻繁にあります。「カートに追加した商品が決済画面に表示される」のような連携を、Rork に明示的に伝える必要があります。

プラットフォーム慣習は、特に iOS と Android で大きく異なります。iOS なら戻るボタンは画面上部、Android なら下部のジェスチャーで戻る、というような違いを、最初から指示しておかないと生成されたアプリは『どこかで見たことのない違和感』を生みます。

第一の柱：『仕様』を構造化して伝える

Rork に伝えるプロンプトは、私は常に三層に分けて書きます。第一層が『仕様』、第二層が『制約』、第三層が『期待』です。

仕様は、アプリが何をするかを定義する部分です。ここは曖昧さを完全に排除します。

【仕様】
- 一日の水分摂取を記録するアプリ
- 各記録は『時刻』『量（ml）』『飲料の種類（水・お茶・コーヒー・その他）』を持つ
- 一日の合計摂取量を画面トップに表示
- 目標摂取量（デフォルト2000ml）を設定可能
- 過去30日のグラフを別画面で表示

ここで重要なのが、『データの形』を最初に定義することです。各レコードがどんなフィールドを持つかを明示すると、Rork はデータベース設計から UI 設計まで一貫した実装を返します。逆に「水分を記録するアプリ」とだけ書くと、Rork が独自に解釈したデータモデルが採用され、後から修正が困難になります。

第二の柱：『制約』を明示する

仕様だけ書くと、Rork は最も一般的な実装を選びます。これが期待と合わないことが多々あります。だから『制約』として、具体的な実装方針を明示します。

【制約】
- ナビゲーション: タブバー2つ（記録・分析）
- データ永続化: ローカルストレージのみ（クラウド同期なし）
- ダークモード対応必須
- 記録画面は片手で操作できるレイアウト（重要なボタンは画面下部）
- グラフは折れ線ではなく棒グラフ

この制約のリストが、生成されるアプリの方向性を大きく左右します。特に『片手で操作できるレイアウト』のような UX 上の制約は、明示しないと Rork はバランスの取れた中央配置にしてしまい、実機で使うと使いづらいアプリになります。

私が経験的に学んだ重要な制約の項目は以下の通りです。ナビゲーション構造、データ永続化方式、ダークモード対応、片手操作の優先度、目標プラットフォーム（iOS のみ・Android のみ・両方）、対応する画面サイズ範囲、必要な権限（カメラ・通知など）。これらを最初に明示するだけで、生成品質は劇的に上がります。

第三の柱：『期待』で品質基準を伝える

仕様と制約を伝えた上で、最後に『期待』を書きます。これは『どれだけのクオリティで仕上げてほしいか』を伝える部分です。

【期待】
- 視覚的なデザイン: クリーンでミニマル、鮮やかすぎない配色
- アニメーション: 記録追加時に下から滑り込むスライドイン
- エラーハンドリング: 入力値が範囲外の場合は具体的なメッセージ
- 空の状態: 初回起動時の onboarding メッセージ
- アクセシビリティ: VoiceOver 対応のラベル設定

期待を書くことの最大の効果は、Rork が『手抜き実装』をしなくなることです。「視覚的なデザイン」「アニメーション」「エラーハンドリング」「空の状態」といった細部を明示すると、Rork はそれらを満たすために追加のコードを生成します。書かないと、これらは省略されることが多いです。

繰り返しパターンの効率的な記述

モバイルアプリには、似た構造の画面が複数あることがよくあります。「商品一覧」「カート」「注文履歴」のように、リストとフィルタを持つ画面が3〜4個ある、というケースです。

これらを一つずつ詳しく書くと、プロンプトが膨大になります。私が使っているのは『パターン記述』という手法です。

【共通画面パターン: ListWithFilter】
- 上部: 検索バー + フィルタチップ（複数選択可）
- 中央: スクロール可能なリスト、各項目はカード形式
- リスト下部: ページング（無限スクロール）
- 空の状態: アイコン + メッセージ + CTA

【画面: 商品一覧】
パターン: ListWithFilter
データ: 商品一覧 API
フィルタ項目: カテゴリ、価格帯、評価
カード表示: 画像、商品名、価格、★評価

【画面: カート】
パターン: ListWithFilter
データ: カート内商品（ローカル）
フィルタ: なし（フィルタ部分は非表示）
カード表示: 画像、商品名、数量変更、削除ボタン

このように共通パターンを先に定義し、各画面で『パターン: ...』と参照する形にすると、プロンプト全体の見通しが格段に良くなります。Rork も共通の構造を持つ実装を返してくれるため、コードの一貫性が保たれます。

失敗しがちな指示と修正例

私が最初の頃に何度も失敗した指示パターンと、その修正例をご紹介します。

失敗する指示「使いやすいUIにして」

• なぜ失敗するか: 抽象的すぎて Rork が独自解釈する
• 改善後: 「主要操作（追加・削除）を片手の親指で押せる位置に配置」

失敗する指示「データを保存して」

• なぜ失敗するか: どこに、何を、どう保存するかが不明
• 改善後: 「AsyncStorage に JSON 形式で、起動時に自動読込」

失敗する指示「エラー処理を入れて」

• なぜ失敗するか: どんなエラーを想定しているかが不明
• 改善後: 「ネットワークエラー時は再試行ボタン、入力エラー時は赤枠＋メッセージ」

失敗する指示「アニメーションを付けて」

• なぜ失敗するか: どこに、どんな種類かが不明
• 改善後: 「画面遷移時にフェード（0.3秒）、ボタン押下時にスケール変化」

抽象的な指示を、具体的な状況と挙動に分解することが、品質を上げる近道です。

プロンプト設計の検証フロー

書いたプロンプトをそのまま Rork に投げる前に、以下のチェックリストで自己検証することをお勧めします。

仕様セクションに含まれるべきこと：データの形（フィールドと型）、主要な機能（最低限の動作）、画面の数と役割。制約セクションに含まれるべきこと：ナビゲーション構造、データ永続化、ダークモード、片手操作、対応プラットフォーム。期待セクションに含まれるべきこと：デザインの方向性、アニメーションの有無、エラー時の挙動、空の状態。

このチェックを通過してから Rork に投げると、最初の出力で得られる完成度が大きく違ってきます。

イテレーションの設計

Rork は対話的に修正を加えていけます。最初のプロンプトで完璧を目指す必要はなく、段階的に磨き上げていく前提で設計します。

私が推奨するイテレーション順序は、まずデータと画面構造を確定する、次に主要なフロー（記録追加・編集・削除など）を完成させる、その後でデザインの細部を調整する、最後にアニメーションとマイクロインタラクションを加える、という流れです。

最初からすべてを完璧に指示するよりも、骨格を固めてから肉付けしていく方が、結果的にプロンプトの総量も短くなり、出力品質も高くなります。

次の一歩

このガイドを読み終えた今、まず取り組むべきは、現在進行中のプロジェクト（または次に作りたいアプリ）の『仕様・制約・期待』を実際に書き出してみることです。書き出すと、自分の中で曖昧だった部分が浮き彫りになります。

その曖昧さこそが、これまで Rork から期待外れの結果を受け取っていた原因です。プロンプトを構造化することは、自分の考えを構造化することでもあります。試してみてください。