LASSIC Media らしくメディア

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

クラウド移行とは何か

クラウド移行（クラウドマイグレーション）とは、オンプレミス環境のサーバー・ストレージ・アプリケーションをクラウドへ移転するプロセスである。移転先は主にAWS・Azure・Google Cloudといったパブリッククラウドが選ばれる。

総務省の令和6年版情報通信白書によれば、クラウドサービスを一部でも利用している日本企業の割合は80%を超える^*1。クラウド活用はもはや先進的な取り組みではなく、標準的なインフラ戦略の一部となっている。

クラウド移行の基本手順は、①現状調査 ②移行設計・計画策定 ③移行実行 ④動作検証 ⑤運用定着、の5段階で構成される。各工程で定義された成果物を確認してから次工程に進むのが、失敗回避の原則である。

一方、オンプレミスを継続する場合には見えにくいコストが継続的に発生する。サーバーの老朽化による故障リスクの増大、保守契約費・電力費・空調費の固定的な負担、そしてハードウェアのサポート終了に伴うセキュリティパッチ適用不能のリスクだ。クラウド移行はこれらの「現状維持コスト」を解消する手段として位置づけられる。

しかし、クラウドを導入することと、既存の業務システムをクラウドに正しく移行することは別の課題となる。移行を誤ると、レイテンシの増加・セキュリティホールの発生・ランニングコストの増大という3つのリスクが同時に発生する可能性がある。

クラウド移行の5つの手順

クラウド移行を成功させるためには、段階的な5つの手順を順守することが重要である。工程を飛ばして進めると、後工程での手戻りが大きくなるため、各フェーズで定義された成果物を確認してから次に進むことが原則だ。

手順1：現状調査（アセスメント）

移行対象システムのインベントリを取得し、依存関係・データ量・トラフィックパターン・セキュリティ要件を一覧化する。この段階で「移行できないシステム」（クラウド非対応のレガシーアプリ、特定のハードウェアに依存するシステムなど）を明らかにするのが欠かせない。

現状調査を内製で実施する場合、インフラエンジニア・アプリケーションアーキテクト・セキュリティエンジニアの3職種が必要で、中規模システム（50〜100サーバー程度）では80〜160時間程度の工数が見込まれる。この調査が不十分なまま設計に進むと、移行後に想定外の依存関係が判明し、再設計が必要になりる。

例：この工程の成果物　システムインベントリ一覧、依存関係マトリクス、移行不可システムリスト

手順2：移行設計・計画策定

調査結果をもとに、各システムへの移行戦略の割り当てを行う。移行戦略は、既存構成のまま移行するリフト&シフト、部分最適化を伴うリプラットフォーム、クラウドネイティブに再構築するリアーキテクチャなど6種類（詳細はセクション3「6Rモデル」参照）に大別される。そのうえで、移行順序・スケジュール・ロールバック計画を策定する。移行順序は「リスクの低いシステムから着手する」が鉄則だ。基幹系（販売管理・生産管理など）を最初に移行するケースでは、障害発生時の業務停止リスクが高まる。

一方、設計フェーズでは、ネットワーク設計（VPC・サブネット・セキュリティグループ）・IAM設計・コスト最適化設計を並行して進める。設計の品質が運用コストに直結するため、この工程への投資を惜しむとランニングコストが増大する。

例：この工程の成果物　移行戦略割当表（6R別）、移行順序スケジュール、ロールバック計画書、ネットワーク/IAM設計書

手順3：移行実行

設計に従って環境構築・データ移行・アプリケーション設定を実施する。データ移行では、AWS Database Migration Service（DMS）やAzure Database Migration Serviceなどのマネージドサービスを活用することで、データ整合性を確保しながら移行時間を短縮できる。

また、業務継続の可否は別の論点となる。業務を継続しながら移行する「オンラインマイグレーション」と、一時停止して移行する「オフラインマイグレーション」のどちらを採用するかは、許容できるダウンタイムによって決まる。24時間365日稼働が必要なシステムでは、オンラインマイグレーションの設計難易度が大幅に上昇する。

例：この工程の成果物　移行完了報告書、データ整合性チェック結果、環境構築ログ

手順4：動作検証・パフォーマンステスト

移行後の環境で、機能テスト・パフォーマンステスト・セキュリティテストを実施する。オンプレミスと同等のレスポンスタイムが確保されているかをログで定量的に確認することが重要である。「動いているから問題ない」という主観的な判断ではなく、SLAを数値で定義してから検証を実施する。

加えて、本番環境への切り替え（カットオーバー）の直前には、必ずロールバック手順を確認し、実行可能な状態にしておく。カットオーバー後に問題が発生した際に旧環境への切り戻しができない状態は、障害対応を著しく困難にする。

例：この工程の成果物　テスト結果レポート、SLA適合性確認書、カットオーバー判定書

手順5：運用定着・継続的最適化

カットオーバー後は、クラウド特有の運用体制（コスト監視・セキュリティパッチ管理・スケーリング設定のチューニング）を定着させる。クラウド利用コストは適切な管理をしないと「クラウドリフト」（過剰スペックでの運用）により増大する。AWS Cost ExplorerやAzure Cost Managementを用いて月次でコスト最適化を継続することが推奨される。

例：この工程の成果物　運用手順書、コスト最適化レポート（月次）、セキュリティ監査ログ

移行戦略の選び方（6つのRモデル）

移行戦略の選択はプロジェクトコストに最も大きな影響を与える判断である。Amazonが提唱した「6R」が業界標準のフレームワークとして広く使われている。

現状調査を経ずに「全システムをリフト&シフトで移行する」と決定するケースでは、本来リアーキテクチャが必要なシステムも含めて低コスト移行を試みた結果、クラウド移行後も非効率なコストが発生し続ける「クラウドスプロール」状態に陥るリスクがある。

よくある失敗パターンと対策

クラウド移行プロジェクトの失敗は、技術的な問題よりも計画・プロジェクト管理上の問題に起因するケースが多くある。代表的な失敗パターンを整理する。

パターン1：コスト試算の誤り

クラウドの費用は「使った分だけ」というモデルであるため、オンプレミスとの単純比較では正確な試算ができない。移行後のコストがオンプレミス時代の2倍以上になるケースでは、リザーブドインスタンスの活用・オートスケーリングの設定・不要リソースの削除が検討されていないことが少なくない。移行前の試算には、クラウドコスト計算ツール（AWS Pricing Calculator等）の活用が有効だ。

パターン2：セキュリティ設計の後回し

「移行後にセキュリティを設定すればよい」という判断で移行を急ぐ状況では、移行完了後に脆弱なIAM設定・過剰な公開ポートが残存するリスクを抱える。クラウド環境のセキュリティはオンプレミスと責任分界点が異なるため、設計フェーズからセキュリティエンジニアを関与させることが欠かせない。

パターン3：依存関係の把握漏れ

アプリケーションAを移行した後に、IPアドレス固定で接続していたアプリケーションBが動作しなくなるケースは、事前の依存関係調査が不十分であったことが原因に他ならない。移行アセスメントでは、ネットワークトラフィックの実測（AWS Application Discovery ServiceやAzure Migrateなどのツールを活用）が有効だ。

パターン4：組織の変化対応不足

インフラ担当者がオンプレミス運用のみを経験している状況でクラウドに移行した場合、クラウド固有の運用知識（コスト管理・IAM管理・CLIツール操作）の習得が追い付かず、運用品質が低下することがある。移行と並行したクラウド運用トレーニングの計画が必要である。

内製と外注の判断基準

以上の失敗パターンを踏まえると、そもそも自社で実施するか、外部パートナーに依頼するかという判断自体が重要になる。

クラウド移行を内製で進めるか外注するかの判断は、社内のスキルセット・移行規模・タイムラインによって変わりる。以下の観点で現状を整理することが判断の出発点である。

• クラウドアーキテクト（AWS Solutions Architect等の資格保有者）が社内にいるか
• 移行対象システムの数が10以上か、または基幹系が含まれるか
• 移行期間が6か月以内という制約（リースアップ・コスト削減期限等）があるか
• 24時間稼働要件のシステムが含まれているか

上記のいずれかに該当する場合は、外部パートナーの活用を検討することが現実的である。IPA「DX動向2024」によると、DX推進に取り組む企業の多くが「IT人材不足」を課題として挙げており^*2、クラウド移行専門のスキルを内製で確保することは規模を問わず難しくなっている。

外注する場合も、「丸投げ」ではなく、内製チームと外部パートナーが役割を分担する「協調型」の体制が推奨される。移行ノウハウを自社に蓄積するためには、プロジェクト管理・承認プロセス・ドキュメント管理を内製側が担うことが有効である。

移行前に整理すべき確認事項

クラウド移行プロジェクトを開始する前に、以下の4点を整理することでプロジェクトの精度が上がりる。

• 移行の目的の明確化：コスト削減・可用性向上・スケーラビリティ確保のどれが最優先かを決める
• 許容ダウンタイムの定義：ゼロダウンタイムが必要なシステムと、数時間の停止が許容されるシステムを分類する
• コンプライアンス・規制要件の確認：個人情報・医療情報・金融情報を扱うシステムではデータ所在地の制約がある
• 移行後の運用体制の設計：移行後に誰がクラウドを管理するかを先に決める

クラウド移行の総費用は、移行規模・戦略・パートナー費用によって大きく異なりますが、中規模システム（50〜100サーバー・リプラットフォーム含む）では2,000〜5,000万円程度が目安として参照される。移行後のランニングコストは適切な最適化により移行前比20〜40%削減できるケースもあるが、最適化作業自体に継続的な工数が必要である。

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

1. *1　出典：総務省「令和6年版 情報通信白書 クラウドサービス」（2024年）
2. *2　出典：IPA独立行政法人情報処理推進機構「DX動向2024」（2024年）

Tweet