商標の監視サービスから毎週届く類似商標のお知らせを、自社の登録商標と指定商品に照らして仕分け、異議申立てや情報提供を検討すべきものを知財担当へ回す

処理の起点を決める

監視サービスのお知らせのメールが、Zapier の受信用アドレスに届いたことを起点にします。 お知らせは毎週月曜日に届くので、結果も月曜日のうちにそろいます。定時実行にしない理由は、届く曜日が祝日などでずれることがあるためです。 メールの到着を起点にすれば、届いた日に動きます。

転送の元は、知財部の共有アドレスに置いたメールソフトの振り分けの規則です。差出人が監視サービスのアドレスで、件名に決まった語が入っているものだけを転送します。

お知らせの一覧は1通のメールにまとまって届くので、Zap の中で1件ずつに分けます。 Looping by Zapier の「Create Loop From Text」か「Create Loop From Line Items」を使い、ループの後ろの工程が、1件ごとに繰り返し動くようにします。 ループの各回は、Zap の実行履歴に別の実行として記録されます。

1通に何件入っていたかは、ループの前に一覧に書いておきます。 処理された件数と比べれば漏れが分かります。最後の回だけで動かしたい工程は、loop_iteration_is_last が真のときだけ通すフィルタを置きます。

入力データを集める

質を決めるのは、台帳の「重要度」と「監視の対象として登録した語」の2列です。 重要度は、主力の商品のブランドか、終売した商品の名前かといった区別で、同じ程度の近さでも、主力のブランドなら 要検討 に寄せるために使います。監視の対象として登録した語は、監視サービスに伝えた語のことで、その語のどれに当たって届いたお知らせなのかを、AIに知らせるために持ちます。

過去の仕分けの記録は、同じ出願が二度届いたときのためです。 出願の段階で 経過観察 にしたものが、登録されて公報に載ると改めて届きます。出願番号で過去の記録を引けば、前回の理由を読んだうえで仕分けられます。

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

台帳は全件を渡さず、区分が重なる商標だけを引いて渡します。 全件を渡すと関係のない比較が根拠に混ざります。区分の番号は機械的に照合できるので、AIを使わず検索で絞ります。

区分が1つも重ならないものも、捨てずにAIに渡します。 自社の主力のブランドと同じ名前の出願なら、区分が違っても検討が要ることがあるからです。その場合は、重要度が「主力」の商標だけを比較の相手にします。

添付の公報の写しは、この段では読ませません。 図形の商標の見た目の比較は判断が割れやすく、人が画像を見たほうが早いためです。図形を含むものは 要確認_図形 の印を付けて人に回します。

AIへ渡す前に整形する

1. 転送元の確認 … 差出人が監視サービスのアドレスでないメールは、Zap の最初のフィルタで止めます
2. 一覧の分割 … 本文の表を1件ずつの行に分けます。表の形が崩れていた週は、1件目の取り出しで気づけるように件数を記録します
3. 表記の正規化 … 全角と半角、長音記号の揺れ、空白をそろえます。比較の前にそろえないと、同じ語が別の語として扱われます
4. 出願番号での照合 … 過去の仕分けの一覧に同じ出願番号があれば、前回の仕分けと理由を添えます
5. 区分での絞り込み … 区分が重なる自社の商標を台帳から引きます。重ならなければ、重要度が「主力」の商標だけを引きます
6. 期限の計算の準備 … 公報の種類（出願の公開か、商標掲載公報か）と日付を、日付の形式にそろえます

3番目を軽く見ないでください。 「ー」と「－」の違いだけで、近い商標が引けなくなります。 正規化は Formatter のテキストの変換で行い、正規化の前の文字列も残します。

6番目の期限は、AIに計算させません。 日付の計算は Formatter の Date / Time の「Add/Subtract Time」で行います。式の欄に +2 months のように書けば、入力した日付に2か月を足した日付が返ります。 この機能は Professional 以上のプランで使えます。

AIに処理させる

させるのは、1件のお知らせについて、比較の相手の自社の商標のうちどれに近いか、どの観点で近いか、指定商品のどこが重なるかを根拠付きで書き出し、3つのどれかに仕分けることです。

称呼・外観・観念の3つに分けて書かせるのは、人が読むときの手がかりにするためです。 「読みが同じ」「綴りの1字違い」のように観点が書かれていれば、人はその点だけを確かめれば済みます。

仕分けの基準は、台帳の重要度と組み合わせて指示に書きます。

1行目がいちばん起きやすい失敗です。 「似ていると思われるので異議申立てを推奨します」と書かせると、読む人はその結論から読み始め、根拠の確認が浅くなります。 結論の欄を作らないことで、人が自分で判断する形を保ちます。

指示内容を固定する

あなたは食品・日用品メーカーの知財部で、商標の監視サービスから届いた
お知らせを仕分ける担当です。渡された情報だけを根拠にしてください。

【やること】
お知らせの1件（他社の出願または登録）について、比較の相手として渡す
自社の商標のうち近いものを最大3件挙げ、次の3つのどれかに仕分けます。
- 要検討 ..... 近い自社の商標があり、指定商品に重なりがある。
                または、重要度が「主力」の自社の商標と読みが同じか非常に近い
- 経過観察 ... 近い自社の商標はあるが、指定商品の重なりがはっきりしない。
                または、判断に迷う
- 対象外 ..... 近い自社の商標がなく、指定商品の重なりもない
迷ったときに対象外を選ばないでください。迷ったら経過観察です。

【近さの書き方】
- 近いと見た観点を、称呼（読み）・外観（見た目）・観念（意味）に分けて書く
- 各観点について、何と何がどう近いかを具体的に1文で書く
  例：「称呼：お知らせの『ルミナ』と自社の『ルミナス』は語頭3音が同じ」
- 指定商品の重なりは、お知らせの指定商品と自社の指定商品の語を
  そのまま写して並べる

【厳守事項】
- 商標が似ている・似ていないの結論を書かないでください。
- 異議申立てや情報提供をすべきかどうかを書かないでください。
- 期限の日付を計算しないでください。
- 指定商品が「ほか」「等」で省略されているときは、省略された部分を
  推測で補わず、overlap_goods に「不明（一覧で省略）」と書いてください。
- 商標に図形が含まれると書かれているときは、見た目の比較をせず、
  flags に「要確認_図形」を入れてください。
- 渡されていない自社の商標を、知識から持ち出さないでください。
- 過去の仕分けが渡されたときは、その理由を読み、
  今回変えるならその理由を change_reason に書いてください。
- お知らせでないもの（広告、請求、連絡）が渡されたときは、
  仕分けをせず document_type に種類を書いてください。

【お知らせの1件】{notice_item}
【比較の相手（自社の商標）】{own_marks}
【過去の仕分け】{past_triage}

「迷ったら経過観察」を明記しないと、対象外に寄ります。 出力を短く済ませようとして、はっきりしないものを対象外に入れがちです。外したときの損失は、対象外に入れて誰も読まなかった1件がいちばん大きいので、迷いの行き先を指示で決めておきます。

「渡されていない自社の商標を持ち出さない」は、有名な他社のブランドに似た出願で効きます。 書かないと、AIはそちらとの比較を書き始めます。

出力形式を固定する

次の形のJSONで受け取ります。 Extract Structured Data のアクションで、この形を出力の項目として決めておきます。

{
  "document_type": "watch_notice",
  "notice": {
    "application_no": "",
    "registration_no": "",
    "mark_text": "",
    "has_figure": false,
    "classes": [],
    "goods": "",
    "applicant": "",
    "gazette_type": "application_published | registration_gazette",
    "gazette_date": ""
  },
  "matches": [
    { "own_mark": "", "own_reg_no": "",
      "aspects": { "pronunciation": "", "appearance": "", "concept": "" },
      "overlap_goods": "" }
  ],
  "triage": "要検討 | 経過観察 | 対象外",
  "flags": [],
  "change_reason": ""
}

1つ目の理由は、仕分けと根拠を別の欄に置けることです。 triage は Paths の分岐の条件にそのまま使え、根拠は matches に観点ごとに入ります。

2つ目は、gazette_type と gazette_date で期限の計算を機械に渡せることです。 registration_gazette なら、Formatter で gazette_date に2か月を足した日を異議申立ての期限の目安として出します。application_published なら、期限の欄は空にして「登録前」と書きます。 出願中の段階では、登録されるまでのあいだが情報提供を検討できる期間です。

3つ目は、flags で人に回す理由を残せることです。 flags が空でないものは、仕分けにかかわらず 経過観察 以上として扱う規則を Zap の側に置きます。

システムへ連携する

分岐は Paths で作ります。 Paths は、条件に合ったときだけその枝の工程が動く仕組みで、1つの分岐に最大10本の枝を置けます。 本構成で使うのは 要検討 ／ 経過観察 ／ 対象外 の3本です。どの条件にも当たらなかったときに動く枝（フォールバック）を1本だけ指定できるので、triage が想定外の値だったときはそこで人に回します。

Paths は Zap の最後の工程に置く必要があります。 分岐の後に共通の工程を足すことはできないので、一覧への書き込みは各枝の中にそれぞれ置きます。 Paths は Professional 以上のプランで使え、Free では使えません。

Paths とフィルタの工程は、タスクの使用量に数えられません。 数えられるのは、動いた枝の中のアクションだけです。

特許事務所への連絡はつなぎません。 要検討 のものを特許事務所に相談するかは、知財担当が読んで決めます。相談のメールを自動で送ると、検討の要らない件まで費用のかかる依頼になります。

人が確認する

人が1件ずつ読むのは 要検討 だけです。 経過観察 は週に1回、一覧で流し見ます。対象外 は月に1回、件数と出願人の傾向だけを見ます。

1. 要検討 を期限の近い順に読む … 通知に期限の目安が付いているので、近いものから開きます。matches の観点の欄を読み、公報の写しで商標と指定商品を確かめます
2. 特許事務所に相談するかを決める … 相談するものは、知財担当が事務所へ連絡します。正確な期限は事務所に確認します
3. 経過観察 を週に1回流し見る … 気になるものは 要検討 に上げます
4. 仕分けを覆したら記録する … どれを、どちらに変えたか、なぜかを一覧に書きます

2番目の「正確な期限は事務所に確認」を省かないでください。 一覧の期限は発行日に2か月を足した目安で、実際の期限と食い違うことがあります。

目標は、240件をならして1件2分です。 要検討 が多すぎる月は、台帳の重要度の付け方が粗いか、比較の相手を絞れていません。

例外に対処する

上から3行目が、運用でいちばん気づきにくい失敗です。 監視サービスが一覧の書式を変えると、エラーにならずに1件目だけが処理されて残りが落ちることがあります。 トリガーの直後に件数を記録しておくのは、このためです。

記録を残す

• 受け取ったメールの本文と、添付の有無・件数
• 1件ごとの notice（出願番号、商標、区分、指定商品、公報の種類と日付）
• ChatGPT が返したJSONの全文（matches、triage、flags）
• そのとき比較の相手として渡した自社の商標の一覧
• 人が仕分けを覆した記録（どれを、どちらに、なぜ）
• 特許事務所に相談したかと、その結果（異議申立て・情報提供を行ったか、見送ったか）

4つ目で「そのとき渡した比較の相手」を残すのは、台帳が後から変わるためです。 新しく商標を登録したり重要度を付け直したりすると、同じお知らせでも比較の相手が変わります。 当時なぜ 対象外 になったのかを後から確かめるには、そのときの相手が要ります。

最後の行は、要検討 のうち実際に相談したものの割合を見る材料になります。 指示の条件が厳しすぎるか緩すぎるかが分かります。