画面の文字を読みやすくする技術の4段階 — 活版印刷から可変フォントまでと、いまのサイトでの選び方

画面の文字をめぐる技術は、「字形をどこまで後から変えられるか」を拡げ続けてきました。活版印刷では形とサイズが物理的に固定され、デジタルフォントで拡大縮小が自由になり、Webフォントで端末にない書体も配信できるようになり、可変フォントで太さや幅が連続した値になりました。自由度が上がるたびに、読みやすさを決める責任は書体を作る側から実装する側へ移っています。いま企業サイトで決めるべきなのは、本文・見出し・アイコンのそれぞれに、どの段階の道具を割り当てるかです。

第1段階：活版印刷 — サイズごとに設計が分かれていた

金属活字の時代は、1つのサイズ・1つのスタイルごとに物理的な活字が必要でした。小さく組む本文用は太く余裕をもたせ、大きく使う見出し用は細部を繊細に、というようにサイズごとに別設計がなされます。読みやすさは紙とインクの条件に合わせて作り込まれていた一方、同じ原版を別サイズに流用する自由度はありませんでした。W3Cもウェブの影響を活版印刷の発明になぞらえていますが、技術的に見れば両者は正反対です。印刷は「固定された字形を大量に複製する」仕組み、ウェブは「読者の環境に合わせて字形を可変にする」仕組みだからです。なお「サイズごとに最適な字形」という発想は失われたわけではなく、後述する可変フォントの光学サイズ軸として復活しています。

第2段階：デジタルフォント — 1つのアウトラインで全サイズをまかなう

アウトラインフォント（字形を曲線データで持つ形式）の登場で、1つのデータから任意のサイズを描けるようになりました。現在のWeb上のフォントも、約92〜93%がTrueType系のアウトライン、残り約7%がPostScript系（CFF）です。

ただしウェブでは長く「閲覧者の端末に入っているフォントしか使えない」制約が残りました。HTTP Archiveの集計では、2011年時点で独自のWebフォントを配信していたサイトは3〜5%にすぎません。そのため見出しを画像化する運用が広がり、拡大すると粗くなる・読み上げられないという問題を生みました。WCAG 2.2の達成基準1.4.4は、支援技術なしで200%まで拡大してもコンテンツや機能が損なわれないことを求めており、文字画像はこの拡大に追随できない点が弱点になります。

この段階の道具は今も有効です。2025年のデータではsans-serifの指定が約89%のページに、system-uiが約10%のページに現れます。本文をシステムフォントで組めば、フォントの転送量はゼロで、読み込み中のちらつきも起きません。

第3段階：Webフォント — 配信できる代わりに「読み込み中」が課題になった

@font-faceは1998年にCSS2へ採用されましたが、ライセンスや不正利用への懸念から10年以上ほとんど使われませんでした。転機は2010年7月に公開されたWOFF 1.0の最初の草案で、2014年5月に草案が出たWOFF 2.0はWOFF 1.0比で最大40%小さくなり、2018年にW3C勧告となっています。2025年には約88%のサイトがWebフォントを使い、フォントファイル要求の約65%がWOFF2です。

代わりに生まれたのが「ダウンロード完了までどう表示するか」という問題です。font-displayは読み込みを3つの期間（非表示・代替表示・失敗）に分けて制御します。実際の採用はswapが約50%、blockが約25%ですが、blockの約7割はアイコンフォント由来で、本文に非表示期間を設けている例はごく少数です。

日本語サイトでは重さが直接効きます。フォントファイルの中央値は35〜36KB、90パーセンタイルは115KB前後ですが、漢字を含むフォントは全体の0.4%程度にとどまり、大きすぎて配信を避けられていることがうかがえます。実際、Noto Sans JPはほぼGoogle Fonts経由で配信されており、自己ホストは要求全体の0.2%ほどです。

第4段階：可変フォント — 太さや幅が連続した値になった

可変フォントは、太さ（wght）・幅（wdth）・傾き（slnt）・イタリック（ital）・光学サイズ（opsz）といった登録軸を1ファイルに持ち、中間の値も指定できます。登録軸はCSSのfont-weightなどの通常のプロパティで扱え、font-variation-settingsはフォント独自のカスタム軸に使うのが基本です。光学サイズはfont-optical-sizingが既定で自動になり、文字サイズに応じてブラウザが選びます。Monotypeの実験では、48個の静的フォントに相当する内容を1つの可変フォントにまとめてファイルサイズが88%削減されました。

普及も進み、2025年はデスクトップの39.4%、モバイルの41.3%が少なくとも1つの可変フォントを使っています。ただし使われ方は限定的で、CSSで操作される軸はwghtが57〜61%と突出し、アニメーションに使うページは全体の0.3%程度です。多くの現場では「複数ウェイトを1ファイルで配る手段」として使われている、というのが実態です。最も使われている可変フォントはNoto Sans JPで、可変フォント利用ページの4分の1を占めます。

いまのサイトでの選び方

4段階は置き換えの歴史ではなく、選択肢が積み重なった結果です。次の順で決めると判断がぶれません。

• 使うスタイル数で可変か静的かを決める：本文と見出しで1〜2ウェイトしか使わないなら、サブセットした静的WOFF2のほうが軽くなります。3ウェイト以上、または中間ウェイトや画面幅に応じた微調整が必要なら可変フォントが有利です。
• 和文は「書体選び」より先に「配信方法」を決める：グリフ数が多いため、可変化しても欧文ほど節約が効きません。Google Fontsのような分割配信に任せるか、自前でサブセット（必要な文字だけに絞る処理）を運用するかを先に決めます。
• font-displayは用途ごとに分ける：本文・見出しはswap、アイコンフォントはblock、レイアウトのずれを最優先で抑えたい場合はoptionalにsize-adjustなどの代替フォント調整を組み合わせます。
• 先読みは絞る：preloadは2025年で約12%、preconnectは約18%のページが使っています。最初に見える1ファイルだけに限定し、増やしすぎないのが安全です。
• アクセシビリティを設計条件に入れる：200%拡大（1.4.4）と、行間1.5倍・段落間2倍・字間0.12倍・単語間0.16倍への上書き（1.4.12）に耐えることが求められます。固定高さ、不要なoverflow: hidden、折り返しを禁じるwhite-space: nowrapがよくある失敗原因です。これらは制作者が既定値として設定する必要はなく、上書きされても壊れないことが要件です。

将来を見ると、W3CはIncremental Font Transfer（必要な文字だけを段階的に取得する仕組み）の標準化を進めており、日本語のような大きな文字セットの前提が変わる可能性があります。いま自己ホストで大きなファイルを固定的に抱え込むより、サブセットや配信元を差し替えられる形にしておくほうが、移行コストは小さくなります。

次の一手は棚卸しです。自サイトが読み込んでいるフォントファイルの数と合計サイズ、font-displayの指定、実際に使っているウェイトの種類を一覧にしてください。使っていないウェイトが混ざっていないか、本文が可変フォント1ファイルで足りるかを確認するだけでも、表示速度と読みやすさの両方を改善できます。

出典

• HTTP Archive: 2025年 Web Almanac「フォント」の章
• W3C ブログ: WOFF 1.0 — ウェブのフォントをめぐるW3Cの歩みの節目
• W3C: WOFF File Format 2.0（勧告）
• MDN Web Docs: font-display 記述子
• MDN Web Docs: font-variation-settings プロパティ
• web.dev: ウェブにおける可変フォント入門
• Google Fonts: Webフォントの使い方
• WAIC: Web Content Accessibility Guidelines (WCAG) 2.2 日本語訳
• WAIC: 解説書 達成基準 1.4.12 テキストの間隔