Einstein Discovery で「データは多いほど良い」と盲信して失敗した私の判断

einstein discovery で実際にやらかした判断

初めて Einstein Discovery に触れたとき、「顧客の離反リスクを予測したい」というざっくりとした要件がビジネス部門からあがってきた。Salesforce 管理者として、私はその要件を聞いたときに、まず「データは多いほどAIが賢くなる」という先入観があった。だから、Salesforce 内に存在する関連オブジェクト（取引先、商談、ケース、活動など）のデータを、とにかく考えられる限り全部突っ込んでみようと判断したのだ。今なら絶対やらない、本当にやらかした判断だった。

当時の「データは多いほど良い」という盲信

当時の私は、Salesforce の強力な UI に魅せられていた。「データセットを作成」の画面で、オブジェクトをポチポチ選び、結合条件も設定できる。まるで魔法のように、様々なデータソースが組み合わさっていくのを見て、「これでAIが学習する基盤ができた！」と興奮していたのを覚えている。とりあえず、取引先オブジェクトから紐付く子オブジェクトを可能な限り追加し、さらに活動履歴やケース履歴なども無理やり結合させて、とにかく巨大なデータセットを作った。

具体的には、以下のようなフィールドを特に考えもなく追加していた。

• 取引先情報（業種、従業員数、年間売上など）
• 商談情報（商談フェーズ、金額、確度、完了日など）
• ケース情報（ケース件数、平均解決時間、最終ケース日など）
• 活動情報（最終活動日、活動件数、活動種別ごとの件数など）
• カスタムオブジェクトに記録されたサービス利用履歴
• 営業担当が個人的に追記していたメモフィールド（これも「データだから」と含めた）

目標変数（結果変数）も、「離反リスク」という漠然としたものだったため、「最終活動日からの経過日数が長いもの」「特定のカスタムフラグが立っているもの」「過去に解約に至った取引先」などをDiscoveryにそのまま学習させようとしていた。複数の「離反」の定義が混在していたのだ。

後から「やらなければよかった」と思った設計

あの時のデータセット設計は、本当に後悔しかない。主な問題点は以下の通りだ。

• データの粒度がバラバラだった:

  商談は商談の粒度、ケースはケースの粒度、活動は活動の粒度で存在する。これらを無理やり一つのテーブルに結合したことで、レコードの「意味」が曖昧になってしまった。あるレコードは特定の商談を表し、別のレコードは全く別のケースを同時に含んでいる、といったカオスな状態だった。Discovery は各行を一つの事例として学習するわけだが、その「事例」の定義が曖昧すぎたのだ。

• 目標変数の定義が曖昧だった:

  「離反リスク」という概念を、Discovery が学習できるような具体的な単一の数値やカテゴリに落とし込めていなかった。「契約終了日からの経過日数が一定以上」という指標と、「過去に解約フラグが立ったかどうか」という指標を、同じモデルで学習させようとした。結果として、Discovery が何を最適化しようとしているのか、全く分からなくなった。

• 関連性の低いデータがノイズになった:

  「データが多いほど良い」という盲信から、例えば営業担当がメモとして残していた顧客の趣味や雑談の内容、あるいは全く予測に関係ない古いカスタムフィールドなども全て突っ込んだ。もちろん Discovery 側で重要度が低いと判断され、モデルから除外されるケースもあっただろう。しかし、データセット作成時の処理負荷や、その後の Story の解釈を困難にするノイズでしかなかった。

  特に、Salesforce の標準機能として提供される Text Analyser を使って、活動の Subject や Description フィールドのテキストマイニングも試みたのだが、ノイズが多すぎて意味のあるインサイトはほとんど得られなかった。結局、無駄なデータ処理に時間とリソースを費やしただけだった。

• 学習時間と結果の解釈の困難さ:

  無駄に巨大で複雑なデータセットだったため、Discovery が Story を生成するまでにかなりの時間を要した。そして、いざ Story ができたとしても、提示されるインサイトは「〇〇フィールドがこの値だと予測値が上がる」といったものが多かったが、その〇〇フィールド自体が複数の意味を持つデータが混在しているため、ビジネスアクションに繋がる具体的な示唆を読み取ることができなかった。例えば、「Activity_Subject_Text_Sentiment が高いと離反リスクが下がる」と言われても、Activity_Subject の粒度がバラバラなので、「どの活動の、どの感情が」という具体的な指示が出せないのだ。

今なら別の選択をする

あの経験を経て、今なら Einstein Discovery の導入では、まず以下の点を徹底する。

1. 目標変数（結果変数）の明確化を最優先:

   「何を予測したいのか」をビジネスサイドと徹底的に協議し、Salesforce 上のどのフィールドで、どのようなロジックで表現できるかを具体的に定義する。例えば、「過去1年以内に一度も商談が発生せず、かつサポートケースが3件以上あった取引先を『高離反リスク顧客』とする」といった、誰が見ても明確なフラグを作成する。Discovery の予測対象は、シンプルかつ明確なフラグであるべきだ。

2. データセットのスコープを最小限に絞り込む:

   目標変数に直接的・間接的に影響を与えそうな、本当に必要なオブジェクトとフィールドだけに絞る。まずは最小限のデータセットでモデルを作成し、その結果を見ながら徐々にフィールドを追加していくイテレーションを回す。闇雲にデータを増やすのは百害あって一利なしだ。

3. データの品質と粒度の統一:

   データセット作成前に、各フィールドの入力規則、欠損値、ユニークネスなどを確認し、必要であれば前処理を行う。また、複数のオブジェクトを結合する場合でも、結合後のレコードが「何を表現しているのか」が明確になるよう、粒度を意識した設計を心がける。例えば、取引先ごとの集計データ（例：過去1年間の商談件数、ケース件数合計）として粒度を揃えるなどだ。

4. ビジネスアクションへの繋げ方を常に意識:

   予測モデルを作る最終目的は、ビジネスアクションを改善することにある。そのため、どんなデータを入れるか、どんなインサイトを求めるかを考える際に、「このデータから得られるインサイトは、誰が、何を、どう変えるために役立つのか」という視点を常に持つ。使えないインサイトを生み出すデータは、無駄でしかない。

当時の私は、Salesforce の強力な UI を過信しすぎていたのかもしれない。簡単にデータセットが作れるからといって、その裏にあるデータサイエンスの基本的な考え方（特にデータ準備の重要性）を疎かにしてしまった。結局、あのモデルは破棄し、最初からビジネス要件の整理とデータ定義からやり直すことになった。あの時の経験がなければ、今でも「データ量至上主義」という罠に陥っていたかもしれない。