CRMにAIを入れるとき、いきなり「次に何をさせるか」から考えると危険です。
その前に必要なのは、AIが見ている文脈を人が確認できる形にすることです。
顧客の最新状態、直近イベント、証跡、不足情報、担当者、信頼度。これらが曖昧なままAIに次アクションを作らせると、文章はそれらしくても、実務では承認しにくい提案になります。
以前の記事では、AIに文脈を作らせるCRMレコード設計と、AIの次アクション案をAction Candidateレコードとして扱う設計を書きました。
今回は、その間に置くべきレコードについて整理します。
AIが提案を作る前に、CRM上で「いまの文脈」を固定するContext Snapshotレコードです。
最新状態だけでは、AIの文脈にならない
多くのCRMには、現在のステージ、最終活動日、担当者、メモ、添付ファイル、問い合わせ履歴があります。
しかし、それらが存在していても、AIにとって文脈が明確とは限りません。
たとえば、次のような状態です。
- 直近イベントはあるが、どの顧客や案件に紐づくかが曖昧
- ステージは更新されているが、なぜその状態になったかが追えない
- メモはあるが、判断に使った証跡が分からない
- 担当者はいるが、承認者や確認すべき人が別にいる
- AIの要約はあるが、どの情報が不足しているかが分からない
この状態でAIに「次の一手」を出させると、提案の前提を人が検証しにくくなります。
だから、提案の前にContext Snapshotを作ります。
Context SnapshotはSoCの作業レコード
Context Snapshotは、CRMの事実レコードを置き換えるものではありません。
顧客、商談、問い合わせ、活動履歴などのSoRを参照しながら、AIと人が確認できる「現在の業務文脈」を一時点でまとめるレコードです。
| 層 | 役割 | 主なレコード |
|---|---|---|
| SoR | 事実を残す | 顧客、商談、問い合わせ、活動、添付、実行履歴 |
| SoC | 事実から文脈を作る | Context Snapshot |
| SoA | 承認された行動へ進める | Action Candidate、タスク、通知、更新 |
ここで大事なのは、文脈を自由記述の要約だけにしないことです。
AIが作った要約は便利ですが、それだけでは承認者が判断できません。Context Snapshotには、要約と一緒に、イベント、状態、証跡、信頼度、担当者、候補アクション、承認状態、監査ログを分けて持たせます。
持たせたい項目
Context Snapshotは、大きな新システムでなくても作れます。CRMのカスタムモジュール、関連リスト、承認プロセス、ワークフロー、公式API、通常のWebアプリケーションを組み合わせれば十分です。
最小構造は次のようなものです。
| 項目 | 目的 | 例 |
|---|---|---|
| Trigger event | 何をきっかけに文脈を作ったか | フォーム送信、会議メモ追加、ファイル追加、Web行動 |
| Related record | どの顧客、商談、問い合わせに紐づくか | 顧客ID、商談ID、問い合わせID |
| Current state | いまの状態 | 未確認、確認中、要追加情報、提案準備完了 |
| Source / Evidence | 人が確認できる根拠 | フォーム値、活動履歴、メモ、添付、公式API取得結果 |
| Context summary | AIまたはルールが整理した文脈 | 「追加情報が不足している」「返信待ち」 |
| Confidence | 文脈の確からしさ | 高、中、低、要確認 |
| Owner / Reviewer | 誰が確認するか | 担当者、承認者、運用チーム |
| Missing information | 何が足りないか | 金額、期限、意思決定者、同意確認 |
| Next-action candidate seed | 次に作れそうな候補 | 確認タスク、返信下書き、CRM更新案 |
| Context approval status | 文脈を提案に使ってよいか | Draft、Needs evidence、Ready for proposal、Archived |
| Audit trail | 何が変更されたか | 作成時刻、参照元、確認者、修正差分 |
この形にすると、AIの提案はブラックボックスから出てくる文章ではなくなります。
まず文脈を確認し、その文脈をもとにAction Candidateを作る。承認者は、提案内容だけでなく、提案の前提も見られます。
Event: 提案の前に、文脈の出発点を固定する
AIが文脈を作るとき、最初に必要なのは「何が起きたか」です。
問い合わせが入ったのか。会議メモが追加されたのか。ファイルがアップロードされたのか。Webサイトで特定の記事から問い合わせ導線に進んだのか。
イベントが固定されていないと、AIは複数の履歴を混ぜてしまいます。
Context Snapshotには、発生時刻、イベント種別、発生元、関連レコード、取得経路を残します。取得経路は、公式API、標準Webhook、フォーム送信、CRMの標準履歴など、正規の方法に限定します。
これだけで、後から「なぜこの文脈が作られたのか」を説明できます。
State: 現在地を選択肢として持つ
文脈の中で特に重要なのは状態です。
「確認中」「返信待ち」「追加情報不足」「承認待ち」といった状態が自由記述だけに埋もれると、AIは次に進んでよいか判断しにくくなります。
Context Snapshotでは、現在状態を選択肢として持たせます。
例:
- New context
- Needs evidence
- Needs owner
- Needs more information
- Ready for proposal
- Proposal created
- Archived
状態が明確なら、AIは「まだ提案すべきでない」「まず担当者を割り当てるべき」「提案を作ってよい」といった分岐を扱いやすくなります。
Source / Evidence: 要約の裏側を見えるようにする
AIの要約が正しいかどうかは、要約だけを読んでも分かりません。
人が確認するためには、何を見てその文脈にしたのかが必要です。
証跡は、すべての原文をCRMにコピーすることではありません。個人情報や不要な詳細を広げないために、要約、参照リンク、取得時刻、参照した項目名だけで十分な場合もあります。
大事なのは、承認者が次の問いに答えられることです。
- どのイベントを見たのか
- どのCRM項目を見たのか
- どのメモやファイルを参照したのか
- どの情報は不足しているのか
- どこから先は推定なのか
この境界があると、AIの文脈は「それっぽい説明」ではなく、検証可能な業務情報になります。
Confidence: 文脈の確からしさを項目にする
Context Snapshotには、文脈の信頼度を持たせます。
顧客IDで完全一致した文脈と、名前やメールの一部から推定した文脈は、同じ扱いにしません。
例:
| Confidence | 意味 | 次の扱い |
|---|---|---|
| High | 一意キーや明確な履歴で確認できる | 低リスク提案へ進めやすい |
| Medium | 複数条件でおそらく一致 | 人の確認を挟んで提案へ進める |
| Low | 候補はあるが曖昧 | まず証跡や担当者を確認する |
| Unknown | 判断材料が不足 | Action Candidateを作らない |
信頼度は、AIの文章ではなくCRM項目として持つのが実務的です。通知条件、承認条件、レビュー優先度に使えるからです。
Owner: 文脈の責任者を明確にする
AIが文脈を作っても、誰が確認するかが決まっていないと止まります。
Context Snapshotには、担当者、確認者、承認者、未割当状態を持たせます。
未割当は空欄ではなく、業務上の状態です。
未割当なら、AIが次に作るべき候補は「顧客への返信」ではなく、「担当者の割当確認」かもしれません。
この違いをCRMが持っていると、AI提案のずれを減らせます。
Next-action candidate seed: 実行内容ではなく、候補の種だけを置く
Context Snapshotは、まだ実行案そのものではありません。
ただし、次にどんなAction Candidateを作れそうかは持っておくと便利です。
例:
- 担当者への確認タスク
- 顧客への返信下書き
- 不足情報の確認依頼
- CRM項目の更新案
- 社内レビュー依頼
この段階では、詳細な実行payloadや送信文面まで確定しなくてよいです。
Context Snapshotでは「この文脈なら、次にこの種類の候補を作れそう」と示すだけにします。実際の承認対象は、次のAction Candidateレコードで扱います。
Approval status: 文脈を提案に使ってよいかを判断する
Action Candidateには承認状態が必要です。
同じように、Context Snapshotにも確認状態が必要です。
おすすめの最小ステータスは次の通りです。
| Status | 意味 |
|---|---|
| Draft | 自動生成された直後 |
| Needs evidence | 根拠が不足している |
| Needs owner | 確認者が未確定 |
| Ready for proposal | この文脈をもとに提案を作ってよい |
| Proposal created | Action Candidateへ進んだ |
| Archived | 使わない、または古くなった |
この状態がないと、AIは古い文脈や未確認の文脈から提案を作ってしまいます。
Audit trail: 文脈も更新履歴を残す
AI提案の監査ログは重要です。
しかし、その前提となる文脈にも監査ログが必要です。
- いつContext Snapshotが作られたか
- どのイベントとレコードを参照したか
- AIが何を要約したか
- 人がどこを修正したか
- 信頼度や状態がどう変わったか
- どのAction Candidateへ進んだか
これが残ると、あとから「提案が悪かったのか」「文脈の作り方が悪かったのか」「証跡が足りなかったのか」を分けて改善できます。
小さい母数でも、記録設計は役に立つ
マーケティングや営業のデータは、いつも十分な量があるとは限りません。
記事を公開しても、直近のセッションが少ない週があります。UTMや記事別の反応がまだ見えないこともあります。
このとき、AIに「この施策は成功か失敗か」と判断させるのは危険です。
むしろ必要なのは、少ない事実を少ないまま扱うことです。
- 事実: セッション数が少ない
- 文脈: まだ成果判断できる母数ではない
- 信頼度: 低い
- 次アクション候補: 再配信、観測期間延長、別チャネル比較
- 承認状態: 人が判断する
Context Snapshotは、このように「分からないことを分からないまま残す」ためにも役立ちます。
AI-readyなCRMとは、AIに強い断定をさせるCRMではありません。
AIが、根拠の強さと弱さを分けて、人が確認できる文脈を作れるCRMです。
最初の実装パターン
最初から全レコードにContext Snapshotを作る必要はありません。
おすすめは、1つの重要イベントだけに絞ることです。
- フォーム送信、会議メモ追加、ファイル追加などのイベントを受ける
- 関連するCRMレコードへ紐づける
- AIまたはルールでContext Snapshotを作る
- イベント、状態、証跡、信頼度、担当者、不足情報を一画面に出す
- 人がReady for proposalかNeeds evidenceを選ぶ
- ReadyになったものだけAction Candidateへ進める
- 結果と修正内容を監査ログへ戻す
この流れなら、CRMの標準項目、カスタムモジュール、承認プロセス、ワークフロー、公式API、通常のWebアプリケーションを組み合わせて段階的に始められます。
まとめ
AI-readyなCRMレコードとは、AIが何でも自動実行できるレコードではありません。
AIが、確認可能な文脈を作り、人が承認できる提案へ進めるレコードです。
そのためには、Action Candidateの前にContext Snapshotを置くと設計しやすくなります。
見るべき問いは、次の5つです。
- どのイベントから文脈が作られたか分かるか
- 現在状態と不足情報が選択肢として分かるか
- AIの要約の根拠を人が確認できるか
- 文脈の信頼度と確認者が明確か
- その文脈からどの提案へ進んだか追えるか
この5つに答えられるCRMは、SoRの記録をSoCの文脈へ変え、SoAの承認済みアクションへつなげやすくなります。
CRM/AIのContext Snapshot設計や、人が承認できる業務フローを整理したい場合は、お問い合わせページからご相談ください。
著者: 泉田幸太郎
最終更新: 2026年6月22日
