毎月増える自社と競合の特許を請求項の内容で技術のまとまりに分類し、ポートフォリオの地図を更新して手薄な領域を出す

処理の起点を決める

毎月第1営業日の定時実行を起点にします。 特許データベースの前月分の書き出しを、担当が決まったフォルダに置いたことを確かめてから動かします。書き出しの件数がいつもより大きく少なければ、処理を止めて担当に知らせます。 検索の条件を誤ったまま当てはめると、競合の出願が減ったように見えます。

作り直しは四半期に1回、別の処理として回します。 1月・4月・7月・10月の当てはめの後に、それまでの全件でまとまりを作り直します。作り直しの結果は、人が承認するまで当てはめに使いません。 承認までのあいだは、前のまとまりで当てはめを続けます。

入力データを集める

質を決めるのは、いちばん下の2つです。 出願人の名寄せ表が無ければ、子会社名義の出願が競合の件数から抜け、競合の動きを小さく見誤ります。 印の規則が無ければ、件数の表は出ても、どこを見ればよいかが決まりません。

請求項は1だけを使います。 請求項全体を入れると、従属項の細かな限定が内容の近さを左右し、同じ技術の特許が、実施の形の違いで別のまとまりに散ります。 技術の中身を表すのは要約と請求項1で十分です。

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

特許データベースの書き出しは、出願人を指定した保存済みの検索式で行います。検索式は知財部で管理し、名寄せ表と同じ出願人の範囲にそろえます。

埋め込みは、同じ公報を二度作りません。 公開公報と登録公報で同じ出願が二度出てくることがあり、出願番号で重複を除いてから埋め込みます。 登録で請求項が補正されていれば、登録公報の請求項1で埋め込み直し、公開時のベクトルは履歴として残します。

ベクトルの次元は、最初に決めたら変えません。 output_dimensionality を768で始めたら、全件を768で作ります。次元を変えるときは、モデルを替えるときと同じく、全件を埋め込み直します。

AIへ渡す前に整形する

1. 重複の除去 … 出願番号で公開と登録をまとめ、新しい方の請求項1を使います
2. 出願人の名寄せ … 名寄せ表で、子会社・旧社名を競合各社に寄せます。表に無い出願人は「その他」として担当に知らせます
3. テキストの整形 … 要約と請求項1から、図面の符号（「（10）」など）と改行を除きます
4. 埋め込み用の文 … 「task: clustering | query: 」の後に、発明の名称・要約・請求項1をつなぎます
5. 長さの確認 … 入力の上限（8,192トークン）を超えるものは、請求項1の後半を落とします
6. 外国語の公報 … 日本語の公報と英語の公報を同じ空間で比べます。翻訳はしません
7. 特許分類の扱い … IPC・FI は埋め込みの文に入れず、集計の切り口として別の列に残します

7番目で特許分類を文に入れないのは、記号が内容の近さを引っ張るからです。 「H01M 4/62」のような記号を文に混ぜると、同じ記号を持つ特許どうしが近く出やすくなり、特許分類で分けたのと変わらない結果になります。 分類は、まとまりと並べて「このまとまりはどの分類にまたがっているか」を見るのに使います。

4番目の書き方は、ドキュメントの指定に合わせます。 gemini-embedding-2 では task_type の指定は使えず、テキストの作業は「task: clustering | query: {content}」のように、作業の指示を入力の文に直接書くとされています。指定をそろえないと、同じ特許でも作った時期によってベクトルの性質が変わります。

6番目で翻訳をしないのは、ドキュメントで gemini-embedding-2 が100を超える言語でのまとまり作りに対応するとされているからです。 競合の米国出願を翻訳してから埋め込むと、翻訳の言い回しで内容の近さが動きます。

AIに処理させる

この構成の「AI」は3つの部品に分かれます。 内容を数値にするのが埋め込み、まとまりを作るのが HDBSCAN、まとまりに名前を付けるのが生成AIです。生成AIは、どの特許をどのまとまりに入れるかを決めません。

毎月の当てはめを HDBSCAN でしないのは、HDBSCAN に新しいデータを既存のまとまりに当てはめる機能が無いからです。 ドキュメントでは、使える方法は fit と fit_predict で、全件で作り直す形になります。そこで、作り直しのときに store_centers="centroid" で各まとまりの中心を保存し、毎月はその中心との近さで当てはめます。

当てはめのしきい値は、作り直しのときに決めます。 各まとまりについて、中に入った特許と中心とのコサイン類似度の分布を見て、下から5％の値をそのまとまりのしきい値にします。 まとまりごとに広がりが違うため、全体で1つのしきい値にすると、広いまとまりに何でも入り、狭いまとまりに何も入らなくなります。

min_cluster_size は、知財部が「1つの領域として見たい最小の件数」で決めます。 既定は5です。小さくすると領域が細かく割れ、大きくすると新しい領域が「どこにも入らない」に落ちます。 最初は20前後で始め、作り直しのたびに担当と見直します。

印の規則は、AIではなく表で持ちます。

指示内容を固定する

まとまりの名前の案は、Claude API に次の指示で作らせます。 渡すのは、中心に近い特許10件と、中心から遠い特許3件の発明の名称・要約・請求項1です。

あなたは製造業の知財部で、特許のまとまりに分かりやすい名前を付ける立場です。
渡された特許の記載だけを使って、このまとまりの名前と説明の案を作ってください。

【渡す情報】
- 中心に近い特許10件：発明の名称、要約、請求項1
- 中心から遠い特許3件：発明の名称、要約、請求項1
- 前の四半期で対応するまとまりの名前と説明（ある場合）

【書き方】
- name は20字以内で、まとまりに共通する技術の要素を表す名前にしてください。
- description は2文で、1文目に共通する技術の要素、
  2文目に中心から遠い特許との違い（まとまりの広がり）を書いてください。
- common_terms には、10件のうち半数以上の請求項1に出てくる技術の言葉を、
  最大5つ、記載のとおりに並べてください。
- 前の四半期の名前がある場合、内容が同じなら同じ名前を使ってください。
  変える場合は rename_reason に理由を書いてください。

【厳守事項】
- 渡された特許に書かれていない技術の言葉を、名前や説明に使わないでください。
- 権利範囲が広い・狭い、侵害のおそれ、有効性について書かないでください。
- 出願人の名前、出願の意図、今後の出願の見込みを書かないでください。
- 「自社は〜すべき」のような提案を書かないでください。
- 10件に共通する要素が見つからない場合は、名前を付けず、
  name を空にして mixed を true にしてください。

【中心に近い特許】{core_patents}
【中心から遠い特許】{edge_patents}
【前の四半期のまとまり】{previous_cluster}

「中心から遠い特許」を渡すのは、名前を狭くしすぎないためです。 中心の10件だけを渡すと、名前はその10件の共通点に絞られ、まとまりの端にある特許が名前から外れます。 端の3件があると、どこまでを含む名前にすべきかが分かります。

「共通する要素が見つからなければ名前を付けない」を明記するのは、HDBSCAN が性質の違う特許を1つにまとめることがあるからです。 何も言わなければ生成AIは、ばらばらの10件にもそれらしい名前を付けます。mixed が立ったまとまりは、min_cluster_size の見直しの材料になります。

出力形式を固定する

次の形のJSONで、まとまりごとに受け取ります。 件数と印は Python が埋め、name から rename_reason までを Claude API の構造化出力（output_config.format に type: "json_schema"）で受け取ります。

{
  "cluster_id": "C2026Q4-07",
  "previous_cluster_id": "C2026Q3-05",
  "overlap_with_previous": 0.82,
  "embedding_model": "gemini-embedding-2",
  "dimensions": 768,
  "name": "",
  "description": "",
  "common_terms": [],
  "mixed": false,
  "rename_reason": "",
  "counts_12m": { "own": 4, "competitor_A": 21, "competitor_B": 9, "others": 6 },
  "growth_3m": { "competitor_A": 2.3 },
  "flags": ["own_thin", "competitor_A_growth"],
  "approved": { "by": "", "at": "" }
}

1つ目の理由は、名前と件数を別の層に置けることです。 件数と印は集計の規則で決まり、生成AIは名前だけを書きます。名前の案が気に入らなくても、件数と印は変わりません。

2つ目は、前の四半期との対応を残せることです。 overlap_with_previous は、前のまとまりに入っていた特許のうち、今回このまとまりに入った割合です。8割を超えれば同じまとまりとして名前と推移を引き継ぎ、それ未満は人が対応を決めます。 これが無いと、作り直しのたびに推移のグラフが途切れます。

3つ目は、embedding_model と dimensions です。 モデルや次元が違うベクトルを混ぜていないかを、集計の前に機械的に確かめられます。

システムへ連携する

社内の技術分類の一覧は、自動では書き換えません。 新しいまとまりを社内の区分として採用するかは、知財部と研究開発本部で決めます。まとまりは区分の見直しの材料で、区分そのものではありません。

人が確認する

人が読むのは、印の付いたまとまりと「未分類」の特許です。

1. 「未分類」を先に見る … 既存のどのまとまりとも遠い特許です。新しい技術の芽か、検索式の誤りで混じった無関係の特許かを見分けます
2. 印の付いたまとまりの新しい特許を読む … 競合の出願が増えたまとまりの新しい特許を数件読み、増えた中身を確かめます
3. 当てはめの誤りを直す … 明らかに違うまとまりに入った特許は、担当が付け替えます。付け替えた記録を残します
4. 作り直しの名前と対応を承認する … 四半期に1回、名前の案と前のまとまりとの対応を確かめます

3番目の付け替えの記録を省かないでください。 同じまとまりで付け替えが続くなら、そのまとまりの中心かしきい値がずれています。 次の作り直しで直す材料になります。

「新しい領域の候補」の印は、研究開発の担当と一緒に見ます。 「未分類」のうち互いに近い特許が数件そろったものは、知財の担当だけでは技術の意味が判断しにくいことがあります。研究開発の担当が「これは既存の領域の言い換え」と言えば次の作り直しで既存に寄せ、「新しい領域」と言えば社内の区分の見直しの候補にします。

目標は、600件をならして1件1分です。 近さが十分な特許は一覧で流し見て、「未分類」と印の付いたまとまりに時間を使います。

例外に対処する

5行目で「未処理」と「未分類」を分けるのは、意味が逆だからです。 「未分類」は既存のどこにも近くない特許、「未処理」はまだ近さを測っていない特許です。混ぜると、APIの一時的な停止が新しい技術の芽に見えます。

記録を残す

• 特許データベースの書き出しと、そのときの検索式
• 公報ごとのベクトル、モデル名と次元、埋め込んだ日
• 当てはめの結果（まとまり、中心とのコサイン類似度、しきい値）
• 人が付け替えた記録 … どの特許を、どのまとまりから、どこへ移したか
• 四半期ごとのまとまりの一覧（中心、名前、説明、前のまとまりとの対応、承認者）
• 月ごとのまとまり×出願人の件数と印、そのとき使った印の規則の版

5つ目で前のまとまりとの対応を残すのは、推移を後から読み直すためです。 経営会議で「A社はいつからこの領域に出願を増やしたか」と聞かれたとき、作り直しをまたいで件数をつなげる根拠になります。