Rorkを使い始めて最初に感動し、次に壁にぶつかるのは決まって同じタイミングです。最初の数時間は「こんなに簡単にアプリが動くのか」という驚きがあります。でも、ちょっと込み入った機能を追加しようとしたり、UIを自分のイメージ通りに仕上げようとすると、修正のたびに別の部分が壊れはじめる。
その壁を乗り越えるのに必要なのは、Rorkの仕様を詳しく覚えることではありません。「Rork に何をどの順序で伝えるか」というプロンプト設計の原則です。
2014年から個人開発でアプリを作ってきましたが、Rorkのようなツールを使うようになって痛感したのは、コードを書く速度よりも「何を、どの順番で作るかを言葉にする速度」がボトルネックになる、ということでした。以下は、その言語化を助けるために私が実際に使っている型です。
なぜ「全部まとめて指示する」と失敗するのか
Rorkに対して「タスク管理アプリを作って。ユーザー認証があって、タスクの追加・編集・削除ができて、カテゴリ分けもできて、期限設定もできて、通知も送れるようにして」と一度に指示すると、アプリは一応動きます。でもそこから先が辛くなります。
一度に多くの要素を生成させると、Rorkは各コンポーネントを「それっぽく」生成しますが、相互の設計が噛み合っていないことが多いです。ユーザー認証のデータ構造とタスクのデータ構造が連動していない、状態管理が各コンポーネントで独立してしまってデータの同期が崩れる、といった問題が後になって噴出します。
修正が修正を呼ぶスパイラルに入ってしまうのは、このタイプの指示の結果です。
設計を先に言語化する
私が実際にRorkで完成度の高いアプリを作るときに最初にやることは、アプリを作らせることではなく、設計を言語化させることです。
このアプリの概要：
- ユーザーが個人のタスクを管理するアプリ
- タスクはプロジェクト（複数）に属する
- ユーザー認証あり（メール+パスワード）
- タスクには期限・優先度・完了フラグを持つ
このアプリに必要な主要なデータモデルを提案してください。
コードは書かずに、エンティティ名・フィールド・関係性だけをテキストで説明してください。
この段階でコードを生成させません。まずRorkに設計を提案させ、それが自分のイメージと合っているか確認します。ここで食い違いがあれば修正します。設計が固まってからコードの生成に進みます。
この一手間で、後から「データ構造を変えたいんだけど」という大規模な修正が発生する確率が大幅に下がります。
状態管理の方針を最初に決めておく
「一度に指示すると失敗する」理由の中核は、状態管理が各コンポーネントでばらばらに実装されてしまうことでした。これは設計フェーズで先に方針を決めておくと、かなり抑えられます。
私は設計を言語化させる段階で、データモデルと一緒に「状態をどこで持つか」も決めるようにしています。
このアプリの状態管理の方針を提案してください。
- サーバー側のデータ（タスク・プロジェクト）は何で同期するか
- 画面間で共有する状態（ログインユーザー等）はどこに置くか
- 一時的なUI状態（モーダルの開閉等）はどう扱うか
コードはまだ書かず、方針だけをテキストで説明してください。
「サーバーデータはこの仕組みで、共有状態はここ、UI状態はローカルで」と一度合意しておくと、各フェーズの実装が同じ土台の上に乗ります。後から噴き出しがちな「画面ごとにデータの持ち方が違う」という最も厄介な不整合を、入口の段階で防げます。
スコープを絞った逐次実装
設計が決まったら、実装は小さな単位で段階的に進めます。私が使っている順序は以下の通りです。
第1フェーズ: データ層のみ
先ほど確認したデータモデルを元に、
Supabaseのテーブル定義（SQL）と
TypeScriptの型定義（interface）のみを生成してください。
UIは作らないでください。
第2フェーズ: 認証のみ
ユーザー認証（サインアップ・ログイン・ログアウト）の
画面と処理のみを実装してください。
タスク機能はまだ作らないでください。
第3フェーズ: コア機能のみ（CRUD）
認証済みユーザーがタスクを追加・表示・編集・削除できる
基本機能のみを実装してください。
カテゴリ・期限・通知は後のフェーズで追加します。
このように「今このフェーズで作るものだけ」を明示し、「〜はまだ作らない」を添えることで、Rorkが余計な機能を先行実装して設計が散らかるのを防げます。
修正指示の出し方
完成度の高いアプリを作る人と、途中で詰まってしまう人の最大の差は、修正指示の具体性だと感じています。
❌ 「なんかボタンの見た目がよくない、修正して」
✅ 「送信ボタンの背景色を #3B82F6 に変更し、ホバー時に 0.9 の不透明度にしてください。角丸は8pxで統一します」
❌ 「エラーハンドリングがなってない」
✅ 「タスク追加の API コール失敗時に、画面上部にエラーメッセージを3秒間表示するトーストUIを追加してください。成功時のトーストはすでにあるので、同じコンポーネントにエラー用のバリアントを追加する形にしてください」
抽象的な指示はRorkの解釈に委ねることになります。それがイメージと合えばラッキーですが、ズレたときの修正コストが高くなります。
動いている部分を「壊さない」と伝える
冒頭で触れた「修正のたびに別の部分が壊れる」現象は、修正指示に"守ってほしい範囲"を書いていないことが原因のほとんどです。Rorkは頼まれた変更を実現しようとするあまり、関係のないコンポーネントまで「ついでに」書き換えてしまうことがあります。
私はこれを防ぐために、修正プロンプトへ必ず「触ってほしくない範囲」を一文添えるようにしています。
タスク一覧のソート機能だけを追加してください。
認証まわり（src/auth/）とデータモデルの型定義は
今は変更しないでください。
最後に、変更したファイルの一覧を示してください。
押さえどころは2つです。ひとつは「変更してほしくないディレクトリ・ファイルを名指しする」こと。もうひとつは「変更したファイルの一覧を最後に出させる」ことです。後者があると、意図しない場所に手が入っていないかをその場で目視できます。
それでも稀に無関係な箇所が書き換わることはあります。そのときは慌てて直さず、いったん前の状態に戻してから、より狭いスコープで指示し直すほうが結局は速いです。動いていたコードを"資産"として守る意識を持ってから、修正スパイラルに入る回数がはっきり減りました。
Rorkに「何が起きているか」を説明させる
複雑な問題が発生したとき、すぐに「直して」と言うよりも、まず現状を説明させることが有効です。
タスク一覧ページでスクロールするとデータが消える問題が発生しています。
コードを修正する前に、この問題の原因として考えられることを
3つ挙げて説明してください。
この質問をすることで2つのメリットがあります。ひとつは、Rorkが診断した原因と自分の予想が一致しているか確認できること。もうひとつは、修正の前に「なぜそう直すのか」の理解が得られるため、同じ問題が別の箇所で起きたときに自分で対処できるようになることです。
「作り直し」か「継続修正」かの判断
長い修正の末に「全部最初から作り直したほうが早い」という状況になることがあります。この判断は難しいですが、私が使っているざっくりした基準があります。
作り直しを選ぶとき
- 3回以上の修正で同じ問題が再発している
- 修正によって別の機能が壊れるサイクルが止まらない
- データモデルの根本的な見直しが必要になった
継続修正でいくとき
- 問題の原因が明確で、影響範囲が限定されている
- UIの見た目の調整が中心
- 機能追加（既存コードへの破壊的変更なし）
作り直す場合は、今回の経験を活かして設計フェーズをより丁寧に行えば、2回目は必ず速くなります。最初の失敗は設計の学習コストだと捉えると、気持ちが楽になります。
完成させるための心構え
Rorkは「動くプロトタイプをすぐ作る」には明確に速いツールです。でも「磨き込まれたアプリを完成させる」には、人間側のディレクション能力が問われます。
自分がどんなアプリを作りたいのか、各機能がどう連携すべきなのかを言語化できていれば、Rorkはその設計を実装に変換する強力なパートナーになります。逆に「なんとなくこんな感じ」のまま進めると、Rorkも「なんとなくこんな感じ」のコードを積み上げていきます。
次に作るアプリでは、最初の指示を出す前に5分間、「このアプリで絶対に必要なデータは何か」を紙に書いてみてください。その5分が、後の数時間を救うことになると思います。