私たちがお話しするエンタープライズは、どこも同じ2つの壁にぶつかります。
1つ目は、一貫性を保つための調整コストです。
Androidアプリはあるチーム、Webアプリは別のチーム。マーケティングサイト、ドキュメント、社内ツールも、それぞれ別のチームが担い、それぞれに独自のリリースサイクル、レビュー担当者、出荷パイプラインがあります。
従来のツールでも、翻訳メモリや用語集をプロジェクト間で共有できます。ワークスペースもある。組織レベルのアセットもある。ですが、共有されていても、それが強制されるわけではありません。共有用語集の用語は翻訳者への提案であって、モデルへの制約ではないのです。チーム間の一貫性は、結局は運用の規律に委ねられます。誰かが用語集の整合を保ち、誰かがチーム間の用語衝突を解消し、あるチームがCTAをこう訳したのに別のチームは別の表現で出してしまう、といったズレを誰かが追い続ける。一貫性の実現は可能です。ですが、維持は終わりなく続きます。
しかも、各チームのプロジェクト内では、そのズレがさらに積み上がっていきます。翻訳メモリが一貫性を保てるのは、セグメントが変わらないあいだだけです。毎週リファクタリングが入るコードベースでは、セグメントも毎週変わります。私たちのRAL researchは、モデルに検索されたコンテキストがないとき、用語のズレがどれほど速く進むかを測定しています。
2つ目の壁は、こうしたコストを生み出すツール群から抜け出すこと自体のコストです。エンタープライズでは、あらゆる要素が掛け算で膨らみます。チーム横断で蓄積された用語集、プロジェクトごとにTMXやベンダー独自形式で積み上がった翻訳メモリ、各チームのCIに組み込まれたコネクタ、調達経由で契約された翻訳者体制、IdPと統合されたSSO。
結果として移行は、どのローカリゼーションマネージャーも引き受けたくない、複数四半期にまたがるエンジニアリングプログラムに見えてしまいます。
このマルチチーム構成に合うアーキテクチャは、2つあります。
1つは、プロジェクトスコープの翻訳メモリを、推論時にコンテキストを検索する組織スコープのローカライゼーションエンジンに置き換えること。用語集は1つ、ブランドボイスも1つ。すべてのチームのアプリが同じローカライゼーションエンジンを参照します。
もう1つは、顧客自身が移行を担うやり方を、Lingo.devのフォワードデプロイ型ローカリゼーションエンジニアがあなたではなく私たちの時間で移行を進めるやり方に置き換えることです。
どちらのパターンも、すでにスタック内の他のあらゆるインフラで使われています。今こそ、ローカリゼーションもようやく追いつくべきです。
アーキテクチャ #1: ローカライゼーションエンジン#
ローカライゼーションエンジン
チームがLingo.dev上で作成する、組織単位で設定されたステートフルな翻訳APIです。各ローカライゼーションエンジンは、それぞれ独自の用語集、ブランドボイス、ロケール固有の指示、ランク付きのモデルチェーンを保持します。各リクエストでは、一致する用語集の用語を検索し、最初のトークンが生成される前にモデルのコンテキストウィンドウへ注入します。さらに、完了後には独立してスコアリングされます。最初の翻訳はコンテキストなしで始まり、1000回目の翻訳はそれまでの蓄積すべての恩恵を受けます。
ローカライゼーションエンジンが保つのは、セグメント単位ではなく用語単位の一貫性です。スコープは単一チームのプロジェクトではなく、組織全体。用語集は1つ、ブランドボイスも1つ。あらゆるチームのサーフェスが同じローカライゼーションエンジンを参照します。
「Submit」に対するglossaryエントリは、ボタン、メール件名、ツールチップなど、あらゆるスペイン語のサーフェスで機能します。Webチームかモバイルチームかは関係ありません。検索が照合するのは文字列ではなく意味です。「Deploy」に対する1つのエントリが、「deploying」「deployment」「Deploy your app」にも反応します。形ごとに別々のエントリを用意する必要はありません。
ブランドボイスは、ローカライゼーションエンジンにロケールごとに紐づきます。すべてのリクエストで使われます。
Instructionsは、ロケール単位で適用される、個別にテスト可能なルールです。略語のルール、ノーブレークスペース、引用符など、どれも個別にデバッグできます。
model chainは、各リクエストを優先モデルにルーティングし、順位付けされたフォールバックを備えます。用語集に手を入れずにプロバイダを切り替えられます。
AI評価者は独立したモデル上で動作します。すべてのリクエストを、用語集および各指示に対して個別にスコアリングします。理由付きの合否が、時系列で追跡されます。
| 論点 | プロジェクトスコープのツール | 組織スコープのローカライゼーションエンジン |
|---|---|---|
| 一貫性のスコープ | プロジェクトごと、チームごと | 組織ごと |
| 一貫性の単位 | ハッシュで管理されるセグメント全体 | 意味的に照合される個別用語 |
| ソースの書き換え後も維持されるか | いいえ | はい |
| アプリ横断・チーム横断 | 運用頼み。人が整合を保つ | アーキテクチャで担保。ローカライゼーションエンジンが整合を保つ |
| 品質測定 | ルールベースのチェック（タグ、数値） | リクエスト単位のLLMスコアリング |
| モデルの柔軟性 | プロバイダロック | ランク付きチェーン |
| 出力に対する支配力 | 翻訳者の裁量 | 用語集がモデルを上書きする |
ズレは、受け入れるしかないものではなく、測定できるものになります。用語集はすべてのリクエストで機能し、AI評価者は各リクエストごとに準拠状況を検証します。
この仕組みは、retrieval augmented localization (RAL)と呼ばれます。推論時に、エンジンは入力をn-gramフレーズに分解し、それらを埋め込み、用語集のベクトルインデックスに対してコサイン類似度検索を実行します。一致した用語は、最初のトークンが生成される前にモデルのコンテキストウィンドウへ入れられます。構造はRAGと同じで、翻訳に適用したものです。
複数のLLMプロバイダと複数の欧州言語にまたがる統制評価において、RALは用語エラーを17〜45%削減しました。42,000件超のペア品質評価。Holm-Bonferroni補正後の p < 0.001 を、すべてのプロバイダで達成しました。一方、総合品質スコアでは、この差をまったく検出できませんでした。
アーキテクチャ #2: フォワードデプロイ型ローカリゼーションエンジニアリング#
2つ目の壁は移行です。今のスタックは動いている。コストを生み出してはいても、機能はしている。それを置き換えるコスト、つまりエンジニアリング工数、統合のやり直し、翻訳者の再オンボーディング、過去データの移行は、調整コストを払い続けるより高くつくように見えてしまうことがほとんどです。
だからこそ、そのコストは今も払い続けられています。同じ移行ボトルネックが本気で動こうとするエンタープライズを何度も足止めするのを見て、私たちは移行そのものを自分たちで引き受けることにしました。
Lingo.devがエンタープライズをオンボーディングするとき、移行を担うのは私たちのエンジニアです。ライセンスに上乗せされるプロフェッショナルサービス契約としてではありません。標準のオンボーディング経路としてです。
フォワードデプロイ型ローカリゼーションエンジニアが、あなたの用語集、ブランドボイス文書、コネクタ設定、翻訳者契約に目を通します。翻訳メモリはTMXから、用語集はそれがどんな従来形式であっても取り込みます。何ひとつ再導出しません。用語を事前に読み込んだローカライゼーションエンジンをLingo.dev上に構築します。CIにも組み込みます。さらに、信頼している人間の翻訳者が関与し続けられるよう、翻訳者体制を非同期パイプラインにつなぎます。
複数チームのケースこそ、このアーキテクチャが真価を発揮します。従来のやり方では、チーム間で用語を揃えるにはN個の同期された移行が必要です。各チームが自分のプロジェクト内でキーとTMを再導出するからです。ここではローカライゼーションエンジンを一度構築すれば済みます。各チームは自分たちのタイミングで、自分のアプリをそれにつなげばいい。アプリ横断の一貫性は、すべてのチームがそれぞれの移行を終えた後ではなく、最初のロケールがそのエンジンに到達した時点で現れます。
私たちのエンジニアは、次の本番デプロイ、その次の本番デプロイまで伴走し、あなたの社内チームがシステムを引き継ぐところまで支えます。
これが、私たちのエンタープライズ顧客のオンボーディング方法です。
複数チームの組繍が毎週出荷する段階では、翻訳は買い手とベンダーのあいだで切る調達チケットであってはなりません。次の本番デプロイの後ではなく、それと並走して動く必要があります。Palantir、Scale AI、Ramp、その他のインフラベンダーは、10年以上にわたり、フォワードデプロイ型エンジニアリングでエンタープライズ顧客をオンボーディングしてきました。
今こそ、ローカリゼーションもようやく追いつくべきです。
監査
Lingo.devのエンジニアが、ソースリポジトリ、既存のTM（TMXエクスポートを含む）、用語集、コネクタ、翻訳者契約を、各サーフェスを担当するすべてのチームにまたがって確認します。そのうえで、順序とタイムラインを含む移行計画を作成します。計画のオーナーはあなたです。
現在の品質に合わせてエンジンを構築
インポートした用語集、ロケールごとのブランドボイス、翻訳者パイプラインを使ってローカライゼーションエンジンを設定します。本番トラフィックを流す前に、現在のツールの出力とエンジンの出力を横並びで比較します。同じ文字列を、同じ週に比較します。品質が維持されているかどうかを判断するのは、あなたです。
各チームのCIに組み込み
全面リプレースは不要です。ローカライゼーションエンジンは、各チームの既存パイプラインの1ステップとして動作します。マージフロー、レビューフロー、レビュー担当者はすべてそのまま。エンジンが古いステップだけを置き換えます。
あなたのペースで切り替え
まずは1チーム、1ロケールペア。次に3つ。その後に残りです。順番はあなたが決めます。各ステップで比較を実施します。ロールバックは1コミットで済みます。
あなたのチームへ移管
私たちのエンジニアが、ドキュメント、ランブック、そして引き継ぎまで私たちがカバーするオンコールローテーションとともに、システムをあなたのプラットフォームチームへ引き渡します。
エビデンス#
研究。 RAL study：複数のLLMプロバイダと複数の欧州言語にまたがる42,000件超のペア品質評価。Holm-Bonferroni補正後の p < 0.001 をすべてのプロバイダで達成。用語エラーの削減幅は17〜45%。
モデル選びより設定。 私たちは、Mistral、Gemini、Claude、GPTのいずれであっても、適切な用語集、ブランドボイス、コンテキスト設定があれば、一貫して出荷可能で参照品質の翻訳を、コストのごく一部で実現できることを見出しました。モデル自体を改善したからではありません。各リクエストで、ローカライゼーションエンジンは一致する用語集の用語、ブランドボイス、ロケール指示を類似度検索で取得し、最初のトークンが生成される前にモデルのコンテキストウィンドウへ注入します。
本番規模。 プラットフォーム上で2億語超を翻訳。
実名顧客。 Mistral、Solana、SoSafe、Cal.com。
対象範囲#
Lingo.devは、単一プロダクトの企業からオープンソースプロジェクト、モバイル専業チーム、エンタープライズプラットフォームまで、さまざまなローカライゼーションチームを支援しています。ここでご紹介するアーキテクチャは、20以上のロケールで複数のアプリを展開する、複数チーム体制のエンタープライズ向けに最適化されたものです。
次に進む流れ#
最初のステップは、2週間のパイロットです。1チーム、1ロケールペアで始めます。
専任のローカライゼーションエンジニアが、お客様のローカライゼーション責任者とエンジニアリング責任者に伴走します。まずは、お客様のワークフローを把握します。そのうえで、チームが話せない言語でも翻訳品質を可視化できる測定体制を整えます。独立したモデルで動作するAI評価者が、各翻訳を用語集とお客様のルールに照らして採点します。このスコアリングは、翻訳品質評価の標準フレームワークであるMQMをベースに調整しています。
お客様の用語集とブランドボイスのドキュメントに基づいて、ローカライゼーションエンジンを構築します。お客様のソースコンテンツで、現在お使いのツールと並行して動かします。その差を見て、ご判断ください。
その後は、残りのチームとロケールへの移行を、当社ではなくお客様のスケジュールに合わせて進めます。
ローカライゼーションエンジニアリングの専門家に今すぐご相談ください。
