Noto Sans JPがPDFで細る原因と直し方｜源ノ角ゴシックへ逃がす
「Webでは普通だったのに、PDFにしたら日本語だけ急に細くなった」「Noto Sans JPで組んだのに、太字を指定した見出しまで全部かすれている」——資料をPDFに書き出した瞬間に文字が痩せる現象に、戸惑った経験がある方は多いはずです。
結論から言うと、原因はNoto Sans JPの可変フォント（バリアブルフォント）版が持つ、ある性質にあります。配布されている可変フォントは、太さの軸の既定値がThin（100）に設定されていて、フォント自身も「Noto Sans JP Thin」という名前を名乗っています。そのため、太さの指定がうまく伝わらない経路に入ると、標準のRegularではなくいちばん細いThinに着地します。直し方は、太さが確実に伝わる形でフォントを渡すこと。最も手堅いのは、同じ字形を持つ静的フォント「源ノ角ゴシック（Source Han Sans）」へ逃がすことです。
株式会社Fyveは、提案書や見積書といった書類をHTMLから自動でPDF生成する運用を日常的に行っており、この「激細り問題」に何度もぶつかってきました。この記事では、なぜ細るのかという仕組みから、私が現場で使っている具体的な逃がし方までを、非エンジニアの方にもわかるように解説します。
そもそも何が起きているのか — 「全部Thinになる」現象の正体
まず押さえたいのは、これはNoto Sans JPというフォントが壊れているわけではない、という点です。フォント側は太さの情報をきちんと持っています。問題は、その太さを描画する側（PDF変換やブラウザ）の処理にあります。
Noto Sans JP は「可変フォント」である
可変フォントとは、1つのフォントファイルの中に「細い〜太い」を連続的に変化させる軸（ウェイト軸）を持たせた形式です。Thin・Light・Regular・Medium・Bold・Blackといった太さを、1ファイルで表現できます。ファイルサイズを抑えられる便利な仕組みですが、この軸を正しく解釈できるかどうかは、描画する側の環境に依存します。
既定の姿が「Thin」だから、細い方へ落ちる
ここが混乱しやすいところです。可変フォントには、太さの軸が使われなかったときに表示される「既定の姿」が決められています。多くのフォントはこれがRegular（400）なので、軸が効かなくても標準の太さで出ます。
ところがGoogle Fontsが配布しているNoto Sans JPの可変フォントは、中身を調べるとこうなっています（2026年7月30日時点で確認）。
太さの軸（wght）: 最小 100 ／ 既定 100 ／ 最大 900
フォント名（PostScript名）: NotoSansJP-Thin
フォントファミリー名: Noto Sans JP, Noto Sans JP Thin既定値が100、つまりいちばん細いThinです。しかもフォント自身が「Noto Sans JP Thin」という名前を持っています。だからこのフォントは、軸が効かなかったときの着地点が標準の太さではなくThinになる。これが「全部Thinになってしまう」と言われる現象の正体です。
逆に言えば、太さの指定さえ正しく届いていれば、可変フォントのままでも問題は起きません。細るかどうかを分けているのは「PDFにしたかどうか」ではなく、「太さの情報が最後まで伝わったかどうか」です。
この現象は特定のツールに限りません。PowerPointからPDFへ書き出したときに全ウェイトがThinになる不具合や、Chromeの開発者ツールで確認するとすべてThin表示になる挙動、R Markdownでの細字化など、複数の環境で同じ症状が報告されています（google/fonts の Issue #6187 など）。つまり「自分の設定ミス」というより、このフォントの既定の姿がThinであることが根っこにある問題です。書き出す道具を変えても、太さの情報が途中で落ちれば同じ結果になります。
「細い」ではなく「太字だけ効かない」ときは、読み込みを疑う
細るのとは別に、本文は正常なのに太字だけが効かないケースがあります。この場合、原因はたいてい「そもそも太字のフォントを読み込んでいない」ことです。
Google Fontsのページから貼り付ける形のリンクについて、配信されるCSSの中身を実際に確認しました（2026年7月30日時点）。
リンクの書き方 | 実際に読み込まれる太さ |
|---|---|
| 400のみ |
| 400 と 700 |
| 100〜900（可変） |
太さを指定せずに貼ると、読み込まれるのは400だけです。この状態でfont-weight: 700を書いても実体のBoldが存在しないため、ブラウザが標準の字を機械的に太らせて表示します。いわゆる合成太字（フェイクボールド）です。
どのくらい違うのかを測りました。同じ文字を同じ大きさで描き、インクの量（黒い画素の数）を数えた結果です。
状態 | 太字のインク量 |
|---|---|
太さを指定せずに貼った場合（合成太字） | 28,222 |
| 32,038 |
合成太字は本物より約12%細いという結果でした。並べれば違いが分かりますが、単体で見ると気づきにくい差です。「なんとなく締まらない」の正体がこれであることは珍しくありません。
対処は、使う太さをリンクに書き足すだけです。
<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@400;700&display=swap" rel="stylesheet">Noto Sans JP と源ノ角ゴシックは「同じフォント」— だから逃がせる
ここで多くの人が混乱するのが、「源ノ角ゴシックに変えたら、デザインの雰囲気まで変わってしまうのでは？」という不安です。結論を言うと、その心配は不要です。
Noto Sans JP（Google名義）と源ノ角ゴシック＝Source Han Sans（Adobe名義）は、GoogleとAdobeが共同開発した、字形が同一のフォントです。名前と配布経路、ライセンス表記が違うだけで、見た目の骨格は同じもの。だからこそ、Noto Sans JPで組んだデザインを源ノ角ゴシックに差し替えても、レイアウトや印象を崩さずに細り問題だけを解消できます。
ポイントは「可変フォントの姿ではなく、ウェイトごとに分かれた静的な姿で使う」こと。源ノ角ゴシックはウェイト別の静的ファイルが配布されているため、可変軸に起因するThin落ちが構造的に起きません。同じ顔立ちのまま、太さだけ安定させられるのが、この逃がし方の要点です。
直し方 — 実務での逃がし方4パターン
ここからは具体的な対処です。環境や作り方によって最適な手が変わるので、上から順に「確実な順」で並べています。
① 静的な源ノ角ゴシック（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-faceで太さを範囲で宣言するのが要点です。
@font-face {
font-family: "NotoSansJP";
src: url("/fonts/NotoSansJP.ttf") format("truetype-variations");
font-weight: 100 900; /* 単一値ではなく範囲で書く */
}ここをfont-weight: 400;のように単一値で書くと、太さが400に固定され、太字は合成太字になります。書き方を5パターン試して比べたところ、崩れたのはこの単一値のケースだけでした。範囲で宣言してあれば、可変フォントのままでも太さは正しく出ます。
それでも静的フォントを先に勧めるのは、埋め込んだあとのファイルサイズが違うためです。同じ内容のA4を書き出したところ、可変フォントを埋め込むと548KB、静的な源ノ角ゴシックだと184KBでした。書類を大量に出す運用ほど、この差が効いてきます。
③ 使うウェイトだけに絞って軽量サブセット化する
可変フォントは全ウェイトを内包するぶんファイルが重くなりがちです。実際の資料で使うのは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・書類自動生成の全体像については、こちらの記事も参考になります。
AIとの対話だけで資料やLPを組み立てる仕組みづくりについては、こちらでも解説しています。
まとめ
Noto Sans JPがPDFや印刷で激細りするのは、可変フォント版の太さの軸の既定値がThin（100）で、フォント自身も「Noto Sans JP Thin」と名乗っているためです。太さの指定が届かない経路に入ると、標準のRegularではなくいちばん細い姿に着地します。フォントが壊れているのではなく、既定の姿がどこに置かれているかの問題だと理解すると、対処の道筋が見えてきます。
また、細るのとは別に「太字だけ効かない」現象もあります。こちらはGoogle Fontsのリンクに太さを書いておらず、400しか読み込めていないことが原因であることが多く、本物のBoldより約12%細い合成太字で表示されます。
一番確実なのは、字形が同じ静的フォント「源ノ角ゴシック（Source Han Sans）」へ逃がすこと。Macで生成するならヒラギノ角ゴを素直に使うのも有効です。見た目を変えずに太さだけ安定させられるので、資料の印象を保ったまま問題を解決できます。
私たちのように書類をHTMLから自動生成する運用では、フォントの選び方ひとつで成果物の見栄えが大きく変わります。同じ理屈は、AIに資料づくりを任せる場面でもそのまま効いてきます。細部の詰まりを一つずつ潰していくことが、そのまま自動化の品質につながっていきます。
その太字、本物ですか
日本語フォントで起きる4つの事故と、AIに検品させるやり方（全15ページ＋検品スキル）
同じ「細い」でも原因は4つあり、どれも目で見て気づける差ではありません。フォントの中身・配信されるCSS・書き方5パターンを実測して切り分けました。出したPDFをAIに検品させるスキルも同梱しています。
- リンクの貼り方ひとつで、太字が12%細くなる（実測値つき）
- 可変フォントの既定がThinだから、細い方へ落ちる仕組み
- 書き出す側の落とし穴3つと、AIへの頼み方
- 出力のたびに自動で止める検品スキル（そのまま入れて使えます）
受け取りページには、他にもこれだけ置いてあります
＋6PDF 10点・合計266ページ ＋ すぐ使えるzip素材 3点
どれも登録後の受け取りページから、まとめてダウンロードできます。
毎週金曜の無料ニュースレター「まるごとAI経営」の購読特典です。メール登録後すぐ、受け取りページのご案内が届きます。そこにはこの資料に加えて、過去の特典もすべてまとめて置いてあります。あわせて、AI活用に関するお知らせやお役に立てそうなご案内をお送りすることがあります。解除はいつでも1クリック。