「Rorkを使ってみたいけど、どのプランを選べばいいんだろう」と迷ったことはありませんか。私も最初、公式ページを見ながら「無料でどこまでできるのか」「Proにしたら何が変わるのか」がよく分からなくて、しばらく無料のまま使い続けていました。そして、最初のアプリを申請しようとした夜中に、ビルドの直前で無料枠の壁にぶつかりました。
結論からお伝えすると、プランの選び方は「何を作るか」と「どこまで本気か」で変わります 。公式の機能比較表を眺めているだけでは見えてこない、実際の使い勝手の差について、個人開発者の視点からまとめます。私自身、2014年からアプリ開発で生計を立ててきた中で「ツール代を出し渋って時間を失う」失敗を何度もしてきたので、その反省も込めた整理です。
3プランの違いを一枚で
まず全体像を、執筆時点の情報で早見表にまとめます。価格や上限は改定されることがあるので、最終判断の前に公式の料金ページで最新の数字を確認してください。
項目 無料 Pro Max
月額(執筆時点) $0 $25前後〜 $200
生成回数 上限あり(すぐ届く) 大幅に緩和 Pro相当+
EAS Build(実機ビルド) 制限あり 利用可 クラウドMacで完結
生成されるアプリ React Native React Native ネイティブSwift
主な対象 お試し・学習 リリースを目指す個人開発 ネイティブ機能が核のアプリ
この表で一番伝えたいのは、MaxはProの上位互換ではなく別系統の製品 だということです。ここを取り違えると「Proで足りるのに$200払う」「Maxが要るのにProで詰まる」という両方向の失敗が起きます。以下で一つずつ掘り下げます。
料金の実体はクレジット — 「月いくら」より「月何回話せるか」
プラン表を眺めていて長く腑に落ちなかったのが、「生成回数の上限」という言い方でした。実際に触ってみて分かったのは、Rork の課金の実体がクレジット制 だということです。ここを理解しないまま月額だけで比較すると、判断を必ず外します。
仕組みは単純です。AI とのやり取り1回につき、1クレジットを消費します。「ログイン画面を作って」も1回、「そのボタンの色を変えて」も1回。指示の重さは関係ありません。
そして重要なのが、クレジットは毎月1日にリセットされ、繰り越されない という点です。使い切らなかった分は消えます。
無料枠は月35クレジット、1日あたりおよそ5回に相当します。有料側は執筆時点で Junior が月$25、Senior が月$100、そして Max が月$200という段階になっています。以前の「Pro」という呼び方から区分が細かくなっているので、公式ページで現在の名称と数字を必ず確認してください。
区分 月額(執筆時点) クレジットの目安 到達できる地点
無料 $0 月35(1日約5回) 触って感触をつかむ・簡単な試作
Junior $25 アイデア検証に足りる水準 アイデアの検証とデモまで
Senior $100 作り込みに耐える水準 MVP を仕上げる現実的な線
Max $200 ネイティブ生成込み Swift 出力・Apple エコシステム全域
この並びで見ると、プラン選びの問いが変わります。「いくら払うか」ではなく、そのプランでシップまで届くか 。届かないプランは、無料であっても時間という高い対価を払っています。
繰り越しなしを前提にした、週割りの使い方
繰り越されない以上、「月初にざっと試して、月末にまとめて仕上げる」進め方は仕組みと噛み合いません。月初の消費が軽ければ、その分は月末に回らずただ消えます。
私が落ち着いたのは、月のクレジットを4週で割り、週ごとに使い切る配分です。無料枠の35クレジットなら、週8〜9回。この単位で区切ると、1週間で何を確かめるかを先に決めるようになります。
第1週:画面の骨格を出させる。遷移と主要画面だけ
第2週:データの流れを通す。保存と読み出しが動く状態まで
第3週:詰まっている1点だけを潰す。欲張らない
第4週:実機で確認し、残りを微修正に充てる
週の途中で足りなくなったら、その週はそこで止めます。翌週に回せば済む話で、慌てて上位プランへ飛ぶ必要はありません。
消化ペースを、月末から逆算する
週の配分を決めても、守れているかどうかは体感では分かりません。私は月の半ばに一度だけ、次のスクリプトに三つの数字を入れて確かめています。残りを残日数で割るだけの計算ですが、目に見える形になると「今週はここで止める」の判断が速くなります。
#!/usr/bin/env node
// credit-pace.mjs — 繰り越しなしのクレジットを、月末までの配分に翻訳する。
// 使い方: node credit-pace.mjs <月間クレジット> <経過日数> <使用済み> [月の日数]
const [ total , elapsed , used , daysInMonth = 30 ] = process.argv. slice ( 2 ). map (Number);
if ([total, elapsed, used]. some (Number.isNaN)) {
console. error ( "使い方: node credit-pace.mjs <月間クレジット> <経過日数> <使用済み> [月の日数]" );
process. exit ( 1 );
}
const remain = total - used;
const daysLeft = Math. max (daysInMonth - elapsed, 1 );
const pace = used / Math. max (elapsed, 1 ); // 現在の1日あたり消費
const landing = Math. round (pace * daysInMonth); // 現ペースでの月末着地
const allowance = remain / daysLeft; // 使い切るための1日あたり許容
console. log ( `残り : ${ remain } クレジット / 残り ${ daysLeft } 日` );
console. log ( `現ペース : ${ pace . toFixed ( 2 ) } / 日 → 月末着地 ${ landing }(上限 ${ total })` );
console. log ( `使い切る配分: ${ allowance . toFixed ( 2 ) } / 日(週あたり ${ ( allowance * 7 ). toFixed ( 1 ) })` );
if (landing > total) {
console. log ( `⚠ ${ Math . floor ( total / pace ) } 日目で枯渇します。1指示あたりの情報量を増やして往復を減らしてください。` );
} else if (landing < total * 0.7 ) {
console. log ( `△ ${ total - landing } クレジットが未消化のまま消える見込みです(繰り越しなし)。` );
} else {
console. log ( `✔ 使い切るペースに乗っています。` );
}
無料枠の35クレジットで、12日が過ぎた時点で20を使ってしまった月に走らせるとこうなります。
$ node credit-pace.mjs 35 12 20
残り : 15 クレジット / 残り 18 日
現ペース : 1.67 / 日 → 月末着地 50(上限 35)
使い切る配分: 0.83 / 日(週あたり 5.8)
⚠ 21 日目で枯渇します。1指示あたりの情報量を増やして往復を減らしてください。
21日目という具体的な日付が出ると、残り10日を無課金で越えるのか、今月だけ上げるのかを落ち着いて選べます。
見落とされがちなのは反対側です。同じ12日目で、まだ6しか使っていない月。
$ node credit-pace.mjs 35 12 6
残り : 29 クレジット / 残り 18 日
現ペース : 0.50 / 日 → 月末着地 15(上限 35)
使い切る配分: 1.61 / 日(週あたり 11.3)
△ 20 クレジットが未消化のまま消える見込みです(繰り越しなし)。
20クレジットが黙って消えます。節約したように見えて、実際には試せたはずの検証を20回分あきらめただけでした。繰り越しがない課金では、余らせることは値引きではありません。私はこの出力を見た日に、後回しにしていた画面を一つ作らせるようにしています。
1クレジットを重くする — まとめて渡す
クレジットが指示の重さと無関係に1ずつ減るなら、1回の指示に情報を詰めるほど単価は下がります 。
❌ 3クレジット消費する渡し方
1. 「設定画面を作って」
2. 「ダークモードの切り替えを追加して」
3. 「切り替えた状態を保存して」
✅ 1クレジットで済む渡し方
「設定画面を作ってください。ダークモードの切り替えトグルを含め、
選択した状態は AsyncStorage に保存し、次回起動時に復元してください。
画面上部にタイトル、その下に設定項目を縦に並べたレイアウトでお願いします。」
同じ結果に3倍の差が出ます。無料枠で試す方ほど、この差は効いてきます。
逆に言えば、指示を出す前に仕様を書き切る時間 が、そのままクレジットの節約になります。手を動かす前に紙に書く、という古い作法が、ここでは費用に直結します。
なお、生成されたコードを自分で直す分にはクレジットを消費しません。細かな文言修正や余白の調整まで AI に頼むのは、単価の面では割に合いません。構造を出させるのは AI、細部を詰めるのは自分。この分担が、限られたクレジットを一番遠くまで運んでくれます。
無料プランでできること・できないこと
Rorkの無料プランは、試しに使ってみる分には十分な内容です。基本的なアプリ生成、プレビュー確認、プロジェクトの保存はできます。
ただし、個人開発で収益を目指すうえで引っかかるのは、生成できる回数に上限がある 点です。複雑なアプリを丁寧に作り込もうとすると、思ったよりも早く上限に達します。「ちょっと修正して」「次はここを変えて」と繰り返すスタイルで開発する場合、無料枠では1〜2日でなくなることもあります。
もう一つ気になるのが、EAS Build(実機ビルド)へのアクセスが制限される ことです。実際にApp StoreやGoogle Playに申請するためにはビルドが必要です。無料プランでは、この工程で詰まる可能性があります。冒頭で触れた「申請直前で止まった」のは、まさにこのビルド制限でした。
試作や学習目的であれば無料で十分ですが、「リリースして収益を上げたい」という目的がある場合は、最初からProを選ぶほうが結局は効率的です。
Proプランが向いている人
有料プランは執筆時点で月$25前後から 用意されています。個人開発のメインツールとしてRorkを使うなら、この価格帯のProが現実的な選択肢です。生成回数の制限が緩和され、EAS Buildも使えるようになります。
私がProに切り替えたのは、最初のアプリをリリースしようとしたときでした。無料プランで作り込んだアプリをビルドしようとして、制限にぶつかったのがきっかけです。月額を払い始めてから、「ちょっと機能を追加して確認する」というサイクルがスムーズになりました。
月$25という金額が高いか安いかは、収益の側から逆算すると判断しやすくなります。私は広告収益型のアプリを長く運用してきたので、ツール代は「月の広告インプレッション何回分か」で考える癖がついています。AdMobのeCPMがおよそ$1〜5のカテゴリなら、$25は月5,000〜25,000インプレッション分 です。デイリーアクティブユーザーが数百人いるアプリが1本あれば、十分回収できる水準と言えます。逆に、まだ収益化の見込みが立っていない段階なら、この計算式自体が「先にProへ投資して開発速度を買うか、無料枠で検証を続けるか」を考える材料になります。
Proが特に向いているのは、以下のような使い方をしている方です。月に数本〜十数本のアプリを作って改善を繰り返している方、複数のプロジェクトを並行して進めている方、App Store / Google Playへのリリースを目標にしている方。
一方で、ペースがゆっくりめで月に1〜2本しかアプリを触らない方は、無料プランでやりくりできる場合もあります。自分の開発ペースを振り返って判断するといいでしょう。
Rork Maxが必要になるのはどんなとき?
ここは正確に書いておきたいのですが、Rork Maxは「Proの上位版」というより、React NativeではなくネイティブSwiftアプリを生成する別製品 です。2026年2月に登場し、料金は執筆時点で月$200と、Proとはひと桁違います。クラウド上のMacでコンパイルするため、手元にMacやXcodeがなくてもビルドからApp Store申請まで完結するのが大きな特徴です。
ネイティブSwiftで生成されるということは、ARKit(LiDAR含む)・Metalベースのグラフィックス・Live Activities・HealthKit・オンデバイスのCore MLといった、Expo経由のReact Nativeでは届きにくいApple側の機能に正面からアクセスできるということです。私も実機でどこまで生成できるかを一通り検証しましたが、その詳細はRork Max の SwiftUI 生成はどこまでできるのか — 実機テストで見えた可能性と限界 にまとめています。
個人開発者がMaxに踏み切るタイミングとしてよく聞くのは、次のようなケースです。「ゲームアプリでMetalベースの描画が必要になった」「カメラ機能を深く使いたいが、Expoのカメラ制限が邪魔になっている」「HealthKitと連携したウェルネスアプリを本気で作りたい」。
注意したいのは、月$200という価格は「アプリ1本の売上で軽く回収」とはいきにくい点です。広告収益で考えると、先ほどの計算でいえば月4万〜20万インプレッション分に相当します。Proの範囲で完結するアプリも多いので、まずProで作り切ってみて、「どうしてもネイティブ機能の壁に当たった」と確認できてから検討するのが自然だと思います。
月額と年額、どちらがお得?
RorkのProおよびMaxプランは、月払いと年払いの両方が選べます。年払いを選ぶと月払いより割安になります。
長期的にRorkをメインツールにするつもりであれば、年払いの方がコストを抑えられます。ただし、「まだ続けるかどうか分からない」という段階であれば、月払いで様子を見るのが無難です。一度年払いにすると途中解約しても返金されない場合が多いため、自分の開発継続意欲を正直に見極めた上で判断してください。
私の経験則では、サブスク型のツールは「3ヶ月続けて使ったら年払いに切り替える」くらいがちょうどよいバランスです。最初の熱量だけで年払いを選んで、結局使わなくなったツールが過去に何本もありました。
他のAIアプリビルダーと料金を並べてみる
「FlutterFlowとRork、どちらにすべきか」という比較検索をよく見かけます。同じ「ノーコード寄りのアプリ作成」でも、料金の考え方が少しずつ違うので、執筆時点の目安を横に並べてみます。数字は各社とも改定が早いので、最終判断の前に必ず公式ページで最新を確認してください。
ツール 無料枠 有料の目安(執筆時点) 生成の仕組み 出力
Rork あり(回数制限) $25前後〜/Max $200 自然言語からAI生成 React Native/Swift(Max)
FlutterFlow あり(書き出し制限) $30前後〜 ビジュアルビルダー+AI補助 Flutter
Adalo あり(公開制限) $36前後〜 ドラッグ&ドロップ中心 独自ランタイム
料金だけを見るとRorkのProは中間くらいですが、比べるべきは金額より**「何を対価に払っているか」**だと思っています。FlutterFlowやAdaloは画面を自分で組み立てるビジュアル編集が中心で、細部を手で詰められる代わりに学習コストがかかります。Rorkは「英語で説明すると動くアプリが返ってくる」対話生成が中心で、代わりに生成回数という別の軸で上限が効きます。
私自身の感覚では、UIの一つひとつを自分でピクセル単位に詰めたい方はビジュアルビルダー系が合い、「まず動くものを早く出して、そこから直したい」方はRorkのような生成系が合います。どちらが安いかではなく、自分の作り方の癖に合うのはどちらか、という順で選ぶと後悔が少ないです。ネイティブSwiftの領域まで一つのツールで踏み込めるのは、この3つの中ではRork Maxだけという点も、比較の際の判断材料になります。
アップグレード・ダウングレード前に知っておきたいこと
プラン変更そのものはRorkの管理画面から簡単に行えます。プロジェクトや既存の作業は引き継がれるので、移行で手間が増えることはありません。ただ、タイミングについては少しだけ気をつけたい点があります。
アップグレードのタイミング :TestFlight申請のためにビルドが要る、といった大事な節目の「直前」ではなく、その1〜2日前に切り替えておくのがおすすめです。請求やアカウント周りで稀に起きる引っかかりを、締め切りに追われずに解消できます。
ダウングレード :上位プランから下位プランへ下げる場合、多くは現在の請求サイクルの終わりに反映されます。それまでは上位機能を使えるので、残りのビルドやエクスポートはサイクル内に済ませておくと無駄がありません。
年額のロックイン :前述のとおり、年払いは途中解約しても返金されないのが一般的です。「このワークフローで行く」と決めているなら妥当な賭けですが、まだ試している段階なら月払いの方が下振れを小さくできます。
選ぶ前に自問したい4つの質問
機能とプランを抽象的に突き合わせるより、次の4つに正直に答えるほうが、判断はずっと早くなります。
App StoreかGoogle Playに申請するアプリを作るのか? ── はい、ならEAS Buildが必要なので、最低でもProです。
継続的に触るのか、たまにしか触らないのか? ── 高頻度ならPro以上。月1〜2回なら無料でも回せることがあります。
React Native+Expoでは届かないネイティブ機能(ARKit・HealthKit・Metal等)を使う予定があるか? ── 最初から「はい」と分かっているなら、行き先はおそらくMaxです。
どのくらいの期間使うつもりか? ── 12ヶ月以上ならば年払いも妥当。まだ見極め中なら月払いで下振れを抑えます。
ここまで答えてもまだ迷うなら、まず無料プランで1週間、実際に何か一つ作ってみてください。つまずきポイントにすぐ当たるので、Proに進むべきかどうかは自然と見えてきます。
チームや複数人での利用はどうなるのか
RorkはもともとソロのPoCや個人開発を念頭に設計されていますが、複数人でプロジェクトを管理したい場合はプランによって扱いが変わります。チームでの利用を想定しているなら、公式のプラン詳細でシート数やコラボレーション機能の有無を事前に確認することをおすすめします。
個人でしか使わない場合は特に気にする必要はありませんが、フリーランスとしてクライアントのプロジェクトを管理したい場合などは、この点が判断材料になることがあります。
Rork Max が月$200 を回収する損益分岐点を試算する
「Maxは高い」と感じるかどうかは、感覚ではなく数字で押さえたほうが判断がぶれません。広告収益型のアプリを長く運用してきた経験から、私はツール代を必ず「損益分岐に必要なユーザー規模」に翻訳して考えます。
試算の前提を置きます。AdMob のバナー+インタースティシャル併用で、1 デイリーアクティブユーザー(DAU)あたり1日およそ3インプレッションが発生する、eCPM は控えめに$2、と仮定します。この前提だと、1 DAU が生む月間収益はおおよそ次のようになります。
3 インプレッション × 30日 × ($2 ÷ 1,000) = 月 $0.18 / DAU
この「1 DAU = 月 $0.18」を物差しにすると、各プランの損益分岐が見えてきます。
プラン 月額 回収に必要な月間インプレッション(eCPM $2) 必要なおおよそのDAU
Pro $25 約12,500 約140人
Max $200 約100,000 約1,100人
Pro の損益分岐はおよそ 140 DAU。1本そこそこ回っているアプリがあれば、十分に届く水準です。一方 Max は 1,100 DAU 相当。ここには「ネイティブ機能があるからこそ実現できる体験」で、より高い eCPM や有料転換を狙えるか、という別の掛け算が乗ってきます。単純な広告単価だけで Max の$200 を回収しようとすると、それなりのユーザー基盤が要る、というのが正直なところです。
自分の eCPM で、この表を引き直す
いま出した数字は eCPM $2 という1本の仮定に乗ったものです。広告単価はジャンルと配信地域で数倍動くので、表そのものより、手元の数字で引き直せる形にしておくほうが役に立ちました。
#!/usr/bin/env node
// breakeven.mjs — プラン月額を「回収に必要な DAU」へ翻訳する。
// eCPM と1 DAU あたりのインプレッション数は、AdMob の実測値に差し替えて使います。
const PLANS = [
{ name: "Junior" , usd: 25 },
{ name: "Senior" , usd: 100 },
{ name: "Max" , usd: 200 },
];
const IMPRESSIONS_PER_DAU = 3 ; // 1 DAU が1日に見る広告の回数
const DAYS = 30 ;
const ECPMS = [ 1 , 2 , 5 ]; // 控えめ / 標準 / 良好
const revenuePerDau = ( ecpm ) => ( IMPRESSIONS_PER_DAU * DAYS * ecpm) / 1000 ;
for ( const ecpm of ECPMS ) {
const perDau = revenuePerDau (ecpm);
console. log ( ` \n eCPM $${ ecpm } → 1 DAU あたり月 $${ perDau . toFixed ( 3 ) }` );
for ( const p of PLANS ) {
const dau = Math. ceil (p.usd / perDau);
const imp = dau * IMPRESSIONS_PER_DAU * DAYS ;
console. log ( ` ${ p . name . padEnd ( 7 ) } $${ String ( p . usd ). padStart ( 3 ) } → ${ String ( dau ). padStart ( 6 ) } DAU / 月間 ${ imp . toLocaleString ( "en-US" ). padStart ( 9 ) } インプレッション` );
}
}
手元で実行した結果を表にすると、こうなります。
eCPM 1 DAU の月間収益 Junior $25 Senior $100 Max $200
$1 $0.090 278 DAU 1,112 DAU 2,223 DAU
$2 $0.180 139 DAU 556 DAU 1,112 DAU
$5 $0.450 56 DAU 223 DAU 445 DAU
同じ Max でも、eCPM $1 のカテゴリでは 2,223 DAU、$5 のカテゴリでは 445 DAU。5倍の開きがあります。「Max は高い」という感想が正しいかどうかは、作っているアプリのジャンルを見ないと決まらない、ということです。
私の壁紙アプリは日本向けのインタースティシャル中心で、$2 と $5 の中間あたりを行き来しています。この範囲だと Junior は 100 DAU 前後で回収でき、Max は四桁の入口が見えてから、という線が引けました。
一点だけ補足すると、IMPRESSIONS_PER_DAU の 3 は控えめな値です。表示頻度を上げれば数字は良くなりますが、離脱も同時に増えます。この定数を大きくして損益分岐を下げるのは、計算上だけの改善になりやすいところでした。
もちろん eCPM や1ユーザーあたりのインプレッションはジャンルで大きく変わります。ここで大事なのは正確な数字そのものより、自分のアプリの eCPM と想定 DAU を、このフォーマットに一度当てはめてみる という習慣です。数字に落とすと、迷いの多くは消えます。
プロファイル別・どのプランで元が取れるのか
同じ$25でも、開発ペースによって「割高」にも「破格」にもなります。三つの典型的なプロファイルで、年間コストと回収の目安を並べてみます。
プロファイル 推奨プラン 年間コスト(月払い換算) 回収の考え方
週末に月1〜2本触る学習者 無料〜Pro $0〜$300 まだ収益前提でなくてよい。詰まったらPro
リリースを回す個人開発者 Pro 約$300 140 DAU級のアプリ1本で回収圏内
ネイティブ機能が核の開発者 Max 約$2,400 広告+有料転換の合わせ技で1,000 DAU超を狙う
この表を作って改めて感じたのは、Pro の$300/年は、アプリを1本きちんとリリースできる人にとっては驚くほど安い ということです。過去、ツール代を惜しんで手作業で消耗し、結果的に何十時間も溶かした失敗を私は何度も繰り返してきました。年$300 で開発のリズムそのものを買えるなら、多くの場合それは投資として妥当です。
無料 → Pro → Max を行き来して固まった段階的投資フロー
最後に、私自身が実際にプランを上げ下げしながら固めた「順番」を共有します。いきなり上位を掴まないことが、結果的に一番コストを抑えます。
第一段階は、無料で1週間、必ず1本を最後まで触ること。ここでの目的は完成ではなく、自分がどこで詰まるかを知ることです。生成回数の壁に当たるのか、ビルドで止まるのか。詰まる場所が、次に払うべきプランを教えてくれます。
第二段階は、リリースを決めた時点で迷わず Pro へ。ビルドの直前ではなく1〜2日前に切り替え、請求周りの引っかかりを締め切りから切り離します。ここで年払いには飛びつかず、まず月払いで3ヶ月走ります。
第三段階は、Pro で作り切ったうえで「ネイティブの壁」に確かに当たったときだけ Max を検討する。ARKit が要る、Metal が要る、HealthKit をフレームワークレベルで叩きたい——この確信が持てて初めて、$200 は「機能への投資」になります。壁に当たる前に Max を掴むと、多くの場合その予算は眠ったままになります。
この三段階を一言でまとめるなら、必要になってから、必要な分だけ払う 。ツールへの投資で後悔するのは払いすぎたときより、払うのをためらって手が止まったときの方が、私の場合はずっと多いのです。
「とりあえずPro」が個人開発者の現実的な出発点
結論をまとめると、個人開発でRorkを本格的に使うなら、Proから始めるのが現実的 です。無料プランは試すためのプランと割り切り、「リリースして収益を上げる」という目標があるなら迷わずProに移行する方が、開発のリズムを維持しやすいと感じています。
Maxは強力ですが、月$200の価値が出るのは「ネイティブ機能が事業の核になる」と確信できたときです。まず作って、リリースして、収益が出てから上位プランを検討するという順番が、長続きする個人開発の姿だと思っています。ツールへの投資で後悔したことより、投資をためらって開発が止まったことへの後悔の方がずっと多い、というのが正直なところです。
プラン選びで迷っている方の、背中を少し押せたなら嬉しいです。