ルールのないCRMにAIエージェントを入れると何が起きるか｜起こりうる事故と、先に整備という近道

「うちもそろそろAIエージェントを入れて、商談記録の入力やフォロー、レポート作成を自動化したい」。営業の現場で、こうした声が当たり前に聞かれるようになりました。

ところが、いざCRM（顧客管理システム）を開いてみると、同じ取引先が「株式会社○○」「○○(株)」「○○ホールディングス」と3通りで登録され、商談名は「A社・継続」「4月の件」「★最重要」と各人がばらばらに付け、肝心の項目は空欄のまま——こうしたCRMは珍しくありません。
多くの方は「データが多少ばらついていても、AIなら賢くやってくれる」「むしろAIに掃除させればいい」と考えます。

本記事では、入力のルールが決まっていないCRM——以下「ルールのないCRM」と呼びます——にAIエージェントを入れた際に現場で起こりうることを、具体的な事故として書きます。そのうえで、ルールを整えないまま導入すると現場が結局どうなるのか、そしてAIを入れる前にCRMを整えておくことがなぜ近道になるのかまでを解説します。

ここで言う「ルールのないCRM」とは、たとえば次のような状態です。

・同じ取引先が、表記の違いで複数のレコードに分かれている（社名の重複・表記ゆれ）
・入力してほしい項目が空欄のまま運用され、入力形式も人によってばらばら（入力ルールの不在）
・商談フェーズの定義が共有されておらず、同じ「提案中」の意味が人によって違う
・商談名が各人の自由記述で、命名のルールがない

AIエージェントは、人と違って「データを疑わない」

事故の話に入る前に、土台となる前提を一つだけ共有させてください。それは、AIはばらついたデータを「直して」はくれず、むしろ「増幅する」という性質です。なぜそうなるのか、噛み砕いて説明します。

AIエージェントの頭脳にあたるのは、大規模言語モデル（LLM）と呼ばれる仕組みです。膨大な文章から言葉のパターンを学び、文脈に対して「それらしい」答えを組み立てます。便利な一方で、根拠が薄くても、もっともらしい答えを自信ありげに返す傾向があり、これはハルシネーション（幻覚）と呼ばれます（出典: LLM（大規模言語モデル）とは？仕組みをわかりやすく解説 — Salesforceブログ）。

ここで分かれ目になるのが、人とAIの決定的な違いです。
経験のある営業担当者なら、レコードを見て「あれ、この会社、別の名前でも登録されていなかったか」「この商談名、何のことだろう」と、手が止まります。違和感を覚えて確認する、という当たり前の動作です。
ところがAIは、目の前のデータを正しいものとして受け取り、立ち止まりません。CRM向けAIをめぐる議論でも、「AIエージェントは、扱っているデータを疑わない。自信を持って、大規模に、ためらいなく実行する」と指摘されています（出典: If Your Data Is Already Broken, Agentforce Will Multiply Those Problems — Salesforce Ben）。

この「疑わずに大規模実行する」性質こそが、ばらつきを増幅させます。
人が一件の不正確なレコードに出くわしても、起きるのはその場限りの小さな問題です。しかしAIが大量の不正確なレコードを処理すると、同じゆがみが全体に行きわたる、系統的なゆがみになる。
先のSalesforce Benの記事も、この違いを事故の本質として挙げています。

そして、ここで一つ補っておきたいことがあります。この性質は、CRMに外付けするAIでも、CRMに最初から搭載されているAIでも変わりません。
むしろ、内蔵AIのほうがばらつきの影響を強く受ける面すらあります。

たとえばSalesforceに搭載されているAIエージェント、Einsteinによるリードスコアリング（見込み客の有望度を点数化する機能）は、自社の過去の成約データを分析し、「過去に受注できた案件にどれだけ似ているか」で新規のリードを採点します（出典: Understand How Einstein Scores Your Leads — Salesforce Help）。

つまり、過去のレコードがばらついていれば、そのばらつきがAIモデルそのものに焼き付きます。その場で渡すだけの使い方より、ばらつきが構造的に響いてくるわけです。
また、「内蔵だから自社データ用にできている」という安心も、過信は禁物です。AIはCRMのどの欄が「会社名」「フェーズ」かという構造は理解していますが、その欄の中身が3通りに割れていたり、フェーズの意味が揃っていなかったりするのは別の問題で、構造を知っていても中身がばらついていれば正しくは読めません。
先に引いたSalesforce Benの記事も、データが壊れたままであれば、内蔵AIであるAgentforceはその問題を直すどころか増幅させる、と論じています（出典: If Your Data Is Already Broken, Agentforce Will Multiply Those Problems — Salesforce Ben）。

この前提を持ったうえで、では具体的にどんな事故が起きるのかを、ばらつきの種類ごとに見ていきます。

ばらつきの種類別に、AIはどんな間違いを起こすか

ルールのないCRMの「ばらつき」と言っても、その種類によって、AIのどの機能で、どんな間違いが起きるかは変わってきます。冒頭で挙げた状態を3つの型に整理し、それぞれ「どのばらつきが」「AIのどの機能で」「どんな誤動作を起こし」「結果どんな業務インパクトになるか」という粒度で描きます。

社名の重複・表記ゆれ — 名寄せと集計を誤り、同じ客に重複アプローチする

一つ目は、同じ取引先が複数のレコードに分かれている状態です。
「株式会社○○」と「○○(株)」、全角と半角の混在、住所表記のばらつき——入力のルールが統一されていないために、本来は一社であるはずの取引先が、別々の会社として登録されてしまう。これは手動入力の現場で最も起きやすいばらつきです（出典: CRMの名寄せとは？ — DataVizLab）。

こうしたばらつきを一つの正しい情報にまとめる作業を、名寄せと呼びます（出典: 名寄せとは？ — 営業DX Handbook by Sansan）。
表記がばらついたままだとAIはどう振る舞うか。同じ会社を別物として扱い、片方の履歴しか参照せずに「この顧客とは初めての接点です」と判断したり、重複したレコードの両方に、あるいは間違ったほうに動作したりします（出典: Salesforce Ben）。

このばらつきは、わかりやすい事故として表れます。
AIに自動フォローを任せていれば、同じ取引先に複数の担当者から、ばらばらの内容で連絡が飛びます。
顧客から見れば「左手と右手が連携していない会社」に映り、信頼を損ね、最悪の場合は失注やクレームにつながります。
集計の面でも、一社が二社に分かれて数えられれば、顧客数も商談金額も水増しされ、その数字を信じた打ち手がずれていきます。

人が名寄せをしていた頃は一件ずつ拾えていた違和感が、AIによる自動処理では拾われないまま、全件に広がるのです。

入力ルールの不在 — 要約も次アクションも、「もっともらしく間違った答え」を返す

二つ目は、肝心の項目が空欄のまま放置され、入力形式も自由、という状態です。
商談の背景、検討状況、競合の有無といった欄が、人によって埋まっていたり空だったりする。カテゴリ分類も、選択式ではなく自由記述になっている。
AIエージェントに「商談の要約」「次にとるべきアクションの提案」「対応チームへの自動振り分け」を任せたいなら、このばらつきは特に厄介です。

理由は、先に触れたLLMの性質にあります。
AIは空欄を「わからない」と保留できず、文脈から「それらしい中身」を補って埋めてしまう。存在しない前提を勝手に作り、その上に要約や提案を組み立てるため、出力は一見すると筋が通っているのに、事実とずれた内容になります。「もっともらしいが間違った答え」を、自信たっぷりに返してくる。これがこのばらつきの怖さです。
自由記述のカテゴリも同様で、AIはそれを誤って解釈し、たとえば問い合わせを誤った担当チームへ、何の警告も出さずに振り分けてしまうことがあります（出典: Salesforce Ben）。

このばらつきから、二つの事故が発生します。
一つは、誤った次アクションの提案を信じて現場が動いてしまい、後から手戻りが発生すること。
もう一つは、確度スコアや要約が信用できないとわかった瞬間、結局すべてを人が見直すことになり、「自動化したのに、確認の手間だけが増えた」という状態に陥ることです。

AIが頼りになるのは、判断の材料が揃っている範囲に限られます。材料が欠けていても、AIはそれを言わずに答えを出してしまう、という点が、人による補完との一番の違いです。

商談名・フェーズ定義の自由記述 — パイプラインを読めず、予測が信用できない数字になる

三つ目は、商談名が「4月の件」「★最重要」のような自由記述で、商談フェーズの定義もチームで共有されていない、という状態です。
AIエージェントに「パイプライン（進行中の商談全体）の分析」「売上予測」「レポートの自動生成」を任せたいときに、これが問題になります。

問題の核心は、同じ言葉が人によって違う意味になっていることです。
たとえば同じ「提案中」というフェーズでも、ある担当者は「資料を送っただけ」、別の担当者は「決裁者にプレゼンまで済ませた」状態を指していたりします。この状態では、パイプライン上の案件数も金額もまったく信用できず、データ分析や売上予測も意味をなさなくなります（出典: AIで売上予測の精度を向上させる方法 — StartLink）。

フェーズの定義や移行の条件が揃って初めて、パイプラインは正しく読める数字になる、というのは、運用の基本として広く語られているところです（出典: パイプライン管理とは？ — Salesforceブログ）。

このばらつきから起こりうる事故として最も重いのは、AIが出した予測やレポートを経営判断に使ってしまうことです。
母数となる商談の状態が取り違えられていれば、どれほど高度なAIでも、はじき出す予測は実態とかけ離れます。それを信じて増員や投資のタイミングを決めれば、判断そのものが狂う。
AIのレポートは、人が手集計していた頃より速く、きれいな見た目で出てきます。だからこそ、土台が崩れていることに気づきにくく、かえって危ういのです。

ここまでの3つを一覧にすると、ばらつきの種類とAIの機能、そして起きる事故の対応関係が見えてきます。

共通しているのは、いずれも「AIが間違っていることに、AI自身も現場も気づきにくい」という点です。だからこそ、ばらつきは静かに、しかし全体に広がります。

整えないままAIを入れると、結局どうなるか——自動化の範囲と現場の負担

ここまでは、ルールのないCRMにAIを入れたときに起きる、一つひとつの「事故」を見てきました。ここからは視点をひとつ上げます。

こうした事故が起こりうると承知のうえで、それでもルールを整えないままAIを導入したとすると、現場は結局どんな状況に落ち着くのか。
個別の事故ではなく、導入したあとに残る全体像を、3つの面から見ていきます。

第一に、自動化できる範囲が狭まります。
AIに安心して任せられるのは、データが整っていて、AIが正しく判断できる範囲だけです。ばらついた項目については、AIは判断を止められない代わりに、人が後ろですべて確認しなければなりません。
結果として、「自動化を入れたのに、人手がほとんど減らない」という状態になります。自動化したつもりの範囲が、実際にはAIと人の二人三脚になっている、ということです。

第二に、AIを入れたことで、かえって人の作業が増えます。
AIが出した要約や提案が正しいかを確かめ、間違いを直し、ときには重複アプローチで生じたクレームに対応する——これらは、AIを入れる前にはなかった仕事です。
しかもAIが大量のレコードを一度に処理するぶん、点検すべき件数も膨らみます。
第一の点が「自動化しても人手が減らない」話だとすれば、こちらはAIが新しい作業そのものを生み出す話で、整わないうちは、AIは人の仕事を肩代わりするどころか、確認という別の仕事を上乗せしてしまうのです。

第三に、ルールを決めながら導入しようとすると、工数が膨らみます。
動いているAIの裏側で、表記ゆれを直し、フェーズの定義を揃え、入力ルールを決めて周知する。これを同時並行で進めるのは、二重の負荷です。

つまり、ルールのないままAIを入れることは、見かけ上の自動化と引き換えに、見えにくい運用コストを抱え込むことを意味します。
投資対効果（ROI）で見れば、立ち上げの時期ほど割に合いにくい構図になります。

「整えてからAI」を、社内でどう判断し、どう説明するか

ここまでの話を一言にまとめると、AIエージェントを入れる前に、CRMをルール化された整った基盤にしておくことが、結局いちばんの近道になります。

ばらつきを残したまま走り出すより、入口を整えてから動かすほうが、損害を直し続ける側から、事故を未然に防ぐ側へ回れる、ということです。

とはいえ、ここで誤解してほしくないのは、「完璧に掃除し終えてからでないとAIに触れてはいけない」という話ではない、という点です。

全社のデータを隅々まで整えてから、というのでは、限られた工数の企業は永遠に始められません。現実的なのは、全部をやろうとしないことです。
AIに任せたい業務をまず一つ決め、そこから逆算して、必要な範囲のデータだけを先に整える。 この順番なら、掃除に人を大量に割けなくても着手できます。

なお、CRMの多くには、重複管理や名寄せを助ける機能が備わっています。ただし、これらは「整備という作業を実行するための道具」であって、ボタン一つでばらつきが消えるものではありません。重複管理だけでは不十分で、入力の検証・標準化・名寄せをまとめて運用して初めて、AIが信頼できる土台になります。

先のSalesforce Benの記事も、AIを入れてからデータを直すのではなく、重複排除・標準化・補完・検証といったデータ品質の取り組みを、AI導入の前提として継続的に回すべきだと述べています（出典: If Your Data Is Already Broken, Agentforce Will Multiply Those Problems — Salesforce Ben）。
内蔵AIに掃除を期待するのではなく、こうした機能を使って整備をやりきる、と捉えるのが実態に合っています。

最後に、現場の納得についても触れておきます。SFAやCRMが定着しない最大の理由は、現場のやる気の問題ではなく、入力の負担と、入力しても自分には返りがない、という構造にあると指摘されています（出典: SFAが定着しない5つの理由 — GENIEE、SFA運用を成功させる方法 — サスケ）。

だからこそ、ルール化を「現場にさらなる入力を強いること」として持ち込むと、また形だけのものになりかねません。
そうではなく、「AIに任せられる前提を作るための投資であり、整えば入力や確認の手間はむしろAIが引き受けてくれる」という整理後の結果まで一緒に示すことが、定着の分かれ目になると考えています。

まとめ

ルールのないCRMにAIエージェントを入れても、AIはばらついたデータを直してはくれません。人のように立ち止まって疑うことをせず、間違ったまま、自信を持って、大規模に実行してしまう。

これは外付けのAIでも、CRMに内蔵されたAIでも同じで、むしろ内蔵AIは自社の過去データを学習に使うぶん、ばらつきが焼き付きやすい面さえあります。

そのばらつきは、種類ごとに違う事故を起こします。 社名の表記ゆれは名寄せと集計を誤らせて重複アプローチを生み、入力ルールの不在はもっともらしく間違った要約や提案を生み、商談名やフェーズの自由記述はパイプラインを読めなくして予測を狂わせます。

そしてその事故は、自動化できる範囲を狭め、人の確認という運用負担を残し、ルール化しながらの導入であれば工数を膨らませる——という形で、AI導入の見返りそのものを小さくしてしまいます。

だからこそ、答えは「とりあえずAI」ではなく、「整えてからAI」です。
といっても、全社の完璧な掃除を待つ必要はありません。最初の一歩は、AIに任せたい業務を一つ決め、そこに必要な範囲だけを先に整えること。順番を変えるだけで、同じAIへの投資が、見かけの自動化ではなく、実際に手が空く自動化として返ってきます。