AIでFAQを多言語化する方法｜翻訳後の用語と回答を揃える

AIでFAQを多言語化するときは、元FAQを一つの正本として保ち、翻訳文だけでなく質問の意味、回答範囲、用語、注意事項、更新日を言語間で揃えることが大切です。生成AIへ「全部翻訳して」と頼むだけでは、料金、条件、例外が別の言い方になったり、元回答にない保証が足されたりすることがあります。まずFAQをID単位に分け、翻訳前と翻訳後を同じ行で比較できる形にします。

この記事のゴールは、公開先の各言語でFAQの内容が揃い、原文に変更があったとき該当する質問だけを更新できる状態を作ることです。翻訳精度や問い合わせ削減率を実測した記事ではありません。実際の公開前には、その言語を読める担当者が確認してください。

翻訳する前にFAQの正本を決める

日本語で管理するのか、英語で管理するのかを決め、複数言語のうちどれが原文なのかを記録します。各言語のFAQを別々に直すと、一方だけ古い料金や条件を伝える状態になります。FAQごとにID、質問、回答、分類、公開日、最終更新日、オーナー、参照先を持たせ、翻訳版には原文IDを引き継ぎます。

正本の候補が複数ある場合、いきなり翻訳へ進まないでください。過去の更新が一部言語だけに入っていないかを担当者が比較し、採用する原文を決めます。どちらが最新か確認できなければ、そのFAQは翻訳保留にします。更新履歴を見ずに多数決で決めると、古い誤答を正式な原文にするおそれがあります。

FAQを翻訳しやすい単位へ分ける

元の長い文書を段落のまま渡すより、1つの質問と回答を1レコードに分ける方が差分を追いやすくなります。FAQ IDを維持し、question、answer、category、source link、statusを別欄にします。複数の質問が一つの回答に混ざる場合は、翻訳前にFAQの設計を見直し、分割しても答えの条件を落とさないか確認します。

表の例：

表は横にスクロールできます

FAQ ID	原文質問	原文回答	用語・固定表記	翻訳状態	確認者
F-021	解約後も使えますか	契約終了日まで利用できます	解約＝cancel、終了日＝end date	Draft	未割当

この例の回答は形式説明用です。実際のサービス条件を表すものではありません。公開する内容は必ず自社の契約・仕様と照合してください。

用語表で訳語と固定表記を決める

製品名、plan名、機能名、ボタン名、法務・返金に関わる語、単位や日付表記を用語表にします。項目は「原語」「採用訳」「訳さない語」「使用例」「適用言語」を持ちます。用語を訳すか残すか迷う場合は、公開済みUIや公式製品表記を確認し、担当者が決めた形を次のFAQにも使います。

用語表だけでは足りない場合は、やってはいけない変換も書きます。例：「Pro」はプラン名として原綴りを維持する、「税込」は通貨換算しない、「最短」は保証表現に言い換えない、URLとメールアドレスは原文どおりにする。AIへ渡す際は、用語表と禁止事項を同じ指示へ含め、出力に違反があれば該当IDを再確認します。

翻訳指示に変えてよいもの・変えてはいけないものを分ける

翻訳ルールには対象読者、敬体や文体、回答の長さ、翻訳しない語、原文にない情報を追加しないこと、不明箇所の表示方法を含めます。回答を短くする場合も、条件・例外・期限・問い合わせ先を削らないように指定します。自然な言い換えと事実の追加は別です。

指示例：

「FAQ IDごとに質問と回答を翻訳してください。事実、対象条件、数字、URLを変更しないでください。原文にない保証や説明を追加しないでください。不明な語は推測せず [要確認] としてください。用語表の訳語を固定してください。FAQ IDと回答範囲を保ち、変更した表現があれば理由を短く添えてください。」

これは作業用の型であり、全言語にそのまま適用できる品質保証ではありません。

翻訳とレビューを二つの工程にする

最初のAI出力は翻訳案として扱います。確認担当は、質問が同じ利用者の疑問に答えるか、回答に条件が欠けていないか、元にない断定が加わっていないかを見ます。法律、返金、安全、健康、個人情報、契約など影響が大きい回答は優先的に人が読み、必要に応じて法務や専門担当へ回します。

用語の統一だけを自動比較しても、意味が一致したとは限りません。「場合があります」が「必ず」に変わる、対象外条件が抜ける、否定が反転するなどの差は、単語一致だけでは見逃すことがあります。高リスクFAQでは、原文と翻訳を並べ、対象・条件・例外・次の行動をそれぞれ確認します。

数字・URL・条件は原文と照合する

価格、期間、バージョン、対象プラン、日時、メールアドレス、URLは、翻訳文の自然さと別に照合します。数字が一致しても通貨、税、月払いと年払いが変われば意味が違います。「最大」「最短」「一部」「通常」「対象外」など条件を限定する語もチェック対象です。

翻訳差分QAでは、FAQ IDをキーに原文と翻訳文を比較します。原文が更新されたFAQだけを抽出し、翻訳版の更新要否を判定します。変更が一文字でも必ず再翻訳する、あるいは変更が小さいから何もしない、のどちらも避け、回答の意味に影響するかを担当者が見ます。

更新時に言語間の回答をずらさない

原文を直すときは更新対象ID、変更前後、理由、影響言語を記録します。修正したIDだけ翻訳へ回し、公開前に対応する全言語の状態を確認します。翻訳が間に合わない場合は、古い回答を公開し続けるのか、対象FAQを一時非公開にするのか、運用責任者が決めます。AIが自動で公開する設計にはせず、公開者を明確にします。

公開後も更新日と確認者を残します。頻繁に変わる料金や利用条件なら、内容の根拠となる社内ページや公式情報を紐付け、次回確認の目安を決めます。翻訳文が原文と一致していても、原文自体が古ければ正しいFAQにはなりません。

失敗の兆候と戻し方

質問と回答のIDがずれたら、翻訳をそのまま戻さず、元の一覧から対応関係を復元します。回答が長くなったら、説明を足したのか、訳語の性質なのかを比較します。条件が消えたら、条件語だけを別チェックし、翻訳担当者に修正箇所を示します。どの原文に対応するか分からない出力は公開せず、再生成より先に入力データを整えます。

複数FAQを一度に処理する場合は、少数の代表IDで出力形式と用語が守られるか試します。安定しない場合は、質問の種類や専門性ごとに分割します。法務FAQと操作FAQを同じpromptにまとめると、同じ語でも必要な慎重さが異なるためです。

AIものさしの判断

FAQ多言語化では、翻訳文の流暢さだけでなく、FAQ ID、意味、用語、条件、更新履歴が言語間で揃うことを完了条件にします。原文の正本を決め、構造化し、用語と翻訳ルールを渡し、差分と高リスク箇所を人が確認してから公開します。

まずFAQを5〜10件だけ選び、ID、原文、用語、翻訳文、担当者、公開状態を並べて試行してください。正本や条件が分からない質問は翻訳せず保留します。各言語の回答が同じ範囲を説明し、原文更新時に追いかけられる運用ができたら、対象を広げます。

翻訳状態を公開まで管理する

各FAQに「原文確定」「翻訳案」「言語確認」「承認」「公開」の状態を持たせます。担当者が分からない、根拠リンクが古い、条件が確定していないFAQは翻訳完了にせず、公開対象から分けます。翻訳の進捗だけでなく、最終承認者と公開日が分かることが大切です。

公開する言語が増えた場合も、一斉に全件を出す必要はありません。問い合わせの多いFAQや利用者影響の大きい案内から、少数ずつ確認します。未対応言語に古い案内が残るなら、非公開、更新中の表示、サポート窓口への誘導など、組織が採用する扱いを決めてください。

FAQ翻訳の受入チェック

• FAQ IDが原文と翻訳版で一致している。

• 質問と回答の組が崩れていない。

• 条件、否定、例外、期限、金額、URLが照合済み。

• 用語表の固定訳が守られている。

• 原文にない保証や推測が加わっていない。

• 高リスクの回答を適切な担当者が確認した。

• 原文の更新が言語版へ反映できる状態になっている。

チェック項目が未完なら、そのFAQだけを保留できます。全件を再翻訳する必要があるか、影響範囲をIDで確認してから決めます。

担当者と更新ルールを決める

運用開始前に、原文オーナー、翻訳担当、レビュー担当、公開担当を決めます。同じ人が兼任しても構いませんが、公開の承認者を誰か分かる形にします。公開後に原文を修正した場合は、更新日、変更理由、影響するFAQ ID、翻訳の再確認状況を記録します。

問い合わせ内容からFAQの不足を見つけた場合は、既存回答をそのまま別言語へ増やす前に、正本の回答を更新します。各言語で個別に例外説明を足すと、正式な条件かローカルな補足か分からなくなるためです。地域固有の案内が必要なら、共通回答と地域別補足を別項目にします。

言語版の公開可否を決める

表は横にスクロールできます

状態	確認内容	次の処理
原文が未確定	正本候補の差分や更新日が一致しない	オーナーが正本を確定するまで保留
翻訳案のみ	IDと形式は揃ったが意味確認が未完了	担当者が条件・例外を照合
高リスク回答	返金、契約、安全、個人情報などを含む	該当領域の責任者が確認
公開承認済み	差分と用語、リンクが確認済み	承認言語だけ公開

全言語の完成を待つか、一部言語だけ先に公開するかは運用側の判断です。未対応言語の利用者が古いFAQへ到達するなら、公開版の更新日や追加確認先も用意します。読者が誤った条件をもとに行動しないことを優先し、翻訳作業の完了率だけで公開を決めません。

小さく試してから運用へ広げる

開始時は種類の違うFAQを少数選びます。定型の操作案内、plan条件を含む回答、例外のある回答を一つずつ含めると、用語表だけで足りるか、レビュー担当の専門知識が必要かを確認できます。試行では原文ID、翻訳指示、出力、修正理由、承認者を残し、同じ誤りが複数件で起きるならpromptの長さを増やす前に入力データや訳語ルールを見直します。

複数言語を一度に始めず、まず一言語で比較の手順が回るか確かめても構いません。担当者の負荷、確認にかかった時間、差し戻し理由は実際の運用記録として集めます。これらの値はサービス一般の性能を示す数字ではなく、自社FAQの運用設計を調整する材料です。