## 25. 費用の考え方

確認：2026年9月

料金は頻繁に変わるため、金額は記載しない。採用前に各サービスの料金ページで最新の金額を確認する。ここでは**何に対して課金され、どこで膨らみやすいか**を整理する。

| サービス | 主な課金の軸 | 膨らみやすい要因 | 対策 |
|---|---|---|---|
| Vercel | 関数の実行（アクティブなCPU時間、メモリ、呼び出し回数）、画像最適化の変換回数、データ転送、ビルド | 画像最適化・SSRの多用、アクセス急増 | 支出上限を設定する。静的生成できるページは静的にする |
| Supabase | コンピュート（インスタンスサイズ）、月間アクティブユーザー数、データ転送量、ストレージ | toCでのユーザー増加、Storageからの大量配信 | 画像や動画の配信はCDN（Cloudflare Images等）に逃がす。規模が見えたら §24 の移行パスを検討する |
| Neon | コンピュート時間、ストレージ | 常時起動の設定、使っていないブランチやプロジェクトの放置 | 自動停止（scale to zero）を有効にする。不要なブランチを削除する |
| Amazon RDS | インスタンスの稼働時間、ストレージ、I/O、バックアップ | 過大なインスタンスサイズ、使っていない検証環境の常時稼働 | 検証環境は夜間停止する。リザーブドインスタンスを検討する |
| ECS Fargate | vCPU・メモリの稼働時間 | 過大なタスクサイズ、最小タスク数の設定しすぎ | 実測に合わせて調整する。検証環境はSpotを使う |
| AWS Lambda | リクエスト数、実行時間×メモリ（初期化にかかった時間も課金対象） | 常時トラフィックをLambdaで処理している | §23-2 の目安で常駐コンテナへ移す |
| NAT Gateway | 稼働時間、処理したデータ量 | プライベートサブネットからの外部通信量（イメージ取得、外部API） | VPCエンドポイントを使う。検証環境では構成を見直す |
| S3 | 保存量、リクエスト数、データ転送 | 外部への大量配信 | CloudFront経由で配信する。配信が多いならR2を検討する |
| Cloudflare R2 | 保存量、操作回数（外部への転送は無料） | 大量の小さなファイル操作 | まとめて扱う |
| CloudWatch | ログの取り込み量、保存期間、Logs Insightsでスキャンした量、カスタムメトリクス | デバッグログの出しっぱなし、保存期間を無期限のままにする | ログレベルと保存期間を決める。参照頻度の低いロググループは低頻度アクセスのクラスにする |
| Datadog | ホスト数、ログ量、カスタムメトリクス | ログの全量送信、タグの組み合わせ爆発 | 送信するログを絞る。サンプリングを使う |
| Sentry | エラー数、トレースのスパン数、セッションリプレイ数、ログ量 | 同じエラーの大量発生、トレースの全量送信 | トレースのサンプリング率を設定する。既知のノイズを除外する |
| Clerk／Auth0 | 月間アクティブユーザー数 | toCでユーザーが急増 | 規模が見えたら §24 の移行パスを検討する |
| Algolia | 検索リクエスト数、レコード数 | 入力のたびに検索する実装 | デバウンスを入れる。規模次第でMeilisearchを検討する |
| LLM API | 入出力のトークン数 | 長いプロンプトの繰り返し送信、不要な再生成 | プロンプトキャッシュを使う。用途ごとに小さいモデルを使い分ける |
| Stripe／KOMOJU | 決済額に対する手数料率 | — | 決済手段ごとの料率を事前に確認する |

**共通の対策**：クラウドの予算アラートを必ず設定する。PaaSは支出上限を設定する。検証環境は使わない時間に停止する。