【プロ直伝】サーバーサイジングは「未来」で決まる。経営層を納得させる計算式と根拠

2026年2月14日

18年のキャリアで数々の「修羅場」を潜り抜けてきたインフラエンジニアのもっちです。

若手リーダー（3〜5年目）の皆さん、サーバーのスペックを決めるとき、根拠を論理的に説明できていますか？「なんとなく多めに」というサイジングは、オンプレミスならコストの無駄、クラウドなら予算承認の壁に突き当たります。

今回は、私が現場で実際に使っている「CPU・メモリ・ディスク」の計算式と、失敗から学んだ「未来を織り込む」思考法を詳しく解説します。

この記事の想定読者

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

環境別：サイジングの設計思想

まず、ターゲットとなる環境によって、サイジングの「重み」が異なることを理解しましょう。

環境	設計思想	リスクへの考え方
オンプレミス	最大値設計（一発勝負）	拡張が困難なため、5年間のピークを想定して過剰気味に積む。
仮想環境	リソース共有と柔軟な拡張	物理の空きを見つつ、必要に応じて「後から足す」保険をかける。
クラウド	動的最適化（Right Sizing）	厳密な計算より「運用しながらの最適化」を重視。ただし予算説明の根拠は必須。

クラウド時代になり、サイジングの重要性が低下したと言われることもありますが、それは半分正解で半分間違いです。

「なぜその予算が必要なのか」を経営層に説明するアカウンタビリティ（説明責任）は、どの環境でもエンジニアの必須スキルだからです。

ここからは具体的な計算式を紹介しますが、その前に大切なことがあります。それは、「数式に代入する数値（リクエスト数やデータ量など）の妥当性」です。

正確な入力値を顧客から引き出すための具体的な質問項目については、まずこちらの記事で整理することをおすすめします。

CPUは「瞬間的な処理能力」を基準に計算します。

必要コア数=⌈目標利用率ピーク時リクエスト数/秒×1リクエストあたりの処理時間×安全率⌉

ピーク時リクエスト数/秒： 平均ではなく、スパイク時（キャンペーンや始業時など）の最大値を採用します。
目標利用率： 100%を目指してはいけません。待ち行列理論上、利用率が80%を超えるとレスポンスが急激に悪化するため、「70%〜80%」を上限に設計します。
安全率： 将来のプログラム改修やOSの負荷増を見越し、1.2〜1.5倍程度を見込みます。

メモリは「足りなくなったら即、システム停止」に直結します。

合計メモリ容量=(OS・エージェント+ミドルウェア+アプリヒープ領域)×安全マージン

【私の失敗談：メモリ増設の代償】 アプリの機能追加によるメモリ消費増を見落とし、本番稼働後にメモリが枯渇。仮想環境だったので緊急増設で凌げましたが、調整と作業で数日間、生きた心地がしませんでした。

ディスクは「今」ではなく「数年後」の姿を見ます。

必要ストレージ容量=(システム領域+現在のデータ量+(月間データ増加量×運用月数))×1.2

【私の失敗談：DB表領域の枯渇】 DBの「表領域（Tablespace）」の伸びを「点」でしか見ておらず、新規割当領域が突然パンクしました。かつて、ログの保持期間を曖昧にしたまま運用を開始し、ディスクがパンクしかけた苦い経験もあります。

サイジングで最も重要な思考法は、「現状のスペック（点）」ではなく「ビジネスの成長（線）」を設計に織り込むことです。

過去の統計データだけを見てサイジングするのは危険です。なぜなら、エンジニアが知るべき情報は「未来」にあるからです。

これらの情報を引き出すには、聞き方よりも「場」の設定が重要です。

若手リーダーにぜひ実践してほしいのが、サイジングを「自分一人の責任」にしないという戦略的アプローチです。

「誰に」確認するか： 担当者レベルではなく、必ず経営層（またはプロジェクト責任者）に将来の計画を確認してください。担当者は「目の前の仕様」に、経営層は「将来の投資」に責任を持っているからです。
「どこで」合意するか： 個別メールではなく、全体会議などの「オフィシャルな場」で、サイジング方針を公式に説明してください。
「エビデンス」を残す： 「経営層と合意した事業計画に基づき、このスペックを選定した」という事実を議事録に残しましょう。予測が外れることはあります。その際、それが「エンジニアのミス」ではなく「事業の成長に伴うリサイズ」という前向きな議論になるよう、防衛線を張っておくのです。

会議で経営層を納得させるための具体的なヒアリング項目の参考として、以下の記事にIPAによる「非機能要件グレード」シートをへのリンクを入れているので、参考にしてください。