納付期限が来る特許を、事業での使用状況と照らして維持と放棄の判断材料を作る

処理の起点を決める

毎月1日のスケジュール実行で動かします。抽出するのは「翌々月に納付期限が来る権利」です。

翌月ではなく翌々月にするのは、事業部への照会に往復2〜3週間かかるためです。期限の1か月前に検討を始めると、返事待ちのまま期限が来ます。 追納期間（納付期限の経過後6か月）に割増を払って延命する運用は、費用がかかるうえに管理が複雑になるので、最初から避ける設計にします。

入力データを集める

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

権利一覧： 知財管理システムからCSVで書き出すか、APIで取得します。次回納付期限と請求項数の2つが正しく取れることを最初に確認してください。 ここが違うと、あとの計算がすべて狂います。

公報： 特許番号から本文を取得します。社内に公報のアーカイブがあればそれを使い、なければ特許情報プラットフォーム（J-PlatPat）で個別に確認します。大量に自動取得する場合は、利用条件を必ず確認してください。

製品仕様書： 全文をそのまま生成AIに渡すと量が多すぎます。製品名・構造・採用技術を抜いた索引を先に作り、検索基盤に入れておきます。特許の請求項から検索して、近い製品だけを取り出して渡します。

料金表： 特許庁の産業財産権関係料金一覧から、年次の区分ごとの単価を持ちます。令和7年4月1日時点では、第1年から第3年までが年4,300円に1請求項あたり300円、第4年から第6年までが年10,300円に1請求項あたり800円です。年次が進むほど単価が上がるため、古い権利ほど維持費が重くなります。 単価は改定されるため、料金表を年1回は見直してください。

AIへ渡す前に整形する

1. 対象の絞り込み … 第4年分以降の年金納付対象だけを抜きます。設定登録時にまとめて納めた分は対象外です
2. 請求項数の確認 … 訂正や一部放棄で請求項数が変わっていることがあります。最新の数を使います
3. 存続期間の確認 … 出願日から20年の満了が近い権利は、そもそも判断が不要です。残存年数を計算して先に外します
4. 製品索引の更新 … 製品仕様書の索引は月1回の更新で足ります。毎回作り直す必要はありません

AIに処理させる

計算と生成AIで役割を分けます。

計算（Python）にさせること： 年金額、残存年数、これまでに払った累計額、満了までに払う見込み額。金額の計算は生成AIにさせません。 請求項数の掛け算を間違えると、判断そのものが変わります。

生成AIにさせること：

指示内容を固定する

あなたは知財部を支援する担当者です。
納付期限が来る特許について、維持と放棄を検討するための表を作ってください。

【厳守事項】
- 金額と年数は、渡された計算結果をそのまま使ってください。
  自分で計算しないでください。
- 「この特許は製品Aに実施されている」と断定しないでください。
  請求項と製品仕様が一致しているかは事業部が判断します。
  「製品Aに関連する可能性がある。確認が必要」と書いてください。
- 維持の理由と放棄の理由を、必ず両方書いてください。
  どちらか一方しか書けない場合は、その旨を理由に書いてください。
- 他社の特許や訴訟の状況について、渡された資料にないことを書かないでください。
- 推奨（維持すべき / 放棄すべき）は書かないでください。
  判断は人が行います。

【この特許の情報】
{patent_info}

【公報の請求項と課題・効果】
{claims_and_effects}

【検索でヒットした自社製品】
{matched_products}

【年金の計算結果】
{fee_calc}

【昨年までの検討記録】
{past_decisions}

「推奨を書かないでください」の1行が重要です。 推奨が書かれていると、事業部は中身を読まずにそれを承認します。この仕組みが作るのは判断そのものではなく、判断するための材料です。

出力形式を固定する

Claude API の structured outputs を使い、JSONスキーマを指定して受け取ります。output_config.format に type: "json_schema" とスキーマを渡すと、スキーマに沿った有効なJSONが返ります。enum や const は使えますが、minimum / maximum のような数値制約や minLength のような文字列制約は使えないため、値の妥当性は受け取ったあとに自分で検査してください。

{
  "patent_no": "",
  "title": "",
  "annuity_year": 0,
  "due_date": "",
  "claims_count": 0,
  "fee_this_time": 0,
  "fee_until_expiry": 0,
  "years_remaining": 0,
  "claim_summary": "",
  "related_products": [
    {
      "product_name": "",
      "relation": "関連する可能性がある | 関連は薄い | 判断できない",
      "reason": ""
    }
  ],
  "reasons_to_keep": [],
  "reasons_to_abandon": [],
  "questions_for_business_unit": [],
  "last_year_decision": "",
  "needs_review": []
}

金額は文字列でなく数値で返させます。文字列にすると「10,300円」のようにカンマと単位つきで返り、合計の計算で壊れます。

システムへ連携する

検討表の出力先は3通りあります。

まずは1つめで始めるのが現実的です。 検討表がファイルで出るだけで、照会の準備は大きく楽になります。

人が確認する

全件、人が確認します。放棄の自動判定はしません。

理由は、権利を放棄すると元に戻せないためです。納付期限を過ぎても6か月の追納期間があり、その間は割増を払えば存続させられますが、そこも過ぎると権利は消滅します。消滅した権利は、故意でない場合の回復手続があるものの、通るとは限りません。

確認を速くするための設計が重要です。

• 検討表で、維持の理由と放棄の理由を左右に並べて表示する
• 昨年の判断と、その理由を上部に固定表示する（同じ検討の繰り返しを防ぐ）
• 満了までに払う見込み額を大きく出す。今回の額だけだと判断が甘くなる
• needs_review に入った項目を色分けする

例外に対処する

記録を残す

この業務では、判断の記録そのものが翌年の入力になります。

• 検討表（生成した状態のまま）
• 事業部・発明者の回答
• 最終の判断（維持／放棄）と、その理由
• 判断した人と日付
• 人が修正した項目と、修正前後の値

最後の項目は精度の実測値になります。「請求項の要約はそのまま通るが、製品の対応づけは半分が修正されている」と分かれば、製品索引の作り方を直せばよいと分かります。