ACQUA JOURNAL
WordPressで画像をアップロードできないとき|容量・形式・保存・画像処理の確認

WordPressで画像をアップロードできないときは、何度も同じファイルを送り直す前に、原本、エラー文言、登録された状態を確認します。ファイル容量、形式、保存先、画像サイズを作る処理など、止まる場所によって調べる対象が違います。
画像の差し替えが反映されない問題や、不要画像の削除とは分けて考えましょう。この記事では、企業の更新担当者が試せる比較と、制作担当やホストへ渡す情報を整理します。原因を調べるために防御や権限を一律に緩める必要はありません。
1. 原本と、失敗した条件を残す
画像を登録し直す前に、手元の原本を別に保存してください。ファイル名、拡張子、容量、縦横の大きさ、操作した画面、時刻、表示されたエラーを記録します。画像に顧客情報が含まれるなら、相談用の記録では隠します。

同じファイルだけ失敗するのか、すべての画像が失敗するのかも確認します。「記事の編集画面から追加」と「メディア一覧から追加」で違う場合は、どちらの操作で起きたかを書いてください。古い状態の画面を見ていることもあるため、未保存の文章を守ってから登録一覧を確認します。
| 記録する項目 | 役立つ理由 |
|---|---|
| エラーの文言と発生時刻 | 通信やサーバーの記録と照合できる |
| 形式、容量、縦横 | 送信制限と画像処理を比較できる |
| 失敗する操作と対象 | 編集画面固有か、登録全体かを分けられる |
| 同じ条件で正常な画像 | 違いを絞れる |
| 直前の変更 | 更新や設定の影響を候補にできる |
直前に設定を変えたからといって原因と断定しません。知らない投稿やファイルの増加もある場合は通常の画像登録を中断し、現在の管理者へ症状を伝えます。
2. 送信、ファイル保存、画像生成を分ける
画像登録は、一つの成功表示だけで終わる処理ではありません。ブラウザーから送信する、サーバーが保存する、WordPressが画像情報と表示用のサイズを作る、といった段階があります。画面にエラーが出ても、元ファイルや登録情報の一部が残っている場合があります。

WordPressのアップロード処理は、ファイルのエラー、サイズ、形式等を扱います。画像情報を作る処理では、サムネイルなどの中間サイズも生成します。転送が完了したことと、必要な画像サイズが作られたことを分けて調べてください。
通信の結果を確認する
制作担当は対象要求と応答を確認し、拒否、容量制限、サーバーエラー等を分けます。HTTPエラーだけで内部原因は確定できません。認証やWAFで止まった場合と、画像処理で失敗した場合では対応が違います。何度も再送して登録数を増やさず、現在の状態を読み戻しましょう。
登録一覧と元画像を確認する
メディア一覧に対象があるか、元画像が開けるか、必要な縮小画像が表示されるかを確認します。登録名が同じでも別ファイルの場合があるため、対象URLやIDを担当が照合します。原本を削除して状況を消す前に、調査資料を残してください。
3. 小さい画像で、容量と形式を比較する
更新担当者が行いやすいのは、原本を保管したうえで、同じ形式の小さい画像を用意して試すことです。無機密の検証用画像を使い、通常の公開記事へ不用意に挿入しない方法を選んでください。

小さい画像は登録できるのに、大きい画像が失敗するなら、容量制限や画像処理の負担を調べる手がかりになります。ただし、この結果だけでメモリ不足とは確定しません。形式が同じでも壊れたデータや特殊な符号化等の違いがあり得ます。
形式を変えて試す場合も、元の画像を残します。拡張子だけを書き換えても、実際の形式は変わりません。正しく読み込める編集ソフトで別ファイルとして書き出し、画質、透過、色が必要な用途に合うか確認してください。すべてをJPEGへ変える、SVGを一律に許可する、といった対応は避けます。
登録できた画像は、記事中の表示と必要なサイズを確かめます。ファイルが小さいこと自体が目的ではなく、必要な写真や文字を読者が判断できることが大切です。
4. WordPress、PHP、ホストの制限を照合する
管理画面に見える上限だけで、通過するすべての制限は分かりません。一つのファイルの上限、送信要求全体の上限、ホストや防御機能の制限を担当が照合します。複数ファイルを送る場合は、その合計も関係します。

PHPの設定説明では、upload_max_filesizeとpost_max_sizeを別に扱います。アップロードのエラー定数にも、容量超過、部分送信、一時保存先の不足、ディスクへの書込み失敗などがあります。実際の応答と記録を確認し、似たエラー文言を一つの原因へまとめません。
| 確認する制限 | 確認する人と内容 |
|---|---|
| WordPress側 | サイトや追加機能で許可する形式と容量 |
| PHP側 | 一ファイルと要求全体の上限、実行環境 |
| ホスト側 | 利用プラン、書込み先、空き容量、操作可否 |
| 防御や中継 | 当該要求への拒否、別の受付制限 |
上限を上げるなら、業務に必要な画像条件とサーバーの制約を確認します。数値を無制限にする、メモリ値だけを上げ続ける、すべての制限を外す対応は、原因確認の代わりになりません。共有ホストで変更できない条件もあるため、正式な管理先へ対象と時刻を添えて相談します。
5. 書込みと画像生成の環境を調べる
保存先へ書き込めない問題と、保存後に画像を加工できない問題を分けます。制作担当は、ディレクトリの所有者や必要権限、空き容量、一時保存先、画像処理に使う環境の対応を、ホストの仕様と実際の記録から確認します。

保存先の権限は必要範囲で確認する
すべてのフォルダーを777へ変えるような操作は避けてください。必要な所有者と権限は環境で異なります。変更前の値と戻し方を残し、対象の書込みだけを検証します。ホスト側の制約なら、自社で触れるWordPress設定だけで解決しようとしません。
派生画像が作られたかを見る
元画像はあるのに一覧の縮小画像が欠ける、特定サイズだけ表示されない場合は、画像生成の状態も調べます。必要なサイズと登録情報を担当が確認し、再生成するなら対象と保存を決めて試します。古い派生ファイルを、不要と決めて一括削除しないでください。
フォームの受付や注文が動いているサイトでは、画像の問題だけを理由にDB全体を古い状態へ戻さないことも大切です。バックアップの取得対象と復元条件を確認し、影響の小さい修正方法を選びます。
6. 修正後は登録、重複、公開表示まで確認する
同じ条件の検証用画像で、登録が完了すること、元画像と必要なサイズが開けること、管理画面に正しい情報が残ることを確かめます。再送で重複が増えていないかも記録してください。

公開ページで画像が表示されても、別の古い画像を参照している場合があります。実際の画像URL、代替テキスト、スマホとPCの表示を確認します。登録成功と差し替えの反映は別の問題です。以前の画像のままなら、画像差し替えが反映されないときの確認を行います。
不要画像の整理は、この登録不具合が収束してから別に判断します。公開中の参照先を調べずに削除すると、記事や共通部品へ影響し得ます。未添付画像の使用先と派生画像の確認も、削除前の確認として参照してください。
7. Acquaへ渡す情報と、依頼する作業
自社で行う比較の結果をまとめれば、外部へ任せる範囲を小さくできます。相談にはサイトURL、登録する画面、エラーと時刻、画像条件、登録済みか、現在の管理先をそろえてください。最初の問い合わせへパスワードや顧客原本を貼らないでください。

企業のWeb運用支援では、更新担当者が止まっている操作、必要な画像の用途、修正後の確認方法を相談できます。制作会社向けの実装支援では、アップロード要求、テーマの画像サイズ、追加コード、ホストへの確認事項と検収範囲を整理します。
調査、修正、ホスト側の対応、再生成の可否、必要な権限、費用は実際の構成を確認して決めます。すべての環境へ同じ操作を約束しません。Acquaの相談窓口へは、機密情報を含めない概要から相談してください。
8. 次の担当も画像更新を続けられる状態にする
完了は、エラーが消えたことだけではありません。必要な画像を登録し、公開ページで正しく表示し、原本を残し、次の担当が使える条件と手順を分かる状態にします。

使える形式や必要な画像の大きさ、ホスト側に残る制限、異常時の連絡先を記録します。画像選びと原稿更新にかかる時間、やり直しの回数は実測し、工数と品質を別に評価してください。登録の成功件数を、相談や売上の成果へ置き換えません。
参考にした一次資料: