SoR→SoC→SoAの具体例：記録、文脈、次の行動をつなぐ設計
最近、CRMとAIの使い方について話すときに、私は SoR → SoC → SoA という順番で考えることが増えています。
SoRは System of Record です。顧客、案件、問い合わせ、請求、活動履歴など、信頼できる事実を残す場所です。
SoCは System of Context です。フォーム、チャット、メール、会議メモ、ファイル、過去の対応履歴をつなぎ、「いま何が起きているのか」を整理する層です。
SoAは System of Action です。整理された文脈から、次に取るべき行動を提案し、必要なら人の承認を挟んで、タスク作成、通知、下書き作成、CRM更新などへ進める層です。
要点: AI活用の本質は、CRMを捨てることではありません。信頼できる記録を残し、その上に文脈整理と承認済みアクションの仕組みを重ねることです。
具体例：問い合わせ対応をCRM/AIで動かす
たとえば、Webフォームから問い合わせが入る業務を考えます。
従来の流れでは、担当者がフォーム通知を見て、CRMを開き、過去の対応履歴を探し、返信内容を考え、必要なら社内に確認します。
この流れ自体は珍しくありません。ただ、問題は 次の行動が担当者の記憶と余裕に依存しやすい ことです。
これをSoR→SoC→SoAで分けると、次のようになります。
| 層 | 役割 | 問い合わせ対応での例 |
|---|---|---|
| SoR | 信頼できる事実を残す | 顧客情報、過去の問い合わせ、担当者、契約状態 |
| SoC | 状況を整理する | 今回の問い合わせ内容、過去の経緯、未確認項目、重要度 |
| SoA | 次の行動へつなぐ | 返信下書き、確認タスク、担当者通知、CRM更新案 |
ここで大事なのは、AIをいきなり「実行者」にしないことです。
最初は、AIを 確認者の補助 として使います。
- 問い合わせ内容を要約する
- 不足している情報を見つける
- 過去履歴との関係を整理する
- 担当者が確認すべき点を並べる
- 返信文の下書きを作る
- CRMに残すべき項目を提案する
人は、その提案を見て承認、修正、却下します。
この形なら、AIに業務を丸投げするのではなく、判断の前段を整える仕組みとして導入できます。
SoCがないと、AIは一般論を返す
AIに「この問い合わせへ返信してください」と頼むだけなら、きれいな文章は作れます。
しかし、それだけでは実務には足りません。
必要なのは、その問い合わせがどの顧客から来ているのか、以前どんな対応をしたのか、未対応のタスクが残っているのか、請求や契約の状態に注意が必要なのか、といった文脈です。
この文脈がないままAIを使うと、返答は丁寧でも、業務としては危ないことがあります。
だから、SoRの上にSoCを作る必要があります。
SoCは、AIが読むためだけの層ではありません。人が確認するための整理画面でもあります。
「今回の問い合わせは、どの顧客の、どの履歴と関係があり、何が足りず、次に何を決める必要があるのか」
ここまで見えるようになると、担当者の判断はかなり楽になります。
SoAは承認後に動かす
文脈が整理できたら、次は行動です。
ただし、SoAも最初から完全自動化しません。
業務アクションにはリスクがあります。
| アクション | リスク | 初期の扱い |
|---|---|---|
| 社内タスクを作る | 低 | 自動化しやすい |
| 社内通知を出す | 低〜中 | 条件付きで自動化 |
| CRM項目を更新する | 中 | まずは承認制 |
| 顧客へ返信する | 高 | 人の確認を必須にする |
| 契約や請求を変更する | 高 | 人が主導する |
AIができることが増えても、すべてを自動実行にする必要はありません。
現実的には、まず次の順番で進めます。
- AIが要約と不足項目を出す
- AIが次の行動候補を出す
- 担当者が承認または修正する
- システムがタスク、通知、下書き、CRM更新を実行する
- 実行結果を記録へ戻す
この順番なら、現場は「勝手に何かされる」不安を持ちにくくなります。
Action Ledgerを残す
SoAを作るなら、Action Ledgerが必要です。
Action Ledgerは、システムが何を提案し、人がどう判断し、実際に何が実行されたかを残す履歴です。
たとえば、次のような情報を残します。
- 元になった問い合わせ
- 参照したCRMレコード
- AIが整理した文脈
- 提案されたアクション
- 承認者
- 修正内容
- 実行結果
- 次に改善すべき点
これがあると、AI活用を「雰囲気」ではなく、運用改善として扱えます。
どの提案は役に立ったのか。どの提案は不要だったのか。どの条件なら自動化してよいのか。
この判断ができるようになります。
最初に作るなら、小さなレビューキュー
最初の実装としておすすめなのは、大きなAIエージェントではなく、小さなレビューキューです。
問い合わせ、フォーム送信、会議メモ、ファイルアップロードなど、業務上意味のあるイベントが入ったら、AIが整理した内容をレビューキューに置きます。
担当者は、そこを見て処理します。
- これは対応不要
- これは担当者へ通知
- これは返信下書きを使う
- これはCRMへ追記
- これは追加確認が必要
こうした判断がたまると、あとで自動化しやすい低リスク領域が見えてきます。
実装イメージ：Form 2.0からレビューキューへ渡す
実際に構築するなら、CRMそのものを置き換えるのではなく、Form 2.0などの入力面から入ってきた情報を、Zoho CRM内のレビューキューへ渡す 形が現実的です。
CRMはSoRとして顧客、商談、問い合わせ、活動履歴を持ち続けます。その周辺に、フォーム送信、写真、メール、チャット、会議メモ、ファイル追加、Webhookなどのイベントを受け取る薄いバックエンドを置きます。
そのバックエンドでは、送信元の検証、重複排除、CRMレコードとの照合、文脈の整理、AIによる要約と次アクション案の作成を行います。作成された候補はすぐに実行せず、CRM内のWebTab、関連リスト、カスタムボタンなどのウィジェットに表示します。
上の画像は、Form 2.0相当の入力、写真、CRM照合、AI判断、作成候補をZoho CRM内のレビュー面にまとめたデモ画面です。入力内容をそのまま自動実行するのではなく、人が確認できる候補として出すのがポイントです。
最小構成では、次の順番で作ります。
- 入力を受け取る: Form 2.0、Webフォーム、写真、ファイル、Webhookを受け付ける。
- CRMの記録と照合する: 顧客、物件、商談、問い合わせ、過去メモ、担当者を検索する。
- 文脈を組み立てる: 何が起きたか、不足情報は何か、リスクはどこか、誰が見るべきかを整理する。
- レビュー面に出す: Zoho CRM Widgetで、原典、照合結果、判断材料、作成候補を表示する。
- 人が承認する: 担当者が承認、修正、却下、保留を選べるようにする。
- 承認後に実行する: タスク作成、メモ追加、項目更新、通知、返信下書き作成を行う。
- Action Ledgerに残す: 何を提案し、誰がどう判断し、何が実行されたかを記録する。
参考に見るなら、まずはZoho公式の Widgets in Zoho CRM、Working with Widgets、Create Your First Widget、ZDK CLIのWidgets が入口になります。
まとめ
SoR→SoC→SoAは、CRMをAIに置き換える話ではありません。
CRMを信頼できる記録として残し、その周辺に文脈整理と行動支援を重ねる設計です。
最初にやることは、AIに全部任せることではありません。
記録を整え、文脈を集め、AIに整理させ、人が確認し、承認後に実行する。
この小さな順番を作るだけで、CRMは「記録を見る場所」から「次の行動を安定して起こす場所」へ変わっていきます。
著者: 泉田幸太郎 最終更新: 2026年6月6日
