PHPでログを出力する方法
PHPでログを出力する方法には、標準関数のerror_log()を使う方法、php.iniでPHPエラーの記録先を設定する方法、独自のログファイルへ書き込む方法、Monologなどのログライブラリを利用する方法があります。
ログを適切に残しておくと、Webサイトやシステムで問題が発生したときに、原因を特定しやすくなります。
特に本番環境では、エラー内容をブラウザに表示するのではなく、ログへ記録して管理者が確認できるようにすることが重要です。
PHPのログ出力とは
PHPにおけるログ出力とは、プログラムの実行状況やエラー、警告、デバッグ情報などを記録することです。
例えば、次のような情報をログとして残すことがあります。
- PHPで発生したエラーや警告
- ユーザーのログインやログアウト
- API通信の結果
- データベース処理の成功・失敗
- バッチ処理の開始・終了
- 例外の内容
- デバッグ用の変数の値
ログを記録しておけば、障害が発生したあとでも「いつ」「どこで」「どのような問題が起きたのか」を調査できます。
error_log()でログを出力する方法
error_log()の基本的な使い方
PHPで簡単にログを出力したい場合は、標準関数のerror_log()を利用できます。
<?php
error_log('ログを出力しました');
error_log()は、指定した文字列をPHPのエラーログへ送信するための関数です。
出力先は、PHPのerror_log設定やWebサーバー、実行環境などによって決まります。
例えば、ユーザーIDを確認したい場合は次のように書けます。
<?php
$userId = 123;
error_log('user_id: ' . $userId);
ログには、次のような内容が記録されます。
user_id: 123
var_dump()などでブラウザに直接表示する方法と異なり、画面を汚さずに情報を確認できる点がメリットです。
配列をログへ出力する方法
error_log()へ配列をそのまま渡すのではなく、文字列へ変換してから出力します。
例えば、print_r()を利用できます。
<?php
$user = [
'id' => 123,
'name' => 'Taro',
];
error_log(print_r($user, true));
print_r()の第2引数にtrueを指定すると、内容を画面へ直接出力せず、文字列として返せます。
JSON形式に変換する方法もあります。
<?php
error_log(
json_encode(
$user,
JSON_UNESCAPED_UNICODE
)
);
出力例は次のとおりです。
{"id":123,"name":"Taro"}
ログ解析ツールなどで処理する場合は、JSON形式の構造化ログが扱いやすいことがあります。
特定のログファイルへ出力する方法
error_log()でファイルを指定する
error_log()では、特定のファイルへ直接ログを書き込むこともできます。
<?php
error_log(
"ログメッセージ\n",
3,
'/var/log/myapp/application.log'
);
error_log()の第2引数に3を指定すると、第3引数で指定したファイルへメッセージが追記されます。
この方法では、PHPを実行しているユーザーが対象ファイルやディレクトリへ書き込める権限を持っている必要があります。
また、message_typeに3を指定した場合、改行は自動で追加されません。
そのため、必要に応じて次のように\nを付けます。
error_log(
"ログメッセージ\n",
3,
'/var/log/myapp/application.log'
);
日時を付けてログを記録する
独自のログファイルを利用する場合は、日時を含めておくと調査しやすくなります。
<?php
$message = sprintf(
"[%s] User login: user_id=%d\n",
date('Y-m-d H:i:s'),
123
);
error_log(
$message,
3,
'/var/log/myapp/application.log'
);
ログは次のようになります。
[2026-08-09 21:30:00] User login: user_id=123
ただし、規模の大きいシステムでは日時やログレベルなどを自前で管理するより、専用のログライブラリを利用したほうが管理しやすくなります。
error_log()の戻り値に注意する
error_log()は基本的に成功時にtrue、失敗時にfalseを返します。
ただし、デフォルトのmessage_type = 0では、実際にログが正常に書き込まれたかどうかにかかわらずtrueが返る場合があります。
そのため、次のような処理だけでログファイルへの書き込み成功を厳密に判定できるとは限りません。
if (error_log('test')) {
echo 'ログ出力成功';
}
ログが出力されない場合は、ログファイルそのものやPHP設定を確認することが重要です。
php.iniでPHPのエラーログを設定する方法
log_errorsを有効にする
PHP自身が発生させたエラーをログへ記録する場合は、php.iniのlog_errorsを有効にします。
log_errors = On
これにより、PHPで発生したエラーをログへ記録できるようになります。
error_logで出力先を指定する
ログファイルの保存先は、error_logディレクティブで指定できます。
error_log = /var/log/php/php-error.log
例えば、次のように設定します。
log_errors = On
error_log = /var/log/php/php-error.log
指定したディレクトリに対して、PHPを実行しているユーザーが書き込み権限を持っている必要があります。
display_errorsの設定
開発環境での設定
開発環境では、エラーをブラウザへ表示したほうが原因を把握しやすい場合があります。
例えば、次のような設定です。
display_errors = On
log_errors = On
error_reporting = E_ALL
PHPコード内から設定することもできます。
<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');
ただし、コード内で変更できる設定には制限があります。
恒久的な設定は、基本的にphp.iniなどで管理するほうが適切です。
本番環境での設定
本番環境では、PHPエラーをユーザーへ直接表示しないことが基本です。
例えば、次のように設定します。
display_errors = Off
log_errors = On
error_reporting = E_ALL
この設定では、エラーを検出しながら、ブラウザには表示せずログへ記録できます。
エラーメッセージには、ファイルパスや内部構造、データベース関連情報などが含まれる可能性があります。
そのため、本番環境でdisplay_errors = Onにすると、セキュリティ上のリスクにつながる場合があります。
error_reportingで報告するエラーを設定する
E_ALLですべてのエラーを対象にする
PHPでは、error_reportingによって報告対象となるエラーの種類を設定できます。
一般的には次のように指定します。
error_reporting = E_ALL
PHPコード内では次のように書けます。
<?php
error_reporting(E_ALL);
開発環境では、問題を早期に発見するためE_ALLを指定する方法が基本です。
本番環境では運用方針に合わせる
本番環境でもE_ALLを設定し、display_errors = Offとしてログにだけ記録する構成は有効です。
ただし、システムによってはE_NOTICEやE_DEPRECATEDなど一部のログを除外する運用もあります。
例えば、次のような設定です。
error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED
どのエラーを記録するかは、システムの保守方針やログ量に応じて判断します。
現在のPHPログ設定を確認する方法
phpinfo()で設定を確認する
現在読み込まれているPHP設定を確認するには、phpinfo()を利用できます。
<?php
phpinfo();
phpinfo()を開くと、読み込まれているphp.iniの場所や各種設定値を確認できます。
ただし、phpinfo()にはサーバー構成など多くの情報が表示されます。
そのため、本番環境で外部からアクセスできる状態のまま残さないことが重要です。
コマンドラインからphp.iniを確認する
CLI環境では次のコマンドが利用できます。
php --ini
詳細なPHP設定を確認したい場合は、次の方法もあります。
php -i
Webサーバー経由で動作するPHPとCLI版PHPでは、異なるphp.iniが読み込まれていることがあるため注意が必要です。
ini_get()で個別に確認する
PHPコードから現在の設定値を確認することもできます。
<?php
echo ini_get('log_errors');
echo ini_get('error_log');
echo ini_get('display_errors');
ログファイルの保存先だけ確認するなら、次のように書けます。
<?php
var_dump(ini_get('error_log'));
ini_set()でログ設定を変更する方法
PHPでは、一部の設定をini_set()で変更できます。
<?php
ini_set('log_errors', '1');
ini_set('error_log', '/tmp/php-error.log');
error_log('テストログ');
ただし、すべてのphp.ini設定を実行時に変更できるわけではありません。
設定項目ごとに変更可能な範囲が決められています。
本番環境で恒久的に利用する設定については、php.iniやPHP-FPMなどの設定ファイルで管理するほうが適しています。
アプリケーション独自のログを出力する方法
PHPエラーとアプリケーションログを分ける
PHP自体のエラーログと、アプリケーション独自のログは分けて管理すると調査しやすくなります。
例えば、次のように分けられます。
php-error.log
application.log
payment.log
batch.log
簡単なログ関数を作る場合は、次のように実装できます。
<?php
function appLog(string $level, string $message): void
{
$line = sprintf(
"[%s] [%s] %s\n",
date('Y-m-d H:i:s'),
strtoupper($level),
$message
);
error_log(
$line,
3,
'/var/log/myapp/application.log'
);
}
appLog('info', 'Application started');
appLog('warning', 'Disk space is running low');
appLog('error', 'Database connection failed');
出力例は次のとおりです。
[2026-08-09 21:30:00] [INFO] Application started
[2026-08-09 21:30:01] [WARNING] Disk space is running low
[2026-08-09 21:30:02] [ERROR] Database connection failed
小規模なプログラムであれば、このような方法でもログを管理できます。
ログレベルを使い分ける
アプリケーションログの代表的なレベル
アプリケーションログでは、重要度に応じてログレベルを使い分ける方法があります。
代表的なものは次のとおりです。
DEBUG
INFO
NOTICE
WARNING
ERROR
CRITICAL
ALERT
EMERGENCY
例えば、次のように使い分けます。
DEBUG
開発や調査に必要な詳細情報
INFO
通常の処理が正常に行われたことを示す情報
WARNING
処理は継続できるが注意が必要な状態
ERROR
何らかの処理に失敗した状態
CRITICAL
システム運用に重大な影響を与える問題
ログレベルを使い分けると、「ERROR以上だけ通知する」といった監視もしやすくなります。
PHPのエラーレベルとは別物
DEBUGやINFOなどのログレベルと、PHPのE_ERRORやE_WARNINGなどは別の概念です。
PHPには、例えば次のようなエラーレベルがあります。
E_ERROR
E_WARNING
E_NOTICE
E_DEPRECATED
一方、DEBUGやINFOなどは主にアプリケーションログで利用される重要度です。
混同しないように注意しましょう。
Monologなどのログライブラリを利用する
大規模なPHPアプリケーションでは専用ライブラリが便利
小規模なPHPプログラムではerror_log()だけでも十分な場合があります。
一方、本格的なWebアプリケーションでは、Monologなどのログライブラリを利用すると管理しやすくなります。
概念的には、次のようにログレベルを指定できます。
$logger->info('User logged in');
$logger->warning('API response is slow');
$logger->error('Database connection failed');
ログライブラリを利用すると、ファイル出力だけでなく、syslogや外部のログ管理サービスなどへ出力できる構成を作りやすくなります。
大規模なシステムでは、次のような仕組みを組み合わせることがあります。
ログレベル
構造化ログ
ログローテーション
監視システム
外部ログ管理サービス
set_error_handler()で独自のエラー処理を行う
ユーザー定義エラーハンドラーを設定する
PHPでは、set_error_handler()を利用して独自のエラーハンドラーを設定できます。
<?php
set_error_handler(function (
int $errno,
string $errstr,
string $errfile,
int $errline
): bool {
error_log(
sprintf(
'[PHP ERROR] %s in %s:%d',
$errstr,
$errfile,
$errline
)
);
return false;
});
この例では、エラーが発生したときに独自の形式でログを出力しています。
return falseの意味
set_error_handler()のコールバックからfalseを返すと、独自処理のあとにPHP標準のエラーハンドラーへ処理を戻します。
return false;
一方、false以外を返した場合は、そのエラーについてPHP標準のエラーハンドラーによる処理が行われない場合があります。
独自ログだけを記録するのか、PHP標準のエラー処理も残すのかを考えて実装する必要があります。
error_reportingとの関係
set_error_handler()を利用する場合は、error_reporting()との関係にも注意が必要です。
必要に応じて、現在のエラーが報告対象かどうかをハンドラー内で確認できます。
if (!(error_reporting() & $errno)) {
return false;
}
独自エラーハンドラーを本格的に利用する場合は、単純なログ出力だけでなく、どのエラーを処理するかも設計することが重要です。
未処理の例外をログへ記録する方法
set_exception_handler()を利用する
set_error_handler()は主にPHPエラーの処理に利用します。
未処理の例外については、set_exception_handler()を利用できます。
<?php
set_exception_handler(function (Throwable $e): void {
error_log(
sprintf(
'[UNCAUGHT EXCEPTION] %s in %s:%d',
$e->getMessage(),
$e->getFile(),
$e->getLine()
)
);
});
これにより、tryとcatchで処理されなかった例外をログへ記録できます。
アプリケーション全体のエラー処理を設計する場合は、PHPエラーと例外を分けて考えることが重要です。
PHP-FPM環境のログを確認する
PHP-FPMには独自のログ設定がある
NginxとPHP-FPMを組み合わせてPHPを動かしている場合は、PHP本体のログだけでなくPHP-FPM側のログも確認する必要があります。
PHP-FPMには、error_logやlog_levelなどの設定があります。
そのため、PHP-FPM環境で問題を調査するときは、例えば次のログを切り分けて確認します。
Nginxのエラーログ
PHP-FPMのログ
PHP本体のerror_log
アプリケーションログ
PHPコードに問題があるように見えても、実際にはPHP-FPM側でエラーが発生している場合もあります。
PHPのログが出力されない場合の確認ポイント
最小限のテストログを出力する
ログが出ない場合は、まず最小限のコードで確認します。
<?php
error_log('PHP LOG TEST');
このログすら出力されない場合は、アプリケーションの処理ではなくPHP設定や権限に原因がある可能性があります。
log_errorsを確認する
次の設定が有効になっているか確認します。
log_errors = On
error_logのパスを確認する
保存先が正しく設定されているか確認します。
error_log = /var/log/php/php-error.log
書き込み権限を確認する
PHPを実行しているユーザーがログファイルやそのディレクトリへ書き込める必要があります。
ファイルパスが正しくても、権限がなければログを保存できません。
読み込まれているphp.iniを確認する
PHPでは、CLI、Apache、PHP-FPMなどで異なるphp.iniを利用している場合があります。
php --ini
などを利用して、実際に読み込まれている設定ファイルを確認しましょう。
設定の再読み込みが必要か確認する
php.iniやPHP-FPMの設定を変更した場合、利用している実行環境によってはPHP-FPMやWebサーバーの再読み込み、または再起動が必要です。
一方、CLI版PHPのように、次回実行時に設定が読み込まれる環境もあります。
そのため、必ず再起動すると考えるのではなく、使用しているSAPIやサーバー構成に応じて確認することが重要です。
PHPでログを運用するときの注意点
パスワードやAPIキーをログへ出力しない
ログには機密情報を安易に記録しないようにします。
例えば、次のようなコードは避けるべきです。
error_log('password=' . $_POST['password']);
特に注意したい情報には、次のようなものがあります。
- パスワード
- APIキー
- アクセストークン
- セッションID
- Cookie
- クレジットカード情報
- 不要な個人情報
ログは管理者だけが見るものと考えがちですが、ログサーバーの流出や設定ミスによって第三者へ漏れる可能性もあります。
必要な情報だけを記録することが重要です。
Web公開ディレクトリへログを置かない
ログファイルをWeb公開ディレクトリへ配置するのは避けるほうが安全です。
例えば、
/var/www/html/error.log
のような場所に置くと、Webサーバーの設定によっては外部からアクセスされる可能性があります。
可能であれば、
/var/log/myapp/
など、Web公開領域とは別の場所へ保存します。
ログファイルの肥大化を防ぐ
アクセス数の多いWebサイトでは、ログファイルが短期間で非常に大きくなることがあります。
そのため、本番環境ではログローテーションを設定することが重要です。
例えば、次のように世代管理します。
application.log
application.log.1
application.log.2.gz
一定期間を過ぎたログを圧縮したり削除したりすることで、ディスク容量の不足を防げます。
PHPのログ設定例
開発環境の設定例
開発環境では、エラーをすぐに確認できるように次のような設定が考えられます。
error_reporting = E_ALL
display_errors = On
log_errors = On
error_log = /var/log/php/php-error.log
開発中はエラーを画面へ表示しながら、ログにも記録しておくと問題を追跡しやすくなります。
本番環境の設定例
本番環境では、エラーをユーザーへ見せず、ログへ記録する構成が基本です。
error_reporting = E_ALL
display_errors = Off
log_errors = On
error_log = /var/log/php/php-error.log
ただし、記録するエラーレベルについては、システムの運用方針に応じて調整する場合があります。
PHPのログ出力は環境に合わせて使い分けることが重要
PHPでは、簡単なデバッグであればerror_log()だけでもログを出力できます。
一方、本格的なWebシステムでは、PHP自身のエラーログとアプリケーションログを分け、ログレベルや構造化ログ、ログローテーションなども含めて設計することが重要です。
開発環境ではエラーを発見しやすい設定にし、本番環境ではdisplay_errors = Offとして内部情報をユーザーへ表示しないようにします。
また、パスワードやAPIキーなどの機密情報をログへ残さず、ログファイルをWeb公開領域の外へ配置することも重要です。
適切なログ設定を行っておけば、PHPアプリケーションで問題が発生した際の原因調査や保守、監視を効率化できます。
以上、PHPでログを出力する方法や設定についてでした。
最後までお読みいただき、ありがとうございました。










