TL

Cloud Service

Cloud Translation

テキストを多言語間で自動翻訳する Google の機械翻訳 API。事前学習済みモデルで即利用でき、AWS Translate に相当する。

基礎運用上の優秀性
最終更新: 2026-06-14公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.テキストを多言語へ自動翻訳するマネージドな機械翻訳 API。学習不要で即利用できる。
  • 2.言語検出と翻訳を API 一発で実行。専門用語の対応は用語集や AutoML カスタムモデルで補強する。
  • 3.AWS の Amazon Translate 相当。翻訳した文字数に応じた従量課金で、自前のモデル運用は不要。

解決する課題

アプリやコンテンツを多言語へ展開するとき、翻訳モデルを自前で学習・運用するのは現実的ではありません。Cloud Translation は Google が事前に学習済みのニューラル機械翻訳モデルを API として提供し、テキストを送るだけで多言語間の翻訳結果を返します。

  • ユーザー投稿やチャット、商品説明などをリアルタイムに多言語へ翻訳したい
  • 入力テキストの言語が不明で、まず言語を自動判定してから処理を分けたい
  • 翻訳エンジンの学習データ収集・モデル運用・スケーリングから解放されたい
  • 業界固有の用語やブランド名を、訳し方を制御しながら一貫して翻訳したい
  • ドキュメント(PDF や Office 形式など)をレイアウトを保ったまま翻訳したい

主要概念と用語

  • NMT(ニューラル機械翻訳): Cloud Translation の翻訳エンジン。文単位ではなく文脈を考慮して訳すため、従来の統計的手法より自然な翻訳になりやすい
  • 言語コード: 翻訳元・翻訳先の言語を表す識別子(ISO 639 ベース)。ソース言語を省略すると言語の自動検出が行われる
  • 言語検出(Language Detection): 入力テキストがどの言語かを推定する機能。翻訳前の振り分けや、対応言語の判定に使う
  • Basic 版(v2): 事前学習済みモデルでテキストを翻訳する基本 API。最小構成で素早く組み込める
  • Advanced 版(v3): 用語集・バッチ翻訳・ドキュメント翻訳・カスタムモデルなど、企業用途向けの機能を備えた拡張 API
  • 用語集(Glossary): 特定の語句を指定した訳語に固定するための対訳辞書。ブランド名や専門用語の訳ブレを防ぐ(Advanced 版の機能)
  • AutoML Translation: 自前の対訳データで追加学習し、ドメインに特化したカスタム翻訳モデルを作る仕組み
  • バッチ翻訳(Batch Translation): Cloud Storage 上の大量テキストをまとめて非同期に翻訳する処理(Advanced 版の機能)
  • ドキュメント翻訳(Document Translation): PDF や Office 文書などを書式・レイアウトを保持したまま翻訳する機能

仕様・制限・クォータ

  • 入力はプレーンテキストまたは HTML。HTML を渡すとタグ構造を保ったまま中のテキストだけを翻訳できる。ソース言語は指定も自動検出も可能
  • 対応言語は多数にのぼり、組み合わせによって品質差がある。対応言語一覧は公式ドキュメントで随時更新されるため、最新の対応状況は公式で確認する
  • リクエストあたりの文字数や同時実行数に上限があり、プロジェクト単位のクォータ(QPS や文字数)が設定される。大量処理はバッチ翻訳や分割リクエストで設計する
  • Basic 版(v2)と Advanced 版(v3)で機能差がある。用語集・バッチ・ドキュメント翻訳・カスタムモデルは Advanced 版でのみ利用できる
  • 課金は**翻訳した文字数(言語検出のために送った文字数を含む)**が基本軸。具体的な単価・無料枠・上限値は変動するため断定せず、公式の料金とクォータを参照する

内部の仕組み

Cloud Translation は Google が運用する事前学習済みのニューラル機械翻訳モデルをマネージドな API として公開しています。利用者はモデルの学習やインフラのスケーリングを意識せず、テキストとソース・ターゲット言語を渡すだけで翻訳結果を受け取れます。

リクエストの流れは、まずソース言語が指定されていなければ言語検出で推定し、続いて該当する言語ペアの NMT モデルで翻訳を実行し、結果を返すという形です。Advanced 版では翻訳時に用語集を適用して特定語句の訳語を固定したり、AutoML のカスタムモデルを指定してドメイン特化の翻訳に切り替えたりできます。大量データはバッチ翻訳として非同期に処理し、入力・出力ともに Cloud Storage を経由します。

Basic 版と Advanced 版の使い分け

まず動かすだけなら Basic 版(v2) で十分です。ブランド名や専門用語の訳を固定したい、文書をレイアウトごと翻訳したい、大量テキストを一括処理したい、ドメイン特化モデルを使いたい、といった要件が出てきたら Advanced 版(v3) を選びます。後から要件が増える可能性があるなら、最初から Advanced 版で組んでおくと移行コストを抑えられます。

設計パターン / ベストプラクティス

  • ソース言語が分かっている場合は明示的に指定する。自動検出は便利だが、短文や混在テキストでは誤判定の余地があり、無駄な検出処理も省ける
  • ブランド名・製品名・専門用語は**用語集(Glossary)**で訳語を固定し、訳ブレを防ぐ。一般的な NMT で品質が出ないドメインは AutoML のカスタムモデルを検討する
  • Web ページやリッチテキストはプレーンテキストへ分解せず HTML のまま渡し、タグ構造を保持する
  • 同じ文を繰り返し翻訳するケースは結果をキャッシュし、重複した翻訳リクエストと課金文字数を削減する
  • 大量・定型のテキスト翻訳は同期 API を多数叩くのではなく、バッチ翻訳で Cloud Storage 経由の非同期処理にまとめる
  • 機械翻訳の品質は完璧ではない前提で、重要文面は**人手レビュー(ポストエディット)**の工程を挟む

運用・監視

  • Cloud Monitoring で API のリクエスト数・エラー率・レイテンシを監視し、急増やエラー増を検知する
  • Cloud Logging / Cloud Audit Logs で API 呼び出しの監査ログを確認し、誰がどの翻訳 API を使ったかを追える
  • クォータ(QPS・文字数)に達すると RESOURCE_EXHAUSTED 系のエラーになるため、指数バックオフによる再試行と必要に応じたクォータ引き上げ申請を用意する
  • 翻訳量が想定より多い場合は、キャッシュの効きや無駄な再翻訳、自動検出の過剰呼び出しを点検して課金文字数を抑える

コスト

課金は翻訳した文字数が基本軸で、言語検出のために送信した文字数も対象になります。Advanced 版の用語集・バッチ翻訳・ドキュメント翻訳や、AutoML のカスタムモデル利用には追加の考慮が必要です。一定の無料枠が用意される一方、単価や上限は変動するため、コスト試算は公式の料金ページで確認します。

課金軸考え方コスト最適化のヒント
翻訳文字数翻訳に送ったテキストの文字数に応じた従量課金繰り返し翻訳する文面はキャッシュして重複送信を減らす
言語検出検出のために送った文字数も課金対象ソース言語が分かるなら明示指定し、不要な検出を省く
カスタムモデルAutoML モデルの学習・利用に伴うコスト汎用 NMT で品質が足りるドメインには無理に使わない
バッチ・ドキュメントCloud Storage の入出力ストレージ等が付随一括処理にまとめ、不要な中間ファイルは削除する

セキュリティ

  • API 呼び出しはサービスアカウントと IAM で最小権限化する。アプリには翻訳に必要なロールのみを付与し、認証情報のハードコードを避ける
  • API キーを使う場合はキーの利用制限(API 制限・参照元制限)を設定し、漏えい時の影響を抑える。可能なら API キーよりサービスアカウント認証を優先する
  • 翻訳に送るテキストには個人情報や機密情報が含まれうるため、送信前のマスキングや最小化を検討し、必要に応じて VPC Service Controls で外部流出経路を制限する
  • バッチ・ドキュメント翻訳で利用する Cloud Storage バケットのアクセス制御を適切に設定し、入出力データが過剰に公開されないようにする
アンチパターン

API キーをクライアントアプリやリポジトリに直書きして配布するのは NG。漏えいすると第三者に翻訳 API を悪用され、課金が膨らみます。GCP 内のワークロードではサービスアカウント認証を使い、外部公開が避けられない場合でもキーには利用制限を必ず設定しましょう。

Well-Architected の観点

  • 運用の優秀性: 事前学習済みモデルを API として利用でき、モデルの学習・運用・スケーリングが不要。用語集やバッチ翻訳で定型運用を標準化し、Cloud Monitoring と Audit Logs で可観測性を確保できる
  • コスト最適化: 課金は翻訳文字数ベースで、キャッシュや言語の明示指定、バッチ集約により無駄な送信を削減できる
  • セキュリティ: IAM とサービスアカウント、API キー制限、VPC Service Controls により、認証情報と送信データの管理を統制できる

試験で問われるポイント

頻出
  • Cloud Translation は事前学習済みのニューラル機械翻訳 API で、AWS の Amazon Translate に相当する
  • ソース言語を省略すると言語の自動検出が働く。検出した文字数も課金対象になる点を押さえる
  • Basic 版(v2)と Advanced 版(v3)の機能差が問われる。用語集・バッチ翻訳・ドキュメント翻訳・カスタムモデルは Advanced 版でのみ利用できる
  • ブランド名や専門用語の訳を固定するには用語集(Glossary)、ドメイン特化の品質が必要なら AutoML Translation のカスタムモデルを使う
  • 課金は翻訳した文字数が基本軸。大量処理はバッチ翻訳で非同期に設計する
  • 「翻訳モデルを自前で学習せず多言語化したい」なら Cloud Translation、画像内テキストの抽出は Vision API、音声の文字起こしは Speech-to-Text、というように用途ごとの API の使い分けが問われる

関連サービス・比較

観点Google Cloud TranslationAmazon Translate
位置づけ事前学習済みの機械翻訳 API(マネージド)事前学習済みの機械翻訳 API(マネージド)
言語検出対応(ソース省略で自動検出)対応(Amazon Comprehend と連携も可)
用語の固定用語集(Glossary)カスタム用語(Custom Terminology)
カスタムモデルAutoML TranslationActive Custom Translation
大量処理バッチ翻訳(Cloud Storage 経由)非同期バッチ翻訳(S3 経由)
文書翻訳ドキュメント翻訳(書式保持)ドキュメント翻訳に対応
認証・権限サービスアカウント + IAMIAM ロール

関連して、画像内の文字を読み取るなら Vision API、音声を文字に起こすなら Speech-to-Text、文章の意味解析や感情分析なら Natural Language API と、目的に応じて Google Cloud の AI API を組み合わせます。

ハンズオン / CLI例

# 1) プロジェクトで Cloud Translation API を有効化
gcloud services enable translate.googleapis.com

# 2) アプリ用サービスアカウントを作成し、認証情報を取得
gcloud iam service-accounts create translate-app \
  --display-name "Translation App"

# 3) gcloud のアクセストークンを使い、REST API でテキストを翻訳(英語→日本語)
ACCESS_TOKEN=$(gcloud auth print-access-token)
PROJECT_ID=$(gcloud config get-value project)

curl -s -X POST \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  "https://translation.googleapis.com/v3/projects/${PROJECT_ID}:translateText" \
  -d '{
        "sourceLanguageCode": "en",
        "targetLanguageCode": "ja",
        "contents": ["Hello, world."]
      }'

# 4) ソース言語を省略すると自動検出される(英語と判定して日本語へ)
curl -s -X POST \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  "https://translation.googleapis.com/v3/projects/${PROJECT_ID}:translateText" \
  -d '{
        "targetLanguageCode": "ja",
        "contents": ["Good morning."]
      }'

Google Cloud Service

Cloud Translationを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

AI / 機械学習

比較で見る軸

クラウド: Google Cloud / カテゴリ: AI / 機械学習 / 難易度: basic

導入後に効く点

言語検出と翻訳を API 一発で実行。専門用語の対応は用語集や AutoML カスタムモデルで補強する。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Google Cloud
カテゴリ
AI / 機械学習
難易度
basic
関連資格
設計柱
operational

判断チェックリスト

  • 自社の用途が「AI / 機械学習 / operational」に近いか確認する。
  • 強みである「テキストを多言語へ自動翻訳するマネージドな機械翻訳 API。学習不要で即利用できる。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

AI / 機械学習operational