知財部が新しい商品名の候補を、自社と他社の登録商標の一覧から読み（称呼）の似たものを探し、一次調査の候補を出す

処理の起点を決める

起点は2つあります。毎週の取り込みと、担当の取り込みのボタンです。

毎週の取り込みは、調査用のデータベースから書き出した一覧を S3 に置いたことで動きます。書き出す範囲は、自社が商品を出す区分の商標に限ります。 出願中のもの、登録のもの、消滅したもの（参考に残す）を状態の項目で分けます。

担当のボタンは、依頼のフォームの候補を一覧の画面に取り込んだ後に押します。候補を1件ずつではなく、依頼ごとにまとめて流します。 同じ商品の候補は同じ類似群コードで探すので、まとめると条件を1回作れば済みます。

入力データを集める

質を決めるのは、いちばん下の表です。 特許庁の類似商品・役務審査基準は、類似関係にあると推定する商品・役務をグループにし、各グループに検索のための特定のコードを付けたもので、審査官の統一的な基準として使われています。現行は国際分類第13-2026版対応で、2026年1月1日以降の出願に適用されます。社内の商品の分け方ごとに、見るべきコードを知財部が決めて表にします。

称呼の列は、データベースの参考の情報として入っていることが多い列です。 入っていない商標は、次の前処理で読みを作ります。

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

索引の設定は次のようになります（置き換えの組は一部だけを示します）。

PUT /tm_marks
{
  "settings": { "index.max_ngram_diff": 1,
    "analysis": {
      "char_filter": {
        "loose_map": { "type": "mapping", "mappings": [
          "ー => ", "ッ => ", "ヴ => ブ",
          "ガ => カ", "ギ => キ", "ザ => サ", "ダ => タ", "バ => ハ", "パ => ハ",
          "シャ => サ", "シュ => ス", "ショ => ソ", "キャ => カ" ] },
        "vowel_map": { "type": "mapping", "mappings": [
          "カ => ア", "キ => イ", "ク => ウ", "ケ => エ", "コ => オ",
          "ー => ", "ッ => ", "ン => " ] }
      },
      "tokenizer": {
        "kana_2_3": { "type": "ngram", "min_gram": 2, "max_gram": 3 }
      },
      "analyzer": {
        "loose": { "type": "custom", "char_filter": ["loose_map"],
                   "tokenizer": "kana_2_3" }
      },
      "normalizer": {
        "vowel": { "type": "custom", "char_filter": ["vowel_map"] }
      }
  } },
  "mappings": { "properties": {
    "mark_no":       { "type": "keyword" },
    "mark_text":     { "type": "text" },
    "reading_exact": { "type": "keyword" },
    "reading_loose": { "type": "text", "analyzer": "loose" },
    "reading_vowel": { "type": "keyword", "normalizer": "vowel" },
    "group_codes":   { "type": "keyword" },
    "classes":       { "type": "keyword" },
    "holder":        { "type": "keyword" },
    "status":        { "type": "keyword" }
  } }
}

reading_loose は ngram で2〜3文字に切ります。 公式のドキュメントでは、ngram の分かち書きは指定した長さの重なり合う文字の並びを作り、min_gram と max_gram の差は索引の設定 index.max_ngram_diff（既定は1）までです。2と3なら既定のままで足ります。 「ルミナ」をそろえた形は「ルミ」「ミナ」「ルミナ」になり、「ルミーナ」も長音が消えて同じ形になります。

探す形は次のとおりです。

POST /tm_marks/_search
{ "query": { "bool": {
    "filter": [ { "terms": { "group_codes": ["30A01", "30A02"] } },
                { "terms": { "status": ["registered", "pending"] } } ],
    "should": [
      { "term":  { "reading_exact": { "value": "ルミナ", "boost": 4 } } },
      { "term":  { "reading_vowel": { "value": "ルミナ", "boost": 2 } } },
      { "fuzzy": { "reading_exact": { "value": "ルミナ", "fuzziness": 1,
                                       "prefix_length": 1 } } },
      { "match": { "reading_loose": { "query": "ルミナ",
                                      "minimum_should_match": "70%" } } } ],
    "minimum_should_match": 1 } },
  "size": 100 }

類似群コードは filter に置きます。 点数に関わらず、コードの重ならない商標は一覧に出ません。読みのそろえ方は should に並べ、どれで当たったかを後で調べるために、そろえ方ごとに名前を付けて記録します。

term の値は、検索の側でも同じそろえ方を通ります。 reading_vowel は normalizer なので、「ルミナ」と書いて探しても母音の形「ウイア」で引かれます。

AIへ渡す前に整形する

1. 読みを片仮名にそろえる … 平仮名の称呼は片仮名に、半角の片仮名は全角にします
2. 読みの無い商標に読みを作る … 漢字の商標は、kuromoji の読みの形（kuromoji_readingform）で片仮名の読みを作り、reading_source に「自動」と書きます
3. 1つの商標に読みが複数あれば、すべて持つ … 称呼の列に複数が書かれていれば配列にします
4. 類似群コードを配列にする … 指定商品ごとのコードを1つの配列にまとめます
5. 状態をそろえる … 出願中・登録・消滅を3つの値にします
6. 候補の読みを作る … Claude で、候補ごとに自然な読みと、独立して読まれうる部分を挙げます（次の項）

2番目の読みは、あくまで補いです。 公式のドキュメントでは、kuromoji の読みの形のフィルタは、kuromoji の分かち書きが持つ読みの情報で各語を片仮名（または英字）の読みに置き換えます。辞書の読みなので、商標として自然な読みと違うことがあります。 審査基準も、自然に称呼されるものだけが生じ、不自然な称呼は生じないとしています。自動で作った読みで当たったものには、一覧で印を付けます。

AIに処理させる

AIの仕事は、候補の名前から探すための読みを挙げることだけです。 探すのも、違いを書き出すのも、規則と索引の仕事です。

「読みを1つに決めない」が、いちばん大事な線です。 審査基準は、2以上の自然な称呼を持つ文字の商標は、その一方を振り仮名として付けても、他の一方の称呼も生ずるとしています。読みを1つに絞ると、もう一方の読みで近い商標を見落とします。

独立して読まれうる部分を挙げるのは、名前が長いときのためです。 審査基準は、全体の観察だけでなく、構成部分の一部を他人の商標と比べて判断する場合があるとしています。「プチモアショコラ」なら「プチモア」でも探します。ただし、どこを要部と見るかの判断はさせず、探す範囲を広げるためだけに使います。

指示内容を固定する

あなたはメーカーの知財部で、商品名の候補の一次調査を手伝う立場です。
候補の名前から、先行商標を探すための読み（称呼）を挙げてください。
類似するかどうか、登録できるかどうかは判断しないでください。

【挙げるもの】
- readings: 名前から自然に生じる読みを、片仮名ですべて。
  英字の名前は、ローマ字読みと英語読みの両方が自然なら両方
- parts: 名前の中で、それだけで読まれうるまとまり（語）。
  そのまとまりの読みも片仮名で
- notes: 読みを挙げた理由を1行ずつ

【厳守事項】
- 自然に読まれる読みだけを挙げてください。
  漢字の音読みと訓読みを機械的に組み合わせた不自然な読みは挙げないでください。
- 読みを1つに絞らないでください。迷うものは両方挙げてください。
- 振り仮名が付いている場合は、振り仮名の読みと、
  字そのものから自然に生じる読みの両方を挙げてください。
- 長音・促音・濁点は、自然に読まれるとおりに書いてください。
  そろえる処理は別の仕組みで行うので、自分で外したり足したりしないでください。
- 「類似」「非類似」「登録可能」「問題なし」などの判断を書かないでください。
- 区分や類似群コードを推し量らないでください。

【候補の名前】{candidate}
【振り仮名（あれば）】{furigana}

「そろえる処理を自分でしない」を明記するのは、そろえる規則を1か所に置くためです。 AIが「ルミーナ」を「ルミナ」に直して返すと、索引のそろえ方と違う直し方が混ざり、どのそろえ方で当たったかの記録が意味を持たなくなります。

出力形式を固定する

Bedrock の Converse API の outputConfig.textFormat に JSON スキーマを渡し、次の形で受け取ります。

{
  "candidate": "",
  "readings": [ { "kana": "", "basis": "natural | romaji | english | furigana" } ],
  "parts": [ { "text": "", "kana": "" } ],
  "notes": [""]
}

公式のドキュメントでは、Converse API の outputConfig.textFormat に JSON スキーマを渡すと応答がスキーマに沿い、enum が使えます。basis を enum で閉じ、読みの出どころが一覧で分かるようにします。

画面に出す一覧は、検索の結果から Lambda が作ります。

「違い」の列は、AIではなく規則で書き出します。 候補の読みと当たった商標の読みを1音ずつ比べ、清濁の差、長音・促音の有無、拗音と直音の差を名前で書きます。担当が審査基準の例と見比べる材料になります。

システムへ連携する

調査用のデータベースの画面は、引き続き使います。 一覧で気になった商標は、データベースの画面で最新の状態と公報を確かめます。毎週の書き出しの間に状態が変わることがあるからです。

人が確認する

1. 候補の読みを見る … Claude が挙げた読みに、抜けや不自然なものが無いかを見ます。足したい読みがあれば、画面で足して探し直します
2. 当たり方の順に見る … 「そのまま」から順に、「母音の並び」は最後に見ます
3. 近いものに印を付ける … 「近い」「やや近い」「遠い」の印と、理由を1行で書きます
4. 本調査に回すかを決める … 「近い」が1件でもあれば本調査に回す、のように部の決まりで決めます

1番目を省かないでください。 読みが抜けていれば、その読みで近い商標は一覧に出ません。検索の仕組みがどれだけ丁寧でも、入口の読みが足りなければ拾えません。

4番目の決まりは、部で文書にしておきます。 担当ごとに「やや近い」の扱いが違うと、一覧がそろっても本調査に回す件数がそろいません。印の付け方と、本調査に回す条件を先に決めることが、品質をそろえる本体です。

例外に対処する

3行目は、編集距離の性質によるものです。 公式のドキュメントでは、fuzzy の検索は編集距離の範囲で語を広げ、広げる数の既定は50で、先頭の固定の文字数（prefix_length）が0だと広げる数が増えて重くなるとされています。3音の読みで1音違いを許すと、ほとんどの3音の商標が当たります。

記録を残す

• 候補ごとの、名前、使う商品、Claude が挙げた読みと部分、担当が足した読み
• 検索の条件（類似群コード、そろえ方ごとの問い合わせ）と、当たった商標と当たり方
• 担当の印と理由、本調査に回したか
• 本調査の結果（弁理士の見解の要旨）
• 取り込んだ一覧の書き出しの日

本調査の結果を残すのは、一次調査の引き方を直すためです。 本調査で近い商標が見つかり、一次調査の一覧に無かったなら、どの読みのそろえ方が足りなかったかが分かります。 逆に、一覧で「近い」と印を付けたのに本調査で問題が無かった組も残します。そろえすぎている箇所が分かり、一覧を短くする材料になります。