プロローグ — 「翻訳は今や ビルドパイプラインだ」

2018 年に「i18n」と言えば、PM が韓・英・日の列を持つ Excel を用意し、開発者がそれを JSON に手で写して commit する風景だった。2022 年になると Lokalise・Phrase・Crowdin といった TMS(Translation Management System)がキー値同期と翻訳者協業を SaaS にし、DeepL が MT 品質を一段引き上げた。そして 2024〜2026 年には GPT-4o・Claude・Gemini が「文書のトーン・ドメイン文脈を意識する」翻訳を持ち込み、ゲームが再び変わった。

2026 年 5 月時点で、我々が「i18n / ローカライゼーション」と呼ぶ領域は **4 つの異なる陣営** に整理できる。

1. **TMS(翻訳管理システム)** — Lokalise, Phrase, Crowdin, Tolgee, Weblate, Localazy, POEditor, Transifex, Smartling, Lingo(Locize)

2. **AI / MT エンジン** — DeepL, GPT-4o, Claude translate, Gemini translate, Reverso, Papago, Kakao i, NICT VoiceTra, NTT

3. **開発者ライブラリ** — i18next, FormatJS / react-intl, ICU MessageFormat(仕様)

4. **Localization-as-code(LLM ベース)** — Lingo.dev, Locale.dev, OpenStrings

同じ「翻訳」というラベルでも、Lokalise と Lingo.dev と i18next は別の階層の問題を解いている。TMS は人・翻訳者・翻訳メモリ(TM)・用語集を扱い、AI エンジンは raw 翻訳の品質を決め、ライブラリはランタイムレンダリングと複数形・性別処理を担う。Lingo.dev のような新陣営は「翻訳を git diff のように PR で扱おう」という発想だ。

本稿は 2026 年 5 月時点の主要 11 ツール以上の立ち位置・強み・弱み・価格モデルを整理したうえで、最後に **OSS プロジェクト / スタートアップ / グローバル SaaS / セルフホスト規制業界** の 4 シナリオごとに「何を選ぶべきか」を答える。

第1章 · 2026年 i18n 地図 — TMS / OSS / ライブラリ / AI の 4 陣営

全体地図を 1 表に。

| 陣営 | アイデンティティ | 代表ツール |

| --- | --- | --- |

| TMS(商用) | SaaS、翻訳者協業 + キー値同期 | Lokalise, Phrase, Crowdin, Smartling, Transifex, Lingo(Locize), POEditor, Localazy |

| TMS(OSS) | セルフホスト可能、コミュニティ翻訳 | Tolgee, Weblate |

| AI / MT | 翻訳エンジンそのもの | DeepL, GPT-4o, Claude, Gemini, Reverso, Papago, Kakao i |

| 開発者ライブラリ | ランタイム i18n、フォーマット処理 | i18next, FormatJS, react-intl, FBT, Lingui, next-intl |

| 標準 | メッセージフォーマット仕様 | ICU MessageFormat, Unicode CLDR, XLIFF, gettext PO |

| Localization-as-code | LLM + git ワークフロー | Lingo.dev, Locale.dev, OpenStrings |

ワークロード別:

| シナリオ | 推奨 | 理由 |

| --- | --- | --- |

| OSS プロジェクト(ボランティア翻訳者募集) | Crowdin, Weblate, Tolgee | 無料/割引 OSS プラン、コミュニティツール |

| B2B SaaS スタートアップ(製品多言語化) | Lokalise, Phrase, Lingo.dev | TMS + GitHub 連携、AI ワークフロー |

| グローバルエンタープライズ | Smartling, Phrase(RWS), Lokalise | コンプライアンス、エージェンシーワークフロー |

| セルフホスト(規制・機密) | Weblate, Tolgee self-host | データ外部流出ゼロ、GPL/AGPL |

| マーケコンテンツ・ブログ | DeepL Pro + 人手レビュー, Lingo.dev | トーン・ニュアンス処理 |

| ゲーム・UGC 大量翻訳 | GPT-4o / Claude API + 用語集 | コスト・文脈意識 |

最初に押さえたい洞察:**TMS・AI エンジン・ライブラリは代替ではなく補完関係。** Lokalise を使っているから i18next が不要になるわけではないし、DeepL が優秀だから TMS が不要になるわけでもない。まず自チームが何に時間を使っているかを把握すること。

第2章 · Lokalise — TMS のリーダー

Lokalise は 2017 年にラトビアで創業、2021 年にシリーズ B(50M USD)を調達してグローバル TMS の 1 位を固めた。2026 年現在 5,000+ チームが利用し、「モダン SaaS の UX + 開発者親和ワークフロー」のスタンダードとして確立している。

コア概念

- **Project** — 1 アプリ・サービス単位。キー値ペアを保持。

- **Key** — 識別子。`home.welcome.title` 形式のドット記法が一般的。各キーに全言語の翻訳がぶら下がる。

- **Translation memory(TM)** — 過去翻訳の DB。新キー追加時に類似度マッチで自動提案。

- **Glossary** — 用語集。ブランド名、製品名、禁忌語を管理。

- **Branching** — プロジェクトの翻訳を git ブランチのように分岐。機能単位の翻訳作業。

開発者ワークフロー

- **CLI** — `lokalise-cli` でキー push/pull。JSON、YAML、strings、ARB、xml など 30+ フォーマット。

- **GitHub App** — PR マージで自動 sync。新キーは翻訳者に通知。

- **API + Webhook** — 翻訳完了でビルドをトリガ。

- **Figma プラグイン** — デザイン段階でコピーを抽出、翻訳を並行開始。

価格(2026 年 5 月時点)

| プラン | 価格 | キー/ユーザ |

| --- | --- | --- |

| Start | $120/月 | 10 ユーザ、5,000 キー |

| Essential | $230/月 | 10 ユーザ、5,000 キー + branching |

| Pro | $585/月 | 15 ユーザ、30,000 キー |

| Enterprise | 要相談 | SSO、監査ログ、カスタム |

強みと弱み

- 強み:UX が最もきれい。デザイナー・翻訳者・開発者が同じ画面で作業。AI 自動翻訳(DeepL / OpenAI / Google バックエンドを選択)。

- 弱み:価格が高い。OSS プロジェクトには厳しい。セルフホスト不可。

いつ選ぶか

B2B SaaS、シリーズ A 以降のスタートアップ、多言語モバイルアプリ。「翻訳者とデザイナーが一緒に働くモダンワークフロー」を必要とするチーム。

第3章 · Phrase + Memsource(RWS)— 統合後の姿

Phrase は 2014 年にドイツで創業、2017 年に Memsource を買収、2021 年には英国の RWS Holdings に統合された。2026 年現在は 2 つの製品ラインを 1 ブランドで並走させている。

- **Phrase Strings** — 旧 Phrase。キー値ベースの開発者親和 TMS。JSON、YAML、iOS strings、Android xml。

- **Phrase TMS** — 旧 Memsource。XLIFF / TMX ベースの翻訳者親和 CAT(Computer-Aided Translation)ツール。Trados の代替。

コア概念

- **Project + Branching** — Strings 側は Lokalise とほぼ同じキー値モデル。

- **CAT エディタ** — TMS 側は文単位のセグメント、TM マッチ、MT(machine translation)サジェストを 1 画面に。

- **AI Translation** — Phrase NextMT(自社エンジン)+ DeepL + GPT バックエンドを選択可能。Enterprise でドメインチューンモデル。

- **Quality scoring** — MQM(Multidimensional Quality Metrics)ベースの自動品質スコア。

開発者ワークフロー

- **Phrase CLI** — キー sync。公式 GitHub Action と GitLab CI 連携。

- **In-context エディタ** — Web アプリに SDK を入れると、翻訳者が実 UI 上でコピーを編集。(Tolgee 影響)

- **OTA(Over-The-Air)** — モバイルアプリの翻訳をアプリ再配信なしでプッシュ。

価格

- Strings:$135/月から。キー・ユーザが増えると急速に高くなる。

- TMS:要相談。エンタープライズ中心。

強みと弱み

- 強み:TMS と Strings の両ワークフローをカバー。RWS のグローバル翻訳者ネットワーク直結。MQM 品質測定が標準サポート。

- 弱み:2 製品の UX が統合途中で一貫性に欠ける、との評。価格は Lokalise よりやや高め。

いつ選ぶか

翻訳エージェンシーと協業するエンタープライズ、またはモバイルアプリの OTA 更新が必要なチーム。RWS と既存関係があるなら自然な選択。

第4章 · Crowdin — OSS プロジェクト親和

Crowdin は 2009 年にウクライナで創業。2026 年現在、OSS とゲームコミュニティ翻訳の事実上のスタンダード。React Native、Docker、Discord、Minecraft、Telegram のローカライズはすべて Crowdin で回っている。

コア概念

- **Crowdin for Open Source** — 公式の OSS 無料プラン(承認制)。キーと翻訳者が無制限。

- **Pre-translation** — Memsource MT + DeepL + ChatGPT バックエンド選択。

- **Community translation** — 匿名・ログイン済みユーザが翻訳を提案。モデレーターが承認。

- **Vendors marketplace** — プロ翻訳エージェンシーをプロジェクト内から直接コール。

開発者ワークフロー

- **Crowdin CLI** — キー sync。

- **GitHub 連携** — main ブランチの変更検知 → Crowdin に push → 翻訳完了で PR 自動作成。

- **String repository** — 複数プロジェクトで同じキーを再利用。

- **Screenshot context** — キーごとに UI スクリーンショットを添付して翻訳者に文脈提供。

価格

| プラン | 価格 |

| --- | --- |

| Free(小規模) | $0、1 プロジェクト、60,000 文字 |

| Pro | $50/月 |

| Team | $250/月 |

| Business | $450/月 |

| Enterprise | 要相談 |

| OSS | 無料(承認制) |

強みと弱み

- 強み:OSS プランが圧倒的に寛大。コミュニティ翻訳ツールが最も成熟。ゲーミフィケーション(翻訳者ランキング、バッジ)で自発的な貢献が集まる。

- 弱み:UI が Lokalise / Phrase より少し古めかしい。エンタープライズ RBAC / SSO / 監査ログは追加料金。

いつ選ぶか

OSS プロジェクト、ゲームコミュニティ、ユーザ自身が翻訳に参加する製品。「翻訳者を雇うのではなく募集したい」ケース。

第5章 · Tolgee — オープンソース in-context エディタ

Tolgee は 2020 年にチェコで創業した比較的新しい OSS TMS。2026 年現在 GitHub 4,500+ star、MIT ライセンス。セルフホストと SaaS の両方を提供。

シグネチャ機能 — in-context エディタ

Tolgee の代名詞は **開発サーバ上で Alt + クリックで コピーを その場で 編集できる** こと。React / Vue / Angular の SDK が DOM に隠しマーカを埋め、Tolgee ブラウザ拡張がそれを拾う。デザイナー・PM が直接 UI 上で翻訳を直す。

// React 例

const tolgee = Tolgee()

.use(DevTools())

.use(FormatIcu())

.init({

apiUrl: 'https://app.tolgee.io',

apiKey: process.env.NEXT_PUBLIC_TOLGEE_API_KEY,

language: 'ja',

})

export default function App() {

return (

)

}

コア概念

- **Screenshot auto-capture** — キーが画面に現れるたびに自動でスクリーンショット。

- **Translation memory** — 自社 TM + DeepL / OpenAI 自動翻訳の統合。

- **Activity** — キーごとの変更履歴。誰がいつ何を変えたか。

- **CLI + Push/Pull** — JSON、YAML、xliff、Apple strings など。

価格

| プラン | 価格 | キー |

| --- | --- | --- |

| Free | $0 | 1,000 string、3 ユーザ |

| Cloud Standard | $69/月 | 10,000 string |

| Cloud Enterprise | 要相談 | 無制限 |

| Self-hosted Free | $0 | 無制限(小規模チーム) |

| Self-hosted Business | 要相談 | SSO、監査ログ |

強みと弱み

- 強み:in-context エディタが最もなめらか。OSS でセルフホスト可能。Lokalise / Phrase より大幅に安い。

- 弱み:エコシステムがまだ小さい。翻訳者マーケットプレイス・エージェンシー連携が弱い。

いつ選ぶか

「PM・デザイナーが直接コピー修正」が必要な小規模チーム、データを外部に出したくないスタートアップ、Phrase / Lokalise の価格がきついシード期チーム。

第6章 · Weblate(チェコ OSS) / Localazy / POEditor

Lokalise・Phrase・Crowdin が SaaS トップ 3 だとすれば、このカテゴリは「OSS コミュニティ・中規模チーム」がよく選ぶ次の 3 つ。

Weblate — GPL フルスタックセルフホスト

- 2012 年にチェコの Michal Čihař が開始。GPL ライセンス、GitHub 4,700+ star。

- gettext PO 中心。Linux デスクトッププロジェクト(GNOME、KDE)翻訳のスタンダード。

- セルフホストが本当に楽。Docker compose 一発。Postgres + Redis のみ。

- Hosted Weblate(SaaS)もあり、OSS プロジェクトは無料ホスティングを申請可能。

- AI 自動翻訳:DeepL / Google / Microsoft / OpenAI バックエンドを選択。

- 弱み:UI がやや古めかしい。モバイルアプリワークフロー(iOS strings、Android xml)は Lokalise 比で弱い。

Localazy — もうひとつのチェコ勢

- 2019 年にチェコで立ち上げ。「自動化 + コミュニティ翻訳マーケットプレイス」のコンセプト。

- ShareTM — コミュニティ翻訳メモリ。他プロジェクトの翻訳を無料で再利用。

- モバイルアプリ親和。iOS / Android / React Native / Flutter SDK が充実。

- 価格:Free 1,000 source、Startup $39/月、Pro $129/月。

- 強み:価格に対する機能が良い。自動化と CLI が洗練されている。

POEditor

- 2012 年にルーマニアで立ち上げ。最も古典的なキー値 TMS。

- 価格が最も低め(Free 1,000 string、Start $14.99/月)。

- UI はミニマル。小規模チームには十分。

- GitHub、GitLab、Bitbucket、Azure DevOps すべてに直接連携。

比較サマリ

| ツール | OSS? | セルフホスト | 強み | 弱み |

| --- | --- | --- | --- | --- |

| Weblate | GPL | 可 | Linux デスクトップ / OSS の標準 | UI が古め |

| Localazy | 不可 | 不可 | モバイル親和、ShareTM | セルフホスト不可 |

| POEditor | 不可 | 不可 | 最安、シンプル | 高度な機能は弱い |

第7章 · Lingo(Locize) / Transifex / Smartling — その他

Lingo / Locize — フラット料金、i18next の兄弟

- Lingo は Locize にリブランド済み。i18next メンテナの Jan Mühlemann が作った TMS。

- 核心:**フラット料金**。100,000 キーで €25/月のように、使用量と無関係の価格。

- i18next との完全統合。`i18next-locize-backend` 1 行で完了。

- AI 自動翻訳統合(DeepL、Google)。

- 弱み:UI デザインが比較的シンプル。デザイナー親和ワークフローは Lokalise / Phrase に劣る。

- いつ選ぶか:i18next を使う React / Node チーム、価格予測可能性が重要な場所。

Transifex — 古参の強者

- 2007 年ギリシャで創業。最古参の SaaS TMS の 1 つ。

- WordPress、Mozilla、Eclipse の翻訳インフラ。

- 2020 年代に Lokalise / Phrase に押されたが依然安定。

- 「Live」機能:in-context 編集、Tolgee より先に試みた。

- 価格:Starter $70/月、Growth $250/月。

- 強み:安定性、長年の連携。

- 弱み:革新スピードが遅く UI が古めかしい。

Smartling — エンタープライズ専用

- 2009 年に米国で創業。Lyft、British Airways、Pinterest などグローバルエンタープライズが顧客。

- 自社 TMS + 自社翻訳エージェンシーネットワークが結合したフルスタック。

- LanguageAI — 自社 AI 翻訳 + 人手レビューワークフロー。

- 価格は要相談。基本 6 桁。

- 強み:エンタープライズコンプライアンス(SOC2、ISO 27001、GDPR)、エージェンシー品質保証。

- 弱み:小規模チームには過剰、価格の入り口が高い。

第8章 · AI 翻訳 — DeepL / GPT-4o / Claude / Gemini / Reverso

TMS がインフラなら AI はエンジン。2026 年現在、翻訳品質の新基準は LLM ベース。

DeepL — 依然強い専門翻訳エンジン

- ドイツ・ケルン所在。2017 年リリース以来、EU 言語ペア(独・仏・伊・西・葡・蘭)で Google / Microsoft を上回るとの評を維持。

- 2024 年に DeepL Write(ライティング補助)、2025 年に LLM ベースの次世代エンジンをリリース。

- 強み:フォーマル/インフォーマルトグル、用語集精度、ドメインモデル(法律・財務など)。

- 弱み:アジア言語(韓・中・日)では GPT-4o / Claude にやや劣るとの声。

- 価格:API Pro $5.49/月から + 使用量。

GPT-4o(OpenAI) translation

- OpenAI の 4o モデルは 100+ 言語の翻訳で上位。

- 強み:文脈意識(前後の文を見て意味を決定)、コードコメント翻訳、Markdown / HTML 構造保持。

- 弱み:時折ハルシネーション。LLM 単体では用語集遵守が 100% でない → RAG / few-shot が必要。

- 価格:input $2.50/1M token、output $10/1M token。

Claude(Anthropic)translation

- Claude Sonnet / Opus は長文ドキュメント翻訳に強い。1M token コンテキストで本 1 冊を一度に。

- トーン維持(ブランド voice)能力が高いと評される。

- 安定性・幻覚率が GPT 比で低いとの報告が多い(2025 年の複数ベンチマーク)。

- 価格:Sonnet input $3/1M、output $15/1M。

Gemini(Google) translation

- Google の本拠地。100+ 言語、Vertex AI Translate API と LLM API の二系統。

- 強み:Google の既存翻訳コーパス + LLM の結合。多言語 OCR・ドキュメント翻訳に強い。

- 価格:1.5 Pro input $1.25/1M、output $5/1M。

Reverso

- 1998 年フランス創業。翻訳 + 文脈検索(実ドキュメントコーパスから類似例文を見せる)。

- 翻訳者が「単語ニュアンスチェック」用に併用。

- B2C ツール。API もあるがインフラ級ではない。

Anthropic translation API + 韓・日メジャー

- Anthropic は専用「translation API」を提供せず、Messages API に system prompt + 用語集で処理。

- 韓国の Papago、Kakao i Translation、日本の NTT、DeepL 日本データセンターは第 13・14 章で個別に扱う。

品質比較(韓・英・日 2025 社内ベンチマーク参照)

| エンジン | 韓↔英 | 韓↔日 | トーン / ブランド voice | ドメイン用語精度 |

| --- | --- | --- | --- | --- |

| DeepL | 上 | 上 | 中 | 上(用語集使用時) |

| GPT-4o | 上 | 上 | 上 | 中(few-shot 要) |

| Claude Sonnet | 上 | 上 | 最上 | 中 |

| Gemini 1.5 Pro | 上 | 上 | 中 | 中 |

| Papago | 最上(韓↔英) | 上 | 中 | 中 |

| Google Translate | 中 | 中 | 下 | 下 |

第9章 · Lingo.dev — LLM ベース localization-as-code

Lingo.dev(旧 Replicant.ai Translation)は 2024 年に登場した新陣営。発想が違う:**「翻訳は git diff のように PR で扱うべき」**。

コアアイデア

- 開発者が `en.json` を編集すると、Lingo CLI が LLM(OpenAI / Anthropic / Google を選択)で自動翻訳し、`ko.json` / `ja.json` を作って PR を開く。

- 翻訳者・TMS なしで OSS や小規模チームが多言語製品を回せる。

- TMS のキー値同期の代わりに、git diff が真実。

例

インストール

npm i -g lingo.dev

初期化

lingo init

i18n.json

{

"source": "en",

"targets": ["ko", "ja", "zh-CN"],

"files": ["locales/*.json"],

"model": "anthropic/claude-sonnet-4",

"glossary": "glossary.json"

}

自動翻訳 → PR 作成

lingo translate --open-pr

強み

- TMS コスト節約。シード〜シリーズ A のスタートアップに合理的。

- LLM モデル選択の自由。Claude / GPT / Gemini バックエンドを差し替え可能。

- 用語集でブランド用語を制御。

- git diff で翻訳履歴が自然に管理される。

弱み

- 人手翻訳者ワークフローがない。「法的・規制コピー」は依然 TMS + 人手レビューが安全。

- マイナー言語(スワヒリ、ペルシャ語など)で LLM 品質がばらつく。

- 大量翻訳時に LLM API コストが TMS の定価より高くなることもある。

いつ選ぶか

OSS プロジェクト、小規模 SaaS、マーケサイト、ブログ。「1 人のフルスタックが i18n インフラまで担当する」チーム。

競合

- **Locale.dev** — 2025 年登場。Lingo.dev とほぼ同等。PR ベース。

- **OpenStrings** — OSS ライブラリ。LLM 翻訳 + cache 管理を内蔵。

第10章 · ICU MessageFormat — 複数形 / 性別の処理

上層を整理したので標準仕様まで降りる。ICU(International Components for Unicode)は IBM・Unicode が作った i18n 標準。**MessageFormat** は複数形・性別・日付のような厄介なフォーマットを 1 つの文字列内で処理する。

なぜ必要か

英語の「1 item / 2 items」は簡単だが、ロシア語は単数・少数・複数の 3 形があり、アラビア語は 6 形ある。日本語は複数形がない(同じ単語)。韓国語は「1個・2個」のように単位(助詞)が別に付く。これらを 1 キーで表現する文法。

{count, plural,

=0 {No items}

one {# item}

other {# items}

}

上の文法を ICU MessageFormat と呼ぶ。JavaScript、Java、Swift、Kotlin、Go すべてに ICU 互換ライブラリがある。

韓国語 / 日本語の特殊性

韓国語: {count, plural, other {#개 아이템}}

日本語: {count, plural, other {#件}}

韓国語は plural ルールが単純(全て `other`)だが、助詞(은/는、이/가、을/를)処理は ICU では解けない。そのため韓国語 i18n では別の助詞ヘルパを使うか、文章自体を再構成する。

Select(性別 / 文脈)

{gender, select,

male {彼が登録しました}

female {彼女が登録しました}

other {彼/彼女が登録しました}

}

SelectOrdinal(序数)

{position, selectordinal,

one {#st}

two {#nd}

few {#rd}

other {#th}

}

MessageFormat 2.0(MF2)

- 2024 年に Unicode が MessageFormat 2.0 の初の安定リリースを発表。

- 旧 MF の厄介な escape・ネスト問題を改善。

- 2026 年現在、i18next・FormatJS・LinguiJS すべてが MF2 をサポート中。

第11章 · i18next — JS i18n のスタンダード

JavaScript エコシステムで最も広く使われる i18n ライブラリ。2011 年開始、2026 年現在 npm 週間ダウンロード 8M+。React、Vue、Svelte、Node、Express、Electron など、ほぼどこでも動く。

コア概念

- **i18next core** — 環境非依存のコア。キー lookup、補間(interpolation)、複数形、ネームスペース。

- **react-i18next, vue-i18next** — フレームワークバインディング。

- **Backends** — locize、http、fs、chained など多彩。

- **Plugins** — language detector、ICU formatter、postProcessor など。

例(React)

i18n.use(initReactI18next).init({

resources: {

en: { translation: { welcome: 'Hello, {{name}}' } },

ja: { translation: { welcome: 'こんにちは、{{name}}' } },

},

lng: 'ja',

fallbackLng: 'en',

})

function Greeting({ user }) {

const { t } = useTranslation()

return <h1>{t('welcome', { name: user.name })}</h1>

}

上記の例の `{{name}}` のようなプレースホルダは MDX 本文で扱うとき常にインラインコードで囲むこと(空の式でなくとも、MDX が JSX 式として解釈するケースを回避するため)。

ネームスペース

大きなアプリは 1 つの JSON にすべてのキーを詰め込まない。

{

"common": { "save": "保存" },

"checkout": { "title": "決済" }

}

`t('checkout:title')` のようにコロンでアクセス。

複数形処理

i18next は独自の複数規則(`_one` / `_other` サフィックス)を提供するが、ICU 互換モードもある。`i18next-icu` プラグイン有効化で MF1 / MF2 構文がそのまま使える。

Lazy loading

- HTTP backend で言語別 chunk 分割 → 初期バンドルが軽くなる。

- Next.js / Remix と統合すると SSR 内でキー prefetch。

強みと弱み

- 強み:エコシステムサイズ・プラグイン数が圧倒的。backend が自由。

- 弱み:API がやや重い。React Server Component / App Router 親和度は next-intl / use-intl の方が良いとの評。

第12章 · FormatJS / react-intl — React i18n

FormatJS は Yahoo が作った i18n ツールチェーン。看板は **ICU MessageFormat が 1 級市民**。

構成

- **@formatjs/intl** — コア。Intl API(Web 標準)をラップ。

- **react-intl** — React バインディング。

- **@formatjs/cli** — メッセージ抽出(extract)ツール。ソースから `defineMessages` 呼び出しをすべて収集。

- **@formatjs/icu-messageformat-parser** — ICU パーサ。

例

const messages = {

ja: { greeting: 'こんにちは、{name}さん' },

en: { greeting: 'Hello, {name}' },

}

function App() {

return (

)

}

強み

- ICU MessageFormat が 1 級市民。複数形・性別・日付・数値フォーマットの一貫性。

- メッセージ抽出 CLI が強力。ソース → JSON 自動生成 → TMS push。

- `<FormattedNumber>`・`<FormattedDate>`・`<FormattedRelativeTime>` などコンポーネント親和。

弱み

- React 以外の環境で i18next ほど万能ではない。

- メッセージキーが長くなるとデバッグが大変。

その他の React i18n ツール

- **next-intl** — Next.js App Router 最適化。SSG / SSR の両方をサポート。

- **LinguiJS** — JSX インライン翻訳コンポーネント(`<Trans>`)。メッセージ ID 自動生成。

- **FBT** — Meta(Facebook)が作ったライブラリ。独自トークナイザで複合文を処理。

第13章 · 韓国 — Papago、Kakao i 翻訳

グローバルツールだけを扱うには韓国市場が独特すぎる。

Naver Papago

- 2016 年リリース。2026 年現在、韓国内で圧倒的 1 位の翻訳サービス。

- 強み:韓↔英、韓↔日、韓↔中でグローバルエンジン比優位。とくに韓↔英の自然さが秀逸。

- API:Naver Cloud Platform(NCP)Papago Translation。1 日 10,000 文字無料、以降は文字単位課金。

- 2024 年に LLM ベース次世代エンジン(HyperCLOVA X ベース)を導入。

- 弱み:非英語・非アジア言語ペアは弱い。欧州言語は DeepL が優位。

Kakao i Translation

- Kakao Enterprise が運営。KakaoTalk・Daum 検索と統合。

- API は Kakao i Cloud。Papago に比べシェアは低いが Kakao エコシステム内統合が強み。

- ビジネスコンテンツ・ニュースドメインに fine-tune されたモデルを別途提供。

利用パターン

- 韓国企業の一般的な i18n スタック:TMS(Lokalise / Crowdin)+ DeepL / Papago の併用 + 社内レビュー。

- B2C コンテンツ翻訳(Webtoon、Web 小説、メディア)は Papago / Kakao + 人手レビュー。

- グローバル SaaS は DeepL / Claude / GPT がより一般的。

Papago API 呼び出し例

const res = await fetch('https://naveropenapi.apigw.ntruss.com/nmt/v1/translation', {

method: 'POST',

headers: {

'X-NCP-APIGW-API-KEY-ID': process.env.PAPAGO_ID,

'X-NCP-APIGW-API-KEY': process.env.PAPAGO_KEY,

'Content-Type': 'application/x-www-form-urlencoded',

},

body: new URLSearchParams({

source: 'ko',

target: 'en',

text: '안녕하세요',

}),

})

第14章 · 日本 — NICT VoiceTra、NTT、Cygames in-house

NICT VoiceTra

- 日本の国立研究開発法人 情報通信研究機構(NICT)が作った多言語音声翻訳システム。

- 31 言語のテキスト翻訳 + 17 言語の音声認識・合成。

- 政府・観光インフラ(JR 駅、空港)で広範に使われる。気象庁・税関も採用。

- 無料アプリ(VoiceTra)提供。学術・公共機関向けの優遇 API。

- 強み:日本語ドメイン特化(法律、医療、観光、災害対応)の fine-tune。

NTT — COTOHA Translator・tsuzumi

- NTT グループの AI 部門 NTT 人工知能研究所が運営。

- COTOHA Translator — ビジネスドキュメント特化。日本の大企業 100+ が採用。

- tsuzumi(2024)— NTT 自社 LLM。日本語特化で OpenAI 比の日本語表現の自然さを強調。

- 日本国内データセンター運営 → データ主権・金融・医療業界で好まれる。

Cygames など ゲーム会社の in-house

- 日本の大手ゲーム会社(Cygames、Square Enix、Bandai Namco)は社内 LQA(Localization Quality Assurance)チーム + 独自翻訳ワークフローを持つ。

- Crowdin・Lokalise・Phrase を使いつつ、社内用語集とキャラクター voice DB を別管理。

- Cygames は最近 LLM ベースの社内翻訳ツールを構築し、日本語 → 英・中・韓を 1 次翻訳した後に人手 LQA が仕上げるワークフローを定着させた。

日本市場の特殊性

- 漢字・カタカナ・ひらがなの 3 スクリプト混在。LLM の処理能力はモデルにより差が大きい。

- 敬語(尊敬語・謙譲語・丁寧語)— ビジネスコンテンツで決定的。

- 英語借用語をカタカナで写すか、もとの漢字・日本語で表現するかはドメインごとに異なる。

第15章 · 誰が何を選ぶべきか — OSS / スタートアップ / グローバル / セルフホスト

これまでの整理を 4 シナリオで答える。

OSS プロジェクト(コミュニティ翻訳)

- **第一選択**:Crowdin OSS プランまたは Weblate。

- **理由**:無料、コミュニティ翻訳ツールが成熟。

- **ライブラリ**:i18next、gettext。

- **AI 補助**:pre-translation 機能で DeepL / OpenAI バックエンドを活用。

- **セルフホスト優先なら**:Weblate。

B2B SaaS スタートアップ(シード〜シリーズ A)

- **第一選択**:Tolgee Cloud または Lingo.dev。

- **理由**:価格が合理的。Tolgee は in-context 編集、Lingo.dev は PR ベース自動化。

- **ライブラリ**:i18next + react-i18next、または next-intl(Next.js)。

- **AI 補助**:Claude / GPT-4o API を直接呼ぶか、Tolgee 内蔵の自動翻訳。

グローバルエンタープライズ

- **第一選択**:Phrase(RWS)または Lokalise。

- **理由**:コンプライアンス(SOC2 / ISO / GDPR)、エージェンシーワークフロー、MQM 品質測定。

- **AI + 人手レビュー ワークフロー**:DeepL + 自社 fine-tune + 翻訳者レビュー。

- **コンプライアンス最優先なら**:Smartling。

セルフホスト(規制・機密)

- **第一選択**:Tolgee self-hosted または Weblate。

- **理由**:データが外部に出ない。医療、金融、政府。

- **AI 統合**:社内 LLM(例:Llama 3.3、Qwen 2.5)または Azure OpenAI プライベートエンドポイント。

アンチパターン 7 つ

1. 「TMS 一つで全部済む」— TMS はインフラに過ぎず、ライブラリ(i18next など)なしではランタイムが破綻。

2. AI 翻訳だけ信じてレビュー省略 — ブランド voice・法的コピーが壊れる。

3. キー名を英文メッセージにする — メッセージ変更でキーも変わり git diff が暴走。ID は意味ベースで。

4. ICU MessageFormat を使わず if / else で複数形分岐 — 新言語追加のたびにコード変更。

5. すべてのページの全キーを一括ロード — バンドルサイズ・SSR 時間が暴走。lazy load を。

6. 用語集なしの LLM 翻訳 — ブランド名・製品名が毎回違う形で出てくる。

7. セルフホスト OSS ツールのデータをバックアップしない — Weblate・Tolgee も DB は定期バックアップ必須。

次回予告

- 次の候補:**i18n ライブラリ徹底比較 — i18next vs FormatJS vs next-intl vs Lingui のコード比較**、**MessageFormat 2.0 移行実践**、**LLM 翻訳の品質評価(MQM / BLEU / COMET)と社内ベンチマーク作り**。

> 「TMS はキー値を管理し、ライブラリはランタイムをレンダリングし、AI は raw 翻訳を作り、人間はトーンと文脈を担う。4 層のどれが欠けても i18n は崩れる。」

— ローカライゼーション & i18n ツール 2026、終わり。

参考 / References

- [Lokalise — Translation Management Platform](https://lokalise.com/)

- [Phrase — Localization Platform (RWS)](https://phrase.com/)

- [Phrase TMS (formerly Memsource)](https://phrase.com/platform/tms/)

- [Crowdin — Localization Management](https://crowdin.com/)

- [Crowdin Open Source program](https://crowdin.com/page/open-source-project-setup-request)

- [Tolgee — Open source localization](https://tolgee.io/)

- [Tolgee GitHub — tolgee/tolgee-platform](https://github.com/tolgee/tolgee-platform)

- [Weblate — Web-based translation](https://weblate.org/)

- [Weblate GitHub — WeblateOrg/weblate](https://github.com/WeblateOrg/weblate)

- [Localazy — Localization for mobile and web](https://localazy.com/)

- [POEditor — Translation management](https://poeditor.com/)

- [Lingo (Locize) — i18next backend service](https://www.locize.com/)

- [Transifex — Localization platform](https://www.transifex.com/)

- [Smartling — Translation Services & Software](https://www.smartling.com/)

- [Lingo.dev — LLM localization-as-code](https://lingo.dev/)

- [Locale.dev — AI translation for developers](https://locale.dev/)

- [DeepL — Translator and Pro API](https://www.deepl.com/)

- [DeepL Pro API documentation](https://developers.deepl.com/)

- [OpenAI API — GPT-4o models](https://platform.openai.com/docs/models/gpt-4o)

- [Anthropic Claude API — Messages](https://docs.anthropic.com/en/api/messages)

- [Google Gemini API](https://ai.google.dev/)

- [Reverso Context](https://context.reverso.net/translation/)

- [i18next documentation](https://www.i18next.com/)

- [i18next GitHub — i18next/i18next](https://github.com/i18next/i18next)

- [react-i18next](https://react.i18next.com/)

- [FormatJS — Internationalize your web apps](https://formatjs.io/)

- [react-intl documentation](https://formatjs.io/docs/react-intl/)

- [next-intl — Next.js i18n](https://next-intl-docs.vercel.app/)

- [LinguiJS](https://lingui.dev/)

- [FBT — Facebook i18n framework](https://facebook.github.io/fbt/)

- [ICU MessageFormat — Unicode CLDR](https://unicode-org.github.io/icu/userguide/format_parse/messages/)

- [MessageFormat 2.0 specification](https://unicode-org.github.io/message-format-wg/)

- [Unicode CLDR](https://cldr.unicode.org/)

- [XLIFF 2.0 specification — OASIS](https://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html)

- [GNU gettext](https://www.gnu.org/software/gettext/)

- [Naver Papago — Translator](https://papago.naver.com/)

- [Naver Cloud Platform Papago Translation API](https://www.ncloud.com/product/aiService/papagoTranslation)

- [Kakao i Translation](https://kakaoi.ai/)

- [NICT VoiceTra](https://voicetra.nict.go.jp/en/index.html)

- [NTT COTOHA Translator](https://www.ntt.com/business/services/application/ai/cotoha-translator.html)

- [NTT tsuzumi LLM](https://www.rd.ntt/e/research/JN202310_19069.html)

- [MQM — Multidimensional Quality Metrics](https://themqm.org/)