WordPress でアップロードファイルサイズの上限を引き上げる

WordPress のアップロード上限は3つの設定で決まり、そのすべてが噛み合っていなければなりません。実際の上限は upload_max_filesize、post_max_size、そして Web サーバーのリクエストサイズ制限のうち 最も小さい 値になります。1つだけ引き上げて残り2つを小さいままにしても何も変わりません。多くの人が「直したのに効かなかった」と結論づけるのは、まさにこれが原因です。まずは WordPress 最大アップロードサイズツールで現在の値を確認しましょう。WordPress が報告するのと同じ値を読み取り、どれがボトルネックになっているかを表示します。

なぜこの上限があり、どこで決まっているのか

WordPress はアップロード上限を設定しているわけではありません。ただ報告しているだけです。「アップロードしたファイルは php.ini の upload_max_filesize を超えています」というメッセージが表示されるとき、それは PHP がそのまま出しているものです。

アップロードは3つの別々の値でせき止められ、実際の上限はその中で最も小さい値になります。

upload_max_filesize（PHP）— PHP が受け付ける単一ファイルの最大サイズ。
post_max_size（PHP）— POST ボディ全体の最大サイズ。ファイルは他のフォーム項目と一緒に POST リクエストの中に乗って送られるため、この値は upload_max_filesize より大きくなければなりません。
Web サーバーのボディサイズ制限 — Nginx なら client_max_body_size、Apache なら LimitRequestBody。これは PHP の外側に存在するため、Nginx の背後では PHP だけをいじった修正が黙って失敗します。

4つ目の値である max_execution_time はサイズを制限するものではありませんが、回線が貧弱な場合に遅い大きなアップロードを転送の途中で中断させます。これはサイズの上限とは別の症状であり、上限そのものの一部ではありません。

落とし穴はこうです。upload_max_filesize = 256M に設定してリロードしても、100 MB のファイルがまだアップロードできない。なぜなら post_max_size が 8M のままだからです。PHP はファイルを検査する前に、ボディ全体の時点でリクエストを拒否します。上限があなたを無視したのではありません。別の上限が先に引っかけたのです。

直し方（順番どおりに）

効果が定着しやすいものから、最後の手段へと進めていきます。

1. php.ini を編集する（正しい場所）。 サイトが実際に読み込んでいるファイルを特定します。<?php phpinfo(); を書いたページを表示して「Loaded Configuration File」を確認するか、ホスティング事業者に尋ねてください。2つの PHP 値を設定し、post_max_size は upload_max_filesize より大きく保ちます。

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

PHP-FPM（sudo systemctl restart php8.2-fpm）または Apache を再起動します。PHP プロセスを再起動するまで変更は反映されません。

2. php.ini にアクセスできない場合は .htaccess を使う（Apache + mod_php のみ）。 WordPress のルートにある .htaccess に追記します。

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

これは PHP が Apache モジュールとして動作している場合にのみ機能します。PHP-FPM、CGI、FastCGI では php_value は 500 エラーを引き起こします。このエラーは値が間違っているのではなく、アプローチ自体が間違っていることを意味します。その場合は .user.ini に切り替えてください。

upload_max_filesize = 256M
post_max_size = 260M

3. Web サーバーの制限を引き上げる — 誰もが忘れるステップ。 Nginx では、サイズ超過のリクエストを PHP はそもそも見ることすらできません。Nginx が先に 413 Request Entity Too Large を返すからです。server ブロックに記述します。

client_max_body_size 256M;

sudo nginx -t && sudo systemctl reload nginx でリロードします。Nginx を使っていて PHP の編集が「何も効かなかった」場合、原因はほぼ確実にこれです。

変更を加えたら、報告される値を必ず再確認してください。最大アップロードサイズツールは新しい実効上限を教え、あなたの環境に合った正確なコード片を生成します。3つのうちどれがまだ小さいのかを当てずっぽうで探す必要がなくなります。

やってはいけないこと

wp-config.php を編集して上限が上がると期待しないこと。 広くコピペされているあの1行は、ブログ記事が主張するようには動きません。

@ini_set( 'upload_max_filesize' , '256M' );

upload_max_filesize は PHP_INI_PERDIR です。PHP の実行時に ini_set() で変更することはできません。新しい値を受け付けるのは php.ini、.htaccess、.user.ini からのみで、アプリケーションのコードからは決して受け付けません。この行はエラーも出さずに実行され、何もしません。これが WordPress で最も自信満々に繰り返される誤ったアドバイスの1つになっています。

@ini_set('post_max_size', ...) を貼り付けるのもダメ — 同じ制約、同じ「黙って何もしない」動作です。

WP_MEMORY_LIMIT を設定してアップロード上限だと思い込まないこと。 これはコードを実行する際の PHP のメモリ上限を制御するものです。サーバーがどれだけ大きなファイルを受け付けるかとは無関係です。

1つのファイルで止まらないこと。 最もよくある失敗は、upload_max_filesize だけを変更して「直せなかった」と宣言することです。3つすべてを変更し、post_max_size を upload_max_filesize より大きく保ってください。

「念のため」と非常識に高い値を設定しないこと。 2 GB の上限はリソース枯渇の問題を招くだけで、役には立ちません。本当にギガバイト級のファイルが必要なら、ブラウザの外（SFTP、あるいはチャンクアップロード対応のプラグイン）でアップロードすべきで、単一の PHP POST に無理やり押し込むべきではありません。

それでも解決しない場合は

3つの値をすべて引き上げたのにまだ壁にぶつかるなら、リクエストはサーバーより上流のどこかで制限されています。CDN やプロキシ（Cloudflare のダッシュボードは独自にアップロードボディサイズを制限します）、php.ini を無視するマネージドホストのプラットフォーム制限、あるいはまだ更新されていない .user.ini などです。.user.ini は PHP の user_ini.cache_ttl に従うため、保存してから数分は反映が遅れることがあります。ファイルに書いた内容ではなく、サーバーが実際に報告している値を確認し、まだ小さいままの層を修正してください。報告される数値がようやく目標値と一致したとき、アップロードは通ります。