「クラウドは安い」は本当か｜顧客に説明するコストの現実

「クラウドにすれば安くなるんですよね？」——二次請けでいちばん多く聞かれる問いです。答えは「条件次第、何もしなければ上がることもある」。安くなる／ならないの構造と、コストを下げるレバー、そして顧客に過剰約束しないための正直な説明の仕方を、現場目線で整理します。

01「クラウドにすれば安くなるんですよね？」

二次請けで移行案件をやっていると、顧客からいちばん多く聞かれるのがこの一言です。期待を込めて聞かれるので、こちらも「はい、安くなります」と言いたくなる。でも正直に答えるなら、「条件次第です。何もしなければ、むしろ上がることもあります」——これが現場の実感です。

期待と現実にギャップが生まれる理由ははっきりしています。クラウドの料金は「使った分だけ」です。ところがオンプレの発想のまま——余裕を持って大きめに買い、24時間つけっぱなしにする前提で——同じ構成を移すと、「使っていない分」まで従量で払い続けることになります。クラウドが本質的に効くのは「変動する」「不要なときは止められる」ワークロード。固定・常時フル稼働は、実はオンプレや専用機の土俵でもあります。

02何と比べて「安い」のか — TCOで並べる

「クラウドにしたら高くなった」と言う人の多くは、クラウドの利用料と、オンプレの利用料（電気代のような直接費）だけを比べています。これは家賃だけを見て「持ち家より高い」と言うようなもので、比較になっていません。

オンプレの本当のコストはTCO（総所有コスト）です。目に見える利用料の裏に、次のような費用が隠れています。

• ハード購入・減価償却——サーバ／ストレージ／ネットワーク機器の初期投資
• 保守・故障対応——保守契約、部品交換、深夜の駆けつけ
• データセンター・ラック・電力・空調・場所——意外に大きい固定費
• 回線・ソフトウェアライセンス
• 運用・監視の人件費——ここがいちばん見落とされます
• 数年ごとの機器更改と、それに備えた余剰キャパの空押さえ

クラウドはこれらの多くを利用料に内包し、4〜5年ごとにやってくる機器更改の山谷を平準化します。オンプレは「更改のたびに大きな一括投資を判断する」世界で、その意思決定コストとリスク（読み違えて過大投資／過小投資になる）も、実はTCOの一部です。クラウドはそこを月々の変動費に置き換えます。だから比較するなら、クラウドの利用料と並べるべきはオンプレのTCO全体です。同じ範囲・同じ期間でそろえて初めて、公平な土俵になります。

とくに運用の人件費は台帳に「サーバ費用」として現れないため、比較から抜け落ちがちです。監視、パッチ当て、バックアップ確認、深夜のアラート対応——これらは人の時間で払っているコストで、マネージド化で減らせる余地でもあります。TCOに計上しないと、クラウド側の「運用が楽になる」という価値がまるごと見えなくなります。

03安くなりにくい3つのケース

TCOで並べても、それでも安くなりにくい——むしろ上がる——典型パターンがあります。共通するのは「クラウドの弾力性を使わず、オンプレの弱点だけ持ち込む」ことです。

• ① 塩漬けのリフト&シフト——オンプレの構成をそのまま、スペックも冗長化もそのまま移す。弾力性を一切使わないので、オンプレの割高な部分だけがクラウドに引っ越してきます（詳しくは「とりあえずリフト&シフト」の代償）。
• ② 常時フル稼働・定常負荷——予測可能で止まらない24時間365日のワークロードは、従量課金の旨味が出にくい領域です。クラウドの強みは「変動への追従」であって、平坦な負荷は必ずしも得意分野ではありません。
• ③ 過剰スペック——オンプレは「余裕を持って大きめに」買う文化があります。それを同スペックのまま移すと、使っていないCPU・メモリの分まで、毎月従量で払い続けることになります。

加えて、データ転送量（特に外向きの通信）や、マネージド以外の細かなサービスの積み上げも、見積り時に読み切れず後から効いてきます。オンプレでは「回線を引いてしまえば中の通信は気にしない」感覚だったのが、クラウドでは通信の向きと量が費目になる。ここは設計時の発想の切り替えが要る部分で、後から気づくと構成の作り直しになります。

04コストを下げるレバー

では、どうやって下げるか。クラウドにはオンプレにはなかったレバーがいくつもあります。順に整理します。

right-sizing（適正化）：オンプレ由来の「大きめ」を、実際の使用率に合わせて落とす。CPU・メモリの実測を見て、段階的に。ここが最も素直に効きます。

不要リソースの停止・削除：開発／検証環境を夜間・休日に止める。使っていないEBSボリューム、古いスナップショット、未アタッチのIPを掃除する。「使っていないものを止められる」こと自体がクラウドの本質的なレバーで、オンプレでは物理的にできなかったことです。

マネージド化：データベースやコンテナ実行基盤などをマネージドサービスに寄せ、パッチ・バックアップ・冗長化の運用工数を減らす。利用料だけ見ると割高に見えることもありますが、人件費（TCO）まで含めると効いてくるのがポイントです。

購入コミット（RI・Savings Plansの考え方）：常に動いている定常分を「一定期間使い続ける前提でコミットし、オンデマンドより単価を下げる」仕組みです。勘所は「まず数か月の実使用を見て、動かない土台の部分だけコミットし、変動分はオンデマンドで残す」こと。割引の度合いは条件で変わるので、ここでは考え方にとどめ、実データで試算します。

ストレージ階層：アクセス頻度の低いデータを低頻度・アーカイブ階層へ、ライフサイクルで自動的に移す。ログや過去データなど「置いておくが滅多に読まない」ものに効きます。

これらを回す前提として、コストが「誰の・何の費用か」見える状態を作っておくことも大切です。タグ付けのルールを最初に決め、環境（本番／検証）やサービス単位で費用を分解できるようにしておく。見えないコストは下げられません。オンプレの「全部まとめて情シスの固定費」から、使った人・使ったものに費用が紐づく世界への移行でもあります。

05"移行の隠れコスト"を織り込む

ランニングの話ばかりしてきましたが、移行そのものにかかるコストを見落とすと、投資回収の絵が崩れます。二次請けの実感として、ここがいちばん読み違えられます。

• 移行工数——現状把握（アセスメント）、設計、検証、切替。とくに検証と切替は、想定より膨らみます。
• 二重運用期間——オンプレとクラウドを並行で動かす期間は、両方のコストが同時に乗ります。ここが長引くほど「安くなるはずだった」が消えていきます。
• 学習コスト——チームのスキル習得、運用体制の作り直し、監視・デプロイのツール変更。人が慣れるまでの生産性低下も見えないコストです。
• アプリ改修——塩漬けにできない部分の作り替え、データ移行、回線の手当て。

二次請けの立場だと、この移行工数がいちばん値切られやすい部分でもあります。「移すだけでしょう」と言われがちですが、現状のドキュメントが古い・依存関係が不明・止められない業務がある——といった現場のリアルは、たいてい見積りの前提を超えてきます。だからこそアセスメント（現状把握）に手を抜かない。ここでの読み違えが、後工程の炎上に直結します。

06顧客への正直な説明の仕方

ここまでを踏まえて、顧客にどう説明するか。結論は「過剰約束をしない」——これに尽きます。

私がよく使う言い方はこうです。「今のまま移すと、短期はむしろ上がることが多いです。ただしTCOで見れば、機器更改・運用・人件費のところで回収でき、最適化を続ければ下げていけます」。断定せず、しかし逃げず、構造で話す。これがいちばん揉めません。

説明の前に、前提を3つそろえておくと話が噛み合います。

• 何と比べるか——現行オンプレのTCO（利用料だけでなく人件費・場所・更改まで）
• いつの時点で見るか——初年度は移行費が乗る。3年・5年のスパンで見るか
• 最適化を前提にするか——塩漬けのままか、レバーを回した後か

そして数字は、当てずっぽうの割引率ではなく、顧客自身の請求・台帳データで作る。ここを曖昧なパーセンテージで語ると、その瞬間に信頼を失います。コスト以外の価値——俊敏性、拡張性、可用性、機器更改リスクの解消、BCP——も並べて、総合で意思決定してもらうのが筋です。可用性の価値を金額感でつかむには、ダウンタイムコスト・SLA計算ツールのような道具も使えます。

07まとめ — 「勝手に安くなる箱」ではない

クラウドは「置けば勝手に安くなる箱」ではなく、「安くできる余地が大きい仕組み」です。余地を現金化するには、TCOで正しく比較し、レバーを回し続け、移行コストを織り込み、顧客には構造で正直に説明する——この4つが要ります。

EMWは二次請けとして、移行の設計・構築から運用のコスト最適化（FinOps）まで、実務で回してきました。「クラウドにしたら本当に安くなるのか」を、御社の現行データをもとに、TCOと投資回収の絵で一緒に検証します。過剰約束はしません。下げられるところと、下げにくいところを、正直にお示しします。

08よくある質問（FAQ）