JPEG XL (JXL)とは？JPEGの未来を担う画像フォーマット
JPEG XLとは一体何か
JPEG XLは、ファイル拡張子「.jxl」で識別される画像コーデックで、2022年にISO/IEC 18181として規格化されました。開発したのは、1992年のオリジナルのJPEG規格を策定したのと同じ委員会であるJoint Photographic Experts Groupです。Googleが初期のPIKコーデックから提供した技術と、Cloudinaryが持ち込んだFUIF（Free Universal Image Format）の技術協力のもとで進められました。その結果、JPEGだけでなく、PNG、GIF、さらにはWebPさえも、ほとんどの実用的なユースケースで置き換えることを目指してゼロから設計されたフォーマットが誕生しました。 その名前は誤解を招くかもしれません。JPEG XLは単にJPEGを高画質にしたものではありません。全く新しいビットストリームとコンテナフォーマットなのです。.jxlファイルは.jpgファイルと構造的な類似点を共有していないため、古いソフトウェアではアップデートなしに開くことはできません。このコーデックは、ロッシー（非可逆）圧縮とロスレス（可逆）圧縮の両方、チャンネルあたり最大32ビットのHDR（ハイダイナミックレンジ）カラー、Display P3やRec. 2100を含む広色域、アルファ透明度、アニメーション、さらにはレイヤー画像までサポートしています。これは以前はTIFFやPSDのようなフォーマットが必要だった機能セットです。 戦略的に最も賢い機能の一つが、ロスレスJPEGトランスコーディングです。既存の.jpgファイルがある場合、JPEG XLはそれを通常20～22%小さい.jxlファイルとして再エンコードでき、後からその.jxlファイルから元のJPEGをバイト単位で完全に復元できます。これは、写真家やアーカイブが、元のJPEGデータを永久に捨てることなくストレージコストを削減できることを意味します。他の次世代フォーマットにはない、実用上の大きな利点です。
JXLとJPEG、WebP、AVIFの圧縮率の比較
圧縮効率は、JPEG XLが技術的な優位性を最も明確に示す点です。同等の視覚品質で比較した場合、JXLは画像の内容や品質ターゲットにもよりますが、ファイルサイズにおいて常にオリジナルのJPEGを35～60%上回る性能を発揮します。つまり、JPEGで500KBの写真が、JXLではほとんどの人がオリジナルと見分けがつかない品質レベルで、約280～325KBになる可能性があるということです。 Googleが2010年に発表し、10年間のウェブ標準となったWebPと比較すると、JXLは写真において同等品質で約20～30%効率的です。ブラウザのサポートではまだWebPに大きなアドバンテージがありますが、JXLの圧縮率の向上は、このトレードオフを検討する価値があるほど大きいです。 より興味深い比較対象は、AV1ビデオコーデックをベースにしたAVIFです。AVIFとJXLは、シナリオによって一長一短があります。AVIFは非常に低いビットレート（重度に圧縮されたサムネイルなど）で優位に立つ傾向がありますが、JXLは中～高画質レベルでより良い性能を発揮し、エンコードも著しく高速です。Cloudinaryが2023年に発表したベンチマークによると、参照エンコーダーであるlibjxlを使用した場合、JXLは高解像度の写真を品質80で約0.3秒でエンコードしたのに対し、AVIFが同等の品質を達成するには数秒を要しました。これは、画像を大規模にエンコードするサービスにとっては非常に大きな差です。 また、JXLはテキストやグラフィックス、イラストの扱いもAVIFより優れています。AVIFはビデオコーデック由来の特性から、シャープなエッジにブロックノイズが発生することがあります。写真とシャープなテキストの両方を含む混合コンテンツのドキュメント（PDFのページなどを想像してください）では、一般的にJXLの方が信頼性の高い選択肢です。ロスレスJXLはロスレスWebPよりも大幅に効率的で、写真コンテンツではPNGと競合し、多くの合成グラフィックスではPNGを上回ります。
ブラウザとソフトウェアのサポート状況：ありのままの現状
ここからは、熱意を現実に合わせる必要があります。2026年半ばの時点で、JPEG XLのサポートは広まっていますが、まだ普遍的とは言えず、そのギャップは重要です。 ブラウザ側では、SafariがSafari 17（2023年9月リリース）で完全なJXLサポートを追加しました。これにより、すべての現行iPhone、iPad、Macが対応しています。FirefoxはFirefox 113（2023年5月）でJXLサポートをデフォルトで有効にしました。目立つ未対応はChromeです。Googleは2023年初頭のChrome 110で、「エコシステムからの十分な関心」がないとして実験的なJXLサポートを削除しました。世界のブラウザ市場シェアの約65%を占めるChromeのこの決定は、大きな論争を巻き起こしました。EdgeやBraveといったChromiumベースのブラウザもChromeに追随し、サポートを中止しました。この記事の執筆時点では、ChromeはJXLを再有効化しておらず、ウェブユーザーの大部分はプラグインなしではブラウザで.jxlファイルを表示できません。 デスクトップソフトウェア側では、状況はより良好です。Adobe Photoshopはバージョン25.0（2023年10月リリース）でJXLの読み込みと書き出しのサポートを追加しました。「ファイル > 書き出し > Web用に保存」から形式ドロップダウンでJXLを選択できます。GIMPはプラグイン経由でJXLをサポートしています。macOS 14以降のAppleのプレビューアプリと写真アプリは、JXLファイルをネイティブで開くことができます。Windows 11は2024年のアップデートで、フォトアプリを通じてJXLのデコードサポートを追加しました。 プロの写真ワークフローでは、Darktable、RawTherapee、Capture Oneといったツールが様々なレベルでJXLの書き出しをサポートしています。「サポート」という言葉が、完全なラウンドトリップ編集から読み取り専用の表示まで、あらゆる意味を持つ可能性があるため、JXLベースのアーカイブワークフローに移行する前には、特定のバージョンのノートを確認してください。
今、実際にJXLを使うべきなのは誰か
ブラウザのサポートにギャップがあることを考えると、「すべてをJXLに切り替えよう」という画一的なアドバイスは無責任でしょう。このフォーマットは特定のコンテキストでは非常に理にかなっていますが、そうでない場合もあります。 JXLはアーカイブストレージとして優れた選択肢です。もしあなたがJPEGファイルのライブラリを管理している写真家なら、ロスレスJPEGトランスコーディングパスを使ってJXLに変換することで、品質を一切損なうことなくアーカイブを小さくでき、後で元のJPEGを復元することも可能です。平均4MBのJPEGが10万枚あるライブラリ（合計400GB）は、画像データを一切破棄することなく、JXLで約310～320GBにまで縮小できます。現在のクラウドストレージの価格を考えれば、これは継続的なコスト削減として意味のあるものです。 また、JXLはクライアントを制御できるアプリベースの画像配信にも適しています。ネイティブのiOSやmacOSアプリを開発している場合、Appleのプラットフォームがネイティブでサポートしていることを知っているので、安心してJXLアセットを配信できます。レンダリングエンジンを自社で管理しているサーバーサイドのPDF生成パイプラインでも同様です。 一般的なウェブでの利用については、判断がより難しくなります。もしあなたのアクセス解析で、オーディエンスの大部分がデスクトップやAndroidのChromeを使用していることがわかった場合（これは非常によくあるケースです）、フォールバックなしでJXLを提供すると、それらのユーザーには画像が壊れて表示されてしまいます。標準的なアプローチは、HTMLのpicture要素を使い、JXLソースとWebPやJPEGのフォールバックを用意して、ブラウザが処理できるものを選択させる方法です。これにより実装は複雑になりますが、サポートしているブラウザを利用するユーザー（その割合は増え続けています）に対しては、ファイルサイズ削減のメリットを享受できます。 メールの添付ファイルや同僚と共有するドキュメントにJXLを使うのは、まだ時期尚早です。ほとんどのメールクライアントやドキュメントビューアはJXLをレンダリングせず、技術に詳しくない相手に.jxlファイルを送ると、混乱を招く可能性が高いです。
CocoConvertでJXLへの変換、JXLからの変換を行う
CocoConvertはJPEG XLの双方向変換をサポートしています。JPEG、PNG、WebP、TIFFといった一般的なフォーマットをJXLに変換することも、JXLファイルをJPEG、PNG、WebPに変換して、まだこのフォーマットをサポートしていないソフトウェアとの互換性を確保することもできます。 CocoConvertでJPEGをJXLに変換するには、変換ページでファイルをアップロードし、出力フォーマットとしてJXLを選択し、品質設定を選びます。品質スライダーはlibjxlのdistanceパラメータに対応しており、distance 0は数学的にロスレス、distance 1.0はほとんどの写真コンテンツで視覚的にロスレスと見なされ、distance 3.0はファイルをより小さくしますが、よく見るとわずかな圧縮がわかります。もし迷ったら、CocoConvertの0～100スケールでの品質85が、およそdistance 1.0に相当し、写真のデフォルトとして妥当な設定です。 元のJPEGを完全に再構築できるロスレスJPEGトランスコーディング機能については、CocoConvertは現在、これを別のオプションとして提供していません。これは正直に認めるべき現在の制限事項です。真のロスレスJPEGトランスコーディングは、ソースファイルが変換パイプラインを通じて変更されないことを要求しますが、CocoConvertの現在のアーキテクチャは元のビットストリームをラップするのではなく、画像を再エンコードします。もしビットパーフェクトなJPEGの保存が要件であれば、`--lossless_jpeg=1`フラグを付けた`cjxl`（libjxl参照実装の一部）のようなコマンドラインツールが適切な選択です。 JXLをJPEGやPNGに戻す変換はCocoConvertで簡単に行え、まだJXLをサポートしていないソフトウェアを使っている同僚とファイルを共有する必要がある場合に便利です。.jxlファイルをアップロードし、ターゲットフォーマットを選択して、結果をダウンロードしてください。一度に複数のファイルを処理するためのバッチ変換も利用可能で、ウェブ展開用にJXLアセットのフォルダ全体をWebPに変換するような場合に実用的です。
知っておくべき技術的な特徴
圧縮率以外にも、JPEG XLには古いフォーマットと一線を画すいくつかの技術的な能力があり、特定のユースケースで評価する際には理解しておく価値があります。 プログレッシブデコーディングは、最も実用的な機能の一つです。JXLファイルは、ファイルデータのごく一部をデコードしただけで画像の低解像度版が利用可能になるように構成でき、データが届くにつれて品質が向上します。これはプログレッシブJPEGの仕組みと似ていますが、JXLの実装はより洗練されています。初期のプレビューは、ぼやけたフル解像度のパスではなく、適切に縮小されたバージョンです。遅い接続でのウェブ配信では、これにより体感的な読み込み時間を大幅に改善できます。 JXLはチャンネルあたり最大32ビット（JPEGの8ビットと比較して）をサポートしており、10ビットや16ビットの精度が重要なHDR写真や科学的な画像処理ワークフローに適しています。また、ICCカラープロファイルを完全にサポートしているため、現在TIFFに依存しているカラーマネジメントワークフローも、色の忠実度を損なうことなくJXLに移行できる可能性があります。 JXLのアニメーションサポートはGIFよりも高性能で、APNGやWebPアニメーションに匹敵します。各フレームは独自の表示時間を持ち、GIFの256色制限やWebPアニメーションで時折発生する互換性の問題もありません。ただし、高フレームレートのビデオのようなアニメーションでは、実際のビデオフォーマット（H.264、AV1）の方がファイルサイズは小さくなります。JXLアニメーションは、短いループするUIアニメーションや、個々のフレームの品質が重要な画像シーケンスに最適です。 最後に、JXLには「エキストラチャンネル」と呼ばれる機能があり、深度マップやサーマルデータ、カスタムのピクセル単位のメタデータをメイン画像と一緒に埋め込むことができます。これは今日ではニッチな機能ですが、カメラが単なるRGBフレーム以上のものをキャプチャするコンピュテーショナルフォトグラフィーのアプリケーションにおいて、このフォーマットを有利な立場に置くものです。
JXLはこれからどうなるのか
JPEG XLの今後の軌跡は、GoogleがChromeでどう動くかに大きく依存します。Chromeの市場支配力は、Googleがサポートを拒否したフォーマットがウェブでの採用に構造的な上限に直面することを意味します。公表された理由である「エコシステムの関心が不十分」というのも、支配的なブラウザがそのフォーマットをサポートしていない状況でエコシステムの関心を示すのは困難であるため、ある種循環論的です。オープンソースコミュニティや、より良い画像圧縮に金銭的な利害関係を持つCloudinaryやShopifyといった企業からの継続的な圧力があるため、状況は変わるかもしれません。 ブラウザの文脈以外では、採用は加速しています。AppleがiOS、macOS、Safari全体で完全サポートしていることは重要です。Appleデバイスはプレミアムなウェブトラフィックの大部分を占め、ハイエンドのモバイル写真のほぼすべてを占めています。Photoshopのサポートが追加されたことで、プロの写真家はツールを切り替えることなく、既存のワークフローでJXLへの明確な道筋を得ました。 JXLがISO標準化されたことも、長期的なアーカイブのユースケースにとって重要です。標準化団体、政府の公文書館、医療画像機関などは、独自規格や事実上の標準よりも、正式なISOの裏付けがあるフォーマットを採用する可能性が高いです。これにより、ウェブでの存在感がChromeのスタンスによって制約されたとしても、JXLは組織的な採用において有利な立場にあります。 今日、画像を扱うほとんどの人にとっての実践的な推奨事項は、全面的なインフラ変更を行うのではなく、情報を常に把握しておくことです。サポートが確実なアーカイブストレージやネイティブアプリの配信にはJXLを使用しましょう。ウェブでの利用にはJPEGとWebPのフォールバックを維持しましょう。そして、Chromeのリリースノートに注目してください。このフォーマットの技術的なメリットに深刻な異論はありません。問題は純粋に採用のタイミングであり、そのタイミングは、支持者が望むよりは遅いかもしれませんが、JXLに有利な方向に動いています。