新規登録
ファイル形式・標準規格Read this article in English

Unicode CLDR とは何か — 書式コードが読むべきロケールデータ

日付を表示する処理には、翻訳とはまったく関係のない疑問がいくつも付きまといます。日・月・年はどの順番で並ぶのか、区切り文字は何か、そもそも年を主要な単位として表示するのか。これらは事実ではなく慣習であり、言語とは独立にロケールごとに異なります。CLDR(Unicode Common Locale Data Repository)は、その答えが存在する場所です。Unicode プロジェクトの一部として保守されている、ロケールごとの慣習を構造化しバージョン管理したデータセットです。

この記事では、CLDR が実際に何を含んでいるか、なぜ書式化 API がそれを自前で再実装せずこのデータの上に構築されているのか、そしてロケールデータを静的なものとして扱うことがなぜ誤りなのかを見ていきます。

CLDR が提供するもの

CLDR は単一のものではなく、ロケール固有の慣習のそれぞれ異なる側面をカバーする、関連するデータセットの集まりです。

  • 複数形ルール — ある数値が言語ごとにどの CLDR 複数形カテゴリ(one・few・many・other など)に対応するか。ICU MessageFormat の plural 引数を支えるデータ
  • 日付・時刻のパターン — フィールドの順序、区切り文字、使用されている暦法、そのロケールが月名・曜日名を略すか綴るか
  • 数値のパターン — 小数点・桁区切りの記号、通貨記号の位置、パーセント表記、数字の字形
  • 照合順序(コレーション) — ロケール固有のソート順。同じ文字体系を共有する言語同士でも、アルファベット順は普遍的なものではない
  • 表示名 — 言語・文字体系・地域・通貨の名前を、それ自体をローカライズした形でどう表示するか(例: 日本語で「フランス語」がどう呼ばれるか)

例 — 同じ日付を CLDR データから書式化する

以下のロジックには、ロケールごとにハードコードされた部分は何もありません。パターン、区切り文字、月名はすべてロケールをキーとするデータから来ており、同じ関数呼び出しが、個別にコーディングされたことのないロケールに対しても正しい出力を生成します。

const d = new Date("2026-08-15");

new Intl.DateTimeFormat("en-US").format(d); // 8/15/2026
new Intl.DateTimeFormat("ja-JP").format(d); // 2026/8/15
new Intl.DateTimeFormat("de-DE").format(d); // 15.8.2026

書式化 API がアプリごとに再実装されず CLDR を土台にしている理由

標準ライブラリやプラットフォームの書式化 API — JavaScript の Intl や、他のランタイムにおける同等のロケール API — は、実質的には CLDR データのフロントエンドです。API 表面は関数呼び出しですが、「ドイツ語は日付をどう書式化するか」という実際の知識は、API の実装自体ではなく CLDR の側にあります。

この役割分担があるからこそ、アプリケーションは、ある1つのロケールで観察した書式化の慣習をハードコードして、それが一般化できると仮定してはいけません。「通貨記号は数値の前に置く」は多くのロケールで正しい一方、それ以外のロケールでは誤りです。すべてのロケールで正しくあるための唯一の方法は、仮定をコードに埋め込むのではなく、ロケールデータに問い合わせることです。

アプリはロケールデータを読むべきで、慣習をハードコードすべきでない

これが防いでいる実際の失敗のパターンは、地味ですが根深いものです。開発者が自分自身のロケールで書式化をテストし、見た目が正しかったので、そこで観察した慣習(固定の日付区切り文字、小数点はカンマかピリオドかという思い込み、通貨記号は常に左に置くといった前提)がそのままハードコードされてしまう。これらはどれも普遍的ではなく、開発者がテストしていなかったロケールにアプリが実際に到達した瞬間、静かに壊れます。

ハードコードする代わりに CLDR に基づく API から読み取ることで、書式化の正しさは、開発者が個人的にテストしたロケールの数ではなく、CLDR がカバーしている範囲の広さに応じてスケールするようになります。

ロケールデータは変化するし、それは想定内である

CLDR はバージョン管理されており、定期的なサイクルで更新されます。ある言語の使われ方がより詳しく文書化されるにつれて複数形ルールが精緻化されたり、通貨自体が変わって通貨記号が変わったり、新しい地域・文字体系の組み合わせが追加されたりします。これはバグという意味での不安定さではなく、データセットが、それが記述している現実世界の変化に合わせて正確であり続けているということです。

実務上の含意は、書式化の出力が CLDR のバージョンをまたいでバイト単位で完全に安定しているとは保証されない、ということです。書式化の正しさそのものではなく、特定の書式化された文字列に依存するコードは、その文字列が永続すると仮定すべきではありません。ロケールに基づく書式化は、永久に凍結されることではなく、今この瞬間に正しいことを最適化しています。

関連記事