生成AIでレガシーシステムを刷新する相談先の選び方｜会社のタイプ別比較と刷新・延命・撤退の判断軸

生成AIの進化で、古いシステムのソースコードを読み解いたり、新しいシステムを組み上げたりする作業は、以前より進めやすくなりました。けれども、レガシー刷新の難しさは、古いプログラムを新しい言語に書き換えることだけではありません。私たちスパイスファクトリー（以下、当社）がレガシー刷新に取り組むなかで見えてきたのは、難しさの多くが「作る」ことよりも、「何を作るべきかを正しく知る」側にある、ということです。長年の改修で複雑になった業務ルールや、設計書に残っていない例外処理を見落とすと、新しいシステムは一見動いているようでも、実際の業務で問題が起きかねません。

だからこそ、生成AIを使ったレガシー刷新では、「AIを使えるか」だけでは足りません。「旧システムを正しく理解し、必要な仕様を引き継ぎ、その結果を確かめられるか」。これが、相談先を選ぶときの大事な基準になります。

今回は相談先のタイプ別の比較と、選ぶときに確認したい8つの基準を中心に、相談の前にそろえたい判断材料、刷新・延命・撤退の判断軸、設計書がない場合の進め方、費用の目安までを紹介します。基準の説明には、当社が実際に進めている刷新プロジェクトで見えたことも、具体例として織り込みました。レガシーシステムそのものの定義や、放置したときのリスクについては「レガシーシステムとは？放置リスクと刷新の進め方」をご覧ください。なお、この記事でいう「撤退」は事業からの撤退ではなく、既存システムの廃止、他システムへの統合、パッケージやSaaSへの置き換えを指します。記事の情報は2026年10月時点のものです。

古い基幹システムを生成AIで刷新したいとき、相談先にはどんな会社がある？

相談先を整理しやすいように、支援の特徴に着目して4つのタイプに分けてみました。業界で決まった分類ではありませんし、実際には複数のタイプの顔をあわせ持つ会社も多くあります。「どのタイプの強みを、どこまで持っているか」を見るための目安として使ってください。現状把握・業務の分析・実装・検証のどこまでを担うかは、同じタイプでも会社ごとに違うので、次章の基準で確かめるのがおすすめです。

当社は③のタイプです。ただ、メインフレーム上の大規模なCOBOL資産を、仕様を変えずに短期間で移すことが主な目的なら、変換ツールと移行実績を持つ②や、①が第一候補になることもあります。

もうひとつ、パッケージやSaaSへの置き換えは、方針を決める段階から比較の選択肢に入れておきたいところです。その場合は、パッケージやSaaSのベンダーや、その導入支援会社も相談先になります。経済産業省の「レガシーシステムモダン化委員会総括レポート（新しいタブで開きます）」（2025年5月。事務局のIPAが公開）も、現状の業務プロセスを見直すことで、投資対効果の許容できる範囲で標準的なパッケージやSaaSへ移れないかを、最優先で検討するとしています。

公開情報で相談先のタイプを見分けるポイント

候補が挙がったら、各社の公開ページで次の点を見てみてください。どのタイプの強みを持っているかが、だいたい見えてきます。

• サービスページに書かれている移行の方式（リホスト／リライト／リビルド／リプレイスなど）と、対応する言語・基盤
• 「診断」「アセスメント」など、現状把握だけを頼めるメニューがあるか
• AIの解析結果を、誰がどのように確かめるかの説明があるか
• 旧システムの仕様を、刷新後にどう引き継ぎ、どう確かめるかの説明があるか
• ソースコードの取り扱い（解析する環境、データの保存場所、AIの学習への利用の有無、操作ログ）の説明があるか
• 価格や期間の目安を公開しているか。公開しているなら、その前提条件

相談先の選び方：比較するときに確認したい8つの基準

見積もりの金額だけで比べると、前提の違う提案を並べて比べることになりがちです。次の8つの観点で、相談先ごとの前提をそろえてから比べてみてください。頼む工程（現状把握だけか、再構築や本番移行までか）と移行の方式によって、基準の重みや確かめる細かさは変わります。初回の相談では、右の列を参考に質問してみてください。

基準3〜7は、仕様の把握・引き継ぎ・検証の進め方を見る観点です。AIを使う場合はこれに加えて、解析する範囲の取り違えや、もっともらしい誤りにどう対処しているかを、具体的な手順で説明してもらうとよいでしょう。

相談の前にそろえたい判断材料

次の情報が手元にあると、どのタイプの相談先でも、初回の相談がぐっと具体的になります。すべてそろっていなくてもかまいません。分からない項目は「分からない」と伝えてください。それも大事な情報です。

刷新・延命・撤退はどう判断する？

古いシステムだから刷新が必要、とは限りません。前述の総括レポートも、メインフレームなど古い技術や開発手法で作られたシステムであっても、開発・運用・保守の体制が整い、デジタル技術の活用やデータ連携ができ、仕様が明確で継続的に機能を改良できる作りなら、レガシーシステムではないと言える、としています。判断の出発点は、システムの現状と事業の今後を突き合わせることです。

判断の軸

刷新・延命・撤退を比べるときは、次の軸で現状を見ていきます。

• 事業上の重要度と今後の変化：成長させるのか、維持するのか、縮小するのか
• 技術的な寿命：製品のサポート期限、技術者を確保できる見通し
• 守りのコスト：保守費用、改修1件あたりの調査の手間と見積もりの推移
• 属人化の度合い：仕様を説明できる人がいるか、その人がいなくなったらどうなるか
• 利用の実態：使われていない機能・画面・帳票がどれくらいあるか
• 代わりの手段：パッケージやSaaS、他システムへの統合で置き換えられるか

答えは、1つのシステムの中でも機能ごとに分かれることがあります。「この機能群は刷新、この帳票は延命、この画面は廃止」というように、システムを分けて判断するのが現実的です。総括レポートも、可視化した情報をもとにシステムを仕分けして優先度を付け、本当にモダン化が必要な範囲を見極めることを求めています。

刷新を選んだ後にも、もう一段の判断が待っています。旧システムの業務ルール一つひとつについて、そのまま引き継ぐのか、変えるのか、ほかと統合するのか、やめるのか（基準6）。システム全体の投資判断と、ルール単位の判断の両方を記録しておくと、後から「なぜこうしたか」を説明できます。

設計書がない・担当者がいない場合の進め方

設計書が残っていない。当時の担当者や開発ベンダーも離れてしまった。そんな状態でも、刷新の検討は始められます。ただし、ソースコードをAIに読ませれば仕様が分かる、というほど単純ではありません。

当社の刷新プロジェクトで見えたこと

当社が進めている大規模な業務システムの刷新プロジェクト（ソースコードは数百万行規模）では、受け取った資材はソースコード、データベースの定義、運用マニュアルだけでした。解析を進めるうちに、次のようなことが分かってきました。

• 1つの機能の仕様が、複数の場所に分かれていた：画面の入力チェックのほか、SQLやデータベース側の処理、帳票や設定ファイルなどです。画面のプログラムだけを読んでも、業務ルールは復元できません。
• 「対象外」とされた資材に、本当のソースコードがあった：バッチや外部連携の実際のソースコードは、「対象外」として渡されたフォルダにしかありませんでした。受け取った資材の区分が、実態と合っているとは限らないのです。
• 「検索して0件」が、本当に0件とは限らなかった：文字コードが混在していたため、ある検索ツールは一部のファイルを読み飛ばし、実際には該当する箇所があるのに0件と返していました。
• AIが書いた仕様書にも、書かれていない挙動があった：ある業務分類の画面群について、AIが書いた仕様書を別の観点から突き合わせて検証したところ、仕様書に書かれていなかった挙動が多数見つかりました。その後は解析の手順を直し、漏れにくくしています。

進め方の一例

こうした落とし穴を踏まえると、設計書がない場合は、次の順で進めるのがおすすめです。

1. 対象の範囲を決め、資材を集める：ソースコードだけでなく、データベースの定義、設定ファイル、ジョブや帳票の定義も集めます。受け取った資材の区分が実態と合っているかも確かめます。
2. 代表的な機能を、画面からデータベースまで通して読む：そのシステムの「標準的な作り」（層の構成、命名、データの更新の仕方など）をつかみます。ほかの機能にも当てはまるかを確かめ、作りが異なる領域は追加で調べます。
3. 標準から外れた処理を、種類ごとに探す：例外処理、画面にだけある入力チェック、データベース側の処理など、標準の流れを追うだけでは見えない仕様を探します。
4. AIが書いた仕様を、別の担当が元のコードと突き合わせて確かめる：書かれていない挙動の候補を挙げ、合格とするかどうかは人が判定します。
5. 業務部門にヒアリングし、実態と突き合わせる：なぜその仕様なのか、実際に使われている機能なのかを、現場で確かめます。
6. 刷新・延命・撤退の判断材料にまとめる：機能ごとの扱い、移行の方式、概算の費用と期間、リスクを整理し、経営層が判断に使える形にします。

ソースコードから分かるのは、仕様や構造までです。AIの解析だけで元の仕様を完全に復元できるわけではありませんし、使われていない機能を見分けるには、利用の実態を確かめる必要があります。長年の運用でデータの入れ方が途中で変わり、データに不整合が生じていることもあります。その場合は、コードの解析とは別にデータの調査が要ります。総括レポートも、システムの移行で問題が起きやすいのはデータ移行だと指摘しています。

ソースコードなどの資材から読み取れること・読み取れないことと、解析の結果の確かめ方は「設計書がない古いシステムの仕様は、生成AIでどこまで復元できる？」で紹介しています。

生成AIで刷新すると何が変わる？解析から刷新・検証まで

生成AIは、現行システムを理解する工程だけでなく、新しいシステムを作る工程や、確かめる工程にも使えるようになってきました。当社では、次の3つの段階をAIで連携させ、重要な判断と承認は人が担う形で、刷新プロジェクトを進めています。

AIが迷った論点をすべて人に投げると、人の判断待ちがボトルネックになります。かといって、人に聞かずに進めると、意図しない仕様の変更が混ざります。当社のプロジェクトでは、同じ原因から来る質問を1つの論点に束ね、選択肢と影響範囲を添えて示すことで、ある業務分類で人に確認する論点を少数に絞り込みました（判断を求める論点をまとめた結果で、作業時間の削減を示すものではありません）。

現在は、限られた範囲で解析から刷新・受け入れまでを通し、ほかの業務分類にも対象を広げている段階です。引き継ぐ部分の結果は、旧のコードから期待する結果を読み起こしてテストに固定しています。旧システムと新システムを実際に動かして結果を比べる検証、バッチ・帳票・外部連携・認証認可の刷新、データ移行のリハーサルや切り戻し、運用への移行は、これから取り組む課題です。この進め方を別の技術で作られたシステムに当てはめられるかも、まだ検証していません。総括レポートも、人手に頼った従来の移行やモダン化は人材の減少で早晩限界を迎えるとして、生成AI等を使ったレガシーコードの解析やコード生成など、モダン化の生産性を高める技術の開発・導入が必須だとしています。

生成AIを使った刷新の費用はどのくらい？段階別の目安

刷新の費用は、対象の規模、移行の方式、データ移行の難しさなどで大きく変わるため、最初から全体の金額を出すのは難しいものです。次のように段階を分け、前の段階の結果を見てから次の投資を判断する進め方をおすすめします。

相談先を比べるときは、金額だけでなく、含まれる作業と成果物をそろえて比べてください。

スパイスファクトリーの現状分析・戦略策定の参考価格

参考として、当社のAIモダナイゼーションの価格と期間の目安を載せておきます。刷新全体の相場ではありません。金額を載せている有料メニューは、上の表の「2. 現状把握」「3. 戦略策定」にあたります。無料相談と、別契約となる再構築・実装もあわせて記載しています。

期間・価格はいずれも参考・目安で、システムの規模・件数・状況によって変動します。システム簡易診断と分析・戦略提案は請負契約を想定しています。再構築・実装は別契約です。

スパイスファクトリーのAIモダナイゼーション支援（③AI駆動型）

当社は、AIによるコード解析と人間中心設計（UXデザイン）を掛け合わせ、刷新・延命・撤退を根拠を持って判断するための材料をそろえ、AI活用を前提とした移行戦略まで描く「AIモダナイゼーション」を提供しています。大切にしているのは、AIで速く読むことよりも、旧システムの仕様を失わずに次のシステムへ引き継ぐことです。

• 設計書や担当者がいなくても始められる：設計書が欠落していたり、仕様を把握している担当者がいない状態でも開始できます。必要なのは対象システムのソースコードと、簡単なヒアリングのお時間です。分析・戦略提案では、UXデザイナーによる業務ヒアリングで、コードには書かれていない現場の情報も加えます。
• 現状把握のコストと期間を抑える：AIを活用した独自の解析アプローチにより、従来人手で行っていた分析と比べ、コストと期間を大幅に抑えて現状把握が可能です。
• ソースコードを守る解析環境：解析はデータを国内リージョンに限定して実行し、いただいたコード・成果物がAIの学習に利用されることはありません。閉域環境での実行と操作ログの記録により、監査証跡の提出にも対応します。当社はAWSセレクトティアパートナーであり、AWS上（Amazon Bedrock）で稼働するClaudeを用いて解析を行います。ISMS（ISO/IEC 27001）を全社の基盤とし、専門家レビューと経営層レビューを組み合わせた体制でリスクを管理しています。
• ドキュメントの自動生成：ソースコードをもとに、システムの全体像から設計・依存関係・UI/UXまで、7カテゴリ・30種類以上のドキュメントを自動で生成します。
• 分析の後の再構築まで：UI/UX設計、システムの再構築、アジャイル開発まで支援できます。既存ベンダーの置き換えを前提とせず、中立的な立場からの評価としてもご活用いただけます。

実績としては、多数のExcel・マクロで運用されてきた業務を、フォーマット・構造をAIで解析した上でWebシステムへ移行した実績があります（公共インフラの設備点検報告システム）。

大規模な刷新プロジェクトで適用・検証している進め方

前述の大規模な業務システムの刷新プロジェクトでは、次の進め方を適用・検証しています。

• 仕様の見落としを減らすための解析：標準的な処理の流れを追う調査と、標準から外れた処理を探す調査を組み合わせ、元のソースコード・データベースの定義・マニュアルを根拠に仕様を書き起こします。書いた担当とは別のAIが元の資材と照合し、書かれていない挙動の候補を人が判定します。
• 旧仕様の扱いをルール単位で記録：把握した旧システムの業務ルールすべてに、「そのまま／変える／やめる／要判断」などの扱いが記録されていることを機械で照合し、新しい仕様の受け入れ条件とテストに対応づけます。要判断の項目は、未決事項として管理します。業務ルールは引き継ぎ、操作性や技術の構造は新しくする、という線引きを、判断の記録とあわせて示します。
• 解析から刷新・検証までをAIで連携：解析・実装・テスト・レビューをAIで連携させ、画面の方向性、業務ルールの変更、受け入れ、本番への反映といった重要な判断は人が担います。

解析から刷新・受け入れまでを通した範囲は、現時点では限定的です。旧システムと実際に動かして比べる検証、バッチ・帳票・外部連携・認証認可、データ移行のリハーサルや切り戻し、運用への移行はこれからの課題で、別の技術で作られたシステムへの適用も未検証です。案件ごとに、どこまでを対象にできるかを確かめたうえでご提案します。

一方で、前述のとおり、メインフレーム上の大規模なCOBOL資産を、仕様を変えずに短期間で移すことが主な目的なら、移行専門会社や大手SIerのほうが向くことがあります。無料相談では、対象システムの構成や課題を伺い、当社のサービスで対応できるかどうかと進め方をご提案します。

サービスの詳細はAIモダナイゼーションのサービスページ、刷新判断のチェックリストを収録したホワイトペーパー、サービス紹介資料をご覧ください。

よくある質問（FAQ）

古い基幹システムを生成AIで刷新したいのですが、どこに相談すればよいですか？

何を決めたい段階かで変わります。メインフレームを含む全社規模の移行を一括で任せたいなら大手SIer・総合ITベンダー、仕様を変えずに言語や基盤を移したいなら移行専門会社、旧システムの仕様を読み解いて引き継ぎながら業務の見直しも含めて作り直したいならAI駆動型の開発会社、社内の開発チームで生成AIの活用を進めたいなら生成AI導入支援・AIコンサルティング会社が候補です。パッケージやSaaSへの置き換えを考えるなら、そのベンダーや導入支援会社も候補になります。どのタイプでも、AIの解析結果をどう確かめ、旧仕様をどう引き継ぐかは各社に確かめてください。方針がまだ決まっていないなら、現状把握（診断）を切り出して頼める相談先から始めると、手戻りを抑えられます。

AIが復元した仕様が正しいかどうか、どう確かめればよいですか？

まず、仕様の記述ごとに、元のソースコードやデータベースの定義のどこが根拠なのかを示せるかを確かめます。次に、書いた担当とは別の担当（別のAIや人）が、元の資材と突き合わせて検証しているかを確かめます。AIは、読んでいないものを「無い」と書くなど、もっともらしい誤りをすることがあります。当社の案件では、AIに自己点検を追加で指示しても誤りの発見が増えない例があったため、自己点検だけに頼らず、原典との照合と別の視点による検証を重視しています。実際、AIが書いた仕様書を別の観点から検証したところ、ある業務分類の画面群で、書かれていなかった挙動が多数見つかりました。最後に、合格とするかどうかは人が判定します。

刷新すると、業務のルールまで変わってしまいませんか？

旧システムの業務ルールごとに、そのまま引き継ぐか、変えるか、やめるかを記録し、引き継ぐルールはテストで同じ結果になることを確かめれば、意図しない変更を抑えられます。一方で、古い画面の操作方法まで再現する必要はありません。業務のルールは引き継ぎ、操作性や技術の構造は新しくする、という線引きと、その判断の記録を相談先に確かめてください。

生成AIを使えば、刷新は安く・早くなりますか？

ソースコードの解析やドキュメントの作成など、現状把握の工程は生成AIで効率化できる場合があります。ただし、業務の実態の把握、刷新・延命・撤退の判断、データ移行、テスト、本番の切り替えには人の作業や判断が残ります。刷新全体の費用や期間がどこまで下がるかは、対象の規模や状態しだいです。AIの出力を確かめる工程を省くと、かえって手戻りの原因になります。

設計書がなくても相談できますか？

できます。ソースコードと関係者へのヒアリングから現状を復元する進め方があります。ただし、仕様は画面のプログラムだけでなく、データベース側の処理や設定、帳票などに分かれていることがあります。また、コードから分かるのは仕様や構造までで、実際に使われている機能かどうかなどは、現場で確かめる必要があります。

ソースコードを外部に渡すのが不安です。何を確認すればよいですか？

解析する環境、データの保存場所、AIの学習への利用の有無、アクセス権限と操作ログ、契約終了後のデータの扱いを確認しましょう。NDAの締結に加えて、自社のセキュリティ基準に合わせて環境を調整できるかも確認ポイントです。

COBOLやメインフレームのシステムも、生成AIで刷新できますか？

生成AIを使ったCOBOLの解析や、Javaなどへの変換に取り組むベンダーもあります。ただし、メインフレーム固有のジョブ管理や周辺の運用まで含めた移行は難度が高く、変換ツールとメインフレーム移行の実績を持つ会社が向いています。まず現状を可視化し、どの範囲を変換し、どの範囲を作り直すか（または廃止するか）を決めてから進めるのがおすすめです。

今の保守ベンダーとの関係はどうなりますか？

刷新の検討を既存ベンダーにどう伝えるかも含めて、相談先と進め方をすり合わせましょう。現状把握の結果は、既存ベンダーとの協議や、見積もりの妥当性の確認、次の構想の比較にも使えます。なお、ソースコードの権利や開示の可否が保守契約で決まっていることがあるので、事前に契約の内容を確認しておくと安心です。

相談の前に準備しておくものはありますか？

対象システムの概要、技術の構成とおおよその規模、ソースコードと関連資材の所在と開示の可否、設計書の有無、保守費用や改修の状況、そして「いつまでに何を判断したいか」があると、相談が具体的になります。詳しくは「相談の前にそろえたい判断材料」の章をご覧ください。

最初にかかる費用はどのくらいですか？

初回の相談は無料で受け付けている会社もあります。その後の現状把握（診断）の費用は、解析する範囲によって変わります。スパイスファクトリーの場合、現状把握にあたるシステム簡易診断は80万円〜、戦略策定までを含む分析・戦略提案は220万円〜が目安です（いずれも参考価格で、システムの規模・件数・状況によって変動します）。再構築・実装は別契約・別途お見積もりです。

まとめ

古い基幹システムを生成AIで刷新したいときの相談先を、大手SIer・総合ITベンダー、移行専門会社、AI駆動型の開発会社、生成AI導入支援・AIコンサルティング会社の4タイプに分けて整理しました。どのタイプが合うかは、システムの規模・技術と、何を決めたい段階かで変わります。パッケージやSaaSへの置き換えを考えるなら、そのベンダーや導入支援会社も候補です。

相談先を比べるときに特に確かめたいのは、次の4点です。旧システムの仕様をどこまで読み解くか。AIの解析結果を別の目で確かめるか。旧仕様の「残す・変える・やめる」を追跡できるか。そして、刷新後に決めたとおり動くかをどう確かめるか。生成AIは読む速さも作る速さも大きく変えましたが、「何を作るべきかを正しく知り、それを引き継いだと確かめる」ことは、引き続き刷新の成否を分けます。

進める順番は、現状把握の相談先を選ぶ → 現状把握 → 刷新・延命・撤退の判断 → 選んだ方針に合う方式と実施体制の決定 → 実行、が基本です。

当社では、「刷新すべきか延命すべきか、判断の根拠がそろわない」という段階からご相談をお受けしています。AIモダナイゼーションの無料相談から、お気軽にお問い合わせください。