Rorkを使い始めて最初の数本のアプリは、たいてい『なんとなく動くもの』ができて感動するものです。でも、3本目4本目あたりから、こういう感覚に変わってきます——「Rorkに何を頼んでいいのかわからない」「同じ依頼なのに毎回違うアプリができる」「途中から何度も同じ修正を繰り返している」。
私自身、20本以上のアプリをRorkで作ってきて気づいたのは、これらの行き詰まりはRork側の問題ではなく、依頼する側の『要件分解』の問題だということです。そして、要件分解の考え方は、最近読んだ古嶋十潤『独学で鍛える数理思考』にあるような、検索エンジンや分類モデルの数学的構造から学べることが多いのです。
ここではAIコーディングエージェント時代にRorkで失敗しないアプリ開発の思考法を、数理的視点でまとめます。
アプリ開発は『情報空間の絞り込み問題』
「家計簿アプリを作って」とRorkに頼むと、Rorkはとりあえず動くものを返してきます。でも、それがあなたの欲しかった家計簿アプリとは限りません。
これは数学的に言うと、『家計簿アプリ』というラベルが指す可能空間（実装の集合）があまりに広いからです。一口に家計簿アプリといっても、シンプルな金額入力型・レシート読み取り型・銀行口座連携型・グラフ重視型・複数ユーザー対応型——百種類以上のバリエーションが考えられます。
検索エンジンが100億ページから10件を選び出すように、Rorkは『家計簿アプリの可能空間』から1つの実装を選び出します。あなたが追加情報を与えなければ、Rorkはランダムに（厳密には学習データの偏りに従って）選ぶことになります。
良いプロンプトとは、この可能空間を意図的に絞り込んでいく操作です。「家計簿アプリを作って」だけでは絞り込みがほぼゼロですが、「個人用、月単位の集計、カテゴリは食費・交通・娯楽の3つだけ、グラフは円グラフ1個、SQLite ローカル保存」と書けば、可能空間は劇的に小さくなり、Rorkの返してくるアプリも安定します。
要件を5つのレイヤに分解する
私が普段Rorkに依頼するときに使っている要件分解の枠組みを共有します。これは検索エンジンの『ファセット検索』に近い発想で、要件を独立した次元（レイヤ）に分けることで、それぞれを明示的に絞り込めるようにするものです。
レイヤ1: ユーザーと利用シーン 誰が、いつ、どこで、なぜ使うか。「自分が外出先で電車を待っている間に、財布の現金残高を素早く記録する」のような具体的な記述。
レイヤ2: 中核機能（コア体験） アプリの『これがなければアプリが成立しない』機能を1〜3個。家計簿アプリなら『支出を記録する』『月ごとの合計を見る』の2つかもしれません。
レイヤ3: データモデル 扱うデータの構造。「expense（id, amount, category, date, memo）」のような具体的な定義。
レイヤ4: UIの大まかな構成 画面数（最初は3〜5画面が現実的）と、各画面の役割。「タブ1: 支出入力、タブ2: 月次集計グラフ、タブ3: 設定」程度の粒度。
レイヤ5: 技術的制約 Rorkで使える範囲での技術選定。「ローカルストレージのみ、ログイン機能なし、オフライン動作」など。
この5レイヤを依頼前に書き出してから Rork にプロンプトを投げると、最初から欲しいものに近いアプリが返ってきます。逆に言うと、5レイヤのうちどれか1つでも曖昧だと、その曖昧さがそのままアプリの不安定さに反映されます。
『正例』と『負例』を両方書く
機械学習の分類モデルを訓練するとき、正例（こういうものが良い）だけ与えても、モデルは『すべてを良い』と判断する偏った分類器になります。負例（こういうものは違う）も同じくらい重要です。
Rorkへのプロンプトでも全く同じです。「シンプルなデザインで」と書くだけでは、Rorkは『シンプル』の意味する空間が広いため、グラデーションを使ったり影を使ったりするかもしれません。「シンプル＝白背景、影なし、テキストは黒のみ、ボタンは1色のフラットデザイン」のように正例を絞ったうえで、「禁止：グラデーション、影、絵文字、円形以外のアイコン」のように負例を明示すると、Rorkは正確に意図を汲んでくれます。
私が普段使うプロンプトテンプレートには、必ず以下の構造を入れています。
## やりたいこと（正例）
- ...
## やりたくないこと（負例）
- ...
## 任せて良い範囲
- ...
## 任せたくない（必ず確認してほしい）範囲
- ...
特に4つ目の『必ず確認してほしい範囲』は、Rorkが暴走するのを防ぐ最大の安全装置です。「データベース構造の変更は必ず確認してから」のように書くと、Rorkは勝手に既存テーブルを書き換えなくなります。
『確信度を聞く』という習慣
確率モデルでは、点推定（最も確率の高い値1点）だけでなく、分布全体を扱う点が肝心です。Rorkとのやりとりでも、これは効きます。
たとえば「ログイン機能を追加したい」と頼むと、Rorkは1つの実装を返してきますが、その実装にどれだけ自信があるかは見えません。代わりに「3つの実装案を、それぞれのメリット・デメリットと共に提示してください。最後に推奨案と、その確信度（高・中・低）を示してください」と頼むと、Rorkは複数案を出してくれます。
確信度が『低』のときは、Rorkが何かを推測していて間違える可能性が高いタイミングです。そこで質問を返してもらえば、間違った実装に進む前に修正できます。これは確率モデルにおける『不確実性のある領域では追加観測を求める』という考え方を、AIエージェントとのやりとりに持ち込んだものです。
『繰り返しの強調』は逆効果
検索エンジンのTF-IDFという考え方では、文書全体に頻出する単語は重要度が下がります。同じ単語を何度も書くと、結果としてその単語の情報量が薄まるのです。
Rorkへのプロンプトでも同じことが起きます。「絶対に〜してください」「必ず〜してほしいです」「とても重要なのですが〜してください」と何度も繰り返すと、Rorkはその強調を『装飾』として無視するようになります。
代わりに、本当に重要な制約は1〜2回だけ、文の冒頭か末尾に明示します。「【重要】データベース構造は変更しないでください」のように、目立つマーカーで1度だけ伝えるほうが、はるかに効果的です。
失敗しやすい『5つの典型的なミス』
ここまでの考え方を踏まえて、Rorkユーザーがよく陥る失敗パターンを5つ紹介します。
ミス1: 「いい感じに」「うまく」のような汎用語を多用する これらは情報量がほぼゼロです。「カードのコーナーを8px丸めて、影は柔らかく入れる」のように具体的に書きましょう。
ミス2: 一度に大量の機能を依頼する 1回のプロンプトでアプリ全体を依頼すると、各機能の品質が下がります。コア機能から順番に、1機能ずつ依頼するのが最も結果が安定します。
ミス3: データモデルを後回しにする UI設計から始めると、後でデータモデルが画面に合わなくて作り直しになります。データモデル → 画面構成 → UI詳細の順で固めるのが鉄則です。
ミス4: 既存コードを無視した変更依頼 途中から「画面を増やしたい」と頼んでも、既存ファイルとの整合性をRorkが取り切れないことがあります。「既存のNavigationStackに次の画面を追加してください」のように、既存構造への接続点を明示しましょう。
ミス5: テスト方針を伝えない 「テスト書いてください」だけだと、Rorkは表面的なテストを書きがちです。「主要なユーザーフロー3つ（記録→集計→削除）に対して、E2Eテストを書いてください」のように具体化しましょう。
締めくくり：Rorkは『情報量の多い相手』として扱う
Rorkを単なる『コードを書くツール』として扱うと、毎回同じ失敗を繰り返します。代わりに、『情報を絞り込んでいく対話相手』として扱うと、自分の要件理解が深まり、結果としてより良いアプリが作れるようになります。
数理的思考というと身構えがちですが、本質はシンプルで、『これは構造的にどういう問題なのか』と問うことです。Rorkとのやりとりも『情報空間の絞り込み問題』と捉えれば、何を伝えるべきか、何を確認すべきかが明確になります。
次の一歩としておすすめなのは、いま作りたいアプリのアイデアを、上で紹介した『5レイヤの要件分解』に落とし込んでみること。書き出してみると、自分の中でどのレイヤが曖昧か気付くはずです。そこを明確にしてからRorkに投げれば、最初の試作の品質が一段上がります。