【初心者向け】Webデザインのためのフォント選び完全ガイド｜迷わない選び方とおすすめ書体

Webサイトでその書体を使ってよいかどうかは、印象や好みではなく「入手経路」と「ライセンス原本の記述」の2点で決まります。入手経路とは、OSにバンドルされている書体を指名するのか、フォントファイルを自分のサーバーに置いて配信するのか、Google FontsなどのCDNから配信するのかという違いのことです。そして配布元のライセンス文書に「Webフォントとしての配信（embedding／webfont）を許す記述」があるかどうかが合否のラインになります。

フォント選びの記事は世の中に大量にありますが、その多くは「この書体はやさしい印象」「この書体は信頼感がある」という印象の話で終わります。ところが実務で本当に事故になるのは印象のミスマッチではなく、選んだあとで「その書体はそもそも配信できない」と分かるケースです。カンプでヒラギノ角ゴを組んで承認まで通したのに、実装段階でWindowsユーザーには一切表示されないと判明する。無料と書かれていたフォントを自社サーバーに置いたら、配布元のライセンスにWeb配信の許諾が書かれていなかった。こうした差し戻しは、選ぶ順番を変えるだけで防げます。

この記事では、書体名のカタログではなく「候補を配信可否で先に絞り込む手順」を扱います。読み終えたあと、いま候補に挙がっている書体を自分で判定できる状態になることがゴールです。記事の後半には、ブラウザだけで完結する検証ステップと合否ラインの表を用意しました。

なお、本記事に記載したフォントの収録状況・ライセンス区分・配信可否は、すべて2026年8月1日時点で配布元の一次資料を直接確認した内容です。該当箇所には出典へのリンクを置いているので、判断の前には必ず最新の表示をご確認ください。

フォントは「印象」より先に「配信できるか」で絞る

フォント選びを「印象 → 実装」の順で進めると、印象で選んだ候補が実装段階で全滅することがあります。逆に「配信できる候補を洗い出す → その中から印象で選ぶ」という順にすると、選定にかけた時間が無駄になりません。最初に絞り込みをかけたほうが、結果的に候補を見る目も速くなります。

この記事が答えること・答えないこと

フォントまわりの疑問は大きく4つに分かれます。この記事が引き受けるのは、そのうち「使ってよいかの判定」だけです。残りは別の記事に分けてあるので、必要な入口から進んでください。

つまりこの記事には、書体名と印象を並べた一覧表は載せません。書体名のカタログは用途ごとに更新頻度が高く、独立した記事のほうが正確に保てるためです。ここでは、そのカタログを見る前に立てておくべき判断基準だけを扱います。

判定に使う2つの軸

判定の軸は2つだけです。どちらも、書体の見た目とはまったく関係がありません。

1. 入手経路：その書体は「閲覧者の端末に元から入っているもの」なのか、「こちらが配信するもの」なのか。配信するなら、自分のサーバーからか、外部のCDNからか。
2. ライセンス原本の記述：配布元が出しているライセンス文書に、Webフォントとしての配信を許す記述があるか。まとめ記事やSNSの伝聞ではなく、配布元の文書そのものを見る。

この2軸を先に通すと、候補は驚くほど減ります。そして減ったあとに残った候補は、少なくとも「本番で配信できないことが後から分かる」というリスクを抱えていません。

▶ デザインの基礎を体系的に整理したい方はこちら

入手経路の3分類｜OSバンドル・セルフホスト・CDN配信

Webページで文字を表示する方法は、突き詰めると3種類しかありません。この分類を先にはっきりさせないと、ライセンスの読み方も検証の手順も定まりません。

OSバンドル｜端末に入っている書体を指名する

CSSで書体名を書くだけで、フォントファイルは一切配信しない方式です。閲覧者の端末にその書体が入っていれば表示され、入っていなければ次の候補にフォールバックします。

この方式には、ライセンス上のリスクがほぼありません。こちらは何も配信していないため、フォントの再配布にも埋め込みにも当たらないからです。転送量も増えず、表示の遅延も起きません。代わりに引き受けるリスクが1つあります。その書体が閲覧者の端末に入っている保証がないことです。

セルフホスト｜自分のサーバーにフォントファイルを置く

フォントファイル（woff2など）を自分の管理下のサーバーに置き、そこから閲覧者に配信する方式です。表示は端末環境に左右されず、意図した書体が確実に出ます。

ただし、この方式は「フォントファイルを不特定多数に配布している」状態にあたります。ライセンス上、もっとも慎重に確認が必要なのがこの経路です。「デザインツールで使えたから」「PCに入っていたから」という理由でファイルをサーバーに置くのは、判断としては最も危険な部類に入ります。

CDN配信｜提供元のサーバーから配る

Google FontsやAdobe Fontsのように、提供元が用意した配信サーバーを経由して読み込む方式です。フォントファイル自体は自分で持たず、提供元が定めた利用規約の範囲内で使います。

配信の許諾については提供元が明示しているため、判断は3経路のなかで最も簡単です。ただしこの経路には固有のリスクがあります。提供元のサービスや自分の契約状態に、表示が依存することです。サブスクリプション型のサービスでは、契約が終われば配信も止まります。

3経路の比較

実務では1サイトのなかでこの3経路が混ざります。混ざること自体は問題ありませんが、いま話している書体がどの経路なのかを常に1つに特定できる状態にしておく必要があります。「Noto Sans JPを使う」だけでは判断材料になりません。「Noto Sans JPをCDN配信で使う」なのか「セルフホストする」なのかで、確認すべき文書が変わるからです。

OSバンドルは「あると思っていたら無い」が起きる

OSバンドルを前提にした指定は手軽ですが、「入っているはず」という思い込みがそのまま表示崩れになります。ここは伝聞ではなく、OS提供元が公開している収録一覧で確認できます。

Windows 11で常時入っている和文フォントは限られる

Microsoftが公開しているWindows 11のフォント一覧を読むと、収録は「ベースとして常時入るもの」と「Feature On Demand（FOD）＝追加インストール扱いのもの」の2階層に分かれています。日本語フォントの多くは後者の「Japanese Supplemental Fonts」に置かれています。

ここで注意したいのがメイリオ（Meiryo）です。日本語Webの本文フォントとして長く筆頭に挙げられてきた書体ですが、Windows 11のベース一覧には含まれておらず、Japanese Supplemental Fonts側に収録されています。同様に游明朝（Yu Mincho）もFOD側です。日本語環境として使っていれば実際には入っていることがほとんどですが、「Windows 11なら必ずある」と言い切れる和文はYu GothicとMS Gothic系だとみておくのが安全です。出典はMicrosoft Learn「Windows 11 font list」で、2026年8月1日時点の掲載内容を確認しています。

実務上の結論はシンプルです。OSバンドルを当てにする場合、和文の第一候補にメイリオを置かない。置くとしても、その後ろにYu Gothicなど常時入る書体を必ず並べてフォールバックを作ります。

ヒラギノ角ゴはWindowsとAndroidに存在しない

ヒラギノ角ゴはmacOSとiOSにバンドルされる書体で、WindowsやAndroidには入っていません。Macで制作していると常に美しく表示されるため、その表示が全ユーザーの見え方だと錯覚しやすい典型例です。

さらに重要なのが、ヒラギノをNoto Sans JPと同列に扱えないという点です。Noto Sans JPはCDN配信もセルフホストも許諾された書体ですが、OSにバンドルされる書体は「その端末上での表示や印刷」を前提に提供されるものであり、第三者へWebフォントとして配信することを許す記述は公開文書で確認できません。この記事の判定ルールは「記述が無いものは許可されていないと扱う」ですから、ヒラギノをセルフホストする選択肢は最初から候補外になります。

つまりヒラギノは、OSバンドル経路でMacユーザーにだけ届く書体として扱うのが正確です。「Macでは美しく、Windowsでは別の書体になる」という前提を関係者と共有できるなら使えますし、それが許されないなら最初から候補から外します。

同じ書体でもOSによって名前が違う

OSバンドル経路には、もう1つ落とし穴があります。同じ游ゴシックでも、Windowsでは Yu Gothic（半角スペースあり）、macOSでは YuGothic（スペースなし）と名前が異なります。片方しか書いていないと、もう一方の環境では指定が効きません。

選定の段階で必要な認識は「OSバンドルを使うなら名前ゆれの対応が要る」ということまでで十分です。具体的な書き方や候補の並べ方は実装側の話なので、次の記事にまとめてあります。

▶ CSSでのfont-family指定と名前ゆれの対処はこちら

ライセンスの読み方｜合否は「Web配信を許す記述」で決まる

フォントのライセンス文書は難解に見えますが、Web制作で確認すべき点はごく限られています。「配信・埋め込みを許しているか」「商用利用を許しているか」「改変や再配布に条件はあるか」の3点です。ここを押さえれば、大半の書体は数分で判定できます。

SIL Open Font Licenseは埋め込みを明示的に許している

フリーフォントで最も多く使われているのがSIL Open Font License（OFL）1.1です。公式のライセンス本文には、許諾される行為として use, study, copy, merge, embed, modify, redistribute, and sell が列挙されており、埋め込み（embed）と再配布（redistribute）が明示的に含まれます。したがってセルフホストでのWeb配信も許諾の範囲です。

制約として押さえるのは主に2つです。1つはフォント単体で販売してはいけないこと（ソフトウェアなどに同梱して販売するのは可）。もう1つはReserved Font Nameが設定されている場合、改変版に同じ名前を使えないことです。Webサイトで通常どおり使うぶんには、どちらも問題になりません。出典はSIL Open Font License 公式本文です。

Google Fontsは「全部が同じライセンス」ではない

「Google Fontsは完全無料で商用利用可能」という説明をよく見かけますが、これは正確ではありません。Google Fonts公式のリポジトリでは、トップレベルのディレクトリ名がそのまま収録フォントのライセンスを示す構造になっており、複数のライセンスが混在しています。

公式のREADME自体が It is important to always read the license for every font that you use.（使うフォントごとに必ずライセンスを読むことが重要です）と明記しています。「Google Fontsだから確認不要」という前提こそが、公式の言い分と食い違っています。数値・記述の出典はgoogle/fonts 公式リポジトリで、ディレクトリの収録数は同日にAPIで実測したものです。

実務上は、これら3つのライセンスはいずれもWeb配信と商用利用を許しているため、Google Fontsを経由して使うぶんには判定はほぼ通ります。問題になるのはライセンスを個別に確認する習慣がないまま、別の配布サイトから拾ったフォントにも同じ感覚を持ち込むときです。

名前が似ていても別の書体・別の入手経路

丸ゴシック体を探すと「Rounded M+」と「M PLUS Rounded 1c」の両方が出てきます。名前が似ているため同じものだと思われがちですが、配布元も入手経路もライセンスも別です。

自家製 Rounded M+のライセンスページには Unlimited permission is granted to use, copy, and distribute them, with or without modification, either commercially or noncommercially. と記されており、商用・非商用を問わず利用・複製・再配布が認められています（配布サイトはhttpのみで提供されています）。一方のM PLUS Rounded 1cはGoogle Fontsの ofl ディレクトリに収録されたOFLフォントで、CDNからそのまま呼び出せます。

どちらも使えますが、手順がまったく違います。片方はファイルをダウンロードして自分で配信する作業が発生し、もう片方は読み込み1行で終わります。「丸ゴシックを使う」と決めた段階では同じに見えて、作業量とライセンス確認の重さは別物です。ここを取り違えると、見積もりの工数がずれます。

サブスク型フォントは契約が切れると配信も止まる

Adobe Fontsのようなサブスクリプション型のサービスは、契約が有効な間だけ利用できます。フォントファイルを自分で保有しているわけではないため、契約が終了すればWeb配信も止まり、サイトの表示はフォールバック先の書体に置き換わります。

これは欠点ではなく、選定時に織り込むべき条件です。判断の分かれ目は「そのサイトを何年運用するか」「運用を誰に引き継ぐか」にあります。制作会社が自社契約で配信を設定したまま納品し、契約更新が途切れた瞬間にクライアントのサイトの見た目が変わる、という事故は構造的に起こり得ます。

• 長期運用・引き継ぎ前提のサイト → 契約に依存しない経路（OFLフォントのCDN配信またはセルフホスト）を優先する
• 自社で継続的に運用するサイト → サブスク型でも問題は起きにくい
• いずれの場合も、契約者名義と支払い主体をドキュメントに残す

なお、Adobe Fontsで提供される書体数やプランの料金は改定されるため、本記事では数値を記載していません。導入判断の前に公式サイトで最新の条件をご確認ください。

▶ Adobe Fontsで実際に使える日本語・英語フォントを見る

▶ Google Fontsのおすすめ書体を見る

【検証】選んだ書体を、その用途で配信してよいか確かめる

ここまでの内容を、実際に手を動かす手順に落とします。所要時間は1書体あたり数分で、ブラウザ以外のツールは使いません。いま候補に挙がっている書体を1つ選び、そのまま3ステップを通してください。

ステップ1｜入手経路を1つに特定する

その書体を、OSバンドル・セルフホスト・CDN配信のどれで使うのかを言葉にします。「どれでもいい」「まだ決めていない」は不合格です。経路が決まらないと、次に開くべき文書が決まらないためです。

迷ったときの決め方は単純です。Windowsユーザーにも同じ書体で見せたいならOSバンドルは使えません。その時点で候補はセルフホストかCDN配信の2つに絞られます。

ステップ2｜ライセンス原本の所在を開く

まとめ記事やSNSの投稿ではなく、配布元が自分で出している文書を開きます。判定の根拠にしてよいのは次のものだけです。

• 配布元サイトの「ライセンス」ページ
• ダウンロードしたファイルに同梱されている OFL.txt / LICENSE.txt
• Google Fontsなら、リポジトリの該当ファミリーのディレクトリに置かれたライセンスファイル
• サブスク型なら、そのサービスの利用規約・ライセンスに関する公式ヘルプ

ここで「原本が見つからない」という結果自体が判定材料になります。配布元がライセンス文書を出していないフォントは、使ってよい範囲が誰にも分かりません。仕事で使う書体としては、その時点で候補から外します。

ステップ3｜Web配信を許す記述があるか読む

開いた文書のなかで、次のキーワードを探します。英文なら embed / webfont / distribute / redistribute、和文なら「埋め込み」「Webフォント」「再配布」です。ブラウザの検索機能（Ctrl+F または Command+F）で十分です。

判定ルールはただ1つ。記述が無いものは「許可されていない」と扱います。「禁止と書かれていないから大丈夫だろう」は、フォントのライセンスでは通用しません。許諾は明示されて初めて成立します。

合否ライン

5項目すべてが「合格」の列に収まったときだけ、その書体をその用途で使えます。1つでも右の列に落ちたら、経路を変えるか書体を変えます。

実例で当てはめると、Google Fontsから ofl 配下のファミリーをCDN配信する構成は5項目すべてが合格します。ヒラギノ角ゴをセルフホストする構成は「Web配信の可否」で落ちます。メイリオをOSバンドル経路で第一候補に置く構成は、ライセンスは問題ないもののそもそも表示される保証がないため、選定としては不合格です。

不合格だったときの切り分け

この検証はライセンスと入手経路の判定までで止めます。「指定したCSSが実際に効いているか」「どの書体で描画されているか」はブラウザの開発者ツールで見る別の作業なので、実装側の記事に分けています。

▶ 見出し×本文の組み合わせをブラウザで試す（フォントペアリング プレビューア）

可変フォントという絞り込みの観点

配信可否で候補を絞ったあと、もう1つ効く観点があります。その書体に可変フォント（Variable Fonts）版が存在するかどうかです。

可変フォントとは

可変フォントとは、太さ（weight）や幅（width）などを連続的な軸として1つのファイルに収めたフォント形式です。従来はLight・Regular・Bold…とウェイトごとに別ファイルを読み込む必要がありましたが、可変フォントなら1ファイルで全ウェイトをまかなえます。仕様と使い方はMDNの可変フォントガイドにまとまっています。

「ウェイト3本」より「可変1本」で候補を絞る

選定の場面でこの観点が効くのは、「デザイン上ほしいウェイトが3本以上あるとき」です。従来型のフォントで太さを3段階使い分けようとすると、ファイルを3本読み込むことになります。日本語フォントは収録文字数が多くファイルサイズも大きいため、この差は無視できません。

Google Fontsでは、可変軸に対応したファミリーを wght@100..900 のように範囲で指定できます。2026年8月1日時点で、Roboto・Inter・Noto Sans JPはいずれもこの範囲指定でCSSが返ってきます（実際にリクエストして確認済み）。つまりこの3書体は、ウェイトを何本使う設計でも読み込みは1系統で済みます。

• 本文と見出しでウェイトを2本しか使わない → 可変かどうかは判断材料にならない
• ウェイトを3本以上使う設計 → 可変フォント版がある書体を優先する
• 将来ウェイトを増やす可能性がある → 可変フォント版があると設計変更のコストが下がる

ここで扱うのはあくまで「候補を絞る観点」までです。実際の読み込み方や font-variation-settings の書き方、サブセット化との組み合わせは実装の領域なので、CSS側の記事に譲ります。

選定の段階で起きる失敗と、失敗ではないもの

フォント選びの「NG集」はよく見かけますが、条件が広すぎて実務の定番手法まで否定しているものが少なくありません。ここでは、本当に避けるべきものと、避ける必要がないものを分けます。

見出し明朝×本文ゴシックは失敗ではない

「明朝体とゴシック体を混ぜてはいけない」という説明を見ることがありますが、これは条件が広すぎます。見出しに明朝、本文にゴシックという組み合わせは、書籍・雑誌・Webを通じて定番のペアリングです。役割の違う要素に違う骨格の書体を当てることで、階層が視覚的に伝わりやすくなります。

問題になるのは「明朝とゴシックが混ざっていること」そのものではなく、混ぜ方に規則がないことです。「h2は明朝、h3も明朝、本文はゴシック」は規則ですが、「h2は明朝、h3はゴシック、リード文は明朝」は規則ではありません。読者は書体の切り替わりを情報の切り替わりとして読むため、規則のない切り替えは意味のないノイズになります。

本当に避けるべき使い方

• 装飾フォントを長文の本文に使う：可読性が明確に下がる。装飾フォントはロゴ・見出し・短いキャッチコピーまでにとどめる
• 同じ役割の要素に違う書体を当てる：h3ごとに書体が変わるなど。切り替えに意味がないため読者が混乱する
• フォールバックを設計せずOSバンドル書体を指定する：制作環境でしか意図した表示にならない
• ライセンス未確認のファイルをサーバーに置く：見た目の問題ではなく、権利の問題として残り続ける

「書体は2〜3種類まで」は目安であって規則ではない

「1サイトで使う書体は2〜3種類が限度」という言い方は広く流通していますが、これを裏づける公的な基準や調査は見当たりません。実際には、和文1・欧文1・コード表示用の等幅1という構成で3種類を超えるサイトは珍しくありませんし、それで読みにくくなることもありません。

数を制限すること自体が目的ではなく、「書体が切り替わる場所に意味があるか」が本質です。役割ごとに1書体を割り当て、その割り当てをドキュメント化できるなら、種類が4つでも設計は破綻しません。逆に2種類でも、割り当てのルールがなければ雑然とします。

なお、可読性の観点で公的な基準があるのは書体の「数」ではなく「拡大したときに壊れないこと」のほうです。W3CのWCAGでは、200%まで拡大しても内容や機能が失われないことが達成基準として定められています。書体の数を気にする前に、こちらを満たしているかを確認してください。

▶ 文字サイズ・行間・行長の具体的な数値はこちら

フォントを決めたあとに読むもの

配信可否の判定を通った書体が手元に残ったら、次は具体的な書体選びと実装に進みます。目的に応じて必要な記事を選んでください。

• Google Fontsのおすすめ日本語・英語フォント：CDN配信でそのまま使える候補を探す
• Adobe Fontsのおすすめ日本語・英語フォント：契約がある場合の候補を探す
• CSSのフォント指定ガイド：font-familyの並べ方・名前ゆれ・読み込みの設定
• タイポグラフィ設計ガイド：文字サイズ・行間・行長の数値を決める
• 構造→視覚→文字で組み立てるUIデザインの流れ：文字を決める前段の設計手順
• カンプを作る前に押さえるWebデザインの原則：制作フローの上流を整理する
• バナーデザインの構図と配置：限られた面積で文字を組む場合の考え方
• フォントペアリング プレビューア：見出しと本文の組み合わせをブラウザで比較する

よくある質問（FAQ）

Q. Webデザインでフォントを選ぶときの判断基準は何ですか？

印象や好みより先に「配信できるか」を判定してください。具体的には、その書体をOSバンドル・セルフホスト・CDN配信のどれで使うのかを1つに特定し、配布元が出しているライセンス文書にWebフォントとしての配信を許す記述があるかを確認します。この2点を通った候補のなかから、可読性・トーン・ウェイトの本数といった要件で絞り込むのが、差し戻しの起きない順序です。

Q. メイリオを本文フォントの第一候補にしてもよいですか？

OSバンドル経路で使うなら、第一候補には置かないことをおすすめします。Microsoftが公開しているWindows 11のフォント一覧では、メイリオはベースとして常時収録される書体ではなく、Feature On Demandの「Japanese Supplemental Fonts」に含まれています。常時入る和文はYu GothicとMS Gothic系です。メイリオを指定すること自体は問題ありませんが、その後ろにYu Gothicなどを並べてフォールバックを作ってください。

Q. ヒラギノ角ゴをWebフォントとして配信できますか？

できないものとして扱ってください。ヒラギノ角ゴはmacOSとiOSにバンドルされる書体で、その端末上での表示や印刷を前提に提供されています。第三者へWebフォントとして配信することを許す記述は公開文書で確認できないため、この記事の判定ルール（記述が無いものは許可されていないと扱う）では不合格になります。Macユーザーにだけ届くOSバンドル経路として使うか、全環境で同じ書体を見せたいなら配信可能な別の書体を選んでください。

Q. Google Fontsなら商用利用の確認は不要ですか？

不要ではありません。Google Fonts公式リポジトリのREADMEは「使うフォントごとに必ずライセンスを読むことが重要です」と明記しています。収録フォントは大多数がSIL Open Font License 1.1ですが、Apache License 2.0のもの、Ubuntu Font License 1.0のUbuntu系ファミリーも含まれており、単一のライセンスではありません。いずれもWeb配信と商用利用は許諾されているため実務上は通りますが、「Google Fontsだから確認不要」という前提は公式の説明と食い違っています。

Q. Rounded M+とM PLUS Rounded 1cは同じフォントですか？

別のフォントです。自家製 Rounded M+は自家製フォント工房が配布する書体でM+ FONTS LICENSEが適用され、サイトからファイルをダウンロードして自分で配信する（セルフホスト）前提になります。M PLUS Rounded 1cはGoogle Fontsに収録されたSIL Open Font License 1.1の書体で、CDNから読み込むだけで使えます。どちらも商用利用は可能ですが、必要な作業と確認すべき文書が異なるため、名前の似ている両者を取り違えないでください。

Q. サブスク型のフォントサービスは避けたほうがよいですか？

避ける必要はありませんが、契約が切れた時点で配信が止まり、表示がフォールバック先の書体に変わることを前提に選んでください。判断の分かれ目は運用体制です。自社で継続的に運用するサイトなら問題は起きにくく、制作会社が納品して運用を引き継ぐサイトでは、契約主体と更新責任をドキュメントに明記しておく必要があります。長期運用で引き継ぎが読めない案件では、契約に依存しないOFLフォントを優先するほうが安全です。

Q. 明朝体とゴシック体を同じページで混ぜてはいけませんか？

混ぜて問題ありません。見出しに明朝、本文にゴシックという組み合わせは定番のペアリングで、役割の違う要素に違う骨格の書体を当てることで階層が伝わりやすくなります。避けるべきなのは混在そのものではなく、切り替えに規則がない状態です。「見出しは明朝、本文はゴシック」のように役割と書体の対応を決め、その割り当てをドキュメント化できていれば、種類が増えても設計は破綻しません。

Q. 可変フォントはどんなときに選ぶべきですか？

デザイン上ほしいウェイトが3本以上あるときです。従来型のフォントで太さを3段階使い分けるとファイルを3本読み込むことになりますが、可変フォントなら1ファイルで済みます。日本語フォントは収録文字数が多くファイルサイズも大きいため、この差は無視できません。逆にウェイトを2本しか使わない設計なら、可変かどうかは選定の判断材料になりません。Google FontsではRoboto・Inter・Noto Sans JPなどが可変軸に対応しています。

まとめ｜フォントは「使ってよいか」から決める

フォント選びで迷う原因は、選択肢が多いことではなく、絞り込む順番が逆になっていることです。印象で選んでから実装で詰まるのではなく、配信できる候補を先に確定させてから印象を比べれば、選定にかけた時間が無駄になりません。

• 入手経路をOSバンドル・セルフホスト・CDN配信のどれか1つに特定する
• 配布元が出しているライセンス原本を開く（まとめ記事は根拠にしない）
• embed / webfont / redistribute を許す記述を探す。記述が無ければ使わない
• OSバンドルを当てにするなら、常時収録されている書体でフォールバックを作る
• ウェイトを3本以上使うなら、可変フォント版がある書体を優先する

この5行を通すだけで、「承認まで進んだあとに配信できないと分かる」という最も痛い差し戻しは避けられます。まずは、いま候補に挙がっている書体を1つ選んで、ライセンス原本を開くところから始めてください。

▶ 配信できる書体が決まったら、CSSでの指定方法へ

▶ 文字を決める前段のUI設計手順を確認する