毎月発行される意匠公報の図面を開発中の製品の外観と画像で照らし合わせ、似ている他社意匠の候補を知財の確認リストにする

処理の起点を決める

月に1回の定時実行にします。 当月に発行された公報の取り込みが終わった翌営業日に動かします。公報の発行のたびに動かす形にはしません。 開発中の製品の図は月の途中でも差し替わるため、毎回違う製品の版で照らし合わせることになり、結果を月ごとに比べられなくなります。

開発中の製品の側は、フォルダへの追加でも検索を動かします。 新しく企画に上がった製品は、過去12か月分の公報に対して一度だけ検索し、月次の実行では見ない過去分を埋めます。

実行の単位は製品の図1枚ごとにします。1枚ずつに分けておけば、途中で止まっても、止まった図から再開できます。

入力データを集める

質を決めるのは、3つ目の図の書き出し方です。 公報の図面は、線で描かれた図もあれば写真のものもあります。一方、3Dデータの画面をそのまま写すと、色と光沢と影が付いた画像になります。 埋め込みはこの見た目の違いも拾うため、形が近いのに遠い順位になります。

そこで、製品の図は2通り書き出します。 1つは輪郭と稜線だけの線画、もう1つは背景を白にした陰影付きの図です。公報の図面が線画ならば線画どうし、写真ならば陰影付きの図と比べます。どちらの公報かは、取り込むときに画像の色の数で見分けて属性にしておきます。

4つ目の「関係する意匠分類」は、絞り込みの条件になります。 掃除機の開発品を照明器具の公報と比べても意味がありません。製品ごとに、見る意匠分類を知財担当が決めて案件管理表に持たせます。

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

公報の図面は、契約している特許調査サービスから取り込みます。 取り込める形式や、取り込んだ画像を社内の検索に使ってよいかは契約によって違うため、利用環境に応じた確認が必要です。

J-PlatPat をプログラムで巡回して集めることはしません。 J-PlatPat の利用上の注意では、データの単純な収集を目的とした大量データのダウンロードや、プログラムによる定期的な自動データ収集のような行為は禁止されており、違反が検出された場合は予告なくアクセスを制限するとされています。

属性は、Vector Search の絞り込みの形に合わせて持たせます。 意匠分類や図の向きのような区分は名前空間と値の組（トークンの絞り込み）で、発行年月のような数は数値の絞り込みで持ちます。問い合わせでは、名前空間の間は AND、名前空間の中は OR で組み合わされ、数値は LESS、LESS_EQUAL、EQUAL、GREATER_EQUAL、GREATER のいずれかで比べます。

登録番号は「クラウディングタグ」に入れます。 1件の公報には6〜7枚の図があり、そのまま近い順に並べると、同じ公報の図が上位を埋めて、他の公報が押し出されます。 Vector Search には、同じクラウディングタグから返す件数に上限を付けて結果を分散させる機能があるため、登録番号をタグにして1件の公報から返す図を2枚までに抑えます。

AIへ渡す前に整形する

1. 図ごとに分ける … 1ページに複数の図が載っているものは、枠で分けて1図1画像にします
2. 図の名称の文字を消す … 「正面図」「斜視図」といった文字と図の枠線を取り除きます
3. 余白をそろえる … 形の外接矩形を求め、周りに同じ割合の白い余白を付けて正方形にします
4. 色を見分ける … 線画か写真かを色の数で判定し、style の属性にします
5. 製品の図の書き出し … 公報と同じ7つの向きで、線画と陰影付きの2通りを書き出します
6. 形式と大きさの確認 … JPEG か PNG にそろえ、1枚が最大16,384×16,384ピクセルに収まることを確かめます
7. 同じ図の重複を除く … 関連意匠や再掲などで同じ図が二度入らないよう、画像のハッシュで照合します

2番目を軽く見ないでください。 公式のドキュメントには、このモデルは画像の中の文字を光学式文字認識（OCR）のように見分けられると書かれています。「正面図」という文字が全部の図に残っていると、その文字の共通点で近くなります。 形ではなく図の名称で並んでしまうので、文字は必ず消します。

3番目も同じくらい効きます。 同じ形でも、画像の中で小さく描かれているか大きく描かれているかで、埋め込みは変わります。公報の図は余白の取り方がまちまちなので、形の大きさを画像の中でそろえます。

AIに処理させる

させるのは、2つのことだけです。 1つは、図をベクトルにして近い順に並べること。もう1つは、並んだ候補について形のどこが同じでどこが違うかを言葉にしたメモを作ることです。

右端の列の1行目と2行目が、この構成でいちばん大事な制約です。 公式のドキュメントは、埋め込みの内積は較正された確率ではなく、用途によって点数の分布が違うため、固定の閾値で質を測るのを避け、検索には順位を使うことを勧めています。製品ごとに上位10件、と件数で決めます。

4行目がいちばん起きやすい失敗です。 一覧に点数を載せると、読む人は必ず割合として読みます。確認リストには順位だけを出し、点数はログに残します。

指示内容を固定する

観点メモを作る Gemini API への指示です。埋め込みと検索には指示文を使いません。

あなたは知財部で、意匠公報の図面と自社の開発中の製品の図を見比べる
担当者の補助をする立場です。
2つの画像を見て、形の同じところと違うところを書き出してください。

【渡すもの】
- 画像A：意匠公報の図（{view_name}）
- 画像B：自社の開発中の製品の図（同じ向き）
- 公報の書誌：登録番号 {reg_no}、意匠に係る物品 {article}

【書き出す観点】
1. 全体の形（箱型、円筒、曲面の多さなど）
2. 輪郭の特徴（角の丸み、くびれ、張り出し）
3. 主な面の構成（面の分かれ方、段差、開口の位置）
4. 目立つ部分（取っ手、ボタン、吹き出し口など）の位置と形

【厳守事項】
- 似ている、似ていない、類似する、非類似である、と書かないでください。
- 権利を侵害する・しない、問題がある・ないも書かないでください。
- 点数、割合、度合いを書かないでください。
- 画像に写っていないことを推測で書かないでください。
  見えない面は「この図からは分からない」と書いてください。
- 図の中に文字や記号が残っていても、それを根拠にしないでください。
- 色や質感の違いは、形の違いとは別に1行だけ書いてください。
  図の描き方（線画か写真か）による違いは書かないでください。
- 各観点は、同じところと違うところを1文ずつにしてください。
- 画像が図面でない、または判別できない場合は、
  観点を書かず、image_issue に理由を書いてください。

「似ている、と書かない」を明記しないと、ほぼ必ず書きます。 見比べを頼まれると、最後に「全体として類似した印象を与える」とまとめたがります。その一文が確認リストに載ると、知財担当の判断より先に結論が回ってしまいます。

「図の描き方による違いを書かない」も同じ理由です。 線画と陰影付きの図を渡すと、何も言わなければ「Aは線画、Bは写真的」と書きます。形の違いではない違いで、メモが埋まります。

出力形式を固定する

検索と観点メモの結果を、次の形のJSONにまとめます。

{
  "run_month": "2026-09",
  "product_code": "",
  "product_stage": "企画 | 試作 | 金型発注前",
  "classes": [""],
  "candidates": [
    {
      "rank": 1,
      "reg_no": "",
      "article": "",
      "design_class": "",
      "issue_date": "",
      "best_view": "front | back | left | right | top | bottom | perspective",
      "views_hit": ["front", "perspective"],
      "style_pair": "line-line | photo-shaded",
      "memo": { "overall": "", "outline": "", "surfaces": "", "features": "", "color_note": "" },
      "image_issue": ""
    }
  ],
  "missing_views": ["bottom"],
  "reviewer_mark": "detail | skip | ask_attorney | null"
}

1つ目の理由は、候補に点数を持たせないことです。 rank だけを出し、内積の値は検索のログにだけ残します。 確認リストを開いた人が、点数を割合として読む余地を作りません。

2つ目は、views_hit で「どの向きで近かったか」が分かることです。 正面図だけで近いのか、斜視図でも近いのかで、見るべき度合いが変わります。複数の向きで上位に入った公報ほど、先に見ます。

3つ目は、missing_views で比べられなかった向きを残せることです。 「照らし合わせて出なかった」と「照らし合わせていない」を分けられます。

reviewer_mark は人が付けます。 detail は詳しく見る、skip は見なくてよい、ask_attorney は特許事務所へ見解を依頼する、の3つです。この印の付き方が、次の月に上位の件数を決める材料になります。

システムへ連携する

索引の更新は、バッチ更新を前提にします。 月に1回、当月分をまとめて足すだけなので、Cloud Storage に置いた差分だけを索引に反映する部分更新で足ります。ストリーミング更新は数秒で反映されますが、ストリーミング更新用に作った索引にはバッチ更新ができないとされています。後から切り替えられないので、最初に決めます。

案件管理表には書き込みではなく、横に並べる一覧として出します。 担当者が印を付けた結果だけを、人が案件管理表に移します。機械が案件管理表を書き換えると、候補に上がっただけの公報が「要注意の意匠」として記録に残ります。

人が確認する

人が開くのは、製品ごとの上位10件と、image_issue の別枠だけです。 それ以外の公報は、件名と代表の図だけを一覧で流し見ます。

1. 製品ごとに上位の候補を見る … views_hit の多いものから、公報の全部の図を開いて見ます
2. 観点メモは読むだけにする … メモは見比べる場所の手がかりです。判断の根拠にはしません
3. 印を付ける … detail、skip、ask_attorney のどれかを付けます
4. 上位に入らなかったものを流し見る … 関係する意匠分類の残りを、代表の図だけで一覧します
5. 見落としに気づいたら記録する … 上位に入らなかったのに見るべきだった公報は、順位とあわせて残します

4番目を省かないでください。 埋め込みの近さは形の近さと一致しないことがあります。一覧の流し見は、この構成が見落とす型を知るための作業です。 5番目の記録がたまると、どの向きや描き方の組み合わせで順位が落ちるかが分かります。

判断の最終は、知財担当と弁理士です。 ask_attorney を付けた公報は、これまでどおり特許事務所に類否の見解を依頼します。この構成は、依頼する公報を選ぶところまでです。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、公報の取り込みと製品の図の書き出しの問題です。 直すほうが、埋め込みのモデルを変えるより効きます。

部分意匠の行は、特に注意が要ります。 部分意匠の図では、権利を求める部分以外が破線で描かれることがあり、全体の形で比べると、権利を求めていない部分の近さで上位に来ます。 順位をそのまま信じず、人が見ます。

記録を残す

• 当月の実行で使った公報の一覧と、取り込んだ日時
• 公報の図と製品の図の、前処理の前後の画像
• 埋め込みに使ったモデルの名前と出力の次元、検索の条件（絞り込みの属性、上位の件数、クラウディングの上限）
• 製品の図ごとの近傍の結果と、内積の値
• 観点メモの全文と、禁止語で捨てたメモ
• 人が付けた印と、上位に入らなかったのに見るべきだった公報の記録

3つ目で検索の条件を残すのは、条件を月ごとに変えるためです。 上位の件数や絞り込む意匠分類を変えると、同じ公報でも出る・出ないが変わります。当時の条件が残っていないと、先月の結果と比べられません。

開発中の製品の図は、ログでも社外秘として扱います。 画像そのものと埋め込みの両方を、保存先の地域を決めたプロジェクトに置きます。