特許案件ごとの打合せ記録を要約し、決定事項と理由を「経緯メモ」に積み上げて、担当替えでも引き継げるようにする

処理の起点を決める

録音ファイルが案件フォルダの受付場所に保存されたことを起点にします。 打合せの直後に担当者が保存し、ファイル名の先頭に整理番号を付けます。整理番号の無いファイルは処理せず、担当者に戻します。 どの案件の経緯メモに積むかが決まらないからです。

処理は即時ではありません。 バッチ文字起こしはベストエフォートでスケジュールされ、ピーク時には処理の開始まで最大30分、完了まで最大24時間かかる場合があるとされています。追記案が届くのは早ければ当日、遅くとも翌営業日です。 経緯メモは次の打合せまでにそろっていればよく、この遅れは問題になりません。

もう1つの起点は、方針に関わるメールです。特許事務所から「請求項の補正案を送ります」「方針を変更したい」といったメールが届いたとき、担当者が案件のメール用フォルダへ移すと、録音の無い追記案として同じ流れに乗ります。 月80件のうち、2〜3割はメールだけのやり取りを想定しています。

入力データを集める

質を決めるのは、出席者と役割の一覧です。 文字起こしの話者は「話者1」「話者2」としか分かれません。誰が弁理士で誰が発明者かが分からなければ、「決めたのは誰か」が書けません。 打合せの後に担当者が1分で入力する票に、話者の番号と役割の対応を書きます。

経緯メモの抜粋は、案件ごとに3つの部分に分けて持ちます。 現在の状態（1段落）、未解消の保留事項の一覧、直近5件の決定事項です。この3つだけを毎回渡します。

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

文字起こしは、Power Automate から Batch Speech to text コネクタで送ります。要求で押さえる設定は4つです。

4行目の置き場所を間違えないでください。 ルートに書いてもエラーにはならず、結果が自社の管理外の場所に保存されます。 未出願の発明の内容を含む文字起こしなので、置き場所は最初のテストで確かめます。

経緯メモは、SharePoint 上の案件ごとのファイルから、Power Automate で3つの部分を読み出します。メールは、案件のメール用フォルダから、前回の打合せの日付より後のものだけを取ります。 同じメールを二度渡すと、同じ決定が2件の追記案になります。

AIへ渡す前に整形する

1. 整理番号の確認 … ファイル名の整理番号が、経緯メモのある案件か確かめます。無ければ処理を止めて担当者に戻します
2. 録音の形式の確認 … 話者分離はモノラルの録音が対象で、ステレオでは使えないとされています。会議システムの設定でモノラルにするか、変換してから送ります
3. 録音の長さの確認 … 話者分離を使う場合、1ファイル240分を超える音声は使えないとされています。長い打合せは分割します
4. 話者と役割の対応付け … 担当者の票をもとに、「話者1＝弁理士」のように置き換えます
5. メールの整理 … 引用部分と署名を取り除き、新しく書かれた部分だけにします
6. 経緯メモの抜粋の組み立て … 現在の状態、未解消の保留、直近の決定を、それぞれ番号付きで並べます
7. トークン数の見積もり … 送る前にトークン計数のAPIで見積もり、想定を大きく超えるものは人に回します

5番目を省くと、同じ内容が何度も入ります。 事務所とのメールは返信のたびに過去の本文を引用するため、古い方針が新しいメールの中に何度も現れます。 AIが引用部分を「今回の提案」と読むと、覆されたはずの方針が決定として戻ってきます。

AIに処理させる

させるのは、今回の打合せとメールから、経緯メモに積むべきものを5種類に分けて取り出すことです。 どれにも、根拠にした発言の時刻かメールの日付を付けさせます。

いちばん大事なのは、1行目の「理由」です。 打合せでは、理由が先に語られて決定が後に来ることが多く、「引用文献2の構成と重なるので、ここは外しましょう」の前半が理由です。 AIにはそこを探させ、見つからなければ空欄にせず「理由の記載なし」と書かせます。空欄だと「書き忘れ」と「理由が話されなかった」の区別がつきません。

3行目は、渡した保留を1件ずつ判定させます。 状態は resolved（解消）、still_open（話題に出たが未解消）、not_discussed（話題に出なかった）の3つです。not_discussed を「解消した」と読ませないことが、保留を消さないための要です。

最後の行が、いちばん起きやすい失敗です。 弁理士の「補正で請求項1に限定を入れる案もあります」は提案で、担当者が「それでお願いします」と答えて初めて決定になります。提案と決定の区別を、発言者の役割と、応答の有無で判定させます。

指示内容を固定する

あなたは企業の知財部で、特許案件の経緯メモを管理する立場です。
今回の打合せの文字起こしと関連メールから、経緯メモに追記する案を作ってください。
経緯メモは、担当者が交代したときに、これだけで案件を引き継ぐための記録です。

【取り出すもの】
1. decisions ... 今回決まったこと。何を・誰が決めたか・理由
2. new_open_items ... 今回決まらなかったこと。誰が何を確かめるか
3. open_item_updates ... 渡した未解消の保留が、今回どうなったか
4. superseded ... 渡した直近の決定のうち、今回変わったもの
5. deadline_mentions ... 打合せで話された期限（参考として）

【厳守事項】
- 理由は、文字起こしかメールに書かれている内容だけを書いてください。
  書かれていなければ reason を「理由の記載なし」としてください。
  推測で理由を補わないでください。
- 提案と決定を分けてください。提案に対して、決める立場の出席者が
  同意した発言がある場合だけ decisions に入れてください。
  同意が無いものは new_open_items に入れてください。
- 渡した保留は、1件ずつ必ず判定してください。
  話題に出なかったものは not_discussed です。resolved にしないでください。
- メールの引用部分に書かれた古い方針を、今回の決定として扱わないでください。
- 期限は、話された言葉をそのまま写してください。日付の計算をしないでください。
- 拒絶理由にどう応答すべきか、権利範囲が適切かについて意見を書かないでください。
- すべての項目に、根拠にした発言の時刻とメールの日付を evidence として付けてください。
- 案件と関係の無い雑談は取り出さないでください。

【案件】{case_id}
【打合せの属性】{meeting_meta}
【出席者と役割】{attendees}
【案件の現在の状態】{current_state}
【未解消の保留事項】{open_items}
【直近の決定事項】{recent_decisions}
【文字起こし】{transcript}
【関連メール】{emails}

「推測で理由を補わない」を明記しないと、もっともらしい理由が入ります。 「請求項3を削除」とだけ話された打合せでも、前後の文脈から「進歩性の指摘に対応するため」と書きます。正しいことも多いのですが、正しいかどうかを後任者は確かめられません。 記録に無い理由は、無いと書かせます。

「同意した発言がある場合だけ」は、提案が決定に化けるのを止める一文です。 弁理士の説明がいちばん長く、長く語られた案が決定のように見えます。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "case_id": "",
  "meeting": { "date": "", "type": "inventor | attorney | office_action", "source": "recording | email" },
  "decisions": [
    { "what": "", "decided_by": "", "reason": "",
      "evidence": [{ "kind": "transcript | email", "ref": "" }] }
  ],
  "new_open_items": [
    { "what": "", "owner": "", "evidence": [{ "kind": "transcript | email", "ref": "" }] }
  ],
  "open_item_updates": [
    { "open_item_id": "", "status": "resolved | still_open | not_discussed", "note": "" }
  ],
  "superseded": [
    { "decision_id": "", "status": "changed | unclear", "new_decision_index": 0 }
  ],
  "deadline_mentions": [{ "quote": "", "ref": "" }],
  "current_state_draft": ""
}

1つ目の理由は、追記の単位がそろうことです。 経緯メモの1行は「決定1件」か「保留1件」で、JSONの配列の1要素がそのまま1行になります。自由文で受け取ると、1段落に決定と保留が混ざり、後で消し込めません。

2つ目は、保留の消し込みを取りこぼさないことです。 open_item_updates には、渡した保留の数だけ要素が並ぶはずです。数が合わなければ、Power Automate の側で追記案を差し戻します。 スキーマでは件数を強制できないため、この照合は後段で行います。

3つ目は、過去の決定を上書きしないことです。 superseded は古い決定の番号を指すだけで、古い行は消しません。経緯メモでは古い行に「E-014 で変更」と印が付き、「最初はこう決め、こういう理由で変えた」という流れが残ります。 引き継ぎで知りたいのは、まさにこの流れです。

システムへ連携する

経緯メモへの書き込みは、担当者が確定した後だけです。 追記案は別の場所に置き、確定のボタンを押したものだけを経緯メモの末尾に足します。経緯メモの既存の行は、この構成からは書き換えません。 変更の印を付けるのも、確定した追記に含まれる superseded をもとにした追記の1行としてです。

知財管理システムとはつなぎません。 deadline_mentions は「打合せでこう話された」という参考情報で、期限の正本と食い違っていれば、担当者が知財管理システムの値を確かめるきっかけにします。

人が確認する

担当者は、追記案を1件ずつ確定します。 経緯メモは長く読まれる記録なので、ここは省きません。

1. 決定事項の理由を確かめる … evidence の時刻から文字起こしの該当箇所を開き、理由がその発言から読めるかを見ます
2. 提案と決定の区別を確かめる … 決定に入ったものに、決める立場の人の同意があるかを見ます
3. 保留の消し込みを確かめる … resolved になったものが、本当に解消したかを見ます
4. 「現在の状態」を読み直す … 後任者がこの1段落だけ読んで状況が分かるかを見ます
5. 直したら記録する … どの項目をどう直したかを残します

1番目がいちばん時間を使うところで、使うべきところです。 「理由の記載なし」と出たものは、担当者が覚えていれば書き足します。覚えていなければ、そのまま残します。 「なぜかは分からない」という記録も、後任者にとっては意味があります。

目標は、80件をならして1件9分です。 決定が1〜2件の短い打合せは数分で済み、中間対応の方針相談のように決定と保留が10件近く出る打合せは20分ほどかかります。

例外に対処する

2行目は、発明者面談でよく起きます。 同じ発明者の関連案件をまとめて話すため、1つの録音に3件分の話が入ります。 案件の境目は担当者にしか分からないので、票で指定します。

記録を残す

• 元の録音ファイルと、文字起こしの結果（話者分離つき）
• 打合せの属性の票（出席者と役割の対応を含む）
• Claude API に渡した入力の全文と、返ってきたJSON
• 担当者が確定した追記と、確定までに直した箇所
• 経緯メモの各行の番号と、superseded による変更の対応
• 案件ごとの「理由の記載なし」の件数

4つ目で直した箇所を残すのは、AIが間違えやすい型を知るためです。 同じ直しが続くなら、指示か前処理を直します。

最後の行は、打合せの質を見る材料になります。 「理由の記載なし」が多い案件は、理由を話さずに決めている打合せです。AIの問題ではなく、打合せの最後に「理由を一言で」と確認する運用で減らせます。