「動いてはいるけれど、使っているフレームワークはもうサポートが終わっているらしい」。そう分かったとき、新しいフレームワークへ作り直す（＝リプレイスする）には何が必要なのか、費用や期間はどのくらいか、見当がつかない方は多いはずです。
「古いフレームワークで作ったシステムを新しくしたいけど、費用も期間も見当がつかない。段階的に進めることはできるの？」
先に結論をお伝えします。リプレイスで最初に必要なのは、「作り直す」決断ではなく、現状の棚卸しです。 何が・どこで・どのくらい使われているかが分かれば、全面的な作り直しだけでなく、一部ずつ新しくする段階的な進め方も選べます。
この記事では、発注者の立場で用意しておきたいものを、チェックリストと開発会社への質問例つきで整理します（情報は2026年10月時点。費用・期間は案件によって大きく異なるため、具体額は示しません）。
古いフレームワークを使い続けるリスクについては、タイムズカーの情報漏えいを題材にした記事で整理しています。
なぜ古いフレームワークのリプレイスは「見当がつかない」のか
見当がつかない理由は、ほぼ次の3つに集約されます。
- 中身が見えない：作った担当者が退職し、設計書が古いか無いため、どんな機能があるかを誰も説明できない
- 範囲が決まらない：画面だけ新しくするのか、裏の仕組みやデータまで変えるのかで、作業量が何倍も変わる
- 正解が1つではない：全部作り直す、少しずつ置き換える、いまのまま守りを固める、など複数の選び方がある
経済産業省の「DXレポート」は、こうした古いシステム（レガシーシステム）について、技術面の老朽化、システムの肥大化・複雑化、ブラックボックス化が経営の足かせになりうると指摘しています。
📰 出典：経済産業省「DXレポート ～ITシステム『2025年の崖』の克服とDXの本格的な展開～」（2018年9月）
つまり、見当がつかないのは発注者の落ち度ではなく、古いシステムにありがちな状態です。まず「見える化」から始めれば大丈夫です。
リプレイスの進め方は大きく3通り
| 進め方 | 内容 | 向いている場合 | 注意点 |
|---|---|---|---|
| 全面的に作り直す | 新しいシステムを丸ごと作り、一度に切り替える | 小規模、または機能が整理されている | 切り替え時のリスクが大きい。作っている間は新機能を足しにくい |
| 段階的に置き換える | 機能ごとに新しい仕組みへ移し、古い部分を少しずつ減らす | 規模が大きく、止められない業務システム | 古い仕組みと新しい仕組みを並行して動かす期間の管理が必要 |
| 当面は守りを固めて延命 | WAFやアクセス制限などで守りつつ、移行時期を計画する | すぐに作り直す予算や体制がない | 根本解決ではない。期限を決めないと先送りになる |
段階的な進め方は「ストラングラーフィグ（絞め殺しの木）パターン」と呼ばれ、AWSの技術ガイドにも紹介されています。古いシステムの前に振り分けの仕組みを置き、機能を1つずつ新しい側へ移していく方法です。
📰 出典：AWS Prescriptive Guidance「Strangler fig pattern」
同ガイドは、一度にすべてを移す方法は変革のリスクと業務への影響が大きいこと、新機能の追加を待てない場合や利用者への影響を抑えたい場合に段階的な方法が向くことを説明しています。一方で、既存のソースコードを見られることが前提であること、規模の小さいシステムなら作り直しのほうが効率的な場合もあることも書かれています。段階的が常に正解とは限りません。
リプレイスの前に必要な5つの準備
1. 今のシステムの棚卸し（何があるか）
最初に、開発会社や保守会社に次の一覧を作ってもらいます。
- 使っているフレームワーク・言語・主要ライブラリの名前、バージョン、サポート期限
- 画面・機能の一覧（使われていない機能も含む）
- 連携している他のシステム（会計、基幹、外部サービスなど）
- データベースの種類と、保存しているデータの量・種類
整理が難しい場合は、自社のIT資産を一覧にする方法も参考になります（IT資産台帳の作り方）。
2. ソースコードと資料の所在の確認
リプレイスの調査には、ソースコード、設計書、サーバーの構成情報が必要です。ソースコードがどこにあり、発注者が受け取れる状態かを確認します。契約上、ソースコードの扱いが決まっていないケースもあるため、早めに確認しておくと安心です。
3. 「使われている機能」と「いらない機能」の仕分け
古いシステムには、使われなくなった機能が残りがちです。利用状況をログや現場の聞き取りで確認し、次の3つに分けます。
- 必ず引き継ぐ機能
- 作り直すタイミングで見直す機能
- 廃止してよい機能
廃止できる機能が多いほど、費用と期間は小さくなります。
4. データの移行方針
画面より難しいのは、実はデータの移行であることが多いです。
- 過去データをどこまで新システムへ移すか
- 不要なデータ（退会者の情報など）を、いつ・どう消すか
- 移行中も業務を止められるか、止められないか
データを減らしておくことは、移行の手間を減らすだけでなく、万一の漏えいのときの被害を小さくすることにもつながります。
5. 切り替えと切り戻しの計画
新システムへ切り替えるときに、問題が起きたら元に戻せるか（切り戻しできるか）を決めておきます。切り替え日だけでなく、並行運用の期間、受け入れテストの担当、現場への周知まで含めて計画します。
費用と期間の見当をつけるには
具体的な金額は、システムの規模・機能の数・データ量・連携先などで大きく変わるため、一般的な相場を断定することはできません。見当をつけるには、次の順番が現実的です。
- 棚卸しと現状調査だけを、小さな契約（調査・設計フェーズ）で依頼する
- その結果をもとに、「全面」「段階的」「延命」の3案で概算見積もりを出してもらう
- 複数社に同じ資料を渡して、比較する
調査だけを先に切り出すと、本番の見積もりの精度が上がり、後からの追加費用も抑えやすくなります。複数社の見積書は、同じ資料・同じ条件で出してもらったものを並べて比べましょう。
発注者がやりがちな失敗パターン
- 「今と同じものを」とだけ頼む：古い仕様をそのまま引き継ぎ、不要な機能まで作り直してしまう
- 作る側に調査を丸投げする：業務の判断は発注者にしかできず、仕分けが進まない
- 切り替えの日付だけ決める：データ移行やテストの時間が足りなくなる
- 先送りを続ける：サポート切れのまま使い続け、必要になった時に準備の時間が残っていない
発注者向けチェックリスト
- ☐ フレームワーク・ライブラリのバージョンとサポート期限の一覧を受け取った
- ☐ 画面・機能・連携先の一覧を作った（使っていない機能にも印を付けた）
- ☐ ソースコード・設計書・サーバー構成情報の所在と、受け取れるかを確認した
- ☐ 「引き継ぐ／見直す／廃止」の仕分けを現場と一緒に行った
- ☐ データの移行範囲と、削除してよいデータの方針を決めた
- ☐ 切り替え方法（一括か段階的か）と、切り戻しの手順を確認した
- ☐ まず調査・設計だけを小さく契約する方法を検討した
- ☐ 移行までの暫定の守り（WAF・アクセス制限・監視）を相談した
開発会社への質問例
- 「今のシステムで使っているフレームワークの名前・バージョン・サポート期限を、一覧でいただけますか？」
- 「全面的な作り直しと、段階的な置き換えでは、費用・期間・リスクがそれぞれどう違いますか？」
- 「調査と設計だけを先に小さく依頼することはできますか？その場合の成果物は何になりますか？」
- 「ソースコードや設計書は、いつ、どの形で受け取れますか？不足している資料はありますか？」
- 「データ移行はどの範囲で、どのような手順で行いますか？移行中に業務を止める時間はどのくらいですか？」
- 「切り替えで問題が起きたとき、元に戻せますか？その手順も教えてください」
まとめ：まず棚卸しと調査から、小さく始める
古いフレームワークのシステムをリプレイスするときに必要なのは、大きな決断よりも、現状を知ることです。
- 見当がつかないのは、中身が見えていないから
- 進め方は「全面」「段階的」「延命」の3通りで、案件によって向き不向きがある
- 事前に、棚卸し・ソースコードの所在・機能の仕分け・データの方針・切り戻し計画を整理する
- 費用と期間は、調査・設計を小さく切り出して、3案で見積もってもらうと見当がつく
「古いから不安」で止まらず、まずは一覧を作るところから始めてみてください。
システムの確認・新しいフレームワークへのリプレイスは、株式会社THIRD HEROへお気軽にご相談ください
「自社のシステムがどのフレームワークで動いているか分からない」「サポート期限を確認したい」「新しいフレームワークへ移行したいが、何から始めればいいか分からない」。そんなときは、株式会社THIRD HEROへお気軽にご相談ください。
- 使っているフレームワーク・ライブラリの確認と、サポート期限の整理
- 外部公開や個人情報を扱う箇所の優先順位づけ
- 新しいフレームワークへのリプレイス（段階的な移行も含む）の進め方・概算のご相談
お問い合わせの時点で、システムの資料や詳しい情報が揃っていなくても問題ありません。分かる範囲でお聞かせいただければ、現状の整理からご一緒します。
あわせて読みたい関連記事
