font-family は軽く見られがちですが、実務ではレイアウト崩れと可読性と表示速度を左右する結構な重要パーツです。しかも日本語は、端末やOSで標準フォントの事情が違うので、雑に1つだけ指定すると地味に事故ります。
先に結論 コピペで使えるおすすめfont-family 3パターン
忙しい人向けに、まずは完成形です。迷ったらこのまま使ってOKです。
パターン1 まずは軽く速く システムフォント優先（Webフォントなし）
LPやコーポレート、運用が長いサイトで強いです。Webフォントを読み込まないので表示が速く、CLS（ガタつき）も抑えやすいです。
body {
font-family:
system-ui,
-apple-system,
"Hiragino Sans",
"Hiragino Kaku Gothic ProN",
"Yu Gothic",
"Meiryo",
sans-serif;
}パターン2 見た目をそろえる Webフォント優先（Noto Sans JP想定）
デザインの再現性を取りたい場合はこちら。Webフォントが読み込めない時でも、近い見た目に落ちる順番にしています。
body {
font-family:
"Noto Sans JP",
system-ui,
-apple-system,
"Hiragino Sans",
"Hiragino Kaku Gothic ProN",
"Yu Gothic",
"Meiryo",
sans-serif;
}パターン3 游ゴシック系を優先したい（既存資産を活かす）
游ゴシック前提のデザインや、既存サイトの印象を変えたくない場合の現実解です。既存記事の方向性を残しつつ、整理して読みやすくしています。
body {
font-family:
"Yu Gothic",
"Yu Gothic Medium",
"YuGothic",
"Hiragino Sans",
"Hiragino Kaku Gothic ProN",
"Meiryo",
sans-serif;
}ここまでで半分は終わりです。以降は「なぜこうなるのか」「どこで事故るのか」を短く、でも実務で困らない深さで解説します。
なぜ複数フォントを指定するのか 1つ指定はだいたい罠
結論から言うと、ユーザーの環境がバラバラだからです。Windows、macOS、iOS、Androidで、標準で入っている日本語フォントが違います。指定したフォントが無ければ、ブラウザは勝手に代替フォントを選びますが、その順番を放置すると次の問題が出ます。
- 字形や字幅が変わって、行送りや改行位置がズレる
- 太字の出方が違って、見出しだけ弱く見える
- 一部の記号や英数字が別フォントに切り替わって統一感が崩れる
- 最悪、意図しない明朝系に落ちて雰囲気が変わる
つまり font-family は「保険の列」です。上から順に候補を並べて、無いなら次、無いなら次、最後は generic（sans-serifなど）で受け止める。これが基本です。
フォールバックの基本ルール 迷ったらこの4つだけ守る
ルール1 必ず最後は sans-serif か serif で締める
最後の受け皿がないと、環境によって変な落ち方をします。締めの generic は必須です。
ルール2 日本語と欧文を分けたいなら 先頭に日本語対応フォントを置く
日本語サイトで最初に欧文フォントを置くと、日本語が別フォントに落ちて混ざり方が汚くなることがあります。日本語対応フォント、あるいは system-ui を先に置くのが無難です。
ルール3 ブレークポイントごとに font-family を変えない
SPだけ別指定にすると、同じ文章なのに改行位置が変わって、意図しない余白が出ます。レスポンシブの崩れの犯人になりがちです。
ルール4 まずは短く 目的が増えたら伸ばす
長いリストは正義ではありません。管理がしんどい上に、実務では「誰がこの順番を決めたのか」問題が起きます。まずは短く組んで、困ったら足す方が運用が楽です。
離脱が増えやすい原因と 改善の考え方
ページビューが多いのに離脱率が高い記事は、だいたい次のどれかが原因です。
- 結論が遅い（欲しいのはコピペなのに、前置きが長い）
- 自分のケースに当てはめる手順が見えない（判断軸がない）
- 例はあるが、どれを選べばいいか分からない（比較がない）
- 用語の説明が後回しで、途中で読むのをやめる
なのでこのリライトでは、冒頭にパターン別の完成形を置き、次に判断フロー、最後に根拠と実装の細部を置きました。読む順番で迷わない構成にしてあります。
どれを選ぶ 判断フロー 30秒で決める
Webフォントを入れるかどうか
- ブランドやデザイン再現性が最優先 -> Webフォントあり（パターン2）
- 速度と安定性が最優先 -> システム優先（パターン1）
- 既存が游ゴシック前提 -> 游ゴシック寄せ（パターン3）
ウェイト（太さ）を何種類使うか
- 本文はRegular、見出しはBold程度 -> 2ウェイトで十分
- 細かい太さ調整が必要 -> 可変フォント（後述）を検討
Webフォントを使う場合の実装 最短で失敗しない形
Google Fontsを使う前提で書きます。自前配信でも考え方は同じです。
読み込み例 Noto Sans JP（必要なウェイトだけ）
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link
rel="stylesheet"
href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@400;700&display=swap">display=swap を付ける理由は単純です。フォント読み込み中に文字が消える状態を避けるためです。まずシステムフォントで表示し、後からWebフォントに切り替えます。
CSS側 font-family は Webフォント -> システム -> 汎用 の順
body {
font-family:
"Noto Sans JP",
system-ui,
-apple-system,
"Hiragino Sans",
"Hiragino Kaku Gothic ProN",
"Yu Gothic",
"Meiryo",
sans-serif;
}メリット
- どの端末でも見た目がそろいやすい
- デザインカンプと差が出にくい
- 見出しや数字の印象もコントロールしやすい
デメリット
- 日本語フォントは容量が大きく、表示が重くなることがある
- フォント切替で微小なレイアウト変化が出る場合がある
- 必要以上にウェイトを増やすと通信が太る
可変フォント（Variable Font）を活用する 何が嬉しいのか
可変フォントは、ざっくり言うと「1ファイルに複数の太さが入っている」タイプです。従来のように Regular用のファイル、Bold用のファイルを別で持つ必要が減ります。
やり方 自前配信の例（概念をつかむ）
@font-face {
font-family: "NotoSansJPVar";
src: url("/fonts/NotoSansJP-Variable.woff2") format("woff2-variations");
font-display: swap;
}
body {
font-family:
"NotoSansJPVar",
system-ui,
-apple-system,
"Hiragino Sans",
"Yu Gothic",
"Meiryo",
sans-serif;
}これでCSS側は同じfont-familyのまま、font-weight で太さを変えられます。複数ウェイトを使いたいサイトほど恩恵があります。
メリット
- 太さ違いのファイル管理が減る
- UI全体のタイポグラフィ調整がやりやすい
- 設計がきれいになりやすい
デメリット
- フォントの用意や検証が少しだけ手間
- 全部の案件で必要とは限らない（2ウェイトで足りるなら不要）
パフォーマンス最適化 離脱を減らすならここが本丸
フォントの記事で離脱が増える一番の理由は、読む前にページが重いことです。フォントは画像と同じで、読み込みが遅いと体験が落ちます。ここは実務の手当が効きます。
1 font-display を正しく使う
@font-face {
font-family: "Noto Sans JP";
src: url("/fonts/NotoSansJP-Regular.woff2") format("woff2");
font-display: swap;
}swap は、まず表示を優先して後から差し替える方式です。読者が本文を読める状態を先に作れるので、離脱対策としても相性が良いです。
2 使うウェイトだけに絞る
本文に400、見出しに700。まずはこれで十分なケースが多いです。500や600を追加するのは、実際に必要になってからでOKです。
3 自前配信なら preload を検討する
<link
rel="preload"
href="/fonts/NotoSansJP-Regular.woff2"
as="font"
type="font/woff2"
crossorigin>最初に表示したいフォントを優先的に取りに行くための手段です。やり過ぎると逆に他のリソースを邪魔することがあるので、本文フォントなど本当に重要なものだけに絞ります。
よくある事故と対処法 ここだけ見ればだいたい直る
事故1 太字が弱い もしくは見出しだけ雰囲気が違う
原因は、指定したフォントにそのウェイトがない、またはOS側の合成太字になっている可能性です。対策は次のどちらかです。
- Webフォントを使うなら、必要なウェイトを確実に読み込む
- システムフォント中心なら、font-weightの設計を控えめにする
事故2 英数字だけ別のフォントに見える
日本語フォントが英数字を持っていない、または形が合わない場合に起きます。基本は、font-familyの先頭側に統一したいフォントを置き、システム側は後ろに回します。
事故3 レイアウトがガタつく（CLSっぽい）
Webフォント読み込み後に字幅が変わると起きます。対策としては、
- font-display: swap でまず表示を優先
- フォールバックに近い字幅のフォントを並べる
- どうしても厳しい場合はシステムフォント優先に戻す
実務で使える小技 日本語サイトの読みやすさを底上げする
line-heightは先に決める フォントより先に効く
日本語は行間が詰まると一気に読みにくくなります。まずは本文 line-height 1.7 から試すと安定します。
body {
line-height: 1.7;
}文字詰めをするなら palt だけに頼らない
詰めは便利ですが、サイト全体に雑に当てると見出しや数字の見え方が変わって違和感が出ることがあります。適用範囲はコンポーネント単位にしておくと安全です。
まとめ 迷ったら短く始めて 足りない所だけ足す
font-family で一番避けたいのは、何となくコピペした長いリストを誰も触れない状態で放置することです。運用が長いほど、そこが静かに負債になります。
この記事のおすすめはシンプルです。
- 速度と安定が大事なら システムフォント優先
- 見た目をそろえるなら Noto Sans JP などWebフォント優先
- 既存資産を活かすなら 游ゴシック寄せで現実的に
最初は短い1行で組んで、困った現象が出たら、その現象に対するフォールバックを1つだけ追加する。これが一番事故が少ない運用です。
読者向けに さらに役立つチェック項目
チェック1 実機で確認する最低ライン
- Windows + Chrome
- macOS + Safari
- iPhone（iOS Safari）
- Android（Chrome）
チェック2 フォントを増やす前に見る指標
- LCP（文字が出るまでの体感）
- CLS（読み込み後のガタつき）
- 実機のスクロールの軽さ
チェック3 コピペしたら終わりにしない
フォントはUIの土台です。土台が不安定だと、どれだけレイアウトを整えても最後に違和感が残ります。逆にここが整うと、デザイン全体が一段締まります。