閉じる

php.iniの変更が反映されない原因は?確認すべき5つのポイントと解決手順

PHPの開発やサーバー構築において、「php.iniを編集したのに設定が反映されない」という事態は、初心者からベテランまで多くのエンジニアが直面するトラブルの一つです。

メモリ上限の変更やファイルアップロードサイズの設定など、重要なパラメーターを調整する際に反映が滞ると、アプリケーションの動作に深刻な影響を及ぼしかねません。

本記事では、2026年現在のモダンな開発環境(Docker、クラウド環境、PHP-FPMなど)を踏まえ、php.iniの変更が反映されない原因を特定するための5つのチェックポイントと、それぞれの具体的な解決手順を詳しく解説します。

設定が反映されない仕組みを根本から理解し、迅速なトラブルシューティングを行えるようになりましょう。

まずは現在の設定状況を正しく把握する

解決策を探る前に、まず最初に行うべきは「PHPが現在どの設定ファイルを読み込み、どのような値として認識しているか」を客観的に確認することです。

自分が編集しているファイルが、実はシステムから無視されている可能性があるためです。

最も確実な方法は、PHPの情報を出力するphpinfo()関数を使用することです。

以下のコードを一時的なPHPファイル(例: info.php)として作成し、ブラウザからアクセスしてください。

PHP
<?php
// 現在のPHP設定情報を表示する
phpinfo();
?>

実行後、ブラウザに表示された画面で以下の項目を重点的にチェックします。

項目名確認すべき内容
Configuration File (php.ini) PathPHPがphp.iniを探しに行く標準のディレクトリパスです。
Loaded Configuration File実際に読み込まれているphp.iniのフルパスです。ここが(none)になっている場合は、設定ファイルが読み込まれていません。
Additional .ini files parsed追加で読み込まれている設定ファイルのリストです。
各ディレクティブのLocal Value / Master Value左側が現在の有効値、右側がphp.iniに記述された基本値です。

この画面でLoaded Configuration Fileに表示されているパスが、あなたが編集したファイルのパスと完全に一致しているかを必ず確認してください。

もし異なるパスが表示されているなら、どれだけ編集を繰り返しても反映されることはありません。

1. WebサーバーまたはPHP-FPMを再起動していない

php.iniが反映されない最も基本的かつ頻繁な原因は、設定変更後にプロセスを再起動していないことです。

PHPの設定ファイルは、PHPが起動するタイミングで一度だけ読み込まれます。

Apacheのモジュールとして動作している場合や、NginxとPHP-FPMを組み合わせて使用している場合、ファイルを書き換えただけではメモリ上の設定は更新されません。

Webサーバー(Apache)の場合

Apache上でPHPを動かしている場合は、Apache自体を再起動する必要があります。

Shell
# Apacheの再起動 (Ubuntu/Debian系)
sudo systemctl restart apache2

# Apacheの再起動 (RHEL/CentOS系)
sudo systemctl restart httpd

PHP-FPMの場合

Nginx環境などでPHP-FPMを利用している場合は、WebサーバーではなくPHP-FPMプロセスを再起動しなければなりません。

ここを見落として「Nginxを再起動したのに変わらない」と悩むケースが非常に多いです。

Shell
# PHP 8.3を利用している場合の例
sudo systemctl restart php8.3-fpm

Docker環境の場合

コンテナ環境では、コンテナ自体の再起動が必要です。

Shell
# Docker Composeを利用している場合
docker-compose restart php

設定変更後は「プロセスの再起動」が必須であるというルールを徹底しましょう。

2. 編集しているphp.iniのパスが間違っている

PHP環境には、複数のphp.iniファイルが存在することが一般的です。

特に、CLI(コマンドラインインターフェース)用と、Webサーバー(Apache/PHP-FPM)用で別々のファイルが用意されているケースが多々あります。

CLI用とWeb用の違い

ターミナルからphp -i | grep php.iniを実行して確認したパスを編集しても、ブラウザ経由で実行されるPHPには反映されません。

  • CLI用のパス例: /etc/php/8.x/cli/php.ini
  • Web用のパス例: /etc/php/8.x/fpm/php.ini または /etc/php/8.x/apache2/php.ini

先述したphpinfo()を使って、「ブラウザから見た時のLoaded Configuration File」を正しく特定し、そのパスにあるファイルを編集しているか再確認してください。

シンボリックリンクの罠

環境によっては、php.iniが別の場所へシンボリックリンクされていることがあります。

ファイルを編集したつもりが、リンクが切れていたり、リンク先が異なる場所を指していたりする場合も注意が必要です。

3. 上位の設定や他の設定ファイルで上書きされている

php.iniに正しく記述していても、他の場所で行われている設定によって値が上書き(オーバーライド)されている場合があります。

PHPの設定には優先順位が存在することを理解しましょう。

.user.ini または .htaccess による上書き

共有サーバーや特定のアプリケーション構成では、ディレクトリごとに設定を制御するために以下のファイルが使われることがあります。

  • .user.ini: PHP-FPM環境などで利用される、ディレクトリ単位の設定ファイルです。
  • .htaccess: Apache環境で php_value などの記述がある場合、php.iniの設定よりも優先されます。

もしプロジェクトのルートディレクトリにこれらのファイルが存在する場合、そちらの設定が優先されている可能性が高いです。

PHPスクリプト内での ini_set()

PHPプログラムの中で以下のように記述されている場合、php.iniの設定は実行時に上書きされます。

PHP
<?php
// スクリプト内でメモリ上限を一時的に変更する
ini_set('memory_limit', '512M');
?>

プログラムコード内で動的に設定が書き換えられていないか、プロジェクト全体を検索して確認してみるのも有効な手段です。

4. 記述ミスや構文エラーがある

php.iniの書き方が間違っている場合、PHPはその行を無視したり、デフォルト値に戻したりすることがあります。

コメントアウトの消し忘れ

php.iniでは、行の先頭にセミコロン ; が付いているとその行はコメントとして扱われます。

INI
; よくある間違い:コメントアウトされたままなので反映されない
;upload_max_filesize = 100M

; 正解:セミコロンを削除する
upload_max_filesize = 100M

単位の記述ミス

数値の単位を指定する際、正しい形式で記述されているか確認してください。

例えば、MB ではなく M と記述するのが一般的です(例: 128M)。

また、全角文字が混じっていないか、不要なスペースが入っていないかも注意深くチェックしましょう。

変更不可な設定(PHP_INI_SYSTEM)

設定項目によっては、php.iniでしか変更できないものや、スクリプト内では変更できないものがあります。

これを変更の変更の変更可能性(Changeable)と呼びます。

モード意味
PHP_INI_USERスクリプト内や .user.ini で変更可能
PHP_INI_PERDIR.htaccess や php.ini で変更可能
PHP_INI_SYSTEMphp.ini または httpd.conf でのみ変更可能
PHP_INI_ALLどこでも変更可能

例えば、memory_limitPHP_INI_ALL なのでどこでも変えられますが、一部の拡張モジュールの設定などは PHP_INI_SYSTEM に制限されていることがあります。

5. 環境変数やコンテナの仕組みによる制限

2026年現在の開発現場では、DockerやKubernetes、あるいはクラウドプラットフォーム(AWS, Google Cloudなど)の利用が一般的です。

これらの環境では、php.ini以外の仕組みでPHPの設定が制御されているケースが増えています。

Dockerの環境変数

Dockerイメージによっては、環境変数(ENV)を通じてPHPの設定を動的に生成するものがあります。

Dockerfileや docker-compose.yml 内で設定が定義されている場合、コンテナ内のphp.iniを手動で書き換えても、再起動時に環境変数の値で上書きされてしまうことがあります。

読み取り専用ファイルシステム

セキュリティの厳しい環境や不変(Immutable)なインフラ構成では、php.ini自体が読み取り専用でマウントされていることがあります。

この場合、エディタ上では保存できたように見えても、実際には変更がディスクに書き込まれていない可能性があります。

OPcache の影響

厳密にはphp.iniの設定そのものではありませんが、PHPスクリプトのキャッシュ機能である OPcache が有効な場合、プログラムの変更が即座に反映されないことがあります。

設定変更と同時にコードの挙動も確認している場合は、OPcacheのクリア(またはプロセスの再起動)もセットで行う習慣をつけましょう。

確実に反映させるための解決手順フロー

これまでのポイントを踏まえ、設定が反映されない時に試すべき手順をフローチャート形式でまとめました。

  1. phpinfo() を確認する
    • Loaded Configuration File のパスをメモする。
    • 現在の値(Local/Master)が期待通りか確認する。
  2. 正しいファイルを編集する
    • 手順1で特定したパスのファイルを編集する。
    • セミコロンが外れているか、タイポがないか確認する。
  3. 適切なプロセスを再起動する
    • Apache環境なら Apache。
    • Nginx/PHP-FPM環境なら PHP-FPM。
    • Dockerならコンテナ。
  4. 上書き要因を排除する
    • .htaccess.user.ini がないか確認。
    • コード内の ini_set() を検索。
  5. 権限と反映の最終確認
    • ファイルの所有権や読み取り権限を確認。
    • 再度 phpinfo() を見て、値が変わっているか確認。

まとめ

php.iniの設定が反映されない問題の多くは、「編集しているファイルが違う」「再起動する対象が違う」かのどちらかに集約されます。

まずは落ち着いて phpinfo() を実行し、PHPが認識している真実の情報を読み取ることが解決への最短ルートです。

特にPHP-FPMを利用している環境では、Webサーバーの再起動だけで満足してしまいがちですので、必ずPHP-FPMプロセスの再起動を忘れないようにしてください。

また、近年のコンテナ技術やクラウド環境では、設定の持ち方が多様化しています。

インフラ層での環境変数指定など、従来のphp.ini管理以外のルートも疑う視点を持つことで、より高度なトラブルにも対応できるようになります。

この記事で紹介した5つのポイントを一つずつチェックし、確実な設定反映を実現しましょう。

クラウドSSLサイトシールは安心の証です。

URLをコピーしました!