特許事務所から届いた明細書の案を発明届と打合せの記録に照らし、記載の抜けと実施例の不足と狭すぎる請求項を修正依頼にまとめる

処理の起点を決める

事務所からの受領メールの到着を起点にします。 事務所から案が届くのは不定期で、締め日のような集中もありません。Power Automate で知財部の共有メールボックスを見張り、件名に案件番号を含むメールが届いたら、添付の Word を SharePoint の案件フォルダへ保存して、担当者に Teams で知らせます。

点検そのものは、担当者がエージェントを開いて始めます。 受領と同時に自動で点検を走らせることはしません。担当者は、案の版（初稿か再稿か）と、照合に使う発明届と議事メモの版を自分で選びます。どの版と照らしたかを人が決めることで、照合の前提を取り違えません。

件名に案件番号が無いメールは、保存せずに担当者へ回します。 事務所ごとに件名の付け方が違うので、取り決めの段階で「件名の先頭に案件番号」を頼んでおきます。

入力データを集める

質を決めるのは、3つ目の議事メモです。 発明届は発明者が最初に書いたもので、打合せでの方針の変更は入っていません。「材質は限定しない」「この実施例は外す」といった決定は、議事メモにしか残りません。議事メモに決定事項が書かれていなければ、狭すぎる請求項は拾えません。

再稿のときは、前回の指摘表も渡します。 前回の指摘が直っているかを、指摘表の行ごとに確かめさせます。再稿を最初から読み直す時間が、ここで消えます。

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

3つのファイルは、担当者がエージェントのチャットで指定します。 Word の Copilot では「/」を入力してファイル名を打つと参照先を選べるとされ、エージェントのチャットでも同じように案件フォルダのファイルを選べます。

同時に扱うファイルの数には上限があると考えて設計します。 OneDrive の Copilot では、要約・比較・Q&A などの複数ファイルへの操作が現在5ファイルまでとされています。この構成で1回に渡すのは3つ（再稿のときは前回の指摘表を足して4つ）に抑えます。 実験報告書などを追加で読ませたいときは、別の回に分けます。

議事メモは、打合せのたびに同じファイルに追記していく形にします。 打合せごとにファイルを分けると、どの回の決定が最新かが分からなくなります。1案件1ファイル、日付の新しい決定が上、を知財部の決まりにします。

AIへ渡す前に整形する

1. 案を「請求の範囲」と「発明の詳細な説明」に分ける … 事務所の Word を2つのファイルに分けて保存します。長い文書は分けて渡すよう、公開資料で勧められています
2. 段落番号を残す … 【0001】のような段落番号を消さずに残します。指摘表で箇所を示す手がかりになります
3. 発明届の欄の見出しをそろえる … 古い様式の発明届は、課題・構成・効果・実施例・変形例の見出しを今の様式に合わせて付け直します
4. 議事メモの決定事項に印を付ける … 決定事項の行の頭に「【決定】」と付けます。検討の途中の発言と、決まったことを分けるためです
5. パスワードを外す … パスワードで保護されたファイルはエージェントで使えないとされています。事務所には保護を付けずに送ってもらい、社内の保管で守ります
6. 図面は渡さない … 図面の簡単な説明の文章だけを本文側に残します。図面との対応は UC-0146 の点検の範囲です

1番目を軽く見ないでください。 公開資料では、大規模言語モデルはファイルの先頭と末尾の内容を優先しやすいとされ、長い文書は分けて渡すか、部分ごとに要約させることが勧められています。明細書の案は請求項が先頭、実施例が中ほどに来るので、1つのまま渡すと中ほどの実施例が手薄になります。 実施例の不足を見つけたいのに、その部分が読まれにくい、という形になります。

AIに処理させる

させるのは、発明届と議事メモから要点の一覧を作り、その1行ずつについて案のどこに書かれているかを判定することです。 判定は3つの型に分けます。

右端の列が、この構成でいちばん大事な区別です。 抜け と言い切るのは、どの段落にも見当たらないときだけです。似た記載があれば 一部のみ にして段落番号を挙げさせ、人が読んで決めます。 言い換えを抜けと判定した指摘を事務所に送ると、事務所の弁理士の時間を無駄にします。

実施例の不足は、請求項の広さと対にして出させます。 特許法第36条第6項第1号は、特許を受けようとする発明が「発明の詳細な説明に記載したもの」であることを求め、第36条第4項第1号は、発明の詳細な説明を、その分野の通常の知識を有する者が実施できる程度に明確かつ十分に記載することを求めています。請求項を広げたいなら、広げた範囲を支える実施例が本文に要ります。 だから「狭すぎる」の指摘には、「広げるなら足すべき実施例」を必ず添えさせます。

3行目がいちばん起きやすい失敗です。 実施例の不足を指摘させると、モデルは親切に「例えば材質をアルミニウムにした実施例を追加する」と書きます。実験していない実施例を明細書に書くことは、出願の内容そのものを作ることです。 足すべきなのは発明届と実験報告にある実施例だけで、無いなら発明者に聞く、が正しい流れです。

指示内容を固定する

エージェントの指示（Agent Builder の「指示」の欄に書くもの）の例です。

あなたは知財部の担当者が、特許事務所から届いた明細書の案を点検するのを手伝う役割です。
担当者が指定した「明細書の案」「発明届」「打合せの議事メモ」だけを根拠にしてください。

【進め方】
1. 発明届と議事メモから、発明の要点の一覧を作ってください。
   区分：課題／構成／効果／実施例／変形例／打合せでの決定
   議事メモの「【決定】」の行は、発明届より優先してください。
2. 要点の一覧の1行ずつについて、明細書の案のどの段落に書かれているかを探し、
   status を次から選んでください。
   - 記載あり ... 同じ内容が書かれている。段落番号を挙げる
   - 一部のみ ... 似た記載はあるが、要点の一部が欠けている。段落番号と欠けている部分を書く
   - 抜け ....... どの段落にも見当たらない
   迷ったときに「抜け」を選ばないでください。「一部のみ」にしてください。
3. 独立請求項の構成要素を1つずつ取り出し、次から選んでください。
   - 必要な限定 ..... 発明届の構成または議事メモの決定に、同じ限定がある
   - 狭すぎる疑い ... 議事メモの決定または発明届の変形例と食い違う限定がある
   - 判断できない ... 議事メモにも発明届にも、その限定についての記載が無い
4. 請求項の構成要素ごとに、それを具体的に示す実施例が案に何件あるかを数え、
   発明届の実施例・変形例の件数と並べてください。
5. 「狭すぎる疑い」の行には、広げるなら本文に必要になる実施例を、
   発明届または議事メモに書かれているものの中から挙げてください。

【厳守事項】
- 発明届と議事メモに書かれていない実施例、材料、数値を作らないでください。
  足りないときは「発明者に確認」と書いてください。
- 請求項の書き換え案を確定した形で書かないでください。
- 特許になるか、権利が取れるかの見込みを書かないでください。
- 明細書の案の文章を書き換えないでください。指摘だけにしてください。
- 根拠には、発明届の欄名、議事メモの日付、案の段落番号を必ず書いてください。
  段落番号を挙げられない指摘は出さないでください。
- 再稿の場合は、前回の指摘表の行ごとに「対応済み／未対応／一部対応」を付けてください。

「迷ったときに抜けを選ばない」を明記しないと、言い換えが抜けになります。 事務所の弁理士は発明届の言葉をそのまま使わず、上位の概念に書き直すことが多いからです。発明届の「ゴム製のパッキン」が案では「弾性部材」になっている、という形です。 抜けと判定すると、正しく書かれているものに修正を頼むことになります。

「段落番号を挙げられない指摘は出さない」は、確認の時間を守るための一文です。 箇所の示されない指摘は、人が案の全文を読み直して探すことになり、第10章の45分に収まりません。

出力形式を固定する

エージェントの出力は、3つの表と修正依頼の下書きで受け取ります。 表は Word に貼ってそのまま事務所との打合せに使える形にします。

JSON ではなく表にしているのは、出力が後段のシステムではなく、人と事務所に渡るからです。表の列を固定しておけば、担当者が変わっても指摘の形が同じになります。 これが「指摘の深さが担当者で揃っていない」という事務所の声への答えになります。

修正依頼の下書きは、確定した指摘だけから作らせます。 人が確認を終えた表をエージェントに戻し、「status が抜け・一部のみ・実施例の不足・狭すぎる疑いのうち、担当者が残した行だけ」で文面を作ります。確認前の表から下書きを作ると、取り消したはずの指摘が文面に残ります。

システムへ連携する

知財管理システムへは書き込みません。 案件の状態を「事務所へ修正依頼済み」に変えるのは、送信した担当者です。指摘表が出ただけで状態が進むと、確認していない案件が依頼済みに見えます。

修正依頼のメールも自動では送りません。 事務所との関係にかかわる文面で、送るかどうか、どの指摘を残すかは担当者が決めます。

人が確認する

人が見るのは、指摘表の行と案の段落の対応です。 案の全文を最初から読む確認にすると、第10章の45分には収まりません。

1. 抜け の行を先に見る … 案の全体を「要点の言葉」と「言い換えの候補」で検索し、本当に無いかを確かめます
2. 一部のみ の行は段落を開く … 欠けているとされた部分が本当に欠けているかを読みます
3. 狭すぎる疑い は議事メモと並べる … 決定の内容と、その後の打合せで方針が変わっていないかを確かめます。変わっていれば、議事メモの書き方を直します
4. 実施例の不足は発明者に聞く … 発明届に無い実験データがあるかを Teams で問い合わせます
5. 残す指摘を決め、下書きを作らせる … 取り消した行は理由を一言残します

3番目を省かないでください。 請求項をどこまで広げるかは、先行技術の調査の結果を見て弁理士と決めることで、議事メモの一行だけでは決まりません。 エージェントの「狭すぎる疑い」は、話し合うきっかけです。

目標は、1件45分です。 指摘表の行が20行前後という想定で、それより長くかかる案件は、議事メモに決定が書かれていないか、案を分けずに渡しているかのどちらかです。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、発明届と議事メモの書き方の問題です。 書き方をそろえるほうが、指示文を工夫するより効きます。

記録を残す

• 点検に使った3つのファイルの版（ファイル名と更新日時）
• エージェントが出した指摘表の全文
• 人が取り消した指摘と、その理由
• 発明者への問い合わせと回答
• 事務所へ送った修正依頼の文面と送信日時
• 再稿で、前回の指摘が「対応済み／未対応／一部対応」のどれだったか

3つ目が、この構成の質を上げる材料になります。 取り消した理由が「言い換えだった」に偏るなら、点検の観点の一覧に言い換えの例を足します。「議事メモの決定が古かった」に偏るなら、議事メモの書き方を直します。