Notes / プロジェクト運営

ブラウザ単独の不具合をどこで切るか。特定ブラウザ限定問題と判定する判断軸

「Safari/Chromeでは問題ない、Braveだけで不具合が出る」。この事象に何時間費やすか。特定ブラウザ限定問題と判定してサイト側fixを断念する判断軸と、ユーザーへの案内方法。

browser compat decision making cross-browser testing

「SafariとChromeでは問題ない、特定の1ブラウザだけで不具合が出る」。サイト制作中にこの状況に出会うことがあります。

時間をかければ原因を突き止められるかもしれない。けれど対象ブラウザのシェアと修正コストを天秤にかけると、特定ブラウザ限定問題と判定してサイト側修正を断念する判断のほうが、コスト上有利なケースは多いです。

切り分けの手順

ブラウザ単独問題と判定するには、次の順序で再現性を確認します。

主要環境で再現するか

OSブラウザ
macOSSafari、Chrome、Edge、Firefox
WindowsChrome、Edge、Firefox
iOSSafari、Chrome、Brave (日本など多くの地域ではWebKit強制)
AndroidChrome、Samsung Internet、Brave

1つでも再現するならブラウザ単独ではない、サイト側にも原因があると考えます。ただし「1つでも再現するならサイト側が主因」と決めつけるのも危険。ブラウザ共通の拡張、OS設定、ネットワーク要因の合流もあり得るので、再現条件は丁寧に書き出します。

エンジンで分類する

現在のブラウザのレンダリングエンジンは大別して3系統です。Blink (Chrome、Edge、Brave-desktop、Opera、Samsung Internet)、WebKit (Safari、日本市場における iOSブラウザのほとんど)、Gecko (Firefox)。

「Chromeでは出ない、Edgeでは出る」ならBlink系で挙動差は珍しく、ブラウザ拡張やEdge固有機能 (Read Aloud等) を疑う。「Safariでは出ない、iOS Braveでは出る」なら同じWebKitなのにブラウザ単独で再現するため、Braveのレンダリング以外の機能 (Shields、Fingerprint Protection、Rewards) が干渉している可能性です。

ブラウザ拡張機能を疑う

該当ブラウザの拡張機能を全部無効化して再現するか確認します。広告ブロッカー、プライバシー保護、セキュリティ拡張はJavaScript、イベント、スクロールに干渉することがあります。

拡張オフで再現しないなら、ユーザー側の拡張機能起因でサイト側修正の責任外。

ブラウザ固有機能を順にオフ

該当ブラウザのセキュリティ機能やプライバシー機能を順に無効化します。BraveならShields、Fingerprint Protection、Block Cookies。EdgeならTracking Prevention、Defender SmartScreen。FirefoxならEnhanced Tracking Protection、privacy.resistFingerprinting。

「Fingerprint Protectionをオフにしたら再現しない」なら、ブラウザ側の意図的なAPIタイミング改変が原因。サイト側で完全に塞ぐのは難しいです。

ブラウザのフォーラムで検索

該当ブラウザのGitHub Issues、フォーラム、Stack Overflowで「同じ症状」が報告されているか確認します。報告例があればknown issueとして扱う。

断念する基準

これらを踏まえて、次のいずれかに当てはまれば、サイト側修正は対象外にする判断が現実的になります。

  • 主要環境で再現しない、1ブラウザのみ
  • そのブラウザのセキュリティ機能やプライバシー機能をオフにすると再現しない
  • シェアが小さい (例: 該当ブラウザのユーザー比率が < 5%)
  • 同 issue がブラウザ側 known issue として報告されている

すべて Yes なら、対象ブラウザのユーザーには別ブラウザでの閲覧を案内し、サイト側は対応外とします。

判定後のユーザーへの案内

「Braveだけで不具合が出る、Shields offでも継続」のような事例を経験したら、次のような対応を取ります。

利用環境ページかFAQに明記する。「対応ブラウザ」「推奨ブラウザ」にSafari、Chrome、Edge、Firefoxを列挙し、Brave等の派生ブラウザは「主要機能のみ確認済み」程度にしておきます。

該当ブラウザでアクセスがあった時のヒント表示も検討。Brave 検出は UA 文字列や navigator.brave で試みますが、いずれも標準仕様ではなく、検出が外れる時期もあります。検出に依存しすぎず、原則は利用環境ページでの案内に留めます。

fix-it バックログとして記録します。完全断念ではなく、「将来ブラウザ側が修正するかもしれない」「シェアが伸びたら対応する」の判断保留として、バックログに残して3〜6ヶ月毎に状況を見直します。

諦める判断がコスト上有利な理由

100%のブラウザ互換性を追うのは、コストが指数関数的に増えます。主要4ブラウザの実機テストで時間内に終わるプロジェクトでも、派生ブラウザ全部対応で終わらないプロジェクトは多い。

派生ブラウザの利用者は派生ブラウザを選ぶ理由 (privacy重視、軽量、ad block) があり、その選択はブラウザ機能のトレードオフを承知の上です。自分が選んだブラウザの制約は、利用者側で吸収する。この社会契約は現代のWebの前提として成立しています。

逆に、これを成立させるためにも「主要ブラウザでちゃんと動く」は確保します。Safari、Chrome、Edge、Firefox、iOS Safari、Android Chromeの6環境を死守して、それ以外はベストエフォートというのが現実的な品質基準。


ブラウザ単独問題は、5ステップの切り分けで「主要4ブラウザで再現しない」「ブラウザの特殊機能オフで消える」と判定できます。シェア、コスト、利用者側の選択を踏まえれば、サイト側修正を対象外にする判断はコスト上有利な選択肢です。

Webプロジェクトの品質基準設計のご相談はお問い合わせから、業務領域の詳細はServicesへ。