ブラウザが間違った Favicon を選んでいる？開発者のための正しい修正方法

favicon を更新し、新しいファイルをデプロイし、ページを再読み込みしたのに、ブラウザは間違ったアイコンを表示し続けています。数か月前の古いロゴ、別サイトのアイコン、本来そこにあるべきではないぼやけた汎用プレースホルダーなどが表示されることもあります。

これは開発者が直面する favicon に関する最もよくある不満のひとつです。ファイルはサーバーに存在し、HTML タグも正しく見えます。それなのにブラウザは間違った favicon 資産を選び、デプロイした内容を無視します。

本稿ではまず即効性のある修正方法を紹介し、その後に根本原因を掘り下げます。

2 分でできるクイックフィックス

「間違った favicon」が表示される症状の多くは、単一の根本原因に集約されます。ブラウザの優先順位です。複数の icon ソースが存在する場合、ブラウザは厳格な参照順序に従い、競合があればその結果が上書きされます。

まずはこちらのチェックリストを試してください。

サイトルートにある /favicon.ico を削除してください。多くのブラウザで HTML の宣言より優先されます。
<head> 内に、適切な sizes と type 属性を明示した rel='icon' タグを追加してください。
キャッシュバスティング用のクエリ文字列（例: ?v=2）を付与し、ブラウザに新しいファイルを取得させます。
Ctrl+Shift+R でハードリロードを実行するか、それでも解消しない場合は favicon キャッシュクリアガイドを順に確認してください。

これで解決すれば完了です。解決しない場合は、優先順位の競合によってブラウザが間違った favicon を選んでいるため、ここからより深い診断に入ります。

ブラウザが誤ったアイコンを選ぶ理由

ブラウザは HTML を盲目的に信用するわけではありません。HTML 仕様で定義された参照手順を実行しており、わずかな不一致でも結果が上書きされることがあります。

1. /favicon.ico の罠

レガシーな favicon.ico がサイトルートに存在し、かつ HTML 内にモダンな <link rel='icon'> タグを出力している場合、ブラウザは多くのケースで ico ファイルを優先します。多くのブラウザは、他の icon が宣言されていない場合に自動的に /favicon.ico をリクエストし、そのファイルが存在する限り、それを権威ある情報として扱います。

修正方法: ルートの favicon.ico を削除するか、正確な sizes 属性を付けた link tag で明示的に配信してください。

2. sizes 属性の欠落または誤り

sizes 属性は、各 icon ファイルがどの解像度を持つのかをブラウザに伝えます。これがなければ、ブラウザは 16x16 の PNG を 32x32 の表示コンテキストに拡大し、皆が嫌うピクセル化した見た目になります。

必ず明示的に宣言してください。

<link rel='icon' type='image/png' sizes='32x32' href='/icons/favicon-32x32.png'>
<link rel='icon' type='image/png' sizes='16x16' href='/icons/favicon-16x16.png'>

HTML 仕様では rel='icon' がサイトアイコンを宣言する標準的な方法とされています。正確な解析ルールについては WHATWG HTML Living Standard を参照してください。

3. type 属性の競合

type='image/svg+xml' と宣言しているのに、実際の配信ファイルが PNG である場合（あるいはその逆）、ブラウザはそのファイルを完全にスキップし、利用可能な他のリソース — 古いキャッシュを含む — にフォールバックすることがあります。

MIME タイプが実際のファイルと一致しているか確認してください。よくあるバグとして、ファイル拡張子や HTML 属性では SVG と宣言しているにもかかわらず、CDN が image/png を返すケースがあります。

4. Web App Manifest による上書き

サイトに site.webmanifest が存在し、独自の icons 配列を含んでいる場合、ブラウザは HTML のリンクタグより manifest のアイコンを優先することがあります。特にモバイルや「Add to Home Screen」フローでは顕著です。

/site.webmanifest を確認し、icons 配列が HTML で宣言しているファイルと一致しているかを確かめてください。サイズやフォーマットの不一致は、プラットフォーム固有のロジックによってブラウザに間違った favicon を選ばせる原因になります。

5. CDN とエッジキャッシュの遅延

Cloudflare、Fastly などの CDN は static assets を積極的にキャッシュします。デプロイ後でも、エッジノードが古い favicon を数時間から数日にわたって配信し続けることがあります。

デプロイ後は必ず /favicon.ico、/icons/*、/site.webmanifest のパスについて CDN のキャッシュをパージしてください。さもないと、ブラウザは単に古いエッジのキャッシュによって間違った favicon を選び続けることになります。

6. Service Worker の罠

Service Worker は、ブラウザの HTTP キャッシュとは独立に favicon のレスポンスをキャッシュできます。PWA がインストール時に icon をキャッシュしてしまうと、Service Worker が更新されるまで古いバージョンが表示され続けます。

Service Worker のバージョンを上げ、href 値にキャッシュバスティング用のクエリ文字列を含めてください。バージョン付きのファイル名にするのがより安全です。

予防: 壊れない icon スタックを構築する

問題が解決したら、将来の「間違った favicon」インシデントを防ぐために構成を堅牢化しておきましょう。

単一の信頼できる情報源: 適切な favicon ジェネレータのワークフローを使い、すべての icon を単一のソースファイルから生成します。
一貫した命名規則: サイトルートではなく専用の /icons/ ディレクトリを使用します。
デプロイ時にキャッシュを破壊する: ビルドパイプラインでファイル名をハッシュ化し（例: favicon-abc123.png）、古いキャッシュを参照不能にします。
定期的に監査する: メジャーなリリース前に、複数ブラウザで簡易的な監査を実施します。
Incognito モードで検証する: Incognito ウィンドウは多くのキャッシュ層をバイパスするため、正しく動作しているかを正直に確認できます。

まとめ

ブラウザが間違った favicon を選んでいるケースでは、それがランダムであることはほぼありません。想定外の優先順位に従い、無効化し忘れたキャッシュから取得し、実態と一致しない type 属性を読み取っている、というのが実態です。

ルートの favicon.ico を削除し、サイズとタイプが正しい明示的なリンクタグを宣言し、manifest を同期させ、デプロイごとにキャッシュをパージする。この一連の作業で「間違った favicon」の大半は解消します。残るエッジケースの大半は、DevTools を数分使えばデバッグできる CDN か Service Worker の罠です。