Lingo.dev v1.0 のご紹介

ローカライゼーションチームなら、誰もが見覚えのあるパターンです。プロダクトに不慣れな翻訳者は、ブランド用語を取り違えます。LLM ラッパーには、リクエストをまたいで文脈を保持する仕組みがありません。数回リリースを重ねるうちに、用語は少しずつぶれていきます。しかも誰も気づきません。総合品質スコアは 0.95 と出て、そのまま先へ進んでしまうからです。

私たちはそのギャップを測定しました。推論時に用語集コンテキストを注入することで、5 つの LLM プロバイダーと 5 つのヨーロッパ言語において、用語ミスを 17〜45% 削減できます。私たちはこれを retrieval augmented localization（RAL）と呼んでいます。LLM は本番翻訳に使える品質水準に達しました。ただし、適切なコンテキストパイプラインがある場合に限ります。それがなければ、個々に切り離されたリクエストは毎回、用語のぶれを生む新たなきっかけになります。Lingo.dev では、Mistral、Solana、SoSafe、Cal.com などの顧客向けに 2 億語超の翻訳を支えるローカライゼーション基盤を提供してきた経験をもとに、それを中心に v1.0 を構築しました。

ローカライゼーションエンジン#

ローカライゼーションエンジンとは、Lingo.dev 上で動くステートフルな翻訳 API です。あらゆるリクエストを通じてドメインコンテキストを保持する、RAL の実装でもあります。一度設定すれば、どこからでも呼び出せます。

• Models - OpenRouter のカタログから、任意のモデルを選べます。ロケールごとにモデルを順位付けし、フォールバックチェーンを設定可能。プライマリモデルが利用できない場合でも、エンジンがリクエストを落とさず次のモデルへルーティングします。
• Glossary - ロケールペアごとに、ソース用語とターゲット訳を対応付けます。エンジンは一致する用語をすべてのリクエストに注入します。Cal.com のエンジンが "Workspace" に遭遇すると、LLM が 1 トークンも生成する前に用語集がそれを解決します。翻訳者へのオンボーディングは不要です。
• ブランドボイス - ロケールごとにトーンや文体を定義します。たとえば、ドイツ語の法務コンテンツにはフォーマル、日本語のマーケティングには会話調、英語ドキュメントにはテクニカルな文体を設定できます。
• Instructions - 特定のパターンに対するロケール別のルールを設定します。たとえば、フランス語のエリジオン規則、ポルトガル語の綴り規則、ドイツ語の引用符、イタリア語で英語由来語をどう扱うかといった指定です。

このエンジンはステートフルです。用語集の各エントリ、ブランドボイスの各ルール、あらゆる指示が、リクエストをまたいで保持されます。新しいエンジンでの最初の翻訳には、まだ蓄積されたコンテキストがありません。ですが 1,000 回目の翻訳では、チームが初日から積み上げてきた設定がすべて効いてきます。差分ベースの CI/CD ワークフローでは、各ビルドで変更箇所だけを再翻訳します。用語のぶれを防ぐのは、このエンジンのステートフル性です。人間の翻訳者も、ステートレスな LLM ラッパーも、同じぶれに悩まされています。

本番反映前に playground で設定をテストできます。文字列を試し、ロケールごとに比較し、納得できたら本番へ反映できます。

呼び出し方#

統合パスは 3 つ。エンジンも、コンテキストも、品質も同じです。

CLI - リポジトリを指定すれば、設定済みのすべてのロケールを 1 つのコマンドで翻訳できます。

npx lingo.dev@latest run

CI/CD - GitHub integration は、プッシュのたびに翻訳済み文字列を含むプルリクエストを作成します。差分上で翻訳をレビューし、準備ができたらマージ。引き継ぎは不要です。外部チームを待つ必要もありません。

API - バックエンドコードからエンジンを直接呼び出せます。

curl -X POST https://api.lingo.dev/process/localize \
  -H "X-API-Key: $LINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "engineId": "eng_abc123",
    "sourceLocale": "en",
    "targetLocale": "es",
    "data": {
      "welcome": "Welcome to the future of payments",
      "cta": "Get started"
    }
  }'

すべてのリクエストはログに残ります。使用モデル、消費トークン数、フォールバック状況、適用された用語集、マッチした指示などです。reports dashboard では、語数、トークン消費量、主要ロケール、用語集カバレッジ、変更率を確認できるため、どの用語が実際に適用されているのか、どこにカバレッジの抜けがあるのかを正確に把握できます。

モデルを自由に選べる#

用語の一貫性は、たまたま使っている LLM ベンダーに左右されるべきではありません。RAL は、一貫性レイヤー — 用語集、ブランドボイス、指示 — を、翻訳を実行するモデルから切り離します。付与されたコンテキストによって、どのモデルでもドメインに即した正確な出力へ導けます。リリースの合間に GPT-5.4 から Claude Opus へ切り替えても、用語集の項目を 1 つも再設定する必要はありません。

この分離は、ベンダーロックインの解消にもつながります。クローズドな翻訳 API では、用語集、スタイルルール、用語管理が 1 つのプロバイダーに縛られます。モデルの性能が後退すれば、できるのはサポートチケットを切ることだけ。別のプロバイダーがより優れたモデルを出しても、簡単には乗り換えられません。Lingo.dev では、モデルはあくまで設定パラメータです。どのモデルがその下で動いていても、一貫性レイヤーはそのまま維持されます。

私たちが EU AI Act で 5 つのプロバイダーをテストした とき、72 語の用語集を備えた Mistral（MQM 0.940、1.0 はエラーなし）は、Google の生の品質（0.938）に迫りました。コスト差は 1 桁ではありません。適切に構築された用語集は、モデル側に求められる知能の量を減らします。用語集が成熟するにつれて、同じ品質閾値をより安価なモデルでも満たせるタイミングを、プラットフォームが知らせます。

品質スコアリング#

用語のぶれを直すことは、問題の半分にすぎません。もう半分は、標準的な品質指標ではそのぶれ自体が見えないことです。私たちの research では、ベンチマークやリーダーボードで使われるような総合的な翻訳品質スコアが、生の翻訳と用語集で拡張した翻訳に同一のスコアを付ける一方で、次元別スコアリングでは用語ミスが 17〜45% 少ないことが示されました。RAL が埋めるギャップは、業界が翻訳品質の測定に使っている指標では見えないのです。

測定できない問題は、修正できません。Lingo.dev v1.0 には AI評価者 が搭載されています。単一の総合スコアではなく、各翻訳を次元ごとに評価する自動品質チェックです。基準は自然言語で定義できます。たとえば「すべての HTML タグは保持されていますか？」や「ネイティブ話者にとっての自然さを評価してください」といった具合です。出力は独立した LLM が評価します。たとえば GPT-5.4 が翻訳し、Claude Sonnet がスコアリングすることで、自己評価バイアスを排除します。

モデルをまたいだ次元別評価なら、総合スコアでは見逃される問題を捉えられます。たとえば、幻覚された用語、ずれた文体、壊れたプレースホルダー、そしてリリースを重ねる中で静かに積み上がる用語のぶれです。

これが意味すること#

すでに Lingo.dev を使っている場合 - CLI、CI/CD、MCP ツールはこれまでどおり使えます。v1.0 で追加されるのは、エンジン設定です。モデル選択、フォールバックチェーン、ブランドボイス、用語集、品質スコアリング。すべてロケール単位で、すべてダッシュボードから設定できます。移行は不要です。

Lingo.dev が初めての方へ - 無料の開発者アカウントを作成 すると、事前設定済みのローカライゼーションエンジンを利用できます。最初の翻訳済みビルドは CLI なら 4 分で完了。API 経由での統合も可能です。

次のリリースから、すべてのロケールへ一貫した用語で届けられます。1 週目に構築した用語集が、すべての言語・すべてのビルドで、あらゆるブランド用語を確実に適用します。設定コストは最初に集中し、翻訳のたびに積み増されることはありません。開発者が 1 つの段落を変更した場合でも、CI パイプラインが再翻訳するのはその段落だけ。同じエンジン、同じ用語集、同じ品質閾値です。翻訳は、もはや引き継ぎ作業ではありません。ビルド工程の一部になります。

Lingo.dev v1.0 は、ローカライゼーションをインフラのように機能させたいエンジニアリングチーム、ローカライゼーションマネージャー、プロダクトリードのために設計されています。人間の翻訳者との調整を手動レビューのラウンドで進めたいチームには、従来型のローカライゼーションプラットフォームのほうが適しているかもしれません。

始めるには 無料の開発者アカウントを作成、または デモを予約 してください。

ローカライゼーションにとっての RAL は、生成にとっての RAG のようなものです。Lingo.dev v1.0 は、それを実行する場所です。

次のステップ#