【2026年版】老朽化システム刷新ガイド｜画面単価方式で進める段階的モダナイゼーション完全マニュアル

「動いているから触らない」——多くの中小企業が、老朽化したシステムを目の前にしてこう判断します。実際、2026年現在も日本企業の61%でレガシーシステムが残存していると経済産業省は報告しています（2025年5月「レガシーシステムモダン化委員会総括レポート」）。

本記事は、システム刷新を検討する経営者・情シス担当者に向けた実務ガイドです。一般論から入らず、まずFUNBREWが実際に刷新をやって分かったことから書きます。そのうえで、画面単価方式とPhase制で費用と進め方をどう決めるかを説明します。

1. PHP 5系のECサイトをLaravelへ刷新して分かったこと

先に結論を書きます。刷新でいちばん時間を要したのは、新しいシステムを作る工程ではありませんでした。今動いている古い環境をもう一度作り直す工程と、発注側にしかできない受入テストの2つです。FUNBREWがPHP 5系で動いていたECサイトをLaravelへ刷新した案件（期間2ヶ月）で、実際に起きたことを書きます。

いちばん大変だったのは「昔の環境をもう一度作る」こと

刷新の第一歩は、現行システムを開発側の手元で動かせるようにすることです。ところがPHP 5系のコードは、現在のPHP・OS・ミドルウェアの組み合わせではそのまま起動しません。つまり刷新を始める前に、あえて当時のバージョンの環境を作る作業が必要になります。

これは新しい環境を用意するより手間がかかります。古いバージョンは公式の配布が終了していることがあり、依存ライブラリや拡張モジュールも同時代のものを揃える必要があるためです。しかもこの工程は成果物として目に見えないため、見積もりの検討でも軽く扱われがちです。

• 現行と同じ環境を再現できないと、「今どう動いているか」を確認しないまま作り直すことになる
• 再現に手間取ると、刷新そのものが始まる前に期間を消費する
• 発注側がサーバー構成の情報（PHPのバージョン、OS、データベース、拡張モジュール、定期実行処理）を最初に出せると、この工程は短くなる

自社システムのPHPがどのバージョンで、いつサポートが切れるのかはPHPサポート終了日カレンダーで確認できます。

一括で切り替えたが、並行稼働できる準備はしていた

このECサイトは一括切替で移行し、大きな問題は起きませんでした。ただし最初から一括と決めていたわけではなく、途中で並行稼働に切り替えられる形で進めています。

一括で切り替えられるかどうかは、データ量と業務を止められる時間で決まります。現行システムを調べる前から「一括で」「段階で」と方式を決め打ちする提案には注意してください。判断材料は後述のPhase 1（調査・可視化）で揃います。

受入テストは発注側にしかできない

技術面より苦労したのは、発注側に受入テストという考え方がなかったことです。受入テストとは、発注側が「発注したとおりに動くか」を自分の業務で確認する工程を指します。

刷新の合格条件は、多くの場合「前とまったく同じように動くこと」です。そして何が"前と同じ"なのかを最もよく知っているのは、毎日それを使っている発注側です。開発側はソースコードからしか現行の仕様を読み取れず、長年の運用で積み上がった例外的な使い方までは復元できません。

• 受入テストを開発会社に任せきりにすると、拾えなかった仕様がそのまま本番で表面化する
• 見積もりを取る段階で「誰が」「どれだけの時間」テストに充てられるかを社内で決めておく
• 確認の順序は、毎日使う画面 → 月末や年度末など特定のタイミングだけ動く機能、の順に洗い出すと漏れにくい

2. 「2025年の崖」を超えて — 老朽化システムが招く現実のリスク

経済産業省は2018年9月公表の「DXレポート」で、企業の基幹系システムが古くなり保守困難に陥る問題を「2025年の崖」と命名しました。当時、運用21年以上の基幹システムを抱える企業は20%でしたが、2025年には60%に達すると予測されていました。

2025年5月の経産省総括レポート — 予測は現実になった

2025年5月28日、経済産業省は「レガシーシステムモダン化委員会総括レポート」を公表し、ユーザー企業の61%でレガシーシステムが残存している現状を明らかにしました。2018年の警告通り、日本企業の半数以上が老朽化システムを抱えたまま2025年を迎えてしまったのです。

12兆円/年の経済損失と人材不足

同DXレポートが警告した経済損失は、レガシーシステムの放置が続いた場合2025年以降に最大12兆円/年に達する規模です。さらにIT人材需給の試算（経産省2019）では、2030年にIT人材は中位シナリオで約45万人、高位シナリオで約79万人不足するとされています。古い技術を扱えるエンジニアは年々減少し、保守を依頼できる会社が見つからない状況が現実化しています。

「動いているから触らない」が最大のリスク

老朽化システムの放置で具体化しているリスクは以下の4つです。

• セキュリティ脆弱性 — サポート切れのフレームワーク・ライブラリは脆弱性が修正されない。情報漏洩・サイバー攻撃の温床に。
• パフォーマンス低下 — データ量増加に耐えられず、業務効率が落ち続ける。
• 人材確保が困難に — レガシー技術を扱えるエンジニアが市場から消え、保守費が高騰する。
• 突然の停止リスク — サーバーOSやPHPバージョンの非対応で、ある日突然動かなくなる。

3. あなたのシステムは「刷新」「引き継ぎ」「保守継続」のどこにいるか

老朽化システム対策には3つの選択肢があります。それぞれ守備範囲が異なるため、まず自社の状況を客観的に判断することが重要です。

判断フレーム — 3つの分岐

「刷新が必要」と判断する3つの基準

以下のいずれかに該当する場合は、刷新を本格的に検討すべきタイミングです。

• 技術的限界 — フレームワーク・OS・DBエンジンのサポートが終了済み、または1年以内に終了予定
• 機能的限界 — モバイル対応・API連携・新機能の追加が現行アーキテクチャでは実現できない
• コスト的限界 — 小さな改修でも見積もりが高額になり、保守費が年々増加している

このうち2つ以上が該当する場合、リファクタリングや延命では費用対効果が合わなくなる局面です。業務システム移行の注意点10選もあわせてご確認ください。

4. 老朽化システムの5つの症状 — 自己診断チェックリスト

具体的な刷新タイミングを見極めるための自己診断チェックリストです。3つ以上当てはまる場合は、Phase 1（調査・可視化）からの着手をおすすめします。

• 症状1：技術スタックの陳腐化 — PHP 5系/CakePHP 1.x/jQuery依存/サーバーOSがCentOS 7以前など、サポート終了済み技術で稼働している
• 症状2：属人化と引き継ぎ困難 — システムの仕組みを把握している人が1〜2名しかおらず、退職リスクを抱えている
• 症状3：改修コストの高騰 — 「ボタン1つ追加」レベルの改修でも、見積もりが数十万〜数百万円に膨らむ
• 症状4：外部連携の限界 — 新しいSaaSやAPIとの連携ができず、業務フローが分断されている
• 症状5：セキュリティ指摘 — 脆弱性診断・SIerからのセキュリティ監査で指摘を受けている、または情報漏洩リスクを認識している

5. なぜ「段階的アプローチ」が必然か — Phase制の必然性

老朽化システム刷新では、一括リプレース（ビッグバン方式）は失敗確率が極めて高いのが業界の共通認識です。中小企業の刷新は、Phase制による段階的アプローチが事実上の必然となっています。

一括刷新が失敗する3つの理由

• 仕様の見落とし — 現行システムは長年の業務改善が積み上がっており、ドキュメント化されていない暗黙仕様が多数存在する。一括で作り直そうとすると必ず漏れる。
• 業務停止リスク — 切替日に問題が発覚すると業務が完全に停止し、復旧にも時間がかかる。
• 予算超過 — 全画面を同時に作るため、初期投資が大きく、途中で予算が尽きるとプロジェクトが頓挫する。

FUNBREWのPhase制 — 2段階アプローチ

FUNBREWでは老朽化システム刷新を以下の2フェーズに分割します。

Phase 1単独の発注も可能です。調査結果を見てからPhase 2に進むかを判断できるため、リスクを最小化できます。

6. 画面単価方式で見積もる刷新費用

「一式◯◯万円」のブラックボックス見積もりの問題

大手SIerの刷新見積もりは「一式3,000万円」「一式5,000万円」といった包括方式が一般的です。これには以下の問題があります。

• 何にいくらかかっているのかが不明（PMフィー・営業フィー・予備費が積まれている）
• 不要な画面を後回しにする調整が困難
• 追加費用の根拠が示されにくい

画面単価方式 — 透明性のある料金算出

FUNBREWでは画面の難易度別に4ランクの単価を設定し、画面数 × 単価で費用を算出します。

バッチ処理（裏側の定期実行処理）も同様に4ランクで料金が決まります（S 3万円〜C 12万円/本）。

試算例 — 30画面・10バッチの業務システムの場合

典型的な中小企業向け業務システムの試算例です。

Phase 2（刷新開発）も同じ単価ロジックで算出されます。小規模10画面・中規模30画面・大規模80画面の3パターンの実物見積もりサンプルは画面単価方式の見積もりサンプル公開でご確認いただけます。

大手SIer・フリーランスとの比較

7. Phase 1（調査・可視化）だけでも発注する価値

FUNBREWの最大の特徴は、Phase 1（調査・可視化）の単独発注を歓迎している点です。「いきなり刷新は決められない」「まず現状を把握してから判断したい」というニーズに応えます。Phase 1で実際に作成する画面棚卸し表・優先順位マトリクス・Phase 2見積書の実物サンプルはPhase 1調査の中身を実物公開で公開していますので、発注前にイメージを掴みたい方はあわせてご覧ください。

Phase 1納品物 — 6種類のドキュメント

Phase 1完了時に納品される6種類のドキュメントは、それぞれ独立した活用価値を持ちます。

1. 画面一覧表（Excel）— 全画面の機能概要・難易度ランク・刷新時の見積単価を記載。用途：刷新見積もりの根拠資料、他社への仕様伝達、社内稟議資料
2. バッチ処理一覧表（Excel）— 画面に表れない裏側の定期実行処理を洗い出し。用途：運用設計の引き継ぎ、障害時の影響範囲把握
3. 各処理の機能概要書（Word/Markdown）— 画面・バッチの処理内容を技術者でなくても理解できるレベルで記述。用途：仕様理解の共有、新規開発の要件定義インプット
4. 不明点・リスクQAリスト（Excel）— 調査過程で発見した不明点・仕様矛盾・潜在リスクをリスト化。用途：刷新プロジェクト開始前の課題整理、現行ベンダーへの確認リスト
5. 操作マニュアル（簡易版）（Word/PDF）— 主要操作手順を画面キャプチャ付きで作成。用途：新任担当者の教育資料、現行運用の標準化
6. システム構成図・技術スタック整理（draw.io＋Excel）— インフラ構成、使用技術、外部サービス連携をビジュアル化。EOL情報も付記。用途：セキュリティリスク評価、インフラ移行計画の策定

Phase 1単独発注の3つの活用シーン

• シーン1：社内稟議 — 経営層への刷新提案資料として、現状リスクと刷新見積もり根拠を可視化
• シーン2：相見積もり — 他社への発注を検討する際の汎用仕様書として活用。FUNBREWに刷新を依頼しなくてもOK
• シーン3：保守引き継ぎ — 現行ベンダーから別の保守会社へ移管する際の引き継ぎ資料。システム保守引き継ぎの手順もご参照ください

8. 刷新プロジェクトの実務 — データ移行・並行稼働・受入テスト

Phase 2（刷新開発）の実務は、データ移行・並行稼働・受入テストの3つが品質を左右します。

データ移行の3パターン

詳細はデータ移行ガイドをご参照ください。

並行稼働（パラレルラン）の進め方

並行稼働は新旧システムを一定期間（通常1〜3ヶ月）同時に動かし、データ整合性と業務適合性を検証する工程です。Phase 2のリスク低減の要となります。

• 第1週：シャドー運用 — 新システムは結果を表示するだけで、業務判断は旧システムで実施
• 第2〜4週：ダブルエントリー — 業務担当者が新旧両方にデータを入力し、結果を比較
• 第5週以降：新システム主軸 — 業務判断を新システムで実施し、旧システムはバックアップとして残す

カットオーバー（切替）の判断基準

旧システムを完全停止する判断は、以下の3条件をすべて満たした時点で実施します。

• 並行稼働期間中、データ不整合が連続3週間ゼロ
• 業務担当者からの操作性フィードバックが反映済み
• 受入テスト（UAT）で重大欠陥がゼロ

9. 「古いシステムのまま改修」は選べる。ただし予算感は合わないことが多い

古いフレームワークのまま機能を追加すること自体は、技術的には可能です。ただし費用はWeb制作の相場感には収まりません。実際に、そこで折り合わなかった案件があります。

実際にあった相談 — 古いCakePHPへの機能追加

「今のシステムのまま機能を足したい」というご相談でした。技術的にはできます。しかしお出しした見積もりは、ご想定の金額と桁が違いました。理由は次の3つです。

• 当時の開発環境を用意する工程が先に発生する — 前述のとおり、古いバージョンの再現は新規構築より手間がかかる
• サポートが切れたフレームワークは、触った箇所以外への影響を公式情報で確認できない — そのリスクを開発会社が引き受ける分が金額に乗る
• 触れる技術者が減っている — 古い技術を扱える人の確保自体が難しくなっている

ご想定の予算は、Web制作の感覚から来ていました。高くて数十万円、という水準です。ページを作る仕事と、動いている古いシステムに手を入れる仕事は、費用の決まり方が違います。前者は作る量で決まりますが、後者は触った結果どこまで影響が及ぶか分からない不確実性で決まります。

折り合わなかった結果、何が残ったか

この案件は費用が折り合わず、古いシステムのまま一部だけを改修する形になりました。セキュリティパッチは当てられないままです。それがこの判断で実際に残ったものです。

刷新の判断は「やるべきかどうか」ではなく、「今のリスクを持ち続けられるかどうか」で決まります。予算が出せないなら持ち続けるのも一つの判断です。ただし、その場合に何が残るのかは発注前に知っておいてください。

10. ベンダー選びで気をつける7つのポイント

老朽化システム刷新は数百万〜数千万円規模の投資となります。ベンダー選定で確認すべき7つのポイントを整理しました。

① 画面単価方式か、一式見積もりか

「一式◯◯万円」のブラックボックス見積もりは、PMフィー・営業フィー・予備費が積まれているため割高になりがちです。画面ごとの単価を提示できるベンダーを優先してください。

② Phase 1単独発注に対応するか

「調査だけ」を断られる場合、刷新まで一気通貫で発注することが前提となります。リスク分散のため、Phase 1のみの発注に応じるベンダーを選ぶべきです。

③ 既存ソースを読める担当者がいるか

レガシーPHP（PHP 5系・CakePHP 1.x・FuelPHPなど）やフレームワーク未使用のレガシーコードを読める担当者が在籍しているか確認してください。「ヒアリングだけで仕様を作る」ベンダーは要注意です。

④ 段階移行（Strangler Pattern）の経験があるか

既存システムの一部を新システムに置き換えながら、徐々に旧システムを「絞め殺す」（Strangle）アプローチの実績があるか確認してください。一括リプレースしか提案しないベンダーはリスクが高いです。

⑤ NDA・コード受け渡しのプロトコルが整っているか

ソースコードを共有する前にNDA（秘密保持契約）を締結し、Git権限の一時付与・暗号化転送・VPN経由アクセスなど、明確なコード受け渡し手順を持っているか確認します。

⑥ 中小規模に最適化されているか

大手SIerは100画面以下の中小規模刷新を「割に合わない」案件として扱うことがあります。逆にフリーランスは10画面以上で対応困難になります。30〜100画面規模に最適化されているベンダーが理想です。

⑦ 刷新後の保守体制があるか

刷新だけして保守は別ベンダーという形では、知見の引き継ぎコストが発生します。月額保守を提供しているベンダーを選ぶことで、リリース後の運用も安定します。

11. 刷新事例 — PHP5基幹システム／LMS／WordPress復旧

事例1：老朽化PHP基幹システムのフルリプレース

7年以上運用されたPHP 5＋独自フレームワークの基幹システムを、Laravel + Vue.js + PostgreSQLでフルリプレース。期間4ヶ月、データを完全移行しながらUIを全面刷新しました。表示速度3倍向上、セキュリティリスク解消、保守コスト60%削減を達成しています。

事例2：企業向けLMS（オンライン学習サービス）の刷新

PC専用テキストベースの社員教育システムを、Laravel + Vue.js + FFmpegでスマートフォン対応・動画学習・学習分析機能付きに刷新。期間6ヶ月、スマートフォンでの受講と、管理者ダッシュボードでのリアルタイム進捗把握を実現しました。

事例3：3年放置WordPressのセキュリティ復旧

3年以上アップデートされていなかった企業サイトのWordPressを、PHP・WordPress本体・全プラグインを最新化。2週間で脆弱性ゼロの状態に復旧しました。「刷新」とはフルリプレースだけではなく、保守復旧型の刷新も含まれます。

12. 刷新の最初の一歩は「画面数を伝える」だけ

FUNBREWの刷新サービスは、お問い合わせ時の情報量を最小化しています。現行システムの画面数だけお伝えいただければ、1〜2営業日で概算見積もりをご提示します。

概算見積もりまでの3ステップ

1. STEP 1：お問い合わせ — Webフォームまたはお電話で「画面数（おおよそで可）」「使用言語・FW」「現状の課題」を伝える
2. STEP 2：概算回答 — FUNBREWから1〜2営業日以内に画面単価ベースの概算金額と期間目安を回答
3. STEP 3：詳細ヒアリング — 概算で進めたい場合、30分のオンライン面談で詳細を確認し、Phase 1の正式見積もりへ

まとめ — 刷新の判断はデータで、進め方は段階的に

老朽化システム刷新の本記事のポイントを整理します。

• 経産省最新レポート（2025年5月）では61%の企業がレガシー残存。「2025年の崖」は予測通り現実化した
• 「刷新」「引き継ぎ」「保守継続」は別の選択肢。判断フレームで自社の位置を確認する
• 5つの症状（技術陳腐化／属人化／改修コスト高騰／外部連携限界／セキュリティ指摘）のうち3つ以上当てはまればPhase 1着手のタイミング
• 一括リプレースは失敗確率が高い。Phase制（調査→刷新）と画面単価方式でリスクを最小化
• Phase 1（調査・可視化）の納品物6種類は、社内稟議・相見積もり・引き継ぎにも使える汎用資産
• ベンダー選定は「画面単価」「Phase 1単独可」「ソース解析力」「段階移行経験」「NDA体制」「中小規模最適化」「刷新後保守」の7点で確認
• 刷新の期間を外す原因は新規開発ではなく、古い環境をもう一度作る工程にあることが多い
• 受入テストは発注側にしかできない。「前と同じ」を知っているのは使っている側なので、見積もり段階で担当と時間を決めておく
• 「古いまま改修」も選べるが、その場合はセキュリティパッチが当たらない状態が残る

関連記事

• Phase 1調査の中身を実物公開｜画面棚卸しサンプル付きで解説 — Phase 1の成果物を実物で確認
• 画面単価方式の見積もりサンプル公開｜30画面のリアル試算 — 規模別3パターンの見積もり実例
• レガシーPHPからモダンPHPへ｜中小企業のシステム刷新ガイド
• 業務システム移行の注意点10選｜データ移行・並行稼働・テスト計画まで徹底解説
• システム保守の費用相場と選び方｜"守り"だけで終わらない攻めの保守運用ガイド
• データ移行ガイド｜旧システムから新システムへの移行手順と注意点
• 他社が作ったシステムの引き継ぎは可能？費用と進め方を徹底解説

「うちのシステム、そろそろ限界かも」と感じたら、まずはお問い合わせフォームから画面数をお伝えください。1〜2営業日で概算見積もりをお出しします。

刷新の際に新旧を並行して動かす期間について、実務で何が難しいかは新旧システムの並行運用は何が大変かで解説しています。