WordPressで画像アップロード、記事保存、バックアップ、復元、外部ストレージ同期を行ったとき、「507 Insufficient Storage」が返ることがあります。容量を増やしたはずなのに保存できない、特定の連携先だけ507になる、といった症状です。
507は、処理を完了するために必要な表現をサーバーが保存できない状態です。ただし、WordPress画面の507が、必ず契約サーバーのディスク満杯を意味するわけではありません。別のクォータ、inode、データベース、バックアップ一時領域、外部保存先が原因の場合があります。
空きを作るために、確認せずバックアップ、画像、ログ、データベースを一括削除しないでください。削除対象を誤ると、復旧手段や公開コンテンツまで失います。保存先と使用量を特定してから整理します。
先に結論：507エラーは8段階で確認する
- 編集中の本文、アップロード元、バックアップ設定を退避する
- 保存・アップロード・バックアップの連打と自動再試行を止める
- URL、操作、時刻、対象サイズ、507、応答本文を記録する
- WordPress本体、ホスティング、DB、外部保存のどこが返したか特定する
- ディスク使用量、クォータ、inode、DB容量、一時領域を別々に確認する
- 不要と確認できたキャッシュ・一時ファイル・古い複製だけを整理する
- 必要なら契約容量や保存設計を見直し、一度だけ再実行する
- 保存結果、バックアップ、公開表示、監視、再発の有無を確認する
アップロードする要求本文自体が大きすぎる場合はWordPressの413 Content Too Largeを直す確認順、画像処理や権限を含む一般的な失敗はWordPressの画像アップロードエラーを直す手順へ切り替えてください。
507 Insufficient Storageとは？
RFC 4918の507 Insufficient Storageは、要求を成功させるために必要な表現をサーバーが保存できず、処理を実行できない状態です。この状態は一時的とされています。
利用者の操作によって507になった場合、RFCは、利用者が別の操作として改めて要求するまで自動的に繰り返してはいけないと定めています。バックアップや同期の無限再試行を止め、空きと保存先を確認する理由です。
507はWebDAVで定義されました。WordPressはステータス名を認識できますが、標準の画像アップロードや記事保存が容量不足時に必ず507を返すわけではありません。500、ディスク書き込みエラー、JSONエラー、プラグイン独自コードになる場合もあります。
そのため、507という番号だけで「uploadsフォルダが満杯」と決めません。保存先は、Webサーバーのディスク、アカウントクォータ、inode、データベース、バックアップ領域、外部APIなど複数あります。
413・500・507・509の違い
| 表示 | 主な意味 | 最初に見るもの |
|---|---|---|
| 413 Content Too Large | 送信する要求本文が大きすぎる | ファイルサイズ、POST本文、各層の受信上限 |
| 500 Internal Server Error | 処理中の予期しない問題 | PHP・サーバーログ、直前変更 |
| 507 Insufficient Storage | 完了に必要な表現を保存できない | 保存先、空き、クォータ、一時領域 |
| 509 Bandwidth Limit Exceeded | 一部サービスが使う転送量超過の非標準応答 | ホスティングの転送量・独自仕様 |
「容量」という言葉だけで413と507を混同しないでください。413は主に受信する要求の大きさ、507は処理後の状態を保存する能力の問題です。509は標準HTTPステータスではなく、提供元独自の意味を確認します。
WordPressで507が出る主な原因
1．ホスティングのディスク使用量が上限に達している
WordPress本体、テーマ、プラグイン、画像、キャッシュ、ログ、バックアップ、メールなどが同じ契約領域を使い、上限へ達する場合があります。uploadsだけを見ても、別ディレクトリの巨大なバックアップやログを見落とします。
コントロールパネルの契約容量と実使用量を確認し、どの領域が増えたかを調べます。表示が更新されるまで時間差があるサービスでは、実際の使用量と集計時刻も確認します。
2．容量は空いていてもinodeやファイル数の上限に達している
小さなキャッシュ、一時ファイル、セッション、縮小画像が大量に作られると、バイト容量に余裕があっても作成可能なファイル数へ達する場合があります。画面に「容量不足」とだけ表示されると見落としやすい原因です。
ホスティングがinodeやファイル数を表示する場合は別項目として確認します。キャッシュ生成の再帰、サムネイル増殖、バックアップの細分化がないかを調べます。
3．データベースの容量・一時領域・権限に問題がある
記事保存、設定変更、注文処理ではデータベースへ書き込みます。DBクォータ、テーブル肥大、一時領域不足、読み取り専用状態、ストレージ障害により保存できない場合があります。
サイトファイルの空きだけを見ず、データベースの使用量、エラーログ、提供元の障害情報を確認します。接続エラーも出る場合はWordPressのデータベース接続確立エラーを直す手順も使ってください。
4．バックアップや画像処理の一時領域が不足している
バックアップは、元データとは別にアーカイブと一時ファイルを作るため、完成サイズ以上の空きが必要になることがあります。画像最適化、展開、復元、動画変換も作業領域を使います。
処理途中の一時ファイルが残り、次の試行でさらに空きを消費する場合があります。ジョブ状態を確認し、進行中の処理を重ねず、公式のクリーンアップ手順を使います。
5．外部ストレージやWebDAV側のクォータが不足している
WordPressサーバーに空きがあっても、バックアップ先、メディア保存先、クラウドドライブ、WebDAV、S3互換サービスの契約上限に達している場合があります。外部サービスが507を返し、プラグインが管理画面へ表示します。
外部URL、バケット・フォルダ、アカウント、リージョン、クォータ、削除保留領域を確認します。ゴミ箱や版履歴が容量へ含まれるサービスもあるため、提供元の仕様を見ます。
6．キャッシュ・ログ・バックアップが増殖している
エラーログの急増、ページキャッシュの重複、日次バックアップの世代管理不備、サイト内へ保存したバックアップを次のバックアップが再び含める構成で、使用量が急増することがあります。
単に古い順に削除せず、保持方針、復元テスト済みの世代、外部保管の有無を確認します。直近の正常バックアップを失うと、障害復旧が難しくなります。
最初の10分で行う安全な初動
1．入力を退避し、自動再試行を止める
記事本文、商品情報、フォーム入力、アップロード元ファイルを安全な場所へ退避します。バックアップ、同期、画像最適化、インポートの自動再試行を一時停止し、新しい一時ファイルが増えないようにします。
停止操作自体が状態を変える場合は、現在のジョブID、開始時刻、対象、進捗を記録します。処理が完了間近なら、強制終了より提供元の手順を優先します。
2．失敗した保存先を特定する
Network欄とログで、507を返したURL、メソッド、外部ドメイン、応答本文、リクエストIDを確認します。WordPressのuploads、データベース、外部ストレージ、バックアップ先のどれへ保存していたかを分けます。
公開ページの閲覧も失敗するならサイト全体のサーバー状態、特定アップロードだけなら対象ファイルと一時領域、外部URLだけなら連携先を優先します。
3．空き容量と増加原因を同時に見る
総容量、使用量、空き、クォータ、inode・ファイル数、DB容量を記録します。現在値だけでなく、いつから何が増えたかを確認します。突然増えたログやキャッシュは、元のエラーやループが別に存在する手がかりです。
ファイル名やパスに個人情報・秘密が含まれる場合は、公開の相談先へ一覧を貼りません。容量、件数、更新時刻、種類を伏せ字で共有します。
どの保存先が507を返したか特定する
| 確認先 | 見るもの | 判断の手がかり |
|---|---|---|
| ホスティング | 総容量、クォータ、inode、メール領域 | 契約アカウント全体が上限か |
| WordPressファイル | uploads、cache、logs、upgrade、バックアップ | 急増したディレクトリがあるか |
| データベース | DB使用量、テーブル、一時領域、書き込みエラー | 記事保存や注文だけ失敗するか |
| 外部ストレージ | 外部URL、クォータ、版履歴、ゴミ箱 | WordPress側に空きがあっても失敗するか |
| 処理ジョブ | バックアップ、復元、最適化、同期の状態 | 一時ファイルや再試行が増えているか |
WordPress公式のwp_upload_bits()資料では、アップロード先の作成やファイル書き込みに失敗した場合、エラーとして扱う仕組みが確認できます。ただし、そのエラーが必ずHTTP 507になるとは限りません。
WordPressのアクセスログに507がなく、外部サービスのAPI URLが返しているなら、ローカル画像を削除する前に外部クォータを確認します。反対にサイト全体の書き込みが失敗するなら、ホスティングとDBを優先します。
原因別の安全な直し方
1．再生成できるキャッシュと一時ファイルだけを整理する
ページキャッシュ、処理途中の一時ファイル、失敗したアップデート展開物など、再生成可能で不要と確認できたものから整理します。利用中プラグインの公式消去機能を優先します。
cacheという名前だけで削除せず、対象プラグイン、現在のジョブ、復旧への影響を確認します。削除後は空きが増えたことと、異常な再生成が始まらないことを見ます。
2．ログの増加原因を直してから安全に世代整理する
巨大ログが原因なら、先に同じエラーを繰り返すプラグイン、PHP、外部連携を止めます。その後、必要な調査期間を保存し、ローテーション方針に沿って古いログを整理します。
ログを空にしても原因が残ればすぐ再発します。エラー頻度、最初の発生時刻、直前変更を記録してから整理してください。
3．バックアップは復元可能性を確認して世代整理する
ローカルに多数の完全バックアップがある場合は、保持方針、外部コピー、復元テスト済みの世代を確認します。最新の正常バックアップと障害直前の世代を保護し、重複や期限切れだけを削除します。
バックアップをサイト配下へ置き、次のバックアップがそのファイルを再び含む構成は見直します。外部保存と保持数を設定し、同じ領域を無制限に消費しないようにします。
4．画像とサムネイルは参照関係を確認して整理する
メディアライブラリで未使用に見えても、テーマ、CSS、OGP、商品、外部連携から参照される場合があります。一括削除前にバックアップを取り、公開ページとデータベースの参照を確認します。
不要な画像サイズが大量生成されるなら、テーマとプラグインが登録するサイズを見直します。既存画像の再生成は追加の作業領域を使うため、空きとテスト環境を確保してから行います。
5．DB肥大は原因別に保守する
リビジョン、期限切れ一時データ、ジョブ履歴、プラグイン独自テーブルなど、増加元を特定します。テーブルを直接削除せず、プラグインの公式保守機能、バックアップ、テスト環境を使います。
データベース最適化を複数ツールで同時実行しません。注文、会員、フォーム、分析データには保持義務や業務上の必要性がある場合があります。
6．必要量が継続的に不足するなら容量と保存設計を見直す
不要データを整理しても通常運用で不足する場合は、ホスティングプラン、外部ストレージ、バックアップ保持、ログローテーション、メディア配信を見直します。現在の増加量と必要な余裕を基に判断します。
プラン変更前に、何の上限が不足したかを確認します。ディスク容量を増やしても、inode、DBクォータ、外部保存先が原因なら解決しません。
本番の削除やDB保守前にはWordPress更新前のバックアップ手順とWordPressのテスト環境を作る手順を使い、戻せる状態で検証してください。
やってはいけない対処
- 空きを作るためバックアップを全削除する
- uploads、データベース、ログをまとめて消す
- 未使用表示だけを信じて画像を一括削除する
- 保存・バックアップ・同期を何度も再試行する
- 容量、inode、DB、外部クォータを同じものとして扱う
- 原因を直さずログやキャッシュだけを繰り返し消す
- 複数の最適化・DB保守ツールを同時実行する
- 必要な空き量を確認せず本番で復元・再生成を始める
復旧後の確認チェックリスト
- 記事保存、画像アップロード、更新が一度で完了する
- バックアップが正常に完了し復元用ファイルが存在する
- WordPress、DB、外部保存先の空きに安全な余裕がある
- inode・ファイル数が上限へ近づいていない
- キャッシュ、ログ、一時ファイルが異常増加しない
- バックアップが自分自身を再び含んでいない
- 公開画像、添付ファイル、商品データが欠けていない
- DB保守後も投稿、注文、会員、フォームが正常である
- 自動再試行が無限ループになっていない
- 容量監視と通知が有効になっている
公開URLが507や別の5xxを返し続けると、読者と検索クローラーが本文を取得できません。GoogleのHTTPステータスコード解説に沿って、主要公開ページが200を返すことも確認します。
自力で直せないときに伝える情報
- 発生日時、対象URL、操作、HTTPメソッド
- 保存対象の種類と概算サイズ
- 秘密値を伏せた507応答、リクエストID
- ホスティングの総容量、使用量、空き、クォータ
- inode・ファイル数、DB使用量
- 外部保存先のサービス、フォルダ、クォータ
- 進行中・失敗中のバックアップ、同期、最適化
- 急増したディレクトリやログの種類
- すでに整理した対象と結果
契約領域やDBならサーバー会社、プラグインの一時ファイルやバックアップなら開発元、外部URLの507なら保存サービスへ相談します。ファイル名やログに含まれる個人情報・認証情報は伏せてください。
よくある質問
507はディスク容量を増やせば必ず直りますか？
必ずではありません。inode、DBクォータ、一時領域、外部ストレージ、処理中ロックが原因なら、契約ディスクを増やしても解決しません。507を返した保存先と不足した資源を確認します。
キャッシュを削除してよいですか？
再生成可能なキャッシュと確認できれば候補です。ただし、cacheという名前だけで判断せず、進行中処理とプラグインの公式手順を確認します。削除後に異常増殖しないかも見ます。
507と画像の413は同じですか？
違います。413は送信する要求本文が上限を超えた状態、507は処理完了に必要な状態を保存できない状態です。ファイルサイズを小さくして直るか、保存先の空きが不足しているかを分けます。
まとめ
507 Insufficient Storageは、要求を完了するために必要な表現を保存できない状態です。WordPressでは、ホスティング容量、inode、DB、一時領域、バックアップ、外部ストレージを分けて確認します。
- 入力を退避し、自動再試行を止める
- 507を返した保存先を特定する
- 容量、クォータ、inode、DB、一時領域を別々に測る
- 再生成可能で不要なものだけを対象限定で整理する
- バックアップと公開データを守る
- 通常運用に必要な余裕と監視を整える
507では、慌てて大量削除するより、どの保存先の何が不足したかを測り、復旧手段を残したまま必要な空きを作ることが最優先です。