AIをCRMに組み込むとき、最初に考えるべきことは「AIに何を実行させるか」ではありません。
その前に、AIが作った次アクション案を、CRM上でどう安全に扱うか を決める必要があります。
顧客への返信案、担当者への確認タスク、CRM項目の更新案、フォローアップの提案。こうした出力を、そのまま実行してしまうと危険です。一方で、ただの文章としてチャット画面に残すだけでは、業務は前に進みません。
そこで必要になるのが、AIの提案を Action Candidateレコード として扱う設計です。
以前の記事では、AIに文脈を作らせるCRMレコード設計として、イベント、状態、証跡、信頼度、担当者、承認状態、監査ログを分ける考え方を書きました。
今回はその次の問いです。
AIが「次にこれをやるべきです」と提案したとき、その提案をCRMのどこに置き、誰が確認し、何を根拠に承認するのか。
AI出力は、事実ではなく候補として扱う
CRMの中には、性質の違う情報が混ざりやすいです。
| 種類 | 例 | 扱い方 |
|---|---|---|
| 事実 | 顧客がフォームを送信した、商談ステージが変わった | System of Recordに残す |
| 文脈 | 返信待ち、確認が必要、情報が不足している | System of Contextで整理する |
| 提案 | 返信下書きを作る、担当者に確認する、項目更新を提案する | Action Candidateとして分ける |
| 決定 | 承認、修正して承認、却下、保留 | 承認履歴として残す |
| 実行結果 | タスク作成、通知送信、CRM更新、返信作成 | Action Ledgerへ戻す |
ここで大事なのは、AIの文章をそのままCRMの事実欄に入れないことです。
AIの出力は、まだ業務上の決定ではありません。人が確認できる候補です。
この境界があると、CRMは記録を持つ System of Record から、文脈を整理する System of Context、そして承認された行動へ進む System of Action に変わりやすくなります。
Action Candidateレコードに持たせたい項目
Action Candidateは、大きな新システムでなくても作れます。CRMのカスタムモジュール、関連リスト、承認プロセス、タスク、通常のWebアプリケーションを組み合わせれば始められます。
最小構造は次のようなものです。
| 項目 | 目的 | 例 |
|---|---|---|
| Trigger event | 何をきっかけに候補が作られたか | フォーム送信、会議メモ追加、ファイル追加 |
| Related record | どの顧客、商談、問い合わせに紐づくか | 顧客ID、商談ID、問い合わせID |
| Context summary | AIが整理した現在の文脈 | 「追加情報が不足している」 |
| Source / Evidence | 人が確認できる根拠 | フォーム値、メモ、添付、公式API取得結果 |
| Confidence | 提案の確からしさ | 高、中、低、要確認 |
| Risk tier | 実行した場合の影響 | 低リスク、要承認、高リスク |
| Owner / Approver | 誰が見るべきか | 担当者、上長、運用チーム |
| Proposed action | 提案された次アクション | タスク作成、返信下書き、項目更新案 |
| Approval status | 人の判断状態 | 提案済み、修正待ち、承認、却下、保留 |
| Execution result | 承認後に何が起きたか | タスクID、通知ID、更新履歴 |
| Audit trail | 誰が、いつ、なぜ判断したか | 承認者、時刻、修正差分、却下理由 |
この形にしておくと、AIの提案は「それっぽい助言」ではなく、確認、差し戻し、承認、実行、振り返りができる業務オブジェクトになります。
Trigger event: 提案の出発点を残す
Action Candidateは、何かの出来事から生まれます。
たとえば、問い合わせフォームが送信された、会議メモが追加された、Webサイトで特定記事から問い合わせ導線に進んだ、ファイルがアップロードされた、などです。
提案だけが残っていて、きっかけが追えないと、後から検証できません。
「なぜこのタスクが作られたのか」「なぜこの顧客に返信が必要と判断したのか」を説明するために、Trigger eventは明示しておきます。
ここで使う情報は、公式API、標準Webhook、フォーム送信、CRMの標準履歴など、正規の取得経路に限定するのが安全です。
Source / Evidence: 承認者が見られる根拠を付ける
AI提案の品質は、承認者が根拠を見られるかどうかで大きく変わります。
「返信してください」とだけ出ている提案は確認しにくいです。
一方で、次のように根拠が分かれていれば判断できます。
- どのフォーム項目を見たか
- どの会議メモを要約したか
- どのCRM項目が空欄だったか
- どの直近イベントを参照したか
- どの情報は不足しているか
証跡は、全文コピーである必要はありません。個人情報や不要な原文を広げないために、要約と参照リンクで十分な場合もあります。
大事なのは、承認者が「この提案は何を見て作られたのか」を追えることです。
ConfidenceとRisk tierを分ける
AI提案では、信頼度とリスクを混ぜないほうがよいです。
たとえば、顧客IDが完全一致していて信頼度が高い場合でも、顧客へ外部送信する返信はリスクが高い行動です。
逆に、信頼度が低くても、社内向けの確認タスクを作るだけなら影響は小さい場合があります。
| 観点 | 見ているもの | 例 |
|---|---|---|
| Confidence | 判断材料の確からしさ | ID一致、複数条件一致、推定、材料不足 |
| Risk tier | 実行した時の影響 | 社内メモ、担当者タスク、顧客連絡、金額変更 |
この2つを分けると、自動化の境界を決めやすくなります。
低リスクで信頼度が高い候補は、承認を軽くできます。高リスクの候補は、信頼度が高くても人の明示承認を通します。
Approval status: SoAの中心は承認状態
System of Actionというと、実行ばかりに目が行きます。
しかし、実務上の中心は承認状態です。
おすすめの最小ステータスは次のようなものです。
| Status | 意味 |
|---|---|
| Proposed | AIまたはルールが候補を作った |
| Needs evidence | 根拠が足りず、追加確認が必要 |
| Needs owner | 承認者や担当者が未確定 |
| Edited | 人が内容を修正した |
| Approved | 実行してよいと判断された |
| Rejected | 実行しないと判断された |
| Executed | 承認後の処理が完了した |
| Failed / Rework | 実行に失敗し、再確認が必要 |
この状態があると、AI提案は「誰かが見たか分からない文章」ではなく、業務フロー上の待ち行列になります。
Proposed actionは、実行内容と説明を分ける
提案レコードには、実行内容だけでなく、説明も分けて持たせます。
例:
- Action type:
Create task - Target: 対象の顧客または商談
- Draft payload: 作成するタスクの件名、期限、担当者
- Reason: なぜこのタスクが必要か
- Evidence links: 根拠となるフォーム、メモ、履歴
- Human note: 承認者が修正した理由
この分離がないと、あとから「AIの提案が悪かったのか」「人が修正したのか」「実行時の連携で失敗したのか」が分かりません。
Execution resultを戻して、学習材料にする
承認後に処理が実行されたら、結果をAction Candidateへ戻します。
タスクを作ったならタスクID、通知を送ったなら通知ID、CRM項目を更新したなら更新前後の差分を残します。
そして、できれば結果も後で見ます。
- 承認されたが、後で差し戻された
- 承認されたが、実行に失敗した
- 却下が多い提案タイプだった
- 人が毎回同じ修正をしている
- 低リスクなので次回から承認を軽くできそう
この振り返りがあると、AI活用は単発のプロンプトではなく、運用として育てられます。
最初に作るなら、1種類の候補だけでよい
Action Candidate設計は、最初から全業務へ広げなくてよいです。
最初は1種類に絞ります。
例:
- 問い合わせが入ったら、AIが要約と不足情報を作る
- 担当者への確認タスク案を作る
- 根拠、信頼度、リスク、担当者を一画面に出す
- 人が承認、修正、却下、保留を選ぶ
- 承認後だけCRMタスクを作る
- 結果と人の判断をAction Ledgerへ戻す
これだけでも、CRMは「記録を探す場所」から「次の判断を支える場所」へ近づきます。
まとめ
AI-readyなCRMとは、AIが直接業務を動かすCRMではありません。
AIが作った次アクション案を、根拠付きで人が承認できるCRM です。
そのためには、Action Candidateレコードとして、Trigger event、Related record、Context summary、Source / Evidence、Confidence、Risk tier、Owner、Proposed action、Approval status、Execution result、Audit trailを分けて持つことが重要です。
この構造があると、SoRにある事実をSoCで文脈化し、SoAで人が承認できる行動へつなげられます。
まず問い直すべきことは、次の5つです。
- AIの提案が、どの事実とイベントから生まれたか分かるか
- 承認者が根拠を確認できるか
- 信頼度とリスクを分けて扱っているか
- 承認、修正、却下、実行の状態が追えるか
- 実行結果が次の設計に戻っているか
CRM/AIの承認フローやAction Candidate設計を整理したい場合は、お問い合わせページからご相談ください。
著者: 泉田幸太郎
最終更新: 2026年6月16日
