コードを書いていて何も表示されない白画面（WSOD）が出るときや、想定しているエラーがブラウザに出力されず動作がわからないときがあります。特に「PHP エラー表示 されない」という状態は、設定が隠れていたり、サーバ側で制御されていたりと意外と原因が多岐にわたります。この記事ではPHPでエラーが表示されない理由を徹底的に洗い出し、設定の確認手順や修正方法を最新情報をもとに解説します。開発環境でも本番環境でもコードが止まらないようにするための知識です。
目次
PHP エラー表示 されない原因と検索意図に応じたパターン
まず、検索ユーザーが「PHP エラー表示 されない」と入力する際に抱えている可能性のある意図や問題点を整理します。これによって記事構成や修正手順が読者にとって役立つものになります。
- 開発環境で期待するエラー（警告・通知）が表示されず原因がわからない
- 本番環境でエラーが表示されずユーザーに見せたくないのだがログにも残っていない
- 設定ファイル（php.ini やサーバ設定）で非表示になっているのではないかと疑っている
- 致命的なエラー（構文エラーなど）が原因で ini_set や display_errors の設定が反映されない状態
- PHP バージョンやサーバプラットフォーム（Apache, nginx, PHP-FPM等）で設定方法が異なるのか知りたい
PHP エラー表示 されない時の設定項目の確認
エラーが表示されない時、最初に確認すべき設定項目が複数あります。これらは php.ini やインクルードされる設定ファイル、そして実行時設定で切り替わるものです。最新情報も踏まえて解説します。
display_errors の設定
display_errors はブラウザにエラーを表示するかどうかを制御するディレクティブです。開発中は On、公開環境では Off にするのが一般的です。実行時に ini_set で上書き可能ですが、構文エラーのようにスクリプトが完全に解析されないタイプのエラーには適用されないことがあります。
php.ini に設定されている値を確認し、もし Off になっているなら On に変更し、サーバを再起動します。ini_set を使っている場合はスクリプトの最上部で設定するようにします。
display_startup_errors の影響
PHP の起動過程で発生するエラーは、display_errors が On でも隠されることがあります。そのようなケースで利用される指令が display_startup_errors です。PHP 8.0 以降ではこの指令のデフォルトが On になっており、起動時の問題を見やすくしています。
error_reporting レベルの設定
error_reporting はどのレベルのエラーを表示または記録するかを設定します。E_ALL や E_ALL & ~E_NOTICE など多数の定数があり、デフォルトで想定外の通知が省かれていることがあります。通知レベルを下げ過ぎていると見た目には「エラーがない」ように見えることがあるため、開発時には E_ALL に設定するのが望ましいです。
ログ記録 log_errors と error_log の確認
display_errors が Off の場合でも、log_errors を On にして error_log のパスが有効で書き込み可能であれば、エラーはログに残ります。ログ先が正しくない、権限がない、ログディレクトリが存在しない、設定が反映されていないなどでログが作成されていないケースがあります。
構文エラー（Parse Error）と設定の限界
PHP スクリプトに構文エラーがあると、スクリプト自体がそもそも実行されず、display_errors など実行時設定が働かないことがあります。解析前のエラー（Parse Error）は早期に停止するため、設定を動かす前段階で止まってしまうのです。
構文チェックを行う
コマンドラインで php -l スクリプト名 を実行して構文エラーがないかチェックすることができます。この方法でエラーが発見されれば修正し、改めてブラウザで確認を行います。
構文エラー時の出力の可否
構文エラーがあるとき、php.ini の display_errors が On でもインクルードされたファイルで parse error が出ていたら呼び出し元で止まり、画面に何も表示されないことがあります。このような時はメインスクリプトの直下で簡易なテストコードを書くなどしてどこで止まっているか切り分けます。
環境別（CLI vs Web）での挙動の違い
PHP コマンドライン（CLI）では構文エラーを含めてすべてのエラーレベルが標準出力に表示されるのが通常です。Web サーバ経由だと設定やサーバ側制約で隠されるので、まず CLI で問題が再現するかを試すのが有効です。
サーバーやホスティングの制約とオーバーライド
サーバー環境には共有ホスティング・VPS・専用サーバーなどがありますが、利用形態によっては php.ini を直接編集できなかったり、.htaccess や Webサーバーの設定が ini 設定を上書きしていたりします。最新の PHP 環境でもこうしたオーバーライドが原因でエラー非表示になることが少なくありません。
.htaccess や PHP-FPM 設定の確認
Apache を使っているなら .htaccess ファイルで php_flag や php_value で display_errors を Off にしている可能性があります。PHP-FPM を使っている環境ではプールごとの設定ファイルで php_admin_value や php_admin_flag によって強制的に設定が禁止されていることがあります。
ホスティング制約と disable_functions の確認
ホスティングプロバイダーが安全のため ini_set を禁止していたり、特定関数を disable_functions や open_basedir 安全モードで制限している場合があります。ini_set が効果を持たない、あるいはエラーレベルの設定が反映されないことがあるため、制限内容を調べることが必要です。
PHP バージョンの相違が設定に与える影響
PHP のバージョンによって、デフォルト値や挙動、ディレクティブの削除・追加があります。例えば PHP 8.0 で display_startup_errors のデフォルトが On になったり、log_errors_max_len が PHP 8.1 で削除されたりといった変化があります。バージョンのドキュメントを見るのが確実です。
WordPress 特有の設定による影響
WordPress を使っていると、WP_DEBUG や wp-config.php 内での設定がエラー表示を制御していることが多いです。テーマやプラグインでエラーが隠されるケースもあり、PHP の一般設定だけでなく WordPress の設定を確認することが欠かせません。
WP_DEBUG 定数の役割
wp-config.php に define(‘WP_DEBUG’, true) とすることで開発者向けに警告・通知を表示するようになります。さらに define(‘WP_DEBUG_LOG’, true) でログファイルに記録、 define(‘WP_DEBUG_DISPLAY’, true) で画面に表示を制御します。これらの定義が false になっているとエラーが見えなくなります。
テーマやプラグインでのエラーキャッチャー
テーマやプラグインでは独自例外処理やエラーキャッチャー（try/catch）を使ってエラー出力を中断することがあります。またテンプレートで output buffering を使って白画面だけを表示する仕組みが入っていることもあるため、これらのコードの中を確認する必要があります。
サーバー環境での表示制御（PHP バージョン・モジュール）
WordPress 環境では PHP モジュールやサーバーの設定が WordPress の挙動に影響を与えることがあります。PHP-FPM や Apache モジュール、FastCGI などの環境で display_errors を制御する方法が異なるため、使用している環境を把握して適切な設定を選びます。
エラーを可視化・デバッグする具体的手順
原因が複数考えられるとき、一つずつ確認しながら解決していく手順を持っておくと開発が止まりません。最新環境で実際に有効なステップを順番に紹介します。
ステップ1：phpinfo を使って設定状態を確認する
簡易な PHP ファイルを作成し phpinfo 関数を呼び出すことで、現在読み込まれている php.ini ファイルの位置、display_errors や error_reporting の現在値がわかります。これにより、設定が想定通りかどうかをまず判断できます。
ステップ2：php.ini の編集とサーバ再起動
phpinfo でわかった php.ini のファイルを編集し、以下のような設定を確認または書き換えます。 display_errors を On、display_startup_errors を On、error_reporting を E_ALL に設定し、log_errors を On にします。編集後は必ずサーバまたは PHP-FPM を再起動して変更を反映させます。
ステップ3：スクリプト上での強制設定
php.ini を編集できない環境や一時的にエラーを見たい場合、スクリプトの最上部に ini_set(‘display_errors’, ‘1’)、ini_set(‘display_startup_errors’, ‘1’)、error_reporting(E_ALL) のように書いて表示を強制します。ただし構文エラーはこれでも捕捉できないことがあります。
ステップ4：ログファイルを確認する
display_errors を On にしても画面に出ない場合、ログにエラーが出ていないか確認します。log_errors と error_log の設定が正しいか、ログファイルのパーミッションや所有者が書き込み可能かどうかをチェックします。最近の PHP では error_log ディレクトリやファイルへの書き込みが許可されていないとログが落ちないことがあります。
ステップ5：構文エラーの検出と切り分け
スクリプトを含めて構文エラーがないかをコマンドラインで確認します。もし構文エラーがあれば、そのエラーを修正後、段階的にテストを進めます。構文エラーが別ファイルで起きている場合は include や require を使った箇所をチェックします。
よくある問題と最新環境での注意点
最新環境で「PHP エラー表示 されない」という状態に陥る原因には更新された仕様やサーバ／PHPモジュールの変更が関係していることがあります。過去の知識だけで修正すると見落とす点です。
PHP 8 の display_startup_errors のデフォルト状態
PHP 8.0 以降、display_startup_errors の初期値が On になっており、PHP 起動時のエラーが画面に表示されるようになっています。従来 Off だった環境では、起動直後のモジュールロードミスなどのエラーが見えるようになったため、設定を本番用に戻す際には注意が必要です。
log_errors_max_len の削除とログ出力の簡略化
PHP 8.1 より前のバージョンで使われていた log_errors_max_len という設定は最新の環境で意味をなさないことがあります。最新環境ではその設定が削除されており、ログ出力の長さなどは別の方法で制御されているため、古いガイドに頼らないことが重要です。
ホスティングサービスでの管理画面からの制御
クラウドホスティングや共有ホスティングでは、管理画面で PHP 設定を制御できることがあります。PHP バージョン切り替えメニューや「PHP 設定」タブで display_errors の On/Off や error_log のパスを指定できる場合があるので利用してみてください。
Xdebug 等の開発補助ツールの影響
Xdebug や類似の拡張モジュールを使うと、デフォルトでエラー表示が強制されたり、バックトレースやスタック情報が追加されたりします。これらのツールを使っている場合、本番環境では無効化するか、ファイルや環境ごとに切り替えられる設定にしておくと安全です。
エラー表示がされない時に試すコード例
設定確認後、具体的にエラー表示を強制するためのコード例を試してみることが有効です。以下は典型的なテストコード例です。動作しない場合は設定か環境に根本原因があります。
<?php
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
error_reporting(E_ALL);
// 故意に構文エラーを入れてみる
echo 'テスト'
?>
このコードをブラウザで読み込んで白画面になる場合、構文エラーが原因です。セミコロンを直したうえで、次に記述を追加して段階的にエラーが表示されるか確認していきます。
セキュリティを考慮した運用方法
エラーを表示することは便利ですが、ユーザーに内部情報を見せてしまう危険性があります。情報漏洩を防ぎつつデバッグ効率を保つための運用のコツを解説します。
本番環境では display_errors Off と log_errors On
公開環境では display_errors を Off にし、log_errors を On にするのが基本です。画面にエラーを見せず、サーバ側のログで詳細を確認する構成にすることで、システム情報やパスなどの機密情報漏洩を防ぎやすくなります。
エラーページのカスタマイズとユーザーへの配慮
500 エラーや致命的なエラーが起きたときにユーザーに表示されるページをカスタムすることが多くあります。PHP のエラー表示非表示設定とは別に、Webサーバーの ErrorDocument や framework の例外ハンドラで汎用的なエラーメッセージを返すようにするとよいです。
ロギング内容の選別と監視体制の構築
ログにはどのエラーがどの状況で発生したかをできるだけ詳細に残すことが望まれます。ただしパスワードや個人情報は含めないようマスクすること。さらにログが定期的にローテーションされているか、容量制限を超えていないかなど運用面も意識します。
開発環境と本番環境で設定を分離する仕組みを持つ
設定ファイルや environment 変数を使って、開発環境ではエラーを表示、本番では非表示というルールを明確にしておくと作業ミスが減ります。CI／デプロイ時にこの切り替えが自動で適用されるとより安心です。
まとめ
PHP で「エラー表示がされない」という問題は、display_errors や display_startup_errors、error_reporting、log_errors といった基本設定の食い違い、構文エラー、サーバ／ホスティングの制約、そして WordPress などフレームワーク固有の設定によって引き起こされることがほとんどです。問題を解消するためには、設定を一つひとつ確かめる手順を踏み、構文エラーの有無を確認し、ログを必ず残す体制を整えることが重要です。
本番環境ではユーザーにエラーを見せずログに全ての異常を残すように設定し、開発環境では即座に表示させて原因を把握できるように使い分けます。これらを確実に実施すれば、開発の途中でエラーが見えずに悩むことが激減します。効率的かつ安全な PHP 開発が可能になります。
コメント