WordPressで画像をアップロードできないとき、原因はおおむね「ファイル形式が許可されていない」「サイズがPHPの上限を超えている」「uploads フォルダーに書き込めない」「サーバーが画像を処理できない」のどれかです。表示されるメッセージで、どれに当たるかをかなり絞り込めます。
この記事では、エラー表示から原因を特定し、原因ごとの直し方を説明します。内容は2026年10月時点のWordPress 6.8系とPHP 8.3を前提にしています。
エラーの表示から原因を絞る
| 表示されるメッセージ（日本語の管理画面） | 主な原因 | 見る節 |
|---|---|---|
| 「このファイルタイプをアップロードする権限がありません。」 | WordPressが許可していない拡張子、または拡張子と中身が合っていない | ファイル形式の制限 |
| 「（ファイル名）は、このサイトのアップロードサイズ上限を超えています。」 | PHPの upload_max_filesize または post_max_size が小さい |
アップロードサイズの上限 |
| 「ディレクトリ …… を作成できません。」で始まるメッセージ | wp-content/uploads にWebサーバーが書き込めない |
uploads フォルダーの権限 |
| 「サーバーが画像を処理できません。」で始まるメッセージ | 画像の縮小版を作る処理でメモリや時間が足りない、画像処理ライブラリの不具合 | 画像処理ライブラリとメモリ |
| 「HTTP エラー」とだけ表示される | 上の2つ目〜4つ目のどれか、またはWAFやセキュリティ系のプラグインが通信を止めている | 各節、WAF |
メッセージが出ないまま失敗する場合や「HTTP エラー」だけの場合は、サーバーのエラーログを確認すると原因が分かることがあります。WordPress側のログを残すには、wp-config.php の /* That's all, stop editing! */ より上に次を書きます。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );ログは wp-content/debug.log に書かれます。確認が終わったら WP_DEBUG を false に戻します。
現在の設定をまとめて確認する
管理画面の「ツール」→「サイトヘルス」→「情報」タブを開き、「メディア処理」の項目を見ると、使われている画像処理ライブラリ（GD または Imagick）、アップロードファイルの最大サイズ、post データの最大サイズ、有効な最大ファイルサイズが一覧で確認できます。
SSHが使える場合は、WP-CLIでも確認できます。
# WordPress が受け付ける最大サイズ（upload_max_filesize と post_max_size の小さいほう）
wp eval 'echo size_format( wp_max_upload_size() ), PHP_EOL;'
# 許可されている拡張子の一覧
wp eval 'echo implode( ", ", array_keys( get_allowed_mime_types() ) ), PHP_EOL;'
# 空き容量
df -hWP-CLIはコマンドライン用のPHPで動くため、PHPの設定値（php.ini）がWebサーバー側と異なることがあります。PHPの上限はサイトヘルスの表示を正とします。
ファイル形式の制限
WordPressは、許可した拡張子のファイルだけを受け付けます。JPEG・PNG・GIFに加え、WebPはWordPress 5.8、AVIFはWordPress 6.5から標準で許可されています。古いバージョンのままのサイトでは、これらの形式が拒否されることがあるため、まずWordPressを更新します。
拡張子が許可されていても、ファイルの中身を調べた結果が拡張子と合わない場合（たとえばPNGの画像の名前だけを .jpg に変えた場合）も、同じメッセージで拒否されます。画像編集ソフトで正しい形式に書き出し直してからアップロードします。
SVGを使いたい場合
SVGはWordPressの初期設定では許可されていません。SVGは中にスクリプトを含められる形式で、そのまま受け付けるとクロスサイトスクリプティングの入口になるためです。upload_mimes フィルターでSVGの拡張子を追加するだけのコードや、正規表現で script タグを消すだけのコードでは、イベント属性などを使った攻撃を防げません。
SVGを扱う場合は、アップロード時にSVGを無害化（サニタイズ）するプラグイン、たとえば Safe SVG を使います。SVGの使い方はWordPressでSVGをアップロードして使う方法でも説明しています。
アップロードサイズの上限
ファイルサイズの上限は、PHPの次の設定で決まります。
| 設定 | 意味 |
|---|---|
upload_max_filesize |
1ファイルあたりの上限 |
post_max_size |
1回の送信全体の上限。upload_max_filesize 以上にする |
memory_limit |
PHPが使えるメモリの上限。大きな画像の縮小版を作るときに使う |
max_execution_time |
1回の処理に使える秒数の上限 |
WordPressが受け付ける上限は、upload_max_filesize と post_max_size の小さいほうです。upload_max_filesize だけを上げても、post_max_size が小さいままでは上限は変わりません。
設定を変える場所
設定を書く場所は、サーバーのPHPの動かし方によって違います。
| 環境 | 書く場所 |
|---|---|
| 共用レンタルサーバー | サーバー会社の管理画面にある「php.ini 設定」などの項目。無ければ各社のマニュアルを確認する |
| VPSなどでPHP-FPMを使っている | PHP-FPMの php.ini（Ubuntu 24.04 なら /etc/php/8.3/fpm/php.ini）、またはWordPressのディレクトリに置く .user.ini |
| ApacheのPHPモジュール（mod_php）を使っている | php.ini、または .htaccess の php_value |
php.ini や .user.ini には、次のように書きます。値は扱う画像に合わせて決めます。
upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
max_execution_time = 120注意点が2つあります。
.user.iniが読まれるのは、PHPをCGI・FastCGI（PHP-FPMを含む）で動かしている場合だけです。また、読み直しの間隔（user_ini.cache_ttl）の初期値が300秒のため、反映まで最大5分ほどかかります.htaccessのphp_valueは、mod_phpで動いている場合にしか使えません。PHP-FPMの環境で書くと、Apacheが命令を解釈できず、サイト全体が500エラーになります
php.ini を書き換えたら、PHP-FPMを再起動して反映します。
# Ubuntu 24.04 の PHP 8.3 の場合
sudo systemctl restart php8.3-fpmNginxを使っている場合は、Nginx側の受信上限 client_max_body_size（初期値1MB）も超えないようにします。超えると「413 Request Entity Too Large」が返り、WordPressの画面では「HTTP エラー」と表示されます。
# server ブロックか http ブロックに書く
client_max_body_size 64m;uploads フォルダーの権限
画像は wp-content/uploads/年/月/ に保存されます。Webサーバー（PHP）を動かしているユーザーがこのフォルダーに書き込めないと、フォルダーを作れずにアップロードが失敗します。サーバーを移転したあと、ファイルの所有者が変わってしまったときによく起きます。
WordPressの公式ドキュメントが示す権限の目安は、ディレクトリが755、ファイルが644です。VPSなどで所有者を直す例は次のとおりです。Webサーバーの実行ユーザーは、Ubuntu・Debianでは www-data、RHEL系では apache や nginx などで、環境によって違います。
# 所有者と権限の確認
ls -la /var/www/html/wp-content/
ls -la /var/www/html/wp-content/uploads/
# 所有者を Web サーバーの実行ユーザーにする（Ubuntu・Debian の例）
sudo chown -R www-data:www-data /var/www/html/wp-content/uploads
# ディレクトリは 755、ファイルは 644
sudo find /var/www/html/wp-content/uploads -type d -exec chmod 755 {} \;
sudo find /var/www/html/wp-content/uploads -type f -exec chmod 644 {} \;共用レンタルサーバーでは所有者は変えられないため、FTPソフトやサーバー会社のファイルマネージャーで権限だけを確認します。権限を777にする方法は、他の利用者や不正なプログラムからも書き込めるようになるため使いません。
保存先の設定が古いままになっていないか
移転後にだけ失敗する場合は、保存先のパスが旧サーバーのまま残っていないかも確認します。
wp option get upload_path
wp option get upload_url_path通常はどちらも空です。旧サーバーのパス（例: /home/旧ユーザー名/public_html/wp-content/uploads）が入っていたら、空にします。
wp option update upload_path ''
wp option update upload_url_path ''wp-config.php に UPLOADS 定数を書いている場合も、その値が新しいサーバーで正しいかを確認します。
画像処理ライブラリとメモリ
WordPressは画像をアップロードすると、サムネイルなどの縮小版を作ります。この処理には、PHPの画像処理ライブラリ（Imagick または GD）が使われます。どちらも無い場合や、処理中にメモリが足りなくなった場合は「サーバーが画像を処理できません。」と表示されます。
ライブラリが入っているか
サイトヘルスの「メディア処理」で、使われているライブラリを確認します。WP-CLIでは、ある形式を扱えるかを次のように調べられます。
wp eval 'var_dump( wp_image_editor_supports( array( "mime_type" => "image/jpeg" ) ) );'
wp eval 'var_dump( wp_image_editor_supports( array( "mime_type" => "image/webp" ) ) );'bool(false) なら、その形式を扱えるライブラリがありません。VPSなどで追加する場合は次のとおりです。
# Ubuntu・Debian の例
sudo apt install php-gd php-imagick
sudo systemctl restart php8.3-fpm大きな画像とメモリ
WordPress 5.3以降は、幅か高さが2560ピクセルを超える画像をアップロードすると、2560ピクセルに縮小した版を自動で作り、それを元画像として使います。スマートフォンで撮った大きな写真では、この処理でメモリが足りなくなることがあります。
管理画面で画像を処理するときのメモリ上限は、wp-config.php の WP_MAX_MEMORY_LIMIT（初期値256M）で決まります。次のように上げられます。ただし、サーバー側でPHPのメモリ上限の変更が禁止されている場合は効きません。
define( 'WP_MAX_MEMORY_LIMIT', '512M' );設定を変えられない場合は、アップロードの前に画像を2560ピクセル以下に縮小すると処理が軽くなります。
Imagick で失敗するときは GD を優先する
WordPressは、Imagick と GD の両方が使える場合、Imagick を先に使います。Imagick の設定（使えるメモリやスレッド）が原因で失敗する環境では、GD を先に使うようにすると直ることがあります。テーマの functions.php か、自作のプラグインに次のコードを追加します。
<?php
// 画像処理に GD を優先して使う
add_filter( 'wp_image_editors', function ( $editors ) {
return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
} );GD は扱える形式が Imagick より少ないため、追加したあとはWebPなど使いたい形式を前述の wp_image_editor_supports で確認します。
WAFやプラグインがアップロードを止めている場合
共用レンタルサーバーには、不正な通信を止めるWAF（Webアプリケーションファイアウォール）の機能があります。画像のファイル名や中身が誤って攻撃と判定されると、アップロードが「HTTP エラー」で失敗し、管理画面の操作でも403エラーになることがあります。サーバー会社の管理画面でWAFのログを確認し、該当する場合は一時的にWAFを無効にして試します。試したあとは元に戻し、必要ならサーバー会社に除外設定を相談します。
セキュリティ系や画像最適化系のプラグインが原因のこともあります。すべてのプラグインを止めて試し、直ったら1つずつ有効に戻して原因を探します。
# 有効なプラグインを控えてから、すべて無効にする
wp plugin list --status=active --field=name > ~/active-plugins.txt
wp plugin deactivate --all
# 確認が終わったら、元の状態に戻す
wp plugin activate $(cat ~/active-plugins.txt)まとめ
- まずエラーメッセージを確認し、形式・サイズ・権限・画像処理のどれに当たるかを絞る
- 形式の拒否は、WordPressの更新、正しい形式での書き出しで直す。SVGはサニタイズするプラグインを使う
- サイズの上限は
upload_max_filesizeとpost_max_sizeの小さいほう。書く場所はPHPの動かし方で違い、PHP-FPMでphp_valueを使うと500エラーになる - uploads フォルダーはディレクトリ755・ファイル644で、Webサーバーの実行ユーザーが書き込めるようにする。移転後は
upload_pathも確認する - 「サーバーが画像を処理できません。」は、画像処理ライブラリとメモリを確認し、必要ならGDを優先する