なぜ Web フォントを捨てて System Font Stack にしたか — 業務アプリでの和文選定

TL;DR

niyase の本文・UI フォントを System Font Stack に決めました(2026-05-25)。

font-family:
  -apple-system, BlinkMacSystemFont, "Segoe UI Variable", "Segoe UI",
  "Hiragino Kaku Gothic ProN", "Hiragino Sans", "Yu Gothic UI", "Yu Gothic",
  YuGothic, Meiryo, "Noto Sans JP", sans-serif;

Mac ユーザーは Hiragino、Windows ユーザーは Yu Gothic、Linux ユーザーは Noto Sans JP — 各 OS の native font で読める。Web font は body 用には一切ロードしません。

理由を分解した記録です。

発端: 「IBM Plex Sans JP の漢字に違和感がある」

niyase はロゴ用に IBM Plex Sans (SIL OFL 1.1) を採用しています。

• IBM が企業 identity 用に設計、anti-Helvetica の思想
• 「キュッとしまった」字形が小文字 wordmark niyase にフィット
• 商用利用・ロゴ転用とも完全に自由

ロゴ用としては理想的でした。ところが、その流れで 本文・UI も IBM Plex Sans JP に揃えた段階で違和感が芽生えます。

業務文章としてある程度の長さを表示してみると、こうなりました:

Niyase はコード・設計・テスト・ドキュメントまで AI を主力に据えた開発体制を採用しています(最終判断・品質レビュー・セキュリティ確認は人間が握ります)。だから、会計・給与・勤怠・法務などのコア機能を網羅し、業種ごとの必要機能もプラグインで提供できる。

漢字を凝視すると、そこはかとなく中国語っぽい。「業」「給」「網」「能」「最」「験」あたりの字形が、日本のゴシック体の系譜とわずかに違う気がする。

調べると IBM Plex Sans JP は IBM Plex のグローバルシリーズの一環で、漢字は CJK 統一的なベースで設計されています。日本のゴシック体に特化していない。ロゴには完璧(英文だから)、長文の本文には違和感、というアンマッチでした。

やったこと: 10 候補を共通サンプルで比較

社内ブランドプレビューで、同じ段落を 10 種のフォントで描画して縦覧しました。

• IBM Plex Sans JP(現状)
• Noto Sans JP(世界標準)
• Zen Kaku Gothic New(現代的)
• Zen Kaku Gothic Antique(レトロ・温度感)
• BIZ UDPGothic(モリサワ UD)
• M PLUS 1p(幾何的)
• Kosugi Maru(丸ゴシック)
• Klee One(教科書体)
• Hiragino Kaku Gothic ProN(macOS native)
• Yu Gothic UI(Windows native)

結果、Mac で見るとどうしても Hiragino が最も読みやすい。30 年近く Mac を使ってきた身体反応もありますが、それ以上に「字形そのものが安定して綺麗」。

ところが Hiragino は Web フォントとして配信できない

ライセンス上の理由で、Hiragino は Apple OS にバンドルされた system font であり、Web 配信は不可。Web font として全プラットフォームに届けるオプションは存在しません。

ここで判断分岐がやってきます:

正直 A と B も悪くなかった。「全員に同じ見え方を強制する Web font 統一」は、デザイン中心の media では正解の一つです。

でも、迷っているうちに niyase のミッションが頭を過りました。

判断軸: 「自分の美的感覚を共有する目的ではない」

niyase は業務アプリです。コーポレートサイトもアプリも、「ユーザーが業務をこなすための道具」 として作っています。デザインがメインの media ではない。

そう考えると、デザイナーやエンジニアが「全プラットフォームで同じ見え方にする」という美意識を、ユーザーに強制する理由がない。

• Mac ユーザー → Hiragino で読みやすい(慣れ親しんだ frame)
• Windows ユーザー → Yu Gothic UI で読みやすい(同上)
• Linux ユーザー → Noto Sans JP で読める(fallback)

各ユーザーが「自分の OS で最も読みやすい・見慣れたフォント」で niyase を使える。ユーザーの利便性を最大化 する選択は、System Font Stack です。

これは決して妥協ではなく、 ユーザーの居場所を尊重する選択 だと整理できました。

実装

packages/ui/src/globals.css で body の font-family を System Font Stack に。各 app の tailwind.config.ts の fontFamily.sans も同じスタックに揃えます。

body {
  font-family:
    /* 英文 */
    -apple-system,
    BlinkMacSystemFont,
    "Segoe UI Variable",
    "Segoe UI",
    /* 和文(macOS / iOS) */ "Hiragino Kaku Gothic ProN",
    "Hiragino Sans",
    /* 和文(Windows) */ "Yu Gothic UI",
    "Yu Gothic",
    YuGothic,
    Meiryo,
    /* 和文(Linux / Android fallback) */ "Noto Sans JP",
    sans-serif;
  line-height: 1.7; /* 和文長文の読みやすさ */
}

ロゴ wordmark は依然として IBM Plex Sans Bold 700 をロードして、SVG が font-family: 'IBM Plex Sans' で参照します。英文 wordmark なので漢字問題は発生しません。

コード(<code> / <pre>)は IBM Plex Mono を継続採用。これも英文しか含まないので問題なし。

副次的に得たもの

System Font Stack を採用すると、想像していなかった副次効果がいくつかありました。

1. ファイルサイズ ゼロ

Web font のロードが消える分、 本文用に 200-500KB が削減。初回表示の遅延も減ります。

2. FOIT / FOUT が発生しない

Web font が読み込まれるまで「白く見える」「フォントが化ける」が完全になくなる。アクセス直後から確定したフォントが見える。

3. ライセンス確認の負荷ゼロ

Web font の OFL 1.1 確認、attribution 表記、PDF 埋め込みの可否などの判断が、本文側からは消えます(ロゴ側だけに残る)。

4. ユーザーの OS アップデートに自動追従

Apple が Hiragino を進化させたら、niyase の本文もそれに追従して進化する。自分でメンテしなくても、最新の native font で読める。

5. 業界ベストプラクティスへの合流

GitHub / Apple / Slack / Notion / Vercel / Tailwind 公式 — みんな同じ。最も洗練された B2B B2C 各社の選択 がそこにありました。

結論

「自分の美的感覚を全ユーザーに共有する」のではなく、「各ユーザーの環境に niyase を寄せていく」 という設計判断。

これは niyase のミッションである 「諦めていたアイディアを、今こそ形に」 と地続きの考え方でした。

ユーザーの "今" を否定して未来を見せるのではなく、ユーザーの今のままで niyase を使える状態を作る。フォント選定すらも、その思想の表現になっていました。

おまけ: Plan B

将来、ユーザーから「フォントが好みに合わない」という声が頻発したら、再検討の第 1 候補は Zen Kaku Gothic New(Google Fonts / SIL OFL 1.1)。

• 古川敦氏制作
• Web font として配信可
• 現代的・程よい humanism
• Hiragino に近い humanist 系譜

System Font Stack を続けるか、Zen Kaku Gothic New に切り替えるか、その判断はユーザーの声を聞きながらやります。

タイポグラフィの設計判断、面白かったので記録に残しました。同様に和文フォントで悩んでいる方の判断材料になれば。