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