技術者の打ち合わせメモから発明届出書の下書きを作る

処理の起点を決める

技術者が「これは発明かもしれない」と思った時点が起点です。システム上のトリガーはありません。

ただし、起点を人の気づきだけに任せると届出漏れが起きます。運用で2つの入口を足してください。

• 設計レビューや試作報告の直後。 「今日の議論で新しいところはあったか」を会議の最後に聞き、あれば当日中にメモをプロジェクトに投げる
• 学会発表や展示会の申し込み時。 発表内容が決まった時点で、発明届出の要否を確認する。これは新規性の観点から必須です

入力データを集める

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

打ち合わせメモ： 技術者が話した内容をそのまま貼り付けます。整った文章である必要はありません。むしろ、整えようとして時間をかけるのが、今まさに削ろうとしている作業です。 箇条書き、言い切らない文、順序がばらばらでも構いません。

写真： 生成AIに画像として渡せます。ただし、写真から寸法や材質は読み取れません。 「この部品は焼結金属です」といった説明は技術者が文章で足します。

様式と記入例： 知財部がプロジェクトの知識として一度入れておきます。技術者が毎回添付する必要はありません。

実験データ： 説明だけを渡し、実数値は技術者が後で入れる運用にします。 理由は後述します。

AIへ渡す前に整形する

技術者が特別な前処理をする必要はありませんが、知財部がプロジェクトを作るときの準備が実質的な前処理です。

1. 様式の欄を文章で説明する … 「従来技術の問題点」の欄に何を書くべきかを、様式のファイルとは別に文章で書きます。様式のWordファイルだけを入れても、欄名しか伝わりません
2. 記入例を3件選ぶ … 良い届出書を3件選びます。1件では型が固定されすぎ、10件では方向が散ります。 機械系、電気系、ソフトウェア系のように分野の違うものを混ぜます
3. 社外に出せない情報を除く … 記入例に顧客名、仕入先名、未公開の製品名が入っていれば、置き換えるか伏せます
4. 用語集を作る … 製品名の正式表記、部品の社内呼称と正式名称の対応。これが無いと、下書きに社内の略称がそのまま出ます
5. 注意事項を書く … 数値を推測させない、公開予定を必ず確認する、といった指示をプロジェクト指示に入れます

AIに処理させる

「不足の指摘」と「公開予定の確認」が、この構成で一番効く部分です。 下書きを作ることより、書けていない欄を技術者に気づかせることのほうが、差し戻しを減らします。

指示内容を固定する

プロジェクトの指示（すべてのチャットに適用される）に、次を設定します。

あなたは知財部の担当者として、技術者が発明届出書を書くのを手伝います。
技術者が話した内容から、添付した様式の各欄の下書きを作ってください。

【厳守事項】
- 実験値、寸法、材質、型番、日付を推測して書かないでください。
  技術者が言っていない数値は、必ず【要記入：測定値】のように
  記入欄として残してください。
- 効果の欄に「大幅に向上」「飛躍的に」といった程度の表現を
  使わないでください。何がどう変わるのかを事実として書き、
  程度は技術者の数値に委ねてください。
- 従来技術として、技術者が話していない他社製品や特許を
  挙げないでください。先行技術調査は知財部が別に行います。
- メモから書けなかった欄は、空欄にしたうえで
  「この欄には何が必要か」を質問として最後にまとめてください。
- 最後に必ず次を確認してください。
  「この内容を、学会・展示会・カタログ・顧客への提案資料などで
  すでに公開しましたか。または公開する予定はありますか。
  ある場合は、時期と相手を教えてください」

【様式】添付ファイルのとおり
【記入例】添付ファイルのとおり
【用語集】添付ファイルのとおり

「実験値を推測して書かない」の指示が最も重要です。 生成AIは、文脈から「20％向上」のようなもっともらしい数値を書いてしまうことがあります。発明届出書の数値は、後の出願書類と審査会の判断の根拠になります。技術者が下書きをそのまま提出すると、誰も測っていない数値が社内文書に載ります。 記入欄として残す形にして、技術者が埋めるまで空欄と分かるようにします。

出力形式を固定する

自由文で構いませんが、欄の見出しを様式と一致させます。

【発明の名称】（3案）
1. 
2. 
3. 

【技術分野】

【従来の技術】

【従来技術の問題点】

【課題を解決するための手段】

【効果】
※ 数値は【要記入】としています

【実施例】

【図面の説明】
※ 図番号は技術者が入れてください

────────────────
【技術者に確認したいこと】
- 
- 

【公開の状況について】
この内容をすでに公開しましたか。または公開予定はありますか。

最後の2ブロックを本文と線で区切って出させます。下書きをWordに貼り付けるとき、ここを消し忘れないためです。

システムへ連携する

システム連携はありません。 技術者が下書きをコピーして、Wordの様式に貼り付け、加筆して提出します。

連携を作りたくなりますが、この構成では作らないほうがよいと考えます。理由は、発明届出書は貼り付けて終わる文書ではなく、技術者が直しながら考える文書だからです。自動で提出まで流すと、直す工程が省かれます。

提出後は既存の発明管理台帳に入ります。ここは今までどおりです。

人が確認する

下書きは全件、技術者本人が読んで直します。知財部も従来どおり全件読みます。確認の工程は一切減らしません。

減っているのは、白紙から文章を組み立てる時間だけです。

技術者が確認すべき点を、下書きの末尾に定型で出させます。

• 数値の欄が【要記入】のまま残っていないか
• 従来技術の説明が、自社の実際のやり方と合っているか
• 解決手段の記述に、事実でない一般化が混ざっていないか
• 共同発明者の記載が漏れていないか

共同発明者は、AIには分かりません。 誰が発明に寄与したかは技術者と知財部が判断する事項です。職務発明の対価に関わるため、ここを曖昧にしないでください。

例外に対処する

記録を残す

技術者が生成AIに入力した内容は、原則として社内に残しません。 プロジェクトのチャット履歴は、発明の未公開情報を含みます。

残すのは次です。

• 提出された発明届出書（従来どおり発明管理台帳へ）
• 知財部が差し戻した件数と理由（構成を入れる前後で比較する）
• プロジェクトの知識として入れた様式・記入例・用語集の版

差し戻しの件数と理由は必ず記録してください。 この構成の効果は「下書きの質」ではなく「差し戻しが減ったか」で測ります。差し戻し理由の上位が変わらないなら、記入例か指示を直します。