SXG（Signed Exchange）とは？仕組みと2026年の提供終了・撤去手順

SXG（Signed HTTP Exchanges、Signed Exchange）は、HTTPレスポンスをサイトの証明書で署名し、Googleのキャッシュのような第三者が配信しても「元のサイトのページ」としてブラウザに扱わせる配信形式です。Google検索のAMP表示と、検索結果からのプリフェッチによる表示高速化に使われてきました。

ただし2025年から2026年にかけて、配る側が相次いで手を引きました。Cloudflareは2025年10月に機能を止め、Google検索は2026年7月1日にSXGの手順書を削除し、Google Trust Servicesは2026年9月30日前後の1〜2日以内にSXG用証明書の発行を停止すると告知しています。この記事では仕組みを短く押さえたうえで、いまSXGを返しているサイトの確認と撤去の手順、代わりに表示速度を稼ぐ手段までをまとめます。

まとめ：SXGの要点と2026年10月時点の扱い

• SXGは「リクエストURL・レスポンスヘッダー・本文」に署名を付けて1ファイルにした形式です。MIMEタイプは application/signed-exchange;v=b3、署名の有効期限は最長7日、証明書は CanSignHttpExchanges 拡張付きで有効期間90日以内という制約があります。
• 最大の使い手はGoogle検索でした。検索結果ページからSXGをプリフェッチし、クリック後のLCP（最大コンテンツの描画時間）を縮めていました。対象はChromium系ブラウザだけです。
• 2025年10月にCloudflareが停止、2026年6月23日にCloudflareがEOLを告知、2026年7月1日にGoogle検索がSXGの記述を削除、Google Trust Servicesは2026年9月30日前後の1〜2日以内にSXG用証明書の発行を停止すると告知しました。Google製の生成ツール3種もGitHubでアーカイブ済みです。
• Chromeは2026年10月時点でもSXGを読み込めますが、ブラウザの対応と、検索・CDN・認証局のサービス提供は別の話です。Google検索向けの新規施策としては導入を勧めません。
• すでにSXGを返しているサイトは、Acceptヘッダーによる出し分けを止め、証明書の自動更新ジョブを外します。表示速度はオリジンとCDNのキャッシュ、サイト内遷移ならSpeculation Rules APIで稼ぎます。

SXGの仕組み：署名付きレスポンスを第三者が配れる理由

通常のHTTPSでは、ブラウザが「このページは example.com のもの」と信じる根拠はTLS接続そのものです。そのため、Googleのサーバーから届いたHTMLはGoogleのページとして扱われます。SXGは署名をレスポンス側に埋め込むことで、この前提を外しました。配信経路がGoogleのキャッシュでも、署名が example.com の証明書で検証できればアドレスバーには元のURLが表示されます。Chromeの開発者ブログはSXGを、より大きな仕様群であるWeb Packagingの一部と位置づけています。

SXGファイルの構成要素

ブラウザは signature ヘッダーの cert-url から証明書を取りに行き、署名・有効期限・証明書の拡張を検証してからページとして表示します。

証明書と署名期限の制約

SXGの署名には、通常のTLS証明書ではなく CanSignHttpExchanges 拡張を持つ証明書が必要です。仕様の検証手順はsecp256r1（ECDSA P-256）の鍵を基本とし、それ以外はTLS 1.3以降で定義された署名方式に限っています。web.devの解説によると、仕様上この拡張付き証明書の有効期間は90日以内で、申請するドメインにはDNSのCAAレコードの設定が求められます。2018年11月時点で対応する認証局はDigiCertだけでしたが、のちにGoogleの認証局（Google Trust Services）からも任意のACMEクライアントで自動取得できるようになりました。

署名側にも期限があります。署名の expires は最長7日なので、同じページでも週に1回以上は署名し直す必要があります。証明書と署名は実際の有効期限より前に更新する必要があり、証明書更新・再署名・失敗時の監視を自動化する運用が必要でした。

クローラーにだけSXGを返すコンテンツネゴシエーション

サーバーは、リクエストの Accept ヘッダーで application/signed-exchange のq値が text/html 以上のときだけSXGを返します。web.devはこの規則について、実際にはクローラーにSXGを返し、ブラウザには通常のHTMLを返す結果になると説明しています。Chromium本体も通常のページ遷移で Accept の末尾に application/signed-exchange;v=b3;q=0.7 を付けますが、text/html（q値1）より低いのでHTMLが返ります。ブラウザで直接ページを開いてもSXGかどうかは見えないので、確認にはAcceptヘッダーを指定したリクエストが必要です（手順は後述）。

Google検索がSXGで速くしていた仕組みと条件

Google検索は2021年4月19日に、AMPではない通常ページ向けのSXG手順書を公開しました。仕組みは、Googlebotがサイトのリクエストに応じて返されたSXGをクロールしてGoogleのSXGキャッシュに保存し、検索結果ページを表示した時点でそのSXGをブラウザへプリフェッチしておくというものです。ユーザーがクリックしたときには本文がブラウザに届いているので、LCPが縮みます。web.devは過去の実験で、SXGのプリフェッチによりLCPが平均300〜400ミリ秒短くなったと記載しています。

プリフェッチには条件がありました。Chromeの開発者ブログが挙げていたのは、iOS以外のChromiumブラウザ（ChromeやEdge）でバージョン98以降、かつリファラーがGoogle検索のドメインであることです。SXGキャッシュに置く期間はサイト側のmax-ageで2分から7日の間で決まり、同ブログは1日（86400秒）以上が性能面でうまく働き、2分では効果が出ないと書いています。

効果の公表値としては、web.devが「CloudflareがテストしたサイトのうちTTFBが改善したのは98%、LCPが改善したのは85%、改善幅の中央値は20%超」という数字を紹介しています。ただしこれは自動SXGを提供していたCDN側の測定で、検索経由のうちプリフェッチが効いた閲覧だけを見た値です。サイト全体のLCPがそのまま20%縮むと読むのは誤りです。

AMPでは別の役割もありました。GoogleのAMPキャッシュから配信されたページでも、SXGを使えばアドレスバーに google.com 配下ではなく元のドメインのURLを表示できました。

2025〜2026年のSXG提供終了・停止の経緯

関連サービスの変更を事業者別に整理します。

Cloudflare：2025年10月に無効化、2026年6月にEOL

Cloudflareは2025年10月20日からAMPとSXGのサポートを外すと告知し、変更履歴（Speed Changelog）では2026年6月23日付で「2025年10月から無効化済み」と明記したうえでEOLを宣言しました。EOL後はAPIやルールセットからSXGを設定できず、Zone APIはエラーを返し、SXGの設定を含むルールセットは設定を外すまで保存できません。Cloudflareの自動SXG（Automatic Signed Exchanges）はSXG導入の主な入口だったので、この停止で利用サイトの多くが一度に外れました。

Google検索：2026年7月1日にSXGの記述を削除

Google検索セントラルの更新履歴は、2026年7月1日付で「AMPドキュメントからAMPビューア・AMPキャッシュ・SXGへの古い参照を削除した」と記録しています。同日からGoogle検索はAMPページをパブリッシャーのAMPホストへ直接リンクするようになり、AMPキャッシュの更新やSXGの設定は不要になりました。AMPページの順位は他のページと同じ扱いが続きます。

非AMPページ向けのSXG手順書（search/docs/appearance/signed-exchange）は、2026年10月1日時点で日本語版・英語版ともこの更新履歴の項目へ301リダイレクトされます。更新履歴の文面はAMPの配信変更についてのもので、非AMPページのプリフェッチ停止を明言した文ではありません。ただ、手順書そのものが消えた以上、Google検索向けにSXGを整える根拠はなくなったと判断してよい段階です。

証明書とツール：GTSの発行停止とGoogle製ツールのアーカイブ

Google Trust Servicesは、SXG用ディレクトリ（dv-sxg.acme-v02.api.pki.goog）からのSXG証明書の発行を2026年9月30日の前後1〜2日のうちに止めると告知しました。理由は「SXGの標準は広く採用されず、発展もしておらず、Web PKIの他の部分から乖離しつつある」ためです。同じディレクトリから通常のTLS証明書は引き続き取得できます。発行済みのSXG証明書は有効期間が90日以内なので、遅くとも2026年末までに順次失効し、更新はできません。

生成ツールも止まっています。GitHubの表示では、Google製の google/sxg-rs が2025年10月24日、google/webpackager が2026年2月13日、google/nginx-sxg-module（最終リリースv4.5）が2026年3月10日にアーカイブされ、読み取り専用になりました。仕様リポジトリの WICG/webpackage は更新が続いていますが、IETFへの最終提出版は2020年7月27日公開のdraft-09です。WICGの編集版は別に公開されています。

一方でブラウザ側の機能は残っています。chromestatusのOrigin-Signed HTTP Exchangesは「Enabled by default（Chrome 73）」のままで、Can I useでもChrome 157まで対応になっています。ブラウザで読み込めることと、利用中の配信サービスや認証局が運用を継続することは別です。

ブラウザ別のSXG対応状況

SXGを読み込めるのはChromiumを土台にしたブラウザだけです。Can I use（2026年10月1日時点）のデータは次のとおりです。

Firefoxを作るMozillaは、標準化への立場表明でWeb Packaging Format（SXGを含む）を「negative（否定的）」としています。Safariも実装していません。iOS版のChromeやEdgeも、Google検索のSXGプリフェッチの対象から外れていました。SXGが効くのは、もともとAndroidとPCのChromium系ブラウザからの閲覧に限られていたことになります。

自サイトのSXGを確認して撤去する手順

SXGを返したまま放置しても、Chromeが読み込める以上すぐに表示が壊れるわけではありません。ただ、証明書が更新できなくなれば署名の検証に失敗するSXGが残ります。今のうちに出し分けを止めておくのが安全です。

curlによるSXG配信の確認

以下のexample.comを調査対象ページの最終URLに置き換え、SXGを要求する Accept ヘッダーを付けてリクエストし、返ってくる Content-Type を見ます。

curl -s -o /dev/null -D - \
  -H "Accept: application/signed-exchange;v=b3;q=0.9,text/html;q=0.8" \
  https://example.com/ | grep -i '^content-type'

# SXGを返している場合の出力例
# content-type: application/signed-exchange;v=b3
# 通常のHTMLを返す場合の出力例
# content-type: text/html; charset=UTF-8

中身まで検証するなら、WICGのリポジトリにあるGo製の dump-signedexchange を使います。署名が有効なら人が読める形でヘッダーと本文が表示され、無効ならエラーになります。

go install github.com/WICG/webpackage/go/signedexchange/cmd/...@latest
dump-signedexchange -verify -uri https://example.com/

CloudflareのSXG設定・ルールセットの撤去

Cloudflare側は2025年10月から無効化済みなので、配信は止まっています。残る作業は設定の掃除です。SpeedタブやAPIでSXGを有効にした設定、SXGの設定を含むルールセットが残っていると、2026年6月23日のEOL以降は保存時にエラーになります。ルールセットを編集する前にSXGの項目を外してください。Terraformなどで設定をコード管理している場合は、該当する属性を消しておかないと次回の適用で失敗します。

nginx-sxg-module・webpackager・sxg-rsの配信停止手順

自前で署名していたサイトは、次の順で外します。

1. SXGの生成を止め、Acceptヘッダーにかかわらず通常のHTMLを返すようにする
2. 配信済みSXGの署名期限が切れるまで証明書チェーン（cert-url）の配信を維持し、その後にcert-urlとvalidity-urlの配信を止める
3. SXG用証明書のACME自動更新ジョブを止める（GTSは2026年9月30日前後のSXG証明書発行停止を告知）

nginx-sxg-moduleなら、設定から sxg 系のディレクティブと load_module の行を消してリロードします。

# 削除する行（nginx-sxg-module の README の設定例と同じ形）
load_module "modules/ngx_http_sxg_filter_module.so";
sxg on;
sxg_certificate     /path/to/certificate-ecdsa.pem;
sxg_certificate_key /path/to/private-key-ecdsa.key;
sxg_cert_url        https://cdn.example.com/example.com.cert.cbor;
sxg_validity_url    https://example.com/validity/resource.msg;
sxg_expiry_seconds  604800;

# 反映
sudo nginx -t && sudo nginx -s reload

削除後に前の節のcurlを実行し、text/html が返ることを確かめれば完了です。

AMPページの継続判断と廃止手順

AMPページをSXGとセットで運用していた場合も、SXG側の作業は不要になりました。2026年7月1日以降、Google検索はAMPページをパブリッシャーのドメイン上のAMP URLへ直接リンクします。AMPキャッシュからの配信が無くなった以上、AMPを続けるかどうかは表示速度と保守コストだけで判断できます。通常ページを残してAMP版を廃止する場合は、通常ページのrel=”amphtml”を削除し、AMP URLから対応する通常ページへ301または302リダイレクトを設定します。

SXGの代わりに表示速度を稼ぐ手段

SXGが担っていたのは「検索結果からの最初の1ページを先読みする」ことでした。この役割をサイト側で丸ごと置き換える手段はありません。だからこそ、先読みに頼らずオリジンの応答を速くするのが本筋です。

検索からの最初の1ページ：TTFBと画像の最適化

LCPには、サーバー応答（TTFB）、リソース取得開始までの遅延、取得時間、取得後の描画遅延が影響します。どの区間が長いかを測ったうえで、CDNのエッジキャッシュでHTMLを返す、LCP画像のサイズと形式を見直す、といった基本の施策を当てます。指標の基準値と改善の順番はコアウェブバイタルの3指標（LCP・INP・CLS）の基準と改善方法で、キャッシュ設計はCDNの仕組みとキャッシュ制御で解説しています。

Chrome側の仕組みとしては、Chromeの開発者ブログが2022年に、Android版Chrome 103から「Private prefetch proxy」を段階的に展開し、Google検索などからのサイト外遷移を中央値で30%速くすると発表しています。Cookieなどの保存データを持たないサイトだけを、プロキシ経由で利用者の情報を渡さずに先読みする仕組みです。サイト側で署名や証明書を用意する必要はありませんが、効くかどうかはChromeとリファラー側の条件で決まり、運営者が制御できる手段ではありません。

サイト内の2ページ目以降：Speculation Rules API

サイト内の遷移なら、Speculation Rules APIで次に開かれそうなページを先読み・事前レンダリングできます。Chromeの事前レンダリングは109以降で利用できますが、以下の例で使う文書ルールとeagernessにはChrome 121以降が必要です。<script type="speculationrules"> をページに置くだけで使え、証明書も署名も不要です。

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/column/details/*" },
    "eagerness": "moderate"
  }]
}
</script>

ただし掲載例の事前レンダリングはFirefoxとSafariでは効かず、未表示ページの処理がアクセス解析や広告計測に混入する場合があるので、計測タグの扱いを確かめてから入れてください。

SXGを今から導入するのはやめるべきです。Cloudflareの提供終了やGTSの発行停止告知を踏まえると、Google検索向けにSXGへ新規投資する優先度は低いと判断します。改善工数は、LCPの内訳を測定し、TTFBや画像取得、描画処理のうち遅延が大きい箇所に優先して使うことを勧めます。

SXGとAMP・Web Packaging・Web Bundlesの違い

SXGはAMPとセットで語られることが多く、関連する用語が混同されがちです。役割を分けると次のとおりです。

AMPはページの書き方の規格で、SXGは配信の形式です。AMPページをGoogleのAMPキャッシュから配ってもURLを元のドメインで見せるためにSXGが使われていたので、両者はセットで導入されてきました。Web Bundlesのページ遷移（Navigation to Bundled Exchanges）は、chromestatusで「No longer pursuing（開発中止）」になっています。

よくある質問

SXGとは何の略ですか？

Signed HTTP Exchanges の略で、Signed Exchange とも呼ばれます。HTTPのリクエストとレスポンスの組（exchange）に署名を付けたもの、という意味です。

Google検索のためにSXGを設定する必要はありますか？

ありません。Google検索は2026年7月1日にSXGの記述をドキュメントから削除し、AMPページについても「SXGの設定は不要」と明記しました。非AMPページ向けの手順書もリダイレクトされて読めなくなっています。

application/signed-exchange とは何ですか？

SXGのMIMEタイプです。現行の形式は application/signed-exchange;v=b3 で、サーバーはAcceptヘッダーでこのタイプが要求されたときだけSXGを返します。証明書チェーンは別に application/cert-chain+cbor で配信します。

CanSignHttpExchanges とは何ですか？

SXGの署名に使える証明書であることを示す拡張です。仕様上、この拡張付き証明書の有効期間は90日以内に制限されます。ACMEで発行していたGoogle Trust Servicesは、2026年9月30日前後のSXG用証明書発行停止を告知しています。

CloudflareのSigned Exchangesはまだ使えますか？

使えません。2025年10月に無効化され、2026年6月23日にEOLとなりました。APIやルールセットでも設定できず、SXGの設定が残ったルールセットは外すまで保存できません。

関連記事

• コアウェブバイタルとは？3指標（LCP・INP・CLS）の基準と改善方法【2026年版】
• INPとは？Core Web Vitalsの応答性指標の基準値と3区間・改善手順
• CDNとは？仕組み・キャッシュ制御からサービスの選び方まで実装目線で解説
• テクニカルSEOとは？主要施策と優先順位つきチェックリスト【2026年版】
• Lighthouseスコアの見方と改善方法｜Best Practices・SEOの配点と5カテゴリ