# General Translation Knowledge Base: 多言語アプリのローカライゼーションテスト チェックリスト
URL: https://generaltranslation.com/ja/kb/multilingual-app-launch-checklist.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 本番環境のビルドで、サポート対象のすべてのロケールについて次の9項目をテストしてください：エラー状態やメールを含むジャーニー全体、言語の切り替え、複数形、通貨とタイムゾーン、テキストの伸長、右から左のレイアウト、アクセシビリティ、翻訳の配信、クロール可能な言語別URL。各項目には明確な合格条件を設けてください。
Category: 国際化
Last updated: 2026-10-16
Authors: Jackie Chen
Published: 2026-10-16

ホームページが翻訳済みで完成しているように見えても、チェックアウト、バリデーションエラー、パスワードリセットのフローはソース言語のまま、ということがあります。まずはユーザーが最後までたどる必要のある導線を洗い出し、それらを本番環境のビルドでテストしてください。

多言語Webアプリをローンチする前に、サポート対象のすべてのロケールで次の9項目を確認してください：

1. **ジャーニー全体が翻訳されている**：読み込み中、空、エラーの各状態に加え、メールや通知も対象です。
2. **言語の選択が一貫している**：初回訪問時、切り替え後、再訪問時のいずれでも同じ言語が選択されること。
3. **変数と複数形が正しい**：対象言語で使われるすべての複数形カテゴリで正しく表示されること。
4. **通貨とタイムゾーンが明示的に設定されている**：UIの言語とは切り離して設定されていること。
5. **テキストが伸長してもレイアウトが崩れない**：狭い画面やブラウザでズームした状態でも確認すること。
6. **右から左に書く言語**で、書字方向、レイアウト、双方向が混在するテキストが正しく表示されること。
7. **支援技術に正しい言語が伝わる**：ラベルやアクセシブルネームも正しいこと。
8. **本番環境のビルドに翻訳がすべて含まれている**：新しく追加した文言もリリース前に翻訳されること。
9. **公開ページにクロール可能な言語別URLがある**：翻訳済みメタデータと`hreflang`が設定されていること。

コンテンツはサポート対象のすべてのロケールで、レイアウトと操作性は代表的なデバイスとブラウザでテストしてください。項目9は、検索エンジンにインデックスさせたい公開ページにのみ当てはまります。

## Video

The video is narrated in English, with English captions.

[What should I check before launching a multilingual app?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-multilingual-app-launch-checklist.mp4) (33 秒)

Before launching a multilingual app, test nine things in every supported locale: complete user journeys including errors, language detection and switching, variables and plurals, currency and time zones, text expansion, right-to-left layout, accessibility, production translation delivery, and crawlable language URLs. With General Translation, run gt validate, then `npx gt translate` before the build so new copy ships translated.

## コンテンツと言語の動作を確認する

### 1. 失敗時の状態を含め、ユーザージャーニー全体を翻訳する

アカウント作成や購入完了など、重要なユーザージャーニーを1つ選びます。ローディング、空、成功、エラーの各状態を実際に操作して確認してください。ボタン、ダイアログ、フォームのバリデーション、プレースホルダー、アクセシビリティ用のラベルに加え、そのジャーニーで送信されるメールや通知もチェックします。手動での確認に入る前に、[ハードコードされた文字列のチェック](/kb/find-hardcoded-strings) でソース言語のリテラルを洗い出しておきましょう。

**合格条件：** 製品名などの意図的な例外を除き、すべてのユーザー接点でレビュー済みの対象言語コンテンツが使われていること。未処理のキー、メッセージ欠落を示すマーカー、理由の説明できないソース言語へのフォールバックが表示されないこと。

General Translation では、レビュアーが [ダッシュボードの翻訳エディター](/docs/platform/dashboard/guides/reviewing-translations) で文言を修正します。新しい翻訳を生成する前に、アプリとメールの各プロジェクトで [用語集とカスタムプロンプト](/docs/platform/dashboard/guides/defining-context-for-translations) を共有してください。文脈の変更は新しい翻訳にのみ適用されます。既存の文言も変わっているはずだと思い込まず、改めてレビューしてください。

### 2. 初回訪問、言語切り替え、再訪問を検証する

新しいブラウザでの初回アクセス、明示的な言語選択、再読み込み、ディープリンク、サポート対象外のブラウザ言語をテストします。アプリがアカウントに言語設定を保存する場合は、サインインとサインアウトもテストしてください。URL、保存された設定、ブラウザの言語が食い違う場合に、どれが優先されるかを記録しておきます。言語設定のマッチングについては[言語検出ガイド](/kb/detect-user-language)を、明示的な言語選択とアクセシブルなナビゲーションについては[言語切り替えガイド](/kb/language-switcher)を参照してください。

**合格条件:** アプリがそのポリシーに一貫して従い、意図しない言語が選択されてもユーザーが元に戻せること。サーバーでレンダリングされたアプリの場合は、ハイドレーション後のページだけでなく初期レスポンスも確認してください。

ロケール識別子は BCP 47 に準拠します。たとえば `es-MX` と `es-AR` は、メキシコのスペイン語とアルゼンチンのスペイン語として別々のターゲットにできます。提供する地域別ターゲットはそれぞれテストしてください。クッキーベースの言語切り替えとロケールのプレフィックス付きルートは用途が異なるため、アプリの実際の URL の挙動を確認してください。

### 3. 変数と複数形カテゴリを検証する

0、1、2、およびそれより大きい値を含む数量をテストし、さらに対象言語の複数形カテゴリに対応するケースを追加します。句読点を含む名前、長いアカウント名、翻訳後に変数の順序が入れ替わる可能性のある文もテスト対象に含めてください。個別に翻訳した断片を連結して文を組み立てるのは避けてください。

GT の React ライブラリでは、[`<Plural>`](/docs/react/reference/components/plural) がロケール固有の複数形を選択し、[`<Branch>`](/docs/react/reference/components/branch) が条件ごとの選択肢を翻訳単位の中にまとめて保持し、[`<Var>`](/docs/react/reference/components/var) が動的な値をローカルで差し込みます。デフォルトの文だけでなく、各選択肢もそれぞれテストしてください。なお、[`<Var>`](/docs/react/reference/components/var) 内のユーザー値を翻訳 API に送信する必要はありません。

**合格条件:** 値が崩れずに保持され、文として正しく読め、必要なすべての複数形に使用可能な内容が用意されていること。英語の単数形/複数形のテストペア 1 組だけでは不十分な理由については、Unicode の[複数形規則](https://cldr.unicode.org/index/cldr-spec/plural-rules)を参照してください。カタログベースのメッセージを使う場合は、[ICU メッセージ](/kb/icu-message-format)内の分岐もあわせてテストしてください (コンポーネントベースのパターンについては [React で複数形を扱うには？](/kb/how-to-handle-plurals-in-react)を参照してください) 。

## フォーマット、レイアウト、アクセシビリティを確認する

### 4. 言語、通貨、タイムゾーンを分けて扱う

同じ金額と同じ時刻を、複数のロケールでテストしてください。製品で必要な場合は、使用する通貨とタイムゾーンを明示的に設定します。言語設定だけでは、顧客がどの通貨で支払うのか、予約がどのタイムゾーンに基づくのかはわかりません。

たとえば、次のコードは既存の USD 金額をドイツの表記慣習に従って書式設定します。

```js
new Intl.NumberFormat('de-DE', {
  style: 'currency',
  currency: 'USD',
}).format(1234.5);
```

指定された金額は通貨換算されずに、そのまま書式設定されます。フォーマットの際に表示桁が丸められる場合があるため、プロダクトで必要な精度を確認してください。同様に、特定の地域における時刻を表示する場合は、タイムゾーンを明示的に指定してください：

```js
new Intl.DateTimeFormat('en-GB', {
  dateStyle: 'medium',
  timeStyle: 'short',
  timeZone: 'Europe/Paris',
}).format(new Date('2026-01-15T12:00:00Z'));
```

**合格条件：** 区切り記号、通貨の種類、暦日、表示される時刻が、プロダクトの意図する意味と一致していること。サポート対象のタイムゾーンで夏時間が採用されている場合は、夏時間の切り替えも含めて確認してください。[数値](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat)と[日付](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat)の API では、これらをそれぞれ個別に指定できます。UI の言語を切り替えても、支払うべき金額やイベントの発生時点が変わってはいけません。GT の [`<Currency>`](/docs/react/reference/components/currency) と [`<DateTime>`](/docs/react/reference/components/datetime) は、通貨とタイムゾーンをオプションで明示的に指定したうえで、ロケール対応のフォーマットを行います。これらの指定内容も、上記の `Intl` 呼び出しと同様にテストしてください。

### 5. さまざまな画面サイズでテキストの伸長をテストする

翻訳済みの画面を、狭いビューポートやブラウザでズームした状態で開きます。ナビゲーション、ボタン、テーブル、ダイアログ、バリデーションメッセージを確認してください。長い翻訳文字列やユーザーが入力する長い値も含めてテストします。短い見出しと住所全体とでは、レイアウトにかかる負荷が異なります。

**合格条件:** 重要なテキストが読みやすい状態を保ち、操作要素が問題なく使用できること。テキストの見切れや要素の重なりによって操作が隠れないこと。切り詰めは、はみ出しをすべて隠す手段として使うのではなく、意図して適用されているかを確認してください。

[疑似ローカライゼーション](/kb/pseudo-localization)を使うと、翻訳が揃う前に、レイアウトの問題や翻訳対象としてマークされていない文字列を洗い出せます。ただし、これは実際の言語でのテストを補うものであり、翻訳品質を保証するものではありません。実装例については、[Lingui のガイド](https://lingui.dev/guides/pseudolocalization)を参照してください。

### 6. 右から左のコンテンツをレイアウト要件としてテストする

アラビア語やヘブライ語など、右から左に書く言語をサポートする場合は、ドキュメントの書字方向、ナビゲーションの順序、フォーム、そしてメールアドレスや注文 ID のように書字方向が混在するコンテンツをテストしてください。テキストの方向に合わせてレイアウトを切り替える箇所では CSS の論理プロパティを使用し、方向を示すアイコンは個別に確認してください。余白、アイコン、書字方向が混在する値の扱いについては、[RTL CSS ガイド](/kb/right-to-left-css)で解説しています。

**合格条件:** レイアウトが意図した読み方向に従い、かつ埋め込まれた左から右の値が問題なく読めること。言語コードを設定しても、テキストの方向は設定されません。W3C の [HTML の書字方向に関するガイダンス](https://www.w3.org/International/questions/qa-html-dir)に従ってください。

### 7. 支援技術に伝わる言語を確認する

ページの `lang` 属性、コンテンツ内での言語の切り替え (該当する場合) 、表示されるラベル、アクセシブルネーム、代替テキストを確認します。主要な利用フローでは、キーボード操作とスクリーンリーダーによる操作も試してください。翻訳済みのプレースホルダーがあっても、常に表示されるフォームラベルの代わりにはなりません。

**合格条件:** ドキュメントで正しい言語が宣言されていること、各コントロールに意味のあるローカライズされた名前が付いていること、翻訳後のレイアウトでも問題なく操作できること。言語宣言については W3C の[解説](https://www.w3.org/International/questions/qa-html-language-declarations)を、ラベルの関連付けについては[フォームラベルのガイダンス](https://www.w3.org/WAI/tutorials/forms/labels/)を参照してください。

## ユーザーに配信されるリリースを確認する

### 8. 本番環境のアセットと翻訳の更新を確認する

リリースプロセスに従ってクリーンなチェックアウトからビルドし、そのビルドを各サポート対象のロケールで実行します。翻訳アセットが存在し、正常に読み込まれることを確認してください。テスト用のブランチで翻訳元のメッセージを変更し、次のリリースまでに翻訳パイプラインがその変更を検出することを確認します。

**合格条件:** 開発時に残ったファイルに頼ることなく、アプリが意図どおりの翻訳を提供していること。アセットの欠落や生成の失敗があった場合に、気付かれないまま不完全な状態でリリースされるのではなく、目に見えるエラーになるか、明示的に許容したフォールバックが使われること。翻訳ツールの認証情報はビルド環境に保管し、ブラウザ向けバンドルには含めないでください。

GT では、ビルドの前に [`gt validate`](/docs/cli/reference/commands/validate) を実行し、続いて [`gt translate`](/docs/cli/reference/commands/translate) を実行します。翻訳が失敗した場合にビルドを停止するよう設定することもできます。[`gt generate`](/docs/cli/reference/commands/generate) はソーステンプレートを書き出すだけです。レビュー担当者がローカルの出力を編集した場合は、[`gt save-local`](/docs/cli/reference/commands/save-local) を使用して、以降の実行でもその変更が保持されるようにしてください。

設定した更新経路をテストしてください。設定済みのプッシュ、プルリクエスト、または手動のトリガーを実際に動かし、[Locadex](/docs/platform/locadex/guides/configuring-automations) が翻訳用のプルリクエストを作成または更新することを確認します。また、意図したブランチが追跡されていることも確認してください。[バンドルされた翻訳](/docs/react/guides/storing-translations)を使う場合、デプロイされたアプリは GT のサービスに依存せず、提供されたファイルをレンダリングできます。CDN 配信を使う場合は、公開した編集内容をバージョンとキャッシュの設定に照らしてテストし、ユーザーに届くまでの遅延も含めて確認してください。

### 9. 公開する各言語版が検出可能か確認する

検索結果への表示を想定したページについては、各言語版にクロール可能なURL、翻訳済みのタイトルと説明文、意図したカノニカルURL、有効な言語の代替リンクがあることを確認してください。また、現在のページ自身も含めて、[hreflang](/kb/what-is-hreflang) が相互に参照し合っているかも確認します。代替リンクをサイトマップで宣言している場合は、サイトマップにも同じページ間の関係が反映されていることを確認してください。

**合格条件:** 公開されている各言語のURLで期待どおりのコンテンツが読み込まれ、意図した場合にはインデックス登録が可能で、実在する代替バージョンを指していること。サポートされている注釈の方法については、Google の[ローカライズ版ページに関するガイダンス](https://developers.google.com/search/docs/specialty/international/localized-versions)を参照してください。Next.js で実装する場合は、[多言語SEOガイド](/kb/multilingual-nextjs-seo)を参照してください。

パスのプレフィックス、言語別のサブドメイン、国別ドメインを使えば、言語ごとに個別のURLを用意できます。これらの比較については[URL構造ガイド](/kb/multilingual-url-structure)を参照してください。`Accept-Language` ヘッダーやクッキーで訪問者の言語を選択することはできますが、それだけでは各言語版にクロール可能なURLは生成されません ([言語リダイレクトとSEO](/kb/locale-routing-seo)を参照) 。Google の[多言語サイトに関するガイダンス](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)でも、URLを分けることが推奨されています。ログインが必要なダッシュボードなどでは、言語別URLをインデックス登録させる必要がない場合もあります。プロダクトの対象ユーザーに合わせてルーティングの方針を決めてください。GT の無料の [Report Card](https://generaltranslation.com/report-card) を使えば、公開サイトのローカライゼーションを一次チェックできます。ただし、ログインが必要な操作フローの検査や、意図的にエラー状態を発生させることはできません。

## リリース記録を残す

ビルド、ロケール、ジャーニー、ブラウザまたはデバイス、期待される結果、実際の結果、レビュー担当者を記録します。不具合には担当者を割り当ててください。チェックアウト画面の翻訳漏れや主要なアクションが読めないといった問題は、軽微な言い回しの好みとは区別して扱い、許容したフォールバックは明示しておきましょう。記入例は次のとおりです。

| ビルド              | ロケール | チェック項目                 | デバイス           | 期待される結果               | 実際の結果                              | 判定                       |
| ---------------- | ---- | ---------------------- | -------------- | --------------------- | ---------------------------------- | ------------------------ |
| 4.12.0 (a1b2c3d) | `de` | 1. チェックアウト時のカード決済拒否    | Chrome、デスクトップ  | 再試行アクション付きのドイツ語エラー    | ドイツ語エラーは表示されるが、幅 320px でボタンラベルが切れる | 不合格: リリースをブロック、担当者割り当て済み |
| 4.12.0 (a1b2c3d) | `pl` | 3. 商品 2 個、5 個、22 個のカート | Safari、iPhone  | ポーランド語の few 形と many 形 | 5 個で `few` 形が表示される                 | 不合格: 複数形のキーを修正           |
| 4.12.0 (a1b2c3d) | `ar` | 6. アカウント設定             | Chrome、Android | 左右反転したレイアウト、戻る矢印が右向き  | 期待どおり                              | 合格                       |

## Related questions

- [翻訳されていないハードコードされた文字列を見つけるにはどうすればよいですか？](https://generaltranslation.com/ja/kb/find-hardcoded-strings.mdx): CI でリンターを実行し、ユーザー向けの文字列リテラルを検出します。たとえば JSX なら eslint-plugin-i18next の no-literal-string ルール、Android なら Android Lint の HardcodedText チェック、Rails なら erb_lint の HardCodedString リンターが使えます。さらに、疑似ロケールでアプリを一通り操作し、静的チェックでは追跡できないテキストを洗い出します。
- [言語切り替え機能のベストプラクティス：UX、SEO、アクセシビリティ](https://generaltranslation.com/ja/kb/language-switcher.mdx): 各言語は Deutsch や 日本語 のようにその言語自身の名称で表記し、国を表す国旗は使わないでください。各選択肢からは、クロール可能なリンクで同じページの該当言語版へ遷移させ、選択内容はクッキーに保存します。ローカライズされた URL は決して自動リダイレクトしないでください。
- [疑似ローカライゼーションとは？](https://generaltranslation.com/ja/kb/pseudo-localization.mdx): 疑似ローカライゼーションは、原文をアクセント記号付きで約40%長く水増しし、括弧で囲んだ改変版に置き換えるテストです。これにより、ハードコードされた文字列、切り詰め、フォントの表示崩れ、文の連結といった問題を、翻訳を用意する前に発見できます。Android にはこの用途向けに en-XA と ar-XB の疑似ロケールが用意されています。
- [CSS で RTL（右から左）言語をサポートするには？](https://generaltranslation.com/ja/kb/right-to-left-css.mdx): lang だけでは書字方向は変わらないため、html 要素に dir="rtl" と lang の両方を指定します。そのうえで、margin-left などの物理的な CSS を margin-inline-start などの論理プロパティに置き換えます。flex の行、グリッドの列、デフォルトのテキストの配置は自動的に反転しますが、translateX()、left、right は反転しません。
- [多言語対応の Next.js アプリで SEO を設定するには？](https://generaltranslation.com/ja/kb/multilingual-nextjs-seo.mdx): 各言語に /en/about や /es/about のようなプレフィックス付きの URL を割り当て、公開している言語ごとに html lang、自己参照のカノニカル、x-default を含む hreflang の代替リンク、翻訳済みのタイトルと説明文、サイトマップのエントリを出力します。未公開のバージョンには noindex を指定します。General Translation の gt-next は各言語を専用の URL にルーティングし、getGT でタイトルを翻訳します。

## Previous and next questions

- Previous question: [Transifex の代替ツール：General Translation と Transifex の比較](https://generaltranslation.com/ja/kb/general-translation-vs-transifex.mdx)
- Next question: [AI翻訳は本番環境のアプリで使えるほど正確か？](https://generaltranslation.com/ja/kb/is-ai-translation-accurate.mdx)

## Sitemap

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