Rork に「ToDoアプリを作って」と入力してみたら、想像と違うものが出てきた——そういう経験がある方も多いのではないでしょうか。私自身、最初の1週間はこの「期待とのずれ」を修正指示で埋め続けて、1画面に10回近い往復をしていました。
いま振り返ると、ずれの原因は Rork の能力ではなく、私の渡す情報の順番にありました。Rork は自然言語でアプリを作れるツールですが、同じ内容でも書き方の違いで出来上がりが大きく変わります。この往復を減らす鍵が「構造から渡す」という一点です。
Rork は「データと画面遷移」から組み立てる
何十回もアプリ生成を試して気づいたのは、Rork は曖昧な指示を受け取ると、まず無難な CRUD（一覧・追加・編集・削除）の骨組みを置こうとする、ということです。データの形を書かずに頼むと、縦に並ぶ単純なリストが返ってきがちでした。
2014年から個人開発で壁紙アプリを運用してきた経験から、画像中心のアプリでは「2列のカードグリッド」「カテゴリでの絞り込み」「お気に入り」が要だと身体で分かっています。そこで同じ依頼を、構造を先に置く形に書き換えました。
❌ 最初に投げたプロンプト:
「壁紙ギャラリーアプリを作って」
→ 縦一列の素朴な画像リストが返ってきました。
グリッドへの変更・絞り込み追加・詳細画面の作り直しで
修正指示が5往復。
✅ 構造を先に渡したプロンプト:
「壁紙ギャラリーアプリを作ってください。
データ: 画像URL・カテゴリ・解像度・お気に入りフラグ
一覧: 2列のカードグリッド。上部のチップでカテゴリ絞り込み
詳細: 全画面プレビューとお気に入りボタン」
→ ほぼ意図通りの画面が一度目から出てきました。
修正は配色の微調整1回だけ。
Rork はデータモデルと画面遷移を先に固めるので、そこを先回りして渡すと手戻りが目に見えて減ります。以降の書き方は、すべてこの原則の応用です。
「誰が使うか」と画面の一覧を最初に書く
目的と対象ユーザーが入ると、UI のデザイントーンや操作フローが変わります。
❌ 曖昧な例:
「家計管理アプリを作って」
✅ 改善例:
「30代の共働き夫婦が毎日のレシートを撮影して出費を記録できる
家計管理アプリを作って。シンプルで直感的に使えることを重視してください」
そのうえで「どんな画面があるか」を列挙すると、構成の意図まで伝わります。
「以下の画面を含むタスク管理アプリを作ってください:
1. タスク一覧（完了・未完了でフィルター可能）
2. タスク追加画面（タイトル・期限・優先度を入力）
3. タスク詳細画面（編集・削除・完了マークが可能）
4. 設定画面（通知のオン・オフ）」
画面の数が多い場合は「最小構成でいいので動くものを先に作って」と添えると、シンプルなベースから始められます。
デザインの方向性とデータ構造で「見た目と中身」を固定する
見た目の好みは、形容詞を並べるより名詞のキーワードで伝えるほうが効きます。
デザインキーワードの例:
- 「ミニマルでモノトーン」
- 「明るく親しみやすい。アクセントカラーは緑」
- 「ビジネス向けの落ち着いた印象。ダークモード対応」
- 「子ども向けのカラフルで大きな文字」
参考にしたいアプリの名前を挙げるのも有効です。「〇〇（アプリ名）のような雰囲気で」という指定は、Rork が知っているアプリであればイメージの共有が一気に進みます。
中身のほうは、扱うデータをそのまま書きます。
「ユーザーが記録できる内容:
- 食事名（テキスト）
- カロリー（数値）
- 食事の時間（日時）
- 写真（任意）
- メモ（任意、テキスト）
一覧表示: 日付別にグループ化して表示する
集計: 1日の合計カロリーを表示する」
この程度の詳細を最初から書いておくと、後から「カロリーも記録できるようにして」「日付でまとめて」という追い指示をしなくて済みます。データ構造は UI の形をほぼ決めてしまうので、ここを渡すことが冒頭の原則の実践そのものです。
「入れないもの」と修正範囲の指定で暴走を防ぐ
入れてほしくない機能も書いておくと、意図しない方向への展開を防げます。
「注意してほしいこと:
- ソーシャル機能（シェア・フォロー等）は不要
- ログイン・会員登録機能は最初は不要
- 広告表示エリアは含めない
- 画面遷移は最小限にしてください」
修正の段階では、範囲の指定がさらに重要になります。「もっとおしゃれに」と一言投げたら、前のターンで微調整したカードの余白まで元に戻ってしまった——そんな小さな後退を私は何度か経験しました。
❌ 曖昧な修正指示:
「デザインをよくして」
✅ 具体的な修正指示:
「タスク一覧画面のタスクカードの高さを少し大きくして、
タスク名のフォントサイズを16pxに、テキストカラーを #333333 にしてください」
「この画面の、この部分だけ」という範囲指定は、修正の精度を上げるだけでなく、整っていた箇所を守る保険にもなります。私は1ターンにつき変更は1か所に絞ると決めてから、巻き戻りにほぼ遭わなくなりました。
段階的に積み上げ、効いたプロンプトを資産として残す
最初から完全なアプリを一度に頼むと、複雑すぎて意図から外れやすくなります。フェーズを刻むほうが確実です。
第1フェーズ:
「シンプルなメモアプリを作って。
メモの追加・削除・一覧表示だけで OK」
動作確認後→
第2フェーズ:
「今のメモアプリに、メモに色をつけるラベル機能を追加して。
ラベルの色は赤・黄・青・緑の4色から選べるようにして」
確認後→
第3フェーズ:
「ラベルでフィルタリングできる検索機能を追加して」
機能を少しずつ積み上げると、それぞれの変更を確認しやすくなり、全体として意図通りに近づきます。
もう一つ習慣にしているのが、意図通りになった指示文を手元のメモに残すことです。効いたプロンプトの蓄積は、次のアプリでもほぼそのまま使い回せます。プロンプトは使い捨ての呪文ではなく、育てていく自分の資産だと考えています。UI を狙い通りに出すための言い回しは狙った UI を正確に生成するテクニックで、試作止まりにせず完成まで運ぶ設計はアプリを「作り切る」ためのプロンプト設計の原則で、それぞれ掘り下げています。
試行回数の節約 — 無料枠を溶かさないために
構造から書くことには、品質以外にもう一つ実利があります。生成リクエストの節約です。
Rork の無料プランには月ごとのリクエスト制限があり、曖昧なプロンプトで始めると「生成→違う→修正指示→また違う」の往復だけで枠が減っていきます。私が最初の週にやっていた1画面10往復のペースでは、評価が終わる前に枠が尽きてもおかしくありませんでした。構造を先に渡して往復を1〜2回に抑えられれば、同じ無料枠で試せるアイデアの数が単純に数倍になります。
これは有料プランに上がってからも効いてきます。プランの選び方は結局「月に何回生成を回すか」で決まるので、プロンプトの精度はそのままランニングコストに跳ね返ります。プランごとの違いはRork の料金プランを正直に比較した記事に書きましたが、どのプランを選ぶにしても、1回の生成で近いところまで持っていく書き方が最も確実な節約になります。
ひとまとめの例と、語彙の選び方
ここまでの要素を組み合わせた実例です。
【アプリの目的】
毎日の睡眠時間を記録して可視化するアプリ。
ユーザー像: 睡眠の質を改善したいと思っている20〜40代の社会人。
【主要な画面】
1. ホーム（今日の睡眠記録 + 直近7日間のグラフ）
2. 記録追加（就寝時刻・起床時刻・睡眠の質評価・メモ）
3. 履歴（月別に過去の記録を確認できる）
【デザイン方向性】
落ち着いた夜のイメージ。ダークブルー〜ネイビーをベースにした
ダークテーマで。文字は白・薄いグレーを使用。
【データ構造】
各記録: 就寝時刻・起床時刻・睡眠時間（自動計算）・
睡眠の質（1〜5のスコア）・メモ（テキスト）
【入れないもの】
ソーシャル機能・ログイン機能・広告枠
最初から全部書く必要はありません。「まず動くものを見てから詳細を決めたい」場合は、短く書いて出力を確認してから修正指示を出すほうが効率的なこともあります。
言語について補足しますと、私は普段の指示は日本語で書いています。日本語のままで生成は問題なく通りますが、技術的な固有名詞だけは英語表記のほうが確実だと感じています。とくにネイティブ Swift を生成する Rork Max では、Apple ネイティブの機能名をそのまま書くと精度が上がりました。「ロック画面に残り時間を出したい」より「Live Activities で残り時間を表示」、「健康データと連携」より「HealthKit から睡眠データを読み取る」のほうが、狙った実装に近づきます。逆に通常の Rork（React Native）へ同じ固有名を投げても空振りすることがあるので、どちらのエンジンで作っているかを意識して語彙を選ぶと、無駄なやり取りが減ります。
次に試すときは、いまあるアイデアを「目的・画面・データ構造・入れないもの」の4行だけ先に書き出してから Rork に渡してみてください。最初の一枚の精度が変わるはずです。私もこの4行のテンポに落ち着くまで遠回りをしましたが、その分だけ手戻りの少なさを実感しています。