社内の発明届を受け付けるたびに、先行技術調査の検索キーワード・同義語・特許分類の候補を作り、調査担当への依頼票にまとめる

処理の起点を決める

発明届のフォームの回答を起点にします。 Google Forms アプリの Watch Responses で新しい回答を拾います。発明届は月40件で、1日に数件の届き方です。スケジュールは15分ごとで足ります。 夜間にまとめて処理する形にすると、翌朝の割り当てまでに依頼票が間に合わないことがあります。

届の修正は別の扱いにします。 研究者がフォームの回答を編集した場合、同じ届が二度処理されることがあります。台帳に届の番号（受付日と通し番号）を持たせ、同じ番号の依頼票がすでにあれば作り直さず、調査担当に「届が修正された」とだけ知らせます。 作り直すと、調査担当がすでに書き込んだ確認の印が消えます。

図の添付は、この段階ではAIに渡しません。 図は依頼票にリンクで載せ、調査担当が見ます。文字の6項目だけで語と分類の候補は作れます。 図を読ませるのは、最小構成で効果を見てからで足ります。

入力データを集める

質を決めるのは社内の用語集です。 研究者は「Aユニット」「新型の保持具」のように、社内でしか通じない名前で書きます。AIはこの名前を一般の語に直せないので、用語集が無いと社内の呼び名がそのまま検索語の候補に入ります。 用語集は100語程度から始め、調査が終わるたびに足します。

「発明の構成」と「従来の方法との違い」が、要素に分ける材料です。 構成は発明が何でできているか、違いは何が新しいかです。検索の語は構成から、要素の重み付けは違いから取ります。

技術分野は、研究者の選んだものをそのまま渡します。 分類の候補を絞る手がかりになりますが、研究者の選んだ分野が調査の観点と合っていないこともあります。AIには「参考」として渡し、分野の外の分類も候補に出してよいとします。

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

用語集は、全件ではなく技術分野で絞ってから渡します。 全件を渡すと、関係の無い分野の語が検索語の候補に混ざります。研究者の選んだ分野の行と、どの分野にも共通の行だけを渡します。 分野を選び間違えた届でも共通の行は効きます。

過去の調査で使った語は、この構成では渡しません。 似た発明の調査の記録を探して渡すのは、別の仕組み（UC-0510）の仕事です。混ぜると、前の調査の語に引っ張られて、今回の発明の新しい部分の語が出にくくなります。

AIへ渡す前に整形する

1. 空欄の確認 … 6項目のうち「発明の構成」が空、または50字未満なら、AIに渡さずに受付担当へ戻します。構成が書かれていない届からは、要素を作れません
2. 社内の呼び名の印付け … 用語集にある社内の呼び名が届の中にあれば、その語に一般の呼び名を括弧で添えます。AIが社内の呼び名の意味を推測しないようにします
3. 長さの確認 … 6項目の合計が長すぎる届は、実施の例を先頭の部分だけにします。語と分類に効くのは構成と違いで、実施の例は補助です
4. 個人名の除去 … 研究者の氏名と部署は、AIに渡す文から外します。依頼票には台帳から差し込みます
5. 届の番号の付与 … 台帳に登録したときの番号を、AIへの入力と依頼票の両方に入れます

2番目が効きます。 「Aユニット」とだけ書かれた届を渡すと、AIは「A」という文字から何かを推測して語を作ります。括弧で一般の呼び名を添えておけば、推測の余地がありません。

AIに処理させる

させるのは、発明を要素に分けることと、要素ごとの語と分類の候補を作ることです。

要素に「新しい点を含むか」の印を付けさせるのが要点です。 調査では、新しい点を含む要素の語を必ず検索式に入れ、そうでない要素は絞り込みに使います。印が無いと、どの要素を軸に組むかを調査担当が届を読み直して決めることになります。

1行目がいちばん大事です。 AIは、分類の記号をもっともらしく作ります。記号の体系に沿った形をしているので、目で見ただけでは実在するか分かりません。 だから記号だけでなく、「その分類が何を扱うと考えたか」を理由として書かせ、PMGS で引いた説明と比べられるようにします。

指示内容を固定する

あなたは電子部品メーカーの知財部で、先行技術調査の準備をする調査担当の補助です。
発明届を読み、調査担当が検索式を組むための材料を作ってください。
検索そのものはしないでください。

【やること】
1. 「発明の構成」を3〜6個の技術の要素に分ける。
   「従来の方法との違い」に関わる要素には is_novel_point を true にする。
2. 要素ごとに、次の語を挙げる。
   - original：届に書かれた語（そのまま）
   - synonyms：同じものを指す別の言い方（日本語）
   - english：英語の言い方（複数可）
   - broader：上位の概念
   - narrower：下位の概念・具体例
3. 特許分類の候補を挙げる。記号ごとに、種類（IPC／FI／Fタームのテーマ）と、
   その分類が何を扱うと考えたかを reason に書く。
4. 届からは決められないことを、研究者への確認事項にする。
5. 調査に要るのに届に書かれていないことを missing_info に書く。

【厳守事項】
- 分類の記号は「候補」です。確信が持てない記号は挙げないでください。
  記号を挙げるときは、reason にその分類が扱う技術の内容を必ず書いてください。
  reason が書けない記号は挙げないでください。
- 括弧で一般の呼び名が添えられた語は、その一般の呼び名で考えてください。
  社内の呼び名の文字から意味を推測しないでください。
- 届に書かれていない構成を要素に足さないでください。
  足したほうがよいと思うものは、確認事項に書いてください。
- 新規性や進歩性についての意見を書かないでください。
- 検索式（AND・OR を組んだ式）は書かないでください。語の一覧までです。
- 届の情報が足りず要素に分けられない場合は、elements を空にし、
  missing_info に足りない情報を書いてください。

【届の番号】{disclosure_id}
【研究者が選んだ技術分野（参考）】{field}
【発明届】
発明の名称：{title}
解決したい課題：{problem}
発明の構成：{structure}
従来の方法との違い：{difference}
実施の例：{example}
関連する製品：{product}
【社内の用語集】{glossary}

「reason が書けない記号は挙げない」を明記するのは、記号の数を増やさないためです。 何も言わないと、AIは関連しそうな記号を10個、20個と並べます。確かめる手間は記号の数に比例するので、理由の付く記号だけに絞らせます。

「検索式は書かない」も意図してのことです。 式まで作らせると、調査担当はその式を直すところから始め、語の一覧を眺めて自分で組むより視野が狭くなります。 データベースごとに式の書き方も違います。

出力形式を固定する

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

{
  "disclosure_id": "",
  "elements": [
    {
      "element_name": "",
      "is_novel_point": true,
      "original": [""],
      "synonyms": [""],
      "english": [""],
      "broader": [""],
      "narrower": [""]
    }
  ],
  "classification_candidates": [
    { "code": "", "scheme": "IPC | FI | Fterm_theme", "reason": "", "related_elements": [""] }
  ],
  "questions_to_inventor": [""],
  "missing_info": [""]
}

1つ目の理由は、要素ごとに依頼票の欄へ差し込めることです。 elements の要素の数だけ依頼票の表の行が埋まり、調査担当は要素の間を AND、要素の中の語を OR で組むという形をそのまま使えます。

2つ目は、分類の候補を確かめる欄を作れることです。 classification_candidates の1つずつに、依頼票では「PMGS で確認した説明」と「確認の印」の空欄を並べます。AIの reason と、PMGS で引いた説明を横に並べて見比べます。

3つ目は、研究者への確認事項を1回で送れることです。 questions_to_inventor を依頼票の末尾にまとめておけば、調査担当が要るものだけを選んで、研究者に一度に問い合わせられます。

依頼票は次の形にします。

【先行技術調査 依頼票】届の番号：2026-1008-03　担当：（台帳から）

■ 技術の要素
| 要素 | 新しい点 | 届の語 | 同義語 | 英語 | 上位 | 下位 |
| 要素1 | ○ | … | … | … | … | … |

■ 特許分類の候補（PMGS で確認してから使う）
| 記号 | 種類 | AIの理由 | PMGSの説明 | 確認 |
| … | FI | … | （調査担当が記入） | □ |

■ 研究者への確認事項（必要なものを選んで送る）
■ 届の不足

システムへ連携する

商用の特許データベースと J-PlatPat には、シナリオからつなぎません。 検索は調査担当が行います。PMGS は、調査担当が分類の候補を確かめるために画面で使います。

依頼票は知財部の共有ドライブの、権限を絞ったフォルダに作ります。 Create a Document from a Template の新しい文書の保存先の欄で指定します。

人が確認する

依頼票は、調査担当が全件を確かめます。 自動で次の工程へ進むものはありません。

1. 分類の候補を PMGS で引く … PMGS の「コード照会」では FI・Fターム・IPC の記号を入れて内容を確かめられます。AIの reason と説明が合っていれば確認の印を付け、合わなければ消します
2. 分類を自分でも探す … PMGS の「キーワード検索」で、要素の語から分類を探します。AIの候補に無い分類が見つかったら足します
3. 語を足し引きする … 用語集と自分の経験で語を足し、明らかに外れた語を消します
4. 要素の分け方を直す … 新しい点の印が違っていれば直します
5. 研究者に問い合わせる … 確認事項から要るものを選んで、一度に送ります

1番目と2番目を両方やるのが要点です。 AIの候補を確かめるだけだと、AIが挙げなかった分類はいつまでも見られません。 2番目のキーワード検索は、要素の語がすでに並んでいるので、白紙から探すより短く済みます。

ベテランの調査担当は、最初の1か月、新人の依頼票の確認の結果を見ます。 どの語を足し、どの分類を消したかを見れば、AIの出すものの癖と、新人の見落としの両方が分かります。

例外に対処する

2行目を間違えると、調査担当の作業が消えます。 依頼票には確認の印と PMGS の説明が手で書き込まれています。届が直されても依頼票は上書きせず、変わった項目を知らせるだけにします。

構造化出力は、応答が refusal や max_tokens で止まったときにはスキーマに沿わないことがあるとされています。その場合は依頼票を作らず、従来の手順に戻します。

記録を残す

• 発明届の台帳 … 届の番号、受付日時、調査担当、依頼票のリンク、作成の成否
• AIの出力のJSON（全文） … 届の番号ごとに台帳の別のシートに残す
• 依頼票（調査担当の記入を含む） … 確認の印、PMGS の説明、足した語と分類
• 調査で実際に使った語と分類 … 調査が終わったら調査担当が台帳に書き戻す
• 用語集の変更履歴 … いつ、誰が、どの届をきっかけに語を足したか

AIの出力と、実際に使った語と分類を並べて残すのが要点です。 毎月これを見比べると、AIの候補のうち確認で消された分類の割合と、調査担当が足した語の種類が分かります。 消される割合が高い技術分野は、指示か用語集を直します。

発明届とAIの出力は、未公開の発明そのものです。 台帳と依頼票のフォルダは、知財部と担当の研究者だけが見られる権限にします。