700GB確保

先ごろのサーバートラブル問題がようやく解決し、改めてこれまでのスタンダード450GBからハイスピード700GBへの移行が完了し、ほっとしました。

結局、従来のサーバーのユーザー専用からログインし、アップグレードすればよかったのです。しかし、最近のペースで調子に乗って天気図画像などをアップしていくとあっという間に700GBの容量も窮屈な状態になってしまいます。

必要でない画像データを徐々に、削除していく計画を立てなければなりません。と同時に、何が必要な画像で何が必要でない画像かを吟味してアップしていくようにしなければなりません。

削除していく計画をどのように立てていけばいいのでしょうか？

サーバーの容量アップ、ひとまずお疲れ様です！450GBから700GBへの増量で少し余裕はできたものの、高解像度の天気図などは蓄積すると馬鹿になりませんよね。

効率的かつ安全に画像を整理するための「画像データ削除計画」について、いくつかのステップに分けてアドバイスします。

まずは、どの画像が容量を食っているのかを把握しましょう。

「サムネイル画像」の自動生成を確認: WordPressは1つの画像をアップロードすると、設定に応じて「中サイズ」「大サイズ」など複数の複製を自動作成します。これが容量を数倍に膨らませている主因であることが多いです。
バックアップデータの確認: プラグイン（UpdraftPlusなど）でサーバー内にバックアップを保存している場合、古いバックアップが数十GB単位で残っている可能性があります。

すべてをチェックするのは大変ですので、以下の基準で「機械的に」候補を絞ります。

未活用の画像 (Unused Images): 記事からリンクされていない、メディアライブラリに眠っているだけの画像です。「Media Cleaner」などのプラグインを使うと、どこにも使われていない画像を抽出できます。
過去の「速報」記事の画像: 天気図などは、数年前の日常的な実況図であれば、資料的価値が低いものも多いはずです。「3年以上前の日常解説記事」など、期限を決めて削除対象にします。
リサイズ前の巨大なオリジナル画像: デジカメや高解像度スクリーンショットをそのまま上げている場合、1枚で数MBあることがあります。

今後、容量を圧迫させないための具体的な対策です。

削除と並行して、残す画像のサイズを小さくします。

WebP形式への変換: すでに導入されているかもしれませんが、JPG/PNGをWebPに変換するだけで容量は劇的に減ります。
プラグインの活用: EWWW Image Optimizer や Imsanity を使い、過去の画像も含めて一括でリサイズ（例：横幅最大1200px制限など）をかけるのが最も効果的です。

もし「記録として天気図は残しておきたいが、サーバー容量は空けたい」という場合は、以下の方法があります。

クラウドストレージへの移行: 過去の画像アーカイブだけを Google Drive や Amazon S3 などに逃がし、ブログからはそこへリンクを貼る形です。

画像削除は、一歩間違えると記事の「画像割れ（NO IMAGE）」を引き起こします。

必ずバックアップを取る: 削除作業の前に、FTPソフト（FileZillaなど）で wp-content/uploads フォルダをPCローカルにダウンロードしておいてください。
データベースの最適化: 画像を消した後は、データベース内に残った「画像の参照情報」も掃除する必要があります。Advanced Database Cleaner などのツールが便利です。