特許の中間処理で作った補正案の各箇所について、出願当初の明細書・図面のどこに根拠があるかを対応表にし、根拠が見つからない箇所を弁理士の確認に回す

処理の起点を決める

案件フォルダの「補正案」サブフォルダにファイルが保存されたことを起点にします。 補正案は特許事務所から届いた順に処理し、1日1回にまとめません。応答期限まで日数がない案件ほど、照会の往復に時間を残したいからです。

動かすのは、補正書案と意見書案の両方がそろったときだけです。 片方だけで動かすと、意見書案の根拠欄との照合（After の8番目）ができません。ファイル名の決まり（整理番号_補正書案_v1.docx のような形）を特許事務所と取り決め、同じ整理番号の2つがそろった時点で1件として扱います。 版が上がったもの（v2）が届いたら、前の版の結果は残したまま、もう一度最初から動かします。

入力データを集める

いちばん間違えやすいのは3行目です。 根拠を探す先は出願当初の明細書等で、前回の補正で書き換わった後の明細書ではありません。最新の版を引くと、前回の補正で足した文言が「根拠あり」と出ます。取り出すのは出願日に提出したファイルに限り、取り出したファイルのハッシュ値を記録します。

4行目の直前の請求項は、差分を取るために使います。 補正前として比べるのは、当初の請求項ではなく、今回の補正の直前の請求項です。差分の元と根拠の探し先は、別のファイルです。

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

当初明細書は、出願時の電子データから文字で取ります。 公式ドキュメントによると、文字を取り出せないスキャンのPDFは引用できません（画像からの引用は未対応）。出願時のデータがスキャン画像しか残っていない案件は、この構成の対象から外します。

図面だけは別の扱いです。 PDFを渡すとページごとに文字と画像の両方が渡り、図や表も読めます。ただし画像からの引用は返りません。 図面に根拠があるかどうかは、引用の照合ができない候補として扱います。

AIへ渡す前に整形する

1. 出願の種類の確認 … 外国語の書面で出願した案件と国際出願から移行した案件は、どの書面を当初明細書等として読むかを弁理士が決めるため、処理せずに担当者へ戻します
2. 当初明細書の段落分け … 【0001】のような段落番号ごとに1つのかたまりにします。特許請求の範囲は請求項ごと、図面の簡単な説明は図ごとに1つのかたまりにし、かたまりの番号と段落番号の対応表を手元に持ちます
3. 表の展開 … 実施例の表は、行ごとに「表1・実施例3・温度・24℃」のような文に直してかたまりに入れます。表のままだと、数値の境界値が検索から外れます
4. 補正前後の差分 … 直前の請求項と補正後の請求項を、請求項ごとに文字単位で比べます。追加された文言、削除された文言、変更された引用関係を取り出します
5. 補正単位への分割 … 追加された文言を「意味のかたまり」ごとに分けます。1つの請求項に3か所の追加があれば、3つの補正単位です。削除だけの補正も単位として残し、区分は deletion にします
6. 数値の取り出し … 補正単位の中の数値と単位、範囲の上限・下限を取り出します。全角と半角、「〜」「～」「-」の表記をそろえます
7. 除くクレームの検知 … 「（ただし、〜を除く。）」の形の補正は exclusion の印を付けます。審査基準が別に考え方を示している類型なので、根拠の検索はしても、区分は必ず弁理士確認にします

2番目と3番目がこの構成の質を決めます。 かたまりの切り方が、そのまま引用の単位になります。段落より細かく切ると番号の対応が崩れ、粗く切ると「どこに書かれているか」がぼやけます。

AIに処理させる

1回目（引用機能あり）でさせるのは、補正単位ごとに、根拠の候補となる記載を当初明細書から引用することだけです。

2回目（構造化出力）でさせるのは、照合を終えた引用を見て、区分を1つ付けることです。

2行目がいちばん起きやすい失敗です。 根拠が見つからないとき、AIは「当業者にとって自明」と書いて埋めようとします。その一文で、弁理士に回るはずの箇所が対応表から消えます。

指示内容を固定する

1回目（引用機能あり）の指示です。当初明細書はカスタムコンテンツ文書として、この指示の前に渡します。

あなたは特許の中間処理で、補正の根拠となる記載を探す担当です。
渡した文書は、出願当初の明細書・特許請求の範囲・図面の簡単な説明を
段落ごとに区切ったものです。この文書だけを根拠にしてください。

【補正単位】{amendment_unit}
  補正の種類：{change_type}（追加／変更）
  補正後の文言：{added_text}
  補正前の文言：{before_text}

【探し方】
1. 補正後の文言と同じ語句が書かれた段落を探し、引用してください。
2. 同じ語句がなければ、同じものを指すと読める別の語句の段落を探し、
   引用してください。そのとき「言い換えの候補」と書いてください。
3. 1つの段落で足りないときは、合わせて読む段落をすべて引用し、
   「組み合わせ」と書いてください。
4. 候補がなければ「候補なし」とだけ書き、引用を付けないでください。

【厳守事項】
- 引用は文書の中の記載だけにしてください。文書にない内容を、
  技術常識や一般的な知識から補わないでください。
- 「自明である」「当業者であれば理解できる」と評価しないでください。
- 新規事項に当たるか、補正が許されるかを書かないでください。
- 補正の文言を直す提案をしないでください。
- 数値は、補正後の範囲の上限と下限のそれぞれについて、
  その数値が書かれた記載を探してください。範囲の中に入る
  別の数値の記載は、境界値の根拠として扱わないでください。

2回目（構造化出力）の指示です。

次の補正単位について、根拠の候補の照合結果を読み、区分を1つ選んでください。

【補正単位】{amendment_unit}
【1回目の回答と引用（照合済み）】{verified_citations}
【数値の境界値の照合結果】{numeric_check}
【意見書案の根拠欄】{stated_basis}

【区分の選び方】
- explicit ...... 補正の文言と同じ語句が1つの段落にあり、照合が一致した
- paraphrase .... 別の語句の段落しかない
- combined ...... 複数の段落を合わせる必要がある
- drawing_only .. 文章に候補がなく、図面に候補がある
- numeric_check . 数値の範囲の補正（照合結果にかかわらずこれを選ぶ）
- not_found ..... 候補がない、または引用が照合で一致しなかった
迷ったときに explicit を選ばないでください。
照合で一致しなかった引用は、なかったものとして扱ってください。
reason には、区分を選んだ理由を事実だけで1文で書いてください。

「迷ったときに explicit を選ばない」を明記しないと、言い換えが explicit に寄ります。 explicit は対応表で流し見される区分なので、ここに紛れた1件は誰にも見られずに提出されます。

出力形式を固定する

2回目の出力は、次の形のJSONで受け取ります。

{
  "case_id": "",
  "amendment_units": [
    {
      "unit_id": "C1-02",
      "location": "claim_1",
      "change_type": "addition | change | deletion",
      "added_text": "",
      "category": "explicit | paraphrase | combined | drawing_only | numeric_check | not_found | deletion | exclusion",
      "basis": [
        { "paragraph": "0023", "cited_text": "", "match": "exact | partial | none" }
      ],
      "numeric": { "lower": "", "upper": "", "lower_found": false, "upper_found": false },
      "stated_basis": ["0023"],
      "stated_basis_check": "agree | differs | not_stated",
      "reason": ""
    }
  ]
}

1つ目の理由は、区分と照合結果を別の欄に置けることです。 category はAIが付け、basis の match と numeric の結果はコードが入れます。AIが explicit と付けても、match が exact でなければ、対応表では弁理士確認に回します。 判断の最後をコードの側に置きます。

2つ目は、意見書案の根拠欄と並べられることです。 stated_basis_check が differs の行は、特許事務所が別の段落を書いてきたか、こちらの切り方がずれています。どちらであっても、提出前に確かめるべき行です。

構造化出力では、スキーマのすべてのオブジェクトに additionalProperties: false を付けます。公式ドキュメントは、文字列の長さや数値の範囲の制約がスキーマで使えないとしているため、段落番号の形（4桁）の確認はコードで行います。

システムへ連携する

特許事務所へは、自動では何も送りません。 照会するかどうか、どう書くかは担当者が決めます。対応表をそのまま転送する運用もしません。 区分の名前は社内の取り決めで、特許事務所にとっては説明のない符号です。

人が確認する

担当者が見るのは、explicit 以外の行です。 explicit で match が exact の行は、引用の文字列を一覧で流し見て終わりにします。

1. not_found と exclusion を先に見る … 弁理士の判断がいちばん要る行です。照会の文面に、どの補正単位かと、見つからなかった事実を書きます
2. paraphrase と combined を読む … 引用された段落を開き、言い換えとして読めるかを確かめます。読めると考えても、判断は弁理士に任せ、照会に含めます
3. numeric_check の境界値を見る … 上限と下限のそれぞれが書かれているか、補正後の範囲が当初の範囲に入っているかを確かめます
4. differs の行を見る … 意見書案の段落番号が違う理由を確かめ、特許事務所に伝えます
5. 判定を覆したら記録する … どの補正単位を、どの区分に変えたかを残します

2番目で担当者が結論を出さないことが大事です。 言い換えとして読めるかどうかは、審査基準のいう「自明な事項」の判断そのものに近く、知財部の担当者が引き受けてよい判断ではありません。

目標は、40件をならして1件30分です。 補正単位のうち explicit 以外が3割前後という想定です。それより多い月は、かたまりの切り方が粗いか、特許事務所の補正の書き方が変わっています。 事務所ごとに explicit の割合を数えておくと、どちらが原因かが分かります。

例外に対処する

上から2行がいちばん重い例外です。 どちらも、根拠を探す先を取り違える失敗です。代わりのファイルで動かせば結果は出ますが、その結果は誤りです。

記録を残す

• 補正書案・意見書案の版と、受け取った日時
• 使った当初明細書等のファイル名とハッシュ値
• 補正単位の一覧と、差分の結果
• 1回目の回答と引用の全文、照合の結果（match）
• 2回目のJSON（区分と理由）
• 担当者が区分を覆した記録と、弁理士への照会と回答の日付
• 最終的に提出した補正書との対応（どの補正単位が直されたか）

2つ目のハッシュ値は、後から「どの明細書と照らしたか」を示すためです。 補正の適否が審査で争われたとき、当時の確認が当初明細書と照らしたものだったことを示せます。

最後の行は、プロンプトと前処理を直す材料になります。 paraphrase と付いたのに弁理士が「明示的な記載あり」と判断した行が多ければ、かたまりの切り方か表の展開に原因があります。