特許庁の特許情報取得APIで自社と競合の出願の経過をエージェントが毎週見回り、審査請求・拒絶理由・登録など動きのあった案件を知財担当の確認一覧にする

処理の起点を決める

毎週月曜の朝7時に、Schedule Trigger で動かします。 週の始まりに前週分の動きがそろい、知財部の朝の打合せに間に合います。Schedule Trigger は週ごとの間隔と曜日・時・分を指定でき、ワークフローのタイムゾーンが無ければインスタンスのタイムゾーンを使い、セルフホストの既定は America/New_York とされています。ワークフローのタイムゾーンを Asia/Tokyo にします。 保存して公開しないと動きません。

APIのデータは日次で更新され、通常、受付・発送などの手続が行われた日の翌日に取得できるとされています。月曜の朝に取れば、前週の金曜までの手続が入っています。

アクセス数は ID 単位で午前0時から数え、翌日の午前0時にリセットされます。 朝に始めれば、失敗した分をその日のうちに取り直す余裕が残ります。

入力データを集める

質を決めるのは、ウォッチリストの「関係する製品・開発テーマ」の列です。 競合の案件が登録になったとき、誰に知らせるかはこの列で決まります。空のままだと、確認一覧に出ても行き先がありません。

ウォッチリストの出願番号は人が足します。 API一覧にある国内特許情報取得APIは、いずれも出願番号や申請人コードなどを指定して1件の情報を引くもので、出願人を指定して出願の一覧を引くものは一覧にありません。 競合の新しい公開を探すのは、これまでどおり J-PlatPat の検索で行い、見張る番号だけをリストに足します。

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

最初にアクセストークンを取ります。 利用登録の完了後に、特許庁から ID・パスワードと、アクセストークン取得用の URL が電子メールで通知されます。その URL に POST で grant_type=password と ID・パスワードを送ると、access_token と refresh_token が返ります。アクセストークンの有効期限は取得後1時間で、8時間以内ならリフレッシュトークンで取り直せます。

リクエストのヘッダに Authorization: Bearer とアクセストークンを付けます。 出願番号は「西暦4桁＋0埋め6桁」の10桁です。

シンプル版は、特許経過情報から優先権情報と分割情報を除いた簡易版です。 書類の一覧は bibliographyInformation の下の documentList に並び、1件ごとに受付日・発送日（legalDate）、書類名（documentDescription）、書類番号（documentNumber）、書類実体の有無（availabilityFlag）が入ります。前回との比較には書類番号を使います。 書類名で比べると、同じ名前の書類が2通目に出たときに見落とします。

応答の statusCode を必ず見ます。 100 が正常、107 は該当データなし、203 はアクセス上限超過、208 は使えない文字、999 は想定外のエラーです。HTTP の状態が 200 でも、statusCode が 100 でなければデータは空です。 応答には残りのアクセス数（remainAccessCount）も付くので、毎回記録します。

AIへ渡す前に整形する

1. 出願番号の形をそろえる … 「特願2024-012345」のような表記を、10桁の数字に直します。桁が合わないものは取得せず、リストの不備として一覧に出します
2. 対象の範囲を確かめる … 取得できるのは2003年7月以降の特許出願です。それより前の出願はリストで印を付けて外します
3. 前回の書類一覧と比べる … 今回の書類番号の集合から前回の集合を引き、増えた書類だけを残します
4. 書類実体の有無を付ける … availabilityFlag が 0 の書類は本文が取れません。エージェントが取りに行かないよう、増えた書類ごとに有無を添えます
5. 案件の区分を添える … 自社／競合、関係する製品、担当をウォッチリストから付けます
6. 残りのアクセス数を見る … 300件の取得の後の remainAccessCount を見て、追加の取得に回せる数を決めます

3番目で、変化の無い案件はここで落ち、確認一覧にも件数しか出ません。

AIに処理させる

させるのは、増えた書類のある案件1件ごとに、次に取る情報を選んで取りに行き、取ってきた中身を決まった項目に要点としてまとめることです。

優先度は、エージェントにではなく規則に決めさせます。 競合の登録・分割は A、自社の拒絶理由・査定と競合の拒絶理由は B、それ以外は C、のように表で決め、エージェントの出力の event_type と案件の区分からワークフローが付けます。

2行目がいちばん起きやすい失敗です。 拒絶理由通知書の発送日を渡すと、生成AIは応答の期限を計算して書きます。期限は在外者かどうか、延長の請求の有無で変わり、一覧に書かれた日付を担当者がそのまま信じる危険があります。 ここでは発送日だけを書かせ、期限は事務所の報告と案件台帳で見ます。

指示内容を固定する

AI Agent ノードの System Message に、次のように書きます。

あなたは知財部で、見張っている特許出願の経過の変化を調べる担当です。
入力は、1件の出願について、前回から増えた書類の一覧と案件の区分です。

【使える道具】
- get_refusal_reason ..... 拒絶理由通知書の本文（テキスト）を返す
- get_dispatch_document .. 特許査定・拒絶査定・補正の却下の決定の本文を返す
- get_registration_info .. 登録番号・登録日・請求項の数・権利者を返す
- get_cited_documents .... 引用文献の番号と種別を返す
- get_divisional_apps .... 分割出願の番号と状態を返す

【手順】
1. 増えた書類の書類名を見て、必要な道具だけを選んでください。
2. 書類実体が「なし」の書類の本文は取りに行かないでください。
3. 出願審査請求書・手続補正書・意見書は、事実と日付だけを書き、
   道具を使わないでください。
4. 1件あたり道具の呼び出しは4回までにしてください。

【厳守事項】
- 要点は、道具が返した本文と応答だけを根拠に書いてください。
  本文に無い条文・引用文献・請求項の番号を補わないでください。
- 応答の期限を計算しないでください。発送日だけを書いてください。
- 拒絶理由を解消できるか、競合の特許に自社製品が触れるかを
  書かないでください。
- 道具がエラーを返したときは、取得できなかったことを
  fetch_errors に書き、推測で埋めないでください。
- 表に無い書類は event_type を other とし、書類名と日付だけを書いて
  ください。

【案件】{case}
【増えた書類】{new_documents}

「本文に無いものを補わない」を明記しないと、条文を知識で書き足します。 拒絶理由通知書に「29条2項」とあれば、生成AIは「進歩性の欠如」と説明を添え、さらに「36条の記載不備もよく併せて指摘される」と本文に無い条文まで並べることがあります。 確認一覧に載る条文は、本文から写したものだけにします。

「呼び出しは4回まで」は、道具を呼び続ける動きを止めるためです。 Max Iterations（既定10）も小さくします。

出力形式を固定する

Structured Output Parser で、次の形のJSONを返させます。

{
  "application_number": "",
  "side": "own | competitor",
  "event_type": "refusal_reason | decision_grant | decision_refusal | registration | divisional | exam_request | response | other",
  "event_date": "",
  "tools_used": [""],
  "summary": "",
  "refusal_articles": [""],
  "cited_documents": [""],
  "registration": { "number": "", "date": "", "claims": "" },
  "divisional_children": [""],
  "fetch_errors": [""]
}

1つ目の理由は、event_type で優先度と知らせ先を規則で決められることです。 エージェントの言葉の書き方が揺れても、ワークフローは event_type と side だけを見て次の表のとおり振り分けます。

2つ目は、tools_used と fetch_errors で、何を根拠に書いたかが分かることです。 本文を取れずに書類名だけで書いた要点と、本文を読んで書いた要点を、担当者が見分けられます。

3つ目は、divisional_children を別の列に出し、人が足すと決めたものだけをリストに入れられることです。

システムへ連携する

拒絶理由通知書と発送書類は、ZIPファイルで返ります。 中身は書類ごとのXMLで、文字エンコードは SJIS です。同じ出願に拒絶理由通知書が複数あれば、1つのZIPにまとめて返ります。サブワークフローの中で Compression ノードで解凍し、文字コードを UTF-8 に直してから、今回増えた書類番号に当たるXMLだけを選んで本文のテキストをエージェントに返します。過去の通知まで渡すと、古い拒絶理由を今回の動きとして要約します。

Call n8n Workflow Tool は、エージェントが別のワークフローを動かしてその出力を受け取る道具です。 道具ごとに Description を書き、いつ使うかをエージェントに伝えます。入力の出願番号は、$fromAI() でモデルに渡させず、案件の番号を式で固定します。 別の出願の番号を取りに行く誤りを、設定の側で塞ぎます。

案件台帳には書き込みません。 確認一覧と前回の書類一覧のシートに書くところまでです。

人が確認する

1. 優先度 A を先に見る … 競合の登録・特許査定・分割です。登録情報と J-PlatPat で中身を確かめ、関係する製品の開発担当に知らせるかを決めます
2. 自社の拒絶理由・拒絶査定を見る … 事務所の報告が届いているかを確かめます。届いていなければ事務所に問い合わせます
3. 分割の子をウォッチリストに足すかを決める … 足すと決めたものだけを、関係する製品と担当を付けて入れます
4. 要点の誤りを記録する … 条文や引用文献の写し間違いがあれば、どの案件のどの項目かを残します
5. 優先度 C は件数と書類名を流し見る

1番目の判断はAIに寄せません。 競合の特許が自社製品に関係するかは、請求項を読んで知財担当と開発が決めることです。

目標は、1,200件の確認をならして1件0.5分です。

例外に対処する

上の1行目と3行目を「変化なし」として流すと、この構成の意味が無くなります。 取れなかった案件は、取れなかったことが分かる形で必ず残し、前回の書類一覧も更新しません。 更新してしまうと、翌週の比較で増えた書類が消えます。

記録を残す

• 実行ごとの日時、取得した件数、取れなかった案件と statusCode、残りのアクセス数
• 案件ごとの書類番号の集合と取得日（翌週の比較の基準）
• エージェントの出力の全文と、呼んだ道具とその応答の状態
• 人の判断 … 優先度 A の案件を誰に知らせたか、分割の子を足したか、要点の誤りの記録
• 書類の発送日と、確認一覧に載った日の差

最後の行が、この構成の物差しです。 競合の登録日から何日で開発担当に届いたかを並べると、見回りが間に合っているかが分かります。

書類番号の集合を週ごとに残すのは、取得に失敗した週があっても比較をやり直せるようにするためです。