WordPressで記事を書いている途中に画像を追加しようとして、「アップロード中にエラーが発生しました」「このファイルをアップロードする権限がありません」「HTTPエラー」などと表示されることがあります。昨日まで使えていたのに急に失敗すると、画像ファイルが壊れたのか、WordPressそのものに問題が起きたのか分からず不安になるものです。
ただし、画像をアップロードできない原因は一つではありません。画像の形式や容量といった手元のファイルに原因がある場合もあれば、ブラウザ、プラグイン、PHPの設定、サーバーの空き容量、uploadsフォルダの所有者や権限など、サイト側の環境が影響している場合もあります。原因を確認せずに設定を大きく変更すると、別の不具合やセキュリティ低下を招くおそれがあります。
この記事では、WordPress初心者でも安全に試せる順番で、画像アップロードエラーの切り分け方を解説します。自分で対応できる範囲、レンタルサーバー会社へ確認する範囲、WordPress制作者や保守担当者へ依頼した方がよい範囲も整理します。公開中のサイトを守りながら復旧するため、エラー表示を記録し、影響の小さい確認から進めましょう。
画像をアップロードできないときは原因を分けて考える
WordPressの画像アップロードでは、ブラウザから送信されたファイルをPHPが受け取り、WordPressが内容を確認し、サーバー上のuploadsフォルダへ保存します。画像の場合は、必要に応じて複数サイズの画像も生成され、メディアライブラリに登録されます。この流れのどこか一つでも止まると、画面上では似たようなエラーに見えることがあります。
原因は大きく、画像ファイル、ブラウザや通信、WordPress、PHPやWebサーバー、保存先の権限や容量に分けられます。最初からサーバー設定を変更するのではなく、「その画像だけ失敗するのか」「すべての画像で失敗するのか」「別の管理者でも同じか」を確認すると、調査範囲を早く絞れます。
特定の画像だけ失敗する場合
一つの画像だけ失敗し、ほかの小さなJPEGやPNGは登録できるなら、ファイル形式、ファイル名、容量、画像の縦横サイズ、ファイル破損などが疑われます。サイト全体の設定を触る前に、画像を別名で保存し直す、一般的な形式へ変換する、適切な大きさへ縮小するといった手元で戻せる対処を試します。
すべての画像で失敗する場合
小さな画像を含めて何を選んでも失敗する場合は、ログインユーザーの権限、プラグインやセキュリティ機能、PHPのアップロード設定、サーバー容量、uploadsフォルダの書き込み権限など、サイト側の問題である可能性が高まります。直前にWordPress本体、テーマ、プラグイン、PHPバージョン、サーバー設定を変更していないかも確認します。
時間帯や通信環境によって失敗する場合
同じ画像が成功したり失敗したりするなら、通信の不安定さ、サーバー負荷、セキュリティサービスによる一時的な制限、タイムアウトなども候補になります。短時間に何度も再送すると制限を強めることがあるため、エラー時刻を記録し、少し間隔を空けて一度だけ再確認します。
最初に記録しておきたい情報
対処を始める前に、画面に表示された文章をそのまま記録します。「HTTPエラー」だけなのか、「サーバーが画像を処理できません」「アップロードしたファイルを移動できません」のような説明があるのかで、疑う場所が変わります。可能ならエラーが見える画面を保存し、発生日時も控えます。
対象画像のファイル名、拡張子、ファイル容量、ピクセル寸法も確認します。さらに、直前に行った更新や設定変更、利用中の端末とブラウザ、同じ操作をしたユーザー権限を記録します。この情報があると、自分での切り分けだけでなく、サーバー会社や制作者へ相談するときも往復を減らせます。
- 表示されたエラー文と発生日時
- 画像のファイル名、形式、容量、縦横サイズ
- 一つの画像だけか、すべての画像か
- メディアライブラリと投稿編集画面のどちらで失敗するか
- 直前に更新・追加・設定変更したもの
- 利用端末、ブラウザ、ログインユーザーの権限
安全な順番で試す復旧手順
ここからは、影響が小さく元に戻しやすい順番で確認します。途中でアップロードできるようになったら、そこで一度止めます。複数の設定を同時に変えると、何が原因だったのか分からなくなり、再発防止も難しくなります。
小さなテスト画像を一枚だけ試す
まず、一般的なJPEGまたはPNG形式で、容量と縦横サイズが小さい画像を一枚用意します。個人情報や未公開情報を含まないテスト用画像にします。WordPressの「メディア」から「新規メディアファイルを追加」を開き、一枚だけアップロードします。
WordPress公式のメディア追加画面の説明では、通常の複数ファイルアップローダーが機能しない場合にブラウザーアップローダーを使う方法と、画面にホスティング環境の最大アップロードサイズが表示されることが案内されています。利用中の画面に切り替え手段がある場合は、一度試す価値があります。
小さなテスト画像が成功すれば、WordPress全体が完全にアップロード不能ではありません。元画像の形式、容量、寸法、名前に調査を絞れます。小さな画像も失敗するなら、ブラウザ、権限、WordPress、サーバー側へ確認範囲を広げます。
画像ファイル名を半角英数字へ変更する
日本語のファイル名が必ず失敗するわけではありませんが、サーバー、外部ストレージ、セキュリティ機能、連携プラグインの組み合わせによっては扱いに差が出ることがあります。原因切り分けでは、半角英数字とハイフンだけの短い名前に変えて試します。たとえば「店内写真 最終版.jpg」ではなく「shop-interior-01.jpg」のようにします。
拡張子だけを書き換えても画像形式は変換されません。PNGをJPEGとして使いたい場合は、画像編集ソフトの書き出し機能で変換します。ファイル名変更後に成功した場合も、元ファイルを消さず、どの名前で登録したか記録しておくと管理しやすくなります。
対応しやすい画像形式で保存し直す
撮影機器や編集アプリ独自の形式、途中で壊れたファイル、拡張子と実体が一致しないファイルは失敗の原因になります。一般的なJPEG、PNG、WebPなどへ正しく書き出し直し、ファイルを端末上で開けることを確認します。公式の画像とファイル添付の説明でも、メディアは管理画面からアップロードされ、保存にはwp-contentディレクトリの適切な権限が必要になる場合があると説明されています。
透明部分が不要な写真はJPEG、透明背景や輪郭のはっきりした図はPNG、軽量化を重視する場合はWebPというように、用途に合う形式を選びます。ただし、形式変換だけで画質を過度に落とさないよう、元画像は別に保管します。
容量とピクセル寸法を小さくする
画像のファイル容量がサーバーの上限を超えていると、WordPressへ渡る前にアップロードが拒否されます。管理画面に表示される最大アップロードサイズを確認し、画像をその上限より十分小さくします。上限ぎりぎりでは、通信や処理時の負荷で失敗する場合があるため、Web掲載に必要な範囲まで適切に縮小・圧縮します。
ファイル容量だけでなく、非常に大きなピクセル寸法の画像は、サムネイル生成時に多くのメモリを使います。高画素の写真をそのまま登録せず、実際の表示幅や将来の高解像度表示を考えて適切な寸法へ書き出します。公開用途より大きな原本は、WordPressではなく別の安全な保存場所で管理します。
ブラウザを切り替えて再ログインする
キャッシュ、拡張機能、Cookie、ログインセッションの状態が影響することもあります。まず編集内容を下書き保存し、WordPressからログアウトして再ログインします。プライベートブラウズまたは別の最新ブラウザで同じ小さなテスト画像を試し、結果を比較します。
別ブラウザで成功するなら、サイト全体を変更する前に、元のブラウザのキャッシュや拡張機能を一つずつ確認します。広告ブロック、セキュリティ、翻訳、通信を監視する拡張機能などが管理画面のリクエストへ影響することがあります。拡張機能をすべて無効にしたまま運用するのではなく、原因を特定して必要性を判断します。
利用者の権限を確認する
WordPressではユーザーの役割によって、メディアをアップロードできるかが変わります。以前できていた利用者だけが失敗する場合は、役割が変更されていないか、権限管理プラグインで制限されていないかを管理者が確認します。管理者アカウントを共有して試すのではなく、正規の個別アカウントで確認します。
権限の問題を解消するために、必要以上に全員を管理者へ変更するのは避けます。記事作成に必要な権限とサイト設定を変更できる権限は分け、最小限の権限で運用する方が安全です。
WordPressとプラグインを切り分ける
ファイルとブラウザに問題が見当たらない場合は、WordPress内の処理を確認します。画像最適化、WebP変換、セキュリティ、ファイアウォール、外部ストレージ連携、CDNなどのプラグインはアップロード処理に関係することがあります。ただし、公開サイトで無計画に停止すると、表示やセキュリティへ影響する可能性があります。
サイトヘルスの情報を確認する
管理画面の「ツール」から「サイトヘルス」を開き、ステータスと情報を確認します。公式のサイトヘルス画面の説明では、ファイルアップロードが無効になっている状態、メディア処理、サーバー情報、ディレクトリと容量、ファイルシステム権限などを確認できると案内されています。
表示内容は相談時に役立ちますが、サイトヘルス情報にはサーバー構成などの技術情報が含まれます。不特定多数が見られる場所へそのまま公開せず、信頼できるサーバー会社や担当者へ必要な範囲だけ共有します。
直前の更新や変更を確認する
エラーが始まった日時と、WordPress本体、テーマ、プラグイン、PHPの更新日時を照合します。更新直後なら関連は疑えますが、時間が近いだけで原因と決めつけないことが大切です。更新を戻す場合は、復元可能なバックアップと手順が必要です。
公開サイトでプラグインを停止して確認するなら、ステージング環境を使うのが安全です。ステージング環境がない場合は、サイトの利用が少ない時間帯を選び、影響、作業前の状態、戻し方を記録したうえで、一つずつ確認します。EC、予約、会員、フォームなど重要機能があるサイトでは、自己判断の停止より保守担当者への依頼が適しています。
画像関連とセキュリティ関連の機能を確認する
画像圧縮や形式変換の機能が失敗していると、アップロード自体は進んでも最終処理でエラーになることがあります。外部APIの障害、利用量上限、認証切れ、保存先の設定変更なども確認対象です。セキュリティ機能では、ファイル形式、ファイル名、リクエストサイズ、アクセス元、短時間の連続操作が制限される場合があります。
原因調査のために保護機能を止めるときは、対象と時間を限定し、確認後に必ず元へ戻します。停止前後の状態を記録できない場合は、担当者へ依頼した方が安全です。
サーバー側で確認する項目
すべての小さな画像が複数のブラウザで失敗し、ユーザー権限やWordPress内の変更でも説明できない場合は、サーバー側の確認が必要です。レンタルサーバーの管理画面やサポートで確認できる項目もありますが、設定名や変更方法はサービスによって異なります。
PHPのアップロード設定
画像のアップロードにはPHPが使われます。公式のPHP最適化の説明では、管理画面からメディアを登録するときにPHPがアップロードを処理し、個別ファイルの上限はupload_max_filesizeで設定されると説明されています。ほかにもリクエスト全体の上限、実行時間、メモリなどが関係する場合があります。
設定値は大きければよいわけではありません。サーバープランや運用方針に合わない値へ変更すると、負荷やセキュリティ上の問題につながる可能性があります。まず現在値とエラーを確認し、レンタルサーバーの公式手順に従うか、サポートへ相談します。
サーバーの空き容量と契約上限
サーバーのディスク容量やファイル数の上限に達すると、新しい画像を保存できません。画像そのものだけでなく、WordPressが生成する複数サイズ、バックアップ、キャッシュ、ログ、メールなども容量を使います。管理画面で使用量を確認し、急増している項目がないか調べます。
容量を空けるために、内容が分からないファイルを直接削除してはいけません。特にuploads、データベース、バックアップ、テーマ、プラグインのファイルはサイト運営に必要な可能性があります。不要と確認できるキャッシュや古いバックアップも、保持方針と復元可能性を確認してから整理します。
uploadsフォルダの所有者と書き込み権限
WordPressが保存先へ書き込めないと、「アップロードしたファイルを移動できません」といったエラーにつながります。公式のファイル権限の説明では、WordPressが書き込みを必要とする場所は、WordPressを動かすユーザーが所有するか、適切なグループ所有と書き込み権限が必要であり、環境によって設定が異なるとされています。
注意したいのは、解決策として無条件に777へ変更しないことです。誰でも書き込める設定は攻撃リスクを高めます。共有サーバー、PHP-FPM、専用サーバーなどで適切な所有者と権限は異なるため、サーバー会社の案内か管理者の判断に従います。
WAFやCDNなどの制限
Webアプリケーションファイアウォール、CDN、リバースプロキシ、外部ストレージなどがアップロード通信を検査・中継している場合、サイズや通信内容によって拒否されることがあります。エラー時刻を控え、サーバーやサービスのログで該当リクエストが遮断されていないか確認します。
WAFを恒久的に無効にするのではなく、該当ルールと安全な例外設定を特定することが重要です。自分でログを確認できない場合は、エラー時刻、操作URL、対象ファイルの種類と容量を添えてサポートへ問い合わせます。
サーバーログとWordPressのデバッグ情報
管理画面のメッセージだけでは原因が分からない場合、PHPエラーログ、Webサーバーログ、セキュリティログに具体的な記録が残ることがあります。ログにはサーバー内のパス、利用者情報、リクエスト情報が含まれる場合があるため、公開場所へ貼り付けず、必要な部分を担当者と安全に共有します。
本番サイトで画面へのエラー表示を有効にすると、訪問者へ内部情報を見せてしまうおそれがあります。デバッグが必要な場合は、表示ではなく安全なログ記録を使い、調査後に設定を戻します。設定ファイルを直接編集する作業に慣れていなければ、制作者または保守担当者へ依頼します。
エラーメッセージ別の考え方
表示される文言は環境や失敗箇所によって異なりますが、調査の入口になります。文言だけで原因を断定せず、テスト画像と発生範囲の結果を組み合わせて判断します。
HTTPエラーと表示される
HTTPエラーは幅広い失敗をまとめて示している可能性があります。大きな画像だけか、小さな画像も失敗するかを最初に比較します。次に別ブラウザ、メディア追加画面、直前のプラグイン更新、PHP上限、サーバーログを順に確認します。何度も同じファイルを連続送信するのは避けます。
サーバーが画像を処理できないと表示される
画像のリサイズやサムネイル生成で処理が止まっている可能性があります。画像を適切な寸法へ縮小して保存し直し、JPEGやPNGなどで小さなテストを行います。すべての画像で再現する場合は、PHPメモリ、画像処理ライブラリ、サーバー負荷、画像最適化機能などを担当者が確認します。
ファイルを移動できないと表示される
一時保存されたファイルをuploadsフォルダへ移せない状態が考えられます。サーバー容量、uploadsフォルダの存在、所有者、権限、保存先設定を確認します。権限値だけを広げて解決しようとせず、なぜ書き込めなくなったのかを確認します。移行や復元の直後なら、所有者が以前の環境のままになっていないかも調査対象です。
ファイル形式や権限に関するエラーが出る
拡張子と実際の形式が一致しているか、一般的な画像形式であるか、ユーザーにアップロード権限があるかを確認します。許可されていない形式をコードで無理に追加する前に、そのファイルをWebサイトへ置く必要性と安全性を判断します。画像であれば、対応しやすい形式へ正しく変換する方が安全なことが多いです。
やってはいけない対処
急いで画像を入れたいときほど、影響の大きい変更を避ける必要があります。次の対処は、原因を隠したり新しい事故を招いたりする可能性があります。
- uploadsフォルダを理由なく777へ変更する
- バックアップなしでwp-config.phpやphp.iniを編集する
- 複数のプラグインを同時に停止・削除する
- 公開サイトでデバッグ情報を訪問者へ表示する
- 原因不明のままサーバー内のファイルを大量削除する
- 出所不明のコードをfunctions.phpへ貼り付ける
- 管理者アカウントやパスワードを共有する
一時的にアップロードできるようになっても、セキュリティ機能を止めたまま、権限を広げたまま、上限を過大にしたままでは安全な復旧とはいえません。原因を特定し、必要最小限の設定へ戻し、同じテスト画像で再確認して完了とします。
自分で対応できる範囲
初心者でも比較的安全に行いやすいのは、画像の情報確認、ファイル名変更、形式の正しい変換、縮小・圧縮、別ブラウザでの確認、再ログイン、サイトヘルスの閲覧、サーバー管理画面での使用量確認です。いずれも元画像や現在の設定を残し、結果を記録しながら一つずつ行います。
プラグイン停止も操作自体は簡単ですが、公開サイトの機能へ影響します。ステージング環境と復元手段があり、影響範囲を理解できる場合に限って行います。事業用サイト、EC、予約、会員サイト、広告運用中のランディングページなどは、停止時間の損失が大きいため、早めに専門家へ相談する方が結果的に効率的です。
レンタルサーバー会社へ相談するケース
サーバー会社は、契約上限、PHP設定、ディスクやファイル数、WAF、障害情報、サーバーログ、所有者や権限など、ホスティング環境に近い情報を確認できます。次のような場合は、まずサーバー会社のサポート対象か確認します。
- 小さな画像を含むすべてのアップロードが失敗する
- 最大アップロードサイズやPHP設定の変更方法が分からない
- ディスク容量やファイル数の上限に近い
- WAFを有効にした時間とエラー開始が一致する
- uploadsフォルダの所有者や権限が正しいか判断できない
- 同じサーバー内の複数サイトで同時に問題が起きた
問い合わせには、サイトURL、発生日時、正確なエラー文、対象ファイルの形式・容量・寸法、小さなテスト画像でも再現するか、直前の変更、試した内容を添えます。パスワードや秘密鍵を通常の問い合わせ文へ書かないよう注意します。
WordPress制作者や保守担当者へ依頼するケース
WordPress側のプラグイン競合、テーマ独自処理、外部ストレージ連携、CDN、画像最適化、独自コード、データベース登録、複数環境の差分などは、制作・保守担当者が調査しやすい領域です。サーバー会社から「サーバーに異常はない」と案内された場合も、WordPress側の切り分けが必要になります。
- 重要な公開サイトでプラグイン停止を安全に試せない
- 更新後から発生し、戻し方が分からない
- メディアライブラリには入るが画像生成や記事保存で失敗する
- 外部ストレージ、CDN、画像変換サービスを利用している
- PHPエラーや独自コードのエラーが記録されている
- 一度直っても同じ問題が繰り返す
依頼時は「画像アップロードを直してほしい」だけでなく、再現手順と調査済みの内容を伝えます。原因調査、復旧、再発防止、作業後確認のどこまでが依頼範囲かを確認すると、見積もりや作業内容を比較しやすくなります。
依頼先を選ぶときの比較ポイント
画像アップロードの不具合は、サーバーとWordPressの境界で起きることがあります。そのため、単に設定を変更するだけでなく、変更前の記録、バックアップ、原因の説明、元に戻す手順、作業後の確認まで対応できる依頼先が安心です。
調査範囲が明確か
ファイル、ブラウザ、ユーザー権限、WordPress、プラグイン、PHP、ディスク、権限、WAF、ログのどこまで確認するかを聞きます。最初から原因を一つに決めつけるのではなく、再現条件を確認して切り分ける説明があるかが重要です。
本番サイトを守る手順があるか
作業前バックアップ、ステージング環境、メンテナンスの要否、変更記録、復旧手順を確認します。ECや予約サイトでは、注文や予約データが増え続けるため、単純な全体復元ができない場合があります。運用中のデータをどう守るかを具体的に説明できる依頼先を選びます。
原因と再発防止を説明してくれるか
一時的に権限を広げたり、プラグインを止めたりして終わるのではなく、原因、変更した設定、適正な最終状態、今後の画像作成ルール、監視や保守の必要性まで説明してもらいます。担当者が変わっても分かる作業記録が残ると、次回の対応が速くなります。
費用の範囲が分かるか
不具合調査は、原因が分かるまで作業量が確定しにくいことがあります。初期調査費、修正費、サーバー会社との連絡、バックアップ、緊急対応、時間外対応、再発時の保証がどこまで含まれるかを確認します。安さだけでなく、サイト停止時の機会損失と安全性を含めて判断します。
復旧後に確認すること
一枚登録できただけで完了にせず、実際の運用に近い条件で確認します。ただし大量アップロードはせず、代表的な画像を少数使います。メディアライブラリへの登録、サムネイル表示、記事への挿入、下書き保存、プレビュー、公開画面での表示まで確認します。
- 元画像と生成された各サイズが正常に表示される
- 画像URLが正しいドメインとパスになっている
- 記事編集画面で画像を選択・挿入できる
- 下書き保存やプレビューでエラーが起きない
- モバイル表示で画像がはみ出さない
- 一時的に変更した設定や停止した保護機能を戻した
- エラーログに同じ失敗が増えていない
さらに、画像の推奨形式、最大容量、推奨ピクセル寸法、ファイル名ルールを運用メモに残します。担当者が複数いる場合は同じルールを共有すると、同様のエラーや不必要に大きな画像の増加を防げます。
画像アップロードエラーを予防する運用
画像をWordPressへ入れる前に、用途に合う形式へ書き出し、必要な寸法へ縮小し、半角英数字の分かりやすいファイル名を付ける流れを標準化します。元画像は別の保管場所に残し、WordPressには公開用の画像を登録します。
WordPress本体、テーマ、プラグイン、PHPを定期的に更新し、更新前には復元できるバックアップを用意します。サーバー容量、バックアップ容量、ログ、キャッシュの増加も定期的に確認します。画像最適化や外部ストレージのサービスを使う場合は、契約上限や障害情報、認証状態も保守項目に含めます。
「誰が」「どのサイズまで」「どの形式で」「どこから」アップロードするかが決まっていると、問題が起きたときも正常時との差を見つけやすくなります。復旧手順だけでなく、日常の画像運用を整えることが再発防止につながります。
よくある質問
画像を小さくすると必ず直りますか
必ずではありません。大きな画像だけ失敗する場合は有効な切り分けですが、小さな画像も失敗するなら、権限、PHP、容量、プラグイン、サーバーなど別の原因を調べます。小さなテスト画像の結果が、次に確認する場所を決める材料になります。
アップロード上限を上げれば解決しますか
対象ファイルが上限を超えている場合は候補になりますが、処理メモリ、実行時間、サーバー容量、画像寸法、権限などが原因なら上限だけを上げても直りません。現在値とエラーを確認し、必要な範囲でサーバーの公式手順に従います。
uploadsフォルダを777にしてもよいですか
無条件には行わないでください。誰でも書き込める状態はセキュリティリスクを高めます。サーバー構成によって適切な所有者と権限が異なるため、レンタルサーバー会社または管理者へ確認し、必要最小限の設定にします。
プラグインを全部停止すれば原因が分かりますか
競合の切り分けには役立つ場合がありますが、公開サイトの表示、フォーム、決済、予約、セキュリティなどが止まる可能性があります。ステージング環境で一つずつ確認するのが安全です。本番で試す場合は、バックアップ、影響確認、戻し方が必要です。
メディアライブラリには入るのに記事へ挿入できません
アップロード自体は成功し、その後のエディター処理、権限、JavaScript、ブロック、プラグインなどで問題が起きている可能性があります。別ブラウザ、投稿編集画面とメディア画面の比較、ブラウザの開発者情報、プラグイン競合を確認します。公開サイトで安全に切り分けられない場合は制作者へ依頼します。
まとめ
WordPressで画像をアップロードできないときは、最初にエラー文と対象画像の情報を記録し、小さなJPEGまたはPNGを一枚だけ試します。特定の画像だけ失敗するなら、ファイル名、形式、容量、ピクセル寸法を確認します。すべての画像で失敗するなら、ブラウザ、ユーザー権限、サイトヘルス、直前の更新、プラグイン、PHP設定、サーバー容量、uploadsフォルダの所有者と権限へ順番に範囲を広げます。
権限を777へ変更する、複数のプラグインを同時に停止する、バックアップなしで設定ファイルを編集する、といった大きな変更は避けましょう。サーバー設定やログが関係する場合はレンタルサーバー会社へ、WordPressの競合や独自機能が関係する場合は制作・保守担当者へ相談します。
復旧とは、画像が一度入った状態だけではありません。原因を説明でき、必要最小限の設定へ戻し、メディアライブラリ、記事挿入、下書き、プレビュー、公開画面を確認できた状態が安全な完了です。日常の画像形式、容量、寸法、ファイル名のルールも整え、同じトラブルを起こしにくい運用につなげてください。
