技術者へのヒアリングをAIとの対話で行い、届け出されていない発明を掘り起こす

処理の起点を決める

知財担当が、その月のヒアリング対象者リストを登録したことを起点にします。リストはスプレッドシートに20名分の氏名と所属を並べるだけです。

登録後、対象者ごとに資料収集と質問案の生成が走り、生成が終わった人から順に Teams へチャットが届きます。全員に同時に送らないでください。 20名分が同じ日に届くと、回答が集中して知財担当の確認が追いつきません。週5名ずつに分けます。

もう1つの起点として、開発報告書が新しく登録されたときに、その執筆者へ自動で声をかける形も考えられます。ただし、こちらは報告書の量に左右されるため、最初は月次のリスト方式で始めるほうが管理しやすくなります。

入力データを集める

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

開発資料： SharePoint の文書ライブラリから、作成者または関係者が対象技術者である文書を、直近12か月分に絞って取得します。全期間を対象にすると量が増えすぎ、質問が散らかります。

出願済み一覧： 特許管理システムからエクスポートしたCSVを月1回取り込みます。リアルタイム連携は不要です。これは「すでに出願している内容を、もう一度聞かない」ために使います。

対話の記録： Copilot Studio のエージェントは、トピックの中で変数に回答を保持できます。対話の最後に、エージェント フローをツールとして呼び出し、回答一式を SharePoint のリストへ書き出します。エージェント フローは Copilot Studio または Power Automate でつくるローコードの自動化で、ツールとして追加するとエージェントのオーケストレーターが実行時に呼び出せます。

AIへ渡す前に整形する

1. 資料の絞り込み … 対象技術者が関わった文書のうち、直近12か月かつ本文が一定量以上のものに限ります。1行の連絡メモを渡しても質問は作れません
2. 出願済み内容の除外 … 出願済み一覧と照らして、すでに権利化を進めているテーマは質問の対象から外します。ここを外さないと、技術者に「もう出願したはずですが」と言われて対話が止まります
3. 秘密区分の確認 … 顧客との共同開発で、契約上その内容を社外のAIサービスへ出せない資料があります。文書のプロパティで秘密区分を持たせ、区分が高いものは対象から外します
4. 長文の要約 … 開発報告書は数十ページになることがあります。質問案を作る前に、テーマごとに要点へまとめておきます

AIに処理させる

2つの工程に分けます。

質問案をつくる工程（Claude API）：

一次ヒアリングを行う工程（Copilot Studio のエージェント）：

出願できるかどうかの判断はさせません。 新規性・進歩性の判断は、先行技術調査を経て人が行うものです。AIの出力はあくまで「聞き取った内容の整理」です。

指示内容を固定する

質問案を作る側の指示は次のようになります。

あなたは知財部の発明発掘を支援する担当者です。
下の開発資料を読み、この技術者に聞くべき質問を作ってください。

【厳守事項】
- 資料に書かれていないことを前提にした質問を作らないでください。
- 「発明はありますか」という聞き方をしないでください。
  「従来はどうしていたか」「何を変えたか」「なぜそれで解決したか」の順で聞いてください。
- 1テーマにつき質問は3問までにしてください。全体で10問を超えないでください。
- 下の「出願済み一覧」と内容が重なるテーマは、質問の対象から外してください。
  外した場合は excluded_themes に理由を書いてください。
- 専門用語は資料の表記をそのまま使ってください。一般的な言葉に置き換えないでください。
- 特許性の有無、出願すべきかどうかは書かないでください。

【開発資料】
{documents}

【出願済み一覧（この技術者が発明者のもの）】
{filed_patents}

【出願方針（重点領域・見送る領域）】
{ip_policy}

対話を行う側では、Copilot Studio のトピックとして組みます。エージェントは生成オーケストレーションまたはクラシックオーケストレーションで応答するトピックを選び、トピックの中の質問ノードで利用者に質問し、回答を変数に保持します。掘り下げの指示は次のように書きます。

【掘り下げの方針】
- 回答が「特にない」「普通にやった」の場合、次のように聞き直してください。
  「その作業で、うまくいかなかったことはありましたか」
  「以前のやり方と比べて、変えた点はどこですか」
- 回答に数値（寸法・時間・温度・回数など）が出てきたら、
  「その値にした理由」を1回だけ聞いてください。
- 3回聞いても具体的な内容が出ない質問は、それ以上掘らずに次へ進んでください。
  しつこく聞くと、次回から答えてもらえなくなります。
- 回答を評価しないでください。「それは素晴らしいですね」のような感想を返さないでください。

「3回で切り上げる」の1行が重要です。 発掘ヒアリングは、回答者の協力があって初めて成り立ちます。深掘りを続けると負担になり、次の月から回答率が落ちます。 対話型にする以上、ここは設計しておく必要があります。

出力形式を固定する

{
  "engineer_id": "",
  "interview_date": "",
  "themes": [
    {
      "theme_name": "",
      "prior_method": "",
      "problem": "",
      "what_changed": "",
      "why_it_works": "",
      "effect_measured": "",
      "related_documents": [],
      "answer_completeness": "high | medium | low",
      "public_disclosure_flag": "none | planned | done | unknown"
    }
  ],
  "excluded_themes": [],
  "needs_followup": [],
  "raw_transcript_id": ""
}

public_disclosure_flag は、その内容をすでに学会・展示会・カタログで公開したかどうかです。公開済みなら出願の可否に直結するため、必ず聞いて記録します。本人が覚えていない場合は unknown にして、人が確認します。

answer_completeness は、回答が具体的だったかどうかの目安です。これが low ばかりの技術者には、次回チャットではなく対面で聞く、といった判断ができます。

システムへ連携する

対話の結果は、SharePoint のリスト（出願候補シート）へ1テーマ1行で書き出します。列は themes の各項目に対応させます。

知財担当は、このシートを見て次の3つに仕分けます。

面談を経て出願候補に決まったものは、特許管理システムへ登録し、発明届出書の作成を依頼します。この登録は人が行います。 特許管理システムへの自動登録は、この段階では作らないでください。

人が確認する

全件、知財担当が読みます。自動で出願候補に上げることはしません。

理由は2つあります。1つは、発明かどうかの判断が先行技術調査を前提とするもので、対話の内容だけでは決まらないためです。もう1つは、技術者が何気なく話した内容に、他社との共同開発に関わるものや、顧客の秘密情報が混ざることがあるためです。ここは人が見て弾く必要があります。

確認を速くするための設計が効きます。

• シートを answer_completeness の高い順に並べる
• public_disclosure_flag が done の行に色を付ける（出願の可否が変わるため）
• 出願済み一覧との類似度が高い行に印を付ける
• 元の対話ログへ1クリックで飛べるようにする

例外に対処する

記録を残す

この業務のログは、後から出願の経緯を説明するための記録になります。

• 対話の全文（誰が、いつ、何を答えたか）
• 質問案の生成に使った資料の一覧
• 出願候補シートの各行と、知財担当の仕分け結果
• public_disclosure_flag の回答内容
• 面談で確定した内容と、届出依頼の日付

対話の全文は、発明者の認定でもめたときの資料になります。誰がいつ何を言ったかが残っていることに価値があります。 保存期間は、出願の有無にかかわらず長めに取ってください。