残高を確かめようとアカウントメニューを開いたとき、数字が二つ並んでおりました。Credits と、Cloud Credits です。
片方は回数で、もう片方はドル建てでした。同じ「クレジット」という言葉が、違う意味で二度使われていたのです。
最初のうち、私はこの二つをひとつの財布のように眺めておりました。結果は芳しくありませんでした——減っていることは分かるのに、どちらの操作が減らしたのかが最後まで掴めなかったのです。
Build は私が押した分、Cloud は利用者が動かした分。 この一行を手元に置いてから、請求の読み方が変わりました。ここでは、その切り分けの手順と、途中でつまずきやすい三つの場所をお伝えします。
払う相手も、減る瞬間も違います
公式ドキュメントのBuild credits vs Cloud creditsは、二つの残高を「別々に請求され、別々に補充されるもの」として説明しております。まずここが出発点になります。
| 見るところ | Build クレジット | Cloud クレジット |
|---|---|---|
| 払う対象 | Rork の中でアプリを作る作業 | 完成したアプリが実行時に使う AI・クラウド機能 |
| 単位 | クレジット（回数） | USD（ドル建ての残高） |
| プランとの関係 | プランに含まれ、毎月リセット | プランの外。自分で入金する前払い残高 |
| 減らす人 | 作っている自分 | 公開後は、アプリを使う利用者 |
| 主な内訳 | AI チャット、ビルドとプレビュー、素材生成、公開まわりの作業 | バックエンド関数、AI のチャット・画像・音声、Web 検索、メディアや 3D の生成 |
Cloud のほうは、プロジェクトで Rork AI Cloud を有効にすると一度だけ 1 ドル分が付与され、そこから試せる形になっております。アプリが実際にクラウド機能を使ったときにだけ目減りする、という点も明記されております。
つまり Cloud 残高は、作業量ではなく稼働量に連動します。ここが Build といちばん違うところです。
二つの画面を開けば、どちらが減ったかは分かります
切り分け自体は難しくありません。順番だけ決めておけば、毎回同じ手つきで確かめられます。
- 右上のアバターからアカウントメニューを開きます。Credits（Build クレジット）と Cloud Credits（ドル残高）が並んで表示されます。
- Billing の Build Credits タブを開きます。残りのクレジット、サブスクリプション由来の分と使用分、現在のプランが確認できます。足りなければその場で買い足す導線もあります。
- Cloud Credits タブを開きます。ドル残高と、5 ドルから 200 ドルまでの範囲で入金する Add funds、そして Use Cloud Credits のトグルが置かれております。
- 同じタブの Cloud Usage を開きます。直近 30 日の消費が、AI モデル別とプロジェクト別に分解されて出てきます。
切り分けの本体は、4 番目の Cloud Usage です。ここにその期間の行が立っていなければ、減ったのは Build 側だったことになります。逆に特定のモデル名が突出していれば、アプリのどの機能が呼んでいるかまで絞り込めます。
身に覚えのない請求が残った場合、公式はプロジェクトのリンク・おおよその時刻・行った操作を添えてサポートへ連絡するよう案内しております。この三点を先に控えておくと、問い合わせが一往復で済みます。
1回の指示が1クレジットで終わらない場面があります
Plans & Subscriptions では、クレジットを「AI コンピュートの単位で、おおよそ 1 リクエスト分」と説明しております。ただし同じページに、見落とすと見積もりが合わなくなる但し書きが添えられております。
iOS のビルドと、クラウドのシミュレータのセッションは、実機を借りて動くため、それを開始したメッセージとは別に上乗せで課金されます。
ですので「今日は何回話しかけたか」でクレジットを数えると、プレビューを繰り返した日ほどずれていきます。私も最初は会話の数だけを目で追っておりまして、実際の減り方との差を、月の終わりになってから知ることになりました。
プランごとの枠も押さえておきます。
| プラン | 月あたりのクレジット | 日次上限 |
|---|---|---|
| Free | 主要市場で 35、それ以外の地域で 5 | 1 日 5（デザインモードのみ） |
| Rork Pro（月 20 ドル） | 100 | なし |
| Rork Max（月 200 ドルから） | 1,000 / 2,500 / 5,000 / 10,000 | なし |
リセットの起点も揃っておりません。有料プランは最初に購入した日の応当日で、無料プランは暦月の頭です。「そろそろ戻るはず」と思っていた日が数日ずれるのは、たいていここが理由です。無料枠の日次上限については、Rork の無料枠は月35クレジットですが、実際にぶつかるのは1日5という上限のほうですで詳しく書いております。
減っていないことのほうが、問題になる場面
ここがいちばん見落としやすいところです。
公式ドキュメントには、Use Cloud Credits がそのプロジェクトで off になっていると、アプリは従来の機能に留まり Rork AI Cloud を使わない、という警告が置かれております。
つまり「AI 機能を足したのに Cloud 残高がまったく動かない」という状態は、節約できている証拠とは限りません。そもそも呼ばれていない可能性のほうが高いのです。
私は別のサービスでも似た形で時間を溶かしたことがあります。Lab のサイトを運用していた折、機能自体は実装できているのに、管理画面のトグルがひとつ off のままで、数日ほど「効いていないのはコードのせいだ」と探し続けておりました。動かない残高は、うまくいっている証拠ではありません。 この線引きを引いてからは、実装を疑う前に必ずスイッチを見に行くようになりました。
確認の順番は三つで足ります。トグルの状態、Cloud Usage にその日のリクエストが立っているか、そしてモデル別の内訳に想定したモデルの名前があるか。三つとも空なら、コードではなく設定を直す場面です。
公開後は、自分ではなく利用者が減らします
Build クレジットは、自分が手を止めれば止まります。Cloud クレジットはそうはまいりません。アプリが公開されていれば、利用者が機能を使うたびに残高が動きます。
公式は、低残高のメール通知と、残りが少なくなったときに自動で補充する auto top-up を用意しております。どちらも「途中で止まらない」ための仕掛けであって、「使いすぎない」ための仕掛けではありません。ここは分けて考える必要があります。
ですので、上限はアプリ側に置きます。バックエンド関数で、利用者 1 人あたりの 1 日の呼び出し回数を数えて、超えた分は断る——それだけで、想定外の伸び方はかなり抑えられます。
// ai-proxy.ts — 公開後の Cloud 残高を守るための最小のゲート
// 利用者 1 人あたり 1 日の AI 呼び出し回数に上限を置き、超えた分は断ります。
const DAILY_LIMIT = 30;
type UsageRow = { count: number; day: string };
type Deps = {
userId: string;
// 日付ごとの利用回数の置き場所（Supabase でも KV でも構いません）
getUsage: (userId: string, day: string) => Promise<UsageRow | null>;
bumpUsage: (userId: string, day: string) => Promise<void>;
callModel: (prompt: string) => Promise<string>;
};
export async function handleAiRequest(req: Request, deps: Deps): Promise<Response> {
const day = new Date().toISOString().slice(0, 10); // 例: "2026-09-15"（UTC 基準で丸めます）
const row = await deps.getUsage(deps.userId, day);
if ((row?.count ?? 0) >= DAILY_LIMIT) {
// 期待する応答: { "error": "daily_limit_reached", "limit": 30 } を 429 で返します
return new Response(
JSON.stringify({ error: "daily_limit_reached", limit: DAILY_LIMIT }),
{ status: 429, headers: { "Content-Type": "application/json" } },
);
}
const { prompt } = (await req.json()) as { prompt: string };
// 呼び出す前に加算します。失敗しても戻しません
await deps.bumpUsage(deps.userId, day);
const text = await deps.callModel(prompt);
return new Response(JSON.stringify({ text }), {
headers: { "Content-Type": "application/json" },
});
}加算をモデル呼び出しの前に置いているのには理由があります。後に置くと、応答の途中で失敗した回が数に入らないまま、料金だけが発生する経路が生まれてしまうからです。取りこぼしよりも、二重に数えるほうが安全側に倒れます。
上限値そのものは、Cloud Usage のモデル別内訳を見てから決めるのが確実です。1 回あたりの単価はモデルによって桁が変わりますので、回数だけでは金額の感覚が掴めないのです。
私自身、個人開発で壁紙アプリを長く配信しておりまして、配信側の負荷が自分の操作ではなく利用者の使い方で動くことには慣れているつもりでした。それでも Cloud 残高は、慣れとは別の気持ち悪さがありました。前払いの残高が、自分の手の外で目減りしていくという形が、これまでの従量課金とは違ったのだと思います。
プランそのものの選び直しを考えている方は、Rorkの料金プランを正直に比較する：無料・Pro・Maxの違いと個人開発者が損しない選び方と、Rork の無料プランと無料トライアル — クレジットが尽きたとき、手元に何が残るかも合わせてご覧いただければと思います。
今日、ひとつだけ確かめるとしたら
Billing の Cloud Usage を開いて、直近 30 日でいちばん大きい行のモデル名を見てみてください。そこに並んでいる名前が、自分が使っているつもりのモデルと一致しているかどうか——確かめるのはそれだけで十分です。一致していなければ、指示のどこかでモデルが切り替わっております。
お読みいただきありがとうございました。残高の読み方が少しでも軽くなれば嬉しく思います。