商談議事録の AI 分析 — 失注理由を月次で自動集計する

本記事のポイント

• 失注理由が「価格」や「タイミング」で丸められるのは、振り返りをサボっているからではありません。商談議事録が担当者の記憶と自由記述のテキストに散らばったまま、月次で束ねる仕組みがないだけです
• 議事録の集約 → 失注理由のタグ付け → 月次集計 → HubSpot への書き戻しを、Claude Code と HubSpot API でパイプライン化する手順を、コピペで動く一括実行プロンプト付きで STEP 順に再現できます
• タグ体系は 8〜12 個に絞るのが定石です。40 個作ると誰も一貫して付けられず、集計が使い物にならなくなります

「失注理由を聞かれても、いつも『価格』か『タイミング』としか答えられない」。BtoB の営業・マーケの現場で、humbulls が支援するなかでよく聞く悩みです。原因は振り返りをサボっているからではなく、商談ごとの議事録が担当者の記憶と自由記述のテキストに散らばったまま、月次で束ねる仕組みがないからです。本記事では、商談議事録のテキストを Claude Code で失注理由にタグ付けし、月次の傾向レポートまで自動集計して HubSpot に書き戻すパイプラインを、そのまま再現できる手順に落として解説します。プログラミングの経験がなくても、コードとプロンプトは巻末の一括実行キットで生成できるので、必要なのは「どのタグで失注を分類したいか」を決める力だけです。

できあがるもの — 失注理由ランキングが毎月自動で更新される

完成形から見せます。下図の 4 工程で、バラバラだった商談議事録が「今月の失注は 40% がプロダクト適合、25% が意思決定の遅れ」といった構造化された数字に変わり、各商談のノートには AI が付けたタグと 1 行要約が書き戻された状態になります。

この記事の議事録は、HubSpot の商談ノート、オンライン会議の文字起こし、営業メモのどれでも構いません。文章として残っていればパイプラインに載ります。以下、STEP 1 から順に進めます。

STEP 1. 議事録テキストを 1 か所に集約する

「議事録は Notion にあったり、録画の文字起こしだったり、HubSpot のノート欄だったりで、そもそも 1 か所に無いんです」。最初の相談で必ず出てくる状態です。分析の前に、失注商談とその議事録を 1 つの表に集めます。ここが揃っていないと、後の工程がいくら自動でも成果は出ません。

やることは 3 つです。

1. 失注商談を抽出する。HubSpot なら Search API で dealstage が失注 (closedlost) の取引を取得します。API の基本は HubSpot API 入門 で解説しています
2. 各商談に紐づく議事録テキストを集める。HubSpot のノートは取引に関連付いた Notes を取得し、外部の文字起こしは商談 ID をキーに手作業でも貼り付けます
3. 1 行 = 1 商談の CSV にする。列は deal_id / deal_name / close_date / note_text の 4 つで十分です

対象は「直近 6 か月・失注 80 件」のように期間で区切ります。1 商談 1 行にしておくと、後で AI の出力を横に足すだけで済みます。

個人情報の扱い（この STEP で必ず決める）: 議事録には顧客企業名・担当者名・生の発言が含まれます。集約する CSV の保存場所、誰がアクセスできるか、AI に渡す範囲を先に決めてください。実務では、企業名・個人名を 顧客A 担当B のようなプレースホルダーに置換した列を別に作り、AI にはその匿名化列だけを渡す運用が安全です。会社として外部 AI サービスへの入力可否ルールがある場合は、それに従います。判断がつかない場合は、実名を含むテキストをそのまま送らないことを既定にしてください。

つまずきポイントは、議事録の粒度がバラバラなことです。3 行のメモと 5,000 字の文字起こしが混在します。この段階では整形しなくて構いません。長さの違いは STEP 3 で AI 側が吸収します。

→ この集約は巻末の実行キット①でそのまま実行できます

STEP 2. 失注理由のタグ体系を設計する — 8〜12 個に絞る

「タグを細かくすれば正確になると思って、30 個くらい作ったら誰も付けなくなりました」。失注分析でいちばん多い失敗がこれです。原因はタグの精度ではなく、数です。タグは 8〜12 個に絞り、6 つのグループにまとめるのが定石です。多すぎると一貫して付けられず、集計しても「その他」が最多になって示唆が出ません。

失注理由は、次の 6 グループを起点に設計します。自社の商材に合わせて言葉を差し替えてください。

ポイントは、タグごとに「何があったら付けるか」の定義を 1 行で書くことです。この定義がそのまま STEP 3 で AI に渡す判断基準になります。定義が曖昧だと、AI も人も判定がぶれます。

つまずきポイントは、最初から完璧なタグを作ろうとすることです。まず 8 個で始め、集計で「その他」が 2 割を超えたグループだけ後からタグを足す、という運用が現実的です。決定から時間が経つほど、人は失注を「価格のせい」に丸めがちです。議事録という一次テキストからタグ付けするこの方法は、その記憶のバイアスを避けられるのが利点です。

STEP 3. Claude Code で議事録をタグ付け・要約する

「1 件ずつ ChatGPT に貼って分類していたら、80 件で心が折れました」。手作業では続きません。STEP 1 の CSV を Claude Code に渡し、全件を一括でタグ付けします。1 件あたりの処理は数秒、80 件でもおおむね数分で終わります。

AI にやらせるのは 3 つです。

1. STEP 2 のタグ定義に従って、主タグを 1 つと副タグを最大 2 つ付ける
2. 失注の経緯を 1 行 (60 字以内) に要約する
3. 判定の確信度 (高 / 中 / 低) を出す

肝は、出力を JSON で固定し、タグ定義を「必ずこの基準に従うこと」としてプロンプトに埋め込むことです。出力形式を決めておくと、そのまま表に落とせます。

{
  "deal_id": "12345",
  "primary_tag": "予算超過",
  "sub_tags": ["ROI 不明確"],
  "summary": "機能は評価されたが年間予算の枠に収まらず今期見送り",
  "confidence": "高"
}

匿名化の再確認: STEP 1 で匿名化列を作った場合は、AI に渡すのは匿名化済みテキストです。タグと要約の精度は実名が無くても落ちません（誰が言ったかより、何が理由かを見るため）。

つまずきポイントは、確信度「低」の扱いです。AI が迷った商談は、議事録の情報が薄いか、タグ体系に無い理由です。確信度「低」だけを人が目視し、必要ならタグを補正します。全件を人がチェックするのではなく、低確信度だけレビューするのが時短の勘所です。人と AI のタグ一致率は運用で測っておくと、レビュー範囲を狭められます【要確認】。

→ タグ付けと要約は巻末の実行キット①でそのまま実行できます

STEP 4. 月次で傾向を集計する — ランキングと前月比

「タグは付いたけど、で、今月どうだったの?という 1 枚が作れない」。データがあっても、経営や営業に見せる 1 枚にならないと動きません。STEP 3 の出力を月ごとに集計し、失注理由ランキングと前月比を出します。手作業なら 2〜3 時間かかる集計が、スクリプトなら数分です【要確認】。

出すのは 3 つの数字です。

1. 今月の失注理由ランキング (主タグ別の件数と構成比)
2. 前月比 (増えた理由・減った理由)
3. 金額加重の視点 (件数は少なくても失注金額が大きい理由)

集計は Google Sheets のピボットでも、Claude Code に集計スクリプトを書かせても構いません。件数だけを追うと「価格が最多」で毎月終わりがちですが、金額加重で見ると「件数は少ないが大型案件を競合に取られている」といった別の絵が出ます。月次レポート全体を自動化する流れは マーケティングレポート自動化 と同じ発想です。

つまずきポイントは、母数が小さい月の解釈です。失注 5 件で「プロダクト適合が 40%」と言っても、それは 2 件です。件数が少ない月は、構成比より生の件数と要約を読むほうが正確です。傾向として語れるのは、ある程度の件数が積み上がってからです。

STEP 5. HubSpot に書き戻す — ノートと失注理由プロパティ

「分析結果が Sheets の中だけにあって、CRM を見ても何も変わっていない」。集計が別ファイルに留まると、営業は結局見ません。最後に、AI が付けたタグと要約を HubSpot 側に書き戻し、CRM 上で失注理由が追えるようにします。

書き戻し先は 2 か所です。

1. 商談ノート: POST /crm/v3/objects/notes で、要約とタグをノートとして作成し、取引に関連付けます (ノート → 取引の associationTypeId は 214)。本文は hs_note_body、作成日時 hs_timestamp が必須です
2. 失注理由プロパティ: 取引の closed_lost_reason に主タグを書き込みます。このプロパティはドロップダウン化して STEP 2 のタグを選択肢にしておくと、レポートや自動化と揃います

ノート作成のリクエストはこの形です。

{
  "properties": {
    "hs_note_body": "【AI 失注分析】主タグ: 予算超過 / 副: ROI 不明確 — 機能は評価されたが年間予算に収まらず今期見送り",
    "hs_timestamp": "2026-12-01T09:00:00Z"
  },
  "associations": [
    { "to": { "id": "12345" }, "types": [{ "associationCategory": "HUBSPOT_DEFINED", "associationTypeId": 214 }] }
  ]
}

書き戻しの安全策: 更新系の API はまとめて流す前に 1〜2 件で試します。API のレート制限 (Starter は 100req/10s) を超えないよう、件数が多い月は待機を挟みます。既存の closed_lost_reason に人が入れた値がある場合は、上書きせず「AI 分析」とわかる別ノートに残すか、確認してから更新します。削除や一括上書きは、対象件数を表示してから実行するのが原則です。

つまずきポイントは、関連付けの typeId 間違いです。ノートを作れても取引に紐付かないと、商談画面に出ません。1 件書き戻したら、その取引を HubSpot で開き、ノートが表示されるかを必ず目視で確認してください。

→ ノートと失注理由の書き戻しは巻末の実行キット①でそのまま実行できます

動作確認 — 何が見えれば成功か

ここまで組んだら、直近の失注 5 件で 1 周させ、次の 3 点を確認します。

• 集計表: 主タグ別の件数・構成比・前月比が 1 枚で出ている。金額加重の列も埋まっている
• HubSpot の商談: 対象の取引を開くと「【AI 失注分析】」ノートが表示され、closed_lost_reason に主タグが入っている
• 確信度「低」の商談: 目視レビューの対象として抽出され、人がタグを補正できる状態になっている

3 点が揃えば、あとは毎月末に同じパイプラインを回すだけです。初月は件数を絞って精度を確かめ、タグ体系を 1 度チューニングしてから本格運用に移すと安定します。

まとめ — 失注理由は「感覚」から「毎月の数字」へ

商談議事録はすでにテキストとして存在します。足りないのは、それを失注理由に構造化して月次で束ねる仕組みだけです。集約 → タグ付け → 集計 → 書き戻しの 5 STEP をなぞれば、「なんとなく価格」で止まっていた振り返りが、毎月更新される失注理由ランキングに変わります。コードとプロンプトは巻末の一括実行キットで生成できるので、私たち humbulls が支援する現場でも、最初の 1 周は半日ほどで組めています。

失注の傾向が数字で見えたら、次は打ち手です。どの理由をどの順で潰すか、営業とマーケでどう分担するかは、Fractional CMO サービス で伴走しています。失注を経過日数の視点で捉え直す コホート分析 と組み合わせると、「いつ・なぜ落ちるか」がさらに立体的になります。自社のデータで試したい場合は お問い合わせ からご相談ください。

🤖 AI 実行キット

本文の STEP 1〜5 を、そのまま Claude Code に丸ごと実行させるためのキットです。プロンプトの記入例を自社の値に置き換えて渡してください。

キット① 議事録から失注分析パイプラインを一気に組む — 半日

種別: 実装キット 使うもの: Claude Code + HubSpot API (Private App Token)。ブラウザ版 Claude でもタグ付けと集計はできますが、HubSpot からの取得と書き戻しは手動になります 事前に用意するもの: 失注商談の議事録 (HubSpot ノート or 文字起こしのテキスト) / HubSpot の Private App Token / STEP 2 で決めたタグ定義 / 個人情報の扱い方針 (匿名化するか)

プロンプト:

商談議事録から失注理由を分析するパイプラインを作ってください。

【私の環境】
- 議事録のありか: HubSpot の失注取引に紐づくノート
  （記入例。文字起こしCSVならそのパスに置き換え）
- 対象期間: 直近 6 か月・失注のみ（dealstage = closedlost）
- HubSpot Token: スクリプトプロパティ / 環境変数 HUBSPOT_TOKEN から読む
- 個人情報方針: 企業名・個人名は 顧客A / 担当B に置換した列を作り、
  AI にはその匿名化列だけを渡す（記入例。自社ルールに置き換え）

【失注理由のタグ定義（必ずこの基準で分類すること）】
- 予算超過: 金額が合わない
- ROI不明確: 投資対効果を説明しきれなかった
- 機能不足: 求める機能が無い
- 適合外: 用途に合わない
- 対応遅延: レス遅れ・要件の詰めが甘い
- 導入実績不足: 同業事例や安心材料を出せなかった
- 時期尚早: 今期は見送り・稟議が通らない
- 競合採用: 他社に決まった
（記入例。自社の 8〜12 個に置き換え）

【必ず守る実装条件】
1. HubSpot Search API を POST で叩き、paging.next.after で失注取引を全件取得する
2. 各取引に紐づくノートを取得し、deal_id / deal_name / close_date / note_text の
   CSV にまとめる
3. 1 件ずつ上のタグ定義で分類し、次の JSON を返す:
   { deal_id, primary_tag, sub_tags(最大2), summary(60字以内), confidence(高/中/低) }
4. 月ごとに集計し、主タグ別の 件数 / 構成比 / 前月比 / 失注金額 の表を出す
5. 結果を HubSpot に書き戻す:
   - POST /crm/v3/objects/notes で要約ノートを作成し、取引に関連付ける
     （associationTypeId=214、hs_note_body と hs_timestamp を含める）
   - 取引の closed_lost_reason に primary_tag を入れる
6. 書き戻しは最初に 1〜2 件で試し、レート制限(100req/10s)に配慮して待機を挟む

【出力】
- 取得〜集計〜書き戻しのスクリプト一式
- confidence が「低」の商談だけを抜き出す一覧（人のレビュー用）
- 実行手順を最後にコメントで併記

出力の確認ポイント:

• タグ付けが STEP 2 のタグ定義の言葉だけで出ているか (勝手なタグが増えていないか)
• ノートの関連付けに associationTypeId: 214 が入り、取引に紐付いているか
• confidence「低」の商談が別リストに抽出され、人のレビュー対象になっているか
• 書き戻し前に件数が表示され、いきなり全件を上書きしない作りになっているか

うまくいかないとき:

• HubSpot API が 403 を返す → Private App の Scopes 不足です。取引・ノートの読み書き scope を追加してください
• タグが「その他」ばかりになる → タグ定義の 1 行が曖昧です。「何があったら付けるか」を具体化して渡し直します
• ノートは作れるが商談画面に出ない → 関連付けの typeId 違いです。214 になっているか確認します

よくあるつまずきの早見表:

参考文献

• HubSpot Notes (Engagements) API — HubSpot 開発者ドキュメント (取得日: 2026-07)
• HubSpot's default deal properties — closed_lost_reason の仕様 (取得日: 2026-07)
• HubSpot CRM Search API — HubSpot 開発者ドキュメント (取得日: 2026-07)
• Text generation with Claude — Anthropic 公式 (取得日: 2026-07)
• Win-Loss Analysis and Optimization — Qualtrics (取得日: 2026-07)