PHPを利用してWebアプリケーションを開発・運用していると、php.iniの設定変更や拡張モジュールの追加を行った際に、必ずと言っていいほど「再起動」という作業が必要になります。
しかし、初心者から中堅のエンジニアまで、意外と躓きやすいのがこの「PHPの再起動」です。
「コマンドを打ったはずなのに設定が反映されない」「そもそもどのプロセスを再起動すればいいのかわからない」といったトラブルは、サーバー構成や実行環境（SAPI）への理解不足から生じることがほとんどです。
この記事では、2026年現在のモダンな開発環境から従来のサーバー構成までを網羅し、PHPの再起動を正しく実行するための手順と、設定が反映されない原因の切り分け方を詳しく解説します。
PHPの再起動が必要になる主なケース
PHPは、実行形態によって設定の読み込みタイミングが異なります。
一般的に再起動が必要になるのは、以下のようなシステムの根幹に関わる変更を行った場合です。
php.iniの編集（メモリ上限、アップロードサイズ、タイムゾーンの変更など）- 新しいPHP拡張モジュール（PDO、mbstring、OpenSSLなど）のインストールや有効化
php-fpmのプール設定（プロセス数や実行ユーザーなど）の変更- OPcache（オーピーキャッシュ）の内容を強制的にクリアしたい場合
特にPHP-FPM（FastCGI Process Manager）を利用している環境では、Webサーバー（Nginxなど）を再起動してもPHPの設定は更新されません。
PHP自体のプロセスを管理しているサービスを個別に再起動する必要がある点を理解しておくことが重要です。
PHPの実行環境（SAPI）による再起動の違い
PHPの再起動方法を正しく選択するためには、現在動作しているPHPがどのような形態で動いているかを知る必要があります。
これをSAPI (Server API)と呼びます。
| SAPIの種類 | 概要 | 再起動の対象 |
|---|---|---|
| Apacheモジュール (mod_php) | Apacheの一部としてPHPが動作する | Apacheサービス全体 |
| PHP-FPM (FastCGI) | Nginx等と連携し、独立したプロセスで動作する | php-fpmサービス |
| CLI (Command Line Interface) | コマンドラインから実行する | 不要（実行の都度読み込まれる） |
コマンドラインで実行するPHP（CLI）については、コマンドを叩くたびに設定ファイルが読み込まれるため、OSレベルでの再起動は不要です。
反映されない場合は、編集しているphp.iniのパスが間違っている可能性が高いでしょう。
環境別のPHP再起動コマンド
それでは、実際に利用されている主要なOSや環境ごとの再起動コマンドを見ていきましょう。
Linux（Ubuntu / Debian系）
UbuntuやDebianでは、主にsystemd（systemctlコマンド）を使用してサービスを管理します。
PHP-FPMを利用している場合
PHPのバージョンを確認し、対応するバージョンのサービス名を指定します。
例えば、PHP 8.3を利用している場合は以下のようになります。
# 状態確認
sudo systemctl status php8.3-fpm
# 再起動（ダウンタイムが発生する）
sudo systemctl restart php8.3-fpm
# 設定の再読み込み（ダウンタイムを最小化）
sudo systemctl reload php8.3-fpmApacheモジュールとして動作している場合
Apache自体を再起動します。
sudo systemctl restart apache2Linux（RHEL / AlmaLinux / Rocky Linux / CentOS系）
RedHat系のOSでもsystemctlを使用しますが、サービス名の命名規則が異なる場合があります。
PHP-FPMを利用している場合
# 汎用的なphp-fpmサービス名の場合が多い
sudo systemctl restart php-fpmApache (httpd) を利用している場合
sudo systemctl restart httpdmacOS (Homebrew)
開発環境としてmacOSを利用し、HomebrewでPHPをインストールしている場合は、brew servicesコマンドを使用するのが最も簡単です。
# インストールされているPHPのサービスを確認
brew services list
# 特定のバージョンのPHPを再起動
brew services restart php特定のバージョン（例：php@8.2）を指定して再起動したい場合は、brew services restart <a href="mailto:php@8.2">php@8.2</a>のように記述します。
Docker環境
DockerコンテナでPHPを動かしている場合、ホスト側でサービスを再起動するのではなく、コンテナそのものを再起動するか、コンテナ内でプロセスにシグナルを送ります。
Docker Composeを利用している場合
# phpサービスのみを再起動する場合
docker-compose restart phpコンテナ内のPHP-FPMにリロードを指示する場合
コンテナを停止させずに設定を反映させたい場合は、killコマンドを使ってUSR2シグナルを送信します。
# コンテナ内のマスタープロセスに信号を送る
docker exec -it <container_id> kill -USR2 1※PID 1がphp-fpmのマスタープロセスであることを前提としています。
PHP再起動後に設定が反映されない原因と対策
コマンドを実行したにもかかわらず、phpinfo()などの出力が変わらないことがあります。
その場合に確認すべき4つのチェックポイントを解説します。
1. 編集しているphp.iniのパスが正しいか
PHPは複数のphp.iniファイルを保持していることがよくあります。
特に「CLI用」と「FPM用」で分かれているケースが非常に多いです。
以下のコマンドで、現在読み込まれている設定ファイルのパスを確認してください。
# CLI環境での確認
php --ini
# Web環境での確認（PHPファイルを作成してブラウザでアクセス）
<?php phpinfo(); ?>Loaded Configuration Fileの項目に表示されているパスが、あなたが編集したファイルと一致しているか必ず確認しましょう。
2. PHP-FPMのプロセスが残っている
restartコマンドを発行しても、ゾンビプロセスが残っていたり、設定エラーで起動に失敗していたりすることがあります。
以下のコマンドで、プロセスが新しく生成された時刻を確認してください。
ps aux | grep php-fpm実行結果の開始時刻（START列）が、再起動コマンドを打った時刻になっていなければ、正常にプロセスが入れ替わっていません。
その場合は、一度stopしてからstartするか、手動でプロセスをkillする必要があります。
3. OPcacheが有効になっている
パフォーマンス向上のためのOPcacheが有効な場合、PHPファイル自体の変更は検知されても、内部的なキャッシュが古い設定を保持し続けることがあります。
php.ini自体の変更であれば再起動で解消されますが、ソースコードの変更が反映されない場合は、以下の関数を実行するスクリプトをブラウザ経由で叩くことでキャッシュをクリアできます。
<?php
// OPcacheをリセットする
if (function_exists('opcache_reset')) {
opcache_reset();
echo "OPcache has been reset.";
} else {
echo "OPcache is not enabled.";
}
?>4. 設定ファイルの記述ミス（シンタックスエラー）
php.iniの記述を間違えていると、PHP-FPMなどのサービスは起動に失敗します。
再起動コマンドを打った後に、必ずサービスの状態を確認してください。
# エラーがあるか確認するコマンド（PHP-FPM）
sudo php-fpm -ttest is successfulと表示されれば記述に問題はありません。
もしエラーが表示された場合は、指定された行数周辺のタイポや、セミコロンの付け忘れを確認しましょう。
実践的な運用Tips：ダウンタイムを抑える方法
本番環境でPHPを再起動する場合、数秒のダウンタイム（接続不能時間）も許容されないケースがあります。
その際は、以下の手法を検討してください。
Reload（リロード）を活用する
restartは一度プロセスを完全に終了させますが、reloadは現在のリクエスト処理を待ってから新しいプロセスを生成します。
# 推奨されるリロードコマンド
sudo systemctl reload php-fpm段階的なアップデート
複数のサーバーで負荷分散を行っている（ロードバランサー配下にある）場合は、1台ずつ切り離して再起動を行う「ローリングアップデート」が定石です。
まとめ
PHPの再起動は、単純なコマンド操作に見えて、その裏側ではSAPIの理解やプロセス管理といった重要な概念が関わっています。
設定が反映されない時は、まずphpinfo()で編集しているパスが正しいかを確認し、その次にサービスの状態が「active (running)」になっているかをチェックする習慣をつけましょう。
2026年のモダンな開発環境においても、これらの基本原則は変わりません。
今回の手順を参考に、それぞれの環境に適した再起動コマンドを使い分け、スムーズな設定反映を行えるようにしましょう。
もし複雑なDocker環境やクラウドネイティブな構成を利用している場合は、オーケストレーションツールの再起動戦略（RollingUpdateなど）についても併せて学習することをおすすめします。