自社サイトの問い合わせフォームに届く特許・技術・商標のライセンスの問い合わせを分類して知財の担当へ回し、初回の返信を下書きする

処理の起点を決める

フォームの通知メールに「知財問い合わせ」のラベルが付いたことを起点にします。 ラベルは Gmail のフィルタで付けます。通知メールの送信元のアドレスと件名の決まった文字列（「【知財・ライセンスのお問い合わせ】」など）を条件にし、人が手でラベルを付ける運用にはしません。 人が付けると、付け忘れた問い合わせがそのまま漏れます。

New Labeled Email を選ぶのは、検知の期間に制限が無いからです。 New Email Matching Search は届いてから1時間のうちに検知する必要があり、Zap を止めていた時間帯に届いたものを拾えないことがあります。ラベルの付いた時点で拾うので、フィルタを後から直してまとめてラベルを付け直した場合も拾えます。

このトリガーは、同じスレッドに返信が足されたときにも動くとされています。 共有の Gmail から担当者が返信すると、その返信が同じスレッドに入り、もう一度 Zap が動きます。そのままでは同じ問い合わせが2回分類され、2通目の下書きが置かれます。 これを止めるために、次の「データの取得方法」で受付番号による照合を最初に置きます。

入力データを集める

質を決めるのは、技術分野の一覧です。 担当の技術分野を「センサ」とだけ書くと、温度も圧力も流量も同じ担当に寄ります。自社の製品群に沿って、問い合わせに出てくる言葉で手がかりを書きます。 知財部の3名で30分ほどあれば作れます。

相手が選んだ問い合わせの種類は、参考にとどめます。 売り込みも「特許」で届き、商標の相談が「その他」で届きます。AIには「相手が選んだ種類」として渡し、本文と食い違えば本文を優先させます。

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

受付番号での検索を、Zap の最初の段に置きます。 見つかったら、そこで止めます。受付番号はフォームが通知メールに付ける番号を使い、無いフォームならメールの Message ID で代えます。

相手のメールアドレスは、通知メールの送信元ではありません。 送信元はフォームの仕組みのアドレスなので、返信の宛先は本文の「メールアドレス」の欄から取ります。ここを取り違えると、下書きの宛先がフォームの仕組みになります。 AIに写し出させた値を使わず、本文の決まった位置から取る設定にしておきます。

AIへ渡す前に整形する

1. 署名と定型の文言を落とす … 通知メールの末尾に付くフォームの仕組みの案内や、プライバシーポリシーの定型文を除きます
2. 本文の長さを確かめる … 特許番号の一覧を何十件も貼った売り込みがあります。決めた長さを超えるものは、先頭から切って渡し、「本文を切った」と台帳に印を付けます
3. 言語を確かめる … 英語の本文はそのまま渡します。訳してから分類させる段を置きません。 訳す段で言い回しが丸まり、「警告」の調子が消えることがあります
4. 添付の有無を確かめる … フォームで添付を受ける場合、添付の名前だけを台帳に残し、添付の中身はAIに渡しません
5. 社内からの送信を除く … 社員が試しに送ったものは、メールアドレスのドメインで分けて止めます

4番目で添付を渡さないのは、相手の未公開の発明の説明が添付されていることがあるからです。 自社の仕組みで読み込むと、後で「御社に開示した」と言われる材料になります（第13章）。

AIに処理させる

させるのは、問い合わせを3つの軸で分類し、本文に書かれた特許番号・登録番号と期限を写し出すことです。 分類の値は決めた中から選ばせます。

purpose の中で、infringement_notice だけは扱いが別です。 「侵害」「警告」という言葉が無くても、「貴社製品〇〇が当社特許第〇〇号の請求項に該当すると考えております」「ご見解をお伺いしたく」のような書き方はこちらに入れます。迷ったら infringement_notice を選ぶよう指示します。取り違えたときの損が大きいのは、指摘を普通の問い合わせとして扱うほうだからです。

4行目がいちばん起きやすい失敗です。 社名に「IP」「Patent」が入っているだけで broker にしがちです。party は本文に書かれた自己紹介から選ばせ、書かれていなければ unclear にします。 相手を取り違えた下書きは、事業会社の引き合いに定型の断りを返すことになります。

初回の返信の下書きは、分類の後に別の AI by Zapier のステップで作ります。 下書きの段には、分類の結果と、目的ごとに決めた「書くこと」「書かないこと」だけを渡します。

指示内容を固定する

分類のステップの指示です。

あなたは計測機器メーカーの知財部で、自社サイトの知財・ライセンスの
問い合わせを受け付ける担当です。下の【問い合わせ】を読み、
3つの軸で分類してください。本文に書かれていることだけで判断し、
書かれていないことを推測しないでください。

【分類の軸と選べる値】
subject: patent / know_how / trademark / other / unclear
party: company / academia / broker / individual / unclear
purpose: license_in_request / offer_to_us / infringement_notice /
         collaboration / permission_use / sales_pitch / question / unclear

【厳守事項】
- 相手が選んだ種類（form_category）は参考です。本文と食い違えば
  本文を優先し、mismatch を true にしてください。
- 自社の製品・行為が相手の権利に触れる、または触れるおそれがある
  という趣旨の記述があれば、「侵害」「警告」の言葉が無くても
  purpose は infringement_notice にしてください。
  迷ったときも infringement_notice を選んでください。
- party は本文に書かれた自己紹介だけで選んでください。
  社名の文字から推測しないでください。書かれていなければ unclear。
- 本文に書かれた特許番号・登録番号・出願番号は、書かれたとおりに
  写してください。桁を補ったり、書式を直したりしないでください。
- 回答の期限・日付が書かれていれば、書かれたとおりに写してください。
- 特許が誰のものか、侵害に当たるか、許諾すべきかを書かないでください。
- tech_field は【技術分野の一覧】から1つ選び、当てはまらなければ
  none にしてください。
- reason には、分類の根拠にした本文の一文をそのまま写してください。

【技術分野の一覧】{tech_fields}
【問い合わせ】
受付番号: {inquiry_id}
会社名: {company} / 部署: {dept} / 氏名: {name}
相手が選んだ種類: {form_category}
本文: {body}

「迷ったら infringement_notice」を書かないと、question に寄ります。 指摘に当たる問い合わせの多くは「ご見解をお伺いしたい」という質問の形で書かれます。形ではなく、自社の製品が相手の権利に関わるという趣旨で選ばせます。

下書きのステップには、目的ごとの決まりを渡します。

【初回の返信で書くこと】
- license_in_request: 受付のお礼。検討のために、対象と考えている
  特許番号または技術の内容、実施を考えている製品・地域・期間、
  会社の概要をお知らせいただきたいこと。担当から改めて連絡すること。
- offer_to_us: 受付のお礼。社内で確認し、関心がある場合に限り
  当社から連絡すること。
- collaboration / permission_use / question: 受付のお礼と、担当から
  改めて連絡すること。
【書かないこと】
- 許諾する・しない、前向きに検討する、などの見通し
- 料率・一時金・条件
- どの特許が相手の製品・用途に関係するか
- 秘密の情報を送ってほしいという依頼（秘密保持の取り決めの前）
- 本文は日本語なら300字以内。英語の問い合わせには英語で書く
- 署名は書かない（Gmail の署名を使う）

「どの特許が関係するか」を書かないことを、ここで明記します。 第3章の（c）の、担当者が親切心で書いてしまう一文です。初回の返信は、相手から情報をもらう側に立つと決めておきます。

出力形式を固定する

分類のステップは、次の形で受け取ります。

{
  "inquiry_id": "",
  "subject": "patent | know_how | trademark | other | unclear",
  "party": "company | academia | broker | individual | unclear",
  "purpose": "license_in_request | offer_to_us | infringement_notice | collaboration | permission_use | sales_pitch | question | unclear",
  "form_category": "",
  "mismatch": false,
  "tech_field": "",
  "cited_numbers": [""],
  "deadline_text": "",
  "language": "ja | en | other",
  "reason": ""
}

1つ目の理由は、3つの軸を別々の項目にして、分岐の条件にそのまま使えることです。 Paths の条件は「purpose が infringement_notice と等しい」のように書けます。自由文の要約から分岐を作ると、言い回し1つで別の担当に回ります。

2つ目は、cited_numbers と deadline_text を台帳に残せることです。 特許番号が並んでいれば、担当者はそこから管理システムを引けます。期限が書かれていれば、台帳の表示で上に出します。

分岐は次のとおりです。

1行目は、他の分岐の条件に「purpose が infringement_notice でない」を足して、ほかの行と同時に動かないようにします。 Paths は条件に合う分岐をすべて動かすので、排他にしておかないと、指摘に下書きが置かれる経路が残ります。

システムへ連携する

相手への返信は Create Draft で下書きにするだけです。 Zapier の Gmail には送信の操作もありますが、相手への送信には使いません。 送信の操作を使うのは、知財部長と法務への社内の知らせだけで、宛先は Zap の設定で固定の社内のアドレスにします。 宛先をAIの出力から取る設定にはしません。

特許の管理システムとはつなぎません。 番号が自社の特許かどうかは、担当者が管理システムで確かめます。つなぐと、自社の特許の情報が分類の段に流れる経路ができます。

人が確認する

下書きは全件、担当者が開いて確かめてから送ります。 目標は1件あたり6分です。

1. 台帳の分類を見る … reason の一文と分類が合っているかを確かめます。違えば台帳の分類を直し、担当を付け替えます
2. 相手を確かめる … party が unclear や broker のものは、会社のサイトを開いて事業を確かめます
3. 特許番号を確かめる … cited_numbers があれば管理システムを引き、自社の特許か他社の特許かを見ます。他社の特許で、自社の製品名が本文にあれば、指摘として扱い直します
4. 下書きを直して送る … 書かないことが入っていないかを読み、送ります

3番目を省かないでください。 AIが offer_to_us と分類した問い合わせでも、挙げられた特許が自社の製品の分野と重なるなら、売り込みの形をとった指摘のことがあります。 その判断は管理システムと製品を知っている担当者にしかできません。

権利侵害の指摘は、届いた日のうちに知財部長が本文を読みます。 返信を誰がいつどの文面で出すかは、法務と決めます。

例外に対処する

上の2行は、組み始めの週に必ず起きます。 番号の照合が効かないと、担当者が返信するたびに同じ問い合わせの下書きが増えます。 試しの送信で、返信した後の Zap の動きを最初に確かめます。

記録を残す

• 通知メールの受信日時、受付番号、相手が選んだ種類
• 分類の結果の全項目（subject・party・purpose・reason・cited_numbers・deadline_text）
• 分岐で決まった担当と、知らせた日時
• 下書きを作った日時と、担当者が送った日時
• 担当者が分類を直した記録（どの軸を、何から何に変えたか）
• 権利侵害の指摘として扱ったものの一覧と、責任者が読んだ日時

5つ目は、技術分野の一覧と指示を直す材料です。 同じ軸の直しが続くなら、指示の書き方か一覧の手がかりの語が足りません。月に1回、直しの多い順に見直します。