古いPHPシステムを触る前に見る設定ファイル確認の基本

古いPHPシステムを引き継ぐとき、最初に見えるのはたいていコードです。画面の不具合、追加したい機能、直したい処理があるので、つい該当ファイルを探して読み始めたくなります。

ただ、古いPHPシステムでは、コードそのものよりも先に設定ファイルを確認したほうが安全です。データベースの接続先、メール送信、外部API、ログ出力、ファイル保存先、URLの書き換え、定期実行の条件などが、思わぬ場所に分散していることがあるからです。

この記事では、古いPHPシステムを触る前に確認したい設定ファイルと、その見方を整理します。目的は、すぐに設定を直すことではありません。

どこに何があり、何を変えると危ないのかを見える化してから作業に入ることです。

古いPHPシステムは設定ファイルから全体像を見る

古いPHPシステムでは、設計書や環境構成図が最新とは限りません。むしろ、過去の改修や障害対応のたびに、設定だけが少しずつ変わっていることがあります。

たとえば、開発環境では動くのに本番では動かない、検証環境だけメールが送れない、特定のURLだけ404になる、といった問題は、アプリケーションコードだけを読んでも原因が見えにくいものです。実際には、設定ファイルの値、Webサーバーのルール、PHP実行環境、外部サービスの接続先が関係している場合があります。

特に注意したいのは、古いPHPシステムでは「設定が一箇所にまとまっている」とは限らない点です。.env がある場合もあれば、config.php に直接書かれている場合もあります。フレームワークの設定ファイル、独自のiniファイル、サーバー側の .htaccess、cronの設定まで含めて、ひとつの動作が成り立っていることもあります。

そのため、作業前の最初の目標は、コードを直すことではなく、設定の地図を作ることです。どのファイルが何を決めているのか、どの環境で値が違うのか、変更するとどこに影響するのかを押さえるだけで、作業中の判断ミスはかなり減らせます。

最初に確認したい設定ファイルの種類

古いPHPシステムで確認したい設定ファイルは、大きく3つに分けると整理しやすくなります。アプリケーション側の設定、PHP実行環境とWebサーバーの設定、そして周辺処理の設定です。

アプリケーション側の設定ファイル

まず見るべきなのは、アプリケーション内部で使われている設定ファイルです。代表的なものには、.env、config.php、settings.php、database.php、独自名のiniファイルやyamlファイルなどがあります。

ここで確認したいのは、次のような項目です。

• データベースの接続先
• メール送信の設定
• 外部APIや決済サービスの接続先
• ファイルアップロード先
• ログ出力先
• デバッグ表示の有無
• タイムゾーンや文字コード

古いシステムでは、同じ意味の設定が複数の場所に残っていることがあります。たとえば、古いDB接続情報がコメントアウトされずに残っていたり、検証用の外部API URLが別ファイルに書かれていたりするケースです。

大事なのは、値をすぐ書き換えないことです。まずは「この項目は何に使われているのか」「本番・検証・開発で違いがあるのか」「変更するとどの画面や処理に影響するのか」をメモします。認証情報そのものを共有メモに貼るのではなく、項目名と用途を記録するだけでも十分役に立ちます。

PHP実行環境とWebサーバーの設定

次に、PHPの実行環境とWebサーバー側の設定を確認します。代表的なのは php.ini、.user.ini、.htaccess、ApacheやNginxの設定です。

ここには、アプリケーションの動き方を左右する設定が含まれます。たとえば、アップロードできるファイルサイズ、メモリ上限、実行時間、タイムゾーン、エラー表示、リダイレクト、URL書き換え、Basic認証、アクセス制御などです。

画面上は同じPHPファイルを実行していても、サーバー側の設定が違えば結果は変わります。古いシステムでは、.htaccess のrewriteルールでURLが成立していたり、特定ディレクトリだけアクセス制御が入っていたりすることがあります。

特に、display_errors のようなエラー表示設定や、アップロード上限、セッション関連の設定は、改修後の確認でつまずきやすい項目です。アプリケーション側のコードだけでなく、どのPHP設定が効いているのかを見ておくと、原因の切り分けがしやすくなります。

周辺処理の設定

最後に、画面から見えにくい周辺処理の設定を確認します。composer.json、cron、バッチファイル、ログローテーション、バックアップ、デプロイ用スクリプトなどです。

たとえば、画面では単に「予約処理」と表示されていても、実際にはcronで夜間にPHPスクリプトが実行されているかもしれません。問い合わせフォームの送信後に、別のバッチがメールやCSV出力を処理している場合もあります。

古いPHPシステムでは、画面の改修だけに見える作業でも、周辺処理に影響することがあります。DBのカラム名を変えたらバッチが落ちる、保存先ディレクトリを変えたらバックアップ対象から外れる、ログの場所を変えたら監視に引っかからなくなる、といった事故は珍しくありません。

設定ファイルの確認では、画面に出ている処理だけでなく、裏側で動いている処理も含めて見る必要があります。

確認するときは「値」より「差分」と「影響範囲」を見る

設定ファイルを見るとき、つい値そのものに注目しがちです。しかし、古いPHPシステムで本当に重要なのは、値の正誤だけではありません。どの環境で何が違うのか、その違いがどの処理に影響しているのかです。

たとえば、本番環境と検証環境でDB接続先が違うのは自然です。一方で、ログ出力先、メール送信先、外部APIのエンドポイント、デバッグ設定などは、違って当然の場合もあれば、違うと危険な場合もあります。

そのため、設定確認では次のように整理すると扱いやすくなります。

• 設定項目名
• 何に使われているか
• 本番・検証・開発で値が違うか
• 変更すると影響する画面や処理
• 変更前に確認すべき相手や資料
• 戻す場合の手順

ここで注意したいのは、認証情報や秘密情報の扱いです。設定確認のメモに、パスワードやAPIキーをそのまま貼り付ける必要はありません。共有するなら「メール送信用APIキー」「決済サービス接続情報」のように項目の役割だけを残し、具体値は安全な管理場所で扱います。

また、古いシステムでは「使われていないように見える設定」が残っていることもあります。すぐ削除したくなりますが、まずは参照箇所を確認します。コード検索、ログ、実行中のバッチ、過去の運用メモを見て、削除してよい根拠があるかを確認してから判断します。

設定ファイルを読む目的は、正解の値を当てることではありません。作業前に、危ない差分と影響範囲を見つけることです。

触る前に作るミニチェックリスト

古いPHPシステムを触る前には、簡単なチェックリストを作っておくと安心です。完璧な設計書を作る必要はありません。作業に入る前に、最低限の見落としを防ぐためのメモで十分です。

まず、設定ファイルの一覧を作ります。ファイル名、場所、役割、確認した環境を並べます。.env や config.php だけでなく、.htaccess、composer.json、cron、デプロイスクリプトなども含めます。

次に、変更禁止または要確認の項目を分けます。DB接続先、メール送信先、外部API、決済、ファイル保存先、ログ出力先などは、変更前に影響範囲を確認したい項目です。担当者や取引先との関係がある設定なら、技術的に変更できるかだけでなく、運用上変更してよいかも確認します。

さらに、外部接続先を整理します。古いPHPシステムでは、外部API、SMTP、FTP、SFTP、社内サーバー、古い管理画面など、接続先が散らばっていることがあります。接続先がわからないまま改修すると、検証では動いたのに本番で通信できない、という問題が起きやすくなります。

最後に、ログとバックアップを確認します。変更後に何を見れば異常を検知できるのか、問題が起きたときにどこまで戻せるのかを知っておくと、作業の怖さがかなり下がります。

作業前チェックリストは、次のような形で十分です。

設定ファイル一覧を確認した
本番・検証・開発の差分を確認した
DB、メール、外部API、ファイル保存先を確認した
URL書き換えやアクセス制御を確認した
cronやバッチなど画面外の処理を確認した
ログの場所と確認方法を確認した
変更前の退避と戻し方を確認した
秘密情報を共有メモに直接貼っていない

設定ファイル一覧を確認した
本番・検証・開発の差分を確認した
DB、メール、外部API、ファイル保存先を確認した
URL書き換えやアクセス制御を確認した
cronやバッチなど画面外の処理を確認した
ログの場所と確認方法を確認した
変更前の退避と戻し方を確認した
秘密情報を共有メモに直接貼っていない

このチェックリストは、作業者を縛るためのものではありません。古いシステムに入るときの不安を、確認可能な項目に分解するためのものです。

まとめ

古いPHPシステムを触る前に確認したいのは、コードだけではありません。.env や config.php のようなアプリケーション設定、php.ini や .htaccess のような実行環境とWebサーバー設定、cronやバッチのような周辺処理まで含めて見ることで、システムの全体像が見えやすくなります。

最初に目指すべき成果は、設定をきれいに直すことではなく、どこに何があり、何を変えると危ないのかを見える化することです。値そのものよりも、環境差分、用途、影響範囲、戻し方を整理すると、改修や障害対応の判断がしやすくなります。

古いPHPシステムは、触る前の確認に少し時間をかけるだけで、作業中の事故を減らせます。まずは設定ファイルの一覧を作り、本番・検証・開発の差分を見て、外部接続と周辺処理を押さえるところから始めると安全です。