Intlによる国際化フォーマットの内部（CLDRとロケール解決)

なぜ「同じコードで表示が変わる」のか

new Intl.NumberFormat("de-DE").format(1234.5) が 1.234,5 を返し、ブラウザやNode.jsのバージョンを変えると並べ替え順や日付の表記が微妙に変わる——これらは個別のバグではなく、Intlの出力がコードではなくロケールデータに由来するという設計から導かれる必然です。Intl（ECMAScript国際化API, ECMA-402）は自前で規則を持たず、ランタイムが同梱するCLDRというデータベースを参照します。原理を押さえれば、どの出力が環境依存でどこを固定すべきかを推測でなく仕組みから判断できます。前提として基礎は JavaScript を押さえておくと、ここでの内部動作がつながります。

ロケールタグはBCP47で正規化される

Intlに渡すロケール文字列はBCP47言語タグとして解釈されます。タグはハイフン区切りのサブタグ列で、おおむね次の構造です。

各APIはまず受け取ったタグを正規化します。大文字小文字を正規形（言語は小文字、スクリプトは先頭大文字、地域は大文字）に直し、u拡張のキーをアルファベット順に並べ替え、zh-yue のような非推奨タグを正規の yue へ写像します。zh-Hans-CN-u-nu-hanidec のようにスクリプト・地域・拡張を一括指定でき、-u- 以降のUnicode拡張で数字体系（nu）・暦（ca）・照合（co）などをロケール単位で要求できます。

ロケール解決：要求と利用可能の突き合わせ

正規化したタグが、そのランタイムで実際に使えるかは別問題です。各コンストラクタは要求リストとランタイムの利用可能ロケール集合（CLDRが同梱する範囲）を突き合わせ、使うロケールを1つ決めます。この手続きが ResolveLocale で、既定のマッチングは**lookup（言語ネゴシエーション）**です。

要求: "de-AT-u-co-phonebk"
1. 完全一致を探す → 無ければ
2. 末尾サブタグを削って再試行: "de-AT" → "de"
3. ヒットした最長の接頭辞を採用（ここでは "de"）
4. u拡張(co=phonebk)はサポートされていれば引き継ぐ

末尾から段階的にサブタグを削って最長一致を探すため、de-AT 未収録でも de にフォールバックします。複数候補を配列で渡すと先頭から順に評価し、最初に解決できたものを採用します。最終的に何が選ばれたかは resolvedOptions().locale で確認できます。

出力規則の出所はCLDR

桁区切り文字、小数点記号、通貨記号の位置、月名、並べ替え順——これらの規則そのものはV8やJavaScriptCoreの実装ではなく、Unicodeコンソーシアムが整備する CLDR（Common Locale Data Repository） に由来します。Intlは「規則を解釈するエンジン」、CLDRは「規則データ」という分担です。

この分担の重要な帰結は、同じコードでも実行環境で出力が変わり得ることです。ランタイムが同梱するCLDRのバージョンが上がると、新しい通貨記号や改訂された並べ替え規則が反映されます。

Collator：文字列を重み列へ写像して比較

Intl.Collator は文字列を文字コード順ではなく言語的に正しい順で比較します。原理はUnicode照合アルゴリズム（UCA）で、各文字を**多段の照合要素（重み）**へ写像し、段ごとに比較します。

• 第1段（primary）：基底文字の違い（a と b）。最も強い差。
• 第2段（secondary）：アクセント差（a と á）。
• 第3段（tertiary）：大文字小文字差（a と A）。

まず全文字列を第1段の重みだけで比較し、同点なら第2段、さらに同点なら第3段へ進みます。これにより「アクセントや大小は無視して並べたい」を sensitivity で制御できます。基準表はDUCET（既定の照合要素表）で、各ロケールはそこへ**tailoring（差分）**を当てます。たとえばドイツ語電話帳順（-u-co-phonebk）はウムラウトを特別扱いします。

const c = new Intl.Collator("de", { sensitivity: "base" });
c.compare("ä", "a");        // 0 （base感度：アクセント差を無視＝同等）
["z", "ä", "a"].sort(new Intl.Collator("de").compare); // 言語規則で並ぶ
"ä" < "a";                  // false …だがコード順比較は言語的に誤り

素朴な < はコード単位の数値比較（テキストエンコーディングの内部（UTF-16のサロゲートとコードポイント） 参照）で、ä（U+00E4）が a（U+0061）より大きいと判定するなど言語的に破綻します。ユーザー向けの並べ替えは必ず Collator を使います。

Segmenter：境界をUnicode規則で決める

Intl.Segmenter は文字列を書記素・単語・文の単位に分割します。境界の位置はUnicodeのテキスト分割規則（UAX #29 など）に従い、ロケールによって異なります。

const seg = new Intl.Segmenter("ja", { granularity: "word" });
[...seg.segment("東京都に住む")].map(s => s.segment);
// 日本語は空白で区切られないため、規則・辞書ベースで語に分割される

書記素分割は結合文字や絵文字のZWJ連結を1単位にまとめ、単語分割はタイ語・日本語のように空白で区切らない言語で辞書を要する場合があります。segment() が返す各セグメントには isWordLike などの付随情報が付き、単語と区切り記号を区別できます。「見た目の1文字数」や「カーソル移動の単位」はここが基準です。

表示の折りたたみ：formatToPartsで構造を取る

format() は最終的な1本の文字列を返しますが、その内部では部品（パート）の列が組み立てられ、最後に連結（折りたたみ）されます。formatToParts() はこの折りたたみ前の構造を露出します。

new Intl.NumberFormat("de-DE", { style: "currency", currency: "EUR" })
  .formatToParts(1234.5);
// [{type:"integer",value:"1"},{type:"group",value:"."},
//  {type:"integer",value:"234"},{type:"decimal",value:","},
//  {type:"fraction",value:"50"},      // 通貨は小数2桁に丸めるため "5" でなく "50"
//  {type:"literal",value:" "},   // この空白は実は NBSP（U+00A0）
//  {type:"currency",value:"€"}]

type で各部品の役割（integer/group/decimal/currency など）が分かるため、通貨記号だけ色を変える、グループ区切りの実体を検査するといった処理が、文字列を正規表現で割らずに安全に行えます。前述のNBSP問題も、literal パートの中身を見れば確実に判別できます。

実務での落とし穴と対策

帰結を実務に落とすと、危険なのはIntl出力を環境非依存だと仮定することです。

• インスタンスは使い回す：NumberFormat/DateTimeFormat の生成はCLDRデータの読み込みを伴い重い。ループ内で毎回 new せず、ロケール・オプション単位でキャッシュする。
• グループ区切りの実体に注意：多くのロケールで区切りはNBSP系の不可視空白。CSVや数値パースに渡す前に formatToParts() で実体を確認するか、機械処理用には Intl を使わない。
• 暦・数字体系の取りこぼし：ar-SA は既定でヒジュラ暦・アラビア数字になり得る。固定の表記が必要なら -u-ca-gregory-nu-latn のように明示する。
• 比較・重複判定は正規化と併用：Collator の前提として、見た目が同じ文字列はNFCで正規化しておく（数値の表現差については JavaScriptの数値表現とIEEE754 も同じ「内部表現の帰結」という観点でつながります）。

まとめ