社員からの職務発明の届出・報奨・発表前の手続きの質問に、職務発明規程と知財部の手引きを根拠にチャットで答え、判断の要るものを知財部へ回す

処理の起点を決める

起点は、研究者が社内ポータルの知財チャットに質問を送ったことです。 チャットは社内の ID でログインした社員が使え、所属と研究所から、回したときにどの担当者の待ち行列に載せるかを決めます。

発表前の手続きの質問では、発表の予定日を必須にします。 日付が決まっていなければ「未定」を選べますが、未定のまま答えるのは手引きの一般的な手順だけにし、締め切りの日付は出しません。 日付が決まったら、同じセッションで入れ直してもらいます。

1件の質問は、1つのセッションで最後まで続けます。 「では論文の投稿の場合は」のような続けての質問も同じセッションでつなぎ、別の発明の話は新しいセッションで始めます。 前の発明の条件が言い換えの中に残るからです。

入力データを集める

質を決めるのは、回す条件の表です。 「すでに公にした」「職務の範囲かどうか分からない」「報奨の額に納得できない」「共同研究の相手がいる」「発表まで14日を切っている」のような値が選ばれたら、答えを作らずに回す、という規則をこの表に書きます。 14日のような日数は、知財部が出願の段取りに要る日数から決めます。

発明の内容は、この構成に入れません。 研究者が質問の文に技術の中身を書くことがありますが、決まりを答えるのに発明の中身は要りません。 チャットの画面にその旨を表示し、中継プログラムは検索の文に技術の説明を含めない形で組み立てます。

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

規程・手引き・条文・過去の質疑は、Cloud Storage に置いてデータストアに取り込みます。 文書ごとのメタデータに、文書の種類、話題（届出／報奨／発表前／共同研究）、適用開始日、適用終了日、閲覧の範囲を持たせます。

特許法の条文は、e-Gov 法令検索の法令API（laws.e-gov.go.jp/api/2/law_data/…）から取り込みます。 条文の改正の施行日をメタデータに持たせ、半年に一度、APIの改正情報を知財部が確かめます。

絞り込みの式は、話題と版で書きます。 項目を索引可能にしておけば、topic: ANY("reward") AND valid_from <= "2021-03-15" AND valid_to >= "2021-03-15" のように、届出の日に効いていた規程の版だけを引けます。日付は ISO 8601 の形式でそろえます。届出番号が無い質問は、今の版で答えます。

知財部の内部の運用メモには、閲覧の範囲を付けます。 報奨の算定の内部の目安や、審査の場の運用は、研究者に見せる文書ではありません。 acl_info に知財部のグループだけを書きます。この設定はデータストアの作成時にしか選べず、データソースのアクセス制御はプレビューの機能です。 使わない場合は、内部の運用メモを別のデータストアに分け、知財部の画面からしか呼ばない形にします。

AIへ渡す前に整形する

1. 規程を条ごとに分ける … 新旧の規程を、条の見出しが付いた形で取り込みます。附則の適用の区分は、別の断片にします
2. 版の適用開始と終了を付ける … 旧規程には改定の日を終了日として書きます
3. 手引きを話題で分ける … 届出、発表前、共同研究、報奨の見出しを立てます
4. 締め切りの表を作る … 手引きの「発表の○日前までに」を、発表の形（学会・論文・展示会・顧客への説明・プレスリリース）ごとに表にします
5. 条文を取り込む … 第29条、第30条、第35条を、条の見出しを付けて取り込みます
6. 過去の質疑を整える … 研究者の氏名と技術の中身を消し、根拠の条を書き添えます
7. 見出しを断片に含める … データストアの作成時に分割を有効にし、includeAncestorHeadings を有効にします

2番目の版の付け方が、この構成でいちばん効きます。 報奨の質問の多くは「登録されたら何がもらえるか」で、版が届出の日で決まるのか、出願や登録の日で決まるのかは、自社の附則に書いてあります。 附則を読んで適用の基準日を決め、メタデータに持たせます。本記事のモデルでは届出の日を基準にしています。

7番目は、データストアを作る前に決めます。 分割はデータストアの作成のあとでは有効にも無効にもできず、見出しを含める設定は既定では無効です。 「前項の届出」のような断片は、見出しが無いとどの条の話か分かりません。分割の大きさは100〜500トークンで、既定は500です。

AIに処理させる

させるのは、聞き取った条件に当たる規程・手引き・条文の記載を見つけ、研究者が次に何をすればよいかを、根拠を付けて短く返すことです。 何を聞き返すか、何を回すかは、回す条件の表で中継プログラムが決めます。

answer メソッドの設定は次のようにします。

4行目がいちばん起きやすい失敗です。 特許法第30条の条文は検索で見つかり、モデルは条文どおりに「1年以内に出願すれば」と説明できてしまいます。 それを読んだ研究者は、発表してから出願すればよいと受け取ります。例外の条文は、知財部へ回すときの説明にだけ使います。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは知的財産部の担当者として、
研究者・技術者から職務発明の届出・報奨・発表前の手続きの質問に答えます。
読むのは、研究の合間に確かめている社員です。短く答えてください。

【前提】
検索の文の最初に、質問の種類、発表の形、発表の予定日、
発明届を出したか、届出の日、共同研究かどうかが並んでいます。
その条件に当たる記載だけを使って答えてください。

【答え方】
1. 最初に、研究者が次にすることを、手引きの手順の順に書いてください。
2. 締め切りの日付が別に表示されるときは、その日付を書き換えないでください。
3. 根拠にした規程の条と手引きの節を書いてください。
4. 特許法の条文は、手続きの根拠を示すときだけ条の番号を書いてください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  一般的な特許の知識や他社の例で補わないでください。
- 職務発明に当たるかどうかを書かないでください。
- 報奨の額を計算しないでください。
- 発表してから出願すればよい、と受け取れる書き方をしないでください。
  新規性の喪失の例外については、「知財部へ回します」とだけ書いてください。
- 出願するか、秘匿するかを書かないでください。
- 技術の内容に触れないでください。
- 該当する記載が見つからないときは、
  「規程と手引きに該当する記載が見つかりません。知財部へ回します」
  とだけ書いてください。

「発表してから出願すればよい、と受け取れる書き方をしない」が、この指示の要です。 例外の条文を禁じるだけでは、手引きにある「やむを得ず発表した場合は」という節を要約して同じことを書きます。書き方そのものを禁じ、その話題は回す条件の側で拾います。

検索の文は、中継プログラムが組み立てます。 例えば「種類：発表前の手続き、発表の形：学会の口頭発表、発表の予定日：2026-11-20、発明届：未提出、共同研究：なし。発表の前に何をすればよいか」のように、条件を先に並べ、研究者の質問の文を最後に足します。 技術の説明の部分は渡しません。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に整えて、チャットと記録に渡します。

{
  "inquiry_id": "",
  "session_id": "",
  "lab": "",
  "category": "disclosure | reward | pre_publication | other",
  "conditions": { "publication_type": "conference | paper | exhibition | customer | press | none", "publication_date": "", "disclosure_filed": false, "disclosure_no": "", "disclosure_date": "", "joint_research": false },
  "rule_version": "",
  "status": "answered | escalated | skipped",
  "escalate_reason": "already_public | employee_invention_judgment | reward_objection | joint_research | deadline_short | not_in_rules | version_mismatch | skipped | user_request | none",
  "answer_text": "",
  "internal_deadlines": [ { "step": "", "due_date": "", "rule_row": "" } ],
  "refs": [ { "doc_type": "rule | guide | statute | qa", "title": "", "article": "", "version": "", "uri": "" } ],
  "feedback": "resolved | escalated_after | wrong | none"
}

1つ目の理由は、conditions を回答と一緒に残せることです。 知財部へ回すとき、発表の予定日と届出の状況がそのまま渡るので、担当者は聞き直さずに出願の段取りに入れます。

2つ目は、internal_deadlines を回答の文と分けられることです。 日付は締め切りの表から中継プログラムが計算し、rule_row に表の行を残します。回答の文の中に別の日付が出てきたら、回答を出さずに回します。

3つ目は、escalate_reason で回った理由を数えられることです。 already_public が多い研究所は、発表前の手続きの説明会を開く材料になります。 deadline_short が多い発表の形は、締め切りの表の日数を見直します。

システムへ連携する

発明届の受付の仕組みには、書き込みません。 届出は研究者が受付の仕組みから出し、チャットは届出の画面へのリンクを示すだけです。 受付の仕組みの照会のしかたは製品によって違い、この部分は個別の実装が必要です。

人が確認する

研究者は、回答を読んだあと、根拠の規程と手引きのページを開いて確かめてから手続きを進めます。 回答の上には、選んだ条件と、適用した規程の版を並べて表示します。

1. 条件が合っているかを見る … 発表の予定日と形、共同研究かどうかが、実際と合っているかを確かめます
2. 規程の版を見る … 報奨の質問では、届出の日と版が合っているかを見ます
3. 評価を付ける … 解決した／知財部へ回した／誤りを選びます

1番目を軽く見ないでください。 共同研究の契約があるのに「なし」を選ぶと、社内の規程だけで答えが返り、契約の定めが抜け落ちます。 迷ったら「分からない」を選べるようにし、それも回す値にします。

知財部の担当者は、回ってきた質問だけを見ます。 already_public と deadline_short はその日のうちに研究者と話し、出願の段取りを決めます。

目標は、150件をならして1件6分です。 チャットで解決した質問の記録の確認と、回ってきた質問を担当者が判断する時間の平均です。

例外に対処する

2行目は、運用の約束として研究者に伝えておきます。 公にしてしまったことを報告できる窓口だと分かっていないと、研究者は「発表前に何をすればよいか」という形で聞き、手続きの案内で済ませてしまいます。

記録を残す

• 質問の文、選んだ聞き返しの値、日時、所属と研究所
• 中継プログラムが組み立てた検索の文と、使った絞り込みの式
• answer メソッドの応答の全文（回答、出典、根拠のスコア、回答しなかった理由）
• 計算した締め切りの日付と、締め切りの表の行
• 回す・回さないの判定と、その理由、知財部が最終的に答えた内容
• そのとき効いていた規程と手引きの版

最後の行は、報奨の行き違いを後から確かめるときに効きます。 「あのとき登録時にももらえると聞いた」という申出に、当時の版と返した回答を並べて見られるようにしておきます。