クラウド移行費用とオンプレTCO比較2026｜内訳・逆転点・見積もりの読み方

結論から言うと、クラウド移行は「オンプレより安くなる」と先に決めつけて始めると、ほぼ確実に見積もりで揉める。 費用は「初期構築」「移行作業」「移行後の運用」の3層に分かれ、そのどこにいくらかかるかは、対象システム、可用性要件、データ量、通信量、運用を誰が担うかで大きく変わる。オンプレミスとの比較も、サーバー代だけを並べても意味がない。オンプレのTCO（総所有コスト）には、ハードウェアだけでなく電気・空調・設置スペース・保守契約・数年ごとのリプレース・運用人件費が隠れているからだ。この記事は、費用の内訳、3〜5年のTCO比較、どこでコストが逆転するか、移行方式ごとの費用差、隠れコスト、失敗パターン、そして最も差がつく「見積もりの読み方」までを、発注する側の実務目線で整理する。

この記事の内容は、AWSやMicrosoft Azureの公式移行情報など一次情報を参照しつつ、費用相場については各社コラムの記載レンジを二次情報として扱い、断定を避けて示す。相場の金額はあくまで幅であり、自社構成に当てはまる保証はない点を先に断っておく。

この記事の要点（先に結論）

• クラウド移行費用は「初期構築」「移行作業」「移行後の月額運用」の3層。見積もりはこの3つを分けて出させる。
• オンプレとの比較は「サーバー代」ではなく「3〜5年TCO」で行う。オンプレTCOには電気・空調・スペース・保守・リプレース・運用人件費が含まれる。
• 「クラウドは安い」は条件付き。常時フル稼働の重いシステム、大量のデータ転送（下り通信）、高い可用性要件がある場合、クラウドの方が高くつくことがある。
• 移行方式（リホスト＝リフト&シフト／リプラットフォーム／リファクタリング／SaaS化／廃止）で費用も効果も別物になる。安く早く終わるのはリホスト、長期のコスト最適化にはリファクタリングが必要。
• 予算超過の温床は「隠れコスト」。データ転送料、検証環境の消し忘れ、旧環境との並行稼働期間、ライセンス再購入、運用移管が代表格。
• 見積もりで確認すべきは「何を止められないか（復旧優先度）」「並行稼働期間」「移行後の運用範囲」。ここが曖昧な見積もりは後から追加費用が出る。

この記事を読むべき人

• オンプレのサーバー更改（リプレース）時期が近く、クラウド移行と現状維持のどちらが得か判断したい経営者・事業責任者
• ベンダーから出てきたクラウド移行の見積もりが妥当か、社内にIT判断力が乏しく不安な決裁者
• 「クラウドにすれば安くなる」と言われたが、本当にTCOで下がるのか第三者の目で検証したい方
• Windowsサーバーや古い業務アプリ、Access／Excel運用の老朽化に直面し、移行対象と費用の全体像を掴みたい情シス・兼任情シス

まず決めるべきは「金額」ではなく「何を止められないか」

費用を比べる前に、多くの企業が飛ばしてしまう工程がある。移行対象システムごとの「復旧優先度」と「停止許容時間」を決めることだ。ここを決めずに見積もりを取ると、ベンダーは安全側に倒して全システムを高可用構成で見積もるため、金額が膨らむ。逆に、止まっても困らないシステムまで一括で厚く移行しようとして、無駄な費用が乗る。

止められない基幹システムは、切り戻し手順・検証環境・並行稼働を厚く設計するため費用が上がる。一方、参照するだけの古いシステムや、ほとんど使われていないシステムは、移行せず「廃止」や「参照専用のアーカイブ化」で済む場合がある。移行対象を減らすこと自体が、クラウド移行の最大のコスト削減策になることは、あまり語られない。まずは対象を「止められない基幹／古いが必要なレガシー／SaaSに置き換えられる業務／廃止できる業務」の4つに仕分けるところから始めたい。

クラウド移行費用の内訳：初期・移行・運用の3層

費用を正しく比較するには、見積もりを3つの層に分けて捉える必要がある。各社のコラムでも呼び方は違うが、大きくは「移行前の設計」「移行作業」「移行後の運用」に整理できる。

多くのトラブルは、①と②だけを見て契約し、③の運用費と「移行が終わるまでの並行稼働期間の二重コスト」を見落とすことで起きる。移行中は旧オンプレと新クラウドの両方が動くため、その期間の電気代・保守費・クラウド料金が重なる。この並行期間を見積もりで何ヶ月と置いているかは、必ず確認したい。

オンプレミスのTCOに「隠れている」コスト

「オンプレは資産を持っているから安い」という感覚は、初期に買ったハードウェアの金額しか見ていないことが多い。実際のオンプレTCOは、購入費以外に継続的に出ていく費用の合計だ。BTNコンサルティングやウェブスピード等のコラム（二次情報）は、以下を「見落としやすいコスト」として挙げている。AWSの公式ブログも、オンプレと比較する際は「サーバーやストレージだけでなく、ラックやスイッチなどの周辺機器、人件費・施設費・電気・空調・ネットワーク・定期的なハードウェア更改まで、条件を揃えて算入する」ことを推奨している（一次情報）。

特に見落としが大きいのが運用人件費だ。兼任情シスが片手間で監視・障害対応をしている場合、その工数は帳簿に表れないためオンプレが安く見える。クラウドに移すと監視やパッチ適用の一部をマネージドサービスや外部委託に置き換えられるが、それは「見えていなかった人件費が費用として表面化する」ことでもある。安くなったのではなく、隠れていたコストが可視化されただけ、というケースは珍しくない。

費用相場の目安（二次情報・幅として読む）

相場は自社の構成で必ず変わるため、以下はあくまで各社コラムが示すレンジの目安として扱ってほしい。金額の断定ではない。

• 移行の初期・作業費：小規模で概ね数十万〜100万円台、中〜大規模で数百万円規模というレンジが各コラムで示されている。
• 移行後の月額運用料：小規模なら月数万〜十数万円、中小企業全体で月額数十万円〜という記載が見られる。
• 大規模移行：年間数千万円規模に達するとする記載もある。

重要なのは金額そのものより「なぜその金額なのか」を説明できるかだ。同じ「クラウド移行500万円」でも、リホストで最低限動かすだけなのか、リファクタリングして作り替えるのか、移行後1年の運用支援まで含むのかで中身は別物になる。相場との比較で高い・安いを判断するのではなく、見積もりの前提（範囲・方式・期間）を揃えて比べることが先だ。

3〜5年TCO比較：どこでコストが「逆転」するのか

クラウドが有利か不利かは、期間と使い方で入れ替わる。ここが競合記事であまり踏み込まれていない論点だ。一般論として整理すると、以下の傾向がある（構成依存であり保証ではない）。

クラウドは「使った分だけ課金」が基本のため、止められる環境を止め、負荷に応じて増減できる使い方をすると有利になる。逆に、オンプレと同じ「常時フルスペックで立てっぱなし」の使い方をそのまま持ち込むと、従量課金がむしろ割高になり、数年でオンプレのTCOに追いつく・逆転することがある。「リフト&シフトしたのに安くならない」の多くは、この“オンプレの使い方をそのまま持ち込んだ”ことが原因だ。TCO比較のシミュレーションは3年と5年の両方で作り、どの年で損益分岐（逆転）するかを見ておきたい。

移行方式（6R）と費用への影響

同じ「クラウド移行」でも、どの方式を選ぶかで費用も効果も別物になる。AWSやAzureの移行情報でも複数の移行戦略が案内されている（一次情報）。代表的な選択肢を、費用インパクトとあわせて整理する。

費用を抑えたいなら「まずリホストで移し、移行後にコスト最適化やリファクタリングを段階的に行う」二段構えが現実的なことが多い。ただし、古い業務アプリはリホストしても文字コード・帳票・バッチ実行時間・外部APIの相性で“そのままでは動かない”ことがある。リホストで足りるか刷新が必要かは、移す前の調査で決まる。ここを飛ばすと、移行の途中で想定外の改修費が発生する。段階的な進め方の設計は、レガシー刷新・移行の進め方を参照しながら、対象ごとに方式を割り当てていくのが安全だ。老朽化した個別システムが多い場合は、レガシーシステム刷新の観点で調査から入る方が、移行費用の見積もり精度が上がる。

予算超過の温床：隠れコスト一覧

見積もりの「移行作業費」だけを見て安心すると、後から次のコストが出てくる。NTT東日本やクラウド各社のコラム（二次情報）でも予算超過リスクとして指摘される項目だ。

• データ転送料（下り）：クラウドから外部へデータを出す通信は課金対象になりやすい。大量の帳票出力やバックアップ外部保管で積み上がる。
• 並行稼働の二重コスト：移行完了まで旧オンプレと新クラウドの両方を維持する期間の費用。
• ライセンスの再購入・持ち込み条件：OS・DB・商用ソフトのライセンスがクラウドで再購入になる、または持ち込み条件が付くことがある。
• 検証・開発環境の消し忘れ：使っていない環境を停止し忘れ、従量課金が垂れ流しになる。
• 運用移管コスト：監視・障害対応・パッチ適用を誰が担うかを決めず、移行後に慌てて外部委託を追加する。
• 教育・習熟：クラウドの運用に社内が慣れるまでの学習コストと初期の非効率。

これらは「移行が終わってから」表面化するため、初期見積もりでは見えにくい。だからこそ、見積もり段階で運用（③の層）と並行稼働期間を必ず言語化させることが、予算超過を防ぐ最大の対策になる。

よくある失敗パターン（経営者が気づきにくい落とし穴）

競合記事は「コストが暴走するリスク」に触れるだけで、なぜ起きるかまで踏み込んでいないことが多い。発注側が知っておくべき典型を挙げる。

1. オンプレの使い方をそのまま持ち込む：常時フル稼働のまま移し、従量課金が割高化。リホストしただけで満足し、最適化を後回しにして放置する。
2. サーバーだけ移して運用設計が旧態のまま：監視通知は増えるのに、対応する人と手順が変わらず、現場負荷だけ増える。
3. 責任分界を決めない：障害時に「クラウド事業者・移行ベンダー・自社」の誰が調査するか曖昧で、復旧が遅れる。
4. 移行対象を絞らない：廃止・現状維持で済むものまで一括移行し、費用と工数が膨らむ。
5. 並行稼働期間を短く見積もる：実際は検証で伸び、二重コストが計画超過。
6. TCO比較の条件が揃っていない：オンプレは人件費を除外、クラウドはSLAや運用範囲を狭く見積もり、フェアでない比較で意思決定してしまう。

特に6番は根が深い。AWSの公式ブログも、比較時は「調達条件を揃えることを確認する必要がある」と明言している。オンプレ側の人件費・空調・リプレースを入れず、クラウド側の運用委託費を入れないまま並べれば、どちらの結論も作れてしまう。数字は前提で決まる、という感覚を持っておきたい。

見積もりの読み方：発注側が確認する視点

ここが、コスト削減手法の羅列で終わる競合記事と最も差がつく部分だ。クラウド移行の見積もりを受け取ったら、金額の大小の前に、次を確認する。

• 3層に分かれているか：初期・移行・運用が混ざった「一式」見積もりは中身が読めない。分けて出させる。
• 移行方式が明記されているか：リホストなのかリファクタリングなのか。方式が書かれていない見積もりは、範囲が後で動く。
• 並行稼働期間と二重コストの扱い：旧環境をいつまで維持し、その費用を誰が負担するか。
• 移行後の運用範囲：監視・バックアップ・障害対応・パッチ適用のどこまでを含むか。含まないなら誰がやるのか。
• 前提と除外事項：データ量、連携先数、テスト範囲、切り戻しの有無。除外事項に追加費用の火種が潜む。
• 成功の定義：何をもって「移行完了」とするか。旧環境の停止までか、安定稼働の確認までか。

見積もりを比較するときは、金額を横に並べる前に、これらの前提を揃えることが先だ。前提が違う見積もりの安い方を選ぶと、後から追加費用で逆転する。前提を揃える作業そのものが難しい場合は、移行前の第三者診断で、現状棚卸しと見積もり比較の土台を先に作ってから発注に進む方が、結果的に総額を抑えやすい。

責任分界（責任共有モデル）を先に決める

クラウドでは「どこまでを事業者が守り、どこからが自社の責任か」が方式やサービスで変わる。IaaS（サーバーを借りる）ならOSより上は自社責任、SaaSなら大半が事業者側、というように分かれる。ここを決めずに移すと、セキュリティのパッチ・バックアップ・アクセス権限の管理が“誰の担当でもない”状態になり、障害や漏えいの温床になる。移行の設計段階で、監視・バックアップ・脆弱性対応・権限管理のそれぞれを「自社／移行ベンダー／クラウド事業者」のどこが持つかを一覧化しておきたい。移行後のデータ活用まで見据えるなら、データ活用基盤構築の観点で、ログとバックアップの持ち方を最初に設計しておくと後戻りが減る。

発注前チェックリスト

• 移行対象を「止められない基幹／古いが必要／SaaS化可能／廃止可能」に仕分けたか
• システムごとに復旧優先度（RTO/RPO）と停止許容時間を決めたか
• オンプレTCOに電気・空調・スペース・保守・リプレース・人件費を算入したか
• TCO比較を3年と5年の両方で作り、逆転点を確認したか
• 見積もりが初期・移行・運用の3層に分かれているか
• 移行方式（リホスト/リプラット/リファクタ/SaaS/廃止）が対象ごとに決まっているか
• 並行稼働期間と二重コストの負担者が明記されているか
• データ転送料・ライセンス再購入・検証環境の停止など隠れコストを洗い出したか
• 監視・バックアップ・障害対応の責任分界を一覧化したか
• 移行後の運用を内製するか外部委託するか方針を決めたか
• 見積もりの前提・除外事項・成功の定義を確認したか
• 相場の金額ではなく、前提を揃えて複数見積もりを比較したか

ベンダーに必ず聞く質問

• この見積もりの移行方式は何で、なぜその方式を選んだのか
• 並行稼働は何ヶ月を想定し、その間の費用はどちらの負担か
• 移行後3年・5年のTCOはいくらで、どの前提（稼働時間・通信量・SLA）で計算したか
• 移行後の運用は何を含み、何を含まないか。含まない部分は誰がやるのか
• 想定外で追加費用が出るとしたら、どの工程で、どんな理由でか
• 障害時の一次調査は誰が行い、どの範囲まで責任を持つか

これらに具体的に答えられるベンダーは、費用の内訳と運用まで設計できている。逆に「一式でこの金額です」としか言えない場合は、後から追加費用が出る可能性が高いと考えてよい。

GXOの見解と、相談すべきタイミング

クラウド移行の成否は、ベンダー選びや月額料金の安さの前に、「何を止められないか」「何を移さないか」「移行後の運用を誰が持つか」をどこまで整理できるかで決まる。GXOは、移行の見積もり比較だけでなく、その前段の現状棚卸し・復旧優先度づけ・移行方式の割り当て・RFP設計が、手戻りと追加費用を最も減らすと考えている。

相談すべきタイミングは、「サーバー更改の時期が近い」「ベンダー見積もりが妥当か判断できない」「クラウドにしたのに思ったより安くならない」「移行後に運用負荷や障害が増えた」のいずれかに当てはまったときだ。最初から大規模発注を前提にする必要はない。現状棚卸しと第三者視点での見積もり検証、レガシー調査やバックアップ見直しといった小さな範囲から始められる。自社だけで前提を揃えるのが難しい場合は、システム移行・再構築の相談を入口に、診断・要件定義・移行PMO・運用改善まで段階的に接続できる。

FAQ

クラウドに移せば必ず安くなりますか？

必ずしも安くなりません。利用に波があり止められる環境が多いシステムは有利になりやすい一方、24時間フル稼働・大量のデータ転送・高い可用性要件があるシステムは、クラウドの方が高くつくこともあります。3〜5年のTCOで、どの年に逆転するかを確認してから判断してください。

オンプレとの費用比較は何で見ればいいですか？

サーバーの購入費だけで比べないでください。オンプレのTCOには電気・空調・スペース・保守・数年ごとのリプレース・運用人件費が含まれます。クラウド側も月額料金だけでなく、監視・バックアップ・運用委託まで同じ範囲・同じSLAで揃えて比較することが重要です。

見積もりのどこを見れば追加費用を防げますか？

「初期・移行・運用の3層に分かれているか」「移行方式が明記されているか」「並行稼働期間と二重コストの負担」「移行後の運用範囲」「前提と除外事項」を確認します。一式でまとめられた見積もりは中身が読めず、後から追加費用が出やすくなります。

移行方式はどう選べばいいですか？

早く安く出たいならリホスト（リフト&シフト）、長期のコスト最適化にはリファクタリングが向きます。ただし全システムを同じ方式にする必要はありません。止められない基幹、廃止できる業務、SaaS化できる業務を仕分け、対象ごとに方式を割り当てるのが現実的です。

GXOにはどの段階で相談できますか？

構想段階、サーバー更改の検討前、予算化前、ベンダー見積もりの検証段階から相談できます。現状棚卸しや第三者診断など小さな範囲から始め、要件定義・移行PMO・運用改善まで必要に応じて段階的に進められます。

公式・一次情報（最終確認: 2026年7月16日）

• AWS クラウド移行（Cloud Migration）: https://aws.amazon.com/cloud-migration/
• AWS ブログ「クラウドコスト見積もりとオンプレミス環境との比較」: https://aws.amazon.com/jp/blogs/news/cloud-cost-estimation-compared-with-onpremise/
• Microsoft Azure クラウド移行: https://azure.microsoft.com/en-us/solutions/cloud-migration
• 経済産業省 DX政策: https://www.meti.go.jp/policy/it_policy/dx/dx.html

費用相場に関する金額は各社コラムの記載レンジを二次情報として引用しており、自社構成により大きく変動します。TCO削減率やROIの数値（例：非コスト要因が価値の大半を占めるとするAWSブログの言及など）も出典側の前提に依存するため、発注・投資判断の直前に、リンク先の最新版と自社条件での試算を必ず再確認してください。

この記事を実務で使う人へ

この記事は、経営者・事業責任者・情シス・兼任情シス・発注担当が、クラウド移行とオンプレ維持のどちらを選ぶか、ベンダー見積もりが妥当かを判断する材料として使えます。GXOが重視するのは、話題性ではなく「自社の業務・データ・運用責任・予算にどう影響するか」です。担当者だけで判断を閉じず、経営・現場・情シス・外部パートナーの役割を早い段階で分け、前提を揃えたうえで見積もりを比較することが、失敗と追加費用を避ける近道になります。