Brotli（ブロトリ）は、Google が開発した可逆圧縮のアルゴリズムであり、同時にファイル形式でもある。データの中身を保ったまま小さくし、展開すれば元に戻る。仕様は RFC 7932 として標準化され、HTTP の Content-Encoding: br や Web フォントの WOFF2 で広く使われている。公式リポジトリ google/brotli は ★15.0k・MIT ライセンスで、最新タグは v1.2.1（2026-10-26時点）。この記事では「そもそも Brotli とは何か」「なぜ gzip より縮むのか」を、数式ではなく図で追う。
HOW BROTLI PACKS圧縮の流れ
Brotli は辞書と後方参照で重複を消す
-
入力データ
HTML・CSS・JS など
-
後方参照 LZ77
最大16MiBの窓で既出を指す
-
静的辞書
Web頻出の約120KBを内蔵
-
文脈モデリング
2次の文脈で次を予測
-
Huffman符号化
短いビット列にして .br へ
30秒でわかる Brotli（2026-10-26時点）
- ・正体：Google 製の可逆圧縮アルゴリズム／フォーマット（RFC 7932・MIT）
- ・何ができる：HTML・CSS・JS・フォントを gzip より密に縮め、転送量を減らす
- ・なぜ縮む：約120KBの静的辞書・最大16MiBのウィンドウ・2次の文脈モデリングの3点
- ・どこで使う：HTTP の
Content-Encoding: br、WOFF2 Web フォント、CDN
Brotli とは（Google 製の可逆圧縮の規格）
Brotli は公式 README の言葉では「LZ77 の現代的な変種・Huffman 符号化・2次の文脈モデリングを組み合わせた汎用の可逆圧縮アルゴリズム」だ。可逆（lossless）なので、画像の JPEG のように情報を捨てて縮めるのではなく、テキストやバイナリを1ビットも変えずに小さくする。
読者の立場で言い換えると、Brotli が答えるのは次の3つだ。
・何ができる：Web で配る HTML・CSS・JavaScript・フォントを、同じ中身のまま小さくして転送を速くする
・何を解決する：回線やサーバの転送量・読み込み時間を減らす。gzip で頭打ちだった圧縮率をもう一段上げる
・何を代替する：Web 配信での gzip（Deflate） の置き換え、または併用（ブラウザが対応していれば br、なければ gzip に落とす）
Brotli には2つの顔がある。ひとつはフォーマット（RFC 7932 で定義された .br のビット列の決まり）、もうひとつは Google が公開する実装（google/brotli、C 言語のライブラリと brotli コマンド）だ。ブラウザや CDN が「Brotli に対応」と言うとき、多くはこの実装、あるいは互換の実装を使っている。
なぜ gzip より縮むのか（3本の柱）
Brotli が gzip より縮む理由は、3つの構造の差に分解できる。下の図は gzip（Deflate）と Brotli を並べたものだ。
WHY IT'S DENSERなぜ縮む
Brotli は広い窓と内蔵辞書で Deflate より詰める
gzip（Deflate）
LZ77＋Huffman
- 窓は最大32KiB
- 共有辞書なし
- 展開が速く枯れている
Brotli
LZ77＋Huffman＋2次文脈
- 窓は最大16MiB（既定）
- 約120KBの静的辞書を内蔵
- 品質0〜11で速度と密度を選ぶ
1. 大きな内蔵の静的辞書。 Brotli は Web で頻出する文字列（HTML タグ、よく使う英単語、よく出るバイト列など）を集めた約120KBの辞書をあらかじめ持っている。実装ではこの辞書が c/common/dictionary.bin（122,784バイト）として同梱され、エンコーダとデコーダの双方が同じものを共有する。初めて出てくる文字列でも「辞書の何番目」と短く指せるため、ファイルの先頭から縮む。gzip にはこの共有辞書が無い。
2. 大きなスライディングウィンドウ。 圧縮は「少し前に出た同じ並びを、その位置と長さで指す」後方参照（LZ77）で重複を消す。どこまで遡れるかがウィンドウだ。Brotli の既定は lgwin=24、つまり 2^24 − 16 ≈ 16MiB まで遡れる（実装の BROTLI_MAX_WINDOW_BITS は24、大ウィンドウ版では30まで）。gzip（Deflate）のウィンドウは最大32KiB（RFC 1951）。桁が違うぶん、遠くにある繰り返しも拾える。
3. 2次の文脈モデリング。 直前の数バイトという「文脈」から次に来やすいバイトを予測し、符号を割り当てる。確からしい並びほど短いビットで表せるため、辞書と後方参照で消しきれない部分をさらに詰められる。
最後に、消し終えたデータを Huffman 符号化（出現頻度の高い記号に短いビットを割り当てるエントロピー符号化）で仕上げる。品質レベルは 0〜11（実装の BROTLI_MIN_QUALITY〜BROTLI_MAX_QUALITY）で選べ、11 に近いほど密に縮むが遅くなる。README は Brotli を「deflate と同程度の速度で、より密に圧縮する」と表現する。どれだけ縮むかは品質レベルとデータ次第なので、「必ず何%」とは言い切れない。
gzip・zstd との違い
同じ「LZ77＋エントロピー符号化」系でも、設計の重心が違う。用途ごとの向き不向きを表にまとめる。
| 観点 | gzip（Deflate） | Brotli | zstd |
|---|---|---|---|
| 開発元 | PKWARE 系／RFC 1951 | Google／RFC 7932 | Meta（Facebook） |
| ウィンドウ上限 | 32KiB | 16MiB（既定）／大ウィンドウ30bit | 可変（辞書と窓を選べる） |
| 共有の静的辞書 | なし | 約120KBを内蔵 | 任意（学習辞書を外から渡す） |
| 品質レベル | 1〜9 | 0〜11 | 1〜22（＋負の高速域） |
| 得意な場面 | 枯れた互換性・どこでも動く | Web 静的アセットの事前圧縮 | 圧縮/展開の速さと比率の両立 |
ざっくり言うと、gzip はどこでも動く最大公約数、Brotli は Web で最大まで縮める、zstd は速度と比率のバランスに寄っている。HTTP では Content-Encoding として gzip・br・zstd のどれで返すかをサーバとブラウザが交渉する。高い品質レベルの Brotli は圧縮が遅いので、リクエストのたびに縮めるのではなく、ビルド時に一度だけ縮めて置いておく（事前圧縮）用途に向く。逆に毎回動的に生成する応答は、速い zstd や中品質の Brotli が合う。
どこで使われているか
Brotli は日々開くページの裏で動いている。代表的な3つを挙げる。
WHERE IT RUNS使いどころ
Brotli はWeb配信とフォントで効く
-
1.HTTP レスポンス圧縮
Content-Encoding: br。静的アセットの事前圧縮に向く
-
2.WOFF2 Web フォント
フォント本体の圧縮に Brotli を使う
-
3.CDN・エッジ配信
主要ブラウザが br に対応
・HTTP レスポンス圧縮：ブラウザが Accept-Encoding: br を送り、サーバが対応していれば Content-Encoding: br で圧縮済みの HTML・CSS・JS を返す。静的アセットの事前圧縮と相性がよい
・WOFF2 Web フォント：W3C の WOFF2 仕様はフォント本体の圧縮に Brotli を採用している。Web フォントを読み込むとき、知らないうちに Brotli の展開が走っている
・CDN・エッジ配信：主要ブラウザが br に対応しているため、多くの CDN が Brotli での配信に対応する
実際に確かめる
あるサーバが Brotli で返しているかは、Content-Encoding ヘッダで分かる。curl で Accept-Encoding: br を宣言し、応答ヘッダだけを見る（-I）。
curl -H "Accept-Encoding: br" -sI https://example.com/ | grep -i content-encoding
content-encoding: br と返れば Brotli、gzip なら gzip、何も出なければ非圧縮だ。curl --version の出力に brotli/... が含まれていれば、その curl は Brotli の展開にも対応している（curl --compressed で中身を展開して受け取れる）。手元に brotli コマンドがあれば、brotli -q 11 file.js でファイルを圧縮し、-w でウィンドウ幅（10〜24、既定24）を指定できる。
注意：Brotli デコーダの脆弱性は別の話
- ・2026年に、Brotli デコーダの境界外書き込み（CVE-2026-111497、通称 node2shell／HTTP2Shell）が報告された。これは「Brotli で圧縮されたデータを展開する側」の実装の問題で、圧縮の仕組みそのものとは別の論点。影響範囲と直し方は下の記事にまとめている。
READ ALSO — セキュリティ
Node2shell（CVE-2026-111497）｜Node.js同梱Brotliデコーダの境界外書き込みRCEと直し方
READ ALSO — セキュリティ
HTTP2Shell とは｜node2shellの正体は上流Brotliの問題、HTTPでBrotliを展開する多くのライブラリに波及
まとめ：どんなときに Brotli を選ぶか
この記事の結論
- ・向いている人：Web の静的アセットを事前圧縮して転送量を減らしたい。gzip より一段縮めたい
- ・gzip で十分な場合：毎回その場で生成する応答で、圧縮の速さを最優先したいとき（中品質 Brotli や zstd も検討）
Brotli が gzip より縮むのは、約120KBの静的辞書・最大16MiBのウィンドウ・2次の文脈モデリングという3つの構造の積み重ねによる。難しい数式を覚えなくても、「辞書で先に当てる・遠くまで遡る・次を予測する」という3つの図を押さえておけば、なぜ縮むのかは説明できる。
参照ソース
・google/brotli（公式リポジトリ） — README・LICENSE（MIT）・c/include/brotli/encode.h・c/common/dictionary.bin（2026-10-26時点）
・RFC 7932 — Brotli Compressed Data Format — フォーマットの標準仕様
・RFC 1951 — DEFLATE Compressed Data Format — gzip が使う Deflate の仕様（ウィンドウ32KiB）
・WOFF2 File Format（W3C） — Web フォントが Brotli を使う仕様
