社員から届いた発明届出書を読み取り、技術分野と出願・秘匿の方針区分で一次仕分けして、職務発明審査会の資料にする

処理の起点を決める

「受付」フォルダを1時間ごとに見回り、新しいファイルがあれば処理を始めます。 1日1回にすると発表予定の見落としに気づくのが翌日になるため、1時間おきを上限にします。

審査会の締め切り日の翌朝に、全件を見直す処理を別に動かします。 未処理や unreadable のまま残ったものがないかを確かめ、一覧を確定前の形で書き出します。

処理が終わったファイルは「処理済み」フォルダへ移します。移すのは、一覧への書き出しまで成功したときだけです。 受付フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、様式の定義と技術分類の説明文です。 様式の定義がなければ空欄の判定ができません。様式は改訂されるので、版ごとに定義を持ちます。

過去の出願は、改良発明かどうかを見るために持ちます。 同じ発明者の過去の出願の改良なら、先行調査の多くは済んでいます。

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

届出書の読み取りは、Google Apps Script から Form Parser を呼び出して行います。同期処理（その場で結果を受け取る呼び方）は15ページ・40MBまでです。実験データの添付で15ページを超えるものは、バッチ処理（後から結果を受け取る呼び方。100ページまで）に回します。

text には欄の区切りが残りません。 スペース・タブ・改行以外のレイアウトの構造を含まないので、どの文がどの欄のものかは、要素の位置（boundingPoly）と様式の定義を重ねて決めます。 要素と text の対応は textAnchor で引けます。

出願台帳は、毎晩書き出している一覧を読みます。照合は発明者の社員番号が先、名称が後です。

AIへ渡す前に整形する

1. 形式の確認 … Document AI が受け付けるのはPDF、TIFF、JPEG、PNG、BMP、WebP、GIF などです。WordのファイルはPDFに書き出してから入れます（Word を直接読めるのは Layout Parser だけのため）
2. 解像度の確認 … ドキュメントでは、スキャンは200dpi以上が推奨されています。複合機の設定がこれを下回っていないかを最初に確かめます
3. ページ数とサイズの確認 … 同期処理は15ページ・40MBまで。超えるものはバッチ処理に回します
4. 様式の版の判定 … 1ページ目の版番号を読み、欄の定義を選びます。版番号が読めなければ needs_human にします
5. 欄の切り出し … 様式の定義と要素の位置を重ね、欄ごとに文字を集めます
6. 記載の有無の判定 … 欄に文字がなければ empty、文字はあるが信頼度が低い、または画像の品質に問題があれば unreadable、それ以外は filled
7. 添付の分離 … 様式のページと添付資料のページを分け、添付は「補足資料あり」の印だけを付けます

6番目を、この構成でいちばん丁寧に作ります。 Form Parser は値が空のキーと値のペアを確実には取り出せないので、formFields に出てこないことを「空欄」とみなしてはいけません。 欄の位置に文字の要素が1つもないことを確かめて、はじめて empty にします。

AIに処理させる

させるのは、技術分野の候補を選ぶことと、方針を決める観点ごとに「届出書にどう書かれているか」を根拠の文とともに書き出すことだけです。

2行目と3行目が、方針区分の中心です。 製品を見れば分かる発明は秘匿しても知られてしまうので出願に向き、工場の中だけの製造条件は出願すると公開されるので秘匿に向く、というのが一般的な考え方です。どちらに寄せるかは会社の知財戦略で決まるので、AIには事実だけを書き出させます。権利化と秘匿化の判断は、INPIT（工業所有権情報・研修館）の営業秘密支援窓口でも相談を受け付けている論点です。

3行目がいちばん起きやすい失敗です。 実施例の欄が空の届出書を渡すと、解決手段の欄から実施例らしい文を組み立てて「記載あり」と書き出し、その瞬間、発明者に書き足しを頼む機会が消えます。

指示内容を固定する

あなたは知財部で、社員から届いた発明届出書を審査会の前に一次仕分けする立場です。
渡された届出書の欄の内容だけを見て書き出してください。推測で埋めないでください。

【やること】
1. 技術分野の候補を、渡した技術分類の一覧から最大2つ選び、理由を1文で書く
2. 次の観点ごとに、届出書の記載を根拠の文とともに書き出す
   - product_visible : 発明の特徴が、完成品の外観・構造・動作に現れるか
   - detectable      : 他社が実施した場合に、市販品や公開情報から確かめられそうか
   - disclosure_plan : 学会・展示会・論文・顧客への提示などの予定と日付
   - prior_filing    : 渡した過去の出願との関係
   - problem_solution: 課題と解決手段が対応して書かれているか

【値の選び方】
- product_visible / detectable : yes / no / unknown
- disclosure_plan : planned / none / not_stated
- prior_filing    : improvement / unrelated / unclear / no_data
- problem_solution: clear / unclear
迷ったときは unknown または unclear を選んでください。

【厳守事項】
- 出願すべきか、秘匿すべきかは書かないでください。
- 特許になりそうか、新しいかどうかの評価も書かないでください。
- evidence には、判断の根拠にした文を届出書からそのまま写してください。
  要約や言い換えをしないでください。根拠の文がなければ空にしてください。
- 欄の状態が empty のものは「記載なし」として扱い、他の欄から補って
  埋めないでください。実施例が空なら、解決手段から実施例を作らないでください。
- 欄の状態が unreadable のものは判断に使わず、その観点を unknown にしてください。
- 発表予定の日付は書かれたとおりに写してください。「秋」「来年度」を
  特定の日付に直さないでください。
- 技術分類の一覧にない分類名を作らないでください。当てはまらなければ none です。
- 発明者の評価や、貢献の大小に触れないでください。

【届出書の欄と状態】{sections}
【技術分類の一覧（コード・名前・説明文）】{tech_fields}
【過去の出願（同じ発明者・近い名称）】{prior_filings}
【次回の審査会の開催日】{meeting_date}

「evidence は届出書からそのまま写す」を明記しないと、要約した文が入ります。 要約された根拠は読みやすい一方で、届出書のどこに書いてあったかを探せなくなります。仕分け担当が確かめるのは、根拠の文が届出書に本当にあるかどうかなので、原文のまま写させます。

「出願すべきかを書かない」を最初に置くのは、 観点の後に「以上から出願が適当」とまとめたがるからです。結論の一文があると、読む人は根拠より先にそれを見ます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（あらかじめ決めたJSONの形に沿った応答だけを返させる機能）を使い、enum で値の選択肢を固定します。

{
  "receipt_no": "",
  "form_version": "",
  "sections": [
    { "name": "background", "state": "filled | empty | unreadable" }
  ],
  "tech_field": [
    { "code": "", "reason": "" }
  ],
  "aspects": [
    { "aspect": "product_visible", "value": "yes | no | unknown", "evidence": "" }
  ],
  "disclosure": { "value": "planned | none | not_stated", "date_text": "", "evidence": "" },
  "policy_track": "file_candidate | secret_candidate | on_hold",
  "prior_art": "internal_search | outside_firm | covered_by_prior | on_hold",
  "urgent": false,
  "resend_draft": ""
}

sections には様式の欄の数だけ要素を並べ、aspects には観点を4つ並べます。policy_track、prior_art、urgent の3つは、生成AIではなく Google Apps Script の規則が埋めます。

1つ目の理由は、観点と方針区分を別の層に置けることです。 aspects はAIが埋め、policy_track は規則が決めます。

会社の方針が変わっても、直すのはこの表だけです。 たとえば「見つけにくい技術でも、事業の中核なら出願する」と決めたら、技術分類ごとの例外を規則に足します。

2つ目は、至急の印を機械的に付けられることです。 disclosure が planned で、date_text から日付が読み取れ、それが次回の審査会より前なら urgent を true にします。日付が読み取れない「秋の学会」のようなものも urgent にします。 空振りは担当者が1分で外せますが、見落としは取り返しがつきません。

3つ目は、prior_art を規則で決められることです。 improvement なら covered_by_prior、出願の少ない分類なら outside_firm、それ以外は internal_search にして担当者が J-PlatPat で引きます。

システムへ連携する

知財管理システムへは書き込みません。 出願案件として台帳に載せるのは、審査会で「出願する」と決まってからで、それは人が登録します。 仕分けの段階で台帳に書くと、審査会で不採用になった届出書が案件として残ります。

書き足し依頼も、下書きまでにします。 送るのは仕分け担当です。発明者の上長をCCに入れるかどうかは、届出書の中身と部署の事情で変わります。

人が確認する

仕分け担当は全件を見ます。 ただし、見るのは届出書の全文ではなく、一覧の1行と根拠の文です。

1. urgent を最初に見る … 発表予定と日付の根拠の文を読み、審査会の前に発表が来るなら、臨時の審査か発表内容の調整を知財部長に相談します
2. on_hold を見る … unknown になった観点を、届出書の該当箇所で確かめます。多くは発明者への質問1つで解決します
3. file_candidate と secret_candidate の根拠を確かめる … 根拠の文が届出書にあるか、その文から本当にそう読めるかを見ます
4. 所見を書く … 区分を変えた場合は、どの観点をどちらに変えたかを残します
5. 書き足し依頼を直して送る … empty の欄が本当に空欄かを画像で確かめてから送ります

3番目では、根拠の文と値の食い違いを見ます。 食い違っていたら、値を直すのではなく、その届出書を全文で読みます。

ベテランの見直しは、若手が区分を変えたものと on_hold に絞ります。 若手がどの観点で迷ったのかが1行で読めます。

例外に対処する

上から4行目までが大半を占めます。 どれもAIではなく、様式の管理とスキャンの設定の問題です。

記録を残す

• 元の届出書ファイルと、受付番号・受け付けた日時・届いた経路
• OCRが返したJSONの全文と、欄ごとの状態（filled ／ empty ／ unreadable）
• 生成AIへ渡した入力と、返ってきたJSONの全文
• 規則が決めた policy_track、prior_art、urgent と、そのとき使った規則の版
• 仕分け担当が区分や観点を変えた記録 … どの観点を、どちらに、なぜ変えたか
• 審査会の決定（出願／秘匿／保留／不採用）と、一次仕分けとの一致・不一致

4つ目で「規則の版」を残すのは、方針が後から変わるためです。 秘匿に寄せる技術分類を増やせば過去の区分の意味が変わり、当時の規則が残っていないと、どこまで見直せばよいかが決まりません。

最後の行は、規則を見直す材料になります。 ずれが特定の技術分野に偏っていたら、その分野の規則か説明文を直す時期です。