ゲームのフォントを多言語で揃える
遊びを届ける執筆にClaudeを使用しています。
ゲームを多言語対応させるとき、真っ先に詰まるのがフォントです。日本語UIは問題なく表示されていたのに、英語・中国語・韓国語を追加したとたんに文字化けや豆腐（□）が出る——これはほぼすべての開発者が一度は経験する壁です。 原因はシンプルです。フォントファイルは「収録しているコードポイント（文字の番号）の集合」であり、そのフォントに含まれない文字は表示できません。日本語フォントは平仮名・カタカナ・常用漢字をカバーしていますが、ハングルやアラビア文字は含まないことがほとんどです。多言語対応では「どの言語のどの文字をどのフォントで表示するか」を設計することが、翻訳テキストを用意するのと同じくらい重要な作業になります。 この記事では、Webブラウザゲームを前提に、フォント選定の判断基準・実装パターン・見落としやすい落とし穴を順に整理します。
どのフォントが多言語に使えるか
多言語対応フォントには大きく三つの選択肢があります。
パンユニコードフォント（Noto フォントファミリーなど）は、Google が主導して開発した「豆腐をなくす（No Tofu）」を目標にしたファミリーです。ラテン文字・日本語・中国語（簡体・繁体）・韓国語・アラビア語・ヒンディー語など、100以上のスクリプトに対応した個別フォントが無料で公開されています。一つのファイルにすべてを詰め込んだわけではなく、言語ごとのサブセットファイルに分かれているため、必要な言語だけ選んで読み込めます。ライセンスは SIL Open Font License（OFL）で、商用ゲームへの組み込みも可能ですが、公式ライセンス文書を必ず確認してください。
CJK 特化フォントは、中国語・日本語・韓国語（CJK）を高品質に扱いたいときの選択肢です。源ノ角ゴシック（Source Han Sans）や源ノ明朝（Source Han Serif）は Adobe と Google が共同開発しており、日中韓で統一された字形を持ちます。ゲームのUIに使うと、どの言語に切り替えてもデザインの印象が崩れにくい利点があります。ただしフルセットはファイルサイズが非常に大きいため、後述するサブセット化が前提になります。
システムフォントへのフォールバックは「そのOSや端末に入っているフォントに任せる」方法です。開発コストは最小ですが、Android・iOS・Windows・macOS でそれぞれ字形や太さが変わり、デザインの一貫性を保てません。フォントの見た目がゲームのブランドに直結する場合は避けたほうが無難です。
font-face と unicode-range で言語を切り替える
Webブラウザゲームでは CSS の @font-face と unicode-range 記述子を組み合わせる方法が標準的です。仕組みは次のとおりです。
- 言語ごとのフォントファイル（woff2 形式を推奨）を用意する。
- それぞれに @font-face ブロックを書き、unicode-range でそのフォントが担当するコードポイントの範囲を指定する。
- CSS の font-family に同じファミリー名を並べて指定する。
ブラウザはテキストをレンダリングするとき、文字ごとに「この font-family の中でこのコードポイントをカバーするフォントはどれか」を照合し、該当するフォントファイルだけを遅延ダウンロードします。つまり、韓国語テキストが画面に登場しない限り韓国語フォントはダウンロードされない、という効率的な動作になります。
unicode-range の値は公式の Unicode ブロック一覧から確認できます。代表的な範囲を挙げると、ラテン文字拡張は U+0000-00FF 付近、ひらがな・カタカナは U+3040-30FF、CJK統合漢字は U+4E00-9FFF、ハングルは U+AC00-D7AF といった区画に収まっています。Noto フォントの各サブセットのドキュメントには推奨 unicode-range 値が記載されているので、それをそのまま流用するのが最も確実です。
サブセット化でファイルサイズを制御する
Noto Sans JP のフルセットは数MBあり、ゲームのロード時間に直接影響します。表示する文字が事前に確定しているゲームでは、使う文字だけを抜き出した「サブセットフォント」を生成すると大幅に削減できます。
pyftsubset（fonttools に含まれるコマンドラインツール）や、Webブラウザで動くGUIツールを使うと、テキストファイルや文字リストを渡すだけでサブセットを生成できます。手順の概要は次のとおりです。
- ゲーム内で使うすべての文字列（UIラベル・ダイアログ・システムメッセージなど）を言語ごとに洗い出してテキストファイルに保存する。
- pyftsubset にフォントファイルとテキストファイルを渡してサブセットを出力する。
- 出力を woff2 形式に変換してゲームに組み込む。
注意点が二つあります。一つは、動的に生成されるテキスト（プレイヤー名の入力欄など）はすべての文字を含められないため、その部分はシステムフォントへのフォールバックを許容するか、入力できる文字を制限するかを設計段階で決める必要があります。もう一つは、翻訳の追加・修正のたびにサブセットを再生成する手間が生じる点です。更新頻度が高いゲームでは、フルセットをそのまま使い帯域を諦めるか、サブセット生成をビルドパイプラインに自動化するかの判断が必要です。
よくある失敗と回避策
縦書き・ルビ・合字の扱いは見落とされがちです。日本語フォントが縦書きグリフを持っていても、CSSで writing-mode: vertical-rl を指定しなければ縦書きになりません。また、同じ漢字でも日本語・中国語・韓国語では字形が異なる「漢字統合」問題があります。たとえば「辺」の字は日本語と中国語で微妙に形が違います。lang 属性（<span lang="zh"> のように）を HTML に正しく付与すると、フォントが対応している場合に言語ごとの字形を使い分けられます。多言語の読者にとって「なんとなく変な字形」は細かいことのようで印象を損ねます。
行の高さと文字送りも問題になります。アラビア語・ヒンディー語・タイ語はラテン文字より上下の余白が大きいフォントが多く、日本語UIをそのまま流用すると行が重なったりボタンからテキストがはみ出したりします。多言語対応では line-height と padding を言語ごとに調整できる構造にしておくと後が楽です。
右から左へ書く言語（RTL）——アラビア語・ヘブライ語——は、文字の向きだけでなくUIのレイアウト全体を左右反転させる必要があります。CSS の direction: rtl と text-align: right は文字レベルの制御ですが、ボタンの並び順やアイコンの位置など視覚的な整合性はCSSだけでは解決しません。RTL対応を最初から設計に織り込むかどうかはターゲット市場に応じて判断してください。
フォントのライセンス確認は絵や音楽と同様に必須です。「無料で使える」と書かれていても、商用利用・再配布・フォント自体の改変（サブセット化は改変にあたる場合があります）について条件が異なります。OFL は改変・再配布に対して比較的寛容ですが、詳細は公式ライセンス文書を参照してください。
次の行動
まず対応する言語リストを確定させ、それぞれの言語に必要な Unicode ブロックを調べることから始めてください。Noto フォントの GitHub リポジトリと fonttools の公式ドキュメントを参照しながら、最小構成のサブセットを一つ作って実際にブラウザで表示を確認するのが最短の検証方法です。作ったゲームをアソバースに投稿する場合は、フォントファイルをZIPにまとめてHTMLと一緒にアップロードする形で多言語版を公開できます。
参考資料
- Google Fonts / Noto フォントファミリー 公式ドキュメント
- Unicode コンソーシアム 公式サイト（Unicode ブロック一覧）
- fonttools / pyftsubset 公式ドキュメント
- SIL Open Font License（OFL）公式テキスト
- W3C CSS Fonts Module Level 4 仕様（unicode-range 記述子）
