「特許出願中」などの権利表示の根拠を、掲載前に知財台帳と突き合わせる

処理の起点を決める

起点は2つです。 1つは確認用フォルダへの保存で、掲載前の校了データが入るたびに1件ずつ動かします。もう1つは週1回の定時実行で、すでに公開されている商品ページを巡回します。 掲載した時点では正しかった表示が、出願の取下げや権利の消滅で後から合わなくなり、1度見ただけでは気づけないからです。

定時実行は Schedule by Zapier で組みます。トリガーは Every Hour、Every Day、Every Week、Every Month、Custom Frequency から選べ、Every Week なら曜日と時刻を指定します。 指定した分ちょうどに動くことは保証されず、数分以内に動くとされています。 見るのは Zap ではなくアカウント側のタイムゾーンで、変えたときはZapを一度オフにして入れ直す必要があります。

入力データを集める

質を決めるのは台帳の3つの列です。 状態の列が無ければ権利が生きているかを見られず、対象製品の列が無ければ番号と製品の対応を見られません。更新日の列が無ければ、いつ時点のものか分かりません。

他社の標章の一覧は、帰属表示を見るために要ります。 掲載物に出てきた名称が他社の権利かは読んだだけでは決まらず、一覧に無い他社名は人へ回します。

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

掲載物は、PDFのまま渡します。 Claude API へPDFを渡す方法は3つあり、URLを参照する、base64にして document の内容ブロックに入れる、Files API に上げて file_id で参照するのいずれかです。大きなPDFは file_id で参照すると、リクエストを小さく保てるとされています。

台帳の照合は、番号が先、製品名が後です。 番号で引けなかったときに製品名から引き直すと、似た名前の権利に当たります。引けなかったという事実を、そのまま結果に残します。 台帳そのものは生成AIへ渡しません。

AIへ渡す前に整形する

1. 形式の確認 … 標準のPDFか。パスワードや暗号化がかかったものは扱えません
2. サイズとページ数の確認 … 32MB、600ページ（コンテキストウィンドウが100万トークン未満のときは100ページ）が上限です
3. 分割 … 上限を超えるカタログは章ごとに分けます。図版の多いページが続くPDFは、上限に届く前にコンテキストが埋まるとされています
4. 向きの補正 … 横向きのままでは番号の読み取りが落ちます
5. 文字の確認 … 標準的なフォントを使い、文字が読めることを確かめます
6. 並べる順の固定 … リクエストのなかでPDFをテキストより前に置きます
7. メタの付与 … 種類・掲載先・言語・対象国・対象製品を付けます
8. 台帳のスナップショット … そのときの台帳を控え、更新日を見ます

3番目と4番目を軽く見ないでください。 製品カタログは図版が多く、ページ数が上限内でも通らないことがあります。

7番目が、多言語の掲載物を扱う入口です。 英語版カタログの "Patent Pending" がどの国のどの出願のことなのかは、掲載する国が分からないかぎり照らせません。

AIに処理させる

させるのは、掲載物から権利の表示を拾い出し、読み取った文字列をそのまま書き出すことだけです。 台帳との照合も掲載可否の判断もさせません。

右の列の read_confidence が、番号の誤読を拾う第一の手当てです。 ページの画像と、一緒に渡されているテキストで文字が食い違ったときも low にさせます。PDFは各ページが画像とテキストの両方で渡るので、この食い違いは見えます。

5行目を必ず入れてください。 権利の表示は法令の話と地続きなので、何も言わなければ根拠らしい説明を書き添えてきます。それを掲載可否の材料にしてはいけません。

指示内容を固定する

あなたは知財部門で、掲載前の制作物に書かれた権利の表示を拾い出す担当です。
渡された掲載物に書かれている文字だけを見てください。書かれていないことを補わないでください。

【拾い出す対象】
1. 出願中の表示（「特許出願中」「意匠登録出願中」「Patent Pending」など）
2. 登録番号の表示（特許、実用新案、意匠、商標。「特許第◯◯◯◯◯◯◯号」など）
3. 登録商標である旨の表示（「◯◯は当社の登録商標です」、添えられた記号）
4. 意匠・実用新案の表示
5. 他社の標章の表示と、その帰属表示（「◯◯は◯◯社の登録商標です」）

【書き出し方】
- number には、読み取った文字列をそのまま写してください。
  桁を補う、記号を直す、区切りを整える、それらしい番号に近づけることをしないでください。
- 文字に自信が持てないときは read_confidence を low にし、uncertain_chars に
  その文字を書いてください。ページの画像と、一緒に渡されているテキストで
  文字が食い違う場合も low にしてください。
- page と location には、どのページのどこにあったかを書いてください
  （例：3ページ 仕様表の下、裏表紙 製品写真の中の銘板）。
- quote には表示を含む一文を、language にはその表示の言語を書いてください。
- product には対象の製品を記載から書き、読み取れなければ unknown とします。

【してはいけないこと】
- 権利が生きているかどうか、掲載してよいかどうかを書かないでください。
- 台帳にありそうな番号を推測して書かないでください。
- 法令の条文、罰則、違法かどうかの結論を書かないでください。
- 訳文の表示が適切かどうかを判断しないでください。言語を書くまでにしてください。
- 表示が無ければ markings を空の配列にしてください。

【掲載物の情報】
種類: {material_type} ／ 掲載先: {channel} ／ 言語: {language} ／ 対象国: {country}
対象製品（制作側の申告）: {declared_products} ／ 他社の標章: {third_party_marks}

「そのまま写す」を2か所に書いているのは、整えてくるからです。 カンマを外す、全角を半角にそろえる。読みやすくはなりますが、読み取った文字列ではなくなります。

「画像とテキストが食い違う場合も low」も、必ず入れてください。 これを書かないと、どちらか一方を選んで自信ありと返してきます。食い違ったという事実が、人が見るべき合図です。

出力形式を固定する

構造化出力で受け取ります。 output_config.format に type: json_schema とスキーマを渡すと、制約付きのデコードでそのとおりに返るとされています。

{
  "type": "object",
  "properties": {
    "kind": { "type": "string", "enum": ["pending", "patent_no", "utility_no",
               "design_no", "trademark_no", "registered_notice", "third_party"] },
    "number":   { "type": "string" },
    "mark":     { "type": "string" },
    "owner_written": { "type": "string" },
    "product":  { "type": "string" },
    "page":     { "type": "integer" },
    "location": { "type": "string" },
    "quote":    { "type": "string" },
    "language": { "type": "string" },
    "attribution_present": { "type": "boolean" },
    "read_confidence": { "type": "string", "enum": ["high", "low"] },
    "uncertain_chars": { "type": "string" }
  },
  "additionalProperties": false
}

これは表示1件ぶんの形です。全体は material_id と、この形を要素に持つ配列 markings を持つオブジェクトにし、12個すべてを required に入れます。

書ける制約と書けない制約があります。 enum は単純な型にだけ使え、オブジェクトには additionalProperties を false に設定する必要があるとされています。一方で、文字列の長さや数値の範囲の制約は対応していません。

つまり、番号の桁数はスキーマで縛れません。 検査はワークフロー側で行います。これが番号の誤読を拾う第二の手当てです。

印の付いたものは台帳を引かずに人へ回します。3番目は、写し間違いだけでなく前の版からの引き写しも拾います。 台帳と照らした結果は、ワークフローが別の項目として付け、markings には触りません。

「特許出願中」の表示は、出願番号で台帳を引き、状態の列で見ます。 係属中なら matched、取下げや拒絶確定なら not_alive です。登録になっていた場合も、状態をそのまま一覧に出します。 他社の標章は attribution_present を見て、帰属表示が無いものに別の印を付けます。

システムへ連携する

CMSにもDTPのデータにも書き込みません。 出すのは突合結果までで、掲載物を直すのはマーケティング部と制作会社の仕事です。 書き込みを足すと、台帳が古かったときに正しい表示まで消えます。

人が確認する

承認は Human in the Loop の Request Approval で受けます。 これは「Zapの実行を一時停止し、1人以上のレビュアーに、承認・却下、または提出されたデータの変更を求める」ものとされ、応答があるまで後続のステップは止まったままです。 通知先はメール、Slack、別のZapの起動から選べます。

時間切れの扱いを必ず決めてください。 タイムアウトの動作は「スキップして続行」か「実行を終了」から選びます。この構成では「実行を終了」です。 応答が無いまま先へ進む経路を作りません。

1. not_alive と wrong_product を先に見る … 刷り直しにつながるのはこの2つです
2. 書式の検査に落ちたものと low のものを見る … 多くは読み取りの誤りです。 PDFの該当ページで番号を確かめます
3. not_in_ledger を見る … 差し戻す前に、台帳側の未整備をまず疑います
4. 帰属表示の印が付いたものを見る … 他社の標章の扱いを確かめます
5. 判断を記録する … 残す・直す・落とすのどれにしたかと、その理由を残します

Human in the Loop は有料のプランで使えるプレミアムアプリで、そのZapをレビュアーに共有しておく必要があります。

例外に対処する

上から4行目までは、AIの問題ではありません。 校了データの作り方の問題で、依頼の時点でPDFの出し方を決めるほうが早いです。

記録を残す

• 掲載物のファイルと、そのときのメタ（種類・掲載先・言語・対象国・対象製品）
• 生成AIが返した markings の全文（quote・page・location を含む）
• 書式の検査の結果と、そのとき参照した台帳の内容および更新日
• 突合結果と、知財担当がどう決めたか（残す・直す・落とす）とその理由
• 修正を依頼した日時と、直った版との対応
• 掲載物の種類ごとの not_alive の発生件数

3つ目で「そのときの台帳の内容」を残すのは、台帳が後から変わるためです。 権利の状態が更新されると過去の判定の意味が変わり、当時の台帳が残っていないと、やり直す範囲が決まりません。 最後の行は、前の版からの引き写しが起きている場所を示します。