古いPHPシステムが「壊れそう」なときに最初にやること

「触ったら壊れそう」な古いPHPシステムを抱える現場向けに、リスクを最小化しながら安全に現状把握・対処するための実践的な手順を解説します。

「このシステム、誰も触りたくない」という現場へ

こんな悩みを抱えていませんか？

• 10年前に作ったPHPの社内システムが今も動いているが、担当者が退職してソースコードの意味がほぼ分からない
• 少し修正しようとするたびに別の箇所が壊れる「地雷システム」になっている
• サーバーのPHPバージョンが古すぎて、ホスティング会社から「そろそろ更新してください」と通知が来ている
• 「動いているうちは触らない」という方針でずっと放置してきたが、さすがに限界を感じている

これは特定の会社の話ではありません。弊社に相談が来るケースの中でも、特に多いパターンのひとつです。神奈川を中心とした中小企業様からの問い合わせで「PHPで作った古いシステムをどうにかしたい」という声は、年々増えています。

この記事では、壊すことなく安全に現状を把握し、次の一手を決めるための実践的な手順をステップごとに解説します。完全なリプレースを急ぐ前に、まずやるべきことがあります。

なぜ「古いPHPシステム」はこんなに怖いのか

恐怖の正体を整理することが、対処の第一歩です。古いPHPシステムが「触りたくない」状態になる背景には、いくつかの共通した構造的問題があります。

PHP自体のバージョン問題

PHPはバージョンアップに伴い、古い関数や記法がdeprecated（非推奨）→ 削除というサイクルを辿ります。たとえば mysql_connect() はPHP 5.5で非推奨となり、PHP 7.0で完全に削除されました。PHP 5系で書かれたコードがPHP 8系のサーバーで動かないのは、この互換性問題が原因です。

「誰かが書いたコード」問題

外注で作られた、あるいは退職した社員が書いたコードは、コメントがなく、命名規則もバラバラで、ロジックの意図が読み解けないことがほとんどです。変数名が $a、$tmp2、$xxxFlag といった状態では、修正の影響範囲が読めません。

テストコードが存在しない

古い社内システムの大半は、自動テストが一切ありません。つまり、修正後に「壊れていないか」を確認する手段がなく、全部手動で動作確認するしかない。これが「触るのが怖い」という感覚の本質です。

まず最初にやること：5つのステップ

「リプレースするかどうか」を判断する前に、現状を正確に把握することが不可欠です。以下のステップは、壊さずに情報を集めるための安全な作業手順です。

Step 1：現在のPHPバージョンを確認する

最初の一手は環境の確認です。サーバー上で以下を実行するか、既存のPHPファイルに一時的に書いて確認します（確認後は必ず削除してください）。

<?php
phpinfo();

あるいはCLIで確認する場合：

php -v

PHP 5.x系であれば緊急度が高いと判断してください。2024年時点でPHP 5.6のサポートはとっくに終了しており、セキュリティパッチも存在しません。PHP 7.4以下も既にEOL（サポート終了）です。

Step 2：バックアップを取る（これだけは絶対に先にやる）

どんな作業をする前も、バックアップが最優先です。「壊れそう」なシステムを触るときほど、先にバックアップが必要です。

# ファイル一式をtar.gzで固める
tar -czvf backup_$(date +%Y%m%d).tar.gz /var/www/html/your-system/

# MySQLのデータベースをダンプ
mysqldump -u root -p your_database > backup_$(date +%Y%m%d).sql

バックアップはサーバー内だけでなく、ローカルPCやGoogle Driveなど別の場所にも保存してください。同じサーバーが壊れたときに意味をなさなくなります。

Step 3：依存関係・ライブラリの棚卸し

Composerを使っていればルートディレクトリに composer.json があるはずです。

cat composer.json

Composerすら使っていない（古いフレームワークや自作コード）場合は、require や include 文を検索して、どんなライブラリを読み込んでいるか調べます。

# PHP内のrequire/includeを一覧化
grep -rn "require\|include" /var/www/html/your-system/ --include="*.php" | head -50

これで「何を使っているか」の全体像が少し見えてきます。

Step 4：エラーログを確認する

「壊れそう」という感覚の多くは、既にエラーが頻発しているが表示されていない状態です。PHPのエラーログを確認しましょう。

// php.ini の設定を確認
<?php
echo ini_get('error_log');
echo ini_get('display_errors');

ログファイルが見つかったら：

# 直近100行のエラーを確認
tail -n 100 /var/log/php_errors.log

# Deprecatedエラーだけ抽出
grep "Deprecated" /var/log/php_errors.log | sort | uniq -c | sort -rn | head -20

Deprecated: Function mysql_connect() is deprecated のような警告が大量に出ているケースでは、PHP 7系への移行時に致命的なエラーになります。

Step 5：コードの複雑度を大まかに把握する

全コードを読み解く必要はありません。まずはファイル数と行数だけ把握しましょう。

# PHPファイルの数と総行数
find /var/www/html/your-system/ -name "*.php" | wc -l
find /var/www/html/your-system/ -name "*.php" | xargs wc -l | tail -1

ファイル数が500以上・総行数が50,000行を超えているようなら、部分改修よりも段階的リプレースを検討すべきタイミングです。

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

現場でありがちな「やりがちなミス」を事前に把握しておくと、同じ轍を踏まずに済みます。

❌ 「とりあえずPHPを最新にアップデートしてみた」

PHP 5.6から8.2への一括アップグレードを本番環境で試みて、システムが完全に停止したという事例があります。バージョンアップは必ずステージング環境（テスト環境）で先に試すのが鉄則です。本番環境で直接試すのは絶対NGです。

❌ 「古い関数を全部置換した」

mysql_connect を mysqli_connect に一括置換したところ、引数の順番や返り値の仕様が微妙に異なるため、各所で動作がおかしくなった——というケースです。古い関数から新しいAPIへの移行は、関数ごとに仕様差異を確認しながら個別対応が必要です。

❌ 「コードを読まずにリプレースの見積もりを依頼した」

「全部作り直したい」という依頼でよくあるのが、現行システムの仕様が誰にも分からないまま見積もりを依頼するパターンです。結果として仕様漏れが多発し、追加費用が膨らみます。現行システムの仕様書を作るところから始めるのが、長期的なコスト削減につながります。

ある製造業クライアントの実例

神奈川県内の製造業の会社様から「10年前に作ったPHPの在庫管理システムが、サーバー移行に伴い動かなくなりそう」という相談を受けました。

確認したところ、PHP 5.6で書かれており、mysql_* 関数を120箇所以上使用。コメントはほぼなく、テーブル設計書も存在しない状態でした。

私たちが最初にやったのは、全機能のスクリーンショットと操作フローの文書化です。コードを読む前に「どう使われているか」を先に記録することで、要件定義の代わりとしました。その後、PHP 7.4のステージング環境でエラーを洗い出し、critical なものから順に修正。3ヶ月かけて段階的に移行し、最終的にはLaravelベースの新システムへのリプレースロードマップを策定しました。

一気に作り直すのではなく、動かしながら把握し、段階的に改善する——これが「壊れそうなシステム」との正しい向き合い方です。

flowchart TD
    A[現状確認：PHPバージョン・ログ確認] --> B[バックアップ取得]
    B --> C[ステージング環境を用意]
    C --> D{エラー数・複雑度の評価}
    D -->|修正が現実的| E[段階的パッチ対応]
    D -->|規模が大きすぎる| F[段階的リプレース計画]
    E --> G[本番反映・監視]
    F --> H[新システム設計・移行]

まとめと次のステップ

「壊れそうで怖い」というシステムも、正しい順序で現状把握を進めれば、適切な対処法が見えてきます。焦って本番環境で作業したり、コードを読まずにリプレースを発注したりするのが最もリスクの高い選択です。

まずは今日できることから始めてください。

これらを一通り実施した上で、「やはり自分たちでは判断が難しい」と感じた場合は、ぜひ弊社にご相談ください。コードを実際に拝見した上で、リプレース費用の目安や優先順位の整理を含めた無料診断を承っています。20年以上PHPシステムの開発・保守に携わってきた経験から、現実的なロードマップをご提案します。