新しいツールを触りはじめるとき、私がいちばん先に数えるのは機能の数ではなく、「一日で使い切れてしまうかどうか」です。使い切れる枠なら、その日のうちに向き不向きが分かります。使い切れない枠なら、判断は何日かに分かれます。
先週、Rork の無料枠を数え直していて手が止まりました。月に35クレジット。数字だけ見れば、小さなアプリを一本組むには足りそうに思えます。ところが日次の上限が5と書かれていて、そこで前提がひっくり返りました。
35は「一度に使える量」ではありません。5 × 7日です。無料枠で何かを確かめようとする人にとって、制約は総量ではなく、日をまたぐことのほうにあります。
無料枠と有料枠の数字を、まず並べます
はじめに現時点の数字を置きます。Rork はメッセージ課金型で、AI にコードを書かせたり直させたりするたびにクレジットが減る仕組みです。
| プラン | クレジット | 日次上限 | 目安の用途 |
|---|---|---|---|
| 無料 | 月 35 | 1日 5 | 小さなアプリを組んで手触りを確かめる |
| Pro($25/月〜) | 月 100 | なし | 一気に作り込む日を作れる |
| Max | 月 1,000 から(2,500 / 5,000 / 10,000 へ段階的に) | なし | ネイティブ機能まで踏み込む継続開発 |
数字の出どころを明示しておきます。無料枠の月35・日次5、Pro の $25 で100クレジット、Max のクレジット段階は、いずれも 2026年の第三者レビュー(Rork Pricing 2026(No Code MBA)、Rork Pricing Plans 2026(VP0))で一致して報告されている値です。公式の課金ページは改定が入ることがありますので、支払う前にご自身の画面で確認していただければと思います。
もう一つ、正直に書いておきたい報告があります。新規アカウントに無料クレジットがすぐ付与されないことがある、という声が複数のレビューに出ています。付いていない状態を「自分の操作ミス」と受け取って時間を溶かす必要はありません。私は初日に枠が見えなければ、翌日にもう一度だけ見て、それでも変わらなければ問い合わせに回します。
「1日5」は速さではなく順番を縛ります
私は最初のうち、無料枠を「小さな予算」だと思っていました。少ないけれど、必要なときに必要なだけ使える枠だと考えていたのです。結果は芳しくありませんでした。
実際には、日次の上限は予算というより時間割です。5回投げ終えた時点で、その日にできることは終わります。翌日の自分は、前日の画面を思い出すところから始めることになります。作業そのものより、思い出す時間のほうが長くなる日もありました。
枠が足りないのではなく、日をまたぐ設計になっていなかったのだと気づいたのは、二週目に入ってからでした。
ここから引いた線引きが一つあります。無料枠は、作る枠ではなく決める枠として使います。 一日5回を「今日はこれを決める」という問いに割り当てて、決まったら手を止めるのです。何を決めるかを先に書き出しておくと、5回でも十分に前へ進みます。
具体的には、こんな割り当てにしています。
1日目は骨格です。画面の数と遷移だけを作らせて、要件が伝わる書き方かどうかを見ます。2日目はデータの形です。一覧と詳細に何を並べるかを固めます。3日目は入力と保存、4日目は見た目の調整、5日目は実機で触ってからの手直し——この順番なら、途中で気が変わっても前日の成果が無駄になりません。
一度に投げる仕様を書いてから、はじめて送ります
クレジットが減る原因の大半は、機能の多さではなく往復の多さでした。「作って」「違う」「こうして」を繰り返すと、決めていないことの数だけ回数が増えます。
そこで、送る前にテキストエディタで仕様を書き切るようにしました。次のような骨子で、私は 200 字ほどの下書きを作ってから投げています。
# 目的
(誰が、どんな場面で、何を1回でできるようにするか)
# 画面
1. 一覧: 何を、どの順で並べるか / 空のときに何を出すか
2. 詳細: 表示する項目 / 編集できる項目
3. 設定: 変更できる値だけを列挙
# データ
- 保存する項目名と型(端末内かサーバーか)
- 起動時に読む / 保存するタイミング
# 今回やらないこと
- (通知・課金・共有など、今回は触らせない機能を明記)いちばん効いたのは最後の「今回やらないこと」でした。書いておかないと、頼んでいない機能が付いてきて、それを外すためにもう1回使うことになります。1回の指示で余計な生成を止められるなら、それだけで一日の5分の1が浮きます。
Rork への投げ方をもう少し細かく詰めたい方には、小さく足していくプロンプトの組み立て方が参考になると思います。
確認作業は、クレジットの外へ出します
生成が終わったあとの「合っているかどうか」の確認まで AI に頼むと、確認のたびにクレジットが減ります。ここは手元で済ませられます。
書き出したプロジェクトが手元にあるなら、次の2つは費用がかかりません。
# 依存関係・設定・ネイティブ側の食い違いをまとめて点検します
npx expo-doctor
# SDK のバージョンに合わない依存が混ざっていないかだけを見ます
npx expo install --checkどちらも Expo のコマンドで、Rork のクレジットとは無関係に何度でも走らせられます。私は「生成には クレジットを、確認には 時間を払う」と決めてから、無料枠のもち方がずいぶん変わりました。エラーの原因が依存関係にあるのか、指示の書き方にあるのかを先に分けておくと、次に投げる1回が的確になります。
ビルドが通らないときの切り分けは、ビルドが通らないときに見る順番にまとめてあります。クレジットを使う前に、こちらを一周する価値はあります。
クレジットより先に当たる天井と、無料のまま確かめられること
無料枠の話をしていると見落としがちなのですが、クレジットを使い切る前に、別の壁に当たることがあります。
一つは実機での確認です。ブラウザのプレビューやシミュレータで動いた画面と、自分の端末に入れた状態は同じではありません。私はプレビューで整った画面を、まだ完成とは呼ばないようにしています。ここはプレビューとストア用ビルドの差を埋めるチェック項目で具体的に扱いました。
もう一つは公開です。App Store へ出すには Apple Developer Program の登録が要りますし、Google Play にも初回の登録費用があります。ビルダーの料金とは別の支払いで、しかも人手の作業が挟まります。「無料で作れるか」と「無料で出せるか」は、まったく別の問いなのです。
ここまでを一枚にまとめます。無料枠に入る前に、この表の右側を期待していないかどうかだけ見ていただければと思います。
| 確かめられること(無料枠の範囲) | 確かめられないこと(有料または別費用) |
|---|---|
| 自然言語の指示がどこまで正確に画面になるか | 作り込みを続けたときの手戻りの多さ |
| 生成されたコードの構造が自分に読めるか | 日をまたがずに一気に仕上げる進め方 |
| 画面遷移とデータの持ち方の当たりを付けること | ストアに出したあとの更新の回しやすさ |
| 自分のアイデアが2〜3画面で成立するかどうか | ネイティブ機能まで踏み込んだ実装(上位プラン) |
有料に移るかどうかを決める問いは、私の場合は一つだけです。「無料枠の5日目に、まだ同じアプリを触っていたいと思えたか」。これは金額の妥当性というより、続ける気力の有無を測る問いなのかもしれません。思えたなら $25 は安い買い物ですし、3日目で興味が薄れていたなら、それは題材のほうを変える合図だと受け取っています。
プランごとの向き不向きをもう少し踏み込んで比べたい方は、Rork の料金プランを正直に比べた記事にケース別の判断を書いてあります。
明日の5回を、先に決めておきます
今日できることを一つだけ挙げるなら、明日使う5回分の問いを、いま紙かメモに書き出しておくことです。「一覧の並び順を決める」「保存先を端末内にするか決める」のように、答えが出たら止まれる粒度にしておくと、翌朝の自分が迷いません。
私自身、無料枠を「試用期間」と考えていた頃はうまく使えませんでした。決めるための枠だと思い直してから、ようやく前へ進むようになりました。読んでくださってありがとうございます。皆さまの5回が、少しでも実りあるものになりますように。