品質劣化なしで画像を圧縮する方法：WebPワークフロー

最終更新日: June 28, 2026

ほとんどの品質の問題は、圧縮される前から始まっています。4000 px の写真を 800 px のコンテンツスロットにアップロードするだけで、すでにバイトを無駄にしています。低品質な JPEG として保存された製品スクリーンショットは、テキストをぼかすように仕組まれています。目に見える品質低下なしで画像を圧縮することは、ほとんどの場合、正しい順序で手順を踏むことに尽きます。

本ガイドでは、写真、スクリーンショット、製品画像、ブロググラフィックのための実用的なワークフローを紹介します。WebP が広くサポートされており、可逆（lossy）または非可逆（lossless）の両方に対応しているため、こちらを推奨しますが、AVIF をテストする場合や、シャープな UI キャプチャのために PNG を維持する場合も同様のチェックが適用されます。

簡単な回答：品質を失わずに画像を圧縮する方法は？

この順序を使用してください。オリジナルを保持する → 必要な場合はトリミングする → ページが表示する最大のサイズにリサイズする → 最適なフォーマットを選択する → 品質候補を2〜3つエクスポートする → 最後に、最終的な表示サイズでそれらを比較する。視覚的なチェックをパスしつつ最もファイルサイズの小さいものが、正しい圧縮画像です。

ほとんどのウェブ写真には、WebP を q80 から q85 あたりから開始します。スクリーンショット、ダッシュボード、ロゴ、小さなテキストを含む画像には、まず PNG または非可逆 WebP をテストしてください。厳格なファイルサイズ目標がある場合は、リサイズが主な作業を終えた後で、徐々に品質を下げるようにしてください。

エクスポートスライダーだけで結果を判断しないでください。縦長の写真、ジュエリーの写真、価格表のスクリーンショットは、それぞれ異なる場所で失敗します。ライブ画像を置き換える前に、顔、製品のエッジ、小さなテキスト、グラデーション、影を確認してください。

なぜリサイズが圧縮設定よりも重要なのか？

ピクセル寸法は、通常、品質スライダーよりも多くの節約になります。画像が 900 px 幅で表示される場合、4000 px のファイルを配信することは、読者が決して見ることのないピクセルをブラウザにダウンロードさせることを強制します。圧縮はこの無駄を減らすことができますが、リサイズは発生源でそれを取り除きます。

ブラウザは、提供されたファイルを依然としてフェッチし、デコードする必要があります。web.dev の画像パフォーマンスガイドによると、WebP や AVIF のような最新フォーマットはダウンロードサイズを削減でき、これは画像が最初のビューポートにとって重要である場合に Largest Contentful Paint (LCP) を助けることにもつながります。詳細は web.dev's image performance guide を参照してください。

品質設定を選ぶ前に、幅の予算を使用してください：

オーバーサイズのアップロードセットから開始する場合、まず寸法を処理してください。Batch Resize Guide はバッチの幅制限を網羅しており、Resize Images Without Losing Quality はリサイズ時のソフトエッジを避ける方法を説明しています。

品質調整を行う前にどのフォーマットを使用すべきか？

フォーマットの選択は、ユーザーが気づくディテールを守ります。JPEG と可逆 WebP は、小さな色の変化が見えにくいので写真に適しています。PNG と非可逆 WebP は、テキスト周辺の圧縮アーティファクトがすぐに雑に見えるため、スクリーンショットにより安全です。

MDN の画像フォーマットガイドによると、WebP は可逆圧縮と非可逆圧縮の両方をサポートしていますが、これらのモードでは画像データを異なる方法で保存します。だからこそ、「WebP として保存」という指示だけでは不十分なのです。可逆 WebP は製品写真には優れているかもしれませんが、密度の高いダッシュボードのスクリーンショットには適していません。MDN の image file type and format guide を参照してください。

フォーマットが不明確な場合は、以下のルールを使用してください：

1. ファイルサイズが重要な写真には、WebP または AVIF を使用する。
2. 読み取り可能なテキストを含むスクリーンショットには、非可逆 WebP または PNG を使用する。
3. ベクターアートがあるシンプルなロゴやアイコンには、SVG を使用する。
4. 透明度は、ランダムな背景にフラット化するのではなく、WebP、PNG、または SVG で維持する。
5. 低品質な JPEG を WebP に変換し、ディテールが戻ると期待することは避ける。
6. クリーンに再エクスポートできるように、オリジナルのマスターファイルを保持する。

より深いフォーマット比較については、AVIF vs WebP Comparison を読んでください。アーティファクトの背後にある圧縮メカニズムが必要な場合は、How Image Compression Works を使用してください。

どの WebP 品質設定が目に見える損失を避けるか？

万能の設定はありませんが、WebP q80 から q85 は、多くのウェブ写真にとって合理的で最初のテストとなります。これは通常、テクスチャ、エッジ、色の遷移を通常の表示サイズでクリーンに保ちながら、バイト数を大幅に削減します。画像がまだ良さそうに見える場合にのみ下げてください。

この記事のために、ImageMagick を使用して作成した4つのローカル WebP インフォグラフィックを出力しました。最終ファイルは 31 KB から 41 KB でしたが、これはグラフィックがフラットな色と単純な形状を使用しているためです。これらの数値はカメラ写真の保証ではありません。コンテンツの種類が重要であることを示しています。

品質設定は、ルールとしてではなく候補として使用してください：

最も簡単な間違いは、300 パーセントのズームでファイルを比較し、すべての圧縮設定を拒否することです。まず、読者が実際に目にするサイズで検査してください。次に、リスクの高い領域（テキスト、ジュエリー、生地、髪、影、滑らかなグラデーション）にズームインしてください。

ターゲット比率が必要な場合は、Image Compression Ratio: Quality and Size Guide を使用してください。これは、リサイズ後に比率を計算する方法と、高い比率が背景写真には問題ないが、ラベルやスクリーンショットには危険な理由を説明しています。

品質が実際に維持されているかを確認するには？

品質は、圧縮された画像が最終的な表示サイズで元の画像の役割を果たし続けているときに維持されます。これは明白に聞こえますが、2つの一般的なエラーを防ぎます。それは、バイト数が少ないという理由で醜いファイルを承認してしまうこと、そして極端なズームの下で異なるという理由で有用なファイルを拒否してしまうことです。

この視覚的なレビューを使用してください：

1. オリジナルと候補を並べて開く。
2. カメラサイズではなく、レンダリングされたサイズを合わせる。
3. まず最もシャープな被写体のエッジを確認する。
4. 小さなテキスト、ラベル、UIのボーダーを検査する。
5. 空やグラデーション、影のバンディング（帯状の縞）がないか探す。
6. 肌、生地、食べ物、製品のテクスチャを比較する。
7. モバイルで重要である場合は、スマートフォンで画像をテストする。
8. パスした最も小さい候補を保持する。

これは特に e-commerce で重要です。カテゴリーサムネイルは、製品詳細画像よりも多くの圧縮に耐えられる場合があります。同じマスターが両方の配置に供給される場合、サイト全体で単一の品質設定を強制するのではなく、個別のファイルをエクスポートしてください。

Google の画像 SEO ドキュメントも、有用でコンテキスト的な alt テキストとクロール可能な画像マークアップを推奨しています。これは圧縮後に重要になります。なぜなら、小さく、不明確で、説明が不十分な画像は、検索やアクセシビリティにとって勝利ではないからです。詳細は Google Images best practices を参照してください。

全フォルダに対してどのようなワークフローを使用すべきか？

バッチ圧縮にはガードレールが必要です。すべてのファイルに対して積極的な設定を適用すると、最初に犠牲になるのはスクリーンショット、ロゴ、ラベル付きの製品写真です。エクスポートする前に、画像をコンテンツごとにグループ化してください。

このフォルダーワークフローを使用してください：

1. 写真、スクリーンショット、透明グラフィック、ロゴを分離する。
2. 処理する前に、重複や未使用のトリミングを削除する。
3. 各グループを実際の最大表示幅にリサイズする。
4. 写真とイラストレーションには WebP の候補を出力する。
5. テキストを含むスクリーンショットには非可逆の候補を出力する。
6. データが必須でない限り、公開ウェブコピーからメタデータを削除する。
7. 全フォルダを処理する前に、各グループからサンプルを比較する。
8. 選択した幅、フォーマット、品質、バイト範囲を記録する。
9. 既存のページが壊れないように、安定した URL に公開する。
10. すべての最終 URL が HTTP 200 を返すことを検証する。

モバイル中心のページの場合、このワークフローを Mobile Image Optimization Guide と組み合わせてください。より広範なローンチチェックリストが必要な場合は、Complete Image Optimization Checklist を使用してください。

より大きなファイルを許容すべきなのはどんな時か？

画像が信頼性、ディテール、またはコンバージョン価値を伝える場合、より大きなファイルを受け入れるべきです。販売者は、30 KB を節約するためにジャケットのテクスチャをぼかすべきではありません。SaaS チームは、価格設定のスクリーンショットを読めない状態にすべきではありません。パブリッシャーは、軸ラベルが滲むまでチャートを圧縮すべきではありません。

より大きなファイルが妥当なのは、画像が以下を含む場合です：

• 製品ラベル、シリアル番号、原材料、またはサイズ表。
• 小さなテキストやコードを含むスクリーンショット。
• 顔、肌の質感、髪、ジュエリー、または食べ物。
• 滑らかなグラデーション、夜景、影、またはネオン。
• ロゴ、透明なエッジ、または細い線画。
• ユーザーがズームしたり、トリミングしたり、広告で再利用する画像。

正しいターゲットは、可能な限り最小のファイルではありません。それは、文脈の中で依然として信頼できると感じられる最小のファイルです。圧縮されたバージョンによって読者がためらう場合、品質を上げたり、より良いフォーマットを使用したり、その配置専用の別バージョンを出力してください。

出版前のチェックリスト

ライブページで画像を置き換える前に、最終チェックを実行してください。これは、ほとんどの画像問題を引き起こす退屈な間違い（間違った寸法、間違ったフォーマット、壊れた URL、欠落した alt テキスト、デスクトップでは良さそうだがモバイルでは劣るファイル）を検出します。

この最終チェックを使用してください：

よくある質問

品質低下なしで画像を圧縮できますか？

非可逆圧縮はピクセルデータを保持しますが、非可逆圧縮は数学的に同一ではないものの、最終的な表示サイズでの知覚される品質を保つことができます。

圧縮する前にリサイズすべきですか？

ソースが表示される最大の枠よりも広い場合は、まずリサイズしてください。

WebPは常にJPEGより小さいですか？

必ずしもそうではありません。そのため、どちらの形式も同じソースからエクスポートし、一方の形式が優れていると仮定するのではなく、バイト数と視覚的なディテールを比較してください。

どのWebP品質を使用すべきですか？

写真には品質75〜85が有用なテスト範囲ですが、スクリーンショットや滑らかなグラデーションには、より高い設定または非可逆出力が必要な場合があります。

圧縮は画像メタデータを削除しますか？

エクスポートツールによってはメタデータを削除するものもあれば、保持するものもあるため、サイズやプライバシーの観点からEXIFの削除が重要かどうかは最終ファイルを検査してください。

圧縮された画像が大きくなるのはなぜですか？

小さすぎる、またはすでに最適化されているソースを、非効率な設定や不適切な形式で再エンコードすると、より大きく見えることがあります。

圧縮候補を比較する方法はどうすればよいですか？

候補画像をオリジナルと並べて最終レンダリングサイズで表示し、テキスト、エッジ、グラデーション、肌、製品のディテールを確認してください。

画像をバッチ圧縮しても安全ですか？

はい、類似の画像タイプをグループ化し、各グループからサンプルを一つテストし、フルバッチが検証されるまでオリジナルを保持してください。