ローカリゼーションはAIから始まったわけではありません。TMS（翻訳管理システム）から始まったわけでもありません。数十年前、プロダクトチームではなく翻訳者のために作られたツールから始まりました。そしてその遺産は、今もなお業界のあり方を規定しています。
globalize（globalize.now）では、長年にわたりローカリゼーション業界の中でプラットフォームを構築し、顧客と密接に協力しながら、業界の進化を間近で見てきました。
そこで見えてきたのは、こういうことです。ローカリゼーションは緩やかに進化するのではなく、波のように変化するということです。
これまでに大きな転換点が2回ありました。そして今、3回目の、これまでで最も重要な転換が起きています。
CATツール時代のローカリゼーションはどのようなものだったのか？
現代的なローカリゼーションプラットフォームが登場する以前、業界はCATツール（コンピュータ支援翻訳ツール）が主流でした。
これらのツールがもたらしたもの：
- 翻訳メモリ
- 用語データベース
- 体系化されたワークフロー
当時としては大きな進歩でしたが、これらは全く異なる世界を前提に作られていました。
- 孤立した環境で作業する翻訳者
- セグメント単位の翻訳
- プロダクト開発との連携の乏しさ
今日でも、業界の一部はこのモデルに依然として縛られており、それ以降のあらゆる転換は、こうした制約から脱却しようとする動きでした。
ステージ1——デザイン段階でのローカリゼーションとは何だったのか？
最初の大きな転換は、ローカリゼーションがプロダクトライフサイクルのより早い段階へと移行したことでした。
従来、チームは次のような手順を踏んでいました。
- プロダクトを構築する
- 文字列を抽出する
- 後から翻訳する
これにより、ボトルネック、不整合、そして絶え間ない手戻りが発生していました。
現代的なローカリゼーションプラットフォームが登場した初期に顧客と密接に協力する中で、繰り返し挙がってきたテーマがありました。
「ローカリゼーションをもっと早い段階から始める必要がある」
これがデザイン段階でのローカリゼーションの台頭につながり、ローカリゼーションはデザインワークフローに直接組み込まれるようになりました。
チームは次のことに取り組み始めました。
- 複数言語を前提としたデザイン
- より早い段階でのコンテンツ構造化
- 後工程のエンジニアリング作業の削減
なぜこれが重要だったのか：
- グローバルリリースの迅速化
- 手戻りの削減
- プロダクトの一貫性の向上
ローカリゼーションは、後工程の処理からデザイン上の検討事項へと変化しました。
機械翻訳が主流になったステージ2では、何が変わったのか？
2回目の転換は、機械翻訳（MT）によってもたらされました。
機械翻訳は主流になるずっと前から存在していました。初期の頃は、主にアーリーアダプターや実験的なチーム、そして不完全な出力でも構わず使いこなそうとする熱心なユーザーによって利用されていました。
より広く普及したのは、2つの変化が重なってからのことでした。
- ローカリゼーションにおいて、ウォーターフォールではなくアジャイル開発が標準的な働き方として定着したこと。
- デザイン段階でのローカリゼーションへの移行
チームがより速く出荷し、継続的なサイクルで開発を進めるようになるにつれ、スピードとスケーラビリティの必要性が決定的に重要になりました。
こうした環境の中で、機械翻訳は単に便利なものではなく、不可欠なものとなりました。
新しいモデルが登場しました。
- 機械翻訳が初稿を生成する
- 人間がレビューして仕上げる
なぜこれが重要だったのか：
- 翻訳スピードの飛躍的な向上
- グローバル展開にかかるコストの低減
- 継続的ローカリゼーションの実現
ローカリゼーションは、手作業のプロセスからテクノロジーによって強化されたシステムへと進化しました。
ステージ3——AI主導のローカリゼーションの転換とは何か？
私たちは今、根本的に異なる第3のステージに突入しつつあります。
AIはローカリゼーションを改善しているだけではありません。それをまったく新しく定義し直しています。それと同時に、新世代のビルダーたちが台頭しています。
- インディー開発者
- スタートアップの創業者
- AIネイティブなチーム
こうしたビルダーたちは、これまで以上のスピードでプロダクトを出荷していますが、ローカリゼーションはそれに追いついていません。
今日の開発者の多くは：
- 多言語対応を前提としてアプリを構造化していない
- 用語集やスタイルガイドを作成していない
- 問題になるまでローカリゼーションについて考えない
そして、これまで利用可能だったツールは、前の時代に合わせて作られたものでした。
ギャップ
今、次の2つの間にギャップが広がりつつあります。
- プロダクトの構築スピード
- グローバル展開のスケーラビリティ
そのギャップこそが、プロダクトの国際化が効果的に機能しない原因となっています。
AIネイティブなローカリゼーションへの転換
ここから次の進化が始まります。
ローカリゼーションは、もはや次のようなものではありません。
- 独立したワークフロー
- 専門職の担当領域
- 後から発生するもの
それは、次のようなものになります。
- 自動化されたもの
- 開発プロセスに組み込まれたもの
- 初日からAIによって駆動されるもの
globalizeはこの転換に向けてどのように作られているのか
globalize（globalize.now）は、まさにこの新しい現実のために構築されています。
開発者にローカリゼーションを学ばせるのではなく、私たちは次のことを行います。
- リポジトリへ直接接続する
- 既存のコンテンツからローカリゼーションファイルを生成する
- 用語集とスタイルガイドを自動的に構築する
- AIワークフローと統合する
これらすべてを、単一の合理化されたプロセスで実現します。
開発者はローカリゼーションの仕組みについて考える必要がなく、ただ開発を進めるだけで、プロダクトはグローバル展開できる状態になっています。
ローカリゼーションは、プロセスからインフラへとどのように移行しつつあるのか？
これらのステージを通じて、ローカリゼーションは進化してきました。
そして今、それはまったく別のものへと変わりつつあります。プロセスとしてのローカリゼーションではなく、インフラとしてのローカリゼーションへ。
AIで開発・出荷するチームにとって、本当の教訓とは何か？
AIは単にローカリゼーションを加速させているだけではありません。
現行モデルがいかに機能不全に陥っているかを露呈させているのです。
なぜなら、問題は翻訳そのものではなかったからです。
問題は常にコードにありました。
今日、何千ものアプリがAIによって生成されています——高速で、機能的である一方、グローバルユーザーへの対応がまったくできていません。
ハードコードされた文字列。構造もなければ、システムもない。
そして、そうしたチームが展開を決断したとき、まず翻訳から始めるわけではありません。
書き直しから始めるのです。
それが、今起きている転換です。
ローカリゼーションは、もはや後から追加するものではありません。
それは、コードベースが対応しているか、それとも抵抗しているか、そのどちらかなのです。
Cursor、Copilot、あるいは類似のツールからUIを出荷している場合は、globalize.nowがAI生成アプリを翻訳対応状態に保つ仕組みをご覧ください。
ハードコードされた英語が翻訳ワークフローとなぜ衝突するのかについては、AI生成コードが露呈させた、欠落したi18nレイヤーをお読みください。
勝つのは、より速く翻訳できる企業ではありません。
勝つのは、プロダクトが最初からグローバル対応済みである企業です。
それ以外の企業は、皆同じ壁にぶつかることになります。
「もう一つ言語が必要だ」
そして、自分たちが構築したものがスケールしないことに気づくのです。
globalize.nowは、ハードコードされたアプリ内テキストを翻訳可能なロケールファイルに変換し、リリースのたびに自動で最新の状態を保ちます。
globalize.nowを無料で試す