Noto Sans JPがPDFで細る原因と直し方｜源ノ角ゴシックへ逃がす

「Webでは普通だったのに、PDFにしたら日本語だけ急に細くなった」「Noto Sans JPで組んだのに、太字を指定した見出しまで全部かすれている」——資料をPDFに書き出した瞬間に文字が痩せる現象に、戸惑った経験がある方は多いはずです。

結論から言うと、これはNoto Sans JPが「可変フォント（バリアブルフォント）」であることが原因です。PDF化やヘッドレスChromeでの描画では、ウェイト（太さ）の指定が無視され、最も細いThin（100）で出力されてしまいます。直し方はシンプルで、同じ字形を持つ静的フォント「源ノ角ゴシック（Source Han Sans）」へ逃がすことです。

株式会社Fyveは、提案書や見積書といった書類をHTMLから自動でPDF生成する運用を日常的に行っており、この「激細り問題」に何度もぶつかってきました。この記事では、なぜ細るのかという仕組みから、私が現場で使っている具体的な逃がし方までを、非エンジニアの方にもわかるように解説します。

そもそも何が起きているのか — 「全部Thinになる」現象の正体

まず押さえたいのは、これはNoto Sans JPというフォントが壊れているわけではない、という点です。フォント側は太さの情報をきちんと持っています。問題は、その太さを描画する側（PDF変換やブラウザ）の処理にあります。

Noto Sans JP は「可変フォント」である

可変フォントとは、1つのフォントファイルの中に「細い〜太い」を連続的に変化させる軸（ウェイト軸）を持たせた形式です。Thin・Light・Regular・Medium・Bold・Blackといった太さを、1ファイルで表現できます。ファイルサイズを抑えられる便利な仕組みですが、この軸を正しく解釈できるかどうかは、描画する側の環境に依存します。

PDF化・ヘッドレス描画で最も細いウェイトに落ちる

問題が起きるのは、この可変フォントのウェイト軸を描画エンジンが処理しきれないときです。font-weight: 700（太字）を指定していても、軸が無視され、フォントが持つ最も細い姿＝Thin（100）で描かれてしまいます。結果として、画面上は太かった文字が、PDFでは一律に痩せて見えるわけです。

太字を指定してもPDF化・ヘッドレスChromeで最も細いThinに落ちる仕組みの図解

この現象は特定のツールに限りません。PowerPointからPDFへ書き出したときに全ウェイトがThinになる不具合や、Chromeの開発者ツールで確認するとすべてThin表示になる挙動、R Markdownでの細字化など、複数の環境で同じ症状が報告されています（google/fonts の Issue #6187 など）。つまり「自分の設定ミス」ではなく、可変フォントと描画エンジンの相性が根っこにある、構造的な問題なのです。

Noto Sans JP と源ノ角ゴシックは「同じフォント」— だから逃がせる

ここで多くの人が混乱するのが、「源ノ角ゴシックに変えたら、デザインの雰囲気まで変わってしまうのでは？」という不安です。結論を言うと、その心配は不要です。

Noto Sans JP（Google名義）と源ノ角ゴシック＝Source Han Sans（Adobe名義）は、GoogleとAdobeが共同開発した、字形が同一のフォントです。名前と配布経路、ライセンス表記が違うだけで、見た目の骨格は同じもの。だからこそ、Noto Sans JPで組んだデザインを源ノ角ゴシックに差し替えても、レイアウトや印象を崩さずに細り問題だけを解消できます。

ポイントは「可変フォントの姿ではなく、ウェイトごとに分かれた静的な姿で使う」こと。源ノ角ゴシックはウェイト別の静的ファイルが配布されているため、可変軸に起因するThin落ちが構造的に起きません。同じ顔立ちのまま、太さだけ安定させられるのが、この逃がし方の要点です。

直し方 — 実務での逃がし方4パターン

ここからは具体的な対処です。環境や作り方によって最適な手が変わるので、上から順に「確実な順」で並べています。

Noto Sans JPの激細りを直す4つの方法（静的な源ノ角ゴシック・font-weight明示・軽量サブセット・ヒラギノ）の比較図解

① 静的な源ノ角ゴシック（Source Han Sans）を埋め込む

最も確実なのがこれです。ウェイトごとに分かれた静的なOTF/TTFファイルを用意し、@font-faceで読み込みます。可変軸そのものが無いので、Thinに落ちようがありません。

@font-face {
  font-family: "SourceHanSans";
  src: url("/fonts/SourceHanSansJP-Regular.otf") format("opentype");
  font-weight: 400;
}
@font-face {
  font-family: "SourceHanSans";
  src: url("/fonts/SourceHanSansJP-Bold.otf") format("opentype");
  font-weight: 700;
}
body { font-family: "SourceHanSans", sans-serif; }

使うウェイトだけを個別に登録するのがコツです。RegularとBoldの2種類を明示的に紐づけておけば、太字指定もきちんと反映されます。

② font-weight を明示し、font-variation-settings を効かせる

どうしても可変フォントのまま使いたい場合の手です。font-weightを曖昧にせず数値で明示したうえで、font-variation-settings: "wght" 700;のようにウェイト軸を直接指定します。軸を明示的に触ると、描画が正しく切り替わることがあります。

ただしこれは環境依存の回避策で、①ほど確実ではありません。「静的フォントを置けない事情がある場合の次善策」と考えてください。

③ 使うウェイトだけに絞って軽量サブセット化する

可変フォントは全ウェイトを内包するぶんファイルが重くなりがちです。実際の資料で使うのはRegularとBoldの2ウェイト程度、というケースがほとんど。ならば必要なウェイトだけを切り出して静的に埋め込めば、ウェイト崩れの防止とファイル軽量化を同時に達成できます。PDFの生成速度も上がるので、書類を大量に自動生成する運用では効果が大きい手です。

④ 環境にヒラギノ角ゴがあるなら素直にそれを使う

Mac上でPDFを生成するなら、標準搭載のHiragino Kaku Gothic ProNを第一候補にするのが手っ取り早い解決策です。ヒラギノは静的フォントなので細り事故が起きず、日本語の見え方も安定しています。私も、Macで動かす書類生成ではfont-familyの先頭にヒラギノ角ゴを置き、フォールバックとして源ノ角ゴシックを並べる構成を基本にしています。

HTMLからPDFを自動生成する現場での回避法

私たちがこの問題に頻繁にぶつかるのは、提案書や見積書、帳票といった書類を、HTMLで組んでからヘッドレスChrome（Puppeteer）でPDF化しているためです。画面のプレビューでは太字がきれいに出ているのに、生成したPDFを開くと日本語だけ痩せている——という食い違いが典型的なパターンでした。

私が現場で定着させた対処は、次の3点です。

Webフォント（可変版）に頼らず、静的フォントを実体で持つ：源ノ角ゴシックの静的OTF、またはヒラギノ角ゴをローカルに置き、@font-faceかシステムフォント指定で確実に読ませる
font-weight は必ず数値で明示する：boldのような曖昧指定ではなく400 / 700と書き、対応する静的ファイルを紐づける
見出しはMedium以上、本文はRegularを基準にする：日本語はアンチエイリアスで細く見えやすいので、意図より一段太めに寄せると印刷でちょうど良くなる

もう一つの落とし穴は、過去に決めたサイト全体のCSS（古いフォント指定）が、後から追加した個別指定に勝ってしまうことです。エラーは出ないまま静かに上書きされるので気づきにくい。フォントが思った太さで出ないときは、新しい指定だけでなく「全体に効いている古い決まり」まで遡って確認するのが、遠回りに見えて一番の近道でした。

HTMLからのPDF・書類自動生成の全体像については、こちらの記事も参考になります。