IT予算の60〜80%がレガシーシステムの維持・保守に消えている——これは多くの日本企業が直面している現実です。COBOLで書かれたメインフレームシステム、30年以上稼働し続ける基幹システム、ドキュメントが存在しないまま属人化した旧Javaシステム。こうしたレガシーシステムは、AI・リアルタイム分析・クラウド活用といった新技術の導入を阻むだけでなく、担当エンジニアの高齢化・採用難というビジネスリスクも招いています。2025年以降、DORA規制やNIS2指令への対応も相まって、レガシーシステムのリアーキテクチャは「いつかやるべきこと」から「今すぐ取り組むべき経営課題」へと変わりました。

本記事は、レガシーシステムのリアーキテクチャを検討しているIT部門・経営者・プロジェクトマネージャーのための完全ガイドです。リアーキテクチャの全体像から始まり、2026年時点の最新トレンドであるAI活用モダナイゼーション・ストラングラーフィグ・パターン・モジュラーモノリスへの回帰まで、進め方・費用相場・開発会社の選び方・外注方法まで、必要な情報を一つの記事に網羅しています。各テーマの詳細は子記事へのリンクからご参照ください。

レガシーシステムリアーキテクチャの全体像

レガシーシステムのリアーキテクチャとは、老朽化・複雑化・技術的負債が蓄積したシステムのアーキテクチャそのものを現代的な構造へと再設計することです。単なる機能追加やバグ修正では解決できない根本的な構造問題に対処し、将来の変化に対応できるシステム基盤を構築することを目的としています。企業のITシステムは一般的に10〜20年以上の長期間にわたって使用されますが、その間にビジネス要件の変化・技術の進化・組織変更などにより、設計当初の前提が崩れてしまうことが多々あります。

レガシーシステムが引き起こす問題は多岐にわたりますが、特に影響が大きいのは以下の4点です。

1. 維持コストの増大：ITプロジェクトの実態調査によれば、多くの大企業でIT予算の60〜80%がレガシーシステムの保守・維持費に充てられています。バグ対応・ハードウェア更新・互換性維持のためのパッチ適用などに多大なリソースが費やされ、新機能開発やデジタル変革への投資余力が失われます。

2. COBOL技術者の高齢化・採用難：日本国内で稼働するCOBOLシステムは金融機関・官公庁・製造業を中心に依然として多数存在しますが、COBOL技術者の平均年齢は年々上昇しており、新たな担い手の確保は極めて困難な状況です。担当技術者の退職により「誰も触れないシステム」が生まれるリスクは現実のものとなっています。

3. 新技術導入の技術的障壁：AI・機械学習・リアルタイム分析・クラウドネイティブなどの新技術は、モジュール化・API連携・クラウド対応が前提となっています。モノリシックなレガシーシステムはこれらの新技術との統合が困難であり、ビジネス機会の損失につながります。

4. セキュリティ・コンプライアンスリスク：古いシステムはセキュリティパッチが提供されなくなるEnd of Supportに達していることも多く、脆弱性を抱えたまま稼働し続けるリスクがあります。また、2024〜2026年にかけてDORA（デジタル運用強靱性法）やNIS2指令への対応が求められるEU圏での事業展開や、国内の個人情報保護法改正・サイバーセキュリティ基本法への対応も課題となっています。

レガシーシステムの刷新アプローチは「リアーキテクチャ」「マイグレーション」「リプレース」の3つに大別されます。それぞれの特徴を正しく理解することが、自社に最適な戦略選択の第一歩です。

リアーキテクチャ（Re-architecture）は、システムのアーキテクチャそのものを再設計することです。ビジネスロジックを保持しながら、モノリシックな構造をマイクロサービスやモジュラーモノリスへ分解する、あるいはデータ層・ビジネスロジック層・プレゼンテーション層を明確に分離するなど、システムの骨格を現代的な設計思想に基づき作り直します。影響範囲が最も広い分、完了後の拡張性・保守性・スケーラビリティの向上幅も最大です。

マイグレーション（Migration）は、システムの機能・ロジックを保ちながら、動作基盤（プラットフォーム・言語・データベース等）を別環境に移行することです。COBOLからJavaへの言語変換、オンプレミスからクラウドへの移行（リフト&シフト）などが代表例です。アーキテクチャの根本的な再設計は行わないため、移行後も技術的負債の一部は残存する点に注意が必要です。

リプレース（Replace）は、既存システムをパッケージソフトウェアやSaaSに置き換えることです。スクラッチでの再構築コストを避けながら、最新の機能・セキュリティ・サポートを享受できます。ただし、自社の業務フローをパッケージの仕様に合わせる必要があり、独自の業務プロセスがある場合は適用が難しいこともあります。

実際のプロジェクトでは、これら3つのアプローチを組み合わせて採用するケースが多く、例えば「基幹データベースはマイグレーションでクラウドへ移行しつつ、フロントエンドはリアーキテクチャでAPI対応させ、周辺業務はSaaSにリプレース」という複合戦略が一般的です。

レガシーシステムリアーキテクチャの進め方

レガシーシステムのリアーキテクチャは、他のシステム開発プロジェクトと比較して難易度が高く、失敗事例も多数報告されています。成功のカギは「現状の正確な把握」と「段階的・計画的な移行」にあります。2026年時点では、AI技術の活用が現状分析フェーズの効率化に大きく貢献しており、従来と比べて分析フェーズの工数が最大50%削減されるケースも報告されています。

2026年のレガシーモダナイゼーションの最大のトレンドは、AI（人工知能）を活用した自動コード解析・ドキュメント生成です。COBOLや旧COBOL-85等で記述された数十万行・数百万行規模のソースコードを人手でリバースエンジニアリングするのは非現実的でしたが、大規模言語モデル（LLM）を活用したコード解析ツールの登場により、既存コードのビジネスロジック抽出・フローチャート生成・依存関係マッピングが自動化できるようになっています。

AI活用によるリアーキテクチャの一般的な進め方は以下の通りです。

1. AI支援による現状分析（As-Is把握）：AIコード解析ツールを用いてレガシーコードを自動スキャンし、モジュール間の依存関係・ビジネスルール・データフローを可視化します。このフェーズの工数が従来比で最大50%削減されるとされています。
2. 技術的負債の評価・優先順位付け：分析結果をもとに、技術的負債の深刻度（変更困難度・リスク・ビジネスへの影響度）をスコアリングし、対処すべき優先順位を決定します。
3. 目標アーキテクチャの設計（To-Be設計）：現状分析と事業要件を踏まえ、移行先のアーキテクチャを設計します。マイクロサービス・モジュラーモノリス・クラウドネイティブなど、自社の規模と組織能力に合ったアーキテクチャを選択します。
4. 段階的移行計画の策定：一括移行（ビッグバン移行）ではなく、機能単位・ドメイン単位で段階的に移行するロードマップを策定します。各フェーズで旧システムと新システムを並行稼働させることで、リスクを最小化します。
5. パイロット実装・検証：ロードマップの最初のフェーズとして、影響範囲が限定的かつビジネス価値が明確な機能を選んでパイロット実装を行います。ここで得られた知見をもとに、移行計画を精緻化します。
6. 本格移行・切り替え：パイロット検証の成果を活かしながら、残りの機能を順次移行します。各フェーズでの受け入れテスト・性能テスト・セキュリティテストを徹底します。

ストラングラーフィグ・パターン（Strangler Fig Pattern）は、レガシーシステムのリアーキテクチャで最も広く採用されている段階的移行手法です。マーティン・ファウラーが提唱したこのパターンは、熱帯雨林のイチジクの木が宿主の木に巻き付きながら成長し最終的に置き換えるさまに着想を得ています。

具体的には、既存のレガシーシステムを即座に廃止するのではなく、新システムを並行して育てながら少しずつ機能を移行していきます。Webリクエストやビジネス処理の一部を新システムへルーティングするファサード（玄関口となる中間層）を設け、機能単位で切り替えを進めます。これにより「一括置換のリスク」を回避しながら、ビジネスを止めることなくリアーキテクチャを完遂できます。

ストラングラーフィグ・パターンの成功事例として、大手金融機関によるCOBOLメインフレームのクラウド移行があります。ある欧州の大手銀行では、メインフレーム上で稼働するCOBOLシステムを約7年かけてストラングラーフィグ・パターンで段階移行し、最終的に年間の運用コストを40%削減することに成功しました。国内においても製造業・流通業・保険業での導入実績が増えており、プロジェクト全体のリスクコントロールと確実な成果達成の両立に有効な手法として評価されています。

進め方の詳細については、以下の関連記事をご参照ください。

▶ レガシーシステムリアーキテクチャの進め方（詳細）

レガシーシステムリアーキテクチャ：開発会社の選び方

レガシーシステムのリアーキテクチャを成功させるうえで、開発会社の選定は極めて重要です。一般的なシステム開発とは異なり、レガシー特有の技術スキル・経験・プロジェクトマネジメント力が求められます。また、技術的な実装能力だけでなく、社内に知識を移転し長期的に自立運営できるよう伴走する力も重要な評価ポイントです。ここでは、選定基準となる主要ポイントを解説します。

開発会社の技術力を評価する際は、以下のポイントを確認することが重要です。

レガシー技術の実績：依頼するシステムに使用されているCOBOL・PL/I・FORTRAN・旧バージョンのJava/C++・AS/400（IBM i）・メインフレーム（IBM z/OS）などについて、具体的な移行実績があるかを確認します。実績のない会社では、予期しないトラブルが発生するリスクが高まります。実績の規模（コード行数・移行期間・チーム規模）もあわせて確認しましょう。

AI活用ツールの保有・運用実績：前述のとおり、2026年時点ではAIを活用したコード解析・ドキュメント自動生成が分析フェーズの効率化に大きく貢献します。自社開発または商用のAIモダナイゼーションツール（CAST Highlight、Amazon Q Developer、Azure Migrate等）の活用実績があるか確認してください。

目標アーキテクチャへの対応力：移行先のアーキテクチャ（マイクロサービス・モジュラーモノリス・クラウドネイティブ等）に対する設計・実装力を確認します。クラウドベンダー（AWS・Azure・GCP）の認定資格や、Kubernetesなどのコンテナ技術の実績も参考になります。

テスト自動化・品質保証の体制：レガシーシステムは既存テストが存在しないケースも多く、リアーキテクチャ時のリグレッションリスクが高まります。移行前の振る舞いを担保するための自動テスト構築（コンシューマー駆動契約テスト・スナップショットテスト等）の経験があるかを確認することが重要です。

レガシーシステムのリアーキテクチャは、プロジェクト終了後も社内チームが新しいアーキテクチャを継続的に運用・改善できるかどうかが、長期的な成功を左右します。開発会社を選ぶ際は、技術移転・ナレッジ共有への姿勢を必ず確認してください。

ドキュメント整備方針：移行後のシステムについて、アーキテクチャ設計書・API仕様書・運用マニュアルなどを体系的に整備する体制があるかを確認します。ドキュメントなしでは、次の技術的負債のタネを撒くことになりかねません。

社内チームへの教育・トレーニング：新しいアーキテクチャ・開発ツール・運用手順について、社内エンジニアへのトレーニングプログラムを提供できるかを確認します。ハンズオン形式でのペアプログラミングやコードレビューを通じた技術移転は、特に効果が高い手法です。

伴走型サポートの提供：本番稼働後も一定期間、開発会社がシステム運用のサポートを継続してくれるか（伴走支援）を確認します。特に移行直後の6〜12ヶ月は予期しない問題が発生しやすいため、迅速な対応体制が重要です。

開発会社の詳しい選び方・おすすめ会社については、以下の関連記事をご参照ください。

▶ レガシーシステムリアーキテクチャでおすすめの開発会社（詳細）

レガシーシステムリアーキテクチャの費用相場

レガシーシステムのリアーキテクチャ費用は、システムの規模・技術的負債の深刻度・採用するアプローチ・開発会社の体制などによって大きく異なります。一般論として「いくらかかるか」の答えは一つではありませんが、規模感の目安を把握しておくことで、予算計画・社内説明・ベンダー比較の際に役立ちます。

リアーキテクチャ費用の概算は、システムの規模（コード行数・機能数・ユーザー数・データ量）と技術的負債の深刻度によって異なります。以下は目安となる費用レンジです。

小規模（コード10万行以下・社内業務システム等）：500万〜3,000万円程度。技術的負債が比較的軽微で、1〜2年以内のプロジェクト期間を想定しています。モジュラーモノリスへのリファクタリングや、クラウドへのリフト&シフトが主なアプローチとなります。

中規模（コード10万〜100万行・部門基幹システム等）：3,000万〜1億円程度。複数の業務機能を持ち、データ移行や統合テストに相当の工数がかかります。ストラングラーフィグ・パターンを活用した段階的移行が典型的なアプローチです。プロジェクト期間は2〜4年が一般的です。

大規模（コード100万行超・全社基幹システム・金融/製造業の核心システム等）：1億〜数十億円規模。メインフレーム上のCOBOLシステムや、複数サブシステムが複雑に絡み合ったエンタープライズシステムが対象です。プロジェクト期間は5〜10年以上のロードマップとなることも多く、段階的な予算執行が現実的です。

リアーキテクチャ費用を見積もる際に見落としがちな「隠れたコスト」が存在します。表面的な開発費用だけで予算を組むと、後から予算超過が判明するリスクがあります。

現状調査・リバースエンジニアリングコスト：ドキュメントが存在しないレガシーシステムでは、コードや業務を解析するための現状調査に相当の工数が必要です。AIツールを活用しても、人手による確認・整理作業は避けられず、小規模システムでも数百万円単位のコストが発生します。

並行稼働コスト：段階的移行では、新旧システムを一定期間並行稼働させるため、インフラコスト（サーバー・クラウドリソース）と運用コスト（保守担当者のアサイン）が二重に発生します。並行稼働期間が長引くほどコスト増につながるため、移行スケジュールの管理が重要です。

ユーザートレーニング・チェンジマネジメントコスト：システムのUIや操作手順が変わることで、エンドユーザーへのトレーニングや業務マニュアルの整備が必要です。大規模システムでは、社内変革管理（チェンジマネジメント）の専門家を起用することも珍しくありません。

移行後の不具合対応コスト：本番稼働後に判明する不具合への対応費用は、プロジェクト全体費用の10〜15%程度を見込んでおくのが一般的です。特にレガシーシステムでは未文書化の業務ロジックが移行漏れになるリスクがあり、バッファを多めに確保することが重要です。

費用相場の詳細については、以下の関連記事をご参照ください。

▶ レガシーシステムリアーキテクチャの費用・コスト相場（詳細）

レガシーシステムリアーキテクチャの発注・外注方法

レガシーシステムのリアーキテクチャの発注・外注には、一般的なシステム開発にはない固有の難しさがあります。既存システムのドキュメントが不十分であることが多く、要件定義に必要な情報を正確に言語化できない状況でも発注の準備を進めなければなりません。ここでは、そのような環境での発注準備と契約モデルの選択について解説します。

レガシーシステムのリアーキテクチャにおいて、発注元が準備できる情報は限られていることが多いです。理想的な要件定義書がなくても、以下の情報を整理して提供することでRFP（提案依頼書）の品質を高めることができます。

アクセス可能な情報の棚卸し：現在の環境で利用可能なシステム情報（ソースコード・バイナリ・データベース定義・業務マニュアル・運用手順書・障害対応記録）を一覧化します。完全でなくても構いません。まず「何があるか」を把握することが出発点です。

業務の目的・課題の言語化：技術的な詳細よりも、「なぜリアーキテクチャが必要なのか」「解決したい業務上の課題は何か」「3〜5年後にどんなシステムになっていてほしいか」という目的・ゴール・現状の痛点を言語化することが重要です。RFPの質は技術仕様の詳細よりもこのビジネス要件の明確さで決まります。

スモールスタートでの現状調査委託：本格的な移行プロジェクトの前段階として、まず現状調査フェーズのみをスコープ限定で発注する方法が有効です。比較的低コスト（数百万〜数千万円）で現状分析・技術的負債評価・移行計画案の提示を受けられ、複数ベンダーへの並行依頼（競合提案）も容易です。

レガシーシステムのリアーキテクチャにおける契約モデルの選択は、プロジェクトの成否を左右する重要な判断です。一般的なシステム開発と同様、主に「請負（一括固定価格）」と「準委任（時間・材料費用）」の2つのモデルがあります。

請負契約（一括固定価格）は、成果物と費用を事前に固定する契約形態です。予算が確定しやすいメリットがありますが、レガシーシステムは事前に詳細要件が確定しにくいため、スコープ変更のたびに追加費用が発生するリスクがあります。現状調査フェーズが十分に終わり、移行スコープが明確になった段階での採用が適切です。

準委任契約（タイム&マテリアル）は、稼働時間・稼働人数に応じて費用を支払う契約形態です。不確実性が高いレガシーリアーキテクチャプロジェクトでは、柔軟にスコープ調整ができるこの契約形態が適しています。ただし、費用の上限管理が難しいため、月次のコストレビューと進捗管理体制の整備が欠かせません。

フェーズ分割型契約は、プロジェクトを現状調査・基本設計・実装・テスト・移行などのフェーズに分割し、各フェーズで成果物を確認してから次フェーズを発注する方式です。大規模なリアーキテクチャプロジェクトでは、このフェーズ分割型が特に有効で、早期に開発会社の品質・相性を見極められるほか、予算のコントロールもしやすくなります。

発注・外注方法の詳細については、以下の関連記事をご参照ください。

▶ レガシーシステムリアーキテクチャの発注・外注方法ガイド（詳細）

失敗しないためのポイント

レガシーシステムのリアーキテクチャは、IT史上最も失敗しやすいプロジェクトの一つとも言われています。世界的に見ても、大規模なシステム刷新プロジェクトの成功率は50〜60%程度とも報告されており、「完成したが期待した効果が出なかった」「途中で中断・縮小を余儀なくされた」という事例は枚挙にいとまがありません。失敗パターンを知り、事前に対策を講じることが成功への近道です。

失敗パターン1：ビッグバン移行（一括切り替え）。最も多い失敗パターンが、既存システムを一時停止して一気に新システムへ切り替える「ビッグバン移行」です。詳細な計画と十分なテストなしに実施すると、本番稼働直後に重大な不具合が発覚し、ビジネスが停止するリスクがあります。2020年代の有名事例として、某欧州銀行のITシステム移行失敗では数日間にわたってオンラインバンキングが使用不能となり、巨額の損失と顧客信頼の喪失を招きました。段階的移行（ストラングラーフィグ・パターン）の採用が基本です。

失敗パターン2：現状調査の不足。ドキュメントが乏しいレガシーシステムを十分に調査せずに移行を開始すると、移行途中で未文書化のビジネスルール・暗黙の仕様が次々と発覚し、手戻りが膨大になります。プロジェクトの初期段階で、AIツールと人手を組み合わせた徹底的な現状調査への投資が欠かせません。

失敗パターン3：スコープクリープと計画の形骸化。レガシーシステムは全社に広がる依存関係を持つことが多く、移行を進めるうちに「あの機能も移行が必要だった」「この業務ロジックも対応が必要だ」とスコープが際限なく拡大するリスクがあります。プロジェクト開始時にMVP（最小限の移行スコープ）を定義し、スコープ変更は適切な意思決定プロセスを経て管理することが重要です。

失敗パターン4：組織・人の変化への対応不足。技術的な移行が完了しても、ユーザーが新しいシステムを使いこなせなかったり、運用担当者が新しいアーキテクチャを維持できなかったりする問題が発生します。チェンジマネジメント・トレーニング・社内推進体制の整備はシステムの技術的移行と同等に重要です。

レガシーシステムのリアーキテクチャにおいて、セキュリティと規制への対応は避けて通れない重要テーマです。特に2024〜2026年にかけては、国内外のセキュリティ規制強化が顕著であり、リアーキテクチャのタイミングでのセキュリティ設計見直しが強く推奨されます。

ゼロトラストアーキテクチャへの移行：レガシーシステムの多くは「境界防御型」のセキュリティモデル（社内ネットワーク内は信頼する前提）を採用していますが、クラウド化・リモートワーク・API連携が進む現代では、ゼロトラストモデル（すべてのアクセスを検証する）への移行が求められます。リアーキテクチャのタイミングでゼロトラスト設計を組み込むことが、長期的なセキュリティ強化につながります。

DORA・NIS2規制への対応（EU圏向け事業）：EUのDORA（デジタル運用強靱性法）は2025年1月に施行され、金融機関はITシステムのレジリエンス・インシデント報告・第三者リスク管理の強化が義務化されています。NIS2指令も2024年10月に各EU加盟国で施行され、重要インフラ・デジタルサービス事業者へのサイバーセキュリティ要件が強化されました。EU圏で事業展開する企業は、リアーキテクチャの設計段階からこれらの規制要件を組み込む必要があります。

個人情報保護・データガバナンス：改正個人情報保護法（2022年全面施行）やGDPRに対応したデータ管理・暗号化・アクセス制御・データ削除機能の実装が求められます。レガシーシステムに眠るデータの棚卸しとデータガバナンスの再設計も、リアーキテクチャの重要なアジェンダです。

移行期間中のセキュリティリスク管理：新旧システムの並行稼働期間は、セキュリティの管理対象が増えるため、攻撃対象領域（アタックサーフェス）が拡大します。並行稼働期間中の脆弱性スキャン・ペネトレーションテスト・セキュリティ監視の強化が欠かせません。

まとめ

本記事では、レガシーシステムリアーキテクチャの全体像から、進め方・開発会社の選び方・費用相場・発注方法・失敗しないためのポイントまでを網羅的に解説しました。改めて要点をまとめます。

• レガシーシステムの問題はIT予算圧迫・技術者不足・新技術導入障壁・セキュリティリスクの4点に集約されます。
• リアーキテクチャの全体アプローチは、リアーキテクチャ・マイグレーション・リプレースを組み合わせた複合戦略が現実的です。
• 進め方のポイントは、AI支援による現状分析と、ストラングラーフィグ・パターンによる段階的移行の組み合わせです。分析フェーズの工数を従来比最大50%削減できるAIツールの活用は2026年時点の標準的なアプローチです。
• 開発会社の選定では、レガシー技術の実績・AI活用能力・テスト自動化力・知識移転への姿勢を総合的に評価することが重要です。
• 費用相場は小規模で500万〜3,000万円、中規模で3,000万〜1億円、大規模で1億〜数十億円が目安ですが、隠れたコスト（現状調査・並行稼働・トレーニング・移行後不具合対応）を含めたTCOで計画することが重要です。
• 発注方法は、ドキュメントが乏しい環境でも「現状調査フェーズのみのスモールスタート」「フェーズ分割型契約」を活用することで、リスクをコントロールしながら進められます。
• セキュリティ・規制対応はリアーキテクチャと同時に取り組むべき重要テーマです。ゼロトラスト移行・DORA/NIS2対応・データガバナンス強化を設計段階から組み込みましょう。

レガシーシステムのリアーキテクチャは、長期にわたる大規模プロジェクトです。一度の判断ミスが数年にわたるコスト増・開発遅延・ビジネスリスクにつながる可能性があります。各テーマの詳細は以下の関連記事で詳しく解説していますので、ぜひ合わせてご参照ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。