このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
過去10年間でWebページは毎年6～9% 重くなっており、Webがフレームワーク主導になり、インタラクティブになり、メディアも多用されるようになったことで加速しています。その軌道は何も変わりません。変化しているのは、これらのページが再構築される頻度と、それらを要求するクライアントの数です。どちらもエージェントのおかげで急上昇しています。
共有辞書は、サーバーからブラウザへのアセット転送を縮小するため、ページの読み込みが速くなり、特に遅い接続にいるユーザーや訪問者にとっては特有の緩和策になります。デプロイごとにJavaScriptバンドル全体を再ダウンロードする代わりに、ブラウザはサーバーにすでにキャッシュしたものを伝え、サーバーはファイルを区別するだけを送信します。
本日は、共有圧縮辞書のサポート内容をこっそりご紹介し、初期テストで確認した内容をご紹介します。そして、ベータ版を実際に試せるようになる時期をお知らせします（ヒント：2026年4月30日です）。
エージェンティッククローラー、ブラウザ、その他のツールは、エンドポイントに繰り返しアクセスし、ページ全体を取得し、多くの場合、情報の断片を抽出します。2026年3月のCloudflareのネットワーク全体のリクエストのうち、エージェンティックアクターは10%弱を占めており、前年比で約60%増となっています。
出荷されるすべてのページは昨年よりも重く、かつてないほど頻繁にマシンが読むようになりました。しかし、エージェントは単にWebを消費するだけではなく、Webの構築を支援しているのです。AIを活用した開発は、チームがより早く出荷できることを意味します。デプロイ、実験、反復の頻度を高めることは、製品の速度にとっては素晴らしいことですが、キャッシュにとっては大変なことです。
エージェントが1行の修正をプッシュすると、バンドルは再チャンク化され、ファイル名が変更され、世界中のすべてのユーザーがアプリケーション全体を再ダウンロードできます。これは、コードが大幅に異なるからではなく、ブラウザやクライアントが具体的に何が変更されたのかを知る方法を持たないからです。新しいURLを表示して、ゼロから始まります。従来の圧縮は、各ダウンロードのサイズには役立ちますが、冗長性には役立ちません。クライアントがすでにファイルの95%をキャッシュしていることはわかりません。つまり、すべてのデプロイ、すべてのユーザー、すべてのボットが、繰り返し冗長バイトを送信することになります。1日10件の小さな変更を送信して、キャッシュを事実上停止したのです。これにより、ハードウェアがボトルネックになりつつあるWebでは、帯域幅とCPUが浪費されます。
再デプロイ頻度の高い重いページにヒットするリクエストが増えてスケーリングするには、圧縮をよりスマートにする必要があります。
圧縮辞書は、サーバーとクライアントの間で共有される参考資料であり、早見表のように機能します。サーバーは、レスポンスをゼロから圧縮するのではなく、「以前もキャッシュしたので、この部分はすでに知っている」と言って、新しいものだけを送信します。クライアントは同じ参照を保持し、解凍中にそれを使って完全なレスポンスを再構築します。辞書がファイル内のコンテンツを参照できるほど、クライアントに転送される圧縮された出力は小さくなります。
この既知のものに対する圧縮の原則により、最新の圧縮アルゴリズムはこれまでの圧縮アルゴリズムを凌駕しているのです。Brotliには、HTML属性や一般的なフレーズなどの一般的なWebパターンの内蔵辞書が搭載されています。 Zstandardはカスタム辞書のために構築されています。代表的なコンテンツサンプルを入力すると、提供するコンテンツの種類に最適化された辞書を生成できます。Gzipにはどちらもありません圧縮しているため、リアルタイムでパターンを見つけて辞書を構築する必要があります。これらの「従来の圧縮」アルゴリズムは、現在、Cloudflareで利用可能です。
共有辞書は、この原則をさらに一歩進めたものです。リソースの以前にキャッシュされたバージョンが辞書になります。デプロイ時に問題があったのを覚えていますか？チームは1行の修正プログラムを出荷し、すべてのユーザーが完全なバンドルを再ダウンロードすることになります。共有辞書では、ブラウザにはすでに古いバージョンがキャッシュされています。サーバーはそれに対して圧縮し、差分だけを送信します。１行の変更を加えた500KBのバンドルは、ワイヤー上ではわずか数キロバイトになります。1日あたり10万人のユーザーが1日に10回デプロイするとして、500GBの転送と数百メガバイトの差です。
deleteCは、ブラウザがすでに持っているバージョンを辞書に変換するものです。プロトコルは、サーバーが最初にリソースを提供するときに、Use-As-Dictionary応答ヘッダーを付加し、ブラウザに、後で役立つから、本質的にファイルを保持するように指示します。そのリソースに対する次のリクエストでは、ブラウザはAvailable-Dictionaryヘッダーを送り返し、サーバーに「このようなものを入手したのです」と伝えます。その後、サーバーは新しいバージョンを古いバージョンに対して圧縮し、差分だけを送信します。別の辞書ファイルは不要です。
ここで、実際のアプリケーションの成果が得られます。バージョン管理されたJSバンドル、CSSファイル、フレームワークの更新、およびリリース間で段階的に変更されるすべてのもの。ブラウザはすでにapp.bandle.v1.jsをキャッシュしており、開発者は更新を行い、app.bandle.v2.jsをデプロイします。deleteCは、これらのバージョン間の差分を送信するだけです。以降のバージョンもすべて異なります。バージョン3は、バージョン2を圧縮します。バージョン47は、バージョン46を圧縮しています。節約効果はリセットされず、リリース履歴全体を通じて継続します。
また、コミュニティでは、非静的コンテンツのカスタム辞書や動的辞書についても活発な議論が行われています。これは今後の取り組みですが、大きな影響をもたらします。他の投稿に保存しておきます。
共有辞書がそれほど強力であるなら、なぜ誰も使わないのでしょうか？
前回の試行時、実装はオープンWebとの連絡に耐えられなかったためです。
Googleは2008年にChromeで共有辞書圧縮（SDCH）を出荷しました。早期導入企業の中には、ページ読み込み時間が2桁改善されたと報告していることもあり、うまく機能しました。しかし、SDCHは、どのユーザーよりも速く問題を蓄積しました。
最も記憶に残るのは、圧縮サイドチャネル攻撃（CRIME、BREACH）のクラスでした。研究者グループは、攻撃者が圧縮される機密性（セッションクッキーやトークンなど）と一緒にコンテンツを注入できれば、圧縮された出力のサイズによって秘密に関する情報が漏えいする可能性があることを示しました。攻撃者は、一度にバイトを推測し、アセットサイズが縮小するかどうかを観察し、秘密全体を抽出するまでこれを繰り返すことができます。
しかし、問題はセキュリティだけではなく、採用に至らない主な理由さえありました。SDCHは、Same-Origin Policy違反など、いくつかのアーキテクチャ上の問題が表面化しました（皮肉なことに、これが優れたパフォーマンスの理由の1つです）。クロスオリジン辞書モデルはCORSと連携できませんでした。また、キャッシュ APIなどとの連携に関する仕様が欠けていました。その後すぐに、採用の準備ができていないことが明らかになり、2017年にChrome（当時は唯一サポートしていたブラウザ）はそれをサポート対象から外しました。
Webコミュニティがバトを受けるまでに10年かかりましたが、その価値は十分にありました。
最新の標準であるRFC 9842: Compression Dictionary Transportは、SDCHを維持不可能にしていた主要な設計上のギャップを解消します。たとえば、アドバタイズされた辞書が同一生成元からの応答にのみ使用可能であることを強制して、サイドチャネル圧縮攻撃を可能にした多くの条件を防止します。
ChromeとEdgeは、Firefoxがフォローするようにサポートをリリースしています。この標準は広く普及する方向に進んでいますが、完全なクロスブラウザサポートにはまだ追いついていません。
RFCはセキュリティの問題を軽減しますが、辞書トランスポートの実装は常に複雑でした。オリジンは、辞書を生成し、適切なヘッダーを付けて提供し、すべてのリクエストでAvailable-Dictionaryとの一致を確認し、その場でレスポンスをデルタ圧縮し、クライアントが辞書を持っていない場合は適切にフォールバックする必要があるかもしれません。キャッシングも複雑になります。レスポンスはエンコーディングと辞書ハッシュの両方で異なるため、辞書バージョンごとに個別のキャッシュバリアントが作成されます。デプロイの途中では、古い辞書を持つクライアント、新しい辞書を持つクライアント、そしてそうでないクライアントが発生します。キャッシュは、それぞれのコピーを個別に保存しています。ヒット率は低下し、ストレージは上昇し、辞書自体は通常のHTTPキャッシュルールの下で新しい状態を保つ必要があります。
この複雑さは調整の問題です。そして、まさにエッジに属するものなのです。CDNはすでにすべてのリクエストの前に配置され、圧縮を管理し、すでにキャッシュバリアントを処理しています（近日公開のお知らせブログにご期待ください）。
Cloudflareはどのように共有辞書サポートを構築しているか
共有辞書圧縮は、ブラウザとオリジン間のスタックのすべての層に影響を与えます。お客様からの強い関心があります。RFC著者 Patrick Meenan氏のdictionary-workerのように、すでに独自のインプリメンテーションを構築しているユーザーもいます。これは、WASMでコンパイルされたZstandard（例）を使用して、Cloudflare Worker内で辞書のライフサイクル全体を実行するものです。私たちは、これを誰でも利用可能で、できるだけ簡単に実装できるようにしたいと考えています。そのため、プライミングから始め、3つのフェーズでプラットフォーム全体を展開します。
フェーズ1：パススルーサポートは現在アクティブ開発中です。Cloudflareは、Use-As-Dictionary、Available-Dictionary、およびdcbとdczのコンテンツエンコーディングなど、共有辞書が必要とするヘッダーとエンコーディングを、削除、変更、または再圧縮することなく転送します。キャッシュキーは、Available-DictionaryとAccept-Encoding に基づいて変化するように拡張され、辞書圧縮された応答が正しくキャッシュされるようになります。このフェーズは、オリジンで独自の辞書を管理するお客様に対応します。
2026年4月30日までに、フェーズ1のオープンベータを開始する予定です。使用するには 、機能を有効にしたCloudflareゾーンにいること、正しいヘッダー（ Use-As-Dictionary 、Content-Encoding: dcb または dcz ）で辞書圧縮されたレスポンスを提供するオリジンがあること、そして訪問者が Accept-Encoding に dcb/dcz を含んでおり、 Available-Dictionary を送信するブラウザを使用している必要があります。現在、これはChrome 130+とEdge 130+を意味し、Firefoxのサポートも進行中です。
使用可能になったタイミング、また使用方法に関する追加の文書について、変更履歴に注目してください。
すでに社内でパススルーのテストを開始しています。コントロールされたテストでは、2つのjsバンドルを順番にデプロイしました。バージョン間では、同じWebアプリケーションの次のデプロイを表すバージョン間で、ローカライズされた変更がいくつかある以外は、ほぼ同じものでした。圧縮されていない場合、アセットは272KBです。Gzipは92.1KBまで圧縮し、66%削減しました。DCZ上で共有辞書圧縮により、前のバージョンを辞書として使用すると、同じアセットは2.6KBまで低下しました。これは、すでに圧縮された資産と比較して97%の削減です。
同じラボテストでは、クライアントから、サーバー初期応答時間（TTFB）と完全なダウンロード完了の2つのタイミングマイルストーンを測定しました。サーバー初期応答時間（TTFB）の結果には表示されないものが興味深いものです。キャッシュミス（DCZがオリジンの辞書に対して圧縮する必要がある場合）では、サーバー初期応答時間（TTFB）はgzipより20ミリ秒ほど遅いだけです。オーバーヘッドは送信にほぼ無視されます。
ダウンロード時間には差があります。キャッシュミスがあった場合、DCZはgzipの166ミリ秒に対して31ミリ秒で完了しました（81%改善）。キャッシュヒット時は、16ミリ秒に対して143ミリ秒（89%改善）となりました。応答ははるかに小さく、最初にわずかなペナルティを支払っても、終了する前にはるかに先に終了してしまいます。
最小限のJSバンドルの相違をシミュレートする初期のラボ結果。結果は辞書とアセット間の実際のデルタによって異なります。
フェーズ2：Cloudflareがお客様のために作業を開始するところです。オリジンで辞書ヘッダー、圧縮、フォールバックロジックを処理するのではなく、このフェーズでは、ルールを通じてどのアセットを辞書として使用するべきかをCloudflareに伝え、残りはCloudflareが管理します。Use-As-Dictionaryヘッダーを挿入して辞書バイトを保存し、新しいバージョンを古いバージョンに対してデルタ圧縮して、各クライアントに適切なバリアントを提供します。オリジンは通常のレスポンスを提供します。辞書が複雑だと、その情報はお客様のインフラストラクチャから当社のインフラストラクチャへ移動します。
このことを実証するために、これが実際にどのようなものかを示すライブデモを構築しました。こちらで試してみてください: 圧縮（辞書を使用して）できますか？
デモでは、毎分94KBの新しいJavaScriptバンドルをデプロイしていますが、これは典型的な本番環境のシングルページアプリケーションバンドルを模倣することを目的としています。コードの大部分はデプロイ間で静的です。毎回小さな設定ブロックの変更は最初のバージョンが読み込まれると、Cloudflareのエッジはそれを辞書として保存します。次のデプロイが到着すると、ブラウザはすでに持っているバージョンのハッシュを送信し、エッジは新しいバンドルをデルタ圧縮します。その結果、94KBはおよそ159バイトに圧縮されます。これは、gzipに対して99.5%の削減だということです。なぜなら、ワイヤー上にあるのは実際の相違点だけだからです。
デモサイトにはウォークスルーがあり、curlまたはブラウザーを使って圧縮率をご自身で確認できるようになっています。
フェーズ3：Webサイトに代わって辞書を自動的に生成します。お客様が辞書として使用するアセットを指定する代わりに、Cloudflareが自動的にそれらを識別します。当社のネットワークは、何百万ものサイト、数十億ものリクエスト、すべての新規デプロイを含む、通過するすべてのリソースのすべてのバージョンをすでに把握しています。目的は、ネットワークが、次のレスポンスがそのコンテンツの大部分を共有するもののハッシュが異なるパターンを観察した場合、リソースがバージョン管理されており、デルタ圧縮の候補であることを示す強いシグナルがあるということです。前のバージョンを辞書として保存し、それに基づいて次のバージョンを圧縮します。顧客による設定は不要です。メンテナンスは不要です。
これは単純なアイディアですが、実際的には難しいものです。個人データを明らかにしない辞書を安全に生成し、どの辞書が最もメリットをもたらすトラフィックを特定するかは、現実的なエンジニアリング上の問題です。しかし、Cloudflareには適切な要素があります。ネットワーク全体のトラフィックパターンを見て、辞書が存在する必要があるキャッシュ層をすでに管理しており、クライアントへのRUMビーコンは、提供を約束する前に辞書が実際に圧縮を改善することを確認するための検証ループを提供できます。トラフィックの可視性、エッジストレージ、合成テストの組み合わせにより、自動生成が可能になるものの、まだ理解すべき点はたくさんあります。
フェーズ 3 のパフォーマンスと帯域幅のメリットは、私たちの動機の核です。これによって、Cloudflareを使うすべての人が共有辞書にアクセスできるようになります。カスタム辞書を手動で実装することはできなかった数百万のゾーンも対象となります。
Webの創設以来、ほとんどの場合、圧縮はステートレスでした。すべてのレスポンスは、クライアントが以前のものを一切目にしないかのように圧縮されていました。共有辞書は、それを変えます。圧縮に、記憶をたどるのです。
これは5年前と比べて、重大な意味を持っています。エージェンティックコーディングツールは、デプロイ間の間隔を圧縮しますが、消費するトラフィックの割合は増加しています。今日、AIツールは大きな相違点を生み出すことができますが、エージェントはより多くのコンテキストを得て、コード変更においてピンポイントで稼働するようになっています。さらに、リリースの頻度が高く、自動化されたクライアントが多いこともあり、すべてのリクエストに対して冗長バイトが増えることを意味します。deleteCは、1回の転送あたりのバイト数と必要な転送の回数を減らすことで、この方程式の両サイドで助けとなります。
共有辞書は、標準化に数十年かかりました。Cloudflareは、人間であるかどうかにかかわらず、お客様のサイトに触れるすべてのクライアントに対して機能するためのインフラストラクチャの構築を支援しています。フェーズ1のベータ版は4月30日に公開されます。ぜひお試しください。
__
1ボット = HTTPリクエスト全体の31.3%AI = 全ボットトラフィックの~29-30%（2026年3月）。