メディアへ画像を追加したのに「サーバーは画像を処理できません」と出たら
この記事で扱うのは、WordPressのメディアライブラリへ画像を登録し、その画像を投稿で使おうとした時に『サーバーは画像を処理できません』と表示される症状です。 最初に画像をさらに小さくしたり、設定コードを足したりせず、メディアライブラリに原本とサムネイルのどちらが残ったかを確認します。
このエラーは、投稿編集画面の画像ブロックからアップロードした時と、『メディア』→『新しいメディアファイルを追加』から登録した時のどちらでも起こります。入口ごとの場面を会話で確認してから、本文で二つのパターンを分けます。
ねぇねぇ、佐藤さん！WordPressのメディアライブラリへ写真を追加して、書いている投稿の画像ブロックで使おうと思ったんです。『メディア』の『新しいメディアファイルを追加』でJPEGを選んだら、『サーバーは画像を処理できません』と出て、一覧へきちんと登録できたのか分からなくなりました。
投稿で使う前に、メディアへ登録するところで止まったように見えたんだね。エラーが出ても原本だけ残る場合があるから、消したり設定を変えたりする前に、メディアライブラリへ画像名が残ったか一緒に見ようか。
同じ画像を投稿編集画面の画像ブロックから選んだ時にも、似た文が出ました。入口が違うので別の問題なのか、それとも何度も同じ写真を送って増やしてしまったのかが少し怖いです。
二つの入口でも、画像をWordPressへ保存して縮小画像を作る途中で止まれば、同じ文が出ることがあるよ。まず同じ画像を送り直さず、一覧に原本とサムネイルのどちらが残ったか確かめよう。入口ごとの違いは、このあと本文で分けて見ようね。
このエラーが出る二つの入口を分けて確認する
WordPressへ画像を入れる入口は違っても、どちらも途中でメディアライブラリへ添付ファイルを登録し、サムネイルなどの縮小画像を作ります。どの画面で何をしようとして止まったかを、次の二つに分けてください。
投稿編集画面の画像ブロックから追加した場合
書いている投稿へ写真を載せるため、投稿編集画面で『＋』を押して『画像』ブロックを追加し、『アップロード』からパソコン内のJPEGやPNGを選んだ場面です。正常なら画像がメディアライブラリへ登録され、そのまま投稿本文へ挿入されます。エラー後に投稿へ画像が入らなくても、原本だけメディアライブラリへ残っている場合があるため、同じ画像を送り直す前に『メディア』→『ライブラリ』を確認します。
「メディア」から先に画像を登録した場合
後で投稿や固定ページに使う写真を準備するため、管理画面の『メディア』→『新しいメディアファイルを追加』を開き、画像を選んだ場面です。この入口ではまだ投稿へ挿入していないため、確認する成功状態は、メディアライブラリに画像名、寸法、サムネイル、ファイルURLがそろっていることです。エラーが出たら、一覧に項目がないのか、原本だけあるのか、サムネイルまであるのかを見分けます。
サーバーは画像を処理できません。サーバーがビジー状態か、タスクを完了するためのリソースが不足している可能性があります。より小さい画像をアップロードすると解決するかもしれません。推奨される最大サイズは2560ピクセルです。
2560ピクセルは2,560KBという容量ではなく、画像の幅または高さです。 800×450px、240KBのJPEGでも同じ文言が出るなら、単に画像を小さくするだけでは解決しません。反対に、HTTP 403・413、『返答が正しいJSONレスポンスではありません』『アップロードしたファイルを移動できませんでした』『このファイルタイプをアップロードする権限がありません』は別症状です。本記事では同じ原因として混ぜません。
最初にメディアライブラリを開き、どこまで成功したかを見る
エラーが出た直後に『メディア』→『ライブラリ』を開き、今選んだ画像のファイル名を探します。ここで行うのは原因候補の列挙ではなく、失敗した段階を二つに分けることです。
| メディアライブラリの状態 | 成功している段階 | 次に見る原因 |
|---|---|---|
| 画像名も項目もない | 添付ファイル登録前で停止 | 画像固有の破損、一時負荷、PHP処理、サーバーログ |
| 項目はあるが灰色・寸法なし | 添付ファイル登録までは進行 | メタデータ取得、GD・Imagick、サブサイズ生成 |
| 原寸URLは開くが縮小画像がない | 元画像保存までは成功 | サムネイル生成時のメモリ・画像ライブラリ・プラグイン |
| サムネイルも表示される | 画像処理は完了している可能性 | 投稿への挿入だけ失敗する別症状を確認 |
画像を開ける場合は、添付ファイルのURLを別タブで開きます。URLが200で画像を表示できても、サムネイルが作られていなければ完了ではありません。反対に、一覧へ何も残らない場合は『サムネイル再生成』から始めても対象がないため、先にサーバーログと特定画像の確認へ進みます。
確認例は『post-photo.jpg／800×450px／240KB／投稿編集画面で選択／15時10分／項目は残ったがサムネイルは灰色』です。この一行があれば、次に調べる段階を取り違えません。
特定の画像だけ失敗する場合は、形式を変えずに正しく再書き出す
特定の一枚だけ失敗する場合は、サーバー設定より先に画像を作り直します。画像編集アプリで開き、JPEGならRGBカラーで別名保存します。スマートフォン写真がHEICのまま、拡張子だけを
.jpg
へ変えてもJPEGにはなりません。アプリの書き出し機能でJPEGまたはPNGへ変換してください。
- 元画像を削除せずPCへ残す
- 長辺を1920px程度へ縮小する
- ファイル名を半角英数字とハイフンだけにする
- JPEG品質を80〜90程度にして別名保存する
- 新しい一枚だけをメディア画面から追加する
縮小版が成功すれば、大きさ、色空間、埋め込みメタデータ、画像形式のいずれかが関係しています。成功したからといって、サイト内の全画像を一括変換する必要はありません。失敗した元画像と成功した縮小版を残せば、違いを後で確かめられます。
反対に、複数の小さいJPEGがすべて失敗するなら、画像一枚の問題として追い続けないでください。「メディア」→「ライブラリ」を再読み込みし、原本だけ登録されていないかを見ます。原本があり、サムネイルだけ欠けているなら、WordPressがアップロード後に行うサブサイズ生成で止まった可能性が高くなります。
エラーが出た画像を見直したら、メディアライブラリには原本らしいものが残っていました。アップロードが丸ごと失敗したと思っていたので、ちょっと意外です。
原本が残っているのを見つけたなら、大事な手がかりだよ。送信は終わって、その後の小さい画像づくりで止まった可能性があるね。灰色のサムネイルや、画像サイズの欄も一緒に見てみよう。
画像を送ることと、WordPressが小さい画像を作ることを同じ作業だと思っていました。原本を消して何度も送り直す前に気づけて、少しほっとしました。
何度も送り直す前に止まれたから、同じ原本が増えずに済みそうだね。次は元画像を残したまま、別名で縮小した一枚だけを試そう。成功した方と失敗した方を比べられるようにしておくと安心だよ。
小さいJPEGもすべて失敗する場合は、PHPと画像ライブラリを確認する
WordPress管理画面の「ツール」→「サイトヘルス」→「情報」を開きます。「メディア処理」「サーバー」に相当する項目を展開し、GDまたはImagick、PHPメモリ上限、最大アップロードサイズを確認します。項目名はWordPressやサーバー環境で少し異なります。
- GDまたはImagick： どちらも見当たらない、または失敗した画像形式へ対応していない時はサーバー窓口へ確認する
- PHPメモリ上限： 値が小さく、幅の大きい画像だけ失敗する時は候補になる
- 最大アップロードサイズ： 画像のKB・MBと比較する。2560pxとは別の値
サイトヘルスの情報を見ただけで、GDからImagickへ、あるいはImagickからGDへ勝手に切り替えないでください。どちらのライブラリでも正常に動く環境は多く、名前だけで良否は決まりません。エラー発生時刻とサーバーのエラーログを照合できるなら、メモリ不足、処理時間超過、画像ライブラリの失敗など、実際に出た記録を優先します。
公式の
wp_create_image_subsizes()
資料からも、WordPressはアップロードされた画像を基に複数サイズを生成することが分かります。原本の保存と、各サイズの生成を分けて考えることが、無駄な設定変更を避ける近道です。
画像最適化プラグインの更新後から失敗した場合だけ、一つずつ戻す
画像圧縮、WebP変換、メディア整理のプラグインは、アップロード後の画像生成へ関わることがあります。ただし、すべてを一度に停止すると、どれが原因だったか分からなくなります。
- エラーが始まる直前に更新・追加したプラグインを確認する
- 最初は画像処理に直接関わる一つだけを停止する
- 同じ小さいテスト画像を一回追加する
- メディアライブラリに原本とサムネイルが残ったか、成功・失敗の時刻と一緒に記録する
- 変化がなければ元へ戻してから次の一つを調べる
本番サイトで停止の影響が大きいプラグインは、利用者が少ない時間を選ぶか、ステージング環境で確認します。同じ小さい画像がプラグイン停止後だけサムネイル生成まで進めば、そのプラグインの画像変換設定、対応形式、更新履歴を確認します。変化がなければ停止したままにせず、元へ戻してサーバーログの確認へ進みます。
画像圧縮とWebP変換とセキュリティの三つが、どれも画像に関係ありそうです。まとめて止めれば早い気もしますが、公開中のサイトなので少し怖いです。
三つとも気になると、まとめて確かめたくなるよね。でも一度に止めると、直っても原因が分からなくなるんだ。最初は、画像圧縮かWebP変換のうち、エラーが出始める直前に更新した方を一つだけ見よう。
一つ止めて変わらなかったら、そのまま次も止めるのではなく、先に元へ戻すんですね。どれが動いていた状態か分からなくなりそうだったので、順番をメモしておきます。
元へ戻してから次を見る、と決めておけば迷いにくいね。停止した名前、時刻、小さい画像の結果を一行ずつ残そう。セキュリティだけは長く止めたままにせず、判断できなければそこで中断して大丈夫だよ。
原因が分かった後の直し方を分ける
確認結果と関係のない設定を増やさず、該当した原因だけを直します。
PHPメモリ不足がログに出た場合
Allowed memory size exhausted
などが発生時刻のログにある場合は、契約サーバーのPHP設定画面で
memory_limit
の変更可否を確認します。画像の送信が完了しているのに
upload_max_filesize
だけを増やしても、サブサイズ生成のメモリ不足は直りません。管理画面に正式な変更機能がない場合、
.htaccess
へ推測で追記せず、ログを添えてサーバーへ依頼します。
GD・Imagickのエラーが出た場合
サイトヘルスにライブラリ名があるだけでは正常とは限りません。発生時刻のログに画像ライブラリの例外がある、対応形式が欠けている、PHPバージョン変更直後から始まった場合は、直前のPHPバージョンへ戻して同じテスト画像を一度試します。自分で拡張機能を追加できない共用サーバーでは、必要な画像形式とログを窓口へ伝えます。
元画像はあるがサムネイルだけ欠ける場合
PHPまたはプラグインの原因を直した後、既存の失敗画像には縮小画像が自動で戻らないことがあります。まず新しいテスト画像でサムネイル生成が成功することを確認し、その後にサムネイル再生成機能を使います。原因修正前に一括再生成すると、同じ失敗を大量に繰り返すため順番を逆にしません。
書き込みや所有者の問題が疑われる場合
本記事の文言ではなく『アップロードしたファイルを移動できませんでした』が出る場合は別症状です。uploadsへ推測で777を設定せず、対象ドメインの公開フォルダー、年・月フォルダー、所有者をサーバー窓口で確認します。
自力で直らない時は、エラー全文、発生日時、WordPress・PHPのバージョン、画像の形式・縦横px・容量、メディアライブラリへ残った状態、GD・Imagick、発生時刻のログをまとめます。管理画面のパスワードは問い合わせ本文へ書きません。
直ったと判断するにはサムネイルと公開画面まで見る
アップロードの進捗表示が100%になっただけでは完了ではありません。「メディア」→「ライブラリ」で画像を開き、画像が灰色でないこと、縦横サイズが表示されること、投稿の画像ブロックへ挿入できることを確認します。その投稿をプレビューし、別ブラウザとスマートフォン幅でも画像を表示します。
- テスト画像がメディアライブラリへ一件だけ登録された
- 一覧のサムネイルが表示された
- 画像の詳細で寸法とファイルURLを確認できた
- 画像ブロックへ挿入できた
- プレビューで代替テキストと画像が表示された
- 再読み込みしても画像が消えない
原因確認のために停止したプラグインや変更したPHP設定は、検証前の状態と比較します。直った後に複数の設定をさらに変更すると、次の不具合が起きた時に基準がなくなります。一つの変更で成功したなら、そこで止めて記録を残します。最後に『投稿編集画面で画像を選択／このエラーが表示／原本は残ったがサムネイルなし／画像処理プラグインを一つ戻したら生成成功』のように、発生から解決までを一行で残してください。
最初は2560という数字だけを見て、画像をもっと小さくするしかないと思っていました。今は、原本が残るか、サムネイルができるかを分けて見ればいいと分かって、少し落ち着きました。
数字に追い立てられず、原本とサムネイルを分けて見られたね。その見方があれば、必要のない設定まで触らずに済むよ。投稿へ挿入して、別ブラウザでも見えたところまで確かめよう。
一度直っても、次の写真でまた出たら少し慌てそうです。でも今度は『どの画面で画像を選んで、ライブラリのどこまで残ったか』を先にメモします。
また出ても、小さい一枚へ戻れば原因を探す出発点ができるよ。全部を一度に直そうとしなくていいんだ。迷った時は変更を止めて、エラー文と時刻をサーバー窓口へ渡そうね。
まとめ：画像を選んだ後の、どの段階で止まったかを直す
この記事の対象は、投稿編集画面またはメディアの新規追加で画像を選んだ後、『サーバーは画像を処理できません』と表示され、投稿へ挿入できない症状です。まずメディアライブラリで、添付ファイル登録前、元画像保存後、サムネイル生成後のどこまで進んだかを確認します。
特定画像だけなら正しい形式で再書き出し、すべての小さいJPEGで失敗するなら発生時刻のログ、PHPメモリ、GD・Imagickを確認します。画像最適化プラグインは直前の変更がある場合だけ一つずつ戻します。原因修正後に新しい画像でサムネイル生成まで成功してから、過去の不足サムネイルを再生成してください。
現在のサーバーで原因を確認できない場合の選択肢
一度の画像処理エラーだけでサーバーを移転する必要はありません。発生時刻と成功済み段階を伝えてもログ確認やPHP環境の案内を受けられず、同じ障害が繰り返す場合だけ、WordPress向けの管理情報と問い合わせ窓口を確認できる環境を候補にします。
エックスサーバー
発生時刻、PHPバージョン、画像の状態を整理しても現在のサーバーで原因確認を進められない場合に、WordPress向けの管理情報と問い合わせ先を比較する候補です。
向いている人： 同じ画像処理障害が繰り返し、現在の環境ではPHP情報やサポート窓口を確認しにくい人
利点： WordPressとPHPの運用情報を公式案内と照合しながら相談先を検討できる
不要な人： 現在のサーバーでログを確認でき、今回の原因を修正できた人
注意点： 画像エラーが一度出ただけで移転しないでください。移転前に現在の原因と、画像・メール・DNSの移行範囲を確認します。
料金： 契約期間やキャンペーンで変わるため、公式ページで最新条件を確認してください。
エックスサーバーのWordPress運用環境を確認する広告・PRを含みます。現在のサーバーで原因修正できる人には契約変更は不要です。移転はログ確認とサポート相談でも解決できない場合の選択肢として、公式の最新条件を確認してください。
よくある質問
2560px以下なら画像処理エラーは出ませんか？
出ることがあります。2560pxは大きな画像を縮小する既定しきい値で、ブラウザ、画像形式、GD・Imagick、メモリ、権限、通信遮断など別の原因もあります。
エラー後にメディアライブラリへ画像があれば成功ですか？
原本だけ保存され、サムネイル生成に失敗している場合があります。詳細画面、画像ブロックへの挿入、プレビュー表示まで確認してください。
最初にPHPメモリを増やしてもよいですか？
小さい画像、別ブラウザ、メディア画面でも再現し、ログやサイトヘルスからメモリ不足が疑われる時に検討します。複数設定を同時に変えないでください。
サーバーへ何を伝えれば調べてもらいやすいですか？
発生日時、エラー全文、画像の形式・寸法・容量、再現画面、原本の有無、WordPress・PHP、GD・Imagick、直前の更新をまとめて伝えます。