モジュラータイプスケール：一貫性のあるタイポグラフィシステムを構築する方法

モジュラー型フォントスケールとは、製品内のすべてのフォントサイズを生成するために、1つの基本サイズに1つの比率を適用するものです。これが基本的な考え方です。比率を選択し、基本サイズを固定し、ステップを生成し、トークンとして配布します。そして、個別のピクセル値ではなく、これらのトークンをあらゆる場所で使用します。適切に実装すれば、製品内のすべてのサイズが互いに関連しているように感じられます。なぜなら、数学的に関連しているからです。

しかし、不適切に実装すると、誰も説明できない17種類のフォントサイズ、本文と階層構造が矛盾する見出し、そして四半期ごとに開催される再設計会議で「サイズを標準化しよう」という提案が出され、誰も何を基準に標準化すべきか分からないという事態に陥ります。標準化の基準となるのは、まさにこのスケールです。この記事では、実際の製品で通用する、実際の比率、実際のトークン構造、そしてそれを実行可能にするFigmaとTailwindの翻訳機能を備えた、モジュラー型フォントスケールの構築方法を解説します。

モジュラータイプスケールとは

モジュラータイプスケールとは、製品内のすべてのフォントサイズを生成するために、基本サイズに単一の比率を適用するものです。そして、その単一の比率こそが重要なのです。

例えば、基本サイズを16ピクセル、比率を1.25とします。16に1.25を掛けると20になります。20に1.25を掛けると25になります。これを繰り返すと、31、39、49、61となります。16を1.25で割ると12.8になります。これを1.25で割ると10.24になります。これがスケールです。8つのサイズ、1つの基本サイズ、1つの比率、完全な数学的一貫性。

これが機能する理由は心理物理学的なものです。人間の視覚は絶対的な差ではなく、比率に反応するからです。 12から14へのジャンプは、24から28へのジャンプとほぼ同じように感じられます。なぜなら、どちらもほぼ同じ乗数ステップだからです。線形スケール（12、14、16、18、20、22）は、上部が窮屈に感じられ、下部が広すぎるように感じられます。モジュラースケールは、相対的に均等であるため、均等に感じられます。

同じ論理は、音楽の音程（オクターブは2倍、5度は1.5倍、4度は1.333倍）、写真の絞り、そして建築の比率理論の大部分にも当てはまります。タイポグラフィはそれを借用しただけです。この記事で紹介する比率（短2度、完全4度、黄金比）は、音楽から借用されたものであり、同じ種類の知覚的関係性を表しています。

実際の製品に適用される5つの比率

ほとんどの製品は1.125から1.618の範囲にあり、それぞれの比率は特定の密度シグナルを持っています。

ほぼすべての実際のインターフェースを網羅する5つの比率：

| 比率 | 名称 | 密度シグナル | 実際の実装例 |

|------:|------|----------------|---------------------|

| 1.125 | マイナーセカンド | タイトで密度が高く、データ量が多い | Vercel、Geist、ほとんどの管理ダッシュボード |

| 1.2 | マイナーサード | コンパクトでバランスが良い | Tailwindのデフォルトスケール |

| 1.25 | メジャーサード | 標準的な編集レイアウト | Stripe、Material 3のボディロール |

| 1.333 | パーフェクトフォース | ゆったりとした雑誌のような雰囲気 | 編集サイト、長文ブログ |

| 1.618 | ゴールデンレシオ | ドラマチックでディスプレイ主導型 | マーケティングページ、ヒーローパネルサイト |

さらに2つの比率が時折登場します。 1.414（拡大4分の1、つまり2の平方根であり、A4用紙の比率）は、完全4分の1と完全5分の1の中間に位置し、1.333よりもさらにドラマチックな印象を与えたい雑誌風の製品には適切な選択肢です。1.5（完全5分の1）は1.333よりも強調され、1.618よりも控えめな比率で、多くのマーケティングページ作成ツールのデフォルト設定となっています。

この範囲外の比率も使用できますが、通常は避けるべきです。1.1未満では、ステップが非常に小さいため、見出し3と見出し4を一目で区別することができません。1.7を超えると、スケールが急激に変化するため、適切な中間サイズがなくなります。1.618よりも広い範囲を求めるデザイナーは、通常、間違った問題を解決しようとしています。彼らは、より大きな1つのスケールではなく、2つのスケールを必要としているのです。

密度に応じて適切な比率を選びましょう

データ密度の高いアプリケーションにはタイトな比率が適していますが、編集サイトにはワイドな比率が適しています。間違った比率を選ぶと、あらゆる下流工程に影響が出てしまいます。

ダッシュボード、管理パネル、CRM、分析ツールなど、ユーザーが何時間もかけて大量の情報を読むような製品の場合は、1.125または1.2をデフォルトに設定しましょう。タイトな比率にすることで、見出しのサイズがデータからユーザーの注意を逸らすことを防ぎます。このスケールでは、階層構造は主に太さ、色、間隔によって決まるため、サイズではなく、階層構造が効果的に機能します。

SaaSのマーケティングページ、コンテンツサイト、製品ページ、ドキュメントページなどの製品の場合は、1.25または1.333をデフォルトに設定しましょう。中間の比率は、見出しに十分なインパクトを与え、セクションを区別しつつ、本文が相対的に小さく見えることを防ぎます。ほとんどのB2B製品はこの範囲で動作し、Tailwind、Material、Stripeといったツールもこの比率を採用しています。

製品が編集記事、雑誌風、またはディスプレイ広告中心のコンテンツ（長文記事、ファッションサイト、キャンペーン用マイクロサイトなど）の場合は、デフォルトで1.414または1.618の比率を使用してください。この比率は、見出しがまさに見出しらしく、ヒーローブロック全体を占めるにふさわしい印象を与えます。ヒーローブロックと本文の間の余白が効果を発揮するため、本文は適切なサイズに抑えることができます。

間違いは、印象的だからという理由だけで比率を選び（黄金比は有名な例です）、その比率を必要のない製品に無理やり適用することです。CRMで1.618の比率は読みにくいノイズのように見えます。編集サイトで1.125の比率は貧弱に見えます。製品に実際に必要な比率を選び、それを固定してください。

スケーリングする前に基本サイズを固定する

基本フォントサイズは、すべてのステップの基準となるものです。これを間違えると、すべてのステップが間違ってしまいます。

Web上の本文テキストのデフォルトは16ピクセルです。ブラウザのデフォルトサイズは16、ユーザーエージェントのスタイルシートも16、成人の推奨読書サイズの中央値も16です。WCAGとAppleヒューマンインターフェースガイドラインのアクセシビリティガイドラインでは、本文の最小サイズは16とされています。対象ユーザーが高齢層に偏っている場合や、製品が読み物が多い場合は17または18にすることもできますが、本文のサイズは16未満にすることは絶対に避けるべきです。

この基準値が乗数となります。16より大きいサイズは、基準値に比率のべき乗を掛けたものです。基準値より小さいサイズは、基準値を比率のべき乗で割ったものです。基準値を変更すると、すべてのステップがずれます。これはシステムの動作原理であり、問​​題ありません。しかし、基準値の変更は画面ごとの微調整ではなく、構造的な変更であり、サイズをリリースする前に一度、意図的に行う必要があります。

モバイル端末の場合は、基準値を15または16に縮小し、相対単位を使用することもできます。印刷物の場合、ベースサイズは通常11または12ポイントで、比率は変わりません。コードブロックを含むドキュメントの場合、本文を16ポイント、コードブロックを14ポイントに設定し、コードスケールにも同じ比率を適用します。ベースサイズは媒体ごと、比率は製品ごとに設定し、どちらも一度設定すれば済みます。

もう一つルールがあります。Webでは、ベースサイズをピクセルではなくremで設定してください。スケール全体をremで表現することで、ユーザーのフォントサイズ設定やアクセシビリティツール（ズーム、リーディングモード、ブラウザのスケーリング）が正しく反映されます。Tailwindは既にこの処理を行っています。Material Designも同様です。AppleのiOSダイナミックタイプも同等の処理を行っています。スケールをピクセルでハードコーディングすると、プラットフォームの制約に反することになります。

ステップを作成し、役割ごとにラベルを付ける

7～9段階のスケールがあれば、製品に必要なあらゆるサイズを網羅できます。サイズではなく、役割ごとに名前を付けてください。

ベースサイズを16ピクセル、比率を1.25とします。手順は以下のとおりです。

• 10 (極小キャプション、脚注)
• 13 (小、補助テキスト)
• 16 (本文、ベース)
• 20 (リード、大本文)
• 25 (h4、小見出し)
• 31 (h3、中見出し)
• 39 (h2、大見出し)
• 49 (h1、ページ見出し)
• 61 (ディスプレイ、ヒーロー)

9つの手順。これが製品全体です。製品によっては7つか8つ、あるいは10個まで使うものもありますが、10個を超えるとサイズが細くなり、誰も使わないサイズになってしまいます。

次に、これらの要素に名前を付けましょう。「text-31」や「39px」ではなく、役割ごとに名前を付けます。キャプション、小、本文、リード、h4、h3、h2、h1、ディスプレイ。エンジニアリング部門との契約はピクセル値ではなく、役割名です。ベースや比率が変わればピクセル値も変わりますが、役割は変わりません。h1は常に最大の見出しです。 bodyは常にベースとなるテキストです。captionは常に判読可能な最小サイズのテキストです。

これがスケールをスプレッドシートではなくシステムたらしめる理由です。デザイナーが「これがbodyです」と指定すれば、エンジニアはtext-bodyを出荷します。次の四半期にスケールが変更されても、bodyは依然としてbodyを意味し、すべてのコンポーネントは新しい値を自動的に取得します。コードベース内の16をすべて探し出して17に変更する必要はありません。

Material Design 3では、display、headline、title、label、bodyという役割ごとに名前が付けられたスケールが提供され、それぞれにサイズバリエーション（large、medium、small）が含まれています。AppleのHIGでは、Large Title、Title 1、Title 2、Title 3、Headline、Body、Callout、Subhead、Footnote、Caption 1、Caption 2が提供されています。Tailwindではtext-xsからtext-9xlまで提供されていますが、これは役割名ではなくTシャツのサイズ表記であり、Tailwindのデフォルト設定がMaterial Designよりも劣っている唯一の点と言えるでしょう。 Tailwindを採用するほとんどのチームは、最終的にTシャツクラスの上に役割名付きのエイリアスを重ねていきます。

スケールをデザイントークンに変換する

トークンは、デザイナーのスプレッドシート上のスケールをチームの契約書へと変換します。

デザイントークンは、デザイン上の決定事項を表す名前付き値です。タイプスケールの場合、3つのレイヤーが必要です。

1. 生のトークン。実際のサイズ値。font-size-100、font-size-200など、またはfont-size-body、font-size-h1のように名前付きです。これらは真の情報源です。

2. 意味トークン。意図を表すエイリアス。text-heading-page、text-body-default、text-captionなどです。意味トークンは生のトークンを指します。コンポーネントは意味トークンを使用し、生のトークンを直接使用することはありません。

3. コンポーネントトークン 特定のコンポーネント内のバインディング。card-title-size は text-heading-card を指し、text-heading-card は font-size-200 を指します。コンポーネントトークンを使用すると、システムを壊すことなくコンポーネントごとにオーバーライドできます。

16進数、1.25比率のスケールに対応する最小限のJSONトークンファイル：

{
  "font-size": {
    "raw": {
      "100": { "value": "0.625rem" },
      "200": { "value": "0.8125rem" },
      "300": { "value": "1rem" },
      "400": { "value": "1.25rem" },
      "500": { "value": "1.5625rem" },
      "600": { "value": "1.9375rem" },
      "700": { "value": "2.4375rem" },
      "800": { "value": "3.0625rem" },
      "900": { "value": "3.8125rem" }
    },
    "semantic": {
      "caption":  { "value": "{font-size.raw.100}" },
      "small":    { "value": "{font-size.raw.200}" },
      "body":     { "value": "{font-size.raw.300}" },
      "lead":     { "value": "{font-size.raw.400}" },
      "h4":       { "value": "{font-size.raw.500}" },
      "h3":       { "value": "{font-size.raw.600}" },
      "h2":       { "value": "{font-size.raw.700}" },
      "h1":       { "value": "{font-size.raw.800}" },
      "display":  { "value": "{font-size.raw.900}" }
    }
  }
}

この構造は移植可能です。Style Dictionary、Tokens Studio、Specify、Supernovaはすべてこの形式を読み込み、Figma 変数、CSS変数、​​Tailwind設定、iOS Swift定数、Android XMLなど、プラットフォームが必要とするあらゆるものを出力します。トークンがソースであり、その他はすべて生成されます。

スケールをFigma変数に格納する

Figma変数は、デザインチームがスケールを管理する場所であり、意味的なエイリアスを持つ単一のタイポグラフィコレクションとして構成されています。

Typographyという名前の変数コレクションを作成します。その中に、size/100からsize/900までの各生サイズに対応する数値変数を追加し、それぞれにrem単位のピクセル値（10、13、16、20、25、31、39、49、61）を設定します。次に、エイリアスを2階層目として追加します。text/caption、text/small、text/body、text/lead、text/h4、text/h3、text/h2、text/h1、text/display。各エイリアスは、生のサイズ変数を参照します。

次に、役割ごとにテキストスタイルを作成します。Heading/H1は、サイズにtext/h1、ファミリーに見出しの書体、ウェイトに見出しのウェイト、行間比率に見出しの行高比率を使用します。Body/Defaultは、本文の書体、標準ウェイトにtext/bodyを使用します。すべての役割について、この手順を繰り返します。

デザイナーは、インスペクターにフォントサイズを直接入力するのではなく、テキストスタイルを使用してインターフェースを構成するという原則があります。チームがこの原則を採用すれば、スケールは自動的に管理されるようになります。カスタムサイズを設定する人は、そのパターンを視覚的に破る必要があり、その視覚的な変化こそがガバナンスの役割を果たします。

複数の密度モードをサポートする場合は、モード設定と組み合わせてください。「コンパクト」モードでは、生のサイズ変数を上書きして、より密度の高い表示を実現するために1.125の比率を使用できます。「快適」モードでは1.25を使用できます。エイリアスは変更されません。コンポーネントも変更されません。スケールがコンポーネントの下で移動するだけです。これがこのシステムが提供するメリットです。

スケールをTailwind CSSに組み込む

エンジニアリングチームにとって、スケールはTailwindの設定ファイルに格納されます。設定はFigmaの変数構造と完全に一致させる必要があります。

TailwindのデフォルトのfontSizeを、tailwind.config.jsで指定するスケールに置き換えてください。

module.exports = {
  theme: {
    fontSize: {
      'caption':  ['0.625rem',  { lineHeight: '1rem' }],
      'small':    ['0.8125rem', { lineHeight: '1.25rem' }],
      'body':     ['1rem',      { lineHeight: '1.5rem' }],
      'lead':     ['1.25rem',   { lineHeight: '1.75rem' }],
      'h4':       ['1.5625rem', { lineHeight: '2rem' }],
      'h3':       ['1.9375rem', { lineHeight: '2.375rem' }],
      'h2':       ['2.4375rem', { lineHeight: '2.875rem' }],
      'h1':       ['3.0625rem', { lineHeight: '3.5rem' }],
      'display':  ['3.8125rem', { lineHeight: '4.25rem' }],
    },
  },
}

これで、マークアップ内のtext-h1は、Figma内のHeading/H1と同じ意味になります。クラス名が契約です。エンジニアはサイズを選択するのではなく、役割を選択します。役割はビルド時に適切なピクセル値に解決されます。

ここでの行の高さは任意ではありません。パターンは次のとおりです。小さいサイズでは本文の行の高さを狭くし、本文とリードでは行間を広くし、見出しでは再び行間を狭くします。一般的なルールは、本文の行の高さを1.5、見出しの行の高さを1.1～1.2とし、リードとh4サイズ付近では1.3～1.4に調整するというものです。これは別のスケール（リーディングスケール）として、またはステップごとの値として表現できますが、サイズとリーディングの関係は目測ではなく、意図的に設定する必要があります。

Tailwindのデフォルトクラスをスケールと併用したい場合（レガシーコードやサードパーティコンポーネントのため）、fontSizeを完全に置き換えるのではなく、extendを使用してください。しかし、長期的な目標はスケールを2つではなく1つにすることです。同じ製品に2つのタイプスケールがあると、結局は1つのタイプスケールと多くの不具合が生じるだけです。

スケールには、フォント選択のための実際のフォントペアリングガイドと、スケールをコンテキストに位置付けるためのデザインシステムフレームワークを組み合わせましょう。スケールはタイポグラフィシステムの一部であり、フォント選択と役割マッピングは残りの部分です。動作するスケール、実際のトークン、そしてFigma + Tailwindを最初から正しく設定する必要がある場合は、Brainy を雇用するを使用してください。 BrandBrainyとUXBrainyを通じて、トークン、Figma変数、Tailwindの設定を統合した完全なタイプシステムを1つの配信として提供します。

スケールを維持するためのガバナンスルール

すべてのタイプスケールは、例外によって同じように消滅しました。

3つのルールは、どんなツールよりも長くスケールを維持します。

ルール1：すべての新しいコンポーネントは、サイズではなく役割を選択します。 カードを作成するデザイナーは、本文にBody、タイトルにH3、タイムスタンプにCaptionを選択します。インスペクターにfont-size: 18pxと入力することはありません。役割が存在しない場合は、システムを通じて新しい役割を提案し、一時的な上書きは行いません。

ルール2：例外には名前と日付を付けます。 マーケティングチームがキャンペーンページのヒーローに72pxの見出しが必要で、表示サイズが61pxの場合、例外には名前（hero-marketing-q3-launch）と日付が付けられます。キャンペーンがリリースされた後、例外は（再利用可能な場合は）スケールに組み込まれ、（単発的なものだった場合は）削除されます。匿名での上書きは禁止です。

ルール3：スケールは四半期ごとに見直す。年1回ではない。 四半期ごとの見直しは、変化が小さいうちに発見できるほど短い。年1回の見直しは、各チームが既存のシステム上の欠陥を回避して構築してしまい、元に戻すのに大掛かりなプロジェクトになってしまう。四半期ごとの見直しは15分で済む。年1回の見直しは再設計が必要になる。

​​フォントスケールを見失ったチームは、必ず同じような話をする。あるボタンに17pxのサイズが必要だったのに、別のバナーに21pxのサイズが必要だったのに、6ヶ月後にはコードベースに47種類ものフォントサイズが混在し、どれが本来のフォントサイズなのか誰も分からなくなってしまう。スケールは消え去り、残るのはフォントサイズの墓場だけだ。

これを防ぐには、スケールをスプレッドシートではなく、契約書のように扱うことが重要だ。契約はツール（Figma スタイル、Tailwind クラス、リンティング ルール）とレビューによって遵守されます。契約は四半期ごとのレビューで再交渉されます。契約外の事項はすべてバグとみなされます。

よくある質問

モジュラータイプスケールとは何ですか？

モジュラータイプスケールとは、製品内のすべてのフォントサイズを、単一のベースサイズに単一の比率を適用することで生成するシステムです。ベースサイズ（Web の場合は通常 16 ピクセル）と比率（通常 1.125 ～ 1.618）を選択し、ベースサイズに比率を繰り返し乗算または除算することで、各サイズを生成します。結果として、すべてのサイズが数学的に相互に関連付けられたスケールが作成され、任意のピクセル値では得られない、タイポグラフィにおける内部的な一貫性が実現されます。

タイプスケールにはどの比率を使用すればよいですか？

製品に必要な密度に合わせて比率を選択してください。ダッシュボードや管理ツールなど、データ量の多い製品では、見出しがデータから注意をそらさないように、1.125または1.2を使用してください。標準的なSaaSマーケティングページ、コンテンツサイト、製品ページ（ほとんどのB2B製品がこれに該当します）では、1.25または1.333を使用してください。見出しが見出しらしく見える必要がある編集記事、雑誌、ディスプレイ広告などの製品では、1.414または1.618を使用してください。最もよくある間違いは、製品に合っているかどうかではなく、印象的に聞こえるという理由だけで比率を選択することです。

フォントスケールにはいくつのサイズが必要ですか？

ほとんどの実用レベルのスケールは、7～9サイズです。キャプション、小、本文、リード、h4、h3、h2、h1、ディスプレイは、実際の製品のほぼすべての表面をカバーします。7サイズ未満では、デザイナーが個別のオーバーライドで埋める必要のある隙間が生じます。10サイズを超えるとスケールが細かすぎて、一部のサイズが使用されなくなり、システムの保守が難しくなります。 7～9が最適な範囲です。ロール名は、ピクセル値ではなく、各サイズの用途を説明するものであるべきです。

フォントスケールの値にはremとpxのどちらを使うべきですか？

Webではremを使用してください。ブラウザのルートフォントサイズはデフォルトで16ピクセルですが、ユーザーはアクセシビリティ設定やブラウザの設定で変更できます。remベースのスケールはこれらの設定を自動的に尊重します。ピクセルベースのスケールはこれらの設定を無視します。Tailwind、Material Design、そしてほとんどの最新のデザインシステムは、この理由からremを使用しています。モバイルプラットフォームでは、プラットフォームの仕様に従ってください。iOSはポイントを使用し、ダイナミックタイプをサポートしています。Androidはスケールに依存しないピクセル（sp）を使用します。原則は同じで、絶対単位ではなく、プラットフォームの相対単位を使用してください。

モジュラータイプスケールとデザイントークンの違いは何ですか？

モジュラータイプスケールは計算式であり、デザイントークンはその計算式をどのように表現するかを示します。スケールは値（10、13、16、20、25、31、39、49、61）を定義します。トークンは、デザインシステムの他の部分がこれらの値をハードコーディングすることなく参照できるようにする名前付きレイヤーです。トークンなしでスケールを作成することはできますが、スケールは実際のコードベースでは機能しません。スケールなしでトークンを作成することはできますが、値は任意になります。完全なシステムは、トークンとして表現されたスケール、生データ、セマンティックレイヤー、コンポーネントレイヤーで構成され、同じソースからFigmaとコードに渡されます。

多くのタイプスケールが見落としているパターン

タイプスケールはフォントサイズのリストではなく、製品内でテキストがどのように階層化されるかに関する契約です。

これを正しく理解しているチームは、比率を選んだだけで終わりではありません。彼らは比率を選定し、スケールを構築し、トークンとして配布し、FigmaとTailwindに組み込み、四半期ごとのレビューと厳格な例外禁止ルールによってそれを徹底します。スケールは成果物ではなく、規律こそが成果物なのです。成果物は、規律を可能にするためのものです。

この点を誤解しているチームは、スケールをムードボードのように扱います。Pinterestのモックアップで美しい比率を選び、静的な仕様書を配布しますが、6か月後にエンジニアリングチームがそれを採用しなかったことに気づきます。仕様書が実行可能なコードではなかったためです。あるいは、スケールをFigmaに配布してもTailwindには配布せず、デザインファイルと本番アプリが乖離し、最終的には異なるフォントの2つの異なる製品になってしまいます。あるいは、両方に配布しても統制を行わず、1年以内に例外がルールを上回ってしまうこともあります。

近道は、スケールを最初から契約として扱うことです。計算式が手順を定め、トークンがその手順を実行可能なものにします。 Figma変数とTailwindの設定により、設計とエンジニアリングの両サイドでステップが利用可能になります。ガバナンスは、リリース後もステップを有効に保ちます。システムの各要素はそれぞれ特定の役割を担っており、どれか一つでも欠けるとシステムは機能しなくなります。

機能的なモジュール型タイプスケール、実際のトークン、実際のFigma変数、実際のTailwind設定、そしてリリース後もスケールを維持するガバナンスプランが必要な場合は、Brainy を雇用するをご覧ください。BrandBrainyとUXBrainyを通じて完全なデザインシステムを提供しており、タイプスケールは最初からトークンとして設計され、タイポグラフィシステムはブランドカラーパレットに接続され、チームがリリースを開始した後もシステムを有効に保つルールが整備されています。