投稿する
マガジン
著者：アソバース編集部公開：更新：約10分で読めます

ゲームの単位・日付・数字の表記を国ごとに変える

遊びを届ける

執筆にClaudeを使用しています。

色鉛筆の線やゲームのスケッチが描かれたノートとカード。
記事のテーマをもとに制作したAI生成イメージ。実際のゲーム画面ではありません。

ゲームを海外向けに出すとき、テキストを翻訳しただけで「ローカライズ完了」とみなしてしまうケースがあります。しかし英語圏のプレイヤーが「1,234.56 km」と読む数字を、ドイツ語圏では「1.234,56 km」と書きます。日本で「2026年10月20日」と表示する日付は、米国向けなら「10/20/2026」、英国向けなら「20/10/2026」が自然です。単位・日付・数字は文章とは独立して処理が必要な「書式の問題」であり、翻訳とは別の作業として設計段階から考えておく必要があります。 この記事では、ブラウザゲームで実装しやすい範囲で、国・地域ごとの書式の違いを整理し、JavaScriptの標準APIを使った対応手順を説明します。「どの書式に対応するか」の判断基準と、実装でつまずきやすい点もあわせて示します。

この記事の目次
  1. なぜ書式だけ別に考えるのか
  2. 国・地域ごとに異なる主な書式
  3. JavaScriptの `Intl` APIで書式変換を実装する
  4. どの地域に対応するかを決める判断基準
  5. 実装でつまずきやすい点
  6. 次の行動
  7. 参考資料

なぜ書式だけ別に考えるのか

翻訳と書式の違いを混同すると、翻訳ファイルに「10/20/2026」という日付文字列をそのまま埋め込んでしまいます。すると日付の形式を変えたいときに翻訳ファイル全体を修正しなければならず、メンテナンスコストが跳ね上がります。

正しい設計は、ゲーム内で数値・日付・単位を「値」として保持し、表示する直前に「書式変換」を挟む構造です。この変換層を一か所に集めておけば、対応ロケールを増やすときも変換関数を追加するだけで済みます。翻訳ファイルには文字列テンプレートだけを置き、動的な数値や日付は変換後に埋め込む、という分業です。

国・地域ごとに異なる主な書式

まず押さえておくべき差異を三つの軸で整理します。

数字の区切り文字と小数点

日本・米国では桁区切りにカンマ、小数点にピリオドを使います（例：1,234.56）。ドイツ・フランス・スペインなどヨーロッパの多くの国では逆で、桁区切りにピリオド、小数点にカンマを使います（例：1.234,56）。スイスはスペースで桁区切りを行う場合もあります。ゲーム内にスコアや距離など数値を表示する場面がある限り、この違いは必ず影響します。

日付の順序と区切り

年・月・日の並び順は三通りあります。日本・中国・韓国は「年-月-日」（大→小の順）。米国は「月/日/年」。欧州の多くの国は「日/月/年」または「日.月.年」。同じ「04/05/2026」という文字列が、米国では4月5日、英国では5月4日を指します。文字列で日付を保存・表示している場合、ロケール変換なしに別の地域へ出すと誤読を招きます。

長さ・重さ・温度などの単位

メートル法とヤード・ポンド法の違いが最も影響します。米国はマイル・フィート・インチ・ポンド・華氏を日常的に使います。英国はメートル法と旧来の帝国単位が混在しており、道路標識はマイル、体重はストーン単位が使われることもあります。ゲームの中にキャラクターの移動距離・身長・体重・気温が表示される場合、対象地域がどの単位系を期待するかを事前に決めておく必要があります。

JavaScriptの `Intl` APIで書式変換を実装する

ブラウザゲームであればJavaScriptの組み込みオブジェクト Intl（Internationalization API）を使うのが最も現実的です。外部ライブラリを追加しなくても、数字・日付・単位の書式変換を一通りカバーできます。

数字の書式変換

js
const score = 1234567.89;

// 日本・米国（en-US）向け
new Intl.NumberFormat('ja-JP').format(score);  // → 1,234,567.89
new Intl.NumberFormat('en-US').format(score);  // → 1,234,567.89

// ドイツ（de-DE）向け
new Intl.NumberFormat('de-DE').format(score);  // → 1.234.567,89

ロケール文字列（'ja-JP'、'en-US'、'de-DE' など）を変数として外部から渡せる設計にしておけば、書式変換のロジック自体は共通のまま使えます。

日付の書式変換

js
const date = new Date(2026, 9, 20); // 2026年10月20日

new Intl.DateTimeFormat('ja-JP').format(date);  // → 2026/10/20
new Intl.DateTimeFormat('en-US').format(date);  // → 10/20/2026
new Intl.DateTimeFormat('en-GB').format(date);  // → 20/10/2026
new Intl.DateTimeFormat('de-DE').format(date);  // → 20.10.2026

options 引数を使うと「月を英語の短縮名で表示する」「時刻も含める」などの細かい制御もできます。ゲームのリザルト画面などに日付が出る場合は、サーバーから日付を Date オブジェクトや ISO 8601 形式（2026-10-20）で受け取り、表示直前にこの変換を通す設計が堅牢です。

単位の変換

Intl.NumberFormat の style: 'unit' オプションを使うと、単位付き数値をロケールに合わせた形式で表示できます。

js
const distanceKm = 5.3;

// メートル法ロケール向け（キロメートル表示）
new Intl.NumberFormat('ja-JP', { style: 'unit', unit: 'kilometer' })
  .format(distanceKm); // → 5.3 km

// 英語（英国）
new Intl.NumberFormat('en-GB', { style: 'unit', unit: 'kilometer' })
  .format(distanceKm); // → 5.3 km

ただし style: 'unit' は単位の「表記」を変えるだけで、値の変換（km → マイル）は自動では行いません。米国向けにマイル表示したい場合は、値を distanceKm * 0.621371 で変換してから unit: 'mile' を渡す処理を書く必要があります。表記と変換を混同しないように注意してください。

どの地域に対応するかを決める判断基準

すべての書式差異に最初から対応しようとすると実装コストが膨らみます。次の順番で判断すると現実的です。

  1. まず優先ロケールを一つか二つ決める。 日本語と英語（米国）から始めれば多くのプレイヤーをカバーできます。英国・オーストラリアを含めるなら en-GB を追加します。
  2. 数字と日付は必ず対応する。 変換コストが低く、誤読リスクが高いためです。Intl APIを使えば実装は数行で済みます。
  3. 単位は題材に依存する。 ゲーム内容がファンタジーや抽象的なパズルで距離・重さ・温度を出さないなら対応不要です。リアル系のスポーツや地理ゲームなら対応する価値があります。
  4. 通貨は数字の書式より優先度を上げる。 購入画面・課金要素がある場合、通貨記号と桁区切りの誤りはユーザーの信頼を直接損ないます。

実装でつまずきやすい点

ロケール文字列の管理を一元化する。 ゲームコード中の複数箇所に 'en-US' と直書きすると、ロケール切り替えのときに変更漏れが起きます。const LOCALE = 'en-US'; のようにゲーム起動時に一か所で設定し、書式変換関数にはそれを渡す設計にしてください。

ブラウザの navigator.language を参考情報として使う。 ユーザーが明示的にロケールを選んでいない場合、navigator.language がブラウザの言語設定を返します。ただしこれは参考値であり、「ブラウザが日本語設定でも英語コンテンツを楽しみたい」ユーザーもいます。初回起動時にロケール確認ダイアログを出す、または設定画面で変更できるようにするのが丁寧な対応です。

Intl APIの対応状況はブラウザバージョンに依存する。 style: 'unit' オプションは比較的新しく、古いブラウザ環境では動作しない場合があります。対象とするブラウザの範囲を決めたうえで、MDN Web Docs などで各機能の互換性を確認してから採用してください。

日付の「人間が読む表示」と「保存・送受信用の書式」を混ぜない。 データベースやURLパラメータで日付を扱う場合は ISO 8601（2026-10-20）で統一し、画面表示だけ Intl.DateTimeFormat を通すルールを徹底することで、ロケールに関係なく内部処理が壊れません。

次の行動

自分のゲームに数値・日付・単位が表示される箇所をリストアップし、それぞれが「値を持つ変数」から生成されているか、「文字列の直書き」になっているかを確認するところから始めてください。直書きになっている箇所を Intl API を通じた変換に置き換えることで、追加ロケールの対応コストを大幅に下げられます。作ったゲームはアソバースにZIPまたはHTMLファイルで投稿し、多言語対応の実装を実際のプレイで検証してみてください。

参考資料

  • MDN Web Docs — Intl（JavaScript 国際化 API）
  • MDN Web Docs — Intl.NumberFormat
  • MDN Web Docs — Intl.DateTimeFormat
  • Unicode CLDR（Common Locale Data Repository）
マガジン一覧に戻る