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

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

全体像は Vercel 本番運用ガイド を参照してください。

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

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

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）

つまり——関数が 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 無料枠（月）

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

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

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

リージョン選定もコスト：既定の 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軸すべてゼロです。

// 関数レスポンスを 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（キャッシュ戦略）。
• x-vercel-cache で HIT を実測する。これが「呼ばれていない＝課金されていない」の証拠。
• ISR のリクエスト併合は、スパイク時に同一パスへの関数呼び出しをリージョンごと1回に束ね、Invocation を抑えます。

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

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

• 後処理でよいものは waitUntil（応答後に実行。Functions ガイド）。
• 長時間・状態を持つものは Workflows / キューへ。
• これにより「ユーザーが待つ関数」は I/O 主体になり、Active CPU が下がります。

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

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

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

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

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

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

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

コストを監視する

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

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

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

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

• 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 本番運用ガイド から。

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