ローカライゼーション & i18n ツール 2026 — Lokalise / Phrase / Crowdin / Tolgee / Weblate / DeepL / Lingo.dev 徹底ガイド

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

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・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 月時点)

強みと弱み

• 強み: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 スクリーンショットを添付して翻訳者に文脈提供。

価格

強みと弱み

• 強み: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 例
import { Tolgee, TolgeeProvider } from '@tolgee/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 (
    <TolgeeProvider tolgee={tolgee}>
      <Page />
    </TolgeeProvider>
  )
}

コア概念

• Screenshot auto-capture — キーが画面に現れるたびに自動でスクリーンショット。
• Translation memory — 自社 TM + DeepL / OpenAI 自動翻訳の統合。
• Activity — キーごとの変更履歴。誰がいつ何を変えたか。
• CLI + Push/Pull — JSON、YAML、xliff、Apple strings など。

価格

強みと弱み

• 強み: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 すべてに直接連携。

比較サマリ

第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 社内ベンチマーク参照)

第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)

import i18n from 'i18next'
import { initReactI18next, useTranslation } from 'react-i18next'

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 パーサ。

例

import { IntlProvider, FormattedMessage } from 'react-intl'

const messages = {
  ja: { greeting: 'こんにちは、{name}さん' },
  en: { greeting: 'Hello, {name}' },
}

function App() {
  return (
    <IntlProvider locale="ja" messages={messages.ja}>
      <FormattedMessage id="greeting" values={{ name: '太郎' }} />
    </IntlProvider>
  )
}

強み

• 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
• Phrase — Localization Platform (RWS)
• Phrase TMS (formerly Memsource)
• Crowdin — Localization Management
• Crowdin Open Source program
• Tolgee — Open source localization
• Tolgee GitHub — tolgee/tolgee-platform
• Weblate — Web-based translation
• Weblate GitHub — WeblateOrg/weblate
• Localazy — Localization for mobile and web
• POEditor — Translation management
• Lingo (Locize) — i18next backend service
• Transifex — Localization platform
• Smartling — Translation Services & Software
• Lingo.dev — LLM localization-as-code
• Locale.dev — AI translation for developers
• DeepL — Translator and Pro API
• DeepL Pro API documentation
• OpenAI API — GPT-4o models
• Anthropic Claude API — Messages
• Google Gemini API
• Reverso Context
• i18next documentation
• i18next GitHub — i18next/i18next
• react-i18next
• FormatJS — Internationalize your web apps
• react-intl documentation
• next-intl — Next.js i18n
• LinguiJS
• FBT — Facebook i18n framework
• ICU MessageFormat — Unicode CLDR
• MessageFormat 2.0 specification
• Unicode CLDR
• XLIFF 2.0 specification — OASIS
• GNU gettext
• Naver Papago — Translator
• Naver Cloud Platform Papago Translation API
• Kakao i Translation
• NICT VoiceTra
• NTT COTOHA Translator
• NTT tsuzumi LLM
• MQM — Multidimensional Quality Metrics