水族館の写真7枚をWebPに変換したら容量はどれだけ減る?実測と再現手順
実際に撮影した水族館写真7枚をJPEGからWebPへ変換。合計4,386KiBから1,424KiBへ67.5%削減した設定、Pythonの手順、画質確認とNext.jsでの掲載方法を紹介。
写真が多い記事を作るとき、画像を軽くしたい。でも、容量だけを小さくして、水の色や魚の模様がつぶれてしまったら、写真の魅力も失われます。
GAOCRAFTが運営するシーパラ攻略隊(外部サイト)では、2026年10月22日に撮影した「ドルフィン ファンタジー」の写真7枚を記事に使いました。イルカ、魚の群れ、青いアーチ水槽など、細かい模様や色の階調が多い写真です。

図:2026年10月22日、シーパラ攻略隊の現地取材で撮影した写真。この記事で比較した7枚のうちの1枚です(WebP版を表示)。
今回は、その実際の7ファイルをJPEGからWebPへ変換した結果と、あとから同じ処理を再現できる方法を紹介します。なお、これはこの7枚を対象にした実測であり、すべての写真で同じ削減率になることを保証するものではありません。
結果 |7枚合計で 約67.5%削減
使用した元画像はJPEG形式の7枚。最適化後はWebP形式の7枚です。比較は元ファイルと変換後ファイルのバイト数で行いました。
| 指標 | 実測値 |
|---|---|
| 元JPEG合計 | 4,491,362バイト(約4,386KiB) |
| 変換後WebP合計 | 1,458,540バイト(約1,424KiB) |
| 削減した容量 | 3,032,822バイト(約2,962KiB) |
| 削減率 | 67.5% |
| 画像の縦横 | 全7枚で1536×1152pxのまま |

図:元ファイル7枚と変換後ファイル7枚の実容量を比較。通信量や読み込み時間を測った値ではありません。
これはファイルそのものの比較です。実際にWebページを開いたときの通信量が67.5%減ったと測定したわけではありません。 ブラウザーの表示サイズ、画像配信、キャッシュやNext.js側の最適化によって実際の転送量は変わります。
1枚ずつ比較すると 違いが 分かる
| 元の写真 | JPEG | WebP | 削減率 |
|---|---|---|---|
| IMG_0234.jpeg(イルカの近接写真) | 665.9KiB | 214.7KiB | 67.8% |
| IMG_0236.jpeg(魚の群れ) | 552.2KiB | 163.6KiB | 70.4% |
| IMG_0237.jpeg(縞模様の魚) | 776.4KiB | 295.3KiB | 62.0% |
| IMG_0241.jpeg(アーチ水槽の通路) | 541.6KiB | 158.2KiB | 70.8% |
| IMG_0243.jpeg(円柱水槽) | 614.9KiB | 196.2KiB | 68.1% |
| IMG_0244.jpeg(展示パネル) | 602.0KiB | 203.5KiB | 66.2% |
| IMG_0246.jpeg(イルカと魚の群れ) | 633.1KiB | 192.8KiB | 69.5% |

図:今回の7枚のファイルを一つずつ比較した結果。同じWebP設定でも写真の内容により削減率が変わりました。
一番減ったのはアーチ水槽の通路の写真で約70.8%。一番小さい削減率だったのは縞模様の魚の写真で約62.0%。同じ設定でも写真の内容によって圧縮後の大きさは異なりました。
今回 使った 設定と Pythonの 処理
GAOCRAFTでは、PythonのPillowを使いました。設定はWebPのquality=83、method=6。今回は、画像のリサイズは行っていません。

図:今回の変換工程を再現するための手順。画質の目視評価と配信時の速度評価は別の作業です。
再現するには、まず python -m pip install Pillow でPillowを準備します。元画像を別の場所に保管し、次のようなコードで変換できます。
from pathlib import Path
from PIL import Image, ImageOps
source_dir = Path("originals")
output_dir = Path("webp")
output_dir.mkdir(exist_ok=True)
for source in sorted(source_dir.glob("*.jpeg")):
destination = output_dir / (source.stem + ".webp")
with Image.open(source) as original:
# EXIFの向き情報を実際の画像方向に反映する
image = ImageOps.exif_transpose(original).convert("RGB")
image.save(destination, "WEBP", quality=83, method=6)
print(source.name, "→", destination.name)qualityは画質と容量のバランスを決める数値です。methodはエンコードにかける処理の設定で、値が高いほど時間をかけて圧縮を試みます。ここで紹介している数値は今回採用した設定であり、万能な推奨値という意味ではありません。
注意:このコードはJPEGをWebPに変換する例です。ファイル名の付け替え、保存先、メタデータの扱いは運用に合わせて検証してください。元画像は消さずに保管します。
変換前後で 何を 確認したか
今回は元画像と変換後の画像について、少なくともファイル形式・解像度・容量が確認できます。7枚とも1536×1152pxのままなので、今回の削減には解像度を小さくした効果が含まれていません。
ただし、容量が減っただけで画質の良し悪しは決まりません。掲載前には、次のような部分を人の目で確認するのが適切です。
イルカの輪郭や水面の明暗が不自然にぼやけていないか。
魚の縞模様、細い線、群れの密集した部分がつぶれていないか。
展示パネルの文字が読めるか。
スマートフォンの横幅と大きな画面の両方で見え方が適切か。
記事制作時にはPC・スマートフォンのプレビューで写真の表示を確認し、その後本番の写真7点もQAで確認しました。これは表示確認が通ったということで、画質の劣化を定量的に測定した結果ではありません。
Next.jsに 掲載する ときの 役割分担
シーパラ攻略隊はNext.jsを使っています。記事ではWebPファイルを読み込み、next/image の Image で表示しました。
import Image from "next/image";
import photo from "../../../public/images/articles/dolphin-fantasy/dolphin-and-school.webp";
export function DolphinPhoto() {
return (
<Image
src={photo}
alt="青い水槽を泳ぐイルカと魚の群れ"
sizes="(min-width: 768px) 48rem, 100vw"
className="h-auto w-full"
/>
);
}これは掲載方法の説明用に簡略化したコードです。実際のページでは写真のキャプションや、先頭写真に対する読み込み設定も加えています。
ここで分けたいのは、元ファイルをWebPにして軽量化することと、ブラウザーに必要なサイズで配信することです。next/image には表示幅に合わせた画像最適化の仕組みがあります。元ファイルの削減率を、そのままページの読み込み速度の改善率とは言い換えません。
画質を 見ずに 「全部 WebPに すればよい」とは 考えない
今回の7枚では、WebP変換でファイルサイズを大きく削減できました。一方、写真の種類や表示用途によって結果は変わります。文字を含む画像では特に、文字の読みやすさに注意が必要です。
GAOCRAFTでは、何を小さくできたかと、何をまだ測っていないかを分けて記録します。
確認済み:7枚のファイル容量、変換設定、変換後の解像度、記事の画面表示。
未計測:LCPなどのパフォーマンス指標への寄与、通信量の実測比較、画質差の数値評価。
もし改善を再現するなら、変換後の画像をスマートフォンでも目視し、必要に応じて品質設定を比較してから採用するのがおすすめです。
まとめ|記事の 写真は、 容量だけでなく 見せ方まで 考える
ドルフィン ファンタジーの写真7枚は、元JPEG合計約4,386KiBからWebP合計約1,424KiBになりました。約67.5%の削減は今回の実測値です。
ただし、数字はここで終わりではありません。水槽の光やイルカの動きが伝わる写真であること、モバイルでもきちんと見えること、掲載後の表示が確認できることも大切です。
仕上がりが気になる方は、GAOCRAFTが運営するドルフィン ファンタジーの現地写真レポート(外部サイト)で、記事としての見え方を確認できます。
実測と制作に関する注記:写真は2026年10月22日に現地で撮影し、今回の画像最適化を行いました。ファイルサイズは2026年10月23日に元JPEGと変換済みWebPのファイルを再集計したものです。制作・検証:GAOCRAFT。Pythonコードは今回使った設定を再現できるよう整理した例です。