Claude Codeで商談メモから次アクションを抽出しCRMに整える方法｜議事録・要点・更新項目の型を固定する
商談メモが Slack、議事録、録音要約、営業個人のテキストに散らばったままだと、CRMが更新されない問題はほぼ確実に起きます。しかも、抜けるのは議事録そのものではなく、次アクション、期限、担当、更新すべき顧客文脈です。
Claude Code は、この前段を file workflow として整えるのに向いています。商談メモを読み、要点、更新項目、next action、期日、担当候補を同じ出力列に揃えることで、AI CRM や営業管理へ載せやすい状態を repeatable に作れます。
本記事のポイント
- Claude Codeは、商談メモを読み直して要点、更新項目、次アクションを同じ列構造へ整える前処理に向いている。
- GUIでCRM画面を直接動かす段階はClaude Cowork、CRMへ入れる前の抽出と整形はClaude Code、と分けると運用がぶれにくい。
- 先に入力列、出力列、更新権限、人がレビューする境界を決めないと、要約だけ増えてCRM更新率は上がらない。
Claude Codeが向いている「商談メモ to CRM」の仕事
このテーマで Claude Code が強いのは、商談後の情報を「画面操作」ではなく「ファイル整形」として扱える場面です。会議メモ、録音要約、メールの宿題、案件温度感を読み、CRM に入れるべき列へ変換する仕事は、terminal 上でルールファイルを持てる方が安定します。
| 判断軸 | Claude Code | Claude Cowork | 人が残す判断 |
|---|---|---|---|
| 主な入力 | 議事録Markdown、録音要約、CSV、案件一覧 | CRM画面、メール、カレンダー、ローカルGUI | 案件温度感の最終承認 |
| 向いている処理 | 要点抽出、更新列の整形、期限候補の付与 | 実際の入力、画面確認、周辺アプリ操作 | 誰にアサインするかの例外判断 |
| 再現性 | 高い。出力列と判定ルールを固定できる | 中。操作手順の影響を受けやすい | 重要顧客だけ別運用にする判断 |
つまり、商談メモから update candidate を作る段階は Claude Code、その候補を CRM に反映する段階は Claude Cowork や人手、という分担が実務では自然です。Google Workspace で営業管理を行う記事でも同じですが、入力前処理が整わないまま画面自動化を始めても定着しません。
先に固定すべき入力と出力の型
商談メモの自動整形で先に決めるべきなのは、メモの出来の良さではなく、CRM へ渡す出力形式です。最低限、更新対象、決定事項、next action、担当、期限の5列が揃っていれば、営業会議や案件レビューで使える形になります。
| ファイル | 役割 | 最低限入れる項目 |
|---|---|---|
notes/meeting-2026-03-14.md | 元メモ | 会議要点、宿題、決定事項、参加者 |
rules/crm-fields.md | 抽出ルール | 更新対象プロパティ、優先度、期限の付け方 |
master/account-owner.csv | 担当者マスタ | 担当者名、チーム、引き継ぎ条件 |
output/crm-update.csv | 出力 | account_id、update_field、next_action、owner、due_date |
ここで重要なのは、何を要約するかではなく、何を CRM の更新候補にするかを先に決めることです。活動の記録粒度は 活動ログ設計 に近く、案件管理の粒度は CRM / SFA / MA の役割分担 に影響されます。
実装イメージは「議事録生成」ではなく「更新候補生成」
失敗しやすいのは、Claude Code に完璧な議事録を作らせようとすることです。実務で効くのは、営業が次に触る列だけを安定して出すことです。
sales-notes-workflow/
input/
meeting-note.md
owner-master.csv
rules/
crm-fields.md
output/
crm-update.csv
review-notes.md
依頼は「meeting-note を読み、crm-fields に従って update candidate を output/crm-update.csv に保存。判断が割れる箇所は review-notes.md に出す」のように短くした方が安定します。営業が見るべきなのは review-notes と高優先の next action だけです。
この型を作っておくと、Google Workspace CRM のような軽量運用でも、AI CRM のような本格運用でも前処理を共通化できます。
人が確認する境界を先に決める
商談メモは、文章としては正しくても、営業判断としては危ういことがあります。次の3点は最初から人が見る前提で決めた方が安全です。
| 確認ポイント | 人が見る理由 | 固定すべきこと |
|---|---|---|
| 案件温度感 | 熱量は文脈差が大きく、自動判定が割れやすい | Hot / Warm / Cold の条件 |
| 担当アサイン | 既存担当や顧客関係が優先される場合がある | 引き継ぎ条件と例外ルール |
| 期限 | 「来週中」など曖昧表現の解釈がぶれやすい | due date の決め方と未確定時の扱い |
逆に、この境界を決めずに「良い感じに CRM 化して」と頼むと、更新候補は出ても誰も信用しない状態になります。CRM に入力されない問題の根本は、入力そのものより「この情報を入れて良いのか」が曖昧なことです。
見るべきKPIは入力件数より更新率
導入後は、要約件数よりも、更新率と next action 実行率を見る方が正しいです。
- 商談後 24 時間以内の CRM 更新率
- next action の期限付き登録率
- review-notes に残る曖昧案件の比率
- 商談メモから活動ログまでの転記時間
もし更新率が上がらないなら、Claude Code の精度より、CRM 側の必須項目や運用フローが重すぎる可能性があります。その場合は AI CRM や 営業管理の設計から見直す方が先です。
よくある質問
Claude CodeだけでCRM入力まで完結させるべきですか？
最初からは勧めません。まずは crm-update.csv の品質を安定させ、更新候補として信用できる状態にしてから実入力へ進めた方が安全です。
録音要約や文字起こしでも使えますか？
使えます。ただし、発言ログそのものより、決定事項、宿題、期限の抽出ルールを先に決める必要があります。
Claude Coworkとの違いは何ですか？
Claude Coworkは CRM 画面や周辺 GUI を横断する実行に向きます。Claude Code は、商談メモをファイルとして整形し、更新候補を repeatable に作る前処理に向きます。
小規模チームでも意味はありますか？
あります。むしろ少人数の方が、商談メモの粒度と出力列をすぐ揃えられるので、更新率改善の効果が出やすいです。
関連ページと関連記事
商談メモの整理だけで終わらせず、活動ログ、CRM設計、営業管理までつなげて見ると運用が安定します。
- Google Workspaceで営業管理を行う方法｜運用が崩れない最低限の設計：メモの置き場と営業管理の全体設計を確認できます。
- AI CRMとは？従来CRMとの違いと導入判断のポイント：更新候補をどこへ残すべきかの基盤設計につながります。
- CRM活動ログテンプレート｜メール・会議・メモを1本化する最小運用：商談メモの粒度を活動ログへどう落とすかを整理できます。
- CRMに入力されない問題とは？現場が止まる本当の理由と改善策：更新候補があっても反映されない構造的な詰まりを確認できます。
- Google Workspace CRMの考え方｜Gmail・カレンダー中心で回す運用設計：軽量運用に載せる場合の設計が見えます。
商談メモの更新フローを現場へ載せたい場合
記事で見えてきた論点を、顧客管理・営業管理・マーケ連携まで含めて整理する段階では、LP 側の設計もあわせて確認すると判断しやすくなります。