デスクトップブラウザで Google を開き、技術系の何かを検索して、各結果の左側の列を見てみてください。ドメイン名の隣の小さなアイコンが favicon です。Google は 2019 年からモバイル SERP で、2024 年からデスクトップ SERP でこれを表示しています。そこで識別可能な favicon がないサイトは放置されているように見え、シャープでブランドに沿った favicon があるサイトは洗練されて見えます。マークは 16 ピクセル幅、ユーザーがクリックするか判断するまさにその場所、ドメインの隣に表示されます。

Favicon ジェネレーターを開く →

その 16 ピクセルのマークは、ブラウザタブ・ブックマークバー・OS タスクバー・iOS ホーム画面・Android PWA インストール・RSS リーダー・ショートカットタイルを横断して生き残る、数少ないビジュアル要素の 1 つです。それぞれの場面が少しずつ違うファイルを要求します — サイズが違い、ときに形式が違い、ときに専用の manifest エントリが必要です。本稿は、モダンな favicon セットの実際の姿、なぜ単一の favicon.ico ではもう足りないか、ランタイムで各ファイルが何の役割を担うか、そして ZeroTool ジェネレーターがどのようにバイトをアップロードせずブラウザ内でパッケージを組み立てるかを扱います。

モダンブラウザが実際に要求するファイル

自分のサイトで DevTools を開いてリロードし、Network パネルを見てください。クリーンな Chrome のリクエストは少なくともこの 3 つにヒットします：

リクエスト用途備考
/favicon.ico規範的なファイル名を最初に探す古いブラウザやブックマークマネージャのフォールバックマルチサイズコンテナ；モダンブラウザも互換のため要求し続ける
<link rel="icon" type="image/png"> の href が指す PNGモダンブラウザは sizes が一致する PNG を優先Chrome、Firefox、Safari がデバイスピクセル比に最も近いサイズを選ぶ
<link rel="apple-touch-icon"> の href が指す画像iOS Safari、アドレスバーと「ホーム画面に追加」の双方標準サイズは 180×180

Android Chrome で PWA としてインストールすると、リクエストは増えます：

リクエスト用途
/site.webmanifest（または manifest.json）Chrome、Edge、Brave、Samsung Internet — PWA をインストールできる場所すべて
manifest の icons 配列で宣言された 192×192 と 512×512 PNGAndroid ホーム画面アイコン、起動画面、Android 共有シート

それらの manifest エントリに purpose: "any maskable" を加えると、Android はランチャーテーマに応じて円形または角丸正方形のマスクをアイコンに適用し、ランチャーグリッドでネイティブアプリのように見せます。Maskable アイコンは見える部分のマーク周辺に約 10% のセーフゾーン余白が必要で、そうしないとランチャーマスクが端を切り取ります。

そして長い長いテールがあります。Windows タイルはかつて browserconfig.xml を要求しましたが、Microsoft は Windows 10 で廃止し、今日はもう必要ありません。Safari のピン留めタブは <link rel="mask-icon"> 経由の単色 SVG を使います。PWA 以前の古い Android Chrome は apple-touch-icon をフォールバックとして使いました。これらは 2026 年では主流ではありませんが、なぜ古いジェネレーターが 20 個以上のファイルを吐くのに、本当に欲しいのは 11 個だけなのかを説明してくれます。

なぜ単一の favicon.ico では足りないか

歴史的なデフォルトは、ICO を 1 つサイトルートに置いてブラウザに任せる、でした。モニタが最大 1280×1024、タブが 16 ピクセル四方だった頃はそれで十分でした。2 つの出来事がそれを壊しました：

  1. Retina ディスプレイ。 16×16 の ICO をブラウザが 32 論理ピクセルに拡大して 2× ディスプレイで表示すると、ぼやけます。<link rel="icon" type="image/png" sizes="32x32"> タグはブラウザにデバイスピクセル比に合った正しいリソースを選ばせます。
  2. タブ以外の OS サーフェス。 iOS dock アイコン、Android ホーム画面タイル、PWA 起動画面、Windows Edge タイル — それぞれが特定のサイズをサンプリングし、誰も 16 ピクセルの ICO は欲しがりません。180、192、512、それからどれが何かを伝える manifest が欲しいのです。

修正策はモダンセットです：互換のための小さな ICO、モダンな <link rel="icon"> チェーンのための数枚の PNG サイズ、iOS 用の apple-touch-icon、maskable PWA アイコンを含む webmanifest。

完全なファイルリストと各ファイルのランタイム役割

ZeroTool ジェネレーターが出力するファイルと、ランタイムで誰が使うかを並べます：

ファイルサイズ利用場面
favicon.ico16+32+48 マルチサイズ古いブラウザ、ブックマークマネージャ、「規範名を最初にリクエスト」コードパス
favicon-16.png16×16標準 DPI モニタのブラウザタブ
favicon-32.png32×32Retina モニタのタブ、一部のブックマーク UI
favicon-48.png48×48Windows サイトショートカット、一部の SERP プレビュー
favicon-64.png64×64より高密度のマークを必要とする一部のアドレスバー UI
favicon-96.png96×96manifest インストールなしの Android Chrome ショートカット
favicon-128.png128×128古い Chrome web app ショートカット
apple-touch-icon.png180×180iOS Safari「ホーム画面に追加」、iPad dock
android-chrome-192.png192×192PWA インストール経由の Android ホーム画面（manifest icon）
android-chrome-512.png512×512Android 起動画面、共有シート、Play Store スタイルのカード
site.webmanifesttext192/512 PNG・テーマカラー・purpose: any maskable を宣言

11 ファイルです。素材が絵文字や単純な SVG なら全体で約 25 KB、4K 写真を 512×512 に縮小して投入すると約 200 KB になります。

ICO 形式の仕組み

favicon.ico はセット中で最も奇妙なファイルです。PNG より古く、Windows 3.0 で生まれ、当初はデバイス独立ビットマップ（DIB / BMP）フレームを運んでいました。今のジェネレーターはほとんどが PNG 圧縮エントリを使い、Windows Vista 以降のシェル、IE 11、それ以降のすべてのブラウザがネイティブサポートしています。PNG 圧縮エントリは小さく、アルファを保持し、フォーマットも素直です。

ICO ファイルは次の構造です：

ICONDIR (6 バイト)
├── reserved (2 バイト、ゼロ)
├── type (2 バイト、1 = ICO、2 = CUR)
└── count (2 バイト)

ICONDIRENTRY × count (各 16 バイト)
├── width (1 バイト、0 は 256 を意味)
├── height (1 バイト、0 は 256 を意味)
├── colorCount (1 バイト、32-bit ではゼロ)
├── reserved (1 バイト、ゼロ)
├── colorPlanes (2 バイト、1)
├── bitsPerPixel (2 バイト、32)
├── imageSize (4 バイト)
└── imageOffset (4 バイト — ICO ファイル内の絶対オフセット)

(画像ペイロードはディレクトリの後ろに連結)

PNG エントリの場合、imageSize は完全な PNG ファイル（自身の IHDR / IDAT / IEND チャンクを含む）のサイズで、imageOffset はその PNG の最初のバイトを指します。ICONDIRENTRY の width/height は PNG 自身の幅・高さと食い違ってもよく、OS が表示するのは PNG の固有サイズです。ICONDIRENTRY の値は良くて参考値です。一致させておけばどのシェルも満足します。

ZeroTool ジェネレーターは 16・32・48 の PNG を ICO に詰めますが、それより大きいサイズは入れません。Windows のツールがレガシー ICO コンテナから 48 を超える画像を選ぶことはほぼなく、より大きい PNG はモダンな <link rel="icon"> チェーンと manifest で公開済みだからです。256×256 を ICO に入れる古いレシピは apple-touch-icon 登場前のもので、2026 年は apple-touch-icon と android-chrome PNG がその領分を引き受けます。

ZIP コンテナの仕組み

ブラウザは 11 ファイルを 11 回のダウンロードを発火させずに 1 クリックで届ける必要があり、ジェネレーターはそれらを ZIP にまとめます。ZIP はサードパーティツールなしにどの OS でも開けるため、長年デフォルトコンテナです。中身は層構造です：local file header と続くペイロードのシーケンス、その後すべてのエントリをリストする「central directory」、最後にリーダーへ central directory の開始位置を伝える「end-of-central-directory」レコード。

各エントリのペイロードエンコード方法は 2 つ：STORED（無圧縮）か DEFLATE。PNG はすでに圧縮されているため、再度 DEFLATE をかけてもおよそ 0.5–1% しか縮みません — ページバンドルに deflate 実装を載せる価値はありません。ZeroTool ジェネレーターは全エントリで STORED を使い、DEFLATE が要求するであろう約 5 KB のコードを節約します。

CRC-32 は ZIP 仕様で唯一スキップできない部分です。各エントリは未圧縮バイトの 32-bit CRC を必ず持つ必要があります。ジェネレーターはスクリプト起動時に 256 エントリのルックアップテーブルを事前計算し、ファイル毎にバイトを 1 回スキャンします。ファイル名は General Purpose Bit Field のビット 11 で UTF-8 として宣言され、macOS Finder、Windows Explorer、7-Zip で非 ASCII 名がそのまま読めます。

Canvas パイプライン

各 PNG の描画は同じ 5 ステップを踏みます：

// 1 つのターゲットサイズの擬似コード
const canvas = createCanvas(size, size);
const ctx = canvas.getContext('2d');

if (shape !== 'square') {
  drawShapePath(ctx, shape, size);
  ctx.clip();           // 角丸 / 円形のアルファマスク
}
if (bgMode === 'color') {
  ctx.fillStyle = bgColor;
  ctx.fillRect(0, 0, size, size);
}
const inner = size * (1 - padding * 2);
drawSourceCentered(ctx, source, size, inner);  // emoji / text / image / svg
const pngArrayBuffer = await canvasToPng(canvas);

canvas.toBlob('image/png') が重労働を担います — リサンプリング、ディザリング、アルファエンコーディング。出力は完全な PNG ペイロードで、IHDR、1 つ以上の IDAT チャンク、IEND を含みます。多くのモダンブラウザは IDAT 内で適度な zlib 圧縮レベルをデフォルトとしており、16×16 のマークなら通常ファイル毎に 200–400 バイトに収まります。

明示的にハンドルすべき失敗モードは 3 つあります：

  1. クロスオリジン SVG コンテンツによる canvas タイント。 ユーザーが貼り付けた SVG が <image href="https://example.com/x.png"> を読み込むと、ブラウザはピクセルを blob として読み戻すのを拒否します。canvas.toBlob を try/catch で囲み、明確なメッセージを出します：「SVG が外部リソースを参照しています。先に画像をインライン化してください。」
  2. 絵文字フォントの不在。 一部の IT 管理 Linux ディストロにはカラー絵文字フォントが入っていません。Canvas は空の矩形を描画し、結果の PNG は白紙になります。ctx.measureText('🚀').width === 0 で検出し、Image または SVG 入力への切替を促します。
  3. 4K 画像と 9 つのターゲットサイズによるメモリ圧迫。 直列に生成し、各 toBlob を await し、バイトを読み終えたらすぐ object URL を revoke してください。9 枚の高解像度 canvas を同時にメモリに保持すると iPad の Safari がクラッシュします。

SVG・絵文字・クロスプラットフォーム一貫性問題

最も微妙な出力差はカラー絵文字フォントから来ます。macOS は Apple Color Emoji、Windows は Segoe UI Emoji、Android と Linux デスクトップは Noto Color Emoji を出荷することが多い。同じ Unicode コードポイントが意味のある形状差で 3 通りに描かれます：

  • 🚀 は Apple Color Emoji では細い白い窓を持つ黄色いロケット
  • 🚀 は Segoe UI Emoji ではより平たく、窓の色がより暗い
  • 🚀 は Noto Color Emoji ではエッジがより丸く、影も異なる

macOS で favicon を生成し、Windows から訪問者が来ても、訪問者は生成された favicon を見るだけです — バイトはすでに PNG に焼き込まれています。Canvas レンダラーは絵文字を開発者のマシンで描かれた通りにキャプチャし、それらのピクセルをすべての訪問者に届けます。だからマシンを 1 台選び、1 度生成すれば、その後すべての訪問者にとって結果は一貫します。一貫性が問題になるのは開発者自身の反復作業です：6 か月後に別の OS で再生成すると、わずかに異なる favicon が出力されます。

マシン横断でピクセル単位の一致が欲しければ、Image または SVG 入力に切り替えてください。SVG ベクターマークは OS フォントスタックではなく SVG 自身に基づいて決定論的にビットマップ化されます。代償は SVG が自己完結している必要があることです — リモートリソースへの <image href> 不可、外部 <use> フラグメント不可、リモート @font-face URL 不可。貼る前にすべてをインライン化してください。

HTML スニペットがやってくれること

ジェネレーターはこのスニペットを出力し、<head> の中に置きます：

<link rel="icon" type="image/x-icon" href="/favicon.ico">
<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16.png">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32.png">
<link rel="icon" type="image/png" sizes="48x48" href="/favicon-48.png">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">
<meta name="theme-color" content="#ffffff">

いくつかの細かい点：

  • 順序は思っているほど重要ではありません — モダンブラウザはすべての <link rel="icon"> 候補をパースし、sizes と type で最良マッチを選びます。ICO を最初に置くのは慣習であり要件ではありません。
  • <meta name="theme-color"> はモバイル Safari と Chrome のアドレスバー、インストール済み PWA のタイトルバーの色を制御します。favicon ではありませんが、同じ head 内に住み、ブランドカラーの判断を共有するため favicon セットと一緒に旅をします。
  • ファイル名 site.webmanifest は慣習で、多くのチュートリアルは manifest.json を使います。どちらでも動きます。プロジェクトの他箇所が使っている方に合わせるのが楽です。
  • iOS は manifest icons を読みません — 常に apple-touch-icon を選びます。Android Chrome は両方ある場合 manifest icons を優先します。

他のジェネレーターとの比較

RealFaviconGenerator は長年の標準です。ソース画像をサーバーにアップロードし、より広範なレガシー形式（Microsoft tile、Safari pinned-tab SVG、Windows 8 metro）を含めてサーバー側でパッケージを生成し、約 25 ファイルを出力します。トレードオフはアップロードのステップと出力サイズの大きさです。

favicon.io は精神的に ZeroTool に最も近い：シンプルな入力（絵文字、テキスト、画像）、小さなパッケージ、アップロードなし。webmanifest は現在出力していません。

ZeroTool ジェネレーターは 2026 年のベースラインを狙います：11 ファイル、maskable PWA アイコンを含む webmanifest、サーバーアップロードなし、コピー＆ペースト可能な HTML スニペット。Microsoft Tile サポートや Safari pinned-tab SVG が必要なら、RealFaviconGenerator が今でも正解です。個人サイトや社内ダッシュボードのための絵文字駆動 favicon なら、ZeroTool が速い。

デプロイ前チェックリスト

パッケージをデプロイする前に、これらを通してください：

  1. 11 ファイルをサイトルートに配置。 ほとんどのホストは <link> タグなしでも /favicon.ico を 200 で返します。/assets/icons/ ではなくルートに置いてください。
  2. HTML スニペットを <head> 内に貼る。 ICO は暗黙にフェッチされますが、PNG と apple-touch-icon は明示的な <link> タグが必要です。
  3. site.webmanifest の name と short_name を更新。 プレースホルダ名で出荷しないよう、ジェネレーターは空のままにしています。
  4. DevTools の Application パネルでテスト。 Application → Manifest はパースされた manifest、解決されたアイコン、エラーを表示します。Chrome の「Show maskable icon」トグルで maskable レンダリングをテスト。
  5. iOS パスをチェック。 実機 iPhone（または iOS シミュレータ）で「ホーム画面に追加」し、apple-touch-icon が細い白枠なしで表示されることを確認。iOS は角丸を自動付与しますが背景は自動付与しません — 背景透過のアイコンは iOS が白で埋め、ダーク壁紙では奇妙に見えることがあります。
  6. Google SERP favicon を検証。 Google は最低 8×8 を要求し、最低 48×48 を推奨します。マルチサイズ ICO は両方をカバーします。Search Console（Coverage → Favicons レポート）で確認。
  7. ブランドが変わったら作り直す。 favicon セットを一回限りの資産ではなくビルド成果物として扱ってください。ソースファイル（ジェネレーターに与えた SVG または高解像度 PNG）をバージョン管理に入れ、マークやテーマカラーが変わったら同じソースから再生成します。

プライバシーに関するメモ

パイプライン全体がブラウザ内で動くため、ソース画像はどのバージョンも端末を離れません。これは響き以上に重要です：未発表プロダクトの favicon を生成するとき、使ったジェネレーターにブランドマークを漏らすことになります。RealFaviconGenerator のプライバシーポリシーは率直ですが、アップロードは依然として発生します。ZeroTool は画像をローカルに留めます。DevTools → Network を開いて Generate を押せば、外向きリクエストはちょうど 1 件、ノンブロッキングのアナリティクス送信で、ペイロードはツール名のみです。

さらに読む

ZeroTool 関連ツール：SVG → PNG 変換器、WebP 変換器、画像 Base64 変換器、QRコードジェネレーター。