準備するもの
まずフォントのライセンス文書を確認し、「埋め込み・再配布」が許可されているかチェックする。商用フォントの多くは埋め込みを認めていないケースがあり、無断で同梱すると契約違反になる。Google FontsやSIL OFLのフォントは再配布可能なものが多いが、必ず個別ライセンスを読むこと。
次に使用するフォントファイルのサイズを把握する。日本語フォントは1ファイルあたり3〜10MBになることが多く、複数ウェイトを同梱するとZIPが30MBを超える場合もある。メール添付の上限を超えるようであれば、サブセット化ツール（例：PyftsubsetやGlyphhanger）で必要な文字だけ抽出してからパッケージングする。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
実際の手順
HTMLファイルと同じ階層に「fonts/」フォルダを作り、woff2形式のフォントファイルをまとめる。CSS内の@font-face宣言は相対パス（src: url('fonts/NotoSans.woff2')）で記述し、絶対パスやCDNリンクは使わない。ZIPに圧縮する前にHTMLをローカルのブラウザで開いて文字が正しく描画されることを目視確認する。
ZIPを相手に送る際は、展開後のフォルダ構造をテキストで補足しておくと親切だ。「解凍後はindex.htmlをダブルクリックで開いてください」「フォントフォルダを移動すると表示が崩れます」という一文を添えるだけで問い合わせが激減する。ギガサイト便のようなプレビューURLサービスを使えば、ZIPをアップロードするだけで相手はURLをクリックするだけでよくなるため手間を大幅に削減できる。
失敗しやすい点
最も多いミスは「フォントパスがOSの絶対パスになっている」ケース。Macで制作したHTMLが「/Users/tanaka/Desktop/fonts/...」という形で参照していると、相手のWindowsでは当然開けない。納品前にテキストエディタでHTMLを開き、srcやhref属性に絶対パスが残っていないか全文検索する習慣をつけよう。
もう一つの落とし穴は、フォントファイル名に全角文字やスペースが含まれているケース。Mac上では問題なく動いても、WindowsのエクスプローラーやLinux環境でZIPを展開すると文字化けしてパスが一致しなくなることがある。フォントファイルはアルファベット・数字・ハイフン・アンダースコアだけのファイル名にリネームしてから同梱するとよい。
テンプレ文面
「添付のZIPを解凍し、中にあるindex.htmlをブラウザで直接開いてください。フォントは同梱済みのため追加インストールは不要です。表示確認後、問題があれば〇月〇日までにご連絡ください。修正版は同じURLで差し替えますので、再送は不要です。」
レビュー用URLを発行した場合は「下記URLにアクセスしてください（有効期限：〇月〇日）。社内ドメイン認証を設定しているため、会社のメールアドレスでログインをお願いします。URLを社外に転送しないようご注意ください。」という文面で送ると、アクセス制御の意図が相手に伝わりやすい。
よくある質問
woff2以外のフォント形式（ttfやotf）を同梱しても問題ありませんか？
モダンブラウザはwoff2に対応しているため、woff2のみで十分です。ttfやotfは容量が大きいうえ、IE11など旧環境への対応が必要な場合を除いて同梱のメリットはほとんどありません。
フォントをサブセット化すると、後から追加した文字が表示されないことはありますか？
あります。サブセット化は指定した文字コードだけを残すため、原稿確定後に文字が追加された場合はサブセット化をやり直す必要があります。校了前の段階ではフルセットのフォントを使い、最終納品時にサブセット化するのが安全です。
プレビューURLサービスにフォントを含むZIPをアップロードした場合、フォントデータは第三者に見られますか？
パスワードや会社ドメイン認証を設定していれば、認証を通過したユーザーのみアクセスできます。ただしフォントのライセンスによっては第三者サーバーへのアップロード自体が禁止されている場合があるため、ライセンス条項を事前に確認してください。