競合する中国企業の中国語の特許公報を毎月訳して要約し、請求項の要点と自社製品との関わりを知財担当の確認一覧にする

処理の起点を決める

毎朝の時間主導型トリガーで、受け入れのフォルダに新しいファイルがあるかを見ます。 Google Apps Script のインストール型トリガーの時間主導型は、指定した時刻から1時間の幅のなかで動く時刻が決まるので、知財担当の始業より前の時間にします。

ファイルを置いたことを起点にしないのは、月初にまとめて100件以上を置くからです。 1件ずつ置いた瞬間に動かすと、スクリプトの1回の実行時間の中に収まらず、途中で止まった公報が残ります。毎朝、未処理のものから決まった件数ずつ処理し、数日で月の分を終える形にします。

処理済みかどうかは、一覧の状態の列で見ます。 「未処理」「処理中」「完了」「要人手」の4つで、「処理中」のまま翌朝になったものは、失敗として「未処理」に戻します。

入力データを集める

質を決めるのは、下の2つです。 用語集が無いと、同じ中国語の用語が公報ごとに違う日本語になり、要素の対応づけで同じものを別のものとして扱います。 自社製品の構成の一覧が粗いと、対応づけは「どれも似ている」になります。

自社製品の構成の一覧は、請求項と同じ粒度で書きます。 「高信頼のコンデンサ」のような書き方では、請求項の要素と対応づけられません。「内部電極がニッケルを主成分とする」「誘電体層の厚さが1μm以下」のように、請求項の言い方に近づけて書きます。

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

PDFは、ドライブのファイルを読み込み、Files API にアップロードしてから依頼に添えます。 1件の公報について、①翻訳、②要素分け、③対応づけの3つの依頼を同じファイルで送ります。

自社製品の構成の一覧は、公報の分野で絞って渡します。 全製品の一覧を渡すと、遠い製品の要素まで「似ている」と書く候補が増えます。公報の国際特許分類と、製品ごとに持たせた分類の列を突き合わせ、関係しそうな製品の構成だけを渡します。 分類が合わないものは、全製品を渡したうえで「対応なし」になりやすいことを承知で処理します。

AIへ渡す前に整形する

1. ファイル名の確認 … 「公報番号_出願人.pdf」の形になっているかを確かめ、違えば「要人手」にします
2. 大きさとページ数の確認 … 50MB、1,000ページの範囲に収まるかを確かめます
3. 重複の確認 … 同じ発明の公開の公報と登録の公報が両方届いたら、一覧で2行を紐付けます。 登録の公報では、請求項が公開のときから変わっていることが多いからです
4. 用語集の絞り込み … 公報の分野に関係する用語だけを取り出して渡します
5. 製品の構成の一覧の絞り込み … 分類で関係しそうな製品だけにします
6. ページの向きの確認 … 公式の案内でも、アップロードの前にページの向きを確かめるよう挙げられています。スキャンした公報で横向きのページがあれば直します
7. 前月の処理の残りの確認 … 「要人手」のまま残っている公報があれば、その件数を知財担当へ知らせてから今月の分に入ります。残りに気づかないまま月が替わると、その公報は会議に一度も出ません

3番目を軽く見ないでください。 公開の公報で「対応なし」だった発明が、登録のときに請求項が補正されて、自社製品に近づいていることがあります。 紐付けておけば、登録の公報の行に「公開時からの請求項の変化」を並べて読めます。

AIに処理させる

させるのは、請求項を1項ずつ原文と並べて訳すこと、独立請求項を要素に分けること、要素ごとに自社製品の構成との対応を書き出すことの3つです。

①翻訳

②要素分け

独立請求項を、前提部分と、特徴部分の要素に分けます。要素ごとに原文と訳を並べ、どこで区切ったかを原文の位置で示します。 区切りに迷ったときは、細かく区切る側に倒します。

細かく区切るのは、対応づけを要素ごとに分けるためです。 1-b と 1-c を1つの要素にすると、厚さは自社製品に近いが外部電極の層の数が違う、という区別が消えます。1つの要素に1つの条件を目安にします。

③対応づけ

最後の行がいちばん起きやすい失敗です。 製品名からその製品の一般的な構成を推し量り、一覧に無い要素まで similar にします。対応づけの相手は、一覧に書かれた要素だけです。

指示内容を固定する

①翻訳の指示

あなたは製造業の知財部門で、中国語の特許公報の請求項を日本語に訳す担当です。
添付の公報PDFから、請求項（权利要求书）を取り出し、1項ずつ訳してください。

【用語集（中国語 → 社内の日本語）】{glossary}

【厳守事項】
- 1項を1つの訳にしてください。区切り直したり、まとめたりしないでください。
- 「包括」「包含」は「含む」、「由……组成」は「からなる」と訳し分けてください。
- 数値と単位、範囲の端（以上・以下・超・未満）は原文のとおりにしてください。
- 用語集にある語は、用語集の訳を使ってください。
  用語集に無い技術用語は、訳の後に（原文）を残してください。
- 従属項は、どの項に従属するかを depends_on に書いてください。
- 訳せない箇所、読み取れない箇所は「〔判読不能〕」とし、推測で埋めないでください。
- 要約や解説を書かないでください。

③対応づけの指示

あなたは製造業の知財部門で、競合の特許の独立請求項の要素と、
自社製品の構成の一覧を突き合わせる担当です。

【独立請求項の要素（原文と訳）】{claim_elements}
【自社製品の構成の一覧】{product_features}

【要素ごとに付ける対応（match）】
similar / different / absent / unclear

【厳守事項】
- 対応づけの相手は、一覧に書かれた要素だけにしてください。
  製品名から一般的な構成を推し量らないでください。
- 訳だけでは範囲が決まらないときは unclear にし、
  確認が要る原文の語を check_terms に書いてください。
- 迷ったときに absent を選ばないでください。unclear にしてください。
- 侵害する・しない、権利が有効・無効についての意見を書かないでください。
- reason には、対応づけの根拠にした語を、請求項と一覧の両方から写してください。

「迷ったときに absent を選ばない」を入れるのは、見落としが absent の側に起きるからです。 absent の要素が1つでもあると、その公報は優先度が下がります。下げてよいのは、対応が無いと言い切れるときだけです。

「包括」と「由……组成」の訳し分けを明記しないと、どちらも「含む」や「で構成される」に寄ります。 前者はほかの要素があってもよい書き方、後者はそれだけからなる書き方で、自社製品に要素が1つ多いだけで、対応の結論が逆になります。

出力形式を固定する

次の形のJSONで受け取ります。 Gemini API の構造化出力で match を列挙型にしたスキーマを渡します。公式の案内では、出力がJSONとして正しくても値はアプリケーションの側で検証するようにとされているので、スクリプトで検証します。

{
  "pub_no": "",
  "applicant": "",
  "doc_type": "application | grant",
  "claims": [
    { "no": 1, "depends_on": null, "original": "", "ja": "" }
  ],
  "independent_elements": [
    { "claim_no": 1, "element_id": "1-a", "original": "", "ja": "",
      "match": "similar | different | absent | unclear",
      "product": "", "feature": "", "reason": "", "check_terms": [] }
  ],
  "summary_ja": "",
  "priority": "priority | check | none"
}

1つ目の理由は、match と priority を別の層に置けることです。 match はAIが埋め、priority はスクリプトが規則で決めます。

unclear を similar と同じ側に置いているのが要です。 判断できない要素を、対応しない要素として扱いません。

2つ目は、スクリプトで検証できることです。 claims の項の番号が1から抜けなく続いているか、depends_on が存在する項を指しているか、独立請求項（depends_on が無い項）のすべてに要素があるかを確かめます。項が抜けていれば「要人手」にし、priority を出しません。

3つ目は、original と ja を並べられることです。 確認一覧で原文と訳を左右に並べ、中国語を読める担当者は check_terms の語だけを原文で確かめます。

システムへ連携する

確認一覧は、公報ごとのシートと、要素ごとのシートの2枚にします。 公報ごとのシートで優先度と要約を見て、要素ごとのシートで原文と訳と対応を読みます。要素ごとのシートを製品で絞り込めば、「この製品に関係する今月の要素」を設計部門に見せられます。

人が確認する

1. priority から読む … 原文と訳を並べた独立請求項を読み、範囲を自分で判断します
2. check_terms を確かめてもらう … 中国語を読める担当者に、その語の原文での意味だけを確かめてもらいます
3. none を流し見る … 要約と、absent になった要素を見ます。absent の理由に納得できなければ check に上げます
4. 判断を書く … 公報ごとに「関係なし」「要注意」「要検討」を書き、要素ごとの対応を直したら記録します
5. 用語集を足す … 訳の後に原文が括弧で残った語を、用語集に足します

3番目を省かないでください。 none の公報は件数が多いので読み飛ばしたくなりますが、規則で下げたものを一度は人の目に通すことが、第3章の（d）への答えです。

4番目で対応を直した記録は、製品の構成の一覧を直す材料にします。 absent を similar に直すことが同じ製品で続くなら、一覧にその要素の書き方が足りていません。AIの指示を直す前に、一覧の側を直します。

目標は、120件をならして1件12分です。 priority の公報には30分以上かけ、none の公報は数分で流し見ます。priority が多すぎる月は、製品の構成の一覧が粗いか、用語集が足りていません。

例外に対処する

下から3行目は、分類の付け方の問題です。 公報の分類が自社の製品の分類と合わないのは、競合が自社の想定と違う分野の言い方で出願していることを示すかもしれません。対応づけの結果と一緒に見ます。

記録を残す

• 公報のPDFと、書き出した日・書き出した人
• AIが返したJSONの全文（訳、要素、対応、要約）
• そのとき使った用語集と、製品の構成の一覧の版
• スクリプトが決めた priority と、その理由になった要素
• 人が対応や優先度を直した記録 … どの要素を、どれに変えたか
• 中国語を読める担当者が確かめた語と、その結果
• 会議での判断と、その後の対応（設計の変更の検討、弁理士への相談）

3つ目で用語集と製品の構成の一覧の版を残すのは、どちらも毎月育つからです。 後から「なぜこの要素が absent だったか」を確かめるとき、当時の一覧に何が書かれていたかが分からないと、判断を遡れません。