AIで製品マニュアルを翻訳する方法｜用語集で表記を固定

製品マニュアルの翻訳は、文章が自然なら終わりではありません。同じButtonやFeatureが章ごとに別の名前で呼ばれると、Userは操作対象を見失います。翻訳前に製品名、UI Label、機能名、専門語、Warning表現、翻訳しないCodeやModel名をTerminology Contractとして固定します。

この記事では、Terminology Sheet、UI Labelと説明文の分離、Glossary適用、Warning / Cautionの強さ、Code・型番の保護、章別QA、全体Terminology Scan、次Versionへ引き継ぐChange Logまで整理します。読後には、AIへマニュアルを渡して自然な訳文を作るだけでなく、製品全体で用語と操作名が一貫した状態を管理できます。

最初にTerminology Contractを作る

マニュアル翻訳では、翻訳Styleより先に「何をどう呼ぶか」を決めます。

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

Type	Source Term	Approved Translation	Keep as-is	Context
Product	Model X	Model X	yes	製品名
UI Label	Settings	設定	no	画面Label
Feature	Auto Sync	自動同期	no	機能名
Code	XG-200	XG-200	yes	型番
Warning	Warning	警告	no	Safety heading

実際の訳語は既存製品、UI、Support文書の正本に合わせます。

既存UIをTerminologyの正本にする

画面上でButtonが「保存」と表示されているのに、Manualだけ「セーブ」と訳すとUserは迷います。

UI Labelは文章として自然かより、実際の画面表示と一致するかを優先します。既存UIの文字列一覧があるなら、それをGlossary Sourceとして使います。

UI Labelと一般語を分ける

SaveがButton名なら「保存」、文章中のsave the fileなら「ファイルを保存する」のように、同じSource WordでもRoleが違います。

Terminology SheetにUI_LABEL / BODY_TERM / CODE / PRODUCTなどRoleを持たせると、機械的な一括置換を避けられます。

Feature NameはBrand Ruleを確認する

機能名が正式なBrand Nameなら原文保持、公式日本語名があるなら固定訳、まだ日本語名がないなら翻訳方針を決めます。

AIに毎章自由に訳させると、「Smart Sync / スマート同期 / 自動同期」のように揺れる可能性があります。

翻訳しない語をDo-not-translate Listに入れる

Product Name、Model Number、Command、API Name、Variable、File Path、URLなどはそのまま残す場合があります。

例：XG-200, /etc/device/config, reset_mode=true。Caseや記号まで変わると操作不能になることがあるため、完全一致で保持します。

GlossaryにはContextと例文を持たせる

Source Termと訳語だけでは曖昧な語があります。

portなら通信Portなのか物理端子なのか、driverならDevice Driverなのか運転者なのか。ContextとExampleを持たせると誤適用を減らせます。

GlossaryのPriorityを決める

既存UI、既存Manual、Marketing Copy、一般的な訳語が食い違う場合があります。

たとえば UI > Approved Manual > Product Glossary > Editorial Preference のように優先順位を決めます。Source of Truth同士が矛盾する場合は勝手に統合せず、Owner確認へ回します。

章ごとにTranslation Packageを作る

AIへ渡すInputには、本文に加えてTerminology Contract、Do-not-translate List、Style、対象Audience、Safety Text Ruleを含めます。

章単位で処理しても同じRuleを毎回適用できるよう、PromptとGlossary Versionを残します。

Prompt例

「以下は製品ManualのChapter C03です。Terminology SheetのApproved Translationを必ず使用してください。UI Labelは登録値と完全一致、Product Name / Model / Code / Command / File Pathは翻訳しない。Warning / Caution / Noteの強さを変えない。数字、単位、条件、否定を維持する。Glossaryにない専門語は推測で固定せずTERM_REVIEWとして一覧化してください。」

Glossary未登録語を勝手に確定しない

翻訳中に新しい専門語が出た場合、AIが自然な訳を選んでも、それを全Manualの正式語と自動確定しません。

TERM_REVIEWへ追加し、OwnerがApproved Translationを決めてから後続章へ適用します。

Terminology Change Logを作る

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

Term	Old	New	Reason	Effective From	Reviewer
Auto Sync	自動同期	オート同期	UI変更	v2.3	Product Owner

訳語が変わった場合、過去章やHelp Centerも更新対象か確認できます。

Warning / Caution / Noteを別扱いする

Safety Manualでは、Warningの強さを柔らかくしたり、逆に強めたりするとRiskがあります。

Heading Level、Signal Word、条件、結果、回避方法をセットで原文照合します。自然化より意味の強さを優先します。

架空のWarning例

Source：WARNING: Disconnect power before opening the cover.

Translation：警告：カバーを開ける前に電源を切ってください。

説明用の例ですが、beforeや命令の強さを落とさないことがポイントです。

ProcedureはStep順を変えない

操作Manualの1→2→3は順番自体が意味を持ちます。

AIが読みやすさのためにStepを並べ替えないよう指示し、翻訳前後でStep CountとOrderを比較します。

UI Labelを引用符やBoldで識別する

本文中のButton名と一般名詞が混ざる場合、[Save]、「保存」などDocument Ruleに沿って識別します。

Userが画面とManualを照合しやすい表記を全章で統一します。

数字とUnitを原文照合する

Voltage、Temperature、Torque、Storage、Time、File Sizeなどは、誤訳すると操作や安全性へ直接影響します。

単位換算を行う場合はConversion Ruleを別途定義し、AIに暗黙換算させません。原Unitを併記する必要があるかも決めます。

DecimalとRangeを確認する

0.5, 5.0, 5–10, ±2などはFormat変更で意味が変わることがあります。

小数点・Dash・Plus/Minusを含め、Critical Numberとして照合します。

Code Sampleは翻訳対象から分離する

Code Block内のKeyword、Parameter、JSON Key等を翻訳すると動作しません。

Commentだけ翻訳するか、Codeは完全保持するかを決め、本文翻訳とは別のRuleにします。

Screenshot内UIと本文を照合する

ManualにScreenshotがある場合、本文のUI Labelと画像内Labelが一致しているか確認します。

画像が旧Versionなら、翻訳の問題ではなくSource Asset更新が必要かもしれません。Translation QAだけで直そうとしません。

表やListはStructure QAも行う

Spec TableやProcedure Listでは、G939のようにRow / Column / Item Countを比較します。

訳語が正しくてもCell位置がずれていたらManualとしては誤りです。

章別Terminology Scanをする

翻訳後、Approved TranslationとSource Termの残存を検索します。

たとえば「自動同期」がApprovedなのに「スマート同期」「Auto Sync」が本文へ混在していないかを確認します。Keep-as-is指定の語は逆に翻訳されていないか見ます。

禁止訳リストも持つ

過去に使っていた旧訳や誤解を招く訳がある場合、Do not useとして登録します。

Approved TermだけでなくForbidden Termを検索すると、旧ManualからCopyされた表記揺れを見つけやすくなります。

Naturalness QAはTerminology QAの後

まず用語・数字・Step・Warningを固定し、その後に読みやすさを整えます。

文章を自然にするPassでUI LabelやTechnical Termを言い換えないよう、Glossaryを再適用します。

Audienceに合わせて説明量を調整する

Service Technician向けと一般User向けでは、専門語をそのまま残す範囲が違うことがあります。

ただし同じProduct Conceptの正式名称は維持し、説明文の補足量だけを調整します。

Version差分を翻訳単位で追う

Manual v2.2→v2.3で変更された箇所だけ翻訳する場合も、Glossary Versionを固定します。

旧訳を再利用するときは、Source Sentence自体が変わっていないか確認し、似ているだけの文へ過去訳を流用しません。

Translation Memory的に再利用する場合の注意

過去のApproved Translationは有用ですが、前提条件やUIが変わっている可能性があります。

再利用候補として扱い、Current SourceとTerminology Contractに合うことを確認してから採用します。

Manual QA Matrix

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

Check	Status	Method
Glossary一致	PASS	Term Search
UI Label一致	PASS	UI string照合
Warning	REVIEW	原文対照
Number / Unit	PASS	Spot Check
Step Count	PASS	Structure Count
Code保持	PASS	Diff

Critical項目だけでもStatusを残すと、Review漏れを管理しやすくなります。

完了条件

Manual TranslationのDoneは、全文の訳があることだけではありません。

Glossary未解決0、UI Label一致、Critical Number照合、Warning Review、Step Structure確認、Forbidden Term検出0、最終Consistency Passまでを完了条件にします。

最終Checklist

• Terminology Contractを作成

• UIを正本としてLabelを固定

• Keep-as-is / Forbidden Termを定義

• Glossary Contextを記録

• 未登録語をTERM_REVIEWへ

• Warning強度を維持

• 数字/Unit/Rangeを照合

• Procedure順を維持

• Code / Model / Pathを保護

• Table / List Structureを確認

• 全章Terminology Scanを実施

• Change Logを更新

AIものさしの判断

製品マニュアルの翻訳では、文章単位の自然さより「同じものを文書全体で同じ名前で呼ぶ」ことが土台になります。UI Label、Technical Term、Warning、Codeを先にContract化すれば、AIの表現揺れを抑えやすくなります。

まず1章だけでTerminology Pilotを行い、Glossary未登録語とUI Label差分を洗い出してください。Approved Termが固まったら残りへ展開し、最後に全章Searchで表記揺れとForbidden Termを確認する。この順なら、長いManualでも一貫性を維持しやすくなります。