カタログ・製品ページ・取扱説明書の特許表示を毎月の改版のたびに権利台帳と照らし、消滅した特許や対象外の製品への表示を知財部の確認に回す

処理の起点を決める

起点は2つで、動かす頻度を分けます。

改版のほうを毎日にするのは、Webの製品ページが日単位で更新されるからです。 月1回にまとめると、誤った表示が最長1か月公開されたままになります。PDFの掲載物は、制作部門が確認フォルダに置いた翌朝に結果が出ます。

台帳の変化のほうを月1回にするのは、消滅の確定に時間差があるからです。 年金を納めなかった特許は、納付期限の後に追納できる期間が6か月あり、その期間内に納めなければ、特許権は期限の経過の時に遡って消滅したものとみなされます。 放棄の決裁が出た月と、権利が消えたことが確定する月がずれるので、台帳には「追納期間中」の状態を持たせ、消滅が確定した月に起点として拾います。 追納期間中の表示をどう扱うかは、知財部が決めておきます（第7章「人間の確認」）。

入力データを集める

質を決めるのは、型番の対応表です。 権利台帳の対象製品の列は、出願したときの型番で書かれています。後継機の型番が書き足されていないと、正しい表示まで not_covered になります。 シリーズ名で書かれたカタログの表示を型番に戻すのにも、この表を使います。

表記の一覧は、第3章の（d）への手当てです。 AIに渡す指示の中で「次の言い回しも特許表示として拾う」と並べ、掲載物の表記の揺れを1つの形にそろえる入口にします。

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

Webの製品ページは、自社のサイトから取ります。 他社のサイトを取りに行く構成ではありません。HTMLから本文と表の部分だけを残し、ナビゲーションや他製品へのリンクの一覧は落とします。 落とさないと、隣の製品の型番が拾われ、表示がその製品にも掛かっているように見えます。

PDFは Files API に上げてから参照すると、要求の大きさを抑えられます。 総合カタログのように重いものは、ページの範囲で分割してから渡します。公式ページでも、小さな文字のページや込み入った表の多いPDFは、ページ数の上限に届く前にコンテキストを使い切ることがあるとされています。

AIへ渡す前に整形する

1. 形式の確認 … PDFかHTMLかを見て、それ以外（画像だけのファイルなど）はPDFにしてから入れます
2. パスワードの確認 … パスワードや暗号化の掛かったPDFは扱えません。制作部門に外したものを置き直してもらいます
3. 分割 … 100ページを超える掲載物は、章やページの範囲で分けます。分けた範囲は索引に残します
4. HTMLの整理 … 本文と仕様表の部分だけを残し、ナビゲーション・フッター・関連製品の一覧を落とします
5. 前回分の取り出し … 同じ掲載物の前回の判定を索引から出しておき、差分を取る準備をします
6. 台帳の写しを固定 … その回に使う権利台帳を写して日付を付けます。判定の途中で台帳が書き換わっても、結果がぶれないようにします

6番目を飛ばさないでください。 毎月1日は、知財部が前月分の消滅を台帳に入れている最中であることが多く、同じ回の中で前半と後半の判定の根拠が違う台帳になります。

AIに処理させる

させるのは、表示を拾うことと、表示の種類と掛かる型番を判定することの2つです。

2行目の分け方は、法令の書き方に合わせています。 特許法は、特許権者などが物やその包装に特許表示を付けるよう努めるとし、施行規則は、物の特許発明では「特許」の文字と特許番号、物を生産する方法の特許発明では「方法特許」の文字と特許番号を表示とすると定めています。番号の付いていない「特許取得済」は、どの特許かを台帳で確かめられないので、別の種類として拾います。

3行目が、AIに任せる理由です。 第3章の（b）のとおり、1ページに複数の型番が並び、表示は1行だけ、という配置は珍しくありません。レイアウトと文面からどの型番に掛かるかを読み、決められないときは ambiguous と返させます。 無理に全型番へ掛けると、本当は1機種にしか掛からない表示が、残り2機種で not_covered になります。

4行目を明記するのは、AIが親切に書き足すからです。 消滅した特許の表示を見つけると、「虚偽表示に当たるおそれがあります」と付け加えがちです。その一文が一覧に載ると、確認する担当がそれを結論として読みます。 判定の欄に書かせるのは、事実と種類だけにします。

指示内容を固定する

あなたは製造業の知財部で、掲載物に載っている特許表示を拾う担当です。
渡された掲載物（カタログ、取扱説明書、Webの製品ページ）から、
特許表示をすべて拾い、表示の種類と、その表示が掛かっている型番を判定してください。

【拾う言い回し】
次の言い回しを含む表示はすべて拾ってください。
{marking_terms}
（例：特許第、方法特許、PAT.、Patent、特許取得済、特許出願中、出願中）

【表示の種類 marking_type の選び方】
- patent_number ........ 「特許」の文字と番号がある
- method_patent_number . 「方法特許」の文字と番号がある
- pending .............. 出願中である旨の表示
- no_number ............ 特許を取得している旨だが番号が無い
- other ................ 上のどれにも当たらないが、特許に係ると読める言い回し

【掛かる型番 applies_to の決め方】
- 表示と同じ枠・同じ表の行・同じ製品写真の脇にある型番を入れてください。
- ページに複数の型番があり、どれに掛かるか文面とレイアウトから決められない
  ときは、型番を推測で並べず scope を ambiguous にしてください。
- 「全機種」「本シリーズ」などと書かれていれば、その文言を scope_text に写し、
  型番は {model_table} のシリーズの型番を使ってください。

【厳守事項】
- 番号は掲載物に書かれたとおりに quote に写してください。
  桁を補う、区切りを直す、それらしい番号に直すことをしないでください。
- 文字がつぶれて読めない表示は、読めた範囲だけを quote に写し、
  readable を false にしてください。
- 特許が存続しているか、表示が正しいかを書かないでください。
- 虚偽表示に当たるか、表示を外すべきかを書かないでください。
- ナビゲーション、他製品へのリンク、関連製品の一覧にある型番を、
  表示の掛かる型番に入れないでください。
- 表示が1つも無ければ、markings を空の配列にしてください。

【掲載物の情報】{document_meta}
【型番の対応表】{model_table}

「推測で並べず ambiguous に」を書かないと、ページの型番を全部並べます。 並べた型番のうち台帳に無いものが not_covered になり、確認の一覧が誤検知で埋まります。 決められないことを返す選択肢を、はっきり用意します。

番号を写させる指示を、補完を禁じる文と組で書くのも同じ理由です。 掲載物には「特許第123456 7号」のように区切りの崩れた番号が混ざります。AIは直したくなりますが、直すのはプログラムの正規化の仕事で、直した結果も原文と並べて残します。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "document_id": "",
  "document_type": "catalog | manual | web_page",
  "markings": [
    {
      "quote": "",
      "readable": true,
      "marking_type": "patent_number | method_patent_number | pending | no_number | other",
      "page": 0,
      "location": "body | table | margin | photo",
      "scope": "specific | series | ambiguous",
      "scope_text": "",
      "applies_to": [""]
    }
  ]
}

このJSONに、プログラムが3つの欄を足します。 normalized_number（全角・空白・区切りを落とした番号）、ledger_status（台帳での状態）、verdict です。AIの出した欄と、プログラムが足した欄を分けておくと、判定が誤ったときに、どちらの誤りかがすぐ分かります。

引用の照合も、プログラムで行います。 Claude API の構造化出力は、引用の機能（Citations）と組み合わせられません。そこで quote に原文を写させ、PDFやHTMLから取り出した文字列に quote がそのまま含まれるかを確かめます。 含まれないものは、AIが番号を書き換えた疑いがあるので needs_human に回します。

前回の判定との差分も付けます。 同じ掲載物の同じ quote が前回も ok で、台帳の側も変わっていなければ unchanged の印を付け、一覧の下にまとめます。

システムへ連携する

掲載物そのものには書き込みません。 CMSの製品ページを直接書き換える経路は作りません。直すのは制作部門で、知財部は一覧を見て依頼を出すだけです。 書き換えの経路を作ると、誤った判定が公開中のページに直接届きます。

権利台帳も読み取りだけです。 unknown_number が出ても、台帳に番号を書き足しません。台帳の漏れなのか、掲載物の誤りなのかは、知財部が確かめてから決めます。

人が確認する

人が開くのは ok と unchanged 以外のものだけです。 確認の順は次のとおりです。

1. expired を先に見る … 公開中の掲載物に消滅した特許の番号が載っている状態です。Webの製品ページは、その日のうちに制作部門へ連絡します
2. not_covered の型番を確かめる … 多くは台帳の対象製品に後継機が書かれていないだけです。台帳を直すのか、掲載物を直すのかを分けます
3. unknown_number の番号を確かめる … 原文の画像を見て、読み違いか、台帳の漏れか、他社の番号の写し間違いかを確かめます
4. needs_human を読む … 掛かる型番が決められなかったもの、番号の無い表示です
5. 直しの依頼を送る … 掲載物・ページ・原文・台帳の状態を並べた依頼を、制作部門に送ります

追納期間中の特許の扱いを、先に決めておきます。 年金を納めなかった特許は、追納期間の6か月が過ぎるまで消滅が確定しません。この間の表示を外すか残すかは知財部の方針で、AIにも規則にも決めさせません。 規則の側では「追納期間中」を needs_human に回すだけにします。

目標は、60件をならして1件8分です。 ok と unchanged の掲載物は一覧で件数を見るだけで済み、時間を使うのは expired と not_covered の件です。

例外に対処する

4行目は件数が少なくても見落とさないでください。 製品写真に写った銘板の番号は、掲載物の本文を直しても残ります。写真を差し替えないと直らない表示です。

記録を残す

• その回の掲載物のファイルと、Webの製品ページのHTMLの写し（取得日時付き）
• その回に使った権利台帳の写しと日付
• Claude API に渡した指示と、返ってきたJSONの全文
• プログラムが足した欄（正規化した番号、台帳での状態、verdict）
• 人が判定を覆した記録 … どの表示を、どの判定に変えたか、理由
• 制作部門へ依頼した日と、直った版を確かめた日

2つ目の台帳の写しを残すのは、後から「その時点で消滅を知っていたか」を問われるためです。 判定の根拠が当時の台帳だったことが残っていれば、いつ気づき、いつ直したかを説明できます。

最後の行は、直るまでの日数を数えるためです。 依頼を出しても直らない掲載物は、制作部門の側の手順に理由があります。