PHPリプレイス費用と手順｜Next.js移行すべきかの判断基準【2026年版】

PHPで10年運用してきた業務システムを、そろそろ何とかしたい。そう感じているのに、なかなか動けない経営者・情シス担当の方は多いのではないでしょうか。「動いているものを壊すのが怖い」「見積もりを取っても金額の根拠がよく分からない」「そもそも移行するべきなのか、延命でいいのか判断がつかない」——理由はさまざまですが、先送りにできる期限がひとつ、はっきり決まっています。

先に、要点をまとめます。

• 広く使われているPHP 8.2は、2026年12月31日でセキュリティサポートが終了します（公式サポート表）。以降は脆弱性が見つかっても公式パッチが提供されません
• リプレイスは「全部を作り直す」か「延命する」かの二択ではなく、業務の重要度で切り分けて段階的に移す進め方が現実的です
• Next.jsへの移行費用は、対象業務の複雑さとデータ移行の難易度で大きく変わります。本記事では規模別の目安を紹介します

こんな状況ではありませんか？

• 社内の基幹システムや会員サイトが、何年も前に作られたPHPのまま動いている
• PHPのバージョンを一度も上げておらず、今のバージョンがサポート切れに近いのか、正確に把握できていない
• 「そろそろ作り直したほうがいいのでは」という話は出るが、費用も期間も分からず具体的な検討に進めない

この記事で分かること

• PHPの延命が難しくなる技術的な理由と、判断を先送りするリスク
• 一括リプレイスではなく、段階的に移行する場合の進め方
• Next.jsへの移行費用の目安と、費用が膨らみやすいポイント

なお、Next.jsとレガシー開発全般の思想的な違いについてはNext.jsシステム開発と従来型開発、本当の違いとはで扱っています。本記事は「PHPで動いている既存システムを、いつ・どう移行するか」という実務判断に絞って解説します。

なぜ今、PHPのリプレイスを検討するべきなのか？

理由は、多くの中小企業が使っているPHP 8.2のセキュリティサポートが2026年12月31日に終了するためです。

PHPは1つのバージョンにつき、約4年間のサポート期間が設けられています。最初の2年は機能追加・不具合修正を含む「アクティブサポート」、続く2年は重大なセキュリティ脆弱性のみに対応する「セキュリティサポート」です。PHP公式のサポート表によると、2026年8月現在の状況は次の通りです。

PHP 8.2は2022年12月にリリースされたバージョンで、この数年で構築された中小企業のWebシステムに広く使われています。EOL（サポート終了）を迎えると、新たに見つかった脆弱性に対して公式パッチが提供されなくなります。攻撃者は「パッチが出ない既知の脆弱性」を狙いやすくなるため、外部公開しているシステムほどリスクが高まります。

EOLを過ぎても、システムはすぐ止まらないのではないか？

その通りで、動作自体は止まりません。だからこそ対応が先送りにされやすく、後になるほど選択肢が狭まります。

PHPのEOLは「使えなくなる日」ではなく「守られなくなる日」です。システムは変わらず動き続けるため、多くの現場で「まだ動いているから大丈夫」という判断が続き、気づいたときには対応できる開発会社・エンジニアが減っていた、というパターンが起こりがちです。特に、そのシステムを構築した当時の担当者が退職・異動している場合、仕様を把握している人がいないまま延命だけを続けることになり、次にトラブルが起きたときの対応コストがさらに膨らみます。

御社のシステムが該当するPHPのバージョンを一度確認し、EOLまでの残り期間を把握しておくことが、リプレイス検討の最初の一歩になります。

リプレイスと延命、どちらを選ぶべきか？

外部公開していて個人情報や決済を扱うシステムはリプレイスを優先し、社内限定で影響範囲が小さいシステムは延長サポートによる時間稼ぎも選択肢になります。

「PHPのシステムは全部作り直すべき」という単純な話ではありません。判断の軸は、そのシステムがどこまでリスクにさらされているかです。

延長サポート（有償のセキュリティパッチ提供サービス）という選択肢もありますが、これはあくまで「時間を買う」対応です。延長サポートの費用を、リプレイスの原資として積み立てておくという考え方もできます。永続的な解決策ではなく、次のPHPバージョンへの移行やNext.jsへのリプレイスに向けた準備期間を確保する手段として位置づけるのが実務的です。

PHPとNext.js、開発の考え方は何が違うのか？

PHPは「1リクエスト＝1ページ生成」という考え方が中心ですが、Next.jsはコンポーネント単位でサーバー処理とUIを組み合わせる設計が中心です。

従来型のPHPアプリケーション（特にフレームワークを使わない、または古い世代のフレームワークで構築されたもの）は、1つのURLリクエストに対して1つのPHPファイルがHTMLを生成する構造が一般的でした。画面とロジックが混在しやすく、機能追加のたびに影響範囲を把握しづらくなるという課題を抱えているシステムを、私たちも移行の相談でよく目にします。

Next.js（App Router）は、UIをコンポーネント単位に分割し、サーバー側の処理（データ取得・認可判定）とクライアント側の処理（画面の動的な部分）を明確に分けて書けるのが特徴です。これにより、機能追加時の影響範囲が見えやすくなり、AIコーディング支援（Claude Code等）にも指示を出しやすくなります。「このコンポーネントの、この部分だけを直して」という粒度の依頼がしやすいのは、コンポーネント単位で責務が分かれているためです。

とはいえ、こうした設計思想の違いは移行を決める決め手というよりは副次的なメリットです。実務上もっとも重要な論点は、次に説明する「今のデータと機能を、どう安全に移すか」です。

リプレイスはどんな手順で進めるべきか？

「現行仕様の棚卸し→影響範囲の小さい機能から段階移行→データ移行→並行運用→旧システム停止」の順で進めると、業務を止めずに移行できます。

フェーズ1: 現行仕様の棚卸し

まず、今のPHPシステムが「何をしているか」を洗い出します。ドキュメントが残っていないシステムも多いため、実際の画面操作とコードを突き合わせながら、機能一覧・データベースのテーブル構成・外部連携先（決済代行・メール配信サービス等）を整理します。この段階で「実は使われていない機能」が見つかることも珍しくなく、リプレイス対象を絞り込む効果もあります。

フェーズ2: 影響範囲の小さい機能から段階移行

すべての機能を一度に作り直すのではなく、利用頻度が低い、または他機能との依存が少ない画面から着手します。たとえば管理画面の一覧表示のような、失敗しても業務に致命的な影響が出にくい部分から始めると、Next.js側の実装パターンを確立しながらリスクを抑えられます。

フェーズ3: データ移行スクリプトの実装

PHPシステムのデータベース（MySQLが多い）から、新システムのデータモデルへデータを変換・投入するスクリプトを実装します。長年運用されたデータベースには、初期設計時には想定していなかった列の使い方や、手作業で投入された不整合データが紛れ込んでいることが多く、ここが工数の読みにくいポイントです。Excelデータ移行と共通する論点が多いため、Excel台帳をNext.jsに移行する設計の記事で紹介したクレンジングの考え方がそのまま参考になります。

フェーズ4: 新旧システムの並行運用

新Next.jsシステムと旧PHPシステムを一定期間並行稼働させ、同じ業務を両方でこなしながら結果が一致するかを確認します。特に金額計算・在庫数のような数値データは、並行運用の期間中に必ず突き合わせておきたい項目です。

フェーズ5: 旧PHPシステムの停止

並行運用で問題が出なければ、PHPシステムへの新規アクセスを止め、Next.jsに一本化します。停止直後もしばらくはデータベースのバックアップを残し、過去データの参照経路を確保しておくと安心です。

移行費用はどれくらいを見ておくべきか？

小規模な管理画面レベルなら100万円台から、会員サイトや受発注システムのような業務中核システムは300万円〜、複数システムが絡む大規模案件は500万円以上を目安に考えておくとよいでしょう。

費用は「画面数」よりも「データの複雑さ」と「外部連携の数」に比例します。同じ規模の画面数でも、決済代行サービスや複数の外部APIと連携しているシステムのほうが、動作検証の工数が大きく増えます。

見積もりの精度を上げるには、フェーズ1の「現行仕様の棚卸し」を先に済ませ、実際のデータベースとコードを開発会社に見せた上で相談するのが近道です。「思ったより機能が複雑だった」「外部連携が想定より多かった」というギャップは、現物を見ないまま概算だけで進めると起こりやすくなります。開発費用の考え方全般はNext.js受託開発の相場と見積書の内訳3点の読み方でも詳しく解説しています。

リプレイスで失敗しやすいパターンは何か？

「一括切り替え」「仕様の棚卸し省略」「旧システムの即時破棄」の3つが、リプレイスプロジェクトが炎上する典型パターンです。

• 一括切り替えで業務が止まる: ある日を境にすべての機能を新システムに切り替えると、想定していなかった不具合が本番業務中に発覚するリスクが高くなります。フェーズ2で説明した段階移行を基本にしてください。
• 仕様の棚卸しを省略して見積もりを取る: 現行システムの中身を確認せずに「PHPをNext.jsに移行してほしい」とだけ伝えると、見積もりの前提が曖昧になり、着手後に想定外の機能が見つかって費用・期間が膨らみます。
• 旧システムをすぐに破棄する: 切り替え後にデータの整合性を確認したくなる場面は必ず訪れます。旧システムのデータベースは、少なくとも数ヶ月はバックアップとして保持してください。
• 担当者不在のまま仕様を推測で進める: 構築時の担当者が退職している場合、コードから仕様を推測して進めがちですが、業務側の背景（なぜその処理が必要か）まではコードから読み取れません。可能な限り、当時の業務を知る現場担当者にヒアリングする時間を確保してください。
• セキュリティ要件を後回しにする: リプレイスの動機がEOL対応であるにもかかわらず、機能面ばかりに気を取られてセキュリティ設計が手薄になるケースがあります。認証・入力検証・権限管理は新システムの設計段階から組み込んでください。詳しくは中小企業のNext.jsフルスクラッチで、セキュリティをどう担保するかで扱っています。

AI駆動開発はリプレイスのどこを速くするのか？

既存PHPコードの仕様読み解きと、データ変換スクリプトの実装が、AIコーディング支援によって大きく速くなります。

長年運用されたPHPコードは、コメントが少なく、命名規則もばらついていることが珍しくありません。Claude Codeのようなツールに既存コードを読み込ませ、「このファイルは何をしているか」「このテーブルのこの列はどこで使われているか」を洗い出す作業は、人手だけで追うより格段に速く進みます。ただし、AIが出した仕様の要約をそのまま鵜呑みにするのではなく、重要な業務ロジック（金額計算・権限判定等）は人間が実データで動作確認する工程を必ず挟むべきです。

データ変換スクリプトの実装も、変換ルール（旧テーブルのどの列を新モデルのどの項目にマッピングするか）さえ明文化できれば、AIに実装を任せやすい領域です。私たちの開発でも、この役割分担——「業務仕様の確認と最終判断は人、パターン化された実装はAI」——を軸にプロジェクトを進めています。

Next.jsに移行した後、何を変えれば定着するのか？

移行直後は操作に慣れていない分、体感速度が落ちたように感じられやすく、頻出操作を画面上部に配置するなどの導線設計が定着を左右します。

システムを作り直しても、現場が「前のほうが早かった」と感じて使われなくなっては意味がありません。移行プロジェクトの成功は、データが正しく移った日ではなく、現場が自然に新システムだけを使うようになった日で判断するのが実態に近い見方です。よく使う操作ほど画面の見える位置に置く、入力ミスをその場で知らせる、といった細かな改善を移行直後の数週間で拾い上げる体制を作っておくと、定着がスムーズに進みます。

まずは、御社の基幹システムやWebサイトが実際に何のPHPバージョンで動いているかを、担当のエンジニアか制作会社に確認するところから始めてみてください。そこで分かった残り期間の長さが、リプレイスをいつ検討すべきかの最初の判断材料になります。

まとめ：この記事で持ち帰れること

この記事を読むことで、次の2点が判断できるようになります。

• 自社のPHPシステムが「今すぐリプレイスすべき」なのか「延命でも当面問題ない」のかの見極め方
• 一括切り替えではなく、棚卸し→段階移行→並行運用という手順を踏んだ移行の全体像と費用感

PHP 8.2のセキュリティサポート終了（2026年12月31日）は、多くの中小企業にとって「そろそろ検討しなければ」と思っていたリプレイスの検討を具体的に始める、分かりやすいきっかけになります。ただし、期限に追われて一括切り替えに走るのではなく、公開範囲やデータの重要度で優先順位を付け、段階的に移していく進め方のほうが、結果的に業務への影響を抑えられます。

自社のPHPシステムがどの規模のリプレイスに当てはまるか、実際のコードとデータベースを見ながら整理したい方は、15分のカジュアル相談からご相談ください（事例・要件が固まっていなくても大丈夫です／営業はしません）。

すでにNext.jsへの移行を決めていて、既存の受発注管理やExcel台帳の移行を具体的に検討している方は、受発注管理をSaaSからNext.jsフルスクラッチに切り替える判断基準、Excel台帳をNext.jsに移行する設計もあわせてご覧ください。

よくある質問

Q. 使っているPHPのバージョンを確認する方法はありますか？

サーバー管理画面（レンタルサーバーのコントロールパネルやAWS/GCPの管理コンソール）から確認できるほか、phpinfo() 関数を使った確認ページを一時的に設置する方法もあります。自社で確認が難しい場合は、システムを構築・運用している制作会社やエンジニアに問い合わせるのが確実です。

Q. PHPのバージョンを最新に上げるだけではだめですか？

システムの規模やフレームワークの依存関係によっては、バージョンアップだけで延命できる場合もあります。ただし、長年アップデートしていないシステムほど、バージョンアップ自体が大掛かりな改修になりやすく、「バージョンアップの工数」と「Next.jsへのリプレイス工数」を比較検討した上で、どちらが中長期的に合理的かを判断することをおすすめします。フレームワークのバージョンが数世代遅れている場合は、リプレイスのほうが結果的に総コストを抑えられるケースもあります。

Q. リプレイス中、旧システムと新システムのデータはどう同期させますか？

並行運用の期間中は、業務上どちらのシステムを正とするかを先に決めておくことが重要です。多くの場合、旧PHPシステムを正のデータソースとして運用を続けながら、新Next.jsシステム側にも同じ操作を反映し、定期的に集計値を突き合わせる方法を取ります。双方向の自動同期を作り込むと複雑になりすぎるため、並行運用は「短期間・手動突き合わせ」を基本にするのが現実的です。

Q. 一部の機能だけPHPのまま残すことはできますか？

可能です。すべてを一度にNext.jsへ移行する必要はなく、公開範囲が広く重要度の高い機能から優先的に移行し、影響範囲の小さい社内向け機能は当面PHPのまま残す、という判断も現実的な選択肢です。ただし、残す機能についても、使用しているPHPバージョンのEOLは把握し、いつまで延命できるかの目安は持っておくべきです。

Q. 移行費用を抑える方法はありますか？

もっとも効果的なのは、フェーズ1の現行仕様の棚卸しを自社である程度進めておくことです。使われていない機能の洗い出しや、外部連携先の一覧化を事前に済ませておくと、見積もり時の不確実性が減り、開発会社側の調査工数を抑えられます。また、全機能を一度に移行せず、優先度の高い部分から段階的に発注する方法も、初期費用を分散させる手段になります。

※本記事のPHPサポート期限の情報は、2026年8月時点のPHP公式サポート表に基づいています。サポート方針は変更される場合があるため、正確な期限は必ず公式情報でご確認ください。本記事はNext.js 16.x時点の情報です。