外国出願用の明細書の英訳を日本語の原文と段落ごとに照らし、訳抜け・数値の誤り・用語の不統一を拾って、逆訳を付けて弁理士の確認に回す

処理の起点を決める

担当者が、原文と英文明細書を所定の保存先に置いた時点を起点にします。 保存先は Azure Blob Storage のコンテナで、案件の番号のフォルダに、原文と訳文の2つがそろったときだけ処理を始めます。 片方だけで始めると、対応づけの段階で全段落が「訳抜け」になります。トリガーはファイル1つごとに動くので、動いた時点でフォルダにもう片方があるかを確かめ、無ければ何もせずに終わります。

トリガーはイベントベースのものを使います。 公式の説明では、Azure Functions の Blob storage トリガーにはイベントベースとポーリングベースの2つの実装があり、遅延が低いイベントベースが推奨され、Flex Consumption プランはイベントベースだけをサポートするとされています。ポーリングベースでは、従量課金プランでアプリがアイドルのとき、新しい BLOB の処理が最大で10分遅れうるとされています。届いた当日に一覧を見たいこの業務では、イベントベースにします。

特許事務所から直った訳文が届いた時点が、2回目の起点です。 直った訳文を同じフォルダに版を上げて置くと、前の版の一覧と比べて、直った行と、新しく出た行を分けて出します。 直した箇所の周りで別の誤りが入ることがあるからです。

夜間にまとめて動かすことはしません。 出願の期限が迫った案件では、届いた当日に一覧を見て、その日のうちに特許事務所へ修正を依頼したいからです。

入力データを集める

質を決めるのは、段落番号がそろっていることです。 日本語の明細書の【0001】と英文の [0001] が同じ段落を指していれば、対応づけはプログラムで確実にできます。 特許事務所に、段落番号を原文に合わせて振るよう依頼しておきます。

用語集の「使ってはならない訳語」の列が効きます。 決めた訳語だけでは、別の訳語が使われていることを見つけるのに、別の訳語の候補を知っている必要があるからです。 過去に修正を依頼した訳語を、この列に書き足していきます。

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

数値の拾い方は、日本語と英語で書き方の違いを吸収します。 「0.5〜2.0mm」と「0.5 to 2.0 mm」、「10質量%」と「10 mass%」、全角と半角の数字を、同じ形にそろえてから比べます。 そろえ方の決まりは、過去の明細書で拾い損ねた例から足していきます。

符号は、部品の名前と組で拾います。 数字だけを比べると、「センサ12」と「sensor 21」の取り違えは拾えても、「センサ12」が「detector 12」になった用語の不統一は拾えません。 組で拾い、用語集と照らします。

AIへ渡す前に整形する

1. 形式の確認 … 原文と訳文が Word の形式であることを確かめます。PDF で届いたものは Word で受け取り直します
2. 段落番号の対応の確認 … 原文と訳文で段落の数と番号の並びが一致しているかを確かめます。一致しない場合は、対応づけを止めて担当者に知らせます
3. 請求項の番号の対応の確認 … 請求項の数と番号が一致しているかを確かめます
4. 表と数式の扱い … 表は行ごとに文にし、数式は画像のままであれば「数式（照合対象外）」として印を付けます
5. 書き方のそろえ … 全角と半角、範囲の記号、単位の書き方をそろえます
6. 用語集の読み込み … 最新版を読み、訳語の照合に使う辞書を作ります
7. 段落の分割 … 1回の依頼に入れるのは、対応する1組の段落と、前後1段落ずつの原文と訳文までにします

2番目と3番目で止める設計を軽く見ないでください。 段落の数がずれたまま進むと、ずれた位置から後ろのすべての段落が「訳抜け」や「意味の変化」として出てきます。 一覧が数百行になり、担当者は見る気を失います。

7番目で前後の段落を入れるのは、段落をまたいで文が移されていることがあるからです。 訳文では、原文の段落の最後の一文が次の段落の最初に入っていることがあり、前後を見なければ、それを訳抜けと誤って指摘します。

AIに処理させる

させるのは、段落ごとに、原文の文が訳文のどこに当たるかを見て、抜け・追加・意味の変化を指摘し、指摘した英文を直訳することだけです。

数値・単位・符号・用語集の訳語は、AIに見させません。 それはプログラムの照合の結果を一覧に並べます。AIの指摘とプログラムの照合が同じ箇所を指していれば、一覧では1行にまとめます。

1行目がいちばん起きやすい失敗です。 指摘させると、AIは「より適切な訳」を書き添えます。その訳が特許事務所への修正の依頼にそのまま入ると、出願した英文の中に、誰も責任を持っていない文が残ります。 逆訳は「いまの訳文が何と言っているか」を見せるためのもので、直し方の提案ではありません。

指示内容を固定する

あなたは製造業の知財部で、外国出願用の英文明細書が日本語の原文を
正しく反映しているかを確かめる立場です。
渡された原文の段落と訳文の段落だけを見て判断してください。
技術の一般的な知識で、原文に無いことを補わないでください。

【見ること】
原文の各文が訳文のどこに当たるかを見て、次の種類の食い違いを指摘してください。
- omission ……… 原文の文や語句に当たる訳文が無い
- addition ……… 原文に無い内容が訳文にある
- scope_change … 程度・範囲を表す語（約、以上、以下、未満、超、少なくとも、
                 実質的に など）が抜けた、または別の語になった
- logic_change … 「又は」「及び」「かつ」、条件と理由など、つながりが変わった
- meaning_change … 否定、主語、修飾の係り方が変わった

【見ないこと】
- 数値、単位、図面の符号、用語の訳語の違いは見ないでください（別に照合します）。
- 英文として自然かどうか、文体の良し悪しは指摘しないでください。

【指摘の書き方】
- source_quote には原文の該当部分を、target_quote には訳文の該当部分を、
  文書のとおり一字も変えずに写してください。訳文が無い場合は target_quote を空にしてください。
- back_translation には、target_quote の英文を日本語へ直訳してください。
  意訳しない、補わない、原文に寄せないでください。
- 修正案、より良い訳、誤訳かどうかの結論は書かないでください。
- 前後の段落は、文が移されていないかを見るためだけに使い、
  前後の段落そのものの食い違いは指摘しないでください。
- 食い違いが無い場合は findings を空にしてください。

【原文の段落】{source_paragraph}
【訳文の段落】{target_paragraph}
【前後の段落（参考）】{context}

「原文に寄せないで直訳する」を明記しないと、逆訳が原文に近づきます。 AIは原文を見ているので、英文を訳すときに原文の言い回しを借りてしまい、「約」が抜けた英文の逆訳に「約」を入れてしまいます。 それでは、弁理士が日本語どうしを見比べても違いが見えません。

「一字も変えずに写す」は、第5章の5番目の照合のためです。 引用を少しでも整えられると、文書の中から探せなくなり、正しい指摘まで外れます。

出力形式を固定する

構造化出力で、次の形の JSON を受け取ります。

{
  "paragraph_id": "0034",
  "findings": [
    {
      "type": "omission | addition | scope_change | logic_change | meaning_change",
      "source_quote": "",
      "target_quote": "",
      "back_translation": "",
      "note": ""
    }
  ]
}

1つ目の理由は、指摘の種類で並べ替えられることです。 scope_change と logic_change は請求の範囲に関わりやすく、弁理士が先に見る行です。 種類を決まった値で受け取れば、一覧の並べ替えをプログラムで書けます。

2つ目は、引用を照合できることです。 source_quote と target_quote が原文と訳文の中にそのまま含まれるかを、Azure Functions が確かめます。含まれない指摘は、一覧に載せずに記録だけ残します。

3つ目は、プログラムの照合の結果と1行にまとめられることです。 一覧には次の列を並べます。

note は自由記述ですが、短い補足に限ります。 スキーマの側では長さを制限できない（maxLength はサポートされないキーワードとされています）ので、受け取った後にプログラムで長さを確かめ、長いものは切らずに担当者への印を付けます。

システムへ連携する

Chat Completions API を使うのは、会話の履歴をサービスに残さないためです。 公式の説明では、Responses API はメッセージの履歴とそれに関わる内容を保存するとされています。段落ごとの依頼は1回ずつ完結するので、履歴を残す必要がありません。

特許事務所へは、一覧を自動で送りません。 一覧には誤った指摘も含まれていて、担当者と弁理士が外した後のものだけを修正の依頼に使います。

人が確認する

1. 担当者が、範囲の変化と論理の変化の行を先に見る … 原文と訳文の引用を文書で確かめ、逆訳と原文を見比べます
2. 担当者が、訳抜けの行を見る … 前後の段落に文が移されていないかを確かめます。移されていれば「誤った指摘」とします
3. 担当者が、数値・符号・用語の照合の行を見る … 書き方の違いだけのもの（単位の換算が正しいものなど）を外します
4. 弁理士が、残った行を読む … 請求項の文に当たるものを先に見て、修正を依頼するかを決めます
5. 弁理士が、修正の依頼をまとめる … 依頼の文は弁理士が書きます

2番目を省かないでください。 訳抜けの指摘のうち、段落をまたいで文が移されただけのものは、前処理で前後の段落を入れても残ることがあります。それを弁理士に回すと、弁理士が本物の訳抜けを探す時間が減ります。

目標は1件120分です。 担当者の確認に70分、弁理士の判断と修正の依頼に50分を見込みます。請求項が多い案件や、訳者が初めての翻訳会社の案件は120分を超えます。

例外に対処する

上の2行が大半を占めます。 どちらもAIの問題ではなく、特許事務所との受け渡しの決まりの問題です。 段落番号と Word の形式を依頼の条件に入れておけば、ほとんど起きません。

記録を残す

• 案件ごとに、原文と訳文のファイル（版を含む）と、受け取った日時
• 段落の対応づけの結果と、止めた場合の理由
• プログラムの照合の結果（数値・単位・符号・訳語の、原文と訳文の値）
• AIへの依頼と応答の全文、引用の照合の結果（照合できずに外した指摘を含む）
• 担当者の確認の結果と、弁理士の判断と理由
• 特許事務所への修正の依頼と、直った訳文の版

3つ目を残すのは、「数値は照合した」と言えるようにするためです。 出願した後に数値の誤りが見つかったとき、照合したのに見落としたのか、照合の書き方の決まりから漏れていたのかを、記録で確かめられます。

5つ目は、指示と用語集を直す材料です。 「誤った指摘」が多い種類は指示に、修正を依頼した訳語は用語集の「使ってはならない訳語」に反映します。