ローカライゼーションAPI

2010年以前、オンラインで決済を受け付けるには、銀行で加盟店アカウントを申し込む必要がありました。何週間も続く書類手続き。信用審査。最低取引要件。そして、テスト環境が本番とかけ離れたXML API経由で決済ゲートウェイを統合する。PCI準拠も自分たちで対応し、カード番号を保存し、暗号鍵を管理し、セキュリティ監査を通過しなければなりませんでした。

今では、開発者はチェックアウトページに数行のコードを追加するだけです。コンプライアンス、不正検知、通貨換算、入金処理は、すべてAPIの裏側で処理されます。開発者がその複雑さを目にすることはありません。複雑さが消えたわけではありません。カプセル化されたのです。

こうしたことは、何度も繰り返されてきました。かつては専門家やベンダー、何か月もの調整を必要としていたプロフェッショナルな業務が、ひとつのAPIコールに圧縮される。呼び出し自体はシンプルでも、その裏側で動くものは決してシンプルではありません。

API以前のプロフェッショナルなローカライゼーション#

プロダクトを複数言語にローカライズするには、翻訳ベンダーに依頼する必要がありました。ベンダーは翻訳者をアサインしますが、その翻訳者はプロダクトやドメイン、既存の用語に詳しくないことも少なくありませんでした。用語ガイドを送る。翻訳者は、だいたい目を通す。翻訳は5〜10営業日で返ってくる。3つの用語が間違っている。修正のために差し戻す。さらに3日。

その間にも、誰かが用語集を管理し、前回のバッチ以降にどの文字列が変わったかを追跡し、ドイツ語翻訳で正しい引用符が使われているかを確認し、ポルトガル語の出力がブラジル式ではなくヨーロッパ式の綴りになっていることをチェックしなければなりませんでした。こうした調整は、スプレッドシート、メール、Slackスレッドをまたいで進みます。

LLMで自動化を試したチームにとって、翻訳は速くても品質保証は速くありませんでした。すべてのリクエストが毎回ゼロから始まるのです。承認済み用語の記憶はない。ブランドボイスへの理解もない。出力がそのドメインの用語ルールに沿っているかの検証もない。

そして、LLMは本番翻訳に使える品質の閾値を超えました。言語そのものが上達したからではありません。推論時にドメインコンテキストを注入することで、一貫性があり、用語も正確な出力を安定して得られるようになったからです。足りなかったのは、モデルを支えるコンテキストパイプラインでした。

APIの裏側で動くプロフェッショナルなローカライゼーション#

1回のPOST。各言語が完了するたびに、結果がwebhookで届きます。

curl -X POST https://api.lingo.dev/jobs/localization \
  -H "X-API-Key: $LINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "sourceLocale": "en",
    "targetLocales": ["de", "fr", "ja", "ko", "pt-BR",
      "es", "it", "zh-Hans", "nl", "sv", "pl", "tr", "ar", "th"],
    "data": {
      "title": "Introduction to Machine Learning",
      "steps": [
        { "heading": "What is ML?", "body": "Machine learning is a subset of artificial intelligence." },
        { "heading": "Supervised Learning", "body": "Training a model with labeled data." }
      ]
    },
    "callbackUrl": "https://your-app.com/webhooks/translations"
  }'

202はミリ秒で返ります。呼び出し元はそのまま次の処理に進めます。各言語はローカライゼーションエンジンを通じて独立して処理されます。ドイツ語は4秒。日本語は6秒。アラビア語は8秒。各結果は、準備ができた瞬間にあなたのwebhookへ送られます。UIでリアルタイムの進捗を表示したい場合は、ジョブグループにWebSocketを接続してください。"16言語中3言語が準備完了" がライブで更新されます。

開発者がその複雑さを管理することはありません。複雑さが消えたわけではありません。決済と同じように、カプセル化されたのです。

APIの裏側で動くもの#

ローカライゼーションジョブが始まると、プラットフォームはエンジンの設定に沿って複数ステップのパイプラインを実行します。ステップは6つ。それぞれが、スキップしたときに表面化する特定の失敗パターンに対応しています。

各ステップはエンジンごとに設定できます。ソース改善、人手ポストエディット、AIポストエディット、逆翻訳検証は、それぞれ個別に有効化または無効化できます。コンテキスト拡張とLLM翻訳は常にオンです。ここがエンジンの中核だからです。

マーケティングコピーをローカライズするチームなら、6つすべてのステップを有効にするかもしれません。社内ドキュメントをローカライズするチームなら、コンテキスト拡張とLLM翻訳だけを使うかもしれません。どちらでもAPIコールは同じです。パイプラインが適応します。

配信#

結果は、設定したチャネル経由で届きます。ポーリングは不要です。

Webhooks - 各言語は、完了した瞬間に配信されます。4秒で完了したドイツ語翻訳は、日本語が6秒で終わるのを待たずにすぐ届きます。すべてのwebhookには、Standard Webhooks仕様に従った暗号学的署名が含まれます。配信に失敗した場合は、最大5回まで指数バックオフで再試行されます。

WebSocket - ジョブグループに接続すれば、リアルタイムの進捗を取得できます。すべてのイベントには完全な状態スナップショットが含まれます。総ジョブ数、完了ジョブ数、失敗ジョブ数、言語ごとのステータスです。フロントエンド側でローカル状態を維持する必要はありません。サーバーが各イベントで、その時点の正しい状態をプッシュします。

障害の分離 - 日本語が失敗してもドイツ語が成功していれば、ドイツ語翻訳は通常どおり配信されます。失敗したジョブはエラーメッセージ付きで表示されます。グループステータスはpartialになります。再試行するには、失敗したロケールだけを含む新しいリクエストを送信してください。

これが意味すること#

コンプライアンス、用語ガバナンス、ドメイン適応、人手レビュー、品質スコアリングまで、すべてAPIの裏側で処理されます。開発者はコンテンツと対象ロケールを送信するだけ。ローカライゼーションマネージャーはエンジンを設定し、プラットフォームがワークフローを実行します。

かつてはプロジェクトマネージャー、ベンダーとの関係、共有スプレッドシートを必要としていた調整が、今ではwebhook配信、障害の分離、リアルタイム進捗ストリーミングを備えた耐久性の高いバックグラウンドワークフローの中で完結します。

ローカライゼーションのニーズが、リリースをまたいだ一貫性を必要としない単発の文書翻訳であれば、このAPIはオーバースペックかもしれません。エンジンの価値は、使うほど積み上がっていきます。用語集の用語は蓄積され、ブランドボイスは磨かれ、品質スコアは上向いていく。Lingo.devは継続的に出荷するプロダクトのために設計されています。同じコンテンツがスプリントごとに変わり、ロケール間の一貫性が譲れないチームのために。

APIリファレンスを読む、またはデモを予約することで、このパイプラインの動作をご覧いただけます。

次のステップ#