ここ最近の Rork のレビューを読んでいると、機能への称賛と並んで「クレジットの消費が思ったより速い」という声を、いくつも見かけるようになりました。実際、ある2026年のレビューでは、生成したアプリの不具合のうち7割ほどは AI が自力で直せたものの、残り3割は書き出したコードを手で修正した、という記録もありました。
この数字を読んだとき、私が考えたのは「だからクレジットが減るのも当然だ」という話ではありません。むしろ、減り方には予測のつくパターンがあって、そこに自分なりの規律を持てば、月々の出費はもっと穏やかになるはずだ、ということでした。個人開発で複数のアプリを細く長く保守してきた経験から言うと、課金の上限に怯えながら使う道具は、結局あまり使わなくなります。怖くないところまで運用を整えることが、ツールを長く使い続ける条件だと感じています。
なぜクレジットは「気づくと溶けている」のか
クレジットが速く減る最大の理由は、生成そのものではなく、生成の「やり直し」にあります。曖昧な指示を出す、出てきたものを見て少し違うと感じる、言い直す、また少し違う——この往復が一度に2回も3回も起きると、一つの画面を完成させるのに、本来の数倍のクレジットを払っていることになります。
私自身、最初の頃は「とりあえず作ってもらって、見てから直せばいい」という気軽さで頼んでいました。けれどこのやり方は、自分の頭の中が整理されていないことを、クレジットで肩代わりさせているだけでした。考えがまとまっていない分を、ツールへの問いかけの回数で埋めていたのです。減りが速いのは道具のせいではなく、私の準備不足のせいでした。
「クレジットを使う仕事」と「手で直す仕事」を分ける
そこで私がまず引いたのは、何を AI に頼み、何を自分の手で直すか、という線でした。判断の軸は単純で、「やり直しが起きやすいか」と「手で直したほうが速いか」の二つです。
| 作業の種類 | 任せ方 | 理由 |
|---|---|---|
| 画面の骨格・最初のたたき台 | クレジットで生成 | ゼロから書くより速く、多少ずれても被害が小さい |
| 文言・色・余白の微調整 | 手で直す | 往復が起きやすく、1行の変更に生成は重い |
| 定数・しきい値の変更 | 手で直す | 場所が分かっていれば数秒で終わる |
| 未知のライブラリの組み込み | クレジットで生成 | 調べる時間をまとめて短縮できる |
| 再現するバグの原因究明 | まず手で確認 | 原因の仮説がないまま頼むと往復が増える |
たとえば、表示する1ページあたりの件数を 20 から 30 に変えたい、というだけの修正を考えてみます。これを言葉で頼み直すと、ツールは該当箇所を探し、周辺を読み、書き換え、確認する——という一連の生成を走らせます。けれど書き出したコードの中で、すでに場所が分かっているなら、手で直すほうが圧倒的に速く、クレジットも使いません。
// 言葉で頼み直すより、書き出し済みコードのこの一行を手で直すほうが速い
const PAGE_SIZE = 30; // was 20こうした「手で直したほうが速い変更」を AI に投げ続けると、塵が積もるようにクレジットが減ります。逆に、未知の領域や、ゼロから組む下地は、迷わずクレジットを使う。線を引いておくと、出費に納得感が生まれます。
一度の指示で遠くまで行く
往復を減らす最も効く方法は、最初の指示を厚くすることでした。頭の中で完成形を先に決めてから頼むと、生成は一度でかなり遠くまで行ってくれます。私はアプリの新しい画面を頼むとき、頼む前に次の四点を自分用のメモとして書き出すようにしています。
- 目的: この画面で利用者は何を達成するか（1文）
- 入力と状態: 受け取るデータ、空のとき・読み込み中・失敗したときの表示
- 操作: タップ・スワイプで何が起きるか、遷移先はどこか
- 制約: 既存の配色・余白・命名規則に合わせる、外部ライブラリは増やさないこのメモは AI のためというより、自分の考えを先に固めるためのものです。空の状態や失敗時の表示を最初に言葉にしておくと、後から「読み込み中はどうなるの」と気づいて頼み直す、という典型的な往復が消えます。私の感覚では、この四点を添えるだけで、一つの画面にかかる往復は半分以下になりました。
厚く書くと指示が長くなって面倒に思えますが、長い指示一回のほうが、短い指示三回より安く、そして速いのです。
失敗は早く捨て、クレジットは滑走路として扱う
それでも、思った方向に進まない生成は必ず起きます。ここで大事だと感じているのは、うまくいかない出力に未練を持たず、早めに捨てる勇気です。半分ずれた結果を少しずつ言い直して直そうとすると、往復が積み重なり、結局ゼロから頼み直すより高くつきます。三回直して近づかなければ、いったん指示そのものを書き直す——これを自分のルールにしています。
そして月の初めには、その月に使えるクレジットを、開発の「滑走路」として見るようにしています。残量を月末に確認するのではなく、週ごとにざっくり眺める。半分を超える勢いで減っていたら、その週は手で直す比率を上げる。クレジットを使い切ってから慌てるのではなく、滑走路の長さを意識しながら離陸する感覚です。
| 週 | 目安の見方 | 速く減っていたときの調整 |
|---|---|---|
| 第1週 | 新しい画面の下地づくりに厚く使ってよい | — |
| 第2週 | 残りが半分を切っていないか確認 | 微調整を手作業へ寄せる |
| 第3週 | 大きな生成は仕様を固めてから | 厚い指示を徹底し往復を断つ |
| 第4週 | 仕上げと手直し中心に | 新規生成は翌月の滑走路へ回す |
この見方に変えてから、月末にクレジットが尽きて手が止まる、という事故がほとんどなくなりました。出費が読めるようになると、不思議とツールへの信頼も増します。怖くない道具は、自然と手に取る回数が増えていくのです。
次の一歩
もし今、クレジットの減りが速いと感じているなら、まずは直近で AI に頼んだ修正を三つ思い出してみてください。そのうち「場所が分かっていて、手で直せたもの」がいくつあったか。おそらく一つや二つは見つかるはずです。その一つを次回から手作業に回すこと——それが、コスト規律のいちばん小さく、いちばん確実な最初の一歩だと思います。
道具の値段ではなく、道具との付き合い方を整える。私はこの数年、個人開発で道具を選び続けてきましたが、長く使い続けられる形にしていくことこそが、私自身のささやかな結論です。最後までお読みいただき、ありがとうございました。