社内の発明届の受付から出願までの進み具合を毎月集計し、止まっている届と理由の候補、担当への確認の文を知財部に届ける

処理の起点を決める

時間主導型のトリガーを、毎月第1営業日の朝7時台に1つ置きます。 部会は第2週にあるので、担当者が要約を読み、催促を送り、返事が1週間分たまってから部会に出る順になります。部会の直前に動かすと、催促が間に合いません。

月の半ばにもう1回、発表の予定日だけを見るトリガーを置きます。 学会や展示会、製品の発売の予定日が60日以内に迫り、まだ出願していない届だけを拾い、担当者と部長に知らせます。月1回の点検では、発表日の直前の1か月を見落とすからです。

処理は担当者ごとに区切り、どの担当者まで終わったかをスクリプト プロパティに残します。 1回の実行が5分を過ぎたら区切り、15分後の続きのトリガーで再開します。

入力データを集める

質を決めるのは、メールの件名の決まりです。 件名に [INV-2026-031] のように届の番号を入れたメールだけを、その届のやり取りとして読みます。名前や届の名称で探すと、別の届のメールが混ざります。 混ざったメールから要約すると、別の届の事情が理由の候補に並びます。

届の名称は渡しますが、発明の内容は渡しません。 台帳の「発明の概要」の列と、メールの添付ファイルは読みません。

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

台帳とやり取りの記録は、シートの範囲をまとめて読みます。段階が「出願済み」「放棄」「秘匿で確定」の届は、最初に外します。

メールは subject: に届の番号を入れた検索で、直近90日に絞って取ります。 1通ごとに日付、差出人、宛先と、本文の冒頭の数百字だけを取り出します。引用された過去のメールの部分は、> で始まる行と「-----Original Message-----」以降を切り落とします。

OpenAI API の鍵はスクリプト プロパティに置き、UrlFetchApp で呼びます。 muteHttpExceptions を true にして、失敗の状態コードでも応答を受け取り、送り直すかを決めます。

AIへ渡す前に整形する

1. 経過日数の計算 … 段階に入った日から今日までの暦日を数えます
2. 止まっている届の選択 … 設定のシートの日数を超えた届を選びます。発表の予定日まで60日を切り、出願していない届は日数にかかわらず選びます
3. 最後に動いた日の計算 … やり取りの記録とメールのうち一番新しい日付を出します。段階に入った日より、こちらのほうが「止まっている」をよく表します
4. 本文の切り詰め … メールの引用部分と署名を落とし、冒頭だけを残します
5. 技術の内容の除去 … 本文から、設定のシートに書いた技術の語の一覧と、数式・寸法・材料の組成のような数字の並びを伏せます
6. 個人の情報の扱い … 発明者の氏名は「発明者A」のように置き換え、誰が次に動くかは役割（発明者／調査担当／事務所／審査会事務局／知財部）で返させます
7. 入力の上限 … やり取りの記録10件とメール5通を超える分は渡しません

5番目は、完全には伏せきれないものとして扱います。 進み具合のメールにも、技術の話は混ざります。だから本文は冒頭の数百字に限り、添付ファイルは読みません。 伏せた語の数をログに残し、多い届は要約の対象から外して担当者に戻す設定にもできます。

6番目で役割に置き換えるのは、確認の文の宛先を決めるのがスクリプトだからです。 AIには「発明者に聞く」とだけ返させ、宛先のメールアドレスはスクリプトが台帳から入れます。

AIに処理させる

させるのは2つです。 1つ目は、止まっている届ごとに、やり取りから「最後に誰が何を頼み、何が返っていないか」を要約し、止まっている理由の候補と次に動く人を挙げること。2つ目は、次に動く人への確認の文の下書きです。

理由の区分は、waiting_inventor（発明者の返事待ち）、waiting_search（調査の結果待ち）、waiting_committee（審査会の議題待ち）、waiting_firm（事務所の作業待ち）、waiting_ip_dept（知財部の手元で止まっている）、on_hold_by_request（発明者や事業部の依頼で保留中）、unknown です。

waiting_ip_dept を区分に入れているのが、この構成の分かれ目です。 発明者が返したメールに知財部が反応していない届は、担当者からは「発明者待ち」に見えています。最後のやり取りが外から知財部へ届いたものなら、ボールは知財部にあります。 これを要約で言い当てると、第3章の（c）が一覧に出てきます。

いちばん起きやすい失敗は3行目です。 記録が少ない届について、AIは「発明者が多忙のため確認が遅れていると考えられます」のような文で埋めがちです。記録に無ければ unknown で、それは担当者が聞くべき届だという合図です。

指示内容を固定する

あなたはメーカーの知的財産部で、発明届の進み具合を点検する立場です。
1件の発明届について、やり取りの記録とメールを読み、次を答えてください。
発明の技術の内容には触れないでください。

【答えること】
1. recent_steps: 最後の3つのやり取りを古い順に、日付・誰から・誰へ・何を、で
2. stall_reasons: 止まっている理由の候補を次の区分から1つか2つ
   waiting_inventor / waiting_search / waiting_committee / waiting_firm /
   waiting_ip_dept / on_hold_by_request / unknown
3. next_actor: 次に動く人を役割で1つ
   inventor / searcher / committee_office / patent_firm / ip_dept / unknown
4. evidence: 理由の候補を決めた文を、記録からそのまま写す
5. message_draft: next_actor に、何をいつまでにお願いしたいかを伝える短い文

【厳守事項】
- 記録とメールに書かれたことだけを根拠にしてください。
- 記録に無い事情（多忙、繁忙期、優先度が低い、など）を推測で書かないでください。
- 最後のやり取りが社外や発明者から知財部へ届いたもので、その後に知財部からの返信が無ければ、waiting_ip_dept を候補に入れてください。
- 分からなければ unknown にしてください。unknown は誤りではありません。
- 経過日数や期限を計算し直さないでください。渡した値をそのまま使ってください。
- 出願するかどうか、発明の価値、関係者の良し悪しを書かないでください。
- next_actor が unknown のときは、message_draft を null にしてください。
- 伏せ字（■）の中身を推測しないでください。

【届の番号と名称】{disclosure_id} {title}
【今の段階・段階に入った日・経過日数・決めた日数】{stage}
【発表の予定日と種類】{publication}
【次の審査会の議題の締切】{committee_deadline}
【やり取りの記録（新しい順に最大10件）】{log_rows}
【メール（新しい順に最大5通、冒頭のみ）】{mails}

「unknown は誤りではありません」と書くのが要点です。 書かないと、AIは何か答えを出そうとして記録に無い事情を足します。分からないという答えが、担当者が手を動かすべき届を教えてくれます。

waiting_ip_dept の条件を具体的に書いているのは、AIが知財部の立場から読むと、自分の側の遅れを候補に挙げにくいからです。 最後のメールの向きという、記録から機械的に確かめられる条件にします。

出力形式を固定する

次の形のJSONで受け取ります。 stall_reasons と next_actor は区分を enum で列挙します。

{
  "disclosure_id": "INV-2026-031",
  "recent_steps": [
    { "date": "2026-09-02", "from": "patent_firm", "to": "ip_dept",
      "what": "明細書案の第1稿を送付" },
    { "date": "2026-09-03", "from": "ip_dept", "to": "inventor",
      "what": "明細書案の確認を依頼" },
    { "date": "2026-09-19", "from": "inventor", "to": "ip_dept",
      "what": "修正の要望を返信" }
  ],
  "stall_reasons": ["waiting_ip_dept"],
  "next_actor": "ip_dept",
  "evidence": "9/19 発明者より：図3の説明に追記をお願いします",
  "message_draft": null
}

1つ目の理由は、next_actor で確認の文の宛先をスクリプトが決められることです。 inventor なら台帳の発明者、patent_firm なら台帳の事務所の担当、ip_dept なら下書きを作らずに担当者本人への知らせにします。AIにメールアドレスを書かせないので、宛先を取り違えることがありません。

2つ目は、evidence を記録と照らせることです。 スクリプトは evidence の文字列が、渡したやり取りの記録かメールに実際に含まれているかを確かめます。含まれていなければ、その届の理由の候補を unknown に戻します。

3つ目は、recent_steps の日付で「最後に動いた日」を照らせることです。 スクリプトが前処理で出した最後の日付と、recent_steps の最後の日付が違えば、要約が古いやり取りを拾っています。その届は要約を作り直します。

部会用の一覧のシートには、届ごとに次の列を並べます。

システムへ連携する

台帳には書き込みません。 理由の候補が正しくても、段階を進めるのは担当者です。確認の文は下書きまでにし、発明者や事務所へは担当者が送ります。 発明者に知財部からの催促が機械的に届くと、届を出すこと自体が面倒に思われます。

人が確認する

1. 発表の予定日が近い届を先に見る … 出願の前に発表されると困る届です。部長にもその日のうちに伝えます
2. waiting_ip_dept の届を見る … 自分の受信箱で止まっていた届です。催促ではなく、自分が動きます
3. unknown の届を見る … 記録が足りない届です。担当者が発明者や事務所に直接聞きます
4. その他の届の理由の候補を確かめる … 自分の知っている事情と合わなければ、見立ての欄に書きます
5. 確認の文を直して送る … 相手と時期を決めて送ります
6. 部会で一覧を見る … 部長が優先順と打つ手を決めます

2番目を最初のほうに置いているのは、一番早く片づくからです。 自分の手元で止まっていた届は、その日のうちに動かせます。

目標は、180件をならして1件2分です。 一覧の計算と要約を読んで見立てを書くのが1件1分前後、止まっている届の確認と催促が数分、という想定です。

例外に対処する

3行目の no_record は、AIを呼ばずに一覧へ載せます。 記録の無い届をAIに渡しても、要約できるものがありません。記録が無いまま決めた日数を超えた届は、それだけで担当者が発明者に連絡すべき届です。 一覧では unknown より上に並べます。

5行目の「伏せた語が多い」は、届の分野によって偏ります。 材料や回路の届は、進み具合のメールにも組成や部品の型番が書かれがちです。その分野は、やり取りの記録のシートに要点を書く運用を強めるほうが早く効きます。

記録を残す

• 点検した月、届ごとの段階・経過日数・最後に動いた日
• AIに渡したやり取りの件数と、伏せた語の数
• 要約の結果（recent_steps、stall_reasons、next_actor、evidence）
• 確認の文の下書きと、担当者が送ったかどうか、送った日
• 担当者が理由の候補を直した記録
• 部会の決定と、翌月にその届の段階が進んだか

最後の2行を並べて残すのが、この構成を育てる材料です。 候補が waiting_firm から担当者の見立てで別の区分に直される届が多いなら、事務所とのやり取りがメールの外で行われています。