JPEG-XL復活とPQC移行のMerkle Tree Certificates、Chrome 145〜146の変更点

Chrome 145〜146で入った変更を追いかけていたら、JPEG-XL復活からPQC移行、AIエージェントAPI、ゼロデイまで、1つのブラウザの話とは思えないくらい方向性がバラバラだった。それぞれ掘り下げてみた。

JPEG-XL復活（Chrome 145）

2022年にChromeから削除され、大きな反発を招いたJPEG-XLがChrome 145（2026年2月10日安定版リリース）で復活した。削除時の理由は「エコシステムの関心が十分でない」だったが、2023年にApple Safari 17がサポートしたことで風向きが変わった。

復活にあたってC++のlibjxlではなくRustベースのデコーダー「jxl-rs」を採用している。Chromium全体でRust採用が進んでいる流れの一環だ。

ただし現時点では chrome://flags/#enable-jxl-image-format でフラグを有効にしないと使えない。デフォルト有効化のタイムラインは未発表。

フォーマット比較

DebugBearのベンチマーク（990KBのJPEG写真）:

フォーマット	サイズ	JPEG比	エンコード速度	プログレッシブ
WebP	700KB	-29%	最速	なし
AVIF	507KB	-49%	遅い	なし
JPEG XL	472KB	-52%	中〜速い	あり

Cloudinaryの大規模テスト（40,000枚以上）ではJPEG XLはAVIFより20%小さく、エンコード速度は2.5倍速いという結果が出ている。もう1つの強みは既存JPEGからのロスレス再圧縮で、品質劣化ゼロで20〜30%削減できる。

cjxlで変換する

libjxlに同梱されている cjxl コマンドで変換できる。macOSなら brew install jpeg-xl、Ubuntuなら apt install libjxl-tools でインストール。

# 視覚的にロスレス（distance 1.0）
cjxl -d 1.0 input.png output.jxl

# Web向け（やや圧縮重視）
cjxl -d 2.0 input.png output.jxl

# 完全ロスレス
cjxl -d 0 input.png lossless.jxl

# 既存JPEGのロスレス再圧縮（品質劣化ゼロ、元のJPEGに完全復元可能）
cjxl input.jpg output.jxl

# 最大圧縮（effort 9、遅いが最小サイズ）
cjxl -d 1.0 -e 9 input.png output.jxl

distanceは0がロスレス、1.0が視覚的にロスレス、1.0〜2.0がWeb向け、2.0〜3.0がサイズ重視。

バッチ変換にはGNU parallelが便利。1画像1スレッドで複数同時処理する方が、1画像にマルチスレッドを割くより効率的。

parallel -j16 cjxl -e 9 --num_threads=0 -d 1.0 {} {.}.jxl ::: *.png

ブラウザ対応と実運用

ブラウザ	対応状況
Safari	17+でネイティブ対応（アニメーション・プログレッシブは未対応）
Chrome	145でRustデコーダ搭載、フラグ有効化が必要
Firefox	jxl-rs統合作業中、安定版タイムラインなし

全ブラウザのJXL対応率は約12%（主にSafariのシェア分）。Interop 2026でApple、Google、Microsoft、Mozillaの全社がJPEG XLを「調査項目」として参加しており、クロスベンダーでの対応意思はある。

今すぐWebで使うなら <picture> 要素でフォールバックを組む。

<picture>
  <source srcset="image.jxl" type="image/jxl">
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="description">
</picture>

Node.jsのsharpは実験的にJXL対応しているが、プリビルトバイナリには含まれていない。自前でlibvipsをlibjxl付きビルドする必要があり、プロダクションでは使えない状態。JXL変換が必要なら cjxl をchild_processで呼ぶのが現実的。

Chromeのデフォルト有効化とsharpのプリビルト対応が揃うまではWebP/AVIFが実運用の主力になる。

TLS暗号はRSAから楕円曲線を経てPQCに来た

RSA時代

TLS（SSL）の鍵交換は長らくRSAが担っていた。クライアントがランダムなプリマスターシークレットを生成し、サーバーの公開鍵で暗号化して送る。サーバーが秘密鍵で復号し、双方が対称鍵（AES等）を導出する。

鍵サイズは時代とともに膨らんだ。1990年代末は512ビットが標準だったが、1999年に512ビットRSAが公開解読され、2009年には768ビットも因数分解された。現在の標準は2048ビット（256バイト）で、4096ビットにするとTLSハンドシェイクが6〜7倍遅くなるため実用上は2048ビットが圧倒的多数。

RSA鍵交換の致命的な弱点はForward Secrecyがないことだ。サーバーの秘密鍵が漏洩すると、過去に記録された全通信を復号できる。

楕円曲線（ECC）への移行

楕円曲線暗号はRSAと同等のセキュリティ強度をはるかに短い鍵で実現する。

セキュリティ強度	RSA	ECC
128ビット	3,072ビット（384バイト）	256ビット（32バイト）
192ビット	7,680ビット	384ビット
256ビット	15,360ビット	521ビット

ECC P-256の公開鍵はわずか32バイト。RSA-3072の384バイトと比べて12分の1だ。速度もCloudflareのベンチマークでECC-256はRSA-3072より20〜116倍速い。

2011年にGoogleがgmail.comやdocs.google.comでECDHE（Elliptic Curve Diffie-Hellman Ephemeral）をデフォルト有効化した。ECDHEは毎回一時的な鍵ペアを生成するため、サーバーの長期秘密鍵が漏洩しても過去の通信は安全（Forward Secrecy）。2013年のSnowden事件後にForward Secrecyの重要性が広く認識され、2018年のTLS 1.3（RFC 8446）ではRSA鍵交換が完全に廃止された。

量子コンピュータが両方壊す

ここまでの話だと楕円曲線が最強に見えるが、量子コンピュータのShorのアルゴリズムはRSA（素因数分解）とECC（離散対数問題）の両方を効率的に解いてしまう。

皮肉なのは、ECCの方がRSAより量子攻撃に弱いことだ。Shorのアルゴリズムに必要な量子ビット数は鍵のビット長に依存する。

アルゴリズム	必要な論理量子ビット数
RSA-2048	6,190
ECC P-256	2,619
ECC P-384	3,901

古典コンピュータに対してはECC-256とRSA-3072は同等の安全性だが、量子攻撃ではECCの「鍵が短い」という利点がそのまま弱点になる。

2025年時点で暗号解読が可能な量子コンピュータは存在しないが、問題は「Harvest Now, Decrypt Later（HNDL）」だ。今の暗号化通信を記録・保存しておき、将来の量子コンピュータで解読する。米国DHS、英国NCSC、EU ENISAがいずれも「敵対的なアクターが既にデータ収集中」と公式に警告している。これがPQC移行を量子コンピュータ完成前に進める最大の理由。

Chromeは鍵交換のPQC対応を済ませている

鍵交換については既にPQC対応が進んでいる。Chrome 131（2024年11月）からNIST標準のML-KEM（旧CRYSTALS-Kyber）をX25519とのハイブリッド構成でデフォルト有効化済み。ML-KEMは格子暗号の一種で、Shorのアルゴリズムが適用できない格子上の最短ベクトル問題に安全性の根拠を置く。

Cloudflareの観測によると、2025年10月時点で人間由来のTLSトラフィックの過半数がPQC暗号化で保護されている。ハンドシェイク時間の増加は約4%。

ただしML-KEM-768の公開鍵は1,184バイトあり、X25519の32バイトと比べて大幅に増えた。鍵交換は1回のハンドシェイクで済むからまだいいが、証明書は別の問題を抱えている。

Merkle Tree CertificatesによるPQC HTTPS移行

ChromeがX.509証明書ベースのTLS PKIを段階的に廃止し、Merkle Tree Certificates（MTCs）へ移行する計画をGoogle Security Blogで発表した。

証明書のPQC対応が難しい理由

鍵交換のPQC化はChrome 131で実現したが、証明書の署名をPQCに置き換えるのは別の難題だ。ML-DSA（PQC署名アルゴリズム）の署名は3,293バイト規模になる。TLSハンドシェイクでは証明書チェーン（ルート→中間→エンドエンティティ）を丸ごと送るため、複数の署名が累積する。

QUIC接続の半数は総転送量が8KB未満で、既存証明書だけで3〜4KBを占める。ここにPQC署名を載せると小規模通信の帯域コストが深刻になる。Googleは「X.509の枠内では解決しない」と判断し、MTCsという別のアーキテクチャを採った。

MTCsの仕組み

従来のX.509はCAがドメインの証明書に個別に署名し、ブラウザが証明書チェーン全体を受け取って検証する。MTCsでは単一のCA署名が「Tree Head」をカバーし、その下に数百万の証明書がマークルツリー構造で格納される。ブラウザが必要とするのはツリー全体ではなく、軽量な「proof-of-inclusion」のみ。送信データ量はツリーのサイズによらず対数オーダーで収まるため、PQCアルゴリズムを使っても帯域への影響を最小化できる。

さらに、マークルツリーに含まれなければ証明書として機能しないため、証明書透明性（CT）が構造的に内在化される。現行CTは発行と記録が別オペレーションだが、MTCsでは「CTログに記録されていない証明書」が原理的に存在できない。

移行ロードマップ

Phase 1（現在進行中）: Cloudflareとのパイロットでリアルトラフィックにテスト。X.509フォールバック維持
Phase 2（2027年Q1）: CT Logオペレーターを招いてMTCsのパブリックインフラをブートストラップ
Phase 3（2027年Q3）: Chrome Quantum-resistant Root Store（CQRS）を確立。X.509への後退を防ぐダウングレード保護オプション提供

最速でも1年半の計画で、X.509との並行運用が長期間続く前提。FirefoxやSafariの追随は未定だが、Let’s Encryptの関係者は「MTCsは量子耐性HTTPS実装の好ましいアプローチ」とコメントしている。

Web開発者が今すぐやることは特にない。TLS 1.3を使っていれば鍵交換のPQC化はブラウザとサーバーが勝手にやってくれる。証明書側のMTC移行はCA側の話で、Let’s Encryptなどが対応すれば自動的に切り替わる。

WebMCPの宣言的API

Googleが2026年2月10日、WebMCPの早期プレビューを公開した。AIエージェントがウェブサイト上でアクションを実行するための標準プロトコルで、サイト側が「何ができるか」を宣言的に記述し、スクレイピングに依存しない統合経路を提供する。Chrome 146 Canaryで chrome://flags から有効化できる。

宣言的APIは既存のHTMLフォームに属性を追加するだけで動く。

<form
  toolname="search_products"
  tooldescription="商品を検索してフィルタリングする"
>
  <input
    type="text"
    name="query"
    toolparamdescription="検索キーワード"
  />
  <select
    name="category"
    toolparamdescription="商品カテゴリ: 'electronics', 'books', 'clothing'"
  >
    <option value="electronics">電子機器</option>
    <option value="books">書籍</option>
    <option value="clothing">衣類</option>
  </select>
  <button type="submit">検索</button>
</form>

toolname がツールの識別子、tooldescription がエージェントへの説明、各フィールドの toolparamdescription がパラメータの説明。ブラウザがこれを読み取り、AIエージェントに構造化されたツールスキーマとして提供する。

エージェントがフォームを送信すると SubmitEvent に agentInvoked プロパティが追加され、エージェント経由かどうかを判別できる。

form.addEventListener("submit", (e) => {
  e.preventDefault();
  if (e.agentInvoked) {
    // AIエージェントからの送信
    const data = new FormData(e.target);
    e.respondWith(`検索結果: ${data.get("query")} in ${data.get("category")}`);
    return;
  }
  // 通常のフォーム送信
});

JavaScript実行が必要な複雑なインタラクションには命令的APIもある。navigator.modelContext.registerTool() でツールを動的に登録する方式だ。

HNでは253ポイント・137コメントが集まり、「Googleがブラウザを通じてウェブへのアクセスを仲介する動き」として議論を呼んだ。既存のアクセシビリティ標準（ARIA）で十分という意見、サーバー側MCP（Anthropic提唱）の方が適切という意見もある。WebMCPはMCPの名前を借りているがAnthropicのプロトコルとは独立した仕様。

Gemini Auto Browse

Chrome + Geminiの統合も加速している。2026年1月28日に発表されたAuto Browseは、Chromeが自律的にスクロール、クリック、入力、ナビゲーションを実行するエージェント機能だ。旅行予約、フォーム記入、税務書類収集などのマルチステップタスクを代行する。利用にはGoogle AI Pro/Ultraサブスクリプションが必要で、米国先行。

WebMCPがサイト側の宣言インフラなら、Auto BrowseはGoogle側のエージェント実装にあたる。

Chrome 146ではGeminiサイドパネルがmacOS/Windowsで利用可能になり、閲覧中のページの要約やQ&Aに対応する。Google Driveのファイルをコンテキストとして参照する機能も追加された。

CVE-2026-2441とChromeのゼロデイ事情

2026年2月、CSSエンジンのuse-after-free脆弱性CVE-2026-2441が確認された。CVSS 8.8の高深刻度で、細工されたHTMLページ経由でサンドボックス内のリモートコード実行が可能だった。2月11日に報告され、Chrome 145.0.7632.75/76で修正。CISAのKEVカタログに2月17日追加、修正期限は3月10日。

このCVEはこのブログでも2月のCISA KEVまとめで2回取り上げている。CISAがアクティブ悪用中の脆弱性4件をKEVカタログに追加ではChrome UAFの基本情報を、CISA KEV追加の重大脆弱性4件ではBlinkのCSSエンジンがカスケード・継承・アニメーションの動的な状態変化でオブジェクトのライフタイム管理が複雑になり、UAFが繰り返し発生する構造的な問題を書いた。

3月にはMojo（Chromeのプロセス間通信システム）のゼロデイも確認されている。ロシアの組織を標的とした高度な攻撃で悪用された。CSSエンジン、V8（2月にCVE-2026-2649の整数オーバーフローも修正）、Mojoと、攻撃面が広い。Chromeのゼロデイは年間数件ペースで続いており、自動更新が有効になっているかだけは確認しておいた方がいい。

カスタマイズ可能なselect要素（Chrome 134）

Web開発者が長年待ち望んだ機能がChrome 134で実現した。appearance: base-select CSSプロパティにより、<select> のドロップダウンを画像やアニメーションを含むリッチなUIにカスタマイズできる。

従来の <select> はOSネイティブのウィジェットに依存しており、CSSでのスタイリングがほぼ不可能だった。そのため独自のドロップダウンをdivで組み、アクセシビリティを壊すのが常態化していた。

基本的な使い方

HTML側では <select> 内に <button> と <selectedcontent> を配置する。<selectedcontent> は選択中のオプションの内容をボタン内にミラーする要素。

<select id="country">
  <button>
    <selectedcontent></selectedcontent>
  </button>
  <option value="jp">
    <img src="/flags/jp.png" width="20" height="15" alt="" aria-hidden="true" />
    Japan
  </option>
  <option value="us">
    <img src="/flags/us.png" width="20" height="15" alt="" aria-hidden="true" />
    United States
  </option>
</select>

CSS側で appearance: base-select を指定してカスタマイズモードにオプトインする。

select,
::picker(select) {
  appearance: base-select;
}

/* ドロップダウンのスタイリング */
::picker(select) {
  border: 1px solid #e0e0e0;
  border-radius: 12px;
  padding: 8px;
  box-shadow: 0 8px 32px rgba(0, 0, 0, 0.12);
}

/* 矢印アイコン */
select::picker-icon {
  transition: rotate 0.3s;
}
select:open::picker-icon {
  rotate: 180deg;
}

/* オプションのスタイリング */
option {
  display: flex;
  align-items: center;
  gap: 10px;
  padding: 10px 14px;
  border-radius: 8px;
}
option:hover {
  background: #f3e8ff;
}

新しい疑似要素・疑似クラスは ::picker(select)（ドロップダウン本体）、::picker-icon（矢印）、::checkmark（選択済みマーク）、:open（開いている状態）。ネイティブのキーボード操作とスクリーンリーダー対応を保ったまま見た目だけを変えられるのが、divで自作するのとの決定的な違いだ。

非対応ブラウザでは <button> と <selectedcontent> が無視されて通常の <select> にフォールバックする。<select multiple> は未対応。