インフラDDは「今のコスト」だけでなく「スケール時のコスト推移」と「運用の持続可能性」を評価するプロセスです。M&A後にクラウドコストが予想の3倍に膨らみ、統合後の利益計画が大幅に狂った——こうした事例は、初期のコスト構造しか見ないDDの代償です。本記事では、コスト・スケーラビリティ・運用体制の3軸を短期間で評価するための手法、チェックリスト、スコアリングフレームワークを整理します。
インフラDDで評価する3つの軸
インフラDDは3つの軸で構成されます。第一にコスト構造です。月次のクラウド請求だけを見るのではなく、ユーザー単価、リザーブド活用率、アイドルリソース率、そしてスケーリングカーブ(将来コスト推移)を評価します。第二にスケーラビリティで、将来のトラフィック増加に対して現在のアーキテクチャが耐えられるかを評価します。第三に運用体制で、SRE/インフラチームの成熟度、監視、DR/BCPの実効性を評価します。
3軸のどれを欠いてもインフラDDは片手落ちになります。コストだけ見て「クラウド費用は売上の5%で健全」と判断しても、ユーザーが倍増した瞬間に15%に跳ね上がる設計かもしれません。スケーラビリティだけ見て「技術的には対応可能」と判断しても、実運用できる人材がいなければ机上の空論です。
| 評価軸 | 主な評価項目 | 投資判断への影響 | 典型的なリスク |
|---|---|---|---|
| コスト構造 | 月次推移、単価、最適化余地 | P/L直撃 | 想定外のコスト増 |
| スケーラビリティ | 水平拡張、ボトルネック | 成長計画の実現可否 | サービス停止、機会損失 |
| 運用体制 | SRE、監視、DR/BCP | PMI実行可能性 | 障害対応遅延、離職 |
クラウドコストの分析手法
クラウドコスト分析の出発点は、月次推移と内訳の把握です。直近12ヶ月の月次請求を、サービス別(EC2/EKS、S3、RDS、データ転送等)に分解し、どの項目が全体の何割を占めているかを可視化します。次に、売上やトラフィックに対するコスト比率を算出し、同業他社や業界ベンチマーク(一般にSaaS企業ではクラウド費用が売上の5〜10%)と比較します。
最適化の余地を見る主要指標は、リザーブドインスタンス/Savings Plansの活用率、アイドルリソースの比率、スポットインスタンスの活用度です。長期稼働するワークロードにオンデマンド課金を使い続けている場合、30〜50%のコスト削減余地があることも珍しくありません。
最も重要なのはスケーリングカーブの評価です。ユーザー数が2倍になった時、コストは何倍になるかを試算します。線形(ユーザー2倍→コスト2倍)が理想ですが、アーキテクチャ次第で超線形(ユーザー2倍→コスト3倍)になることがあります。特にデータ転送量の多いサービス、マネージドDBで読み書きが集中するサービスは超線形になりがちです。
| 分析項目 | 確認方法 | 健全な水準 | 危険な兆候 | 改善余地の推定 |
|---|---|---|---|---|
| 月次コスト推移 | 請求書12ヶ月分 | 売上連動の増加 | 売上超過の急増 | 原因分解で10〜30% |
| サービス別内訳 | 課金ダッシュボード | 分散 | 単一サービスが50%超 | アーキ変更で20〜40% |
| ユーザー単価 | コスト÷アクティブユーザー | 業界ベンチ並み | 業界比2倍超 | 設計見直しで30% |
| RI/SP活用率 | コンソール確認 | 60%以上 | 30%未満 | 即20〜40%削減 |
| アイドル率 | CPU使用率 | 30%未満 | 60%超 | 即10〜30%削減 |
| データ転送コスト | 内訳確認 | 全体の10%未満 | 全体の30%超 | CDN活用で50% |
【コストスケーリングカーブの比較】
パターンA: 線形スケーリング(健全)
cost
|
| *
| *
| *
| *
| *
+-------------------> users
(ユーザー2倍でコスト2倍)
パターンB: 超線形スケーリング(危険)
cost
|
| *
| *
| *
| *
| *
| *
+-------------------> users
(ユーザー2倍でコスト3倍以上)
※ 超線形の原因は多くの場合、単一DBへの書込集中、
データ転送の最適化不足、キャッシュ層の欠如です。
スケーラビリティの評価
スケーラビリティ評価は、現アーキテクチャが将来のトラフィック増に耐えられるかを検証するフェーズです。水平スケーリング対応の有無、シングルポイント(単一DB、単一キャッシュ等)の存在、データベース層の拡張性が主要な観点です。
理想的には負荷テスト結果が既に存在し、現状の何倍までのスケールが検証済みかを確認できます。負荷テスト結果が存在しない場合、アーキテクチャ図とインタビューから理論上のスケール上限を推定します。
| # | 評価項目 | 確認方法 | 重要度 | リスク判定 |
|---|---|---|---|---|
| 1 | オートスケーリング設定 | IaC/コンソール確認 | 高 | 手動運用 |
| 2 | 水平スケール対応度 | アーキ図確認 | 高 | ステートフル多用 |
| 3 | DB層の拡張性 | 構成確認 | 高 | 単一マスタ依存 |
| 4 | キャッシュ層の有無 | 構成確認 | 中 | キャッシュなし |
| 5 | CDN活用 | 構成確認 | 中 | 未活用 |
| 6 | 非同期処理の分離 | 構成確認 | 中 | 同期一体型 |
| 7 | 負荷テスト実施履歴 | 結果確認 | 中 | 実施なし |
| 8 | ボトルネック特定 | APM確認 | 中 | 未特定 |
| 9 | データ分割戦略 | 設計書確認 | 中 | 戦略なし |
| 10 | スケール時のコスト試算 | 試算書確認 | 高 | 未試算 |
運用体制と成熟度の評価
運用体制の評価は、SRE/インフラチームの規模と役割、監視体制、障害対応プロセス、SLO/SLAの設定、IaCの導入率、DR/BCPの実効性を確認します。優れたアーキテクチャも、運用できる人材とプロセスがなければ机上の空論です。
特に注意すべきはSLO/SLAの実績との乖離です。99.9%の可用性を掲げていても、直近6ヶ月の実績が99.5%であれば、設計と運用の間にギャップがあります。IaCの導入率も重要で、インフラ変更が手動運用のみの組織は、変更時の事故率が高く、DRも実質機能しないことが多いです。
| # | 評価項目 | 確認方法 | 重要度 | リスク判定 |
|---|---|---|---|---|
| 1 | SRE/インフラチーム人数 | 組織図確認 | 高 | 1名以下 |
| 2 | 監視・可観測性ツール | 導入確認 | 高 | 未導入 |
| 3 | アラートの運用 | インシデント履歴 | 中 | アラート地獄 |
| 4 | SLO/SLAの設定 | 定義書確認 | 高 | 未設定 |
| 5 | 可用性の実績値 | 稼働率レポート | 高 | SLA違反常態化 |
| 6 | IaC導入率 | リポジトリ確認 | 中 | 手動運用 |
| 7 | CI/CDとの統合 | パイプライン確認 | 中 | 手動デプロイ |
| 8 | DR/BCP計画 | 計画書確認 | 高 | 計画なし |
| 9 | DR訓練の実施 | 訓練記録 | 中 | 未実施 |
| 10 | オンコール体制 | ローテーション確認 | 中 | 特定人物依存 |
インフラDDスコアリングシート
3軸を統合して総合スコアを算出します。各軸を100点満点で評価し、重み付け平均で総合インフラスコアを得ます。
| 評価軸 | スコア(100点) | 重み | 重み付け最大 |
|---|---|---|---|
| コスト構造 | 0〜100 | 40% | 40 |
| スケーラビリティ | 0〜100 | 30% | 30 |
| 運用体制 | 0〜100 | 30% | 30 |
| 合計 | – | 100% | 100 |
| スコア範囲 | リスクレベル | 推奨対応 | 推定改善コスト | PMI反映 |
|---|---|---|---|---|
| 80〜100 | 健全 | 継続運用 | 〜500万円 | 最適化余地の実現 |
| 60〜79 | 要注意 | 運用改善 | 500〜2,000万円 | 90日計画に織込 |
| 40〜59 | 要改善 | リアーキ検討 | 2,000〜8,000万円 | リプレイス計画 |
| 40未満 | 高リスク | 投資条件見直し | 8,000万円超 | バリュエーション調整 |
ベンダーロックインリスクの評価
特定クラウドベンダーへの依存度は、将来の選択肢を狭める要因です。評価項目はマネージドサービスの利用状況、独自APIへの依存度、マルチクラウド対応の可能性です。AWS Aurora、BigQuery、Azure Synapse等の独自マネージドサービスを多用している場合、他クラウドへの移行コストが跳ね上がります。
ロックインコストの定量化は、「他クラウドへ完全移行するとしたら何人月、いくら必要か」を試算することで行います。移行コストが年間クラウド費用の3倍を超える場合は高ロックインと判定するのが一般的な目安です。ロックイン自体は必ずしも悪ではなく、マネージドサービス利用による運用コスト削減がロックインコストを上回れば経済的には合理的です。問題は、その選択が意図的かどうかです。
まとめ——インフラは「見えないP/L」を持っている
クラウドインフラのコスト構造は、決算書の営業費用に埋もれがちな「見えないP/L」です。DDで可視化することで、買収後のP/L予測精度が格段に高まります。
- インフラDDはコスト・スケーラビリティ・運用体制の3軸で評価する
- コスト分析ではスケーリングカーブが最重要、超線形は即改善対象
- スケーラビリティは負荷テスト結果で検証、未実施なら理論上限を推定
- 運用体制はSLO実績とIaC導入率で成熟度を判定
- ベンダーロックインは「意図的か」が判断基準
DE-STKでは、インフラアセスメントを通じて投資判断とPMI計画の両方を支援しています。コスト最適化の即効性とスケーラビリティの中長期視点を両立した評価をお届けします。
よくある質問(FAQ)
Q1. インフラDDでは何を評価しますか?
クラウドコスト構造(月次推移、スケーリングカーブ)、スケーラビリティ(負荷耐性、ボトルネック)、運用体制(監視・障害対応・DR/BCP)の3軸を中心に評価します。3軸をバランスよく見ることで、買収後のP/L予測とPMI計画の精度が上がります。
Q2. クラウドコストのスケーリングカーブとは?
ユーザー数やトラフィックが増加した際にクラウドコストがどのように推移するかを示す曲線です。線形(ユーザー2倍でコスト2倍)が理想ですが、超線形(ユーザー2倍でコスト3倍以上)の場合はアーキテクチャの改善が必要です。単一DB依存、データ転送量の大きさが主な原因となります。
Q3. ベンダーロックインリスクはどう評価しますか?
マネージドサービスの利用率、独自APIへの依存度、他クラウドへの移行に必要な工数・コストを算出します。移行コストが年間クラウド費用の3倍を超える場合、高ロックインと判定するのが一般的です。ただしロックイン自体は悪ではなく、意図的選択であれば経済合理性があります。