翻訳 API の選び方
機械翻訳は「訳質」と「対応言語数」がトレードオフになりやすい。少数の言語ペアで高い自然さを取るか、幅広い言語をカバーするかで候補が分かれる。日本語が絡む翻訳では、この差がとくに大きく出る。
判断の軸
- 日英中心で品質重視 — 訳文の自然さを実際の文章で比較する。直訳調にならないか
- 多言語を広くカバー — 対応言語数が要件なら、品質より網羅性を取る判断もある
- 文書まるごと翻訳 — レイアウトを保ったまま PDF や Office 文書を扱えるか
- 用語を統一したい — 用語集（Glossary）機能の有無が品質を左右する
翻訳してはいけないものを守る仕組みが要ります
製品名、コード片、{username} のようなプレースホルダ、HTML タグ——これらが翻訳されると表示が壊れます。素朴に文字列を丸ごと投げる実装は必ず事故ります。HTML を扱うモードを使う、翻訳対象外を明示する、といった保護をどう入れるかが実装の主要な作業になります。
コストは文字数に比例する
課金は翻訳した文字量にほぼ比例するため、同じ文言を表示のたびに翻訳し直す実装はコストがそのまま積み上がる。原文のハッシュをキーに翻訳結果を保存し、原文が変わったときだけ再翻訳する構成にすれば、費用も応答速度も改善する。多言語サイトでは必須の作り込みだ。
公開コンテンツに使うときの判断
生成した翻訳をそのまま Web に公開する場合、品質のばらつきがサイト全体の評価に影響しうる。内容が専門的なほど誤訳のリスクは上がる。重要なページは人手で確認し、量が多く重要度の低いページのみ機械翻訳に任せる、という切り分けが現実的だ。