クライアント環境でフォントが表示されない問題の原因と解決策｜現場で使える実践テクニック

こんにちは！
今日は「クライアント環境でフォントが表示されない問題」について解説します。

これ、ほんまによくある悩みなんですよ。
僕も昔、クライアント企業に納品したサイトが「フォントがおかしい」って連絡をもらった経験があります。
ローカルではきれいに表示されてるのに…って感じで、原因特定に丸一日かかりました。

クライアント環境でのフォントトラブルってなぜ起きる？

フォント表示の問題は、環境依存トラブルの中でもめっちゃ厄介です。
理由は、フォントの存在確認が複雑だからですね。

ローカルでは動く理由はシンプルです。
あなたのPC、あるいは制作チームのPC環境には、ほぼ確実に一般的なフォントがインストールされています。
だから font-family: "Helvetica", "Arial", sans-serif; みたいな指定でも、問題なく表示される。

ところがクライアント企業のPC環境だと、どうなってるかわかりません。
古いWindowsマシンかもしれませんし、企業のセキュリティポリシーでフォントがロックされてるかもしれない。
あるいは、Webフォントを使ってる場合、そのサーバーへのアクセスが遮断されてる可能性だってあります。

現場でよく見るのは「ローカルではGoogle Fontsが読み込まれてたけど、クライアント側のファイアウォールでブロックされてた」っていうケースですね。
地味に多いんですよ。

Webフォントが読み込まれていない場合の対処法

Webフォントが表示されないときの調査方法をお伝えします。

まず大事なのは、ブラウザの開発者ツールで確認することです。
Networkタブを開いて、フォントファイルが実際に読み込まれているか見てください。
404エラーが出てたら、ファイルパスが間違ってるか、サーバーに存在してません。
読み込み中のまま止まってたら、ネットワーク接続に問題がある可能性が高いです。

僕がよくやるのは、フォント定義の確認です。

例えばGoogle Fontsを使ってる場合、ヘッダーに <link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP&display=swap" rel="stylesheet"> みたいに記述されてますよね。
このURLが本当に正しいか、実際にアクセスして確認するんです。
ブラウザのアドレスバーに直接貼って、CSSが返ってくるか見る。
これで「あ、このドメインはクライアント企業でアクセス禁止なのか」って気づけるんですよ。

対策としては、3つ方法があります。

• フォントファイルを自分のサーバーにダウンロードして置く
• クライアント企業のIT部門に、該当ドメインのホワイトリスト登録をお願いする
• はじめからシステムフォントだけで構成されたデザインにする

個人的には、1番目の「自分のサーバーに置く」が安定してます。
外部依存がなくなるので、クライアント環境の変化に左右されません。

システムフォントが存在しない環境への対応

次によくあるのが、システムフォントの指定ミスです。

例えば、デザイナーが「この見出しはメイリオで統一」って指定したとします。
ローカルでメイリオをインストールしてるから、きれいに表示される。
だけどクライアント企業のWindows環境には、メイリオがない場合があります。
古いOSだったり、フォントパッケージが削除されてたり。

そこで大事なのが font-family の並び順です。

良くない例：

font-family: "メイリオ", serif;

メイリオだけを指定してて、フォールバック先が serif だけ。
メイリオがなかったら明朝体になっちゃいます。

良い例：

font-family: "メイリオ", "Segoe UI", "Hiragino Sans", "ヒラギノ角ゴ Pro", "Yu Gothic", YuGothic, sans-serif;

複数のフォントを指定することで、左から順番に「存在するか？」をチェックされます。
メイリオがなかったら、次はSegoe UIを見る。
それもなかったらヒラギノ…という具合に、フォールバックしていく。
最終的に必ず何らかのフォントで表示される。

僕がよく使う工夫は、OS別にフォントを指定することです。

WindowsとMacじゃ、標準で入ってるフォントが全然違いますからね。
Macだったら「Hiragino Sans」が確実に入ってますし、Windowsなら「Yu Gothic」。
最後に汎用の sans-serif を置くことで、どの環境でも読みやすいサンス体で表示される。

CORSとキャッシュの落とし穴

Webフォントを外部CDNから読み込んでる場合、CORS（Cross-Origin Resource Sharing）の設定が影響することがあります。

例えば、あなたのドメインが example.com で、Google Fontsから読み込んでるとします。
Google Fontsのサーバー側で、CORSが正しく設定されてれば問題ありません。
だけど、自社サーバーでWebフォントを管理してて、CORS設定が不足してると、ブラウザがフォント読み込みをブロックするんです。

ローカル環境（localhost とか 127.0.0.1）では、CORS制限がゆるいので動く。
本番サーバーでは厳しく適用される。
そのギャップで「ローカルでは動くが本番で動かない」という状況が生まれます。

対策は、サーバー側の .htaccess や web.config で、CORSヘッダーを追加することですね。

Apache の例：

<FilesMatch "\\.(woff|woff2|ttf|otf|eot)$">
Header add Access-Control-Allow-Origin "*"
</FilesMatch>

もう一つ、地味に引っかかるのがブラウザキャッシュです。
ローカルでテストしたときに、ブラウザがフォントファイルをキャッシュしてる。
だから「ファイルが存在しない」って修正しても、ブラウザはキャッシュから古いフォント読み込もうとする。
結果、本当は修正されてるのに「まだ壊れてる」に見える。

これを避けるには、フォントファイルのURLにバージョン番号をつけるといいですよ。