Antigravity の v2.1.4 で、クォータ画面が「使った量」と「残量」をはっきり並べて見せるようになりました。地味な変更に見えますが、個人開発で複数の自動化を回している立場からすると、これはかなり大きい改善です。これまでは「なんとなく今月は使いすぎている気がする」という感覚に頼っていたものが、used と remaining という2つの数値で語れるようになったからです。
ただ、画面を眺めるだけでは精算になりません。私はこの数値を、週に一度の精算の起点として使っています。感覚で「足りなさそう」と慌てるのではなく、残量から枯渇日を逆算し、足りないなら何を止めるかを先に決めておく。その手順を共有します。
残量表示になって何が変わったか
以前のクォータ表示は、累計の使用量が中心でした。使った量はわかっても、「あと何回ぶん回せるか」が直感的に掴めなかったのです。v2.1.4 は remaining を前面に出したことで、判断の軸が「使った量」から「残り」に変わりました。
この差は小さいようで大きいです。残量が見えると、人は自然に「この残りで月末まで持つか」を考え始めます。私自身、表示が変わってから、月の前半に使いすぎる癖にようやく気づきました。
used と remaining を率に読み替える
最初にやるのは、2つの数値を率に直すことです。生の数値のままだと、プランが変わったときに比較できなくなります。
def quota_status(used: float, remaining: float):
total = used + remaining
used_pct = used / total * 100
remaining_pct = remaining / total * 100
return {
"total": total,
"used_pct": round(used_pct, 1),
"remaining_pct": round(remaining_pct, 1),
}
# 例: 月の14日目、used=620 / remaining=380
print(quota_status(620, 380))
# {'total': 1000, 'used_pct': 62.0, 'remaining_pct': 38.0}
月の14日目で62%を使っているなら、単純な按分（46.7%が目安）を大きく超えています。この時点で、残りの16日を38%で回さなければならないとわかります。率に直すだけで、慌てる前に状況が見えます。
バーンレートで枯渇日を予測する
率の次は、1日あたりの消費（バーンレート）です。これがあると、現在のペースで何日に枯渇するかを予測できます。
from datetime import date
def predict_exhaustion(used: float, remaining: float, day_of_month: int):
burn_per_day = used / day_of_month # 1日あたり消費
days_left = remaining / burn_per_day if burn_per_day else 999
return {
"burn_per_day": round(burn_per_day, 1),
"days_until_empty": round(days_left, 1),
}
print(predict_exhaustion(620, 380, 14))
# {'burn_per_day': 44.3, 'days_until_empty': 8.6}
14日目で残量が8.6日ぶんしかない、という結果は、月末まで持たないことを意味します。残り16日に対して8.6日。この差を埋めるには、バーンレートを約46%落とす必要がある、と具体的に言えます。感覚なら「ちょっと節約しよう」で終わるところを、数値は「半分近く減らせ」と教えてくれます。
複数プロジェクトにクォータを配分する
個人開発で複数の自動化を回していると、クォータは1つでもそれを食う口は複数あります。私は Dolice Labs で4つのブログ自動化を走らせているので、限られた残量をどう割り振るかが毎週の論点になります。
| 用途 | 性質 | 週次配分の目安 | 枯渇時の扱い |
|---|
| 本番の定期実行 | 止めると穴が空く | 50% | 最後まで守る |
| 品質改善・加筆 | 遅らせても影響小 | 30% | 翌週に繰り越す |
| 試作・検証 | いつでも止められる | 20% | 真っ先に止める |
配分の肝は、止めてよい順番を先に決めておくことです。枯渇しかけてから「どれを止めるか」を考えると、たいてい一番動かしたくないものまで巻き添えにします。AdMob 収益に直結する本番処理だけは最後まで守る、というように優先順位を平時に決めておけば、いざというとき迷いません。
枯渇の兆候が出たときの優先順位
バーンレートが配分を超え始めたら、次の順で手を打ちます。慌てて全部を止めるのではなく、影響の小さいものから順に絞るのが原則です。
- 試作・検証のジョブを停止する。これだけで20%ぶんの口が閉じる
- 品質改善の頻度を半分に落とす。本番ではないので遅延が許容できる
- 本番処理のうち、再試行回数の上限を一段下げる。失敗の握りつぶしではなく、攻めの再試行を減らす
- それでも足りなければ、本番の実行間隔を広げる。最後の手段
この順番を守ると、限られた残量でも「読者に見える部分」への影響を最小化できます。私はこの優先順位を運用ノートに書いて固定し、枯渇しかけた週はそれに従うだけにしています。判断をその場でしないことが、結局いちばん事故を減らします。
週次精算をルーティンにする
最後に、ここまでを週に一度の精算としてまとめます。月曜の朝、クォータ画面を開いて used/remaining を控え、率とバーンレートを出し、枯渇日を予測する。配分を超えていれば、上の優先順位で先に止めるものを決める。所要5分ほどの作業です。
この5分を習慣にしてから、月末にクォータが尽きて本番が止まる、という事故がなくなりました。残量表示は、眺めるためではなく精算するための道具です。次にクォータ画面を開くときは、used と remaining を一度メモして、率に直すところから始めてみてください。