# General Translation Knowledge Base: 国際化とローカライゼーションの違い（i18n vs. l10n）
URL: https://generaltranslation.com/ja/kb/internationalization-vs-localization.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 国際化（i18n）とは、1つのプロダクトで多数のロケールをサポートできるようにするためのコードと設計の作業です。たとえば、Intl を使った日付のフォーマットや、右から左に書くテキストへの対応などがこれにあたります。ローカライゼーション（l10n）は、プロダクトを特定のロケールに合わせて最適化する作業で、翻訳に加えて通貨、日付形式、単位、トーン、法的な細部などを扱います。
Category: 国際化
Last updated: 2026-10-20
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-20

国際化はプロダクトをさまざまな市場に適応できる状態にし、ローカライゼーションはその基盤を活かして特定の市場向けに仕上げます。開発者、デザイナー、翻訳者、プロダクトチームが、同じリリースで両方に関わることも珍しくありません。翻訳はローカライゼーションを構成する要素の1つであり、形式、レイアウト、地域ごとの慣習なども同様に含まれます。

## 国際化 (i18n) とローカライゼーション (l10n) とは？

* **国際化 (i18n) ** とは、コードベースを複数のロケールに対応できる状態に整えることです (日付、複数形、通貨、レイアウトの扱いなど) 。W3C は国際化を、文化・リージョン・言語の異なる利用者に向けて「ローカライゼーションを容易にする」設計・開発と定義しています。具体的には、ユーザー向けのテキストをハードコードされた文字列から切り出す、ロケールに応じて値をフォーマットする、右から左に書く言語のテキストに対応する、全体で Unicode を使用する、といった作業が該当します。 (W3C の [Localization vs. Internationalization](https://www.w3.org/International/questions/qa-i18n) を参照してください。) 
* **翻訳** とは、コンテンツをある言語から別の言語に変換することです。
* **ローカライゼーション (l10n) ** とは、製品を別のロケールに合わせて最適化する、より広範なプロセスです。W3C は翻訳以外の要素として、数値・日付・時刻の書式、通貨、並べ替え順、記号、アイコンや色、住所や電話番号の書式、法的要件、そして文化によって誤解されるおそれのある表現などを挙げています。

ロケールとは、言語または方言とその慣習をひとまとめにしたもので、`en-US` や `de-DE` のようなコードで表します。

## i18n、l10n、g11n の由来

これらはヌメロニム (数字略語) で、最初の文字、間の文字数、最後の文字を組み合わせたものです。「Internationalization」は i と n の間に 18 文字あるので i18n、「localization」は l と n の間に 10 文字あるので l10n です。「Globalization」も同じ要領で g11n になります。

3 つのうち、最も意味が揺れやすいのがグローバリゼーションです。W3C によれば、グローバリゼーションを国際化と同じ意味で使う人もいます。一方、[Microsoft のグローバリゼーション用語集](https://learn.microsoft.com/en-us/globalization/reference/glossary)では、アプリケーションをあらゆるロケールで動作させることをグローバリゼーション、ソフトウェアを世界市場に展開するプロセス全体を国際化と呼んでいます。g11n という表記を見かけたら、筆者がどちらの意味で使っているかを確認しましょう。

## ローカライゼーションは翻訳と同じですか？

翻訳は、ローカライゼーションを構成する工程の 1 つにすぎません。[Microsoft のローカライゼーションガイド](https://learn.microsoft.com/en-us/globalization/localization/localization)では、ある日付の列車の切符の料金を示す文が例として挙げられています。この文はドイツ語に翻訳するだけでは不十分で、料金はユーロで示し、日付は日・月・年の順で表記する必要があります。同ガイドではさらに、米国英語から英国英語へのローカライズでは翻訳がまったく不要な場合もあり、綴り、語彙、書式設定を変更するだけで済むことも指摘されています。

## それぞれの例

**国際化はコードの変更です。** 以下は、注文概要の変更前と変更後の比較です。

```js title="order-summary.mjs"
const date = new Date(Date.UTC(2026, 6, 30));
const total = 1234.5;

// 変更前: 英語のテキスト、米国式の日付順、ドル記号がハードコードされている
console.log(
  `Order placed on ${date.getUTCMonth() + 1}/${date.getUTCDate()}/${date.getUTCFullYear()}. Total: $${total.toFixed(2)}`
);

// 変更後: テキストはロケールごとのメッセージから取得し、値は Intl で書式設定する
const messages = {
  'en-US': 'Order placed on {date}. Total: {total}',
  'de-DE': 'Bestellt am {date}. Gesamt: {total}',
};

function orderSummary(locale, currency) {
  const values = {
    date: new Intl.DateTimeFormat(locale, { timeZone: 'UTC' }).format(date),
    total: new Intl.NumberFormat(locale, { style: 'currency', currency }).format(total),
  };
  return messages[locale].replace(/\{(\w+)\}/g, (_, key) => values[key]);
}

console.log(orderSummary('en-US', 'USD'));
console.log(orderSummary('de-DE', 'EUR'));
```

Node.js 24 で実行すると、次のようになります：

```text title="Output"
Order placed on 7/30/2026. Total: $1234.50
Order placed on 7/30/2026. Total: $1,234.50
Bestellt am 30.7.2026. Gesamt: 1.234,50 €
```

フォーマット処理のコードはどちらのロケールでも動作し、ドイツ語のメッセージは別途用意します。`Intl.NumberFormat` は指定した通貨で金額を書式設定するだけで、ドルをユーロに換算するわけではありません。ここで同じ金額を使っているのは説明のためであり、為替レートに基づく計算ではありません。

**ローカライゼーションとは、各市場に合わせて仕上げたページのことです。** 米国向けの製品ページをドイツ向けにローカライズすると、変わるのは文言だけではありません。

| 要素     | en-US ページ                         | de-DE ページ                                  |
| ------ | --------------------------------- | ------------------------------------------ |
| 価格     | $49.00                            | 49,00 €                                    |
| 日付     | July 30, 2026                     | 30. Juli 2026                              |
| サポート時間 | 3:00 PM                           | 15:00                                      |
| 重量     | 2.2 lb                            | 1 kg                                       |
| 文体     | "Start your free trial" | "du" ではなく敬称の "Sie" を使用 |

最初の 3 行の書式は、コードを国際化しておけば `Intl` が処理してくれます。一方、単位や文体、さらに価格そのものを変えるべきかどうかは、市場ごとに誰かが判断すべきローカライゼーション上の決定事項です。

## i18n と l10n は誰が担当するのか？

* **開発者**は国際化を担当します。文字列をラップまたは抽出し、ロケール対応のフォーマットや複数形の処理を追加し、ロケールごとのルーティングを設定したうえで、長いテキストや右から左に書く文字体系に対応できるようレイアウトを調整します。
* **翻訳者、レビュアー、ローカライゼーションマネージャー**はローカライズを担当します。翻訳を行い、用語の一貫性を保ち、トーンや例文を各市場に合わせて調整し、実際に動作する製品上で各言語の表示を確認します。
* **プロダクトチームと法務チーム**は、通貨、決済手段、必須の告知事項など、市場ごとに何を変えるかを決定します。

## 概要

|       | 国際化 (i18n)                               | ローカライゼーション (l10n)               |
| ----- | ---------------------------------------- | ------------------------------- |
| 変更対象  | コードとデザイン                                 | 特定のロケール向けのコンテンツと慣習              |
| タイミング | 最初の追加言語に対応する前に整備し、機能の変更に合わせて維持する         | ロケールごとに実施し、コンテンツが変わるたびに再度実施する   |
| 担当者   | 開発者                                      | 翻訳者、レビュアー、ローカライゼーションマネージャー      |
| 成果物   | ターゲットロケールをサポートする単一のコードベース                | 特定のロケール向けに最適化され、レビュー済みのプロダクト    |
| 例     | `$${total}` を `Intl.NumberFormat` に置き換える | チェックアウト画面をドイツ語の敬語表現 (Sie) で翻訳する |

## よくある間違い

* **ローカライゼーションを翻訳と同一視する。** 日付が米国式のまま、価格がドル建てのまま、他言語では通じない慣用句もそのままでは、翻訳済みのページでも外国のサイトのように感じられます。W3C も、ローカライゼーションはインターフェースやドキュメントの翻訳に比べて「多くの場合、はるかに複雑な問題」であると述べています。
* **i18n 対応を後回しにする。** ハードコードされた文字列、連結された文、固定幅のボタンがあると、大規模なコードベースほどローカライズが難しくなります。翻訳されたラベルは、意味が正しくてもレイアウトからはみ出すことがあります。[疑似ローカライゼーション](/kb/pseudo-localization)を使えば、こうした問題の多くを翻訳前に洗い出せます。
* **複数形の選択ロジックを自前で実装する。** `count === 1 ? 'item' : 'items'` は複数形が 2 つしかない英語では機能しますが、アラビア語には 6 つあります。 ([React で複数形を扱うには？](/kb/how-to-handle-plurals-in-react)を参照) 
* **文脈なしで翻訳する。** 「Save」という単語だけを渡された翻訳者やモデルには、それが「保存する」なのか「節約する」なのか判断できません。

リリース前には、[多言語アプリのリリースチェックリスト](/kb/multilingual-app-launch-checklist)で、各ロケールでテストすべき項目を確認してください。

## General Translation における i18n と l10n の分担

国際化については、`gt-next`、`gt-react`、`gt-vue`、`gt-node` などの General Translation のオープンソースライブラリがコード側を担います。[`<T>`](/docs/react/reference/components/t) コンポーネントは JSX を記述したその場でラップするため、文字列を抽出してまとめるキーファイルは必要ありません。また、[`<DateTime>`](/docs/react/reference/components/datetime)、[`<Currency>`](/docs/react/reference/components/currency)、[`<Plural>`](/docs/react/reference/components/plural) を使えば、値をロケールに合わせて書式設定できます。

```jsx title="OrderSummary.jsx"
import { T, DateTime, Currency } from 'gt-next';

export function OrderSummary({ date, total, currency }) {
  return (
    <T>
      Order placed on <DateTime>{date}</DateTime>. Total:{' '}
      <Currency currency={currency}>{total}</Currency>
    </T>
  );
}
```

ローカライゼーションについては、`gt.config.json` にロケールを追加し、[`npx gt translate`](/docs/cli/reference/commands/translate) を実行してそのロケールの翻訳を生成します。翻訳プラットフォームはコンポーネント、変数、開発者向けの注記を文脈として活用します。[コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations)を使えば用語やスタイルのルールをプロジェクト間で共有でき、チームはダッシュボード上で[翻訳をレビュー](/docs/platform/dashboard/guides/reviewing-translations)できます。公開中のサイトをチェックしたい場合は、無料の [Report Card](https://generaltranslation.com/report-card) で、`hreflang` タグ、言語宣言、ロケールルーティング、翻訳済みメタデータ、テキストの方向などを含め、サイトのローカライズの完成度を評価できます。

## 重要なポイント

* 国際化 (i18n) は、複数のロケールに対応するための共通基盤を整えるものです。機能の変更に合わせて、その対応を継続的に維持する必要があります。なお、国際化によって翻訳が生成されるわけではありません。
* ローカライゼーション (l10n) は、製品を各ロケールに合わせて最適化する作業です。翻訳だけでなく、通貨、日付や数値の書式、単位、語調、法的・文化的な細部への対応も含まれます。
* i18n、l10n、g11n の数字は、最初と最後の文字の間にある文字数を表しています。なお、g11n の意味は情報源によって異なります。

## Related questions

- [多言語アプリのローカライゼーションテスト チェックリスト](https://generaltranslation.com/ja/kb/multilingual-app-launch-checklist.mdx): 本番環境のビルドで、サポート対象のすべてのロケールについて次の9項目をテストしてください：エラー状態やメールを含むジャーニー全体、言語の切り替え、複数形、通貨とタイムゾーン、テキストの伸長、右から左のレイアウト、アクセシビリティ、翻訳の配信、クロール可能な言語別URL。各項目には明確な合格条件を設けてください。
- [i18nは自前で構築すべきか、General Translationを使うべきか](https://generaltranslation.com/ja/kb/general-translation-vs-in-house-i18n.mdx): 自前のi18n（言語ごとの辞書と小さな t() ヘルパー）は、対応言語が1〜2つで文言も少ないうちは十分に機能します。しかしアプリが成長するにつれて、複数形規則、フォールバック、ファイルの同期を自分で作り直すことになり、そのうえ翻訳そのものも用意しなければなりません。General Translationのオープンソースライブラリがレンダリングを担い、General Translationがコードから翻訳を生成・更新します。
- [疑似ローカライゼーションとは？](https://generaltranslation.com/ja/kb/pseudo-localization.mdx): 疑似ローカライゼーションは、原文をアクセント記号付きで約40%長く水増しし、括弧で囲んだ改変版に置き換えるテストです。これにより、ハードコードされた文字列、切り詰め、フォントの表示崩れ、文の連結といった問題を、翻訳を用意する前に発見できます。Android にはこの用途向けに en-XA と ar-XB の疑似ロケールが用意されています。
- [翻訳管理システム（TMS）とは？](https://generaltranslation.com/ja/kb/what-is-a-translation-management-system.mdx): 翻訳管理システム（TMS）とは、ソースコンテンツとその翻訳を保管し、翻訳メモリ、用語集、レビュー、機械翻訳、外部連携といった翻訳ワークフローを運用するソフトウェアです。翻訳メモリは、完全一致またはあいまい一致によって過去の翻訳を再利用します。代表的な例として Crowdin、Lokalise、Phrase、Smartling、Transifex があります。
- [General Translation vs. i18next、react-intl、next-intl：どのi18nライブラリを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-i18n-libraries.mdx): i18next、react-intl、next-intlなどのオープンソースライブラリ自体は、翻訳を一切行いません。これらが行うのは、あなた自身や翻訳者、あるいは別のサービスが作成し、言語ごとのカタログファイルに用意した翻訳を表示することだけです。General Translationのライブラリも同じくオープンソースで同じ役割を果たしますが、General Translationはさらに、コードを文脈として活用しながら翻訳そのものも行います。

## Previous and next questions

- Previous question: [ユーザーのブラウザ言語を検出するには？](https://generaltranslation.com/ja/kb/detect-user-language.mdx)
- Next question: [多言語SEOにおけるサブディレクトリ・サブドメイン・ccTLDの比較](https://generaltranslation.com/ja/kb/multilingual-url-structure.mdx)

## Sitemap

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