クラウド移行の課題と失敗パターン｜コスト増・セキュリティ・人材不足を移行前に潰す判断軸

クラウド移行が止まる最大の理由は、セキュリティ不安ではありません。総務省の令和6年通信利用動向調査で、クラウドを使っていない企業が挙げた理由の第2位は「既存システムの改修コストが大きい」の29.6%。「情報漏えいなどセキュリティに不安がある」の24.9%を上回りました。この記事では、既存資産の互換性・移行後のコスト増・責任共有モデルの読み違い・人材不足の四つについて、どこで金額が跳ね、どこで事故が起きるかを整理します。2024年以降に前提が変わったベンダーロックインの扱いと、移行を見送るべき条件も条件付きで示しました。

まとめ：クラウド移行でつまずく四つの課題と移行前に決める判断

クラウド移行が失敗する形は、おおむね四つです。既存システムがそのまま載らないこと、移行後に月額が想定を超えること、責任分界を読み違えて設定不備を残すこと、移行後の運用を担う人がいないこと。どれも移行作業ではなく、移行前に決めていなかった判断の帰結です。

総務省の令和6年通信利用動向調査（2025年5月30日公表）で、クラウドを使っていない企業の理由の第2位は「既存システムの改修コストが大きい」の29.6%。セキュリティ不安の24.9%より上でした。検討を止めているのは漠然とした不安ではなく、改修の見積もりが出ないことです。

移行前に決めるべき判断は三つ。移行方式をシステムごとに割り当てること。オンプレミスの減価償却とクラウドの従量課金を同じ期間・同じ費目で並べること。コスト超過と設定不備を検知する仕組みを移行と同時に入れること。これが決まらないまま日程だけ先に固めると、後戻りできない場所で問題が出ます。

移行しないという結論も判断のうちです。サポート期限が近いという理由だけで全システムを一斉に運ぶ計画は、後述の三条件に当てはまるなら見送ったほうが5年総額で安く収まります。

総務省調査が示すクラウド移行をためらう理由と実際につまずく課題のずれ

クラウド移行の課題は、セキュリティ・コスト・人材の三点セットで並べられがちです。公的統計を当てると、その並び順は実態とずれます。移行前に恐れる課題と、移行後に実際に効く課題も別物でした。

クラウドを使わない理由の最上位が既存システムの改修コストである構造

総務省「令和6年通信利用動向調査」（2025年5月30日公表、調査時点は2024年8月、企業40,592事業所が対象）で、クラウドサービスを利用していない企業が挙げた理由は次の順でした。

「必要がない」を除けば最上位は改修コストです。業務へ合わせて作り込んだ部分ほどクラウド側の標準機能では受け止められず、書き直しが発生します。作り込みが厚い企業ほど初期費用が跳ね上がり、投資判断がそこで止まる。セキュリティ不安は24.9%で、順位は改修コストの下です。

一方、クラウドを使っている企業では効果があったとする回答が88.2%に達し、利用企業の割合も8割を超えました。移行さえ済めば満足度は高いのに、入口の改修見積もりで止まっている構図です。課題の議論をセキュリティから始めると、この入口を素通りします。

改修見積もりを出すために移行費用と運用費用を分けて置く範囲の決め方

見積もりが出ない原因の多くは、一度きりの支出と毎月の支出を混ぜて数えていることにあります。移行費用は棚卸し・改修・データ移送・並行稼働・切り替えの五工程。運用費用には月額のインフラ料金に加え、監視・バックアップ・パッチ適用・アカウント管理の人件費が乗ります。前者だけで稟議を通すと、翌期に運用予算が足りません。

既存資産の互換性でつまずく典型パターンと移行方式の選び分けの基準

改修コストの中身は、ほぼ互換性の問題です。どこが載らないかを特定できれば、金額は見えてきます。

7Rのうちリホストへ寄せた場合に残る負債と方式を分ける判断基準

AWSの規範ガイダンスは、移行戦略を7つ（リホスト、リプラットフォーム、リファクタリング、リパーチェス、リテイン、リタイア、リロケート）に整理しています。ありがちなのは、期限に追われて全部をリホスト（そのまま載せ替え）に寄せる選択。移行は速く初期費用も抑えられますが、オンプレミス前提の構成が残り、可用性も費用構造も当時の設計に縛られます。

判断基準は単純です。今後3年で機能追加が続くシステムはリファクタリング寄り、保守だけのシステムはリホストで足ります。会計・人事・勤怠のように他社と差がつかない業務は、SaaSへ置き換える（リパーチェス）ほうが総額は下がる。全部を同じ方式で運ぶ計画書が出てきたら、そこが最初の危険信号です。方式を決めたあとの工程はクラウド移行の進め方（計画から切り替えまで）にまとめています。

文字コード・帳票・ミドルウェアなど移行時に落ちる箇所の洗い出し

互換性の問題は、本体よりも周辺で起きます。実務で頻出するのは次の箇所です。

• 文字コード：Shift_JISやEUC-JP前提の処理がUTF-8環境で化ける。外字を抱える基幹系ほど深い
• 帳票と印刷：専用フォームやプリンタドライバ依存の出力。PDF出力などへの置き換えが要る
• ミドルウェア：サポート切れのバージョンのまま載せると、クラウド側が動作を保証しない
• ライセンス：オンプレミス向けの条項がクラウド稼働を許諾していない場合がある
• バッチと外部連携：FTPや専用線前提のジョブは経路とタイミングの再設計が要る

この洗い出しを方式決定の前に済ませると、見積もり精度が変わります。文字コードと帳票は稼働後に見つかると業務が止まるため、並行稼働の期間中に実データで確認してください。

サポート期限に追われた移行がリホスト偏重を生む構造と回避の手順

期限は実在します。Microsoft LifecycleではSQL Server 2016の延長サポートが2026年7月14日に終了済みで、Windows Server 2016は2027年1月12日に終了予定です（太平洋時間基準）。この日付が先にあると方式検討より日程が優先され、リホスト一択になります。

回避は二段構えです。期限が効くシステムだけを切り出してリホストで逃がし、残りは期限から切り離して方式を個別に決める。全部を同じ期限に縛ると、本来リパーチェスやリタイアで済むものまで載せ替え、移行後の月額に恒久的に乗ります。棚卸しで「止められるもの」を1本でも見つけておくと、この後の費用計算が楽です。

移行後に月額コストが増える四つの原因と増加を止める費用設計の勘所

「クラウドにしたら高くなった」の中身は、だいたい四つです。原因ごとに打ち手が違います。

オンプレの減価償却と従量課金を同じ土俵で比べたときに生じる誤差

ずれる原因の筆頭は、期間と範囲の不一致です。オンプレミスのサーバ費用は購入時に資産計上し、おおむね5年で償却します。償却済みの機器とクラウドの月額を並べれば、当然クラウドが高く見える。比べるなら、機器の再購入時期を起点にした5年総額どうしで置いてください。

範囲の抜けも起きます。オンプレミス側の費目は機器代だけではありません。電気代、空調、ラック費用、保守契約、障害対応の人件費、数年ごとの機器更改プロジェクト費。これらをクラウド側に足さずに比較すると、判断が片側へ寄ります。両方に同じ費目を並べる。それだけで結論が入れ替わります。

データ転送料金とストレージ階層が費用に効いてくる規模と設計の目安

従量課金で読み違えやすいのは、計算資源以外の費目です。クラウドからインターネットへ出ていく通信（アウトバウンド転送）には料金がかかり、主要な事業者は月100GB程度を無料枠として超過分を従量で課金します。社内利用が中心なら影響は小さい。画像や動画を外部配信するシステムでは、転送料が計算資源の料金を上回ります。

ストレージも階層の選び分けで金額が動きます。頻繁に読み書きするデータと、法定保存のために置くだけのデータを同じ階層に置けば、後者に高い単価を払い続けることになる。移行時に参照頻度で分類しておけば、この差は効いてきます。移送の手順と整合性検証はクラウドデータ移行の手順と整合性検証にまとめました。

割引購入モデルを使える条件と使わないまま放置した場合の年間差額

クラウド事業者は、1年または3年の利用を約束する代わりに単価を下げる購入モデル（リザーブドインスタンス、Savings Plans、確約利用割引など）を用意しています。オンデマンド単価との差は数割に及び、24時間動かす業務システムを1年放置すれば、その差額がそのまま損失です。

ただし移行直後の長期契約は避けてください。稼働から数か月は必要スペックが動きます。実測が落ち着いてから、稼働が固定的なものだけを寄せる。開発・検証環境は夜間と休日に停止するだけで月額が半分近くまで下がり、こちらは契約より先に手を付けられます。

移行と同時にコスト増を検知する仕組みと予算責任者を決める段取り

四つ目の原因は、増えたことに誰も気づかない期間の長さです。オンプレミスでは支出の前に稟議が挟まりますが、クラウドは操作した瞬間に課金が始まる。この非対称を埋めるのが、タグ付けと予算アラートです。

移行時にやることは三つ。システム単位・環境単位のタグを全リソースに付ける、想定月額の80%と100%で通知が飛ぶ予算アラートを設定する、請求内訳を見る担当者を役割として決める。三つ目が抜けている組織が多く、アラートが飛んでも誰も止めません。移行の完了条件に「初月の請求内訳をレビューし、差異を説明できたこと」を入れておけば、この穴は埋まります。

責任共有モデルの読み違いが生むセキュリティ課題と設定不備の防ぎ方

移行前に語られる不安と、移行後に起きる事故は原因が違います。前者は事業者への不信、後者はほぼ自社の設定です。

クラウドのセキュリティとクラウド内のセキュリティを分ける境界線

AWSは責任共有モデルとして、自社の責任範囲を「クラウドのセキュリティ」、顧客の責任範囲を「クラウドにおけるセキュリティ」と定義しています。前者はハードウェア、ソフトウェア、ネットワーク、施設の物理的な保護。後者はデータの分類と暗号化、アクセス権限、ゲストOSやアプリケーションの管理です。他の主要事業者も同型の切り分けを公開しています。

誤解が起きるのは、この線がサービスの種類で動くところです。仮想サーバ（IaaS）ならゲストOSのパッチ適用は顧客側に残り、マネージドのデータベースやストレージなら事業者側へ移ります。移行設計書に「どのサービスで、どこまでが自社の作業か」を書いていない組織は、この線を誰も引かないまま本番を迎える。全体像はクラウドセキュリティのリスクと責任共有モデルで扱っています。

共有統制で顧客側に残るパッチ管理と構成管理の具体的な守備範囲

AWSは統制を三種類に分けています。顧客が完全に引き継ぐ「継承した統制」、インフラ層と顧客層の両方に適用される「共有統制」、アプリケーション固有の「顧客固有の統制」。穴が空きやすいのは真ん中です。

共有統制にはパッチ管理、構成管理、トレーニングが含まれます。パッチ管理なら事業者はインフラを直し、ゲストOSとアプリケーションは顧客が当てる。オンプレミス時代の作業のうちどれが消えてどれが残るかを一覧にしないまま人員計画を立てると、消えた作業だけを根拠に体制を薄くしてしまいます。

移行直後に設定不備が集中する理由と公開前に潰す点検項目の並べ方

設定不備は移行当日ではなく、直前に集中して作られます。切り替え日が迫ると検証のためにアクセス制限を緩め、そのまま本番を迎えるからです。ストレージの公開範囲、管理コンソールの多要素認証、退職者を含むアカウント、暗号鍵の管理者、監査ログの保存先。この五つは切り替え前のチェックリストに固定で入れてください。

IPAの「情報セキュリティ10大脅威 2026」（2026年1月29日公表）では、組織向けの2位に「サプライチェーンや委託先を狙った攻撃」が入りました。移行を外部委託する期間は、委託先の作業アカウントが自社環境に強い権限で存在する期間でもあります。作業用アカウントの有効期限を移行完了日に合わせ、完了後に残っていないかを確認する。この一手間がいちばん安く効きます。移送中・並行稼働中・切り替え直後の統制はクラウド移行のセキュリティで工程別に整理しました。

クラウド移行を担う人材が足りない状態での体制設計と外部委託の線引き

人材不足は採用で解く問題として語られがちですが、移行案件で効くのは線引きです。オンプレミスで培ったネットワーク・OS・監視の知識はそのまま効き、通じないのは権限設計と課金の二領域。クラウドでは操作権限がそのまま課金権限になり、どのサービスで組むかという設計判断が月額に直結します。何を自社に残すかを決めれば、必要な人数は見えてきます。

内製する範囲と委託する範囲を分ける判断基準と移行後の引き継ぎ

線引きの基準は頻度と可逆性です。毎日触る作業は内製に寄せ、数年に一度の作業は委託する。移行は後者の典型で、社内に専任者を育てても次の出番は数年後。日々のアカウント発行、監視のしきい値調整、費用の確認は内製に置いたほうが速く回ります。

委託時に必ず契約へ入れておくのが、移行後の引き継ぎ内容です。構成図、IaCのコード、運用手順書、権限の一覧、請求内訳の読み方。ここが曖昧なまま検収すると、翌年の改修で同じ委託先しか触れない状態になり、費用交渉の余地が消えます。外部と進めるならシステムリプレイス・マイグレーションの支援のように、運用引き継ぎまで含めて委託範囲を確認してください。

ベンダーロックインの前提が変わった2024年以降の料金と本当に残る依存

「一度クラウドに入れると、出すときに高額な転送料を取られる」。この説明は2023年までは正しく、2024年以降は条件付きで正しくありません。料金の話と設計の話は分けて扱います。

移行時のデータ転送を無償化したAWSとGoogle Cloudの申請条件

AWSは2024年3月5日、他社クラウドまたはオンプレミスへ移行する顧客に対し、インターネット向けデータ転送の料金をクレジットで返す方針を公表しました。Google Cloudも2024年1月に同種の措置を発表しています。ただし無条件ではありません。AWSはサポートへの申請と承認が前提、通常の無料枠（月100GB）を超えた分が対象で、後の更新では転出完了までの目安として90日が示されました。

実務上の意味は二つ。移行元から出る費用を理由に検討を止める根拠は弱くなりました。もう一つ、これは「全データを移して撤退する」場合の措置であり、日常運用の取り出しは通常料金のまま。マルチクラウド構成で日常的にデータを行き来させる設計は、対象外だと考えてください。

EU Data Actがスイッチング料金を禁じる時期と日本企業への影響

EUのデータ法（規則(EU)2023/2854）は2024年1月11日に発効し、2025年9月12日から適用が始まりました。事業者には他社やオンプレミスへの乗り換え支援が義務づけられ、乗り換えに伴う料金は2027年1月12日をもって全面禁止される建て付け。それまでは実際に生じた直接費用の範囲に制限されます。

日本国内の契約に直接適用される規制ではありません。ただし主要事業者は世界共通で料金体系を組むため、EU向けの変更が日本の料金表へ波及する例が続いています。実利は交渉材料が増えること。乗り換え支援の手順と費用の扱いを、更改時に契約条項で確認する価値があります。

料金以外に残る依存はマネージドサービスと運用設計であるという結論

転送料が消えても、ロックインは消えません。残るのは二つ。ひとつは特定事業者にしかないマネージドサービスへの依存で、サーバーレス基盤や独自データベースを深く使うほど作り直し量が増えます。もうひとつは運用設計への依存。監視・権限・課金の運用が事業者固有のツールに密着していると、移行の対象がシステムではなく組織の手順になります。

ここは言い切ります。マネージドサービスは避けるべきではありません。運用の人員が限られる企業ほど、事業者側に運用を寄せた設計のほうが総額で安く、事故も減ります。避けるべきなのは、乗り換える可能性が現実にある二領域、データの保管形式と認証基盤で独自仕様に寄せることだけ。この二点さえ守れば、あとは深く使ったほうが得です。

クラウド移行を見送るべき条件と見送ったあとに残す再検討のトリガー

移行しない判断が妥当な状況もあります。条件を挙げて言い切ります。

移行しないほうが総額で安く済むケースの条件と試算の組み立て方

次の三条件がそろうシステムは、移行を見送ったほうが5年総額で安く収まります。負荷が年間を通じて一定で、繁忙期の跳ね上がりがないこと。扱うデータ量が大きく、外部への配信が主目的ではないこと。現行機器の償却が終わっておらず、保守契約も2年以上残っていること。三つそろうと、クラウドの弾力性が働かないまま月額だけが積み上がります。

試算は機器の更改時期を起点に組み立ててください。保守終了日を基準日に置き、そこから5年間の総額をオンプレミス継続案とクラウド移行案の両方で並べる。オンプレミス側には次回の機器購入費と設置費、クラウド側には移行の一時費用と月額の5年分を入れる。これで、償却済み機器の維持費と月額を直接比べる誤りが消えます。費用構造の違いはオンプレミスとクラウドの比較と選び方で整理しています。

移行をいったん止めるべき組織状態と先に片づける前提条件の順序

金額とは別に、組織の状態を理由に止めるべき場合があります。現行システムの構成図が最新でない、稼働中のサーバの用途を説明できる人がいない、業務側が移行後の操作変更を受け入れていない。いずれかに当てはまるなら、日程を決める前にそこを片づけてください。構成が分からないまま運ぶと、障害時の切り分け先が何倍にも増えます。

片づける順序は、棚卸し、業務側の合意、方式決定、日程確定です。逆順で進むプロジェクトが多く、日程が先に決まると棚卸しが省略されます。見送ると決めた場合は、再検討のトリガーも同時に決めてください。機器の保守終了日の18か月前、業務量が想定上限の7割を超えた時点、基幹ミドルウェアのサポート終了が公表された時点。この三つに触れたら再検討すると決めておけば、見送りが放置に変わりません。

よくある質問

クラウド移行の検討で寄せられる質問を、判断に使える形で整理しました。

クラウド移行にかかる期間はどのくらいですか？

単一の業務システムをリホストで運ぶなら棚卸しから切り替えまで3〜6か月、基幹系を含む複数システムをリプラットフォームで運ぶなら1年以上が現実的です。期間を左右するのは移行作業より、棚卸しと業務側の合意形成、それに並行稼働の検証期間。帳票と月次処理は、その月を1回通さないと確認できません。月次・年次のサイクルを1周する時間を工程に含めてください。

クラウド移行でセキュリティは本当に下がりますか？

事業者側の基盤という意味では、自社のサーバ室より保護水準が高いのが通常です。事故が起きるのは顧客側の設定で、ストレージの公開範囲、管理者アカウントの多要素認証、権限の付けすぎに集中します。自社が担う範囲を移行設計書に明記し、切り替え前にチェックリストで確認すれば水準は上がる。分かれ目は事業者選びではなく自社の運用設計です。

移行後にコストが増えたらどう戻せばよいですか？

原因を四つに切り分けてください。比較の前提が違っただけなのか、割引購入モデルを使っていないのか、転送料やストレージ階層の設計なのか、単に不要なリソースが起動したままなのか。手を付ける順序は、停止できる環境の停止、リソースサイズの見直し、最後に長期契約の適用。この順なら契約前に不要な支出を落とせます。数か月分の請求内訳を並べ、増えた費目の特定から始めてください。

オンプレミスに残したほうがよいシステムはありますか？

あります。法令や業界規則でデータの所在地や物理的な管理形態が指定されている業務は、要件を満たす構成を組めると確認できるまで動かさないほうが安全です。負荷が一定でデータ量が大きく、現行機器の償却も保守契約も残っているシステムも同様。全面移行にこだわらず、サポート期限が効くものから順に運ぶ形でも成果は出ます。

ベンダーロックインはどこまで気にすべきですか？

データの保管形式と認証基盤の二点だけで足ります。転送料については、AWSが2024年3月に他社移行時のインターネット向け転送を申請ベースでクレジット対象とし、Google Cloudも同種の措置を取りました。EUのデータ法では乗り換え料金が2027年1月12日から禁じられます。マネージドサービスを避ける方針は、運用人員が限られる企業ではかえって総額を押し上げる。この二点さえ保てば、事業者の機能は深く使って構いません。

関連記事

• クラウド移行の進め方：課題を潰したあとの計画・費用・切り替えの手順
• クラウドとは？AWSとは何か：仕組みと料金の考え方という前提の整理
• オンプレミスとクラウドの違い：コスト・セキュリティ・拡張性で比べる選び方
• ハイブリッドクラウド移行：一部をオンプレミスに残す構成と接続設計
• プライベートクラウド移行：閉域・専有環境の方式選定と手順