議事録を Salesforce / kintone の案件レコードに自動で振り分ける｜n8n × Embedding で実装する『議事録ルーター』

要約後に残る、案件への転記

会議の文字起こしと要約を自動化しても、CRMと連携していなければ、担当者が要約を読み、Salesforceの商談やNotionの案件ページに転記する作業が残ります。

案件名だけでは振り分け先を決められない会議では、担当者が保存先を確定した際に、案件IDと選択理由を残します。引き継ぎ後も紐付けの理由を追えるようにするためです。

案件に議事録を紐付けると何が変わるか

1. 営業の活動履歴をCRMに集約します。商談レコードから議事録を開き、過去のやり取りをたどれる構成です。
2. PMは案件ごとの議事録を参照できます。kintoneやNotionの案件ページから原文を開き、週次定例で扱う課題や宿題を拾います。
3. 経営層も判断の根拠となる発言をたどれます。

n8nとEmbeddingを使う全体構成

n8nが会議終了を契機に議事録を取得し、候補検索、判定、確認、保存へ渡します。カレンダーに案件IDやURLがある会議は、その照合から始めます。保存先を直接特定できる情報があれば、文章の意味から推定する処理を省けるためです。

検索用の入力は案件名・概要・直近の活動メモで、OpenAIのtext-embedding-3-largeなどでベクトル化します。保存先の候補にはPinecone、Qdrant、Supabase Vectorがあります。議事録側には、単一案件の会議なら要約、複数案件の会議なら話題ごとに分けた区間を使い、入力上限内に収めます。案件側と議事録側でモデル・次元数を揃え、入力の組み立て方も固定します。

候補の検索と、リンク先の判定を分ける

同じ製品を扱う別顧客の案件は、文章だけでは区別しにくくなります。部署・閲覧権限で検索対象を絞り込み、顧客側参加者との対応から候補を探す順序にします。参加者情報が欠けた会議も閲覧権限の範囲は維持し、顧客を特定できないまま自動リンクする処理は見送ります。

• 文章の類似度には、ベクトルの向きの近さを測るコサイン類似度を−1〜1のまま使います。案件名や型番を拾うBM25は、候補検索を比較する際の追加案です。
• 参加者の一致は、会議参加者に案件担当者のメールアドレスが含まれれば1、なければ0とする完全一致の判定です。顧客側参加者は検索対象の絞り込み、社内担当者は候補の加点に使います。同じ担当者が持つ案件には同じ点数が付くので、担当者の一致だけで保存先を決める設計にはしません。
• 活動時期の近さは、この採点例では最終活動日の当日を1とし、90日後の0まで直線的に下げます。直近で動いている案件を上位に置くための項ですが、休眠案件の再開には不利に働きます。

合計値のcompositeは、候補の順位付けに使う照合スコアです。正解確率として扱う場合は、最上位候補の正誤をラベルにして、ロジスティック回帰などで校正する設計です。順位付けの良し悪しは特徴量と重み、確率との対応は校正で扱います。

採点処理へ渡す入力は、検索結果のembeddingResults、参加者のmeetingParticipants、案件情報のdealsByIdです。n8nでは前段で単一案件の会議または分割後の1区間を1アイテムにまとめ、$input.first().jsonから各プロパティを取得して変数へ代入する構成にします。掲載コードは、その入力を受け取る採点部分です。CodeノードはRun Once for All Itemsで動かし、1実行につき1アイテムを扱います。

入力検証は採点の前段に置く設計です。dealsByIdに存在しない案件、欠損・不正日付、有限数でないスコアは確認待ちへ回します。未来日は異常値として確認待ちへ回します。入力不備を低スコアへ押し込むと、候補が合わない理由とデータの欠損を区別できなくなるためです。

時期スコアはDate.now()による実行日時が基準なので、再処理日によって値が変わります。会議当時の判定を再現するなら、meeting_started_atと会議当時の案件情報を使う設計を選びます。最新情報で判定し直す運用なら、実行基準時刻を保存します。

文章類似度が−1〜1、参加者一致が0か1、活動時期が0〜1で、重みが0.5・0.3・0.2なら、担当者不参加の合計値は最大0.7、最終活動から90日以上なら最大0.8です。担当者が参加し、文章類似度が1でも、67.5日を超えると0.85に届きません。この性質から、私は合計値に直接0.85を当てる案を採りません。代理出席や休眠案件を含むデータで重みを選びます。

// inputs:
//   embeddingResults: [{deal_id, score}] from Vector DB
//   meetingParticipants: ['alice@co', 'bob@co']
//   dealsById: { deal_id: { owner_email, last_activity_at, ... } }

const WEIGHTS = { embedding: 0.5, participant: 0.3, recency: 0.2 };

function recencyScore(lastActivityIso) {
  const days = (Date.now() - new Date(lastActivityIso)) / (1000 * 86400);
  return Math.max(0, 1 - days / 90); // 90日でゼロに減衰
}

const scored = embeddingResults.map(({ deal_id, score: textScore }) => {
  const deal = dealsById[deal_id];
  const participantHit = meetingParticipants.includes(deal.owner_email) ? 1 : 0;
  const recency = recencyScore(deal.last_activity_at);
  const composite =
    WEIGHTS.embedding * textScore +
    WEIGHTS.participant * participantHit +
    WEIGHTS.recency * recency;
  return { deal_id, composite, breakdown: { textScore, participantHit, recency } };
});

scored.sort((a, b) => b.composite - a.composite);
return scored.slice(0, 3); // Top-3

採点結果の上位3件から最上位候補を取り出し、後段でcompositeを校正したconfidenceを分岐に渡す設計です。保存先は、単一案件として扱う区間ごとに確定した1件とします。

Salesforce・HubSpot・kintoneへの書き込み

Salesforceの保存先にはEventやTaskがあり、この案ではTaskのWhatIdに商談IDを指定します。HubSpotならMeeting Engagementを商談に関連付け、kintoneならプロジェクト管理アプリのレコードへコメントを投稿する構成です。保存内容は議事録へのリンクと3行の要約に揃えます。kintoneへの接続は、HTTP RequestノードからREST APIへアプリID・レコードID・コメント本文を渡す方式です。

Taskを選ぶのは、会議後の記録を完了した活動として残すためです。期日を表すActivityDateには会議日を入れます。開始・終了時刻を管理する用途ならEventを選びます。

要約では、金額、対象時期、否定、条件、合意の有無を残します。「検討中」を「確定」に変えてしまえば、正しい案件に保存できても記録として使えません。本文を短くする際も、発言にない年月や担当者は補わない方針です。

保存結果と承認状態は別に記録する設計です。会議ID・区間ID・案件IDと保存結果を追えるようにし、再送・取消・案件統合後の付け替えを扱います。要約の転記先と通知先も、議事録の閲覧範囲内に限定します。

{
  "Subject": "商談議事録 — 2026/05/14",
  "WhatId": "006XX0000012345",
  "ActivityDate": "2026-05-14",
  "Status": "Completed",
  "Description": "【AI要約】n・先方は来期Q1の予算化を検討中n・競合C社の提案も並行受領n・次回は要件詳細のすり合わせnn議事録全文: https://drive.google.com/file/d/XXXX/viewn録画: https://zoom.us/rec/share/YYYY"
}

自動リンクと人による確認の切り替え

自動リンクを見送った議事録は、担当者が候補を選びます。校正後のスコアが高くても、候補のTop-2が僅差、顧客が不一致、必須情報が欠損する場合は、この経路へ回す設計です。自動化率は対象全件に対する自動リンク件数、誤リンク率は自動リンク件数に対する誤ったリンク件数で測ります。

• 0.85以上なら自動リンクする例です。確認対象の条件に該当しなければCRMへ保存し、担当者にSlackで結果を通知します。
• 0.60以上0.85未満では候補3件を提示します。Slackのボタンで選択を受け付け、承認者の権限を照合する設計です。確定表示への更新はCRMへの保存成功後とし、応答が不明なまま再投稿する処理は避けます。
• 0.60未満なら未分類として担当者へ戻します。担当者は候補外の案件も探し、新規案件、情報不足、案件と無関係な会議を分けます。

複数案件にまたがる議事録への対処

週次会議で複数顧客の商談や複数プロジェクトを扱う場合は、議事録を話題ごとに分けるチャプタリングを加えます。案件ごとに該当区間の要約と原文へのリンクを保存し、他案件の内容が混ざるのを防ぎます。

文字起こしの段落と話題の境界は一致しないため、前後の発話も含めた判定を考えます。権限と顧客の条件で絞った候補からClaudeやGPTに案件IDと根拠の発話範囲を選ばせる方法と、重なりのある固定長区間で検索する方法が候補です。話題が再登場する会議や参照先が曖昧な発話は、人が区間と案件の対応を選ぶ設計にします。

1部門で試験運用する

試験は、営業・PM・カスタマーサクセスなど、議事録の発生量が多い1部門から始める案です。

1. 着手時は全件を担当者が判定します。既存案件数の目安を20〜50件としてベクトル化し、自動リンクを無効にします。
2. 重みと校正を調整し、自動リンクの条件を選びます。許容する誤リンク率を満たすか、調整に使っていない議事録で評価する段階です。
3. 対象拡大は誤リンクと確認負担で判断します。複数案件の分割と新規案件の下書きは、既存案件への照合と分けて評価する方針です。

試験には同一顧客の並行案件、担当者が同じ案件、休眠案件の再開、代理出席を含めます。単一案件の会議では、評価対象の会議数を分母に、検索直後の上位K_search件に正解が入った割合をRecall@K_searchとして測ります。全件採点と検索で候補を絞る方式を試し、再採点後に提示する3件の取りこぼしを比べます。

更新・確認待ち・未分類の扱い

• 案件データは変更分を更新します。案件名やメモは再ベクトル化し、削除・統合された案件は候補から外す設計です。最新情報で判定する際は、検索条件と採点に使う案件情報を判定時に取得します。
• 未確定の通知先を決めておきます。会議主催者など1名と代理担当、再通知期限を設定します。候補には顧客名と一致の根拠を添え、候補外の検索・該当なし・複数案件・保留も選べるようにします。
• 新規案件の候補は承認待ちに保存します。担当者の承認後にCRMへ登録する設計です。

構築費と運用費を見積もる

構築費は、接続するCRMと承認・再送・取消処理の範囲から見積もります。運用費はVPS、Embedding、要約・文字起こし、Vector DB、バックアップ、保守を積み上げます。text-embedding-3-largeの費用を100万トークン当たり0.13ドルと置き、月200件、分割後に送信する重複分も含めた合計を1件1万トークンとする計算例では、議事録分の目安は月0.26米ドルです。案件データの再計算分も加算します。

月間の純削減額が正の場合、回収月数は初期費用を「月間の短縮時間の人件費換算額から追加運用費を引いた額」で割って求めます。換算の基になるのは、導入前後の総作業時間の差です。導入後の作業時間には、承認と訂正も含めます。

修正記録を使って判定を見直す

担当者による訂正から残したいのは、判定時の候補と修正後の案件、判断理由です。検索対象から漏れた案件と、候補には入ったのに順位が低かった案件を分ければ、見直す処理を絞れます。

案件メモに修正内容を反映し、該当案件のベクトルを更新します。Embeddingモデルは固定します。順位付けでは重みの候補を比較し、参加者や活動時期の項を外した場合にも正解案件を拾えるかを評価します。

調整用と評価用の議事録は分けます。同じ定例会議の似た記録を両方へ入れず、案件情報も会議当時のものを使う方針です。修正済みメモを検索すると、後から得た答えが評価に混ざるためです。候補1位の正解率とRecall@3で順位付けと検索漏れを見ます。自動リンク分も無作為に点検し、誤リンク率と自動化率を測ります。確認時間は作業削減、未処理件数は確認待ちの滞留を判断する指標です。

適用範囲と導入判断

採用判断で優先するのは、同じ誤リンク率で人の確認時間をどれだけ減らせるかです。議事録サービスとCRMの間に判定・確認処理を実装する費用に見合うかを、標準連携や案件IDによる照合と同じ議事録で比べます。