WordPress画像アップロード時のHTTPエラー対処法｜原因別5つの解決策 | WPセンターブログ

メディアライブラリに画像をアップロードしようとしたら突如表示される「HTTPエラー」。原因がわからず、何度も再試行しても解決しない経験はありませんか？特にブログ初心者やサーバー知識の浅い方にとって、このエラーは大きな壁となり得ます。本記事では、画像アップロード時に発生するHTTPエラーを「原因別に5つのケース」に細分化し、具体的かつ実践的な手順で解決策を提示します。原因の切り分けからツール紹介、設定変更までを網羅することで、技術的知見の少ない方でもトラブルシュートを自走できるようサポートします。

画像ファイルサイズ・形式の問題

結論：最も多い原因は、アップロードしようとする画像ファイルがサイズ制限を超過しているか、WordPressがサポートしないファイル形式であることです。

理由：WordPressではデフォルトでアップロード可能なファイルサイズに上限が設定されており（例：2MB〜128MB）、かつ許可ファイル形式はJPEG、PNG、GIF、SVG（要追加設定）などに限られます。これらを外れたファイルを送信すると、サーバー側がリクエストを拒否し、HTTP 400系のエラーとして返す場合があります。また、極端に大きな画像は処理時に一時ファイルを生成し、その数値演算中にメモリ負荷が高まり、結果的にHTTP 500エラー化することも少なくありません。

確認手順

ローカルでファイル情報をチェック
macOS：Finderで「情報を見る」→ファイルサイズ／種類を確認
Windows：エクスプローラーでファイルを右クリック→プロパティ
ブラウザデバッグコンソールのNetworkタブ
Chrome DevTools → Network → 画像アップロードリクエストを再送 → ステータスコードとResponseを確認
WordPressダッシュボードでの制限確認
メディア → 新規追加 → 「最大アップロードサイズ：○MBまで」と表示される数値を把握

具体手順・解決策

画像圧縮とリサイズ
ツール例：
– TinyPNG（Web版／プラグイン）
– ImageOptim（macOSアプリ）
– RIOT（Windows版）
手順：
1. 画像を上記ツールにドラッグ＆ドロップ
2. 自動圧縮後、画質設定を70〜80%程度に維持
3. 解像度をブログ表示幅（例：1200px）にリサイズ
プラグインによる自動最適化
Imagify や Smush の無料プランでも、アップロード時に自動圧縮・リサイズ可能
設定例：
```
// Imagify: functions.php に追加
add_filter( 'imagify_resize_images', '__return_true' );
add_filter( 'imagify_manual_optimization_default', '__return_true' );
```
メリット：手動操作不要。既存メディアにも一括最適化機能あり。
ファイル形式の変更
SVG を扱う場合、デフォルトではセキュリティ制限あり → SVG Support プラグインを導入
HEIC や WebP はテーマ／プラグインで対応を追加

WordPressのアップロード制限を緩和
サーバーの php.ini や .htaccess で upload_max_filesize と post_max_size を調整

; php.ini の例
upload_max_filesize = 64M
post_max_size = 64M

# .htaccess の例
php_value upload_max_filesize 64M
php_value post_max_size 64M

PHPメモリ制限不足

結論：画像処理などで一時的に大量のメモリを消費すると、PHPのメモリ上限（memory_limit）を超過してHTTP 500エラーが発生します。

理由：WordPressはアップロードされた画像をサムネイル生成やExif情報の読み込みなどで再処理します。特に高解像度・高画質の画像は、その変換プロセスで多くのメモリを必要とし、memory_limit 設定が低い場合、PHP自体が処理を停止し「Internal Server Error（500）」を返します。また、プラグインやテーマが独自に画像処理ライブラリ（Imagick や GD）を利用する場合も、追加のメモリが必要です。

確認方法

phpinfo() でメモリ設定を確認
一時的にテーマの functions.php やサーバー上のテスト用 info.php に以下を記述し、ブラウザで確認：
```
<?php phpinfo(); ?>
```
memory_limit の値（例：128M）を探す
WP-CLI でのチェック
wp config get WP_MEMORY_LIMIT
wp config get WP_MAX_MEMORY_LIMIT
WP_MEMORY_LIMIT：フロントエンドでの上限
WP_MAX_MEMORY_LIMIT：管理画面・バッチ処理での上限
エラーログでの証拠取得
/var/log/apache2/error.log（Apache）や /var/log/nginx/error.log（Nginx）を確認し、Allowed memory size of ... bytes exhausted の記述を探す

対処手順

wp-config.php にメモリ上限を設定

// wp-config.php の先頭付近に追加
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

php.ini でグローバル設定を更新
php.ini（対象PHPバージョン用）で以下を修正：
```
memory_limit = 512M
max_execution_time = 300
```
設定変更後、Webサーバーを再起動：sudo systemctl restart apache2 または sudo systemctl restart nginx

.htaccess を利用した上書き（Apacheのみ）

<IfModule mod_php7.c>
  php_value memory_limit 512M
  php_value max_execution_time 300
</IfModule>

プラグイン側のメモリ要件を確認
Imagick を使うプラグインは特にメモリ消費が大きいので、必要に応じて GD ライブラリに切り替え

ツール紹介

Query Monitor プラグイン：メモリ使用量やクエリ情報を可視化し、どの処理がメモリを逼迫しているか把握可能
New Relic APM（有料）：サイト全体のリクエストごとのメモリ・CPU使用率をモニタリングし、過負荷原因を特定

注意点：共有ホスティングでは php.ini の直接編集が不可な場合があり、その場合はホスティング会社に上限緩和を依頼する必要があります。メモリを増やしすぎると、サーバー自体の物理メモリを圧迫し、他のサイトやサービスに悪影響を及ぼすリスクがあるため、設定値は慎重に決定してください。

サーバーの一時フォルダ容量・パーミッション問題

結論：アップロード処理時にWordPressが一時ファイルを生成する/tmp ディレクトリの容量不足やパーミッション不備が原因で、HTTP 500エラーやタイムアウトが発生します。

理由：PHPのファイルアップロードでは、リクエストを受け取るとまずサーバー側で一時ファイルを /tmp に書き出し、後でアプリケーションがそれを読み込んで処理します。一時フォルダのディスク容量が消費済み、またはフォルダの所有者・権限が誤っている場合、ファイル書き込みに失敗し、処理が中断されてエラーとなります。

容量不足のサインと確認手順

df -h /tmp で空き容量を確認。使用率が100%に近い場合、容量不足。
du -sh /tmp/* で大きいファイルやディレクトリを特定し、古い一時ファイルを確認。
php -i | grep sys_temp_dir で一時フォルダパスを確認。

容量クリアとメンテナンス方法

不要ファイルの自動クリーンアップ
```
find /tmp -type f -mtime +2 -delete
```
2日以上前の一時ファイルを削除。
cronに登録例：
```
0 3 * * * find /tmp -type f -mtime +2 -delete
```
tmpfs マウント設定の見直し
`/etc/fstab` で tmpfs サイズを指定：
```
tmpfs   /tmp    tmpfs   defaults,size=1G   0 0
```

パーミッション設定の最適化

推奨権限
所有者：Webサーバー実行ユーザー（例：`www-data`） / 権限：`700` または `755`

変更手順

sudo chown www-data:www-data /tmp
sudo chmod 755 /tmp

セキュリティ留意点：権限を緩くしすぎると不正ファイル配置リスクがあるため避けてください。

プラグイン・テーマの干渉

結論：インストール済みのプラグインやテーマが、メディアアップロード処理に干渉しているケースがあります。特に画像圧縮・キャッシュ・セキュリティ系プラグインで発生しやすいため、ステージング環境での検証を推奨します。

理由：プラグインはWordPressのフック機構を利用して挙動を拡張・変更しますが、複数プラグインが同一フックを操作すると処理順序が影響し、エラーが起きやすくなります。

干渉検証のフロー

ステージング環境でプラグインを全無効化し、アップロードテスト。
プラグインを1つずつ有効化して切り分け。
テーマを標準テーマに切り替え再テスト。

代表的トラブルプラグイン

キャッシュ系（WP Rocket, Autoptimize）：キャッシュ衝突 → 一時的にクリア
セキュリティ系（Wordfence, Sucuri）：WAF遮断 → アップロード先をホワイトリスト
画像最適化（EWWW, ShortPixel）：API失敗 → タイムアウト延長

通信タイムアウトとセッション切れ

結論：PHPの max_execution_time や curl_timeout 設定値を超えると処理が中断され、HTTPタイムアウトエラーが発生します。

設定変更例

php.ini

max_execution_time = 300
max_input_time = 300

.htaccess

<IfModule mod_php7.c>
  php_value max_execution_time 300
  php_value max_input_time 300
</IfModule>

WP HTTP API

add_filter( 'http_request_timeout', function() { return 60; } );
add_filter( 'http_request_args', function( $r ) {
    $r['timeout'] = 60;
    return $r;
});

セッション延長

define( 'AUTH_COOKIE_EXPIRATION', 86400 );

さらなるトラブルシューティングとベストプラクティス

HTTP/3・APIの将来展望

HTTP/3の普及で接続時間短縮、今後WordPressも新APIへ移行予定。

ログ活用

Apache/Nginxのエラーログ、New RelicやDatadogで監視。

定期メンテナンス

ファイルシステム：容量・権限チェック
PHP設定：各種上限値確認
プラグイン：更新後テスト
バックアップ：ロールバック手順整備
監視：エラー率アラート設定

まとめ

画像アップロード時のHTTPエラーは、ファイルサイズ・形式、メモリ制限、一時フォルダ容量・パーミッション、プラグイン干渉、通信タイムアウトのいずれか、または複数が絡むことで発生します。まずは原因を切り分け、各対処手順（圧縮・リサイズ、メモリ設定、権限修正、プラグイン検証、タイムアウト延長）を実行してください。本記事のチェックリストを運用フローに組み込み、再発防止と安定運用を実現しましょう。

今すぐ手順を実行し、快適なメディアアップロード環境を構築しましょう。