他社の製品カタログ・仕様書を集めた社内のアーカイブを、自社特許の請求項の構成要件で毎月検索し、侵害の疑いのある製品の候補と対比表の下書きを知財担当へ出す

処理の起点を決める

月末の定時実行で動かします。 その月に共有フォルダへ入った資料を対象にします。資料が入るたびに動かさないのは、同じ製品の資料が数日に分けて入ることが多いからです。 カタログが先に入り、仕様書が後から入ると、1件ずつ照らしても構成要件がそろいません。製品ごとにまとめて照らすため、月の締めで動かします。

監視対象の特許を足したときは、臨時で過去の資料にもさかのぼって動かします。 新しく監視に入れた特許については、アーカイブの過去2年分の資料を対象にします。新しい特許を監視に入れた月だけ、件数が大きく増えます。

資料の登録の時点で、製品名とメーカーを必ず入れてもらいます。 製品ごとに構成要件を数えるので、製品が特定できない資料は候補の集計に入れられません。

入力データを集める

質を決めるのは、4行目の検索の言葉です。 構成要件の文言は抽象的で、そのままではカタログの言葉に当たりません。明細書の実施例に書かれた具体的な部品名や、業界で使われる呼び方を、構成要件ごとに数語ずつ足します。 「付勢手段」なら「ばね」「コイルスプリング」「板ばね」「弾性部材」。特許法第70条第2項が、用語の意義は明細書の記載と図面を考慮して解釈するとしているのと同じ考え方で、言葉を足す根拠は明細書に置きます。

最後の行の対照の資料は、しきい値を決めるために使います。 自社の実施品は、その特許の構成要件をすべて備えているはずです。自社のカタログで全部の構成要件に記載が当たらなければ、検索の言葉か、しきい値が足りていません。

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

本文は、PDFの文字の層から取り出します。 画像だけのPDF（スキャンしたカタログ）は文字の層が無いため、取り出した文字数が極端に少ない資料に印を付けて、知財担当の一覧に出します。 保存したWebページは、本文の部分だけを取り出します。

ページごとに分けて索引に入れます。 カタログの1ページは、1つの機能や1つの部位の説明になっていることが多く、ページ番号を残しておけば、対比表の引用からすぐ元のページを開けます。 1ページの文字数が多い仕様書は、見出しで分けます。

索引の1件は、次の形にします。

{
  "doc_id": "2026-09-0142",
  "page": 7,
  "product_key": "メーカーX/型番ABC-200",
  "maker": "メーカーX",
  "doc_type": "catalog | spec | manual | web",
  "language": "ja | en",
  "acquired_month": "2026-09",
  "text": "（ページの本文）",
  "text_vector": [0.0]
}

検索は、構成要件1つにつき1回です。 構成要件の文言と検索の言葉を語の一致の句に、構成要件の文言の埋め込みを意味の近さの句に入れ、filter に acquired_month と language を入れます。 英語の資料には、英語の検索の言葉で別に検索します。

{
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "text": "付勢手段 ばね コイルスプリング 板ばね 弾性部材" } },
        { "knn": { "text_vector": { "vector": [0.0], "k": 50 } } }
      ],
      "filter": { "bool": { "filter": [
        { "term": { "acquired_month": "2026-09" } },
        { "term": { "language": "ja" } }
      ] } }
    }
  }
}

句は2つだけにしています。 上限は5つですが、構成要件ごとに句の数が違うと、構成要件のあいだでスコアを比べにくくなり、しきい値をそろえられません。 検索の言葉は1つの句にまとめ、意味の近さの句と2つで組みます。filter は全部の句にかかるので、月と言語の絞り込みを句ごとに書く必要はありません。

AIへ渡す前に整形する

1. 登録情報の確認 … 製品名とメーカーが無い資料は、集計から外して担当者に戻します
2. 重複の除去 … 同じ資料が別の担当から二重に入っていれば、ファイルのハッシュ値で1つにします
3. 本文の取り出しと文字数の確認 … 文字の層が無い資料に印を付けます
4. ページの分割 … ページごと、長いページは見出しごとに分けます
5. 言語の判定 … ページごとに日本語か英語かを決め、language に入れます
6. 埋め込みの作成 … ページの本文の埋め込みを作ります
7. 構成要件の埋め込みの作成 … 40件の特許の構成要件の文言の埋め込みは、分説を変えたときだけ作り直します

3番目の印を見落とさないでください。 画像だけのカタログは、検索に1度も当たらないので、候補にもならず、問題があることにも気づけません。 印の付いた資料は、文字を読み取ってから入れ直すか、知財担当が目で見るかを決めます。

AIに処理させる

検索と候補の決定は、生成AIを使わずに行います。 構成要件ごとの検索の結果を、ワークフローが製品ごとにまとめ、記載が当たった構成要件の数を数えます。

「1つを除いて」を候補に入れるのは、カタログに内部の構造が書かれないからです。 外から見える構成要件はすべて当たり、内部の1つだけが書かれていない製品は、現物を調べる価値があるかもしれません。

生成AIにさせるのは、候補の製品について、構成要件ごとに記載の状況を整理した対比表の下書きを作ることです。

3行目が、いちばん起きやすい失敗です。 「制御部が〜を判定する」という構成要件に、カタログに「自動制御」とだけ書かれていると、一般的な製品の作りから推して described にします。 何を判定しているかが書かれていなければ unclear です。

指示内容を固定する

あなたは製造業の知財部門で、他社製品の監視を手伝います。
自社特許の請求項の構成要件と、他社の製品資料の該当しそうなページを渡します。
構成要件ごとに、資料にどう書かれているかを整理した対比表の下書きを作ってください。

【status の選び方】
- described .. 構成要件に当たりうる具体的な記載が、資料の本文にある
- not_found .. 渡したページに、この構成要件に関係する記載が無い
- unclear .... 関係する記載はあるが、構成要件に当たるかを資料からは決められない
迷ったときに described を選ばないでください。

【厳守事項】
- 判断の根拠は、渡した資料のページの本文だけにしてください。
  この種の製品の一般的な作りや、あなたの知識で補わないでください。
- quote には、資料の本文の文字列をそのまま写してください。
  要約、言い換え、翻訳をしないでください。
- 「侵害する」「技術的範囲に属する」「抵触する」と書かないでください。
  結論は書かず、記載の状況だけを書いてください。
- 文言が違うが同じ働きをする、という理由で described にしないでください。
  その場合は unclear にし、note に違いを書いてください。
- not_found と unclear のときは、to_verify に、現物や追加の資料で
  何を確かめればよいかを書いてください。
- 資料の書き手（メーカー）を批判する表現を書かないでください。

【特許】{patent_no} 請求項{claim_no}
【構成要件】{elements}（記号、文言、検索の言葉）
【製品】{product_key}
【検索で当たったページ】{hits}（資料番号、ページ、本文、どの構成要件の検索で当たったか）

「同じ働きをする、という理由で described にしない」を明記しています。 書かないと、構成要件の「ばね」とカタログの「ゴム製の緩衝材」を、働きが同じだからと described にします。文言の違うものをどう扱うかは、専門家が検討することです。 下書きの段階では、違いがあることを見せるところで止めます。

「侵害する」などの語を名指しで禁じているのは、この表が社内で回るからです。 下書きに結論めいた言葉があると、検討の前に結論が独り歩きします。

出力形式を固定する

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

{
  "patent_no": "",
  "claim_no": 1,
  "product_key": "",
  "elements": [
    { "element": "A",
      "status": "described | not_found | unclear",
      "quote": "",
      "doc_id": "",
      "page": 0,
      "note": "",
      "to_verify": "" }
  ],
  "summary_counts": { "described": 0, "not_found": 0, "unclear": 0 },
  "materials_needed": []
}

1つ目の理由は、elements をそのまま対比表の行にできることです。 構成要件の記号、文言、資料の記載、ページを並べれば、会議に出す表の形になります。知財担当は一から書かず、下書きを直すところから始められます。

2つ目は、quote と doc_id・page を機械で検査できることです。 ワークフローが、quote の文字列がその資料のそのページの本文に実際に含まれているかを確かめます。含まれていなければ、その行の status を unclear に書き換え、「引用を確認できない」と記録します。要約や言い換えが混ざった引用を、そのまま表に載せないためです。

3つ目は、status が enum で決まっていることです。 構造化出力では enum が使え、決めた3つ以外の値は返りません。 「おおむね該当」のような中間の言葉が表に入ることがありません。

4つ目は、materials_needed で次の調査をまとめられることです。 現物の入手、取扱説明書の追加の入手、分解の調査など、会議で決めるべき次の手が1か所に集まります。

システムへ連携する

特許管理システムには書き込みません。 候補と対比表は、知財部門だけが見られる場所に置きます。権利活用の検討の記録は、特許管理システムの案件とは分けて管理します。

しきい値は、対照の資料で決めます。 自社の実施品のカタログを、監視対象の特許ごとに検索させ、全構成要件に当たるときのスコアの分布を見ます。そのうえで、他社の資料で「当たった」とみなす値を決めます。しきい値を低くすると候補が増えて知財担当の確認が重くなり、高くすると見逃しが増えます。 最初の3か月は低めにして、候補の中で知財担当が「関係なし」とした割合を見ながら上げていきます。

人が確認する

知財担当は、候補になった製品の対比表の下書きを開き、資料の該当ページを見て確かめます。

1. 優先度が高い候補を先に見る … すべての構成要件に記載が当たった製品です
2. 該当ページを開く … 引用の前後を読み、構成要件に当たる記載なのか、言葉が似ているだけなのかを確かめます
3. unclear と not_found を見る … 何を確かめれば決められるか（to_verify）を読み、現物の入手や追加の資料が要るかを決めます
4. 会議に出すかを決める … 出すものは、下書きを直して対比表にします
5. 関係なしとしたものに理由を残す … しきい値と検索の言葉の見直しに使います

2番目を省かないでください。 構成要件ごとの検索は、言葉が似ているページを拾います。「制御部」の検索で、制御盤の外形の寸法のページが当たることもあります。

目標は、300件をならして1件6分です。 候補にならなかった資料は一覧で数秒、候補になった製品は対比表と該当ページを見るので数十分かかります。

例外に対処する

6行目で照合の結果を使わないのは、見逃しを見逃しと気づけないからです。 自社の実施品で当たらない検索は、他社の同じ構成の製品でも当たりません。 その特許については、検索の言葉を直すまで、知財担当が従来どおり資料を見ます。

記録を残す

• 月ごとの資料の一覧と、登録情報、本文の取り出しの結果
• 構成要件ごとの検索の条件（検索の言葉、しきい値）と、当たったページとスコア
• 製品ごとの当たった構成要件の数と、候補の判定
• 対比表の下書きの全文と、引用の検査の結果
• 知財担当の判定（会議に出したか、関係なしとしたか、その理由）
• 構成要件の分説と検索の言葉の変更の履歴
• 対照の資料での検索の結果（特許ごと、月ごと）

2つ目で検索の条件を残すのは、後で「なぜこの製品は候補にならなかったか」を説明するためです。 何年か後に、ある製品が権利の対象になりうると分かったとき、当時の検索の言葉としきい値が残っていれば、見逃した理由を確かめられます。

最後の行は、検索の質の記録です。 対照の資料で当たらなくなった月があれば、構成要件の分説か検索の言葉の変更が原因です。