# General Translation Knowledge Base: 多言語アプリをローンチする前に何を確認すべきか？
URL: https://generaltranslation.com/ja/kb/multilingual-app-launch-checklist.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 多言語アプリをローンチする前に、サポート対象のすべてのロケールで次の9項目をテストしてください：エラー時を含むユーザージャーニー全体、言語検出と言語の切り替え、変数と複数形、通貨とタイムゾーン、テキストの伸長、右から左のレイアウト、アクセシビリティ、本番環境での翻訳の配信、SEOのためのクロール可能な言語別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は、検索エンジンにインデックスさせたい公開ページにのみ当てはまります。

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

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

アカウント作成や購入完了など、重要なユーザージャーニーを1つ選びます。ローディング、空、成功、エラーの各状態を実際に操作して確認してください。ボタン、ダイアログ、フォームのバリデーション、プレースホルダー、アクセシビリティ用のラベルに加え、そのジャーニーで送信されるメールや通知もチェックします。

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

**General Translation を使う場合：** [`gt translate`](/docs/cli/reference/commands/translate) の出力がリリースに含まれていることを確認します ([`gt generate`](/docs/cli/reference/commands/generate) はソーステンプレートを書き出すだけなので、別途翻訳済みテキストが必要です) 。レビュアーは [ダッシュボードの翻訳エディター](/docs/platform/dashboard/guides/reviewing-translations) で文言を修正します。代わりにリポジトリ内の生成ファイルを直接編集する運用の場合は、[`gt save-local`](/docs/cli/reference/commands/save-local) を実行して、以降の実行でも編集内容が保持されるようにしてください。アプリ、ドキュメント、通知の間で製品用語を統一するには、翻訳を生成する前に [コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations) で共有の用語集とカスタムプロンプトを割り当てます。文脈の変更は新しい翻訳にのみ適用され、既存の翻訳が書き換えられることはありません。

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

新しいブラウザでの初回アクセス、明示的な言語選択、再読み込み、ディープリンク、サポート対象外のブラウザ言語をテストします。アプリがアカウントに言語設定を保存する場合は、サインインとサインアウトもテストしてください。URL、保存された設定、ブラウザの言語が食い違う場合に、どれが優先されるかを記録しておきます。

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

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

**General Translation の場合:** 地域別ターゲットを含むサポート対象の言語は、[ロケール設定](/docs/react/guides/managing-locales)で定義します。

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

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

**合格条件:** 値が崩れずに保持され、文として正しく読め、必要なすべての複数形に使用可能な内容が用意されていること。英語の単数形/複数形のテストペア 1 組だけでは不十分な理由については、Unicode の[複数形規則](https://cldr.unicode.org/index/cldr-spec/plural-rules)を参照してください。

**General Translation の場合:** [`<Plural>`](/docs/react/reference/components/plural) はロケールの複数形規則に従います。英語の基数カテゴリは 2 つですが、アラビア語には 6 つあります。人物の文法上の性など、明示的な値によって文言が変わる場合は [`<Branch>`](/docs/react/reference/components/branch) を、名前などの動的なテキストには [`<Var>`](/docs/react/reference/components/var) を使用してください。この変数ラッパー内の値は翻訳 API に送信されません。実装パターンについては [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 では、これらをそれぞれ個別に指定できます。

**General Translation を使う場合：** [`<Currency>`](/docs/react/reference/components/currency)、[`<DateTime>`](/docs/react/reference/components/datetime)、[`<Num>`](/docs/react/reference/components/num) は、アクティブなロケールに基づいて値を書式設定します。通貨とタイムゾーンは、ビジネス上の意図に合わせて設定してください。UI の言語を切り替えても、支払うべき金額やイベントの発生時点が変わってはいけません。

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

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

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

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

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

アラビア語やヘブライ語など、右から左に書く言語をサポートする場合は、ドキュメントの書字方向、ナビゲーションの順序、フォーム、そしてメールアドレスや注文 ID のように書字方向が混在するコンテンツをテストしてください。テキストの方向に合わせてレイアウトを切り替える箇所では 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. 本番環境のアセットと翻訳の更新を確認する

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

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

**General Translation の場合:** [`gt validate`](/docs/cli/reference/commands/validate) を実行して、API 呼び出しの前にサポート対象のインライン翻訳のエラーを検出し、[差分翻訳のステップをビルドの前に配置します](/docs/cli/guides/generating-translations)。このステップは既存の翻訳を再利用し、変更されたコンテンツだけを翻訳するため、新しい文言を追加したリリースで、その文言を翻訳済みの状態で出荷できます。[ブランチ追跡](/docs/cli/guides/branching)を使うと、並行する開発ブランチを分離したまま管理できます。[Locadex の自動化](/docs/platform/locadex/guides/configuring-automations)を使えば、プルリクエスト経由で翻訳の更新を処理できます。このリリースチェックの一環として、翻訳元の文言を変更し、設定済みのトリガーが動作するかテストしてください。

[ローカルストレージのワークフロー](/docs/react/guides/storing-translations)では、アプリは General Translation へのランタイム呼び出しを行わずにバンドルされた翻訳を提供し、更新は新しいビルドで出荷されます。CDN 配信では、公開した編集内容を再デプロイなしでアプリに反映できますが、翻訳バージョンとキャッシュの設定に左右されます。この更新経路もテストしてください。非公開の翻訳ツールの認証情報はビルド環境に保管し、ブラウザ向けバンドルには含めないでください。

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

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

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

パスのプレフィックス、言語別のサブドメイン、国別ドメインを使えば、言語ごとに個別のURLを用意できます。`Accept-Language` ヘッダーやクッキーで訪問者の言語を選択することはできますが、それだけでは各言語版にクロール可能なURLは生成されません。Google の[多言語サイトに関するガイダンス](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)でも、URLを分けることが推奨されています。ログインが必要なダッシュボードなどでは、言語別URLをインデックス登録させる必要がない場合もあります。プロダクトの対象ユーザーに合わせてルーティングの方針を決めてください。

## リリース記録を残す

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

公開サイトを手早く一次チェックしたい場合は、General Translation の無料の [Report Card](https://generaltranslation.com/report-card) でローカライゼーションのスコアを確認できます。ただし、認証が必要なフローやエラー状態は確認できないため、上記のジャーニーチェックと併用してください。

## よくある質問

### 多言語アプリはどのようにテストすればよいですか？

本番環境のビルドを使い、サポート対象のすべてのロケールで、エラー状態やメール、通知も含めたユーザージャーニーを一通り実行します。複数形、変数、通貨、タイムゾーン、レイアウト、右から左に記述するテキスト、アクセシビリティを確認し、チェック項目ごとに合格条件を記録してください。

### 最も見落とされやすいローカライゼーションのバグは何ですか？

エラー時などの表示が翻訳されていないケースです。メイン画面の翻訳が終わった後も、エラーメッセージ、フォームのバリデーション、空状態 (エンプティステート) の表示、トランザクションメールがソース言語のまま残っていることはよくあります。チェック 1 で、これらを重点的にテストしてください。

### 疑似ローカライゼーションとは何ですか？

疑似ローカライゼーションとは、原文をアクセント記号付きの長いプレースホルダーテキストに置き換える手法です。これにより、実際の翻訳が用意される前に、レイアウトのはみ出しや翻訳対象としてマークされていない文字列を見つけられます。ただし、実際の言語でのテストに代わるものではありません。詳しくは [Lingui の疑似ローカライゼーションガイド](https://lingui.dev/guides/pseudolocalization)を参照してください。

### 多言語ページには SEO のために個別の URL が必要ですか？

インデックス登録させたいページであれば、必要です。Google は、[言語バージョンごとに個別の URL](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) を用意し、`hreflang` で相互にリンクすることを推奨しています。クッキーや `Accept-Language` ヘッダーだけでは、クロール可能な言語バージョンは生成されません。Next.js の場合は、[多言語 Next.js の SEO](/kb/multilingual-nextjs-seo) を参照してください。

## Related questions

- [Reactアプリに最適なi18nライブラリは？](https://generaltranslation.com/ja/kb/best-react-i18n-library.mdx): React向けの主要なi18nライブラリは、General Translationのgt-react、react-i18next、Lingui、React Intlの4つです。いずれも翻訳のレンダリングと書式設定に対応していますが、JSXにインラインで記述したテキストから翻訳の生成まで行えるのはgt-reactだけです。i18nextのカタログやプラグインを引き続き使いたい場合はreact-i18next、メッセージを抽出してコンパイル済みカタログを生成したい場合はLingui、FormatJSとICU MessageFormatを使いたい場合はReact Intlを選びましょう。
- [翻訳ファイルなしで i18n はできますか？](https://generaltranslation.com/ja/kb/i18n-without-translation-files.mdx): はい。gt-react または gt-next を使えば、コンテンツは `<T>` コンポーネントで囲んだままコンポーネント内にインラインで記述でき、翻訳はビルド時に出力として生成されます。そのため、キーやロケールごとの JSON ファイルを作成したり、同期を保ったりする必要はありません。
- [React で複数形を扱うには？](https://generaltranslation.com/ja/kb/how-to-handle-plurals-in-react.mdx): n === 1 のような条件分岐で複数形の選択ロジックをハードコードするのは避けましょう。英語のみのアプリなら小さなヘルパーで十分ですが、多言語アプリではロケール対応の複数形規則が必要になります。gt-react や gt-next の `<Plural>` のような i18n コンポーネントを使えば、あらゆる言語の複数形に対応できます。
- [多言語対応のNext.jsアプリでSEOを設定するには？](https://generaltranslation.com/ja/kb/multilingual-nextjs-seo.mdx): 言語ごとに専用のURLを用意し、html の lang 属性を設定します。各ページのカノニカルURLは自身を指すようにし、すべての言語の hreflang 代替リンクを追加します。さらに、タイトルと説明文を翻訳し、すべての言語版をサイトマップに掲載します。

## Previous and next questions

- Previous question: [Transifex の代替ツール：General Translation と Transifex の比較](https://generaltranslation.com/ja/kb/general-translation-vs-transifex.mdx)

## Sitemap

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