翻訳API：企業の多言語コンテンツを自動化する方法

ネットショップでは毎週何百もの商品が追加され、カスタマーサポートには10言語でメールが届き、アプリのボタンの文言は毎日更新されます。こうしたすべてをメールでファイル送信して翻訳者に依頼していては、翻訳がビジネス全体のボトルネックになってしまいます。リリースの準備はできているのに、ドイツ語のページはまだ順番待ち。そこで、言語関連の作業をメールからコードへ移す企業が増えています。

この記事では、翻訳APIの仕組みや対応できる業務、人の手が欠かせない場面について解説します。すべてを機械に任せるべきだとか、逆にすべて人に任せるべきだとか主張するつもりはありません。それぞれのテキストに最適な担当者が割り当てられるワークフローの構築方法を見ていきましょう。

翻訳APIとは？簡単に解説

APIとは、あるプログラムが別のプログラムにアクセスするためのルールをまとめたものです。自社のシステムからテキストと翻訳元・翻訳先の言語を送ると、翻訳結果が返ってきます。ユーザーがサイトを開いてドキュメントをアップロードし、メールが届くのを待つ必要はありません。ユーザーには、ページが自動的に別の言語に切り替わったように見えます。

同じインターフェースの背後には、さまざまな仕組みがあります。数秒で応答する機械翻訳エンジンの場合もあれば、依頼が人間の翻訳者に送られ、後から結果が返ってくるプラットフォームの場合もあります。Translate24は企業向けAPIを提供し、1,200人以上の認定翻訳者のネットワークを活用しています。そのため、「送信して受け取る」方式だからといって、必ずしも「機械が翻訳する」とは限りません。

開発者にとって、連携作業は通常、いくつかのリクエストに集約されます。注文の作成、テキストの送信、ステータスの確認、結果の取得です。プロダクトマネージャーにとってより重要なのは、翻訳が手作業で依頼する独立したタスクではなく、業務プロセスの一部になることです。商品データベースに新しい行が追加されると、自動的に一連の処理が始まります。翻訳の自動化でなくなるのは翻訳者ではなく、メールの送信や添付ファイル、コピー＆ペーストといった周辺作業です。

よくある活用例：商品カタログ、サポート、ユーザー投稿

最もわかりやすい活用例は商品カタログです。何千もの商品ページを持つショップでは、説明文や仕様が変わるたびに、すべてを手作業で翻訳することはできません。APIが変更された項目を取得し、必要な言語の翻訳を返します。これによりコストを抑えられ、新商品のローカライズにかかる期間も数週間から数日に短縮できます。

2つ目はカスタマーサポートです。顧客がポルトガル語で問い合わせると、担当者はロシア語で内容を確認し、顧客の言語で返信できます。ここでは文章の洗練度よりスピードが重要なので、迅速な機械翻訳が適しています。一方、定型返信やヘルプセンターの文章は、一度人の手で確認しておくのが望ましいでしょう。何千人もの人が読むことになるからです。

3つ目は、レビュー、コメント、広告、マーケットプレイスの商品説明といったユーザー投稿です。コンテンツ量は膨大ですが、個々のテキストの価値は高くありません。そのため、こうしたコンテンツは通常、自動翻訳され、「機械翻訳」と表示されます。ただし、レビューが法的な申し立てに発展した場合は、専門家に依頼するべきです。

機械翻訳、人による翻訳、それとも併用か

「どちらがよいか」という問いへの率直な答えは、間違いが起きた場合の損失によって変わります。投稿へのコメントに誤訳があっても、ほとんど影響はありません。一方、医療機器の取扱説明書、契約書、広告のキャッチコピーの誤訳は、大きな損失につながります。そのため、APIを導入する前に、テキストをリスクレベルごとに分類しておくとよいでしょう。

実用的な方法は、リスクを3段階に分けることです。リスクが低ければ機械翻訳だけで十分ですが、中程度なら編集者による校正も必要です。リスクが高い場合は、プロの翻訳者が一から翻訳し、さらに別の専門家が確認します。こうしたルールはコードに組み込めます。コンテンツの種類に応じて、依頼先を振り分けられます。

ローカライズについても触れておきましょう。単語を置き換えるだけではなく、日付や通貨、単位の形式、ユーモア、文化的な言及などを調整する必要があります。たとえば、「ワンクリックで購入」というボタンは、直訳すると不自然な表現になることがあります。機械翻訳で下訳を作り、最後はその言語のネイティブスピーカーが判断します。

自動化されたワークフローで品質と用語を保つ

自動化されたワークフローの大きな課題は、訳語にばらつきが出ることです。同じ単語が商品ページごとに3通りに訳されていると、購入者は混乱します。「カート」「バッグ」「袋」は同じものを指すことがあっても、別々のもののように見えてしまいます。これを防ぐには、用語やブランド名を統一した用語集が必要です。最初の苦情が寄せられてからではなく、導入前に作成しておきましょう。

2つ目の課題は、テキストに含まれる技術的な要素です。{name}のような変数、HTMLタグ、リンクは、文字列全体を翻訳すると壊れるおそれがあります。そのため、こうした要素はプレースホルダーで保護するか、テキストから切り離します。文字数にも注意が必要です。ドイツ語の文は英語よりかなり長くなることが多く、ボタンのレイアウトが崩れる場合があります。

品質は推測するのではなく、測定する必要があります。たとえば、週ごとのテキストから数パーセントをサンプルとして抽出し、編集者に確認を依頼します。よくある誤りを記録し、用語集やルールに反映しましょう。こうしてワークフローを段階的に改善し、プロの翻訳が本当に必要な場面で活用できます。

データのセキュリティ

APIを通じて送られるのは、抽象的な文字列ではなく、顧客の氏名、注文番号、契約条件などの実データです。そのため、サービス提供者を選ぶ前に、何を送信するのかを把握する必要があります。個人情報は翻訳前にマーカーへ置き換え、翻訳後に元に戻せることがよくあります。これは、すべての委託先を信頼するより安全です。

基本的な項目を確認しましょう。通信時の暗号化、APIキーによるアクセス制御、サービス提供者側でのテキストの保存期間などです。自社のコンテンツがモデルの学習に使われるかどうかも確認してください。人間の翻訳者に依頼する場合は、秘密保持契約を締結しているかを確認しましょう。APIキーを公開リポジトリに置いてはいけません。また、テスト環境と本番環境には別々のキーを用意してください。

法的要件は国によって異なります。たとえば、欧州のGDPRとロシアの個人データ保護法では、情報の保存や移転に関する規制が異なります。複数の市場で事業を展開する場合は、事前に弁護士と運用方法を確認してください。特に機密性の高い文書は、完全自動のワークフローに通さないほうがよいでしょう。

連携を始めるには

まず、どのようなテキストがあるのか、どれくらいの頻度で更新されるのか、それぞれの誤訳がどれほどの損失につながるのかを調査しましょう。新商品の説明文など、1つのワークフローを選び、2言語でパイロット運用を開始します。最初のリクエストを送る前に、用語集と振り分けルールを準備してください。1か月後に、従来の手作業と速度やコストを比較します。

その後は、すでに機能している仕組みを崩さないように、対応言語やコンテンツの種類を段階的に増やしていきます。翻訳の自動化は、繰り返し発生するタスクに適しています。一方、意味やトーン、責任が重視される場面では、人の力が必要です。導入について相談したい方は、企業向けAPIと、プロの翻訳が必要な業務に対応する認定翻訳者ネットワークを提供するTranslate24までお問い合わせください。