eternal-studentのブログ

様々な便利なWebツールや知的に面白いコンテンツを共有しています。

レガシーとは「古いコード」ではなく ——企業が自らの過去を封印した記憶装置である

 

 
AI Era · Business Redesign · Legacy Modernization

レガシーとは「古いコード」ではなく
——企業が自らの過去を封印した記憶装置である

AI導入の壁は、モデルの性能ではなく、既存の業務フロー・基幹系・部門分断との不整合にある。レガシー刷新とは古いシステムを新しくすることではない。AI時代に合わせて、企業が自らの業務知識・責任分担・部門境界を再設計するための、避けて通れない準備である。

「2025年の崖」は、実は2025年に起きる問題ではなかった。本当の危機は、古いシステムが残っていることですらない。それを延命できる人も、仕様を説明できる人も、責任を取れる人も——もう消え始めていることだ。そしてAIが第三の断層として加わった今、より根本的な問いが浮かび上がる。AIを前提に業務そのものを組み替えようとしたとき、レガシーシステムはなぜこれほどの抵抗を示すのか。答えは単純だ。レガシーシステムとは、古いコードではなく、企業が過去の業務フロー・責任分担・部門境界を凍結保存した記憶装置だからである。

Section 01

課題の本質:レガシーは「化石化した業務フロー」であり「化石化した組織図」でもある

経済産業省は2018年の「DXレポート」で、2025年以降に老朽化・ブラックボックス化したITシステムが経営の足枷となり、最大で年間12兆円の経済損失をもたらす可能性を示した。この警告は「システム問題」として語られることが多いが、実態は違う。問題の核心は技術的負債(過去の設計判断や実装上の妥協が積み重なり、将来の変更を困難にする状態)の累積であり、それは同時に組織的負債の累積でもある。

レガシーシステムは「化石化した業務フロー」である。さらに言えば「化石化した組織図」でもある。古いコードには、当時の部門間の力関係、責任の押しつけ合い、例外処理の積み重ねが刻まれている。だから刷新は、技術問題である前に組織設計の問題になる。

問題の構造は三層になっている。

第一層:技術的負債の複利効果

1980〜90年代に構築された大型ホスト(メインフレーム)やCOBOL(事務処理向けに設計された高水準プログラミング言語)で書かれた基幹系は、保守・改修を重ねるたびに「パッチの上にパッチを重ねる」構造となった。経済産業省のDXレポートでは、基幹系システムのうち稼働21年以上のものが約2割を占めると示されており、長期にわたる延命が今日の複雑性を生み出してきた。

第二層:ベンダーロックイン(特定ベンダーへの依存により他への乗り換えが困難になる状態)と内製化能力の喪失

日本の大企業ITは、特定ベンダーが長期契約でシステムを管理する「SIer依存モデル」が定着している。顧客企業のIT部門は発注・管理機能に特化し、内製化能力を失った。このモデルは安定をもたらす一方で、刷新コストと移行リスクを際限なく高め、「変えたいが変えられない」という膠着状態を構造的に生み出してきた。

第三層:AIとの非互換性——業務再設計を迫る新たな断層

2025年以降に顕在化した最も深刻な問題が、生成AI・AIエージェントとの統合障壁だ。クラウドネイティブなAPIエコノミーを前提とするAIツールは、ホスト系データベースや閉じたERPとダイレクトに連携できない。しかしより根本的な問題がある。

従来の業務は、人が判断・転記・確認する前提で設計されていた。AIにより、要約・分類・照合・起票・問い合わせ対応・ナレッジ検索などが再構成可能になった今、「どの業務を誰が担うか」という設計自体が見直し対象になる。AIを既存業務に「載せる」のではなく、AIを前提に業務そのものを組み替えること——その試みを阻む最大の障壁が、レガシーに固定された古い業務フロー・古い責任分担・古い部門境界なのだ。

基幹系に精通した60代のSEが定年退職した翌年、夜間バッチが原因不明のエラーで止まった。ソースコードはあるが、変数名は略号だらけで現在の業務ロジックと一致しない。「触れる人間がいない」という判断のもと、その処理だけ手動運用に切り替えられた。問題はコードではなかった。そのコードに閉じ込められた「誰が何を判断し、何を転記し、誰が承認する」という業務の設計そのものが、もはや誰にも読み解けなくなっていたことだった。
Section 02

なぜ企業は毎回「延命」を選ぶのか——失敗が繰り返される構造的メカニズム

技術的負債の清算と産業再編は、歴史上繰り返されてきた。しかし毎回、企業は全面刷新ではなく延命を選んできた。なぜか。そのメカニズムを二つの事例から読み解く。

事例①:1980年代米国の「ATM戦争」——勝者は刷新者ではなく接続者だった

1970〜80年代、米国の金融機関は独自開発した「第一世代ATMシステム」の更新問題に直面した。各行が異なるアーキテクチャを持ち、相互接続が取れないため、顧客は自行ATMしか使えない。全面刷新は高コストで不確実性が高く、各行は「自行システムを維持しながら様子を見る」という短期合理的な判断を続けた。

この膠着を解いたのは、CIRRUS・PLUSなどの「共同ATMネットワーク」という中間プレイヤーだった。彼らは既存システムの刷新を迫る代わりに、既存システムとAPI的に接続する「ミドルウェア層」を提供した。産業転換期の覇者は「全面刷新を迫る者」ではなく「レガシーとモダンをつなぐ層を作った者」だった。2020年代のiPaaS(Integration Platform as a Service:異なるシステムやアプリケーションを統合するクラウド基盤)市場は、まさにこの役割の現代版だ。

事例②:Y2K特需——「延命でも乗り切れる」という成功体験が刷新を遅らせた

1999年前後のY2K(2000年問題)対応は、日本のIT業界に空前のシステム刷新需要をもたらした。しかし、この「強制的な刷新」が生んだのは真の近代化ではなく、最小限の延命修正だった。それ以上に深刻だったのは、Y2Kを延命で乗り切ったことで企業に植えつけられた認識だ。

当時のある金融機関では、Y2K対応に投じた数十億円の大半が「現行コードを変えずに動かし続けるための検証作業」に消えた。システム構造は何も変わらず、「問題は解決した」という安堵感だけが残った。その後の経営陣の口癖は「前回も乗り切った。今回も何とかなる」だった。2005年以降のオープン系移行で、その代償を払うことになる。

Y2Kは単なる技術危機ではなく、「延命でも乗り切れる」という成功体験を企業に植えつけた事件だった。このパターンは今も繰り返されている——クラウドに移行したが中身はレガシーのまま、という「令和のY2K対応」として。

延命が選ばれる理由は単純だ。全面刷新は高コストで不確実性が高い。短期では延命の方が合理的に見える。しかし延命は危機を回避するだけで、本質問題を次世代へ先送りする。こうして技術的負債は世代を超えて累積し、今日の「崖」を形成してきた。

比較軸 ATM戦争(1970〜80s 米国) Y2K対応(1999年) 2025年の崖問題(2020s 日本)
外圧の性質 競争優位の喪失 規制・期限 AI業務再設計への遅れ
企業が選んだ対応 様子見→ミドルウェアで接続 最小限の延命修正 リフト&シフト→「クラウドのふりしたレガシー」
延命が与えた成功体験 「閉じたままでも戦える」 「パッチでも乗り切れる」 「移行済みで問題ない」(現在進行形)
勝者のポジション 接続インフラ提供者 なし(延命のみ) 業務再設計を担うインテグレーター
Section 03

今回が不可逆な理由:AIが「業務の分解・再配分」を可能にした

過去の刷新の波が本質的変化をもたらさなかったのに対し、今回は三つの不可逆な変化が同時に成立している。

変化①:AIコード変換ツールの実用化——刷新コストの崩壊

従来、COBOLからモダン言語への移行が敬遠されてきた最大の理由は「移行コストの巨大さ」だった。大規模基幹系のリライトは数十億〜数百億円、期間は5〜10年という試算が通常だった。IBMのwatsonx Code AssistantはRPG・COBOLのモダナイズと自動単体テスト生成を公式に提供し、AWSもAmazon Q Developerを通じてメインフレーム近代化支援機能を2024年末に公開プレビューとして開始した。変換後の品質保証はまだ発展途上だが、「コードを読める人間がいなくても刷新の入り口に立てる」環境が初めて整いつつある

変化②:技術者の世代交代——延命策を担う人材の不足が深刻化する

COBOL・RPGなどのレガシー言語技術者の高齢化と担い手不足は長年指摘されており、IPAをはじめ複数の機関が継続的に警鐘を鳴らしている。2020年代後半から2030年前後にかけて、延命策を担う人材の不足が深刻化する可能性が高く、「選んで刷新できる」選択肢が「強制的に止まるか捨てるか」に変わるリスクが現実味を帯びてきた

変化③:AIが業務の分解・再配分を可能にした——これが最も根本的な変化だ

従来の業務は、人が判断・転記・確認する前提で設計されていた。しかしAIにより、業務の構成要素が初めて分解・再配分可能になった。これは単なる効率化ではない。請求、承認、照会、報告、稟議、問い合わせといったホワイトカラー業務の単位そのものが、AIを前提に再分解されることを意味する。

📊 AIが可能にする業務の再配分(概念整理)
  • 要約・分類・照合:大量ドキュメントの処理、仕訳の自動分類、請求書照合
  • 起票・ドラフト生成:報告書・提案書・メールの初稿自動生成
  • 問い合わせ対応:社内FAQ・規程・マニュアルへの自律的な回答
  • 例外処理のルール化:熟練者の判断パターンをAIが学習・代替
  • 部門間の受け渡し削減:承認フローの一部をAIの判定で代替
AI時代の本質は、人を置き換えることではない。人・システム・AIのあいだで、どの判断とどの作業を誰に割り振るかを再設計することにある。そしてレガシーシステムとは、この再設計を阻む「古い業務フローの固定装置」として立ちはだかる。

つまり今回の刷新が不可逆な理由は、単にコードが古いからではない。AIによる業務再配分という根本的な変化が始まった今、レガシーに固定された業務フローを解体しない限り、競争力の源泉そのものを手に入れられないからだ。これは過去の危機とは本質的に異なる。

Section 04

利益プールの移動と勝者の条件:「翻訳権」を誰が握るか

レガシーIT刷新市場の地図を描くとき、市場を「どのレイヤーに参入するか」で整理するだけでは不十分だ。より重要なのは、産業の利益プール(ある市場で生まれる利益の総量とその分布)がどこから、どこへ移動しているかを見抜くことだ。

これまで利益を生んできたのは、保守・改修・個別対応を積み上げる「ランザビジネス(現行システムの維持・運用)」だった。AIコード変換・SaaS成熟・iPaaS普及が進む今、この利益プールは「保守」から「翻訳」「統合責任」「業務再設計」へ移動しつつある。

📈 利益プールの移動:何が価値を持たなくなり、何が価値を持つか
  • 価値を失うもの:工数を積み上げるだけの保守・パッチ対応・リフト&シフト型移行
  • 価値が生まれるもの:業務の意味をAI/クラウドが扱える形式へ翻訳する権利
  • 価値が生まれるもの:移行後の動作・品質・コストの統合責任を担う能力
  • 価値が生まれるもの:業務再設計・BPR(Business Process Reengineering:業務プロセス再設計)を実装レベルで担える専門性
レガシー刷新市場の本質は、新しいシステムを売る市場ではない。既存業務の意味を、AIとクラウドが扱える形式へ「翻訳する権利」を誰が握るかの市場である。交渉力を持つのは、コードを書ける企業ではなく、顧客の業務の意味を再定義し、その再定義に責任を持てる企業だ。

コード変換・解析AIツール層——勝つのは「精度の会社」ではない

COBOLやRPGをモダン言語に変換するAIツール群では、AWS・IBM・Microsoftが先行し、日本のSIer大手も自社ツールを開発している。しかしこの市場で勝者を決めるのは変換精度ではない。勝つのは「変換後の業務ロジックの意味と責任を保証できる会社」だ。コードを変換するだけでなく、業務要件との整合検証・テスト自動生成・品質保証まで一貫して提供できるプレイヤーが「翻訳権」を手にする。

マイグレーション専門サービス層——勝つのは「業務再設計の痛みを引き受けられる会社」だ

ツールだけでは移行は完結しない。負けるのは「クラウド移行を完了させた会社」であり、勝つのは「業務標準化という痛みを顧客と一緒に引き受けられる会社」だ。金融なら金融規制と業務知識、製造なら生産管理の深い理解が必要で、純粋技術企業が短期で獲得しにくい参入障壁を形成する。

あるSIerがクラウド移行プロジェクトを「完了」と報告した数ヶ月後、顧客から「移行前より月次コストが増えた」という連絡が来た。オンプレミスのバッチ処理をそのままクラウド上で走らせていたため、常時起動のインスタンスが膨らんでいた。「移行はした。最適化は別の話」——この分断こそが、リフト&シフトの罠の正体だ。そして最適化の先にある「AI活用に耐えられる構造への転換」は、さらにその先の話として先送りされていった。

インテグレーション層(iPaaS)——勝つのは「既存を活かしながら意味を再記述できる会社」だ

完全刷新が困難な企業にとって、既存システムをAPIで包み込む「ストラングラーフィグ・パターン(既存システムを新システムで少しずつ置き換えていく手法)」でAI層と接続する手法は現実的な中間解となる。MuleSoft(Salesforce)、Boomi、Informaticaなどのデータ統合・iPaaS系プレイヤーがグローバルで先行しているが、このレイヤーの真の競争優位は機能ではなく「一度フローを作り込んだ顧客との粘着性」とその積み上げによるデータ優位性にある。

SMB向け刷新パッケージ市場——勝つのは「PLGで業種の業務習慣を先に取った会社」だ

kintone(サイボウズ)、SmartHR、楽楽精算(ラクス)などのバーティカルSaaSは、「自社開発していた業務システムをSaaSに置き換える」需要を取り込んでいる。PLG(Product-Led Growth:製品自体が顧客獲得を牽引する成長戦略)によるスケールが前提だが、勝者は「業種の業務習慣をSaaSの設計に取り込んだ会社」であり、それができていないプレイヤーはカスタマイズの泥沼で消耗する

Section 05

ケーススタディ:AI時代の成功と失敗の分水嶺

✅ 成功例 01
みずほ銀行「MINORI」——8年間・4,000億円の先に見えたもの

みずほ銀行は2002年・2011年の2度の大規模システム障害を経て、2011年から約8年間・4,000億円超を投じて次世代勘定系システム「MINORI」を構築し、2018〜2019年にかけて段階的に移行を完了させた。富士通の技術解説では、MINORIがチャネル系・業務系・勘定系といった機能レイヤーを分離し、ESBを介したサービス連携構造を採っていることが触れられている。

「成功例」として取り上げる最大の理由は稼働したという事実だけでなく、「触れないブラックボックスの一枚岩」から「機能ごとに分離・接続できる構造」へ転換を試みた点にある。これは、将来的なAI統合のための「業務フローの再記述可能性」を確保する試みとして解釈できる。

示唆:ゴールを「完璧な刷新」ではなく「疎結合への移行」と定義し直すことが、大規模レガシー刷新を成功させる鍵となる。疎結合化は、AI時代の業務再設計の前提条件でもある。
❌ 失敗パターン 01
ERP導入失敗の構造——「商品コードの政治」がプロジェクトを止める

業種を問わず、ERP刷新プロジェクトが暗礁に乗り上げる最も多いパターンは、システム技術の問題ではない。ある流通企業では、ERP導入そのものより、商品コード体系の統一でプロジェクトが止まった。営業・物流・経理がそれぞれ独自のコードを長年使っており、「標準化=自部門のやり方を捨てること」と解釈された。

標準コードへの統一は、単なるデータ整備ではない。各部門にとっては、自分たちの仕事の定義権を手放すことを意味した。「部門独自コード」の中には、その部門が何十年もかけて積み上げた業務知識が埋め込まれており、それを手放すことは、自部門の存在証明を失うことに等しかった。ITプロジェクトに見えて、実態は組織の権力構造の問題だった。

示唆:レガシーシステムに埋め込まれた「部門の定義権」を誰が、いつ、どう手放すかを設計しないプロジェクトは、技術的に正しくても必ず止まる。
✅ 成功例 02
国内SIerのAIコード変換サービス——「ツール提供」から「翻訳責任」へ

TISをはじめ複数の国内SIerが、2023〜2024年にかけてCOBOL・RPGコードの解析・変換にLLMを活用したサービスを顧客に提供し始めている。TISは「Xenlon〜神龍 モダナイゼーションサービス」としてCOBOL変換を含む近代化支援を打ち出している。こうした取り組みに共通する成功パターンは一点に集約される傾向がある。変換精度を売りにするのではなく、変換後の動作保証・テスト自動化・業務ロジックの意味検証をセットにした「翻訳責任パッケージ」として提供したことだ。顧客が恐れているのは変換失敗ではなく「変換後に業務の意味が失われること」であり、その不安を解消できるプレイヤーが案件を獲得しつつある。

示唆:AIコード変換市場の勝者を決めるのは変換精度ではなく「業務の意味の翻訳責任」を引き受けられるかどうかだ。
❌ 失敗パターン 02
AI「貼り付け」の罠——業務フローが旧来のままでは効果は出ない

生成AIを導入しても、業務フローが旧来のままなら効果は限定的どころか逆効果になることがある。ある企業では、問い合わせ対応業務にAIチャットボットを導入したが、社内の承認フローが「AIの回答を人間が確認し、承認し、転記して顧客に回答する」という構造のままだったため、AIは現場の作業量を減らすどころか、新たな確認作業を増やした。

AI導入に失敗する企業の多くは、AIモデルの性能ではなく、旧来の承認フローと部門分断を前提にしたまま導入している。成功した企業が共通して行っていることは、AIの導入前に「このフローのどのステップは人でなければならないか」を問い直し、業務設計そのものを変えることだ。

示唆:AIは業務の「上に載せる」のではなく、業務の「前提を問い直す」ために使う。旧来のフローを維持したままのAI導入は、複雑性を増やす投資になりやすい。
Section 06

結論:企業の「自己再定義能力」が競争力になる時代

レガシーIT刷新市場は一過性の需要ではなく、10〜15年続く産業構造転換の序章だ。しかしここで重要なのは、この市場を「ITの更新市場」として見ることをやめることだ。本質は業務と責任の再設計市場であり、勝者は最新技術を持つ企業ではなく、複雑な業務の意味をAI時代の言語に翻訳できる企業だ。

📌 投資視点からのアクション

注目セクターiPaaS・データ統合基盤(MuleSoft、Boomi、Informatica)、AIコード変換・マイグレーション専門サービス。国内ではTIS、クラスメソッド、サイボウズを注視。評価軸は「業務再設計まで担えるか」。
評価指標単なるARR成長率より「顧客のITランニングコスト削減実績」「刷新後のAI活用事例数」「業務フロー再設計の実績件数」をKPIとして持つ企業を優先する。
回避すべき罠「クラウド移行支援のみ」で業務再設計まで踏み込めないSIerは、利益プールの移動に乗れず取り残される。「移行完了」をゴールとする提案は危険信号だ。

📌 事業参入視点からのアクション

小規模参入の余地中堅・中小企業向けの「AI時代の業務再設計伴走支援」は、大手SIerが手薄な領域。製造・流通・医療など業種特化でのBPR×AI活用支援は参入余地が大きい。
差別化ポイント「移行後のAI活用支援まで含めた一貫提案」がRFP通過率を高める。PoC→業務再設計→本番移行→AI活用の四段階パッケージが競合との差別化になる。
パートナー戦略AWS・Azure・Google CloudのSIer認定プログラムへの早期参加が案件紹介の重要パスとなる。クラウドベンダーのマーケットプレイス出品も有効な顧客獲得チャネルだ。

📌 スキル獲得視点からのアクション

技術者向けCOBOLの読解力+クラウドネイティブ設計スキルに、「業務フローを読み解いてAI統合設計に落とす能力」を加えた組み合わせが最高水準の希少価値を持つ。
コンサルタント向け「BPR×AI活用計画立案」の複合スキルが2025〜2030年の最重要コンサルスキルとなる。技術力よりも「組織が変われない理由を解きほぐし、変革の痛みを設計する力」が決定的な差になる。
経営者・投資家向け自社・投資先について「AIを導入しているか」ではなく「AIを前提に業務フローを再設計しているか」を問うことが、競争力評価の正しい問いになる。
レガシーとは、古い技術の残骸ではない。企業が過去の成功体験・責任回避・部門間妥協をコード化した記憶装置である。だから刷新とは、システム更新ではなく、企業が自分の過去をどこまで再定義できるかの試験なのだ。AI時代の競争力は、新しいモデルを買えるかどうかではない。自社の過去を、AIが読める言語に再記述できるかどうかで決まる。そしてAI時代の企業変革とは、単なるデジタル化ではない——企業が自分自身を、どの単位の業務と責任の集合体として再定義するかの問題である。

参考文献

  1. 経済産業省(2018)「DXレポート〜ITシステム『2025年の崖』克服とDXの本格的な展開〜」. https://www.meti.go.jp/policy/it_policy/dx/20180907_02.pdf
  2. 経済産業省(2018)「DXレポート(サマリー)」. https://www.meti.go.jp/policy/it_policy/dx/20180907_01.pdf
  3. IPA(2024)「DX動向2024」独立行政法人情報処理推進機構. https://www.ipa.go.jp/digital/chousa/dx-trend/
  4. 中小企業庁(2024)「2024年版中小企業白書 第4章第7節 DX」. https://www.chusho.meti.go.jp/pamflet/hakusyo/2024/
  5. みずほフィナンシャルグループ(2019)「次世代勘定系システム『MINORI』の全面稼働について」プレスリリース.
  6. 富士通株式会社(2020)「みずほ新勘定系システム『MINORI』を活用したAPI連携」. https://jp.fujitsu.com/family/article_m/2020/pdf/2020-06.pdf
  7. IBM(2024)"watsonx Code Assistant for Z." IBM Products Documentation.
  8. Amazon Web Services(2024)「メインフレームのモダナイゼーション向け Amazon Q Developer」. https://aws.amazon.com/jp/about-aws/whats-new/2024/12/amazon-q-developer-transformation-mainframe-modernization/
  9. TIS株式会社(2024)「Xenlon〜神龍 モダナイゼーションサービス」. https://www.tis.co.jp/news/2024/tis_news/20241003_1.html
  10. Fowler, M.(2004)"Strangler Fig Application." martinfowler.com. https://martinfowler.com/bliki/StranglerFigApplication.html
  11. Gartner(2024)"Market Guide for Application Modernization and Migration Services." Gartner Research.
  12. 野村総合研究所(2023)「ITロードマップ2024年版」東洋経済新報社.