SaaSプロダクトの海外展開を検討する際、避けて通れないのがUI(ユーザーインターフェース)の多言語化です。i18n(Internationalization、国際化)は単なる文字列の翻訳にとどまらず、日付・通貨のフォーマット、レイアウトの対応、翻訳ファイルの管理まで幅広い設計が必要です。
この記事では、SaaSプロダクトのi18nを設計段階から実装・運用まで体系的に解説します。
i18nとl10nの違い
i18n(国際化)とは
i18n(Internationalization)は、プロダクトを複数の言語や地域に対応できるように設計・実装することです。具体的には、コード内にハードコードされた文字列を外部化し、ロケールに応じて切り替え可能な仕組みを構築します。
l10n(ローカライゼーション)とは
l10n(Localization)は、i18nの仕組みの上で、特定の言語・地域向けにコンテンツを翻訳・調整することです。翻訳テキストの作成、通貨・日付フォーマットの設定、文化的な配慮(色やアイコンの意味)などが含まれます。
| 項目 | i18n(国際化) | l10n(ローカライゼーション) |
|---|---|---|
| 担当 | エンジニア | 翻訳者・PMM |
| タイミング | 設計・開発段階 | リリース準備段階 |
| 内容 | 文字列外部化、ロケール切替機構 | 翻訳テキスト作成、地域適応 |
| 頻度 | 初回設計 + 新機能追加時 | 新言語追加・文言変更のたび |
設計段階で考慮すべきこと
文字列の外部化
i18nの第一歩は、UIに表示するすべての文字列をコードから分離し、外部の翻訳ファイル(JSON、YAML等)に格納することです。
// NG: ハードコードされた文字列
<button>保存する</button>
// OK: キーで参照
<button>{t('common.save')}</button>
レイアウトの柔軟性
言語によってテキストの長さは大きく異なります。日本語で2文字の「保存」は、英語では「Save」(4文字)、ドイツ語では「Speichern」(9文字)になります。固定幅のボタンやラベルは避け、テキスト量に応じて伸縮するレイアウトを設計しましょう。
- ボタン —
min-width+paddingで対応 - テーブルヘッダー — テキストが長くなっても折り返せるように
- ナビゲーション — メニュー項目の文字数増加に備える
- フォームラベル — 固定幅を避ける
日付・数値・通貨のフォーマット
日付や通貨の表示形式はロケールによって異なります。JavaScriptのIntl
APIを活用しましょう。
// 日付フォーマット
new Intl.DateTimeFormat('ja-JP').format(date) // 2026/3/9
new Intl.DateTimeFormat('en-US').format(date) // 3/9/2026
// 通貨フォーマット
new Intl.NumberFormat('ja-JP', {
style: 'currency', currency: 'JPY'
}).format(1000) // ¥1,000
new Intl.NumberFormat('en-US', {
style: 'currency', currency: 'USD'
}).format(1000) // $1,000.00
複数形・性別の処理
英語には単数形・複数形があり、フランス語やドイツ語には名詞の性別があります。ICU MessageFormat を使うことで、これらの文法的な違いに対応できます。
フレームワーク別の実装方法
React(react-i18next)
Reactアプリケーションではreact-i18nextが最も広く使われています。i18nライブラリ比較も参考にしてください。
// i18n.js
import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';
i18n.use(initReactI18next).init({
resources: {
ja: { translation: require('./locales/ja.json') },
en: { translation: require('./locales/en.json') },
},
lng: 'ja',
fallbackLng: 'en',
});
// Component
import { useTranslation } from 'react-i18next';
function Dashboard() {
const { t } = useTranslation();
return <h1>{t('dashboard.title')}</h1>;
}
Vue(vue-i18n)
Vueアプリケーションではvue-i18nがデファクトスタンダードです。
// main.js
import { createI18n } from 'vue-i18n';
const i18n = createI18n({
locale: 'ja',
fallbackLocale: 'en',
messages: {
ja: require('./locales/ja.json'),
en: require('./locales/en.json'),
},
});
// Component
<template>
<h1>{{ $t('dashboard.title') }}</h1>
</template>
Next.js(next-intl / next-i18next)
Next.jsでの多言語化については、Next.js多言語化ガイドで詳しく解説しています。App RouterとPages Routerで実装方法が異なるため、プロジェクトの構成に合わせて選択してください。
翻訳ファイルの管理
ファイル構成のベストプラクティス
翻訳ファイルは機能単位で分割し、名前空間(namespace)で管理するのが効率的です。
locales/
ja/
common.json // 共通UI(ボタン、ラベル等)
dashboard.json // ダッシュボード画面
settings.json // 設定画面
billing.json // 課金関連
en/
common.json
dashboard.json
settings.json
billing.json
翻訳キーの命名規則
-
階層構造 —
画面名.セクション名.要素名(例:settings.profile.saveButton) -
意味ベース — UIの見た目ではなく意味で命名(
redButtonではなくdeleteButton) - 一貫性 — 同じ概念には同じキーを使う
翻訳漏れの検出
CIパイプラインに翻訳キーのチェックを組み込むと、翻訳漏れを早期に発見できます。すべてのロケールファイルのキーを比較し、不足があればエラーにするスクリプトを用意しましょう。
マーケティングサイトの多言語化
プロダクトUIとマーケティングサイトの違い
SaaSのマーケティングサイト(LP、ブログ、ドキュメント)は、プロダクトUIとは異なるアプローチが効率的です。
| 項目 | プロダクトUI | マーケティングサイト |
|---|---|---|
| 更新頻度 | 機能リリースごと | 随時(コンテンツ追加) |
| 翻訳量 | 比較的少ない | 大量(ブログ記事等) |
| SEO要件 | なし | あり(hreflang等) |
| 管理者 | エンジニア | マーケター |
| 最適な手法 | i18nライブラリ | blaidなどの翻訳サービス |
blaidでマーケティングサイトを多言語化
マーケティングサイトの多言語化は、blaidのようなサービスを使うと、エンジニアリソースをかけずに実現できます。JavaScript1行の追加だけでサイト全体が翻訳され、SEOに必要なhreflangタグも自動的に付与されます。
- エンジニアの工数ゼロ — コードの変更は1行のみ
- コンテンツ更新に自動追従 — ブログ記事の追加時も翻訳が自動適用
- SEO対応 — 検索エンジンにインデックスされる形式で翻訳
まとめ
SaaSプロダクトの多言語化は、プロダクトUI(i18n)とマーケティングサイトで最適なアプローチが異なります。
推奨する進め方:
- プロダクトUIは設計段階からi18nを組み込む(文字列外部化、Intl API活用)
- フレームワークに合ったi18nライブラリを選定する
- 翻訳ファイルの管理ルールを整備し、CIで翻訳漏れを検出する
- マーケティングサイトはblaidで効率的に多言語化する
プロダクトUIのi18nには時間がかかりますが、マーケティングサイトの多言語化はblaidの無料プランですぐに始められます。まずはマーケティングサイトから海外展開の第一歩を踏み出してみてください。