ツール一覧 ／ AI活用ノート ／ AI生成画像をWebに載せる前の圧縮手順｜書き出しとWebP変換の順番
生成AIの画像は既定でPNGのまま数MBになりがちです。生成サイズの決め方、リサイズと圧縮をどちらから先にやるか、WebPに変換する判断、1枚あたりの目標KBの決め方を、公式ドキュメントの数値をもとに手順として整理しました。
生成した画像をそのまま納品用のサイトに置いて、Lighthouseで怒られたことがある人向けです。
先に断っておくと、この記事の数値はすべて提供元の公式ドキュメントとHTTP Archiveの公開データを2026-09-03時点で読んだものです。有料プランを課金して検証したものではありません。
生成側の既定値が原因です。
OpenAIの画像生成APIは、出力形式が指定されなければPNGを返します。output_format で jpeg / webp も選べますが、圧縮率を指定する output_compression（0〜100）はJPEGとWebPにしか効きません。PNGを選んでいる限り、このパラメータは何もしません（2026-09-03時点のOpenAI公式ガイド）。
サイズ側にも制約があります。最大辺は3840px以下、両辺が16の倍数、アスペクト比は3:1以下、総ピクセル数は655,360〜8,294,400。つまり既定に任せると、1024×1024より小さいものは出てきません。
Google Gemini側は、生成解像度として512px（0.5K）／1K／2K／4Kが用意されています。モデルによって使える解像度が違い、2Kと4KはGemini 3.1 Flash ImageとGemini 3 Pro Imageのみです。また公式ドキュメントには「生成された画像にはすべてSynthIDウォーターマークが入る」と明記されています。
PNGは可逆圧縮です。写真的なノイズや微妙なグラデーションを含む生成画像とは相性が悪く、1536×1024でも数MBまで膨らみます。ここを設定で潰さないまま納品すると、そのまま表示速度に乗ります。
リサイズが先です。 理由は2つあります。
ひとつは劣化の話。WebPやJPEGの非可逆圧縮は画素を捨てます。捨てたあとに縮めると、捨てた痕跡を縮小補間が拾って、輪郭のにじみやブロックノイズが残ります。順番を逆にするだけで、同じKBでも見た目が悪くなります。
もうひとつは、効き幅の話です。1536×1024のPNGを、実際には768px幅のカラムに置いている——AI画像でよくある状態です。このとき効くのは品質パラメータではなく寸法です。Lighthouseの「Properly size images」監査は、レンダリングされるサイズと実ファイルのサイズをデバイスピクセル比込みで比較し、差が4KiB以上あれば失格にします。判定基準そのものが「表示サイズに合っているか」なので、圧縮率をいじっても抜けられません。
生成サイズをいくつにするかは、表示幅の2倍を上限にします。高DPIディスプレイの2xを想定した数字です。web.devの解説でも、300×200で表示する画像に対して600×400を2xとして渡す例が示されています。3xまで用意する必要は、写真的な素材ではほぼありません。
「軽くする」では判断が止まります。数字を持ちます。
HTTP Archiveの Web Almanac 2025（Page Weight章、2025年7月データ）によると、トップページの中央値はデスクトップ2,862KB、モバイル2,559KB。そのうち画像だけでデスクトップ1,058KB、モバイル911KBです。ページの3分の1以上が画像です。
1枚あたりのファイルサイズも出ています。デスクトップのトップページで、90パーセンタイル（重いほうから10%目）の値は次のとおりです。
ここから目標を決めます。本文中の画像は1枚100KB以下、ヒーロー画像だけ200KBまで。 WebPの90パーセンタイルが97KBなので、100KBを切っていれば「重いほう10%」には入らないという意味の数字です。
上限として意識するのはLCPです。web.dev の Optimize LCP によれば、良好とされるのはページ訪問の75%以上で2.5秒以内、2.5〜4.0秒が「改善が必要」、4.0秒超が「悪い」。ファーストビューに3MBのPNGを1枚置くと、モバイル回線ではここが持ちません。
Lighthouseの「Serve images in modern formats」監査は、削減見込みが8KiB未満なら報告から外すと明記されています。裏を返すと、既に100KBを切っているWebPをAVIFに変えても、監査項目としては消えている可能性が高い。労力の配分の目安になります。
この記事で「向いている」と書くときの基準は3つです。順に優先します。
<picture>の分岐が増えるほど保守コストが乗る）速度だけを見るならAVIF一択ですが、3番目を加えると順位が変わります。
| 形式 | 透過 | 圧縮の効き | 弱点 | 向いている用途 |
|---|---|---|---|---|
| PNG | あり（8/16bit） | 可逆のみ。写真調では効かない | AI画像だと数MBになる | 図版、UI素材、原本の保管 |
| JPEG | なし | 非可逆 | 透過不可。WebPに劣る | 既存資産との互換だけ |
| WebP | あり | 非可逆でJPEG比25〜35%減、可逆でPNG比26%減 | 最大16,383×16,383px | 本文・ヒーローの既定 |
| AVIF | あり | JPEG比・WebP比ともに中央値で約50%減 | プログレッシブ表示なし。書き出しが遅い | ヒーロー1〜2枚 |
← 表は横にスクロールできます →
（圧縮率はMDN「Image file type and format guide」の記載、およびGoogleの WebP Compression Study による）
WebPの「JPEGより25〜34%小さい」という数字は、Googleが同じSSIM値で揃えて比較した結果です。ただしこの研究、使っているのはlibwebp 0.1.2とImageMagick 6.5.7で、現行版よりかなり古い。対象も「標準的なテスト画像は写真的なものが中心」と本文で断られています。フラットな塗りのAI生成イラストにそのまま当てはまる保証はありません。手元で1枚試して比べるほうが早いです。
AVIFの「プログレッシブ表示なし」は地味に効きます。低速回線で、JPEGなら粗い絵から徐々に鮮明になるところが、AVIFでは何も出ないまま待つことになります。ヒーロー画像に使うなら、この体感差は把握しておいたほうがいい。
GUIで済ませるなら Squoosh（squoosh.app）です。Google Chrome Labs製の無料ツールで、公式サイトに「画像は端末から出ません。Squooshはすべての処理をローカルで行います」と明記されています。クライアントから預かった素材を扱う場合、この一文は説明材料になります。無料で足ります。有料の代替に移る理由は、枚数が増えて手作業が回らなくなったときだけです。
枚数が多いならcwebpを回します。オプションの既定値は公式ドキュメントに書いてあります。
cwebp -q 80 -resize 1536 0 -m 4 hero.png -o hero.webp
-q は0〜100、既定は75。写真調のAI画像なら75〜82あたりで目視の差が出にくくなります。-resize 幅 高さ は、片方に0を渡すとアスペクト比を保って計算されます。上の例は幅1536px指定。-m は0〜6の圧縮方法、既定は4。数値を上げると時間がかかる代わりにファイルが小さくなります。バッチなら6でも構いません。-lossless。-near_lossless は0〜100で、既定100が「前処理なし」です。数値を下げるほど前処理が強くなる、向きが直感と逆なので注意してください。書き出したら、HTML側は表示幅の指定まで含めてセットです。web.devの Responsive images では、max-inline-size で親要素より大きく表示させないこと、width と height 属性を必ず書いてレイアウトシフトを防ぐことが挙げられています。加えて、ファーストビューの画像には fetchpriority="high" を付け、LCP画像に loading="lazy" は付けない。web.dev の Optimize LCP は「LCP画像を遅延読み込みすると必ずリソース読み込みの遅延を生み、LCPに悪影響を与える」と書いています。
srcsetのw記述子を使うときはsizesが必須です。MDNの解説どおり、ブラウザはsizesのメディア条件から表示スロット幅を決め、それに合う候補をsrcsetから選びます。sizesがないと選択が働きません。なお、切り抜きを変える（アートディレクション）場合だけ<picture>とmedia属性を使い、そのときはsizesにメディア条件を併記しない、と明記されています。
ここは調べていて引っかかった点です。
AVIFとWebPの対応状況が、2つの公式資料でずれています。 Chrome for Developers の Lighthouse ドキュメント（Serve images in modern formats）は、AVIFの対応をChrome・Firefox・Operaとし、「WebPとAVIFはiOS 16未満のiPhoneでは動作しない」と書いています。一方MDNの Image file type and format guide は、WebPを「Chrome・Edge・Firefox・Opera・Safariの全バージョン」、AVIFを「Safari 16.1以降を含む」としています。
MDNのほうが新しい状態を反映していると読めますが、片方だけを根拠に「Safariは大丈夫」と結論を書くのは避けたほうがいい。実務上の落としどころは、AVIFを使うなら<picture>でWebPのフォールバックを置く、WebPは単体で使う、です。MDNもAVIFについては「対応が広範ではなく歴史も浅いため、WebP・JPEG・PNGのフォールバックを<picture>で用意すべき」としています。
もうひとつ、書き出し設定が効かないケース。OpenAIのAPIでoutput_compressionを渡しても、output_formatがPNGのままなら効きません。透過が必要な生成物は形式がPNGかWebPに限られる（JPEGは透過非対応）ので、「透過あり・軽く」を両立させたいならWebPを明示的に指定する必要があります。ここを既定任せにしたまま「圧縮パラメータを入れたのに小さくならない」と悩む、が起きやすいところです。
生成画像の再圧縮とSynthIDウォーターマークの関係については、Googleの公式ドキュメントに「すべての生成画像にSynthIDが入る」とは書かれていますが、リサイズや非可逆圧縮を通したあとの挙動は明記されていません。推測で書けないので、そのまま「書かれていない」と置いておきます。納品物の扱いに関わる場合は提供元の規約を直接確認してください。
Q. 全部AVIFにしてしまえばいいのでは。
速度だけならそうです。ただし<picture>のフォールバックが全画像に付くこと、書き出し時間が伸びること、プログレッシブ表示がないことが乗ります。Lighthouseは削減見込みが8KiB未満の画像を報告から外すので、既に100KBを切っているWebPをAVIFに変えても監査上のスコアは動かないことがあります。ヒーローだけで十分なケースが多いです。
Q. 生成は最初からWebPで書き出せば手間が減りませんか。
OpenAIのAPIならoutput_format: "webp"で可能です。ただし原本を可逆で持っておかないと、あとでトリミングや色調整をするときに再圧縮が重なります。原本はPNG、公開用にWebP の2本立てが安全です。
Q. 100KBという目標は厳しすぎませんか。 Almanac 2025のデータでは、WebPの90パーセンタイルが97KBです。100KB以下は「重いほう10%に入らない」水準であって、飛び抜けて厳しい数字ではありません。全面写真のヒーローだけ200KBまで許容する、という運用で回ります。
Q. WordPressのプラグインに任せてはいけませんか。 任せて構いません。ただしプラグインが変換するのは「アップロードされた画像」です。3MBのPNGを上げれば、サーバー上に3MBの原本が残り、変換処理もその重さで走ります。アップロード前にリサイズする工程は、プラグインを入れても消えません。
Q. cwebpの品質はいくつが正解ですか。 既定は75です。写真調なら75〜82の範囲で1枚試して、等倍で目視確認するのが早い。数値を固定するより、案件ごとに1枚だけ比べる習慣のほうが結果的に速いです。
以下はすべて2026-09-03時点で実際に開いて確認したものです。