レガシーシステム刷新の開発会社の選び方｜4タイプ比較・費用相場・失敗回避【2026年版】

「20年動き続けている基幹システムを刷新したいが、どの開発会社にどう頼めばいいのか見当がつかない」——レガシーシステムの刷新を検討し始めた多くの担当者が、最初にぶつかるのがこの壁です。大手SIerに頼むべきか、マイグレーション専業ベンダーがいいのか、コンサルが必要なのか。費用は数千万円なのか数億円なのか。判断材料がないまま相見積もりを取っても、各社の提案を比べる軸すら持てません。

レガシーシステム刷新は、Webサイトの作り直しのような単純な「再開発」ではありません。現行システムの仕様がドキュメント化されておらず、業務と一体化し、特定の担当者しか中身を把握していない——こうした制約の中で、事業を止めずに移行を成し遂げる必要があります。だからこそ、開発会社の「タイプ」と自社の状況の相性が、プロジェクトの成否を大きく左右します。

本記事では、レガシー刷新を頼める開発会社を4タイプに分類して比較し、手法×規模の費用相場、選定の7基準とスコアシート、そしてAIエージェントによって移行コスト・工期がどう変わりつつあるのかまで、発注者の意思決定を1本で完結させる形で解説します。刷新手法そのものの詳細はレガシーシステム刷新戦略、技術負債の全体像は技術負債の解消アプローチも合わせてご覧ください。

レガシーシステム刷新とは — 発注前に押さえる基礎

レガシーシステム刷新とは、老朽化・複雑化・ブラックボックス化した既存の業務システムを、現在の技術標準と事業要件に合う形へ作り替える取り組みを指します。単なるバージョンアップではなく、保守できる人材の枯渇や事業のスピードを阻害する構造的な問題を解消することが目的です。発注先を選ぶうえでは、まず「自社のシステムがなぜ刷新を必要としているのか」を正しく捉えることが出発点になります。同じ「古いシステム」でも、環境が限界なのか、保守人材がいないのか、業務そのものが時代に合わないのかで、取るべき手段も頼るべき会社も変わるからです。

刷新が必要になるレガシーシステムには、典型的に3つの特徴があります。

• 老朽化：サポートが終了したOS・ミドルウェア・言語（COBOL、古いERPパッケージ等）で動いており、セキュリティパッチや法改正対応が困難。
• 属人化：仕様を把握しているのが特定の少数のベテランだけで、退職や定年でノウハウが失われるリスクがある。
• ブラックボックス化：ドキュメントが整備されておらず、「なぜそう動いているか」を誰も説明できない。障害時に原因究明が難しく、再構築のための仕様再現もできない。

「刷新」と関連用語の違い

発注の場面では「刷新」「更改」「マイグレーション」「モダナイゼーション」「リプレース」が混在して使われ、認識のズレが手戻りの原因になります。整理すると次のとおりです。

「マイグレーション＝とにかく動かす」と「モダナイゼーション＝構造から直す」では、必要な予算も開発会社のタイプも変わります。発注前にどこまでを目的にするかを言語化しておくことが、後の会社選びの精度を決めます。

レガシー放置で膨らむ4つのリスク

1. 保守コストの増大：枯渇する技術者を高単価で確保し続ける必要があり、IT予算が「守り」に固定される。
2. 事業機会の損失：新サービスやデータ活用が既存システムの制約で実装できず、競合に後れを取る。
3. セキュリティ・コンプライアンスリスク：サポート切れ製品の脆弱性、法改正への追従遅れ。
4. 事業継続リスク：仕様を知る人材の退職・障害発生時に復旧できず、業務が止まる。

これら4つのリスクは、時間が経つほど静かに、しかし確実に大きくなります。とりわけ深刻なのが、保守人材の高齢化と退職です。仕様を理解する人がいなくなった瞬間、システムは「直すことも作り替えることもできないブラックボックス」と化し、刷新の難度もコストも跳ね上がります。「まだ動いているから大丈夫」という現状維持は、実際には毎年リスクという名の負債を積み増している状態だと捉えるべきです。だからこそ、刷新は人材が残っているうちに着手するほど有利になります。

「2025年の崖」の2026年現在の実態

「2025年の崖」とは、経済産業省が2018年9月に公表した「DXレポート」で示された警告で、老朽化・ブラックボックス化したレガシーシステムが残存した場合、2025年以降に最大で年間12兆円の経済損失が生じうるという試算です（2018年時点の試算約4兆円の約3倍）。出典：経済産業省「DXレポート ～ITシステム『2025年の崖』の克服とDXの本格的な展開～」2018年（meti.go.jp）。

崖の「年」を越えた2026年現在、この問題は解消したのでしょうか。結論から言えば、答えはノーです。最新の調査を見ると、レガシー問題はなお根深く残っており、むしろ着手の遅れた企業ほど厳しい状況に置かれています。

• レガシー残存企業は60%台で高止まり：JUAS（日本情報システム・ユーザー協会）の「企業IT動向調査2024」では、レガシーシステムが残る企業の割合が60%台を維持していると報告されています（調査対象：東証上場企業等4,500社、回答976社。JUAS）。
• 約8割がレガシーを保有：IPA（情報処理推進機構）の「DX動向2025」では、日本企業の約8割が何らかのレガシーシステムを抱えていると報告されています（IPA DX白書・関連刊行物）。なお「2025年には21年以上稼働する基幹系システムが約6割に達する」という予測は、経済産業省のDXレポート（2018年）が示したものです（meti.go.jp）。
• 刷新の着手は進みつつある：レバテックの調査（2025年8月）では、システム刷新の約5割が「進行中」と回答しており、着手企業は2020年以降に集中しています（levtech.co.jp）。

つまり、2026年の現実は「崖を回避できた」のではなく、多くの企業がようやく刷新に動き出した一方で、半数近くは依然として手付かずという状況です。後発で着手する企業ほど、保守人材の確保競争と移行ノウハウの不足という二重の壁に直面します。だからこそ、自社の状況に合った開発会社をどう選ぶかが、今まさに問われています。

後発着手のリスクは、年々高まっています。レガシーシステムを支えてきたベテラン技術者の引退が進むほど、現行仕様を把握する人材は社内外ともに枯渇していきます。仕様を知る人がいなくなれば、現状把握のコストは跳ね上がり、最悪の場合は「中身が分からないまま動かし続けるしかない」状態に陥ります。一方で、AIによるコード解析の進歩は、この「失われた仕様」を取り戻す新たな手段を提供し始めています。つまり今は、人材の枯渇とAI技術の成熟が交差する、レガシー刷新にとって重要な転換点なのです。手をこまねくほど不利になる一方で、適切な手法とパートナーを選べば、これまでより速く・安全に刷新できる環境も整いつつあります。

レガシー刷新の3手法と自社診断（リホスト/リライト/リビルド）

開発会社を選ぶ前に、自社の刷新が「どの手法を中心に据えるべきか」を把握しておく必要があります。手法によって得意な会社タイプも費用も変わるためです。たとえばリホスト中心ならマイグレーション専業ベンダー、業務改革を伴うリビルドならコンサル一気通貫型、というように、手法と会社タイプは密接に結びついています。逆に言えば、手法を決めずに会社を探し始めると、各社の提案が噛み合わず比較できません。レガシー刷新の手法は、大きく3系統に整理できます。

リホスト系（早く・安く・まず動かす）

現行のアプリケーションをほぼそのまま、新しい基盤（クラウド等）へ「載せ替える」手法です。

• 目的：サポート切れ基盤からの脱却、ハードウェア老朽化への対処。
• メリット：費用・期間を抑えやすく、業務影響が小さい。
• 向くケース：システム自体は使えるが、稼働環境だけが限界に来ている。
• 注意点：ブラックボックス化や保守性の問題は残ったまま。根本解決にはならない。

リライト系（構造を整え保守性を回復する）

ロジックを保ちつつ、言語・フレームワークを現代的なものへ書き換える手法です。COBOLからJavaやモダンな言語への移行などが該当します。

• 目的：保守できる人材を確保しやすくし、技術負債を減らす。
• メリット：業務ロジックを維持しながら保守性・拡張性を回復できる。
• 向くケース：業務要件は概ね妥当だが、言語・構造が時代遅れ。
• 注意点：仕様の正確な把握が前提。ここでつまずくと品質が崩れる。

リビルド／リプレース系（業務ごと作り直す）

業務プロセスを見直し、システムをゼロから設計・構築する手法です。パッケージやSaaSへの置き換え（リプレース）も、業務ごと作り直すこの系統に含めて整理します。

• 目的：業務改革とセットで競争力を取り戻す。
• メリット：根本解決でき、将来のDXの基盤になる。
• 向くケース：業務プロセス自体が古く、システムだけ直しても効果が薄い。
• 注意点：費用・期間・社内負荷が最も大きい。要件定義の巧拙が成否を分ける。

3手法の比較と自社診断

簡易診断フロー

1. 業務プロセス自体を見直したい？ → YES：リビルド/リプレースを軸に検討。
2. 業務は概ねOKだが、言語・構造が古く保守人材がいない？ → YES：リライトを軸に検討。
3. システムは使えるが、稼働環境だけが限界？ → YES：リホストを軸に、段階的なモダナイゼーションを計画。

実際の刷新では、これらを組み合わせ「まずリホストで延命し、重要領域からリライト・リビルドする」という段階的アプローチが現実的です。手法ごとの詳細な選定基準とストラングラーパターンの実践はレガシーシステム刷新戦略｜リホスト・リプラットフォーム・リビルドの選び方で詳しく解説しています。

AIエージェント時代のレガシー移行 — 工期・コストはこう変わる

レガシー刷新の最大の難所は、「現行システムが何をしているのか誰も正確に説明できない」というブラックボックス問題です。従来、この現状把握（リバースエンジニアリング）には膨大な工数がかかり、刷新コストの大きな割合を占めてきました。設計書が失われ、コメントもないコードを、人間が一行ずつ読み解いて仕様を起こす——この作業に数ヶ月を費やすことも珍しくありませんでした。ここに、AIエージェント・AIコーディングの活用が変化をもたらしつつあります。この変化は、開発会社選びの基準そのものにも影響します。AIを使いこなせる会社とそうでない会社とで、同じ刷新の工期と費用に差が生まれ始めているからです。

AIをレガシー移行に活用できる代表的な工程は次のとおりです。

• ソースコード解析と仕様の逆生成：数十万行のコードをAIが読み解き、処理の流れ・データの依存関係・分岐条件を要約。ドキュメントが失われた現行仕様の「たたき台」を高速に作成する。
• 旧言語からのコード変換支援：COBOL等の旧言語を現代言語へ変換する際の下書きをAIが生成し、人間がレビュー・修正する。ゼロから書き起こすより着手が速い。
• テストの自動生成：現行の挙動を担保する回帰テストをAIが生成し、移行前後で「同じ結果になるか」を検証しやすくする。移行リスクの低減に直結する。
• 影響範囲調査の高速化：特定の項目やロジックを変更したときの波及範囲を、コード横断でAIに洗い出させる。

私たちkoromoは、こうしたAI活用によるプロダクト開発で「通常6ヶ月規模の開発を1ヶ月程度に圧縮する」アプローチを取っています（効果は案件の前提条件により異なります）。レガシー刷新においても、特に現状把握とテスト整備の工程でAIが効くため、従来は数ヶ月かかっていた初期フェーズを短縮できる余地があります。AIによるリファクタリングの実際はClaude Codeを活用したリファクタリングガイドで具体的に解説しています。

ただし、AI活用には明確な限界があります。AIが生成した仕様・変換コード・テストが「業務として正しいか」を判断するのは人間の役割です。レガシーシステムには、当時の業務上の理由でそうなっている例外処理が無数に埋め込まれており、その妥当性は現場の業務知識と突き合わせて検証しなければなりません。「AIで全自動移行」を謳う提案には注意が必要で、AIはあくまで人間の判断を高速化する道具として位置づけるべきです。技術負債そのものへの向き合い方は技術負債の解消アプローチも参照してください。

したがって、開発会社を選ぶ際は「AI活用の実績があるか」だけでなく、「AIの出力を業務観点で検証する体制があるか」までを確認することが重要になります。

AIが効く工程・効きにくい工程

AI活用の効果は工程によって大きく異なります。期待値を正しく持つために、整理しておきましょう。

この表からわかるとおり、AIは「現行を理解する」「変更の影響を調べる」「動作を担保する」といった、これまで人手で時間がかかっていた調査・検証系の工程で特に威力を発揮します。一方、「この業務ルールは今後も必要か」「どこから刷新すべきか」といった意思決定はAIに委ねられません。優れた開発会社は、この線引きを明確にしたうえでAIを道具として使いこなしています。

レガシー刷新の費用相場マトリクス（手法 × 規模）

競合記事の多くは「数千万円〜数億円」とだけ示しますが、実際の費用は**「手法」×「システム規模」**の組み合わせで大きく変わります。発注の目安として、概算レンジを整理します。

なお以下はあくまで一般的な目安であり、現行システムの状態・ドキュメントの有無・業務の複雑さによって変動します。正確な金額は必ず複数社からの見積もりで確認してください。

費用を左右する変動要因

• 現行仕様の見える化コスト：ドキュメントが無いほど、現状把握の工数が増える。
• データ移行の複雑さ：データ品質が低い、文字コードや形式が混在しているほど高くなる。
• 並行稼働期間：旧新システムを一定期間並行運用する場合、その分の運用コストが乗る。
• 業務側の関与度：要件確認や受け入れテストに業務部門が割けるリソースの量。

AI活用による削減の考え方

前章のとおり、AIは主に現状把握・テスト整備・コード変換の下書きで効きます。これらは従来コストの一定割合を占める工程のため、適切に活用できれば初期フェーズの工数を抑えられる可能性があります。ただし削減率はシステムの状態に大きく依存するため、「何%削減できる」と断定する提案ではなく、「どの工程に・どう適用し・誰が検証するか」を具体的に説明できる会社を信頼すべきです。逆に、AI活用の中身を語れずに大幅なコスト削減だけを強調する提案は、実態が伴っていない可能性があり注意が必要です。

補助金・公的支援の活用

刷新は投資額が大きいため、IT導入補助金やDX関連の公的支援の対象になる場合があります。年度や要件は変わるため、提案段階で補助金活用の知見がある会社かどうかも確認しておくとよいでしょう。

見積もりの読み方と比較のコツ

複数社から見積もりを取ると、同じ要件でも金額が大きく異なることに驚くかもしれません。安さだけで選ぶと、後から追加費用が膨らむケースが少なくありません。見積もりは次の観点で読み解きます。

• 現状把握（アセスメント）の費用が計上されているか：ここを省いた見積もりは、後で「想定外」を理由に追加請求が発生しやすい危険信号です。
• データ移行とテストの工数が明示されているか：レガシー刷新ではこの2つが工数の大きな割合を占めます。曖昧な見積もりは要注意です。
• 並行稼働・切り替えの費用が含まれるか：旧新システムの並行運用期間の運用コストが抜けていないか確認します。
• 保守・運用フェーズの費用感：刷新後の保守費用まで含めて総額（TCO）で比較します。

金額だけを横並びにするのではなく、「何にいくらかかるのか」の内訳の透明性で各社を比較するのが、失敗しない見積もり評価の基本です。

刷新の効果（ROI）をどう見るか

レガシー刷新は「コスト」ではなく「投資」です。投資判断のためには、刷新によって何が改善するかを定量・定性の両面で見積もる必要があります。定量面では、高騰する保守人材コストの削減、障害対応にかかる時間の削減、インフラ費用の最適化などが挙げられます。定性面では、新サービスを投入できるスピード、データ活用による意思決定の質、セキュリティ・コンプライアンスリスクの低減といった、放置した場合に失われる価値が含まれます。発注前にこれらの「刷新しない場合に膨らみ続けるコスト」を可視化しておくと、社内の投資合意も得やすくなります。

レガシー刷新を頼める開発会社4タイプと比較マトリクス

レガシー刷新を依頼できる会社は、得意領域によって大きく4タイプに分かれます。自社の規模・予算・スピード要求・上流支援の必要度に応じて、相性の良いタイプが変わります。検索すると「おすすめ◯選」という会社一覧の記事が多く見つかりますが、社名を並べたランキングを眺めても、自社にどれが合うかは判断できません。重要なのは個社名より先に「どのタイプの会社が自社の刷新に向いているか」を見極めることです。タイプを絞れば、そのタイプの中から具体的な候補社を効率よく比較できます。

① 大手SIer

NTTデータ、TIS、富士通系などの大規模システムインテグレーター。

• 強み：大規模・ミッションクリティカルな基幹系の刷新実績、安定した体制、品質管理。
• 向くケース：金融・公共・大企業の基幹システムで、規模と信頼性が最優先。
• 留意点：費用が高くなりやすく、スピードや柔軟性は中小規模案件には過剰なこともある。

数百人規模が関わる勘定系・生産管理系のように、止まれば事業全体に影響が及ぶシステムでは、長年の実績に裏打ちされた品質保証とプロジェクト管理体制が何よりの安心材料になります。一方で、その重厚な体制は小回りを犠牲にするため、「スピード感を持って小さく試したい」案件には向きません。

② マイグレーション専業ベンダー

レガシー移行・モダナイゼーションを専門にする独立系企業。

• 強み：言語変換や基盤移行のノウハウ・ツール・実績が豊富。リホスト/リライトに強い。
• 向くケース：現行ロジックを保ったまま、言語・基盤を確実に移行したい。
• 留意点：業務改革（リビルド）や上流のDX構想までは守備範囲外の場合がある。

COBOLからの言語変換や特定ERPからの移行など、同種の案件を何度も手がけている専業ベンダーは、移行特有の落とし穴を熟知しています。「動作を変えずに確実に移す」ことに価値があるケースでは、最も頼れる選択肢です。ただし、移行を機に業務そのものを変えたい場合は、上流設計に強い会社と組み合わせる必要があります。

③ コンサル一気通貫型

構想策定から設計・開発・移行まで一貫支援するコンサルティング兼開発企業。

• 強み：業務改革を伴う刷新の上流（あるべき姿の設計）に強い。
• 向くケース：システムだけでなく業務プロセスから見直したい。
• 留意点：上流偏重で実装力に差がある場合があり、開発の実行体制を見極める必要がある。

「現行システムをそのまま作り直すのではなく、この機会に業務のやり方ごと見直したい」という経営判断がある場合に力を発揮します。全社のIT戦略を再設計し、刷新の優先順位や投資配分まで描けるのが強みです。ただし、構想は立派でも実装フェーズで外部に再委託する会社もあるため、設計から開発・移行までを誰が担うのか、実行体制を契約前に確認しておく必要があります。

④ AIネイティブ開発会社

AIエージェント・AIコーディングを前提に高速開発を行う新興の開発会社（koromoもこのタイプ）。

• 強み：AIによる現状把握・テスト整備・実装の高速化。スピードとコスト効率。
• 向くケース：スピードを重視し、AI活用による工期短縮の余地が大きい刷新。中小〜中堅企業とも相性が良い。
• 留意点：超大規模・高度な規制対応案件では、大手SIerとの役割分担が必要なこともある。

ブラックボックス化した現行システムの解析や、移行を担保する回帰テストの整備といった、従来は人手で時間がかかっていた工程をAIで圧縮できるのが最大の特徴です。「予算は限られるが、保守人材の枯渇が迫っていてスピーディに刷新したい」という中小・中堅企業の悩みに、コストとスピードの両面で応えられます。AI活用の実態と限界を理解し、その出力を業務観点で検証できる体制を持つ会社を選ぶことが重要です。

4タイプ比較マトリクス

（◎＝特に強い、○＝対応可、△＝相対的に弱い）

どのタイプが正解かは一律には決まりません。たとえば「大規模基幹系×高い規制要件」なら大手SIerや専業ベンダーが軸になり、「スピード重視×AI活用で工期を圧縮したい中堅企業」ならAIネイティブ開発会社が有力です。業務改革を伴うなら、上流に強い会社と実装に強い会社を組み合わせる選択肢もあります。AI領域の会社比較はAI開発会社おすすめ30選比較、受託開発全般の比較は受託開発会社の比較も参考にしてください。

タイプ選定で陥りやすい誤解

会社タイプを選ぶ際、規模の大きい会社ほど安心という思い込みは禁物です。大手SIerは大規模・高信頼性の案件で真価を発揮しますが、中小規模の刷新では体制が重く、意思決定に時間がかかり、結果として費用対効果が合わないことがあります。逆に、スピードとコストを重視するあまり実績の浅い会社に発注すると、ブラックボックス化したシステムの現状把握でつまずき、かえって手戻りが増えます。

判断の軸は「会社の大きさ」ではなく「自社の刷新の性質との相性」です。具体的には、(1) 移行の難度（現行システムの複雑さ・属人化の度合い）、(2) 業務改革を伴うか、(3) スピードとコストの優先度、(4) 自社が割けるリソース量——この4点を整理してからタイプを絞り込むと、ミスマッチを避けられます。多くの場合、1社にすべてを任せるのではなく、上流（構想・アセスメント）と実装で会社を分ける、あるいは主担当と補完役を組み合わせる方が、結果的にリスクとコストの両方を抑えられます。

状況別・おすすめパートナータイプ早見

この早見表はあくまで出発点です。実際には複数の状況が重なるため、候補タイプを2つ程度に絞ったうえで、次章の7基準で具体的に比較していくのが確実です。

失敗しない開発会社の選び方 — 7評価基準＋スコアシート

会社のタイプを絞り込んだら、具体的な評価に入ります。レガシー刷新では「技術力があるか」だけで選ぶと失敗します。最新の技術スタックを持っていても、業務を理解せず、移行リスクの管理が甘ければ、刷新は途中で頓挫します。重要なのは、ブラックボックス化したシステムを安全に移行しきれるか、そして自社の業務を理解して伴走してくれるかです。提案の見栄えや実績の数だけでなく、次の7基準で多面的に評価しましょう。

1. 現行技術環境への対応実績：自社が使う言語・基盤（COBOL、特定ERP等）の移行実績があるか。
2. 現状把握（アセスメント）能力：ドキュメントが無い前提で、現行仕様を解析・可視化できるか。
3. 移行リスクの管理体制：並行稼働・切り戻し（ロールバック）・段階移行の戦略を提示できるか。
4. 業務理解と提案力：自社の業界・業務課題を理解し、技術ではなく課題起点で提案できるか。
5. AI活用と検証体制：AIで工程を加速しつつ、その出力を業務観点で検証する体制があるか。
6. 伴走姿勢とコミュニケーション：丸投げを許さず、発注者を巻き込んで進める体制か。
7. 撤退・見直し基準の明示：うまくいかないときの判断基準（Go/No-Go）を契約前に示せるか。

選定スコアシート

候補3〜5社を、各基準を5点満点で採点し、重要度で重み付けすると比較しやすくなります。

RFP・相談時に入れるべき質問

• 当社と同じ言語・基盤の移行実績を、具体的な規模感で教えてください。
• ドキュメントが無い現行システムを、どう解析・可視化しますか。
• 移行時の切り戻し（ロールバック）戦略はどう設計しますか。
• AIを使う工程と、その出力を誰がどう検証するかを教えてください。
• プロジェクトが想定どおり進まない場合の見直し・撤退の判断基準は何ですか。

企業規模別・業種別のレガシー刷新アプローチ

同じ「レガシー刷新」でも、企業規模や業種によって最適な進め方と発注先は変わります。自社の状況に近いケースを参考にしてください。

中小企業のレガシー刷新

予算と社内のIT人材が限られる中小企業では、いきなり基幹システム全体のリビルドに踏み切るのはリスクが大きすぎます。現実的なのは、最も困っている一つの業務領域に絞り、リホストやSaaS置き換えで段階的に刷新する進め方です。発注先は、小回りが利き、AI活用でコストを抑えられるAIネイティブ開発会社や、特定領域に強い専業ベンダーが相性良好です。IT導入補助金などの公的支援を活用できる場面も多いため、補助金の知見がある会社を選ぶと負担を軽減できます。

中堅企業のレガシー刷新

事業が拡大し、システムが成長の足かせになり始めるのが中堅企業の典型的な悩みです。複数の業務システムが連携して動いており、一部が老朽化している——というケースが多く見られます。この規模では、影響範囲を見極めながら優先度の高い領域から刷新し、AI活用で工期を圧縮するアプローチが効果的です。スピードとコスト効率を両立できるAIネイティブ開発会社や、上流から実装まで一貫支援できる会社が候補になります。

大企業・基幹系のレガシー刷新

金融・製造・公共など、ミッションクリティカルな基幹システムを抱える大企業では、信頼性と移行の安全性が最優先です。大規模なデータ移行、厳格な規制対応、長期にわたる並行稼働が必要になるため、実績豊富な大手SIerやマイグレーション専業ベンダーが軸となります。ただし、現状把握やテスト整備といった工程ではAI活用の余地があり、AIネイティブ開発会社を部分的に組み合わせて全体の工期を短縮する設計も現実的になってきています。

業種特有の留意点

• 金融・保険：規制対応とデータ移行の正確性が極めて重要。監査証跡を残せる体制が必須。
• 製造業：生産管理・在庫管理システムは止められないため、段階移行と切り戻し戦略が肝。
• 小売・流通：繁忙期を避けた移行計画と、店舗・現場への展開設計が成否を分ける。
• 公共・自治体：調達ルールと長期保守を前提とした、ドキュメント整備の徹底が求められる。

契約形態 × フェーズ最適マッチング

レガシー刷新は一括の請負契約で丸ごと発注すると、不確実性の高い現状把握フェーズで見積もりが膨らんだり、手戻りが起きたりします。フェーズごとに最適な契約形態を使い分けることが、コストとリスクを抑える鍵です。

レガシー刷新の難しさは、着手の段階では「何をどこまで作り直すか」が確定できない点にあります。現行システムを解析してみて初めて、移行の難度や必要な工数が見えてくるためです。にもかかわらず、すべてを最初から請負契約で固めようとすると、開発会社は不確実性をリスクとして見積もりに上乗せせざるを得ず、結果として費用が高止まりします。逆に、安く請けた会社が想定外の事態で立ち行かなくなるケースもあります。この構造を理解したうえで、不確実性の高い前半は準委任、範囲が固まった後半は請負、という使い分けが合理的です。

「まずアセスメントを準委任で実施し、その結果をもって移行実装の請負範囲を確定する」という二段階の進め方は、不確実性を見積もりに織り込むうえで合理的です。契約形態ごとの違いとリスク配分は受託開発会社の比較で詳しく解説しています。

レガシー刷新の失敗5類型と早期検知シグナル

レガシー刷新は失敗率が高いプロジェクトです。代表的な失敗パターンと、その「予兆」を知っておくことで、早期に軌道修正できます。

これらの多くは、システム開発全般の失敗パターンと共通しています。より具体的な事例はシステム開発の失敗事例7選で解説しています。発注前にこれらのシグナルを評価軸に組み込んでおくことで、提案の「危うさ」を見抜けるようになります。

特に注意したいのが、**「ビッグバン移行の破綻」**です。旧システムを一斉に止めて新システムへ切り替える方式は、一見すると工期が短く費用も安く見えます。しかし、ブラックボックス化したレガシーでは想定外の挙動が必ず潜んでおり、一括切り替えはそのリスクを最大化します。実績ある開発会社は、機能やデータを少しずつ新システムへ移していく「ストラングラーパターン」のような段階移行を前提に計画します。提案書に切り戻し（ロールバック）の手順や、移行を区切る単位が書かれているかは、その会社の経験値を測る良い指標です。

もう一つ見落とされがちなのが、**「ベンダーロックインの再生産」**です。せっかく刷新しても、新システムが特定ベンダーの独自技術や非公開仕様に依存していれば、数年後に同じ問題が繰り返されます。オープンな技術の採用と、仕様書・運用手順の整備を契約条件として明記しておくことで、将来の選択肢を確保できます。

ベンダーロックインから脱却すべきか — 判断フロー

レガシー刷新では「現行システムを保守している既存ベンダーに引き続き頼むか、別の会社に乗り換えるか」が悩みどころです。既存ベンダーは現行仕様に詳しい一方、依存が続くと価格交渉力を失い、刷新の選択肢も狭まります。次の観点で判断します。

• 既存ベンダー継続が向くケース：現行仕様が複雑で属人化が極端、移行の難度が非常に高く、まずは安全に基盤刷新（リホスト）だけ進めたい場合。
• 乗り換え・複数社検討が向くケース：業務改革を伴うリビルドを行う、コストの妥当性を競争原理で検証したい、AI活用など新しい進め方を取り入れたい場合。
• 折衷案：アセスメントだけ第三者に依頼し、現行仕様を「自社の資産」として可視化したうえで、移行実装の発注先を競争で選ぶ。

重要なのは、現行仕様の可視化（ドキュメント化）を自社の手に取り戻すことです。仕様が自社資産になっていれば、どのベンダーに発注しても主導権を保てます。前述のとおり、この可視化工程はAIによる解析で加速できる余地が大きい領域です。

ベンダーロックインは、価格交渉の不利だけでなく、刷新そのものを遅らせる要因にもなります。現行ベンダーにとって、刷新は自社の保守売上を失うことを意味するため、刷新に消極的な提案になりがちな構造的問題があるのです。だからこそ、刷新の意思決定にあたっては、現行ベンダーの提案を鵜呑みにせず、第三者の視点を一度入れることが有効です。アセスメントだけでも外部に依頼すれば、「本当に作り直しが必要か」「どこから手をつけるべきか」を客観的に判断でき、その後の発注の選択肢が大きく広がります。

レガシー刷新の進め方と発注者の関与

最後に、刷新プロジェクトの基本的な流れと、各段階で発注者が担うべき役割を整理します。開発会社に任せきりにせず、要所で主体的に関与することが成功の条件です。

1. アセスメント（現状把握）：現行システムの棚卸し、依存関係・利用状況の可視化。
   • 発注者の役割：業務知識の提供、キーパーソンの確保。
2. 構想・要件定義：刷新の目的・ゴール・成功指標（KPI）の言語化、手法の選定。
   • 発注者の役割：何を達成したいかの意思決定、優先順位付け。
3. 設計・開発・データ移行：新システムの構築、移行とテスト。
   • 発注者の役割：受け入れテスト、業務側の確認。
4. 本番化・定着：段階的な切り替え、運用移管、効果測定。
   • 発注者の役割：現場への展開、運用体制の整備。

各フェーズを通じて欠かせないのが、開発会社との密なコミュニケーションです。レガシー刷新では、解析を進める中で当初は見えていなかった課題が次々と現れます。その都度、発注者と開発会社が認識をすり合わせ、優先順位を調整できるかどうかが、プロジェクトの軌道を保つ生命線になります。定例の進捗確認の場を設け、課題と決定事項を文書で残す——こうした地道な運用が、「気づいたら大幅な手戻りが発生していた」という事態を防ぎます。丸投げせず、かといって過度に介入しすぎず、要所で意思決定を担うのが、発注者の理想的な関与の形です。

特に重要なのは、**「一度に全部やらない」**という原則です。優先度の高い領域から段階的に刷新することで、リスクと社内負荷を分散できます。外注と内製のどちらをどう組み合わせるかは内製と外注の使い分け、外注の進め方はプロダクト開発の外注ガイドも参考にしてください。

発注前にやるべき準備チェックリスト

開発会社に相談する前に、自社で次の項目を整理しておくと、提案の質が上がり、見積もりのブレも小さくなります。準備不足のまま発注すると、現状把握フェーズで想定外の工数が発生し、費用が膨らむ典型的な原因になります。

• 現行システムの棚卸し：どのシステムが、誰によって、何の業務に使われているかを一覧化する。
• 困りごとの優先順位付け：「保守人材がいない」「新機能を足せない」など、刷新で解決したい課題を重要度順に並べる。
• 刷新の目的とゴールの言語化：刷新後にどうなっていたいか、成功をどう測るか（KPI）を決める。
• 現行資料の収集：残っている設計書・仕様書・運用手順を集める（無くても問題ないが、あれば現状把握が速くなる）。
• キーパーソンの確保：現行業務とシステムを把握している担当者を、プロジェクトに関与できる体制にする。
• 予算とスケジュールの大枠：いくらまで、いつまでに、という制約条件を整理しておく。
• 段階化の検討：一度に全部か、領域を絞って段階的にか、の方針を持っておく。

これらは完璧でなくても構いません。むしろ「現行仕様が分からない」こと自体が刷新の出発点であり、その可視化こそ開発会社の腕の見せ所です。準備の目的は、発注者として「何を達成したいか」を明確にし、提案を正しく評価できる状態を作ることにあります。

まとめ：自社に最適な刷新パートナーの選び方

レガシーシステム刷新の開発会社選びは、次の3ステップで進めるのが確実です。

1. 手法と目的を言語化する — リホスト/リライト/リビルドのどれを軸にするか、何を達成したいかを決める。
2. 会社タイプを絞る — 大手SIer/専業マイグレベンダー/コンサル一気通貫/AIネイティブ開発会社から、規模・予算・スピードで候補タイプを選ぶ。
3. 7基準とスコアシートで比較する — 現状把握能力・移行リスク管理・AI検証体制・撤退基準の明示を軸に、複数社を採点して選定する。

「2025年の崖」を越えた今こそ、レガシー刷新は「いつかやる課題」から「事業継続のために今着手する経営課題」へと変わっています。AIエージェントの活用で、かつて最大の壁だった現状把握の工程は確実に軽くなりつつあります。自社の状況に合ったパートナーを選び、段階的に・着実に刷新を進めていきましょう。

最後にもう一度強調しておきたいのは、レガシー刷新は「正しいパートナー選び」と「正しい進め方」の両輪で決まるということです。どれほど優れた開発会社でも、目的が曖昧なまま丸投げすれば成果は出ません。逆に、発注者が刷新の目的と優先順位を明確に持ち、現状把握を独立フェーズとして確保し、段階的に移行する設計を取れば、難度の高い刷新でも成功確率は大きく高まります。本記事で紹介した4タイプの見極め、費用相場の読み方、7基準のスコアシート、失敗5類型の早期検知を、自社の発注検討にぜひ役立ててください。私たちkoromoも、AI活用による現状把握の高速化と高速開発で、レガシー刷新のご相談に対応しています（適用範囲や効果は現行システムの状態により異なります）。

よくある質問