PHPの古い社内システム、「触るのが怖い」状態から脱出する方法

「誰が作ったかわからないPHPコード」を前に手が止まった経験はありませんか？コード解読から安全な改修まで、実践的な第一歩を解説します。

「このコード、触っていいんですか…？」

こんな悩みはありませんか？

前任者が作ったPHPの社内システムが動いているが、中身を誰も把握していない
バグを直そうとすると別の場所が壊れ、結局「動いているうちは触らない」方針になっている
PHPのバージョンが5系のまま放置されており、セキュリティが不安
新しい機能を追加したいが、どこに何を書けばいいかまったくわからない

これは決して珍しい状況ではありません。Fivenineでも、「10年前に外注して作ったシステムの改修を頼みたい」というご相談を年に数件いただきます。先日も、神奈川の製造業のクライアントから「社員名簿と勤怠を管理するPHP4系のシステムがあるが、PHP8のサーバーに移行したい」というご依頼が舞い込みました。

この記事では、そんな「触るのが怖い」レガシーPHPシステムに向き合うための、現実的かつ安全な第一歩をお伝えします。

なぜ「触るのが怖い」状態が生まれるのか

「怖い」の正体を正しく理解することが、脱出の第一歩です。主な原因は以下の3つです。

1. グローバル変数とスパゲッティコードの蔓延

古いPHPコードによく見られるのが、$_SESSIONや$_GETを直接受け取り、そのままSQLクエリに投げ込むようなコードです。ファイルが互いにincludeし合い、どこから処理が始まってどこで終わるのかを追うだけで1日が潰れます。

2. テストが存在しない

ユニットテストやインテグレーションテストが一切ない場合、コードを1行変えると「どこかが壊れていないか」の確認を手動で行うしかありません。その恐怖が「触らない」選択を正当化します。

3. ドキュメントがゼロ

変数名が$aや$tmp2、関数名がdoSomething()といったコードでは、何をしているのかを理解するために本番データを見るしかないケースもあります。これは精神的にも実務的にも大きなリスクです。

バックエンド開発でお困りですか？

API設計・DB最適化・システム構築など、ご相談ください

無料で相談する

実践：「怖い」状態から脱出するための5ステップ

Step 1｜絶対に先にバックアップを取る

当然のことに聞こえますが、意外と省略されがちです。前述の製造業クライアントの案件でも、着手前にサーバー丸ごとのスナップショットと、データベースの論理バックアップを両方取得しました。mysqldumpで十分です。

# データベースのバックアップ
mysqldump -u root -p legacy_db > backup_$(date +%Y%m%d).sql

# ファイル一式のバックアップ
tar -czf legacy_app_$(date +%Y%m%d).tar.gz /var/www/legacy_app/

バックアップなしで作業を始めることは、安全装置なしで爆発物を扱うようなものです。

Step 2｜PHPのバージョンと依存関係を把握する

現在のPHPバージョンを確認し、どこまで互換性があるかを把握します。

<?php
// phpinfo.php を一時的に作成して確認
phpinfo();

あるいはCLIから：

php -v
# PHP 5.6.40 (cli) のような出力が出る

PHP 5系は2018年末にサポートが終了しています。PHP 7系も2022年末に終了済みです。現在の推奨はPHP 8.2以上です。バージョンが古い場合、後のステップで段階的な移行を計画する必要があります。

Step 3｜コードの全体地図を作る

全ファイルを読む必要はありません。まずエントリーポイント（ブラウザからアクセスされる.phpファイル）を洗い出し、処理の流れを把握します。

# ディレクトリ構造の確認
find . -name "*.php" | head -50

# includeやrequireの依存関係を可視化
grep -rn "include\|require" --include="*.php" . | grep -v "vendor"

次に、データベースへのアクセス箇所を全件抽出します。SQLインジェクションの危険箇所を特定するためです。

# mysql_query（旧式・危険な関数）の使用箇所を検索
grep -rn "mysql_query\|mysql_connect" --include="*.php" .

mysql_queryが出てきた場合、それはPHP 7以降では動作しない廃止済み関数です。優先的にPDOまたはmysqliへの移行が必要です。

Step 4｜最小単位で安全にリファクタリングする

一気に書き直すのは最悪の選択です。前述のクライアント案件でも、まず「最も使用頻度が高い社員検索機能だけ」を安全なコードに置き換え、残りは触らずに並行稼働させました。

例えば、以下のような危険なコードが見つかった場合：

<?php
// ❌ 危険：SQLインジェクションの温床
$id = $_GET['id'];
$result = mysql_query("SELECT * FROM users WHERE id = $id");

PDOを使った安全なコードに書き換えます：

<?php
// mysql_query + 生の変数でSQLを組み立てている
$id = $_GET['id'];
$conn = mysql_connect('localhost', 'user', 'pass');
mysql_select_db('legacy_db', $conn);
$result = mysql_query("SELECT * FROM users WHERE id = $id", $conn);
while ($row = mysql_fetch_assoc($result)) {
    echo $row['name'];
}

<?php
// PDO + プリペアドステートメントで安全に
try {
    $pdo = new PDO(
        'mysql:host=localhost;dbname=legacy_db;charset=utf8mb4',
        'user',
        'pass',
        [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]
    );
    $stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id');
    $stmt->execute([':id' => (int)$_GET['id']]);
    $rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
    foreach ($rows as $row) {
        echo htmlspecialchars($row['name'], ENT_QUOTES, 'UTF-8');
    }
} catch (PDOException $e) {
    // エラーは画面に出さずログに記録
    error_log($e->getMessage());
    echo '処理中にエラーが発生しました。';
}

htmlspecialcharsによるXSS対策も同時に施しているのがポイントです。

Step 5｜変更後の動作確認を仕組み化する

手動テストには限界があります。PHPUnitを導入し、最低限「正常系が動くこと」だけでも自動化しましょう。

composer require --dev phpunit/phpunit

<?php
// tests/UserRepositoryTest.php
use PHPUnit\Framework\TestCase;

class UserRepositoryTest extends TestCase
{
    public function test_ユーザーIDで検索できること(): void
    {
        $repo = new UserRepository($this->createTestPdo());
        $user = $repo->findById(1);
        $this->assertSame('山田 太郎', $user['name']);
    }
}

テストがあるだけで、次に触る人（将来の自分を含む）への「安心の贈り物」になります。