「秒単位で課金」は、完結しているように聞こえて実はそうではない言葉のひとつです。その裏には、支払額を左右するいくつもの決定があります。何を計測するのか、計測はいつ始まりいつ止まるのか、最低料金はあるのか、1 セント未満の端数をどう扱うのか、そして実際にいつ残高からお金が引かれるのか。
この記事では、コードサンドボックスについての私たちの答えを、計算と一緒に書き出します。目標は、何かを実行する前に請求額をセント単位で予測できること、そして秒単位課金があなたのワークロードには合わないモデルになる境目を見分けられることです。
単位:確保された vCPU と RAM
サンドボックスの価格は、そのプランが確保するリソースの価格です。
- vCPU 1 時間あたり $0.040
- RAM 1 GiB・1 時間あたり $0.013
したがって small プラン(0.5 vCPU、1 GB)は 0.5 × 0.040 + 1 × 0.013 = 1 時間 $0.033、1 秒あたり約 $0.0000092 です。最大の max(8 vCPU、16 GB)は 1 時間 $0.528 です。
私たちが計測するのは確保量であって、消費量ではありません。次のコマンドを待っているサンドボックスも、プロジェクトをコンパイルしているサンドボックスも、秒単価は同じです。実際の CPU 使用量で計測する方が紙の上では公平に見えますが、それでは価格を事前に知ることができず、しかも容量はどちらにせよあなたのために確保されています。送信トラフィックには課金しません。
時計:作成から削除まで
一時的なサンドボックスは、作成された瞬間から削除されるまで課金されます。アイドルタイムアウト(デフォルト 300 秒)で削除されるまでのアイドル時間も含まれます。
予想外の請求のほとんどはここから生まれます。2 分で終わるスクリプトでも、誰も削除しないサンドボックスで動かせば 7 分分の課金になります。2 分の作業と、タイムアウトを待つ 5 分です。解決策は地味です。使い終わったらサンドボックスを削除する(SDK の with ブロックがやってくれます)か、アイドルタイムアウトを短くすることです。
最低料金:サンドボックスあたり 60 秒
すべての一時的なサンドボックスは、その寿命のうち少なくとも 60 秒分が課金されます。microVM を起動し、ディスクとネットワークを接続し、それをすべて片付けるコストは、中のコードが 1 秒動くか 50 秒動くかに関係なく同じだからです。
| 寿命 | プラン | 課金時間 | 料金 |
|---|---|---|---|
| 20 秒 | small | 60 秒 | $0.00055 |
| 61 秒 | small | 61 秒 | $0.00056 |
| 10 分 | small | 600 秒 | $0.0055 |
| 3 時間 | standard | 10,800 秒 | $0.198 |
最低料金はサンドボックスが終了したときに一度だけ、しかも総寿命が 60 秒未満だった場合にのみ適用されます。時間単位やコマンド単位の追加の最低料金はありません。
積算と引き落とし:マイクロドルとセント単位
ここが「秒単位」という言葉がふつう語らない部分です。サンドボックスのホストは、サンドボックスごとに 1 時間単位の区間で使用量を記録します。課金ジョブは 1 分に 1 回、締まった区間を集めて料金を計算し、残高から引き落とします。
料金計算は 100 万分の 1 ドル単位、引き落としはセント単位で行われます。1 セント未満の残りはアカウントに残り、次回の引き落としに加算されます。サンドボックスごとにも時間ごとにも切り上げはしません。
小さな規模ではこれが効いてきます。20 秒のサンドボックス 100 個の料金は 100 × $0.00055 = $0.055 です。引き落とされるのは 5 セントで、残りの 0.5 セントは次のバッチを待ちます。もしサンドボックスごとに 1 セントへ切り上げていたら、同じ作業に 1 ドルかかっていたことになります。
ほかに知っておく価値のある性質が 2 つあります。
- 各区間はちょうど一度だけ課金されます。 使用量の記録と引き落としは、サンドボックスと時間をキーにして 1 つのデータベーストランザクションで書き込まれます。再実行や確認の喪失で二重に請求されることはありません。
- 障害は課金を遅らせるだけで、失わせたり重複させたりはしません。 課金側がサンドボックスのホストに到達できなければ何も確定されず、区間は待機し、接続が戻ったときに課金されます。
その結果、ダッシュボードの数字はリアルタイムの数字より最大 1 時間遅れることがあります。リアルタイムの数字は、GET /sandboxes/{id}/usage がそのサンドボックスのここまでの billed_usd と estimated_total_usd を返します。
persistent サンドボックス:開始した 1 時間ごと、上限あり
persistent サンドボックスはセッション間でディスクを保持し、最長 30 日間使えます。課金は開始した 1 時間ごとで、61 分なら 2 時間分です。その代わり、1 暦月(UTC)の料金が 730 時間分から 25% を引いた額を超えることはありません。
standard プランの場合、この上限は $48.18 ではなく月 $36.14 です。persistent サンドボックスが一時停止している間は、まったく課金されません。
残高がなくなったら
残高がマイナスになることはありません。新しいサンドボックスは 402 insufficient_balance で拒否されます。すでに動いている一時的なサンドボックスは、アイドルタイムアウトか TTL で終了します。persistent のものはチャージがないまま 24 時間たつと一時停止し、入金すると自動的に再開します。一時停止中のスナップショットは 14 日間保管されます。 その後サンドボックスは削除され、id には 410 sandbox_deleted が返ります。
AI エージェントにサンドボックスを作らせるなら、1 日と 1 か月の上限を設定してください。上限に達すると、リセット時刻とともに 429 budget_exceeded が返されます。プログラムはこれに基づいて動作できます。
秒単位課金が不利になるところ
秒単位課金は、秒や分で測れる作業には最適です。作業が長く続くほど不利になります。
| ワークロード | 秒単位のサンドボックス | 代替案 |
|---|---|---|
| 2 分のテスト | $0.0011(small) | 時間課金のマシンは丸 1 時間分請求する |
| 3 時間のバッチ処理 | $0.198(standard) | ほぼ同じ |
| 24 時間 365 日動くサービス | 月 $36.14(standard、persistent の上限) | AI agent VPS:4 vCPU、4 GB で月 $10 |
分岐点は、おおよそワークロードが 1 日に数時間以上動くあたりです。それを超えると、使わない柔軟性に対してお金を払うことになり、月単位で借りるサーバーの方が時間あたりではるかに安くなります。秒単位課金は割引ではなく、容量計画をしなくて済むことへの対価だと考えるのが公平です。
すばやい見積もり方
プランの 1 時間あたりの価格 × サンドボックスが存在する秒数 ÷ 3600、ただし下限は 60 秒。自分で削除しないならアイドルタイムアウトを足します。persistent の場合は、各セッションを 1 時間単位に切り上げ、月の上限で打ち止めにします。
ルール、クォータ、予算 API の全体はサンドボックスの制限と課金に、上で使った呼び出しは SDK リファレンスにあります。秒単位で実際に何を借りているのか気になるなら Firecracker microVM をやさしく解説 を、マシンを作るのが人ではなくソフトウェアになったとき課金モデルがなぜそれほど重要になるのかは AI エージェントがインフラに本当に求めるもの をご覧ください。
コメント
まだコメントはありません。最初になりましょう。