AI翻訳は 日常的な文章を驚くほど正確に処理できますが、だからといってすべての言語の構造的な文法規則に常に従うとは限りません。最も厄介なエラーの中には、不自然な言い回しやトーンに関するものではなく、目標言語が数、性、文脈、あるいは話者と読者の関係に基づいて特定の文法形式を要求する場合に発生するものがあります。
こうした例外的なケースは、 短いUI文字列や 動的なコンテンツによって翻訳エンジンがほとんど文脈情報を得られない多言語ウェブサイトで特に顕著になります 。ロシア語の複数形からフランス語の性別の一致や丁寧な代名詞に至るまで、これらのルールによって、本来は正確な翻訳が突然機械翻訳のように見えてしまうことがあります。こうした失敗がどこで発生し、どのように制御できるのか、続きをお読みください。
AI翻訳における複数形化エラー
英語では、名詞の数が1から複数に変わる際に「s」を付けるだけで済むため、複数形の付け方は一見簡単そうに見えます。しかし、多くの言語では、数自体によって名詞の形が決まる、より複雑なシステムが用いられています。これは、特にウェブサイトで動的な変数が使われている場合、AI翻訳にとって構造的な課題となります。.
言語によって複数形の規則がどのように異なるか
すべての言語が、単数形と複数形の単純な区別として複数形を扱うわけではありません。言語によっては、名詞の形が正確な数に応じて変化する場合もあれば、2つの項目を表す専用の形を持つ言語もあります。.
例えば、同じ基本的なUIメッセージでも、文法的な論理は大きく異なる場合がある。
- 英語: 1アイテム / 2アイテム
- ロシア語: 名詞の形は数によって変化します。
- アラビア語： 単数形、双数形、複数形が求められる場合があります。
これは、動的なコンテンツを翻訳する際に重要になります。翻訳エンジンは、常に英語のパターンをそのまま使用して名詞を別の言語の同等の名詞に置き換えることができるとは限りません。正しい翻訳先言語の形式を決定するには、名詞の数と文法的な文脈を考慮する必要があります。.
例えば、多言語対応のECサイトの場合、カートメッセージには「商品」という単語の翻訳を1つだけ保存するべきではありません。カートに商品が1つ、2つ、または複数入っているかによって、システムが異なる形式を必要とする場合があります。.
ロシア語の複数形と数に基づく規則
ロシア語は、数に基づく文法が自動翻訳を困難にする理由を示す良い例です。名詞は、後に続く数によって異なる形をとることがあります。「製品」という単語を使った簡略化された例は次のとおりです。
- 1 個
- 2 個
- 5 товаров
重要な点は、名詞自体が数の変化に応じて変化するということである。これは英語とは異なり、英語では通常、1つの製品と2つの製品の区別が基本となる。.
商品の数を動的に表示するECサイトのカートを想像してみてください。翻訳システムは、{count}が1なのか、特定の数値範囲内にあるのか、あるいは別の文法形式が必要なのかを知る必要があります。同様の問題は検索結果にも発生する可能性があります。
- 1件の商品が見つかりました
- 2つの商品が見つかりました
- 5つの商品が見つかりました
翻訳が対象言語の数の規則を適用せずに生成される場合、ユーザーに表示される数字は正しくても、名詞は誤った形のままになる可能性がある。.
アラビア語の複数形と双数形
アラビア語は単数、双数、複数を区別するため、さらに複雑な構造になっています。英語では一般的に1つの項目と複数項目を区別しますが、アラビア語ではちょうど2つの項目を表す特定の文法形式を用いることができます。したがって、項目数を表示するUIの場合、ロジックは次のようになります。
- 1項目 > 単数
- 2アイテム > デュアル
- 3つ以上のアイテム > 複数形
この区別は、動的なウェブサイトコンテンツにとって重要になります。「You have {count} items」のような文字列には、翻訳の文法形式に直接影響を与える可能性のある変数が含まれています。.
翻訳エンジンが{count}を翻訳文に挿入された単なる数字として扱う場合、数字と名詞の文法的な関係を見落とす可能性があります。結果として意味は通じるかもしれませんが、構造的に誤りがあるかもしれません。.
動的UI文字列における複数形化エラー
動的なUI文字列は、翻訳後に挿入される値によって最終的な意味が左右されるため、特に脆弱です。一般的な例としては、カート数、検索結果、通知、コメント、ダウンロード数、ダッシュボード統計などが挙げられます。簡単な英語のメッセージを例に考えてみましょう。
- アイテムが1つあります
- アイテムが2つあります
- アイテムが5つあります
英語では、文法的な変化は比較的単純です。しかし、複数の複数形カテゴリーを持つ言語では、それぞれの値に応じて異なる形式が必要になる場合があります。.
したがって、問題は必ずしも翻訳の質の低さにあるわけではありません。翻訳文自体は完全に理解できるものであっても、変数が変化すると意味が通じなくなる可能性があります。多言語ウェブサイトでは、動的な値と翻訳されたテキストとの間の文法的な関係性を維持する必要があります。.
そのため、目に見える単語だけを翻訳するだけでは十分ではない場合が多いのです。動的なコンテンツには、変数が対象言語の文法とどのように相互作用するかを理解する翻訳ロジックが必要です。.
AI翻訳における文法的な性別の誤り
文法上の性によって、構造上の新たな課題が生じる。名詞を男性名詞、女性名詞、あるいはその他の文法カテゴリーに分類する言語では、一つの名詞の性が周囲の複数の単語に影響を与えることがある。.
文法上の性別が翻訳に与える影響
文法上の性別は、単に名詞を男性名詞か女性名詞かに分類するだけではありません。性別は文法上の一致に影響を与える可能性があり、関連する冠詞、形容詞、代名詞、その他の単語も変更する必要が生じる場合があります。簡略化した関係は次のようになります。
noun → article → adjective
翻訳エンジンが名詞の性別を誤って選択した場合、その誤りはフレーズ全体に広がる可能性があります。誤った単語が1つあるだけでなく、表現全体に矛盾した文法形式が含まれることになるかもしれません。.
これは、原文のフレーズが翻訳先の言語に必要な情報を明示的に提供していない場合、特に困難になります。そのため、短い英語のフレーズは、文法的な性別を持つ言語に正しく翻訳するために、追加の文脈情報が必要になる場合があります。.
フランス語とスペイン語のジェンダー協定
フランス語とスペイン語は、名詞の性別が周囲の単語にどのように影響するかを明確に示す例である。名詞は一般的に文法上の性別を持ち、関連する冠詞や形容詞はその性別に一致する必要がある。.
ウェブサイトの場合、これは製品説明、カテゴリ名、プロフィールラベル、サービス説明などで使用されるフレーズに影響を与える可能性があります。名詞の性別を間違えた翻訳は、結果としてフレーズの残りの部分で不正確な一致を生み出す可能性があります。たとえば、翻訳ワークフローでは、次の点を判断する必要があるかもしれません。
- どのような名詞が説明されているのでしょうか？
- その文法上の性は何ですか？
- どの記事を添えるべきでしょうか？
- 形容詞には対応する形が必要ですか？
そのため、単語を一つずつ見ていくと正しく見える翻訳でも、単語を組み合わせると文法的に誤りとなる場合があるのです。.
UI文字列における性別エラー
短いUI文字列は、文脈情報がほとんど含まれていないことが多いため、特に翻訳が難しい。翻訳システムは、「新規アカウント」「プロフィールの更新」「利用可能なサービス」といったフレーズを受け取っても、その名詞がページ上の他の場所でどのように使われているかを正確に把握できない場合がある。.
これは、ラベル、通知、CTA、製品名、再利用可能なインターフェースコンポーネントなどでよく見られます。翻訳キーには数語しか含まれていない場合があり、文法的な一致を判断するために必要な情報はアプリケーション内の別の場所に存在します。たとえば、開発者は次のような汎用文字列を再利用するかもしれません。
New {item}
正しい翻訳は、{item}が何を表しているかによって異なる場合があります。変数が異なる文法上の性別を持つ名詞を指す場合、単一の静的な翻訳ではすべての文脈で正しく機能しない可能性があります。.
したがって、問題は単にAIが「単語を誤って翻訳した」ということだけではない。AIは、対象言語がどの文法形式を必要としているかを判断するのに十分な情報を受け取っていなかった可能性がある。.
文法上の性別の誤りを訂正する
性別に関する誤りを修正するには、翻訳システムに用語と文脈に関する十分な制御権限を与えることから始まります。自動出力に完全に依存するのではなく、チームは重要な用語をどのように翻訳し、レビューするかを定義できます。有効なアプローチには次のようなものがあります。
- 性別に配慮した用語を用語集に定義し、重要な名詞が常に意図した形で使用されるようにしてください。.
- 繰り返し出現するパターンや特定の用語には、カスタム翻訳ルールを使用してください。.
- ソーステキストから性別が明らかにならない曖昧なUI文字列に対して、追加のコンテキスト情報を提供する。.
- 文法的な一致が重要なページや文字列については、人間の手による後編集を適用してください。.
この組み合わせは、再利用可能なUIコンテンツが大量にあるウェブサイトで特に役立ちます。なぜなら、同じ問題を複数の箇所で手動で修正するのはすぐに非効率になるからです。.
性別と人称に基づく名詞形
言語学における例外的なケースの中には、単純な男性名詞／女性名詞の区別を超えたものがある。特定の言語では、文法形式は名詞が指す対象（人、物、その他のカテゴリーなど）によっても変化する。こうしたケースは、自動翻訳において文脈の重要性をさらに高める。.
文脈によって変化する名詞の形
単語は、文中における意味や指示対象によって、異なる文法形式を必要とする場合があります。同じ翻訳キーがウェブサイトの異なる部分で再利用されている場合、これは問題となる可能性があります。次のような一般的なウェブサイトコンテンツを考えてみましょう。
- ユーザーとアカウントの役割
- 製品カテゴリー
- 顧客タイプ
- 人や物を指すことができるラベル
短いラベルは、元の言語では無害に見えるかもしれませんが、ターゲット言語では追加情報が必要になる場合があります。たとえば、ダッシュボードでは、「顧客」という一般的なラベルをある場所で使用し、別の場所では人間以外のエンティティに対して同様の構造を再利用することができます。.
文脈が欠落している場合、翻訳エンジンは文法的には正しい形式を選択するものの、意図した意味とはかけ離れたものになる可能性があります。そのため、短い孤立した文字列は、多言語インターフェースにおいて最も脆弱な部分の一つと言えます。.
ポーランド語の人称に基づく名詞形
ポーランド語は、文法形式が、参照対象が人間か非人間的存在かによって異なることを示しています。つまり、単語やフレーズを翻訳するには、原文に含まれる情報以上の情報が必要になる場合があるということです。.
ユーザー数、顧客数、製品数を表示するダッシュボードを考えてみましょう。インターフェースでは、{count} 人のユーザー数や {count} 製品の数といった再利用可能な構造を使用できます。.
適切な文法処理は、数えられる対象と関連する文法カテゴリーによって異なります。したがって、翻訳エンジンは、すべての名詞を互換性のあるラベルとして扱うのではなく、コンテンツが人または物を表しているかを理解する必要があります。.
開発者やウェブサイトの所有者にとって、これは単独の文字列翻訳における重要な限界を浮き彫りにしています。翻訳エンジンは、文字列が何を表しているかを識別するために十分なコンテキストを必要とします。.
AIが文脈文法規則を見落とす理由
AI翻訳は、翻訳先の言語が原文に含まれていない情報を必要とする場合、文脈に応じた文法処理に苦労することがあります。例えば、英語は、他の言語では明示的に必要とされる文法情報を暗黙のうちに含んでいることがよくあります。一般的な原因としては、以下のようなものがあります。
- 周囲の文脈がほとんどない、非常に短い文字列。.
- 何を表しているかを明示していない変数。.
- ウェブサイトの様々な箇所で翻訳キーが再利用されている。.
- 目標言語に必要な情報をエンコードしていないソース言語の構造。.
次のような文字列を例にとります。
{{count}} users
翻訳エンジンは、{{count}}が何を表しているか、そして次の名詞にどの文法規則が適用されるかを理解する必要があり、同様に次のような文字列も理解する必要があります。
{{name}} is available
文法的な一致がその情報に依存する言語では、{{name}}が何を指すかについての情報が必要になる場合があります。.
文字列が提供する文脈が少ないほど、自動システムが文法的な推測を行う必要が生じる可能性が高くなる。.
性別と名詞形の誤りを修正する
最も確実な方法は、文法的な文脈が重要な文字列について、翻訳ワークフローにより多くの制御権限を与えることです。自動翻訳は初期の作業負荷を処理できますが、追加の制御によって、繰り返し発生するケースや曖昧なケースに対処できます。実用的なワークフローでは、以下を組み合わせることができます。
- 意味が使用状況によって変化する文字列の、文脈を考慮した翻訳。.
- 特定の文法要件を持つ用語の用語集。.
- 繰り返し出現するパターンに対するカスタム翻訳ルール。.
- 曖昧な文字列や影響力の大きい文字列については、人間によるレビューを行う。.
- 翻訳メモリは 、修正済みの翻訳を保存し、将来的に使用できるようにするものです。
このアプローチでは、翻訳を個々の文として扱うことを避け、ウェブサイト全体で重要な文法上の判断の一貫性を保ちます。.
フォーマルな言葉遣いとインフォーマルな言葉遣いのルール
フォーマルな言葉遣いとインフォーマルな言葉遣いは、翻訳の構造的な問題を引き起こす可能性もあります。言語によっては、レジスター（文体）によって代名詞、動詞の形、文の構造が変わるため、間違ったレジスターを選択すると、翻訳されたメッセージの文法が変わってしまうことがあります。.
丁寧な代名詞とくだけた代名詞
言語によっては、読者への呼びかけ方をフォーマルとインフォーマルで区別しているものがあります。適切な形式は、相手、関係性、状況によって異なります。英語のUIメッセージ「お名前を入力してください」を例に考えてみましょう。.
英語では、「you」が丁寧語かくだけた表現かを翻訳時に明記する必要はありません。しかし、翻訳先の言語によっては、その区別が必要となる場合があります。適切な選択肢は、ウェブサイトによって異なります。
- Eコマースの決済画面： 丁寧な表現やフォーマルな表現が使用される場合があります。
- カスタマーサポート： 丁寧な言葉遣いを好む場合があります。
- 銀行や口座のページ： 常に丁寧な言葉遣いが用いられる場合がある。
- SaaSのオンボーディング： ブランドに応じて、フォーマルな言葉遣いか、より会話的な言葉遣いのどちらかを選択できます。
重要なのは一貫性です。ウェブサイトが一度文体を確立したら、翻訳されたUI文字列は、ユーザー体験全体を通して同じ文法に従うべきです。.
レジスターが文の構造をどのように変えるか
レジスターは、相手に呼びかける際に使用する代名詞だけでなく、それ以上のものに影響を与える可能性があります。フォーマルとインフォーマルな文法形式を持つ言語では、レジスターの選択は動詞の活用や文の他の部分にも影響を与えることがあります。例えば、同じ種類のメッセージでも、異なる環境では次のような違いが生じる可能性があります。
- 正式な顧客通知では、丁寧な文法構造を用いるべきである。.
- 非公式な消費者向けアプリは、ユーザーに直接的に語りかける可能性がある。.
- 専門サービス提供のウェブサイトでは、一貫して正式な書式が用いられる場合がある。.
つまり、文体は単なる書き方の好みではなく、言語規則として扱うべきである。翻訳エンジンが明確な理由もなくフォーマルな文体とインフォーマルな文体を切り替えてしまうと、たとえ全ての文が技術的には理解可能であっても、ウェブサイト全体に一貫性が感じられない可能性がある。.
UIと顧客メッセージにエラーを登録する
ウェブサイトの多くの箇所で、特に異なる文字列が個別に翻訳されている場合に、一貫性のない表記が見られることがあります。よくある箇所は以下のとおりです。
- UIラベル
- エラーメッセージ
- 通知
- 取引メール
- カスタマーサポートメッセージ
顧客への呼びかけが常に丁寧な言葉遣いで行われている決済フローを想像してみてください。ところが、その後に突然、くだけた代名詞を使った通知が表示されるとします。どちらのメッセージにも明らかな翻訳ミスはないかもしれませんが、この変更によって多言語対応における一貫性が損なわれてしまいます。.
これは、ユーザーが同じウェブサイトの異なるセクション間を移動する際に特に顕著になります。翻訳システムは、文ごとに個別に判断するのではなく、関連する文字列全体で選択された文体を維持する必要があります。.
一貫した言語レジスターを維持する
最初のステップは、各ターゲット言語における推奨レジスターを確立し、ウェブサイト全体で一貫して使用することです。これにより、原文でレジスターの区別が明示されていない場合でも、翻訳者や翻訳システムは明確な参照基準を得ることができます。ウェブサイトはこの一貫性を以下の方法でサポートできます。
- 推奨される文体を定義する翻訳ガイドライン。.
- 重要な代名詞と専門用語の用語集。.
- 繰り返し出現する言語パターンに対応したカスタム翻訳ルール。.
- チェックアウトや取引に関するメッセージなど、影響力の大きいコンテンツに対する人間のレビュー。.
これらの制御が確立されることで、形式的および非形式的な選択が翻訳ワークフローの一部となり、文字列ごとにランダムに決定されることがなくなります。.
構造的なAI翻訳エラーを修正する
カスタム翻訳ルールを使用する
カスタム翻訳ルールを使用すると、自動翻訳で必要な文法的結果が得られない場合に、特定の用語、パターン、または文字列の処理方法をより詳細に制御できます。たとえば、ルールは次のような管理に役立ちます。
- 動的な複数形化パターン
- 専門用語
- 一貫した文法形式
- 繰り返し表示されるUI文字列
同じ翻訳が表示されるたびに手動で修正する代わりに、好みの動作を一貫して適用するルールを定義できます。これは、動的コンポーネントや再利用可能なコンポーネントを含むウェブサイトで特に役立ちます。Linguise Linguise カスタム翻訳ルールもサポートしており、他のコンテンツは自動的に処理しながら、特定の翻訳を細かく調整できます。
用語集付きの管理用語
用語集は、翻訳全体を通して一貫性を保つべき用語を管理するのに役立ちます。特に、ある用語に複数の翻訳の可能性がある場合や、その文法的な特徴が重要な場合に有効です。例えば、用語集では次のような用語の推奨翻訳を定義できます。
- 製品名
- ブランド用語
- 役名
- 特定の文法上の性別を持つ用語
これにより、翻訳エンジンは明確な参照情報を得ることができ、あらゆる箇所が新たな解釈に委ねられることがなくなります。多言語ウェブサイトの場合、これは用語のばらつきを減らし、文法的な選択の一貫性を維持するのに役立ちます。.
人間によるポストエディットを適用する
構造上の特殊なケースの中には、特にソース文字列から必要な文脈を確実に推測できない場合、人間の言語判断が必要となるものがあります。影響力の大きいコンテンツについては、以下のような場合に人間のポストエディットを優先的に行うことができます。
- チェックアウトの流れ
- 法的メッセージおよびアカウントメッセージ
- 重要なお知らせ
- トラフィックの多いランディングページ
目的はウェブサイト全体を手動で翻訳することではありません。むしろ、文法的な正確さがユーザーエクスペリエンスに直接影響を与える例外的な箇所やデリケートな文字列に、人間のレビューを集中させることができます。.
翻訳メモリで修正内容を保持する
翻訳がレビューされ修正された場合、次回同様の文字列が翻訳された際に修正内容が消えてしまうべきではありません。 翻訳メモリは、 承認済みの翻訳を保存し、一致するコンテンツや類似のコンテンツに再利用できるようにするのに役立ちます。簡略化されたワークフローは次のようになります。
AI翻訳 → 人間による修正 → 翻訳結果の保存 → 一致するコンテンツへの再利用。.
これは、UI文字列が繰り返し使用されているウェブサイト、専門用語が繰り返し使われているウェブサイト、または類似コンテンツが大量に存在するウェブサイトに特に有効です。構造上の問題を一度修正すれば、毎回同じ判断を適用できるため、毎回新しい自動翻訳から始める必要がありません。.
結論
構造的なAI翻訳エラーは、一見正確に見える翻訳でも発生する可能性があります。複数形、文法上の性、人称に基づく名詞の形、フォーマルまたはインフォーマルな文体などは、元の英語文字列からは明らかではない規則を導入する可能性があるからです。.
対象言語が複雑になればなるほど、自動翻訳の適用方法を制御することが重要になります。Linguise Linguise 、自動翻訳と、カスタム翻訳ルール、用語集管理、人間によるポストエディット、翻訳メモリなどの制御機能を組み合わせることで、ウェブサイト運営者が自動翻訳の効率性を損なうことなく、こうした言語的な特殊ケースに対応できる方法を提供します。Linguise ご利用いただくこと Linguise 、多言語ウェブサイトの正確性と一貫性を言語間で維持できます。
