Media > AI活用ユースケース > 法務 > 外国へ商標を出願するときに、日本の出願の指定商品・役務を英訳し、国際分類の表示と過去の対訳に照らして範囲のずれと要確認の表示を挙げる

外国へ商標を出願するときに、日本の出願の指定商品・役務を英訳し、国際分類の表示と過去の対訳に照らして範囲のずれと要確認の表示を挙げる

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

日本の商標出願をもとに外国へ出願するとき、区分ごとの指定商品・指定役務を英訳した対訳表を作ります。事務所の過去の対訳と国際分類の英語の表示を優先して使い、無い表示だけをAIが訳して、和文より範囲が広がる訳に印を付けます。

サマリー
生成AI
ChatGPT/Claude/Gemini
連携・自動化
Google Apps Script/Python
対象業界
その他/士業/小売/製造
対象部門
法務/知財
対象業務
内容確認・チェック/書類作成
主な課題
属人化している/書類作成に時間がかかる/確認ミスが多い
AIで行う処理
翻訳
主な効果
品質標準化/属人化解消/工数削減
導入難易度
★★★☆☆
実装レベル
本格構成
費用感
API連携(中)
人間の確認
条件付き
現在工数
60h/月
AI導入後
18h/月
想定削減
70%
年間削減
504h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 外国出願の担当が、日本の出願の指定商品・指定役務を区分ごとに書き出す
  2. 表示ごとに、過去の外国出願のフォルダと自分のメモから、同じ和文の英訳を探す
  3. 見つからない表示は、国際分類の英語の表示や MGS で近い表示を探す
  4. それでも無い表示は、担当者が英訳する
  5. 英訳が和文より広くなっていないか、区分が日本の出願と同じかを見直す
  6. 区分ごとに英語の一覧に整え、弁理士に回す
導入後(After)
  1. 人外国出願の担当が、日本の出願の指定商品・指定役務を所定の様式で案件に添付し、出願先の国と出願の経路(国際出願・直接出願)を入れて、状態を「英訳待ち」にする
  2. 自動英訳のプログラムが和文を項目に区切り、表記を揃える
  3. 自動事務所の対訳表と和文が完全に一致する項目に、対訳表の英語と、それが受け入れられた国・版を付ける
  4. 自動一致しない項目について、対訳表と参照表から似た和文の対訳を集める
  5. 自動Claude API が、一致しない項目ごとに英訳の案を出し、和文との範囲のずれを判定する
  6. 自動判定を規則でまとめ、対訳表と、MGS で確かめるべき表示の一覧を案件に添付する
  7. 人担当者が、新しく訳した表示を MGS で検索し、指定する国の官庁が受け入れる表示かを確かめる
  8. 人弁理士が対訳表を読み、範囲を判断して英語の一覧を確定する
各工程の詳しい説明を読む
  1. 外国出願の担当が、日本の出願の指定商品・指定役務を区分ごとに書き出す
  2. 表示ごとに、過去の外国出願のフォルダと自分のメモから、同じ和文の英訳を探す
  3. 見つからない表示は、国際分類の英語の表示や MGS で近い表示を探す
  4. それでも無い表示は、担当者が英訳する
  5. 英訳が和文より広くなっていないか、区分が日本の出願と同じかを見直す
  6. 区分ごとに英語の一覧に整え、弁理士に回す

(a)過去の英訳を探すのに時間がかかる。 同じ「洋菓子」でも、過去の案件ごとに違う英語が使われていることがあり、どれが受け入れられた英語かは、その案件の経過の書類を開くまで分かりません。

(b)和文より広い訳を見落とす。 和文が「調理済みの冷凍食品」でも、訳すときに用途や形態の言葉が落ちると、日本の出願より広い商品を指定した一覧になります。 一覧を出してしまうと、後から広げることはできませんが、広すぎた一覧は指定国の審査で指摘を受けます。

(c)担当者ごとに訳が違う。 同じ依頼者の別の商標で、同じ商品が違う英語で指定されていると、依頼者から「どちらが正しいのか」と聞かれ、説明に時間を取られます。

(d)版の違いを持ち込む。 過去の案件の英訳を写すとき、その案件がどの版の国際分類で出されたかを確かめずに写すと、今の版では区分が違う表示を持ち込みます。

  1. 【人】 外国出願の担当が、日本の出願の指定商品・指定役務を所定の様式で案件に添付し、出願先の国と出願の経路(国際出願・直接出願)を入れて、状態を「英訳待ち」にする
  2. 【自動】 英訳のプログラムが和文を項目に区切り、表記を揃える
  3. 【自動】 事務所の対訳表と和文が完全に一致する項目に、対訳表の英語と、それが受け入れられた国・版を付ける
  4. 【自動】 一致しない項目について、対訳表と参照表から似た和文の対訳を集める
  5. 【自動】 Claude API が、一致しない項目ごとに英訳の案を出し、和文との範囲のずれを判定する
  6. 【自動】 判定を規則でまとめ、対訳表と、MGS で確かめるべき表示の一覧を案件に添付する
  7. 【人】 担当者が、新しく訳した表示を MGS で検索し、指定する国の官庁が受け入れる表示かを確かめる
  8. 【人】 弁理士が対訳表を読み、範囲を判断して英語の一覧を確定する

3番目が、この設計の分かれ目です。 対訳表と一致する項目はAIに見せません。過去に受け入れられた英語があるのに、AIに訳し直させると、受け入れの記録の無い英語に置き換わります。

7番目を人に残すのは、受け入れの確認をAIの答えで済ませないためです。 MGS には、表示ごとに指定した国の官庁が受け入れるか拒むかを見られる機能があります。AIが「受け入れられるはず」と書いても、それは根拠になりません。

02今回想定するシステム構成

構成図
日本の出願の指定商品・指定役務(所定の様式)+ 出願先の国・経路
   ▼【トリガー】案件管理システムの状態が「英訳待ち」
英訳のプログラム(Python)
   ├──▶ 項目の区切り、表記の揃え
   ├──▶ 対訳表と完全一致 →「過去の対訳」(英語・受け入れた国・版)
   ├──▶ 一致しない項目 → 対訳表と参照表から似た対訳を集める
   ▼
Claude API ── 一致しない項目ごとの英訳と判定
   │   ① 英訳の案(候補の中から選ぶ/新しく訳す)
   │   ② 和文との範囲(same/broader/narrower/uncertain)
   │   ③ 区分の合致   ④ 確認の理由
   ▼
英訳のプログラム ── 規則でまとめ、対訳表と MGS で確かめる一覧を作る
   ▼
【人】担当者が MGS で受け入れを確認 → 弁理士が範囲を判断して確定
役割想定する製品代替候補
処理Claude API(対訳の無い表示の英訳と、範囲のずれの判定)OpenAI API、Gemini API
連携Python(項目の区切り、対訳表との照合、候補の収集、対訳表の作成)Google Apps Script
表示の確認WIPO Madrid Goods and Services Manager(担当者が画面で確認)米国への直接出願では USPTO の ID Manual
案件の管理事務所の案件管理システム共有フォルダと案件の一覧表

新しく作るのは、英訳のプログラムと、2つの表です。 1つ目は事務所の対訳表で、過去の外国出願で使った和文と英語の組に、出願先の国、国際分類の版、審査の結果(受け入れ・指摘あり)を付けたものです。2つ目は参照表で、担当者が MGS で確かめた英語の表示を、確かめた日と受け入れの結果とともに記録したものです。

表示の確認の土台は、WIPO の MGS です。 WIPO の案内では、MGS は国際出願の商品・役務の一覧を作り、確かめるための道具で、数十万の表示から選べるとされています。「Check acceptance by designated Contracting Party」の機能で、表示ごとに、参加している官庁が受け入れるか拒むかを見られます。 2021年の WIPO の案内では、40の指定締約国について受け入れを確かめられ、少なくとも25の言語で使えるとされています。

一覧の形式を誤ると、WIPO の方式審査を通りません。 WIPO の2018年の案内では、国際出願の一覧は国際分類の決まりに沿う必要があり、満たさなければ方式審査を通らず不備の通知が出るとされています。区分ごとにまとめ、区分の番号を付けた形に、プログラムで整えます。

米国に直接出願する案件では、USPTO の ID Manual を参照します。 USPTO の案内では、ID Manual は商品・役務の表示とその分類を載せたもので、明細書(使用の証拠)が支えるかぎり審査官が追加の照会なく受け入れるとされています。ただし一覧は網羅的ではないとも書かれています。

判定の受け取り方は、Claude API の構造化出力です。 リクエストの output_config.format に type: "json_schema" とスキーマを渡すと、返答がスキーマに沿ったJSONになります。範囲の判定を enum で固定でき、規則によるまとめをプログラムで書けます。 enum の文字列は大文字・小文字が保証されないとされているため、値は小文字の英字にし、大文字・小文字を区別せずに比べます。

03どうやって実装するのか

Step1

処理の起点を決める

案件管理システムで、案件の状態が「英訳待ち」になったことを起点にします。 英訳のプログラムが15分ごとに案件の一覧を見て、状態の変わった案件を拾います。依頼者と出願先の国を詰めている途中で動かさないよう、担当者が状態を変えたときだけ動かします。

出願先の国が変わったら、もう一度動かします。 国によって確かめる道具が変わり(国際出願なら MGS、米国への直接出願なら ID Manual)、対訳表の受け入れの記録も国ごとに違うためです。前回の対訳表は消さず、版を分けて残します。

対訳表と参照表の更新は、別に動かします。 指定国の審査の結果が届いたとき、国際分類の新しい版が発効したときに、表を更新します。更新した日より前に作った対訳表のうち、出願前のものを一覧にして担当者に知らせます。

Step2

入力データを集める

データ中身取得元
日本の指定商品・指定役務区分と、区分ごとの和文の表示の並び案件に添付された所定の様式
出願先と経路国・地域、国際出願か直接出願か案件管理システム
依頼者の商品の説明外国で売る商品・提供する役務の説明案件管理システム
事務所の対訳表和文、英語、区分、出願先の国、国際分類の版、審査の結果過去の外国出願の記録
参照表英語の表示、区分、MGS で確かめた日、受け入れの結果担当者の確認の記録

質を決めるのは、事務所の対訳表です。 対訳表の英語は、受け入れられたものと、指定国から指摘を受けたものを分けて持ちます。 区別しないと、指摘を受けた英語を「過去に使った訳」として当ててしまいます。

依頼者の商品の説明を入れるのは、和文だけでは訳が決まらない表示があるためです。 和文の表示が広い言葉のとき、英語では用途や材質を書き足すかどうかで範囲が変わります。依頼者が外国で何を売るかを、範囲を判断する材料として弁理士に渡します。

Step3

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

指定商品・指定役務は、所定の様式(区分の列と表示の列を持つ表)で受け取ります。 日本の出願の願書の写しから文章のまま読ませると、区切りの位置を誤ります。願書から表に写す作業を、最初の手順に置きます。

取るものどこから何に使うか
和文の区分と表示案件に添付された様式英訳の対象
出願先と経路案件管理システム確認の道具の選択と、受け入れの記録の絞り込み
対訳表の行事務所の対訳表(完全一致、似た和文の検索)過去の英語の当て込みと候補
参照表の行参照表(似た英語の検索)候補
商品の説明案件管理システム範囲の判断の材料

似た和文の検索は、AIではなくプログラムで行います。 文字の重なりで、対訳表と参照表から上位10件ずつを取ります。候補の行はプログラムが取り出し、AIにはその中から選ぶか、無ければ訳すかを決めさせます。

Step4

AIへ渡す前に整形する

  1. 区切り … 表示の並びを、読点・全角の空白・改行で項目に分けます。括弧の中では分けません
  2. 表記の揃え … 全角・半角、長音の記号を揃えた照合用の値を作ります。対訳表には元の表記を載せます
  3. 完全一致の照合 … 揃えた和文で対訳表を引き、区分も一致し、出願先の国で受け入れられた記録のある行を「過去の対訳」とします
  4. 受け入れの記録の無い一致 … 和文は一致するが、出願先の国で使った記録が無い行は、英語を当てたうえで「要確認」の印を付けます
  5. 版の確認 … 対訳表の行の国際分類の版が今の版と違えば、印を付けます
  6. 候補の収集 … 一致しない項目ごとに、似た和文の対訳を上位10件取ります。指摘を受けた記録のある英語は、候補から外します

4番目を分けるのは、国によって受け入れられる表示が違うためです。 ある国で受け入れられた英語が、別の国でも受け入れられるとは限りません。MGS に受け入れの確認の機能があるのは、そのためです。出願先の国で使った記録が無ければ、過去の対訳でも確かめる対象に入れます。

6番目で指摘を受けた英語を外すのは、同じ指摘を繰り返さないためです。 外した英語は、候補とは別に「過去に指摘を受けた訳」として対訳表に添え、担当者が避けられるようにします。

Step5

AIに処理させる

させるのは、対訳表と一致しない項目ごとに、次の4つを出すことだけです。

出すもの根拠にするもの判断できないとき
英訳の案候補の行の中から選ぶ。合う候補が無ければ新しく訳す新しく訳し、new_translation の印
和文との範囲和文の語、英訳の語、商品の説明uncertain
区分の合致候補の行の区分と、和文の区分uncertain
確認の理由範囲や区分の判断に迷った点空欄

範囲の判定は4つの値で返させます。 same(同じ範囲)、broader(英訳のほうが広い)、narrower(英訳のほうが狭い)、uncertain(判断できない)です。broader は、出願の一覧に入れる前に必ず弁理士が見る印です。

させないこと理由
和文に無い商品を足す日本の出願に無い商品を外国で指定することになる
「namely」「including」などで例を書き足す範囲の書き方が変わる。書き足しは弁理士が決める
区分を変える区分の判断は弁理士が行う。合わなければ uncertain
「受け入れられる」と書く受け入れの確認は MGS と各国の官庁の資料で人が行う
依頼者の商標の名前を見る英訳には要らない。渡さない

1行目と2行目が、最も起きやすい失敗です。 AIは、英語として自然な一覧にしようとして、和文に無い用途や例を書き足すことがあります。 書き足した語は、そのまま範囲の変化です。指示で禁じたうえで、英訳の語と和文の語の対応を term_map に書かせ、和文に対応の無い英語の語があればプログラムが「要確認」にします。

Step6

指示内容を固定する

あなたは特許事務所の外国出願の担当です。日本の商標出願の指定商品・指定役務のうち、
事務所の対訳表と一致しなかった項目を、外国出願用の英語に訳してください。

【出すもの】
1. translation:英訳の案
   - 【候補の行】に和文と同じ範囲の英語があれば、その英語をそのまま写す
   - 合う候補が無ければ、和文の語だけを使って新しく訳し、new_translation を true にする
2. source_id:写した候補の行の番号。新しく訳したときは空
3. scope:和文と比べた英訳の範囲
   - same ...... 同じ範囲
   - broader ... 英訳のほうが広い(和文に無い商品を含みうる)
   - narrower .. 英訳のほうが狭い(和文の商品の一部が外れる)
   - uncertain . 判断できない
4. class_check:和文の区分と、候補の行の区分が合っているか(ok/mismatch/uncertain)
5. term_map:和文の語と英訳の語の対応
6. note:判断に迷った点を1〜2文

【厳守事項】
- 和文に無い商品・用途・材質・例を英訳に足さないでください。
- "namely" "including" "such as" などで例を書き足さないでください。
- 区分を変えないでください。合わないと思うときは class_check を mismatch にしてください。
- 候補の行の英語を写すときは、語を足したり減らしたりしないでください。
- 迷ったときは scope を same にせず uncertain にしてください。
- 指定する国で受け入れられるかどうかは書かないでください。
- term_map には、英訳のすべての語が和文のどの語に当たるかを書いてください。
  和文に当たる語が無い英語の語があれば、その語の相手を空にしてください。

【和文の項目】{item}(区分:第{class}類)
【依頼者の商品の説明】{client_note}
【候補の行】{candidates}
【過去に指摘を受けた訳】{rejected}

「例を書き足さない」を明記しないと、自然な英語にするために書き足します。 「衣服」を訳すときに、具体例を並べて「namely」で続けるのは英語の一覧としてはよく見る形ですが、どの例を挙げるかは範囲の判断です。 弁理士が依頼者と決めます。

term_map で和文に当たらない英語の語を空にさせるのは、プログラムで書き足しを見つけるためです。 相手が空の語が1つでもあれば、その項目は broader かどうかにかかわらず弁理士に回します。

Step7

出力形式を固定する

次の形のJSONで受け取ります。

{
  "item_id": "",
  "original_ja": "",
  "class": 0,
  "translation": "",
  "new_translation": false,
  "source_id": "",
  "scope": "same | broader | narrower | uncertain",
  "class_check": "ok | mismatch | uncertain",
  "term_map": [ { "ja": "", "en": "" } ],
  "note": ""
}

1つ目の理由は、過去の対訳とAIの訳を同じ表に並べられることです。 前処理で「過去の対訳」とした項目も同じ形の行にし、どの行が過去の英語で、どの行がAIの新しい訳かを source_id と new_translation で分けます。

2つ目は、対訳表の判定を規則で決められることです。

対訳表の判定条件
過去の対訳前処理で対訳表と完全一致し、出願先の国で受け入れの記録がある
候補から選択source_id があり、scope が same、class_check が ok
要確認(MGS)new_translation が true、または出願先の国での受け入れの記録が無い
要判断(弁理士)scope が broader/narrower/uncertain、class_check が ok 以外、term_map に相手の無い語がある

判定の条件が重なる行は、下の行を優先します。 新しい訳で範囲も broader の行は、MGS で確かめる前に弁理士が範囲を決めます。範囲が決まらないまま MGS で受け入れを確かめても、確かめた英語が使われないことがあり、担当者の確認が無駄になるためです。 弁理士が英語を決めてから、担当者が MGS に回します。

3つ目は、出願用の英語の一覧をプログラムで組み立てられることです。 弁理士が確定した行を、区分ごとに番号を付けて並べ、区切り記号をそろえます。組み立てをAIに任せないので、確定した英語が一覧の段階で変わりません。

担当者と弁理士には、案件ごとに次のような対訳表を渡します。

【案件】TM-F-2026-0331 出願先:国際出願(指定国 5) 国際分類:NCL(13-2026)

【要判断(弁理士)】
 第30類「冷凍の調理済み麺」→ (英訳の案)   scope: broader
   理由:英訳から「冷凍」に当たる語が落ちている

【要確認(MGS)】
 第30類「抹茶入りの焼き菓子」→ (英訳の案)   new_translation
   MGS で各指定国の受け入れを確認

【候補から選択】 3項目 【過去の対訳】 8項目(受け入れた国と版は別表)

「要判断」と「要確認」を上に置き、行き先を分けます。 前者は弁理士、後者は担当者が見るもので、同じ一覧に混ぜると、MGS で確かめれば済む行に弁理士の時間を使います。

Step8

システムへ連携する

つなぎ先方式内容
案件管理システム一覧の読み取り、ファイルの添付、状態の変更状態の変わった案件を拾い、対訳表を添付する
対訳表・参照表プログラムからの読み取りと追記照合、候補の収集、確認の結果の記録
Claude APIAPI呼び出し(構造化出力)一致しない項目の英訳と判定
WIPO MGS担当者が画面で検索新しく訳した表示の受け入れの確認
弁理士への連絡案件管理システムの通知対訳表ができたことを知らせる

MGS とはプログラムでつなぎません。 担当者が画面で表示を検索し、受け入れの結果を参照表に記録します。記録した結果は、次の案件の候補と前処理の照合に使われます。

WIPO や各国の官庁への出願のシステムともつなぎません。 英語の一覧を出願書類に入れて提出するのは、従来どおり弁理士の確認を経た人の手順です。WIPO の案内にあるとおり、出した後に一覧は広げられないので、提出の手前は必ず人が持ちます。

Step9

人が確認する

対訳表の全行を、判定ごとに担当者と弁理士で分けて見ます。

  1. 担当者が「要確認(MGS)」を見る … 新しく訳した表示と、出願先の国で使った記録の無い過去の対訳を MGS で検索し、受け入れの結果を記録します。「要判断」にも当たる行は、弁理士が英語を決めた後に回します
  2. 弁理士が「要判断」を見る … 範囲が広い・狭い・判断できない行と、区分の合わない行です。依頼者の商品の説明と照らし、和文の範囲に収まる英語を決めます
  3. 弁理士が「候補から選択」と「過去の対訳」を流し見る … 英語の並びに違和感が無いかだけを見ます
  4. 確定した英語を対訳表に戻す … 受け入れの結果が出たら、審査の結果の欄を更新します

2番目が、AIに任せられない部分です。 英語でどこまで具体的に書くかは、依頼者がその国で何を売るかと、日本の出願の範囲の両方を知っている弁理士にしか決められません。

4番目が、次の案件の時間を減らします。 確定した英語と受け入れの結果が対訳表に戻ると、同じ和文の次の案件では前処理で当たり、AIにも担当者にも回りません。

目標は、36件をならして1件30分です。 過去の対訳で埋まる案件は短く、新しい商品の多い案件は MGS での確認に時間がかかります。

Step10

例外に対処する

起きること対応
指定商品が所定の様式でない英訳せず、担当者に様式での作り直しを依頼する
出願先の国が入っていない確認の道具を選べない。英訳はせずに担当者に戻す
候補が1件も集まらないAIに新しく訳させ、「要確認」と「要判断」の両方にする
AIの source_id が候補の行に無いその英訳を捨て、新しい訳として扱う
term_map に相手の無い英語の語がある「要判断」にする
対訳表の行の国際分類の版が古い英語を当てたうえで「要確認」にし、今の版で区分を確かめる
国際分類の新しい版の発効をまたぐ案件発効後に出す案件は新しい版で区分を確かめ直す
Claude API が応答しない状態を「英訳待ち」のまま残し、次の回で再試行する
返ったJSONの値が想定外大文字・小文字を区別せずに比べ、それでも合わなければ「要判断」
英語以外の言語で出す出願この構成の対象外。弁理士が個別に扱う

上から6行目と7行目は、毎年必ず起きます。 国際分類は毎年版が変わり、WIPO の案内でも次の版の事前の公表が始まっています。版をまたぐ時期に出す案件は、過去の対訳に頼りすぎないことが大事です。

Step11

記録を残す

  • 和文の様式と、出願先の国・経路
  • 英訳に使った対訳表・参照表の版と、国際分類の版
  • 項目ごとの判定(前処理の結果とAIの出力の両方)と、集めた候補の行
  • 担当者が MGS で確かめた結果と、確かめた日
  • 弁理士が確定した英語と、AIの案から変えた理由
  • 出願後の各国の審査の結果(表示を理由とする指摘の有無)

2つ目の国際分類の版が、後から最も必要になる記録です。 指定国から表示について指摘を受けたときに、英訳の時点でどの版を見ていたかが分からないと、訳の誤りか、版の変更かを切り分けられません。

最後の行は、対訳表を育てる材料になります。 指摘を受けた英語と補正後の英語を対訳表に戻すと、次の案件から指摘を受けた訳は候補に出ず、補正後の英語が当たります。

04実装レベルの3段階

最小構成:和文と商品の説明を手でAIの画面に貼り、英訳と語の対応を出させる / 1項目ごとの英訳
半自動化:上記+プログラムで対訳表との照合と候補の収集を自動にし、判定ごとの対訳表を作る / 照合、候補の収集、英訳、対訳表
本格構成:上記+案件管理システムの状態を起点に動かし、MGS の確認結果と各国の審査の結果を対訳表に戻す / 英訳の全体と、対訳表と参照表の更新

本記事の想定は本格構成です。 月36件を扱う事務所では、確認の結果を対訳表に戻す作業を人が覚えておくのが難しく、同じ表示を毎回 MGS で確かめ直すことになります。 半自動化で、過去の英訳を探す時間が減ります。 本格構成で、確認の結果と審査の結果が対訳表に戻る仕組みが加わります。戻す仕組みまで作ると、ベテランの担当者の記憶にあった「この英語は通る」が表として残り、新しい担当者も同じ英語を使えます。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
4 名
月間件数
36 件
1件あたり現在時間
100 分
1件あたり導入後時間
30 分
現在  36件 × 100分 ÷ 60 = 60 時間/月
導入後 36件 × 30分 ÷ 60 = 18 時間/月
月間削減時間
42h
削減率
70%
年間削減時間
504h
年間金額換算(時間単価6,000円)
302万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 外国への商標出願(マドリッド協定議定書による国際出願、各国への直接の出願)を月に数十件扱う特許事務所・法律事務所、または海外展開の多い企業の知財部門。指定商品・指定役務の英訳を担当者が1件ずつ起こしており、過去の英訳が担当者の手元に散らばっている場合。指定国の官庁から表示を理由とする指摘を受けた記録を残している場合。
向いていない
  1. 外国への商標出願が年に数件で、担当の弁理士が毎回すべての表示を確かめられる場合。指定商品・指定役務を最初から国際分類の英語の表示だけで選んでいる場合。なお、どの商品・役務を指定するかという権利の範囲の判断と、各国で表示が受け入れられるかの最終的な判断は、この構成では代替できません。

07最小構成で試す方法

  1. 過去の外国出願から10件を選ぶ(うち数件は、指定国から表示について指摘を受けたものを入れる)
  2. 各案件の和文の指定商品を書き出し、事務所で過去に使った英訳があれば並べる
  3. 過去の英訳が無い表示について、手元のAIサービスの画面に、和文と商品の説明を貼り付け、「和文の範囲を広げずに英訳してください。例を書き足さないでください。英訳の各語が和文のどの語に当たるかを示してください」と指示する
  4. 出てきた英訳を、実際に出した英語と、指定国からの指摘の内容と並べる
  5. 新しく訳した表示を、担当者が MGS で検索して受け入れを確かめる

10件は必ずやってください。 プログラムを組む前に、「範囲を広げる書き足しをしないか」と「指摘を受けた表示に印が付くか」を確かめます。

出てきた内容判断
実際に通った英語と同じか近い訳で、書き足しが無いプログラムの組み立てに進む
例を並べる、用途を足すなどの書き足しが出る指示と term_map の照合で直る。構成は有効
指摘を受けた英語と同じ訳を出す対訳表に指摘の記録を持たせるのが先

3行目が出たら、AIより対訳表の整備を先にしてください。 指摘の記録が無ければ、AIもプログラムも同じ訳を避けられません。過去の案件の経過の書類から、指摘を受けた英語を拾って対訳表に戻す作業が、最も効く準備です。

08実装時につまずきやすいポイント

問題対策
例や用途を書き足して範囲が広がる指示で禁じ、term_map で和文に当たらない語を拾う
過去に受け入れられた英語をAIが訳し直す完全一致の項目をAIに見せない
別の国で通った英語を、出願先の国でも通ると扱う出願先の国で受け入れの記録が無ければ「要確認」にする
指摘を受けた英語を候補にする対訳表に審査の結果を持たせ、指摘を受けた英語を候補から外す
版の古い対訳を持ち込む対訳表に国際分類の版を持たせ、今の版と違えば印を付ける
区分をAIが変える区分を変えさせず、合わなければ mismatch にする
受け入れの確認をAIの答えで済ませる新しい訳は担当者が MGS で確かめる
一覧の形式が崩れる区分ごとの番号と区切り記号をプログラムで組み立てる
確定した英語が対訳表に戻らない確定と審査の結果の記録を、案件を閉じる条件にする
enum の値の大文字・小文字がずれる値を小文字の英字にし、大文字・小文字を区別せずに比べる

上の3行が、この構成の失敗のほとんどです。 どれも、AIに訳させる範囲を、事務所の記録で言えないところだけに絞れているかで決まります。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 日本の出願の指定商品・指定役務、出願先の国、依頼者が外国で売る商品の説明です。外国出願の計画は、依頼者がどの国で何を売るかという未公表の事業の計画そのものです。

  1. AIに渡す範囲を、表示と候補と商品の説明までに限る … 依頼者の名前、商標そのもの、出願の予定日は渡しません
  2. 利用するサービスのデータの扱いを確かめる … 生成AIのAPIに送った内容がどう扱われるかを、利用規約とデータの取り扱いの条件で確かめ、依頼者との守秘の約束と矛盾しないことを確かめておきます
  3. この構成は弁理士の判断を代替しない … どの商品を指定するか、英語でどこまで書くかは弁理士が決めます。対訳表が出すのは、過去の記録との照合の結果と、訳の案と範囲の判定だけです
  4. 提出は必ず人が行う … 国際出願の一覧は、出した後に広げられません。一覧を自動で出願書類に入れる仕組みを作りません
  5. 対訳表の出どころを残す … どの英語が、どの国で、どの版のときに受け入れられたかを、行ごとに残します

誤りが起きた場合のリスクは、和文より広い英語で外国に出願することと、狭すぎる英語で守りたい商品を落とすことの2つです。 前者は term_map の照合で、後者は narrower の判定と弁理士の確認で防ぎます。

10まず何から始めるか

1週目:対訳表の形を決める

和文・英語・区分・出願先の国・国際分類の版・審査の結果の列を持つ対訳表の形を決めます。直近1年分の外国出願から、まず20件を表に移します。

2週目:指摘を受けた英語を拾う

過去の案件の経過の書類から、指定国から表示について指摘を受けた英語と、補正後の英語を拾って対訳表に入れます。ここが、AIより先に効く準備です。

3週目:10件で試す

過去の10件で、手元のAIサービスに英訳させます。例や用途の書き足しが無いか、指摘を受けた英語と同じ訳を出していないかを最優先で見ます。

4週目:照合と候補の収集を作る

照合のプログラムで、完全一致の項目に過去の対訳を当て、一致しない項目の候補を集めるところまで作ります。この時点では、AIに見せる前の候補の一覧を弁理士に見てもらい、拾い方を直します。

2か月目: Claude API の英訳と判定を足し、弁理士が英訳を変えた割合を数えます。3か月目以降: MGS の確認結果と各国の審査の結果を対訳表に戻す仕組みを作ります。新しい担当者が、過去の対訳と MGS の記録だけで英語の一覧を作れるようになった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-08/最終更新:2026-10-08
確認した内容情報源確認日
国際出願は英語・フランス語・スペイン語のいずれかで出すこと。本国の官庁で基礎となる出願・登録が要ること。MGS で一覧を作れること。国際出願を出した後に商品・役務の一覧を広げられないことWIPO: How to file an international trademark application2026-10-08
MGS で数十万の表示から選べること。「Check acceptance by designated Contracting Party」で、表示ごとに参加している官庁が受け入れるか拒むかを見られることWIPO: Madrid Goods and Services Manager: New Participant – Egypt2026-10-08
MGS が一覧の作成を支援する道具で、40の指定締約国について表示の受け入れを確かめられること。少なくとも25の言語で使えることWIPO: WIPO Cooperates with the EUIPO on Classification Terms under the Madrid System2026-10-08
国際出願の一覧が国際分類の決まりに沿う必要があり、満たさなければ方式審査を通らず不備の通知が出ること。MGS が WIPO と参加官庁に受け入れられる表示の確認を助けることWIPO: 2018 Edition of Classification Guidelines Available Now2026-10-08
ニース分類が標章の登録のための商品・役務の国際分類であること。NCL(13-2026) が2026年1月1日に発効したこと。NCL(13-2027) の事前の公表が行われていること。2013年から毎年新しい版が出ることWIPO: Nice Classification2026-10-08
ID Manual が商品・役務の表示とその分類を載せたもので、明細書が支えるかぎり審査官が追加の照会なく受け入れること。一覧が網羅的でないことUSPTO: Guides, Manuals, and Resources2026-10-08
output_config.format に type: "json_schema" を指定すると返答がスキーマに沿ったJSONになること。enum が使えること。enum の大文字・小文字が保証されず、大文字・小文字を区別せずに比べるよう推奨されていることClaude Docs: Structured outputs2026-10-08

指定商品・指定役務の選び方と英語でどこまで書くか、各国で表示が受け入れられるかの最終的な判断は、弁理士が行ってください。 本記事は WIPO・USPTO・Anthropic の公開している情報で確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-1102)についてのご相談はこちらから。

AI活用について相談する
目次