この記事のポイント
- SaaS の多言語化は「UI を英訳すれば終わり」ではなく、技術設計（i18n）・UX・サポート・法的対応（GDPR/CCPA/SOC2）の 4 層を一体で考える必要がある
- i18n の最低限要件：UI 文字列の外部化・日付/通貨/タイムゾーン対応・英語ヘルプセンター 50〜100 記事・利用規約と Privacy Policy の英語/現地法準拠版
- 初期コスト目安：UI 英語化 200〜500 万円・翻訳 100〜300 万円・ヘルプセンター 100〜300 万円・法務対応 50〜150 万円。合計 500〜1,400 万円
- データプライバシー対応：GDPR は DPA + SCCs + Schrems II 後の技術的措置必須。EU データは AWS Frankfurt 等で保管が現実解。中国は PIPL 対応で原則中国国内データ保管
- 翻訳プロセスは「DeepL Pro で下訳 → ネイティブ翻訳者がチェック」のハイブリッドが、フル外注の 30〜40% コスト削減
SaaS の多言語化は「UI を英語にすれば終わり」ではありません。技術設計（i18n）・UX・カスタマーサポート・データプライバシー対応・法的対応を一体的に考える必要があります。本記事では SaaS プロダクトの多言語化を 5 層で体系的に解説し、コストを抑えながら英語・多言語対応を進めるための実務を整理します。
→ SaaS 海外展開の全体像は SaaS 海外展開 完全ガイド〔GTM設計からグロースまで〕 を参照してください。
結論：i18n はコード設計・データモデル・CI/CD・翻訳運用のすべてに影響する全社プロジェクト。早ければ早いほどコストが安い。
| 用語 | 略称 | 意味 |
|---|---|---|
| 国際化 | i18n（Internationalization） | 多言語/地域に対応できる「素地」を作る技術設計 |
| 地域化 | L10n（Localization） | 特定の言語/地域向けの実装（翻訳・通貨・日付フォーマット等） |
i18n は基盤、L10n は適用。i18n を完成させてから L10n を進める のが正しい順序。
UI 内のテキストをコードから分離し、翻訳ファイル（JSON / YAML / .properties）で管理する。
// ❌ ハードコード（NG）
const message = "ようこそ";
// ✅ i18n 対応
const message = t('welcome');
// en.json
{ "welcome": "Welcome" }
// ja.json
{ "welcome": "ようこそ" }
// es.json
{ "welcome": "Bienvenido" }
| 言語/フレームワーク | ライブラリ | 特徴 |
|---|---|---|
| React | react-i18next・next-intl・lingui | エコシステム成熟 |
| Vue | vue-i18n | 公式推奨 |
| Angular | @angular/localize | 公式組込 |
| Svelte | svelte-i18n | 軽量 |
| Ruby on Rails | rails-i18n | 公式組込 |
| Python（Django） | Django i18n（公式）・gettext | 公式組込 |
| Python（Flask） | Flask-Babel | 標準 |
| Java（Spring） | Spring MessageSource | 標準 |
| .NET | IStringLocalizer | 公式組込 |
英語は単複（1 item / 2 items）、ロシア語は 4 形態、アラビア語は 6 形態と、言語によって複数形ルールが異なる。ICU MessageFormat 規格を使うと統一的に処理できる。
// ICU MessageFormat 例
{
"items": "{count, plural, =0 {No items} one