研究開発部が社外からのサンプル提供の依頼を Make で受け、AI で用途・量・秘密保持契約の要否を整理して担当の研究者に割り振る

処理の起点を決める

自社サイトの技術問い合わせフォームの送信と、研究開発部の代表アドレスへのメールの2つを起点にします。 フォームには「サンプルの依頼」の選択肢を足し、それを選んだ送信だけを Make の Custom webhook の URL に送ります。メールは Gmail の Watch emails で、「サンプル依頼」のラベルを見張ります。ラベルは Gmail のフィルタで、件名か本文に「サンプル」「試料」「sample」が含まれるものに付けます。

フォームの側は即時、メールの側は15分おきにします。 依頼は締め切りのある業務ではありませんが、学会の直後に届いた依頼に翌週返すか当日返すかで、相手が評価に使う材料が変わります。 15分おきでも、窓口が机に戻るのを待っていたいまよりずっと早く担当に届きます。

Webhook の待ち行列には上限があります。 公式のページでは、即時に処理されなかったデータは Webhook ごとの待ち行列にため、その上限は契約のクレジット1万ごとに667件、最大1万件で、超えた分は受け取らないとされています。受け取れる要求は10秒あたり300件までです。また、どのシナリオにもつながっていない Webhook は5日（120時間）を過ぎると無効になり、410を返すとされています。シナリオを作り直すときは、フォームの送り先の URL も同じ日に差し替えます。

入力データを集める

質を決めるのは、呼び名の表です。 第3章の（a）のとおり、依頼の品名はカタログの名前とは限りません。論文や学会で使った開発の呼び名を研究者から集め、品番と1対1で並べます。 この表が薄いと、AIがどれだけ正確に品名を写しても、品番は引けません。

秘密保持契約の台帳は読むだけです。 法務部が持つ台帳を、研究開発部の側で写して持ちません。写しを持つと、期限を延ばした契約が写しの側で切れたままになります。 シナリオの接続には、台帳のシートを読むだけの権限を与えます。

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

品番の引き方は、品名→呼び名の順です。 品名で引けたらそこで止め、引けなければ呼び名の表を引きます。どちらでも引けない依頼は、AIに品番を当てさせずに窓口へ回します。 「似た名前の品番」を候補に出させると、窓口がその候補を正解と思い込みやすいからです。

相手先の名称は、表記がそろいません。 「〇〇大学大学院工学研究科」「〇〇大 △△研究室」「〇〇 University」が同じ相手です。秘密保持契約の台帳には別名の列を持たせ、名称と別名のどちらかに一致すれば当たりとします。 大学の場合は、契約が大学と結ばれているのか研究室の教員個人と結ばれているのかで範囲が違うので、当たった契約の範囲の列をそのまま担当に見せます。

AIへ渡す前に整形する

1. 重複の確認 … 受付の台帳を送信元と依頼品の名前で引き、14日以内に同じ依頼があれば止めて窓口に知らせます
2. 返信の引用を落とす … メールの返信に付いてくる前のやり取りを落とし、依頼主が書いた部分だけにします
3. 署名を分ける … 署名の部分から所属と国を取り、本文とは別の欄にします
4. AIに渡す範囲を絞る … 電話番号と担当者の個人の連絡先は渡しません。氏名は聞き返しの宛名にだけ使い、分類の呼び出しには所属だけを渡します
5. 言語の印 … 本文が日本語か英語かそれ以外かを付けます。英語以外は窓口へ回す印にします

2番目を落とすと、こちらが前に送った文面を依頼として読みます。 前の返信に「開発品は秘密保持契約の締結後にお送りします」と書いてあると、引用を残したまま渡せば、依頼主が秘密保持契約を求めているように見えます。

4番目で氏名を渡さないのは、分類に要らないからです。 依頼の種類と用途は所属と依頼の文で決まります。要らないものは外のサービスに渡さない、を最初の版から守ります。

AIに処理させる

させるのは、依頼の文を項目に分けることと、依頼の種類と用途を決まった区分に分類することの2つです。

依頼の種類と用途の区分がこの構成の分類で、ai_function の中心です。 依頼の種類で回す先が変わり、用途の区分で担当のリーダーが見るべき点が変わります。resale は、受けない理由ではなく、担当が必ず確かめる印です。 商社からの依頼は、商社の先の顧客が評価する前提であることが多く、それ自体は普通の依頼です。

依頼品の名前は、品番に直させません。 直させると、呼び名の表に無い名前を、AIが知っている似た名前の品番に寄せます。写すのはAI、引くのは表、という分担を崩さないことが、誤った研究者に回さないための一番の守りです。

指示内容を固定する

あなたは素材メーカーの研究開発部で、社外から届くサンプル提供の依頼を
整理する担当です。下に渡す依頼の文を読み、項目に分けて分類してください。
依頼を受けるかどうか、契約が要るかどうかは決めないでください。

【すること】
1. request_type を次から1つ選ぶ。
   sample_eval / joint_research / purchase / info_only / out_of_scope / unclear
2. purpose を次から1つ選ぶ。
   academic / product_dev / resale / not_stated
3. 依頼品の名前を、依頼の文に書かれたとおりに items に写す。
   1つの依頼に複数の品があれば、すべて並べる。
4. 品ごとに、量の数値と単位を書かれたとおりに写す。
5. 送り先の国を destination_country に写す。署名の所属の国も手がかりにしてよい。
6. SDS・技術資料・組成・データシートなど、求めている資料を docs_requested に写す。
7. 希望の時期を書かれたとおりに写す。
8. 判断に要る情報で書かれていないものを missing に並べる。
9. 区分を選んだ根拠の文を evidence に、依頼の文からそのまま写す。

【厳守事項】
- 依頼品の名前を品番に直さない。似た名前の品を推し量らない。
- 量が書かれていなければ null にする。「少量」「評価に足りる量」を数値にしない。
- 単位を換算しない。「0.5kg」は 0.5 と kg のまま写す。
- 国が書かれておらず、署名からも分からなければ null にする。
  メールアドレスのドメインから国を推し量らない。
- 「秘密保持契約が必要」「輸出の許可が必要」などの判断を書かない。
- 用途が書かれていなければ not_stated にする。所属から用途を推し量らない。
- サンプルの依頼でない文（売り込み・求人・取材など）は out_of_scope にし、
  ほかの項目は空にする。

【依頼主の所属】{organization}
【依頼の文】{request_text}
【フォームの項目（ある場合）】{form_fields}

「メールアドレスのドメインから国を推し量らない」を書くのは、推し量るからです。 海外の会社の日本法人や、日本の大学の留学生の個人のアドレスなど、ドメインと送り先が違う例はいくらでもあります。仕向地が null の依頼は、輸出の確認が要るかどうかが決まらない依頼として扱い、聞き返しの対象にします。 推し量った国で「国内」と決めると、確認が要る依頼が確認の流れから落ちます。

「所属から用途を推し量らない」も同じです。 大学からの依頼でも、企業との共同研究の評価に使う場合があります。書かれていない用途は、担当のリーダーが依頼主に聞くべきことです。

出力形式を固定する

次の形の JSON を返させます。

{
  "request_id": "",
  "request_type": "sample_eval",
  "purpose": "product_dev",
  "items": [
    { "name_as_written": "XX-200", "quantity": 500, "unit": "g" }
  ],
  "destination_country": "JP",
  "docs_requested": ["SDS", "technical_data"],
  "desired_timing": "11月中",
  "missing": ["評価の条件"],
  "evidence": [
    { "field": "purpose", "quote": "弊社の新製品の塗膜で評価したく" }
  ]
}

1つ目の理由は、AIの分類と規則の結論を別の層に置けることです。 JSON はAIが埋め、秘密保持契約の要否と回す先はシナリオが規則で決めます。規則は次のとおりです。

2つ目は、品ごとに判定できることです。 1つの依頼に上市品と開発品が混ざることがあります。items を配列にしておけば、品ごとに製品マスタを引き、1品でも秘密保持契約が要れば依頼全体を法務部に回せます。

3つ目は、evidence で窓口の確認が速くなることです。 用途を product_dev と決めた根拠の文が並んでいれば、依頼の全文を読み直さずに分類の当否を確かめられます。 公式のページでは、構造化出力は文字列の enum の大文字・小文字までは保証しないとされているので、ルーターの条件で比べるときは小文字にそろえてから比べます。

システムへ連携する

ルーターのルートは、輸出の確認→窓口へ→秘密保持契約→そのまま回す→フォールバックの順に並べます。 公式のページでは、ルートは同時ではなく1本ずつ順に処理され、どの条件にも当たらないデータはフォールバックのルートが処理するとされています。輸出の確認を先頭に置くのは、海外の依頼が「そのまま回す」ルートに流れないようにするためです。 各ルートの条件は互いに重ならないように書き、フォールバックは窓口へのメールにします。

担当グループのリーダーへのメールは、要約と判定の理由だけにします。 依頼の原文は受付の台帳の行へのリンクで見せます。メールの本文に依頼主の連絡先を写さないのは、転送されて広がるのを防ぐためです。

聞き返しの下書きは、依頼主にそのまま送りません。 Gmail の下書きとして代表アドレスに置き、窓口が確かめてから送ります。

人が確認する

窓口が毎日見るのは、窓口へ回った依頼と、聞き返しの下書きです。

1. 品番が引けなかった依頼を見る … 依頼品の名前を研究者に聞き、分かったら呼び名の表に1行足します。 次から同じ名前は自動で引けます
2. 聞き返しの下書きを確かめる … missing が依頼の文に合っているかを見ます。量と仕向地の聞き返しは必ず残します
3. 分類を流し見る … そのまま回った依頼の request_type と evidence を一覧で見て、外れていれば直し、担当に知らせます
4. 送る … 下書きを Gmail の画面から送り、受付の台帳の状態を書き換えます

秘密保持契約が要る依頼は、法務部が台帳と範囲を確かめます。 契約が無ければ締結の手続きに入り、締結までサンプルの出荷の手配を止めておく印を受付の台帳に付けます。 海外の依頼は、輸出管理の担当が品番と仕向地で確認し、結果を受付の台帳に書きます。どちらも、確認が終わるまで担当のリーダーは出荷の手配に進めません。

例外に対処する

上の3行が大半を占めます。 どれもAIの読み違いではなく、呼び名の表と依頼のフォームの欄の作り方の問題です。 仕向地の聞き返しが多いなら、フォームに国の欄を必須で足すほうが早く効きます。

記録を残す

• 依頼の元の項目とメールの本文（引用を落とす前のもの）
• AIに渡した文と、返ってきた JSON の全文、stop_reason
• 引いた製品マスタの行と秘密保持契約の台帳の行（そのときの値）
• 規則が出した判定と、回した先
• 窓口・法務部・輸出管理の担当が直した記録と、その理由
• 依頼主への返信の日時と、担当のリーダーが受けるかを決めた日時

3つ目で台帳の値を写して残すのは、台帳が後から変わるからです。 秘密保持契約の期限を延ばした後に「なぜあのとき法務に回ったのか」を聞かれても、当時の期限が残っていれば答えられます。

最後の行は、窓口の負担が偏っていないかを見る材料になります。 届いてから担当が決めるまでの日数を、担当グループごとに並べます。