CRMにAIを入れるとき、最初に決めたいのは「AIに何をさせるか」だけではありません。
その前に、どのCRMレコードならAIに渡してよいかを決める必要があります。
顧客、商談、問い合わせ、活動履歴、添付ファイル、Web行動。CRMには多くの記録があります。しかし、記録が存在することと、AIがその記録から信頼できる文脈を作れることは別です。
以前の記事では、AIに文脈を作らせるためのCRMレコード最小構造、Context Snapshotレコード、Action Candidateレコードを整理しました。
今回は、その前段に置く判定ルールです。
Record Readiness Gate。つまり、CRMレコードがAIに使わせてよい状態かを判定する入口です。
AI-ready enoughは「全部そろっている」ではない
AI-readyなCRMというと、項目を増やし、データを細かく集める話に見えます。
しかし実務では、すべての情報がそろうことはあまりありません。
- 問い合わせは来たが、会社名が曖昧
- 商談ステージは更新されたが、理由がメモに埋もれている
- 会議メモはあるが、次に誰が判断するか決まっていない
- Webの反応はあるが、記事別や流入元別の根拠が薄い
- AIが要約したが、どの情報を根拠にしたか確認しにくい
この状態でAIに「次の一手」を作らせると、文章は自然でも、承認者は不安になります。
AI-ready enoughとは、完全なデータを持つことではありません。
AIが文脈を作ってよい範囲と、人が確認すべき範囲が分かれていることです。
Record Readiness Gateとは何か
Record Readiness Gateは、AI処理の前に置く確認ポイントです。
CRMの元レコードを見て、次のどれに進めるかを判定します。
| 判定 | 意味 | 次の扱い |
|---|---|---|
| Not ready | 根拠や担当者が足りない | 追加情報の確認へ戻す |
| Context only | 文脈化はできるが、行動案は早い | Context Snapshotを作る |
| Ready for proposal | 人が確認できる根拠がある | Action Candidateを作る |
| Ready for low-risk workflow | 低リスクな社内処理に限り進められる | 承認ルール付きで実行候補へ進める |
このゲートがないと、CRMはSoRからいきなりSoAへ飛びます。
記録はある。AIが要約する。次アクション案が出る。承認者は、どの前提でその提案になったのかを追う。
この流れは使いにくいです。
SoRからSoC、SoAへ進めるには、元レコードが文脈化に耐える状態かを先に見る必要があります。
判定に使う8つの観点
Record Readiness Gateでは、少なくとも次の8つを見ます。
| 観点 | 見ること | 足りないと起きること |
|---|---|---|
| Event | 何が起きたか | AIが古い履歴や別件を混ぜる |
| State | 現在どこにいるか | 提案してよい段階か分からない |
| Source / Evidence | 何を根拠にしたか | 承認者が検証できない |
| Confidence | どの程度確からしいか | 弱い根拠を強く扱ってしまう |
| Owner | 誰が確認するか | 提案が宙に浮く |
| Next-action candidate | 次に作りうる候補 | いきなり実行内容まで飛ぶ |
| Approval status | 人の確認状態 | 未確認の文脈から行動案が作られる |
| Audit trail | 変更と判断の履歴 | 後から改善できない |
これは新しい大規模システムでなくても始められます。
CRMの標準項目、カスタム項目、関連リスト、承認プロセス、ワークフロー、公式API、通常のWebアプリケーションを組み合わせれば、まずは1つの業務イベントだけで設計できます。
Event: 何が起きたかを固定する
AIが文脈を作る前に、出発点を固定します。
フォーム送信なのか。会議メモの追加なのか。ファイルの追加なのか。Web記事から問い合わせ導線へ進んだ行動なのか。
イベントが曖昧だと、AIは複数の履歴を一つの話としてまとめてしまいます。
Record Readiness Gateでは、少なくとも次を確認します。
- イベント種別
- 発生時刻
- 発生元
- 関連する顧客、商談、問い合わせ
- 取得方法
取得方法は、公式API、標準Webhook、フォーム送信、CRMの標準履歴など、説明できる方法に限定します。
イベントが固定されると、Context SnapshotやAction Candidateの前提が追いやすくなります。
State: 現在地を自由記述に埋めない
AIにとって使いにくいCRMの典型は、状態がメモにだけ書かれていることです。
「追加確認中」「返信待ち」「承認待ち」「提案準備完了」といった状態は、選択肢として持つ方が扱いやすいです。
例:
- New
- Needs evidence
- Needs owner
- Needs more information
- Ready for context
- Ready for proposal
- Proposal created
- Archived
状態が明確なら、AIは「提案を作る」以外の次アクションも扱えます。
たとえば、担当者が未定なら、顧客への返信案ではなく、担当者割当の確認タスクが先かもしれません。
Source / Evidence: 要約の裏側を見えるようにする
AIの要約は便利ですが、要約だけでは承認できません。
承認者が見たいのは、何を見てその文脈になったのかです。
証跡は、すべての原文をCRMへコピーすることではありません。個人情報や不要な詳細を広げないために、参照元、取得時刻、対象項目、要約、添付リンクだけで十分な場合もあります。
重要なのは、次の問いに答えられることです。
- どのイベントを見たのか
- どのCRM項目を見たのか
- どのメモ、添付、履歴を参照したのか
- どこまでが事実で、どこからが推定か
- どの情報が不足しているか
これが見えれば、AIの出力は「それらしい文章」から「確認できる業務情報」へ変わります。
Confidence: 弱い根拠を弱いまま扱う
CRM/AIで危ないのは、少ない根拠を強く見せてしまうことです。
たとえば、アクセス分析でセッションが少ない週があります。URL別、流入元別、キャンペーン別の内訳がまだ見えないこともあります。
このときAIに「この施策は成功か失敗か」と言わせるのは早すぎます。
Record Readiness Gateでは、信頼度を項目として持ちます。
| Confidence | 意味 | 扱い |
|---|---|---|
| High | 一意キーや明確な履歴で確認できる | 提案へ進めやすい |
| Medium | 複数条件でおそらく合っている | 人の確認を挟む |
| Low | 候補はあるが曖昧 | 追加情報を集める |
| Unknown | 判断材料が不足 | 行動案を作らない |
AI-readyなCRMは、AIに強く断定させるCRMではありません。
根拠の強さと弱さを分けて、人が判断できる状態にするCRMです。
Owner: 誰が確認するかをAIに推測させない
AIが文脈を作っても、誰が確認するかが分からないと止まります。
担当者、確認者、承認者、未割当状態は、CRM項目として持つ方が安全です。
未割当は空欄ではなく、業務上の状態として扱います。
未割当なら、次の候補は「顧客に送る文章」ではなく「担当者を決める」かもしれません。
この区別があるだけで、AIの提案はかなり現実に近づきます。
Next-action candidate: 実行ではなく候補として置く
AIに次アクションを作らせる場合、最初から実行させる必要はありません。
まずは候補として置きます。
例:
- 担当者への確認タスク
- 顧客への返信下書き
- 不足情報の確認依頼
- CRM項目の更新案
- 社内レビュー依頼
Record Readiness Gateでは、「どの種類の候補なら作ってよいか」を判定します。
詳細な送信文面、更新payload、通知先は、Action Candidateレコード側で扱います。
Approval status: 文脈と行動案の承認を分ける
人の承認は、行動案だけに必要なのではありません。
その前の文脈にも確認状態が必要です。
おすすめは、文脈側と行動案側を分けることです。
| 層 | 確認すること | 例 |
|---|---|---|
| Context approval | この文脈を提案に使ってよいか | Draft、Needs evidence、Ready for proposal |
| Action approval | この行動案を実行してよいか | Pending review、Approved、Rejected、Executed |
この分離がないと、文脈が未確認のまま、行動案だけが承認待ちに進みます。
承認者は、提案そのものだけでなく、提案の前提も確認できるべきです。
Audit trail: 何を改善すべきか分かるように残す
AI提案が外れたとき、原因は一つとは限りません。
- 元レコードのイベントが曖昧だった
- 状態が古かった
- 証跡が足りなかった
- 信頼度の扱いが甘かった
- 担当者が違った
- 行動案の作り方が悪かった
監査ログがなければ、どこを直すべきか分かりません。
Record Readiness Gateでは、作成時刻、参照元、判定結果、不足情報、人の修正、次に作られたContext SnapshotやAction Candidateへのリンクを残します。
これにより、AIの精度改善を「プロンプトを直す」だけに閉じず、CRMの記録設計として改善できます。
最初の実装パターン
最初から全CRMにゲートを作る必要はありません。
おすすめは、1つのイベントから始めることです。
- フォーム送信、会議メモ追加、ファイル追加など、対象イベントを1つ選ぶ
- 関連するCRMレコードへ紐づける
- Event、State、Evidence、Confidence、Ownerを確認する
- 不足があればNot readyにする
- 文脈化できるならContext Snapshotを作る
- 提案へ進めるならAction Candidateを作る
- 人の確認、修正、実行結果を監査ログへ戻す
この流れなら、AIを業務の外側に置いたままではなく、CRMの中で人が確認できる形にできます。
まとめ
AI-readyなCRMレコードとは、AIが何でも自動で動かせるレコードではありません。
AIが、信頼できる文脈を作ってよいかを判定でき、人が承認できる行動候補へ進めるレコードです。
Record Readiness Gateで見る問いは、次の8つです。
- 何が起きたか分かるか
- 現在状態が明確か
- 根拠を人が確認できるか
- 信頼度を項目として扱えるか
- 誰が確認するか決まっているか
- 次アクションは候補として分けられているか
- 文脈と行動案の承認状態が分かれているか
- 判断と変更の履歴が残るか
この8つに答えられるCRMは、SoRの記録をSoCの文脈へ変え、SoAの人が承認できる行動案へつなげやすくなります。
CRM/AIのレコード設計や、人が確認できる業務フローを整理したい場合は、お問い合わせページからご相談ください。
