クラウド移行の相談を受けるとき、最初に問われるのはいつも「何をどう移すか」ではなく「そもそも何を移すべきか」という問いだ。データセンターのラック一本一本に、それを正当化したビジネス上の判断が刻まれている。それをまるごとクラウドへ持ち込めば済む話ではない。Pulse Tech Zone Pathがこれまで製造業、金融、メディアの各領域でオンプレミス資産の棚卸しを行ってきた経験から言えば、移行の失敗の大半は戦略の選択ミスではなく、選択の前提となる資産評価のすっ飛ばしにある。本稿では、リフト＆シフト、リプラットフォーム、リファクタリングという三つの戦略を整理し、それぞれがどの条件のもとで有効に機能するかを具体的に記述する。コスト試算の落とし穴と、移行後の運用コストの見積もり方についても触れる。

まず資産を四象限で仕分ける

移行戦略を語る前に、現行システムの棚卸しが必要だ。Pulse Tech Zone Pathでは「ビジネス依存度」と「技術的負債の深さ」という二軸で資産を四象限に分類することを出発点にしている。依存度が高く負債が浅いシステムはリフト候補、依存度が高く負債も深いものはリファクタリング候補、依存度が低く負債が浅いものは廃棄または統合の候補となる。たとえば社内ファイルサーバーのように、業務への依存は高いがアーキテクチャは単純なものは、リフトで十分なことが多い。一方、15年前に独自フレームワークで書かれたERPの中核モジュールは、そのままクラウドへ持ち込んでも運用コストが下がらない。棚卸しには最低でも2週間、200台以上のサーバーがあるなら専用ツール（AWS Migration Evaluator、Azure Migrateなど）を使って自動収集することを推奨する。

リフト＆シフト：速度を優先する場面での選択

リフト＆シフトは、仮想マシンをほぼそのままクラウドへ複製する手法だ。移行期間が短く、アプリケーションの変更が最小限で済む。データセンターの契約終了が6か月後に迫っている、あるいは特定のコンプライアンス対応のためにオンプレミス設備を縮小しなければならない、といった期限駆動の案件に向く。ただし「クラウドへ移せばコストが下がる」という前提は危険だ。オンプレミスでt2.xlarge相当のスペックを24時間365日稼働させれば、月額コストはオンプレミスを上回ることがある。リフト後にリザーブドインスタンスやSavings Plansで単価を下げる計画、および不要時間帯のスケールダウン設定をセットで設計しなければ、移行前より請求が増える事例は珍しくない。リフト＆シフトは「終点」ではなく「起点」として位置づけるのが正しい。

リプラットフォーム：中間の妥協ではなく、意図的な選択

リプラットフォームはしばしば「中途半端な戦略」と見なされるが、実際には特定の条件下で最も費用対効果が高い。アプリケーションのコードロジックは変えず、実行基盤だけをクラウドネイティブなマネージドサービスへ置き換える手法だ。たとえば、自前のMySQLをAmazon RDS for MySQLへ移行する場合、OSのパッチ適用、バックアップ管理、フェイルオーバー設定の運用工数がマネージド側に吸収される。ある製造業クライアントのケースでは、DBの運用に割いていた専任エンジニア0.4人月分の工数が移行後にほぼゼロになり、年間で約180万円相当の人件費が開発業務へ再配分された。リプラットフォームが適するのは、OSやミドルウェアの運用負荷が高く、かつアプリケーション層の改修コストをかけられない場面だ。

リファクタリング：いつ、何を、どこまでやるか

リファクタリングはクラウドネイティブアーキテクチャへの再設計を意味する。マイクロサービス化、コンテナ化、サーバーレス化がその代表的な手法だ。投資対効果が最も高くなりうるが、同時に最もリスクと工数が大きい。判断基準は三点に絞られる。一つ目は、スケーラビリティの要件が動的かどうか。トラフィックが季節や時間帯で大きく変動するECや配信系サービスは、リファクタリングによる自動スケールの恩恵が明確だ。二つ目は、開発サイクルの速度がボトルネックになっているかどうか。モノリシックなコードベースがデプロイ頻度を月1回以下に制限しているなら、分割して独立デプロイできる構造へ移行する価値がある。三つ目は、チームにクラウドネイティブの設計経験があるかどうか。経験のないチームがリファクタリングに踏み込むと、設計の瑕疵がコストに直接反映される。

移行後コストの見積もりで見落とされがちな項目

移行計画の段階でよく抜け落ちるコスト項目を列挙する。データ転送料金：クラウドへの転送はほぼ無料だが、クラウド外への転送（egress）は有料だ。大量データを定期的に外部SaaSへ送るアーキテクチャは、egress費用が月額数十万円になることがある。ライセンス持ち込みの可否：WindowsやSQL ServerのオンプレミスライセンスをクラウドへBYOLで持ち込む場合、ライセンス条項の確認が必要だ。サポート契約：AWS BusinessサポートはEC2等の月額利用料の10パーセントが最低ラインとなり、利用規模によっては年間100万円を超える。監視・ログ基盤：オンプレミスではZabbixなどOSSで賄っていた監視が、クラウドではCloudWatchのカスタムメトリクス費用として積み上がる。これらを移行計画のスプレッドシートに明示的な行として加えることが、予算超過を防ぐ最初のステップだ。

残すという選択：クラウド化しない判断の根拠

すべてをクラウドへ移す必要はない。オンプレミスに留める合理的な理由が存在するケースがある。まず、超低レイテンシ要件を持つシステムだ。製造ラインの制御システムや高頻度取引のオーダー管理システムは、ネットワーク遅延の変動がビジネスへの直接的な影響を持つため、エッジまたはオンプレミスに置き続けることが合理的な場合がある。次に、規制要件だ。一部の金融・医療データは、国内のオンプレミス設備での保管を求める規制が現時点でも存在する。パブリッククラウドのリージョンが国内にあれば対応できるケースが増えているが、個別の規制文書を法務チームと確認せずに移行を進めるのはリスクが高い。「クラウド移行」の成果物は全量移行ではなく、残す資産と移す資産の明確な根拠の整理にある。

判断を記録に残すこと：意思決定ログの価値

移行戦略の選択において、判断のプロセスを文書化することは技術的な成果物と同等に重要だ。なぜリフトを選んだのか、なぜ特定のシステムを残したのか、その時点での制約条件と優先順位を記録しておかなければ、1年後に担当者が交代したとき、その判断を再評価する手がかりが失われる。Pulse Tech Zone Pathではアーキテクチャ決定記録（ADR：Architecture Decision Record）の形式を推奨している。各決定について「文脈」「決定内容」「検討した代替案」「結果と見直し条件」の四項目を短く記述するだけでよい。これにより、将来のリプラットフォームやリファクタリングの判断が、ゼロからの調査ではなく既存の記録の更新として行えるようになる。

オンプレミスからクラウドへの移行は、一度で完結するプロジェクトではない。資産の評価、戦略の選択、実行、そして運用の中での継続的な見直しというサイクルが本質だ。リフト、リプラットフォーム、リファクタリングのいずれが正解かは文脈によって変わるが、その選択を支える判断軸と記録の習慣は、どのケースにも共通して必要とされる。Pulse Tech Zone Pathは東京を拠点に、製造、金融、メディア各領域のクラウド移行戦略の策定と実行支援を行っている。