発明届と発明者との打合せ記録から、特許事務所へ出す出願依頼書を下書きし、足りない情報を発明者への確認質問にする

処理の起点を決める

担当者が確認リストの状態を「下書き依頼」にしたことを起点にします。 「アイテムが作成または変更されたとき」のトリガーは状態以外の列を変えても動くので、フローの最初で状態が「下書き依頼」かを確かめ、違えば何もせずに終えます。 下書きを保存したら、状態を「下書き済み」に変えます。

文字起こしが保存されたことを起点にはしません。 打合せが2回に分かれる案件や、図面のラフが後から届く案件があります。資料が途中のまま動くと、「図面の指示が無い」という見当違いの質問が出ます。そろったと判断するのは担当者です。

発明者の回答が届いて資料を足したら、担当者が状態を「下書き依頼」に戻します。同じ案件の下書きを作り直し、前の版は消さずに残します。 版を並べると、回答で何が埋まったかが分かります。

入力データを集める

質を決めるのは、いちばん下の確認事項の書き方です。 「実施例を書く」だけでは、何がそろえば足りるのかが分かりません。「実施例：構成の具体例、効果を確かめた条件、比較の対象、結果の数値」のように、事実の単位で書きます。 確認質問は、この行と資料を突き合わせて出ます。

公表の予定日は必ず入れます。 学会発表や製品の展示会が決まっている案件は、それより前に出願する必要があるので、質問の期限と依頼書の送付日をそこから逆算します。 下書きの冒頭に、その日付をそのまま書かせます。

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

発明届は1件だけを引きます。 同じ発明者の別の届を混ぜると、別の発明の構成が実施例に紛れます。発明届の番号で絞り、返ってきた件数が1件でなければ止めます。

図面のラフは、中身ではなくファイル名と図の番号の一覧として渡します。 図面の指示で要るのは「どの図に何を描くか」で、図そのものの読み取りは担当者と弁理士が行います。 発明者が図に付けた説明の文字は、文字起こしと同じく番号を振って渡します。

AIへ渡す前に整形する

1. 資料のそろいの確認 … 発明届、文字起こし、調査結果の3つがあるかを見ます。図面のラフは任意です。無いものは、そのまま「資料が無い」としてAIに伝えます
2. 文字起こしを発言ごとに分ける … 話者と時刻で区切り、T-001 のような番号を付けます
3. 相づちと雑談を落とす … 「はい」「なるほど」だけの発言と、冒頭・末尾の日程調整の発言を除きます。番号は振り直さず、欠番にします
4. 発明届の項目に番号を振る … R-構成、R-効果 のように項目名で付けます
5. 調査結果の文献に番号を振る … 文献ごとに P-01 を付け、対比のメモを並べます
6. 社外の固有名を伏せる … 打合せで出た取引先や共同開発の相手の名前を、取引先A のように置き換えます
7. 数値の一覧を作る … 文字起こしと発明届から、数字と単位を含む発言を抜き出し、番号と並べて表にします。後段で下書きの数値と照らすための表です

3番目で番号を振り直さないのは、根拠の番号と元の文字起こしを1対1で結ぶためです。 振り直すと、担当者が T-084 を開いたときに元の時刻と合わなくなります。

7番目は、AIに渡すと同時にフローの側にも持っておきます。 下書きに出てきた数値が、この表のどの行にあるかを機械的に照らせるようにするためです。

AIに処理させる

させるのは、依頼書の10項目を下書きすることと、埋められない項目を確認質問にすることです。どちらも、渡した資料の番号を根拠にします。

「権利化したい範囲」は、この中でいちばん慎重に扱います。 打合せで出た希望は書きますが、上位の概念への言い換え（「ばね」を「付勢部材」とするような）は、本文とは別の generalization_candidates に置かせます。採るかどうか、どこまで広げるかは担当者と弁理士が決めます。

指示内容を固定する

あなたは製造業の知財部で、特許事務所へ出す出願依頼書の下書きを作る担当者です。
渡された資料に書かれていることだけを根拠にしてください。

【書くこと】
依頼書の書式の10項目を、項目ごとに書いてください。
あわせて、項目ごとの確認事項のうち、根拠になる発言・資料が無いものを、
発明者への確認質問にしてください。

【厳守事項】
- 1文ごとに、根拠にした発言・資料の番号（T-xxx、R-xx、P-xx、図-x）を付けてください。
  番号を付けられない文は書かないでください。
- 実施例と変形例は、発明者が述べたもの（T-xxx）か発明届（R-xx）にあるものだけを
  書いてください。「〜でもよい」「〜も考えられる」と自分で足さないでください。
- 数値は、資料にある値と単位をそのまま書いてください。
  換算、丸め、範囲を広げる・狭めることをしないでください。
- 上位の概念への言い換え（例：「ばね」→「付勢部材」）は本文に書かず、
  generalization_candidates に、元の語と言い換えの候補と根拠の番号を並べてください。
- 特許請求の範囲の文案、特許になるかどうかの見込みを書かないでください。
- 調査結果の文献との違いは、文献の番号ごとに、どの構成がその文献に無いかを書いてください。
  対比のメモが無い文献は「対比なし」と書き、推測で違いを書かないでください。
- 埋められない項目は missing_note に理由を書き、確認質問を作ってください。
  確認質問は、発明者が「はい／いいえ」か数値で答えられる形を優先し、
  なぜ必要かを1文添えてください。
- 社外の固有名は、置き換えた表記（取引先A など）のまま使ってください。

【審査会の結論と公表の予定】{decision}
【依頼書の書式】{form}
【項目ごとの確認事項】{checkpoints}
【発明届】{disclosure}
【打合せの文字起こし】{transcript}
【先行技術の調査結果】{prior_art}
【図面のラフの一覧】{drawings}

「自分で足さないでください」と、足しがちな言い回しまで書くのが要点です。 実施例を書けと言われると、AIは発明者の構成から自然に広がる変形を「〜でもよい」の形で書き足します。その1文が、第3章の（d）の再現になります。

確認質問を「はい／いいえか数値で答えられる形」にするのは、発明者の返事を早くするためです。 「変形例を教えてください」と聞くと返事が来ません。「ばねの代わりにゴムでも同じ効果が出ますか」なら、開発の合間に答えられます。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力を使い、JSON Schema に沿った形で返させます。

{
  "case_id": "",
  "sections": [
    {
      "section": "title | field | background | gist | difference | embodiment | variation | scope | drawings | filing",
      "sentences": [ { "text": "", "sources": ["T-084", "R-構成"] } ],
      "missing_note": ""
    }
  ],
  "prior_art_comparison": [
    { "doc_id": "P-01", "absent_features": "", "status": "compared | not_compared" }
  ],
  "generalization_candidates": [
    { "original_term": "", "candidate": "", "sources": ["T-112"] }
  ],
  "questions": [
    { "section": "", "question": "", "why_needed": "", "answer_type": "yes_no | number | text" }
  ],
  "numbers_used": [ { "source": "T-084", "value_in_text": "" } ]
}

1つ目の理由は、文と根拠を同じ要素に持たせられることです。 確認リストでは文の横に番号が並び、担当者は番号からその発言だけを開きます。

2つ目は、section と answer_type を enum で縛れることです。 構造化出力は enum に対応しているので、書式に無い項目が増えることも、質問の種類が自由な文になることもありません。 構造化出力ではすべての項目を必須にし、additionalProperties を false にする決まりがあるので、空の項目も必ず返ってきます。「書かなかった」と「書き忘れた」が区別できます。

3つ目は、generalization_candidates を本文と別の層に置けることです。 Word の依頼書では、言い換えの候補を「担当者確認用」の欄に流し込み、事務所へ送る前に、採ったものだけを本文へ移します。

numbers_used は、フローが前処理の数値の一覧と照らします。一覧に無い数値が1つでもあれば、下書きに印を付けて担当者に知らせます。

システムへ連携する

テンプレートのコンテンツ コントロールには使えない種類があります。 対応しているのはプレーン テキスト、コンボ ボックス、ドロップダウン リスト、イメージ、繰り返しセクションで、リッチ テキストは対応していません。 項目ごとの本文はプレーン テキストのコントロールにし、プロパティで「複数の段落」を許可しておくと改行が入ります。

文献ごとの対比と確認質問は、繰り返しセクションで表の行にします。 行の数は案件ごとに違うので、フローで値の配列を作って渡します。コントロールの名前はテンプレートの中で一意にする必要があり、重複すると両方に同じ値が入ります。

依頼書は事務所へ自動で送りません。 送るのは課長の確認の後で、送信は担当者が行います。

人が確認する

担当者が見るのは、下書きの全文と、印の付いた箇所と、言い換えの候補です。 文字起こしを頭から読み直すことはしません。

1. 印の付いた数値を先に見る … numbers_used が数値の一覧と合わなかったものです。丸めか単位の取り違えがほとんどです
2. 実施例と変形例の根拠を開く … 1文ごとの番号から発言を開き、発明者がそう言っているかを確かめます
3. 言い換えの候補を採るかを決める … 採るものだけを本文へ移します。迷うものは弁理士との面談の論点に回します
4. 確認質問を整えて送る … 重複を除き、発明者が答えやすい順に並べ替えます。送信は担当者が行います
5. 直した箇所を記録する … どの項目の、どの文を、なぜ直したかを残します

2番目を省かないでください。 依頼書に書いた実施例は、事務所にとっては発明者が確かめた事実です。根拠の番号が付いていても、発言の読み違いで別の構成を書いていることがあります。

目標は、1件70分です。 打合せの記録を読み直す60分が、根拠を開いて確かめる時間に置き換わる想定です。それより長くかかる案件は、打合せで構成が詰まっていないことが多く、質問が多く出ます。

例外に対処する

上から4行目が、この構成で気をつけたい例外です。 打合せの中で発明者が言い直すことはよくあります。どちらかを選ばせると、言い直す前の古い構成が依頼書に残ることがあります。 両方を並べて発明者に聞けば、1往復で決まります。

記録を残す

• 下書きの依頼の日時と、そのときの資料の一覧（ファイル名と更新日時）
• 前処理で番号を振った文字起こし・発明届・調査結果
• Azure OpenAI に渡した指示と、返ってきたJSONの全文
• 数値の照合の結果
• 担当者が直した箇所と理由、採った言い換えの候補
• 確認質問と、発明者の回答、回答を反映した版
• 事務所へ送った依頼書の最終版と送付日

5つ目が、書式と確認事項を直す材料になります。 同じ項目ばかり直されているなら、確認事項の書き方か、打合せでの聞き方のどちらかが足りていません。 月に一度、直した箇所を項目別に数えます。

最後の行は、事務所からの問い合わせと突き合わせます。 依頼書を送った後に事務所から何を聞かれたかを残すと、確認事項に足すべき行が見えてきます。