# General Translation Knowledge Base: General Translation と Mobility：どちらを使うべきか？
URL: https://generaltranslation.com/ja/kb/general-translation-vs-mobility.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Mobility は翻訳済みのモデル属性をデータベースに保存します。General Translation は、用語集とカスタムプロンプトを活用し、API を通じてそれらの翻訳を生成します。両者を組み合わせれば、Rails モデルをそのまま維持しながら、商品リストや投稿などのデータベースコンテンツを翻訳できます。
Category: 国際化
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16

Mobility は、データベース内のデータを翻訳するための Ruby gem です。モデルで `translates :title` を宣言すると、`post.title` は任意のストレージバックエンドから読み込んだ、現在のロケールのタイトルを返します。Mobility が担うのは翻訳の保存と取得で、翻訳文の作成は編集者や翻訳者、あるいは外部サービスに任されます。General Translation は、その翻訳を HTTP API 経由で提供します。翻訳済みの属性は Mobility によって既存のデータベースに保持されるため、現在のクエリやモデルメソッドをそのまま使えます。

## Mobility の強み

* **ストレージを選択できる。** デフォルトの `key_value` バックエンドは、[すべての翻訳を 2 つの共有テーブルに保存します](https://github.com/shioyama/mobility/wiki/KeyValue-Backend) (文字列用とテキスト用に 1 つずつ) 。`table` バックエンドはモデルごとに翻訳テーブルを使用し (Globalize と同じ方式) 、`column` は `title_en` や `title_es` のようなサフィックス付きのカラムを使用します。`serialized` は 1 つのテキストカラムにまとめて保存し、PostgreSQL では `json`、`jsonb`、`hstore`、`container` (モデルごとに 1 つの jsonb カラム) でネイティブに保存できます。独自のバックエンドを作成することも可能です。
* **どのバックエンドでも共通の API。** 読み書きは `I18n.locale` に従います。プラグイン (フォールバック、`post.title_es` のようなロケールアクセサ、ダーティトラッキング、キャッシュ、存在チェック) も[どのバックエンドを選んでも同じように動作します](https://github.com/shioyama/mobility#backends)。
* **クエリ。** [`Post.i18n.where(title: "...")`](https://github.com/shioyama/mobility#querying) は現在のロケールに応じた結合を自動で構築するため、保存方法を意識せずに翻訳済みの属性を検索できます。
* **ORM のサポート。** [Active Record 7.0 以降および Sequel で動作し](https://github.com/shioyama/mobility#installation)、Wiki には Globalize からの移行ガイドも用意されています。
* **無料。** MIT ライセンスで提供されており、[現在のリリースは 1.3.2 です](https://rubygems.org/gems/mobility)。

## Mobility が対応しない部分

以下は、英語のタイトルと本文を持つ投稿の例です。SQLite 上で `key_value` バックエンドを使用し、タイトルについてのみスペイン語から英語へのフォールバックを設定しています。

```ruby title="app/models/post.rb"
class Post < ApplicationRecord
  extend Mobility
  translates :title, type: :string, fallbacks: { es: :en }
  translates :body,  type: :text
end
```

```ruby
post = Post.create!(title: "Spring sale", body: "Everything is 20% off this week.")

I18n.with_locale(:es) { post.title } # => "Spring sale"（フォールバックによる英語の値）
I18n.with_locale(:es) { post.body }  # => nil
I18n.with_locale(:ja) { post.title } # => nil
```

これはストレージ層としては正しい動作です。Mobility が保存したのは英語の値だけで、ほかのロケールは誰かが書き込むまで空のままです。フォールバックを設定していればスペイン語の読者には英語が表示され、設定していなければ何も表示されません。商品一覧、記事、ヘルプページなど日々更新されるコンテンツでは、新規作成・編集されたレコードを誰かが言語ごとに翻訳し、適切なロケールで保存しなければなりません。

## General Translation で Mobility の属性を埋める

General Translation の実行時翻訳エンドポイント `POST https://api.gtx.dev/v2/translate` は、文字列をオンデマンドで翻訳します。認証には、**Runtime translation** 権限を持つプロジェクトの APIキーを Bearer トークンとして渡します。ボディには、独自の ID をキーとする `requests` オブジェクト(各エントリには `source` 文字列と、`context` メモなどの任意の `metadata` を含めます)に加えて、`sourceLocale`、`targetLocale`、トップレベルの `metadata` オブジェクト(空でも可)を指定します。レスポンスも同じ ID をキーとして返されます。これは短い Ruby メソッドで実装できます。

```ruby title="app/services/gt_translate.rb"
require "net/http"
require "json"

# { field => text } 形式のハッシュを General Translation のランタイム API で翻訳します。
# リクエストしたすべての翻訳を返します。失敗時は、データベースへの書き込み前に例外を送出します。
def gt_translate(fields, from:, to:, context: nil)
  uri = URI("https://api.gtx.dev/v2/translate")
  requests = fields.to_h do |field, text|
    [field.to_s, { source: text, metadata: { dataFormat: "STRING", context: context }.compact }]
  end

  request = Net::HTTP::Post.new(uri)
  request["Authorization"] = "Bearer #{ENV.fetch("GT_API_KEY")}" # 「Runtime translation」権限を持つプロジェクトキー
  request["Content-Type"] = "application/json"
  request["gt-api-version"] = "2026-03-06.v1"
  request.body = { requests:, sourceLocale: from.to_s, targetLocale: to.to_s, metadata: {} }.to_json

  response = Net::HTTP.start(uri.host, uri.port, use_ssl: true,
                            open_timeout: 5, read_timeout: 30) { |http| http.request(request) }
  raise "Translation request failed (#{response.code})" unless response.is_a?(Net::HTTPSuccess)

  results = JSON.parse(response.body)
  requests.keys.to_h do |field|
    result = results.fetch(field)
    unless result["success"] == true && result["translation"].is_a?(String)
      raise "Translation incomplete for #{field}"
    end
    [field, result.fetch("translation")]
  end
end
```

上記の投稿を一度だけ翻訳する場合は、英語の属性を読み取り、スペイン語の翻訳結果を完全な形で保存します：

```ruby
source = Mobility.with_locale(:en) do
  { title: post.title(fallback: false), body: post.body(fallback: false) }
end
translated = gt_translate(source,
                          from: :en, to: :es, context: "Blog post for an online shoe store")
Mobility.with_locale(:es) { post.update!(translated) }
```

このヘルパーは、投稿を更新する前に、リクエストしたすべてのフィールドに翻訳があることを確認します。モデルの通常のバリデーションも引き続き適用されます。(リクエストとレスポンスのフィールドについては、[エンドポイントのリファレンス](/docs/platform/openapi/reference/translation/translate-content)を参照してください。)

General Translation が行うのは、単なる機械翻訳の呼び出しにとどまりません。このエンドポイントはプロジェクトの[用語集とカスタムプロンプト](/docs/platform/dashboard/guides/defining-context-for-translations)に沿って翻訳するため、製品名やトーンがプロダクト全体と揃います。文脈のメモでは、テキストが靴店向けであることを伝えています。さらに用語を共通化することで、商品説明をアプリやマーケティングサイトと統一できます。APIキーはサーバー側で管理してください。継続的に自動化する場合は、翻訳を既存のコンテンツ公開ワークフローに組み込み、API の[レート制限](/docs/platform/openapi/overview#api-basics)を守ってください。

この例では、結果をモデルに直接保存しています。公開前に編集者の承認が必要なコンテンツの場合は、翻訳元の記事と同じ下書き・公開プロセスを経て結果を保存してください。

## Mobility と General Translation の比較早見表

| 機能               | Mobility                    | General Translation                                              |
| ---------------- | --------------------------- | ---------------------------------------------------------------- |
| 概要               | 翻訳済みのモデル属性を保存するための Ruby gem | HTTP API、CLI、JavaScript および Python 向けライブラリ、ダッシュボードを備えた翻訳プラットフォーム |
| データベースへの翻訳の保存    | 対応 (8 種類のストレージバックエンド)       | 同じモデル属性に翻訳を提供                                                    |
| 翻訳の生成            | 非対応                         | 対応 (`POST /v2/translate` を使用)                                    |
| Ruby とのインテグレーション | モデル属性とロケールアクセサ              | Ruby から HTTP API を呼び出し                                           |
| 用語とトーンの一貫性       | 翻訳者に依存                      | すべてのリクエストに用語集とカスタムプロンプトを適用                                       |
| 料金               | 無料 (MIT ライセンス)              | [従量課金制](https://generaltranslation.com/pricing)                  |

## Mobility だけで十分なケース

翻訳をすでに人が担当している場合は、Mobility 単体で問題ありません。たとえば、編集者が管理画面のフォームで各言語を入力している場合、翻訳会社に依頼している場合、あるいは法務文書のように人手での翻訳が欠かせないコンテンツを扱う場合です。対応言語が 2〜3 言語程度で、レコードの更新があまりない場合も Mobility だけで十分です。一方、ユーザーの出品情報、サポート記事、数千点の商品を扱うカタログなど、人手による翻訳が追いつかないペースでコンテンツが増えていき、新しいレコードを保存した時点ですべての言語で利用できるようにしたい場合は、General Translation を導入しましょう。

## 重要なポイント

* Mobility は、8 種類のバックエンドで翻訳済みのモデル属性を保存・取得でき、フォールバックやクエリにも対応しています。ただし、翻訳そのものは生成しません。
* Rails アプリから General Translation の `POST /v2/translate` エンドポイントを呼び出し、翻訳された属性を Mobility 経由で保存します。
* General Translation は、用語集、カスタムプロンプト、コンテンツ固有の文脈を適用して翻訳します。既存のモデルや公開ワークフローはそのまま使い続けられます。

## Related questions

- [General Translation と Rails I18n：両方必要か？](https://generaltranslation.com/ja/kb/general-translation-vs-rails-i18n.mdx): Rails I18n はメッセージの検索と、日付や数値の書式設定を担います。General Translation は翻訳を生成し、英語の変更に合わせて翻訳を常に最新の状態に保つほか、チームでレビューできるダッシュボードも提供します。両者を組み合わせれば、リリースのたびに翻訳済みの Rails カタログを出荷できます。
- [General Translation と i18n-tasks：どちらを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-i18n-tasks.mdx): i18n-tasks は、Rails I18n の不足キーや未使用キーを検出し、ロケールファイルを整理し、Google Translate、DeepL、OpenAI、Yandex、watsonx を使って不足キーを補完できる Ruby gem です。General Translation は、用語集、カスタムプロンプト、ダッシュボードでのレビューを活用してロケールファイル全体を翻訳します。両者は役割が異なるため、多くのチームにとっては併用も有効です。
- [Google 翻訳の代替：General Translation と Google 翻訳の比較](https://generaltranslation.com/ja/kb/general-translation-vs-google-translate.mdx): Google 翻訳は、単発のテキストをすばやく翻訳するのに便利ですが、製品を別の言語でリリースするには、各文字列を文脈に沿って翻訳し、用語を統一し、変数や複数形を正しく扱い、レビューを行い、リリースプロセスを整える必要があります。General Translation はコード内の各文字列の文脈を理解し、コードからレビュー、そして毎回のリリースまで、ローカライゼーションのワークフロー全体を自動化します。
- [General Translation vs. i18next、react-intl、next-intl：どのi18nライブラリを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-i18n-libraries.mdx): i18next、react-intl、next-intlなどのオープンソースライブラリ自体は、翻訳を一切行いません。これらが行うのは、あなた自身や翻訳者、あるいは別のサービスが作成し、言語ごとのカタログファイルに用意した翻訳を表示することだけです。General Translationのライブラリも同じくオープンソースで同じ役割を果たしますが、General Translationはさらに、コードを文脈として活用しながら翻訳そのものも行います。
- [TMS（Smartling、Lokalise、Phrase、Crowdin、Transifex）ではなく General Translation を使う理由](https://generaltranslation.com/ja/kb/general-translation-vs-tms.mdx): Smartling、Lokalise、Phrase、Crowdin、Transifex などの翻訳管理システム（TMS）は翻訳者間の作業を取りまとめますが、文字列の抽出、送信、翻訳待ち、プロダクトへの再組み込みは依然としてエンジニアの仕事です。General Translation はコード内のコンテンツを文脈ごと翻訳し、リリースのたびに全言語をまとめて提供します。ロックインのないオープンソースのライブラリ上で動作します。

## Previous and next questions

- Previous question: [General Translation と Locize：どちらを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-locize.mdx)
- Next question: [General Translation と nestjs-i18n：どちらを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-nestjs-i18n.mdx)

## Sitemap

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