AIで表や箇条書きのレイアウトを崩さず翻訳する方法

表や箇条書きをAIで翻訳するときは、文章の自然さより先に「どの原文要素が、訳文のどこに対応するか」を固定します。表ならRow / Column / Cell、箇条書きなら階層と順番を翻訳単位にし、翻訳前後で件数と位置関係を照合します。

この記事では、Structure Manifest、Cell ID、Bullet Path、結合Cell、脚注、数値・単位・Placeholder、文字量増加によるLayout崩れまで整理します。読後には、内容が自然でも表の対応がずれている翻訳を避け、構造と意味の両方を確認できる状態を目指します。

最初に翻訳対象のStructureを数える

翻訳前に、Table数、Row数、Column数、見出し数、Bullet数、Footnote数を記録します。

例：Table 2 / Rows 18 / Columns 5 / Bullet lists 4 / Bullet items 27 / Footnotes 3。この数がAfter Translation QAの基準になります。

Structure Manifestを作る

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

Element ID	Type	Position	Count / Level	Note
T01	Table	p.3	6×4	Header 1 row
L01	Bullet	p.5	8 items / 2 levels	Nestedあり
F01	Footnote	p.6	1	Table T02参照

文書全体を翻訳する前に、壊したくない構造を一覧化します。

表はCell IDで対応させる

Table 1のRow 2 / Column 3ならT01-R02-C03のようなIDを付けます。

AIへはCell単位で原文と訳文を対応させ、順番を変えないよう指示します。翻訳後にCell IDを外しても構いませんが、作業中は対応確認に使えます。

Headerは本文Cellと分ける

Headerは列の意味を決めるため、訳が曖昧だと全Rowの理解へ影響します。

たとえばStatusを「状態」「進捗」「ステータス」のどれにするかを先に決め、同じTable内で揺らさないようにします。

結合Cellは最初に記録する

Rowspan / Colspanのある表は、単純なCSV化で位置関係が崩れることがあります。

「R1C1はC1〜C3を結合」「R4C1は2Rowを結合」のように記録し、翻訳後も同じGroupを指しているか確認します。

架空のTable Input / Output

Input：

T01-R01-C01 | Plan

T01-R01-C02 | Monthly price

T01-R02-C01 | Basic

T01-R02-C02 | $20 / user

Output：

T01-R01-C01 | プラン

T01-R01-C02 | 月額料金

T01-R02-C01 | Basic

T01-R02-C02 | $20 / user

製品名やPrice表記をKeep-as-isにする場合は、Glossary / Do-not-translate Listで固定します。

数字・単位・記号は別にQAする

表では文章より数字の方がDecisionに直結することがあります。

金額、%、単位、型番、日付、Range、≤や±などの記号は原文と照合します。Localeに合わせて表記変更する場合も、Value自体が変わっていないか確認します。

BulletはPathで管理する

箇条書きはL01-1, L01-1.1, L01-1.2, L01-2のようにPathを付けます。

これならNested BulletがFlattenされていないか、Itemが落ちていないかを機械的に近い形で確認できます。

Bulletの階層は意味の一部

親Bulletが条件、子Bulletが例外や具体例になっていることがあります。

すべてを同じ階層へ平らにすると、条件関係が変わる可能性があります。翻訳後もLevelを維持します。

番号付きListは順番を勝手に変えない

手順書の1→2→3はProcess順かもしれません。

AIが読みやすさのために順序を入れ替えないよう、「Order must remain unchanged」と明示します。順序変更が必要なら、翻訳ではなく編集として別判断にします。

Footnoteは参照先を維持する

脚注がどのCellやSentenceにかかっているかを記録します。

翻訳後にFootnote Textだけ残っても、参照先が変わると意味を失います。F01 → T02-R04-C02のようにLink関係を保持します。

PlaceholderとVariableを翻訳しない

{{user_name}}、%s、{0}、<product_id>のようなVariableを文章として翻訳するとSystemで使えなくなる場合があります。

Do-not-translate Listへ入れ、文字列を完全一致で保持します。前後の語順だけTarget Languageに合わせます。

URL・Code・File Pathも保護する

URL、Command、API Parameter、File Pathなどは通常の文章と分けます。

自然な翻訳のためにSlash、Hyphen、Caseまで変えられると動作しないことがあります。Code Spanとして保持し、前後の説明だけ翻訳します。

AIへのPrompt例

「以下のTable / Listを翻訳してください。Structure IDを維持し、TableはCell単位、ListはBullet Path単位で出力してください。Row / Column / Item Orderを変えない。数字、単位、URL、Code、Placeholder、Product Nameは指定どおりKeep。Merged Cell、Footnote Reference、Nested Levelを維持する。翻訳が長くなりLayout RiskがあるCellにはLONG_TEXTを付けてください。」

文章品質とStructure Preservationを同時に要求します。

翻訳後の文字量増加を想定する

言語によって、原文より訳文が長くなるCellがあります。

そのまま押し込むとFont Size低下やRow Height増加につながります。まず長文化したCellを検出し、短縮案・Column幅・Layout分割の順で調整します。

短縮は意味を削らず別Passで行う

Layoutに収まらないからといって、最初の翻訳時に重要条件を省略しないようにします。

Full Translationを保存したうえで、PresentationやUI用にShort Versionを別途作ります。短縮後は原文と意味比較します。

表のCell内改行を確認する

原文で1Cell内に2Lineある場合、それが単なる見た目なのか、2つの意味単位なのかを確認します。

翻訳後に不必要な改行を増やすとRow Heightが崩れます。逆に意味の違うLineを1つに統合すると読みにくくなる場合があります。

Headerの長文化は略語を勝手に作らない

英語Headerを日本語へすると長くなる、または逆に日本語から英語で長くなることがあります。

Spaceが足りないからとAIが独自略語を作ると、意味が伝わらない可能性があります。Approved Abbreviationがある場合だけ使い、それ以外はLayout側で調整します。

表が画像化されている場合は取得QAから始める

PDF内のTableが画像の場合、Cell構造自体を正しく取得できていない可能性があります。

Header数、Row数、代表CellのValueを原画像で確認し、Structure Acquisitionが通ってから翻訳します。

List Marker自体に意味がある場合

Check、Warning、禁止、手順などでIconやMarkerが意味を持つことがあります。

単なるBulletへ統一せず、Warning, Required, OptionalなどSemantic Roleを残します。

Before / After Countを比較する

翻訳前後で次を比較します。

• Table Count

• Row / Column Count

• Cell Count

• Bullet Item Count

• Nested Level Count

• Footnote Count

• Placeholder Count

Countが変わった場合は、意図した変更か確認します。

Cell Spot Checkをする

全Cellを毎回手で見るのが難しい場合でも、Header、最長Cell、数字の多いRow、条件文、Footnote付きCellを重点確認します。

重要Tableは全Cell照合してもよいです。

Layout QAとTranslation QAを分ける

Translation QAでは意味・用語・数字を確認します。Layout QAでは位置・順序・階層・折返し・Overflowを確認します。

訳文が正しくてもLayoutが壊れていればDeliverableとして未完了です。逆に見た目が整っていてもCell対応が違えばFAILです。

Final Structure QA

• Table / List / Footnote数が一致

• HeaderとCellの対応が維持

• Merged Cellの意味を保持

• Bullet階層と順番が同じ

• 数字/単位/記号が一致

• Placeholder / URL / Codeが不変

• LONG_TEXT箇所をReview

• Footnote参照先が正しい

• 最終FileでOverflowや切れを確認

AIものさしの判断

表や箇条書きの翻訳では、原文の見た目をそのまま再現することより、「構造上の対応関係を壊さない」ことが先です。TableはCell、ListはPathを翻訳単位に固定すると、抜けや位置ずれを見つけやすくなります。

まず最も複雑なTableかNested Listを1つだけPilotしてください。Structure Manifest→翻訳→Count比較→Cell Spot Check→Layout確認まで通し、そのRuleを残りへ展開する。この順なら、全文を翻訳した後に構造崩れを発見するリスクを減らせます。