タイプスケール：13段階を選んだ理由と比率が重要な理由

Robert BringhurstのThe Elements of Typographic Styleは、調和のとれた書体関係が音楽と同じ数学的比率に従うことを確立しました。完全四度（1.333）、完全五度（1.5）、黄金比（1.618）です。私は完全四度から始めましたが、最終的にはどの標準比率でも生成できないカスタムプログレッションにたどり着きました。なぜなら、本文とディスプレイ見出しの間に、コンテンツ構造が特定のステップを要求したからです。¹

TL;DR

タイプスケールとは、ベースサイズと数学的比率からフォントサイズの階層を生成するものです。blakecrosley.comのタイポグラフィシステムを構築した後——0.75rem（12px）から5rem（80px）までの13段階、システムフォントのみを使用——比率そのものよりも、本文とH1の間のステップ数の方が重要だということを学びました。私のスケールは隣接するステップ間でおよそ1.18のプログレッションを使用していますが、コンテンツ構造が視覚的な分離を必要とする箇所では意図的なジャンプ（3.875remから5rem）を設けています。以下のインタラクティブな比較で、厳密な比率とコンテンツ駆動の調整の違いをご確認いただけます。

私のタイプスケール：13段階

これが私のサイトのcritical.cssから抽出した実際のスケールです。

:root {
  --font-size-xs:      0.75rem;   /* 12px — metadata, timestamps */
  --font-size-sm:      0.875rem;  /* 14px — captions, fine print */
  --font-size-base:    1rem;      /* 16px — body text, default */
  --font-size-lg:      1.125rem;  /* 18px — lead paragraphs */
  --font-size-xl:      1.3125rem; /* 21px — large body, section intro */
  --font-size-2xl:     1.5625rem; /* 25px — H4, card titles */
  --font-size-3xl:     1.875rem;  /* 30px — H3 */
  --font-size-4xl:     2.25rem;   /* 36px — H2 */
  --font-size-5xl:     2.7rem;    /* 43.2px — H1 */
  --font-size-6xl:     3.25rem;   /* 52px — large H1 */
  --font-size-7xl:     3.875rem;  /* 62px — page title */
  --font-size-display: 5rem;      /* 80px — hero headline */
}

隣接するステップ間のプログレッションは厳密な数学的比率ではありません。xsからxlまでのステップはおよそ1.17〜1.18倍に従います。5xlからdisplayまでのステップはより積極的にジャンプします（1.20〜1.29倍）。これは、ヒーローの見出しがページレベルの見出しから視覚的に分離される必要があるためです。²

なぜ厳密な比率を使わないのか？

厳密な長3度（1.25）で16pxのベースから計算すると、次のステップが生成されます：16、20、25、31.25、39.06、48.83、61.04。本文（16px）からH3（31.25px）へのジャンプはほぼ2倍——H3が頻繁に出現するコンテンツ量の多いページでは劇的すぎます。私のスケールは中間範囲（18、21、25、30、36）を圧縮して見出しを本文に対して比例的に保ちつつ、上位範囲（43、52、62、80）をディスプレイタイポグラフィ用に拡張しています。

スケールを決定したのは数学ではなく、コンテンツ構造です。すべてのステップを実際のブログ記事のコンテンツに対してテストし、スクイントテストに失敗した箇所でサイズを調整しました。³

なぜシステムフォントなのか

私のフォントスタックはこちらです。

:root {
  --font-family: -apple-system, BlinkMacSystemFont, "SF Pro Text",
                 "SF Pro Display", "Helvetica Neue", Arial, sans-serif;
}

パフォーマンスの観点

システムフォントの読み込み時間はゼロミリ秒です。ネットワークリクエストなし、FOIT（Flash of Invisible Text）なし、FOUT（Flash of Unstyled Text）なし。この選択は私のLighthouseパフォーマンススコア100/100に貢献しています。

カスタムWebフォントは通常、フォントファイルのダウンロードとブラウザのレンダリング判断により、First Contentful Paintに100〜300msを追加します。Google FontsはCDNから読み込まれます（最低でもDNSルックアップ1回 + HTTPリクエスト1回）。セルフホストのフォントはDNSルックアップを排除しますが、ダウンロードは依然として必要です。システムフォントはフォント読み込みレイテンシのすべての要素を排除します。⁴

デザインの観点

システムフォントはプラットフォームに合致します。macOSでは、私のサイトはSF Proでレンダリングされます——macOSのシステムUI、Apple Mail、Safariのクロームで使用されているのと同じ書体です。オペレーティングシステムとウェブサイト間の視覚的な連続性は、ブランド的というよりもネイティブに感じられます。

Linear、Vercel、Raycastも同じアプローチを採用しています。このパターンは私の16のプロダクトデザインスタディから浮かび上がりました。ブランド表現よりもコンテンツの可読性を優先するプロダクトは、システムフォントを使用する傾向があります。

カスタムフォントが価値を持つ場合

カスタムフォントは、マーケティングページ、ブランドアイデンティティ、書体そのものがデザインであるディスプレイタイポグラフィに適しています。私のサイトはコンテンツファーストです（ブログ記事、プロジェクト説明）。タイポグラフィは透明であるべきで、読者はフォントではなくコンテンツを処理するべきです。

ウェイトシステム

4つのウェイトですべての階層ニーズに対応します。

:root {
  --font-weight-normal:   400;  /* Body text */
  --font-weight-medium:   500;  /* Navigation, labels */
  --font-weight-semibold: 600;  /* Subheadings, emphasis */
  --font-weight-bold:     700;  /* Headlines, primary actions */
}

13段階のサイズと4段階の不透明度ティアを組み合わせると、208通りの潜在的な組み合わせ（13サイズ × 4ウェイト × 4不透明度）が得られます。実際には、一貫して使用しているのはおよそ15通りです。このシステムは、すべてのテキストインスタンスで決定を要求することなく柔軟性を提供します。ほとんどのテキストはbaseサイズ、normalウェイト、primary不透明度を使用します。⁵

レスポンシブタイポグラフィ

単一比率の問題

デスクトップ向けに設計されたタイプスケールは、モバイルでは見出しが大きすぎます。displayサイズの80pxは1440pxのビューポートでは美しく映りますが、375pxのスマートフォン画面では圧迫感があります。システム全体をビューポート単位でスケーリングする代わりに、特定のブレークポイントでオーバーライドしています。

@media (max-width: 1024px) {
  .hero__title { font-size: var(--font-size-6xl); }  /* 52px */
}

@media (max-width: 768px) {
  .hero__title { font-size: var(--font-size-3xl); }  /* 30px */
}

本文は全ビューポートで16pxのままです。16pxはすべてのモダンスクリーンで読みやすいため、本文をスケーリングする必要はありません。ディスプレイサイズと見出しサイズのみが、より小さいビューポートで縮小されます。このアプローチはフルードタイポグラフィ（clamp()）よりもシンプルで、既知のブレークポイントで予測可能な結果を生み出します。⁶

ディスプレイサイズでの字間調整

大きな文字にはよりタイトなトラッキングが必要です。80pxでは、デフォルトの字間が文字間に目に見えるギャップを生み出します。

.hero__title {
  font-size: var(--font-size-display);
  font-weight: var(--font-weight-bold);
  letter-spacing: -0.03em;
  line-height: 1.05;
}

-0.03emの字間と1.05の行高は、タイトでインパクトのある見出しを生み出します。本文の16pxではデフォルトの字間に、読みやすさのための余裕ある1.7の行高を使用しています。タイトな見出しとゆったりした本文のコントラストが、装飾なしで視覚的なリズムを生み出します。⁷

タイポグラフィのテスト

スクイントテスト

目をぼかすか、画面から離れてみてください。見出しの階層は、すべてのレベルで視覚的に区別できるべきです。H3とH4が混ざって見える場合、選択したフォントに対して比率が小さすぎます。

私のスケールにスクイントテストを適用したところ、--font-size-xl（21px）と--font-size-2xl（25px）が最初は区別しにくいことがわかりました。ウェイトの差を追加すること（xlはnormal 400、2xlはsemibold 600を使用）で、サイズを変更せずに区別を解決しました。ウェイトはサイズとは独立して階層を提供します。⁸

コンテンツテスト

すべての見出しレベルに実際のコンテンツを入れてください。プレースホルダーテキストは、「Lorem Ipsum」に実際の言語が持つ視覚的なウェイトの変化がないため、階層の問題を隠してしまいます。私はスケールのすべての調整を、最も長いブログ記事（ハミング誤り訂正、H2、H3、H4、コードブロック、テーブル、脚注を含む2000語以上）に対してテストしています。最も複雑なコンテンツでスケールが機能すれば、すべてのコンテンツで機能します。

重要なポイント

デザイナーの方へ： - ベースサイズ16pxから始め、1.15から1.25の間の比率を実際のコンテンツに対してテストしてください。厳密な数学的比率は、極端な値においてコンテンツ駆動の調整を必要とすることがよくあります - 確定する前にスクイントテストとコンテンツテストを実施してください。すべての見出しレベルでの視覚的な区別は、数学的な純粋さよりも重要です

デベロッパーの方へ： - タイプスケールは:rootレベルのCSSカスタムプロパティとして定義してください。コードベース全体でvar(--font-size-*)を参照することで、任意のフォントサイズが蓄積するのを防ぎます - カスタムWebフォントの前にシステムフォントを検討してください。100〜300msのフォント読み込み節約はすべてのページ読み込みで蓄積され、システムフォントはプラットフォームネイティブの可読性を提供します - 既知の幅での予測可能な結果がスムーズな補間よりも重要な場合、フルードタイポグラフィではなくディスプレイサイズのブレークポイントオーバーライドを使用してください

参考文献