2026-10-12 訂正：upload_max_filesizeとpost_max_sizeを同じ3Gにしても、multipartの付加情報を含む3GiBファイルのPOSTは収まりません。.htaccessのphp_valueは実行方式に条件があります。4Gメモリ・時間無制限を一律に推奨する設定と「WordPress再起動」、公開phpinfoの手順を撤去しました。
3GBを扱う前に単位と転送経路を決める
GB（10進）とGiB（2進）を区別し、対象ファイルのbyte数を確認します。PHPのG表記では3Gは3×1024³ bytesです。OS image等をWordPressのメディア添付として配信する必要があるか、専用storageへの暗号化転送と権限制御で扱う方が適切かを先に判断します。
この記事は設定の検討手順です。実serverへ3GBを送って成功確認した記事ではありません。共有hostingでは変更権限・契約上限・quotaがあり、VPSへ移せば必ず解決するわけでもありません。
ファイル上限とPOST全体上限を分ける
PHP公式設定資料のupload_max_filesizeは個々のファイル、post_max_sizeはPOST全体を制限します。multipartのheader・他field・複数ファイルを含むため、POST上限には余裕が要ります。
以下は64bit環境で単一3GiBファイルを検討する際の容量設定だけの例です。無条件に本番へ適用する推奨値ではありません。
upload_max_filesize = 3G
post_max_size = 4G
4Gとの差を他fieldや同時ファイルで使えるかは実requestで確認します。余裕を広げるほど受付可能な負荷も増えます。32bit整数制限、PHP・OS・filesystem、一時領域upload_tmp_dirの空き容量と権限、最終保存領域、同時upload数を点検します。
memory_limitはPHP処理のメモリ上限であり、アップロード容量をそのまま全てRAMへ確保する設定ではありません。一方、画像変換やpluginがファイル全体を読む場合は追加memoryが必要になり得ます。旧memory_limit=4G／WP_MEMORY_LIMIT=4Gは撤回し、処理内容とworker数に基づいて容量を決めます。WP_MEMORY_LIMITを書いてもserverのupload上限を突破できません。
PHPの実行方式を確認してから設定する
PHP設定変更の公式資料ではApache moduleとしてPHPを使う場合のphp_valueを説明しています。Apacheであることだけを理由に.htaccessへ貼りません。PHP-FPM／CGI等では同じdirectiveが使えず500となり得ます。管理者の運用に合わせ、実際にWeb requestを処理するphp.ini、FPM pool等を特定します。CLIとWebで読み込む設定が異なる場合があります。
実行時間・入力時間・FPM request timeout・Web server・proxy・CDNのtimeoutを別々に確認します。0で無制限にすれば安定するという旧推奨は撤回しました。必要転送時間を見積もり、有限の制限・中断・再開・監視を設計します。
WordPressまでの各層で制限を確認する
| 層 | 主な確認対象 |
|---|---|
| CDN／load balancer／proxy | request body上限、timeout、buffering、一時領域 |
| Nginx／Apache | upload経路に適用されるbody上限・timeout |
| PHP | upload／POST上限、実行方式、一時領域、処理memory |
| WordPress | 実効upload上限、許可拡張子、Multisite制限・quota、plugin |
| storage／配信 | 最終容量、permission、アクセス制御、配信負荷 |
Nginxのclient_max_body_sizeはserver／location等の適用範囲を確認します。PHPだけ変えても手前で拒否されれば届きません。許可範囲を広げる場合は、認証、容量・頻度制限、実行可能ファイルの扱いも確認します。
WordPressのwp_max_upload_sizeはPHPのuploadとPOST設定の小さい側から上限を算出しfilterも通します。管理画面に大きい数字が出ることは、実転送成功の証明ではありません。Multisiteやplugin固有の制限も確認します。
転送方法の選択
- ブラウザupload：既存経路の上限、回線断、再送、後処理を検証する。大容量に向くかは実測で判断。
- SFTP等の暗号化転送：転送先とpermissionを固定する。serverにファイルがあるだけではWordPress添付metadataは登録されない。
- 外部storage：multipart／resumable uploadや署名URL等を検討し、expiry、権限、storage費用と配信費用を確認。
旧FTPの一律推奨とAdd From Serverの無条件採用を撤回しました。pluginの現行互換性・保守状況・巨大ファイル対応は今回未確認です。メディア追加・移行backupのimport・外部file配信は異なる処理なので、同じ上限変更で全て解決すると考えません。
設定反映と検証
WordPress自体を再起動する手順ではありません。PHP／Web server等のreload・restartの要否は構成に従います。構文チェックと影響範囲を確認して管理者が反映します。
公開URLにphpinfo.phpを置く旧例は撤去しました。管理者限定の診断で必要項目だけを確認し、診断情報・認証情報を公開しません。CLIだけの値をWeb設定反映済みと扱わないことも大切です。
試験では許可size直下・超過、複数file、回線断、同時upload、一時領域不足、途中失敗時の残骸、添付metadata・checksum、公開アクセスを確認します。今回は一次資料の確認と記事修正までで、PHP／Nginx／WordPress構文実行、server変更・再起動、実upload、plugin互換性・load試験は未実施です。
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。