RattleでCRM更新が崩れる原因｜確認を形だけにしない

「AIが確認を取ってから書き換えるのだから、CRMが崩れる心配はない」「承認ボタンを押したのは営業本人なのだから、間違っていれば本人の責任だ」——商談の更新をAIに任せる話が出たとき、営業企画の会議でよく出る二つの見方です。どちらも半分しか当たっていません。CRMが崩れる原因は確認の有無ではなく、確認する人が何を見て押すのか、どの定義で書くのかが決まっていないことにあります。この記事では、Rattle と、同じチームが作った Von を例に、AIが確認付きでCRMの商談や予測を書き換えるとき、誰の権限で書くか、確認を形だけにしない設計、予測の根拠の見せ方、マーケと営業で商談の定義がずれる問題を、崩れ方のシナリオの順に整理します。

Rattle は、CRMの更新を Slack と Teams の中で済ませる営業基盤

Rattle は、米国の企業が提供する営業部門向けの基盤です。公式の説明では、Salesforce や HubSpot と、Slack や Microsoft Teams をつなぎ、商談の更新、手順の自動化、承認、会議の準備を、営業が普段使っているチャットの中で済ませられるようにしています。製品は、更新・自動化・承認・商談ごとの共有の場などをまとめた中核の機能群と、商談のリスクや売上の動向を知らせる Rattle Agents に分かれています。

AIが入るのは主に通話のあとです。公式の製品ページでは、通話の文字起こしを読み取り、Salesforce や HubSpot に入れる更新案をまとめて示し、担当者が Slack や Teams の上でワンクリックで承認する流れを説明しています。会議の記録は、Gong や Zoom などの録音の道具から取り込みます。CRMのデータを見張るエージェントは、空いている項目や古い項目を見つけて担当者に確認や修正を促し、難しい更新については、CRMに反映する前に承認を求めることがあると書かれています。

裏を返せば、すべての更新に承認が挟まるとは公式に書かれていない、ということです。どの更新が承認なしで入り、どれが確認待ちになるのかは、契約前に設定の画面と合わせて確かめる必要があります。公式の製品ページは「人が承認したデータ」を強調していますが、承認の仕組みがあることと、どの項目に承認が効いているかは別の話です。この記事で扱うのは、この確認付きの書き込みを社内でどう運用するかです。

2025年12月の Von と、Rattle の今の位置づけ

2025年12月23日、Rattle の公式ブログは、同じチームが作った新しい製品 Von の提供開始を発表しました。Von は営業部門のためのAIのデータ分析役と位置づけられ、CRM、通話の録音、メール、予定表、Snowflake のようなデータ基盤につないで、普通の文章で質問すると1〜2分ほどで答えを返すとしています。公式の説明では、文章を生成するだけではなく、裏側で問い合わせの命令を実行し、予測の分析や勝ち負けの傾向の抽出まで行う仕組みだとしています。

CRMへの書き込みについては、通話の記録、商談の項目の更新、レコードの作成、複数の対象にまたがる一括の変更を頼めるとしたうえで、変更の前に必ず確認を求め、Salesforce の権限と入力規則を守ると明記しています。発表の時点で対応するCRMは Salesforce だけでした。その後も Von の公式ブログは更新が続き、2026年10月26日には、担当者ごとの予測の数字を推薦し、提出を確かめる予測のエージェントについての解説を公開しています。

Rattle との関係について、発表は「Von は Rattle を置き換えない」としています。一方で、現在の Rattle の公式サイトは、既存の顧客への Rattle の提供は続けるとしつつ、Von の案内を前面に出しています。新規で Rattle を契約できるのか、今後の開発の重心がどちらにあるのかは、営業窓口で確かめてから判断するのが安全です。

• 価格、新規契約の条件、日本語の通話への対応は、公開情報では確かめられなかった。見積もりの段階で書面で確かめる
• Von の対応CRMは発表時点で Salesforce のみ。現在の公式サイトは HubSpot も接続先に挙げているため、使う機能ごとに対応状況を確かめる

誤解：「確認ボタンがあれば、CRMは崩れない」

Rattle も Von も、AIの書き込みに人の確認を挟む作りを強調しています。そのため、確認の仕組みがあること自体が安全の根拠のように扱われがちです。しかし確認は、押す人が中身を読み、正しいかどうかを判断できて初めて効きます。通話のたびに数件の更新案が届き、その多くが正しいと、人は次第に読まずに押すようになります。

もう一つの見落としは、確認する人が正しく判断しても、項目の意味がずれていれば数字は崩れることです。たとえば「商談の段階」を、営業は相手の温度感で、マーケは決まった条件で読んでいれば、同じ更新を見ても正しいと感じる基準が違います。確認が防げるのは、AIの読み違いの一部だけです。

本当に必要なのは、確認の画面で何を見せるか、どんな更新なら確認を飛ばしてよいか、誰の名前で書き込まれるか、そして項目の定義を誰が持つかを、導入の前に決めることです。以下では、確認付きの書き込みが崩れていく典型を四つのシナリオで見たうえで、それぞれの対策を整理します。

AIがCRMに書き込む経路は、三つに分けて考える

Rattle と Von を合わせると、AIがCRMの中身を変える経路は少なくとも三つあります。経路ごとに、誰が起点になり、どこで確認が入るのかが違います。導入の検討では、まずこの三つを分けて棚卸しします。

経路	起点	確認の入り方（公式の説明）	崩れやすい点
通話のあとの更新案（Rattle）	通話の終了	更新案を Slack や Teams に送り、担当者がワンクリックで承認	件数が多く、読まずに押される
CRMの項目の穴埋め（Rattle Agents）	エージェントの点検	空欄や古い項目の確認を促す。難しい更新は反映前に承認	承認なしで入る更新の範囲が見えにくい
依頼・一括変更・予測（Von）	人の依頼、または予測の提出	変更の前に必ず確認。予測と一緒の更新は同意したものだけ反映	一度の確認で多数の商談が動く

表で分かるとおり、確認が「ある」点ではどの経路も同じです。違うのは、一度の確認で動く件数と、確認する人が全体を見渡せるかどうかです。通話のあとの更新案は一度の件数が少ない代わりに頻度が高く、Von の一括変更は頻度が低い代わりに一度の影響が大きい。運用の決めごとは、この違いに合わせて分けて作ります。

誰の権限で書くか：依頼した本人の権限と、つないだ人の権限

Rattle の安全性のページでは、レコードと項目へのアクセスは利用企業の権限設定に従い、それを迂回しないと説明しています。認可には OAuth 2.0 を使い、SAML による SSO や、役割ごとに最小限の権限を割り当てる設定にも対応するとしています。Von も、書き込みは Salesforce の権限と入力規則に従うと公表しています。

ここで確かめたいのは、書き込みが誰の名義で記録されるかです。Von の公式サイトは、管理者が一度つなげば組織全体ですぐ使えることを利点に挙げています。便利な反面、接続に使った利用者の権限で書き込むのか、依頼した本人の権限で書き込むのかによって、項目の変更履歴に残る名前と、触れられる商談の範囲が変わります。この点は公開情報だけでは確かめきれなかったため、試行の段階で、変更履歴に誰の名前が残るかを実際に見て確かめてください。

権限の設計は、Salesforce 側で連携用の利用者を分け、AIからの書き込みだけを後から抽出できるようにしておくのが基本です。AIの書き込みと人の手入力が履歴の上で見分けられないと、崩れたときに戻す範囲を決められません。CRMの入口を外のAIに開くときの権限の一般論は別の記事で扱っているので、ここでは「履歴で見分けられること」を導入の条件として押さえておきます。

シナリオ1：通話のあとの更新案を、まとめて承認してしまう

最も起きやすいのは、通話のあとに届く更新案を、中身を読まずに承認するシナリオです。Rattle の製品ページでは、通話の内容をまとめて読む時間が60分から2〜3分になったという利用者の声を紹介しています。時間が縮むのは利点ですが、裏返せば、2〜3分で確かめきれない誤りは、そのまま通るということです。

崩れ方は静かです。相手が「来期に検討したい」と言ったのを、文字起こしが「来月」と読み違える。決裁者の名前が、同席した別の人に入れ替わる。どれも一件ずつ見れば小さな誤りですが、完了予定日や決裁者の項目は、予測や優先順位の計算にそのまま使われるため、積み重なると見込みの数字が実態から離れていきます。しかも、誤った値には本人の承認の記録が付いているので、後から誰も疑いません。

対策は、確認の画面に出す情報を変えることです。更新案だけを出すのではなく、根拠となった発言の一節と、今の値と新しい値を並べて見せる。日付と金額と決裁者のように、間違えたときの影響が大きい項目は、承認の前に発言の該当箇所を開かないと押せない運用にする。こうした設定が製品の中でどこまでできるかは、試行で確かめ、できない部分は手順書と事後の点検で補います。

シナリオ2：「難しい更新だけ確認する」線を、誰も引いていない

先に見たとおり、Rattle のCRMのデータを見張るエージェントは、難しい更新について反映前に承認を求めることがあると説明されています。言い換えると、難しくないと判断された更新は承認なしで入りうるということです。この「難しい」の線を製品の既定のまま使うと、どの項目がAIの判断だけで書き換わっているのかを、社内で誰も説明できない状態になります。

線は項目ごとに人が引きます。考え方は単純で、間違えたときに、誰かの判断や数字が変わる項目は必ず確認する。たとえば、通話をしたという事実の記録や、次回の打ち合わせの日程の記録は、確認なしで入れてよい候補です。一方、商談の段階、金額、完了予定日、失注の理由、競合の名前は、確認を挟む側に置きます。

線を引いたら、表にして営業企画が持ち、半期ごとに見直します。確認なしで入れた項目についても、月に一度、無作為に数件を抜き出して、通話の記録と突き合わせることで、AIの読み違いの傾向を確かめます。確認を外してよいのは、誤りの少なさが記録で示せた項目だけです。感覚で「もう大丈夫だろう」と外すと、線はすぐに曖昧に戻ります。

シナリオ3：一括変更の依頼が、他人の商談まで動かす

Von は、複数の対象にまたがる一括の変更を頼めると公表しています。たとえば「同じ段階に長くとどまっている商談の完了予定日を見直して」と頼めば、条件に合う商談がまとめて更新の候補になります。確認は求められますが、数十件の変更が一度に並ぶと、一件ずつ読む人はまずいません。

ここで崩れるのは、範囲です。依頼した人が自分の担当の商談のつもりで頼んでも、条件の書き方によっては他の担当者の商談まで対象に入ります。Salesforce の権限で触れない商談は守られますが、マネージャーや営業企画のように広い権限を持つ人が頼むと、その範囲はそのまま広がります。権限が広い人ほど、一括変更の影響も広がることを、運用の前提にしておきます。

対策は、一括変更を誰が頼めるかを絞ることと、件数の上限を決めることです。たとえば、一度に変えてよいのは20件まで、他人の商談を含む変更は担当者への通知を先に送る、項目の値を消す変更は営業企画の承認を通す、といった決めごとです。件数と対象の担当者の一覧を、確認の画面の先頭に出させることも有効です。一覧を見て初めて、依頼した本人が範囲の広さに気づくことは珍しくありません。

シナリオ4：予測の数字と一緒に、完了予定日と段階が動く

2026年10月26日に Von が公開した予測のエージェントの解説によると、エージェントは担当者ごと、予測の区分ごとに推薦の数字を出し、その数字に合わせて、完了予定日や段階といった Salesforce の更新案も用意します。担当者が推薦に同意して提出すると、同意した更新が提出と一緒に反映され、承認するまでは何も書き込まれないと説明されています。

仕組みとしては丁寧ですが、ここには別の種類の危うさがあります。予測の数字に合意することと、個々の商談の項目を書き換えることが、一つの操作にまとまっているからです。担当者は「今週の見込みはこれでよい」と考えて提出しただけでも、その裏で複数の商談の完了予定日が、推薦に合わせて動くことになります。数字を合わせるために項目が動き、動いた項目がまた次の予測の材料になる、という循環も起きえます。

運用では、予測の提出と商談の更新を、画面の上でも頭の中でも分けて扱うことを勧めます。提出の前に、一緒に反映される更新の一覧を必ず開く。完了予定日を前に倒す変更は、通話や相手のメールの根拠が添えられているものだけに同意する。予測の数字を経営の報告にどう使うかは別の記事で扱っているので、ここでは「数字の合意と項目の変更を一度に押さない」ことだけを決まりにしておきます。

確認を形だけにしない設計：見せる順番と、押せない条件

ここまでの四つのシナリオから、確認の設計で決めることは五つに絞れます。製品の設定でできることと、社内の決まりで補うことの両方を含めて、導入の前に順番に決めていきます。

大事なのは、確認の回数を増やすことではなく、一回の確認で判断に要る材料がそろっていることです。通話のたびに十件の確認を求めれば、すぐに形だけになります。確認する項目を減らし、その代わり一件の重みを上げるほうが、結果としてCRMは崩れにくくなります。逆に、次のような運用は確認を形だけにします。

• すべての更新案に確認を求め、件数で担当者を疲れさせる
• 根拠の一節を出さず、新しい値だけを見せて承認させる
• 承認した件数や速さを、営業の評価の指標にする
• 一括変更の確認を、対象の一覧を開かずに押せるようにしている

予測の根拠の見せ方：定義、根拠の商談、前回からの差

Von の予測のエージェントは、各区分にどの商談を入れるかを、チームが普通の文章で書いた定義に従って判断すると説明しています。解説の例では、確度の高い区分の定義として「段階3以降、予算の確認済み、相手からの口頭の約束、期間内の完了予定日」といった書き方が挙げられています。推薦の数字は、この定義、Salesforce の商談の情報、通話のメモやメールの兆候から作られます。

ここから分かるのは、予測の根拠は三つの層に分けて見せられるということです。一つ目は、どの定義で区分したか。二つ目は、その区分に入った商談の一覧。三つ目は、前回の提出から何が変わったか。Von は提出の履歴を書き手のメモと合わせて保存し、なぜ数字が変わったかを後から追えるようにしているとしています。会議では、AIの推薦の数字だけでなく、この三つを並べて見る習慣を作ります。

AIに根拠を書かせることは、AIに判断させないこととセットです。推薦の数字と担当者の数字が離れているとき、どちらが正しいかをAIに決めさせるのではなく、差の理由を担当者に一行で書かせ、マネージャーが読む。Von も、推薦は出発点であり、最終的な判断は担当者のものだと説明しています。推薦との差を、担当者の能力の評価に使わないことも決めておかないと、担当者は差を出さないように推薦をそのまま受け入れるようになり、根拠の層は形だけになります。

マーケと営業で「商談」の定義がずれる問題

Von の公式ブログは2026年10月21日、同じ質問をしても社内の人によってAIの答えが違う理由を解説しています。挙げられた例では、四半期の受注率を三人が尋ね、それぞれ37.5%、30%、15%という答えを得ました。受注の数を、決着した商談の数で割ったのか、条件を満たした商談の数で割ったのか、作られたすべての商談の数で割ったのかが違っていただけで、計算はどれも正しかったとしています。

BtoBのマーケと営業の間では、同じずれが日常的に起きています。マーケは、引き渡した見込み客が商談になった割合を、商談が作られた時点で数えます。営業は、一定の段階を越えたものだけを商談と呼びます。AIがCRMを読んで分析し、そのうえ項目を書き換えるようになると、どちらの定義で書き込まれたのかが、記録の上から見えなくなる点が問題です。マーケの報告とAIの分析が食い違ったとき、どちらの数字が間違っているのかを誰も説明できなくなります。

特に影響を受けやすいのは、商談化の判定、商談の発生元、失注の理由の三つです。商談の発生元はマーケの施策の評価に直結しますが、通話の内容からAIが推定して書き込むと、展示会で名刺を交換した相手が「紹介」に分類されるような読み違いが起きえます。こうした項目は、AIが書く対象から外すか、マーケ側の確認を必ず通す項目として扱うのが安全です。

定義をそろえる場所は、AIの中ではなく人が持つ文書

Von は、2026年6月に公開した設計の解説で、組織ごとの業務の定義を持つ層を作り、どの項目が年間の契約額か、会計年度がいつ始まるか、どの段階からを有望とするかといった決まりを、問い合わせを作る前に読むと説明しています。さらに、利用者の修正を記憶し、組織・チーム・個人の単位で蓄積するとしています。仕組みとしては、定義のずれを減らす方向です。

ただし、定義をAIの中にだけ置くと、別の問題が起きます。誰かがAIに教えた修正が、組織の定義として広がるのか、本人だけの記憶にとどまるのかが見えにくいからです。Von のブログ自身も、プロンプトの共有や個人の工夫では、チーム全体で同じ答えは保証されないと書いています。だからこそ、定義の原本は、マーケと営業が合意した社内の文書に置き、AIの設定はその写しとして扱うのが安全です。

進め方としては、受注率、有望な商談、商談の発生元、失注の理由、会計年度の五つから始めます。それぞれに、言葉の意味、計算の式、例外、持ち主を書き、マーケと営業の責任者がそろって承認します。AIの中の定義を書き換えてよいのは、この文書を変えたあとだけ、と決めます。AIが教わった修正は、月に一度一覧にして持ち主が採否を決める運用にすれば、定義が静かに変わることを防げます。

データの行き先と費用、止め方・やめ方

Rattle の安全性のページによると、顧客のデータは米国の AWS のオレゴン地域に置かれ、保存時も通信時も暗号化されるとしています。Von は、通話の録音、メール、予定表、文書の保管場所などを読み込み、2026年6月の設計の解説では、基盤のモデルとして Anthropic の Claude と OpenAI のモデルを使うと説明しています。通話やメールの中身が、海外の事業者と、その先のモデル提供者を通る前提で、社内の規程と顧客との契約に照らして確認します。Von は第三者の監査による SOC2 と ISO 27001 の取得を公表しています。

費用は公開されていません。Von は無料の試行を用意し、価格は問い合わせとしています。費用の増え方は、つなぐ利用者の人数や取り込むデータの種類で変わると考えられるため、見積もりでは、営業だけで使う場合と、マーケやカスタマーサクセスまで広げた場合の両方を出してもらうと、広げたときの増え方が読めます。

止め方は、経路ごとに用意します。通話のあとの更新案は、連携の接続を外せば止まります。エージェントの穴埋めは、対象の項目を設定から外します。Von の一括変更は、依頼できる人を絞ることで実質的に止められます。やめるときは、AIが書き込んだ値を変更履歴から抜き出せるかが鍵になるため、導入の初日から、AIの書き込みを抽出できる形で記録しておくことが、きれいにやめるための条件です。

よくある質問

Rattle と Von は、どちらを入れればよいですか。

Slack や Teams の中で商談の更新や承認を回したいなら Rattle、CRMや通話のデータを横断して分析し、必要な更新を頼みたいなら Von、というのが公式の説明から読める役割の違いです。ただし Von の発表時点の対応CRMは Salesforce だけでした。新規で Rattle を契約できるかどうかも含め、営業窓口で確かめてください。

日本語の通話でも、更新案は正しく作られますか。

日本語の文字起こしや更新案の精度について、公式の説明では確かめられませんでした。録音の道具の文字起こしに頼る部分もあるため、試行では日本語の通話を数十件流し、日付・金額・人名の読み違いの率を数えてから判断します。

承認した更新が間違っていたら、責任は誰にありますか。

道具の仕組みからは決まりません。社内で、承認した人、確認の項目を決めた営業企画、定義を持つ責任者の役割を分けて書いておくことが先です。承認した人だけに責任を寄せると、確認の画面や項目の設計の誤りが見えなくなります。

通話の内容をAIが読むことを、相手に伝える必要はありますか。

録音と文字起こしの扱いは、すでに使っている録音の道具の運用に従うのが基本です。AIが内容を読んでCRMに書き込むことで利用の目的が広がる場合は、社内の規程と顧客への説明を見直します。法的な判断が要る場合は、専門家に確かめてください。

まとめ

Rattle と、同じチームの Von は、AIが通話やメールを読み、確認を取ってからCRMを書き換える仕組みを持っています。確認の仕組みがあることは出発点にすぎず、CRMが崩れるかどうかは、何を見せて押させるか、どの項目を確認なしで通すか、誰の名義で書くか、どの定義で書くかで決まります。確認する項目を絞って一件の重みを上げ、根拠を並べて見せ、予測の合意と項目の変更を分けて扱い、商談の定義はマーケと営業が合意した文書に置く。この順番で決めておけば、AIに判断を渡さないまま、入力の手間だけを減らすことができます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。