古いPHPシステム、作り直す？使い続ける？判断フレームワーク

10年前のPHPで動く社内システム、そのまま使い続けるべきか全面刷新すべきか。コスト・リスク・保守性の3軸で判断するための実践的フレームワークを解説します。

「このシステム、まだ使えますよね…？」という不安、ありませんか？

「10年前に外注して作ったPHPの受注管理システムがあるんですが、最近ちょくちょく動作がおかしくて。作り直したほうがいいのか、手を入れながら使い続けるべきか、判断がつかなくて…」

こういった相談は、弊社にも年間10件以上寄せられます。古いPHPシステムの多くは PHP 5.x 〜 7.x 系で書かれており、現行の PHP 8.x とは非互換な部分も多く、セキュリティリスクも年々高まっています。しかし「作り直し」には当然コストがかかる。このジレンマ、どう判断すればよいのでしょうか。

この記事では、コスト・リスク・保守性の3軸を使った判断フレームワークと、実案件での判断事例を紹介します。エンジニア・Web担当者が上司や経営者に説明する際の材料としても使えるように構成しました。

なぜ「とりあえず使い続ける」が危険なのか

古いPHPシステムを放置し続けるリスクは、思っているより広範囲に及びます。

PHPのバージョンとサポート期限問題

PHP 7.4 は2022年11月にセキュリティサポートが終了しました。PHP 8.0 も2023年11月にEOL（End of Life）を迎えています。つまり、多くの現役システムがすでにセキュリティパッチのない状態で稼働しているわけです。

# 現在のPHPバージョンを確認するコマンド
php -v

# PHP 7.4.33 (cli)... のような表示ならすでにEOL

バージョンが古いだけでなく、フレームワークなしの「素のPHP」で書かれたシステムは、SQLインジェクションやXSSといった基本的な脆弱性が残っていることも珍しくありません。

「エンジニアがいなくなる」リスク

もう一つ深刻なのが、属人化の問題です。10年前に構築したシステムを今も把握しているエンジニアがいる会社は少数。コードにコメントがなく、設計書もない。「触ると壊れるから誰も手をつけない」状態になっているケースが本当に多いのです。

ある神奈川の製造業クライアントでは、社内唯一のPHP担当者が退職し、在庫管理システムが完全にブラックボックス化。バグが出るたびに外部業者に高額な調査費を払い続けるという状況に陥っていました。

判断フレームワーク：3つの軸でスコアリングする

「作り直すべきか」の判断は、感覚ではなくスコアリングで行うと意思決定がスムーズになります。以下の3軸でそれぞれ評価してみてください。

flowchart TD
    A[古いPHPシステムを評価] --> B{コスト軸\n年間保守費用 vs 再構築費用}
    B -->|保守費 > 再構築費の30%| C[作り直し優位]
    B -->|保守費 < 再構築費の10%| D[継続利用優位]
    B -->|中間| E{リスク軸\nセキュリティ・PHP EOL}
    E -->|高リスク| C
    E -->|低リスク| F{保守性軸\nコード品質・属人化}
    F -->|保守困難| C
    F -->|保守可能| D
    C --> G[段階的リプレイスを検討]
    D --> H[部分改修でコスト最適化]

軸1：コスト軸

現行システムの年間保守コストを正確に把握することが出発点です。

• バグ対応・改修にかかった外注費（年間）
• サーバー代・ライセンス費用
• 属人化による業務停止リスクの機会損失

これらを合算し、再構築費用の20〜30%を超えているなら、3〜5年以内に逆転する計算になります。

軸2：リスク軸

以下の項目に1つでも該当する場合、リスクは「高」と判定します。

// こういったコードが残っている場合は即時対応が必要
$user_input = $_GET['id'];
$sql = "SELECT * FROM orders WHERE id = " . $user_input; // SQLインジェクション脆弱性
mysql_query($sql); // mysql_* 関数はPHP 7.0で削除済み

• mysql_* 関数（mysqli_* ではなく）を使用している
• PHPバージョンが7.4以下
• 個人情報・決済情報を扱っているのに暗号化が不十分
• 外部公開されているにもかかわらず入力値検証がない

軸3：保守性軸

コードの保守性は、以下のような観点で評価できます。

上記のような状態（合計スコアが低い）なら、改修コストは加速度的に増大していきます。

実案件での判断事例

ケース1：継続利用を選んだ事例

状況： 神奈川県内の食品卸会社。PHP 7.4で動く受注管理システム。利用者は社内5名のみ。外部公開なし。

判断： リスク軸のスコアが低く（内部利用のみ・個人情報なし）、コスト軸でも年間保守費が20万円以下。再構築見積もりは350万円だったため、**部分改修（PHP 8.1へのバージョンアップ + 脆弱性対応）**を選択。費用は約45万円で済みました。

結果： システム停止リスクを下げながら、残り2〜3年の延命に成功。この間に業務フローの見直しも並行して進め、次回の刷新に備えています。

ケース2：作り直しを選んだ事例

状況： 同じく神奈川の人材派遣会社。PHP 5.6で動くスタッフ管理システム。外部のスタッフがWebからログインして使用。個人情報（氏名・住所・銀行口座）を扱っていた。

判断： PHP 5.6はEOL、外部公開かつ個人情報を扱う、コードはフレームワークなしでSQLインジェクション脆弱性あり。3軸すべてで「作り直し」が優位との判断に。

選択技術： Laravel 11 + MySQL + AWS（EC2/RDS）構成で再構築。

// 刷新後：Laravelによる安全な実装例
public function show(Request $request)
{
    $staffId = $request->validated()['id']; // バリデーション済み入力値
    $staff = Staff::findOrFail($staffId);   // Eloquent ORMで安全なクエリ
    return response()->json($staff);
}

結果： セキュリティ診断でのリスク指摘がゼロに。スタッフの利便性向上（スマホ対応）により、月次の問い合わせ件数が40%減少。再構築費用は約480万円でしたが、1年以内に保守コスト削減と業務効率化で回収見込みが立っています。

よくある失敗パターンと対処法

失敗1：「とりあえず最新PHPに上げれば解決」

PHPのバージョンアップは必要ですが、それだけでは根本解決になりません。PHP 8.xに上げた途端に動かなくなる関数や構文が多数あり、検証なしの更新は本番障害のリスクがあります。

対処法： ステージング環境を用意し、動作確認してから本番へ。php -l でシンタックスチェック、php8.1 script.php で個別ファイルのテストを行いましょう。

# 構文エラーの一括チェック（ディレクトリ配下全ファイル）
find ./src -name "*.php" | xargs -I{} php -l {}

失敗2：「部分改修を繰り返し、結局コストが膨らむ」

「今回はここだけ直せばいい」という判断を繰り返した結果、3年間で再構築コストを上回る改修費を支払っていたというケースは非常に多いです。

対処法： 年間保守費のログをきちんと記録し、累積コストを可視化する習慣をつけてください。

失敗3：「全部作り直す」という極端な判断

逆に、すべてを一気に刷新しようとして予算超過・スケジール遅延・現場混乱を招くケースも多い。特に業務に深く根付いたシステムは、段階的移行（ストラングラーフィグパターン）が有効です。

対処法： まず「新規データの書き込みのみ新システムへ」→「既存データを段階移行」→「旧システム停止」という3フェーズで進めると、リスクを大幅に低減できます。

まとめと次のステップ

古いPHPシステムの判断に「絶対の正解」はありません。しかしコスト・リスク・保守性の3軸で定量評価する習慣を持つだけで、感情的・場当たり的な判断を避けられます。

弊社ではこれまでの実案件経験をもとに、現行システムの無料診断（簡易スコアリング）をご提供しています。「うちのシステム、どっちなんだろう」と思ったら、まずは一度ご相談ください。