AI生成画像をWebに載せる前の圧縮手順｜書き出しとWebP変換の順番

生成した画像を納品用のサイトに置く前に、Lighthouseのスコアまで含めて整えておきたい人向けです。

この記事の目次

1. 結論を先に
2. AI画像のファイルサイズが大きくなる理由
3. リサイズと圧縮、どちらを先にやるか
4. 目標KBをどう決めるか
5. フォーマットをどう選ぶか
6. 選定基準
7. 実際のコマンドと設定値
8. 確認しておくと安心なこと
9. よくある質問
10. 参考にした資料

結論を先に

• 時間で請求しているなら: 生成サイズを表示幅の2倍で止める → 表示幅にリサイズ → WebPの品質75〜82で書き出し → 1枚100KB以下。ここまでで大半の案件は終わります。
• 透過が必要なら: WebP（可逆）かPNGの減色が合います。JPEGは透過を持たない形式なので、この用途では他の2つを選びます。
• AVIFは後回しでいい: 効果は大きく、そのぶんフォールバックの管理も一緒に設計することになります。ヒーロー画像1〜2枚だけ、が現実的な落としどころです。

先に断っておくと、この記事の数値はすべて提供元の公式ドキュメントとHTTP Archiveの公開データを2026-09-03時点で読んだものです。有料プランを課金して検証したものではありません。

AI画像のファイルサイズが大きくなる理由

生成側の既定値で決まります。

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まで用意する必要は、写真的な素材ではほぼありません。

目標KBをどう決めるか

「軽くする」では判断が止まります。数字を持ちます。

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秒超はさらに改善の余地がある区分とされています。ファーストビューの画像を軽くしておくほど、この基準に収まりやすくなります。

Lighthouseの「Serve images in modern formats」監査は、削減見込みが8KiB未満なら報告から外すと明記されています。裏を返すと、既に100KBを切っているWebPは、そのままでも監査項目としてクリアできている可能性が高い。労力の配分の目安になります。

フォーマットをどう選ぶか

選定基準

この記事で「向いている」と書くときの基準は3つです。順に優先します。

1. 透過が必要か（要件なので妥協できない）
2. 同じ見た目で何KB落ちるか（請求可能な時間に直結する）
3. フォールバックを書かずに済むか（<picture>の分岐が増えるほど保守の手間が乗る）

速度だけを見るならAVIFが最有力で、3番目まで含めると向いている場面が分かれます。

← 表は横にスクロールできます →

（圧縮率は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はプログレッシブ表示を持たない設計です。低速回線では、読み込みが完了してから一度に表示される形になります。ヒーロー画像に使うなら、この見え方を把握したうえで選ぶと安心です。

実際のコマンドと設定値

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のほうが新しい状態を反映していると読めますが、片方だけを根拠に結論を出すより、両方を踏まえて設計しておくほうが安心です。実務上の落としどころは、AVIFを使うなら<picture>でWebPのフォールバックを置く、WebPは単体で使う、です。MDNもAVIFについては「対応が広範になってからの歴史が浅いため、WebP・JPEG・PNGのフォールバックを<picture>で用意すべき」としています。

もうひとつ、書き出し設定を活かすためのポイント。OpenAIのAPIでoutput_compressionを渡すときは、output_formatにjpegかwebpを指定しておくとそのまま効きます。透過が必要な生成物は形式がPNGかWebPになるので、「透過あり・軽く」を両立させたいなら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時点で実際に開いて確認したものです。

• Page Weight | 2025 | The Web Almanac by HTTP Archive（HTTP Archive）
• Optimize Largest Contentful Paint（web.dev / Google）
• Responsive images | web.dev（web.dev / Google）
• Image file type and format guide（MDN Web Docs / Mozilla）
• Using responsive images in HTML（MDN Web Docs / Mozilla）
• WebP Compression Study（Google for Developers）
• cwebp | WebP（Google for Developers）
• Properly size images | Lighthouse（Chrome for Developers / Google）
• Serve images in modern formats | Lighthouse（Chrome for Developers / Google）
• Image generation（OpenAI）
• Nano Banana image generation | Gemini API（Google AI for Developers）
• Squoosh（Google Chrome Labs）

この記事は、Webサイトの動く部品集 AETHER Motion の制作チームが書いています。