Webフォントとは|『デバイス非依存の文字表現』を実現する技術の本質と日本語対応の壁

『Webフォント』って、ぶっちゃけ何のことか、説明できますか?

株式会社Cameen 西村温裕ことおんゆーです。

近年、Webサイト制作の現場ではブランド表現の一貫性が重視されるようになりました。Google Fonts・Adobe Fonts・FONTPLUS・TypeSquare、こういうWebフォントサービスを使うのが標準的な制作工程になっています。

でも、いざ「Webフォントって具体的に何の技術?」「@font-faceとどう違う?」「日本語Webフォントが重いのはなぜ?」と聞かれると、答えに詰まる方が多いんですよね。「フォントをWebで使う仕組み」という認識で止まって、Webフォントの本質的な役割と運用設計まで理解している人は意外と少ない。これ、自分だけだと思ってませんか?

うちの事業ではWordPressサイト6サイトを運用していて、Webフォントの選定・実装・パフォーマンス調整を何度も繰り返してきました。その中で見えてきたのは、Webフォントは単なる「綺麗なフォント表示」ではなく、「デバイスやOSに依存せずブランド表現を統一する技術」だということ。見た目を整えることが目的ではなく、どの端末で見ても同じ印象を与えることが本質です。

もう1つ繰り返し観察したのは、「Webフォントの設定を雑にやってCore Web Vitalsを破壊するサイト」が圧倒的に多いという事実。日本語フルセットのフォントを何も考えずに読み込むと、LCP(Largest Contentful Paint)が5秒を超えてSEO評価が下がります。Webフォントはデザインだけでなくパフォーマンス設計が決定的に重要な領域です。

今回はその「今さら聞けないWebフォント」を、表面的な解説ではなく、デバイス非依存の技術構造と日本語対応の壁、運用上必須の4設定まで一気に深掘りしていきます。読み終わる頃には、自分のサイトでWebフォントをどう設計すべきか、サブセット化からfallback設計まで紙に書き出せるレベルになっているはずです。

結論:Webフォントの核心は「綺麗なフォント」ではなく「デバイス非依存のブランド表現統一」

Webフォントの本当の正体は、「ユーザー端末にインストールされているフォントに依存せず、Webサーバーから配信したフォントファイルでブランド表現の一貫性を保証する技術」のことです。単なるデザイン強化技術ではなく、デバイス・OS・ブラウザの違いを吸収して、誰が見ても同じ文字表現を実現する仕組みです。

業界の体感として、Webフォント未使用のサイトはOSごとに全く違う印象になります。Windowsでは「游ゴシック」、macOSでは「ヒラギノ角ゴ」、iOSでは「San Francisco」、Androidでは「Noto Sans」が表示され、同じサイトでもデバイスごとに別物に見えてしまう。Webフォントはこの問題を根本から解決する技術です。

Webフォントの技術的な実装は、CSS3の@font-face仕様(2009年策定)が起点。サーバーに置いたフォントファイル(woff/woff2形式)をブラウザがダウンロードし、ページ内のテキストに適用します。Google Fonts(2010年公開)、Adobe Fonts(旧Typekit)、日本語特化のFONTPLUS・TypeSquareなどのサービスが普及し、現在では大多数のWebサイトがWebフォントを採用しています。

Webフォントの真の価値は見た目ではなく、ブランド体験の一貫性とCore Web Vitalsとの兼ね合いの設計です。日本語Webフォントは欧文と比べて圧倒的にファイルサイズが大きく(後述しますが100倍程度の差があります)、雑に実装するとLCP・FCPが破綻します。デザインとパフォーマンスのバランス設計が、Webフォント運用の決定的な分かれ目です。

なぜ「Web Fonts」と名付けられたのか

もう少し深く掘ります。なぜこの技術は「Webフォント(Web Fonts)」と名付けられたのか。命名の背景を整理します。

「Web Fonts」はそのまま「Web上のフォント」という意味なんですが、命名のニュアンスには「ローカル端末ではなくWeb経由で取得するフォント」という対比が込められています。それまでのWebサイトは、ユーザーのOSにインストール済みのフォント(system fonts)に依存していました。Webフォントは、この依存関係を逆転させる技術です。

Webフォントの技術的起点は、2009年のCSS3仕様策定。W3C(World Wide Web Consortium)が@font-face仕様を正式採択し、ブラウザがフォントファイルをHTTP経由でダウンロードして適用できるようになりました。それ以前は、ブラウザのフォント描画はOS依存で、Webデザイナーは「どの端末でも安全なフォント(Arial・Times New Romanなど)」しか使えませんでした。

業界の転換点は2010年。Google Fonts(当初Google Web Fonts)が無料で多数のフォントを公開し、誰でも簡単にWebフォントを使える環境が整いました。同時期にAdobe Typekit(現Adobe Fonts)が商用フォントのWeb配信を開始し、デザイナーが商用フォントをWebサイトで使えるエコシステムが完成しました。

日本語Webフォントの普及は欧文より遅れて、2012年頃から本格化しました。FONTPLUS(ソフトバンク・テクノロジー)・TypeSquare(モリサワ)などの専門サービスが、日本語フォントのライセンス問題と巨大ファイルサイズ問題を解決するためのサブセット配信技術を整備。これにより、日本語サイトでもWebフォント活用が現実的になりました。

業界の体感として、現在はWebサイトの90%以上が何らかのWebフォントを採用しています。Google Fontsの統計では月間50兆回のリクエストが処理されているという数字もあり、Webフォントは事実上のWeb標準技術になりました。

技術仕様も進化を続けていて、フォントファイル形式はTTF→EOT→WOFF→WOFF2と圧縮効率が改善され、現在の標準WOFF2は元のフォントファイルから30〜50%サイズを削減できます。さらにVariable Fonts(2016年〜)では1ファイルで複数のウェイト・スタイルを扱えるようになり、Webフォントの運用効率が一段階向上しました。

Webフォント実装の現場で何が起きているか

Webフォント実装の現場で、具体的に何が起きているか。5段階で整理します。

ステージ1:フォント選定とブランド設計

制作の最初の段階は、ブランドに合うフォントの選定。和文ゴシック(Noto Sans JP・Source Han Sans・ヒラギノ角ゴ)、和文明朝(Noto Serif JP・Source Han Serif)、欧文サンセリフ(Inter・Roboto・Helvetica)、欧文セリフ(Garamond・Georgia)、こういう選択肢から事業の性格に合わせて2〜3種類を選びます。

フォント選定でよくある失敗は「デザイナーの好み」で決めること。本来は、ブランドガイドラインで定めた「信頼系」「ポップ系」「和風」などのトーンと、可読性(本文用)・表現力(見出し用)のバランスから論理的に選びます。ターゲット読者の年齢層・閲覧端末も判断軸になります。

ステージ2:ライセンス確認と配信方式の決定

フォント選定後は、必ずライセンス確認。Google Fonts(無料・SIL OFL)、Adobe Fonts(契約サブスク)、商用フォント(モリサワ・フォントワークス)、こういう違いを確認します。商用利用可否・ページビュー上限・ドメイン制限、すべてライセンスで規定されています。

配信方式は3パターン。(1)CDN経由(Google Fonts・Adobe Fonts)、(2)セルフホスト(自サーバーに配置)、(3)ハイブリッド(主要フォントはCDN・補助はセルフ)。CDNは設定が簡単だが3rd-partyドメインへのリクエストが発生、セルフホストはパフォーマンス制御しやすいがファイル管理が必要です。

ステージ3:CDN/セルフホスト判断とCSS実装

配信方式が決まったら、CSS実装。CDN経由ならlinkタグで読み込み、セルフホストなら@font-face宣言でフォントファイルパスを指定します。フォントファミリー名・ウェイト・スタイル・サブセット範囲、すべてCSSで明示的に記述します。

業界の事故例として多いのが、不要なフォントウェイトを全部読み込んでしまうケース。Light(300)・Regular(400)・Medium(500)・Bold(700)・Black(900)を全部読み込むと、実際には使わないウェイトでもファイルがダウンロードされます。「使うウェイトだけ明示する」が基本原則です。

ステージ4:font-display設定とfallback設計

Webフォント実装の核心が、font-display設定とfallback設計。font-display: swapを指定すれば、Webフォント読み込み中はシステムフォントで表示し、読み込み完了後にWebフォントに切り替わります。これによりFOIT(Flash of Invisible Text=テキストが見えない時間)を回避できます。

fallback設計は、Webフォント読み込み失敗時の代替手段。font-familyに「Noto Sans JP, ヒラギノ角ゴ ProN, BIZ UDPGothic, sans-serif」のように複数候補を並べておくと、Webフォント取得失敗時もシステムフォントで自然に表示されます。ユーザー体験を守る最後の砦です。

ステージ5:パフォーマンス計測と継続改善

実装後は、必ずパフォーマンス計測。PageSpeed Insights・Lighthouse・WebPageTestで、LCP(Largest Contentful Paint)・FCP(First Contentful Paint)・CLS(Cumulative Layout Shift)を測定します。Webフォントの影響でこれらの指標が悪化していないか確認します。

計測の結果でLCPが2.5秒を超えていたら、サブセット化・preload追加・font-display調整、これらを順次実施して改善。Core Web VitalsはSEOランキングにも影響するため、Webフォントのパフォーマンス影響は継続的に監視する必要があります。実装して終わりではなく、運用フェーズが本番です。

身近な話で全体像をつかむ

ちょっと身近な話で、全体像を掴み直しましょう。

全国チェーン飲食店のメニュー表記統一に置き換えてみます。あなたが全国に1,000店舗ある飲食チェーンの本部担当だとします。各店舗のメニュー表記を、北海道店も沖縄店も、新宿店も大阪店も、全部同じデザイン・同じフォントで統一したい。これが目標です。

選択肢は2つ。(1)各店舗で勝手にメニュー作成→店舗ごとにバラバラ(2)本部が統一テンプレートを配布→全店舗で同じ表記。(1)が「Webフォント未使用のサイト」、(2)が「Webフォント採用のサイト」に対応します。デバイス・OSがバラバラでも、本部(Webサーバー)から配信したフォントを使えば全端末で表記が統一されます。

でも、ここで問題が発生。全店舗に配布するメニューデザインのファイルが大きすぎて、配送に時間がかかってしまったらどうなるか。お客様が来店してもメニューが届くまで待たされる。これがWebフォントで言うLCP遅延・FOITの問題です。

解決策は2つ。(1)メニューを必要な料理だけに絞って軽量化する(=サブセット化)、(2)メニューが届くまで仮メニューで対応する(=font-display: swap+fallback)。この2つを組み合わせることで、統一性とスピードの両立が実現します。

業界の例として、Google Fonts経由でNoto Sans JPフルセットを読み込むと、ファイルサイズが約5MBを超えます。これは欧文フォント1個(約30〜50KB)の100倍の重さ。何も対策せずに使うと、特にモバイル回線でLCPが破綻します。サブセット化やpreload設計が必須になる理由は、この日本語特有のサイズ問題にあります。

逆に、Webフォントを正しく設計したサイトは、ブランド体験の統一とパフォーマンスの両立を実現できます。常用漢字+ひらがな+カタカナだけにサブセット化すれば、5MBが300KB以下に圧縮可能。これに加えてfont-display: swap+preloadを組み合わせれば、LCP 2.5秒以内+ブランド表現統一+SEO評価維持、すべて両立します。設定の有無で天と地ほど結果が変わる領域です。

Webフォント運用で必須の4設定