サーバーサイジングの計算式とスペック目安一覧｜現役18年プロの設計根拠

2026年2月14日2026年9月26日

レベル別記事一覧

▼▼▼まずはここからチェック！

あわせて読みたい

【必読ガイド】おすすめ記事：スキル別ロードマップ私は現在、大手SIerで18年間、インフラエンジニアおよびサービスマネージャーとして、止まることが許されない200台規模のシステムを支えています。このブログでは、私...

「新しく構築するWebサーバー、CPUは何コアにする？」「メモリは64GBで足りる？それとも128GB積むべき？」

設計構築やリプレイス案件を担当した際、先輩や顧客から「なぜそのスペックにしたの？」と根拠を問われ、言葉に詰まってしまった経験はありませんか？

「なんとなく多めに積んでおけば安心」というサイジングは、オンプレミスならコスト超過で却下され、クラウドなら毎月の予算承認の壁に突き当たります。

今回は、18年間にわたり数々の修羅場を潜り抜けてきた筆者が、現場で実際に使っている「CPU・メモリ・ストレージ・RAID・NIC」の具体的な計算式、代入例、スペック目安一覧を余すところなく解説します。

この記事の想定読者

初めてサーバー選定や見積もりの主担当・リーダーを任された若手エンジニア
スペック選定の根拠を問われ、「なんとなく」の回答しかできず悩んでいる方
経営層や顧客への説明・予算確保を論理的に通したいプロジェクト担当者

この記事を読むことでのメリット

現場で即座に使える「CPU・メモリ・ストレージ」の計算式と代入例が手に入る
実務で迷わない「スペック選定の目安（早見表）」で手戻りをゼロにできる
障害を防ぐ「未来予測」と、組織として合意を取る「戦略的な立ち回り」がわかる

この記事の音声解説を聞く

【早見表】サーバーサイジングのスペック目安一覧（CPU・メモリ・ディスク）

忙しい現場エンジニアのために、実務で標準的に使われるサイジングの判断基準を一覧表にまとめました。まずはこの数値をベースに検討をスタートしてください。

リソース	設計の目標値・目安	主な選定理由・根拠
CPU	ピーク時使用率 60%〜70%	監視閾値（80%）に引っかからない安全圏。スパイク耐性を確保。
メモリ	必要積算量＋ 30%以上のバッファ	枯渇すると即OS停止に直結。OS/ミドル更新余力とキャッシュ効果。
ストレージ容量	（将来予測容量）× 1.2〜1.3倍	ログ急増、DBインデックス再構築、パッチ適用時の一時領域を確保。
ストレージ種別	性能重視：SSD 容量・コスト重視：HDD	DBや仮想化ホストはSSD一択。長期ログ保管やバックアップは安価なHDD。
RAID構成	OS領域：RAID 1 データ領域：RAID 10 または 5/6	OSは可用性重視のミラーリング。データはI/O速度と対障害性のバランス。
NIC（回線）	ピーク帯域が上限の 60〜70%以下	通常通信だけでなく、夜間バックアップや大容量データ転送の帯域を考慮。

サーバーサイジングの基本：アプローチが違う「既存更改」と「新規構築」

サイジングに取り掛かる際、最初に確認すべきは「既存システムの更改（リプレイス）」なのか「完全新規のシステム構築」なのかという点です。ここを混同すると作業が迷走します。

【既存システムの更改】
過去の実績データ（CPU・メモリ使用率）を収集 → ピーク値を基準に維持・見直し

【新規システムの構築】
要件ヒアリング（同時アクセス・データ量） → 計算式で仮設計 → 負荷テストで検証・修正

① 既存更改：過去のモニタリング実績から逆算する

考え方は非常にシンプルです。過去のモニタリングデータ（月次運用レポートやZabbix/Datadog等のグラフ）を確認し、「通常時の平均」と「スパイク時のピーク値」をベースに判断します。

具体例： 現行の「8コア・CPU使用率ピーク50%」のサーバーを更改する場合単純計算すると「実質4コア分」ですが、だからといって新サーバーを4コアに落としてはいけません。
4コアに削ると、同じ負荷が来ただけで使用率がほぼ100%に達し、突発的なスパイクで即座にパンクします。利用者が増える傾向にあるなら「8コア維持」、または仮想環境で後から柔軟に変更できる設計にします。

② 新規構築：仮設スペックを負荷テスト（JMeter）で検証する

実績データがない新規案件では、後述する計算式を使って「仮のスペック」を設計します。

ただし、数字を決めて終わりにしてはいけません。可能であれば検証環境を構築し、Apache JMeterなどで疑似負荷テストを実施して実際のCPU・メモリ消費を測定するのがプロの鉄則です。

💡 クラウド時代の「ライトサイジング」と初期見積もりの関係

「AWSやAzureなら後からスケールできるから、事前のサイジングは適当でいいのでは？」と言われることがあります。

しかし、それは半分正解で半分間違いです。後から変更できるのはクラウドの強みですが、プロジェクト開始時の「初期予算承認（月額いくらかかるのか）」を通すための説明責任（アカウンタビリティ）として、事前の論理的サイジングは依然として必須のスキルです。

【計算式＆具体例】実務で使えるサーバーリソースのサイジング根拠

ここからは、設計書や見積根拠にそのまま書けるリソース別の計算式と、現場ならではの具体的な代入例を解説します。

① CPUサイジング計算式：ピーク処理能力と目標利用率（60〜70%）

CPUは「瞬間的なトランザクションをいかに遅延なく処理できるか」で決めます。

【CPUの計算式】

\text{必要コア数} = \left\lceil \frac{\text{ピーク時秒間リクエスト数} \times \text{1リクエストあたりの処理時間(秒)}}{\text{目標CPU利用率}} \times \text{安全係数} \right\rceil

ピーク時秒間リクエスト数
平均アクセス数ではなく、キャンペーン開始時や始業直後などの「瞬間最大風速」を採用。
目標CPU利用率
60%〜70%（最大でも80%以下）。待ち行列理論上、利用率が80%を超えると処理待ちの行列が指数関数的に増大し、レスポンスが悪化します。また、一般的な運用監視のアラート閾値が「80%」であることが多いため、平常ピークでアラートが鳴らない状態をキープします。
安全係数
将来のプログラム改修やOS負荷増を見越し、1.2〜1.5倍を見込みます。

【実務での代入例】

ピーク時アクセス：50 req/sec
1リクエストの平均処理時間：0.1秒
目標CPU利用率：70%（0.7）
安全係数：1.3倍

\text{必要コア数} = \frac{50 \times 0.1}{0.7} \times 1.3 = \frac{5}{0.7} \times 1.3 \approx 7.14 \times 1.3 = 9.28 \rightarrow 10\text{コア}

小数点以下を切り上げ、サーバーの規格に合わせて「10コア（または余裕を持って12〜16コア）」を選定します。

あわせて読みたい

「CPU使用率は20%台なのに、なぜか処理が激重…」という現場トラブルに遭遇したことはありませんか？

その真因はシングルスレッド限界やディスクI/O待ちにあります。CPUの本当の負荷を見抜くための必須知識は以下の記事で図解しています。

あわせて読みたい

【図解】CPU使用率とロードアベレージの違い｜「低いくせに重い」真因と目安を解説インフラエンジニアとしてキャリアを積むと、必ず直面する「数字の矛盾」があります。「CPU使用率は低いのに、アプリケーションの応答が極端に遅い」「ロードアベレー…

② メモリサイジング計算式：安定稼働を積み上げる「キリ番」の法則

メモリは「足りなくなったら即、システム停止（OOM Killer発動やクラッシュ）」を招くため、最も安全側に倒して見積もる必要があります。

【メモリの計算式】

\text{合計メモリ容量} = \left( \text{OS・管理エージェント} + \text{ミドルウェア} + \text{アプリ専有領域} \right) \times \text{安全マージン}

OS・管理エージェント
OS本体（Windowsなら4〜8GB、Linuxなら2〜4GB目安）＋監視・バックアップ用エージェント。
ミドルウェア
Webサーバーのプロセス数 × プロセスサイズ、DBのバッファプール（InnoDB Buffer Pool等）。
アプリ専有領域
JavaのJVMヒープ領域など、アプリケーションが固定で確保する領域。

【実務での代入例】

OS＋エージェント：4GB
ミドルウェア（Web/DBキャッシュ）：8GB
アプリヒープ領域：16GB
安全マージン：1.3倍

\text{合計メモリ容量} = (4 + 8 + 16) \times 1.3 = 28\text{GB} \times 1.3 = 36.4\text{GB}

現場の勘所：キリの良い上位スペック（64GB）を選ぶ

計算結果が「36.4GB」になった場合、40GBや48GBでギリギリ設計するのは避けるべきです。

OSやミドルウェアの将来のバージョンアップで消費量が増加することや、空きメモリがOSのファイルキャッシュ（buff/cache）として機能しディスクI/Oを劇的に高速化することを考慮し、一段上の「64GB」を選定するのが現場のスタンダードです。

【私の失敗談：メモリ増設の代償】

かつてアプリの機能追加によるメモリ消費増を見落とし、本番稼働直後にメモリが枯渇。仮想基盤だったため緊急のオンライン増設でなんとか凌ぎましたが、深夜の緊急調整と顧客への障害報告書作成で、数日間生きた心地がしませんでした。

あわせて読みたい

「メモリ使用率80%超え＝危険」とは限りません。本当に危険なSWAP（ページング）の兆候と、現場で慌てないための監視術を徹底解説しています。

あわせて読みたい

メモリ使用率80%で慌てない！歴18年のプロが教える「SWAP・ページング」の本質と現場の監視術（Linux/Wi… インフラエンジニアとして18年、200台規模の仮想化基盤や多種多様なシステムを運用してきましたが、若手から最も多く受ける相談が「メモリ使用率が高いので、すぐ増設が…

③ ストレージ容量計算式：5年後の蓄積とSSD/HDDの使い分け

ストレージは「容量」だけでなく、「アクセス速度（I/O）」もセットで考えます。

【ストレージ容量の計算式】

\text{必要ストレージ実容量} = \left( \text{OS・システム領域} + \text{現在データ量} + (\text{月間データ増加量} \times \text{運用月数}) \right) \times 1.3

月間データ増加量
月間のレコード純増分、添付ファイル・画像アップロード量、ログの肥大化ペース。
運用月数
ハードウェアの保守期間（一般的な5年更改なら「60ヶ月」）。
安全マージン（1.3倍）
ログの急増、DBのインデックス再構築用の一時領域、OSパッチ適用時のスナップショット領域として最低30%の余力を確保します。

【実務での代入例】

OS・システム領域：100GB
初期データ量：200GB
月間増加データ量：20GB
運用期間：5年（60ヶ月）

\text{必要実容量} = \left( 100 + 200 + (20 \times 60) \right) \times 1.3 = (300 + 1,200) \times 1.3 = 1,500\text{GB} \times 1.3 = 1,950\text{GB (約2TB)}

SSDとHDDの使い分け基準

SSD（NVMe / SAS SSD）ランダムアクセスに圧倒的に強い。DBサーバー、仮想化基盤のデータストア、高頻度アクセスのあるWeb/APサーバーには必須。
HDD
容量単価が安い。syslogなどの長期ログ保管サーバー、日次バックアップデータの退避先など、アクセス頻度が低い大容量用途に限定して採用。

【私の失敗談：DB表領域のパンク】

DBの「表領域（Tablespace）」の自動拡張設定を過信し、ファイルシステム側の残容量監視を甘くしていたため、深夜のバッチ処理中にディスクが100%になりDBが緊急停止したことがあります。ストレージサイジングは「一時領域」と「ログのローテーション設計」まで見通すことが肝要です。

④ RAID構成の選定基準：OS（RAID 1）とデータ（RAID 10）の鉄則

ストレージ容量を計算したら、物理ディスクをどう束ねるか（RAID構成）を決めます。実務での選定基準は極めてシンプルです。

RAID種別	特徴	実効容量	実務での採用方針
RAID 1（ミラーリング）	2台に同一書き込み。障害に強い	ディスク1本分	OS・システム領域（容量は不要、可用性最優先）
RAID 10（1+0）	高速・高信頼・高コスト	構成台数の 1/2	DB/APデータ領域（性能と対障害性を両立させる本番環境の王道）
RAID 5 / 6	パリティ利用で容量効率が高い	台数 – 1 (RAID 5) 台数 – 2 (RAID 6)	ファイルサーバー、ログ保管庫、バックアップ領域

実務では、1台のサーバーの中でも「OS領域はSSDのRAID 1」「DB/APデータ領域はSSDのRAID 10」というように、用途ごとにボリュームを分けて構成するのが定石です。

あわせて読みたい

なぜエンタープライズの現場ではRAID 10が圧倒的に支持されるのか？
各RAIDの仕組みと実務での使い分け基準はこちらの記事で解説しています。

あわせて読みたい

現役エンジニアが教えるサーバーRAID選び方｜なぜ現場はRAID10一択なのか「サーバーのストレージ構成、RAID 5でいいですよね？」現場で若手エンジニアやお客様からよく受ける質問です。しかし、18年インフラ運用に携わってきた私の答えは「要…

⑤ ネットワーク（NIC）と電源の冗長化設計

見落とされがちですが、インフラの可用性を担保する生命線がネットワークと電源です。

1Gbps vs 10Gbpsの判断基準
平常時100Mbps、ピーク300Mbps程度のWebトラフィックであれば1Gbps NICで十分です。しかし、「深夜のフルバックアップで数TBのデータを短時間で転送する」「ストレージ専用ネットワーク（iSCSI等）を束ねる」といった要件がある場合は、迷わず10Gbpsを選定します。
NICの冗長化（チーミング/ボンディング）
本番サーバーではNICの1本挿しは厳禁です。最低2ポートを搭載し、アクティブ/スタンバイ構成、またはリンクアグリゲーション（LACP）で束ねて冗長化と帯域確保を両立させます。
電源ユニットの二重化
業務用サーバーは電源ユニットを2基搭載（大規模機では4基）し、電源AはUPS系統Aへ、電源BはUPS系統Bへ接続。データセンター内の給電回路レベルで物理的に分離するのが基本です。

【実践シミュレーション】中規模Web/DBシステムのサイジング例

ここまでの計算式を統合し、実務でよくある「会員数10万人規模の社内業務システム（Web＋DB分離構成）」を例にサイジングを組み立ててみましょう。

前提条件

会員数：10万人、ピーク時同時アクセス：約500人
DB初期データ：100GB、年間データ増加：50GB
ハードウェア保守期間：5年運用

【サイジング試算結果と選定スペック】

■ Web/APサーバー（2台構成：ロードバランサー配下）
  ・CPU: 8コア / 16スレッド（1台障害時の片肺運転でも耐えられる余裕を確保）
  ・メモリ: 32GB（同時接続プロセス数 ＋ OSファイルキャッシュ用）
  ・ストレージ: RAID 1（SSD 480GB × 2本 / OS・アクセスログ用）
  ・NIC: 1Gbps × 2ポート（チーミングによる冗長化）

■ DBサーバー（Active / Standby HAクラスタ構成）
  ・CPU: 16コア / 32スレッド（複雑な集計クエリや並行トランザクションに対応）
  ・メモリ: 64GB（InnoDBバッファプールを40GB以上確保しディスクI/Oを極小化）
  ・ストレージ（OS領域）: RAID 1（SSD 480GB × 2本）
  ・ストレージ（DBデータ領域）: RAID 10（SSD 960GB × 4本 / 実効容量 約1.9TB）
      ※ 計算根拠: 初期100GB ＋ (50GB × 5年) ＝ 350GB
      ※ 350GB × 安全マージン1.3 ＝ 約455GB。RAID10(1.9TB)で将来のログ・一時領域も完全担保
  ・NIC: 10Gbps × 2ポート（データ同期レプリケーションおよび夜間バックアップ用）

想定外のスパイクに備える「スケールアップ」と「スケールアウト」

サイジングは未来予測である以上、テレビ報道やSNSのバズなどによる「想定外のトラフィック」を100%防ぐことは不可能です。パンクした際の逃げ道もあらかじめ設計に盛り込んでおきましょう。

スケールアップ（垂直拡張）
CPUコア数やメモリ容量を物理的・仮想的に増強する手法。DBサーバーなど、単一サーバーでデータの一貫性を保つ必要がある層に適しています。
スケールアウト（水平拡張）
ロードバランサー配下に同スペックのサーバーを複数台並べる手法。WebサーバーやAPIサーバーに適しており、突発的なアクセス増にも柔軟に台数を増やして対応できます。