ローカライゼーションエンジニアリングプラットフォーム。
Lingo.dev で処理された単語数: ,,
仕事の置き場所が変わる。
かつてローカライゼーションはプロダクトの外側にありました。調整には何週間もかかり、翻訳者はその分野に不慣れで、リクエストのたびに毎回コンテキストを渡し直す必要がありました。これをプロダクトの内側に組み込んだチームは、使うほどに効果が積み上がることを実感しています。
前
翻訳をベンダー管理の関係として捉えること。
リクエストはプロダクトの外に出ます。ベンダーはドメインを知らないまま翻訳します。毎回の納品は都度ゼロから行われるため、用語はリリースを重ねるごとにぶれていきます。品質は、誰にも監査できないレビュー担当者の主観に委ねられます。
以降
翻訳を、設定できるインフラへ。
ローカライゼーションエンジンには、用語集、ブランドボイス、ロケール別のモデルチェーンが含まれます。すべてのリクエストは、そのコンテキストが最初から付与された状態でプロダクトに入ります。用語は固定され、品質は各指標ごとにスコア化され、時系列で追跡されます。
チームが測定して見えてきたこと。
ローカライゼーションをプロダクトの内側に取り込んだエンジニアリングチームは、文脈が積み上がっていくことに気づきました。用語は固定され、品質は測定可能になります。
導入事例をすべて見る
“Lingo.devのアプローチは、Stripeが決済を変革したときのことを思い出させます。複雑なプロセスを、開発者にとって見えないものにしたのです。”
Pete Koomen
Group Partner, Y Combinator
ローカライゼーションエンジンに含まれるもの
ステートフルな翻訳API。作成して、設定して、呼び出すだけ。
ローカライゼーションエンジンは、あらゆるリクエストをまたいでドメイン文脈を保持します。用語集が製品用語を守り、ブランドボイスがロケールごとの文体を定義し、モデルチェーンが優先順位付きフォールバックでプロバイダーを選択します。チームが追加したルールはすべて蓄積され、用語のぶれを防ぎます。
ローカライゼーションエンジンに含まれるもの
- 用語集
- ロケールペアごとに、意味的類似性でマッチング
- ブランドボイス
- ロケールごとのトーンと丁寧さ
- 指示
- ロケール固有のルール（書式、慣習）
- モデルチェーン
- 自動フォールバック対応の優先順位付きプロバイダー
- AI評価者
- 品質の各次元ごとに独立したスコアラー
1curl -X POST https://api.lingo.dev/process/localize \
2 -H "X-API-Key: $LINGO_API_KEY" \
3 -H "Content-Type: application/json" \
4 -d '{
5 "engineId": "eng_abc123",
6 "sourceLocale": "en",
7 "targetLocale": "de",
8 "data": {
9 "greeting": "Hello, world!",
10 "cta": "Get started"
11 }
12 }'1{
2 "data": {
3 "greeting": "Hallo, Welt!",
4 "cta": "Jetzt starten"
5 }
6}
“開発者ツールにおいて、開発者体験はすべてです。Lingo.devはそこを見事に押さえ、複雑なローカライゼーションを数行のコードにまでシンプルにしてくれました。”
Paul Copplestone
CEO兼共同創業者, Supabase
変わったものだけ再ローカライズし、変わっていないものは取り出す。
リリースのたびにプロダクト全体を再ローカライズするのは非効率で、承認済みコンテンツまで上書きしてしまいます。変更箇所だけを再ローカライズするのが正しいアプローチですが、その変更は毎回、プロダクト全体から切り離された状態で単独でモデルに渡されるため、用語がぶれます。検索拡張ローカライゼーションは第三の方法です。変更された箇所だけを再ローカライズし、各リクエストごとに対応するコンテキストを取り出します。
変更点のみ、コンテキストなし
変更のたびに、毎回ゼロからの推測になる。
- 入力
- "Users can switch providers at any time."
- コンテキスト
- (none)
- 出力（pt）
- "fornecedores"
前後の文脈がなければ、モデルは "provider" がベンダーなのか、サービスなのか、供給者なのか判断できません。そこで一般的な語を選びます。そして次のリリースでは、また別の語を選ぶかもしれません。
648件の用語エラー — 用語面で最難関のケース（規制文書）でもトップクラスのモデル。
RALで、変わった箇所だけ
この変更に必要な用語だけ。
- 入力
- "Users can switch providers at any time."
- コンテキスト
- provider → prestador
- 出力（pt）
- "prestadores"
ローカライゼーションエンジンは入力を分解し、用語集に対して類似検索を行い、一致した用語だけを推論時に注入します。コンテキストウィンドウは小さいまま、翻訳の一貫性は保たれます。
RALでは266件のエラー。同じモデル、同じ記事でも、最も難しいケースでは59%少ない結果に。より易しいケースでは、さらに差が縮まります。
プロフェッショナルなローカライゼーション基盤を、一歩ずつ。
すべての非同期ローカライゼーションはこのパイプラインを通り、ステップごとの設定とロケールごとの障害分離に対応しています。モデルがトークンを生成する前に、用語集、ブランドボイス、指示が取得・注入されます。
検索拡張ローカライゼーション。
複数のLLMプロバイダーと複数言語にまたがる、用語密度の高いコンテンツの統制評価。公式の人手参照訳と比較した段落ごとの用語エラーをGEMBA-MQMで測定し、対応のあるWilcoxon符号付順位検定にHolm-Bonferroni補正を適用した結果、すべてのプロバイダーで p < 0.001 でした。
- 17–45%
- 用語ミスの削減
- 42,000+
- ペア品質評価
話せない言語でも、品質は測定できる。
モデル横断の品質スコアリング、用語集の適用、そして必要な場面での人によるレビュー。社内にそのロケールを読める人がいなくても、チームはディメンション別スコアを上位層へレポートできます。
自動品質スコアリング
クロスモデル評価: 1つのモデルが翻訳し、別のモデルが採点します。流暢さ、正確性、用語、スタイルをMQMの観点で評価。ロケールごとの傾向やリグレッションアラートをダッシュボードで確認できます。
用語集とブランドボイス
用語集が、ロケールをまたいで製品用語をぶれなく保ちます。ブランドボイスが、言語ごとのトーンや丁寧さを定義します。どのリリースでも、チームがすでに承認した用語をそのまま使えるため、表現の揺れも、その場しのぎの訳語選びも起きません。
必要なところに、人のレビューを
スコアがしきい値を下回ると、翻訳はAPIの背後にある認定翻訳者ネットワークへ自動的にルーティングされます。ベンダー管理や手動での引き継ぎ調整は不要です。
“Lingo.dev を使えば、オランダ語は自然に読め、ロシア語は UI にぴったり収まり、ブランドボイスもぶれません。”
Sebastiaan van Leeuwen
プロダクトマネージャー、Truely
ローカライゼーションエンジンにつながる4つの接点。
ローカライゼーション担当者が品質ルールを設定します。あとはAPIを呼び出すか、CLIを実行するか、GitHub Actionを追加するだけです。
“Dependabotが自動化でパッケージ更新を簡単にしたように、Lingo.devはローカライゼーションで同じことを実現しています。”
Grey Baker
Dependabot の生みの親
テナントごとに。プロダクトごとに。チームごとに。ローカライゼーションエンジンを。
Lingo.devがローカライゼーションエンジンをホストします。アーキテクチャに必要な数だけ作成でき、それぞれを独立して設定し、APIでプロビジョニングし、個別に可観測性を確保できます。
テナントごと
顧客ごとに 1 つのローカライゼーションエンジン。
1回のAPIコールで、各ワークスペースまたはアカウントごとにローカライゼーションエンジンをプロビジョニングできます。各テナントごとに専用の用語集、ブランドボイス、モデルチェーンが割り当てられ、利用状況もテナント単位で追跡されます。
サーフェスごと
コンテンツの表面ごとに1つのローカライゼーションエンジン。
マーケティングコピー、プロダクトUI、法務の定型文、ヘルプドキュメント――それぞれで必要な用語は異なります。表面ごとに別々のローカライゼーションエンジンを運用しましょう。用語集と品質スコアはそれぞれ分離されたまま保たれます。
大規模運用にも対応
必要なだけローカライゼーションエンジンを。
ローカライゼーションエンジンは、Lingo.devにおける中核的なインフラプリミティブです。API経由でプロビジョニングし、他のサービスと同じように呼び出せます。1つでも数千でも実行でき、モデルルーティング、ストレージ、スコアリングはプラットフォームが処理します。利用状況はローカライゼーションエンジンごとに追跡されます。
プロフェッショナルなローカライゼーションを、インフラとして。
ソースの事前編集、検索拡張翻訳、人による事後編集、AI品質ゲートまで。プロフェッショナルなローカライゼーションワークフロー全体を、単一の API の背後にカプセル化しています。SOC 2 Type II 監査済みです。
プロフェッショナルなローカライゼーションパイプライン
ソースの事前編集、コンテキストの拡充、LLM翻訳、人手による事後編集、AI品質ゲート、納品までを、1回のAPI呼び出しの裏側でオーケストレーションし、ロケールごとに障害を切り分けます。
検索拡張翻訳
ベクトル検索による意味的な類似性で一致した用語集用語に加え、ブランドボイスと製品コンテキストもローカライゼーションエンジンの状態から自動で取得されます。
ステートフルなローカライゼーションエンジン
ローカライゼーションエンジンは、リクエストをまたいで用語集、ブランドボイス、翻訳メモリ、モデル設定を蓄積します。コンテキストは保持され、ジョブを重ねるたびに改善されます。
一元管理のガバナンス
ローカライゼーションチームは、ローカライゼーションエンジンごとに用語集、ブランドボイス、品質しきい値、レビューチェックポイントを定義し、プロダクトチームはCI/CDを通じてセルフサービスで利用できます。
品質とコストのレポート
ローカライゼーションエンジンごとのダッシュボードで、品質スコア、トークン消費量、用語集カバレッジ、GitHubコミット由来の変更率、モデル別のLLMコスト内訳を確認できます。
チームの自律性
翻訳はプルリクエストで届きます。ローカライゼーションチームがガバナンスと品質基準を担いながら、チーム規模を比例して増やさずにローカライゼーションを拡張できます。
SOC 2 Type II
保存時・転送時の暗号化を含む監査済みのセキュリティ管理を提供。DPAはご要望に応じて利用可能です。
データ暗号化
保存データは AES-256 で暗号化、通信は TLS で保護。API キーはアプリケーション層でハッシュ化され、EU と US リージョンのデータレジデンシーにも対応しています。
99.9% Uptime SLA
マルチリージョンのインフラと、個別プロバイダー障害に備える優先順位付きモデルのフォールバックチェーンを採用しています。
