特許事務所が商標の存続期間の満了日を台帳から拾い、顧客ごとに更新するかを尋ねる通知文を下書きして、確認を経て送る
特許事務所が管理する登録商標の台帳から、存続期間の満了が近づいたものを毎月拾い、顧客ごとにまとめます。更新するか、名義や住所に変わりがないかを尋ねる通知文をAIが下書きし、弁理士が確かめて送ります。
- 生成AI
- ChatGPT/Claude/Gemini
- 連携・自動化
- Make/n8n/Power Automate/Zapier
- 対象業界
- IT・SaaS/士業/小売/製造
- 対象部門
- 法務/知財
- 対象業務
- 台帳・マスタ管理/書類作成
- 主な課題
- 人手が足りない/書類作成に時間がかかる/期限・対応漏れが起きる
- AIで行う処理
- 生成
- 主な効果
- 品質標準化/工数削減/機会損失防止
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 担当者が毎月初めに台帳を開き、満了日が7か月後の月に入る商標を絞り込む
- 1件ずつ、権利が生きているか、すでに顧客から更新しない旨の連絡が無いかを確かめる
- 顧客ごとに並べ替え、区分の数から料金表を見て費用の見積もりを出す
- 顧客ごとに通知文を書く。商標の一覧の表を貼り、申請できる期間と答えの期限を書く
- 権利者の名称や住所が、顧客の今の会社名・所在地と違っていないかを見て、違えば文中で尋ねる
- 担当の弁理士に確認を頼み、直しが入れば書き直す
- Outlook で送り、台帳の通知の状態を「1回目送付済み」にする
- 自動毎月1日の朝にシナリオが動く
- 自動台帳から、満了日が7か月後の月に入り、通知の状態が「未通知」の商標を拾う
- 自動「更新しない」「手続中」「顧客が自社で管理」の商標を除く
- 自動区分の数と料金表から、費用の見積もりを計算する
- 自動顧客ごとにまとめ、商標の一覧の表を作る
- 自動AIが表の前後の通知文を下書きする。名義と住所の違いがあれば、尋ねる文を入れる
- 自動下書きに表を差し込み、Outlook の下書きに入れる。台帳の状態を「下書き作成済み」にする
- 人担当者が表の番号と日付を台帳と照らし、弁理士が文面を確かめる
- 人担当者が送り、台帳の状態を「1回目送付済み」にする
各工程の詳しい説明を読む
- 担当者が毎月初めに台帳を開き、満了日が7か月後の月に入る商標を絞り込む
- 1件ずつ、権利が生きているか、すでに顧客から更新しない旨の連絡が無いかを確かめる
- 顧客ごとに並べ替え、区分の数から料金表を見て費用の見積もりを出す
- 顧客ごとに通知文を書く。商標の一覧の表を貼り、申請できる期間と答えの期限を書く
- 権利者の名称や住所が、顧客の今の会社名・所在地と違っていないかを見て、違えば文中で尋ねる
- 担当の弁理士に確認を頼み、直しが入れば書き直す
- Outlook で送り、台帳の通知の状態を「1回目送付済み」にする
(a)通知が漏れると、権利が消える。 商標法では、決められた期間内に更新登録の申請をしないと、商標権は存続期間の満了の時にさかのぼって消滅したものとみなすとされています。通知が漏れた1件は、顧客の事業の看板を失わせることになりかねません。
(b)顧客ごとの表を作るのに時間がかかる。 1つの顧客に10件の商標があれば、10行の表に、登録番号、商標、区分の数、満了日、申請できる期間、費用を並べます。3番と4番に、1件あたりの時間の半分以上がかかります。
(c)文面が担当者でばらつく。 申請できる期間の書き方、答えの期限の書き方、名義の確認の尋ね方が担当者ごとに違います。顧客から「前回の通知と書いてあることが違う」と問い合わせが来ることがあります。
(d)名義と住所の違いを見落とす。 顧客が合併で社名を変えていたり、本社を移していたりしても、台帳の権利者の名称と住所は登録のときのままです。 更新の直前に気づくと、手続の段取りが変わります。
- 【自動】 毎月1日の朝にシナリオが動く
- 【自動】 台帳から、満了日が7か月後の月に入り、通知の状態が「未通知」の商標を拾う
- 【自動】 「更新しない」「手続中」「顧客が自社で管理」の商標を除く
- 【自動】 区分の数と料金表から、費用の見積もりを計算する
- 【自動】 顧客ごとにまとめ、商標の一覧の表を作る
- 【自動】 AIが表の前後の通知文を下書きする。名義と住所の違いがあれば、尋ねる文を入れる
- 【自動】 下書きに表を差し込み、Outlook の下書きに入れる。台帳の状態を「下書き作成済み」にする
- 【人】 担当者が表の番号と日付を台帳と照らし、弁理士が文面を確かめる
- 【人】 担当者が送り、台帳の状態を「1回目送付済み」にする
5番目と7番目で表をワークフローが作るのは、意図してのことです。 番号と日付と金額は、AIに書き写させると、どこかで1桁違えます。 台帳の値をそのまま表にすれば、写し間違いは起きません。
8番目は省きません。 下書きを作るまでは機械が行い、顧客に届くものは必ず人が確かめてから送ります。 期限の通知は、事務所が顧客に負う責任の中心です。
2回目の通知も同じ流れです。 満了の4か月前の月に入っても答えの無い商標を拾い、答えの期限が近いことを伝える下書きを作ります。そこでも答えが無ければ、満了の1か月前の月に担当の弁理士の一覧に載り、電話で確かめます。 通知を3段階にしておくことで、1回目のメールが迷惑メールに入っていた顧客も拾えます。
02今回想定するシステム構成
年金管理の台帳(Google スプレッドシート:登録番号・商標・権利者・区分の数・満了日・顧客・状態) ▼【トリガー】Make のスケジュール(毎月1日 7時) Make のシナリオ ├──▶ Search Rows:満了日が7か月後の月 かつ 状態=未通知 ├──▶ 除く:更新しない/手続中/顧客が自社で管理 ├──▶ 料金表を引き、区分の数から見積もりを計算 ├──▶ Array aggregator(Group by:顧客コード)で顧客ごとにまとめる ├──▶ 顧客の情報(今の会社名・所在地・担当者・言語)を引く ├──▶ Anthropic Claude(Make an API Call、構造化出力) │ 表の前後の通知文・名義と住所の確認の文 ├──▶ 表を差し込み、Microsoft 365 Email の Create a Draft Email └──▶ 台帳の状態を Update a Row で「下書き作成済み」 ▼ 【担当者と弁理士】表と文面を確かめて送る
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| ワークフロー | Make | n8n、Zapier、Power Automate |
| 生成AI | Claude API(Make の Anthropic Claude アプリ) | OpenAI API、Gemini API |
| 連携 | Google スプレッドシート(年金管理の台帳・顧客の情報・料金表・通知の記録) | Microsoft 365 のリスト |
| メール | Microsoft 365 のメール(Outlook の下書き) | Gmail |
新しく足すのは、Make のシナリオ2本(1回目の通知と、2回目の通知)だけです。 台帳、顧客の情報、料金表はいまあるものを使い、台帳に「通知の状態」と「顧客の答え」の列を足すのが最初の準備作業です。
入口は Make のスケジュールです。 シナリオの実行は、一定の間隔、1回だけ、毎日、平日、毎週、毎月、日を指定、必要なときだけ、から選べます。毎月1日の朝に動かします。
顧客ごとにまとめるのは、Array aggregator の Group by です。 Make のヘルプでは、Group by に入れた式の値ごとに出力のまとまりが1つずつ作られ、Key にその値、Array にその値に当たるまとまりのデータが入るとされています。顧客コードで分ければ、顧客ごとに商標の配列が1つできます。
出口は Microsoft 365 Email の Create a Draft Email です。 Make のページには、下書きを作る Create a Draft Email、下書きを送る Send a Draft Email などのモジュールが並んでいます。この構成は下書きを作るところまでで、Send a Draft Email は使いません。
03どうやって実装するのか
処理の起点を決める
毎月1日の朝7時に、1回目の通知のシナリオを動かします。 満了日が「7か月後の月」に入る商標を拾います。たとえば10月1日の実行なら、翌年5月中に満了する商標が対象です。
| 通知 | 拾う条件 | 送るもの |
|---|---|---|
| 1回目 | 満了日が7か月後の月、状態が「未通知」 | 更新するかの問いと、商標の一覧 |
| 2回目 | 満了日が4か月後の月、状態が「1回目送付済み」で答えが空 | 答えの期限が近いことと、同じ一覧 |
| 弁理士へ | 満了日が1か月後の月、答えが空 | 顧客名と商標の一覧を担当の弁理士に。電話で確かめる |
1回目を7か月前にしているのは、申請できる期間の始まりから逆算した値です。 商標法では、更新登録の申請は満了前6月から満了の日までの間にするとされています。期間に入る1か月前に届けば、顧客は社内で決める時間が取れ、事務所は期間に入ってすぐに申請できます。
2回目のシナリオは、1回目と同じ日に続けて動かします。 別の日にすると、月初の忙しい時期に2回確認の作業が発生します。
2回目では、答えの来ていない商標だけを表に載せます。 10件のうち7件に答えをもらっている顧客に、10件全部の表を送り直すと、どれが残っているのかを顧客に探させることになります。 台帳の「顧客の答え」の列が空の行だけを拾い、本文には「残り3件について」と件数を書かせます。
満了の日を過ぎたものは、このシナリオでは扱いません。 商標法では、期間内に申請できなかったときも、経済産業省令で定める期間内なら申請できるとされていますが、その場合は割増登録料がかかり、事情の確認が要ります。 満了日を過ぎて答えが無い商標は、弁理士の一覧にだけ出します。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 対象の商標 | 登録番号、商標(文字・図形の別と表示)、権利者の名称と住所、区分の数、満了日、登録料の分割納付の有無 | 年金管理の台帳 |
| 顧客の情報 | 顧客コード、今の会社名、今の所在地、担当者の名前とメールアドレス、通知の言語 | 顧客の情報の表 |
| 料金表 | 区分の数ごとの事務所の手数料と、更新の登録料の額 | 料金表の表 |
| 過去の答え | 前回の更新のときの答え、「この商標は更新しない」と聞いている記録 | 台帳の「顧客の答え」の列 |
| 通知文の型 | 事務所として必ず入れる文(申請できる期間、答えの期限、問い合わせ先) | 自社で用意する文例 |
質を決めるのは、料金表と通知文の型です。 料金表の登録料の額は、商標法では「43,600円を超えない範囲内で政令で定める額に区分の数を乗じて得た額」とされていて、実際の額は政令で決まります。事務所が特許庁の最新の料金を確かめて表に入れ、改定のたびに直します。 AIには料金を書かせません。
権利者の名称と住所を顧客の今の情報と並べるのは、第3章の(d)のためです。 更新登録の申請書には申請人の氏名又は名称及び住所を書くとされており、台帳の権利者と顧客の今の会社名が違えば、通知の中で尋ねます。
データの取得方法を決める
台帳は Search Rows で、満了日と通知の状態で絞って読みます。 Make の Search Rows は、条件を AND と OR でつなげて絞り込め、日付で比べるときは表の見出しを有効にして、列の種類を日付にします。
| 取るもの | どこから | 何に使うか |
|---|---|---|
| 対象の商標の行 | 台帳(Search Rows:満了日と状態) | 通知の対象 |
| 顧客の情報 | 顧客の情報の表(Search Rows:顧客コード) | 宛先と、名義・住所の照合 |
| 料金表 | 料金表の表(Search Rows:区分の数) | 費用の見積もり |
| 顧客ごとの配列 | Array aggregator(Group by:顧客コード) | 1通に入れる商標の一覧 |
Array aggregator で顧客ごとにまとめるときは、後で使う項目を集める項目に入れておきます。 Make のヘルプでは、集める元のモジュールと aggregator の間のモジュールの項目を後で使うなら、aggregator の設定に含めるよう案内されています。料金表から計算した見積もりを入れ忘れると、表の費用の列が空になります。
AIへ渡す前に整形する
- 除く商標の判定 … 台帳の状態が「更新しない」「手続中」「顧客が自社で管理」のものを外します
- 申請できる期間の計算 … 満了日から、期間の始まり(満了の6か月前の日)と終わり(満了の日)を計算します
- 答えの期限の計算 … 満了の3か月前の日を、事務所の答えの期限にします。土日と祝日なら前の営業日にします
- 費用の見積もり … 区分の数と料金表から、登録料と事務所の手数料を計算します
- 名義と住所の照合 … 台帳の権利者の名称・住所と、顧客の今の会社名・所在地を比べ、違えば印を付けます
- 分割納付の印 … 登録料を分割で納めた商標は、印を付けて表の備考に出します
- 表の作成 … 顧客ごとの配列から、通知に差し込む表を HTML で組み立てます
2番目から4番目は、AIに任せずワークフローの側で計算します。 日付と金額は、計算の式が決まっていれば機械のほうが確かです。AIの出力には、これらの値を入れる場所そのものを作りません。
5番目の照合は、完全一致で比べません。 「株式会社」の位置や全角・半角の違いで、同じ会社を違うと判定します。空白と記号をそろえてから比べ、違えば印を付けるだけにして、尋ねる文の要否は担当者が見ます。
AIに処理させる
させるのは、表の前後に置く通知文を下書きすることだけです。
| 書く部分 | 中身 |
|---|---|
| 書き出し | 顧客の担当者の名前と、いつも管理を任されていることへの一言 |
| 本題 | 下の表の商標が、存続期間の満了の時期を迎えること |
| 問いかけ | 商標ごとに「更新する」「更新しない」「相談したい」のどれかを答えてほしいこと |
| 名義・住所の確認 | 印のある顧客にだけ、権利者の名称・住所が今のものと違うので、変わったかを教えてほしいこと |
| 締め | 答えの期限、問い合わせ先 |
申請できる期間と答えの期限は、文の中では差し込みの記号で書かせます。 {{APPLY_FROM}} {{APPLY_TO}} {{REPLY_BY}} の記号を置かせ、ワークフローが計算した日付に置き換えます。 記号が欠けていれば、下書きにせずに担当者へ回します。
| させないこと | 理由 |
|---|---|
| 登録番号・満了日・区分の数・金額を書く | 写し間違いが起きる。表と差し込みで入れる |
| 更新を勧める、更新しなくてよいと言う | 更新するかは顧客の事業の判断 |
| 使っていない商標について意見を言う | 使っているかを事務所は知らない。尋ねるのは担当者 |
| 満了後の申請や回復の案内 | 割増登録料や事情の確認が要る。弁理士が個別に話す |
| 名義の変更の手続の説明 | 事情によって手続が違う。弁理士が答える |
2行目がいちばん起きやすい失敗です。 「長くお使いの大切な商標ですので、ぜひ更新をご検討ください」と書くのは自然に見えますが、整理を考えている顧客には、売り込みに読めます。 逆に「ご不要であれば更新は不要です」も、事務所の判断を示したことになります。
指示内容を固定する
あなたは特許事務所の年金管理の担当として、顧客に送る通知の下書きを書きます。
顧客が管理を任せている登録商標が、存続期間の満了の時期を迎えることを知らせ、
商標ごとに更新するかを尋ねる文です。
【入力】
- 顧客の会社名と担当者名:{client}
- 通知の回:{round}(1回目/2回目)
- この顧客の商標の件数:{mark_count}
- 名義・住所の違いの印:{name_address_flag}
- 前回の更新のときの答え:{previous_answers}
- 事務所の通知文の型:{template}
【書く部分】
- intro:書き出しと本題。下に表があることを書いてください。
- question:商標ごとに「更新する」「更新しない」「相談したい」の
どれかを、{{REPLY_BY}} までに返信で知らせてほしいことを書いてください。
申請できる期間は {{APPLY_FROM}} から {{APPLY_TO}} までと書いてください。
- name_address:名義・住所の違いの印が true のときだけ、
表の権利者の名称・住所が今のものと違っているかを尋ねる文を書いてください。
false のときは空にしてください。
- closing:問い合わせ先と結び。
【厳守事項】
- 登録番号、満了日、区分の数、金額を文の中に書かないでください。
それらは表に入ります。日付は上の記号のとおりに書いてください。
- 更新を勧める表現も、更新しなくてよいという表現も書かないでください。
- 商標を使っているかどうかについて、意見を書かないでください。
- 満了日を過ぎた後の手続、権利の回復、名義の変更の手続を説明しないでください。
- 2回目の通知では、答えの期限が近いことを、責める調子にせず書いてください。
- 事務所の通知文の型にある文は、言い回しを変えずに含めてください。
「文の中に番号と日付を書かない」と「記号のとおりに書く」を対にしています。 片方だけだと、日付を書かない代わりに「来年5月頃」とぼかした表現を足します。記号を置く場所を決めておけば、ぼかす余地がありません。
事務所の通知文の型を「言い回しを変えずに含める」とするのは、第3章の(c)のためです。 申請できる期間や答えの期限の言い方を型で固定し、AIには型の外側だけを書かせます。
出力形式を固定する
Make an API Call で Messages API を呼び、構造化出力で次の形のJSONを受け取ります。 Claude API の構造化出力は、output_config.format に type: "json_schema" でスキーマを渡す形です。
{
"subject": "",
"intro": "",
"question": "",
"name_address": "",
"closing": "",
"placeholders_used": ["{{APPLY_FROM}}", "{{APPLY_TO}}", "{{REPLY_BY}}"]
}
1つ目の理由は、表を間に差し込めることです。 intro の後に表、表の後に question と name_address、最後に closing を並べます。文章1本で返ってくると、表を入れる位置を探すことになります。
2つ目は、差し込みの記号を確かめられることです。 question の中に3つの記号がそろっているかをワークフローが確かめ、欠けていれば下書きにせずに担当者へ回します。 記号を置き換えた後に、文の中に数字の並び(4桁の年や7桁の番号)が残っていないかも確かめます。
差し込む表は次の形です。
| 登録番号 | 商標 | 権利者 | 区分の数 | 満了日 | 費用の見積もり | 備考 |
|---|---|---|---|---|---|---|
| (台帳の値) | (台帳の値) | (台帳の値) | (台帳の値) | (台帳の値) | (料金表から計算) | 分割納付・名義の違い |
表のすべての値は、台帳と料金表から来ます。 担当者は第7章の「人間の確認」で、この表を台帳と照らすだけで済みます。
注意が2つあります。 公式ドキュメントでは、構造化出力でも、出力がトークンの上限で切れた場合(stop_reason が max_tokens)と、応答が断られた場合(refusal)は、スキーマに合わないことがあるとされています。どちらも下書きにせず担当者へ回します。また enum の値は大文字小文字だけ違って返ることがあるとされているので、比べるときは大文字小文字を区別しません。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 年金管理の台帳 | Google Sheets の Search Rows / Update a Row | 対象を拾い、通知の状態を書く |
| 顧客の情報・料金表 | Google Sheets の Search Rows | 宛先、名義・住所の照合、見積もり |
| 顧客ごとのまとめ | Array aggregator(Group by) | 顧客ごとの商標の配列 |
| Claude API | Anthropic Claude の Make an API Call(構造化出力) | 通知文の下書き |
| メール | Microsoft 365 Email の Create a Draft Email | 担当者のメールボックスに下書き |
知財管理のシステムには書き込みません。 台帳は毎月書き出したスプレッドシートで、通知の状態と顧客の答えは、担当者がシステムの側にも入れます。 システムとの二重の管理になりますが、期限の正本をワークフローが書き換える経路を作らないためです。
下書きは担当者のメールボックスに作ります。 共有のメールボックスにすると、誰が確かめたかが分からなくなります。顧客の担当の弁理士ごとに、その弁理士と組む担当者のメールボックスに入れます。
人が確認する
下書きはすべて、担当者と弁理士が確かめてから送ります。
- 担当者が表を台帳と照らす … 登録番号・満了日・区分の数の3つを、台帳の行と見比べます。ワークフローが写しているので食い違いは起きないはずですが、台帳の側の誤りがここで見つかります
- 担当者が除いた商標を確かめる … 「更新しない」「手続中」で外した商標が、本当にそうかを台帳の記録で確かめます
- 弁理士が文面を確かめる … 勧める・止める表現が無いか、名義・住所の尋ね方が適切かを見ます
- 担当者が送り、状態を「1回目送付済み」にする
2番目を省かないでください。 外した商標は通知に載らず、顧客は通知が来なかったことに気づけません。 「更新しない」と聞いた記録が誤っていれば、その商標は誰にも気づかれないまま満了します。
2回目の下書きは、送る直前に台帳の答えの列をもう一度見ます。 シナリオが動いた朝から送るまでの間に、顧客が答えてくることがあります。答えた顧客に催促が届くと、事務所の管理を疑われます。
顧客からの答えは、担当者が台帳の「顧客の答え」の列に入れます。 「更新する」と答えた商標は、弁理士が申請の準備に入ります。答えの記録を自動にしないのは、返信の文が「たぶん更新」「社内で確認中」のようにあいまいなことが多いためです。
例外に対処する
| 起きること | 対応 |
|---|---|
| 顧客の担当者のメールアドレスが空 | 下書きを作らず、担当者の一覧に出す |
| 顧客との契約が終わっている | 顧客の情報の状態を見て除き、弁理士の一覧に出す |
| 1つの顧客の商標が30件を超える | 表は添付の一覧にし、本文には件数だけを書く |
| 差し込みの記号が欠けた | 下書きにせず、担当者へ回す |
| 記号の置き換え後に数字の並びが残った | 下書きにはするが、件名に【要確認】を付ける |
| 名義・住所の照合で判断がつかない | 印を付け、尋ねる文を入れるかを担当者が決める |
| 外国の顧客 | 通知の言語の列が日本語以外なら、下書きを作らず弁理士へ |
| 満了日を過ぎて答えが無い | このシナリオでは扱わない。弁理士の一覧に出す |
| APIが応答しない | 台帳の状態を「未通知」のまま残し、翌日にやり直す |
上から2行目までは、台帳と顧客の情報の整備の問題です。 最初の数か月は、連絡先の抜けと契約の終わった顧客の残りが目立ちます。 通知のたびに直していくと、台帳の質が上がります。
満了日を過ぎた商標を弁理士に回すのは、条文の扱いが変わるためです。 商標法では、省令で定める期間にも申請がなければ商標権はさかのぼって消滅したものとみなされ、その後は原商標権者が省令で定める期間内に限って申請できますが、故意に申請しなかったと認められる場合は除くとされています。顧客が「更新しない」と答えた記録は、日付と答えた人まで残します。
外国の顧客を外しているのは、通知の型が国内向けだからです。 外国の代理人を通す顧客は、やり取りの作法も期限の考え方も違うので、弁理士が個別に扱います。
記録を残す
- その月に拾った商標の一覧と、除いた商標と除いた理由
- 顧客ごとの下書きの内容(AIが書いた文と、差し込んだ表)
- 送った日時、送った人、確かめた弁理士
- 顧客の答えと、答えが来た日
- 2回目の通知と、弁理士への一覧に出た商標
- 料金表の版(見積もりに使った額)
3つ目が、この構成で最も大事な記録です。 期限の通知は、いつ、誰が、何を送ったかを後から示せることが事務所を守ります。送った通知のメールそのものも、顧客ごとのフォルダに残します。
最後の行は、料金の改定のときに効きます。 見積もりの額が改定の前か後かを、通知ごとに追えるようにしておきます。
04実装レベルの3段階
最小構成では、表を作る時間が残ります。 1件15分のうち、短くなるのは文を書く③の一部だけです。 半自動化で、1件15分が9分程度になります。 洗い出しと表はワークフローが作りますが、見積もりと通知文は担当者が書きます。本格構成で6分になり、この段階が本記事の想定です。 段階を飛ばさないでください。 半自動化で数か月、洗い出しの結果と担当者の手作業の結果を並べると、台帳の状態の列の抜けと、顧客の情報の古さが先に分かります。 そこを直してから下書きまで進めます。
05工数削減シミュレーション
導入後 100件 × 6分 ÷ 60 = 10 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 数百の顧客から数千件の登録商標の管理を任され、存続期間の満了日を台帳で持っている特許事務所。毎月、満了の近い商標を拾って顧客ごとに更新の意思を尋ねる通知を、担当者が台帳を見ながら1通ずつ書いている場合。1つの顧客が多くの商標を持ち、商標ごとに区分の数も満了日も違うため、通知の表を作るのに時間がかかっている場合。
- 管理している商標が数十件で、満了日の管理と通知を弁理士が自分で回せている場合。台帳に満了日・区分の数・顧客の連絡先がそろっておらず、まず台帳の整備が要る場合。更新の手続を顧客が自社で行い、事務所が期限の管理を任されていない場合。なお、更新するかどうかの判断、更新の手続、満了後の申請や回復の要否の判断は、この構成では代替できません。
07最小構成で試す方法
- 先月通知した顧客から10社を選ぶ(商標が1件の顧客、10件以上の顧客、名義が違う顧客を混ぜる)
- 台帳から、その10社の商標の一覧と、顧客の今の会社名・所在地を取り出す
- 手元のAIサービスに、第7章のプロンプトと顧客の情報を貼り、表の前後の文を書かせる
- 当時実際に送った通知と並べ、勧める表現や番号・日付の混入が無いかを見る
- 弁理士に、この文面で送れるかを聞く
10社は必ずやってください。 シナリオを組む前に、「表の前後の文だけをAIに任せる形で、通知として成り立つか」を確かめます。
| 出てきた内容 | 判断 |
|---|---|
| 弁理士が「このまま送れる」と答えた | シナリオに進む |
| 更新を勧める一文が入った | 指示の書き方で直る。構成は有効 |
| 台帳の権利者と顧客の今の情報が合わない顧客が多い | 台帳の整備が先。 AIの問題ではない |
3行目が出ても失敗ではありません。 名義や住所の違いは、更新の直前に気づくより、通知の時点で分かるほうが顧客にとっても助かります。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 文の中に満了日や番号を書く | 番号と日付を書かせず、記号で置く。置き換え後に数字の並びを確かめる |
| 「来年5月頃」とぼかす | 記号のとおりに書くと明記する |
| 更新を勧める・止める表現が入る | どちらも書かないと明記する。弁理士が確かめる |
| 費用の列が空になる | Array aggregator の集める項目に見積もりを入れる |
| 除いた商標の記録が誤っている | 担当者が除いた商標を毎回確かめる |
| 名義の違いを表記ゆれで誤判定する | 空白と記号をそろえてから比べ、印だけを付ける |
| 料金が古いまま | 料金表を事務所が確かめて直し、版を記録する |
| 満了日を過ぎたものに通常の通知が出る | このシナリオでは扱わず、弁理士の一覧へ |
| 下書きが共有のメールボックスに散らばる | 担当者ごとのメールボックスに作る |
| 顧客の答えを自動で台帳に入れたくなる | 返信はあいまいなことが多い。担当者が入れる |
| 外国の顧客に国内向けの文が出る | 言語の列で分け、弁理士が個別に扱う |
| 分割納付の商標の扱いが漏れる | 台帳に分割納付の印を持ち、表の備考に出す |
上の3行が、この構成の失敗のほとんどです。 どれも、AIの文が期限や判断に踏み込むという同じ問題です。番号と日付は表と記号に、判断は顧客と弁理士に置く線を、指示と確認で守ります。
最後の行も見落とされがちです。 商標法では、設定の登録のときの登録料を分割して納めた場合、後期の分を存続期間の満了前5年までに納めるとされています。更新とは別の期限ですが、同じ台帳から同じ仕組みで拾えます。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 顧客の会社名と担当者の連絡先、管理している商標の一覧、更新するかの答え、費用の見積もりです。未公表の事業の整理の方針が、更新しないという答えから読み取れることがあります。
- AIに渡す範囲を文を書くのに要る情報に限る … 顧客の会社名、担当者名、件数、印だけを渡し、商標の一覧と顧客の答えの履歴の詳細は渡しません
- 期限の正本を書き換えない … 知財管理のシステムには書き込まず、状態の記録は担当者が入れます
- 送信は人が行う … 下書きまでを作り、期限の通知は必ず人が確かめてから送ります
- 勧めも止めもしない … 更新するかは顧客の判断です。事務所が意見を言うときは、弁理士が自分の言葉で書きます
- 送った記録を残す … いつ、誰が、何を送ったかを、送ったメールそのものと台帳の記録の両方で残します
- 料金表の正しさを事務所が持つ … 登録料は政令で定める額で、改定されることがあります。AIにも外部のページにも頼らず、事務所が確かめた額だけを使います
誤りが起きた場合のリスクは、通知が漏れて商標権が消えることと、誤った番号や日付の通知で顧客が判断を誤ることの2つです。 前者は台帳の状態の列と毎月の洗い出しで、後者は番号と日付をAIに書かせない設計で防ぎます。どちらも期限の管理の責任に関わるので、確かめて送る人の工程は残します。
10まず何から始めるか
1週目:台帳に列を足す
年金管理の台帳に、「通知の状態」と「顧客の答え」の列を足します。次の12か月に満了する商標から順に、状態を埋めます。あわせて料金表を最新にし、版を書きます。
2週目:10社で試す
先月通知した顧客から10社を選び、手元のAIサービスで表の前後の文を書かせます。番号や日付が文に入っていないか、勧める表現が無いかを最優先で見ます。
3週目:通知文の型を決める
申請できる期間、答えの期限、問い合わせ先の言い方を、弁理士と型として決めます。 名義・住所の違いを尋ねる文の型も作ります。
4週目:洗い出しから表までをつなぐ
Make で台帳から対象を拾い、顧客ごとにまとめて表を作るところまで作ります。この時点では通知文は担当者が書き、表だけをシナリオから使います。
2か月目: 見積もりの計算、名義・住所の照合、AIの下書き、Outlook の下書きまでを足します。担当者と弁理士の確認にかかる時間を測ります。3か月目以降: 2回目の通知と弁理士への一覧を足し、1件15分が何分になったかを実測します。台帳の状態の列に「未通知」のまま期間に入った商標が無くなった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| 商標権の存続期間が設定の登録の日から10年であること(第19条)。更新登録の申請書の記載事項、申請が満了前6月から満了の日までの間であること、期間後も経済産業省令で定める期間内なら申請でき、しなければさかのぼって消滅したものとみなすこと(第20条)。故意に申請しなかった場合を除く商標権の回復(第21条)。その場合の割増登録料(第23条)。更新登録の登録料が43,600円を超えない範囲内で政令で定める額に区分の数を乗じた額であること(第40条)。登録料の分割納付と後期分の期限(第41条の2) | e-Gov 法令API: 商標法 | 2026-10-08 |
| シナリオの実行の間隔の選び方(毎月など) | Make Help: Schedule a scenario | 2026-10-08 |
| Search Rows の絞り込み(AND/OR)と、見出しを有効にしたときの列の種類(日付など)、Update a Row | Make: Google Sheets | 2026-10-08 |
| Group by の値ごとに出力のまとまりが作られ、Key と Array が入ること。間のモジュールの項目を後で使うなら aggregator の設定に含めること | Make Help: Aggregator | 2026-10-08 |
| Anthropic Claude アプリに Create a Prompt と Make an API Call があり、API キーで接続すること | Make: Anthropic Claude | 2026-10-08 |
| Microsoft 365 Email のアプリに Create a Draft Email、Send a Draft Email などのモジュールがあること | Make: Microsoft 365 Email | 2026-10-08 |
構造化出力を output_config.format に type: "json_schema" で指定すること | Claude Docs: Structured outputs | 2026-10-08 |
更新するかどうか、満了後の申請や回復をどう進めるかは、担当の弁理士と顧客で決めてください。 本記事は商標法の条文と公開されている仕様で確認できた範囲だけを扱っています。登録料の実際の額は、特許庁の最新の案内で確かめてください。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-1112)についてのご相談はこちらから。
