SaaS ローカリゼーションガイド：アプリを書き直さずにグローバル展開（2026年版）
多くの SaaS プロダクトは、国際化を何年も先延ばしにします — それが重要でないからではなく、 従来のアプローチでは、最初の翻訳された文字列を1人のユーザーが目にする前に大規模なエンジニアリング プロジェクトが必要になるからです。このガイドでは、代替アプローチが実際にどのようなものかを示します。
SaaS ローカリゼーションの問題
SaaS ローカリゼーションの標準的なアドバイスは、react-i18next、i18next、formatjs のような i18n ライブラリを採用することです。これらのライブラリはいずれも 同じ複数ステップの移行を必要とします。
- →すべての UI 文字列を
t()呼び出しでラップし、 コードベース全体で何百ものコンポーネントに手を加える。 - →対象言語ごとに JSON 翻訳ファイルを作成・保守する。
- →型安全なキー定義を追加し、翻訳漏れをコンパイル時に検出できるようにする。
- →複数形化のルールを実装する — 言語ごとに大きく異なる。
- →新しい UI 文字列が公開前に翻訳されるよう、翻訳ワークフローを整備する。
1〜2年の開発実績がある一般的な SaaS プロダクトにとって、これは翻訳された文字列を1人のユーザーが 目にする前に必要な2〜4週間のエンジニアリングプロジェクトです。チームは合理的に、国際的な収益が 無視できなくなるまでこれを後回しにします。
実際に翻訳が必要なもの
アプローチを選ぶ前に、「プロダクト」が翻訳の観点で実際に何を意味するかを整理しておくと役立ちます。 一般的な SaaS アプリケーションの場合：
| コンテンツの種類 | DOM 内？ | ウィジェットでの対応 |
|---|---|---|
| UI 文字列、ナビゲーション、ボタン | あり | 自動対応 |
| エラーメッセージと通知 | あり（表示時） | MutationObserver 経由で対応 |
| オンボーディングフローとヘルプテキスト | あり | 自動対応 |
| API レスポンス後の動的コンテンツ | あり（レンダリング後） | MutationObserver 経由で対応 |
| メールテンプレート | なし | 対象外 — 別のソリューションが必要 |
| JS バンドルにハードコードされた文字列 | レンダリングされる場合のみ | DOM にレンダリングされる場合に対応 |
横にスクロールしてすべての列を確認できます。
ユーザーが Web アプリでやり取りするものの大部分は DOM にレンダリングされます。そのため、 あらゆるエッジケースをカバーできなくても、DOM ベースの翻訳は実用的な出発点になります。
DOM ベースの代替アプローチ
スクリプトタグ型の翻訳ウィジェットは異なるアプローチを取ります — ソースコードに手を加える代わりに、 ブラウザ内でレンダリングされた HTMLを観察し、その場で翻訳します。
その仕組みは次のとおりです。
- 1ページ読み込み時に、スクリプトが DOM を走査してテキストノードを収集し、効率的な API 呼び出しの ためにブロックへグループ化します。
- 2翻訳された文字列が API から返され、DOM に差し替えられます。元のテキストはメモリ上に保持されます。
- 3MutationObserver が新しい DOM ノード — ナビゲーション、モーダルの表示、 リストに反映される API レスポンスなどによって発生 — を監視し、即座に翻訳します。
- 4保存済みの翻訳は、新たに生成リクエストを送ることなく再利用できます。
代表的なデバイスとネットワークで切り替えの挙動をテストしてください。スクリプトタグによるアプローチは アプリケーションのソースコードに手を加えずに済む場合があります。
注意すべき点
DOM ベースのアプローチは80〜90%のケースをうまく処理しますが、自分のプロダクトについて評価すべき 特定の状況があります。
DOM に一度もレンダリングされない文字列
アプリが JavaScript 内で文字列を組み立てて toast ライブラリやアラートに渡す場合、中間的な JS 文字列は DOM に到達する前に構築されている可能性があります。DOM のテキストノードに到達すれば ウィジェットが対応しますが、ネイティブブラウザの alert()や DOM 外のオーバーレイに 表示される場合は翻訳されません。
ユーザー生成コンテンツ
ユーザーが書いたコンテンツ — コメント、メモ、リッチテキストエディタ — はレンダリング時に翻訳 されますが、これが望ましくない場合があります。Lingvit の除外セレクタを使って、UGC コンテナを 翻訳対象外としてマークしてください。
バックエンドのメールテンプレート
トランザクションメール（ウェルカムメール、請求書、パスワードリセット）はサーバー側で送信され、 DOM を通過することはありません。これらはメールサービスのローカリゼーション機能を利用するか、 言語ごとに個別のメールテンプレートを維持するなど、別途対応が必要です。
API レスポンスの文字列
バックエンドが返す文字列が直接表示される場合（API からのステータスラベルなど）は、DOM に レンダリングされた時点で対応されます。同じ文字列が非レンダリングの文脈（ダウンロードされる CSV、Webhook など）に現れる場合は対象外です。
React／Next.js の SaaS でのセットアップ
既存の React または Next.js アプリケーションに Lingvit を追加するには3ステップで済み、 コンポーネントへのコード変更は不要です。
- 1
サインアップしてプロジェクトを作成
app.lingvit.com でプロジェクトを 作成し、アプリケーションのドメインを登録します。プロジェクトキーが発行されます。
- 2
ルートレイアウトにスクリプトタグを追加
Next.js App Router では、
app/layout.tsxに追加します。<Script src="https://cdn.lingvit.com/widget.bundle.js?v=1" strategy="afterInteractive" />Pages Router や素の React の場合は、閉じタグの
</body>の直前に<script>タグを貼り付けてください。 - 3
ダッシュボードで対象言語を選択
ダッシュボードから対象言語を選択します。言語切り替えは自動的に挿入されます。翻訳は各言語の 最初のページ訪問時に生成が始まります。
編集による管理
自動翻訳は量を処理しますが — 製品名、法的用語、ブランド固有の言い回しには人による確認が必要です。 Lingvit は複数の管理手段を提供します。
翻訳ブラウザ
言語ごとにすべての翻訳済み文字列を確認し、ダッシュボードで直接、自動翻訳を上書きできます。 上書きは永続的に保存され、その文字列については自動翻訳より優先されます。
用語集
製品名、機能名、ブランド固有の専門用語など、決して翻訳してはいけない用語を定義できます。 用語集のエントリはすべての言語に対してグローバルに適用されます。
公開の管理
翻訳は公開して初めて反映されます。ユーザーに表示される前にある言語を下書き・レビューし、 コードデプロイなしで公開できます。
よくある質問
- ウィジェットは React の並行機能や Suspense に対応していますか？
- はい。MutationObserver によるアプローチはフレームワークに依存しません — React がどのようにレンダリングするかにかかわらず、最終的な DOM 出力を観察します。並行モード、Suspense 境界、ストリーミング SSR はいずれも DOM ノードを生成し、オブザーバーは通常どおり処理します。
- SSR について — 翻訳されたコンテンツは検索エンジンにインデックスされますか？
- クライアントサイドのウィジェット翻訳では、ソース HTML には元の言語のみが含まれます。認証で保護された SaaS ダッシュボードでは、これはほとんど問題になりません。多言語 SEO が重要な一般公開のマーケティングページでは、スクリプトタグによるアプローチはサーバーレンダリングされた i18n ほど適していません。
- 新機能に既存の i18n ライブラリと併用できますか？
- はい。Lingvit は DOM 内にあるものを翻訳します — 文字列が i18n ライブラリ由来か、ハードコードされたものか、API レスポンス由来かは関係ありません。新機能には react-i18next を使いつつ、移行期間中はそれ以外を Lingvit にカバーさせることができます。