# Vercel コスト最適化ガイド：Active CPU 課金モデルを理解して請求を下げる

> Vercel公式に忠実なコスト最適化ガイド。Fluid ComputeのActive CPU課金（CPU実行時間のみ課金・I/O待ちは非課金）、Provisioned Memory（GB-hr）、Invocationsの3軸、リージョン別単価、公式の計算式、無料枠（Hobby: 4 CPU時間/360 GB-hr/100万Invocations）、キャッシュ・maxDuration・メモリ・並行性・ジョブ分離による削減策を実数値で解説します。

- 公開日: 2026-06-28
- 著者: 友田 陽大
- タグ: Vercel, コスト最適化, Fluid Compute, サーバーレス, 可観測性, アーキテクチャ設計, TypeScript
- URL: https://tomodahinata.com/blog/vercel-cost-active-cpu-pricing-optimization-guide
- カテゴリ: Vercel 本番運用
- 総合ガイド: https://tomodahinata.com/blog/vercel-production-platform-guide

## 要点

- Vercel FunctionsはActive CPU課金——コードが実際にCPUを使った時間（ミリ秒）だけ課金され、DBクエリやAI呼び出しのI/O待ちは課金されない。従来の壁時計GB秒とは根本的に違い、I/O主体のアプリほど安くなる
- 課金は3軸：Active CPU（CPU-hr、I/O待ちで一時停止）／Provisioned Memory（GB-hr、インスタンス生存中ずっと・I/O待ちでも継続）／Invocations（リクエスト数、Pro $0.60/100万）。メモリは待ち時間も課金されるのがポイント
- Hobby無料枠はActive CPU 4時間・Provisioned Memory 360 GB-hr・Invocations 100万/月。単価はリージョン別で、東京hnd1/大阪kix1はCPU $0.202/h・メモリ $0.0167/GB-h、iad1は$0.128/$0.0106
- 削減の効く順は——①キャッシュでInvocation自体を消す（x-vercel-cacheでHIT確認）②重いCPU処理を関数から分離（Workflows/ジョブ）③maxDuration/メモリを用途に合わせ過剰割当を削る④Fluidの並行性でインスタンス総数を減らす
- I/Oバウンドな処理はActive CPU課金とFluidの並行性の恩恵が大きい。逆に画像処理などCPUバウンドはActive CPUを多く消費するので分離・最適化の対象

---

「Vercel は規模が大きくなると高い」——これは**課金モデルを誤解したまま設計した場合**に起きます。2026年の Vercel Functions は **Active CPU 課金**で、従来のサーバーレス（壁時計の GB 秒）とは根本的に違います。モデルを正しく理解すると、**同じアプリでも請求が大きく変わる**設計判断ができます。この記事は [Fluid compute pricing](https://vercel.com/docs/functions/usage-and-pricing) の公式仕様・実数値に忠実に、コストの作られ方と下げ方をまとめます。

全体像は [Vercel 本番運用ガイド](/blog/vercel-production-platform-guide) を参照してください。

---

## まず課金の3軸を理解する

Vercel Functions（Fluid Compute）の請求は**3軸の合算**です。

| 軸 | 課金対象 | 決定的な性質 |
|---|---|---|
| **Active CPU** | コードが**実際に CPU を使った時間**（ms） | **I/O 待ち中は課金停止**。CPU-hr 単位 |
| **Provisioned Memory** | 割り当てメモリ × インスタンス稼働時間 | **I/O 待ち中も課金継続**。GB-hr 単位 |
| **Invocations** | 受信リクエスト数 | 成否問わず1件ずつ。Pro $0.60/100万 |

### Active CPU が変える発想

公式の説明そのものが、設計の核心です。

> You are only billed during actual code execution and not during I/O operations (database queries, like AI model calls, etc.) ... Pauses billing when your code is waiting for external services.（— [Fluid compute pricing](https://vercel.com/docs/functions/usage-and-pricing)）

つまり——**関数が DB や AI の応答を待っている間、CPU 課金は止まる**。例えば「データ処理に 100ms・DB クエリ待ちに 400ms」かかる関数は、**100ms 分の Active CPU しか課金されません**。

ここから2つの帰結が出ます。

1. **I/O バウンドなアプリ（AI・外部API・DB中心）は安くなる**。待ち時間が課金されないため。
2. **CPU バウンドな処理（画像処理・暗号・大きな JSON 変換）は Active CPU を多く消費する**。だから「重い CPU 処理を関数から分離する」が直接効く。

> ただし **Provisioned Memory は I/O 待ち中も課金**されます。「メモリ × インスタンス生存時間」なので、**過剰なメモリ割り当て**と**だらだら長いインスタンス生存**はメモリ課金を押し上げます。Active CPU が止まってもメモリは止まらない——ここが見落とされがちです。

---

## 無料枠とリージョン別単価（実数値）

### Hobby 無料枠（月）

| リソース | 無料枠 |
|---|---|
| Active CPU | 4 時間 |
| Provisioned Memory | 360 GB-hr |
| Invocations | 100万 |

Pro はオンデマンド課金で、月次の Pro 利用クレジットが相殺に使えます。

### リージョン別単価（抜粋）

単価は**リージョンで変わります**。日本周辺と主要リージョンを抜粋します（per hour CPU / per GB-hr memory）。

| リージョン | Active CPU (/h) | Provisioned Memory (/GB-h) |
|---|---|---|
| 東京 `hnd1` | $0.202 | $0.0167 |
| 大阪 `kix1` | $0.202 | $0.0167 |
| Washington D.C. `iad1`（既定） | $0.128 | $0.0106 |
| Portland `pdx1` | $0.128 | $0.0106 |
| シンガポール `sin1` | $0.160 | $0.0133 |
| フランクフルト `fra1` | $0.184 | $0.0152 |

> **リージョン選定もコスト**：既定の `iad1` は単価が最安帯です。レイテンシ要件が許すなら、ユーザーに近いリージョンの単価と性能のトレードオフを意識します（ただし DB との距離も総レイテンシ・転送に効くので、**関数とDBを近づける**のが基本）。

### 公式の計算例

São Paulo（CPU $0.221/h、メモリ $0.0183/GB-h）で、**4GB メモリ・Active CPU 4秒・インスタンス生存10秒**の1呼び出し：

- CPU：(4 / 3600) × $0.221 = **$0.0002456**
- メモリ：(4GB × 10 / 3600) × $0.0183 = **$0.0002033**
- 合計：**$0.0004489 / 呼び出し**

この式から分かるのは、**メモリ割り当て（4GB）とインスタンス生存時間（10秒）がメモリ課金を支配**し、**Active CPU（4秒）は CPU を使った分だけ**ということです。

---

## 削減策：効く順に

闇雲な節約ではなく、**インパクトの大きい順**に手を入れます。

### ① キャッシュで Invocation 自体を消す（最大の効果）

最も効くのは「**関数を呼ばない**」こと。キャッシュヒットすれば Active CPU・メモリ・Invocation の**3軸すべてゼロ**です。

```ts
// 関数レスポンスを CDN にキャッシュ → 2回目以降は関数が走らない
export async function GET() {
  return Response.json(await getCatalog(), {
    headers: { "Cache-Control": "public, s-maxage=300, stale-while-revalidate=600" },
  });
}
```

- ページは **ISR**、API は **CDN Cache**、データ片は **Runtime Cache**（[キャッシュ戦略](/blog/vercel-caching-isr-cache-components-ppr-guide)）。
- **`x-vercel-cache` で `HIT` を実測**する。これが「呼ばれていない＝課金されていない」の証拠。
- ISR の**リクエスト併合**は、スパイク時に同一パスへの関数呼び出しをリージョンごと1回に束ね、Invocation を抑えます。

### ② 重い CPU 処理を関数から分離

Active CPU を食う処理（画像/動画変換・大量集計・暗号）は、ユーザーリクエストの同期パスから外します。

- 後処理でよいものは **`waitUntil`**（応答後に実行。[Functions ガイド](/blog/vercel-functions-fluid-compute-streaming-cron-guide)）。
- 長時間・状態を持つものは **Workflows / キュー**へ。
- これにより「ユーザーが待つ関数」は I/O 主体になり、Active CPU が下がります。

### ③ maxDuration とメモリを用途に合わせる

- **メモリは I/O 待ち中も課金**。CPU をほとんど使わない I/O 主体の関数に 4GB は過剰。用途に合わせて下げる。
- **`maxDuration` の過大設定**は、ハングした関数が上限まで生き続けてメモリ課金を垂れ流すリスク。妥当な上限を明示する。

```ts
// I/O 主体の軽い関数：メモリ控えめ・タイムアウト短め
export const maxDuration = 15; // だらだら生かさない
// メモリはダッシュボード/設定で用途に合わせて（Hobby 2GB/Pro 最大4GB）
```

### ④ Fluid の並行性でインスタンス総数を減らす

Fluid Compute の**最適化された並行性**は、I/O 待ち中に同じインスタンスが別リクエストを処理するため、**必要なインスタンス総数＝メモリ課金の総量**が減ります。これは自動で効きますが、**グローバル状態にリクエスト固有データを置かない**（並行処理を安全にする）規律が前提です（[Functions ガイド](/blog/vercel-functions-fluid-compute-streaming-cron-guide)）。

### ⑤ その他の課金ドライバを見る

- **BotID Deep Analysis** は `checkBotId()` 呼び出しごと（$1/1000）。高価値ルートに限定（[Firewall/BotID](/blog/vercel-firewall-waf-botid-ddos-security-guide)）。
- **Blob** はストレージ（GB-月、15分ごとのスナップショット平均）＋データ転送。**client upload で転送課金を回避**、イミュータブル運用でキャッシュを効かせる（[ストレージ](/blog/vercel-storage-blob-edge-config-marketplace-guide)）。
- **画像最適化・Fast Data Transfer** も Observability で内訳を確認。

---

## コストを監視する

「請求が来てから驚く」を避けるには、**Observability で実値を継続監視**します。

- 関数の **Active CPU / メモリ / Invocation** の内訳を見る。
- どのルートが Invocation を量産しているか（＝キャッシュすべき候補）を特定。
- どのルートが Active CPU を食っているか（＝分離・最適化すべき候補）を特定。
- **Spend Management**（支出上限・アラート）で予算超過を検知。

> **計測 → 最適化の順**：推測でメモリを上げ下げするのではなく、**Observability で重いルートを特定 → ②③で削る → 再計測**。これは [可観測性・SRE の原則](/blog/opentelemetry-observability-production-tracing-metrics-logs) と同じで、「症状（請求・遅延）から原因（特定ルート）へ」遡るのが王道です。

---

## 本番チェックリスト（コスト）

- [ ] **Active CPU 課金**（I/O 待ち非課金）を前提に設計している
- [ ] **メモリは I/O 待ち中も課金**される点を理解し、過剰割当を避ける
- [ ] キャッシュで **Invocation を消し**、`x-vercel-cache` で `HIT` を実測
- [ ] 重い CPU 処理を **`waitUntil`/Workflows/ジョブへ分離**
- [ ] `maxDuration`・メモリを**用途に合わせて明示**
- [ ] Fluid の並行性が効くよう**グローバル状態を汚していない**
- [ ] BotID/Blob/画像最適化など**他の課金ドライバ**も内訳確認
- [ ] **Observability ＋ Spend Management** で継続監視・上限設定

---

## まとめ

Vercel のコストは「規模」ではなく「**設計**」で決まります。

1. **Active CPU 課金**＝I/O 待ちは無料。I/O 主体ほど安い
2. **メモリは待ち時間も課金**＝過剰割当・長生きインスタンスが敵
3. 削減は **①キャッシュ → ②CPU処理の分離 → ③maxDuration/メモリ → ④並行性**の順
4. **計測 → 最適化**（Observability で重いルートを特定）
5. リージョン単価・BotID・Blob 転送など**全課金軸**を見る

課金モデルを味方につければ、Vercel は「規模で高い」どころか、**I/O 主体のモダンなアプリで最もコスト効率の良い基盤**の一つになります。実装の起点は本クラスタの [Vercel 本番運用ガイド](/blog/vercel-production-platform-guide) から。

> 本記事は [Fluid compute pricing](https://vercel.com/docs/functions/usage-and-pricing) / [Functions Limits](https://vercel.com/docs/functions/limitations) 公式ドキュメント（2026年6月時点）に基づきます。価格・無料枠・リージョン単価は変動するため、本番採用時は公式の最新値で試算してください。