- React
- i18n
- ガイド
React i18n vs 自動翻訳：あなたのアプリにはどちらが適しているか？（2026年版）
読了時間 10分
Reactチームには多言語対応への根本的に異なる2つの道があります。ソースコードに 手を加えるi18nライブラリと、DOMレベルで動作する自動翻訳です。どちらが常に優れているわけではありません。このガイドでは、 それぞれをいつ選ぶべきかを整理します。
従来のReact i18nアプローチ
React国際化の標準的なライブラリはreact-i18next、react-intl（FormatJSの一部）、LinguiJSです。それぞれ違いはありますが、同じ 基本ワークフローを共有しています。
- コンポーネント内のすべての文字列を
t()呼び出しに置き換えます：<p>Submit</p>は<p>{t('form.submit')}</p>に なります。 - ロケールごとにJSON翻訳ファイルを作成します：
en.json、fr.json、de.jsonなど。各キーが 翻訳済みの文字列にマップされます。 - 言語ごとに複数形処理を扱います — ポーランド語やアラビア語の複数形ルールは 英語よりはるかに複雑です。
- 型安全なキー定義を追加し、TypeScriptがコンパイル時に欠落や誤記の翻訳キーを 検出できるようにします（
typescript-i18nや i18next自体の型サポート経由）。 - 正しいロケールバンドルを読み込むようビルドやランタイムを設定し、開発中に追加された 新しい文字列が自動的に翻訳ワークフローに現れる仕組みを整えます。
Next.js App Routerプロジェクトでは、ロケールルーティングとSSRレンダリングされた 翻訳のためにnext-intlやnext-i18nextを追加します。
i18nライブラリの実際のコスト
t()でラップする単位あたりの コストはわずかです。累積コストは大きくなります。
初回移行：エンジニアリング2〜5日
1年以上のUI開発の蓄積がある既存のReactアプリケーションでは、すべてのコンポーネントを ハードコードされた文字列がないか監査し、t()で ラップし、初期の翻訳ネームスペース構造を作成し、i18nプロバイダーをセットアップする 作業は、文字列が1つも翻訳される前から複数日にわたるプロジェクトになります。
新しい文字列ごとの継続的な保守
新しいUI文字列にはすべて、キー定義、ソースロケールファイルへの英語エントリ、 そして各対象言語ファイルへの更新が必要です。火曜日のPRで文字列が追加された場合、 その機能がそれらのユーザーに表示される前にフランス語とドイツ語の翻訳ファイルを 出荷する必要があります。
コンテキストとネームスペース管理
翻訳ファイルが数百から数千のキーに成長するにつれ、ネームスペース管理はそれ自体が 専門分野になります。キーにはプレフィックスが必要になり、ネームスペースには読み込み 戦略が必要になり、キーの衝突や未使用キーの蓄積のリスクが時間とともに増加します。
RTLには別のレイアウト作業が必要
i18nライブラリは文字列の翻訳を扱いますが、レイアウトの方向は扱いません。 アラビア語やヘブライ語のサポートには、ライブラリのセットアップに加えて別途の CSS作業が必要です — 論理プロパティ、アイコンの反転、 dir="rtl"下での テストです。
i18nライブラリが正しい選択となる場面
ライブラリのオーバーヘッドが妥当、あるいは必須となる具体的な状況があります。
オープンソースプロジェクト
翻訳ファイルがGitHub上でコミュニティによって提供される場合、標準的なi18n ライブラリ形式（JSONやPOファイル）が貢献者にとって正しいインターフェースです。 コミュニティによる人力貢献を求めるプロジェクトには自動翻訳は機能しません。
コンプライアンス駆動の文字列レビュー
規制業界（法律、医療、金融）では、すべてのUI文字列がデプロイ前に明示的に レビュー・承認される必要がある場合があります。i18nライブラリはこれを監査可能に します — すべての文字列がバージョン履歴を持つ独立した成果物になります。
大量の数値・日付・通貨フォーマット
UI全体でフォーマットされた数値、日付、通貨を表示するアプリ（例：アナリティクス ダッシュボードや会計ツール）は、DOMベースの翻訳が提供しない、
IntlAPI経由の ロケール対応フォーマットをFormatJSのようなライブラリから得られます。オフラインファーストなアプリ
オフラインで動作する必要があるアプリ（完全なオフラインサポートを持つPWA）は、 ネットワークがないときに翻訳APIを呼び出せないため、バンドルされた翻訳ファイルが 必要です。i18nライブラリはビルド時に翻訳をバンドルします。
自動翻訳が優れている場面
DOMベースのアプローチは、別の制約セットにより適しています。
既存アプリへの、書き直しなしのローカライゼーション追加
自動翻訳にとって最も説得力のあるケースです。稼働中のReactアプリケーションがあり、 200個のコンポーネントに触れずに5言語を追加したい場合、DOMベースの翻訳が唯一 現実的な選択肢です。
専任のi18nエンジニアがいないチーム
ライブラリベースのi18nシステムを適切に構築・維持するには、ライブラリ自体、 翻訳ワークフロー、複数形処理のエッジケースに関する専門知識が必要です。 スクリプトタグ方式にはそのいずれも必要ありません。
急速に進化するUI
製品が毎週新しいUIを出荷する場合、翻訳ファイルのパリティを維持することは 絶え間ない摩擦になります。自動翻訳は追加の手順なしで、初回のページ訪問時に 新しい文字列を処理します。
完璧さよりも市場投入の速さが重要
1週間で公開される高品質な自動翻訳は、3か月かけて出荷される完璧なi18nライブラリ 統合に勝ります。多くの国際市場では、翻訳品質の差が決定要因ではなく — 存在すること 自体が重要なのです。
ReactにおけるDOMベース翻訳の仕組み
LingvitはMutationObserverベースのアプローチを使い、Reactの レンダリングモデルと自然に統合します。
- 初期読み込み時に、スクリプトはDOM内の既存のすべてのテキストノードを走査し、 翻訳のために送信します。Reactの仮想DOMやレンダリングの仕組みはこのプロセスには 見えません — 最終的にレンダリングされたHTMLだけが重要です。
- MutationObserverが、後続のDOM変更 — Reactの状態変化、ルート遷移（Next.jsの クライアントサイドナビゲーション）、遅延読み込みされるコンポーネント、APIレスポンス 由来の動的コンテンツ — によって追加される新しいノードを監視します。
- 保存済みの翻訳はAPI経由で取得されます。翻訳された文字列がその場で入れ替わるため、 言語の切り替えにページの再読み込みは不要です。
- RTL言語の場合、
document.documentElement.dirが 自動的に設定され、レイアウト内のCSS論理プロパティが反転します。
セットアップ比較
| ステップ | i18nライブラリ | Lingvit |
|---|---|---|
| インストール | npm install react-i18next i18next | スクリプトタグ1つ |
| 設定 | i18nインスタンス + プロバイダー + ネームスペース設定（約100行） | ダッシュボード：言語を選ぶだけ |
| 文字列への計装 | すべてのコンポーネントの文字列をt()でラップ | コード変更なし |
| 翻訳ファイル | 言語ごとのJSONファイルをリポジトリで管理 | 自動生成され、Lingvit内に保存 |
| 型安全性 | typescript-i18n経由でオプション（約50行の設定） | 該当なし |
| 新しいUI文字列 | キーを追加し、すべてのロケールファイルを更新 | 初回のページ訪問時に翻訳 |
| RTLサポート | 別途CSS作業が必要 | アラビア語、ヘブライ語、ペルシア語、ウルドゥー語で自動対応 |
横にスクロールしてすべての列を表示できます。
よくある質問
LingvitはReact 18/19のConcurrent Modeやストリーミング SSRで動作しますか？
はい。MutationObserverによるアプローチはReactのバージョンに依存しません — Reactがどのようにレンダリングするかに関わらず、最終的なDOM出力を監視します。Concurrent Mode、Suspense、ストリーミングSSRはいずれも最終的にDOMノードを生成し、オブザーバーはそれらを通常通り処理します。Reactバージョン固有のAPIは一切関係ありません。
Next.js App RouterやServer Componentsでも動作しますか？
はい。Server Componentsは、ブラウザに送信され他のHTMLと同じようにDOMに挿入されるHTMLを生成します。ルートのlayout.tsx内のスクリプトタグがこのコンテンツを通常通り検知します。Next.jsによって処理されるクライアントサイドナビゲーションは、新しくレンダリングされたコンテンツに対してMutationObserverを発火させます。
プロの翻訳者は文字列をレビューできますか？
はい。Lingvitのダッシュボードには、プロの翻訳者が言語ごとにすべての文字列をレビュー、編集、承認できる翻訳ブラウザが用意されています。上書きされた翻訳は永続的に保存され、自動翻訳よりも優先されます。これにより、リポジトリ内で翻訳ファイルを管理することなく、i18nライブラリと同等のレビューワークフローを得られます。