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

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

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

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

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

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

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

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

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

実務で使えるリソース計算式と詳細根拠

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

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

① CPUサイジング：最大負荷を捌き切る

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

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

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

② メモリサイジング：安定稼働を積み上げる

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

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

• OS・エージェント/ミドルウェア： OS本体と、Webサーバのプロセス数やDBのバッファキャッシュを積み上げます。
• アプリヒープ領域： JavaのJVMヒープなど、アプリが専有する領域です。

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

③ ディスク容量サイジング：将来の蓄積を予測する

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

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

• 月間データ増加量： 月間のレコード増加数や、ユーザーのアップロードファイル量。
• 運用月数： ライフサイクル（例：60ヶ月）を掛け合わせます。

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

算出されたスペックは、詳細設計書のパラメータシートに『選定根拠』として記載しましょう。単に『16GB』と書くのではなく、この記事で導き出した計算プロセスを設計書に添えることで、レビューでの説得力が格段に増し、手戻りを防ぐことができます。

詳細設計書については以下の記事を参考にしてみてください。

「点」ではなく「線」で捉える：未来の情報を引き出すコツ

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

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

• 経営計画： 来期のユーザー獲得目標は？
• リリース計画： どんな重い機能が追加される予定か？

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

現場を救うリーダーの立ち回り：責任を組織で持つ

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

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

まとめ：計算式は「対話」のための共通言語

サーバーサイジングの計算式を学ぶことは、パズルを解くことではありません。

顧客や経営層に対し、「なぜこの金額が必要なのか」をプロとして説明し、信頼を勝ち取るためのツールです。

技術的な根拠（計算式）と、戦略的な立ち回り（エビデンス確保）。この両輪を回して、ビジネスを支える強いインフラを構築していきましょう。

---

サイジングは単なる計算作業ではありません。システムの信頼性を担保し、無駄なコストを抑えるという、インフラエンジニアとしての『誇り』に関わる仕事です。

こうした『守りの技術』をいかにして自分の価値（キャリア）に繋げていくか、私が18年の現場経験で感じたマインドセットについても、ぜひ一度読んでみてください。