Google Cloud Translation API は、130 以上の言語間の機械翻訳をプログラムから呼べるサービスだ。Web サービスの多言語化や、ドキュメント翻訳パイプラインに組み込む用途で広く使われている。

Basic と Advanced の使い分け

このサービスは 2 つのエディションで性格が分かれる。Basic はテキスト翻訳と言語自動検出を素直にこなす。Advanced はそれに加えてドキュメント（PDF / DOCX 等）の直接翻訳、カスタム用語集（Glossary）の適用、AutoML による独自モデル学習に対応する。

選定のポイントは用語の一貫性だ。製品名やブランド用語を訳語固定したいなら Glossary が使える Advanced が必要になる。ただし Advanced の単価は Basic の数倍で、用途が単純なテキスト翻訳だけなら Basic で十分なことが多い。「とりあえず Advanced」はコストの無駄になりやすい。

料金と精度の限界

料金は翻訳文字数ベースの従量課金で、月間 50 万文字までの無料枠がある。動的に翻訳する設計だと同じテキストを何度も翻訳しがちなので、翻訳結果のキャッシュを挟むとコストが安定する。さらに見落としやすいのが、HTML を翻訳する際にタグも文字数にカウントされる点だ。マークアップが多いコンテンツでは、見た目の本文量より請求文字数が膨らむ。

精度面では、機械翻訳である以上ニュアンスや専門用語を外すことがある。法律文書や医療文書のように誤訳が致命的になる領域では、人手のレビュー工程を必ず挟む前提で組むべきだ。UI テキストやヘルプ記事のような「多少崩れても通じる」コンテンツが本来の守備範囲だ。

DeepL との実質的な使い分け

翻訳品質、特に日本語と欧州言語の自然さでは DeepL を推す声も多い。一方 Google は対応言語数の広さと、GCP の他サービス（ストレージや AutoML）との連携で優位に立つ。「品質最優先で言語ペアが限定的」なら DeepL、「対応言語の網羅性とクラウド統合を取る」なら Google、という整理が現実的だ。

翻訳してはいけないものを守る仕組み

製品名、コード片、プレースホルダ、HTML タグ——翻訳されると壊れる要素は多い。素朴に文字列を丸ごと投げると、{username} のような変数が翻訳されたり、タグの構造が崩れたりする。HTML を扱うモードを使う、翻訳対象外を明示する属性で囲む、といった対処が必要になる。翻訳品質以前に、この保護をどう入れるかが実装の主要な作業になる。

💡
翻訳結果はキャッシュしてください

課金は文字数に比例するため、同じ文言を表示のたびに翻訳し直す実装はコストがそのまま積み上がります。原文のハッシュをキーにして翻訳結果を保存し、原文が変わったときだけ再翻訳する構成にすれば、費用も応答速度も改善します。多言語サイトでは必須の作り込みです。

機械翻訳を公開コンテンツに使うときの判断

生成した翻訳をそのまま Web に公開する場合、品質のばらつきがサイト全体の評価に影響しうる。内容が専門的なほど誤訳のリスクは上がる。実務では、重要なページは人手で確認し、量が多く重要度の低いページのみ機械翻訳に任せる、という切り分けが現実的だ。全ページを無検証で自動翻訳して公開する運用は、リスクに見合わないことが多い。