Free Tier 预算看板：多服务的免费额度管理

2026/9/20

背景与问题

solo スタック（Workers/D1/Stream/R2/各種 SaaS）は free tier の集合体——「無料のつもりが課金」事故と、逆に「無料枠を活かしきれていない」無駄の両方がある。額度の一元管理設計。

（出典はいずれも 2026-09-20 アクセス）

事実（AWS Free Tier）：最大 $200 クレジット・90+ サービス・6 か月——クレジット型と常時無料型（Lambda 1M リクエスト/月など 30+ サービスが常時無料枠持ち）が混在する構造。
事実（Unity Cloud の alert モデル）：free tier 枠の 75% と 100% で自動アラート——自家トラッキングの閾値設計の良い基準。
事実（CAST AI の隠れコスト解説）：「無料」でもテスト中に課金が発生する路径がある（制限超過の瞬間）——日次リセット型（Workers）と月次型では事故の型が違う。
事実（ツール状況）：マルチクラウド統一の free tier ダッシュボードは存在しない（各社別管理）——nOps 等のコストツールか自作の軽量集計が選択肢。
推测：solo の実害は「複数サービスの日次リセット時刻の違い」——UTC 日次（Workers）と JST 日次（国内 SaaS）が混在すると残量の勘違いが起きる。全枠を「UTC 換算の残量%」で一覧化するのが解。

自家看板の最小構成：表（サービス/枠/使用量/残量%/リセット時刻）を 1 ページで管理——週次で 5 分更新（自動 API 連携は過剰装備）。
閾値ルール：残量 25% 以下で黄、10% 以下で赤（Unity の 75/100 モデルを反転）——赤のサービスは新規利用を止める。
日次リセット型の特別扱い：Workers（10 万 req/日）は「転発で打ち抜かれる」型——opc-edge-api-workers の限流とセットで、尖峰日の事前予測（宣伝予定日）を看板に書く。
年 1 回の見直し：free tier の変更（縮小傾向が 2026 年の一般トレンド）を確認——枠縮小は有料線の見直しトリガー。