社外から持ち込まれる技術提案・売り込みを、受け取る前に切り分ける

処理の起点を決める

受付箱（共有メールボックス）へのメールの到着を起点にします。問い合わせフォームからの送信も、同じ受付箱へ入る形にします。起点をここに集めることが前提条件です。 個人のアドレスへ直接届いた提案はこの処理を通らないため、転送してもらう運用を作らないと、仕組みだけあっても素通りします。

到着したら、まず添付を切り離してください。 本文を読む前に隔離します。「あとで隔離する」ではなく「最初に隔離する」です。 添付が本文と一緒に流れている限り、どこかの処理で開かれる余地が残ります。

同じ相手からの続報を、別件として扱わないでください。 1通目の判断が付いているなら引き継ぎます。スレッドの識別子か、差出人のアドレスで束ねます。

社内からの転送も起点になります。 その場合、転送した人ではなく、元の差出人の情報で判断します。 判断のあとで追加の情報が届くこともあるため、同じ案件の判断を作り直せる入口も用意してください。

入力データを集める

渡してよいものと、渡さないものを、最初にはっきり分けます。

このほかに、照合の材料として既存の取引の有無（取引先の台帳）、NDAの有無と契約番号と対象分野（NDAの台帳）、進行中の開発テーマの一覧（研究開発本部の管理表）、過去の判定の記録（Microsoft Lists）を参照します。

中身を読めば分類は正確になります。しかし、正確な分類のために中身を読むのでは、この仕組みを作る意味がありません。 添付を開かないという制約が、この構成のすべてを決めています。

ファイル名だけでも、かなりの手がかりになります。 「〇〇社_特許出願前_提案書.pdf」というファイル名は、それ自体が「未出願の発明が書かれている可能性がある」という材料です。「Confidential」「社外秘」といった語の有無も見ます。

拡張子とサイズも材料になります。 図面の形式のファイルや数十メガバイトの資料が付いていれば、「概要の紹介」ではなく「具体的な技術内容の開示」である可能性を示します。会社案内のPDFが1つだけの提案とは扱いを変えます。ただし、ファイル名に相手の未公開の型番が入っていることもあるため、渡す範囲は社内の方針で決めます。

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

NDAの台帳： ここがこの構成の質を決めます。会社名で引けるだけでは足りません。

「対象分野」の列が最も効きます。 NDAがあれば何でも受け取ってよいわけではなく、放熱構造について結んだNDAが通信方式の提案を覆うとは限りません。 分野が書かれていれば、「NDAはあるが、この提案の分野は対象外」と判定できます。

「情報の流れ」の列も外せません。 自社が出す側として結んだNDAは、受け取る側の保護にはなりません。「受領の義務」の列は、相手のひな形で結んだNDAを見分けるために置きます。 一方的に受領を義務づける条項があると、「NDAがあるから受け取ってよい」という判定ができません。 印の付いた契約は人が見ます。

進行中の開発テーマの一覧： 研究開発本部の管理表を、分野を表す語を並べた形に直してください。

「機微度」の列が要ります。 テーマ名そのものが社外秘なら、その名称をAIへ渡してよいのかという問題が生じます。 機微度が高いテーマは分野を表す語だけを渡します。語の粒度も精度を左右します。 粗すぎると何にでも当たり、細かすぎると当たりません。1テーマ3〜5語で始めます。

取引先の台帳も、ドメインで引ける形にします。 「株式会社」の位置、英字表記、旧社名——会社名は揺れるためです。整備には法務部門を巻き込んでください。 「対象分野」「受領の義務」は契約書を読まないと書けません。全件を一度に整える必要はなく、提案が届いた会社から順に埋める形で構いません。

AIへ渡す前に整形する

1. 添付の切り離しと隔離 … 受信したメールから添付を分離し、開かないまま、権限を限定した場所へ置きます。 この時点でファイル名・拡張子・サイズだけを記録します
2. 本文の抽出 … 本文を取り出し、引用部分（過去のやり取り）と署名をそれぞれ区切って持ちます
3. 転送の判別 … 社内から転送されたメールの場合、元の差出人を本文の中から取り出します
4. ドメインの照合 … 差出人のドメインで、取引先の台帳とNDAの台帳を引きます
5. ファイル名の分解 … 会社名らしき語、日付、「社外秘」「Confidential」などの語を取り出します
6. 開発テーマの語の準備 … 機微度に応じて、渡すテーマの語を絞り込みます
7. 過去の記録の照合 … 同じ差出人・同じスレッドの過去の判定を引きます

1が最も重要です。 添付を「開かない」を実装で担保してください。運用の注意書きだけでは守られません。 処理の流れの中に、添付の中身を読み取る処理を一切置かない——これが設計上の約束です。ウイルス対策のスキャンは別の話なので、扱いを情報システム部門と決めておきます。

2の引用部分にも注意が要ります。 後追いのメールには過去のやり取りが引用で付き、その中に1通目の提案の要旨が書かれていることがあります。 判定の材料には使えますが、引用部分と新しく書かれた部分は区別して渡してください。

3を飛ばすと分類が崩れます。 転送されたメールをそのまま渡すと、差出人が自社のドメインになり「既存の取引あり」と判定されます。6では、「次世代の折りたたみ端末の筐体」ではなく「筐体／薄型化／ヒンジ」と渡します。

AIに処理させる

1つの処理だけをさせます。4つの区分のいずれかに分類することです。

undetermined を必ず置いてください。 これが無いと、AIはどれかに押し込もうとします。情報が足りないときに「判断できない」と言えることが、この構成の安全弁です。 本文が「ご挨拶させてください」の一文だけ、という提案は多くあります。

区分と一緒に、根拠を出させます。 そう判断した理由、本文から根拠にした箇所をそのまま抜いた引用、自社の開発テーマとの重なり、秘密情報の手がかり（「Confidential」の表示、図面番号、未公開の型番など）、そして人の確認が要るかどうかとその理由です。

引用を本文だけに限ることが、設計の要です。 出どころを本文に限ると決めておけば、添付の中身らしき文字列が引用に現れたとき、どこかで添付が読まれたという異常の合図になります。

評価をさせません。 「価値が高い」「有望な提案である」といった記述を禁じます。扱うのは手続きの判断だけです。 受領の可否の法的な評価も、相手のひな形が自社に不利かどうかも、人が契約書を読んで決めます。nda_first は「NDAの条件を確認する工程へ回す」という意味であって、「NDAを結べば受け取ってよい」という意味ではありません。

指示内容を固定する

あなたは知的財産部で、社外から届く技術提案の受付を担当する者です。
届いたメールについて、添付ファイルを開く前に、受領してよいかの区分を判定してください。

【前提】
- 添付ファイルの中身は渡されていません。渡されているのは、
  差出人の情報、件名、本文、添付のファイル名と拡張子とサイズだけです。
- 提案の技術的な価値を評価しないでください。
  「有望」「採用を検討すべき」と書かないでください。

【厳守事項】
- 判定は次の4つのいずれかにしてください。それ以外の値を書かないでください。
  open_ok / nda_first / return_unopened / undetermined
- 記載がなければ「不明」としてください。
  差出人の会社名、部署、提案の分野が本文から読み取れない場合、
  推測で補わず「不明」と書いてください。
- 分野が読み取れない場合は undetermined にしてください。
- 判定の根拠は、必ず本文の記載から引用してください。
  引用できない根拠は書かないでください。添付の中身を引用しないでください。
  ファイル名を根拠にする場合は、ファイル名であることを明記してください。
- NDAのひな形の条件の良し悪しを判定しないでください。
  nda_first は「NDAの条件を確認する工程へ回す」という意味です。
- 下の【NDAの台帳】に「受領の義務あり」の印がある契約の相手からの提案は、
  undetermined にしてください。人が契約を読んで判断します。
- 下の【開発テーマ】と分野が重なり、かつ未取引の相手からの提案は、
  return_unopened を検討してください。
  ただし断定できない場合は undetermined にしてください。

【差出人／既存の取引の有無】
{sender} ／ {trade_status}

【NDAの台帳（契約番号／対象分野／情報の流れ／有効期間／受領の義務）】
{nda_records}

【件名】
{subject}

【本文（引用部分と署名を区別）】
{body}

【添付ファイル（名前／拡張子／サイズ。中身は含みません）】
{attachment_meta}

【自社の進行中の開発テーマ（分野を表す語）】
{rd_themes}

【この差出人に関する過去の判定】
{past_decisions}

「記載がなければ『不明』とする」の指示が、この構成で最も効きます。 生成AIは、書かれていない情報を一般論で埋めようとします。社名から分野を推測されると、その推測が判定の根拠になります。 分野が読めないなら undetermined に落とすのが正しい動きです。

「添付の中身を引用しない」の指示は、二重の歯止めです。 実装上、添付は渡していませんが、前処理の不具合でテキストが混ざったときの備えになります。

「断定できない場合は undetermined」も繰り返し書きます。 return_unopened は相手に返す踏み込んだ判断です。迷ったら人へ回す、という傾きを明示的に作ります。

出力形式を固定する

{
  "case_id": "",
  "sender": {
    "name": "",
    "company": "",
    "domain": "",
    "existing_trade": "yes | no | unknown",
    "nda": {
      "exists": "yes | no | unknown",
      "contract_no": "",
      "scope": "",
      "receipt_obligation": "yes | no | unknown"
    }
  },
  "decision": "open_ok | nda_first | return_unopened | undetermined",
  "reason": "",
  "quote": [
    { "source": "body | subject | file_name", "text": "" }
  ],
  "overlapping_themes": [
    { "theme_id": "", "matched_terms": [] }
  ],
  "confidential_markers": [
    { "marker": "", "source": "body | subject | file_name" }
  ],
  "needs_human": { "value": true, "reason": "" }
}

構造化する理由は、区分を4つに縛るためです。 自由な文章で返させると「NDAを結んだうえで受領されるのが望ましいと考えられます」という返事が来ますが、そのままでは次の処理に渡せません。 decision を enum で固定すれば、値は必ず4つのどれかになります。required に decision reason quote needs_human を入れておけば、根拠の無い判定が返ることもなくなります。

quote を配列にしているのは、根拠が複数あるためです。 「未取引である」「分野が重なる」「ファイル名に出願前とある」——それぞれ別の箇所が根拠になります。source で出どころを分けておけば、ファイル名を根拠にした判定は弱い、と区別できます。

quote に添付を表す値を置いていない点も重要です。 出どころを3つに限定することで、添付の中身を引用する道をスキーマの側で塞いでいます。

confidential_markers が空でないとき open_ok にしないという取り決めは、受け取ったあとの処理で確かめます。matched_terms にどの語で当たったかを出させると、語の粒度が粗すぎて誤って当たった事例を見つけられます。

needs_human は、特に急いで見るべきものを区別するために置きます。 なお、モデルが安全上の理由で拒否した場合は refusal フィールドが返り、分類の結果がありません。 このときは undetermined として人へ回します。エラー扱いで処理を止めると、案件が受付箱に滞留します。

システムへ連携する

書き込むのは記録用のリストだけです。相手への連絡は自動化しません。

返信を自動で送らないでください。 return_unopened の連絡は、相手にとっては門前払いです。文面を人が確かめてから送ります。

研究開発本部への自動転送も行いません。 「この分野は担当チームへ転送」という処理を入れると、確定前に技術者の目に触れて順序が崩れます。 転送は、知財担当が open_ok を確定させたあとです。契約管理のシステムへの書き戻しもしません。

人が確認する

知財担当の確認は、すべての案件で必ず残します。

3つ目を軽く見ないでください。 open_ok の判定が誤ると、開いてはいけないものが開かれます。 この構成で最も損失が大きいのは、return_unopened の誤りではなく open_ok の誤りです。

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

• 区分ごとに画面を分け、undetermined と return_unopened を上に並べる
• 根拠の引用を、本文のどこから取ったかが分かる形で表示する
• 引き当てたNDAの契約番号と対象分野を、判定の横に出す
• 重なった開発テーマと、当たった語を並べる
• 添付のファイル名だけを一覧で見せる（開くボタンは置かない）

5つ目が効きます。 確認の画面に添付を開くボタンがあると、担当者はつい押します。確定するまで、開く動線を画面に置かないでください。

確定の操作には、担当者の名前と日時が必ず付くようにしてください。 「いつ誰がこの区分にしたか」を残すことが、この構成のいちばんの値打ちです。判定を変えたときは理由も残してください。

例外に対処する

「すでに技術者が開いてしまっていた」は必ず起きます。 窓口を一本化しても、個人のアドレスへ直接届いたものは素通りします。このとき大事なのは、開いたことを責めないことです。 責めると報告されなくなり、記録が残りません。「開いてしまったら、すぐ受付箱へ転送する」という運用にします。 件数の急増にも備えてください。滞留すると、しびれを切らした技術者が自分で開きます。

記録を残す

この記録を残すことが、この構成のいちばんの値打ちです。 削減できる時間より、記録があることのほうが重要です。

「開封の記録」が、この構成のいちばんの成果物です。 数年後に「あのとき提案を見たのではないか」と問われたとき、「受け取った日に知財担当が区分を付け、開かずに返した。添付は一度も開かれていない」と示せる状態を作るのが目的です。この記録が無ければ、仕分けをしていたこと自体を証明できません。 いつ、誰が、どの根拠で返すと決めたかに加え、返信の文面と送信の日時も残します。

隔離した添付の保管期間も決めます。 持ち続けると「保持している」ことになり、消すと「返したことの裏付け」が薄くなります。どちらを取るかは、自社の法務・知財部門の判断です。