2026年5月26日

WordPressのサムネイル生成で「Could not write image」などの画像書き込みエラーが出る場合の修正法

エラー・白い画面

WordPressで画像をアップロードしたときやサムネイルを再生成したときに「Could not write image」のような書き込みエラーが出る場合、原因の多くは「アップロード先のフォルダに書き込めない」「ディスクの空きがない」「画像処理ライブラリ（ImageMagickやGD）が処理しきれない」のいずれかです。この記事では、エラーの出どころの見分け方と、原因を可能性の高い順に並べた確認・修正方法、修正後にサムネイルを作り直す手順を説明します。

エラーの出どころを確認する

WordPressは、画像の縮小やサムネイルの作成を、サーバーにインストールされた画像処理ライブラリに任せています。使われるのは主にPHPの拡張機能であるImagick（ImageMagick）とGDで、両方が使える場合は標準でImagickが優先されます。

そのため、表示されるエラーの文言は、どこで失敗したかによって変わります。WordPressが出す定型のメッセージのこともあれば、ImageMagickが返したエラーがそのまま表示されることもあり、サムネイル再生成のプラグインやWP-CLIでは独自の表現になることもあります。「Could not write image」という文言にこだわらず、次の情報をそろえるのが近道です。

エラーが出た操作（新規アップロード、メディアの編集、サムネイルの再生成）
特定の画像だけか、すべての画像か
「ツール」→「サイトヘルス」→「情報」タブの「メディアの処理」に表示される、使用中の画像エディター、ImageMagickのバージョン、対応形式
PHPのエラーログと、WP_DEBUG_LOG を有効にしたときの wp-content/debug.log

すべての画像で失敗するなら書き込み権限やディスク容量、大きな画像や特定の形式（WebPやAVIFなど）だけで失敗するなら画像処理ライブラリやメモリの問題である可能性が高くなります。

原因と修正（可能性が高い順）

1. アップロード先のフォルダに書き込めない

もっとも多い原因です。サムネイルは wp-content/uploads/年/月/ の中に作られるため、そのフォルダにPHPを実行しているユーザーが書き込めないと失敗します。サーバー移転やFTPでの一括アップロードの後、所有者が別のユーザーになっていることがよくあります。

SSHが使える場合は、所有者と権限を確認します。

# PHPを動かしているユーザーを確認（php-fpm の場合の例）
ps aux | grep php-fpm | head -n 5

# uploads フォルダの所有者と権限を確認
ls -la wp-content/uploads/
ls -la wp-content/uploads/2026/

# PHPのユーザーで実際に書き込めるかを試す（ユーザー名は環境に合わせる）
sudo -u www-data touch wp-content/uploads/2026/write-test.txt && echo OK
sudo -u www-data rm wp-content/uploads/2026/write-test.txt

書き込めない場合は、所有者をPHPのユーザーに合わせ、フォルダは 755、ファイルは 644 を基本にします。777 にすると誰でも書き込める状態になるため、避けてください。

# 所有者を合わせる（ユーザー名・グループ名は環境に合わせる）
sudo chown -R www-data:www-data wp-content/uploads

# フォルダは755、ファイルは644
find wp-content/uploads -type d -exec chmod 755 {} \;
find wp-content/uploads -type f -exec chmod 644 {} \;

レンタルサーバーでSSHが使えない場合は、FTPソフトやサーバーの管理画面のファイルマネージャーで権限を確認します。共用サーバーでは、PHPがFTPと同じユーザーで動く設定になっていることが多いため、権限の数字だけ見直せば直ることがあります。アップロード先のパス（upload_path オプションや UPLOADS 定数）が独自に変更されていないかも見ておきます。upload_path に値が入っている場合は、「設定」→「メディア」にその入力欄が表示されます。

2. ディスク容量やファイル数の上限に達している

ディスクの空きがない、またはファイル数（inode）の上限に達していると、画像を書き出せません。容量の表示に空きがあっても、ファイル数の上限に先に達している場合があります。

df -h   # 容量の空き
df -i   # inode（ファイル数）の空き

レンタルサーバーでは、管理画面の容量表示やファイル数の上限を確認します。バックアッププラグインが作った古いバックアップファイルや、キャッシュフォルダが容量を圧迫していることが多いので、不要なものを整理します。削除する前に、それが本当に不要かを確かめてください。

3. 大きな画像でメモリやImageMagickの上限を超えている

スマートフォンやカメラで撮影した数千ピクセル四方の画像は、ファイルサイズが小さくても、展開するとかなりのメモリを使います。PHPの memory_limit やImageMagick自身のリソース上限を超えると、書き出しの段階で失敗します。

WordPressは画像処理のときに、WP_MAX_MEMORY_LIMIT で指定した値までメモリ上限を引き上げようとします。サーバーが許可している範囲で、wp-config.php に設定します。

// 管理画面や画像処理で使うメモリの上限
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

VPSなどでImageMagickの設定を変更できる場合は、policy.xml（/etc/ImageMagick-6/policy.xml など、場所はOSとバージョンで異なる）のリソース上限が低すぎないかも確認します。

また、WordPress 5.3以降は、長辺が一定の大きさ（標準では2560ピクセル）を超える画像を自動で縮小し、ファイル名に -scaled を付けた画像を作ります。この基準は big_image_size_threshold フィルターで変えられ、値を小さくすると処理の負荷を下げられます。

add_filter( 'big_image_size_threshold', function () {
	return 2000; // 長辺2000ピクセルを超える画像を縮小する
} );

アップロード前に画像を適切な大きさに縮小しておくのも、有効な予防策です。

4. 画像処理ライブラリが形式に対応していない

WebPやAVIFなどの形式は、サーバーのImageMagickやGDがその形式に対応していないと書き出せません。サイトヘルスの「メディアの処理」で対応形式を確認し、対応していない場合はサーバー会社に対応状況を問い合わせるか、対応している形式で画像を用意します。AVIFへの対応は、サーバー環境によってまだ差があります（2026年10月現在）。

Imagickだけで失敗し、GDなら処理できる場合は、使う画像エディターの優先順位を入れ替えて切り分けられます。mu-pluginや子テーマの functions.php に追加します。

// GDを優先し、使えない場合にImagickを使う
add_filter( 'wp_image_editors', function ( $editors ) {
	return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
} );

GDは対応形式やメモリの使い方がImagickと異なるため、切り替え後に画質や処理時間に問題がないかを確認し、原因が分かったら設定を見直してください。

5. 一時フォルダやセキュリティ設定で書き込みが制限されている

画像処理は、いったん一時フォルダにファイルを作ってから保存先に移すことがあります。PHPの open_basedir で一時フォルダへのアクセスが制限されていたり、一時フォルダに書き込めなかったりすると失敗します。この場合は、wp-config.php でWordPressが使う一時フォルダを、書き込めるフォルダに指定します。

// 公開ディレクトリの外にある、PHPが書き込めるフォルダを指定する
define( 'WP_TEMP_DIR', '/home/user/tmp' );

また、SELinuxを有効にしているサーバーでは、権限の数字が正しくても、セキュリティコンテキストの設定によって書き込みが拒否されることがあります。サーバーの管理者に確認してください。

修正後にサムネイルを作り直す

原因を直しても、失敗した時点のサムネイルは作られていないままです。WP-CLIが使える場合は、足りないサイズだけを再生成できます。実行前にサイトのバックアップを取り、画像が多いサイトでは負荷の少ない時間帯に行ってください。

# 足りないサイズだけを再生成する
wp media regenerate --only-missing --yes

# 特定の画像（添付ファイルID）だけ再生成する
wp media regenerate 123 456 --yes

WP-CLIが使えない場合は、サムネイルを再生成するプラグインを使う方法もあります。導入前に、更新が続いているか、使用中のWordPressのバージョンに対応しているかを確認してください。再生成が終わったら、メディアライブラリと記事の表示で、画像が正しく出ているかを確かめます。

まとめ

書き込みエラーは、フォルダの権限、ディスクの空き、画像処理ライブラリの上限が主な原因
まずサイトヘルスの「メディアの処理」とエラーログで、使用中のエディターと失敗した条件を確認する
権限はPHPのユーザーで実際に書き込めるかを試し、フォルダ755・ファイル644を基本にする。777にはしない
大きな画像は WP_MAX_MEMORY_LIMIT や big_image_size_threshold で負荷を調整し、Imagickで失敗するなら wp_image_editors でGDに切り替えて切り分ける
修正後は wp media regenerate --only-missing などで足りないサムネイルを作り直す