AIに文脈を作らせるCRMレコード設計: SoRからSoC、SoAへ進むための最小構造

CRMに顧客名、商談名、活動メモが入っているだけでは、AIは安定した業務文脈を作れません。

AIが「次に何をするべきか」を提案するには、CRMの中に 何が起きたのか、いまどんな状態なのか、何を根拠にそう判断したのか、誰が確認すべきなのか が分かる形で残っている必要があります。

これは、CRMをAIに置き換える話ではありません。

むしろ逆です。CRMを信頼できる System of Record として残し、その上に System of Context と System of Action を重ねるために、レコードの持ち方を見直す話です。

以前の記事では、SoRからSoAへ進む考え方と、記録、文脈、承認済みアクションをつなぐ具体例を書きました。

今回は、もう少し手前の問いに絞ります。

AIが信頼できる文脈と、人が承認できる行動案を作るために、CRMレコードは何を持っていれば十分なのか。

「AI-ready enough」とは、全部を持つことではない

AI対応というと、すべての会話、ログ、ファイル、メール、画面操作をCRMへ集めたくなるかもしれません。

しかし、実務ではそれは危険です。ノイズが増え、個人情報や不要な詳細も増え、担当者が確認できない巨大な記録になります。

必要なのは、すべてを集めることではありません。

必要なのは、判断と次アクションに使える最小限の構造 です。

この構造があれば、AIは一般論ではなく、そのレコードに紐づいた業務文脈を作りやすくなります。

最小構造: 8つの要素

AIにとって扱いやすいCRMレコードは、自由記述メモだけでできていません。

少なくとも、次の8つを分けて持つと、文脈整理と承認フローが安定します。

この8つは、CRMの標準項目、カスタム項目、関連リスト、承認プロセス、ワークフロー、公式API、通常のWebアプリケーションで実装できます。

大事なのは、AIの出力をそのままCRMの事実に混ぜないことです。

事実、推定、提案、承認済み結果を分けます。

Event: メモではなく「業務上意味のある出来事」として持つ

CRMの活動履歴には、たくさんのメモが残ります。

ただ、AIが文脈を作る時には、単なるメモよりも「イベント」として扱える記録が有効です。

たとえば次のようなものです。

• 顧客から新しい問い合わせが入った
• 会議メモが追加された
• 添付ファイルがアップロードされた
• 契約状態が変わった
• 支払い失敗が発生した
• 担当者がフォローアップを完了した

イベントには、最低限、発生時刻、発生元、関連する顧客や案件、イベント種別を持たせます。

これだけで、AIは「最近何が起きたか」を時系列で組み立てやすくなります。

State: 現在地を自由記述に埋めない

AI提案がずれやすい原因の一つは、状態がメモの中に埋もれていることです。

「先方確認待ちです」「一旦保留」「たぶん来週対応」などが自由記述だけに残っていると、人間は読めても、システムは安定して処理できません。

状態は、できるだけ選択肢として持たせます。

例:

• New
• Needs review
• Waiting for customer
• Waiting for internal owner
• Ready for approval
• Approved
• Rejected
• Executed

状態が明確になると、AIは次アクションを提案する前に「いま提案してよい段階か」を判断できます。

Source / Evidence: AIの説明を検証できるようにする

AIが「この顧客には返信が必要です」と言った時、担当者が知りたいのは理由です。

その理由を検証するために、レコードには証跡が必要です。

証跡は、必ずしも全文をCRMへコピーすることではありません。むしろ、必要以上にコピーしない方がよい場合もあります。

現実的には、次のように持ちます。

• 原文または要約
• 参照元システム
• 取得時刻
• 添付ファイルや会議メモへの参照
• どの項目を根拠に判断したか

証跡があると、AIの提案は「それっぽい文章」ではなく、確認可能な業務判断になります。

Confidence: 自動化してよいものと、確認すべきものを分ける

AIや自動照合の結果には、確からしさの差があります。

顧客IDで完全一致したものと、名前やメールの一部から推定したものを同じ扱いにすると、誤更新が起きやすくなります。

そこで、レコードには信頼度を持たせます。

例:

• High: IDや一意キーで一致
• Medium: 複数条件でおそらく一致
• Low: 候補はあるが確認が必要
• Unknown: 判断材料が不足

信頼度は、AIの文章に書くだけでは不十分です。承認フローや通知条件に使える項目として持つのが実務的です。

Owner: 誰が判断するかをAIに推測させない

AIが行動案を出しても、誰が見るべきかが曖昧だと止まります。

CRMレコードには、担当者、承認者、確認すべきチームを明確に持たせます。

ここで大事なのは、「未割当」も状態として扱うことです。

未割当は単なる空欄ではありません。次アクションが止まる原因です。

AIは、担当者が明確ならその人向けの確認事項を出せます。未割当なら、まず割当候補や割当ルールの確認を提案できます。

Next-action candidate: 実行ではなく候補として出す

AIの価値は、次の行動を見えやすくすることです。

ただし、最初から実行まで任せる必要はありません。

CRMには、AIが作った行動案を「候補」として持たせます。

例:

• 顧客への返信下書き
• 担当者への確認タスク
• CRMメモの追記案
• ステージ変更案
• 不足情報の確認依頼

候補には、理由、リスク、参照した証跡を添えます。

これにより、担当者はゼロから考えるのではなく、確認、修正、承認に集中できます。

Approval status: SoAを安全にする中心項目

System of Actionに進む時、最も重要なのは承認状態です。

AIが提案しただけなのか、人が承認したのか、修正して承認したのか、却下したのか。

ここが分かれていないと、あとから「なぜこの通知が出たのか」「誰がこの更新を許可したのか」が追えません。

最初の設計では、少なくとも次の状態を持たせます。

• Proposed
• Needs more information
• Approved
• Edited and approved
• Rejected
• Executed

この承認状態があるから、CRMは単なるSoRから、SoAへ安全に進めます。

Audit trail: AI活用を改善できる形で残す

最後に必要なのが監査ログです。

Action Ledgerと言ってもよいです。

記録するのは、AIが何を提案したかだけではありません。

• 何を根拠に提案したか
• 誰が確認したか
• どこを修正したか
• 何を却下したか
• 承認後に何が実行されたか
• 実行結果がどうだったか

これが残ると、AI活用は「一回きりの便利機能」ではなく、運用改善になります。

どの提案は役に立ったのか。どの提案は不要だったのか。どの種類なら自動化してよいのか。

この判断材料がたまります。

最初の実装は、小さなレビューキューでよい

最初からCRM全体を作り直す必要はありません。

おすすめは、重要な業務イベントだけを対象にした小さなレビューキューです。

1. フォーム、メール、会議メモ、ファイル追加などのイベントを受ける
2. 関連するCRMレコードに紐づける
3. AIが文脈と行動候補を作る
4. 証跡、信頼度、担当者、リスクを一画面に出す
5. 人が承認、修正、却下、保留を選ぶ
6. 承認後だけ、タスク作成やCRM更新を実行する
7. 結果をAction Ledgerに戻す

この流れなら、公式API、CRM標準機能、ワークフロー、承認プロセス、通常のWebアプリケーションを組み合わせて段階的に作れます。

AIにすべてを任せる前に、人が確認できる構造を作る。

それが、現実的なAI-ready CRMの第一歩です。

まとめ

AIにとって使いやすいCRMとは、項目が多いCRMではありません。

事実、状態、証跡、信頼度、担当者、行動候補、承認状態、監査ログが分かれているCRM です。

この構造があると、CRMは記録を残すだけのSoRから、文脈を作るSoC、そして人が承認できるSoAへ進みやすくなります。

まず見るべき問いはシンプルです。

• このレコードで、何が起きたか分かるか
• 現在の状態が選択肢として分かるか
• AIの判断根拠を人が確認できるか
• 誰が承認するか分かるか
• 提案と実行結果があとから追えるか

この5つに答えられるだけで、AI活用の土台はかなり安定します。

CRM/AIのレコード設計や、人が承認できる業務フローの作り方を整理したい場合は、お問い合わせページからご相談ください。

---

著者: 泉田幸太郎
最終更新: 2026年6月9日