# General Translation Knowledge Base: AI翻訳は本番環境のアプリで使えるほど正確か？
URL: https://generaltranslation.com/ja/kb/is-ai-translation-accurate.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 広く話されている言語であれば多くの場合は十分な精度がありますが、それは自社の対象言語、UI文字列、リスクの高いコンテンツで評価をクリアしてからの話です。WMT25では、Gemini 2.5 Proが16の言語ペアのうち10で人間による参照訳と同等以上の評価を得ました。しかし、文書単位のベンチマークからは、短いインターフェース文字列をそのままリリースできるかどうかまではわかりません。
Category: 翻訳
Last updated: 2026-10-20
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-20

文書の翻訳で高い性能を発揮するエンジンでも、ボタンのラベルを誤訳することはあります。たとえば「Save」という単語だけでは、ファイルの保存なのか、お金の節約なのか判断できません。エンジンを比較する際は、自社のプロダクトで実際に扱う文字列、文脈、言語を使って評価しましょう。

## 現在の AI 翻訳の精度はどの程度か？

WMT (Conference on Machine Translation) が毎年実施している General Machine Translation 共有タスクでは、プロの人間の評価者が翻訳システムを比較評価しています。[WMT25 の調査結果](https://aclanthology.org/2025.wmt-1.22/) (Kocmi et al., 2025) では、主催者が 20 の大規模言語モデルと 3 つのオンライン翻訳サービスを含む 60 のシステムを、意図的に難易度を高めた文書で実行しました。そのうえで、自動ランキングの上位システム (1 言語ペアあたり 18 システムを目標) を、16 の言語ペアにわたってプロの評価者が採点しています。アプリ開発チームにとって重要な結果は次の 4 点です。

* **このベンチマークの一部では、上位システムが人間の参照訳と同等以上の結果を示しました。** Gemini 2.5 Pro は 16 ペアのうち 14 ペアで最上位クラスタに入り、そのうち 10 ペアでは人手による翻訳と同等以上の評価を得ました。一方、人間の参照訳が最上位クラスタに入ったのは、参照訳が用意されていた 15 ペアのうち 6 ペアにとどまります。なお著者らは、評価に文体上の好みが影響した可能性があること、また参照訳がプロの納品物ほど入念な推敲を経ていなかったことを指摘しています。
* **用語や文法の誤りは依然として発生します。** タスクのテストスイートによると、上位システムでも一部の言語ペアでは、分野固有の用語、非標準的な入力、性の選択や文法的一致の扱いに課題が残っています。
* **低リソース言語では状況がまったく異なります。** マサイ語への翻訳は「ほぼ使い物にならない」水準で、代わりにスワヒリ語を出力してしまうケースも多く見られました。また、エジプト・アラビア語を指定しても、現代標準アラビア語が出力される傾向がありました。
* **自動スコアはあてになりません。** 自動評価指標で首位だったシステムは、人間の評価者による評価ではかなり順位を下げました。著者らは、品質の最終的な判断は今後も人間による評価に委ねるべきだと結論づけています。

ただし、この結果には 2 つの制約があります。WMT は商用サービスを ONLINE-B、ONLINE-G、ONLINE-W として匿名化しているため、「DeepL と Google Translate のどちらが優れているか」という問いの答えにはなりません。また、テスト対象は文書全体 (ニュース、ソーシャルメディアの投稿、音声の書き起こし、文学・教育テキスト) であり、2 語程度の UI 文字列と比べて、モデルが手がかりにできる文脈がはるかに豊富です。

## MT エンジン、大規模言語モデル、人間の翻訳者はどう違うのか？

いずれも正確な翻訳を生成できます。違いは、受け付けられる文脈と、利用者側に任される作業にあります。

| アプローチ                                               | 得意なこと                               | 利用できる文脈                                                                 | 利用者側に残る作業                       |
| --------------------------------------------------- | ----------------------------------- | ----------------------------------------------------------------------- | ------------------------------- |
| ニューラル機械翻訳エンジン (Google Translate、DeepL)              | 文やドキュメントを高速かつ一貫性のある品質で、低コストに翻訳      | 用語集。DeepL はさらに文脈フィールド、敬語レベル、カスタム指示に対応。Google の Advanced エディションは例文ペアにも対応 | 短い文字列の文脈付け、プレースホルダー、複数形、レビュー、配信 |
| 大規模言語モデルの直接呼び出し (OpenAI API、Claude API、Gemini API)  | トーン、用語、書式に関する指示に沿った自然な出力            | プロンプトに含めた内容すべて                                                          | 文字列ごとの文脈の用意、実行間での用語の統一、出力の検証、配信 |
| General Translation                                 | リリースの一環としてアプリやファイルの翻訳を生成            | マークされた JSX 構造またはファイルの文脈、共有の用語集とカスタムプロンプト                                | エディターでの文言のレビューと、翻訳済みプロダクトのテスト   |
| プロの人間の翻訳者                                           | 慣用表現、文化、ブランドボイス、法的文書や規制対象テキストに関する判断 | プロダクトそのもの、スタイルガイド、利用者への質問                                               | 納期と単語単価。いずれもリリースを重ねるごとに膨らむ      |

DeepL と Google Translate の比較について：WMT ではこれらの名前が公表されていないため、各 API が受け付ける内容で比較してください。DeepL の [translate API](https://developers.deepl.com/api-reference/translate) には、それ自体は翻訳も課金もされずに翻訳結果に影響を与える `context` パラメータ、対応言語向けの `formality` 設定、用語集、最大 10 個のカスタム指示があります。Google の [Cloud Translation](https://docs.cloud.google.com/translate/docs/overview) Advanced エディションには、ニューラルモデルに加えて Translation LLM、用語集、そして少数の例文ペアから学習するアダプティブ翻訳が用意されています。どちらかに決める前に、実際の文字列のサンプルを対象言語で両方に通して比較してみてください。

## AI翻訳のエラーはどこから生じるのか

文脈の欠如、モデルの限界、インテグレーションのミスは、いずれも本番環境でエラーを引き起こす原因になります。次のような失敗パターンを確認しておきましょう。

* **曖昧な短い文字列。** 「Save」はドイツ語では *speichern* (ディスクに書き込む) にも *sparen* (お金を節約する) にもなります。単語だけを渡されたモデルは推測するしかありません。
* **用語の揺れ。** 製品名や機能名がアプリとドキュメントで別々に訳されたり、リリースごとに訳が変わったりします。
* **敬語とレジスター。** ドイツ語の *du* と *Sie*、フランス語の *tu* と *vous*、日本語の敬語レベルなどです。ルールがないと、モデルは文字列ごとにどちらかを選ぶため、同じ画面内に両方が混在することがあります。
* **プレースホルダーとマークアップ。** `{{name}}`、`{count}`、`<1>terms</1>` の名前を変えたり削除したりすると、実行時に補間が壊れる可能性があります。一方で、対象言語によっては、プレースホルダー自体は変えずに順序だけを入れ替える必要があります。
* **複数形。** 英語の複数形カテゴリは2つですが、ポーランド語には4つ、アラビア語には6つあります ([CLDR plural rules](https://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html)) 。英語の `one` と `other` の文字列を翻訳するだけでは、残りのカテゴリが欠落します ([How do I handle plurals in React?](/kb/how-to-handle-plurals-in-react) を参照してください) 。
* **長さの制限。** 意味が正しくても、翻訳が固定幅のボタンやタブに収まらないことがあります。実際に使うフォントとレイアウトでテキストを測定してください。文字数制限を設けるだけでは、収まるとは限りません。
* **低リソース言語と方言。** WMT25 で示されたように、広く話されている言語以外では品質が大きく低下し、方言が標準変種に吸収されてしまうことがあります。

## AI翻訳を本番環境で使える品質にするために、チームが行っていること

AI翻訳を実際にリリースしているチームは、モデルを取り巻く次の5つの取り組みを行っています。

1. **各文字列に文脈を付けて送る**：表示される場所や役割を伝え、曖昧な箇所にはメモを添えます。
2. **用語を用語集で固定する**：決して翻訳してはならない名称も含めます。
3. **スタイルルールを一度定義しておく**：言語ごとに敬語レベル、対象読者、表記規則を定めます。
4. **リスクの高いユーザー接点は有資格のレビュアーが確認する**：料金、チェックアウト、法的文書、安全に関するメッセージのほか、規制対象となるあらゆるコンテンツが該当します。リスクの低い文字列については、自動チェックを翻訳品質の評価とみなすのではなく、言語ごとの測定結果に基づいてレビュー方針を定めます。
5. **リリース前に自動QAチェックを実行する**：メッセージファミリーとプレースホルダーのマッチング、必須の複数形カテゴリ、レイアウト上の制限といった機械的なエラーを検出します。i18nextおよびICUファイル向けのチェック項目は[JSON翻訳ガイド](/kb/translate-json-files)にまとめています。なお、これらのチェックで意味や自然さは評価できません。

評価には、実際のラベル、完全な文、エラーメッセージ、補間値、複数形、ドメイン固有の用語を使いましょう。翻訳元、文脈、モデルのバージョン、出力、レビュアーの指摘はまとめて保管します。どのシステムが生成したかをレビュアーに伏せた状態で出力を比較し、エラーを言語別・重大度別に報告します。モデルや翻訳指示を変更した際は、同じケースで再確認してください。こうして得られたデータが、リリース方針の根拠になります。WMTの結果だけでは十分な根拠になりません。

単発のテキスト、社内向けコンテンツ、自分で確認するプロトタイプであれば、機械翻訳エンジンやLLMを直接使えば十分です。法務、医療、規制対象のテキストや、ニュアンスが特に重要なブランドコピーには、プロの翻訳者を起用してください。製品のリリースに合わせて翻訳を常に最新に保つ必要がある場合は、General Translationをお選びください。モデル呼び出しごとにパイプラインを自前で組み立てなくても、翻訳元の文脈、共有用語、生成、レビューを一貫してつなげられます。なお、WMT25ではGeneral Translationは評価対象外のため、そのランキングはGTの翻訳品質を示す根拠にはなりません。

## General Translation が文脈と一貫性をもたらす仕組み

React アプリでは、General Translation の [`<T>`](/docs/react/reference/components/t) コンポーネントで、翻訳対象とする JSX のまとまりを指定します。CLI がそのテキストと要素構造を抽出し、GT のサービスが翻訳を生成し、SDK がその翻訳をレンダリングします。曖昧な箇所がある場合は、[`context`](/docs/react/reference/components/t#context) プロパティでメモを追加できます：

```tsx title="SaveButton.tsx"
import { T } from 'gt-react';

export function SaveButton() {
  return (
    <T context="Editor toolbar. Save means write the document to disk.">
      <button>Save</button>
    </T>
  );
}
```

このメモによって、モデルはこの&quot;Save&quot;が料金プランの切り替え (&quot;Save 20%&quot;) で使われる *sparen* ではなく、*speichern* であると判断できます。CLI で翻訳する JSON や YAML ファイルでは、対応ファイルとなる[キーごとのメタデータ](/docs/cli/reference/keyed-metadata)ファイルがキー単位で同じ役割を果たします。任意で `maxChars` による文字数制限も指定できます。

一貫性を担保するのは、ダッシュボードのコンテキストグループです。用語集では製品名などの用語をすべての言語で統一でき、カスタムプロンプトではドイツ語で敬称&quot;Sie&quot;を使うといったルールを設定できます。これらは割り当てたすべてのプロジェクトで共有されます ([翻訳の文脈を定義する](/docs/platform/dashboard/guides/defining-context-for-translations)を参照) 。レビュー担当者は、ダッシュボードの **Translations** ページでロケールを並べて比較しながら、どの翻訳でも確認・編集できます ([翻訳のレビューと編集](/docs/platform/dashboard/guides/reviewing-translations)を参照) 。文字列ごとに Google Translate を呼び出す方法との違いについては、[General Translation と Google Translate の比較](/kb/general-translation-vs-google-translate)をご覧ください。

## 重要なポイント

* WMT25 では、Gemini 2.5 Pro が 16 の言語ペアのうち 10 で人間による参照訳と同等以上の品質を示しました。一方、マサイ語のような低リソース言語への翻訳は、大半が実用に耐えない品質でした。
* 短い文字列、用語、敬語レベル、プレースホルダー、複数形カテゴリ、レイアウトは、すべての対象言語でテストしてください。文書単位のベンチマークでは、インターフェースの品質までは測れません。
* 文脈、用語集、スタイルルールを用意すると、入力の質が向上します。構造の検証は自動チェックで行い、意味の正確さとリリース可否は資格のあるレビュアーが判断します。
* WMT では商用エンジンが匿名化されているため、DeepL と Google Translate は自社の文字列を使って比較し、各 API が受け付ける入力の違いも考慮してください。DeepL には 文脈フィールドと敬語レベルの指定があり、Google には例文ペアを使ったアダプティブ翻訳があります。

## Related questions

- [Google 翻訳の代替：General Translation と Google 翻訳の比較](https://generaltranslation.com/ja/kb/general-translation-vs-google-translate.mdx): Google 翻訳は、単発のテキストをすばやく翻訳するのに便利ですが、製品を別の言語でリリースするには、各文字列を文脈に沿って翻訳し、用語を統一し、変数や複数形を正しく扱い、レビューを行い、リリースプロセスを整える必要があります。General Translation はコード内の各文字列の文脈を理解し、コードからレビュー、そして毎回のリリースまで、ローカライゼーションのワークフロー全体を自動化します。
- [i18n の JSON ファイルを翻訳するには？](https://generaltranslation.com/ja/kb/translate-json-files.mdx): JSON ロケールファイルでは、文字列の値だけを翻訳します。複数形以外のキー、{{name}} などのプレースホルダー、タグは変更せずに残しますが、複数形のキーは言語によって異なる点に注意が必要です。たとえばポーランド語では inbox_few と inbox_many が必要になります。ファイル形式に対応したツールや API を使い、レビューの前に出力をパースして検証してください。
- [翻訳管理システム（TMS）とは？](https://generaltranslation.com/ja/kb/what-is-a-translation-management-system.mdx): 翻訳管理システム（TMS）とは、ソースコンテンツとその翻訳を保管し、翻訳メモリ、用語集、レビュー、機械翻訳、外部連携といった翻訳ワークフローを運用するソフトウェアです。翻訳メモリは、完全一致またはあいまい一致によって過去の翻訳を再利用します。代表的な例として Crowdin、Lokalise、Phrase、Smartling、Transifex があります。
- [General Translation と TMS（Crowdin、Lokalise、Phrase）の比較](https://generaltranslation.com/ja/kb/general-translation-vs-tms.mdx): 翻訳の生成、コードから導出した文脈、レビューをプロダクトのリリースと連動させたい開発チームには General Translation が適しています。既存のカタログとレンダリングライブラリをそのまま使うことも、翻訳キーを使わずにインライン JSX を記述することもできます。TMS は、言語ベンダー、CAT エディター、XLIFF でのやり取りを中心とした翻訳プログラムに適しており、そのインテグレーションを使えばファイル転送を自動化できます。
- [React で複数形を扱うにはどうすればよいですか？](https://generaltranslation.com/ja/kb/how-to-handle-plurals-in-react.mdx): React で複数形を扱うには、各言語の複数形ごとに文を 1 つずつ用意し、その言語の複数形規則に従って選択します。英語の複数形は 2 種類ですが、ロシア語は 4 種類、アラビア語は 6 種類あるためです。gt-react と gt-next に含まれる General Translation の `<Plural>` コンポーネントに翻訳元の形を渡せば、各対象言語に必要な形は General Translation が生成します。

## Previous and next questions

- Previous question: [多言語アプリのローカライゼーションテスト チェックリスト](https://generaltranslation.com/ja/kb/multilingual-app-launch-checklist.mdx)
- Next question: [CSS で RTL（右から左）言語をサポートするには？](https://generaltranslation.com/ja/kb/right-to-left-css.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/ja/kb/sitemap.md) for every article.