Nimdziがglobalize.nowを審査し、調査会社による言語テクノロジー製品のカタログであるLanguage Technology Radarに掲載しました。globalize.nowはAIを活用したローカライズ基盤で、Nimdziは「開発者向けローカライズ」と「ローカライズ特化型LLMツール」の2か所に分類しています。この記事では、Radarとは何か、globalizeがどこに位置づけられたのか、そしてコードネイティブなローカライズがなぜ独立したカテゴリになったのかを解説します。

Nimdzi Language Technology Radarとは?

Radarは、Nimdzi Insightsが運営する言語テクノロジーのライブデータベースです。年1回の市場スナップショットだった従来のLanguage Technology Atlasに代わり、継続的に更新されるカタログとして提供されています。2026年版には、756社・1,100以上の製品が掲載されています。

製品は、翻訳管理システムや機械翻訳から、音声認識、通訳システムまで、11のカテゴリに分類されています。サブカテゴリを持つカテゴリもあり、製品は、機能の一部が当てはまるかどうかではなく、中核となる提供価値に合った場所に掲載されます。

ツールはどのように審査されるのですか?

企業がデータを提出すると、Nimdziのリサーチャーが、公開情報、提供元とのブリーフィング、そして自らのツール利用をもとに内容を検証します。掲載は無料です。Nimdziは、掲載内容・ランキング・レビューに影響を与えるための手数料は受け取らないと明言しており、だからこそ掲載はバイヤーにとって信頼できる指標となります。

globalizeの場合、プロフィールが完成扱いになるまでに、Radarチームからの一連の質問に答えました。翻訳にどのモデルやエンジンを使っているのか、品質チェックはプラットフォーム外でも機能するのか、修正内容は今後の翻訳にどう引き継がれるのか、といった内容です。カテゴリ分類は、自己紹介ではなく、これらの回答を反映したものです。

globalizeはRadar上のどこに位置していますか?

globalizeは2つのカテゴリに掲載されています。

Translation Management Systems、開発者向けローカライズ。 このサブカテゴリは、翻訳者チームではなくエンジニアリングチーム向けに作られたツールを対象としています。違いは、作業が行われる場所です。従来型のTMSは、文字列を出し入れして同期する独立したワークスペースです。globalizeはリポジトリ内で動作するため、成果物はダッシュボードからのエクスポートではなく、ロケールファイルを含むプルリクエストになります。

Large Language Models、ローカライズ特化型LLMツール。 globalizeは、翻訳に加えて2段階目のレビューにも言語モデルを使い、全言語で意味、プレースホルダー、用語集の用語、スタイルガイドへの適合性をチェックします。このカテゴリは、汎用のチャットではなく、モデルをローカライズ作業に特化して適用しているツールを対象としています。

Nimdziサイト上のプロフィールもご覧いただけます。

なぜ開発者向けローカライズは独立したカテゴリなのですか?

文字列をリリースする人が変わったからです。数年前は、プロダクトチームがコピーをローカライズ担当者に渡し、担当者がTMSで処理してファイルを返す、という流れでした。今では、ひとりで開発する創業者がCursorやLovableで作ったNext.jsアプリを火曜日にリリースし、金曜日までに日本語対応させたいと考えています。ローカライズ担当者はおらず、同期を保つ必要のある新たなダッシュボードを望む人もいません。

この変化によって、解決すべき課題そのものが変わりました。

classic TMS:  code  →  export strings  →  TMS workspace  →  translators  →  import files  →  code
globalize:    code  →  push  →  translated pull request  →  merge

開発者側のニーズは2つに分かれます。1つ目は、そもそもコードベースをローカライズ可能な状態にすることです。AIが生成したアプリの多くは、この状態になっていません。コンポーネントにハードコードされた文字列があり、キーもロケールファイルもないまま出荷されます。globalizeは、アプリ上でリポジトリを接続したときに、これを一度だけ処理します。2つ目は、その後の変更をすべて、誰かが覚えていなくても翻訳できるようにすることです。セットアップ後は、新規または変更されたテキストを含むプッシュのたびに、翻訳を含むプルリクエストとして返ってきます。AIレビュー済みで、そのままマージできる状態です。

では、globalizeはTMSなのですか?

いいえ。NimdziはTMSの見出しの下に開発者向けサブカテゴリを置いていますが、globalizeはTMSではありません。globalizeは、i18nライブラリと翻訳エンジンの間に位置します。next-intlやi18nextといったライブラリは実行時に翻訳を配信する役割を担い、globalizeは既存のどのライブラリとも組み合わせて使えます。LokaliseやCrowdinのような翻訳管理システムは、翻訳者のワークフローを管理します。globalizeはキーとロケールファイルを生成・維持するため、翻訳者のいないチームにはそのワークフロー層がそもそも不要です。2つのアプローチを比較したい方は、Lokalise比較で違いを詳しく解説しています。

globalizeはリポジトリ内で実際に何をするのですか?

GitHubまたはGitLabに接続してリポジトリをスキャンし、アプリで必要であればi18nをセットアップして、レビュー用のブランチに変更をプッシュします。アプリがすでにnext-intl、react-i18next、i18next、Linguiを使っている場合は、その構成を維持したまま翻訳だけを行います。

それ以降は、次の3つが翻訳ジョブのトリガーになります。いずれも、ご自身で制御できる設定です。

  1. 監視対象のブランチへの、新規または変更されたテキストを含むプッシュ。
  2. プルリクエスト(このオプションを有効にした場合)。
  3. ダッシュボードからの手動ジョブ。

各ジョブでは、新規または変更された部分だけを翻訳します。翻訳メモリにすでにある文字列は再利用され、再課金されません。用語集と言語別のスタイルガイドはすべてのジョブに適用され、AIレビューが、デフォルトブランチに反映される前に人の確認が必要な箇所を指摘します。結果は、ロケールファイルだけを変更するプルリクエストとして届きます。

対応フォーマットはWebとモバイルの両方をカバーし、JSON、gettext PO、XLIFF、YAML、Flutter ARB、Apple文字列カタログ、Androidの文字列リソースなどに対応しています。料金はワークスペース単位で、シートごとの課金はありません。最新のプランは料金ページをご確認ください。

開発者にとって、アナリストの掲載はなぜ重要なのですか?

ほとんどの開発者にとっては、大きな違いはありません。globalizeは最初のプルリクエストで判断されるはずで、無料トライアルはまさにそのためにあります。掲載が意味を持つのは、ほかの2つのグループです。

1つ目は、ローカライズ責任者がいるチームです。ツールを評価するローカライズ担当者はNimdziを参照します。独立した審査済みプロフィールがあれば、そのプロダクトが実在し、説明どおりに動作し、見慣れたカテゴリに属していることが伝わります。いきなりデモを行うより、ずっと短い会話で済みます。

2つ目は、従来型のTMSから移行しようとしているバイヤーです。LokaliseやPhraseからコードネイティブな構成へ移ろうとするチームは、本番のカタログを移す前に、その代替手段が本物であることを確かめたいと考えています。Radarへの掲載は、この市場において、ベンダー自身が書くことのできない数少ないシグナルのひとつです。

この先の予定は?

Nimdziは、各ツールを機能ごとにプロファイルするTMS Feature Explorerも運営しており、globalizeのエントリーは現在準備中です。公開されれば、globalizeが何をカバーし、何をあえてカバーしていないのかが項目ごとに示されます。たとえば翻訳者向けエディターやベンダー管理は、コードネイティブなツールが対象とする領域の外にあります。

それまでの間、最も手っ取り早い評価方法は、ご自身のコードで試すことです。リポジトリを接続し、globalizeにセットアップを任せて、最初の翻訳済みプルリクエストを確認してみてください。

globalize.nowは、ハードコードされたアプリ内テキストを翻訳可能なロケールファイルに変換し、リリースのたびに自動で最新の状態を保ちます。

globalize.nowを無料で試す