画像サイズ削減ツール：画質を損なうことなく写真のバイト数をカット

最終更新日: June 28, 2026

先週、カメラから4,200 KBのJPEGを取り出し、それを4つのステップで処理した結果、78 KBのWebPが完成しました。これは、表示サイズにおいて目に見える画質の低下を伴わずに98パーセントの削減率です。画像サイズを縮小する作業は魔法のようなボタン一つではありません。それは一連の安価な操作であり、ツールの選択よりも順序が重要になります。

クイックアンサー：最も早く画像ファイルサイズを削減する方法は？

まず、画像が表示される実際のピクセル幅にリサイズし、次にWebP形式で品質80にエクスポートします。4,200 KBのテスト写真に対してこの組み合わせを行うと、78 KBになりました。圧縮品質だけ（ほとんどの人が最初に触れるスライダー）を調整した場合では、940 KBにしかなりませんでした。リサイズによって節約できるバイト数は、品質による削減額を遥かに上回り、WebPはあらゆる品質レベルでJPEGを凌駕します。

これらの数値の根拠を知りたい場合は、image compression algorithmsでフォーマットの決定について解説しています。

ファイルサイズは主にリサイズによって減少するのはなぜですか？

4000px幅の写真が800pxで表示される場合、ブラウザは実際に表示されているピクセル1つあたり、余分な水平方向のピクセルを4つダウンロードします。そして、それらは破棄されます。私はこれを直接測定しました。同じ画像をフル解像度と1600pxの両方でWebP q80にエクスポートした場合、幅のリサイズだけで980 KBから78 KBへと、なんと92パーセントも削減されました。これは品質調整を行う前です。

私が守っているルールは、最も長い辺をレティナディスプレイの最大の表示幅の約2倍に設定すること、そしてフルブレッドのヒーロー画像の場合は1920pxを超えることは絶対にないようにすることです。コンテンツ画像の場合、通常1200px以上必要になることは稀です。まず解像度を制限することで、パイプライン全体の作業が容易になります。これはresize image for web guideの実際的な目標値と組み合わせて使用します。

なぜ先にリサイズし、次に圧縮するのですか？

順序を逆にするのは労力の無駄です。4000pxの画像を小さなファイルに圧縮するということは、エンコーダが誰もレンダリングしないディテールにビットを費やすことを意味します。その後でリサイズして、それらのビットを捨てるのです。私は毎回このシーケンスを実行します：

1. ソースを開き、実際のピクセル寸法を読み取る。
2. 最長の辺をディスプレイの目標値（例：1600px）に対して計算する。
3. Lanczosリサンプリングでダウンサンプルを行う — これによりエッジがシャープに保たれます。
4. 不要なアルファチャンネルがある場合はRGBに変換する。
5. メタデータを除去し、WebP形式で品質80に再エンコードする。
6. 出力ファイルを書き出し、処理前後のバイト数を記録する。

この6ステップのループにより、4.2 MBのファイルが78 KBになりました。同じループを240枚の商品写真フォルダにかけると、1分もかからず、合計で612 MBを節約できました。

どのフォーマットが実際に最も多くのバイト数を節約しますか？

ウェブ上の写真の場合、答えはWebPです。これはロスシー（可逆）とロスリー-ウィズ-アルファの両方をサポートしており、Googleの参照エンコーダは、同等の視覚品質においてJPEGよりも約25〜35パーセント小さいファイルを生成し、今日ではAVIFよりも幅広いブラウザサポートを持っています。WebP documentationでは、JPEGおよびPNGに対するフォーマットの圧縮比が詳しく解説されています。

私が頼りにしているいくつかのフォーマットルールがあります：

• 写真 → WebP（ロスシー、q70〜85）。
• 色が少ないグラフィック → WebPまたは最適化されたPNG。
• アニメーションが必要 → GIFではなくWebP。
• 純粋な透過度を維持する必要がある場合 → PNGまたはWebP lossless。
• 最新のブラウザのみを対象とするトラフィック → AVIFを使用するとさらに15〜20パーセント削減できる可能性がある。

MIMEタイプとブラウザサポートのマトリックスは、MDN's image types referenceに文書化されています。より深いトレードオフの読み物としては、こちらのcompress images without losing qualityガイドを参照してください。

品質設定はどのように選びますか？

品質とは設定ではなく予算です。私は80から始め、アーティファクトが見えるまで下げていき、その後少し戻します。1600pxの4.2 MBのソースを測定した結果：

ヒーロー画像の場合は80〜85で留めます。サムネイルやアバターの場合は70まで下げます。なぜなら、それらは十分に小さくレンダリングされるため、ロスが目立たないからです。100KBという目標ファイルサイズの場合の作業は、compress image to 100KB guideで最初から最後まで取り組んでいます。

画像フォルダをバッチで削減する方法は？

画像が1枚なら簡単ですが、300枚となるとほとんどの人が諦め、オリジナルファイルをアップロードしてしまいます。同じ6ステップのループもクリーンに並列化できます。私はスレッドプールを使用してディレクトリを処理し、結果をソースファイルと一緒に書き出します。

実用的なバッチチェックリスト：

• .jpg, .jpeg, .png, および .webp の入力をグロブ検索する。
• すでに目標サイズ以下のファイルはスキップする。
• ファイルごとの最長辺を、その使用目的（ヒーローかコンテンツか）によって制限する。
• WebPの出力を書き出し、検証が完了するまでオリジナルファイルを保持する。
• すべての前後ペアをCSVに記録する。
• 最後に合計削減バイト数を報告する。

240枚の写真セットでは、このループは4コアのマシンで画像あたり平均0.21秒であり、集計サイズを88パーセント削減しました。

リサイズすべきですか、圧縮すべきですか？

リサイズです。画像削減における最もレバレッジの高い操作は、ピクセル寸法を表示サイズに合わせることです。圧縮とフォーマットの選択は、それらのピクセルがどれだけ効率的に保存されるかを最適化しますが、リサイズはそもそも何ピクセルが存在するかを決定します。一つしかできないなら、リサイズをしてください。二つできるなら、リサイズしてからWebPに切り替えてください。

どんな写真にも適用できる具体的な順序：

1. 表示幅にリサイズする（最大の削減）。
2. WebPに変換する（次に大きな削減）。
3. 品質を70〜85で調整する（微調整）。
4. EXIFとサムネイルを除去する（小さくても無料の節約）。
5. 結果がフルサイズでクリーンにレンダリングされるか確認する。

目指すべき目標ファイルサイズはどれですか？

ハードリミットは、慣例ではなく、公開先のプラットフォームから来ています。私が設計するターゲット値は、実際のCore Web Vitalsの作業とweb.dev's image guidanceに基づいています：

メールが最も厳しいです。多くのクライアントは、画像の合計ペイロードが約102 KBを超えるメッセージをブロックするため、600pxで80 KB未満の目標値に抑えることで、3枚の画像を含むニュースレターを配信可能に保つことができます。

ファイルサイズを肥大化させる一般的な間違いは何ですか？

私がチーム間で繰り返し目にする失敗は以下の通りです：

• オリジナルカメラファイルをそのままCMSにアップロードすること。
• 「よりシャープに見える」という理由で写真にPNGを使用すること。
• 「念のため」品質を100に設定してしまうこと — これは目に見える利点がないのにサイズがほぼ倍になることがあります。
• EXIFの除去を忘れること（これには完全な埋め込みサムネイルが含まれている場合があります）。
• CSS経由でブラウザ内でリサイズすること、より小さいソースファイルを配信しないこと。
• 巨大な画像を1枚だけ配信し、srcsetに任せること — しかし、より小さなバリアントを生成しないこと。

これらのどれか一つだけでもペイロードが倍になる可能性があります。これらがすべて組み合わさることで、「画像を追加するだけ」というタスクチケットが4 MBのファイルを送り出してしまうのです。

実際の注意点

ファイルサイズと知覚される品質は、同じ線上に並びません。私は38 KBのWebPが120 KBのJPEGよりも綺麗に見える例や、90 KBの画像が平らな青空で崩れてしまい、より複雑な写真の60 KBバージョンの方が問題なく見える例を見てきました。バイト数を測定することは重要ですが、常に実際のレンダリングサイズで結果を目視確認してください — 特にグラデーション、肌の色調、テキストオーバーレイにおいてです。上記の数値は単一のソース画像と単一のディスプレイに基づいています。ビルドパイプラインに目標値をコミットする前に、ご自身でテストを行ってください。

よくある質問

画像ファイルサイズを最も速く削減する方法は？

画質を下げるか形式を変更する前に、画像を実際の表示寸法にリサイズしてください。

画像サイズの削減はピクセル寸法を変更しますか？

圧縮は寸法を変えずにバイト数を減らすことができますが、リサイズは意図的にピクセルの幅と高さを変更します。

写真を小さく保つのに適した形式はどれですか？

WebPは、幅広いブラウザサポートと効率的な非可逆圧縮を兼ね備えているため、ウェブの写真にとって実用的な第一の選択肢です。

最初に試すべき画質設定はどれですか？

まずWebP品質80あたりから開始し、最終的な表示サイズで結果を確認してから調整を行ってください。

元の画像を保持すべきですか？

はい、繰り返し非可逆なエクスポートを行うとディテールが恒久的に失われるため、未加工のソースを保持してください。

画像サイズ削減ツールは正確なKB目標値を達成できますか？

画質と寸法を繰り返すことで目標値に近づけることは可能ですが、視覚的に複雑な画像は単純なものよりも多くのバイト数を必要とする場合があります。

メタデータを削除すると大幅に容量が節約できますか？

EXIFや埋め込みサムネイルの削除は役立ちますが、過剰なピクセル寸法をリサイズする方が通常ははるかに多くの容量を節約します。

複数の画像を一度に削減できますか？

はい、まず代表的なファイルを一つテストし、その後バッチプロセッサを通じて検証された設定を適用してください。

画像クレジット

• Pexelsより提供：A laptop showing charts and graphs for measuring image file size — photo by Lukas
• Pexelsより提供：A close-up of a DSLR camera with lens — photo by Pixabay
• Pexelsより提供：HTML code on a computer screen for WebP markup — photo by Pixabay
• Pexelsより提供：A person typing on a laptop in a home office — photo by Vlada Karpovich