TranslationLLM APILocalization

LLM APIによるAI翻訳:ベンチマークと本番パイプライン(2026年)

約1分

DeepLは自分が最高だと言い、GPTも自分が最高だと言います。しかしあなたの用語集は両方に反対しています——最初のバッチと最後のバッチの間のどこかで、「Plan」の承認済み訳語が静かに別のものにすり替わり、誰も気づかないうちにサポートチケットが届いていました。

AI翻訳は2026年の静かなローカライゼーションのボトルネックです:業界はLLMとニューラル機械翻訳のベンチマークを積極的に進めていますが、開発者側のパイプライン——用語集の強制、チャンキング、品質ゲート、100万語あたりのコスト——は依然としてほとんど文書化されていません。ベンダーのマーケティングは「当社のモデルが最高」と言い、学術論文は出荷できないものを測定し、実際に本番で動く中間層が欠けています。

本ガイドは両方を扱います:プロバイダーのベンチマークが実際に示すもの(自分で実行するための方法論も含む)と、当社が構築した本番パイプライン——glossary → chunk → translate → enforce → QA——および月100万語の翻訳量を手頃なコストに保つコスト管理です。

LLMを活用した翻訳が実際に変えるもの

要点:LLM翻訳は「正しい」を「文脈的に正しい」に置き換えます——そしてそれはエンジンだけでなくパイプラインを変えます。

ニューラルMTは文を翻訳します。LLMは文脈を伴って翻訳します:用語集を尊重し、ブランドのトーンを保ち、スタイルガイドに従い、文単位のシステムが平坦化してしまう曖昧さも処理できます。差を生む3つの能力:

  1. 用語管理。 用語集は「期待」ではなく「入力」です。モデルに、製品名や法的表現に対する承認済み訳語の使用を必須化できます——依頼ではなく強制です。
  2. コンテキストウィンドウ。 段落、ページ、文書——モデルは1文以上を見るため、MTを悩ませる文をまたぐ参照エラーが解消されます。
  3. 指示可能な出力。 トーン、形式度、対象読者——「法務向けはフォーマルに、オンボーディング向けはフレンドリーに」はモデルの切り替えではなくプロンプトで実現します。

潰すべき誤解:LLM翻訳は「より良いMT」ではありません。コスト構造の異なる別のツールです——単語あたりコストは高く、制御性も高い。以下のパイプラインは、まさにそのコストを正当化するために存在します。

なぜ自前の翻訳パイプラインを構築するのか

要点:ベンダーはエンジンを売り、保証は売らないからこそ、パイプラインが必要です——用語集の制御、測定可能な品質、下がり続けるモデルコストは、すべて自前で構築するものです。

翻訳ベンダーを借りるのではなく、パイプラインを自前で持つ3つの理由:

  1. 用語集は契約です。 ブランド名、法務用語、製品ストリング——あなたの用語集はビジネス資産であり、すべてのバッチと言語にわたって一貫して強制できるのはパイプラインだけです。
  2. 品質は測定可能でなければなりません。 「問題なさそう」では製品レビューを乗り越えられません。自動QAステージを持つパイプラインは、バッチごと、言語ごとにスコアを生成します——当社のテストガイドが他のすべてに適用しているのと同じ評価規律です。
  3. モデルコストは下がり続けます。 モデルの世代が変わるごとに単語あたりの価格は下がります。モデルを設定可能なコンポーネントとして扱うパイプラインはその下落を自動的に取り込めますが、ベンダー契約ではできません。

代替案——翻訳ベンダー——は利便性を買ってロックインを売ります。本シリーズの価値比較が、モデルレイヤーはあなたが制御する判断として残すべき理由を示しており、同じ論理が翻訳にも当てはまります。

プロバイダーベンチマーク:言語ペア別の品質・コスト・レイテンシ

要点:品質ランキングは言語ペアに依存し、数か月で陳腐化します——自前のコーパスで検証し、当社のものを含むすべての公開ランキングをスナップショットとして扱いましょう。

2026年の状況は本当に拮抗しています:intlpullのLLM翻訳ベンチマークLokaliseの2026年モデル調査などの独立した評価では、フロンティアモデルが言語ペアとタスクタイプによって順位を入れ替え、予算重視モデルは一般的なペアで差を詰めています。構造的に正しいこと:

  1. フロンティアモデルは低リソース言語ペアとニュアンスのあるレジスターでリードします——訓練データが薄い領域ではその差は本物です。
  2. 予算重視モデルとオープンウェイトモデルは高リソース言語ペアで拮抗しています——英語↔スペイン語、フランス語、ドイツ語、日本語など——「十分良い」が「素晴らしい」のほとんどまで到達する領域です。
  3. プロバイダー間の差は、プロンプト設計の差より小さいです。 ほとんどのペアでは、用語集の注入とチャンキングの方がモデル選択よりも品質を動かします。

コスト面:100万語あたりの価格はモデルティアとキャッシュ挙動によって異なります——フロンティアティアは予算重視ティアの数倍になり、安定したセグメント(定型文、反復ストリング)へのcachingは実効レートを圧縮します。モデルカタログで現在の提供状況を確認できます。翻訳予算はまさにこれらの数字に敏感なため、購入時にはプロバイダーのページで料金を確認しましょう。

自前のベンチマークは半日で完了します:対象言語ごとに代表的なストリングを20本用意し、候補の2モデルと既存のMTに通して、ネイティブスピーカーにブラインドで評価してもらいます。これは業界記事が使うのと同じ方法であり、唯一重要な問い——あなたの製品にとって、あなたの言語で——に答えてくれます。

パイプラインの構築方法:Glossary → Chunk → Translate → Enforce → QA

要点:5つのステージ、1つの契約——用語集はデータ、QAステージはゲート、そしてその間はすべて機械的な処理です。

統合チャットエンドポイント上のスケルトン:

import json
from openai import OpenAI

client = OpenAI(base_url="https://api.tokspan.com")  # unified endpoint — one key for every model

GLOSSARY = [  # enforced, not suggested
    {"source": "Checkout", "target": "Finalizar Compra", "lang": "es"},
    {"source": "Plan", "target": "Tarifa", "lang": "es"},
]

def translate(text, lang, model="gpt-4o-mini"):
    sys = (
        "You are a professional translator. Use the glossary exactly; "
        "never translate glossary terms differently. Keep the brand voice."
        f"\n\nGlossary: {json.dumps(GLOSSARY)}"
    )
    return client.chat.completions.create(
        model=model,
        messages=[{"role": "system", "content": sys},
                  {"role": "user", "content": text}],
    ).choices[0].message.content

# Stage 5: the gate
def qa(original, translated, lang):
    verdict = client.chat.completions.create(
        model="gpt-4o",  # a different model as judge — never the translator
        messages=[{"role": "user", "content":
            f"Rate this translation 0-10 for accuracy, terminology, and tone: "
            f"\nSource: {original}\nTarget: {translated}"}],
    ).choices[0].message.content
    return float(verdict) >= 7

それぞれにルールのある5つのステージ:

  1. Glossary ——システムプロンプトに注入される構造化データ。契約は「できるだけ」ではなく「厳密に」です。
  2. Chunking ——文単位ではなく段落単位で行い、文脈を保持します。用語を含むセグメントは分割せず維持します。
  3. Translate ——モデルティアはルーティング判断です:定型文には予算重視ティア、マーケティングコピーにはフロンティアティア(カスタムルーティングでセグメント単位にできます)。
  4. Enforce ——出力をスキャンして用語集の用語を確認し、漏れがあれば用語を強調した上で再翻訳します。このループこそ、用語管理を「期待」ではなく「保証」にするものです。
  5. QA ——翻訳モデルとは別のモデルを判定役とするLLM-as-judgeゲートで、セグメントごとに閾値スコアを付けます。ゲートを通過しないバッチは出荷されません。前述の評価方法論が適用されます。

品質とコストの管理方法

要点:100万語あたりのコストは設計パラメータです——ティアリング、キャッシング、バッチングを組み合わせれば、品質に触れることなく60〜80%削減するのが日常的です。

コストモデルを1行で:100万語あたりのコスト=モデルレート×トークン膨張係数(翻訳はトークンを膨張させます:100万語のコーパスは、プロンプトのオーバーヘッド後、通常130万〜160万トークンになります)。3つのレバー:

  1. セグメントタイプでティアリング。 定型文、UIストリング、法務の定型文は予算重視モデルで、マーケティングとブランドコピーはフロンティアティアで実行します。この組み合わせで、通常は全フロンティア比50〜70%下がります。
  2. 安定した80%をキャッシュ。 メニュー、ラベル、反復ブロック——反復セグメントの安定したプレフィックスは、入力レートの数分の一のcache pricingにヒットします。同じストリングがすべての言語バッチで繰り返されるため、翻訳はキャッシュに最も適したワークロードの1つです。
  3. オフライン処理をバッチ化。 文書全体の翻訳、ストリングダンプ、夜間同期は遅延に寛容です——本シリーズのバッチガイドの割引パターンは、まさにこれらのワークロードに50%オフを適用します。

もう一方の品質面:QAゲートの閾値と判定モデルはコードと同じようにバージョン管理します。モデルをアップグレードするたびに、本番に触れる前に評価セットを再実行します——「モデルが良くなった」が「用語集が悪くなった」にならないための規律です。

翻訳品質を壊すよくある失敗

要点:4つの失敗——どれもデモでは見えず、本番では高くつきます。

  1. 用語集のドリフト。 強制ループも出力スキャンもなければ、承認済み訳語の使用が「いつも」から「だいたい」に緩みます。強制は好みではなくステージです。
  2. 文脈を壊すチャンキング。 文単位のチャンクは文をまたぐ参照を壊し、用語を含むフレーズを分割します。用語を考慮した境界での段落単位チャンキングが最低ラインです。
  3. 単一指標での評価。 BLEUだけでは「文字通り正しい」を評価し、「自然に正しい」を罰します。判定モデルによるスコアリングとネイティブスピーカーによるサンプリングを併用しましょう——他のすべてのLLM出力評価と同じ二重トラックのパターンです。
  4. 機械的に平坦化されたローカライゼーション。 翻訳はローカライゼーションではありません:日付、通貨、単位、文化的参照は、翻訳の代わりではなく翻訳の後にロケール処理が必要です。パイプラインの最終ステージはロケール適応であり、それを省くと「価格ページ」がサポートチケットになります。

FAQ

LLM翻訳はDeepLやGoogle MTより優れていますか?

用語管理とレジスターについては、はい——LLMはMTが従えない用語集とスタイル指示に従えます。単語あたりコストと単純な高リソースペアでは、依然としてMTが勝ります。この判断は「良いか悪いか」ではなく「制御性かコストか」です。

翻訳品質はどう評価すればよいですか?

判定モデル(翻訳モデルとは別のモデル)によるスコアリングと、固定の評価セットでのネイティブスピーカーによるサンプリングです。BLEUだけでは誤解を招きます——文字通りの重なりを測定するだけで、自然さは測れません。評価セットはバージョン管理し、モデルをアップグレードするたびに再実行しましょう。

100万語の翻訳コストはいくらですか?

おおよそモデルレート×1.3〜1.6倍のトークン膨張です——予算重視ティアはフロンティアティアを大きく下回り、キャッシングとバッチングで実効レートはさらに圧縮されます。当て推量ではなくコストモデルを構築しましょう。本ガイドの計算式が出発点です。

用語集はどう強制すればよいですか?

用語集の注入と出力の強制スキャンを組み合わせます:すべてのセグメントを用語集と照合し、漏れがあれば用語を強調して再翻訳します。「推奨」は期待であり、「スキャンして再試行」は保証です。

翻訳ジョブはバッチ化すべきですか?

オフライン翻訳——ストリングダンプ、ドキュメント同期、夜間フロー——は典型的なバッチワークロードです:遅延に寛容で、高ボリューム、そして主要プロバイダーのバッチティアではすべて50%オフです。インタラクティブなUI翻訳はリアルタイムのままにします。

予算重視モデルで翻訳は対応できますか?

高リソースペアでは、はい——訓練データが豊富な領域ではフロンティアとの差は小さいです。低リソースペアとニュアンスのあるレジスターには依然としてフロンティアティアが正当化されます。セグメントごとのルーティング判断こそ、パイプラインの存在意義です。

まとめ

LLM APIによるAI翻訳は、モデルの勝負ではなく制御の勝負です:用語集の強制が用語を契約にし、判定モデルベースのQAゲートが品質を測定可能にし、ティアリング・キャッシング・バッチングがコストを設計パラメータにします。プロバイダーのランキングはスナップショットです——自前のコーパスで、あなたの言語ペアで、すべての本格的なベンチマークが使う方法で検証しましょう。そしてパイプラインを一度構築すれば、モデルの世代が変わるたびに安くなっていきます。

あなたの言語、あなたのコーパス、あなたの判定。TokSpan APIキーを取得して、同じストリングを複数のモデルで実行してみましょう。$5分の無料クレジットで最初のベンチマークバッチをカバーできます。