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 して反映を確認する。
  • 本番ではエラーを画面に出さずログに記録し、メモリやアップロード上限はサーバー全体の資源と合わせて決める。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲