出願前の特許明細書で、図面の符号と用語の食い違いを点検する

処理の起点を決める

担当者が点検用フォルダにファイルを置いたことを起点にします。届いたメールから自動で始めない理由は2つあります。

1つは、事務所からのメールには明細書案だけでなく、中間処理の案内や請求書も混ざるためです。もう1つは、点検したいタイミングが担当者によって決まるためです。発明者の確認が先に必要な案件もあれば、すぐに見たい案件もあります。自動で始めると、確認待ちのものまで処理してしまいます。

月15件、1日1件以下の頻度なので、手で置く手間は無視できます。

入力データを集める

3つ目の用語集がないなら、この構成を作る前に作ってください。 用語集がないと「押圧部材と加圧部材のどちらが正しいか」を機械が決められず、指摘が「どちらかに統一してください」で止まります。それでも価値はありますが、半分です。

用語集は大きなものでなくてかまいません。直近1年の出願に出てきた部材名を並べて、正式な語に印を付けるだけで始められます。

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

本文のテキスト化： Word形式で届くなら、そのまま段落単位で読み取ります。PDFで届く場合は、テキスト情報を持つPDFかどうかを先に確かめます。事務所が作成した明細書案は、ほぼテキスト情報を持っています。スキャンされた画像PDFの場合は、この構成の対象外として人が読みます。

章の切り分け： 明細書は「【特許請求の範囲】」「【発明の詳細な説明】」「【符号の説明】」のように、見出しが決まった書式で入ります。この見出しで切り分けます。書式が決まっているので、ここは正規表現で足ります。

符号の抽出： 「語＋半角数字」または「語＋全角数字」の並びを拾います。数字は1〜3桁、語は直前の連続した日本語の文字列とします。拾った組を「符号ごと」と「語ごと」の2通りで集計します。

図面の符号： 【符号の説明】の欄に「12 押圧部材」の形で並んでいます。ここが図面側の正解になります。本文で使われている符号のうち、この欄にないものが「図面にない符号」です。

AIへ渡す前に整形する

1. 表記の正規化 … 全角数字を半角にそろえます。「第1実施形態」のような、符号ではない数字を除きます。除き方は「直前の語が『第』『図』『請求項』のいずれかなら符号ではない」という単純なルールで足ります
2. 符号の説明の欄を正解として持つ … 本文の照合はすべてこの欄を基準にします
3. 括弧書きの扱い … 「押圧部材（12）」と「押圧部材12」を同じ組として扱います
4. 請求項の語の切り出し … 請求項は一文が長いので、「〜と、」「〜であって、」で区切って構成要素ごとに分けます。ここは機械的に切って、後でAIに整えさせます

AIに処理させる

正規表現とAIで役割を分けます。

正規表現にさせること： 符号と語の組の抽出、符号の説明の欄との突き合わせ、同じ符号に複数の語が付いている箇所の列挙。ここは漏れなく拾うことが大事で、判断は要りません。

AIにさせること：

AIに「正しい符号はこれです」と決めさせません。 AIが出すのは「この2つは同じものを指している可能性が高い」という候補と、その根拠になる本文の該当箇所です。決めるのは人です。

指示内容を固定する

あなたは特許出願の明細書を点検する知財担当者を支援する立場です。
以下の「符号と語の組」の一覧と、明細書の該当段落を読み、
同じ符号に付いている複数の語が、同じ部材を指しているかを判断してください。

【厳守事項】
- 本文を書き換えないでください。指摘だけを返してください。
- 「同じ部材を指している」と判断する場合は、その根拠になる
  本文の文をそのまま evidence に入れてください。要約しないでください。
- 意図的に区別されている可能性がある場合（上位概念と下位概念、
  実施形態ごとの呼び分けなど）は judgment を "intentional" にし、
  なぜそう考えたかを reason に書いてください。
- 判断がつかない場合は "unknown" を返してください。
  推測で "same" を返さないでください。
- 社内用語集にある語を優先してください。用語集にない語を
  正式名として提案しないでください。

【符号と語の組】
{symbol_pairs}

【該当する段落】
{paragraphs}

【社内用語集】
{glossary}

「推測で same を返さない」の1行が要です。 ここを書かないと、AIは親切に「おそらく同じでしょう」と答えます。特許の明細書では、上位概念と下位概念をわざと書き分けていることがあります。それを「ゆれ」として直すと、権利範囲が変わります。

本文を書き換えさせないことも重要です。 明細書の文章を直す権限は、この構成にはありません。直すのは事務所であり、直すかどうかを決めるのは担当者と発明者です。

出力形式を固定する

構造化出力を使い、決めた形のJSONで受け取ります。OpenAI の Structured Outputs では、text: { format: { type: "json_schema", "strict": true, "schema": … } } の形でスキーマを渡します。スキーマには "additionalProperties": false を使い、"required" に全プロパティを列挙する必要があります。

{
  "findings": [
    {
      "type": "symbol_multiple_terms",
      "symbol": "12",
      "terms": ["押圧部材", "加圧部材"],
      "judgment": "same | intentional | unknown",
      "recommended_term": "",
      "evidence": [
        { "page": 0, "paragraph_no": "0012", "text": "" }
      ],
      "reason": "",
      "confidence": "high | medium | low"
    }
  ],
  "claim_support": [
    {
      "claim_no": 1,
      "element": "",
      "found_in": ["0018", "0021"],
      "status": "supported | not_found | partial"
    }
  ],
  "unmatched_symbols": [],
  "needs_human_review": []
}

evidence を必ず返させるのが確認を速くする鍵です。指摘だけ並べられても、結局本文を探しに行くことになります。該当文がそのまま付いていれば、一覧を見るだけで判断できます。

安全上の理由でモデルが応答を拒否した場合、応答に "type": "refusal" が含まれます。スキーマ外の応答になるため、後段で検出して人へ回す分岐を作ります。

システムへ連携する

この構成は、既存システムと深くつなぎません。つなぐのは次の2か所だけです。

知財管理システムとのAPI連携は、最初は作らないでください。 月15件なら、結果ファイルの名前に整理番号を入れるだけで運用できます。連携を作るとその保守が発生し、この構成の軽さが失われます。

出力は、担当者がそのまま見られる形（Excelまたは画面）と、事務所へ送る文面の2つを作ります。事務所への依頼は「第0012段落 『加圧部材12』を『押圧部材12』へ統一してください」のように、箇所と直し方が一意に決まる形にします。

人が確認する

全件、人が確認します。自動で修正を送る構成にはしません。

理由は、指摘が正しいかどうかが権利範囲に影響するためです。「ゆれ」に見えるものが意図的な書き分けだった場合、統一すると発明の内容が変わります。出願後に直すことはできません。

確認を速くするための設計が重要です。

• 指摘を種類ごとにまとめて並べる（符号の問題、用語の問題、請求項の問題）
• confidence が低いもの、judgment が unknown のものを上に出す
• evidence の本文を一覧の中に展開しておく（別のファイルを開かせない）
• 前回の点検で「直さない」と判断した指摘を、今回は下に送る

最後の項目が効きます。同じ案件を2回3回と点検するので、一度判断したものが毎回同じ位置に出てくると、確認の時間が減りません。

例外に対処する

記録を残す

• 点検した明細書案のファイル名とバージョン
• 抽出した符号と語の組（生の状態）
• AIが返した判断と evidence
• 人がどう判断したか（採用・不採用・保留）と、その理由
• 事務所へ送った修正依頼の内容

3つ目と4つ目を並べて残すことに意味があります。「AIがsameと判断したが人が不採用にした」件が積み上がると、それが用語集に足すべき情報になります。 半年分たまれば、指摘の精度は自然に上がります。

未公開の発明情報を含むため、保存場所は知財部門に限定し、保存期間は自社の文書管理規程に合わせます。