Rorkで一度動くアプリを作ったあと、「ここにもうひとつだけ機能を足したい」と思ったことはありませんか。私は家計簿アプリに「月ごとのグラフ集計」を後から追加しようとして、既存のコードが大きく書き換わってしまい、結局前日の状態に戻した経験があります。追加の指示をしただけなのに、なぜ動いていた画面まで壊れてしまうのか——この戸惑いは、Rorkを使い込んでいる方ほど一度は味わっているのではないでしょうか。
実はこれ、Rorkの性能の問題ではなく、「既存のコードに対してAIにどう振る舞ってほしいか」を言語化できていないことがほとんどの原因です。ここでは私が何度も失敗しながら身につけた、機能追加時の指示の組み立て方を5つの観点でお伝えします。プロンプトを少し工夫するだけで、追加作業の成功率は体感で大きく変わります。
まず押さえたい：機能追加でAIが暴走する3つの典型パターン
対策を考える前に、どこでつまずいているのかを整理しておきます。私がこれまで経験した失敗は、次の3パターンに集約されました。
1 つ目は 「既存コードが勝手にリライトされる」 パターンです。新しいグラフ機能を足してほしいだけなのに、既存の入力フォームまで別のライブラリに差し替えられてしまう。
2 つ目は 「ファイル構造が変わる」 パターンです。screens/HomeScreen.tsx にあったロジックが、気づくと components/Dashboard/ 配下に移動しています。動作は変わらなくても、次回の指示でAIが迷子になります。
3 つ目は 「関係ない画面まで触られる」 パターンです。設定画面の色を少し変えてほしいと頼んだら、ホーム画面のヘッダーまで変わっています。これが一番再現性が低く、厄介な症状でした。
これら3つに共通しているのは、AIが「今ある状態」を正確に把握できていないことです。人間同士のやり取りでも、前提の共有が曖昧だと話がずれていきます。AIに対しても同じで、前提をはっきりさせる指示ほど結果が安定します。
追加したい機能を「正確な住所」で指定する
機能追加で最も効くのが、修正の対象を ファイルパスと関数名で明示する ことです。「ホーム画面にグラフを追加して」ではなく、「screens/HomeScreen.tsx の renderSummary 関数のすぐ下に、月別集計グラフを追加して」と書きます。
ファイル名を書くだけでも精度は上がりますが、関数名・コンポーネント名・既存の変数名まで引用すると、AIは既存コードを参照しにいく動きをしやすくなります。
✅ うまくいく指示の例
「screens/HomeScreen.tsx の `renderTransactionList` コンポーネントの下に、
`MonthlyChart` という名前で新しいコンポーネントを追加してください。
データは既存の `transactions` state（App.tsx で管理）を props で受け取り、
月ごとに集計して表示します。既存の `renderTransactionList` や
`transactions` state のロジックは一切変更しないでください。」この指示には、「どこに（ファイルパス）」「何を（新コンポーネント名）」「どうやって（既存stateから）」「何をしないか（既存ロジックを変えない）」が全て含まれています。Rorkが前提とする情報が揃っている状態なので、意図とズレた実装になりにくくなります。
内部挙動の話を少しすると、AIは長いコンテキストの中から必要な情報を探すのが得意ですが、あいまいな代名詞（「あれ」「これ」「そこ」）には弱い傾向があります。具体的な名前を書くだけで探索の精度が上がるわけです。
「既存コードに触れないで」を制約として明示する
前の節の例にもさりげなく入れましたが、「既存コードは変更しない」は制約として独立して書く ほうが効きます。私は今では、機能追加プロンプトの末尾に必ず制約ブロックを付けるようにしています。
【厳守してほしい制約】
- 既存の画面・コンポーネント・関数・状態管理ロジックは変更しないでください
- 新機能に必要なファイル・関数・state は、すべて新規に追加する形にしてください
- 既存のインポート文は変更せず、必要な import は新規ファイルの冒頭に書いてください
- 既存のルーティング（App.tsx の Stack.Screen）は追加のみで、削除・改名はしないでくださいこのブロックを添えるだけで、AIは「既存の何かを消したり書き換えたりするのは望まれていない」と強く認識します。禁止事項を明示する効果は、プロンプトエンジニアリングの世界でも広く知られていますが、Rorkのようにファイルを直接操作するツールでは特に有効です。
この考え方について、もう少し深く理解したい方には、以前書いたRorkでAIが既存コードを勝手に書き換える時の対処法もあわせて参考になるかと思います。
1 回の指示で 1 機能だけ — スプリント単位で分割する
これは運用の話ですが、とても大切です。「グラフ追加＋エクスポート＋通知の3つお願い」のような複合指示は、基本的にうまくいきません。
私の失敗談をひとつ共有します。以前、お小遣いアプリに「カテゴリ集計グラフ」「CSVエクスポート」「月末リマインダー通知」を一度に頼んだところ、グラフは動くけれど通知が鳴らず、CSVエクスポートは壊れたコードが生成されて、結局その日は全部ロールバックすることになりました。
今はこうしています。
- まず「カテゴリ集計グラフ」だけを指示する
- プレビューで動作確認する（これが大事）
- 問題なければ次のスプリントで「CSVエクスポート」を指示する
- また確認してから「月末リマインダー通知」へ進む
1日で3機能は足せませんが、結果的に作業時間は短くなりました。複合指示が失敗して全部ロールバックすることがなくなったからです。個人開発では、このペースが一番心が折れにくいとも感じています。
追加した機能が意図せず壊した箇所を確認するチェック手順
機能追加のあとは、AIから「完了しました」と言われても、自分の目で3つの観点を確認する習慣をつけると安全です。
画面遷移を一通りたどる: 新機能と無関係な画面も含めて、タブの切り替え・ボタン・戻るジェスチャーが元通り動くかを手で確認します。AIがナビゲーションの設定を触ってしまっているときは、ここで気づきます。
state の流れを確認する: 既存のstate（例えば transactions や userSettings など）が、新機能から正しく読み書きできているかを確認します。読み取りは動いていても書き込みが壊れていた、というパターンは意外と多いです。
コンソールの警告・エラーを見る: プレビューのデベロッパーコンソール（Rork内で開けます）に赤や黄のメッセージが増えていないかを確認します。警告だけでも、将来のクラッシュ原因になり得ます。
この3つを習慣化するだけで、「翌日起動したら壊れていた」という事故をほぼ防げます。動作確認は時間を食う作業に感じるかもしれませんが、結局ここをサボると、何日も巻き戻って修復することになりがちです。
次の一歩：「追加する前に、今あるものを言語化する」
機能追加で一番効くのは、実は「追加する前に、今あるものを言語化しておく」習慣です。「この画面にはこのファイルがあって、このstateを使っている」と自分で書き出してからAIに指示します。たったそれだけで、AIに共有できる前提が格段に増えて、ズレが起きにくくなります。
Rorkが書いたコードを読めるようになると、この言語化がさらに速くなっていきます。React Nativeの基本に軽く目を通したい方は、AIが生成したRorkのコードを読むためのReact Native基礎やRorkでイメージ通りのアプリが出てこないとき：プロンプトの書き方で解決する3パターンもあわせて読んでみてください。
今日あなたのRorkプロジェクトで、次に足したい機能が1つあるなら、まずはその機能を「どのファイルの、どの関数の、どの行の近く」に置きたいかを1行でメモしてみてください。その1行があるだけで、今日の作業時間はきっと短くなります。