Rork Max で最初のアプリを組んだとき、私がいちばん面食らったのはクレジットの減り方でした。プレーンな英語で画面を頼むと数十秒で動く Swift が返ってくる手軽さに任せて、「もう少し余白を」「色を落ち着かせて」と思いつくまま投げ続けたところ、半日で一週間分のつもりだったクレジットが尽きていました。
生成そのものは速い。けれど速いからこそ、何を頼むかを設計しないまま回すと、同じ画面を作り直すだけでクレジットが流れていきます。2026年の利用者レビューでも Rork Max は「クレジットを多く消費するノーコードビルダー」と評されることがあり、月 $200 のプランを払う以上、このクレジットを時間や広告費と同じ「予算」として扱う発想が要ります。
ここからは、クレジットを使い切らないための反復設計を、見積もり・順序・手作業との境界という三つの観点で整理していきます。個人開発で長くアプリを配布してきた中で、生成を「やり直しの少ない形」に寄せるために身につけた考え方です。
再生成は「ガチャ」ではなく在庫の引き落とし
最初に意識を変えたいのは、再生成のとらえ方です。AI に頼むと毎回少しずつ違う結果が返るので、つい「いい当たりが出るまで引く」ガチャのように扱いがちです。けれどクレジットは在庫で、1回頼むたびに棚から引き落とされます。当たりを待つ姿勢は、在庫を運任せで減らしているのと同じです。
ここを切り替えると、行動が変わります。「とりあえず生成して気に入らなければまた頼む」ではなく、「1回の生成で何を確定させるか」を頼む前に決める。1回の生成に乗せる情報量を増やし、往復の回数そのものを減らすのが、クレジットを守る一番の近道です。
私はこの引き落としを可視化するために、画面ごとに簡単な台帳をつけています。どのプロンプトで何を確定させたか、再生成を何回したかを記録するだけのものです。
{ "screen" : "OnboardingPager" , "intent_locked" : true , "generations" : [ { "round" : 1 , "purpose" : "構造の確定（3ページ・ページインジケータ）" , "kept" : true }, { "round" : 2 , "purpose" : "余白とタイポグラフィの仕上げ" , "kept" : true } ], "manual_edits" : [ "アクセントカラーの定数を手で変更" , "ボタンの角丸を 12 に調整" ], "total_rounds" : 2 } 台帳をつけると、「この画面はもう2回直している」という事実が目に見えます。3回目を頼む前に一拍置けるようになり、惰性の再生成が自然と減ります。
プロジェクト全体のクレジットを先に見積もる
感覚で回すのをやめるには、着手前にざっくりとした総量を出しておきます。私は次の素朴な式を使っています。
総クレジット ≒ 画面数 × （初回生成 + 平均再生成回数 × 1回あたりの消費）
数字はプランやアプリの複雑さで変わるので、ここでは考え方を示すための例として置きます。仮に1画面の初回生成を 10、修正の再生成を 1回あたり 4 と見立て、平均で 2回作り直すとすると、1画面あたりは 10 + 4 × 2 = 18。15画面のアプリなら 18 × 15 = 270 が目安になります。
この見積もりが効いてくるのは、途中で「予算の何割を使ったか」を言えるようになる点です。270 の見立てに対して半分を超えたのにまだ画面が3割しか固まっていないなら、回し方が荒すぎるという早期の警告になります。下の表は、同じ15画面でも反復の設計しだいで総量がどれだけ変わるかを並べたものです。
回数を 5 から 2 に落とすだけで、総量は 4 割ほど縮みます。月 $200 のプランで足りるかどうかは、結局この「平均再生成回数」をどこまで下げられるかにかかっています。
構造を決めるプロンプトと仕上げのプロンプトを分ける
再生成回数を下げる具体策の中核が、プロンプトの役割を分けることです。私は生成の頼みごとを大きく二層に分けています。
構造を決める層 : 画面に何があるか、どう並ぶか、どの画面へ遷移するか。レイアウトの骨格とナビゲーションの形。仕上げの層 : 余白、配色、フォントの階層、アニメーションの当たり。見た目の手触り。
この順序が大事な理由は単純です。構造を作り直すと、その上に積んだ仕上げは一緒に流れてしまうからです。配色を整えたあとで「やっぱり画面を2つに分けたい」と構造へ戻ると、せっかく整えた余白や色はリセットされ、もう一度仕上げをやり直すことになります。クレジットを二重に払う格好です。
ですから、構造の層が固まるまで仕上げには踏み込まない。「この画面構成で確定」と自分で言えてから、はじめて余白や色を頼みます。頼むときも一つずつではなく、気になった点をまとめて一度に渡します。
# 悪い例（往復が多い）
1回目: 「余白を広げて」
2回目: 「見出しをもう少し大きく」
3回目: 「ボタンの色を落ち着かせて」
# 良い例（1回にまとめる）
「余白を全体に 1.5 倍ほど広げ、画面見出しを 1段階大きく、
主要ボタンの色をブランドの紺に。トーンは静かで上品に。」
仕上げの指示は言葉でまとめて渡せるものが多く、3往復を1往復にできます。これだけで仕上げ段階のクレジットは目に見えて減ります。
再生成すべきか、手で直すべきか
もう一つの分かれ道が、生成後の Swift を手で直す選択肢です。Rork Max は Xcode を介さずに公開まで進められますが、生成されたコードを読んで小さく直すこと自体は妨げられません。そして、ある種の変更は再生成よりも手作業のほうが圧倒的に安く済みます。
線引きの目安はこうです。見た目の定数まわりは手で、構造とロジックは生成で。 色・余白・角丸・フォントサイズといった値は、生成された Swift の該当箇所を書き換えるほうが、プロンプトで往復するより速くて確実です。
// 生成された View の一部。色や余白は手で直すほうが安い struct PrimaryButton : View { var title: String var action: () -> Void
var body: some View { Button ( action : action) { Text (title) . font (.headline) . frame ( maxWidth : . infinity ) . padding (.vertical, 14 ) // ← 余白はここを直接調整 } . background ( Color ( red : 0.12 , green : 0.16 , blue : 0.36 )) // ← 色も直接 . foregroundStyle (.white) . clipShape ( RoundedRectangle ( cornerRadius : 12 )) // ← 角丸も直接 } } 一方で、画面の追加、遷移の組み替え、データの流れの変更といった構造的な修正は、手で書くとかえって時間を食い、生成の整合性も崩します。こうした変更は素直に再生成へ回します。
私が個人開発で守っている運用上の判断は「3行で直せるなら手で、設計が動くなら生成」というものです。AdMob のバナーを1つ足す程度なら手で挿入したほうが速く、画面間のフローを作り替えるなら生成に任せる。この一線を決めておくと、迷っている時間も再生成の無駄打ちも減ります。
私が線引きの基準にしている三つの問い
迷ったときに立ち返れるよう、私は再生成へ進む前に三つの問いを自分に投げます。これは個人開発の現場で、無駄打ちを減らすために繰り返し使ってきた判断の物差しです。
一つ目は「いま直したいのは見た目か、構造か」。見た目なら、まず手で直せないかを考えます。二つ目は「この変更は、ほかの気になる点とまとめて頼めないか」。まとめられるなら、一拍置いて束ねます。三つ目は「これは3回目以降の再生成ではないか」。台帳を見て3回目だと分かったら、いったん止めて手作業へ寄せると決めています。
この三つを通すだけで、惰性の再生成はかなり防げます。とくに本番直前の追い込みでは、焦りからエラーまがいの雑な指示を投げがちなので、この物差しが効きます。完璧な一発を狙うより、無駄な往復を一つ減らすほうを私はいつも優先します。
失敗を予算に織り込んでおく
最後に、現実的な話をひとつ。どれだけ設計しても、思った通りに生成されないことはあります。生成が的を外し、作り直しが必要になる回数をゼロにはできません。だからこそ、見積もりには最初から「外れ分」を乗せておきます。
私は総クレジットの見積もりに 2 割ほどの余白を足しています。270 の見立てなら 320 ほどを上限として確保しておく。こうしておくと、外れたときに慌てて雑な再生成へ走らずに済みますし、上限に近づいたら「ここから先は手作業へ寄せる」と冷静に切り替えられます。
クレジットは時間と同じで、使い方を設計した人のところに残ります。速さに任せて回すのではなく、1回の生成で何を確定させるかを決め、構造と仕上げを分け、手で直すべきものは手で直す。この三つを習慣にすると、月 $200 の枠は驚くほど長く保ちます。同じようにクレジットの減りに悩んでいる方の、見積もりの足場になれば幸いです。