フレームワーク活用ガイドひとことで言うと#
サービスの成長トレンドとイベント予測に基づいてインフラリソース（CPU、メモリ、ストレージ、ネットワーク）を事前に確保し、パフォーマンス低下や障害を未然に防ぐ計画手法。足りなければ落ち、余れば無駄なコストが出る。ちょうどいい供給を維持し続けるための継続的プロセスである。
押さえておきたい用語#
- ヘッドルーム（Headroom）
- 現在の使用量とリソース上限の差分。突発的な負荷増に対応するための余裕幅を確保しておくことが重要。
- 飽和点（Saturation Point）
- リソース使用率がこれを超えるとレイテンシやエラー率が急上昇する閾値。CPUなら70〜80%が目安になることが多い。
- リードタイム（Lead Time）
- リソースの追加を決定してから実際に利用可能になるまでの時間。クラウドなら数分だが、オンプレミスでは数週間〜数か月かかる。
- 水平スケーリング（Horizontal Scaling）
- サーバーの台数を増やすことで処理能力を拡張する方式。スケールアウトとも呼ぶ。
- 垂直スケーリング（Vertical Scaling）
- サーバーのスペック（CPU・メモリ）を上げることで処理能力を拡張する方式。スケールアップとも呼ぶ。
キャパシティプランニングの全体像#
こんな悩みに効く#
- セール期間やキャンペーン時にサーバーが落ち、売上機会を逃したことがある
- クラウドの月額コストが予算を大幅に超過し、経営層から説明を求められている
- 「いつDBのストレージが満杯になるか」を誰も把握しておらず、夜中にアラートが鳴る
- オートスケーリングに頼りきりで、スケールアウトの限界を検証していない
基本の使い方#
主要リソースの使用量とヘッドルームを定量的に把握する。
- CPU使用率、メモリ使用率、ディスクI/O、ネットワーク帯域をサービスごとに記録
- ピーク時（平日昼間、月末処理など）と平常時の差を把握する
- 各リソースの飽和点（パフォーマンスが劣化し始める閾値）を負荷テストで特定する
過去のトレンドとビジネス計画から3〜12か月先のリソース需要を推計する。
- 過去6〜12か月のリソース使用量の増加トレンドを線形/指数回帰で外挿する
- ビジネス側の情報（新規顧客獲得目標、大型キャンペーン、新機能リリース）を組み込む
- 楽観・標準・悲観の3シナリオで試算し、最悪ケースでもヘッドルームが確保できるか確認する
需要予測に基づいていつ・何を・どれだけ増やすかを具体化する。
- 水平スケーリング（台数追加）と垂直スケーリング（スペック向上）の使い分けを決める
- リードタイムを考慮する（Reserved Instanceの購入は1〜3か月前に判断が必要）
- コスト見積を作り、経営層の承認を得る。RI/Savings Plansの活用で最大40%削減できることも多い
リソースを追加したら、予測の精度を検証して次のサイクルに活かす。
- 負荷テストで実際のキャパシティが予定通りか確認する
- 予測と実績の乖離が大きい場合は、予測モデルを修正する
- ダッシュボードにヘッドルームをリアルタイム表示し、閾値を下回ったらアラートを出す設定にする
具体例#
月間GMV15億円のECプラットフォーム。前年の年末商戦ではトラフィックが通常の2.8倍に急増し、商品検索APIのレイテンシがP99で3秒を超え、カート離脱率が**40%**に達した。
計測:
- 通常時: APIサーバー8台、CPU使用率平均45%、P99レイテンシ200ms
- 前年ピーク時: CPU使用率92%、P99レイテンシ3,200ms
- 飽和点: 負荷テストでCPU 70%超からレイテンシが急上昇することを確認
予測:
- 今年の年末商戦はマーケティング投資を前年比1.5倍に増やす計画
- トラフィック予測: 通常比3.5倍（前年比1.25倍）
計画:
- APIサーバーを8台→24台に増設（3倍のヘッドルーム込み）
- DBのリードレプリカを2台→4台に追加
- CDNのキャッシュヒット率を改善（60%→85%）してオリジンへの負荷を削減
- Reserved Instanceを9月に購入し、コストを**35%**削減
結果:
- 年末商戦ピーク時: CPU使用率58%、P99レイテンシ180ms
- カート離脱率: 40% → 18%（前年比22pt改善）
- インフラコスト: オンデマンドで全台数を賄う場合と比較して月額120万円節約
顧客800社のBtoB SaaS企業。PostgreSQLのストレージ使用量が2TB中1.6TBに達し、残り400GB。過去の増加ペースを分析していなかったため、「あとどれくらい持つか」が不明だった。
計測:
- 過去12か月のストレージ増加量をグラフ化 → 月平均80GB増加
- 直近3か月は大口顧客の契約が増え、月120GBペースに加速
予測:
- 現在のペース（月120GB）が続くと、3.3か月後にストレージ上限に到達
- 新規顧客獲得計画を加味すると、2.5か月後に枯渇リスク
計画:
- 短期: ストレージを2TB→4TBに拡張（ダウンタイム30分、深夜メンテで実施）
- 中期: 3か月以上前のログデータをS3にアーカイブするバッチを構築（月40GB削減見込み）
- 長期: テーブルパーティショニングを導入し、古いデータの管理を効率化
結果:
- ストレージ拡張を2か月前に実施し、枯渇を回避
- アーカイブバッチにより増加ペースが月120GB→月80GBに減速
- 四半期ごとの「ストレージ残量レポート」を自動生成する仕組みを構築し、以降は枯渇リスクを6か月前に検知可能に
エンジニア12名のスタートアップ。月間アクティブユーザーが5万人から1年で50万人に急成長する見込みで、AWS月額コストは現在80万円。「10倍のユーザーに10倍のコスト」では事業計画が成り立たない。
計測:
- 現状のアーキテクチャでユーザー1人あたりのインフラコストは16円/月
- ボトルネック: 全リクエストがRDS（db.r6g.xlarge）を経由しており、DB負荷が最も高い
予測:
- 10倍成長時にそのままスケールすると月額コストは800万円（10倍）
- 目標: 10倍成長時に月額300万円以下（ユーザーあたり6円以下）
計画:
- ElastiCacheを導入し、読み取りの70%をキャッシュで処理（DB負荷を60%削減）
- 静的アセットをCloudFront経由に移行（オリジン負荷を50%削減）
- バッチ処理をSpot Instanceに移行（バッチコストを70%削減）
- Savings Plansを12か月契約で購入（ベースラインインスタンスを38%割引）
結果（1年後）:
- MAU: 5万 → 48万人（約10倍）
- 月額インフラコスト: 80万円 → 260万円（3.25倍に抑制）
- ユーザーあたりコスト: 16円 → 5.4円（66%削減）
- SLO（P99レイテンシ300ms以下）は全月で達成
やりがちな失敗パターン#
- 過去のトレンドだけで予測する — ビジネス側の計画（大型キャンペーン、新機能リリース、大口顧客のオンボーディング）を織り込まないと、予測が外れる。エンジニアとビジネスの定期的な情報共有が必須
- ヘッドルームを確保しない — 予測通りぴったりのリソースしか用意しないと、予測誤差や突発的な負荷で飽和する。最低20〜30%のヘッドルームを確保する
- コスト最適化を後回しにする — 「まず動くことが大事」とオンデマンドインスタンスだけで構築し、気づいたときにはコストが予算の2倍になっている。RI/Savings Plansは早期に検討する
- 計画を一度作って更新しない — サービスの成長は予測通りに進まない。四半期ごとに予測と実績を照合し、計画を見直すサイクルを回す
まとめ#
キャパシティプランニングは、現在のリソース使用量を計測し、将来の需要を予測し、必要なリソースを事前に確保する継続的プロセスである。計測→予測→計画→実行の4フェーズを四半期ごとに回すことで、パフォーマンス障害とコスト超過の両方を防ぐ。大事なのはビジネスの成長計画とインフラ計画を連動させること。エンジニアだけで予測するのではなく、営業・マーケティングの情報を組み込むことで予測精度が大きく向上する。