生成AIの急速な普及によって、多くの企業がAI活用を経営課題として位置付けるようになりました。業務効率化、顧客体験の向上、新サービスの創出など、AIに寄せられる期待は大きいものがあります。しかし、AIのPoCでは一定の成果を確認できても、それを本番業務へ展開し、継続的な事業価値へつなげる段階で苦戦する企業は少なくありません。
こうした状況は個別企業の問題ではありません。Microsoft Azure Blogが引用するForresterの「Q1 2026 Cloud and AI Application Modernization Survey」によれば、ITリーダーの91％が「アプリケーションのモダナイゼーションはAI活用を実現するために不可欠である」と認識しています[1]。また、Forrester Consultingが2024年に実施した調査では、Azureのクラウド基盤を持つ組織の回答者116人のうち75％が、クラウド移行によってAI導入が進めやすくなったと回答しています[2]。
企業はこれまで、オンプレミスのシステムをクラウドへ移行することをクラウド・モダナイゼーション（Cloud Modernization、以下CM）の中心に据えてきました。しかし、クラウドへ移しただけで開発速度、データ活用、業務変革が自動的に向上するわけではありません。AI時代に問われているのは、「クラウドへ移行できたか」ではなく、「クラウドを使ってどれだけ速く変化できるか」です。
クラウド・モダナイゼーションは今、移行プロジェクトから、企業の変化能力を継続的に高める経営モデルへと再定義される必要があります。
クラウド・モダナイゼーション 1.0の主目的は、オンプレミス中心のIT資産をクラウド環境へ移すことでした。データセンターの縮小、ハードウェア更改の回避、設備投資から利用型コストへの転換、可用性や災害対策の強化など、インフラ面の合理化が主要な成果として期待されました。この段階では、既存システムの構造を大きく変えずにクラウドへ移す、いわゆるリフト&シフトが合理的な選択となるケースも多くありました。システム更改期限やデータセンター退出期限が迫る状況では、移行速度、安定性、既存資産の維持が重視されるからです。
IDC Japanも、国内ITモダナイゼーションにおける実行タイプを、リホスト、リライト、リビルドの三つに分類しています。リホストは既存のアプリケーション資産を維持しながら非レガシー環境へ移行する入口であり、予算や移行期間に制約がある企業にとって現実的な選択肢とされています[3]。
したがって、リフト&シフトそのものが誤りなのではありません。問題は、それをクラウド・モダナイゼーションの最終地点と捉えてしまうことにあります。アプリケーションの構造、データの持ち方、開発方法、運用プロセス、組織の責任分担まで変えなければ、企業の変化速度はオンプレミス時代と大きく変わりません。
クラウドへの移行は完了していても、モダナイゼーションは完了していません。この認識が、クラウド・モダナイゼーション 2.0への出発点となります。
リフト&シフトを中心としたクラウド・モダナイゼーション 1.0では、移行完了日が重要なマイルストーンになります。何台のサーバーを移行したか、データセンターをいつ閉鎖できるか、どれだけのインフラ資産をクラウドへ移せたかが、プロジェクトの進捗指標として使用されます。
しかし、これらは移行の完了を測る指標であり、企業の変化能力を測る指標ではありません。
クラウド移行後もアプリケーションが密結合のままであれば、一つの機能変更がシステム全体へ影響します。データが部門やシステムごとに分断されたままであれば、クラウド上に移しても横断的な分析やAI活用は進みません。リリース判定や環境構築、障害対応が手作業のままであれば、クラウドの柔軟性を事業スピードへ転換できません。
経済産業省のレガシーシステムモダン化委員会総括レポートは、レガシーシステムを単に古い技術で構築されたシステムとは定義していません。同レポートでは、運用・保守や機能改良が困難になり、経営・事業戦略上の足かせや高コスト構造の原因となっている状態をレガシーシステムとして捉えています。また、メインフレームなどから脱却していても、運用・保守に問題があれば再レガシー化する可能性があると指摘しています[4]。
これはクラウド・モダナイゼーションにとって重要な示唆です。クラウドへ移行したという事実だけでは、レガシーから脱却したことにはなりません。変更しにくく、外部サービスと接続しにくく、運用が属人化したままであれば、クラウド上で新たなレガシーを形成している可能性があります。
クラウド・モダナイゼーション 1.0の課題は、クラウド移行に失敗したことではありません。移行後の変革を計画に組み込まなかったことにあります。
クラウド・モダナイゼーション 2.0は、クラウド・モダナイゼーション 1.0を否定するものではありません。1.0で構築したクラウド基盤を活用し、企業の変化速度、価値創出力、運営効率を継続的に高める次の段階です。両者の違いは、技術の種類よりも目的と評価基準に表れます。
クラウド・モダナイゼーション 2.0でもっとも重要なのは、クラウドを「場所」ではなく「変化の仕組み」として捉えることです。たとえば、アプリケーションをPaaSやコンテナへ移行すること自体が目的ではありません。目的は、環境構築やスケーリングなどの負担を減らし、事業機能の変更へ集中できる状態を作ることです。
IDC Japanによれば、国内ITモダナイゼーションサービス市場は2025年の約1兆3,044億円から2030年には約2兆1,234億円へ拡大し、2025年から2030年までの年平均成長率は10.2％と予測されています。また、同社の記事では、大企業・中堅企業の約80％が依然としてレガシーシステムを稼働させていると報告されています[3]。
同記事は、短期的にはリホストが一定の需要を持つ一方、今後の成長機会はリライト、リファクタリング、マイクロサービス化、クラウドネイティブアーキテクチャを含むアプリケーションモダナイゼーションにあるとしています。さらに企業がサービスプロバイダーへ求める要素について、技術的な実行だけでなく、ビジネスプロセス変革やクラウド活用の支援が重視され、ビジネス成果が主要な購買基準になりつつあると説明しています[3]。この変化は、日本企業のクラウド・モダナイゼーションが「移すこと」から「変えること」へ移行していることを示しています。
加えて、レガシーシステムモダン化委員会総括レポートは、既存のレガシーシステムが足かせとなり、生成AIを含む最新デジタル技術との連携や組み込みが円滑に進まない問題を指摘しています。同レポートは、データを蓄積・処理するシステムが、外部環境や経営・事業の変化へ迅速かつ柔軟に追従できる必要があるとも述べています[4]。
つまり、日本企業にとってクラウド・モダナイゼーション 2.0は、単なる技術高度化ではありません。レガシー依存、人材制約、AI活用、事業変革に同時に対応するための経営課題です。
従来のクラウド・モダナイゼーションは、開始と終了が明確なプロジェクトとして管理されることが多くありました。対象システムを選び、移行計画を作り、クラウドへ移してプロジェクトを終了します。この方法は移行には適しているが、変化を継続するモデルにはなりにくいといえます。
クラウド・モダナイゼーション 2.0では、モダナイゼーションを一度限りのプロジェクトではなく、継続的な経営サイクルとして運営する必要があります。
その基本サイクルは、以下の四つの判断から構成されます。
重要なのは、すべてのシステムを同じ方法でモダナイズしないことです。業務上の差異化につながらず、変更頻度も低いシステムは、リホストやSaaSへの置き換えが合理的な場合があります。一方、顧客接点や需要予測、商品設計など、事業戦略と密接に関係する領域では、API化、データモデルの再設計、リファクタリング、クラウドネイティブ化が必要になる可能性が高いでしょう。ここでの判断基準は、「技術的に何が可能か」だけではありません。「このシステムを変えることで、どの事業能力がどれだけ速く変わるのか」です。
クラウド・モダナイゼーション 2.0を継続的に進めるためには、データ、アプリケーション、プラットフォーム、運用を個別に整備するだけでは不十分です。これらを、モダナイゼーションを繰り返し実行するための共通基盤として設計する必要があります。
データについては、クラウドへの移行件数ではなく、信頼できるデータへ必要な利用者やシステムがアクセスできる状態を目指します。Microsoft Learnは、AIと分析のためのデータについて、信頼でき、再利用しやすく、既定で安全である必要があると説明しています。また、システムやチームに分散したデータ、一貫しない標準やガバナンスが、AIと分析を、確信を持って利用することを難しくすると指摘しています[5]。
アプリケーションについては、全体を一度にマイクロサービス化するのではなく、変更頻度と事業価値が高い機能から境界を特定し、API化や疎結合化を進めます。重要なのは、アーキテクチャの形式ではなく、変更時の影響範囲を小さくし、新しい能力を迅速に接続できるようにすることです。
プラットフォームについては、個別プロジェクトごとに環境を構築するのではなく、セキュリティ、監視、デプロイ、コスト管理などの共通機能を再利用できるようにします。これにより、開発チームは基盤構築を繰り返すのではなく、事業価値を生む機能へ集中しやすくなります。
運用については、安定稼働のみを目標とするのではなく、安全な変更を繰り返せる状態を目指します。自動テスト、継続的デリバリー、可観測性、SRE、FinOpsなどは、個別の効率化施策ではありません。変更速度、信頼性、コストを同時に管理するクラウド・モダナイゼーション 2.0の運営機能です。
これらをつなぐのは、AI-Readyという状態の説明ではなく、モダナイゼーションを反復可能にする実行システムです。
クラウド・モダナイゼーション 2.0では、移行量を測る1.0の指標だけでは事業変革への貢献を判断できません。少なくとも次の三つの視点から成果を測る必要があります。
第一は、変化の速度です。事業要求からリリースまでに要する時間、変更の頻度、新しいデータやAIサービスを既存業務へ接続するまでの期間を把握します。第二は、変化の安全性です。変更失敗率、復旧までの時間、セキュリティやガバナンス上の例外数などを確認し、スピード向上がリスク増大につながっていないかを測ります。第三は、事業価値です。顧客体験、業務処理時間、収益機会、サービス利用率など、モダナイゼーション対象が目指した事業成果との関係を確認します。
これにより、クラウド費用を単なるITコストとして見るのではなく、企業の変化能力を支える投資として評価できます。
クラウド・モダナイゼーション 2.0を推進する上で、CIOには三つの意思決定が求められます。
第一は、移行プログラムからポートフォリオ経営への転換です。全システムを一律の期限と方法で移行するのではなく、事業価値、変更頻度、技術的負債、リスクを基に継続的に優先順位を更新します。第二は、プロジェクト型投資から継続的な能力投資への転換です。モダナイゼーションを一度限りの大型案件として扱うと、プロジェクト終了後に再び技術的負債が蓄積します。共通プラットフォーム、自動化、データガバナンス、エンジニアリング能力には継続的な投資が必要です。第三は、IT成果から事業成果への転換です。移行完了やクラウド利用率だけではなく、変更速度、顧客価値、業務生産性など、経営成果とのつながりを示す必要があります。
こうした転換を実現するためには、クラウド移行、アプリケーションモダナイゼーション、データ活用、AI導入を個別プロジェクトとして進めるのではなく、全体最適の観点で統合的に推進することが求められます。TCSでは、グローバルで培った大規模モダナイゼーションの知見と業界別のベストプラクティスを活用し、企業ごとの競争優位領域を見極めながら、クラウド・モダナイゼーション 2.0への変革ロードマップ策定から実行までを支援しています。単なるクラウド移行ではなく、企業が継続的に変化し続けるための能力構築を支援できることが強みです。
クラウド・モダナイゼーション 1.0は、企業をオンプレミスからクラウドへ移行させました。
しかし、AI時代にはその先が問われます。クラウド・モダナイゼーション 2.0とは、クラウド上でシステムを稼働させることではありません。事業戦略に応じてITポートフォリオを継続的に見直し、データとアプリケーションを変化させ、共通プラットフォームを再利用し、安全な変更を繰り返す企業能力を構築することです。
クラウド・モダナイゼーション 1.0の問いは、「何をクラウドへ移すか」でした。
クラウド・モダナイゼーション 2.0の問いは、「クラウドによって何を変え続けられるか」です。
AIは、この転換を促す強力な契機です。しかし、クラウド・モダナイゼーション 2.0の価値はAI導入だけに限定されません。それは、新しい技術、新しい顧客要求、新しい事業モデルへ継続的に適応するための経営基盤です。
AI-Ready Enterpriseはゴールの一つです。より本質的なゴールは、クラウドを活用して変化し続けられる企業になることなのです。
参考文献
[1] Microsoft Azure Blog, Many agents, one team: Scaling modernization on Azure (2026)
[2] Forrester Consulting, The Total Economic Impact™ Of Migrating To Microsoft Azure For AI-Readiness (2024)
[3] 日本の2.1兆円規模のITモダナイゼーションの波：レースはすでに始まっている (2026)
[4] 経済産業省「レガシーシステムモダン化委員会総括レポート ～DXの現在地とレガシーシステム脱却に向けて～」 (2025年5月28日)
[5] Microsoft Learn, Data for AI and Analytics: Guidance to set your organization’s data strategy