営業予測システムの発注は、予測の対象とKPI、データと運用ルールを決め、要件に合う契約で委託する流れで進めます。
そうすれば、予測を判断と行動に結び付けやすくなります。各段階で決めておくことを、順に説明します。
▼全体ガイドの記事
・営業予測システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
営業予測システムの発注・外注の全体像
営業予測システムは、顧客情報や商談金額、営業ステージなどを集約し、将来の売上や受注時期を見通す仕組みです。受注予定日や活動履歴、過去の売上実績も、そのための材料になります。
発注時は、予測画面だけでなく、データの更新担当と更新頻度も決めておきます。あわせて、経営会議で公式の値として扱う数字も明確にします。
Microsoft Dynamics 365 Salesの公式資料は、予測カテゴリ、クォータ、階層ロールアップによる収益把握を説明しています。さらに、パイプライン活動も組み合わせる考え方が、公式ドキュメントに示されています（出典: Microsoft Learn「売上予測の概要」、2026年8月確認）。
外注範囲を決める前に、既存製品の機能を確認しておきます。たとえば、HubSpotの公式フォーキャスト機能は、月次・四半期予測のほか、複数パイプラインや加重パイプライン、履歴スナップショットにも対応しています（出典: HubSpot公式「フォーキャストツール」、2026年8月確認）。
標準機能で足りる部分は独自開発せず、承認フローや基幹連携などの独自要件に予算を振り分けます。
営業予測システムとSFA・CRM・BIの違い
SFA・CRM・BIと営業予測システムは、営業データを扱う範囲と役割が異なります。
- SFA：営業活動と案件の進捗の管理
- CRM：顧客との接点の一元管理
- BI：複数システムのデータの分析と可視化
営業予測システムは、データから「今期の受注見込みはいくらか」「目標との差はどこか」「どの案件を今週確認するか」を示し、意思決定につなげます。
独立したシステムを新規開発するだけでなく、既存のSFA・CRMに標準の予測機能を設定する選び方もあります。さらに、CRMの案件と基幹の売上実績をDWHやBIに集める方法もあります。
独自の営業プロセスだけを追加で開発する方法もあります。また、SalesforceやMicrosoft 365を使っている場合は、標準機能と連携範囲を確認し、不足する部分だけを外注すると、過剰な開発を防ぎやすくなります。
発注形態の選択肢：クラウド、パッケージ、スクラッチ
標準の案件管理と加重パイプラインから始めるなら、SaaSの設定が適しています。ただし、営業人数や商談数が増えた場合は、要件を見直します。
独自の階層や商品別の予測が必要で、承認フローや基幹連携も求められる場合は、CRMパッケージのカスタマイズやSIerの導入を検討します。
複数事業部のデータを統合し、独自の予測ロジックや権限を組み込むなら、DWH・BI連携型やスクラッチ開発が候補になります。
形態を選ぶときは、ユーザー数だけでなく、次の条件も確認しておきます。
- データ：連携先の数と過去データの欠損
- 業務：営業階層の複雑さと予測の更新頻度
- 運用：AIに必要な履歴と内製できる人材
特化製品を新たに探すより、既存のCRMを正しく使い、予測の定義とデータ品質をそろえるほうが、短期間で実用的な結果につながるケースも多くあります。
発注前の要件整理とRFPの作り方
要件が曖昧なままだと、会社ごとの見積の前提がそろわず、価格で比べられません。IPAのDX SQUARE「要件定義とは？」は、要件定義をユーザー企業とベンダー企業の認識合わせに重要な工程と説明しています。出典ページは2026年8月に確認しました。
発注者側で業務の目的と現状を整理し、候補会社に同じ資料を渡します。そうすれば、共通の条件で提案を比べられる状態になります。
予測の目的とKPIの決め方
まず、何を予測するかを決めます。月次売上や四半期の受注額、受注件数などのほか、粗利や契約更新額も候補になり、対象が違えば必要なデータと画面も異なります。
営業担当者の見込み、マネージャーが承認した見込み、過去データによるAI推定値を混ぜると、予測が外れたときに原因を説明できません。そのため、公式予測、担当者見込、システム推定の値と実績は、別項目で管理します。
KPIは、売上の的中率のほかにも考えられます。導入の目的に応じて、入力や更新、案件管理、会議運営の指標も確認します。
- 入力・更新：入力遵守率と受注予定日の更新率
- 案件・予測：ステージ滞留日数と予測誤差
- 業務改善：会議資料の作成時間と是正行動に移った案件数
導入前の数値を1か月分でも測っておくと、稼働後に改善があったかを数字で検証できます。「便利になった気がする」という感想だけで判断せずに済みます。
データの棚卸しと予測ルールの統一
RFPの前に、予測に使うデータの所在を洗い出します。顧客と案件を識別するID、担当者、商品の情報を確かめます。金額や通貨に加えて、商談ステージ、受注予定日、確度の情報があるかも確認します。
データが分散している場合は、Excel、SFA、CRMのどこにあるかを確かめます。会計、ERP、MAに置かれている場合は、それぞれ確認します。
そのうえで、システム名と更新頻度、保有期間を一覧にします。欠損項目や重複の有無も、あわせて書き出します。
- データ診断を先に行う理由：入力が不正確だと、高性能なモデルでも誤った値を精密に計算するため、AIモデルの選定より先に診断します。
ステージ別の成約率を使う加重パイプラインでは、定義と成約率の更新責任者を決めておく必要があります。たとえば、「提案済み」は提案書を提出した状態、「最終確認」は決裁者と条件を確認した状態のように、主観に頼らず確認できる条件で定義します。
予測の締め日、受注予定日の変更権限、失注や延期の扱いも決めておきます。月次で誤差を見る方法まで要件に書いておくと、各社の見積を比べやすくなります。
RFPに記載する範囲・成果物・検証方法
RFPでは、業務の前提と候補会社への質問をそろえたうえで、次の項目を共通の条件として示します。
- 背景と対象：目的、部門、利用者数、予測対象、現行業務
- 環境と条件：連携先、移行対象、権限、セキュリティ、日程、予算、保守体制
- 提案内容：標準機能・設定・カスタマイズ・新規開発の区分、追加費用の条件
- 納品と支援：納品物、検収、教育、稼働後支援の範囲
全社展開の前に、1部門か1商品群を対象としたPoCを提案してもらう方法も有効です。4〜8週間程度を目安に、過去データによる予測と実績を検証します。画面の使いやすさや更新負担、予測根拠も確かめます。
PoCの成功条件と本番移行の判定基準は、RFPに書いておきます。そうすれば、試作品だけで終わるリスクを下げられます。
営業予測システムの契約形態と開発・委託の進め方
要件を決めて一度に作る案件もあれば、使いながら改善する案件もあります。予測ロジックや現場の運用がまだ固まっていない場合は、要件定義やPoCと、本開発や保守を同じ契約に押し込めないようにします。
契約名だけで決めず、工程ごとの責任と成果物を明確にします。あわせて、完了条件と、変更を承認する手順を文書にします。
要件整理や伴走型の開発に向く準委任契約
準委任契約は、決められた作業を専門家に委託し、稼働時間や役割に応じて精算する契約です。ヒアリングやデータの棚卸しなど、要件が変わりやすい工程に向いています。
プロトタイプの検証や予測ルールの改善も、進めながら要件が変わる工程です。ただし、作業を行うことと、予測精度や導入効果を保証することは別です。
責任者や稼働時間、会議体は、契約書や個別発注書で確認します。成果物と報告方法、知的財産の扱いは、契約に明記してもらいます。
請負契約が向く工程と検収条件
請負契約は、合意したシステムや機能を完成させ、発注者が検収する形態です。要件が固まった部分、たとえば画面やAPI、データ移行を対象にしやすくなります。レポートや権限設定も、要件が決まっていれば対象になります。
- 納品物：設計書、ソースコード、データ辞書、テスト仕様書、移行仕様書、操作マニュアル
- モデル情報：モデルのバージョンごとの情報
- 受入条件：受入テスト項目と不具合修正の期限
稼働後にステージ定義や予測期間を変えたくなる場合があります。そのため、無償対応の範囲と追加見積の条件を決めておくと、現場の変化に対応しやすくなります。加えて、優先順位と納期への影響も、あらかじめ定めます。
AIの予測値は絶対の保証とせず、入力データの条件、評価指標、再学習の手順を合意しておくことが現実的です。
SaaS利用と導入支援・保守の契約
SaaSでは、ライセンスと導入支援の契約が別になっている場合があります。そのため、月額に含まれる機能とユーザー課金の条件を確認します。
API・ストレージの上限、AIクレジット、データ保持の条件も確認します。サポート時間と解約時の返却についても、確かめておきます。
- 利用条件：AIクレジット、データ保持、サポート時間、解約時の返却
- 導入支援：標準設定、権限設計、データ移行、連携、教育
- 追加支援：運用代行と追加改修は、別に見積もってもらう項目
委託先を一社に固定しすぎると、担当者の交代や契約の終了時に運用が止まることがあります。自社でも管理者権限を持ち、データ辞書と設定一覧を受け取っておきます。
別の会社へ引き継げる状態にしておき、再委託の有無も確認します。加えて、国外のデータセンターやAIサービス、障害時の連絡経路も、契約前に確かめます。
営業予測システムの費用相場とコストの内訳
営業予測システム単体の公的な一律の相場はありません。そこで、以下の金額は、NotebookLMによる営業・CRM・MA系の調査整理と、公開中のCRM・SFA・分析基盤の料金に基づく推定レンジです。
金額は営業人数よりも、連携先や移行データの状態、権限の複雑さで大きく変わります。また、AI検証や保守範囲によっても変わります。
見積は一点の金額として断定せず、前提条件つきの幅で受け取ります。
発注形態ごとの初期費用と期間の目安
発注形態と対象範囲によって、初期費用と期間は異なります。目安となる幅を、次のとおり示します。
- SaaS標準設定：0〜100万円程度、1〜3か月
- 移行・外部連携あり：100〜800万円程度、2〜6か月
- CRM・パッケージ拡張：500〜3,000万円程度、3〜9か月
- 複数事業部の予測基盤：1,500〜5,000万円程度、6〜18か月
- フルスクラッチ：5,000万円〜2億円超、12〜24か月以上となる可能性
複数事業部の予測基盤は、DWHやBIの整備に加えて、複数のCRMや基幹システムとの連携、データ品質の改善を含む場合です。スクラッチでは、独自のロジックや権限、監査の仕組みを作ります。また、モデル運用も含みます。
類似案件には、小規模10万〜500万円、中規模500万〜5,000万円、大規模5,000万円〜数億円以上の目安もあります。ただし、営業予測単体の統計ではありません（出典: NotebookLM Q&A「営業・CRM・MA」、2026年8月確認）。
ライセンス・移行・AI・保守の見積もり
費用は、ライセンスや要件定義・設定、データ移行に分けて見積もります。外部連携や教育・定着支援は、個別の見積として確かめます。AI・BIの追加料金と、保守・運用も、別に確認します。Salesforceの価格は、2026年8月確認時点の1ユーザー月額です。
- 基本プラン：Starter Suite 3,000円、Pro Suite 12,000円、Enterprise 21,000円
- 上位プラン：同時点でUnlimited月額42,000円、Agentforce 1 Sales月額66,000円（各1ユーザー）
- 掲載機能：Pro Suiteは営業の見積もりと売上予測、Unlimitedは予測AI
導入設定や移行、連携のほか、個別開発は、価格表とは別に確認します（出典: Salesforce公式「販売価格」、2026年8月確認）。
20ユーザーの場合、ライセンスだけでも年間72万円から1,584万円まで幅があります。初期構築費は含まれないため、価格表だけで製品を決めないようにします。
Salesforce公式ページには、予測AIなど上位エディションの違いや、追加アドオン、認定パートナーによる導入支援も記載されています。
AIクレジットや対象データ、学習利用の条件は、見積書の別欄で確認します。出力の説明性や再学習・監視の費用は、別の欄に分けて見ます。
ランニングコストと5年TCO
稼働後は、SaaSの月額や、ストレージ・API従量料金、連携基盤の費用が発生します。さらに、AIや問い合わせ対応、運用代行、追加改修の費用もかかります。保守の範囲は、ほかの費用と分けて考えます。
- 利用・基盤：SaaS月額、ストレージ・API従量料金、データ連携基盤
- 支援・改修：AIオプション、問い合わせ対応、運用代行、追加改修
- 保守：初期開発費の年10〜20％程度を仮置きする考え方もあります。SaaSのサポートと個別改修は分けて扱います。
モデル再学習や営業プロセスの変更の費用も、見落とさないようにします。比較では、初期費用に加えて、利用料と連携費、教育費、保守費を含めます。
3年または5年の総保有コスト（TCO）には、価格改定も含めます。見積書には、税別・税込と月額・年額、契約期間を記載してもらいます。加えて、最低利用数や値上げ条件、解約時の出力費も書いてもらいます。
安価なPoCは、本番の再構築費を含まないことがあります。そのため、本番移行の追加条件も確認しておきます。
営業予測システムの委託先選定と見積比較のポイント
委託先は、製品を提供する会社と、設計や移行、連携、定着を支援する会社に分けて考えます。Salesforce、Microsoft、HubSpotなどは、基盤や標準機能を提供しています。
SIerや導入パートナーは、業務設計と個別実装を支援します。知名度や「AI搭載」という言葉だけで判断せず、自社の営業プロセスとデータ環境への理解を確かめます。
製品ベンダーと開発会社の役割と実績
候補会社には、営業予測またはSFA・CRMの実績を尋ねます。企業規模やユーザー数、営業部門数、既存システムを挙げてもらうと、比べやすくなります。あわせて、期間や担当範囲、成果指標も尋ねます。
- 製品ベンダー：標準予測機能、予測カテゴリ、パイプライン分析、AIの説明性、API・権限
- SIer・開発会社：要件定義、データ移行、連携、教育、運用引き継ぎ、内製化支援
事例は、「売上が増えた」という表現より、測定できる指標で確かめます。導入前後の予測誤差や更新遵守率、会議時間、停滞案件数などを見ます。
事例を開示できない場合は、匿名化した構成図や、データ移行方法の説明から技術力を確認します。テスト計画や障害対応体制の説明も、技術力を見る材料になります。
同じ前提と内訳での見積比較
複数社には、同じ前提をそろえて依頼します。そろえる項目は、ユーザー数や対象部門、データ件数、移行期間です。連携先や予測期間、帳票のほか、テスト回数と教育回数も、同じ条件にします。
- 検証条件：予測期間、帳票、テスト回数、教育回数
- 開発内訳：要件定義、基本設計、設定・開発、データクレンジング
- 導入内訳：移行、外部連携、テスト、教育、稼働支援、保守
工程ごとの工数と単価を、見積書で確認します。担当者の役割や前提、除外項目も、比較の材料にします。そのうえで、要件を満たす実質総額と、発注者側の負担を比べます。
価格に差がある場合は、安い会社の工数の少なさと、高い会社の追加作業を確かめます。移行を発注者の作業として除外したり、ヒアリングや教育を含めなかったりする場合もあります。API・AI機能や受入テスト回数が含まれていないこともあります。
セキュリティ・権限・解約時の条件
顧客担当者の氏名や連絡先、商談履歴を扱います。メールや通話記録、従業員データまで扱う場合もあります。
個人情報保護委員会の通則ガイドラインは、令和8年6月に改正されています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、令和8年6月改正）。利用目的や正確性、安全管理を確認事項に挙げており、委託先の監督や漏えい時の対応も含まれます。
RFPには、アクセス権限や暗号化、監査ログ、バックアップを記載します。さらに、脆弱性対応やインシデント報告、再委託、データの保存場所も書き添えます。
- 海外利用：海外のクラウドやAIへ渡る可能性がある場合の、データ、事業者の国、利用目的
- 解約時：CSV・データベースでの返却、バックアップを含む削除、エクスポート費用を契約で定める
個人情報保護委員会の外国第三者提供ガイドラインは、委託先の選定や契約、取扱状況の把握を求める考え方を示しています。
開発・導入後に営業予測の精度と定着率を高める方法
営業予測の精度は、導入した日に決まるものではありません。現場が案件を更新し、マネージャーが予測をレビューし、実績との差を記録するサイクルで改善していきます。
AIについても、最初から自動の判断に任せず、加重パイプラインを基準にします。人が補正した履歴と予測根拠を残す進め方が、安全です。
入力ルールと会議運営の決め方
入力項目を増やしすぎると、営業担当者が更新しなくなります。そこで、予測に必要な項目を優先し、入力の締め日と担当者を決めます。
- 案件情報：受注予定日、案件金額、ステージ
- 行動情報：次回アクション、失注リスク
楽観的な確度の入力が予測値を押し上げないよう、ステージを変えるには、提案書の提出や決裁者の確認などの条件を設けます。
週次会議では、目標との差や前週から変わった案件を確認します。加えて、停滞案件と次の行動も見ます。
月次では、予測と実績の差を振り返り、ステージ別成約率や受注予定日のずれを調整します。
システムの監視で終わらせず、数字で行動を変える会議が定着の中心です。
PoCからの段階的な展開
導入は工程を分け、PoCから本番へと段階的に進めます。PoCは、1部門か1商品に絞って検証します。
- 要件の整理
- データの診断
- PoCの実施
- 本番設計
- データ移行と利用者の教育
- 稼働の支援
PoCでは、予測値と実績、入力時間を試します。画面の理解度やマネージャーの確認方法も、確かめる対象です。
標準的なSaaS設定の期間は1〜3か月です。パッケージ拡張は3〜9か月、複数事業部の予測基盤は6〜18か月が目安です。
独自開発は12〜24か月以上となる可能性があります。期間はデータの準備状況で前後します。
- 本番化しない場合：予測対象の定義や過去データの不足、入力負担、権限・連携の不一致を記録します。
PoCの結果が良くても、全社展開の権限設計や運用責任者は、別途見積もります。保守費やデータ移行は、別の項目として扱います。
AI予測の説明可能性と検証方法
AI予測は、受注確度や失注リスクを見つけるための補助機能です。Microsoft Learnは、目標の達成状況やパイプラインのリスクの把握に使えると説明しています。
同じ資料は、個人評価や報酬など雇用に影響する判断への利用を想定しない注意も示しています（出典: Microsoft Learn「組織で予測を構成する」、2026年8月確認）。
営業担当者の監視や通話記録を扱う場合は、法務・労務と利用目的を確認します。あわせて、通知や同意、保存期間、利用範囲も確かめます。
- 説明情報：主要な入力要因、データ取得時点、モデル版、人による修正履歴
- 評価指標：平均絶対誤差、更新率、誤差の偏り、警告後の行動、会議時間の組み合わせ
- 履歴が少ない場合：加重パイプラインで基準値を作り、実績蓄積後に時系列モデルや機械学習を比較します。
営業予測システムのよくある質問
発注前には、費用や開発期間のほか、データ、契約、導入後の運用についても疑問が出てきます。外注を検討する企業からの質問に、判断の軸が分かるように答えます。
営業予測システムの開発費用はいくらですか？
標準SaaS設定は初期費用0〜100万円程度です。移行や外部連携を加える場合は、100〜800万円程度が目安です。
CRMの大規模カスタマイズは500〜3,000万円程度、DWH・BI・複数事業部連携は1,500〜5,000万円程度です。
フルスクラッチは5,000万円〜2億円超になる可能性があります。営業予測単体の公式統計ではないため、見積もりを取る際は、連携先やデータ品質、対象部門を添えます。加えて、AIや保守の条件も伝えます。
過去のExcelやSFAのデータでも営業予測できますか？
利用できますが、そのまま取り込めるとは限りません。顧客・案件IDの重複や金額単位を確認します。日付の形式やステージ名も、取り込み前に確かめます。
失注や延期の記録、担当者の表記揺れも確認し、移行前にクレンジングします。過去データが少ない場合は、AI予測の導入を急がないようにします。
まずは、加重パイプラインと実績の差を記録します。そのうえで、日々の運用で予測に使うデータを蓄積していきます。
契約形態は準委任と請負のどちらが良いですか？
要件整理やPoCなど、検証しながら変わる工程には準委任が向いています。一方、仕様と完成物を固定しやすい設定・開発・移行には、請負が適しています。
要件定義を準委任、本開発を請負、稼働後を保守契約に分ける組み合わせもあります。契約名よりも、成果物と検収の条件を明確にすることが大切です。加えて、変更管理や知的財産、障害対応、再委託の条件も定めます。
AI予測の精度を発注時に保証してもらえますか？
将来の受注を完全に言い当てることはできません。そのため、精度を断定して保証するより、評価条件と改善手順を契約やRFPに定めておく必要があります。
入力データの期間や、学習と検証の分け方、評価指標を確認します。許容誤差やモデルの更新頻度、予測根拠と人が修正した場合の記録も、対象に含めます。
予測を人事評価や報酬には直接使わず、営業マネージャーの判断を補助する範囲から始めるのが安全です。
まとめ
発注では予測対象とKPIを決め、顧客・案件・売上実績を洗い出します。SaaSやCRM拡張、DWH・BI連携、スクラッチのうちから、必要な範囲を選びます。
発注時に押さえるべき要点
RFPには、業務と範囲、連携、移行を書きます。加えて、権限やセキュリティ、成果物を記載し、検収と保守も書き添えます。そのうえで、各社に同じ条件で提示します。
見積は、ライセンスや要件定義、設定・開発に分けて確認します。移行や連携、教育の費用は導入作業として分けて、AIと保守も個別の項目として扱います。初期費用だけでなく、3年または5年の総額で比べます。
工程の不確実性に応じて、準委任と請負を使い分けます。また、変更管理とデータ返却の条件も確認します。
最初の相談で伝えるべき内容
初回相談では、自社の規模やデータ環境を共有します。あわせて、導入の目的と希望条件も伝えます。
- 営業規模：営業人数、案件数、商談期間、事業部数
- 既存環境：SFA・CRM、Excel、基幹システムとデータの所在
- 目的と体制：予測指標、困っている会議・作業、社内の運用担当者
- 希望条件：希望時期、PoCの可否、標準機能の範囲、将来の拡張費用
営業予測システムは、AIを導入する案件というより、営業データを使って判断と行動を変えるプロジェクトとして設計することが成功への近道です。
▼全体ガイドの記事
・営業予測システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。