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

議事録 AI の限界 — 要約までで止まっている

ここ数年で Zoom や Google Meet の議事録 AI 機能、Otter、Tactiq、Notta、tl;dv など、文字起こし + 要約を自動で出す SaaS は出揃いました。会議が終わると Slack に要約が流れてくる、という体験は多くの企業で当たり前になっています。一方で、現場で何が起きているかというと、その要約を 誰かが目で読み直して、Salesforce の該当商談に貼り付けたり、Notion の案件ページに添付したりしている のが実態です。

営業マネージャーが商談レビューのためにわざわざ議事録を読み直す。PM が案件ごとに議事録を再配置する。担当者が異動するとその引き継ぎノウハウもまた失われる。議事録の振り分けは情報整理コストとして地味に大きい のですが、案件名・参加者・タイミングが絡む判断のため、これまで自動化の標的になりにくい領域でした。

「案件への自動紐付け」が必要な3つの理由

1. 営業の活動履歴を CRM で検索可能にする — 議事録が案件レコードに紐付いていなければ、商談タイムラインに残らない。後から振り返って『この商談で何を話したか』を検索できない。
2. PM の進捗管理が議事録ベースになる — kintone や Notion のプロジェクトページに紐付くことで、決定事項・課題・宿題を案件単位で追える。週次定例の準備時間が大幅に短縮される。
3. 経営層が状況を一覧できる — 案件単位に集約された議事録は、ダッシュボードや営業会議で『各案件の最新動向』として要約しやすい。経営判断の根拠データになる。

つまり、議事録を 案件レコードに紐付ける という工程が完了して初めて、議事録 AI の投資対効果が成立します。ここを自動化しない限り、いくら高性能な要約 AI を入れても全社的な生産性は上がりません。

n8n × Embedding 議事録ルーター 全体アーキテクチャ

実装する仕組みは『議事録ルーター』と呼んでいます。会議が終わるたびに、議事録の内容を読み解いて『どの既存案件に紐付けるべきか』を判定し、Salesforce や kintone の正しいレコードに自動でリンク + 要約コメントを書き込むパイプラインです。

中核は Embedding（埋め込みベクトル）による類似度検索 です。Salesforce や kintone に登録されている既存案件の名前・概要・直近の活動メモを OpenAI の text-embedding-3-large などで事前にベクトル化し、Pinecone・Qdrant・Supabase Vector のような Vector DB に格納しておきます。新しい議事録が届いたら、その議事録もベクトル化して Vector DB に問い合わせ、最も近い既存案件を Top-3 で取得します。

マッチングアルゴリズム — 3 シグナルを合成する

テキストの類似度だけでマッチングすると、似た製品名や業界用語が混じる議事録が誤マッチしやすくなります。実運用では 3 つのシグナルを重み付きで合成 することで、誤マッチ率が大きく下がります。

• ① テキスト類似度 (Embedding) — 議事録本文と案件名・案件メモのコサイン類似度。重み 0.5。
• ② 参加者マッチ (人 → 案件担当) — 会議参加者の email や CRM ユーザー ID と、案件の担当者・関係者を突合。重み 0.3。1人でも一致していれば大きく寄与する。
• ③ 時間軸近接性 — 直近に活動がある案件を優先する time-decay 関数。重み 0.2。1ヶ月以上更新のない案件は減点する。

この3つを重み付きで合計し、0〜1 の confidence スコアに正規化します。重みは初期値で運用を開始し、誤マッチが多いシグナルを下げる・効くシグナルを上げるという形で 1〜2 ヶ月かけてチューニングします。社内のデータパターンに応じた重み調整こそが、議事録ルーターの精度を決定づける要素です。

// 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

Salesforce / HubSpot / kintone への書き込み実装

Top-1 案件が確定したら、各 CRM や PM ツールへの書き込みです。Salesforce なら Event または Task オブジェクトに、HubSpot なら Meeting Engagement、kintone なら案件アプリのコメントとして書き込みます。重要なのは 議事録本体への永続リンク + AI 要約の3行 を投稿することで、案件タイムラインから議事録に戻れる動線を残すことです。

{
  "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"
}

信頼度に応じた振り分け戦略

AI のマッチングは完璧ではないので、信頼度に応じて自動と人間判断を切り替える HITL（Human-in-the-Loop）設計が必要です。confidence スコアを 3 段階で分岐させます。

• ≥ 0.85 → 自動リンク: CRM の該当案件タイムラインに即座に書き込み。担当者には Slack で通知だけ行う。
• 0.60 〜 0.84 → Slack で Top-3 提示: 担当者の Slack に『どの案件にリンクしますか？』として Top-3 をボタンで提示。1 クリックで確定。
• < 0.60 → 未分類 or 新規案件作成: マッチする既存案件がない可能性が高い。新規案件として CRM に下書き作成し、担当者に確認依頼を出す。

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

実務では『1 回の会議で複数案件の話をする』ケースが少なからずあります。商談レビューで複数顧客を一気に振り返る、PM の週次で複数プロジェクトを横断して話す、といった場面です。この場合、議事録ルーターは チャプタリング を組み込みます。

具体的には、議事録の文字起こしを段落単位で分割し、各段落について個別に類似度マッチングをかけます。段落のクラスタごとに別の案件にリンクされるので、1 つの議事録が複数の案件タイムラインに分散して紐付く形になります。Claude や GPT のロングコンテキスト機能を使えば、議事録全体を一度に渡して『この議事録は何個の案件について話しているか』を構造化して返させることも可能です。

導入の段階設計 — どこから着手するか

議事録ルーターは、初日から全社に展開しようとしても定着しません。営業・PM・カスタマーサクセスなど 議事録の発生量が多い 1 部門 からパイロット運用するのが鉄則です。3 段階で進める想定が現実的です。

1. 第 1 段階（着手 1〜4 週目） — 既存案件 20〜50 件の embedding を Vector DB に投入。HITL を 100% 通す（自動リンクは off）。Slack ボタン承認で『どの案件にリンクするか』を担当者が選び、誤マッチを修正ログに残す。
2. 第 2 段階（5〜8 週目） — 修正ログをもとに重み（テキスト類似度・参加者マッチ・時間軸近接）を再チューニング。自動リンクのしきい値を 0.90 から開始し、自動承認比率を測定する。
3. 第 3 段階（9〜12 週目） — しきい値を 0.85 に下げて自動比率を引き上げる。並行して、議事録の段落チャプタリング（複数案件にまたがるケース）と新規案件下書きの自動作成機能を有効化する。

段階設計を飛ばして最初から自動リンクを ON にすると、誤マッチが営業現場の信頼を毀損します。最初の 1 ヶ月は HITL 100% を通して、現場が AI の判断を確認・修正できる状態を担保 することが、定着のために最も重要です。

典型的な失敗パターン

• Vector DB のインデックスを更新しない — 案件名や案件メモが更新されても Vector DB を再生成しないと、古い情報のままマッチングが行われる。週次バッチで再インデックスする運用を最初に決める。
• Slack 通知を全員に投げて承認動線が崩れる — 案件担当でない人に通知が飛ぶと、承認ボタンが誰の責任でも押されずに放置される。通知先は『案件オーナー 1 名』に絞るのが基本。
• 新規案件作成を許可しない — マッチしない議事録を全て『未分類』に積み上げると、未分類フォルダがゴミ箱化する。低信頼度の場合は AI が新規案件レコードを下書き作成し、担当者は承認するだけの導線にする。

投資回収と費用感の目安

セルフホスト構成で議事録ルーターをゼロから組み立てる場合、規模にもよりますが工数 50〜90 時間程度が目安です。月額ランニングは VPS の数千円 + Embedding API の数千円〜1 万円程度 + Vector DB のホスティング（Pinecone は無料枠から、Supabase Vector や Qdrant Self-host なら VPS 内に同居可能）。営業マネージャーや PM が議事録を CRM に転記する時間に換算すれば、規模次第ですが半年〜1 年程度で投資が回収できる水準に入ります。

議事録の質を上げる学習ループ

議事録ルーターは投入直後の精度より、運用しながら精度が上がっていく学習ループ をどう組むかが重要です。人間が修正したマッチング（誤って Top-1 が選ばれた case を Top-2 に直したログ）を蓄積し、それを 1〜2 週間ごとに反映していきます。

具体的な学習ループは2つに分かれます。1 つは Embedding を再構築 する経路で、修正されたマッチングから案件メモを更新して、Vector DB のインデックスを再生成します。もう1 つは 重み付けの再チューニング で、誤マッチを起こしやすいシグナルの重みを下げ、効くシグナルの重みを上げます。月に1回、1時間程度の見直しタイムを取るだけで、半年で 9 割超の精度が見えてきます。

まとめ — 議事録 AI を『置く』から『回す』へ

議事録 AI を『導入した』だけでは効果は半減します。要約までの自動化を 100 とすると、案件への自動振り分けまで通って初めて 200 になるイメージです。n8n + Embedding + Vector DB という比較的軽い構成で、SaaS の議事録 AI を CRM と接続して『回す』状態 に持っていくのが、2026 年現在の現実解と言えます。

本記事で紹介したアーキテクチャは、議事録だけでなく『チャットの長文ログ』『顧客アンケート』『展示会のヒアリングメモ』といった非構造データを CRM に流し込む仕組みにも応用が利きます。1 つ作っておけば、全社の情報インフラとして長く効きます。