# General Translation Knowledge Base: AI翻訳で用語の一貫性を保つにはどうすればよいですか？
URL: https://generaltranslation.com/ja/kb/ai-translation-glossary.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 翻訳しない名称も含めた承認済み用語を一つの用語集にまとめてすべての翻訳リクエストに適用し、変数やコードは翻訳対象から外したうえで、結果をレビューします。General Translation では、コンテキストグループを使ってこれを実現します。コンテキストグループの用語集とカスタムプロンプトは、割り当てたすべてのプロジェクトに適用されます。また、翻訳してはならない値には Var コンポーネントを使用します。
Category: 翻訳
Last updated: 2026-10-28
Authors: General Translation Team
Published: 2026-10-28

用語の一貫性を保つには、承認済みの訳語をまとめた用語集を一つ用意してすべての翻訳リクエストに適用し、翻訳してはならないテキストにはマークを付け、出力をレビューで確認します。用語がぶれるのは、機械翻訳エンジンや大規模言語モデルがリクエストを一つずつ独立して処理するためです。先週採用した訳語も、明示的に渡さない限り今週の翻訳には引き継がれません。

## AI翻訳で用語がぶれるのはなぜか？

たとえば、製品に Vault という機能があるとします。文字列を1つずつドイツ語に翻訳すると、料金ページでは *Tresor*、アプリでは「Vault」のまま、ドキュメントでは *Safe* になることがあります。個々の訳はどれも妥当ですが、並べてみると3つの別々の機能を説明しているように見えてしまいます。用語のぶれには、いくつかの原因があります。

* **リクエストのたびにゼロから翻訳される。** DeepL の API リファレンスには、リクエスト内の各文字列は[個別に翻訳される](https://developers.deepl.com/api-reference/translate/request-translation)と記載されています。LLM は呼び出しのたびに言い回しを選び直すため、モデルのバージョンが変われば訳語も変わる可能性があります。
* **短い文字列には文脈がほとんどない。** 「Vault」や「Spaces」というタブ名は普通名詞として読めてしまうため、エンジンも普通名詞として翻訳します。
* **ユーザー接点ごとにツールが異なる。** アプリの文字列はあるツール、ドキュメントは別のツール、マーケティングページは外部ベンダーという体制では、用語集が3つに分かれるか、そもそも存在しない状態になります。
* **文法によって語形が変わる。** ドイツ語やポーランド語では名詞に格語尾が付くため、承認済みの訳語はそのまま貼り付ければよい文字列ではなく、文に応じて語形変化させるべき基本形です。

ルールを定めるべき用語としては、主にブランド名や製品名、機能名、ドキュメント内で言及する UI ラベル (「**保存** をクリック」は各言語のボタン表記と一致していなければなりません) 、業界用語、そしてコード、変数、URL、ユーザーデータなど、記述どおりに保持すべきものが挙げられます。

## 各選択肢の比較

| アプローチ                                      | 用語の一貫性を保つ仕組み                                                                                              | 弱点                                                  |
| ------------------------------------------ | --------------------------------------------------------------------------------------------------------- | --------------------------------------------------- |
| 機械翻訳の用語集 (DeepL、Google Cloud Translation)  | 言語ペアごとに用語ペアを定義し、リクエストのたびに ID を指定して適用                                                                      | 呼び出しのたびに ID を渡し、言語ペアごとに管理する必要がある。短い文字列は依然として文脈が不足する |
| LLM プロンプト内での用語指定 (OpenAI API、Claude API)   | プロンプトごとに用語とルールを列挙する                                                                                       | どの文字列にどの用語が必要かを自分で判断する必要があり、チェック機構を自作しない限り出力は検証されない |
| 翻訳管理システム (TMS) の用語ベース                      | 翻訳者と AI が承認済みの用語を参照でき、QAチェックで漏れを検出できる                                                                     | コードとは切り離された TMS 内で管理され、プロジェクトごとに接続が必要               |
| 翻訳除外マークアップ (`translate="no"`)              | マークされた要素をエンジンが翻訳せずにスキップする                                                                                 | HTML 入力にのみ対応。テキストをそのまま残すことはできるが、訳語を指定することはできない      |
| General Translation のコンテキストグループ            | 割り当てられた各プロジェクトのすべての翻訳に、用語集とカスタムプロンプトが適用される。[`<Var>`](/docs/react/reference/components/var) で値を翻訳対象から除外できる | 既存の翻訳は、用語集を適用するか再翻訳しない限り変更されない                      |

### 機械翻訳の用語集

DeepL の[多言語用語集](https://developers.deepl.com/docs/customize/managing-glossaries)は、言語ペアごとに用語ペアの辞書を1つずつ保持し、TSV または CSV 形式でアップロードします。1回のリクエストで `glossary_ids` を使って最大5つまで適用できます。Google Cloud Translation の[用語集](https://docs.cloud.google.com/translate/docs/advanced/glossary)は、1つの言語ペアの用語ペア、または複数言語にまたがる同義語セットを、TSV、CSV、TMX ファイルから読み込みます。Google では `ignoreCase` を設定しない限り、用語は大文字と小文字を区別して照合されます。また、用語集を適用した翻訳と適用しない翻訳の両方が返されるため、結果を比較できます。なお、文脈を考慮する用語集モードは Translation LLM でのみサポートされています。

### LLM プロンプト内の用語

OpenAI API や Claude API を使う場合、用語集はプロンプト内のテキストとして渡します。文字列に含まれる用語だけを送信し、JSON スキーマに沿った出力を指示したうえで、承認済みの各用語が翻訳に反映されているかを後から確認します。モデルは指示によく従いますが、用語の選定や確認、複数のスクリプトにまたがって用語リストを最新に保つ作業は、すべて自分で担う必要があります。

### TMSにおける用語ベース

[翻訳管理システム](/kb/what-is-a-translation-management-system)では、用語ベースを文字列と一緒に管理します。翻訳者はエディター上で該当する用語を確認でき、AI翻訳でも用語を活用できます (Crowdinの[AIプロンプト](https://support.crowdin.com/crowdin-ai/)には用語集の用語を含めることができます) 。さらに、QAチェックで用語の使い漏れを検出できます。たとえばCrowdinの[Consistent terminology](https://support.crowdin.com/project-settings/qa-checks/)チェックでは、翻訳元の単語に対応する用語集の用語が使われていない翻訳を検出して警告します。

### 翻訳除外マークアップ

HTML の [`translate` 属性](https://html.spec.whatwg.org/multipage/dom.html#the-translate-attribute)を `no` に設定すると、要素のテキストを変更しないよう翻訳ツールに指示できます。DeepL は、`tag_handling` が `html` の場合、`translate="no"` または `class="notranslate"` が指定された要素をスキップします ([Translating HTML](https://developers.deepl.com/docs/translate/translating-html)) 。Google Cloud Translation も、`text/html` 形式の入力に対して同様に動作します ([troubleshooting](https://docs.cloud.google.com/translate/troubleshooting)) 。プレーンテキストのリクエストでは、この指定は無視されます。

自社のパイプラインから DeepL や Google を直接呼び出すなら、機械翻訳の用語集を使いましょう。製品で既に行っているモデル呼び出しの中で翻訳するなら、プロンプトで指示するのが適しています。翻訳者やベンダーが TMS 上で作業するなら、その TMS の用語ベースを使います。エンジンに送信する HTML には `translate="no"` を使います。スクリプトごとに用語集を渡さなくても、アプリ、ドキュメント、その他のコンテンツ全体で、リリースのたびに用語を統一しておきたい場合は、General Translation を使用してください。

## General Translationが用語の一貫性を保つ仕組み

General Translationは、[コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations)を使って用語を適用します。コンテキストグループは組織レベルで管理する再利用可能な指示のセットで、割り当てたすべてのプロジェクトに適用されます。各コンテキストグループには、用語を定義する用語集と、トーンやスタイルを指定するカスタムプロンプトが含まれています。

### コンテキストグループを設定する

1. ダッシュボードで、組織のサイドバーにある **Context** を開き、プラス記号をクリックして **Create new group** を選択します。プロジェクトの **Context** ページから作成した場合は、**Autogenerate context** を選択すると、そのプロジェクトのファイルをもとに用語集の用語とカスタムプロンプトの下書きを自動生成できます。
2. **用語集** タブで用語を追加し、それぞれに意味と扱い方を説明する定義を記入します。
3. 各対象ロケールの訳語を入力します。直接入力するか、CSV、TSV、JSON ファイルをインポートするか、プロジェクトの **Context** ページで **Translate** をクリックすると、まだ訳語のない用語を AI が補完します。その後、必要に応じて各セルを修正してください。
4. **カスタムプロンプト** タブで、トーンやスタイルに関するルールを追加します (例：ドイツ語のみに「Use the formal Sie」を適用) 。各プロンプトは、すべてのロケール、または特定の 1 つのロケールに適用できます。
5. 各プロジェクトの **Context** タブから、そのプロジェクトにグループを割り当てます。グループが重複する場合は、リストの最上位にあるグループが優先されます。

Vault の例では、用語集は次のようになります。

| 用語        | 定義                      | `de`           | `ja`    |
| --------- | ----------------------- | -------------- | ------- |
| Vault     | 暗号化フォルダーの製品名。英語のまま表記する。 | Vault          | Vault   |
| Workspace | アプリ内でチームが共有するエリア。       | Arbeitsbereich | ワークスペース |

デフォルトの **管理者** ロールと **編集者** ロールは、コンテキストグループを編集できます。

### 用語集が各翻訳に反映される仕組み

General Translation は、翻訳する文字列ごとに、その文字列に含まれる用語集の用語を検出し、各用語の定義と対象ロケールでの訳語を文字列と一緒に送信します。モデルは承認済みの訳語を基本形として扱い、文に合わせて活用させます。また、単語が定義とは異なる意味で使われている場合は、通常どおりに翻訳します。同じコンテキストグループが、[`<T>`](/docs/react/reference/components/t) のコンテンツ、[`npx gt translate`](/docs/cli/reference/commands/translate) で翻訳するファイル、[`tx`](/docs/node/reference/functions/tx) による実行時翻訳、さらに [Locadex](/docs/platform/locadex/quickstart) が生成する翻訳にも適用されます。そのため、アプリ、ドキュメント、マーケティングサイトのいずれでも「Vault」という訳語が統一して使われます。

### `<Var>` で値を翻訳対象から除外する

名前、ID、コード、その他のランタイム値など、一切変更せずにそのまま残すべきテキストもあります。General Translation の [`<Var>`](/docs/react/reference/components/var) は中身をそのままレンダリングし、その内容が General Translation API に送信されることはありません。

```tsx title="InviteBanner.tsx"
import { T, Var, Plural, Num } from 'gt-react';

export function InviteBanner({
  inviterName,
  vaultCount,
}: {
  inviterName: string;
  vaultCount: number;
}) {
  return (
    <T context="Team settings banner. Vault is our product name for an encrypted folder.">
      <p>
        <Var>{inviterName}</Var> invited you to their workspace.{' '}
        <Plural
          n={vaultCount}
          one={<>You can open one Vault.</>}
          other={<>You can open <Num>{vaultCount}</Num> Vaults.</>}
        />
      </p>
    </T>
  );
}
```

招待者の名前は [`<Var>`](/docs/react/reference/components/var) 内に残します。&quot;Vault&quot; は文中に残すため、用語集によって英語のまま保持され、モデルはその語に合わせて文法を組み立てます。さらに、[`<Plural>`](/docs/react/reference/components/plural) には対象言語に必要なすべての複数形が渡されます。製品名は [`<Var>`](/docs/react/reference/components/var) ではなく用語集に登録してください。そうすれば、モデルが名前を把握したうえで、それに合わせて文を組み立てられます。

### 既存の翻訳を更新する

コンテキストグループを編集しても反映されるのは新しい翻訳のみで、既存の翻訳は変更されません。既存のコンテンツにも反映させるには、プロジェクトの **Context** ページで **Apply** をクリックし、更新対象の用語集の用語とロケールを選択します。または、CLI や Locadex の実行でファイルを再翻訳してください ([用語集の訳語を適用](/docs/platform/dashboard/guides/defining-context-for-translations#apply-glossary)を参照) 。その後、その言語を理解できる人にダッシュボードで結果を確認してもらいましょう ([翻訳をレビュー・編集するには？](/kb/review-translations)を参照) 。

## よくある質問

### 用語集を使えば、承認済みの用語が毎回必ず使われますか？

用語集を設定すると承認済みの用語がデフォルトで使われるようになりますが、最終的なチェックはやはりレビューです。文法上、語形を変える必要がある場合もありますし、別の意味で使われている語に用語集の訳語を当てるべきではありません。[AI翻訳は本番環境のアプリに十分な精度がありますか？](/kb/is-ai-translation-accurate)で説明しているとおり、各言語で特にアクセスの多い画面をレビューしてください。

### ブランド名を翻訳せずに残すにはどうすればよいですか？

「Product name. Keep in English」のような定義を付けて用語集に用語として登録し、各ロケールの訳語にはその名前をそのまま指定します。DeepL や Google Cloud Translation に送信する HTML の場合は、`translate="no"` を指定した要素でラップしてください。

### 用語集と翻訳メモリの違いは何ですか？

用語集は、個々の用語の訳し方を統一するためのものです。一方、翻訳メモリは過去の翻訳を文単位で蓄積し、同じ文や類似した文が再び出てきたときに再利用します。 (詳しくは[翻訳メモリとは？AI時代にも必要なのか](/kb/what-is-translation-memory)を参照してください)

### 1つの用語集でアプリ、ドキュメント、Webサイトをまとめてカバーできますか？

はい。General Translation では、1つのコンテキストグループをすべてのプロジェクトに割り当てたうえで、用語やトーンが異なるユーザー接点にのみ、プロジェクト固有のグループを追加します。 (リクエストごとに用語集 ID を渡す方式との比較については、[General Translation vs. DeepL](/kb/general-translation-vs-deepl) を参照してください。)

## 重要なポイント

* 用語の揺れが生じるのは、翻訳リクエストがそれぞれ独立しており、短い文字列には文脈がほとんど含まれないためです。すべてのリクエストに用語集を適用すれば、この前提を変えられます。
* DeepL と Google Cloud Translation では、言語ペアごとに ID を指定して用語集を適用します。LLM のプロンプトでは用語の選定とチェックを自前で行う必要があります。TMS の用語ベースでは、Crowdin の Consistent terminology のような QAチェックも利用できます。
* `translate="no"` を指定すると、DeepL と Google Cloud Translation では HTML テキストが翻訳されずにそのまま残ります。ただし、訳語を指定する機能ではありません。
* General Translation のコンテキストグループを使うと、割り当てたすべてのプロジェクトで 1 つの用語集とカスタムプロンプトを共有できます。**Translate** はロケールで不足している用語の訳を補完し、**Apply** は既存の翻訳を更新します。また、[`<Var>`](/docs/react/reference/components/var) を使えば、ランタイムの値を翻訳対象から完全に除外できます。

## Related questions

- [AI翻訳は本番環境のアプリで使えるほど正確か？](https://generaltranslation.com/ja/kb/is-ai-translation-accurate.mdx): 広く話されている言語であれば多くの場合は十分な精度がありますが、それは自社の対象言語、UI文字列、リスクの高いコンテンツで評価をクリアしてからの話です。WMT25では、Gemini 2.5 Proが16の言語ペアのうち10で人間による参照訳と同等以上の評価を得ました。しかし、文書単位のベンチマークからは、短いインターフェース文字列をそのままリリースできるかどうかまではわかりません。
- [DeepL の代替：General Translation と DeepL の比較](https://generaltranslation.com/ja/kb/general-translation-vs-deepl.mdx): DeepL は機械翻訳 API で、送信したテキストやドキュメントごとに翻訳を返します。一方、General Translation はローカライゼーションプラットフォームです。API では利用者任せになる部分、つまりコードやチームから得られる文脈、あらゆるユーザー接点での用語の統一、ダッシュボードでのレビュー、リリースごとの継続的な翻訳までを担います。
- [開発者向けのおすすめ AI 翻訳ツール：翻訳 API とローカライゼーションプラットフォームの比較](https://generaltranslation.com/ja/kb/best-ai-translation-tools.mdx): ローカライゼーションのパイプラインをすでに自前で運用しているなら、翻訳 API を使いましょう。文脈の付与、一貫性チェック、レビュー、継続的な配信をまとめて管理したいなら、General Translation がおすすめです。DeepL、Google Cloud Translation、OpenAI、Claude は本番環境のパイプラインの基盤として使えますが、General Translation はアプリ、ドキュメント、サイト向けのパイプラインそのものを提供します。
- [翻訳をレビュー・編集するにはどうすればよいですか？](https://generaltranslation.com/ja/kb/review-translations.mdx): 各翻訳を翻訳元や他のロケールと見比べ、不自然な箇所を修正します。General Translation では、ダッシュボードの翻訳ページで翻訳を編集し、ラベルとコメントでレビューの進捗を管理します。編集内容は、AIエージェントである Locadex による次回の翻訳実行でプルリクエストに取り込まれます。
- [翻訳メモリとは？AI時代にもまだ必要なのか](https://generaltranslation.com/ja/kb/what-is-translation-memory.mdx): 翻訳メモリ（TM）は、過去の翻訳元と訳文のセグメントのペアを蓄積したデータベースで、翻訳ツールはこれを検索して完全一致、文脈一致、ファジーマッチを見つけます。AIを使う場合でも、承認済みの訳語を再利用し、過去の翻訳を文脈として参照できるようにしておくことは重要です。General Translation は、ファイルの以前のバージョンからマッチする翻訳を再利用し、チームによる編集も保持するため、TM を別途管理する必要はありません。

## Previous and next questions

- Previous question: [.NET アプリで .resx ファイルを翻訳するには？](https://generaltranslation.com/ja/kb/translate-resx-files.mdx)
- Next question: [DeepL の代替：General Translation と DeepL の比較](https://generaltranslation.com/ja/kb/general-translation-vs-deepl.mdx)

## Sitemap

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