新商品名の候補を先行商標と突き合わせて出願前のリスクを一次仕分けする

処理の起点を決める

商品開発チームがスプレッドシートに候補名を書き込み、「調査依頼」ボタンを押したことを起点にします。Google Apps Scriptならスプレッドシート上のメニューやボタンから関数を呼び出せます。

候補が1件ずつバラバラに届くと、検索の手間が件数分そのまま増えます。10件以上まとまってから動かす運用にしてください。J-PlatPatでの検索は人が行うため、ここをまとめられるかどうかで効果が変わります。

入力データを集める

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

検索結果： J-PlatPatの商標検索で候補の称呼を検索し、検索結果一覧からCSV出力します。この操作は人が行います。 J-PlatPatに一般提供のAPIがあることを確認できていないため、自動取得を前提にした構成にはしません。

CSVには、出願番号・登録番号、商標（検索用）、称呼（参考情報）、区分、出願人・権利者、出願日、登録日、ステータスといった項目が並びます。検索結果一覧のCSV出力ではURLも出力されるため、あとから原本を開き直せます。

類似群コード： 特許庁が公開している類似商品・役務審査基準を使います。これは類似関係にあると推定される商品・役務をグループにまとめ、各グループに検索用のコードを付けたものです。PDFのほかExcel版も公開されているので、Excel版を取り込んで対応表にします。適用される版が決まっている点に注意してください。 国際分類第13-2026版対応の基準は、令和8年1月1日から適用されています。

自社の指定商品・役務： 「この商品名は第30類の菓子で使う」というように、候補ごとに使う区分をあらかじめ決めておきます。ここが決まらないと、どの先行商標が問題になるかが決まりません。

AIへ渡す前に整形する

1. 称呼のバリエーション生成 … 「白梅」から「ハクバイ」と「シラウメ」の両方を出すように、1つの候補から生じ得る自然な読みを列挙します。ここを人手でやると漏れます
2. 特殊記号の正規化 … J-PlatPatの「商標(検索用)」には特殊記号が付きます。「§」は特殊な構成や態様、「∞」は構成の分離（縦書きと横書きなど）、「▲」「▼」は文字コードにない漢字の置換、「￠」はアクセント記号付きのラテン文字、「＼」は2段以上の併記を表します。これらを機械的に外して読める文字列に戻すか、記号の意味を残したまま後段へ渡すかを決めます
3. 棚の絞り込み … 類似群コードが自社の使う商品・役務と1つも重ならない先行商標は、この段階で外します。ここを外さないと、AIに渡す件数が数百件になります
4. 権利の生死の確認 … ステータスが消滅・拒絶になっているものは引用の対象になりません。ただしCSVの表示だけで断定せず、フラグを付けて人が見られるようにします

AIに処理させる

検索と法的な判断はAIにさせません。AIにさせるのは「読みの洗い出し」と「近さの説明」だけです。

商標審査基準では、商標の類否は「外観、称呼又は観念等によって需要者に与える印象、記憶、連想等を総合して全体的に観察し」判断するとされています。称呼の類否については、音質・音量・音調・音節という判断要素が示されており、たとえば相違する1音の母音が共通する場合（「ダイラマックス」と「ダイナマックス」）や、清音と濁音の違いにすぎない場合（「バーテラックス」と「バーデラックス」）が例示されています。AIにはこの4つの判断要素のどれに当たるのかを書かせます。 そうすると、人が確認するときに何を見ればよいかが分かります。

指示内容を固定する

あなたは知財担当を支援する担当者です。
新しい商品名の候補と、J-PlatPatで検索した先行商標の一覧をもとに、
両者がどれくらい近いかを説明してください。

【厳守事項】
- 商標登録ができるかどうかを判断しないでください。
  あなたの役割は、人が確認する順番を決めるための仕分けです。
- 類似群コードが1つも重なっていない先行商標を「近い」と書かないでください。
  棚が違えば、名前が似ていても問題にならないことがあります。
- 称呼の近さを書くときは、音質・音量・音調・音節のどの要素によるものかを
  必ず明示してください。「なんとなく似ている」と書かないでください。
- 観念については、需要者がその意味を直ちに理解できると考えられる場合に限り
  書いてください。辞書に載っているだけの意味を根拠にしないでください。
- 出願人名や権利者名から、企業の関係を推測しないでください。
- 判断に必要な情報が一覧にない場合は、その項目を unknown とし、
  needs_review に理由を書いてください。

【候補名】
{candidate_name}

【この候補で使う予定の商品・役務と類似群コード】
{our_classes}

【検索結果（類似群コードが重なるものだけに絞り込み済み）】
{search_results}

「登録できるかどうかを判断しない」の1行が重要です。 これを書かないと、AIは「登録可能と考えられます」と結論を出してきます。その一文があるだけで、現場は調査が終わったものとして扱ってしまいます。

出力形式を固定する

{
  "candidate_name": "",
  "readings": [],
  "risk_level": "高 | 中 | 低",
  "conflicts": [
    {
      "registration_no": "",
      "prior_mark": "",
      "prior_reading": "",
      "overlapping_class_codes": [],
      "appearance": { "close": true, "reason": "" },
      "pronunciation": { "close": true, "factor": "音質 | 音量 | 音調 | 音節", "reason": "" },
      "concept": { "close": false, "reason": "" },
      "status_note": ""
    }
  ],
  "needs_review": [],
  "summary": ""
}

risk_level は3段階に固定します。5段階やパーセント表示にすると、その数字が独り歩きして「85％だから大丈夫」という使われ方をします。

システムへ連携する

結果はスプレッドシートに書き戻します。1行1候補とし、判定、理由の要約、引っかかった登録番号、J-PlatPatの該当ページへのリンクを並べます。原本へ1クリックで飛べる状態にしておくことが、確認時間を左右します。

候補名は商品マスタや発売スケジュールと結び付けて管理します。「この候補は第30類で使う予定、発売は来春」という情報がないと、調査の優先順位が付けられません。

弁理士への依頼は、この仕組みの外で行います。 スプレッドシートの状態を「一次仕分け済み」「弁理士へ依頼中」「結論あり」と更新していく運用にしてください。

人が確認する

全件、人が確認します。運用が安定しても自動化しません。

理由は2つあります。1つは、この仕組みが商標登録の可否を判断していないためです。もう1つは、名前を決めたあとで先行商標が見つかると、パッケージ、広告、ドメイン、登記まで作り直しになり、損害が大きいためです。

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

• 判定が「高」「中」のものを上に並べる
• 引っかかった先行商標の登録番号から、J-PlatPatの該当ページへ直接リンクする
• 類似群コードの重なりを、コードそのものではなく「同じ棚：菓子」のように日本語で表示する
• needs_review に入った項目を色分けする

最終的な調査と判断は弁理士に依頼してください。 この構成で作るのは、弁理士に渡す前に候補を絞るための材料です。

例外に対処する

記録を残す

• 候補名と、その候補で使う予定の商品・役務
• 検索した日、検索に使った称呼、検索条件
• J-PlatPatからダウンロードしたCSVの原本
• AIが付けた判定と理由
• 人が判定を変えた場合、変える前と後の値
• 弁理士に依頼したかどうかと、最終的な結論

最後の2つが、この仕組みの資産になります。 「AIが高と判定したが、弁理士は問題なしと判断した」という記録がたまると、判定の癖が見えます。また、過去に調べた候補名を検索できるようにしておけば、翌年に似た候補が出たときに一から調べずに済みます。