
レガシーとは「古いコード」ではなく
——企業が自らの過去を封印した記憶装置である
AI導入の壁は、モデルの性能ではなく、既存の業務フロー・基幹系・部門分断との不整合にある。レガシー刷新とは古いシステムを新しくすることではない。AI時代に合わせて、企業が自らの業務知識・責任分担・部門境界を再設計するための、避けて通れない準備である。
「2025年の崖」は、実は2025年に起きる問題ではなかった。本当の危機は、古いシステムが残っていることですらない。それを延命できる人も、仕様を説明できる人も、責任を取れる人も——もう消え始めていることだ。そしてAIが第三の断層として加わった今、より根本的な問いが浮かび上がる。AIを前提に業務そのものを組み替えようとしたとき、レガシーシステムはなぜこれほどの抵抗を示すのか。答えは単純だ。レガシーシステムとは、古いコードではなく、企業が過去の業務フロー・責任分担・部門境界を凍結保存した記憶装置だからである。
課題の本質:レガシーは「化石化した業務フロー」であり「化石化した組織図」でもある
経済産業省は2018年の「DXレポート」で、2025年以降に老朽化・ブラックボックス化したITシステムが経営の足枷となり、最大で年間12兆円の経済損失をもたらす可能性を示した。この警告は「システム問題」として語られることが多いが、実態は違う。問題の核心は技術的負債(過去の設計判断や実装上の妥協が積み重なり、将来の変更を困難にする状態)の累積であり、それは同時に組織的負債の累積でもある。
問題の構造は三層になっている。
第一層:技術的負債の複利効果
1980〜90年代に構築された大型ホスト(メインフレーム)やCOBOL(事務処理向けに設計された高水準プログラミング言語)で書かれた基幹系は、保守・改修を重ねるたびに「パッチの上にパッチを重ねる」構造となった。経済産業省のDXレポートでは、基幹系システムのうち稼働21年以上のものが約2割を占めると示されており、長期にわたる延命が今日の複雑性を生み出してきた。
第二層:ベンダーロックイン(特定ベンダーへの依存により他への乗り換えが困難になる状態)と内製化能力の喪失
日本の大企業ITは、特定ベンダーが長期契約でシステムを管理する「SIer依存モデル」が定着している。顧客企業のIT部門は発注・管理機能に特化し、内製化能力を失った。このモデルは安定をもたらす一方で、刷新コストと移行リスクを際限なく高め、「変えたいが変えられない」という膠着状態を構造的に生み出してきた。
第三層:AIとの非互換性——業務再設計を迫る新たな断層
2025年以降に顕在化した最も深刻な問題が、生成AI・AIエージェントとの統合障壁だ。クラウドネイティブなAPIエコノミーを前提とするAIツールは、ホスト系データベースや閉じたERPとダイレクトに連携できない。しかしより根本的な問題がある。
従来の業務は、人が判断・転記・確認する前提で設計されていた。AIにより、要約・分類・照合・起票・問い合わせ対応・ナレッジ検索などが再構成可能になった今、「どの業務を誰が担うか」という設計自体が見直し対象になる。AIを既存業務に「載せる」のではなく、AIを前提に業務そのものを組み替えること——その試みを阻む最大の障壁が、レガシーに固定された古い業務フロー・古い責任分担・古い部門境界なのだ。
なぜ企業は毎回「延命」を選ぶのか——失敗が繰り返される構造的メカニズム
技術的負債の清算と産業再編は、歴史上繰り返されてきた。しかし毎回、企業は全面刷新ではなく延命を選んできた。なぜか。そのメカニズムを二つの事例から読み解く。
事例①:1980年代米国の「ATM戦争」——勝者は刷新者ではなく接続者だった
1970〜80年代、米国の金融機関は独自開発した「第一世代ATMシステム」の更新問題に直面した。各行が異なるアーキテクチャを持ち、相互接続が取れないため、顧客は自行ATMしか使えない。全面刷新は高コストで不確実性が高く、各行は「自行システムを維持しながら様子を見る」という短期合理的な判断を続けた。
この膠着を解いたのは、CIRRUS・PLUSなどの「共同ATMネットワーク」という中間プレイヤーだった。彼らは既存システムの刷新を迫る代わりに、既存システムとAPI的に接続する「ミドルウェア層」を提供した。産業転換期の覇者は「全面刷新を迫る者」ではなく「レガシーとモダンをつなぐ層を作った者」だった。2020年代のiPaaS(Integration Platform as a Service:異なるシステムやアプリケーションを統合するクラウド基盤)市場は、まさにこの役割の現代版だ。
事例②:Y2K特需——「延命でも乗り切れる」という成功体験が刷新を遅らせた
1999年前後のY2K(2000年問題)対応は、日本のIT業界に空前のシステム刷新需要をもたらした。しかし、この「強制的な刷新」が生んだのは真の近代化ではなく、最小限の延命修正だった。それ以上に深刻だったのは、Y2Kを延命で乗り切ったことで企業に植えつけられた認識だ。
Y2Kは単なる技術危機ではなく、「延命でも乗り切れる」という成功体験を企業に植えつけた事件だった。このパターンは今も繰り返されている——クラウドに移行したが中身はレガシーのまま、という「令和のY2K対応」として。
延命が選ばれる理由は単純だ。全面刷新は高コストで不確実性が高い。短期では延命の方が合理的に見える。しかし延命は危機を回避するだけで、本質問題を次世代へ先送りする。こうして技術的負債は世代を超えて累積し、今日の「崖」を形成してきた。
| 比較軸 | ATM戦争(1970〜80s 米国) | Y2K対応(1999年) | 2025年の崖問題(2020s 日本) |
|---|---|---|---|
| 外圧の性質 | 競争優位の喪失 | 規制・期限 | AI業務再設計への遅れ |
| 企業が選んだ対応 | 様子見→ミドルウェアで接続 | 最小限の延命修正 | リフト&シフト→「クラウドのふりしたレガシー」 |
| 延命が与えた成功体験 | 「閉じたままでも戦える」 | 「パッチでも乗り切れる」 | 「移行済みで問題ない」(現在進行形) |
| 勝者のポジション | 接続インフラ提供者 | なし(延命のみ) | 業務再設計を担うインテグレーター |
今回が不可逆な理由:AIが「業務の分解・再配分」を可能にした
過去の刷新の波が本質的変化をもたらさなかったのに対し、今回は三つの不可逆な変化が同時に成立している。
変化①:AIコード変換ツールの実用化——刷新コストの崩壊
従来、COBOLからモダン言語への移行が敬遠されてきた最大の理由は「移行コストの巨大さ」だった。大規模基幹系のリライトは数十億〜数百億円、期間は5〜10年という試算が通常だった。IBMのwatsonx Code AssistantはRPG・COBOLのモダナイズと自動単体テスト生成を公式に提供し、AWSもAmazon Q Developerを通じてメインフレーム近代化支援機能を2024年末に公開プレビューとして開始した。変換後の品質保証はまだ発展途上だが、「コードを読める人間がいなくても刷新の入り口に立てる」環境が初めて整いつつある。
変化②:技術者の世代交代——延命策を担う人材の不足が深刻化する
COBOL・RPGなどのレガシー言語技術者の高齢化と担い手不足は長年指摘されており、IPAをはじめ複数の機関が継続的に警鐘を鳴らしている。2020年代後半から2030年前後にかけて、延命策を担う人材の不足が深刻化する可能性が高く、「選んで刷新できる」選択肢が「強制的に止まるか捨てるか」に変わるリスクが現実味を帯びてきた。
変化③:AIが業務の分解・再配分を可能にした——これが最も根本的な変化だ
従来の業務は、人が判断・転記・確認する前提で設計されていた。しかしAIにより、業務の構成要素が初めて分解・再配分可能になった。これは単なる効率化ではない。請求、承認、照会、報告、稟議、問い合わせといったホワイトカラー業務の単位そのものが、AIを前提に再分解されることを意味する。
- 要約・分類・照合:大量ドキュメントの処理、仕訳の自動分類、請求書照合
- 起票・ドラフト生成:報告書・提案書・メールの初稿自動生成
- 問い合わせ対応:社内FAQ・規程・マニュアルへの自律的な回答
- 例外処理のルール化:熟練者の判断パターンをAIが学習・代替
- 部門間の受け渡し削減:承認フローの一部をAIの判定で代替
つまり今回の刷新が不可逆な理由は、単にコードが古いからではない。AIによる業務再配分という根本的な変化が始まった今、レガシーに固定された業務フローを解体しない限り、競争力の源泉そのものを手に入れられないからだ。これは過去の危機とは本質的に異なる。
利益プールの移動と勝者の条件:「翻訳権」を誰が握るか
レガシーIT刷新市場の地図を描くとき、市場を「どのレイヤーに参入するか」で整理するだけでは不十分だ。より重要なのは、産業の利益プール(ある市場で生まれる利益の総量とその分布)がどこから、どこへ移動しているかを見抜くことだ。
これまで利益を生んできたのは、保守・改修・個別対応を積み上げる「ランザビジネス(現行システムの維持・運用)」だった。AIコード変換・SaaS成熟・iPaaS普及が進む今、この利益プールは「保守」から「翻訳」「統合責任」「業務再設計」へ移動しつつある。
- 価値を失うもの:工数を積み上げるだけの保守・パッチ対応・リフト&シフト型移行
- 価値が生まれるもの:業務の意味をAI/クラウドが扱える形式へ翻訳する権利
- 価値が生まれるもの:移行後の動作・品質・コストの統合責任を担う能力
- 価値が生まれるもの:業務再設計・BPR(Business Process Reengineering:業務プロセス再設計)を実装レベルで担える専門性
コード変換・解析AIツール層——勝つのは「精度の会社」ではない
COBOLやRPGをモダン言語に変換するAIツール群では、AWS・IBM・Microsoftが先行し、日本のSIer大手も自社ツールを開発している。しかしこの市場で勝者を決めるのは変換精度ではない。勝つのは「変換後の業務ロジックの意味と責任を保証できる会社」だ。コードを変換するだけでなく、業務要件との整合検証・テスト自動生成・品質保証まで一貫して提供できるプレイヤーが「翻訳権」を手にする。
マイグレーション専門サービス層——勝つのは「業務再設計の痛みを引き受けられる会社」だ
ツールだけでは移行は完結しない。負けるのは「クラウド移行を完了させた会社」であり、勝つのは「業務標準化という痛みを顧客と一緒に引き受けられる会社」だ。金融なら金融規制と業務知識、製造なら生産管理の深い理解が必要で、純粋技術企業が短期で獲得しにくい参入障壁を形成する。
インテグレーション層(iPaaS)——勝つのは「既存を活かしながら意味を再記述できる会社」だ
完全刷新が困難な企業にとって、既存システムをAPIで包み込む「ストラングラーフィグ・パターン(既存システムを新システムで少しずつ置き換えていく手法)」でAI層と接続する手法は現実的な中間解となる。MuleSoft(Salesforce)、Boomi、Informaticaなどのデータ統合・iPaaS系プレイヤーがグローバルで先行しているが、このレイヤーの真の競争優位は機能ではなく「一度フローを作り込んだ顧客との粘着性」とその積み上げによるデータ優位性にある。
SMB向け刷新パッケージ市場——勝つのは「PLGで業種の業務習慣を先に取った会社」だ
kintone(サイボウズ)、SmartHR、楽楽精算(ラクス)などのバーティカルSaaSは、「自社開発していた業務システムをSaaSに置き換える」需要を取り込んでいる。PLG(Product-Led Growth:製品自体が顧客獲得を牽引する成長戦略)によるスケールが前提だが、勝者は「業種の業務習慣をSaaSの設計に取り込んだ会社」であり、それができていないプレイヤーはカスタマイズの泥沼で消耗する。
ケーススタディ:AI時代の成功と失敗の分水嶺
みずほ銀行は2002年・2011年の2度の大規模システム障害を経て、2011年から約8年間・4,000億円超を投じて次世代勘定系システム「MINORI」を構築し、2018〜2019年にかけて段階的に移行を完了させた。富士通の技術解説では、MINORIがチャネル系・業務系・勘定系といった機能レイヤーを分離し、ESBを介したサービス連携構造を採っていることが触れられている。
「成功例」として取り上げる最大の理由は稼働したという事実だけでなく、「触れないブラックボックスの一枚岩」から「機能ごとに分離・接続できる構造」へ転換を試みた点にある。これは、将来的なAI統合のための「業務フローの再記述可能性」を確保する試みとして解釈できる。
業種を問わず、ERP刷新プロジェクトが暗礁に乗り上げる最も多いパターンは、システム技術の問題ではない。ある流通企業では、ERP導入そのものより、商品コード体系の統一でプロジェクトが止まった。営業・物流・経理がそれぞれ独自のコードを長年使っており、「標準化=自部門のやり方を捨てること」と解釈された。
標準コードへの統一は、単なるデータ整備ではない。各部門にとっては、自分たちの仕事の定義権を手放すことを意味した。「部門独自コード」の中には、その部門が何十年もかけて積み上げた業務知識が埋め込まれており、それを手放すことは、自部門の存在証明を失うことに等しかった。ITプロジェクトに見えて、実態は組織の権力構造の問題だった。
TISをはじめ複数の国内SIerが、2023〜2024年にかけてCOBOL・RPGコードの解析・変換にLLMを活用したサービスを顧客に提供し始めている。TISは「Xenlon〜神龍 モダナイゼーションサービス」としてCOBOL変換を含む近代化支援を打ち出している。こうした取り組みに共通する成功パターンは一点に集約される傾向がある。変換精度を売りにするのではなく、変換後の動作保証・テスト自動化・業務ロジックの意味検証をセットにした「翻訳責任パッケージ」として提供したことだ。顧客が恐れているのは変換失敗ではなく「変換後に業務の意味が失われること」であり、その不安を解消できるプレイヤーが案件を獲得しつつある。
生成AIを導入しても、業務フローが旧来のままなら効果は限定的どころか逆効果になることがある。ある企業では、問い合わせ対応業務にAIチャットボットを導入したが、社内の承認フローが「AIの回答を人間が確認し、承認し、転記して顧客に回答する」という構造のままだったため、AIは現場の作業量を減らすどころか、新たな確認作業を増やした。
AI導入に失敗する企業の多くは、AIモデルの性能ではなく、旧来の承認フローと部門分断を前提にしたまま導入している。成功した企業が共通して行っていることは、AIの導入前に「このフローのどのステップは人でなければならないか」を問い直し、業務設計そのものを変えることだ。
結論:企業の「自己再定義能力」が競争力になる時代
レガシーIT刷新市場は一過性の需要ではなく、10〜15年続く産業構造転換の序章だ。しかしここで重要なのは、この市場を「ITの更新市場」として見ることをやめることだ。本質は業務と責任の再設計市場であり、勝者は最新技術を持つ企業ではなく、複雑な業務の意味をAI時代の言語に翻訳できる企業だ。
📌 投資視点からのアクション
📌 事業参入視点からのアクション
📌 スキル獲得視点からのアクション
参考文献
- 経済産業省(2018)「DXレポート〜ITシステム『2025年の崖』克服とDXの本格的な展開〜」. https://www.meti.go.jp/policy/it_policy/dx/20180907_02.pdf
- 経済産業省(2018)「DXレポート(サマリー)」. https://www.meti.go.jp/policy/it_policy/dx/20180907_01.pdf
- IPA(2024)「DX動向2024」独立行政法人情報処理推進機構. https://www.ipa.go.jp/digital/chousa/dx-trend/
- 中小企業庁(2024)「2024年版中小企業白書 第4章第7節 DX」. https://www.chusho.meti.go.jp/pamflet/hakusyo/2024/
- みずほフィナンシャルグループ(2019)「次世代勘定系システム『MINORI』の全面稼働について」プレスリリース.
- 富士通株式会社(2020)「みずほ新勘定系システム『MINORI』を活用したAPI連携」. https://jp.fujitsu.com/family/article_m/2020/pdf/2020-06.pdf
- IBM(2024)"watsonx Code Assistant for Z." IBM Products Documentation.
- Amazon Web Services(2024)「メインフレームのモダナイゼーション向け Amazon Q Developer」. https://aws.amazon.com/jp/about-aws/whats-new/2024/12/amazon-q-developer-transformation-mainframe-modernization/
- TIS株式会社(2024)「Xenlon〜神龍 モダナイゼーションサービス」. https://www.tis.co.jp/news/2024/tis_news/20241003_1.html
- Fowler, M.(2004)"Strangler Fig Application." martinfowler.com. https://martinfowler.com/bliki/StranglerFigApplication.html
- Gartner(2024)"Market Guide for Application Modernization and Migration Services." Gartner Research.
- 野村総合研究所(2023)「ITロードマップ2024年版」東洋経済新報社.


