IT予算の60〜80%が保守に費やされる状況を改めるには、レガシーシステムの現状把握と段階的な移行を軸に計画することが欠かせません。
本記事は、レガシーシステムのリアーキテクチャを検討しているIT部門・経営者・プロジェクトマネージャーのための完全ガイドです。全体像から進め方、費用相場、開発会社の選び方、発注・外注方法までを、2026年時点の最新トレンドも含めてまとめています。各テーマの詳細は、子記事へのリンクからご参照ください。
▼ 関連記事一覧
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステムリアーキテクチャの全体像
レガシーシステムのリアーキテクチャとは、老朽化・複雑化・技術的負債が蓄積したシステムのアーキテクチャそのものを、現代的な構造へ再設計することです。
リアーキテクチャの目的は、機能追加やバグ修正では解決できない根本的な構造問題に対処し、将来の変化に対応できるシステム基盤を築くことにあります。
企業のITシステムは、一般に10〜20年以上、長いものでは30年にわたって使われます。その間にビジネス要件の変化や技術の進化、組織変更が重なり、設計当初の前提が崩れてしまうことが多くあります。
レガシーシステムが抱える問題
レガシーシステムが引き起こす問題は多岐にわたりますが、特に影響が大きいのは、保守費・人材・新技術・セキュリティの4つの面です。いずれも事業の足かせになります。
- 維持コストの増大：多くの大企業では、IT予算の60〜80%が保守・維持費に充てられています。
- COBOL技術者の高齢化・採用難：国内の金融機関・官公庁・製造業では、COBOLシステムが今も多数稼働しています。
- 新技術導入の技術的障壁：AIやクラウドネイティブなどの新技術を取り込みにくい状態です。
- セキュリティ・コンプライアンスリスク：脆弱性を抱えたまま稼働し続けるおそれがあります。
保守では、バグ対応やハードウェア更新、互換性維持のためのパッチ適用などに多大なリソースが割かれ、新機能開発やデジタル変革への投資余力が失われます。
COBOL技術者の平均年齢は年々上昇しており、新たな担い手の確保は極めて困難です。担当技術者が退職すると「誰も触れないシステム」が生まれかねず、そのリスクは現実のものとなっています。
新技術は、モジュール化・API連携・クラウド対応を前提としています。このため、モノリシックなレガシーシステムは新技術との統合が難しく、ビジネス機会の損失につながります。
古いシステムは、セキュリティパッチが提供されなくなるEnd of Supportに達していることも多くあります。
セキュリティ面では、2024〜2026年にかけてEU圏で事業を展開する場合、DORA（デジタル運用強靱性法）やNIS2指令への対応が求められます。
国内では、個人情報保護法改正やサイバーセキュリティ基本法への対応も課題になっています。
リアーキテクチャ・マイグレーション・リプレースの違い
レガシーシステムの刷新アプローチは、「リアーキテクチャ」「マイグレーション」「リプレース」の3つに大別されます。それぞれの特徴を理解することが、自社に合う戦略を選ぶ第一歩です。
- リアーキテクチャ（Re-architecture）：システムの構造そのものを再設計することです。
- マイグレーション（Migration）：機能やロジックを保ったまま、動作基盤を別環境に移すことです。
- リプレース（Replace）：既存システムを、パッケージソフトウェアやSaaSに置き換えることです。
ビジネスロジックを保ったまま、モノリシックな構造をマイクロサービスやモジュラーモノリスへ分解したり、データ層・ビジネスロジック層・プレゼンテーション層を明確に分けたりします。影響範囲は最も広くなりますが、完了後の拡張性・保守性・スケーラビリティの向上幅も最大です。
動作基盤（プラットフォーム・言語・データベース等）の移行が中心です。COBOLからJavaへの言語変換や、オンプレミスからクラウドへの移行（リフト&シフト）などが代表例です。アーキテクチャを根本から再設計するわけではないため、移行後も技術的負債の一部が残る点に注意が必要です。
スクラッチでの再構築コストを避けながら、最新の機能・セキュリティ・サポートを利用できます。ただし、自社の業務フローをパッケージの仕様に合わせる必要があり、独自の業務プロセスがある場合は適用が難しいこともあります。
実際のプロジェクトでは、3つのアプローチを組み合わせるケースが多いです。たとえば「基幹データベースはマイグレーションでクラウドへ移行しつつ、フロントエンドはリアーキテクチャでAPI対応させ、周辺業務はSaaSにリプレース」という複合戦略が一般的です。
レガシーシステムリアーキテクチャの進め方
レガシーシステムのリアーキテクチャは、他のシステム開発プロジェクトと比べて難易度が高く、失敗事例も多く報告されています。
成功のカギは「現状の正確な把握」と「段階的・計画的な移行」にあります。
2026年時点では、AI技術の活用が現状分析フェーズの効率化に大きく貢献しています。従来と比べて分析フェーズの工数が最大50%削減されたケースも報告されています。
AI活用による現状分析と段階的移行
2026年のレガシーモダナイゼーションで最大のトレンドは、AI（人工知能）を活用した自動コード解析・ドキュメント生成です。
COBOLや旧COBOL-85などで書かれた数十万行・数百万行規模のソースコードを、人手でリバースエンジニアリングするのは非現実的でした。しかし、大規模言語モデル（LLM）を使ったコード解析ツールの登場により、既存コードのビジネスロジック抽出、フローチャート生成、依存関係マッピングを自動化できるようになっています。
作業は、おおむね次の順で進みます。
ストラングラーフィグ・パターンの活用
ストラングラーフィグ・パターン（Strangler Fig Pattern）は、レガシーシステムのリアーキテクチャで最も広く採用されている段階的移行の手法です。マーティン・ファウラーが提唱したこのパターンは、熱帯雨林のイチジクの木が宿主の木に巻き付きながら成長し、最後には置き換えてしまう様子に着想を得ています。
- 移行の方法：既存システムを即座に廃止せず、新システムへ機能を少しずつ移します。
- 効果：これにより「一括置換のリスク」を避けながら、ビジネスを止めずにリアーキテクチャを完遂できます。
- 成功事例：大手金融機関によるCOBOLメインフレームのクラウド移行があります。
移行では、Webリクエストやビジネス処理の一部を新システムへ振り分けるファサード（玄関口となる中間層）を設け、機能単位で切り替えを進めます。
ある欧州の大手銀行では、メインフレーム上のCOBOLシステムを約7年かけて段階移行し、最終的に年間の運用コストを40%削減しました。
国内でも製造業・流通業・保険業での導入実績が増えており、プロジェクト全体のリスクコントロールと確実な成果達成の両立に有効な手法として評価されています。
進め方の詳しい内容は、関連記事で解説しています。
レガシーシステムリアーキテクチャ：開発会社の選び方
レガシーシステムのリアーキテクチャを成功させるうえで、開発会社の選定は極めて重要です。一般的なシステム開発と違い、レガシー特有の技術スキル・経験・プロジェクトマネジメント力が求められます。
開発会社には、技術的な実装能力に加えて、社内に知識を移し、長期的に自立して運営できるよう伴走する力も必要です。その点も、選定時の重要な材料になります。
レガシー特有の技術力確認ポイント
開発会社の技術力を見るときは、次の4つを確認します。
- レガシー技術の実績：依頼するシステムで使われている技術の移行実績を見ます。
- AI活用ツールの保有・運用実績：コード解析や文書の自動生成に使った経験の有無です。
- 目標アーキテクチャへの対応力：移行先の構成に応えられるかどうかです。
- テスト自動化・品質保証の体制：移行時の品質を支える自動テストの経験です。
COBOL・PL/I・FORTRAN・旧バージョンのJava/C++・AS/400（IBM i）・メインフレーム（IBM z/OS）などが対象です。実績がない会社では、予期しないトラブルが起きるリスクが高まります。実績の規模（コード行数・移行期間・チーム規模）も、あわせて確認しましょう。
2026年時点では、AIによるコード解析やドキュメントの自動生成が分析フェーズの効率化に大きく貢献します。自社開発または商用のAIモダナイゼーションツール（CAST Highlight、Amazon Q Developer、Azure Migrate等）の活用実績があるかどうかが、判断の材料になります。
移行先のアーキテクチャ（マイクロサービス、モジュラーモノリス、クラウドネイティブなど）に対する設計・実装力を確認します。クラウドベンダー（AWS・Azure・GCP）の認定資格や、Kubernetesなどのコンテナ技術の実績も参考になります。
レガシーシステムには既存テストが存在しないケースも多く、リアーキテクチャ時のリグレッションリスクが高まります。コンシューマー駆動契約テストやスナップショットテストなど、移行前の振る舞いを担保する自動テストの経験があるかどうかが要点です。
知識移転・伴走力の評価
レガシーシステムのリアーキテクチャは、プロジェクト終了後も社内チームが新しいアーキテクチャを運用・改善できるかどうかで、長期的な成否が決まります。
開発会社を選ぶ際は、技術移転やナレッジ共有への姿勢を必ず確認してください。
- ドキュメント整備方針：移行後の文書を体系的に整える体制があるかどうかです。
- 社内チームへの教育・トレーニング：社内エンジニア向けの研修を提供できるかどうかです。
- 伴走型サポートの提供：本番稼働後も一定期間、運用を支援し続けるか（伴走支援）です。
アーキテクチャ設計書、API仕様書、運用マニュアルなどが対象です。ドキュメントがなければ、次の技術的負債の種をまいてしまうことになりかねません。
新しいアーキテクチャや開発ツール、運用手順が研修の対象です。ハンズオン形式のペアプログラミングやコードレビューを通じた技術移転は、なかでも効果の高い手法です。
特に移行直後の6〜12ヶ月は予期しない問題が起きやすいため、迅速な対応体制が欠かせません。
開発会社の詳しい選び方やおすすめ会社は、関連記事で解説しています。
▶ レガシーシステムリアーキテクチャでおすすめの開発会社（詳細）
レガシーシステムリアーキテクチャの費用相場
レガシーシステムのリアーキテクチャ費用は、システムの規模、技術的負債の深刻度、採用するアプローチ、開発会社の体制などによって大きく変わります。
「いくらかかるか」に一律の答えはありませんが、規模感の目安を知っておくと、予算計画や社内説明、ベンダー比較に役立ちます。
規模別・技術的負債の深刻度別費用
リアーキテクチャ費用の概算は、システムの規模（コード行数・機能数・ユーザー数・データ量）と技術的負債の深刻度によって変わります。以下は、規模ごとの目安となる費用レンジです。
- 小規模（コード10万行以下・社内業務システム等）：500万〜3,000万円程度です。
- 中規模（コード10万〜100万行・部門基幹システム等）：3,000万〜1億円程度です。
- 大規模（コード100万行超・全社基幹システム・金融/製造業の核心システム等）：1億〜数十億円規模です。
技術的負債は比較的軽微で、1〜2年以内のプロジェクト期間を想定しています。モジュラーモノリスへのリファクタリングや、クラウドへのリフト&シフトが主なアプローチになります。
複数の業務機能を持ち、データ移行や統合テストに相当の工数がかかります。ストラングラーフィグ・パターンを活用した段階的移行が典型的なアプローチで、プロジェクト期間は2〜4年が一般的です。
メインフレーム上のCOBOLシステムや、複数のサブシステムが複雑に絡み合ったエンタープライズシステムが対象になります。プロジェクト期間は5〜10年以上のロードマップになることも多く、段階的に予算を執行するのが現実的です。
隠れたコストと総所有コスト（TCO）
リアーキテクチャ費用を見積もる際は、見落としがちな「隠れたコスト」にも目を向ける必要があります。表面的な開発費用だけで予算を組むと、後から予算超過が判明するリスクがあります。
- 現状調査・リバースエンジニアリングコスト：ドキュメントがない環境で、解析に相当の工数がかかります。
- 並行稼働コスト：新旧システムを一定期間同時に動かす分の費用です。
- ユーザートレーニング・チェンジマネジメントコスト：操作が変わる利用者への研修や対応にかかる費用です。
- 移行後の不具合対応コスト：プロジェクト全体費用の10〜15%程度を見込むのが一般的です。
AIツールを使っても人手による確認・整理作業は避けられず、小規模システムでも数百万円単位のコストが発生します。
段階的移行では、インフラコスト（サーバー・クラウドリソース）と運用コスト（保守担当者のアサイン）が二重に発生します。並行稼働期間が長引くほどコストは増えるため、移行スケジュールの管理が重要です。
システムのUIや操作手順が変わると、エンドユーザーへの研修や業務マニュアルの整備が必要になります。大規模システムでは、社内の変革管理（チェンジマネジメント）を担う専門家を起用することも珍しくありません。
この費用は、本番稼働後に判明する不具合への対応に充てるものです。特にレガシーシステムでは、未文書化の業務ロジックが移行から漏れるおそれがあるため、バッファを多めに確保しておくことが大切です。
費用相場の詳細は、関連記事で解説しています。
▶ レガシーシステムリアーキテクチャの費用・コスト相場（詳細）
レガシーシステムリアーキテクチャの発注・外注方法
レガシーシステムのリアーキテクチャの発注・外注には、一般的なシステム開発にはない固有の難しさがあります。
既存システムのドキュメントが不十分なことも多く、要件定義に必要な情報を正確に言葉にできないまま、発注の準備を進めなければならない場合があります。
そこで、ドキュメントがない環境での発注準備と、契約モデルの選択について見ていきます。
ドキュメントなし環境での発注準備
レガシーシステムのリアーキテクチャでは、発注元が準備できる情報が限られていることが多いです。
理想的な要件定義書がなくても、次の3点を押さえると、RFP（提案依頼書）の質を高められます。
- 使える情報の洗い出し：利用できるシステム情報を一覧にまとめる作業です。
- 業務の目的・課題の言語化：技術の詳細より、ビジネス上の目的を先に整理します。
- スモールスタートでの現状調査委託：本格移行の前に、現状調査だけを範囲を限って発注する方法です。
一覧にする対象は、ソースコード、バイナリ、データベース定義、業務マニュアル、運用手順書、障害対応記録などです。完全でなくても構いません。まず「何があるか」を把握することが出発点です。
「なぜリアーキテクチャが必要なのか」「解決したい業務上の課題は何か」「3〜5年後にどんなシステムになっていてほしいか」を言葉にすることが大切です。RFPの質は、技術仕様の詳細よりもこのビジネス要件の明確さで決まります。
比較的低コスト（数百万〜数千万円）で、現状分析・技術的負債の評価・移行計画案の提示を受けられ、複数ベンダーへの並行依頼（競合提案）も容易です。
契約モデルの選択
レガシーシステムのリアーキテクチャでは、契約モデルの選択がプロジェクトの成否を左右する重要な判断です。
一般的なシステム開発と同様に、「請負」と「準委任」が基本の契約モデルです。
- 請負契約（一括固定価格）：成果物と費用を事前に固定する契約形態です。
- 準委任契約（タイム&マテリアル）：稼働時間や稼働人数に応じて費用を支払う形態です。
- フェーズ分割型契約：各フェーズの成果物を確認してから、次のフェーズを発注する方式です。
予算が確定しやすいという利点がありますが、レガシーシステムは事前に詳細要件が確定しにくいため、スコープが変わるたびに追加費用が発生するリスクがあります。現状調査が十分に終わり、移行スコープが明確になった段階での採用が適切です。
不確実性の高いレガシーのリアーキテクチャでは、スコープを柔軟に調整できるこの形態が適しています。ただし、費用の上限を管理しにくいため、月次のコストレビューと進捗管理の体制が欠かせません。
プロジェクトを現状調査・基本設計・実装・テスト・移行などのフェーズに分けます。大規模なプロジェクトでは特に有効で、開発会社の品質や相性を早期に見極められるほか、予算のコントロールもしやすくなります。
契約と発注の詳しい流れは、関連記事で解説しています。
▶ レガシーシステムリアーキテクチャの発注・外注方法ガイド（詳細）
失敗しないためのポイント
レガシーシステムのリアーキテクチャは、IT史上でも特に失敗しやすいプロジェクトの一つだといわれています。世界的に見ても、大規模なシステム刷新の成功率は50〜60%程度とも報告されています。「完成したが期待した効果が出なかった」「途中で中断・縮小を余儀なくされた」という事例も少なくありません。
失敗パターンを知り、事前に対策を講じることが、成功への近道です。
よくある失敗パターン
失敗は、移行の方式、現状把握、範囲の管理、組織の4つの面で起きやすくなります。
- 失敗パターン1：ビッグバン移行（一括切り替え）：既存システムを一度に止めて切り替える、最も多い方式です。
- 失敗パターン2：現状調査の不足：ドキュメントが乏しいまま、十分に調べずに移行を始めます。
- 失敗パターン3：スコープクリープと計画の形骸化：対象範囲が際限なく広がり、計画が形だけになります。
- 失敗パターン4：組織・人の変化への対応不足：技術的な移行が終わっても、利用者が新しいシステムを使いこなせず、運用担当者が維持できないことがあります。
詳細な計画と十分なテストがないと、本番直後に重大な不具合が発覚するおそれがあります。2020年代の事例では、某欧州銀行の移行失敗で数日間オンラインバンキングが使えなくなり、巨額の損失と顧客の信頼喪失を招きました。段階的移行（ストラングラーフィグ・パターン）が基本です。
途中で未文書化のビジネスルールや暗黙の仕様が次々と見つかり、手戻りが膨大になります。プロジェクトの初期段階で、AIツールと人手を組み合わせた徹底的な現状調査に投資する必要があります。
レガシーシステムは全社に広がる依存関係を持つことが多く、移行を進めるうちに「あの機能も必要だった」「この業務ロジックにも対応が必要だ」といった要求が積み重なります。
プロジェクト開始時に最小限の移行範囲（MVP）を定め、変更は適切な意思決定を経て管理することが重要です。
チェンジマネジメント、トレーニング、社内の推進体制の整備は、技術的な移行と同じくらい大切です。
セキュリティ・規制対応
レガシーシステムのリアーキテクチャでは、セキュリティと規制への対応を避けて通れません。特に2024〜2026年にかけては国内外で規制が強まっており、リアーキテクチャの時期にセキュリティ設計を見直すことが強く推奨されます。
- ゼロトラストアーキテクチャへの移行：社内は信頼するという前提からの転換が課題です。
- DORA（デジタル運用強靱性法）への対応（EU圏向け事業）：2025年1月に施行されました。
- NIS2指令への対応（EU圏向け事業）：2024年10月に各EU加盟国で施行されました。
- 個人情報保護・データガバナンス：データの扱い方を、法制度に合わせて整える課題です。
- 移行期間中のセキュリティリスク管理：並行稼働の間は、管理すべき対象が増えます。
レガシーシステムの多くは「境界防御型」（社内ネットワーク内は信頼する前提）のセキュリティモデルを採用しています。しかし、クラウド化・リモートワーク・API連携が進む現在では、すべてのアクセスを検証するゼロトラストモデルへの移行が求められます。リアーキテクチャの時点でゼロトラスト設計を組み込むことが、長期的なセキュリティ強化につながります。
DORAでは、金融機関にITシステムのレジリエンス、インシデント報告、第三者リスク管理の強化が義務づけられています。
重要インフラやデジタルサービス事業者へのサイバーセキュリティ要件が強化されました。EU圏で事業を展開する企業は、リアーキテクチャの設計段階からこれらの規制要件を組み込む必要があります。
改正個人情報保護法（2022年全面施行）やGDPRに対応して、データ管理・暗号化・アクセス制御・データ削除機能を実装する必要があります。レガシーシステムに眠るデータを洗い出し、データガバナンスを再設計することも、リアーキテクチャの重要な課題です。
その分、攻撃対象領域（アタックサーフェス）も広がるため、並行稼働期間中は、脆弱性スキャン、ペネトレーションテスト、セキュリティ監視を強化する必要があります。
まとめ
全体像から進め方、開発会社の選び方、費用相場、発注・外注方法、失敗しないためのポイントまでを解説してきました。要点は次のとおりです。
レガシーシステムのリアーキテクチャは、長期にわたる大規模プロジェクトです。一度の判断ミスが、数年にわたるコスト増や開発遅延、ビジネスリスクにつながるおそれがあります。
各テーマの詳細は、以下の関連記事で解説しています。
開発を相談する前に読みたい資料は、無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブックと【2026年最新版】AI駆動開発の完全ガイドブックです。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。