AI電話とCRMの連携は「顧客情報を会話へ表示する」ことではありません。着信を既存顧客・見込み客・不明に分け、必要な範囲だけを参照し、会話で取得した情報を構造化してCaseと担当Taskへ渡す仕組みです。読み上げと更新を無制限にすると、便利さより誤照合・過剰権限のリスクが大きくなります。
電話から担当者までのData Flowを先に描く
この順序を飛ばして「CRM連携」とすると、会話ログ、メモ、タスク、顧客マスタのどれを正本にするかが曖昧になります。受付で必要な情報、担当者が必要な情報、保存しない情報を分けます。
Caller IDは照合の入口であって本人確認ではない
| 状況 | AIがしてよいこと | 追加確認または人へ渡すこと |
|---|---|---|
| 番号が1件の顧客に一致 | 用件を聞き、一般的な案内をする | 契約・個人情報の開示 |
| 複数顧客に一致 | 候補を画面側で提示する | 電話上で候補名を読む |
| 番号が未登録 | 新規受付として必要項目を聞く | 既存顧客と断定する |
| 重要な変更依頼 | 本人確認手順を案内 | 住所・支払・権限の変更 |
Read / Write Permission Matrix：会話に必要な最小権限を作る
| 操作 | AI Toolの権限 | 監査で残すもの |
|---|---|---|
| 顧客候補検索 | 限定フィールドのRead | 検索条件・結果数 |
| 受付履歴の参照 | 直近Caseの要約のみ | 参照したCase ID |
| Case作成 | 新規CaseのCreate | 入力値・時刻・発信元 |
| Case更新 | 状態・要約など限定Update | 変更前後・実行者 |
| 担当Task | 期限付きCreate | 担当・期限・失敗理由 |
Salesforceは用途に応じたAPIを案内しており、API専用の統合ユーザーを用意して権限と追跡可能性を分ける方法を示しています。HubSpot、kintone、Zohoでも同じく、個人の管理者アカウントをAI連携に流用せず、連携単位の認証と監査を設計します。
Handoff Data Packetは「会話全文」ではなく、次に動くための要約
| フィールド | 例 | 目的 |
|---|---|---|
| 用件分類 | 見積相談・予約変更 | 担当振り分け |
| 確認済み項目 | 希望日・対象サービス | 聞き直し削減 |
| 未確認項目 | 住所表記・本人確認待ち | 次の質問を明確化 |
| 緊急度 | 至急・通常・要人確認 | SLA判断 |
| 会話要約 | 短い事実ベースの要約 | 担当者の把握 |
生の録音・全文転記を誰でも閲覧できる状態にせず、必要な担当だけが必要な粒度で見られるようにします。AI電話のセキュリティ設計も参照し、保存期間・閲覧権限・マスキングを決めます。
失敗・再試行ではIdempotencyを必ず持つ
API応答が途切れた時、AIが同じ注文・Case・Taskを二重に作らないよう、通話IDや受付IDを冪等キーとして保存します。作成成功だが応答だけ失敗した場合、再試行は検索して既存結果を返します。折り返し・再入電のCase Continuityとつなげると、同じ顧客が再度電話した時も担当が状況を追えます。
導入は代表電話の一部用件から検証する
最初からCRMの全オブジェクトを連携せず、代表電話の一次受付、Case作成、担当Taskの三つから始めます。代表電話のAI化で用件の振り分けを定義し、例外は人間へ転送します。CRM製品ごとのAPI利用可否・プラン・認証要件は変更されるため、実装前に公式ドキュメントと自社の契約条件で確認してください。
3つのCRM連携Flow：同じ着信でも作るものは違う
| ケース | 照合と参照 | 作成・更新 | 人へ渡す条件 |
|---|---|---|---|
| 新規Lead | 番号は候補扱い。既存重複を検索 | Leadまたは問い合わせCaseをCreate。流入元・用件を記録 | 重要顧客の重複、本人確認が必要な情報 |
| 既存顧客 | 電話番号＋必要時の追加確認。直近CaseのみRead | 既存Caseへ時刻・要約・希望をUpdate、必要ならTaskをCreate | 契約変更、個人情報の開示、権限外操作 |
| 再入電Case | 通話ID又はCase IDで前回の未完了案件をRead | 同じ案件に試行結果・次の期限をUpdate | 照合不能、期限超過、担当不在 |
CRM上の顧客レコードを会話にすべて出すのではなく、次の担当者が動くために必要なデータだけをHandoff packetへ残します。
Read / Write / Create / Updateを会話から分離する
| 操作 | 許可例 | 禁止または追加確認 | 監査記録 |
|---|---|---|---|
| Read | 直近の未完了Case・担当・期限 | 住所・支払・契約詳細を無条件に読む | 検索条件・参照したID |
| Create | 新規問い合わせ、折返しTask | 顧客マスタを会話だけで新規確定 | 通話ID・入力値・作成ID |
| Update | Caseの要約、折返し結果、状態 | 契約・権限・請求先の変更 | 変更前後・実行時刻 |
| Write action | 承認済みの限定操作 | 取消不能な処理、金銭・権限操作 | 冪等キー・承認者 |
SalesforceはアプリごとのIntegration User、OAuth client credentials、最小権限のPermission Setを推奨しています。HubSpotやkintoneでも、個人の管理者アカウントを共有せず、連携単位で権限と監査の境界を作る考え方は同じです。
429・5xx・Timeout・CRM停止時のFallback
| 状態 | 通話中の挙動 | バックエンド処理 | 顧客への約束 |
|---|---|---|---|
| 429 Rate limit | 同じ検索を連打しない | 指数バックオフし、再試行回数を限定 | 確認でき次第、折り返す |
| 5xx | 既知情報を推測しない | 可観測な失敗としてQueueへ保存 | 現在は確認できないと明示 |
| Timeout | Create成功を仮定しない | 通話IDの冪等キーで作成済みか照会 | 重複受付を避ける |
| CRM停止 | 必要項目をローカルの暗号化Queueへ最小保存 | 復旧後に順序付きで同期、失敗は人のキューへ | 受付は記録し、担当から連絡する |
HubSpotは制限超過時に429を返すと明記しています。kintoneも同時接続数や日次上限を定め、REST API操作を監査ログに記録します。失敗を会話の失敗にせず、受付と確定を分離します。
一次資料を確認する実装前チェック
API仕様、許可Scope、契約プラン、制限値は変更されるため、実装・本番切替時点で必ず一次資料を再確認します。
3つの具体CRM Flow
Case 1：新規Lead
電話 → Caller ID候補検索 → 該当なし → 用件・連絡先・希望をAIが構造化 → Lead Create → 担当Task → 担当通知、の順です。既存顧客か判断できない時は、顧客マスタを新規作成せず重複確認キューへ渡します。
Case 2：既存顧客
電話 → 候補顧客検索 → 本人確認 → 必要範囲だけCRM Read → 受付 → 既存Case Update又は新規Case → 担当者、の順です。契約状態や直近CaseはReadできても、金額・解約・重要個人情報の変更はHigh-risk Writeとして人の承認を必須にします。
Case 3：折り返し・再入電
電話 → 既存Case候補 → 本人確認 → Case復元 → Callback Status → 担当者Handoff、の順です。前回の失敗理由と次の期限を返し、同じ説明を最初から要求しません。
CRM障害時の専用Fallback Flow
Temporary Caseには通話ID、用件、連絡先、取得時刻、同期状態だけを保存します。復旧後はIdempotency Keyで重複を照合し、失敗を隠して成功扱いにしません。
関連論点を自社の受付へ落とし込む
AI電話受付の仕組み、代表電話のAI化、人間への転送設計、折り返しループ対策、AI電話のセキュリティも併せて確認し、入口の会話だけでなく、記録、例外、担当者への引継ぎまで一つの流れとして整理してください。
よくある質問
発信者番号だけでCRMの顧客を特定してよいですか？
番号は候補照合に使えても、本人確認の代わりにはなりません。共用電話・番号変更・家族の電話を前提に、重要情報を読む前の確認を設計します。
AIにCRMの全顧客データを渡すべきですか？
不要です。目的ごとのToolを通じて必要な項目だけを読取り、書込み権限も操作単位で分離します。