WordPress のアップロードフォルダーがこんなに大きい理由

WordPress のアップロードフォルダーが大きくなるのは、1枚の画像につき1ファイルだけを保存する仕組みではないからです。アップロードするたびに、元の画像とあわせて決まった数のリサイズ版が生成されます。カメラで撮った標準的なサイズの写真なら、テーマやプラグインが追加する分を除いても7枚です。ファイルが壊れているわけではありません。アップロードのたびに起きているこの「掛け算」を目にしているだけです。解決策は、実際には配信していないサイズの生成をやめ、そのうえで再生成して古いコピーをディスクから削除することです。

計算してみる

4000×3000 の JPEG を1枚アップロードして、/wp-content/uploads/2026/07/ の中を見てみてください。ファイルは1つではありません。次のものが見つかるはずです。

• photo.jpg — 元の画像、そのまま
• photo-scaled.jpg — 元の画像の代わりに配信される 2560px のコピー
• photo-150x150.jpg — thumbnail
• photo-300x225.jpg — medium
• photo-768x576.jpg — medium_large
• photo-1024x768.jpg — large
• photo-1536x1152.jpg — medium_large の2倍サイズ
• photo-2048x1536.jpg — large の2倍サイズ

コアだけでも、元の画像に加えて7枚の派生ファイルが生成されます。3 MB のアップロードが、プラグインを1つも動かさないうちにディスク上では 5〜6 MB になることもあります。ここに独自のサイズを4つ登録するテーマと WooCommerce（さらに3つ）を加えれば、1回のアップロードが14〜15ファイルになります。これを数千枚のライブラリで掛け算すれば、フォルダーサイズが大きい理由はもう謎ではありません。

自分の画像サイズと登録済みサイズでの正確な枚数を知りたい場合は、画像ストレージ計算ツールが代わりに計算してくれます。

なぜ起きるのか

アップロードすると、wp_generate_attachment_metadata() が wp_create_image_subsizes() を呼び出します。この関数は get_intermediate_image_sizes() が返すすべてのサイズをループ処理し、元画像がそのサイズを生成できるだけの大きさであれば、それぞれについてファイルを書き出します。コアは thumbnail、medium、medium_large、large に加えて、WP 5.3 で追加された 1536x1536 と 2048x2048 の Retina サイズを登録します。add_image_size() を呼び出すテーマやプラグインは、この同じループに追加されます。しかも、今後のすべてのアップロードに対して恒久的にです。

-scaled ファイルは別の仕組みから生まれます。big_image_size_threshold フィルター（デフォルト 2560px）です。これより横幅が大きい画像はスケール版のコピーが作られ、それが配信される「フルサイズ」画像になります。一方で元の画像はディスク上に残ります。つまり大きな画像をアップロードすると、巨大な元画像と 2560px 版の両方が保持されるのです。

特定の画像に対して自分の環境が何を生成するかは、画像サイズ確認ツールで正確に確認できます。

直し方（この順番で）

1. 何かに手をつける前に、まず計測する。 当て推量は時間の無駄です。サイトのルートから実行します。

du -sh wp-content/uploads
find wp-content/uploads -type f \( -name '*.jpg' -o -name '*.webp' -o -name '*.png' \) | wc -l
du -ah wp-content/uploads | sort -rh | head -20

2. 配信していないサイズの登録を解除する。 ほとんどのテーマは 1536 と 2048 のサイズを出力しませんし、medium_large を使わないものも多くあります。これらを外しましょう。

// functions.php — stop generating sizes this site never outputs
add_action( 'init', function () {
    remove_image_size( '1536x1536' );
    remove_image_size( '2048x2048' );
} );

// Drop medium_large too, if your theme doesn't use the 768px size
add_filter( 'intermediate_image_sizes_advanced', function ( $sizes ) {
    unset( $sizes['medium_large'] );
    return $sizes;
} );

3. 再生成して古いコピーを削除する。 登録解除は今後の生成を止めるだけです。すでにディスク上にあるファイルは、再生成するまで残ります。

wp media regenerate --yes

最近の WP-CLI では、処理の過程で、もう登録されていないサイズのファイルを削除してくれます。代わりに Regenerate Thumbnails プラグインを使っている場合は、「delete unregistered sizes（登録されていないサイズを削除）」のオプションにチェックを入れてください。このチェックを入れないと、古いファイルは残ったままになります。

4. 孤立ファイルを探す。 テーマを切り替えても、古いテーマが登録していたサイズは決して掃除されません。投稿を削除しても、その派生ファイルが必ずしも消えるとは限りません。ステップ3のあとで du -sh が計算ツールの予測をまだ大きく上回っている場合、孤立ファイル（どの添付ファイルからも参照されていない、ディスク上のファイル）があるということです。

やってはいけないこと

「容量節約」のためにスケール画像を無効化しない。 -scaled ファイルは元画像より小さいのです。big_image_size_threshold をオフにしても何も削除されません。ただ WordPress が数メガバイトのフルサイズ元画像をすべての訪問者に配信するようになるだけです。これは帯域幅と画質に関する判断であって、ストレージの掃除ではありません。たいていはページの重さをかえって悪化させます。画像の自動生成を停止するツールは、それが本当に正しい選択となるのはどんな場合かを説明しています。アップロードフォルダーを小さくすることは、その理由には含まれません。

SFTP で uploads から直接ファイルを削除しない。 各添付ファイルのサブサイズ一覧は、その _wp_attachment_metadata に格納されています。手作業でファイルを削除すると参照が壊れ、しかも派生元の元画像を削除してしまうと、再生成ではそのサイズを再構築できません。元画像を削除すれば、その画像は完全に失われます。

フォルダーが縮むことを期待して、設定 → メディアで thumbnail / medium / large を 0 に設定しない。 サイズを 0 にしても今後の生成が止まるだけで、すでにディスク上にあるものには一切触れません。しかも UI からは medium_large、1536、2048、テーマやプラグインのサイズには手が届きません。それらはそもそもそこに表示されないからです。

データベースのせいにしない。 重い uploads フォルダーの正体は画像ファイルであり、DB であることはまずありません。テーブルを最適化しても、この数字は動きません。

それでも解決しない場合

再生成後もフォルダーが想定より大きい場合は、実際の画像サイズと登録済みサイズをストレージ計算ツールにかけ、その数値を du -sh wp-content/uploads と比べてください。差が大きければ、古いテーマや削除済みの投稿による孤立ファイルが原因です。コアのせいではなく、これ以上再生成しても直りません。差が小さければ、計算どおりというだけのことです。アップロード1回につき7ファイル以上、設計どおりに動いているのです。