# General Translation Knowledge Base: ソフトウェアの文字列をAI翻訳する際、十分な文脈を与えるにはどうすればよいですか？
URL: https://generaltranslation.com/ja/kb/ai-translation-context.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: メッセージは分割せず、意味に関するメモ、プレースホルダーの役割、文字数制限、共通の用語を添えて翻訳します。General Translation の CLI は、マークされた JSX を構造化されたブロックとして抽出し、コンテキスト注記を翻訳の生成時にも引き継ぎます。既存の JSON や YAML のカタログでは、キーごとのメタデータで文字列ごとに指示を与えられます。コンテキストグループは、割り当てられたすべてのプロジェクトに用語集とカスタムプロンプトを適用し、レビュー担当者はダッシュボードで出力を修正します。
Category: 翻訳
Last updated: 2026-11-13
Authors: Jackie Chen
Published: 2026-11-13

短いインターフェースの文字列でも、正しい訳が複数ありえます。たとえば「Free」は、料金プランのバッジでは「無料」 (ドイツ語では *kostenlos*) 、座席表では「空席」 (ドイツ語では *frei*) という意味になります。単語だけでは、どちらの意味なのか判別できません。人間の翻訳者なら確認するはずの情報、つまりそのテキストが何を表しているのか、ユーザーが次に何をできるのかを一緒に渡しましょう。

## 翻訳モデルにはどのような文脈が必要か？

| 文脈              | モデルに伝わる内容                            | 例                                      | 提供方法                     |
| --------------- | ------------------------------------ | -------------------------------------- | ------------------------ |
| 前後の文または UI ブロック | リンクやフォーマットも含め、語句同士がどのようにつながっているか     | 「続行する前に**利用規約**をお読みください」を 1 つの文として翻訳する | 断片ではなく、ブロック単位で翻訳する       |
| 意味に関するメモ        | 曖昧な語がどの意味で使われているか                    | 「Free」は「空いている」という意味                    | 説明、コメント、または `context` メモ |
| UI 上の役割と文字数制限   | ボタン、見出し、ツールチップのどれにあたるか、どれだけのスペースがあるか | 12 文字以内に収める必要があるタブのラベル                 | 役割に関するメモと最大文字数           |
| 変数とプレースホルダー     | 値に何が入るか、その値を翻訳してはならないこと              | `{name}` は人の名 (ファーストネーム)               | プレースホルダー構文とメモ            |
| 用語              | 承認済みの訳が 1 つに決まっている製品名や用語             | 「Workspace」は決して「office」と訳さない           | 用語集                      |
| トーンとフォーマル度      | 製品がどのような口調で語りかけるか                    | ドイツ語では敬称の *Sie* を使う                    | スタイルルール                  |
| 表示される場所         | その文字列が表示される画面の様子                     | チェックアウトページのスクリーンショット                   | TMS に添付したスクリーンショット       |

用語とスタイルルールはすべての文字列に適用されるため、一度設定しておけば済みます。用語の一貫性を保つ方法については[用語集ガイド](/kb/ai-translation-glossary)をご覧ください。それ以外は文字列ごとの文脈であり、ワークフローによって最も差が出る部分です。

## カタログベースのワークフローでは文脈をどのように渡すのか？

文字列がキーと値のカタログで管理されている場合、文脈は各キーに付随するフィールドで受け渡されます。

* **メッセージの説明。** [react-intl のメッセージ記述子](https://formatjs.github.io/docs/react-intl/api#message-descriptor)は `description` を受け取り、抽出時にこれを保持できます。gettext の PO ファイルには、翻訳者向けの抽出コメント (`#.`) と、同じ文字列でも意味が異なるものを区別するための [`msgctxt`](https://www.gnu.org/software/gettext/manual/html_node/Contexts.html) があります。
* **プラットフォームのコメント。** Android XML と Apple の `.strings` ファイルはコメントに対応しており、Apple String Catalogs と .NET の `.resx` エントリにはコメントフィールドがあります。エクスポート処理や翻訳インテグレーションでは、これらのメモを確実に引き継ぐ必要があります。
* **キー名。** `pricing.badge.free` のようなキーは意味の手がかりになりますが、モデルがそれだけに頼れるわけではありません。意味に基づくキーの命名については、[キー命名ガイド](/kb/i18n-key-naming)を参照してください。
* **TMS のフィールド。** 翻訳管理システムでは、キーごとに説明、スクリーンショット、文字数制限を追加できます。たとえば [SimpleLocalize](/kb/general-translation-vs-simplelocalize) は、キーごとに開発者が書くコード説明と翻訳者向けの説明を保持します。[SimpleLocalize AI](https://simplelocalize.io/docs/general/auto-translation/#simplelocalize-ai) は、翻訳時にこれらの説明、スクリーンショット、コメントを活用します。

各文は、プレースホルダーやマークアップを含めて分割せずに扱ってください。カタログなら 1 つのキーにまとめられますが、個別に翻訳される断片に分けてしまうと、語順の入れ替えが難しくなります。そのうえで、メモが翻訳ステップまで届いているかを確認してください。エディターやソースファイルに書いた説明も、インテグレーションが受け渡さなければ役に立ちません。

## General Translation はコードから文脈をどのように送信するのか？

General Translation の起点はコンポーネントです。[`<T>`](/docs/react/reference/components/t) で JSX のブロックをマークすると、CLI がそのテキスト、要素構造、変数プレースホルダー、メモを抽出して翻訳サービスに送ります。SDK は、ランタイムの値を使って結果をレンダリングします。

```tsx title="src/SeatStatus.tsx"
import { T, Var } from 'gt-react';

export function SeatStatus({ seat }: { seat: string }) {
  return (
    <T context="Seat map. Free means the seat is available, not that it costs nothing.">
      <p>
        Seat <Var>{seat}</Var> is free. <a href="/checkout">Book it now</a>
      </p>
    </T>
  );
}
```

* **ブロックが翻訳の単位です。** 文、座席のプレースホルダー、リンクテキストがまとめて送られるため、サービスは要素を保持したまま翻訳し、語順を入れ替えることができます。座席のランタイム値はアプリ内に留まります。分岐を含む文での動作については、[条件付き JSX ガイド](/kb/translate-conditional-jsx)を参照してください。
* **メモと制限はテキストのすぐそばに記述します。** `context` プロパティで曖昧さを解消し、`maxChars` プロパティで best-effort の文字数制限を指定します。たとえばタブのラベルには `<T maxChars={12}>` のように指定します。JSX 外の文字列では、[`gt()`](/docs/react/reference/hooks/use-gt) で同じオプションを `$context` と `$maxChars` として渡せます。
* **ソースコードを文脈として使用。** `gt.config.json` の `files.gt.parsingFlags` で `includeSourceCodeContext` を `true` に設定すると、周辺のソースコード行が追加の文脈として送信されます。この機能はオプトインで、抽出されたブロックを補完します。 ([インラインコンテンツの解析](/docs/cli/reference/formats/gt-jsx-files#parsing)を参照してください。) 
* **翻訳しない値。** 名前、メールアドレスなどの動的な値は [`<Var>`](/docs/react/reference/components/var) でラップします。中身は翻訳に送信されず、翻訳結果でもプレースホルダーは元の位置に保持されます。
* **既存カタログ向けの文脈。** JSON および YAML ファイルでは、[キーごとのメタデータ](/docs/cli/reference/keyed-metadata)の対応ファイルで、キーごとに `context` メモと `maxChars` 制限を追加できます。[Android `strings.xml`](/docs/cli/reference/formats/android-strings-files)、[Apple `.strings`](/docs/cli/reference/formats/dot-strings-files)、[`.resx`](/docs/cli/reference/formats/resx-files) ファイル内のコメントは、文脈として翻訳に渡されます。
* **用語とトーンの共有。** [コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations)には用語集とカスタムプロンプトが含まれ、割り当てたすべてのプロジェクトに適用されます。プロジェクトから **Autogenerate from project files** で作成すると、既存のテキストをもとに用語とプロンプトのドラフトが生成されます。また、コーディングエージェントも General Translation の [MCP サーバー](/docs/overview/for-coding-agents#mcp)経由でこれらを更新できます。

キーベースのカタログでは、同じ座席表に関する指示をソースファイルのそばに置きます。次の 2 つのファイルを使えば、既存のキーとライブラリをそのまま使い続けられます。

```json title="locales/en.json"
{
  "seatStatus": "Free"
}
```

```json title="locales/en.metadata.json"
{
  "seatStatus": {
    "context": "Seat map. Free means the seat is available, not that it costs nothing.",
    "maxChars": 12
  }
}
```

## 文脈が十分かどうかを判断するには？

1語だけのボタン、複数の意味を持つ単語、変数を含む文、複数形をピックアップします。それらをリリース対象の言語に翻訳し、各言語を読める人に[ダッシュボード](/kb/review-translations)で確認してもらいます。そこで現在の文言を修正したうえで、不足している情報を適切な場所に追加します。その文字列に対する `context` のメモとして追加するか、同じ問題が繰り返し起こりそうな場合は用語集の用語やカスタムプロンプトとして追加してください。更新した指示はそれ以降の生成に反映されますが、保存済みの翻訳が自動的に書き換えられるわけではありません。より本格的な評価の方法については、[AI翻訳の精度ガイド](/kb/is-ai-translation-accurate)を参照してください。

## 重要なポイント

* JSX で記述する場合でもカタログのキーで管理する場合でも、メッセージとそのプレースホルダーは一緒にまとめておきましょう。
* General Translation は、マークアップされた構造と明示的なメモを翻訳生成に反映します。オプトインで翻訳元の行を含めたり、共有のコンテキストグループを利用したりすることで、メッセージ単体では伝わらない意味を補えます。
* 既存の出力を修正するだけでなく、今後の翻訳のために指示も改善しましょう。意味とレイアウトは分けて確認してください。

## Related questions

- [AI翻訳で用語の一貫性を保つにはどうすればよいですか？](https://generaltranslation.com/ja/kb/ai-translation-glossary.mdx): 翻訳しない名称も含めた承認済み用語を一つの用語集にまとめてすべての翻訳リクエストに適用し、変数やコードは翻訳対象から外したうえで、結果をレビューします。General Translation では、コンテキストグループを使ってこれを実現します。コンテキストグループの用語集とカスタムプロンプトは、割り当てたすべてのプロジェクトに適用されます。また、翻訳してはならない値には Var コンポーネントを使用します。
- [AI翻訳は本番環境のアプリで使えるほど正確か？](https://generaltranslation.com/ja/kb/is-ai-translation-accurate.mdx): 広く話されている言語であれば多くの場合は十分な精度がありますが、それは自社の対象言語、UI文字列、リスクの高いコンテンツで評価をクリアしてからの話です。WMT25では、Gemini 2.5 Proが16の言語ペアのうち10で人間による参照訳と同等以上の評価を得ました。しかし、文書単位のベンチマークからは、短いインターフェース文字列をそのままリリースできるかどうかまではわかりません。
- [JSX の条件付きテキストはどのように翻訳すればよいですか？](https://generaltranslation.com/ja/kb/translate-conditional-jsx.mdx): 文を分割せずに、すべてのバージョンを翻訳します。三項演算子を使うと文が断片に分かれ、断片は意味を失ううえ、各言語の語順に沿った位置にも置けなくなります。General Translation では `<T>` の中で `<Branch>` を使い、文をひとつの単位として翻訳します。
- [翻訳者やローカライゼーションチームがいなくてもソフトウェアをローカライズできるか？](https://generaltranslation.com/ja/kb/localize-without-translators.mdx): はい、専任の翻訳チームがなくてもローカライズは可能です。General Translation は、コードの文脈と共有用語をもとに、新規・変更されたテキストをビルド時に生成します。さらに Locadex を使えば、React や Next.js の新しいテキストにマークを付けられます。バイリンガルのチームメンバーやフリーランスのレビュー担当者は、シート料金なしでダッシュボードから表現を修正できます。レビュー要件は、言語ごと、そして誤りが生じた場合の影響の大きさに応じて設定しましょう。
- [i18n の翻訳キーはどのように命名すべきですか？](https://generaltranslation.com/ja/kb/i18n-key-naming.mdx): キーは英語の文言ではなく、テキストが表示される場所と意味に基づいて命名します（例: checkout.summary.title）。英語が同じでも、用途が異なるものにはそれぞれ別のキーを割り当ててください。たとえばドイツ語では、ボタンの Open は Öffnen、ステータスの Open は Offen と訳されます。

## Previous and next questions

- Previous question: [General Translation と SimpleLocalize の比較：どちらを選ぶべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-simplelocalize.mdx)
- Next question: [翻訳者やローカライゼーションチームがいなくてもソフトウェアをローカライズできるか？](https://generaltranslation.com/ja/kb/localize-without-translators.mdx)

## Sitemap

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