レガシーを刷新すべきか、捨てて作り直すべきか
──AIが判断材料を出す前に経営層が知るべき5つの軸

この記事で分かること（一行洞察）
「刷新か、作り直しか」という問いは、正しい情報なしには答えられない。判断の質がプロジェクトの成否を左右する──だからこそ「判断の前に現状を知る」ことが、今の経営者にとって最もコストパフォーマンスの高い一手になる。

はじめに

「このレガシーシステム、そろそろどうにかしないといけない」という会話が社内で始まったとき、次に必ず出る問いがある。刷新（モダナイゼーション）か、全面作り直し（リビルド）か──だ。この選択が、費用は数倍、期間は数か月単位で変わる。にもかかわらず、多くの経営判断が「コストが安そう」か「ベンダーに勧められたから」で決まっているのが実情だ。

AIリバースエンジニアリングは、この「判断の質」を根本から変えつつある。本稿では、刷新と作り直しを分ける5つの軸と、「先に現状を知る」ことが意思決定をどう変えるかを整理する。

第1章　「刷新」と「作り直し」──そもそも何が違うのか

刷新とは、既存システムの業務ロジックや設計思想を引き継ぎながら、プログラミング言語や開発基盤を現代的に置き換えること。作り直しとは、現行システムを参考にしながらも、ゼロベースで設計し直すことを指す。

どちらも「古いシステムをどうにかする」という目的は同じだが、前提が真逆に近い。刷新は「今あるものを活かす」方向、作り直しは「今あるものを捨てる」方向だ。

ここで経営層が最初に問い直すべきことがある。「システムは動いている」と「システムは使える」は、別の話だ。20年前の設計のまま稼働し続けているシステムが、今のビジネス速度や顧客要求に応えられているかどうかはまた別問題だ。「動いているから問題ない」という判断が、刷新か作り直しかという問いを曇らせている。

ところが日本企業でこの選択を正確な情報に基づいて行えているケースは多くない。理由は単純で、「現状のシステムが何をしているか、誰も正確に把握していない」からだ。詳しくは「塩漬けシステム」が招く3つの経営リスクで解説している。

第2章　「判断が早すぎる」ことが最大の失敗原因

レガシー刷新プロジェクトの失敗率は60〜70%に達するとされている（業界統計）。当社の支援実績でも同様の傾向が確認されており、失敗の多くは「技術的な問題」ではなく「判断の問題」に起因している。

最も多いパターンがこうだ。経営会議で「老朽化対応に予算を取る」と決まり、ベンダーに相談したら「全面リプレイスで○千万円」と提案される。感覚的に高いと感じながらも他に比較軸がなく承認し、プロジェクトが走り始める。しかし数か月後、「思っていたのと違うものができあがった」という結果を招く。

問題の根本は、現状のシステムが何をしているか、誰も正確に把握していない状態で判断が行われていることにある。ドキュメントのない20年前のシステム、「なぜこのロジックがあるのか誰もわからない」コード、担当者の記憶にしか残っていない例外処理──この「見えない現状」のまま刷新か作り直しかを選ぼうとするのは、建物の柱の位置を把握しないままリノベーションか建て替えかを判断するようなものだ。

第3章　やってはいけない「失敗パターン」3選と回避法

パターン①：現状把握なしで見積もりを取る

「刷新するならいくらかかるか」をシステムの中身を把握しないままベンダーに聞いても、出てくる数字は根拠が薄い。ベンダーは「わからないリスク」を見積もりに上乗せするため、必要以上に高くなる。回避策は「先にAIリバースエンジニアリングで現状を数値化してから相見積もりを取る」こと。

パターン②：「安いから作り直し」という判断

一見、新規開発のほうが見積もりが低く見えることがある。しかし現行システムの業務ロジックを「暗黙の了解」として引き継げると思っていたら、移行後に業務が止まったケースは当社支援実績でも複数確認している。作り直し見積もりには必ず「業務ルール引継ぎコスト」を含めて試算することが重要だ。

パターン③：「誰かが知っている」という前提で進める

「あの担当者に聞けばわかる」という属人性に頼ったまま判断を行い、プロジェクト途中でその担当者が退職した──という事態は珍しくない。着手前にナレッジのシステム化（KNOWLEDGE層）を最優先で実施することが、最もコスト効率の良い保険になる。

第4章　AIリバースエンジニアリングが「判断の質」を変えた理由

なぜAIリバースエンジニアリング自体が経営判断に必要なのかという背景はこちらの記事で詳しく解説している。ここでは、刷新 vs 作り直しという判断軸との接続に絞って整理する。

従来、ドキュメントのないシステムの現状把握には3〜6か月かかることが珍しくなかった。それがAIを活用した解読プロセスにより、同等以上の精度を1〜3か月に短縮できるケースが出ている（当社支援実績より）。AIは業務ロジックを言語的に解析し、設計書のない関数の意味を推定し、依存関係マップを自動生成する。その結果、「体感」や「ベンダーの提案」ではなく、数字と根拠に基づく判断材料が揃うようになる。

第5章　刷新が向くケース vs 作り直しが向くケース──5つの判断軸

解読で現状が数値化できると、以下の5軸で刷新・作り直しを冷静に比較できるようになる。

軸①：業務ロジックの複雑性・固有性

長年の運用で積み上がった例外処理や業務ルールが多いほど刷新が有利。逆に業務ルールがシンプルで標準的なら、作り直しがスピード的に有利になる。

軸②：現行コードの再利用可能な割合

当社の支援実績では、再利用可能な割合はプロジェクトによって20〜70%の幅があった。割合が高いほど刷新が有利で、低いほど作り直しとのコスト差が縮まる傾向がある。現状解析なしでは、この数値が「感覚」になるしかない。

軸③：プログラミング言語や開発基盤の硬直性

COBOLや旧世代の言語で書かれている場合、現代のAI活用に必要な開発基盤との相性が悪く、言語ごと変えなければならない。刷新の難易度が上がり、作り直しとのコスト差が縮まる傾向がある。

軸④：データベースの設計構造の複雑さ

データベースの設計構造が複雑に絡み合っている場合、刷新時の「データ移行」コストが膨らみやすく、見積もり段階で軽視されがちな落とし穴になる。

軸⑤：将来のAI活用との整合性

「将来的にAIエージェントを業務に組み込みたい」という経営方針がある場合、刷新後のシステム全体の構造設計が「AI活用しやすいかどうか」が重要な判断材料になる。→ AIエージェント導入前提としてのリバースエンジニアリング

第6章　HITL5 REVERSEで「先に現状を知る」──5層の解読プロセス

ディレクトリジャパンが提唱するAI-HITL5 Frameworkには、ブラックボックス解読を体系化した「HITL5 REVERSE」がある。LAYER 01：SCOPE（解読範囲の確定）／LAYER 02：DECODE（コード解読）／LAYER 03：KNOWLEDGE（知識化）／LAYER 04：VISUALIZE（可視化）／LAYER 05：ENABLE（AI連携可能化）の5層で構成される。

各層にはAI（自動処理）／HUMAN（人間判断）／GATE（承認）の3構造があり、人間が承認した段階でのみ次の層に進む仕組みになっている。これにより「AIが解析した結果」を人間が検証しながら、刷新・作り直し判断に必要な現状マップを確実に積み上げていく。費用対効果の詳細はAIリバースエンジニアリングのROI試算ガイド2026を参照してほしい。

AI-HITL5 Framework ／ ディレクトリジャパン株式会社 提唱 ／ 2026

第7章　経営層が動くべき「正しいタイミング」と最初のステップ

「刷新か作り直しか」という議論は、判断の順序として2番目以降の問いだ。最初にすべきことは「現状を知る」こと──それだけでいい。この一手を打たずに議論を続けても、比較軸のない意思決定を繰り返すだけになる。

14日無償トライアルでは、対象システムの1機能分について、HITL5 REVERSEの設計書サンプルを実物でお見せしている。「解読するとどんな判断材料が手に入るのか」を、資料ではなく現物で確認いただける。

よくある質問（FAQ）

まとめ

刷新か作り直しかという問いは、正しい情報なくしては答えられない。判断の質がプロジェクトの成功率を左右する──だからこそ「判断の前に現状を知る」というステップが、今の経営者にとって最もコストパフォーマンスの高い一手になる。

14日無償トライアルはこちら（NDA締結のうえ、設計書サンプルを実物でお見せします）