見えないパッチ：ブラウザがドメイン固有のクィークでウェブを救う方法

モダンなウェブはしばしば標準化の勝利として語られます。HTML5 の「リビング仕様」によりブラウザ戦争は終結し、Safari、Firefox、Chrome のいずれを使ってもウェブサイトが同じように見え、同じように動作するという普遍的な言語が生まれたと教えられています。

しかし、ブラウザエンジンの内部を覗くと、全く別の現実が見えてきます。世界で最も利用されているウェブサイトにおいては、"標準" がしばしば完全に回避され、ハードコードされたドメイン固有の介入が行われています。TikTok や Netflix から Instagram、さらには SeatGuru に至るまで、私たちが日々訪れる多くのサイトは一般的なルールに基づいて描画されているわけではなく、ブラウザのソースコードに組み込まれた一連の "クィーク"—壊れたサイトロジックを修正するための手動オーバーライド—によって動作しています。

ブラウザ・クィークの仕組み

主要なウェブサイトがウェブ標準に違反するコードを出荷したり、特定のブラウザの非標準的な振る舞いに依存したりすると、他のブラウザではしばしば壊れてしまいます。サイト所有者がバグを修正するのを待つ（数か月かかるか、そもそも修正されない）代わりに、ブラウザベンダーが自ら手を打つことがあります。

Firefox の WebCompat

Firefox は WebCompat と呼ばれるシステムを利用しています。Firefox ブラウザで about:compat にアクセスすると、サイト固有の介入リストを見ることができます。このシステムにより Mozilla は特定ドメインに対してカスタム CSS や JavaScript を注入したり、ブラウザを誤って "スニッフ" するサイト向けにユーザーエージェント文字列を変更したりできます。これらの介入は Bugzilla で追跡され、ブラウザチームが単にブラウザ側からサイトをパッチすることを決定する前に、サイト所有者へ連絡を試みた失敗例が記録されています。

Safari の Quirks.cpp

Safari を支えるエンジン WebKit では、これらの修正は Quirks.cpp というファイルに格納されています。このファイルはウェブの脆弱性を示す興味深いアーカイブです。実質的に次のようなロジックが書かれています：

"ユーザーが facebook.com、x.com、または reddit.com にいる場合、Picture-in-Picture ビデオを別の方法で処理します。これらのサイトはビデオが画面外にスクロールすると自動的に停止してしまうためです。"

最近のコミット履歴を見ると、これらのパッチが絶え間なく追加されていることが分かります。Zillow の間取り画像をセンタリングしたり、TikTok の "ブラウザをアップグレードしてください" メッセージを修正したり、Instagram Reels の再生サイズ変更問題を解決したりしています。特筆すべきケースとして、SeatGuru がコードの調整を拒否したためにクィークが追加され、ソースコード内に FIXME コメントが残されました：

"SeatGuru がサイトを調整したらこのクィークを削除してください。"

Chrome の非対称性

最も顕著な観察の一つは、Chrome が同様に大規模なドメイン固有クィークのリストを保持していないことです。これは必ずしも Chrome が優れた設計だからというわけではなく、その圧倒的な市場シェアが原因です。

Chromium 系ブラウザが市場を支配しているため、開発者はまず Chrome 向けに構築します。Chrome で動作すれば "完成" と見なされます。これが危険なフィードバックループを生み出します：

Chrome が機能や特定の実装詳細を出荷する。
開発者はそれが支配的なブラウザで動作するため採用する。
他のブラウザは同じ詳細を実装するか、差異を埋めるために "クィーク" を追加しなければならない。

この非対称性により、Chrome のウェブ標準解釈が事実上の de facto 仕様となります。Safari や Firefox のユーザーがバグに遭遇すると、ウェブサイトではなくブラウザのせいにされがちです。ユーザーが Chrome に乗り換えるのを防ぐため、Safari と Firefox のエンジニアはオーバーライドを書きます。場合によっては Safari が偽の Chrome ユーザーエージェント文字列を送信し、サイトに機能的なページを提供させることさえあります。

見えない修正の経済学

開発者にコード修正を依頼しないのはなぜか？ブラウザベンダーにとって経済的判断はシンプルです：明日出荷できる 5 行の回避策は、第三者に送られ読まれることのないバグレポートよりもはるかに価値があります。

例として、WebKit エンジニアが FlightAware 用にクィークを詳細に記述したケースがあります。サイトは CSS transform 行列文字列のシリアライズ方法に特化していましたが、ブラウザが新しい仕様に準拠した瞬間に FlightAware が壊れました。Safari エンジニアはドメイン固有の修正を加えてユーザーがサイトを利用できるようにしました。最終的に FlightAware がコードを修正しクィークは削除されましたが、数か月間ユーザー体験はブラウザソースコード内の if 文だけで維持されていました。

開発者への危険

平均的なウェブ開発者にとって、これらのクィークは静かな罠です。主に Chrome でサイトをテストすれば完璧に動作しているように見えるかもしれません。しかし、実は Safari や Firefox のクィークに依存している可能性があります。サイトが "動作している" のはクリーンなコードのおかげではなく、ブラウザエンジニアが知らず知らずのうちに解決した問題のおかげです。

新興プラットフォームにとっては特にリスクが高いです。観測者の中には、claude.ai のような新しいサイトさえもクィークファイルに現れたと指摘する人がいます。これは協働よりもパッチ適用の傾向が加速していることを示唆しています。

結論：地図と地形

ウェブ仕様は地図であり、クィークリストは乱れた地形です。私たちは "Internet Explorer 互換性" の時代から、支配的でないブラウザが互換性の負担を背負う時代へと移行しました。

Quirks.cpp の中の項目になるのを防ぐため、開発者は Chrome 中心のテストを超える必要があります。Safari と Firefox で定期的にサイトを監査することだけが、サイトが実際にウェブに準拠しているか、単に動作させるためにパッチが当てられているだけかを確かめる唯一の方法です。