自社特許の請求項と他社製品の公開資料を構成要件ごとに対比したクレームチャートの下書きを作り、根拠の箇所と足りない資料を知財担当に示す

処理の起点を決める

受付の一覧に案件が登録され、担当者が「資料そろった」の印を付けたときに動かします。 依頼が届いた時点ではなく、製品資料が案件のフォルダにそろった時点です。資料が足りないまま動かすと、足りない資料の一覧が「資料をもっと集めて」だけになります。

動かすのは2回に分けます。 1回目は分説の案と用語の説明の候補を作るところまでで、担当者が確定の印を付けると2回目が動きます。2回目は、構成要件の数×資料の数だけ呼び出しがあり、件によっては数十回になります。夜間にまとめて動かし、翌朝に担当者が下書きを見る形にします。

同じ特許で別の製品を対比するときは、確定した分説を使い回します。 分説と用語の説明は特許ごとに一度確定すればよく、2件目からは1回目を飛ばします。

入力データを集める

質を決めるのは、確定した分説の「用語の説明の箇所」です。 特許法第70条第2項は、用語の意義は明細書の記載と図面を考慮して解釈するとしています。明細書で「固定部材とは、ボルト、クリップ、接着剤等を含む」と書かれていれば、製品資料の「クリップで留める」は固定部材の記載として探す必要があります。 用語の説明を渡さないと、AIは言葉の字面で探し、記載を見落とします。

要約書は渡しません。 同条第3項は、技術的範囲を定める際に要約書の記載を考慮してはならないとしています。公報のPDFから要約書の部分を外してから渡します。

Webページは、保存したときの文字とURL・取得日時を1組にします。 製品ページは後から書き換わります。いつの、どのページの記載かが分からない引用は、チャートの根拠として使えません。

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

製品資料はPDFのまま、文書のブロックとして渡します。 PDFは文字と各ページの画像の両方として扱われるので、表や図の中の文字もある程度読めます。 ただし、引用できるのは文字として取り出せた部分だけで、図の中だけに書かれた記載は引用になりません。

Webページは、文字の文書として渡します。 公式の説明では、文字の文書も文単位に分けられ、引用の場所は文字の位置で返ります。PDFに印刷して渡すより、本文を文字で保存して渡すほうが、どの文を引用したかがはっきりします。

同じ製品資料を構成要件の数だけ渡すので、Files API を使えば送る量を減らせます。 公式の説明では、大きなPDFは Files API で上げて file_id で参照できます。ただし、Files API のファイルは削除するか期限が来るまで残り、ゼロデータ保持の対象外とされています（第13章）。案件が終わったら、上げたファイルを消す処理を入れます。

AIへ渡す前に整形する

1. 公報から要約書を外す … 第70条第3項のとおり、技術的範囲の解釈に要約書を使わない
2. 製品資料の文字の有無を確かめる … 文字を取り出せないページが多いPDFは、文字認識をかけてから渡すか、引用の対象外として印を付ける
3. パスワードと暗号化を外す … PDFはパスワードや暗号化の無い標準のものが対象
4. 大きさを確かめる … 1回のリクエストで32MB、ページ数の上限を超える資料は分ける
5. Webページを保存する … 本文の文字、URL、取得日時を1つのファイルにする
6. 資料に番号を振る … 「資料1 カタログ 2026年版」のように、チャートに書く名前を決めて文書の title に入れる
7. 分説を確定する … 1回目の結果を担当者が直し、構成要件ごとに用語の説明の箇所（段落番号）を付ける

2番目を軽く見ないでください。 製品のカタログは、デザインのために本文を画像で作っていることがあります。文字の無いページは引用が返らず、「記載なし」に見えてしまいます。 前処理の段階で、文字の無いページの一覧を作り、チャートの「確認できなかった資料」に載せます。

6番目の名前は、チャートにそのまま出ます。 引用には文書の番号が付いて返るので、番号と名前の対応をプログラムの側で持ち、チャートには名前とページで書きます。

AIに処理させる

させるのは3つの段階に分けた仕事です。

③の区分は4つです。

not_found は「その構成が無い」ではありません。 指示にも、チャートの凡例にも明記します。ここを混ぜると、記載が無いだけの構成要件を、グループ長が「非充足」と読みます。

3行目のために、③では資料そのものを渡しません。 資料を渡すと、AIは引用に無い箇所も読んで区分を決めます。チャートの根拠に出ない理由で区分が決まると、担当者が確かめられません。

指示内容を固定する

②の呼び出し（Citations を有効にした文書を、資料ごとに渡す）の指示です。

あなたは知財部の担当者を補助して、他社製品の公開資料から、
自社特許の構成要件に対応しそうな記載を探します。

【構成要件】{element_id}：{element_text}
【用語の説明（明細書）】{term_notes}

【してほしいこと】
- 渡した資料の中から、この構成要件に対応しそうな記載を探してください。
- 見つけた記載ごとに、その記載が構成要件のどの部分に対応しそうかを1文で書き、
  必ず資料の該当箇所を引用してください。引用の無い説明は書かないでください。
- 用語は、上の「用語の説明」の範囲で読んでください。一般的な意味で広げたり
  狭めたりしないでください。
- 対応する記載が見つからなければ、「見つからない」とだけ書いてください。
  見つからないことを、その構成が製品に無いという意味で書かないでください。

【してはいけないこと】
- 特許を侵害しているか、技術的範囲に入るかを書かない。
- 資料に書かれていない製品の構造や動作を推測で補わない。

③の呼び出し（構造化出力。資料は渡さない）の指示です。

次の構成要件について、【集めた引用】だけを材料に区分を決めてください。
資料そのものは渡していません。引用に無いことを根拠にしないでください。

【構成要件】{element_id}：{element_text}
【用語の説明（明細書）】{term_notes}
【集めた引用】{citations}   ← 資料名・ページ・原文の一覧

【区分】
- described …… 構成要件の全部に対応する記載が引用にある
- partially …… 一部に対応する記載はあるが、残りが引用に無い
- not_found …… 対応する記載が引用に無い
- unclear …… 記載はあるが、用語の解釈によって対応するかが変わる
迷ったときに described を選ばないでください。
not_found は「その構成が無い」という意味ではありません。

【書くこと】
- 区分の理由（どの引用のどの語が、構成要件のどの語に対応するか）
- 担当者が確かめるべき点（用語の解釈の幅、図だけに書かれている可能性など）
- 足りない資料（何を入手・調査すれば確かめられるか。例：現物の分解、通信の解析、
  保守マニュアルの取り寄せ）
侵害の有無、技術的範囲に入るかどうかは書かないでください。

②で「引用の無い説明は書かない」を明記するのは、Citations を有効にしても、引用の付かない文を書くことがあるからです。 引用の無い文はプログラムの側で捨てますが、指示で減らしておくと、捨てる文が少なくなり、チャートの抜けが減ります。

③で「迷ったときに described を選ばない」と書くのは、described がいちばん強い区分だからです。 チャートを読む人は、described の行を見て次の動きを決めます。弱い根拠で described になった行が1つあると、チャート全体の信頼が落ちます。

出力形式を固定する

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

{
  "element_id": "1B",
  "category": "described | partially | not_found | unclear",
  "reason": "",
  "matched_citations": [
    { "doc_title": "", "page": 0, "cited_text": "", "maps_to": "" }
  ],
  "check_points": [""],
  "missing_materials": [
    { "what": "", "why": "", "how": "purchase | teardown | analysis | request_document | other" }
  ]
}

category の値は小文字・大文字を区別せずに比べます。 公式の説明では、構造化出力は列挙の値の大文字・小文字を保証しないとされています。described が Described で返っても同じものとして扱います。

matched_citations は、②で集めた引用の中から選ばせます。 プログラムの側で、cited_text が②の引用の一覧にそのまま存在するかを照らし、無ければその行を捨てて担当者に印を付けます。③のAIが引用の文を書き換えていないかを、機械で確かめます。

チャートの下書きは、次の形の表にします。

表の下に、足りない資料の一覧を付けます。 missing_materials を構成要件をまたいで集め、「現物の分解で確かめられるもの」「保守マニュアルの取り寄せで確かめられるもの」のように、やり方ごとにまとめます。 グループ長は、この一覧で次の動きを決めます。

システムへ連携する

案件管理システムへは、プログラムから書き込みません。 書き込むのは担当者が確かめて直したチャートだけです。下書きが案件の正式な記録に混ざると、後から誰が確かめたものかが分からなくなります。

人が確認する

担当者が全件を確かめます。 引用は仕組みで取っていても、その引用が構成要件に対応しているかは、担当者が読んで判断します。

1. 分説と用語の説明を確定する … 1回目の結果を直す。ここで止めて、確定の印を付けるまで2回目を動かさない
2. 引用を原文のページで確かめる … 出典の資料名とページを開き、前後の文脈を読む。引用だけを読んで判断しない
3. 区分を直す … 特に described の行と unclear の行。not_found の行は、図や写真に書かれていないかを見る
4. 足りない資料の一覧を確かめる … 実際に手に入るか、費用がかかるかを書き足す
5. グループ長に渡す … 区分を直した行と、その理由を残す

2番目の「前後の文脈」が大事です。 引用は文単位で返るので、「〜の場合は」という条件の付いた文の、条件の部分が引用から外れていることがあります。条件付きの記載を無条件の記載として読むと、区分を誤ります。

3番目の図や写真の確認は、引用の仕組みの外です。 図の中だけに書かれた記載は引用されないので、not_found の行こそ、担当者が資料の図を見ます。

例外に対処する

上の2行が、実際にはいちばん多く起きます。 どちらもAIの問題ではなく、資料の集め方の問題です。カタログはWebのPDFを使い、紙のスキャンは最後の手段にします。

記録を残す

• 案件ごとの入力（請求項、確定した分説、資料の一覧とファイルのハッシュ値、Webページの取得日時）
• ②の応答の全文と、引用の一覧（資料名・ページ・原文）
• ③の応答のJSON
• プログラムが捨てた行と、捨てた理由
• 担当者が区分を直した行と、直した理由
• グループ長の判断（分解する、調査を頼む、鑑定に回す、見送る）と日付

ファイルのハッシュ値を残すのは、同じ資料かどうかを後から確かめるためです。 製品資料は版が変わります。チャートを交渉や鑑定に使う段階で、根拠のページが別の版のものだったと分かると、作り直しになります。

5つ目は、指示を直す材料です。 described を partially に直した行が多ければ、③の指示の「迷ったときに described を選ばない」が効いていません。直した理由を月に1回数えて、多いものから指示を直します。