# General Translation Knowledge Base: ビルド時、実行時、翻訳プロキシ：翻訳はどう配信すべきか？
URL: https://generaltranslation.com/ja/kb/build-time-vs-runtime-translation.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: General Translation を使えば、リリース前にアプリの既知の翻訳を生成し、コードにバンドルするか CDN から読み込めます。バンドルでは文言がリリースに紐づきますが、CDN 上で公開した修正はコードをデプロイしなくても新たなレンダリングに反映されます。訪問者がすぐに必要とするコンテンツにはリクエスト時の翻訳を、サイトのコードを変更できない場合はプロキシを使いましょう。
Category: 国際化
Last updated: 2026-11-12
Authors: Jackie Chen
Published: 2026-11-12

翻訳を訪問者に届ける方法は主に 4 つあります。ビルド時にアプリへバンドルする方法、ページのレンダリング時にコンテンツ配信ネットワーク (CDN) から読み込む方法、リクエストの処理中に API で翻訳する方法、そしてサイトの前段に置いたプロキシやスクリプトで HTML を差し替える方法です。どれを選ぶかによって、本番環境でアプリが何に依存するか、修正した翻訳がどのようにユーザーに届くか、そして検索エンジンが各言語をインデックスできるかどうかが決まります。

翻訳の生成と読み込みは分けて考えましょう。CDN は生成済みの翻訳を配信するだけなので、アクセスのたびに AI モデルを呼び出す必要はありません。デプロイ前に決まっているアプリの文言は、あらかじめ翻訳を生成し、バンドルまたは CDN から配信します。後から追加されるコンテンツは、公開時やバックグラウンドジョブで翻訳できます。訪問者にすぐ結果を返す必要がある場合は、リクエスト時の翻訳を使います。プロキシは、コードを変更できない、あるいは変更したくないサイトのための手段です。

## 配信方式の比較

| 方式                                                                                                                                                                            | 仕組み                                           | 本番環境が依存するもの                         | 修正した翻訳がユーザーに届くまで                              | 適したケース                                  |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | ----------------------------------- | --------------------------------------------- | --------------------------------------- |
| ビルド時にバンドル                                                                                                                                                                     | 翻訳ファイルをビルド前に生成し、ロケールごとにインポートする                | アプリ以外に依存なし                          | 次回のデプロイで反映                                    | 静的ページ、ISR、サーバーでレンダリングされたページを含む、ほとんどのアプリ |
| 実行時に CDN から読み込む                                                                                                                                                               | アプリが各ロケールの生成済み翻訳を取得する                         | CDN                                 | 修正を公開し、翻訳とページのキャッシュを更新する。完全に静的な HTML は再ビルドが必要 | リリースの合間にレビュー担当者が文言を修正するアプリ              |
| リクエスト時に翻訳                                                                                                                                                                     | リクエストの処理中に、サーバーが翻訳 API にテキストの翻訳を依頼する          | 翻訳 API (未翻訳のテキストをレンダリングするリクエストの場合)  | 送信したテキストと文脈をもとに、リクエストごとにレンダリング対象を翻訳する         | ユーザーの投稿、サポートの返信、AI の出力の即時翻訳             |
| プロキシまたはスクリプトによるオーバーレイ ([Weglot](https://weglot.com/technical-presentation/)、[Transifex Live](https://help.transifex.com/en/articles/6244596-introduction-to-transifex-live))  | プロキシが翻訳済みの HTML を配信する。オーバーレイはブラウザ上でテキストを置き換える | ベンダーの配信サービス (キャッシュの影響を受ける)          | ベンダーのダッシュボードで編集し、ベンダーの配信レイヤー経由で提供される          | 手を加えたくない完成済みのサイト、マーケティングサイト             |

コードと文言をまとめてレビューし、同時にリリースしたい場合は、build-time バンドルを使用してください。アプリのリリースの合間にレビュー担当者が文言の修正を公開できるようにしたい場合は、CDN を選択してください。たとえば、ドイツ語のボタンラベルの修正であれば、CDN から読み込むアプリは再ビルドなしで更新できます。ただし、新しいボタンを追加する場合は、従来どおりコンポーネントのデプロイが必要です。リクエスト時の生成は、完成済みの翻訳を読み込む場合に比べてレイテンシが増えるため、あらかじめわかっているインターフェースの文言は事前翻訳で扱うようにしてください。

## SEO に最適なアプローチはどれですか？

各言語に `/es/pricing` のような安定したクロール可能な URL を割り当て、その URL で翻訳済みコンテンツとメタデータを返してください。サーバーでレンダリングされたページや静的生成されたページなら、バンドルした翻訳や CDN から読み込んだ翻訳を使ってこれを実現できます。言語サブディレクトリ型のプロキシでも同じことが可能です。Google は[言語バージョンごとに別々の URL を使用することを推奨しています](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)。Google は [JavaScript をレンダリング](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)できますが、訪問者が言語切り替え機能をクリックして初めて同一 URL の表示言語を切り替えるオーバーレイ方式では、クロール可能な言語別ページが用意されません。hreflang とメタデータについては、[多言語 Next.js SEO ガイド](/kb/multilingual-nextjs-seo)を参照してください。

## エッジでレンダリングされる i18n と翻訳プロキシの違いは何ですか？

エッジでレンダリングされる i18n では、アプリケーションが独自のルートと翻訳を使って、エッジランタイム上で翻訳済みの HTML をレンダリングします。ロケールのミドルウェアを導入しただけでは、ページがエッジでレンダリングされるわけではありません。どのランタイムでレンダリングするかは、フレームワークとホスティングの選択によって別途決まります。ローカライズされたルート、レンダリングされるコンテンツ、キャッシュはすべて自分で管理できます。

一方、プロキシは翻訳元ではなく出力を翻訳します。[Weglot のリバースプロキシ](https://weglot.com/technical-presentation/)は、各ページを訪問者に届ける途中で翻訳し、繰り返しのリクエストをキャッシュし、新しいコンテンツは配信時に取り込みます。文言の編集はダッシュボードで行います。セットアップ手順は[ウェブサイトガイド](/kb/make-website-multilingual)をご覧ください。この方式は、静的かサーバーでレンダリングされたかを問わず、コンテンツを HTML として返すオリジンであれば機能します。ブラウザの JavaScript だけで生成されるテキストは、オリジンのレスポンスに含まれません。プロキシから見えるのはレンダリング済みの HTML 構造だけで、ソースのコンポーネントや開発者が付けたコンテキスト注記は自動的には引き継がれません。トレードオフについては [Weglot との比較](/kb/general-translation-vs-weglot)で解説しています。

## SSG、ISR、SSRを使うNext.jsアプリで翻訳を配信するにはどうすればよいですか？

ビルド前に翻訳を生成しておけば、どのレンダリングモードでもその翻訳を利用できます。General Translationの `gt-next` を使う場合は、`next build` の前に [`npx gt translate`](/docs/cli/reference/commands/translate) を実行してください。サーバーサイドレンダリング (SSR) では、翻訳キャッシュが更新されると、以降のレンダリングでCDNに公開済みの編集内容が使われます。静的サイト生成 (SSG) では、翻訳済みテキストがHTMLに埋め込まれ、再ビルドまたは再検証されるまでそのまま残ります。インクリメンタル静的再生成 (ISR) では、[再検証によってそのHTMLが再生成されます](https://nextjs.org/docs/app/guides/incremental-static-regeneration)。ただし、文言の修正が反映されるのは、翻訳キャッシュにも更新が反映された後です。完全な静的エクスポートの場合は、再ビルドが必要です。

App Routerでロケールごとにルートを事前レンダリングするには、`gt-next` のロケールミドルウェアを使用してルートを `app/[locale]` 配下に移動し、`generateStaticParams` からすべてのロケールを返します：

```tsx title="app/[locale]/page.tsx"
import { getLocales, T } from 'gt-next';

export function generateStaticParams() {
  return getLocales().map((locale) => ({ locale }));
}

export default function HomePage() {
  return <T>Welcome to our site</T>;
}
```

ここでは、Next.js クイックスタートのプラグインとプロバイダーのセットアップ、ルートの `locale` パラメータを読み取るルート直下の `getLocale.ts`、そして `undefined` を返す `getRegion.ts` が用意されていることを前提としています。対応している Next.js のバージョンと必要なファイルについては、[App Router 静的生成ガイド](/docs/react/nextjs/app-router-static-site-generation)を参照してください。Next.js のデプロイ環境でルートを事前レンダリングすることは、`output: 'export'` とは異なります。`output: 'export'` を使う場合は、ガイドに記載されている静的エクスポート用の設定も別途必要です。

## 実行時にのみ存在するコンテンツはどのように翻訳しますか？

訪問者がメモを開いた時点で翻訳する必要がある場合は、General Translation の [`<Tx>`](/docs/react/nextjs/reference/components/tx) コンポーネントと [`tx`](/docs/react/nextjs/reference/functions/tx) 関数を使用できます。これらは Next.js App Router のサーバーコンポーネントから翻訳 API を呼び出します。この例では、ロケールルーティングが設定済みで、`getNote` がメモを読み込むことを前提としています。

```tsx title="app/[locale]/notes/[id]/page.tsx"
import { Tx } from 'gt-next/server';
import { getNote } from '@/lib/notes';

export default async function NotePage({
  params,
}: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await params;
  const note = await getNote(id);
  return <Tx context="A note written by a user">{note.body}</Tx>;
}
```

本番環境では、サーバー上の `GT_API_KEY` に **実行時翻訳** を有効にしたプロジェクトキーを設定し、ブラウザには絶対に公開しないでください ([本番環境の認証情報](/docs/react/nextjs/config#credentials)を参照) 。リクエスト時の翻訳は、ビルド時翻訳とは別に課金されます。詳しくは[使用料金](https://generaltranslation.com/pricing/usage)を参照してください。Express API など、Next.js のサーバーコンポーネント以外の環境では、`gt-node` の [`tx`](/docs/node/reference/functions/tx) を使って文字列を同様に翻訳できます。

## General Translation はどのように翻訳を配信するのか？

General Translation は CLI で翻訳を生成し、アプリは次の 2 つのいずれかから翻訳を読み込みます。

* **ローカルファイル。** `gt.config.json` で出力パスを設定し、ビルド前に [`npx gt translate`](/docs/cli/reference/commands/translate) を実行したうえで、各ロケールをインポートする [`loadTranslations`](/docs/react/reference/functions/load-translations) 関数を用意します。バンドルされた翻訳をレンダリングする際に、General Translation へのリクエストは発生しません。[`gt init`](/docs/cli/reference/commands/init) ではこのセットアップ (**Save locally**) が推奨されており、`gt-vue` ではこれが唯一の選択肢です。
* **General Translation の CDN** (React および Next.js SDK) 。プロジェクト設定で CDN を有効にし、[`npx gt translate --publish`](/docs/cli/reference/commands/translate) を実行したうえで、ローカルのローダーを使わずに SDK に [`projectId`](/docs/react/reference/config#project-id) を渡します。ローカルのローダーが設定されていない場合、SDK はデフォルトで CDN から読み込みます。CLI は、ビルドが読み込む翻訳元のバージョンを記録します。そのバージョンに公開された編集内容は、キャッシュの更新後に新しいレンダリングへ反映されるため、アプリケーションコードを新たにデプロイする必要はありません。ただし、新しく追加したテキストはそれを含むデプロイとともにリリースされ、静的 HTML は前述の再ビルドまたは再検証のルールに従います。CDN による配信は[無料](https://generaltranslation.com/pricing/usage)です。

ローカルファイルと CDN は設定を変更するだけで切り替えられ、コンポーネントに手を加える必要はありません。各 React フレームワーク向けのローダーについては、[翻訳の保存ガイド](/docs/react/guides/storing-translations)を参照してください。

## 重要なポイント

* 事前にわかっているアプリの翻訳は、デプロイ前に生成しておきます。翻訳はリリースにバンドルするか、リリースの合間に行った文言の修正を新たなレンダリングへ反映させたい場合は CDN から読み込みます。
* 新しいコンテンツは、ユーザーが必要とするタイミングに合わせて、公開時、バックグラウンドジョブ、またはリクエスト時に翻訳します。翻訳 API のキーはサーバー側で保持してください。
* プロキシを使えばコードを変更せずに言語を追加できますが、レンダリング済みの HTML を翻訳する仕組みのため、翻訳されたページが表示されるたびにベンダーに依存することになります。
* General Translation では、同じ [`<T>`](/docs/react/reference/components/t) コンポーネントをローカルファイルまたは General Translation の CDN から配信でき、リクエスト時に生成されるコンテンツ向けには [`<Tx>`](/docs/react/nextjs/reference/components/tx) も用意されています。まずは [Next.js クイックスタート](/docs/react/nextjs-quickstart)から始めましょう。

## Related questions

- [ウェブサイトを多言語化するにはどうすればよいですか？](https://generaltranslation.com/ja/kb/make-website-multilingual.mdx): 翻訳をどこで管理するか（プロキシ、CMSプラグイン、サイトビルダー、または自前のコード）を選び、Googleの推奨どおり言語ごとに専用のURLを用意します。ページ全体に加えてタイトルとメタディスクリプションも翻訳し、hreflangで各言語版を関連付けます。また、訪問者を自動でリダイレクトするのではなく、言語切り替え機能を設置しましょう。
- [多言語対応の Next.js アプリで SEO を設定するには？](https://generaltranslation.com/ja/kb/multilingual-nextjs-seo.mdx): 各言語に /en/about や /es/about のようなプレフィックス付きの URL を割り当て、公開している言語ごとに html lang、自己参照のカノニカル、x-default を含む hreflang の代替リンク、翻訳済みのタイトルと説明文、サイトマップのエントリを出力します。未公開のバージョンには noindex を指定します。General Translation の gt-next は各言語を専用の URL にルーティングし、getGT でタイトルを翻訳します。
- [毎日リリースするチームに最適な継続的ローカライゼーションツールは？](https://generaltranslation.com/ja/kb/best-continuous-localization-tools.mdx): General Translation を選べば、マークされた JSX の文脈と共有のプロダクト用語を活用して、ビルドのたびに新しいコピーを翻訳できます。チームは ダッシュボード で文言をレビュー・修正でき、Locadex は新しい UI テキストを翻訳対象としてマークするプルリクエストを作成します。既存の i18next や next-intl のセットアップはそのままで、このワークフローを導入できます。
- [Weglot の代替: General Translation と Weglot の比較](https://generaltranslation.com/ja/kb/general-translation-vs-weglot.mdx): Weglot は、プラグイン、スニペット、またはプロキシを介してレンダリング済みのページを翻訳するウェブサイト翻訳サービスで、Weglot 2.0 では GitHub 上での JSON 翻訳ワークフローが追加されました。General Translation は、ソースコードの国際化、ファイル翻訳、共有の文脈、ダッシュボードでのレビュー、ロケールルーティングを組み合わせたローカライゼーションプラットフォームです。
- [言語リダイレクトと SEO：URL、クッキー、Accept-Language のどれを使うべきか](https://generaltranslation.com/ja/kb/locale-routing-seo.mdx): Googlebot は Accept-Language ヘッダーを送信せず、クロールの大半を米国の IP アドレスから行います。そのため、インデックスさせたいすべてのページの言語は URL で決めましょう。保存済みのクッキーの選択、次いで Accept-Language を使うのは、/ のような中立的なルートのリダイレクト先を決める場合だけにとどめ、その際は一時的な 302 または 307 を使います。

## Previous and next questions

- Previous question: [AIコーディングエージェントと翻訳パイプライン：ローカライゼーションの自動化にはどちらを使うべきか](https://generaltranslation.com/ja/kb/ai-coding-agent-vs-translation-pipeline.mdx)
- Next question: [毎日リリースするチームに最適な継続的ローカライゼーションツールは？](https://generaltranslation.com/ja/kb/best-continuous-localization-tools.mdx)

## Sitemap

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