外国出願のために、日本語の特許明細書から英文明細書の下訳を段落ごとに作り、用語集と過去の訳にそろえて、訳の確認が要る箇所を一覧にする

処理の起点を決める

外国出願が決まった案件の明細書を、案件フォルダに置いたことを起点にします。 外国出願の会議で出願先が決まると、担当者が明細書の最終版と、出願先の国・技術分野を書いた案件票をフォルダに置きます。Power Automate がフォルダへの保存を見て、Python の処理を呼びます。

明細書は、国内出願したときの最終版を使います。出願後に誤記を見つけて直した版がある場合は、どちらを訳すかを担当者が案件票に書きます。訳す元の版が決まっていないと、下訳と出願の内容がずれます。

段落ごとの下訳は、バッチにまとめて送ります。送った後は待つだけで、多くは1時間以内に返ってきます。 返ってきたら Python が照合を走らせ、結果を案件フォルダに書き出して担当者に Teams で知らせます。

バッチを使わないと決めた会社では、同じ処理を通常の Messages API で段落ごとに順に送ります。 第6章のとおり、バッチは29日間の保持があり ZDR の対象外とされているためです。この場合も、用語集と指示文はプロンプトキャッシュで使い回せます。段落を間を空けずに続けて送れば、5分の有効期間の中でキャッシュに当たり続けます。 送る順は段落番号の順にし、途中で止まったときは止まった段落から再開できるよう、返ってきた段落の ID を控えます。

入力データを集める

質を決めるのは、過去の英文明細書を段落の対にしてあるかです。 英文明細書が PDF で1本の文書として残っているだけでは、どの日本語の段落の訳なのかが分かりません。段落番号でそろえた「日本語の段落｜英語の段落」の対にしておくと、同じ文の訳を機械的に引けます。 最初の準備で、直近の数十件を対にしておきます。

英文の書き方の決まりは、担当者の経験を文書にしたものです。 長く担当している人が頭の中で使っている決まりを、「前記Aは the A と訳す」「〜以上は at least 〜 か 〜 or more のどちらにそろえる」のように書き出します。

データの取得方法を決める

用語集の当て込みは、長い語から順に行います。 「第1支持部材」と「支持部材」が両方用語集にあれば、先に「第1支持部材」を当てます。短い語から当てると、長い語の一部だけが訳され、残りが AI 任せになります。

関連する過去の出願の番号は、案件票から取ります。 分割や改良の出願では、親の出願の英文明細書と同じ段落が多く含まれます。番号が分かっていれば、その出願の段落の対を優先して引けます。

過去の訳は、同じ文と近い文を分けて渡します。 同じ文は「この訳をそのまま使う」、近い文は「参考にする」と指示を変えます。近い文の訳をそのまま使わせると、違う部分まで過去の訳で上書きされます。

AIへ渡す前に整形する

1. 段落で区切る … 段落番号ごとに1件にします。請求項は1項ずつ1件にします
2. 段落に番号の付いた ID を振る … 【0012】は p0012、請求項1は c01 のようにし、訳と原文を対で追えるようにします
3. 用語集の語を当てる … 段落ごとに、出てくる用語集の語と訳の一覧を作ります
4. 過去の訳を当てる … 同じ文の訳と、近い文の訳の上位数件を付けます
5. 数値と符号を抜き出す … 数値、単位、範囲（〜以上、〜未満）、図面の符号（「支持部材12」の12）を原文から抜き出して控えておきます
6. 化学式・数式・表を分ける … 段落の中の化学式や数式、表は訳の対象から外し、原文のまま英文に入れる印を付けます

5番目は、訳の後の照合のために控えます。 AI には数値と符号を渡しますが、守られたかは AI の自己申告ではなく、控えた一覧と訳を比べて確かめます。

AIに処理させる

させるのは、段落を英訳すること、使った用語を返すこと、確認が要る箇所に印を付けることの3つです。

最後の種類は、訳の問題ではなく原文の問題です。 二通りに読める日本語を一方に決めて訳すと、外国の出願だけが、国内の出願と違う意味になります。 決めるのは発明者と担当者で、AI は両方の読みを示すまでにとどめます。

指示内容を固定する

あなたは製造業の知財部で、外国出願の英文明細書の下訳を作る立場です。
渡された日本語の段落を英訳してください。最終版ではなく、確認を受ける下訳です。

【守ること】
- 「用語」の一覧にある日本語は、必ず一覧の英語で訳してください。
  文脈上、一覧の訳が合わないと判断したときも置き換えず、
  一覧の訳のまま訳したうえで flags に term_conflict として理由を書いてください。
- 「過去の訳（同じ文）」がある場合は、その英文をそのまま使ってください。
- 「過去の訳（近い文）」は参考にとどめ、違う部分は原文に合わせて訳してください。
- 原文に無い内容を足さないでください。説明を補わないでください。
- 数値、単位、範囲、図面の符号は原文のまま写してください。換算しないでください。
- 化学式・数式・表の印が付いた部分は、訳さずに原文のまま残してください。
- 「約」「以上」「以下」「未満」「略」「実質的に」「少なくとも」は、
  英文の書き方の決まりに従って訳し、必ず flags に scope_word として挙げてください。
- 主語を補ったときは、補った主語を flags に subject_added として挙げてください。
- 「前記」「当該」などの受ける語が一つに決まらないときは、
  一つに決めずに flags に antecedent として候補を全部挙げてください。
- 日本語の原文が二通りに読めるときは、一方を選んで訳したうえで、
  flags に ambiguous_source として両方の読みを書いてください。
- 迷った箇所を flags に書かずに済ませないでください。flags が空でよいのは、
  迷った箇所が一つも無いときだけです。

【英文の書き方の決まり】{writing_rules}
【用語（この段落に出てくるもの）】{terms}
【過去の訳（同じ文）】{exact_matches}
【過去の訳（近い文）】{fuzzy_matches}
【段落 ID】{paragraph_id}
【原文】{source_text}

「一覧の訳が合わないと判断したときも置き換えない」を書くのが、この指示文の要です。 何も言わなければ、文脈に合う訳を選んで置き換えます。置き換えた訳が正しくても、出願どうしの用語はそこでずれます。 置き換えたい理由は flags に書かせ、用語集を直すかは人が決めます。

「flags が空でよいのは、迷った箇所が一つも無いときだけ」は、印の付け惜しみを止めるためです。 流暢な訳ほど、迷いが無かったように振る舞います。

出力形式を固定する

構造化出力で、段落ごとに次の形の JSON を受け取ります。

{
  "paragraph_id": "p0012",
  "translation": "",
  "terms_used": [
    { "ja": "", "en": "", "source": "glossary | exact_match | new" }
  ],
  "flags": [
    { "type": "scope_word | antecedent | subject_added | term_new | term_conflict | ambiguous_source",
      "ja_span": "", "en_span": "", "note": "" }
  ]
}

1つ目の理由は、terms_used を Python で確かめられることです。 用語集の語が glossary で返っていても、translation の中にその英語が本当に入っているかを、文字列の照合で確かめます。 入っていなければ、AI の自己申告と訳が食い違っているということです。

2つ目は、flags を種類で並べ替えられることです。 担当者は scope_word と antecedent を先に、subject_added を後に見ます。請求項の範囲に関わるものから見る順番を、種類で決められます。

3つ目は、Python の照合の結果を同じ一覧に足せることです。 照合で見つけたものは、次の種類で一覧に加えます。

確認の一覧に並ぶ行は、たとえば次の形になります。

1行目は請求項の範囲そのものに関わる行です。 「約」と「以上」が重なった表現は、英訳の仕方で範囲の端が変わって読めます。担当者が決めきれなければ、事務所への申し送りに入れます。 3行目は、AI が terms_used では用語集どおりと答えていても、照合で食い違いが見つかった例です。

照合の length_short は、段落の後半が訳されずに終わったものを拾うためです。 構造化出力のスキーマでは文字数を縛れないとされているため、長さは受け取った後に確かめます。

システムへ連携する

知財管理のシステムと用語集には、この構成からは書き込みません。 用語集に足すかは担当者が決めて手で足します。AI が決めた訳が、確認を経ずに用語集に入る経路を作らないためです。 用語集に入った訳は、次の案件からは「必ず使う訳」になります。

人が確認する

1. 請求項を全文読む … 印の有無にかかわらず、すべての請求項の訳を原文と並べて確かめます
2. scope_word と antecedent を見る … 範囲の語と、指す先の訳を確かめます
3. term_conflict と term_new を見る … 用語集の訳を置き換えたいという理由を読み、用語集を直すか、新しい語を足すかを決めます
4. 照合の結果を見る … 数値・符号・長さの食い違いを直します
5. ambiguous_source を発明者に確かめる … 原文が二通りに読める箇所は、どちらの意味かを発明者に聞き、必要なら日本語の明細書の側の扱いも事務所と相談します
6. 残りの段落を流し読みする

5番目は、訳の担当者だけで決めないでください。 原文の意味を決めるのは発明者で、どちらに決めたかは特許事務所への申し送りに必ず書きます。

目標は、1件をならして180分です。 請求項の通読に40分、印の付いた段落に80分、用語と申し送りに60分という配分です。印の付いた段落が全体の3割を超える案件が続くなら、用語集か書き方の決まりが足りていません。

例外に対処する

6行目は、用語集の側の問題です。 訳が2つある語を AI に渡すと、段落ごとに違う方を選びます。用語集を直さないかぎり、毎回同じずれが出ます。

記録を残す

• 訳す元の明細書の版と、案件票
• 段落ごとに当てた用語と過去の訳（AI に渡したもの）
• バッチの ID と、段落ごとに返ってきた JSON の全文
• Python の照合の結果
• 担当者が直した後の下訳と、直した段落の一覧
• 用語集に足した語と、足すと決めた人・日
• 特許事務所への申し送り（ambiguous_source の決め方を含む）

案件フォルダのアクセス権は、外国出願の担当と特許事務所の窓口に限ります。 段落ごとの JSON には明細書の全文がそのまま入っているため、明細書の原本と同じ扱いにします。出願が公開された後も、確定前の下訳と確認の一覧は社外に出しません。

AI に渡したものを残すのは、訳の誤りの原因を分けるためです。 用語の誤りが、用語集の訳の誤りなのか、AI が用語集を守らなかったのかは、渡したものが残っていないと分かりません。バッチの結果は作成から29日で取り出せなくなるため、返ってきた JSON はその日のうちに案件フォルダへ保存します。