Chrome 155でJPEG XLの表示が出荷されたが、画像を足すかどうかは別の判断 ── 自社の画像の出し分けと応答を確認する13項目（2026年10月時点）

目次

1. 01 何が起きたか — ChromeがJPEG XLの表示を出荷し、MDNは対応ブラウザを4つ挙げた。ただし、画像を足すかどうかは別の話である
   1. Chromeの公式ブログが、出荷を告げた
   2. 同じ日に、安定版の更新も告知された
   3. ブログが勧めていること
   4. ブログが書いていないこと
   5. 対応ブラウザは、MDNの一覧では4つ
2. 02 なぜ・背景 — 「表示できる」と「画像が届く」の間には、配信する側の決めごとがある
   1. 画像の形式を決める場所は、2つある
   2. Googleの画像の文書の一覧に、JPEG XLは載っていない
   3. ブログが挙げた「30〜50%」は、一般論である
3. 03 この記事で出てくる用語
   1. JPEG XLとimage/jxl
   2. Content-Type
   3. Acceptヘッダー
   4. Varyヘッダー
   5. picture要素、type属性、フォールバック
4. 04 型別 — 適用範囲・この記事が確かめていないこと・手順
   1. 適用範囲 — この確認が向いているサイト
   2. この記事が確かめていないこと
   3. 手順の流れは、4つに分かれる
   4. 応答を見るときの書き方
5. 05 明日、自社サイトで確認できることチェックリスト
   1. まず13項目を通して見る
   2. 観点別の内訳と、かかる時間
6. 06 代替・他の選択肢（表で）
   1. 画像の形式を、どうするかの4つの選び方
   2. picture要素の書き方の例
   3. Acceptで出し分けるとき、条件の書き方に注意が要る
   4. Varyが無いと、キャッシュが混ざることがある
   5. CDNの自動変換は、出力できる形式の一覧を見る
   6. 「足さない」ことも、記録する判断である
7. 07 当サイトで内訳と応答を確かめてみた例
   1. 数えた範囲と方法
   2. 画像ファイルは、PNGが9割だった
   3. ページのHTMLの書き方
   4. Acceptを変えた応答
   5. この例の限界
8. 08 このテーマの、これまで
   1. 画像の形式と、画像SEOの過去の記事
   2. 見た目と実際を分けて確かめた記事
9. 09 この記事のまとめ

01 何が起きたか — ChromeがJPEG XLの表示を出荷し、MDNは対応ブラウザを4つ挙げた。ただし、画像を足すかどうかは別の話である

Chromeの公式ブログが、出荷を告げた

Chrome for Developersのブログに、「Shipping JPEG XL in Chrome（訳: ChromeでJPEG XLを出荷する）」という記事がある。日付は2026年10月6日で、書き出しの文は次のとおりである。

"We're excited to announce that Chrome is shipping decoding support for the JPEG XL (.jxl) image format starting from Chrome 155."

（訳: JPEG XL（.jxl）の画像形式について、Chrome 155から、復号（画像のデータを表示できる形に戻すこと）への対応を出荷することを、うれしく発表します。）

この文が書いているのは、ブラウザがJPEG XLの画像を表示できるようになるということである。サイトの画像が、自動でJPEG XLに変わる話ではない。ベータの段階の話は、当サイトの記事「Chrome 155のベータにJPEG XLの表示が入ったが、「入った」と「自社で足す」は別の判断 ── 配信している画像の形式を確認する13項目（2026年10月時点）」で書いた。この記事は、出荷が告げられたあと、配信する側が何を確かめるかに絞る。

同じ日に、安定版の更新も告知された

Chromeの公式リリース情報「Stable Channel Update for Desktop」の2026年10月6日付の記事には、次の文がある。

"The Stable channel has been updated to 155.0.8059.39/.40 for Windows and Mac and 155.0.8059.39 to Linux which will roll out over the coming days/weeks."

（訳: 安定版チャンネルは、WindowsとMac向けが155.0.8059.39/.40、Linux向けが155.0.8059.39に更新された。今後の数日から数週間かけて順次配信される。）

「順次配信される」とあるので、訪問者のChromeが155になる時期は、人によって違う。

ブログが勧めていること

ブログは、配信する側に向けて、次のように書いている。

"In general, we recommend trying both AVIF and JPEG XL to get the best results."

（訳: 一般に、最良の結果を得るために、AVIFとJPEG XLの両方を試すことをおすすめします。）

ブログは、続けて、JPEG XLが特に役に立つのは、写真など、品質を保ちたい画像の場合だと考えている、と書いている。AVIFと比べて選ぶことを勧めていて、「すべての画像をJPEG XLにする」とは、書いていない。

ブログが書いていないこと

このブログの本文には、サイトの管理者がすぐに知りたい、次の点が出てこない（本文を全部読んで確かめた）。画像の取得時に、ブラウザが送る「Accept」という欄に、image/jxlが入るのか。CDN（画像などを、利用者の近くから配信するサービス）や、画像を変換するプラグインが、JPEG XLを出せるのか。検索エンジンが、JPEG XLの画像を、どう扱うのか。これらは、配信する側が、自分で確かめるしかない。

対応ブラウザは、MDNの一覧では4つ

Mozillaの開発者向け文書MDNの「Image file type and format guide（訳: 画像のファイルの種類と形式の手引き）」は、JPEG XLの項で、ブラウザの対応を次のように書いている（このページの最終更新は2026年10月8日と表示されていた。10月13日に開いた版である）。

同じ項には、「Browser support is not yet universal.（訳: ブラウザの対応は、まだ、すべてには広がっていない。）」とも書かれている。4つのブラウザが対応しても、訪問者全員が見られるわけではない。版が古い人には、従来の形式を届ける必要がある。

02 なぜ・背景 — 「表示できる」と「画像が届く」の間には、配信する側の決めごとがある

画像の形式を決める場所は、2つある

サイトの画像が、どの形式で利用者に届くかは、2つの場所のどちらかで決まる。1つ目は、ページのHTMLである。picture要素の中に、形式ごとの画像を並べておけば、ブラウザが、自分に合うものを選ぶ。2つ目は、画像のURLへの応答である。同じURLに、ブラウザが送るAcceptの値を見て、サーバーやCDNが、返す形式を変える方法である。どちらの場所で決めているかで、確認する中身が変わる。

Googleの画像の文書の一覧に、JPEG XLは載っていない

検索エンジンの側も確認が要る。Googleの「Google Image SEO best practices（訳: Google画像検索のSEOのベストプラクティス）」は、対応する形式を次のように書いている。2026年10月13日に開いた版である。

"Google Search supports images referenced in the src attribute of img in the following file formats: BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF."

（訳: Google検索は、imgのsrc属性で参照された画像について、次のファイル形式に対応しています。BMP、GIF、JPEG、PNG、WebP、SVG、AVIF。）

この文は、JPEG XLを「使えない」とは書いていない。一覧に載っていない、という事実だけが読み取れる。同じ文書は、picture要素を使うときに、imgのsrcにフォールバックのURLを必ず書くことを、勧めている。

ブログが挙げた「30〜50%」は、一般論である

Chromeのブログは、JPEG XLの特長として、次のように書いている。

"It offers 30-50% better compression than JPEG, lossless compression, built-in HDR support, lossless JPEG transcoding, and more."

（訳: JPEGより30〜50%よい圧縮、ロスレス圧縮、HDRへの標準対応、ロスレスのJPEG再変換などを備えています。）

この数字は、一般的な説明であり、どの画像を、どの条件で比べたかは、本文に書かれていない。自社の画像で、同じだけ小さくなるとは限らない。この記事も、自社の画像で測ってはいない。

03 この記事で出てくる用語

JPEG XLとimage/jxl

JPEG XLは、MDNによると、ロスあり圧縮（細かい部分を捨てて小さくする）とロスなし圧縮の両方、段階的な復号、HDR（明るさの幅が広い表現）、透明、アニメーションに対応している。種類の名前は「image/jxl」、拡張子は「.jxl」である。MDNは、既存のJPEGの画像を、元に戻せる形で変換できるとも書いている。

Content-Type

画像などを返す応答に付く、中身の種類を示す欄である。画像なら、PNGはimage/png、JPEGはimage/jpegと返る。新しい形式の.jxlのファイルを置いたとき、この欄に何が返るかは、サーバーの設定で決まる。この記事は、サーバーごとの違いまでは確かめていない。置ける場合は、置いたあとに、この欄を見て、image/jxlと返っているかを確かめる。

Acceptヘッダー

ブラウザが画像を要求するとき、「この種類なら受け取れる」という一覧を、Acceptという欄に付けて送る。サーバーやCDNは、この一覧を見て、返す形式を選べる。この仕組みを、コンテンツネゴシエーション（返す中身を、要求の条件に合わせて選ぶ仕組み）と呼ぶ。

Varyヘッダー

同じURLが、要求の条件で別の中身を返すとき、応答に付ける欄である。キャッシュ（一度取った画像を使い回す仕組み）が、条件の違う応答を取り違えないようにする。06章で、MDNの文を引く。

picture要素、type属性、フォールバック

picture要素は、同じ画像の別の版を、source要素で並べておく入れ物である。source要素のtype属性に、その版の種類（たとえばimage/jxl）を書くと、ブラウザは、対応していない種類の版を飛ばす。MDNは、次のように書いている。

"If the user agent does not support the given type, the <source> element is skipped."

（訳: ユーザーエージェント（ブラウザ）が、書かれた種類に対応していなければ、そのsource要素は飛ばされる。）

対応するsourceが無いときは、最後のimg要素のsrcの画像が使われる。この動きを、フォールバックと呼ぶ。新しい形式を足すときの安全網である。

04 型別 — 適用範囲・この記事が確かめていないこと・手順

適用範囲 — この確認が向いているサイト

自社で画像を配信しているサイトが、すべて対象である。画像を自分で置いているサイトも、CMS（サイトの管理システム）のメディア機能を使っているサイトも、CDNを前に置いているサイトも含む。JPEG XLを足す予定がないサイトでも、「いまの形式の内訳を数える」「出し分けの条件を書き出す」は、役に立つ。新しい形式が、また出てきたときにも、同じ確認が使えるからである。

この記事が確かめていないこと

確かめていないことは、4つある。1つ目は、Chrome 155が、画像の取得で送るAcceptに、image/jxlを入れるかどうかである。MDNの一覧に載っている値は、06章で見るが、155の実際の送信は試していない。2つ目は、JPEG XLに変えたとき、自社の画像がどれだけ小さくなるかである。3つ目は、検索エンジンが、JPEG XLの画像をどう扱うかである。Googleの文書の一覧に載っていない、という事実だけを書いた。4つ目は、Cloudflare以外のCDNやCMSの対応状況と、Firefox 158とEdge 155の公開の日付である。

手順の流れは、4つに分かれる

手順は、4つに分かれる。内訳を数えるのは、ページのHTMLを開いて、画像の形式と、picture要素の使い方を数える作業である。応答を見るのは、画像のURLに、Acceptの値を変えて要求し、返ってくる種類と、Varyの有無を見る作業である。仕組みを調べるのは、サーバー・CDN・CMSの、出し分けの条件と、出力できる形式を書き出す作業である。決めるのは、「足す」「足さない」「様子を見る」の1つを選び、理由と見直す日を書く作業である。

応答を見るときの書き方

応答は、コマンドラインのcurlで見られる。Acceptの値を変えて、3回、同じ画像のURLを取り、返ってきた欄を比べる。テスト用の場所に.jxlのファイルを1枚置ける場合は、そのURLのContent-Typeがimage/jxlかも見る。

curl -s -o /dev/null -D - -H "Accept: image/jxl,image/avif,image/webp,*/*;q=0.5" https://example.com/photo.png

この例の「-D -」は、応答の欄を画面に出す指定、「-o /dev/null」は、画像の本体を捨てる指定である。見るのは、「Content-Type」と「Content-Length」と「Vary」の3つである。Acceptを変えても、3つが変わらなければ、そのURLは、出し分けをしていない。

05 明日、自社サイトで確認できることチェックリスト

まず13項目を通して見る

以下は、明日、自社のページを3つ開いて、画像の配信を確かめるための項目である。チェックの状態はブラウザに保存され、サーバーには送信されない。1〜5番目がページのHTMLの確認、6〜7番目が訪問者のブラウザと、Acceptの確認、8〜9番目が画像のURLへの応答の確認、10〜11番目が出し分けの条件と、変換の設定の確認、12番目が検索などに使う画像の確認、13番目が、足すかどうかの判断である。

• トップページ・記事か商品のページ・一覧のページの3つを選び、URLを表に書く
• 3ページそれぞれで、ブラウザの「ページのソースを表示」を開き、「<img」を検索して、見つかった本数を表に書く
• 3ページの<img>のsrcを、拡張子（png・jpg・gif・svg・webp・avif・jxl）に分けて、形式ごとの本数を表に書く
• 3ページで「<picture」を検索し、見つかった本数と、type属性が付いたsourceの本数を、別々に表に書く
• pictureがあるページでは、最後の<img>にsrcが付いているかを確かめ、「ある」か「ない」を表に書く
• アクセス解析で、直近30日のブラウザ別の訪問数の上位5つを書き、Chrome・Edge・Safari・Firefoxの合計の割合（%）を書く
• Chromeの開発者ツールのネットワークの画面で、画像1枚の要求を選び、要求のAcceptの値を一字一句そのまま書き写し、ブラウザの版もあわせて書く
• 同じ画像のURLに、curlでAcceptを「*/*」と「image/jxl,*/*」の2通りにして要求し、Content-TypeとContent-Lengthが2回で違うかを書く
• 応答にVaryがあるかを見て、あれば値を、なければ「なし」を書く
• サーバー・CDN・CMSのプラグインの、画像を出し分ける条件を開き、条件に使っているAcceptの文字列（image/jxl・image/avif・image/webp）を、あるだけ書き出す。出し分けをしていなければ「なし」と書く
• CDNかCMSの画像変換の設定で、出力できる形式を全部書き写し、JPEG XLが「ある」か「ない」かを書く
• og:image・構造化データのimage・faviconに指定している画像の形式を書き、Googleの文書の7形式に入っているかを、○か×で書く
• 「足す」「足さない」「様子を見る」の1つを選んで、理由を1行と、見直す日（たとえば、訪問者のChrome 155以上の割合を測り直す日）を、表の上に書く

観点別の内訳と、かかる時間

すべてに目を通す時間は、あわせて50分ほどである（筆者の見積もりで、ページの画像の数や、設定画面に入る手間で変わる）。内訳は、1〜5番目が15分、6〜7番目が10分、8〜9番目が10分、10〜11番目が10分、12〜13番目が5分である。形式を足す予定がないサイトは、1〜4番目と6番目だけでも、「いまの内訳」と「訪問者のブラウザ」が、数字で手元に残る。6番目は、ブラウザの種類ごとの合計だけを見れば足りる。

06 代替・他の選択肢（表で）

画像の形式を、どうするかの4つの選び方

サイトの管理者が選べる道は、1つではない。4つに分けて、公式の文書に書かれていることと、先に確認することを並べた。公式が勧める順番ではなく、筆者の整理である。

この表から言えるのは、4つの選び方のどれでも、先に必要なのは「自社の内訳」と「応答の確認」だということである。表の中身は、2026年10月13日に開いた文書の記載であり、将来の更新で変わる可能性がある。

picture要素の書き方の例

JPEG XLを足すときの、picture要素の例を示す。ファイル名と説明文は、例のために付けたものである。

<picture>
  <source srcset="photo.jxl" type="image/jxl">
  <source srcset="photo.avif" type="image/avif">
  <img src="photo.jpg" alt="店の入口を正面から写した写真" width="1200" height="630">
</picture>

この形では、image/jxlに対応していないブラウザは、そのsourceを飛ばし、最後のimgに進む。MDNの画像形式の手引きは、「If you need to support browsers that don't allow WebP, AVIF, or JPEG XL, use the <picture> element to provide a PNG or JPEG fallback.（訳: WebP、AVIF、JPEG XLに対応しないブラウザにも対応する必要があるなら、picture要素を使って、PNGかJPEGのフォールバックを用意してください。）」と書いている。最後のimgは、必ず残す。

Acceptで出し分けるとき、条件の書き方に注意が要る

サーバーやCDNが、Acceptを見て形式を選ぶ方法は、picture要素より、HTMLを書き換えずに済む利点がある。ただし、条件の書き方に注意が要る。MDNの「List of default Accept values（訳: Acceptの既定値の一覧）」には、画像の要求の既定値として、次の3つが載っている（2026年10月8日に更新されたと表示されていた版である）。

この一覧で、image/jxlの文字が書かれているのは、Firefox 158以降の行だけである。ChromeとEdgeの行は、「121以降」と書かれていて、155で値が変わったかどうかは、この一覧からはわからない。Chromeのブログにも、Acceptの話は出てこない。サーバーの条件が「Acceptにimage/jxlの文字があれば、JPEG XLを返す」という書き方なら、Chrome 155の画像の要求にその文字が無かった場合、Chromeには、従来の形式が返る。「image/*」は、種類を問わない書き方で、「image/jxlに対応する」という意味にはならない。実際の送信は、05章の7番目で確かめられる。

Varyが無いと、キャッシュが混ざることがある

同じURLで、Acceptによって別の形式を返すなら、Varyの欄が要る。MDNの「Vary header（訳: Varyヘッダー）」は、次のようにも書いている。

"The same Vary header value should be used on all responses for a given URL, including 304 Not Modified responses and the "default" response."

（訳: あるURLに対する、すべての応答に、同じVaryの値を使うべきである。304 Not Modified（更新されていない、という応答）や、「既定の」応答も含む。）

出し分けは、手軽なぶん、キャッシュの設定との組み合わせを確かめる必要がある。MDNの「Content negotiation」も、同じ方法の欠点として、共有のキャッシュの効率が下がることを挙げている。05章の8〜9番目は、そのための項目である。

CDNの自動変換は、出力できる形式の一覧を見る

CDNの自動変換に任せているサイトは、変換先の形式が、CDNの側で決まっている。Cloudflareの画像変換の文書は、formatの値のautoについて、次のように書いている。

"Automatically serves the most efficient format that the requesting browser supports."

（訳: 要求したブラウザが対応する、もっとも効率のよい形式を、自動で返す。）

この文書のformatの値の一覧は、2026年10月13日に開いた版で、auto・avif・webp・jpeg・baseline-jpeg・jsonの6つだった。この6つの中に、JPEG XLは入っていない。同じ文書の、Workerの例は、Acceptにavifやwebpの文字があるかで、変換先を決める書き方になっている。ブラウザがJPEG XLに対応しても、CDN側が、その形式を出せるように作られていなければ、自動では変わらない。これは、Cloudflare以外のCDNでも、確かめる価値がある。

「足さない」ことも、記録する判断である

足さない、と決めた日にも、理由を1行、書いておく。たとえば「訪問者のChrome 155以上の割合が、まだ低い」「CDNの形式の一覧にないので、見送る」などである。書いておくと、半年後に、同じ議論をやり直さずに済む。見直す日を、日付で決めておくと、「様子を見る」が、永久に続くことも避けられる。

07 当サイトで内訳と応答を確かめてみた例

数えた範囲と方法

当サイト（WEBサイトサポート）の、公開している画像ファイルを、2026年10月13日に数えた。数えた範囲は、サイトの画像を置いている3つの場所の全体（730ファイル）である。あわせて、トップページ、AI Ronのブログの一覧ページ、解説記事1本の、3ページのHTMLを取って、imgとpictureの書き方を数えた。HTMLのコメントの中は、数えなかった。さらに、画像2枚に、Acceptの値を変えて要求し、応答を比べた。

画像ファイルは、PNGが9割だった

形式で数えた結果は、PNGが660、JPEGが52、GIFが13、SVGが5だった。730ファイルのうち、PNGが90.4%、JPEGが7.1%である。WebPとAVIFとJPEG XLは、0だった。当サイトは、この記事を書いた時点で、新しい形式を1つも配信していない。

ページのHTMLの書き方

トップページのimgは70本で、srcの拡張子の内訳は、PNGが49、JPEGが17、SVGが3、GIFが1だった。picture要素は24個あり、中のsource要素も24個だった。24個のsourceは、どれも、type属性が付いていなかった。付いていたのは、画面の幅で画像を切り替えるための条件だけで、形式で切り替える使い方は、していなかった。AI Ronのブログの一覧ページは、imgが39本（PNGが33、SVGが6）で、picture要素は30個、type属性が付いたsourceは0だった。解説記事1本は、imgが8本（PNGが5、SVGが3）で、picture要素はなかった。

Acceptを変えた応答

トップページに載っているPNGの画像1枚に、Acceptを3通り付けて取り直した。3通りは、「*/*」、MDNの一覧にあるChromeの画像用の値、「image/jxl」を先頭に置いた値である。結果は、3回とも、Content-TypeがPNGで、Content-Lengthが94,804バイトで同じだった。応答に、Varyは付いていなかった。JPEGの画像1枚にも、「image/jxl」を先頭に置いたAcceptで取ったが、Content-Typeはjpegのままで、Varyは付いていなかった。当サイトの画像は、Acceptの違いで、返す形式を変えていない。

この例の限界

これは、画像の置き場3つと、3ページと、画像2枚での確認である。ほかの画像が同じ応答になるかは、確かめていない。.jxlのファイルを置いたときの応答も、試していない（公開中のサイトに、試験用のファイルを置かないためである）。JPEG XLに変えたときのサイズも、測っていない。当サイトがJPEG XLを足すかどうかは、この記事を公開した時点では、決めていない。確かめた内訳をもとに、見直す日を決めて、結果は、別の記事に書く。

08 このテーマの、これまで

画像の形式と、画像SEOの過去の記事

当サイトには、画像の形式を、別の角度から確かめた記事がある。Chrome 155のベータにJPEG XLの表示が入ったが、「入った」と「自社で足す」は別の判断 ── 配信している画像の形式を確認する13項目（2026年10月時点）は、ベータの段階で、画像の形式の内訳とAcceptへの応答を確かめた記事で、この記事の前編にあたる。画像SEOの基本 ── alt属性・次世代フォーマット・遅延読み込みを、公式ガイドで確認する14項目（2026年9月時点）は、次世代の形式と遅延読み込みを、Googleの公式のガイドで確かめた記事である。検索結果のファビコンにSVGとWebPは使えない ── Googleが対応する7つの画像形式を確認する13項目（2026年9月時点）は、検索結果のファビコンに使える形式の話で、Googleの対応する形式の一覧を、別の用途で確かめた。

ブログでは、検索は「探す」から「作る」に変わる日 — Google画像検索25周年リニューアルとAI Overviews画像生成、今週やるべき画像SEO点検が、Google画像検索の変化と、画像SEOの点検を扱った。

見た目と実際を分けて確かめた記事

「見た目では同じでも、実際は違う」という確かめ方は、この記事の「Acceptを変えて、応答を比べる」と同じ形である。見た目では区別できない ── 時刻の記録を読んだら、画像147本のうち45本が「運ばれてきた」側だったは、画像を時刻の記録で分けて数えた記事である。外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけたは、外から取った画面が、目当ての画面とは限らなかった話で、応答の確認でも、同じ注意が要る。