2026年9月27日
2026年9月27日
PHPのインストールと基本設定(php.iniの場所と最初に見直す項目)
PHP を自分のサーバーや開発環境に入れるときは、OS のパッケージ管理で PHP 本体と必要な拡張を入れ、読み込まれている php.ini の場所を確かめてから、本番向けの値を別ファイルで上書きする という順序で進めると迷いません。この記事では、主な環境でのインストール方法、CLI と PHP-FPM で php.ini が別になる点、WordPress を動かす前提で最初に見直す設定項目、変更が反映されないときの確認方法を説明します。
インストールする前にバージョンを決める
PHP はバージョンごとにサポート期限が決まっていて、期限を過ぎたバージョンにはセキュリティ修正が出ません。サポート状況は php.net の「Supported Versions」のページで確認できます。8.1 以前はすでにサポートが終了しています(2026年10月現在)。
WordPress で使う場合は、WordPress.org の「要件」ページに記載された推奨バージョンも合わせて確認してください。テーマやプラグインが新しい PHP に対応していないこともあるため、既存サイトを移す場合はステージング環境で動作を確かめてから本番のバージョンを決めるのが安全です。
環境別のインストール方法
Ubuntu / Debian
OS 標準のリポジトリに含まれる PHP を使うのが、更新の手間が最も少ない方法です。どのバージョンが入るかは OS のリリースによって異なるので、まず確認します。
apt show php 2>/dev/null | grep -i '^Depends'
Web サーバーに Nginx を使う場合は PHP-FPM を、WordPress に必要な主な拡張と一緒に入れます。
sudo apt update
sudo apt install php-fpm php-cli php-mysql php-curl php-xml php-mbstring \
php-zip php-gd php-intl
OS 標準とは別のバージョンが必要な場合、Ubuntu では有志が保守している PPA を使う方法がよく知られています。便利ですが、OS 公式のサポート外になる点と、PPA の保守状況に依存する点を理解したうえで選んでください。
AlmaLinux / Rocky Linux などの RHEL 系
RHEL 系では、OS のリポジトリ(AppStream)から入れる方法と、Remi リポジトリのような外部リポジトリを使う方法があります。OS のバージョンによっては dnf module で PHP のバージョンを切り替える仕組みになっているので、dnf module list php で選べるバージョンを確認してから入れます。
sudo dnf install php-fpm php-cli php-mysqlnd php-xml php-mbstring \
php-gd php-intl
Windows / macOS の開発環境
Windows では windows.php.net から ZIP 版を取得して展開し、php.ini-development を php.ini にコピーして使うのが基本です。macOS では Homebrew の brew install php が手軽です。いずれもローカル開発用であり、本番と同じ挙動を確かめたいなら、Docker などで本番と同じ OS・同じ PHP バージョンの環境を用意する方が確実性は上がります。
インストールが終わったら、バージョンと読み込まれている拡張を確認します。
php -v
php -m
php.ini はどこにあるのか
php.ini の設定でつまずく原因の多くは、編集したファイルが実際には読み込まれていない ことです。PHP は実行のされ方(SAPI)ごとに別の php.ini を使うことがあり、Ubuntu / Debian のパッケージでは次のように分かれています(8.x の部分はインストールしたバージョン)。
- コマンドライン(CLI):
/etc/php/8.x/cli/php.ini - PHP-FPM:
/etc/php/8.x/fpm/php.ini - Apache の mod_php:
/etc/php/8.x/apache2/php.ini
CLI の設定は次のコマンドで確認できます。
php --ini
ただし、これは CLI の情報です。Web から実行される PHP-FPM の設定を確かめるには、一時的に phpinfo() を出力するファイルを置き、「Loaded Configuration File」と「Additional .ini files parsed」の欄を見ます。phpinfo の画面はサーバーの内部情報を多く含むので、確認が終わったらすぐ削除してください。
<?php
// 確認後はファイルを削除すること
phpinfo();
設定は別ファイルで上書きする
php.ini 本体を直接書き換えると、パッケージ更新時に差分の扱いで迷ったり、どこを変えたか分からなくなったりします。多くのディストリビューションでは、conf.d ディレクトリに置いた .ini ファイルが php.ini の後に読み込まれるので、変更点だけをまとめたファイルを作るのがおすすめです。
; /etc/php/8.x/fpm/conf.d/99-custom.ini の例(値はサイトに合わせて調整)
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 60
max_input_vars = 3000
date.timezone = Asia/Tokyo
display_errors = Off
log_errors = On
error_log = /var/log/php/error.log
expose_php = Off
session.cookie_httponly = 1
session.cookie_secure = 1
session.use_strict_mode = 1
ファイル名の先頭の数字は読み込み順を決めるもので、大きい数字ほど後に読まれ、同じ項目は後の値が優先されます。error_log に指定したディレクトリが存在しない、または PHP-FPM の実行ユーザーが書き込めないとログが出ないので、あらかじめ作成して権限を確認しておきます。
最初に見直す主な項目
それぞれの値の意味と、決めるときの考え方を整理します。
- memory_limit: 1回のリクエストで使えるメモリの上限です。大きくしすぎると、同時アクセス時にサーバー全体のメモリが不足します。「PHP-FPM のプロセス数 × memory_limit」がサーバーのメモリに収まるかを目安に考えます。WordPress 側の
WP_MEMORY_LIMITは、この範囲内で効く設定です。 - upload_max_filesize と post_max_size: メディアのアップロード上限です。post_max_size はフォーム全体の上限なので、upload_max_filesize 以上にします。Nginx を使っている場合は
client_max_body_sizeも合わせないと、PHP に届く前に拒否されます。 - max_execution_time: スクリプトの実行時間の上限(秒)です。PHP-FPM 環境では、プールの
request_terminate_timeoutや Nginx のfastcgi_read_timeoutも別にタイムアウトを持っているので、どこで打ち切られているかをログで確認します。 - max_input_vars: 受け付ける入力変数の数です。メニュー項目の多いサイトや、項目数の多い設定画面で保存できない場合に関係します。
- date.timezone: 未設定だと警告が出たり、ログの時刻がずれたりします。
- display_errors / log_errors: 本番ではエラーを画面に出さず、ログに記録します。画面にパスや SQL が表示されると、攻撃の手がかりを与えることになります。開発環境では表示を有効にして構いません。
- expose_php: Off にすると、レスポンスヘッダーから PHP のバージョン表示が消えます。これだけで安全になるわけではありませんが、不要な情報を出さないための基本設定です。
- session.\*: WordPress 本体は PHP のセッションを使いませんが、フォーム系や会員系のプラグインが使うことがあります。HTTPS のサイトでは cookie_secure を有効にします。
OPcache(PHP のコンパイル結果をメモリに保持する仕組み)は、多くのパッケージで標準で有効になっています。php -i | grep opcache.enable などで状態を確認し、メモリ量などの細かい調整は効果を測りながら進めてください。
変更を反映させて確認する
PHP-FPM は起動時に設定を読み込むため、ファイルを変えたら再起動(または reload)が必要です。設定の書き間違いでサービスが起動しなくなるのを防ぐため、先に構文チェックを行います。
sudo php-fpm8.x -t # 8.x はインストールしたバージョンに置き換える
sudo systemctl reload php8.x-fpm
反映後は、もう一度 phpinfo で値が変わったことを確かめ、確認用ファイルを削除します。WordPress の管理画面にある「サイトヘルス」の情報タブでも、PHP のバージョンや主な設定値を確認できます。
レンタルサーバーの場合
共有型のレンタルサーバーでは、php.ini を直接編集できないことが多く、管理パネルの PHP 設定画面から変更する方式が一般的です。PHP が CGI や FPM で動いている環境では、ドキュメントルートに .user.ini を置いて一部の項目を上書きできる場合もあります。.user.ini の内容は一定時間キャッシュされるため、変更してもすぐには反映されないことがあります。どの方法が使えるかはサーバー会社のマニュアルで確認してください。
設定を変える前には、元の値と変更内容を記録しておき、問題が起きたら戻せるようにしておくと安心です。
まとめ
- PHP のバージョンは php.net のサポート状況と WordPress の要件を見て決め、ステージングで動作を確認する。
- インストールは OS のパッケージ管理を基本にし、WordPress に必要な拡張も合わせて入れる。
- CLI と PHP-FPM では php.ini が別になるので、phpinfo で実際に読み込まれているファイルを確かめる。
- 変更は
conf.dの別ファイルにまとめ、構文チェックのあと reload して反映を確認する。 - 本番ではエラーを画面に出さずログに記録し、メモリやアップロード上限はサーバー全体の資源と合わせて決める。