2026.10.21 インフラ・クラウド

キャパシティプランニングとは？ピーク負荷から必要台数と余裕率を見積もる手順

キャパシティプランニングは、将来のアクセス量を予測し、その負荷を性能目標どおりに処理できるだけのサーバーやデータベースの能力を前もって確保する作業です。MicrosoftのAzure Well-Architected Frameworkの容量計画ガイドは、CPU・メモリ・ストレージ・ネットワーク帯域の量を見積もる工程と定義し、利用状況が変わる前に実施するよう求めています。

この記事では、見積もりの起点になるピーク時のリクエスト毎秒と同時接続数の出し方、負荷試験で測った1台の上限から必要台数を計算する手順を、そのまま動かせるPythonとPromQLの例で示します。後半では、余裕率を何パーセントに置くかの根拠と、受託開発で見積もりを作り込むべき条件を扱います。

まとめ：キャパシティプランニングで決める3つの数値と見直しの周期

先に結論です。見積もりで決めるのは「将来のピーク負荷」「1台が性能目標を守れる上限」「余裕率」の3つで、必要台数はこの3つの割り算で出ます。勘で台数を決めるのではなく、負荷試験の実測値を分母に置くことが精度を左右します。

ピーク負荷：1日の総量ではなく、1分単位で最も混む時間帯のリクエスト毎秒を使う。伸び率は調達や増設にかかる期間より先まで掛ける
1台の上限：CPU使用率ではなく、応答時間の95パーセンタイルが目標を超える直前の処理量を負荷試験で測る
余裕率：平常時の使用率上限70%前後と、1台停止時に残りで85%以内に収まる条件の両方を満たす台数にする
運用：見積もった台数を自動伸縮の下限に入れ、伸び率の予測を監視に載せて四半期ごとに見直す

キャパシティプランニングとは需要予測からリソース量を逆算する作業

見積もりの対象は、Webサーバーの台数だけではありません。データベースの接続数、ストレージの容量とIOPS、ネットワーク帯域、外部APIの呼び出し上限まで含みます。どれか1つが先に尽きれば、他に余裕があってもシステム全体が遅くなるからです。

ガイドが挙げる手順は、容量データの収集、需要の予測、ワークロード目標との突き合わせ、リソース要件の決定、リソース制限の把握の5段階です。既存システムなら過去の利用データから、新規システムなら類似サービスの実績やパイロット運用のデータから予測を始めます。

自然な伸びと施策による伸びを分けて予測するGoogle SREの整理

GoogleのSRE本の序章は、需要予測とキャパシティプランニングを可用性の責務の一部に位置づけ、成長を2種類に分けています。利用者が自然に増える「オーガニックな成長」と、機能リリースや販売キャンペーンのように事業側の施策で起きる「インオーガニックな成長」です。

同書が必須とする手順は3つです。容量の確保にかかるリードタイムより先まで自然な需要を予測すること、施策による需要を予測に正確に織り込むこと、そして生の容量（サーバーやディスク）とサービスとしての処理能力を定期的な負荷試験で対応づけることです。過去データの延長線だけでは、テレビ放映やセールの日の跳ね上がりは見えません。営業やマーケティングの予定表を入力に加える理由がここにあります。

人員の容量計画やオートスケーリングと混同しやすいITインフラの守備範囲

検索すると、プロジェクトの人員配置を指す「キャパシティプランニング」の記事も多く出てきます。こちらはメンバーの稼働時間と作業量を合わせる管理手法で、本記事のITインフラの見積もりとは別物です。

オートスケーリングとの関係も整理しておきます。自動伸縮は負荷に応じて台数を増減する仕組みで、見積もりを不要にするものではありません。上限台数、データベースの接続数、クラウドのアカウント上限は自動では広がらないため、どこまで伸ばせるかを決める作業は残ります。

見積もりの起点にするピーク時のリクエスト毎秒と伸び率の出し方

最初に作るのは、将来のピーク時に1秒間に何件のリクエストが来るかという1つの数値です。ここでは社内向け業務システムを想定した仮定値で計算を進めます。

DAUと1人あたりのリクエスト数からピーク毎秒へ換算する計算式

1日の利用者数（DAU）に1人あたりのリクエスト数を掛けると1日の総量が出ます。これを86,400秒で割った平均値は使いません。業務システムは始業直後に集中し、ECサイトは夜とセール開始時刻に集中するため、平均の数倍の山が来ます。

項目	仮定値	計算結果
1日の総リクエスト	DAU2万人×30回	60万件
1日平均の毎秒件数	60万件÷86,400秒	約6.9件
ピーク1時間の毎秒件数	60万件×15%÷3,600秒	25件
1分単位のピーク	1時間平均の2倍	50件

平均の約6.9件で台数を決めると、ピークの50件に対して7分の1の能力しか用意できません。ピーク1時間の比率と1分単位の倍率は、既存システムならアクセスログを1分ごとに集計して実測値を入れます。

リトルの法則で同時接続数と応答時間とスループットの関係をつなぐ

要件定義で「同時接続1,000人」と言われたとき、そのまま1,000件を同時に処理できる構成を作ると過剰になります。ログインしている利用者の多くは画面を読んでいて、サーバーに処理を投げていないからです。

待ち行列理論のリトルの法則は「系内の平均件数＝到着率×平均滞在時間」を示します。毎秒50件が届き、1件の処理に平均0.3秒かかるなら、サーバー内で同時に処理中のリクエストは50×0.3＝15件です。スレッド数やデータベースの接続プールの大きさは、この15件を基準に決めます。同時接続ユーザー数は、ロードバランサーの接続上限やセッションの保存先を決めるときに使う別の数値として扱ってください。

過去の実測から伸びを予測するPromQLのpredict_linearの書き方

伸び率は、監視データに直線を当てはめて求めるのが手軽です。Prometheusのクエリ関数のリファレンスによると、predict_linear()は範囲ベクトルに単純な線形回帰を当てはめ、指定した秒数後の値を予測します。計算には範囲内に2つ以上のサンプルが必要です。

# 直近30日の1時間ごとの最大毎秒リクエストから、90日後の値を予測する
predict_linear(
  max_over_time(sum(rate(http_requests_total[5m]))[1h:1m])[30d:1h],
  90 * 86400
)

# ディスクの空き容量が14日以内に0を下回る見込みなら通知する
predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[7d], 14 * 86400) < 0

1つ目は、5分平均のリクエスト毎秒を1時間ごとの最大値にならしてから回帰に掛けています。平均値で予測すると山が均されて低く出るため、ピークの系列を入力にするのが要点となります。直線の当てはめは月ごとの伸びが一定という前提に立つので、キャンペーンなど施策による跳ね上がりは別途足してください。

負荷試験で1台の処理上限を測り必要なサーバー台数へ換算する手順

ピーク負荷が分かったら、分母になる「1台で何件まで性能目標を守れるか」を測ります。カタログ上のCPUコア数やメモリ量から推定した値は、アプリケーションの作り方で数倍ずれるため、分母には使いません。

応答時間の95パーセンタイルが目標を超える手前を上限と置く測り方

本番と同じインスタンス種別の1台に対して、毎秒の件数を段階的に上げながら応答時間を記録します。応答時間の95パーセンタイルが目標（例：300ミリ秒）を超えた段の1つ手前を、その1台の上限として扱ってください。上限を「CPU使用率100%の時点」に置くと、実際にはその手前で応答時間が目標を大きく超えています。

段階的に負荷を上げるシナリオは、k6の使い方とインストール手順を解説した記事のstagesとthresholdsで組めます。試験データの件数は本番に揃えてください。データベースが数百件しかない検証環境では索引が効きすぎて、上限を高く見誤ります。

CPU・メモリ・DB接続数・IOPSのどれが先に尽きるかを確かめる観点

負荷試験中は、応答時間と並べて各資源の使用率、飽和、エラーを記録します。上限に達した段で最初に張りついた資源が、その構成のボトルネックです。調べる順番はUSEメソッドで資源のボトルネックを見つける手順に沿うと抜けが出ません。

データベースの接続数：アプリサーバーを増やすほど接続が増え、先に上限へ届く。台数を増やす前に接続プールの合計を確かめる
CPU：処理の重い画面や帳票出力が混ざると、平均より早く張りつく
ストレージのIOPS：ログ書き込みやバッチと重なる時間帯に詰まる
外部APIの呼び出し上限：決済や地図など、自社では増やせない上限がある

Webサーバーを足せば解決するのはCPUが先に尽きる場合だけです。データベースが先に尽きる構成で台数を足すと、かえって接続数が増えて悪化します。

必要台数を出すPythonの見積もりスクリプトと入力値の意味

ここまでの数値を入れて必要台数を出すスクリプトです。標準ライブラリだけで動きます。

# capacity_estimate.py：ピーク負荷から必要台数を見積もる
import math

dau = 20000              # 1日の利用者数
req_per_user = 30        # 1人あたりの1日のリクエスト数
peak_hour_share = 0.15   # 1日のうちピークの1時間に集中する割合
burst_factor = 2.0       # 1時間平均に対する1分単位のピークの倍率
monthly_growth = 0.03    # 月あたりの伸び率
months = 12              # 見積もり期間（増設にかかる期間より長く取る）
node_max_rps = 40        # 負荷試験でp95が目標内に収まった1台の上限
normal_util = 0.70       # 平常時に許す使用率の上限
failover_util = 0.85     # 1台停止時に許す使用率の上限

peak_rps = dau * req_per_user * peak_hour_share / 3600 * burst_factor
future_rps = peak_rps * (1 + monthly_growth) ** months

by_normal = math.ceil(future_rps / (node_max_rps * normal_util))
by_failover = math.ceil(future_rps / (node_max_rps * failover_util)) + 1
nodes = max(by_normal, by_failover)

print(f"現在のピーク: {peak_rps:.1f} req/s")
print(f"{months}か月後のピーク: {future_rps:.1f} req/s")
print(f"平常時条件: {by_normal}台 / 1台停止条件: {by_failover}台")
print(f"必要台数: {nodes}台（平常時の使用率 {future_rps / (nodes * node_max_rps):.0%}）")

この入力では、現在のピーク50.0件、12か月後のピーク約71.3件となり、平常時条件で3台、1台停止条件で4台、必要台数は4台です。月3%の伸びは1年で約1.43倍になります。伸び率を1ポイント変えるだけで台数が変わることがあるため、入力値の出どころ（ログの集計期間、試験の日付）を見積書に残してください。

余裕率の決め方と平常時の使用率上限を70%前後に置く性能面の理由

余裕率は「なんとなく2割」ではなく、応答時間の伸び方と障害時の残り能力から決めます。上のスクリプトで平常時と1台停止時の2条件を分けているのは、この2つが別の理由で効くからです。

使用率が上がるほど待ち時間が急増する待ち行列の性質と性能目標値

窓口が1つの単純な待ち行列モデル（M/M/1）では、平均応答時間は「処理時間÷（1−使用率）」で表されます。処理時間が0.1秒の場合、使用率ごとの応答時間は次のとおりです。

使用率	平均応答時間	処理時間に対する倍率
50%	0.20秒	2倍
70%	約0.33秒	約3.3倍
80%	0.50秒	5倍
90%	1.00秒	10倍

70%から90%への20ポイントで、応答時間は3倍に伸びます。実際のサーバーは複数のCPUで並列に処理するため曲線はもう少し緩やかですが、高い使用率で急に遅くなる性質は同じです。平常時の上限を70%前後に置くのは、予測の外れや一時的な山を受け止める幅をこの曲線の手前に残すためです。

N+1冗長で1台停止時にも残りの台数で捌けるかを確かめる計算

もう1つの条件は障害時です。4台で回していて1台が止まれば、残り3台に負荷が寄ります。平常時70%で回していた構成なら、3台に寄った時点で約93%になり、上の表の曲線では応答時間が大きく伸びる領域に入ります。

そこで、1台停止時に85%以内へ収まる台数を別に計算し、平常時条件と比べて多いほうを採ります。止まってよい台数と稼働率の関係は稼働率の計算と高可用性の設計を扱った記事で確認できる内容です。複数のアベイラビリティゾーンに分けて置く場合は、1台ではなく1ゾーン分が止まる前提で同じ計算をします。

増設のリードタイムとオートスケールの立ち上がり時間を余裕に含める

KubernetesのHorizontal Pod Autoscalingのドキュメントによると、必要なレプリカ数は「現在のレプリカ数×（現在のメトリクス値÷目標値）」の切り上げで決まり、判定は既定で15秒ごとに行われます。判定から新しいPodが要求を受けられるまでには、イメージの取得やアプリの起動時間が加わります。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 4             # 見積もりで出した台数を下限にする
  maxReplicas: 12            # DB接続数の上限から逆算した上限
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70   # 見積もりの平常時上限と揃える

見積もった台数をminReplicasに入れておけば、伸縮の判定が追いつく前の数十秒も計画どおりの能力で受けられます。maxReplicasはデータベースの接続数から逆算した値にしてください。EC2のAuto Scalingで同じ設計をするときの事前準備はAWSでアクセス集中対策を設計する手順の記事にまとめています。オンプレミスで機器を購入する構成なら、発注から設置までの数か月を見積もり期間に含めます。

受託開発でキャパシティプランニングを作り込む条件と既定の自動伸縮で足りる場面

ここからは判断です。すべての案件で見積書を作り込む必要はありません。次のどれかに当てはまるシステムでは、計算の根拠と入力値を非機能要件として文書に残します。

ピークの日時が決まっている：チケット発売、受付開始、年度末の締め処理など、数分で平常の10倍以上が来る
自動では増やせない資源が先に尽きる：データベースの書き込み、ライセンス数で上限が決まるミドルウェア、外部APIの呼び出し上限
オンプレミスや予約購入で台数を前もって固定する：増設に数週間から数か月かかる
止まると売上や業務が止まる：決済、受発注、医療や物流の現場業務

逆に、利用者が数百人規模の社内ツールで、伸びが緩やかなシステムは、クラウドの自動伸縮と監視のしきい値だけで十分です。この場合は負荷試験で1台の上限を1回測り、上のスクリプトで台数を確かめる程度にとどめてください。精密な予測モデルを作っても、入力の誤差のほうが大きく、手間に見合いません。

見積もりを監視と四半期ごとの見直しに落とし込む継続運用の設計

見積もりは作った時点から古くなるものです。前章のpredict_linearで予測したピークが計画の上限に近づいたら通知し、四半期ごとに実測のピークと見積もりの差を確かめる運用にしておくと、慌てて増設する事態を避けられます。大きなキャンペーンや機能リリースの前には、その都度見積もりをやり直します。

予測の外れ方は、データベースの設計やネットワーク構成と絡み合うため、アプリの開発と同じ担当で見るのが手戻りの少ない進め方です。基盤の設計から負荷試験、監視の組み込みまでまとめて任せたい場合は、一創のインフラ構築（AWS・Google Cloud・Azure）で、見積もりの前提づくりから相談できます。

よくある質問

キャパシティプランニングの進め方について、検索で多い質問に答えます。

キャパシティプランニングとキャパシティ管理の違いは何ですか？

キャパシティプランニングは、将来の需要を予測して必要な資源量を決める計画の工程です。キャパシティ管理は、ITILなどの運用の枠組みで使われる言葉で、計画に加えて使用状況の監視、性能の調整、需要の調整までを継続的に回す活動全体を指します。実務では、見積もりを作るのがプランニング、作った見積もりと実測を比べて直し続けるのが管理、と分けて考えると整理しやすくなります。

余裕率は何パーセントを目安にすればよいですか？

固定の正解はありませんが、平常時のピークで使用率70%前後、1台停止時でも85%以内という2条件を出発点にすると、応答時間の急な悪化を避けられます。ピークの予測が外れやすい新規サービスや、数分で負荷が跳ね上がる受付開始型のシステムでは、平常時の上限を50〜60%まで下げる設定にしてください。逆に伸びが安定した社内システムなら、自動伸縮と組み合わせて70%台後半まで上げても回ります。

新規システムで過去のデータが無い場合はどう見積もりますか？

類似サービスの実績、想定利用者数と業務フローから1人あたりのリクエスト数を積み上げる方法、限定公開のパイロット運用で実測する方法の3つを組み合わせます。Azureの容量計画ガイドも、新しいワークロードでは市場調査や専門家の判断、パイロットの結果を予測の入力にするよう挙げています。最初の見積もりは誤差が大きい前提で、公開後1か月の実測で必ず作り直してください。

クラウドのオートスケールがあればキャパシティプランニングは不要ですか？

不要にはなりません。自動伸縮が増やすのはアプリケーションサーバーの台数で、データベースの書き込み能力、接続数、クラウドのアカウント単位の上限は自動では広がらないからです。立ち上がりまでの数十秒から数分の間は、既存の台数で受ける必要もあります。見積もりで出した台数を最小台数に、データベースの上限から逆算した値を最大台数に設定すると、自動伸縮が計画の範囲内で動きます。

負荷試験とキャパシティプランニングはどちらを先に行いますか？

需要の予測を先に作り、負荷試験はその後に行います。ピーク時に毎秒何件が来るかが分からないと、試験でどこまで負荷を上げればよいか決められないためです。負荷試験の役割は、1台あたりの上限とボトルネックになる資源を実測し、見積もりの分母を確定させることにあります。試験の結果で台数が変わったら、見積書の入力値を更新して計算し直してください。