構築・検証した仕組み
SaaS（インターネット経由で利用するソフトウェアサービス）では、既存顧客の解約（チャーン）が売上に直接影響します。利用頻度の低下やNPS（顧客がサービスを他者に勧める意向を示す指標）の悪化など、解約の兆候はSalesforceに記録されています。この記録から解約リスクを点数で判定し、判定理由とリテンション施策（顧客の継続利用を促す取り組み）の文章を生成AIに書かせ、担当者へのToDo（対応すべき作業）作成までを自動化しました。Salesforce Sandbox（本番とは別の検証環境）で構築・検証しています。
解約の申し出を受けてからでは、不満の聞き取りや改善提案に使える時間が限られます。
兆候そのものはSalesforceに残っています。利用回数の落ち込み、NPSの悪化、未解決のサポートケースの増加。ただ、数百件の取引先についてこれらを毎週人手で確認するには時間がかかります。
そこで、取引先のデータが更新されたらフローが起動し、解約リスクの点数を付け、生成AIが判定理由とリテンション施策を日本語で書き、担当者にToDoを配るところまでをSandboxで作りました。Prompt BuilderとFlow Builderが中心で、Apexは呼び出し用の1クラスだけです。
作りながら分かったのは、点数の計算を生成AIに任せると数字を間違えることでした。最終的に、点数はフローの加点ルール、文章は生成AIという分担に落ち着いています。
今回作るもの — 全体の流れ
- 取引先の利用回数やNPSが更新される
- レコードトリガフロー（データの作成・更新をきっかけに自動実行する処理）が非同期パス（レコード保存の確定後に別処理として走る経路）で起動し、加点ルールで解約リスクスコアとリスクレベルを算出する
- 算出した点数と検知した解約の兆候をプロンプトテンプレートへ渡し、生成AIが判定理由とリテンション施策を日本語で書く
- 点数、リスクレベル、生成された文章を取引先に書き戻す
- リスクが高・中なら、取引先所有者にフォローアップToDoを作成する
1回判定するとAI処理済フラグが立ち、同じ取引先は再び判定されません。翌月のデータで評価し直すには、スケジュールフローなどでフラグを戻す処理が別に要ります。今回はそこまで作っていません。
点数はルール、文章は生成AI
最初は点数の計算も生成AIに任せました。ところが「NPS 15は負の値」「合計85点」といった誤りが出ます。加点表を渡しても、足し算そのものを間違えます。そこで点数とリスクレベルはフローの加点ルールで確定させ、生成AIには確定した判定を渡して、理由と打ち手の文章だけを書かせる形にしました。誤差が出せない数値は計算式、言葉にする部分は生成AI、という分担です。
自動処理を担うのは、レコードトリガフローとプロンプトテンプレートです。あわせて作るAgentforceエージェント「解約リスクアナリスト」は、担当者がチャットで個別の取引先について相談するための窓口で、自動処理の経路とは別に動きます。
Step 1 — Agentforceエージェントの作成
このエージェントが担当する範囲
ここで作るエージェントは、担当者がチャットで「この取引先の状況はどうか」と聞くための窓口です。取引先の更新をきっかけに自動で走る処理は、Step 4以降のプロンプトテンプレートとフローが担当します。エージェントを作っただけでは自動化されません。自動処理だけが必要なら、このStepは飛ばせます。
エージェントの新規作成
Agentforce Studioを開き、「New Agent」ボタンから新しいエージェントを作成します。
| 設定項目 | 値 |
|---|---|
| エージェント名 | 解約リスクアナリスト |
| API参照名 | Churn_Risk_Analyst |
| 種別 | AgentforceEmployeeAgent（社内向け） |
| 説明 | 取引先の利用回数、NPS、サポート満足度、未解決ケース数を読み、保存されている解約リスクの点数と判定理由を日本語で答えます。 |
エージェントの詳細設定
エージェントの詳細画面で、ロールと会社情報を設定します。
ロール設定（点数は計算させない）
「あなたは、顧客担当者から取引先の状況を聞かれたときに答える役割です。取引先の月間利用回数、前月との差、NPS、サポート満足度、未解決ケース数、最終ログイン日、契約更新日を読み、すでに保存されている解約リスクの点数と判定をそのまま伝えます。点数は計算し直しません。次に何をするかを聞かれたら、誰がいつまでに何をするかを日本語で答えます。」
会社情報
「はてなベース株式会社は、法人向けにクラウドサービスを提供しています。顧客担当者は、各社の利用状況と問い合わせの履歴を見て、契約の継続に必要な支援を行います。」
トピック「解約予兆分析」の設定
エージェントにトピックを追加し、プロンプトで分析ロジックを指示します。
| 設定項目 | 値 |
|---|---|
| トピック名 | 解約予兆分析 |
| 分類の説明 | Account（取引先）の利用状況・満足度データから解約リスクを分析する |
| スコープ | Account（取引先）データの解約リスク分析 |
トピックの指示文に入れる内容
- 分析対象データ — 月間利用回数と前月比、NPSスコア（-100〜100）、サポート満足度、未解決ケース数、最終ログイン日からの経過日数、契約更新日までの残日数
- 判定基準 — 利用量が前月比50%超で落ちた場合と、NPSが0未満の場合を重く見る。30日を超える未ログイン、未解決ケース4件以上も加点対象。いずれも今回の記事で決めた独自の基準で、NPSの一般的な区分とは別物
- 出力形式 — 0〜100のリスクスコアをHigh/Medium/Lowに分類し、リテンション施策を日本語で提案
設定が終わったら、エージェントビルダーの会話プレビューで動作を確かめます。「アルファ商事の解約リスクはどうなっていますか」と聞くと、トピック「解約予兆分析」が選ばれ、その取引先の利用回数と満足度が返ります。
Step 2 — Accountカスタムフィールドの準備
入力用フィールド（解約シグナルデータ）
Accountオブジェクトにカスタムフィールドを追加します。オブジェクトマネージャーのAccount設定から「項目とリレーション」→「新規」で追加できます。
| フィールド名 | API名 | 型 | 補足 |
|---|---|---|---|
| 月間利用回数 | Monthly_Usage_Count__c | 数値(10,0) | 当月のサービス利用回数 |
| 前月利用回数 | Previous_Month_Usage__c | 数値(10,0) | 比較用の前月データ |
| 最終ログイン日 | Last_Login_Date__c | 日付 | 最後にサービスにログインした日 |
| サポート満足度 | Support_Satisfaction__c | 選択リスト | 非常に満足/満足/普通/不満/非常に不満 |
| NPSスコア | NPS_Score__c | 数値(3,0) | -100〜100 |
| 未解決ケース数 | Open_Case_Count__c | 数値(10,0) | 未解決のサポートケース数 |
| 契約更新日 | Contract_Renewal_Date__c | 日付 | 次回の契約更新予定日 |
出力用フィールド（AI分析結果）
AIエージェントの分析結果を格納するフィールドも用意します。
| フィールド名 | API名 | 型 | 補足 |
|---|---|---|---|
| 解約リスクスコア | Churn_Risk_Score__c | 数値(3,0) | 加点の合計。今回のルールでは最大95点 |
| リスクレベル | Churn_Risk_Level__c | 選択リスト | 高/中/低（60点以上=高、30-59=中、30未満=低） |
| リテンション施策 | Retention_Action__c | ロングテキスト | 推奨するリテンション施策 |
| AI判定理由 | Churn_AI_Reason__c | ロングテキスト | 検知されたシグナルの詳細 |
| 解約予兆検知日 | Churn_Signal_Detected_Date__c | 日付 | フロー実行日 |
| リテンション対応状況 | Retention_Status__c | 選択リスト | 未対応/対応中/対応済/解約 |
| AI処理済フラグ | Churn_AI_Processed__c | チェックボックス | 無限ループ防止用 |
| AI生レスポンス | Churn_AI_Raw_Output__c | ロングテキスト | 生成AIが返した文字列をそのまま保存（原因調査用） |
数式フィールド — 利用変動率
前月比の利用変動率を自動計算する数式フィールドも追加します。
Usage_Change_Rate__c（数式 / パーセント型）
IF(Previous_Month_Usage__c > 0, (Monthly_Usage_Count__c - Previous_Month_Usage__c) / Previous_Month_Usage__c, 0)
前月100回、当月19回なら表示は-81%です。前月0回のときは変化率を0とするため、「比較できない」と「変化なし」を区別できません。本番では前月0回を判定対象から外すなど、扱いを決めてください。
Lightning Record Pageへの反映
フィールドを作成しただけではLightning Experience上に表示されません。Lightning Record Page（レコードページ）のレイアウトを編集し、「解約シグナル（入力データ）」「AI解約リスク分析結果」の2セクションを追加します。
レイアウト設定を忘れずに
項目を作っただけでは画面に出ません。今回の環境はレコードページで項目を直接配置できる設定だったため、Accountレコード画面の右上ギアアイコンから「編集ページ」を開き、Lightning App Builderで項目を並べました。従来のページレイアウトで運用している組織では、そちらに項目を追加します。どちらの場合も、項目の参照権限が必要です。
Step 3 — テストデータの投入
動作検証のため、リスクレベルが異なる7件のテスト取引先を用意しました。最終ログインと契約更新日は、検証した日を基準にした相対日数で示します。この記事の検証日は2026年9月15日です。
| 取引先名 | 月間利用 | 前月利用 | 変動率 | NPS | 満足度 | 未解決Case | 最終ログイン | 契約更新日 | 期待リスク |
|---|---|---|---|---|---|---|---|---|---|
| アルファ商事 | 19 | 100 | -81% | -10 | 非常に不満 | 5 | 46日前 | 29日後 | 高 |
| ベータ工業 | 50 | 80 | -37.5% | 15 | 不満 | 3 | 11日前 | 59日後 | 中 |
| ガンマソリューションズ | 60 | 85 | -29.4% | 30 | 普通 | 2 | 6日前 | 89日後 | 低 |
| デルタコンサルティング | 40 | 70 | -42.9% | 10 | 不満 | 1 | 36日前 | 44日後 | 中 |
| イプシロンテック | 90 | 95 | -5.3% | 65 | 満足 | 0 | 3日前 | 179日後 | 低 |
| ゼータホールディングス | 120 | 110 | +9.1% | 85 | 非常に満足 | 0 | 1日前 | 364日後 | 低 |
| エータサービス | 10 | 90 | -88.9% | -30 | 非常に不満 | 8 | 61日前 | 14日後 | 高 |
テストデータの設計意図
- アルファ商事 — 4つのシグナルすべてに当たる想定。利用量81%減、NPS-10、46日ログインなし、未解決ケース5件
- ベータ工業 — 利用量は37.5%減、NPSは15。最終ログインは11日前で、未解決ケースは加点対象にならない上限の3件
- ガンマソリューションズ — NPSがちょうど30。加点条件の境界を確かめるための1件
- イプシロンテック、ゼータホールディングス — 今回の加点条件にどれも当たらず、いずれも0点になる想定
- エータサービス — アルファ以上に深刻。利用量89%減、NPS-30、61日ログインなし、未解決ケース8件
Step 4 — プロンプトテンプレートの作成
生成AIへの指示は、設定メニューのPrompt Builderで「プロンプトテンプレート」として作ります。フローやApexから名前を指定して呼び出せるうえ、指示文を直すたびにコードを触らずに済みます。
| 設定項目 | 値 |
|---|---|
| テンプレート種別 | Flex（レコードに紐づかない汎用型） |
| テンプレート名 | Churn Risk Analyzer（API名 Churn_Risk_Analyzer） |
| 入力 | context（テキスト1つ。取引先データと判定結果をまとめた文章） |
| モデル | GPT-4o mini（Salesforce標準で選べるモデル） |
| 言語 | 日本語 |
指示文の中身
テンプレートでは、判定理由とリテンション施策の作成を指示します。点数の計算は頼みません。
- 判定理由を書く — 検知した兆候を影響の大きい順に説明する。渡された数値をそのまま引用する。検知していない兆候は書かない。契約更新日が近ければ残日数を挙げる。200文字以内
- リテンション施策を書く — 誰が・いつまでに・何をするかを必ず入れる。その取引先固有の数値を根拠に1つ以上入れる。期限はリスクレベルが高なら3日以内、中なら2週間以内、低なら次回の定例まで。実施する順に2つまで。200文字以内
出力はJSONだけを返させます。reason と retentionAction の2キーです。
今日の日付を渡す
日付を渡さずに施策を書かせたところ、すでに過ぎた日が期限に指定されました。そこで入力の先頭に本日の日付を入れています。残日数や期限が合っているかは、生成後にも確かめてください。
Step 5 — フローから生成AIを呼ぶApexクラス
プロンプトテンプレートはフローから直接呼べますが、今回はApex（Salesforce上で動くプログラム）を1クラス挟みました。生成AIが返したJSON（項目名と値の組で書かれたデータ形式）を項目ごとに分解する処理はフローで書きづらく、応答の前後に説明文が付いたときに捨てる処理も入れたかったからです。
| 項目 | 内容 |
|---|---|
| クラス名 | ChurnRiskAiAnalyzer |
| 入力 | 取引先ID、フローが算出した点数とリスクレベル、検知した解約の兆候の文章 |
| 出力 | 成否、判定理由、リテンション施策、生の応答 |
| 呼び出し方法 | Apex標準のプロンプトテンプレート呼び出し |
取引先の9項目に本日の日付と判定結果を添え、名前を指定してプロンプトテンプレートを呼び出します。応答から最初の「{」と最後の「}」の間を切り出し、JSONとして読み取れなければ成否をfalseで返します。
取引先から読む9項目は、取引先名、月間利用回数、前月利用回数、利用変動率、最終ログイン日、サポート満足度、NPSスコア、未解決ケース数、契約更新日です。フローから受け取るのは取引先ID、点数、リスクレベル、シグナルの文章の4つ。フローへ返すのは成否、判定理由、リテンション施策、生の応答の4つです。この入出力どおりに作れば、フローのアクション要素から同じように呼び出せます。
テストクラスの書き方
この呼び出し方はテストの中では使えないため、文章の組み立てとJSONの切り出しを個別に検証しています。生成AIが使えないときに成否falseと失敗の内容が返ることも確認しました。テストでモデルを呼ばないので、何度回しても利用枠は減りません。
Step 6 — レコードトリガフローの構築
フローの全体像
「解約予兆AI検知フロー」（API名 Account_Churn_AI_Detection）をレコードトリガフローとして作成します。
| 設定項目 | 値 |
|---|---|
| オブジェクト | Account |
| トリガタイミング | レコード更新後（After Save） |
| 最適化 | アクションと関連レコード |
| 処理の実行場所 | 非同期パス（レコード保存の確定後に実行） |
| エントリ条件 | AI処理済フラグがfalse、かつ当月と前月の利用回数が入っていること |
フロー自身の更新による再実行を防ぐ
開始条件に Churn_AI_Processed__c = false を含め、フローの最後で true に変更します。これでフロー自身がレコードを更新しても再実行されません。翌月に評価し直すときは、スケジュールフローなどでフラグを false に戻します。
生成AIの呼び出しは非同期パスに置く
生成AIの呼び出しは、Salesforceから外部への通信として扱われます。レコード保存と同じ処理の中では実行できず、即時パスに置くとエラーで止まります。フローの開始要素で非同期パスを追加し、その先にAI呼び出しを置いてください。処理はレコード保存が確定した数秒後に走ります。
非同期パスを使うときは、エントリ条件を「レコードが条件を満たすように更新されたとき」に変える必要があります。この設定では条件式にISCHANGED関数が使えません。今回はAI処理済フラグと利用回数の入力有無だけで条件を組みました。
フロー内の変数・数式
| 変数名 | 型 | 用途 |
|---|---|---|
| v_RiskScore | 数値（初期値 0） | 加点式のリスクスコア累計 |
| v_RiskLevel | テキスト（初期値「低」） | リスクレベル（高/中/低） |
| v_Reason | テキスト | 判定理由を連結 |
| v_Action | テキスト | 推奨アクションを連結 |
加点の組み立て
フローの中心です。4つの「決定」要素を順に通り、当てはまった条件ごとに「割り当て」要素で点数を足します。
| 決定要素 | 条件（設定した値そのまま） | 加点 | 兆候として残す文 |
|---|---|---|---|
| 利用量低下チェック | 変化率が -0.5 より小さい | +40点 | 利用量が前月比50%超の減少 |
| 利用量低下チェック | 変化率が -0.2 より小さい（上に当たらない場合） | +20点 | 利用量が前月比20%超50%以下の減少 |
| NPS悪化チェック | NPSが 0 より小さい | +25点 | NPSスコアが負値 |
| NPS悪化チェック | NPSが 30 より小さい（上に当たらない場合） | +10点 | NPSスコアが30未満 |
| 未ログインチェック | 最終ログインからの経過日数が 30 より大きい | +15点 | 30日を超えてログインなし |
| 未解決ケースチェック | 未解決ケース数が 3 より大きい | +15点 | 未解決ケースが3件超 |
境界の値に注意
条件はすべて「より小さい」「より大きい」で、等号を含みません。ちょうど-50%の減少は40点ではなく20点、NPSちょうど30は加点なし、未解決ケースちょうど3件も加点なしです。テストデータのガンマソリューションズとベータ工業が、この境界に当たります。
4つの加点を全部足すと95点です。項目の説明では0〜100を格納できる型にしていますが、このルールで出る最大値は95点になります。
生成AIに理由と施策を書かせる
リスクレベルが確定したら、Step 5で作ったApexクラスをアクション要素から呼びます。渡すのは取引先ID、点数、リスクレベル、加点時に組み立てたシグナルの文章です。
| フロー要素 | 処理 |
|---|---|
| AIで理由と施策を作成 | Apexクラスを呼び、判定理由とリテンション施策を受け取る |
| AI生成の成否 | 成功なら生成された文章を採用。失敗なら加点ルールが組み立てた文章のまま進む |
| AIが書いた文章を反映 | 判定理由、リテンション施策、生の応答を変数に格納する |
生成AIが落ちても処理を止めない
AI呼び出しには失敗時の接続先を設定し、判定結果を書き戻す要素につなぎます。プロンプトテンプレートの名前を存在しない名前に変えて試したところ、点数95点とリスクレベル「高」はそのまま書き戻され、文章だけが加点ルール版の「利用量が前月比50%以上減少。NPSスコアが負値。」になりました。確認したのはこの経路だけです。書き戻し自体が失敗する場合や、Apexで例外が出る場合の記録先は別に設計してください。
リスクレベル判定と結果書き戻し
加点が終わったら、合計点でリスクレベルを決め、取引先レコードに書き戻します。
| スコア範囲 | リスクレベル | アクション |
|---|---|---|
| 60点以上 | 高 | 即時対応 + ToDo自動作成 |
| 30〜59点 | 中 | 要注意 + ToDo自動作成 |
| 30点未満 | 低 | 通常対応（定期の状況確認を続ける） |
ToDo自動作成
リスクレベルが「高」または「中」の場合、取引先所有者にフォローアップToDoを作成します。期限と優先度はリスクレベルから決めます。
| リスクレベル | ToDoの期限 | 優先度 |
|---|---|---|
| 高 | 2日後 | High |
| 中 | 7日後 | Normal |
| 低 | ToDoを作らない | — |
ToDoの本文には、点数、生成AIが書いた判定理由、リテンション施策がそのまま入ります。担当者はToDoを開けば、何が起きていて次に何をすればよいかを読めます。
ToDoに何が入るか
件名はリスクレベルと取引先名を並べた「【解約リスク高】アルファ商事 フォローアップ」の形です。ToDoの一覧で、高リスクと中リスクに判定された取引先を確認できます。本文には点数、判定理由、リテンション施策が入るので、取引先レコードを開き直さずに次の連絡を始められます。
Step 7 — 動作検証と結果
テスト実行
アルファ商事のAI処理済フラグをfalseに戻して保存すると、フローが非同期パスで起動します。十数秒後にレコードを再読み込みすると、点数と生成AIが書いた文章が入っています。
開始条件は「条件を満たすように更新されたとき」です。テストデータを入れたあとにフローを作った場合、フラグは最初からfalseなので、そのまま保存しても起動しません。いったんフラグをtrueで保存してから、falseに戻してください。
アルファ商事の点数 — 95点（高リスク）
- 利用量が前月比50%超の減少（当月19回、前月100回で81%減） → +40点
- NPSスコアが負値（-10） → +25点
- 最終ログインから30日超（46日前） → +15点
- 未解決ケースが3件超（5件） → +15点
- 合計 95点 → リスクレベル「高」
生成AIには、95点という判定結果と、検知した解約の兆候を渡しました。
生成AIが書いた判定理由
「利用量が前月比で81.0%減少しており、非常に不満のサポート満足度やNPSスコアが-10であることから、顧客の満足度が低下しています。また、最終ログイン日が46日前で、未解決ケース数が5件であるため、解約リスクが高まっています。契約更新日まで残り29日であるため、緊急度が高い状況です。」
生成AIが書いたリテンション施策
「カスタマーサクセスチームは、2026年9月18日までにアルファ商事株式会社の担当者と連絡を取り、未解決のケースについて解決策を提示します。また、2026年9月20日までに利用状況の改善に向けた提案を行います。」
加点ルールだけの頃は、理由が「利用量が前月比50%以上減少。NPSスコアが負値（批判者）。30日以上ログインなし。未解決ケースが3件超。」、施策が「即時対応：CSマネージャーによる緊急ヒアリング実施。」でした。どのシグナルで加点したかは分かりますが、その取引先の数字は出てきません。生成AIを挟むと、81.0%、-10、46日前、5件、残り29日という実際の値が文章に入ります。
全7件の結果
| 取引先名 | スコア | レベル | 加点の内訳 | ToDoの期限 |
|---|---|---|---|---|
| アルファ商事 | 95点 | 高 | 利用+40, NPS+25, ログイン+15, ケース+15 | 2日後 |
| エータサービス | 95点 | 高 | 利用+40, NPS+25, ログイン+15, ケース+15 | 2日後 |
| デルタコンサルティング | 45点 | 中 | 利用+20, NPS+10, ログイン+15 | 7日後 |
| ベータ工業 | 30点 | 中 | 利用+20, NPS+10 | 7日後 |
| ガンマソリューションズ | 20点 | 低 | 利用+20 | 作成なし |
| イプシロンテック | 0点 | 低 | 加点なし | 作成なし |
| ゼータホールディングス | 0点 | 低 | 加点なし | 作成なし |
高リスク2件と中リスク2件の計4件にToDoが作られました。高リスクの2件は期限が2日後で優先度High、中リスクの2件は7日後で優先度Normalです。低リスクの3件にはToDoを作りません。
期限が2か所に出てくる点は設計の弱いところです。ToDoの期限はフローが決め（高は2日後、中は7日後）、本文の日付は生成AIが指示文の「高なら3日以内、中なら2週間以内」に従って書きます。9月15日の実行では、ToDoの期限が9月17日、生成文の日付が9月18日と9月20日でした。9月20日は5日後で、指示した「高なら3日以内」にも従っていません。担当者に見せる期限を1つにするなら、フローが計算した日付を生成AIに渡し、その日付だけを使わせてください。
結果を見て分かったこと
- 低リスクと判定した取引先にも、生成AIは打ち手を書きます。ゼータホールディングスには「月間利用回数120回を踏まえて活用事例を提供し、さらなる利用促進を図る」という内容でした。解約を止める話ではなく、利用を伸ばす話に変わっています
- ガンマソリューションズはNPSがちょうど30で、「30より小さい」という条件に当たりません。利用量の20点だけで低リスクです。NPS30の取引先も拾うなら、条件を「30以下」に変えます。ガンマは10点が足されて合計30点、中リスクになります
- 同じ95点のアルファ商事とエータサービスでも、今回の出力では数値を挙げる順番と対応策が異なりました
- 指示文では「施策にその取引先固有の数値を1つ以上入れる」としましたが、アルファ商事の施策に数値は入りませんでした。次の修正案は、引用させたい数値を指示文で名指しすることです。この方法で入るかどうかは未検証です
- 判定理由の日本語が整わないことがあります。「非常に不満のサポート満足度」は選択肢の値をそのまま文に埋めた結果で、読みにくい表現です。社外に出す文面に使うなら、人が手を入れる前提にしてください
つまずいた3点
1. 生成AIに点数を計算させると間違える
最初の版では、加点表を指示文に書いて点数の計算ごと生成AIに任せました。7件に対して次の誤りが出ました。
| 取引先 | 生成AIの出力 | 何が誤りか |
|---|---|---|
| ベータ工業 | 85点。「NPSスコアが15と負の値であるため」 | 15は負の値ではない。同じデータをフローの加点ルールで計算すると30点 |
| ガンマソリューションズ | 40点だがリスクレベルは「高」 | 指示した区分では40点は「中」 |
| デルタコンサルティング | 100点 | 同じデータをフローの加点ルールで計算すると45点。倍以上ずれている |
指示文を細かくしても、足し算と大小比較の誤りは消えませんでした。点数はフローの加点ルールで確定させ、生成AIには確定した判定を渡す形に変えています。
2. 即時の処理からは生成AIを呼べない
レコード保存と同じ処理の中では、外部への通信ができません。AI呼び出しは、開始要素に追加した非同期パスへ置いてください。この設定では開始条件の書き方も変わり、ISCHANGED関数が使えなくなります。今回はAI処理済フラグと利用回数の入力有無だけで条件を組みました。
3. 今日の日付を渡さず、過去の日付が期限になった
日付を渡さずに施策を書かせたところ、すでに過ぎた日が期限に指定されました。入力の先頭に本日の日付を入れたあとの検証では、この現象は出ていません。契約更新日までの残日数も同じ情報に依存します。
まとめと本番運用に向けて
構築したもの
| 構成要素 | 名称 | 内容 |
|---|---|---|
| Agentforceエージェント | 解約リスクアナリスト | 社内向け。担当者がチャットで相談する窓口 |
| カスタムフィールド | 16個 | 入力7 + 出力8 + 数式1 |
| プロンプトテンプレート | Churn Risk Analyzer | 判定理由とリテンション施策を日本語で書かせる |
| Apexクラス | ChurnRiskAiAnalyzer | プロンプトテンプレートの呼び出しとJSONの読み取り |
| レコードトリガフロー | 解約予兆AI検知フロー | 非同期パスで加点、AI呼び出し、書き戻し、ToDo作成 |
| Lightning Record Page | Accountレコードページ | 「解約シグナル（入力データ）」「AI解約リスク分析結果」の2セクション |
| テストデータ | 7件 | 高リスク2件・中リスク2件・低リスク3件 |
実装時の要点
押さえる設定
- 点数とリスクレベルは加点ルールで決める。生成AIには確定した判定を渡し、判定理由と顧客への対応策だけを書かせる
- 生成AIの呼び出しは非同期パスに置く。即時の処理からは外部通信ができない
- AI呼び出しが失敗しても書き戻しへ進む。テンプレート名を誤らせた検証では、点数とリスクレベルが記録され、文章だけが加点ルール版になった
- AI処理済フラグで、フロー自身の更新による再起動を止める
- 入力の先頭に本日の日付を入れる。今回の検証では、日付を渡さないと過ぎた日が期限に指定された
- ToDoの期限と優先度はリスクレベルから決める。高は2日後、中は7日後
生成AIを何回呼ぶか
費用を見積もるために、呼び出し回数を整理します。点数はフローで計算し、判定理由とリテンション施策の文章を作るときだけ生成AIを呼びます。取引先1件の判定につき1回です。
| 場面 | 呼び出し回数 |
|---|---|
| 取引先1件の判定 | 1回 |
| 今回の検証（7件を1巡） | 7回 |
| この記事を作る間の合計 | 約40回（指示文の作り直しを4巡、単体の試行を数回） |
| 取引先500件を毎日評価する場合（AI処理済フラグを日次で戻す処理を足したとき） | 1日500回、30日で15,000回 |
日次で全件を評価すると回数が一気に増えます。減らすなら、加点が30点以上の取引先だけ文章を作る、点数が前回から上がった取引先だけ作る、といった条件をフローに足してください。点数の計算は加点ルールなので、文章を作らなくてもリスクの一覧は作れます。
テストクラスの中では生成AIを呼びません。テストを何度実行しても回数は増えません。
加点条件を自社向けに調整する
加点の閾値は業種や契約形態で変わります。
| 調整ポイント | 現在の設定 | 検討例 |
|---|---|---|
| 利用量減少の重度閾値 | 50%以上 | 業種によっては30%でも重大リスク |
| NPS閾値 | 負値で重度、30未満で中度 | NPS業界平均に合わせて調整 |
| 未ログイン日数 | 30日超 | 日次利用SaaSなら7日、月次なら60日 |
| 未解決ケース数 | 3件超 | サポート体制に応じて2件や5件に |
| リスクレベル境界 | 60点/30点 | 高感度にするなら50点/20点に |
本番運用で足すとよいもの
- 過去のやり取りを読ませる — 取引先に紐づくケース履歴や商談履歴をプロンプトへ渡し、打ち手の根拠を増やす
- 利用データの自動連携 — 外部SaaSのAPIとフローHTTP Callout機能で利用回数・ログイン日を自動更新
- ダッシュボード — CRM Analyticsで「リスクレベル別取引先数推移」「業種別解約リスク分布」を可視化
- Slackアラート — 高リスク検知時にCSチャンネルへ自動通知
- スケジュール実行 — 日次スケジュールフローでAI処理済フラグを戻し、定期的に評価し直す。このとき、高・中の取引先には毎回ToDoが作られる。未完了のToDoが残っていれば作らない、リスクが上がったときだけ作る、といった条件を足す