Translation API によるウェブサイト翻訳のベスト プラクティス

※この投稿は米国時間 2021 年 9 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

ウェブサイトの翻訳なら、Google Cloud にお任せください。

Google Cloud Translation API は、Google の最新の機械学習モデルを使用して複数の言語間の翻訳を動的に行うサービスです。100 言語以上に対応した非常にスケーラブルな API であり、言語検出機能が組み込まれています。このブログ投稿では、ウェブサイトで Translation API を使用する際に、費用の最適化、パフォーマンスの向上、セキュリティ対策の強化を実現するためのベスト プラクティスをご紹介します。

パフォーマンス、費用、セキュリティを考慮したアーキテクチャの最適化

ウェブサイト翻訳の一般的な手法は、ウェブサイトにアクセスしたユーザーに言語を選択させ、その言語でウェブサイトを表示するというものです。しかし、オンデマンド翻訳の場合、この手法では同じコンテンツを何度も翻訳対象として再送する必要があるため、費用が高くなる可能性があります。

費用の削減、パフォーマンスの向上、セキュリティ対策の強化を実現するためのベスト プラクティスの一つとして、キャッシュ パターンの活用が挙げられます。翻訳済みのコンテンツをキャッシュに保存することで、Google Cloud Translation API の呼び出し回数が減少するだけでなく、バックエンドのウェブサーバーとデータベースでの負荷とコンピューティングの使用量も削減されます。これにより、アプリケーションのパフォーマンスが最適化され、配信の費用を削減できます。

キャッシュ保存を設定する方法は、アプリケーション アーキテクチャのさまざまなアプリケーション レイヤで多数あります。たとえば、次のような方法があります。

• グローバル配信にコンテンツ配信ネットワーク（CDN）を利用する: 翻訳済みのコンテンツをグローバルに分散したエッジ ロケーションに保存することで、コンテンツをユーザーの近くで提供し、ネットワークのレイテンシを短縮します。CDN を使用する場合、キャッシュ ヒット率（リクエストされたオブジェクトがキャッシュから提供される回数の割合）に注目し、コンテンツが適切にキャッシュに保存されていることを確認するとよいでしょう。また、Google Cloud CDN を使用する場合は、DDoS や bot の活動といった一般的なセキュリティ脅威に対して、デフォルトのセキュリティ保護も活用できます。さらに、Google Cloud Armor などのウェブ アプリケーション ファイアウォール（WAF）でセキュリティ レイヤを追加し、SQL インジェクション（SQLi）、クロスサイト スクリプティング（XSS）、リモートコード実行（RCE）などのアプリケーション レイヤ攻撃から保護することもできます。

• プロキシレイヤでのキャッシュ: すでに NGINX や HAProxy などのサーバーを利用している場合、プロキシ キャッシュがシンプルで効果的なオプションとなります。プロキシ キャッシュの利点は、バックエンドのアプリケーション コードのリファクタリングが最小限で済む、または不要であることです。翻訳済みのコンテンツをプロキシでキャッシュすることで、バックエンド サーバーの費用と負荷も削減できるため、ユーザーにとってのパフォーマンスが向上します。

• アプリケーション レベルでのキャッシュ: ウェブサーバー内にあるメモリのアプリケーション レイヤで、または Redis および Memcached 対応の Google Cloud Memorystore などのプロセス外メモリ キャッシュ サービスを介してキャッシュ保存を設定できます。このレイヤでは、CDN またはプロキシの場合と同様に、html マークアップなしの未処理の翻訳済みコンテンツを保存することをおすすめします。これは、一般に、アプリケーションがキャッシュに保存されたコンテンツを取得した後に html レンダリングが行われるためです。Wordpress や Drupal などのコンテンツ管理システム（CMS）を使用している場合は、提供されている翻訳プラグインまたはカスタム プラグインを使用して、キャッシュに保存されたコンテンツを Memorystore 内に保存し、取得できます。

最小権限の原則による安全なアクセス

Google Cloud Translation API にアクセスする場合は常に、API キーではなく Google Cloud サービス アカウントを使用することをおすすめします。サービス アカウントは、人間以外のユーザーを表す特別なタイプの認証アカウントで、このアカウントで認証を受け、Google Cloud Translation API などの Google API のデータにアクセスできます。サービス アカウントにはパスワードが割り当てられず、ブラウザベースのログインには使用できないため、この脅威ベクトルを最小限に抑えることができます。最小権限の原則に従い、Translation API にアクセスするために必要な最小限の権限とアクセス許可を持つロールを与えるとよいでしょう。詳細については、サービス アカウントの使用と管理、サービス アカウントの保護、サービス アカウント キーの管理のベスト プラクティスに関するドキュメントを参照してください。

翻訳のカスタマイズと透明性の確保

コンテンツに分野固有またはコンテキスト固有の用語や語句が含まれている場合は、Google Cloud Translation API Advanced の用語集を使用してカスタム用語に対応できます。また、Google AutoML Translation でカスタム翻訳モデルを構築し、利用することもできます。

公開前に翻訳のレビューと編集を行わない場合は、コンテンツが Google によって機械翻訳されていることをユーザーに通知し、帰属表示のガイドラインを提示することをおすすめします。このように透明性を確保することで、ユーザーはコンテンツが自動的に翻訳されていて、誤りが含まれている可能性があることを把握できます。

予算: 設定したら管理も忘れずに

Google Cloud Translation API の関連費用は主に、API に送信される文字数に基づいています。たとえば、100 万文字あたりの料金が $10 とすると、2,000 万文字のウェブページを 10 言語に翻訳する場合、料金は $10 x 20 = $200 となります。料金について詳しくはこちらをご覧ください。また、料金計算ツールで見積もりを作成することもできます。

開発に移行する際は、お使いの環境内で予算モニタリングおよびアラートを設定し、費用を管理して不測の事態を回避してください。これによって、予期せず費用が増加した場合、問題に予防的に対処できるようになります。テスト段階では、確実に予算内に収めることができるように、低めの予算を割り当てることをおすすめします。本番環境に移行したら、予算の制限に到達してサービスが中断されることがないよう、予算の割り当てを調整することを忘れないでください。

バックグラウンドも言語も多様な人々による共同作業の機会が増え続けるデジタル時代において、翻訳は不可欠です。本ブログで紹介したベスト プラクティスとガイドラインを、競争力の獲得と新しいオーディエンスへのリーチにお役立ていただければ幸いです。

-データ担当カスタマー エンジニア Tristan Li

-プリンシパル アーキテクト Wayne Davis