商談フェーズをAIで判定するには｜IntelligentSalesと受注確度の見方

日本のSaaSの検討候補には株式会社DeploAIのプロアクティブセールスAI（受注から逆算する実行エンジン）であるIntelligentSalesがあり、商談の発話を分析して商談フェーズを判定し、次に進めるための行動を提案する設計です 。

IntelligentSalesは、あるべき営業の理想形から逆算するバックキャスト型の設計で、不足している情報と次に取る行動を示します。

公式サイトは IntelligentSales です。この記事では当社サービスの商談フェーズ判定を中心に、受注確度の判断材料として使うときの確認点を説明します。受注確率を数値で算出する方式や、その精度を示す検証結果は、今回参照した公式ページでは確認できません。商談の段階を判定することと、受注する確率を数値で予測することは、別の要件として考えてください。

対象は、IT・SaaS企業で案件レビューや営業会議を行う営業責任者です。担当者の「手応えはあります」という報告を、顧客の発言や未確認事項と照らして判断したい場面を想定しています。AIが判断を代行できる範囲を広く見積もるより、自社の案件を前へ進めるために何を確かめられるかを見ていきます。

フェーズの判定と、受注の見込みを分けて考える

同じ「提案済み」に、違う状態が入る

商談フェーズは、その案件がどの段階にあるかを表す見立てです。一方で受注確度は、受注できる見込みに関する見立てです。提案資料を送ったという営業側の行動は確認できても、顧客がどの条件で購入を決めるかまでは、それだけでは分かりません。

たとえば、資料を送付し担当者が好意的に受け止めた案件と、承認者・評価条件・次回の判断日程まで共有された案件が、ともにSFAで「提案済み」になっていることがあります。同じ名称のフェーズでも、次に必要な働きかけは異なります。前者は意思決定の条件を聞くこと、後者は残る懸念を解消することが中心になるかもしれません。

この違いを見ずに、フェーズ名から受注の見込みを決めてしまうと、確認すべきことが隠れます。AIを使う際も、ラベルが付いたことだけを成果にせず、そのラベルの理由と、まだ確かめるべき事項を合わせて見ます。

IntelligentSalesについて確認できる範囲

公式機能紹介 のSFRAは、直近商談の発話を分析して進行段階や停滞箇所を見立て、次のステップと質問を提示する機能として説明されています。評価・アクションは、複数の観点で得た分析を次の行動へまとめる構成です。

ここで確認できるのは、商談内容に基づく段階の分析と行動提案という設計です。自社が使うすべてのフェーズ名への対応、任意の判定条件の設定、受注確率の数値算出までを、公開説明だけで確認したわけではありません。必要な機能は、自社の定義を示して個別に確かめてください。

また、商談の発話を分析するという説明を、会話の最中に判定が逐次更新されるという意味へ広げないことが大切です。公式ページでは、商談中に準備済みのガイドを参照する支援と、その場で即時検知して介在する将来構想とが区別されています。評価対象は、現在相談できる機能と提供条件を確認したうえで決めます。

人が判断するための根拠をそろえる

営業会議で必要なのは、AIと担当者のどちらが正しいかを一度で決めることではありません。見立てが違ったときに、どの情報を追加すれば判断が進むかを明らかにすることです。

担当者は顧客との電話で承認者を確認していても、その内容が今回入力した商談記録に含まれていないかもしれません。逆に担当者が「予算は問題ないと思う」と話していても、顧客が予算を確保したとは言っていない場合があります。入力情報の不足と、解釈の違いを分けないと、AIの評価も担当者への助言も曖昧になります。

案件の見極めに使う観点は、ピラー記事の 営業フレームワーク大全 に整理しています。本記事ではその名称の解説を繰り返すより、自社のフェーズ定義と商談の発言をどう照合するかに焦点を置きます。

架空のSaaS案件で、判定の読み方を確かめる

以下は、導入評価と営業会議の進め方を説明する架空例です。実顧客の案件、IntelligentSalesの判定結果、予測精度を示すデータではありません。表のフェーズ名や確認事項は説明用であり、製品に固定実装されている項目という意味ではありません。

案件A：担当者は前向きだが、社内の判断条件が見えていない

業務管理SaaSの営業担当が、現場責任者へ提案を行いました。顧客は「現場では使いやすそうです。上長に持ち帰って検討します」と話しています。資料は送付済みですが、誰が最終判断をするか、何を基準に選ぶか、いつ確認するかは話されていません。

SFAの「提案済み」という記録は、資料を渡した事実には合っています。しかし、そのラベルだけで受注の見込みが高いと判断する根拠にはできません。営業会議では、担当者の好意的な反応を記録しつつ、意思決定の経路と条件を次に確認する事項として分けます。

AIの評価では、この二つが混ざらずに出ているかを見ます。たとえば、商談に登場していない役員を決裁者として記載していないか、未合意の導入時期を予定として補っていないかを確認します。見立てが慎重であっても、その理由が情報不足として説明されていれば、次の質問を考える材料になります。

案件B：提案に加え、評価条件と次回の確認相手が決まっている

同じSaaSを検討する別の顧客では、業務責任者が次回に参加すること、確認する業務が決まっていること、社内で残っている懸念が明らかになっています。こちらもSFA上は「提案済み」とします。

この案件で、再び「次回の参加者と評価条件を確認する」を最優先にすると、すでに共有された内容を聞き直すことになるかもしれません。営業担当は、残る懸念を説明できる資料や確認方法を準備し、次回の場で何に合意するかを整理するほうがよい場合があります。ただし、業務責任者が決裁者であるとは限りません。決裁者や承認経路をまだ確認できていないなら、その確認は必要な行動として残します。

この比較の目的は、案件Bの受注確率を何％と定めることではありません。同じフェーズ名の中で、次の行動を変えるべき理由を示すことです。AIの出力を評価する際も、違いを適切に説明できているかを確認します。行動提案が両方とも同じ場合には、理由を読み、入力の違いが判断に反映されているかを見ます。

案件C：PoCが動いていても、導入判断の条件は未合意

別の架空例として、SaaSの試用環境で現場担当者が検証を始めた場面を考えます。操作はできていますが、どの業務で評価するか、何を満たせば本導入に進むか、評価結果を誰が承認するかは明確ではありません。

試用が始まったことと、導入判断が進んでいることは同じではありません。ここで「PoC実施中」というラベルだけを見て進展したと判断すると、終了後に何を決めるかが残ります。営業会議では、検証を続ける作業と、評価条件に合意する行動を分けて確認します。

AIを試すなら、利用者の感想だけが入った記録と、評価条件が合意された記録を用意する方法が考えられます。それぞれについて、何が分かり、何がまだ分からないかを人が先に整理します。この比較は、出力の言葉が派手かどうかより、判断条件の有無を捉えられるかを見るためのものです。

自社のSFAの段階へ、どう対応させるか

導入検討時には、自社のSFAで使っているフェーズの名前と、移行条件を取り出してください。「提案中」「評価中」「稟議中」といった名称だけではなく、何が確認できたら次に進めるかを書きます。社内で定義がそろっていない場合、その曖昧さをAIの導入だけで解消したことにはできません。

次の表は、自社で対応を決めるための整理例です。IntelligentSalesがこの表を自動生成する機能や、これらの段階を採用していると説明するものではありません。

公式FAQ では、既存のSFA/CRMとの併用が案内されています。併用できるという説明と、自社のフェーズを自動更新できるという説明は同一ではありません。更新の方法、対応する項目、確認を挟む場所は個別に確かめます。外部連携は 連携ページ のProfessional向けFDE個別構築に該当し、別契約・別費用です。

判定が食い違ったときのレビュー手順

AIと担当者の見立てが違う場合、最初に入力した商談記録を確認します。重要な発言が抜けていないか、別案件の情報が混ざっていないか、話した人の区別が崩れていないかを見ます。入力に問題がある場合、出力だけを直して終えると、同じ原因が残ります。

次に、担当者が判断に使った情報を確認します。商談後のメールや別の面談で得た事実なら、それをどのように分析対象へ反映できるかを相談します。入力にない情報をAIが知らなかったことと、入力にある発言を誤って解釈したことは、別の問題として記録してください。

そのうえで自社のフェーズ定義を照らし合わせます。同じ記録を読んだ上長同士でも判断が分かれるなら、AIの性能だけでなく、社内基準の曖昧さも検討対象です。最後に、追加で聞くことと、今回は誰がどの記録を更新するかを決めます。

レビュー結果には、採用した見立て、採用した理由、未解決の情報を残します。AIに合わせて人の判断を機械的に変更するのでも、人の最初の見立てを正解として固定するのでもなく、顧客の確認済み事実に戻るための運用です。振り返りの会話を整理したい場合は 商談の振り返りに関する記事 も参考になります。

デモの評価結果を、導入の判断に使える形で残す

評価では、分かりやすい案件だけでなく、確認事項が多い案件や、停滞理由を担当者が説明しづらい案件も検討材料にします。実データを利用できない場合は、架空データで表示や手順を確認できます。ただし、その結果を実際の商談での精度と同じには扱わないでください。

確認記録には、入力した情報の範囲、出力された見立て、担当者が追加した情報、次に取る行動を並べます。出力が妥当でも現場で使い切れない場合は、表示方法やレビュー担当の役割が課題かもしれません。誤った断定が出る場合は、どの入力で何を誤ったかを具体的に残して提供元へ確認します。

受注確率の数値が要件なら、何を予測対象にするか、どの時点の情報を使うか、どの案件で確かめるかを別に相談します。割合らしい数値が表示されたことだけでは、予測の精度が確認できたとは言えません。本記事は数値予測の提供や精度を保証せず、その要件をフェーズ分析から分けることをおすすめしています。

情報が変わった案件では、判定時点を残す

案件Bのように評価条件が決まっていた商談でも、その後に担当者が異動したり、対象業務が変わったりすることがあります。以前の商談では確認できていたことが、今の案件でも有効かどうかを見直す必要があります。古い確認結果を、最新の合意として使い続けないためです。

この架空例で、次回の面談相手が変更されたとします。営業担当は、以前決まっていた評価条件を新しい相手が引き継いでいるかを確認します。AIへ直近の商談だけを渡すのか、過去の経緯も渡すのかで、判断に使える情報の範囲は変わります。どの履歴を参照できるかは、導入検討時に確かめる項目です。

営業会議では、判定した時点と、そのときに確認できていた情報を残す方法を考えます。前回より慎重な見立てに変わったとしても、必ずしも分析が不安定になったとは限りません。入力した情報や顧客の条件が変わっているなら、その変化を理解することが先です。一方で、同じ情報から理由なく違う見立てが出る場合は、再現条件を記録して確認します。

このように、段階が進んだか戻ったかだけでなく、何が新たに確認され、何が未確認になったかを見ると、会議で扱う論点が明確になります。顧客がまだ答えていない質問を、以前に営業が予想した内容で埋めないことも大切です。

営業会議へ持ち込むメモの例

案件Aについて会議を行うなら、担当者は「提案済みです」と報告するだけでなく、次のように情報を分けて持ち込む方法が考えられます。これは社内運用の例であり、製品画面の項目や自動出力を示すものではありません。

マネージャーは、このメモを使って、担当者の活動を増やす指示だけでなく、どの確認を先に行うかを話し合えます。担当者が選んだ行動を見れば、AIの分析を読めたかだけでなく、次回の準備に使えたかも確認できます。

社内でこの形式を試す際は、既存のSFAや会議資料に同じ情報があるかも見てください。重複入力を増やさずに参照できる場所を決めることが、運用上の検討事項になります。必要な情報がどこへ表示され、誰が更新するかまで含めて、デモや相談で確かめることをおすすめします。

案件の進め方を話し合う材料として選ぶ

IntelligentSalesの検討では、フェーズ名が付くことだけでなく、商談のどこで止まり、次に何を確認すべきかを判断できるかに注目してください。受注の見込みを話し合う材料は得られる設計ですが、受注確率の数値予測が必要なら、別の機能要件として確認する必要があります。

相談時には、自社のSFAのフェーズ定義、判断に迷った商談場面、AIへ渡せる情報、判定後に誰が記録を更新するかを用意すると、評価の範囲を絞れます。数字による予測が必要なのか、不足情報と次の確認事項が分かればよいのかを先に伝えてください。

デモ相談 では、利用可能な機能・提供時期もあわせてご確認ください。参照情報の確認日：2026年10月12日。機能・FAQ・連携ページの公開日と更新日は確認できていません。記載は公開説明の確認に基づき、製品の実動作や判定精度を検証した結果ではありません。