画像を書き出すときのquality（品質）スライダーを、なんとなく80や90に置いていないでしょうか。あるいは「劣化させたくないから」と100にしている人もいるはずです。
結論から書くと、quality 100は使ってはいけません。ファイルサイズが3倍近くになるのに、画質はほとんど変わらないからです。この記事では、実際にブログへ載せている画像を使って、qualityを30から100まで10刻みで書き出し、「どこから先は払い損になるのか」を実測しました。
写真とスクリーンショットでは最適値がまったく違い、さらにJPEGはスクリーンショットでqualityを上げても画質が単調に上がらないという現象まで確認できました。
スポンサーリンク
測定した条件
結論：ブログに実際に上げた写真4点とスクリーンショット1点を、長辺1920pxに縮小してからquality 30〜100で書き出し、ファイルサイズと画質を測りました。
▼測定環境
▶ エンコーダ：Pillow 12.3.0（JPEG＝optimize・progressive有効、WebP＝method 6）
▶ 前処理：長辺1920pxにLanczos法で縮小
▶ 画質指標：SSIM（11×11のガウス窓、σ=1.5）。1.000が元画像と完全一致
▶ 素材：料理写真・風景写真・物撮り・書影の4点と、ゲーム画面のスクリーンショット1点
SSIMは0.98あたりから、等倍で見ても違いが分かりにくくなります。以下の表では、この0.98を実用上の目安として読んでください。
なお、フォーマット同士の比較はJPEG・WebP・AVIFを同じ画質に揃えて実測した記事にまとめています。この記事は「フォーマットを決めたあと、qualityをいくつにするか」の話です。
実測1：JPEGのquality別（写真）
結論：quality 100は、90と比べて2.7〜3.0倍の容量を食いながら、SSIMの改善は0.01前後しかありません。
| quality | 料理のアップ | 店内の風景 | 物撮り | 書影 |
|---|---|---|---|---|
| 30 | 164KB / 0.916 | 130KB / 0.941 | 77KB / 0.929 | 102KB / 0.957 |
| 40 | 198KB / 0.931 | 156KB / 0.952 | 96KB / 0.940 | 121KB / 0.960 |
| 50 | 231KB / 0.942 | 182KB / 0.960 | 114KB / 0.948 | 138KB / 0.970 |
| 60 | 266KB / 0.950 | 210KB / 0.966 | 134KB / 0.955 | 157KB / 0.974 |
| 70 | 320KB / 0.960 | 252KB / 0.973 | 166KB / 0.963 | 187KB / 0.974 |
| 80 | 404KB / 0.971 | 319KB / 0.980 | 221KB / 0.972 | 236KB / 0.984 |
| 90 | 592KB / 0.985 | 471KB / 0.989 | 351KB / 0.984 | 350KB / 0.991 |
| 100 | 1605KB / 0.999 | 1354KB / 0.999 | 1018KB / 0.999 | 1046KB / 0.999 |
※各セルは「ファイルサイズ / SSIM」
q90からq100への変化を見てください。
▼q90 → q100 で起きること
▶ 料理のアップ：592KB → 1605KB（2.71倍）／SSIM +0.014
▶ 店内の風景：471KB → 1354KB（2.87倍）／SSIM +0.010
▶ 物撮り：351KB → 1018KB（2.90倍）／SSIM +0.015
▶ 書影：350KB → 1046KB（2.99倍）／SSIM +0.008
容量が3倍になって、返ってくるのは1%ぶんの画質です。Webに載せる画像でこの取引に見合う場面はまずありません。quality 100は、可逆圧縮ではないのに可逆に近いコストを払う設定です。
スポンサーリンク
実測2：WebPのquality別（写真）
結論：WebPも同じ傾向です。q100はq90の2.0〜2.3倍の容量を使います。
| quality | 料理のアップ | 店内の風景 | 物撮り | 書影 |
|---|---|---|---|---|
| 30 | 109KB / 0.907 | 76KB / 0.929 | 43KB / 0.916 | 62KB / 0.963 |
| 40 | 129KB / 0.921 | 90KB / 0.940 | 54KB / 0.925 | 71KB / 0.967 |
| 50 | 150KB / 0.932 | 104KB / 0.948 | 65KB / 0.933 | 79KB / 0.970 |
| 60 | 172KB / 0.940 | 118KB / 0.954 | 77KB / 0.941 | 88KB / 0.973 |
| 70 | 196KB / 0.949 | 134KB / 0.960 | 92KB / 0.949 | 100KB / 0.976 |
| 80 | 261KB / 0.964 | 179KB / 0.971 | 129KB / 0.962 | 126KB / 0.980 |
| 90 | 451KB / 0.983 | 306KB / 0.984 | 249KB / 0.980 | 216KB / 0.988 |
| 100 | 924KB / 0.995 | 696KB / 0.994 | 562KB / 0.995 | 507KB / 0.995 |
ここで注意したいのが、WebPのq80は、JPEGのq80より画質が低い点です。料理写真ではJPEG 0.971に対しWebP 0.964。quality値はフォーマットごとに意味が違うので、JPEGから乗り換えるときに同じ数字を引き継ぐと、気づかないうちに画質が下がります。
WebPで写真を扱うなら、JPEGで使っていた値より5〜10ほど高くするのが目安です。
実測3：折り返し点は写真ならquality 70〜80
結論：q80まではコスト当たりの改善が続き、q80を超えると急に効率が落ちます。写真はq70〜80に置いてください。
quality を10上げるのにかかる容量の増分を追うと、境目がはっきりします。料理写真（JPEG）で見てみます。
| 区間 | 容量の増加 | SSIMの改善 |
|---|---|---|
| 30 → 40 | +34KB | +0.015 |
| 50 → 60 | +35KB | +0.008 |
| 70 → 80 | +84KB | +0.011 |
| 80 → 90 | +188KB | +0.014 |
| 90 → 100 | +1013KB | +0.014 |
同じ0.014の改善に、80→90では188KB、90→100では1013KBかかっています。5倍以上の差です。
▼写真のquality目安
① 本文中の写真：JPEG 75〜80／WebP 80〜85
② アイキャッチなど目立つ1枚：JPEG 85／WebP 90まで
③ サムネイル・小さく表示する画像：JPEG 60〜70／WebP 70
④ quality 100：使わない
スポンサーリンク
実測4：スクリーンショットは写真とまったく違う
結論：スクリーンショットはWebPのquality 30でSSIM 0.984に達します。写真の感覚でq80にすると、容量を1.7倍も無駄に払うことになります。
同じ測定をゲーム画面のスクリーンショットで行った結果です（WebP）。
| quality | ファイルサイズ | SSIM |
|---|---|---|
| 30 | 59KB | 0.984 |
| 40 | 68KB | 0.988 |
| 50 | 75KB | 0.992 |
| 60 | 80KB | 0.994 |
| 70 | 86KB | 0.994 |
| 80 | 101KB | 0.997 |
| 90 | 134KB | 0.999 |
| 100 | 204KB | 1.000 |
写真ではq30がSSIM 0.907〜0.963だったのに対し、スクリーンショットではq30で0.984です。平坦な色面と直線が多い画像は、低いqualityでも破綻しません。
技術ブログのようにスクリーンショットを大量に貼るサイトでは、ここを写真と分けて設定するだけでページ全体の重さがかなり変わります。
実測5：JPEGはスクリーンショットで画質が単調に上がらない
結論：JPEGでスクリーンショットを書き出すと、qualityを上げたのにSSIMが下がる区間があります。この時点で、UI画像にJPEGを使う理由はありません。
スクリーンショットをJPEGで5刻みに書き出した結果です。
| quality | サイズ | SSIM |
|---|---|---|
| 30 | 91.0KB | 0.9654 |
| 35 | 97.4KB | 0.9682 |
| 40 | 103.0KB | 0.9531 ←下がる |
| 45 | 109.8KB | 0.9741 |
| 50 | 115.3KB | 0.9740 |
| 55 | 122.1KB | 0.9760 |
| 60 | 128.9KB | 0.9779 |
| 65 | 136.8KB | 0.9808 |
| 70 | 147.4KB | 0.9649 ←下がる |
| 75 | 158.1KB | 0.9866 |
| 80 | 173.3KB | 0.9877 |
| 85 | 195.5KB | 0.9919 |
| 90 | 229.4KB | 0.9954 |
q40とq70で、容量は増えているのにSSIMが落ちています。q35（0.9682）よりq40（0.9531）のほうが悪く、q65（0.9808）よりq70（0.9649）のほうが悪い。
原因を切り分けるため、クロマサブサンプリングを4:4:4に固定して測り直しました。結果は同じ位置で同じように落ち込みました（q40で0.9544、q70で0.9658）。つまり色情報の間引きが原因ではなく、輝度側の量子化テーブルに由来する現象です。
JPEGはquality値を量子化テーブルの倍率に変換する仕組みで、特定の値では文字や線の輪郭にあたる高周波成分の刻みが荒くなります。写真ではノイズに紛れて目立ちませんが、くっきりした輪郭が多い画像では指標にはっきり出ます。
▼ここから言えること
▶ スクリーンショットや図版にJPEGを使わない。qualityを上げても報われないことがある
▶ WebPは同じ素材で単調に改善する。UI画像はWebP一択
▶ どうしてもJPEGを使うなら、q75以上にする（q70の谷を避ける）
設定の早見表
結論：「写真か、UIか」で分けるだけで、ほとんどの場面は足ります。
| 画像の種類 | おすすめ形式 | quality | 長辺 |
|---|---|---|---|
| 本文中の写真 | WebP | 80〜85 | 1920px |
| アイキャッチ | WebP | 85〜90 | 表示サイズ |
| スクリーンショット | WebP | 40〜60 | 等倍 |
| 図版・イラスト | WebP | 50〜70 | 等倍 |
| SNS用のOGP画像 | WebP / PNG | 80 | 1200×630 |
スクリーンショットを等倍としているのは、UI画像は縮小すると文字がつぶれて読めなくなるからです。写真は縮小してもだいたい成立しますが、UIは違います。UI画像の軽量化は、リサイズではなくフォーマットとqualityで行ってください。
実際に試す
このブログで公開している画像一括変換・圧縮ツールは、qualityを1〜100で指定して複数枚をまとめて変換できます。画像はサーバーに送らず、ブラウザの中だけで処理します。
用意してあるプリセットは3つです。
▼プリセットと、今回の測定を踏まえた使い分け
▶ WebP q80・長辺1920px：写真向け。この記事の結論とほぼ一致する
▶ JPEG q70・長辺1280px：軽さ優先。ただしUI画像には向かない（q70の谷にあたる）
▶ 形式そのまま・q92：画質優先。ただしq92は払いすぎなので、85前後に下げてよい
スクリーンショットを変換するときは、プリセットを使わずqualityを40〜60まで下げてみてください。今回の測定どおりなら、見た目を保ったままファイルサイズが半分近くになります。
関連する記事
▶ JPEG・WebP・AVIFを同じ画質に揃えて実測した…そもそもどの形式を選ぶか
▶ MacでWebPファイルを快適に扱う Quick Look＆変換方法…WebPをMacで開く方法
▶ Pythonで画像圧縮GUIアプリを作る…同じ処理をデスクトップで自動化する
まとめ
qualityの設定について、実測から言えることは3つです。
▼結論
① quality 100は使わない。q90の2.7〜3.0倍の容量で、画質は1%しか変わらない
② 写真は70〜80が折り返し点。ここを超えると容量あたりの改善が急に落ちる
③ スクリーンショットは30〜60で足りる。写真と同じ設定にすると容量を無駄に払う
そして、測っていていちばん意外だったのはJPEGの非単調性でした。qualityを上げたのに画質が下がる区間が、スクリーンショットでは実際に存在します。「品質スライダーを上げれば必ずよくなる」という前提は、少なくとも文字の多い画像では成り立ちません。
写真とUI画像を同じ設定で扱うのをやめる。今回の測定で得られた実用的な学びは、結局そこに尽きます。
※測定はPillow 12.3.0のエンコーダによるものです。cwebpやmozjpegなど別のエンコーダでは、非単調性の出る位置を含めて数値が変わります。SSIMは知覚品質の近似であり、実際の見え方と完全には一致しません。
