# General Translation Knowledge Base: en-US や en-GB などのロケールコードとは？
URL: https://generaltranslation.com/ja/kb/locale-codes.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: ロケールコードは言語を識別するコードで、必要に応じて文字体系やリージョンも示します。たとえば en-US は米国で使われる英語、zh-Hant-TW は台湾で使われる繁体字中国語を表します。ほとんどのソフトウェアは、ISO コードを組み合わせた BCP 47 タグを使用しています。General Translation は、gt.config.json で指定する翻訳元ロケールとターゲットロケールに BCP 47 コードを使用します。
Category: ロケール別フォーマット
Last updated: 2026-10-28
Authors: General Translation Team
Published: 2026-10-28

ロケールコードは言語を表すもので、必要に応じて、その言語の表記に使われる文字体系や、使用されるリージョンも示します。`en-US` は米国で使われる英語、`en-GB` は英国で使われる英語、`zh-Hant-TW` は台湾で使われる繁体字表記の中国語を表します。ブラウザ、HTTP、HTML、JavaScript の `Intl` API はいずれも、これらのコードに BCP 47 という共通の標準を採用しています。そのため、どのコードを選ぶかによって、ユーザーに表示される翻訳、日付の書式、複数形規則が決まります。

## BCP 47 タグの構成

[BCP 47](https://www.rfc-editor.org/info/bcp47) は、言語タグに関する IETF の標準です。構文を定義する [RFC 5646](https://www.rfc-editor.org/rfc/rfc5646.html) と、タグの照合方法を定義する [RFC 4647](https://www.rfc-editor.org/rfc/rfc4647.html) の 2 つで構成されています。タグはサブタグをハイフンでつないだもので、並び順は常に次のとおりです。

| サブタグ     | 形式                      | 由来                             | 例                              |
| -------- | ----------------------- | ------------------------------ | ------------------------------ |
| 言語 (必須)  | 2 文字または 3 文字            | ISO 639 (存在する最短のコード)           | `en`, `zh`, `gsw`              |
| 文字体系     | 4 文字                    | ISO 15924                      | `Hant`, `Hans`, `Latn`, `Cyrl` |
| リージョン    | 2 文字または 3 桁の数字          | ISO 3166-1 alpha-2、または UN M.49 | `GB`, `BR`, `419`              |
| バリアント    | 5～8 文字、または数字 1 桁 + 3 文字 | IANA に登録済み                     | `de-1901` (ドイツ語の旧正書法)          |
| 拡張       | 1 文字に続けてそのサブタグ          | `u` は Unicode が定義              | `ar-EG-u-nu-latn`              |
| 私用       | `x` に続けて独自のサブタグ         | 利用者自身                          | `en-CA-x-ca`                   |

有効なサブタグはすべて [IANA Language Subtag Registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry) に掲載されており、コードを調べるならここだけを見れば済みます。2026 年 9 月版には 8,276 の言語サブタグと 305 のリージョンサブタグが収録されており、廃止されたコードにはその代わりとなるコードが併記されています。

これらの要素を組み合わせることで、意図を正確に表せます。`sr-Latn-RS` は、セルビアで使われるラテン文字表記のセルビア語です。`es-419` は、ラテンアメリカおよびカリブ海地域で使われるスペイン語を表し、`419` は複数の国にまたがる地域を示す UN M.49 コードです。RFC 5646 には、さらに紛らわしい例も挙げられています。`de-CH` はスイスで使われるドイツ語 (スイス標準ドイツ語) を指しますが、スイスドイツ語 (Schweizerdeutsch) はそれとは別の言語であり、独自のコード `gsw-CH` が割り当てられています。

### 拡張で変わるのはフォーマットであり、言語ではない

`-u-` 拡張は [RFC 6067](https://www.rfc-editor.org/rfc/rfc6067.html) で定義されており、そのキーは [Unicode の LDML 仕様](https://unicode.org/reports/tr35/)に一覧があります。この拡張は、フォーマットに関する設定を表します。`-u-nu-` は記数法、`-u-hc-` は時間表記 (12時間制／24時間制) 、`-u-ca-` は暦法、`-u-co-` は並べ替え順序を指定します。`en-US-u-hc-h23` もアメリカ英語であることに変わりはなく、`2:05 PM` ではなく `14:05` と表示されるだけです。後述の例で両方の表示を確認できます。

## 大文字・小文字、ハイフン、アンダースコア

タグは大文字と小文字を区別しないため、`EN-gb` と `en-GB` は同じ意味になります。とはいえ、RFC 5646 では[表記の慣例が推奨されています](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1.1)。`zh-Hant-TW` のように、言語は小文字、文字体系は先頭のみ大文字、リージョンは大文字で表記します。コードをファイル名や URL に使用する前にこの形式に正規化し、`/en-gb/` と `/en-GB/` が別々のパスにならないようにしてください。

BCP 47 ではサブタグをハイフンで区切ります。独自の形式を採用しているプラットフォームもあるため、システム間の境界で変換してください。

| システム                                                                                               | 形式                                                         | 例                                 |
| -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | --------------------------------- |
| Web (HTML `lang`、`hreflang`、`Accept-Language`、`Intl`)                                              | ハイフン区切りの BCP 47                                            | `en-US`、`zh-Hant-TW`              |
| [POSIX](https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html) (`LANG`、`LC_*`)  | `language[_territory][.codeset][@modifier]`                | `en_US.UTF-8`                     |
| [Unicode CLDR](https://unicode.org/reports/tr35/) および ICU のロケール ID                                 | アンダースコア (ハイフンも使用可)                                         | `en_US`                           |
| [Java](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Locale.html)         | `toString()` はアンダースコア、`toLanguageTag()` は BCP 47 を返す       | `en_US`、`en-US`                   |
| [Android リソース](https://developer.android.com/guide/topics/resources/providing-resources)           | リージョンの前に `r` を付ける。BCP 47 タグの場合は `b+` を使用 (Android 7.0 以降)  | `values-en-rUS`、`values-b+es+419` |

JavaScript ではアンダースコア形式は使用できません。`Intl.getCanonicalLocales('en_US')` は `RangeError` 例外をスローします。

## よくある間違い

* **`en-GB` ではなく `en-UK` と書く。** 英国のISO地域コードは `GB` であり、`UK` はIANAレジストリに登録されていません。Unicode CLDRは `UK` をエイリアスとして扱うため、JavaScriptは `en-UK` を暗黙的に `en-GB` へ変換しますが、[Googleは](https://developers.google.com/search/docs/specialty/international/localized-versions) hreflangの `UK` を無視します。`en-GB` と書いてください。
* **言語の位置に国コードを入れる。** `jp`、`cn`、`gr`、`dk`、`cz` は言語コードではありません。日本語は `ja`、中国語は `zh`、ギリシャ語は `el`、デンマーク語は `da`、チェコ語は `cs` です。国コードの中には、まったく別の言語を表すものもあります。`se` は北サーミ語 (スウェーデン語は `sv`) 、`kr` はカヌリ語 (韓国語は `ko`) 、`uk` はウクライナ語、`be` はベラルーシ語です。`jp` は2文字なので構文チェックは通ってしまいます。パースできるからといって信用せず、コードは必ず調べて確認してください。
* **簡体字中国語のつもりで `zh-CN` を使う。** 中国語では文字体系によって表記そのものが変わり、リージョンは文字体系を暗に示すにすぎません。`zh-TW` は `zh-Hant-TW` に、`zh-SG` は `zh-Hans-SG` に展開されます。1つの簡体字翻訳で中国本土とシンガポールの両方をカバーする場合は `zh-Hans` とタグ付けしてください。繁体字には `zh-Hant` を使い、表現が異なる場合は `zh-Hant-HK` のようにリージョンを追加します。
* **廃止されたコード。** `iw` (ヘブライ語) 、`in` (インドネシア語) 、`ji` (イディッシュ語) は1989年に非推奨となり、`he`、`id`、`yi` に置き換えられました。バージョン17より前のJavaは古い形式を出力し続けていたため、古いデータには今でも見られます。正規化すれば新しいコードに置き換わります。
* **情報が過剰なタグ。** `en-Latn-US` は、英語ではほぼ常に使われる文字体系をわざわざ付け加えています。RFC 5646は、区別に役立たないサブタグは省略するよう[推奨しており](https://www.rfc-editor.org/rfc/rfc5646.html#section-4.1)、基本フィルタリングでは `en-US` のリクエストが `en-Latn-US` とタグ付けされたコンテンツに一致しないことにも触れています。
* **有効だが利用側がサポートしていないコード。** `es-419` は有効なBCP 47ですが、Googleのhreflangは ISO 3166-1 のリージョンしか受け付けないため、該当ページには `es` または個別の国を指定してください。 ([hreflangとは？](/kb/what-is-hreflang)を参照。)

## 汎用コードと地域コード：どちらを使うべきか

[言語タグの選び方](https://www.w3.org/International/questions/qa-choosing-language-tags)に関する W3C の推奨は、タグはできるだけ短くし、必要な情報を伝える場合にのみリージョンを付けるというものです。これをロケールごとのルールに落とし込むと、次のようになります。

* その言語を話すすべての地域で 1 つの翻訳を共有できる場合は、**言語コードのみを使用します** (`fr`、`de`、`ja`) 。
* 綴り、語彙、法的文書が異なり、翻訳を個別に管理する場合は、**リージョンを追加します**：`en-US` と `en-GB`、`pt-BR` と `pt-PT`、`es-MX` と `es-ES`、`fr-CA`。
* **中国語やセルビア語など、複数の文字体系を持つ言語では、まず文字体系を選びます**：`zh-Hans` と `zh-Hant`、`sr-Cyrl` と `sr-Latn`。
* **翻訳を共有する場合でも、フォーマットには地域コードを使用します。** `en` として一度だけ翻訳したテキストでも、訪問者の `en-GB` に合わせて日付をフォーマットできます。`en-US` では 10/28/2026 と表記される日付が、`en-GB` では 28/10/2026 になります。

言語コードのみのタグであっても、ソフトウェアから見てリージョンが存在しないわけではありません。CLDR の likely-subtags データが最も可能性の高い文字体系とリージョンを補うため、`pt` は `pt-Latn-BR` に、`zh` は `zh-Hans-CN` に展開されます。`pt` の翻訳がヨーロッパ・ポルトガル語なら、`pt-PT` とタグ付けしてください。

ユーザーのロケールがサポート対象外の場合、ソフトウェアはフォールバックを行います。RFC 4647 の [lookup](https://www.rfc-editor.org/rfc/rfc4647.html#section-3.4) は、一致するものが見つかるまで末尾からサブタグを順に削っていきます (`zh-Hant-HK` → `zh-Hant` → `zh`) 。他のマッチャーでは、同じ言語の別リージョンも候補として試します。ブラウザの言語設定の読み取り方や、これらのアルゴリズムの使い分けについては、[ユーザーのブラウザ言語を検出する方法](/kb/detect-user-language)で解説しています。

## JavaScript でコードを正規化する

[`Intl.getCanonicalLocales`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/getCanonicalLocales) は大文字・小文字を正しく整え、非推奨のサブタグやエイリアスのサブタグを置き換えます。また、[`Intl.Locale`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale) を使うと、最も可能性の高い文字体系とリージョンを補完できます。

```js title="locale-codes.mjs"
const names = new Intl.DisplayNames(['en'], { type: 'language' });

for (const tag of ['EN-gb', 'zh-tw', 'iw-IL', 'en-UK', 'jp', 'es-419', 'en_US']) {
  try {
    // 正規化: 大文字・小文字を修正し、非推奨のサブタグやエイリアスを置き換える
    const [canonical] = Intl.getCanonicalLocales(tag);
    // 推定される文字体系とリージョンを追加する
    const maximized = new Intl.Locale(canonical).maximize().toString();
    console.log(`${tag} -> ${canonical} (${maximized}): ${names.of(canonical)}`);
  } catch (error) {
    console.log(`${tag} -> ${error.name}: ${error.message}`);
  }
}

// -u- 拡張で変わるのはフォーマットであり、言語ではない
const time = new Date(Date.UTC(2026, 9, 28, 14, 5));
for (const tag of ['en-US', 'en-US-u-hc-h23', 'ar-EG', 'ar-EG-u-nu-latn']) {
  const formatted = new Intl.DateTimeFormat(tag, {
    hour: 'numeric',
    minute: '2-digit',
    timeZone: 'UTC',
  }).format(time);
  console.log(`${tag}: ${formatted}`);
}
```

Node.js 24.19.0 で `node locale-codes.mjs` を実行した際の出力:

```text title="Output"
EN-gb -> en-GB (en-Latn-GB): British English
zh-tw -> zh-TW (zh-Hant-TW): Chinese (Taiwan)
iw-IL -> he-IL (he-Hebr-IL): Hebrew (Israel)
en-UK -> en-GB (en-Latn-GB): British English
jp -> jp (jp): jp
es-419 -> es-419 (es-Latn-419): Latin American Spanish
en_US -> RangeError: Incorrect locale information provided
en-US: 2:05 PM
en-US-u-hc-h23: 14:05
ar-EG: ٢:٠٥ م
ar-EG-u-nu-latn: 2:05 م
```

特に注目したい行が2つあります。`jp` は正規化を通過しますが、表示名は返されません。このチェックは構文の妥当性を確認するだけで、その言語が実在するかどうかは判定しないためです。また、`ar-EG-u-nu-latn` では、テキストはアラビア語のまま、数字だけが西洋式 (アラビア数字) に切り替わります。

## General Translation におけるロケールコードの使い方

General Translation では、一貫して BCP 47 コードを使用します。`gt.config.json` では、[`defaultLocale`](/docs/cli/reference/config#default-locale) にソースコンテンツの記述言語となるロケール (デフォルトは `en`) を指定し、[`locales`](/docs/cli/reference/config#locales) に翻訳先のロケールを列挙します。

```json title="gt.config.json"
{
  "defaultLocale": "en-US",
  "locales": ["en-GB", "fr-CA", "pt-BR", "zh-Hant"]
}
```

CLI は、翻訳を開始する前にこれらのコードをチェックします。無効なコードがある場合や、`defaultLocale` がターゲットより広い範囲を指している場合は処理を停止します。たとえば `en` から `en-GB` への翻訳は失敗するため、イギリス英語を追加するプロジェクトでは、前述のとおり翻訳元を `en-US` に設定します。

プラットフォームは、[対応ロケール](/docs/platform/dashboard/reference/supported-locales)一覧にあるロケールへの翻訳に対応しています。General Translation は通常、同等のコードを 1 つのロケールとして扱います。たとえば `fr`、`fr-FR`、`fr-Latn-FR` には同じ翻訳が適用され、`ja` と `ja-JP` は同じ保存済み翻訳を更新します ([ロケールコードについて](/docs/platform/core/guides/locale-codes)を参照) 。

URL で `cn` のように登録済みの言語ではないコードを使いたい場合は、General Translation の [`customMapping`](/docs/cli/reference/config#custom-mapping) を使って、そのコードを標準コードのエイリアスとして設定できます (`cn` を `zh` に対応付けるなど) 。表示名を上書きすることも可能です。hreflang については、[ロケールエイリアスの SEO ガイド](/docs/react/nextjs/locale-alias-seo)の方法で、エイリアスを `zh` にマッピングし直します。

`generaltranslation` Core ライブラリは、ロケールヘルパーを APIキー不要のスタンドアロン関数としてエクスポートしています。以下の戻り値は `generaltranslation` 9.5.8 での結果です。

```js title="check-locales.mjs"
import {
  standardizeLocale,
  isValidLocale,
  getLocaleName,
  determineLocale,
} from 'generaltranslation';

standardizeLocale('EN-gb'); // 'en-GB'
isValidLocale('en_US'); // false
isValidLocale('jp'); // false
getLocaleName('pt-BR', 'en'); // 'Brazilian Portuguese'
determineLocale(['fr-CA', 'en-US'], ['en', 'fr', 'zh-Hant']); // 'fr'
```

[`standardizeLocale`](/docs/platform/core/reference/utility-functions/locales/standardize-locale) は大文字・小文字を正規化し、[`isValidLocale`](/docs/platform/core/reference/utility-functions/locales/is-valid-locale) はアンダースコア区切りの形式や、`Intl` では通ってしまう `jp` のようなコードを無効と判定します。[`getLocaleName`](/docs/platform/core/reference/utility-functions/locales/get-locale-name) は言語選択に表示する表示名を返し、[`determineLocale`](/docs/platform/core/reference/utility-functions/locales/determine-locale) はユーザーの言語設定に最も合うサポート対象のロケールを選びます。この例では、カナダ・フランス語のユーザーに `fr` の翻訳を表示しています。

## よくある質問

### 言語コードとロケールコードの違いは何ですか？

言語コードは `en` や `pt` のような単一のサブタグです。一方、ロケールコードには `pt-BR` のように文字体系やリージョンを追加できるため、日付、数値、通貨のフォーマットも決まります。

### en-GB と en-UK のどちらが正しいですか？

`en-GB` です。`GB` は英国を表す ISO 3166-1 コードです。一方、`UK` は登録されたリージョンサブタグではないため、Google は hreflang でこれを無視します。

### zh-CN と zh-Hans のどちらを使うべきですか？

複数のリージョンで使われる簡体字中国語のテキストには `zh-Hans` を使用し、`zh-CN` は中国本土向けのコンテンツに限って使用してください。どちらも簡体字の文字体系に解決されます。

### ロケールコードは大文字と小文字を区別しますか？

いいえ。`en-us` と `en-US` は同じタグとして扱われます。ただし、ファイル名、URL、キーの表記を統一するため、`en-US` と記述してください。

## 要点

* BCP 47 のロケールコードは、言語サブタグの後に、任意で文字体系、リージョン、バリアント、拡張の各サブタグをこの順にハイフンでつないだものです (例：`zh-Hant-TW`、`es-419`、`en-US-u-hc-h23`) 。
* コードは IANA レジストリで確認してください。`en-UK` ではなく `en-GB`、`jp` ではなく `ja`、`iw` ではなく `he` が正しいコードです。
* タグはできるだけ短くし、リージョンはリージョンによって内容が異なる場合にのみ付けます。中国語の場合は、まず文字体系を決めてください。
* 変換はシステムの境界で行います。POSIX、ICU、Java の `toString()` はアンダースコアを使い、Android は `values-b+es+419` という形式を使います。
* General Translation は `gt.config.json` の `defaultLocale` と `locales` から BCP 47 コードを読み取ります。ターゲットより範囲の広いソースロケールは受け付けず、エイリアスは `customMapping` で設定できます。

## Related questions

- [ユーザーのブラウザ言語を検出するには？](https://generaltranslation.com/ja/kb/detect-user-language.mdx): ブラウザが持つ優先順位付きの言語リスト（JavaScript では navigator.languages、サーバー側では q 値で並べ替えた Accept-Language ヘッダー）を読み取り、フォールバックを用意したうえで対応ロケールとマッチングします。なお、Safari や Chrome のシークレットモードでは 1 つの言語しか通知されません。また、IP ジオロケーションでわかるのは所在地であって、言語ではありません。
- [hreflang とは？設定方法を解説](https://generaltranslation.com/ja/kb/what-is-hreflang.mdx): hreflang は、どの URL が同じページの言語版または地域版であるかを Google に伝え、検索結果に適切なページを表示させるための仕組みです。HTML の link タグ、HTTP の Link ヘッダー、またはサイトマップで追加し、すべてのリンクを相互に参照させたうえで、en-UK ではなく en-GB のような有効なコードを使用してください。
- [国際化とローカライゼーションの違い（i18n vs. l10n）](https://generaltranslation.com/ja/kb/internationalization-vs-localization.mdx): 国際化（i18n）とは、1つのプロダクトで多数のロケールをサポートできるようにするためのコードと設計の作業です。たとえば、Intl を使った日付のフォーマットや、右から左に書くテキストへの対応などがこれにあたります。ローカライゼーション（l10n）は、プロダクトを特定のロケールに合わせて最適化する作業で、翻訳に加えて通貨、日付形式、単位、トーン、法的な細部などを扱います。
- [ロケールごとに数値、日付、通貨を書式設定するにはどうすればよいですか？](https://generaltranslation.com/ja/kb/format-numbers-dates-currencies.mdx): 各値はページのレンダリング時に、読者のロケールと JavaScript の Intl API を使って書式設定し、翻訳対象の文章からは切り離します。General Translation の `<Num>`、`<Currency>`、`<DateTime>`、`<RelativeTime>` コンポーネントは `<T>` の中でこの両方を行うため、1 つの翻訳ですべての値に対応できます。
- [多言語SEOにおけるサブディレクトリ・サブドメイン・ccTLDの比較](https://generaltranslation.com/ja/kb/multilingual-url-structure.mdx): 1つのプロダクトでサイトとリリースプロセスを共有するなら、example.com/de/ のようなサブディレクトリを使いましょう。国を示せるのは ccTLD だけで、サブドメインなら個別にホスティングできます。Google は ?lang= パラメータを推奨しておらず、.io や .ai のようなバニティドメインは汎用ドメインとして扱います。

## Previous and next questions

- Previous question: [DeepL の代替：General Translation と DeepL の比較](https://generaltranslation.com/ja/kb/general-translation-vs-deepl.mdx)
- Next question: [Flask や FastAPI のアプリを翻訳するには？](https://generaltranslation.com/ja/kb/translate-python-app.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/ja/kb/sitemap.md) for every article.