typeset

汎用的、不統一、または構成が不十分に感じられるタイポグラフィを評価して改善し、初期設定そのままに見えるテキストを、意図を持って丁寧に仕上げられた文字表現に変えます。

必須の準備

frontend-designを読み、そのコンテキスト収集プロトコルに従ってください。利用可能なコンテキストを再利用し、成果に大きく影響する不足事項についてのみ質問してください。

---

現在のタイポグラフィを評価する

現在のタイポグラフィの何が弱く、または汎用的に見えるのかを分析してください。

1. フォントの選択：

   • 存在感のない初期設定のフォントを使っていませんか？（Inter、Roboto、Arial、Open Sans、システムの初期設定）
   • フォントはブランドの個性に合っていますか？（遊び心のあるブランドに企業向け書体を使うべきではありません）
   • フォントファミリーを使いすぎていませんか？（2～3種類を超えると、ほとんどの場合まとまりがなくなります）

2. 階層：

   • 見出し、本文、キャプションをひと目で見分けられますか？
   • フォントサイズが近すぎませんか？（14px、15px、16pxでは階層が曖昧になります）
   • ウェイトのコントラストは十分ですか？（MediumとRegularの違いはほとんど見えません）

3. サイズとスケール：

   • 一貫した文字スケールがありますか。それとも、サイズが場当たり的になっていますか？
   • 本文は最低限の読みやすさを満たしていますか？（16px以上）
   • サイズ設定の方針は用途に適していますか？（アプリのUIには固定のremスケール、マーケティングやコンテンツページの見出しには流動的なclamp()）

4. 読みやすさ：

   • 行の長さは快適ですか？（理想は45～75文字です）
   • 行の高さはフォントと用途に適していますか？
   • テキストと背景のコントラストは十分ですか？
   • イタリック、下線、大文字表記は、装飾としてではなく意図を持って使われていますか？

5. 一貫性：

   • 同じ要素は、全体を通して同じスタイルになっていますか？
   • フォントウェイトは一貫して使われていますか？（同じ役割の要素が、あるセクションでは太字、別のセクションではセミボールドになっていませんか？）
   • 字間は意図的に設定されていますか。それとも、どこでも初期設定のままですか？
   • 役割ごとの大文字・小文字の使い方は一貫していますか？（タイトル、ボタン、ラベル、トースト、メタデータ）

重要：目標はテキストを「華やか」にすることではありません。より明確で読みやすく、意図が伝わるようにすることです。優れたタイポグラフィは意識されず、悪いタイポグラフィは注意をそらします。

タイポグラフィの改善を計画する

フォントスケール、組み合わせ、読み込み方法、フォント選択のヒューリスティックに関する詳しいガイダンスは、frontend-design スキルのタイポグラフィのリファレンスを参照してください。 行の長さ、行の高さ、配置、ベースライン、ラベルと値の扱い、意味上の階層と視覚上の階層、リンクの強調、数値の配置については、テキストの階層と読みやすさを参照してください。 タイポグラフィの問題に見えて、実際には階層の問題である場合は、階層チェックリストを参照してください。 ReactまたはTailwindプロジェクトでWebフォントを変更する場合、新しいフォントファイルを追加する前に、タイポグラフィのリファレンスにあるフレームワークでのフォント読み込み、フォールバックフォントのメトリクス、OpenTypeユーティリティ、可変フォントの軸、フォントのペイロード予算に関するセクションを確認してください。

共有のテキスト階層・読みやすさリファレンスを、読みやすさとテキスト構造に関する共通の基準とし、そのうえで、ここに示すタイポグラフィ固有の変更を適用してください。

体系的な計画を立ててください。

• フォントの選択：フォントを変更する必要がありますか？ ブランドや用途に合うのはどのフォントですか？
• 文字スケール：制約のあるUIスケールを設定します。モジュラースケールを参考にしつつ、実際に必要な段階を個別に設計してください
• ウェイトの方針：どのウェイトをどの役割に使いますか？（本文にはRegular、ラベルにはSemibold、見出しにはBold、または用途に合う組み合わせ）
• 間隔：行の高さ、字間、タイポグラフィ要素間のマージン
• スキーマ：今後の画面でも一貫性を保てるよう、タイポグラフィの役割が十分明確に文書化されていますか？
• 読み込みとパフォーマンス：フォントはサブセット化され、利用可能な場合はフレームワークによってプリロードされ、レイアウトシフトを防ぐ設定になっていますか？
• OpenTypeと数字：データ量の多いコンポーネントで、tabular-nums、ライニング数字、コードの合字の無効化、その他のフォント機能が必要ですか？

タイポグラフィを体系的に改善する

フォントの選定

フォントを変更する必要がある場合：

• ブランドの個性を反映するフォントを選びます
• 明確なコントラストを組み合わせます（セリフ体＋サンセリフ体、幾何学的＋ヒューマニストなど）。または、同じファミリーの複数のウェイトを使います
• ウェイトの種類が豊富なファミリーを優先します。ウェイトの種類が多いファミリーほど、丁寧に設計されている傾向があります
• UI テキストの読みやすさを優先します。本文には、x ハイトが低いコンデンス体のディスプレイフォントを避けます
• Web フォントの読み込みによってレイアウトシフトが発生しないようにします（font-display: swap、メトリクスを合わせたフォールバック）

階層を確立する

明確な文字サイズのスケールを作ります：

• ほとんどの場合、5〜7 種類のサイズで十分です：キャプション、セカンダリ、本文、小見出し、見出し、ディスプレイ、必要に応じてアイブロウ
• 比率を使って検討し、実際の値はインターフェースにしっくりくるものに決めます
• 複数の要素を組み合わせます：サイズ＋ウェイト＋色＋余白で明確な階層を作ります。サイズだけに頼らないでください
• 階層がひと目でわかるよう、十分に大きなウェイト差を付けます。ミディアムとレギュラーの違いだけでは、控えめすぎることがよくあります
• アプリの UI：固定の rem ベースの文字サイズスケールを使用し、必要に応じて 1〜2 つのブレークポイントで調整します。可変サイズは、密度の高いコンテナベースのレイアウトに必要な空間の予測しやすさを損ないます
• マーケティング／コンテンツページ：見出しやディスプレイテキストには clamp(min, preferred, max) を使った可変サイズを使用します。本文のサイズは固定します

読みやすさを改善する

• テキストコンテナには ch 単位で max-width を設定します（max-width: 65ch）
• ほとんどの段落は 1 行あたり 45〜75 文字に収めます
• 用途に応じて行の高さを調整します。見出しは詰め気味に（1.1〜1.2）、本文はゆったりと（1.5〜1.7）します
• 1 行が長くなるほど行の高さを大きくし、フォントサイズが大きくなるほど小さくします
• 暗い背景に明るい文字を使う場合は、行の高さを少し大きくします
• 本文の文字サイズは少なくとも 16px／1rem にします

細部を整える

• データテーブルや、桁を揃える必要がある数値には tabular-nums を使用します
• 比較が重要な場合は、数値の列を右揃えにします
• 同じ行にサイズの異なるテキストを並べる場合は、ベースラインを揃えます
• 適切な letter-spacing を設定します。スモールキャップや大文字では少し広めにし、大きなディスプレイテキストでは標準または少し狭めにします
• 書体が大きなサイズで自然に間延びして見える場合は、見出しの字間を適宜詰めます
• イタリックは控えめに使います。短い強調、引用、推薦文には適していますが、長い UI コピーやコントロールには適しません
• リンクや短い重要箇所には意図的に下線を引きます。情報量の多いテキスト全体に一律で下線を引かないでください
• 役割ごとに大文字・小文字の使い方を統一し、すべて大文字のラベルやメタデータには字間を追加します
• すべてのリンクを既定で明るい青色にしないでください。読書の流れにおける重要度に合わせて、リンクの強調度を調整します
• 値の名前（--font-16）ではなく、意味を表すトークン名（--text-body、--text-heading）を使います
• font-kerning: normal を設定し、必要に応じて OpenType 機能の使用を検討します

ウェイトの一貫性

• 各ウェイトの役割を明確に定義し、それに従います
• 使用するウェイトは 3〜4 種類までにします（レギュラー、ミディアム、セミボールド、ボールドで十分です）
• ほとんど違いのないウェイトを増やすより、役割ごとに大きな差を付けます
• 実際に使用するウェイトのみを読み込みます（ウェイトを追加するたびにページの読み込み量が増えます）

スケールの整合性

• スケールの基準値には rem または px を使い、実装ではユーザー設定を尊重できる rem を優先します
• 入れ子になった UI では em ベースの文字サイズスケールを避けます。子孫要素のサイズがすぐにシステムからずれてしまいます
• スケールを機能させるのに小数サイズが大量に必要なら、そのスケールは数学的すぎて実用性に欠ける可能性があります

絶対にしないこと：

• フォントファミリーを 2～3 種類以上使う
• サイズを適当に選ぶ。スケールを決めて統一する
• 本文を 16px 未満にする
• 本文に装飾用／ディスプレイ用フォントを使う
• ブラウザーのズームを無効にする（user-scalable=no）
• 入れ子になった UI で文字サイズスケールを定義するのに em を使う
• 階層を作るためだけに極小のフォントサイズを使う。まずウェイトや色を使う
• 長文を中央揃えにする
• 完璧な数学的比率のほうが、手作業で調整したスケールより優れていると決めつける
• 実装でフォントサイズに px を使う。ユーザー設定を尊重するため rem を使う
• 個性が重要な場面で、安易に Inter／Roboto／Open Sans を使う
• 似ているが同一ではないフォント同士（幾何学的なサンセリフ体同士など）を組み合わせる

タイポグラフィの改善を確認する

• 階層：見出し、本文、キャプションをすぐに見分けられますか？
• 読みやすさ：長い文章でも本文を快適に読めますか？
• 一貫性：同じ役割の要素に、全体を通して同じスタイルが適用されていますか？
• 個性：タイポグラフィにブランドらしさが反映されていますか？
• パフォーマンス：Web フォントはレイアウトシフトを起こさず効率よく読み込まれていますか？
• アクセシビリティ：テキストは WCAG のコントラスト比を満たしていますか？ 200％まで拡大できますか？

覚えておいてください。タイポグラフィはインターフェースデザインの土台であり、情報の大部分を担います。タイポグラフィを適切に整えることは、最も効果の高い改善です。