古いPHP・Perl・Javaシステムを延命・刷新する判断基準

執筆：株式会社エスロジカル（Webシステム受託開発・レガシー刷新・インフラ構築）

「PHP 5.x で動いているシステムが壊れそう」「Perl CGI がサーバー移行できない」「Java 8 + Tomcat 7 を誰も触れない」 ——レガシーシステムの維持に頭を抱えているエンジニアや経営者は多いです。
本記事では、延命か刷新かを判断するための軸と、各技術スタックの具体的な対処法を整理します。

1. 延命と刷新の判断軸

「このシステムを刷新すべきか」は技術だけでなく、ビジネスと組織の状況を加味して判断します。

判断軸	延命が合理的な場合	刷新が合理的な場合
セキュリティリスク	既知の CVE が少ない・パッチ適用で対応可能	EOL（サポート終了）の OS/MW・深刻な CVE が多数ある
保守性	担当エンジニアがいる・コードが読める	属人化・ブラックボックス化・コードが誰も読めない
機能追加の必要性	現状維持で十分・変更が少ない	頻繁な機能追加が必要・開発速度が遅すぎる
ビジネス上の重要度	サブシステム・内部ツール	売上に直結する中核システム
コスト	刷新コストが見合わない	延命コスト（人件費）が刷新コストを上回る

実務判断：「全部刷新」は理想ですが現実的でないことが多いです。 まずセキュリティリスクが高い部分・ユーザーへの影響が大きい部分から優先的に対処し、段階的に改善するアプローチが有効です。

2. PHP システムの延命・刷新

PHP 5.6 は 2018 年末、PHP 7.x は 2022 年末にサポートが終了しています。 現在も PHP 5.x / 7.0〜7.2 で動いているシステムはセキュリティパッチが提供されておらず、 放置すると重大なリスクがあります。

• PHP 5.x → 7.x → 8.x の段階移行：一気に 8.x へ移行すると破壊的変更が多く、既存コードの修正量が大きくなります。7.4 → 8.1 のように段階を踏むと安全です。
• 主要な変更点：PHP 7.x 以降では mysql_* 関数が廃止（PDO または MySQLi に変更必須）、PHP 8.x では型チェックが厳格化・エラーハンドリングが変わります。
• テストカバレッジ：移行前に自動テストがない場合、回帰テストを手動で行う工数が移行コストの大半を占めます。
• フレームワークの移行：CodeIgniter 2.x・CakePHP 2.x などのサポート終了フレームワークを使っている場合は、フレームワーク移行も含めて検討します。

3. Perl CGI システムの扱い

Perl 自体は現役の言語ですが、CGI 方式（Apache + mod_perl 等）は 現代のサーバー環境での維持が難しくなっています。

• 延命可能な条件：コードが読める担当者がいる・CGI の動作環境を維持できる・変更頻度が低い
• 延命が困難な条件：担当者の退職・サーバー移行時に Apache + mod_cgi の環境が再現できない・HTTPS 化できていない（古い HTTP のみ構成）
• 移行先の選択肢：Perl Dancer2 / Mojolicious を使った PSGI アプリへの移行、または Go / Node.js / PHP への完全書き直しが現実的な選択肢です。
• 最低限の延命措置：もし刷新コストが確保できない場合、まず HTTPS 化（SSL 証明書取得）とサーバーの OS アップデートだけでも行い、セキュリティリスクを下げます。

4. Java（古い Tomcat・Spring）システムの対処法

• Java 8 の延命：Java 8 の LTS サポートは Amazon Corretto・Azul Zulu など OpenJDK ディストリビューションで 2026 年以降も提供されています。ランタイムだけなら当面は延命可能。
• Tomcat のバージョン：Tomcat 7.x は 2021 年 3 月にサポート終了。Tomcat 8.5 → 9.x への移行を検討します。
• Spring Framework：Spring 3.x / 4.x はサポート終了。Spring Boot 3.x への移行は Java 17 以上が必要なため、JDK アップグレードと合わせて計画します。
• ビルドツール：Ant ベースのビルドを Maven / Gradle に移行するだけで CI/CD の整備がしやすくなります。

5. SSL/TLS 対応状況の確認

• 現在の TLS バージョンを確認する（SSL証明書インストールチェッカー）
• TLS 1.0 / 1.1 を無効化し、TLS 1.2 以上のみを許可する設定に変更する
• HTTP のみで運用している場合はまず SSL 証明書を取得して HTTPS 化する
• 証明書の有効期限が近い場合は更新・または新規取得を行う

SSL証明書の一覧・購入はこちら /  SSL証明書 FAQ /  CSR 作成・インストール手順

6. 刷新プロジェクトの進め方

• スコープを絞る：「全部刷新」ではなく、ユーザー向けの公開 UI だけを刷新し、バックオフィスは維持するなどスコープを分ける。
• ストラングラーフィグパターン：旧システムを動かしたまま、新システムを少しずつ増やしていく。完全移行できたら旧システムを廃止する。
• テストの整備：刷新前に現行システムの挙動をテストケースとして文書化し、刷新後の検証基準にする。
• データ移行：旧 DB のデータ構造が複雑な場合、移行スクリプトの作成とリハーサルに十分な時間を確保する。

7. 意思決定マトリクス

状況	推奨アクション
EOL OS/MW・深刻な CVE・担当者なし	早急に刷新または移行。最低限 HTTPS 化と OS 更新だけでも先行する
古いがセキュリティパッチ適用可能・担当者いる・変更少ない	当面延命。セキュリティパッチを継続適用しながら刷新タイミングを計画
機能追加が必要・開発速度が遅い	段階的刷新。新機能は新技術スタックで作り、旧システムは維持しながら移行
売上直結・セキュリティ要件高い	優先刷新。中核ビジネスリスクを早急に解消する

← 技術ドキュメント一覧へ戻る