PHPでプログラムを書いている時、エラーが発生しても画面に何も表示されず、真っ白なページになる事があります。こうした状況は非常にストレスが溜まるものです。ですが「PHP エラー表示 されない」という問題には原因が複数あり、環境や設定を丁寧に見直すことで解決できます。この記事では、設定ファイルから実際のコードまで総合的に確認し、最新情報に基づいた対策をわかりやすく解説します。
PHP エラー表示 されない原因と基本的な仕組みを理解する
まず「PHP エラー表示 されない」状態が起きるメカニズムを理解することが重要です。PHPにはエラーをどのレベルで報告するかを決定する設定と、それを画面に表示するかどうかを決める設定の両方があります。これらが適切に設定されていないと、エラーが出てもユーザーの画面には表示されず、ログにだけ記録されるか、完全に無視されてしまうことがあります。
error_reporting と display_errors の違い
error_reporting は PHP がどのレベルのエラーを「検出するか」を指定するものです。例えば E_ALL に設定すると、注意（Notice）や非推奨の警告なども含めてすべて検出します。対して display_errors は検出されたエラーを「画面に表示するか」を制御するものです。error_reporting が適切でも display_errors が Off のままでは画面に何も出ません。
display_startup_errors の役割
PHP の起動直後に発生するエラー（拡張モジュールの読み込みミスなど）は display_errors を有効にしていても表示されない場合があります。その際 display_startup_errors を On にすることで、起動段階の致命的なエラーも確認できるようになります。ただし本番環境では Off にすべき設定です。
Fatal の構文エラーとファイルの読み込み失敗
構文エラー（Parse Error）はファイルをコンパイルする段階で発生するため、そのファイル内で ini_set() 等を使って display_errors を設定しても適用されません。構文チェックや別ファイルで呼び出す方法、または php.ini の設定で対応する必要があります。画面真っ白・内部サーバーエラー HTTP 500 として現れることが多いです。
php.ini やサーバー設定のチェックポイント
コード以前に設定ファイルでのミスやサーバー側の制約で PHP エラー表示がされないことが多くあります。ここではそのチェックポイントを順番に紹介します。
正しい php.ini が読み込まれているか確認する
PHP に実際に使われている php.ini の場所が誤っていることがあります。phpinfo() 関数を実行して、Loaded Configuration File の項目を確認します。所定の設定ファイルが読み込まれていなければ、その php.ini を編集しても反映されません。
php.ini の display_errors・error_reporting の設定
php.ini 内で次のような設定を確認・修正してください。
- display_errors = On
- display_startup_errors = On（起動時エラーを確認したい場合）
- error_reporting = E_ALL
- log_errors = On（本番環境で表示させない代わりにログを必ず残すため）
これらを設定後、サーバーや PHP-FPM を再起動する必要があります。
.htaccess や .user.ini、サーバーの将棋設定の影響
ホスティングやサーバー設定が PHP をモジュールとしてではなく FastCGI／PHP-FPM で動かしている場合、php.ini 以外にも .user.ini や .htaccess での上書き設定が必要なケースがあります。またホスト側で .htaccess の php_flag を許可していないこともあります。
WordPress 特有の設定とデバッグ定数を活用する
WordPress を使っている場合、独自のデバッグオプションがあり、「PHP エラー表示 されない」問題を解決する手掛かりになります。WP_DEBUG 系定数を適切に設定することで、画面表示・ログ出力のコントロールが可能です。
WP_DEBUG と WP_DEBUG_DISPLAY の使い分け
WordPress では WP_DEBUG を true にすることでエラー検知と報告機能が有効になります。WP_DEBUG_DISPLAY を true にすると画面に出力、false にすると画面には表示されずログに記録されるようになります。開発環境では両方 true、本番環境では WP_DEBUG_DISPLAY を false にするのが安全な設定です。
WP_DEBUG_LOG によるログ記録
WP_DEBUG_LOG を true に設定すると、すべてのエラーや警告・通知を wp-content/debug.log ファイルに記録します。WP_DEBUG よって検知された内容が画面表示されなくても、このログに記録されるため、問題の原因追及に非常に有用です。
WP_DISABLE_FATAL_ERROR_HANDLER や SCRIPT_DEBUG の役割
WP_DISABLE_FATAL_ERROR_HANDLER を true にすると、致命的なエラー発生時に WordPress が自動でエラー処理画面を出すのを抑制できます。また SCRIPT_DEBUG を true にすることで、標準版ではミニファイドされたファイルではなく、開発版の JS/CSS に切り替えるようになり、デバッグ時の追跡がしやすくなります。
コードレベルでできる対策
設定に問題がなくても、コード自体や実行方法・環境特有の問題で「PHP エラー表示 されない」状態になることがあります。以下で具体的なコードレベルの対策を確認します。
スクリプトの先頭で ini_set と error_reporting を明示的に設定する
スクリプトファイルの先頭に以下のようなコードを入れることで、実行時にエラー表示設定を強制できます。
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
error_reporting(E_ALL);
このコードは本来構文エラーより後に実行されるため、構文自体にミスがあると画面表示されないことがあります。そのため構文のチェックを先に行うことが重要です。
構文エラーの確認（Parse Error）
構文エラーがあるとファイルの読み込み・コンパイルが途中で止まるため、display_errors の設定は適用されません。対策として、コマンドラインで php -l ファイル名 を使って構文チェックを行ったり、編集時に IDE 等で構文ハイライト・静的解析を使うことが効果的です。
出力バッファリング・エラー抑制演算子の影響
ob_start() による出力バッファリングが使われていたり、＠（アットマーク）を使ってエラーを抑制しているコードがあると、画面にエラーが表示されないようになります。これらを一時的に外して、エラーが正常に出るかを確認してください。
ホスティング環境毎の注意点と制約
サーバー環境やホスティングの種類によって、エラー表示できない原因が設定だけでは済まない場合があります。共有ホスティング、VPS、クラウド型ホストそれぞれのケースを把握することで適切な対処が可能です。
共有ホスティングでの制限
多くの共有ホスティングではセキュリティのために display_errors の上書きを認めていないことがあります。php.ini や .htaccess の設定が無視されていたり、エラー表示自体がホストによって制御されているケースがあります。
PHP-FPM や FastCGI の設定
PHP を PHP-FPM や FastCGI で動かしている場合、php.ini だけでなく php-fpm.conf や pool の設定、あるいは .user.ini ファイルでの設定が必要なことがあります。Apache モジュールとしてではなくこれらを使っていると、.htaccess の php_flag 等が効かない場合があります。
SSL や HTTPS 設定、キャッシュの影響
HTTPS のリダイレクト設定やキャッシュプラグイン・サーバーレベルのキャッシュが有効な場合、エラー表示より先にキャッシュが返されることがあります。また SSL 証明書ミスや混在コンテンツエラーによって、ブラウザが警告をブロックして画面に何も表示しないような振る舞いになることもありますので、サーバー設定やキャッシュ設定もあわせて確認してください。
セキュリティと運用に関するベストプラクティス
エラー表示を安易に画面に出すことにはリスクがあります。本番環境でエラー表示がオンになっていると、ファイルのパス・環境変数・認証情報などが漏れ、悪意のある第三者に利用される恐れがあります。安全な運用のためには画面表示とログ出力の棲み分けが必要です。
本番環境では画面にエラーを表示しない設定にする
本番環境では display_errors を Off にし、WP_DEBUG_DISPLAY を false にするなど画面出力を防ぎます。代わりに log_errors や WP_DEBUG_LOG を使ってログに記録し、障害発生時にログを確認する体制を整えておくことが重要です。
ログファイルの管理と通知体制の構築
ログファイルの保存場所・ローテーション設定を適切にしておかないと、ディスク容量不足や古いエラーの見逃しが起きます。またエラーが発生した場合にメール通知・Slack通知などを設定しておくと迅速な対応が可能になります。
開発環境とステージング環境でのエラー表示活用
実際に新しい機能を試す際や改修作業中には、エラー表示を有効にして問題を可視化できる環境を作ることが効果的です。ローカルマシンやステージングサーバーのみで display_errors On、WP_DEBUG true とすることで、影響を最小限にしながら発見と修正がしやすくなります。
デバッグツールや拡張機能の選択肢
設定変更だけでは見逃してしまうケースもあります。PHPの拡張機能やデバッグツールを活用することでさらに効率的にエラーを可視化できます。
Xdebug を使ったステップデバッグ
Xdebug を導入すると、IDE と連携してブレークポイントを設定したり、変数の内容を逐次確認したりできます。エラーが発生した箇所だけでなく処理の流れ自体を追えるため、なぜエラーが画面に表示されないかの原因特定にも役立ちます。
ログ可視化ツールの利用
ログファイルを Web インターフェースで閲覧できるツールや、通知機能付きログ監視サービスを使うことで、エラー記録を見逃さずに済みます。特に運用中のサイトでは画面エラー表示を切っていても、ログ監視で即対応できることが信頼性につながります。
CI／コードレビュー時の静的解析導入
コードの構文ミスや古い関数・非推奨機能の使用などを事前に検知するために静的解析ツールを導入するのも有効です。これにより開発段階でのエラーを抑制でき、画面に何も出ない「PHP エラー表示 されない」状況を未然に防げます。
まとめ
PHPでエラーが画面に表示されない状況は、error_reporting/display_errors/display_startup_errors 設定や構文エラー、サーバーの方式（PHP-FPM／FastCGI）など複合的な要因によるものです。まずは設定ファイルが正しい php.ini を読み込んでいるか、必要な定数や ini_set が適切に機能しているかを確認してください。
WordPress を使っている場合には WP_DEBUG, WP_DEBUG_DISPLAY, WP_DEBUG_LOG といったデバッグ定数を活用することで、画面表示とログ出力の棲み分けができます。本番環境では画面表示をオフにしてログだけ記録し、開発環境やステージング環境でのみ表示を有効にすることがベストプラクティスです。
コードレベルで ini_set や error_reporting をスクリプトの先頭で明示する、静的解析や Xdebug を導入するなどの対策も効果的です。それらを含めて総合的に設定を見直すことで、エラーが出ても見えない状態を解消し、デバッグを快適に行える環境が整います。
コメント