LASSIC Media らしくメディア

LASSIC IT事業部｜プライムベンダーとしてシステム保守・運用を受託

クラウド移行事例の参考範囲は「業種・規模・移行範囲・契約形態」の4観点で決まる

クラウド移行事例を参照する目的は、自社の移行計画における判断軸と失敗回避のヒントを得ることにある。総務省「令和7年版 情報通信白書」（2025年7月公表）では、企業のクラウドサービス利用率は2024年に80.6%に達し、約10年で倍増している^*1。IPA「DX動向2025」（2025年6月公表）では、日本企業のDX取組割合は約8割で米国と同水準・ドイツを上回るが、内向き（効率化）と外向き（成長）の両方で成果を上げる企業は27%にとどまり、米独8割と差が開いている^*2。事例を読む際は、業界・規模・移行範囲・契約形態という4つの観点で自社との類似度を評価する。前提が大きく異なる事例の表層を真似ると、移行コストが事例の数倍に膨らむケースがある。

事例の読み解き方

事例情報には経営判断の前提・移行範囲・採用したクラウドサービス・運用体制が含まれる。これらを切り分けて読むことで、自社が参考にできる範囲と、参考にしてはならない範囲が見えてく。事例の表層だけを真似ると、前提条件が異なるために失敗を再生産する事態が起こり得る。

移行検討の3つの起点：インフラ更改・運用負荷・BCP強化

クラウド移行の検討は、「老朽化したインフラ更新の必要性」「運用負荷の限界」「事業継続計画（BCP）の強化要請」のいずれかが起点となるケースが多い。経済産業省「DXレポート2.2」ではレガシーシステムの維持コストがDX投資を圧迫している点が指摘されており^*3、自社設備の継続維持か、クラウドへの移行かの判断が経営課題となっている。

老朽化したインフラ更新の必要性

サーバー・ストレージ・ネットワーク機器の更改時期では、既存構成の延長で再投資するか、クラウドへ移すかが論点になる。再投資は数年単位の固定費となるため、更改タイミングが移行検討の起点となるケースが多く見られる。

運用負荷の限界

夜間・休日の運用作業、障害対応、パッチ適用といった作業を内製で抱え続ける負担は重く、運用要員の確保が難しい状況では運用品質の低下を招く。クラウドのマネージドサービスを活用することで、運用負荷の一部を外出しできる。

事業継続計画の強化要請

地震・水害・停電などのリスクに対し、自社設備のみで冗長性を確保するには高額な投資が必要である。クラウドのマルチリージョン構成を活用することで、相対的に低いコストで冗長化を実現できる。

移行パターンは4類型：リホスト・リフト&シフト・リファクタ・ハイブリッド

クラウド移行は一様ではありない。事業特性や既存システムの状態によって、適する移行パターンが変わる。ここでは代表的な4パターンを仮説形式で整理する。

パターン1：リフトのみ（リホスト）

既存サーバーをそのままクラウドへ移し、構成変更を最小限に抑えるパターンである。短期間で移行できる反面、クラウドのコスト最適化やマネージドサービスの効果は限定的である。耐用年数を迎えた機器の延命が目的の場合に選ばれる傾向がある。

パターン2：リフト＆シフト（段階最適化）

まずリホストで移行し、その後にデータベースやストレージをマネージドサービスへ置き換えていくパターンである。短期成果と長期最適化を両立しやすい一方、移行後の最適化フェーズが計画的に進まないと、コスト削減効果が中途半端になるリスクがある。

パターン3：リファクタ・リプラットフォーム

アプリケーションをコンテナ化したり、サーバーレス基盤へ載せ替えたりして、クラウドのアーキテクチャに合わせて再設計するパターンである。スケール性・運用効率は大きく向上しますが、初期工数が大きく、要件定義から作り直す覚悟が求められる。

パターン4：ハイブリッド構成

セキュリティ要件・既存資産の制約により、すべてをクラウドに寄せられない企業では、オンプレミスとクラウドを併存させるハイブリッド構成が選ばれる。境界部分のネットワーク設計・認証統合・運用統制が論点となる。

4パターンの選択判断軸

公開事例から学ぶ移行パターン

クラウド移行の判断軸を磨くには、公開された移行事例を構造化して読み解くことが有効である。ここでは、各社が公表している移行事例を「移行パターン×業種×目的」で整理し、自社の参考点を抽出する視点を示す。

事例1：基幹システムのリホスト型移行（金融・小売）

PayPayカードはクレジットカード業界で初となる基幹システムのAWSリフト移行を実施した^*4。横浜銀行も営業店DXに向け業務プロセス改革と並行してクラウド活用を進めている^*4。リホスト型はオンプレミスのアーキテクチャをそのまま移すため移行リスクを抑えやすく、規制業種で先行事例が多い。一方、移行後にマネージドサービスへの段階的置き換えを計画していないと、運用コストの最適化効果が限定的にとどまる傾向がある。

事例2：レガシー基幹のリプラットフォーム型移行（製造）

AGCはメインフレーム上で稼働していた基幹システムをAWS上のSAPに刷新した^*5。ネスレ日本はAS/400上のRPGプログラムをJavaに書き換えるリファクタリングツールを用いて、約1年で移行を完了している^*5。製造業ではIoT・MES連携の要件が新たに加わるため、オーダーメイド継続より標準化されたクラウドサービスの組み合わせを選ぶ判断が増えている。

事例3：100万人規模のフルクラウド化（流通・サービス）

生活協同組合連合会東海コープ事業連合は、100万人の食卓を支えるシステムのフルクラウド化を実施した^*6。森永製菓は基幹システムを含むサーバ90台以上をAWSへ移行している^*6。フルクラウド化は段階移行に比べて切替時の検証範囲が広いため、依存関係マッピングと運用設計の質が成否を分ける。

事例4：ガバメントクラウドの先行事例（公共）

地方自治体の標準化対象業務では、ガバメントクラウドへの移行が令和7年度（2025年度）を期限として進んでいる。デジタル庁の先行事業では、移行後の運用経費が中核市市長会調査で平均2倍強に増加する見込みと指摘され、見積精査・大口割引・財政支援等の対策が継続的に講じられている^*7。コスト構造を移行前提で再設計しない場合、想定外の運用経費上振れが発生し得る。

事例の読み方：4つの観点で自社差分を測る

各事例は業種・規模・移行範囲・移行パターンの4観点で自社との差分を測ることで、参考にできる範囲が明確になる。たとえばPayPayカードのリホスト事例を参考にする場合、自社の規制要件・既存ベンダーロックイン状況・基幹DBの依存関係が事例企業と類似しているかが判断軸となる。

成功事例の共通点は「KPI文書化・依存関係マッピング・運用体制設計」の3点

クラウド移行で成功する事例は、技術選定よりも先に3つの組織条件を満たしている。

1. 移行目的とKPIを経営層・現場・委託先で文書化していること
2. 既存システムの棚卸し・依存関係マッピングを移行前に完了していること
3. 移行後の運用体制（責任分界・監視・障害対応）を設計したうえで切替を行っていること

これらは技術的な選択以前の経営・組織課題に直結している。事例を真似する場合でも、この3点が自社で整っているかを点検することが必要である。

移行目的とKPIの定義

「コスト削減」「事業継続性向上」「開発スピード向上」など、移行で何を達成するのかを定量的に定義する。目的が曖昧なまま着手すると、移行後の効果検証ができず、追加投資の判断軸も持てない。

依存関係マッピング

移行対象のサーバー・データベース・アプリケーション間の依存関係を可視化する。マッピングが不十分なまま切替を進めると、想定外のサービス停止が発生する。

クラウド移行プロジェクトの75%が予算超過：失敗パターンと回避策

クラウド移行は構造的に同じ失敗が繰り返されている。McKinseyの調査ではクラウド移行プロジェクトの75%が予算を超過し、37%がスケジュール遅延を経験している^*8。Gartnerもインフラストラクチャ＆オペレーション部門の60%が2024年までパブリッククラウド予算超過に直面すると分析している^*9。以下、代表的な失敗パターンを整理する。

コストが想定を超過する

クラウドは従量課金が前提のため、利用量の予測精度が低いと月額コストが想定を超過する。事例で語られる「コスト削減」は、移行後にチューニング・最適化を継続した結果として実現したケースが多く、初期段階で実現するわけではありない。

移行直後の性能劣化

オンプレミスでは問題なかった性能が、クラウド環境ではネットワーク経路・ストレージI/Oの違いから劣化することがある。事前の性能検証を省略した状況では、利用者影響が顕在化したあとに対処することになる。

失敗コストの定量化

クラウド移行で重大な障害を起こすと、事業システムの停止に直結する。たとえばECサイトのデータベース移行を誤ると、1日あたりの売上規模に応じた機会損失が発生し、復旧までの時間に応じてユーザー離反も拡大する。基幹系では、停止が業務全体を止めるため、リスクの定量化と冗長設計への投資は事業継続のための前払いと捉えることが必要である。

セキュリティ統制の漏れ

責任共有モデルを正しく理解しないまま移行すると、本来クラウド利用者側で行うべき設定（IAM・暗号化・ログ取得）が抜け落ちる事態が起こる。IPA「DX白書2023」でもクラウドセキュリティの理解不足は重要課題と整理されています^*2。

移行は6ステップ：現状把握・KPI設定・設計・計画・検証切替・運用最適化

クラウド移行プロジェクトは「現状把握→目的・KPI設定→アーキテクチャ設計→移行計画→検証・切替→運用最適化」の6ステップで進める。各ステップに前後関係があり、一部省略は後工程の手戻りを生む。

ステップ1：現状把握

サーバー・ネットワーク・アプリケーションの構成情報、運用手順、契約形態を棚卸しする。利用しているOS・ミドルウェアのサポート期限を確認することで、優先順位を決められる。

ステップ2：目的・KPI設定

移行で達成したい目標を経営層と合意する。コスト・性能・運用効率・事業継続のうち、どれを優先するかを明文化することで、後工程の判断軸が揺らぎにくくなる。

ステップ3：アーキテクチャ設計

採用するクラウドサービス、ネットワーク構成、認証統合、データベース構成、バックアップ設計、監視設計を文書化する。責任共有モデルにおける役割分担も明確にする。

ステップ4：移行計画

移行対象の優先順位、切替単位、ロールバック手順、関係者調整スケジュールを文書化する。業務影響時間を最小化するため、段階移行の単位は「業務停止許容時間」を基準に設計する。

ステップ5：検証・切替

性能・整合性・セキュリティの検証を実施する。検証で合意した品質ゲートを満たしたうえで、本番切替に進む。

ステップ6：運用最適化

移行後はコスト・性能・障害発生件数のモニタリングを継続し、最適化を進める。クラウドはサービス更新が頻繁ですので、定期的な見直しが運用品質の維持に直結する。

オンプレミスとクラウドは選択でなく配置設計：5観点の使い分け

オンプレミスとクラウドは対立する選択肢ではなく、業務特性に応じた配置設計の問題である。判断軸を表に整理する。

表からも分かるとおり、オンプレミスとクラウドのどちらかが優れているわけではない。重要なのは、業務特性ごとに最適な配置を設計する観点である。

関連する論点は以下の記事で個別に深掘りしている：

• クラウド移行の課題と解決策｜失敗しない進め方
• クラウド移行手順を解説｜失敗しない5ステップと注意点

中規模システム移行は5名×6〜12か月：内製と委託の差分

クラウド移行を内製で進める場合、以下の広範な専門知識を社内で確保する必要がある。専門家委託では、これらをベンダー側があらかじめ保有しているため、立ち上げ時の負担を抑えられる。

内製で必要となる主な専門知識

• クラウドサービスのアーキテクチャ・料金体系・サービス更新動向
• ネットワーク設計・VPN・専用線・DNS統合
• IAM・鍵管理・ログ統制・責任共有モデルの理解
• 移行ツール・データベース移行・性能検証手法
• 運用設計（監視・バックアップ・障害対応・コスト管理）

工数の目安

中規模システムの移行では、規模により幅はありますが、5名規模のチームで6か月〜12か月程度の工数を要するケースが一般的である。アセスメント・移行設計・検証・切替・移行後最適化のフェーズごとに継続的な工数が発生する。

専門家委託との差分

専門家への委託では、複数のクラウドサービスへの対応経験を持つ体制を期間単位で利用できる。自社人材を本業のシステム企画・要件定義に集中させたい場面、移行リスクを最小化したい場面では、委託の活用がリスク低減策として機能する。LASSICへの委託は「難しいから頼む」ではなく「リスクを最小化するために専門体制を活用する」という観点で機能する。

---

ご不明な点はお問い合わせフォームからもご連絡いただける。

まとめ

クラウド移行事例は、自社の判断軸を磨くための情報源である。本記事で扱った4パターン（リホスト・リフト&シフト・リファクタ・ハイブリッド）と6ステップ（現状把握→KPI設定→設計→計画→検証切替→運用最適化）は、それぞれ独立した判断軸ではなく、目的・KPIと運用体制の文書化を前提として組み合わさる枠組みである。事例の解釈や移行計画の設計でお悩みの場合は、LASSICへお気軽にご相談ください。

1. 出典：総務省「令和7年版 情報通信白書 第1部第2章第3節 クラウドサービスの利活用の動向」（2025年7月公表）
2. 出典：独立行政法人情報処理推進機構（IPA）「DX動向2025」（2025年6月公表）
3. 出典：経済産業省「DXレポート2.2」（2022年7月）
4. 出典：富士通「導入事例一覧（PayPayカード・横浜銀行ほか）」（2026年5月確認）
5. 出典：富士通・AWS「富士通とAWSによるメインフレームのモダナイゼーションへの取り組み」（AGC・ネスレ日本ほか）
6. 出典：富士通「導入事例一覧（生活協同組合連合会東海コープ事業連合・森永製菓ほか）」（2026年5月確認）
7. 出典：デジタル庁「自治体情報システムの標準化・ガバメントクラウド」（2025年）
8. 出典：McKinsey & Company「Cloud-migration opportunity: Business value grows, but missteps abound」（2021年）
9. 出典：Gartner「7 Reasons Cloud Budgets Don’t Stay in Check」（2022年）。なお本文中のパブリッククラウド予算超過に関する数値はGartner有料レポート由来のため、直接引用の確認は原典レポートを参照されたい。