ログから読む項目
発生日時、エラー種別、メッセージ、ファイルと行、スタックトレースを確認します。Undefined functionなら未読込みや非対応、TypeErrorなら引数や戻り値、Allowed memory sizeならメモリ消費を調べます。記載された行は異常が表面化した場所で、根本原因とは限りません。
確認する順序
同時刻の操作を再現できる検証環境を用意し、PHPと製品の版を照合します。直前の更新、独自コード、依存プラグインを確認します。エラーが複数ある場合は、一つの変更で連続発生していないか時系列で調べます。
デバッグ情報は非公開で扱う
本番画面へスタックトレースを出さず、サーバーのログ機能や保護したログ先を使います。調査のために有効化した設定は期限を決め、ログの容量と公開可否を確認します。共有時はパスや入力値の秘密情報を除きます。
エラーが消えた後の確認
対象操作を再実行し、同じログが増えないことと結果が正しく保存されることを確認します。通知を非表示にしただけでは解決ではありません。修正内容と再現条件を記録し、互換性確認へ追加します。
調査メモに残す項目
エラーの先頭行だけでなく、関連する呼出し、発生操作、入力データの特徴、直前の変更を記録します。全てのスタックトレースを公開する必要はありません。内部パスや秘密情報を除いたコピーを担当者へ渡し、原本は制限した場所で保管します。
非推奨警告と区別する
DeprecatedやWarningはFatalと同じではありませんが、将来の非互換や処理不正の手掛かりになります。表示を止めることと問題の改修を分け、影響を確認したうえで対応を計画します。
よくある質問
行番号にあるファイルを消してよいですか？
原因がそのファイル単独とは限りません。必要な機能を壊す可能性があるため、呼出し元と製品仕様を調べ、停止・修正・再配置の方法を選びます。
PHPを戻すだけで直せますか？
互換性が原因なら暫定復旧の選択肢です。ただし同時にDBや製品を変えた場合は別途確認が必要です。旧PHPのサポートと再移行の期限も管理します。