Webサイトの翻訳では、短いボタン、製品仕様、会社紹介などを同じ画面で扱います。原文の意味を保つことは共通ですが、使える文脈や表示までに待てる時間は異なります。翻訳処理を選ぶ仕組みと、結果を確認する仕組みを分けて設計します。
処理を選ぶ条件を明確にする
使い分けでは、対象言語、文章量、用語集の適用、HTMLを含むかどうか、表示までに待てる時間などを確認します。文章が短いというだけで、誤訳の影響が小さいとは判断できません。短いボタンでも、同意や削除など重要な操作を示す場合があります。
AIシュリーマンの翻訳処理には、文章の長さや辞書の適用、サイトの設定などに応じて処理経路を選ぶ仕組みがあります。表示時の翻訳と、後続の翻訳・校正を組み合わせる経路もあります。実際に通る処理は、機能や設定によって異なります。
特定のモデルがすべての文章や言語で最適であるという前提には立たず、品質と運用条件を確認します。モデル名だけで役割を決めたり、各文章を必ず複数モデルが合議すると説明したりしないようにします。
表示時に行う処理と、後から行う処理を分ける
ページを表示するたびに長い翻訳処理を待つと、利用者の操作を妨げる場合があります。保存済みの訳文を使う、事前に処理する、後続の処理で訳文を更新するなど、用途に合う流れを検討します。
後から更新する場合は、最初に何が表示され、いつ新しい訳文が反映されるかを確認します。処理に失敗したときの表示、再実行、確認担当への連絡も決めます。自動で処理が続くことと、すべての誤りを検出できることは別です。
企業ごとの表記は、適用範囲を指定して管理する
製品名やサービス名は、公式な外国語名があればその表記を使います。原表記を残すものと、翻訳するものを分けます。「製品名だから絶対に翻訳しない」と一律には決めません。
同じ単語でも意味が異なる場合は、対象ページや文脈を確認して訳し分けます。用語集、条件付きの設定、文章やHTML単位の修正などを使い分けます。文体は読み手と用途に合わせ、共通のガイドラインとして管理します。
参考資料を翻訳に渡す仕組みと、モデル自体を追加学習させることは異なります。また、画面で修正した内容がすべて自動的に保存・学習されるとは限りません。どの操作で保存され、どこへ反映されるかを確認してください。
訳文の自然さと、構造・意味の保持を確認する
結果の確認では、原文の欠落、名称、数値、日付、否定、条件、用語の扱いを確認します。HTMLを含む場合は、タグ、属性、変数、リンクなどが壊れていないかをチェックします。画面に反映した後は、文字切れの確認や実際の操作も試します。
自動検査で見つかった指摘は、原文と照らし合わせます。重要な条件や開示内容は、必要な担当部門へ確認を依頼します。校正が入ったことだけを理由に、公開可能と判断しないようにします。
データの保存と外部サービスへの送信を確認する
複数のサービスを使う場合は、どの内容をどこへ送り、何を保存するかを確認します。モデルの学習に使わないことと、処理や監査のための保存がないことは別です。契約、利用機能、設定を分けて確認します。