SFAをAIでスクラッチ開発すべきか？｜パッケージとの比較、費用・期間・成功条件を徹底解説

既存のSFAに限界を感じ、「自社の営業フローに特化したシステムをAIで一から作れないか」と検討し始めた方は少なくありません。AI技術の進化によって、スクラッチ開発という選択肢が以前より現実的に見えるようになったことも、その背景にあります。ただし、費用・期間・保守体制・失敗リスクを正確に把握しないまま開発に踏み込むと、想定外のコストと時間を要する可能性があります。

本記事では、SFAをAIでスクラッチ開発する選択肢の実態を、パッケージ導入との比較・費用と期間の目安・失敗パターン・成功条件という4つの軸で整理します。本記事ではスクラッチ開発という選択肢に絞って深掘りします。SFA選びの全体像について確認したい方は、こちらを参考にしてください。

SFAをAIで開発する選択肢はどこから生まれるのか

スクラッチ開発を検討するきっかけの一つが、「既存のパッケージSFAでは自社の要件を満たせない」という不満です。ただし、その不満が本当にパッケージの限界に起因するのか、設定や運用の問題に起因するのかを切り分けることが先決です。スクラッチ開発の検討は、その確認ステップを経た後に置くべき選択肢です。

既存SFA・パッケージ製品への不満が出発点になるケース

現場で挙がりやすい不満には、次のようなものがあります。

• 自社の営業フェーズ設定がパッケージの標準と合わず、使いにくい
• 入力項目が固定されていて、自社固有の管理項目を追加できない
• AI機能が画一的で、自社の顧客特性や受注パターンに対応していない
• 他の基幹システムとのリアルタイム連携ができない

これらの不満がスクラッチ開発の検討につながるケースはありますが、注意が必要です。パッケージSFAのカスタマイズ範囲は製品によって異なり、「パッケージでは無理」と判断する前に、ベンダーへの詳細確認や設定の見直しで解決できるケースもあります。「パッケージが要件を満たせない」という前提自体を再検証することが、スクラッチ開発を検討する前に行いたい作業です。

「SFAのAI開発」が指す範囲の整理

「SFAをAIで開発する」という表現は、実態として3つの異なる選択肢を含んでいます。これらを混同すると判断を誤るため、まず明確に区別します。

1. フルスクラッチ開発 ゼロから自社専用のSFAを構築する。開発・保守・AI機能の更新まで自社または委託先が担う
2. パッケージへのAI機能追加・カスタマイズ 既存のパッケージSFAにカスタム開発でAI機能を組み込む。ベースはパッケージが担い、AI部分のみを追加する
3. パッケージSFA＋外部AI連携 パッケージSFAとLLM APIや外部AIツールをAPI・iPaaS経由で接続する。スクラッチ開発なしにAI機能を追加する方法

本記事では主に①（フルスクラッチ開発）と③（パッケージ＋外部AI連携）の比較を中心に扱います。②はその中間に位置する選択肢として適宜触れます。

なお、SFAとは「Sales Force Automation（営業支援システム）」の略で、案件管理・営業活動の記録・レポート生成など、営業組織の活動を効率化・可視化するためのシステムを指します。

スクラッチ開発とパッケージ導入の根本的な違い

スクラッチ開発とパッケージ導入は「自由度と速度のトレードオフ」と説明されることが多いですが、実態はそれだけではありません。運用フェーズのコスト構造・AI機能の更新頻度・組織内の保守体制の有無なども、長期的な意思決定を左右します。以下では4つの軸で両者を比較し、どちらがどのような組織に向くかを整理します。

自由度と初期コストの関係

フルスクラッチ開発の利点の一つは、要件定義どおりに作れる点です。営業フェーズの定義・入力項目・AI機能の仕様を自社の要件に完全に合わせられます。ただし、この自由度は同時にリスクでもあります。設計ミスのコストが自社側の負担になりやすいことに加え、「自社に最適な要件」を正確に定義できる組織は実際には多くありません。

パッケージは、カスタマイズ範囲に上限がある代わりに、あらかじめ用意された標準機能や設計を利用できます。「自由度が高い＝成果につながる」ではなく、自由度を活かすには精度の高い要件定義が前提です。要件定義のスキルと時間を持たない組織がスクラッチ開発を選んでも、自由度を十分に活かせない可能性があります。

AI機能の更新・維持コストの違い

生成AIや機械学習モデルは継続的に更新されています。フルスクラッチ開発では、モデルのアップデート・再学習・APIバージョン変更への対応コストが全て自社負担になります。1年後に新しいLLMが登場して従来モデルが陳腐化した場合、その対応も自社で行う必要があります。

パッケージSFAは、AI機能の開発・更新をベンダー側が担うケースが一般的です。ユーザーはライセンス費用を支払うことで、ベンダーが提供するAI機能の更新を利用できます。一方、更新内容やタイミングを自社で自由に決められない点は、パッケージ側の制約になります。「開発した時点のAIで止まるリスク」は、フルスクラッチ開発で考慮しておきたい論点の一つです。

データ蓄積と学習精度の問題

AIの精度は、利用するAIの方式によっては、学習に使うデータの量と質に左右されます。自社専用のAIモデルを機能させるには、十分な量の営業活動履歴・案件データが社内に蓄積されていることが前提です。受注予測モデルを実用的な精度で動かすためには、一般に数百から数千件以上の案件データが必要です。

組織の規模が小さい場合や、SFAの運用歴が浅い場合は、学習データが不足してAI機能が実質的に機能しない可能性があります。パッケージSFAは、複数ユーザー企業のデータをもとに学習・改善されたモデルを持つ場合が多く、自社のデータ量が少なくても一定の精度を担保しやすい構造になっています（ただし製品によって設計は異なります）。

導入後の定着と現場負荷

「自社専用だからこそ現場に合う」という期待でスクラッチ開発を選ぶケースがありますが、UI・UX設計が十分でなければ、使いにくいシステムになるリスクがあります。優れたUI設計には多くの試行錯誤と専門知識が必要で、業務システムの開発経験があっても営業向けUXの最適化は別途検討が必要です。

パッケージSFAは、複数の利用企業から得たフィードバックなどをもとにUIを改善している製品もあります。定着率の観点では、完成度の高いパッケージUIが有利なケースが多いといえます。現場の定着が最優先課題である組織では、この点は特に重要な判断軸になります。

お役立ち資料

SFA/CRM分類チャート 4つのタイプ

国内の主要SFA/CRMを「入力負担」と「運用定着」の観点で4タイプに分類。選定の時間を短縮できます。

資料をダウンロードする

SFAスクラッチ開発の費用・期間の実態

スクラッチ開発の費用・期間は、機能範囲・AI機能の複雑さ・開発体制によって大きく変わります。そのため、一般的な金額や期間だけで判断するのではなく、要件ごとに見積もる必要があります。以下では、費用を考える際の項目と開発フェーズの流れを整理します。

初期開発費用の概算レンジ

SFAをフルスクラッチで開発する場合の費用は、機能の範囲と複雑さによって異なります。主な費用項目は次のとおりです。

• 基本機能のみ（案件管理・アクション記録・レポート）：概ね500万〜1,500万円程度
• AI機能を追加する場合（自然言語処理・受注予測・自動要約など）：さらに500万〜数千万円規模が加わることが多い
• クラウドインフラ費用、セキュリティ対応コスト、外部API接続コストは別途発生する場合がある
• 初期の「簡単なものを安く作る」という想定でも、要件定義後に必要な機能が増え、見積もりが大きくなる場合があるため、予備費も含めて検討する

特にAI機能の開発費用は、使用するモデルの種類・学習データの量・精度目標によって大きく変わります。既製のLLM APIを組み合わせる場合は比較的コストを抑えられますが、自社固有のモデルを学習させる場合はデータ整備からコストが発生します。

開発期間の目安と見落とされがちなフェーズ

フルスクラッチ開発は、一般に次のようなフェーズで進みます。

• 要件定義 1〜3か月。この工程の質が開発全体の成否を左右します
• 設計・開発 3〜9か月
• テスト・データ移行・リリース準備 1〜3か月
• AIモデルの学習・チューニング 独自モデルや予測モデルを利用する場合は、精度検証や調整を行う

必要な期間は、要件・開発人数・既存システム連携・AI機能の方式などによって大きく異なります。数か月で構築できるケースもあれば、1年以上を要するケースもあります。

要件定義に割く時間を短縮しようとする組織ほど手戻りが発生し、結果として全体の期間が延びます。「急いで作ったが使えないシステムになった」という事例の多くは、要件定義フェーズの圧縮が原因です。

TCO（総所有コスト）で比較する

初期費用だけを比較してスクラッチ開発を選ぶと、後のコストで想定外の負担が生じます。5年間のTCOで試算すると、パッケージとの差が縮まるか逆転するケースが多いのが実態です。スクラッチ開発で5年間にわたって発生する主なコスト項目は次のとおりです。

• 保守・運用コスト 社内エンジニアの人件費、または外部委託費（年間数百万〜数千万円規模）
• AIモデルの更新・再学習コスト 独自モデルを利用する場合のモデル更新、精度劣化（ドリフト）対応
• 機能追加・改修コスト 営業プロセスの変更、組織変更、新しい要件への対応
• セキュリティ対応・法改正対応コスト 定期的な脆弱性対応、個人情報保護法等への対応

パッケージSFAの場合、上記の一部をベンダー側が担い、ユーザー側はライセンス費用を継続的に支払う代わりに保守コストの大部分を外部化できます。「初期費用ゼロのパッケージ vs. 初期費用1,000万円のスクラッチ」という初期費用だけの比較では、判断を誤ります。意思決定前には、一定期間のTCOを比較することが重要です。

スクラッチ開発を選ぶべきケース・やめるべきケース

スクラッチ開発が合理的な選択になるケースは、実際には限られています。「他社と差別化したい」「自社固有の要件がある」という理由だけでは判断できず、組織の開発・保守体制と要件の独自性などを合わせて検討する必要があります。

以下では、条件を明確にして判断基準を示します。自社の規模感に合ったSFAの選び方については、規模別のSFA選び方も参考になります。

スクラッチ開発を優先すべきケース

以下の条件が複数そろっている場合は、フルスクラッチ開発の検討が合理的な選択肢になります。

• 自社の営業プロセスがパッケージの標準的な設計では対応しにくく、カスタマイズでは対応が難しいことをベンダーに確認済みである
• 社内に専任のエンジニアチーム、またはAI開発の知見を持つ外部パートナーが確保できている
• 開発完了後の保守・運用を継続的に担える体制（人材・予算）がある
• 機密性の高い顧客データを自社環境外に置けない要件がある（セキュリティ・コンプライアンス上の制約）
• 長期利用を前提に、TCO試算でパッケージより優位になることが数値で確認できている

これらの条件が多く揃っているほど、スクラッチ開発を検討しやすくなります。条件が十分に整理されていない状態でスクラッチ開発を開始すると、途中での計画変更やコスト超過につながる可能性があります。

スクラッチ開発をやめるべきケース

以下に当てはまる場合は、パッケージ導入または外部AI連携の検討を先に行う方法があります。

• 「自社に合ったシステムが欲しい」という理由のみで、具体的な要件がまだ言語化されていない
• 社内に開発・保守を担えるエンジニアリソースがなく、外部委託の予算・体制も定まっていない
• 半年以内での稼働を求めている
• 組織としてSFAを活用するのが初めてで、何のデータを蓄積すべきかがまだわかっていない
• 現場営業担当者のITリテラシーが低く、定着率の確保が最優先課題である

「自社に合ったシステムを作りたい」という考え自体は自然ですが、SFAを使ったことがない状態では「自社に合った要件」を具体化しにくい場合があります。まずパッケージで運用を始め、実際に使いながら課題を明確にしてから、必要に応じてカスタマイズや開発を検討するアプローチも選択肢の一つです。

「パッケージ＋外部AI連携」が最初の現実解になることが多い理由

スクラッチ開発とパッケージ導入の二択で迷っている場合、「パッケージSFA＋外部AI連携」も有力な選択肢になります。

APIやiPaaS（ノーコード連携ツール）に対応しているパッケージSFAは、これらを経由して外部AIツールと接続できます。LLM（大規模言語モデル）APIを組み合わせることで、議事録の自動要約・メール文面の生成・次アクションの提案・商談内容の分類といった機能を、SFAそのものをフルスクラッチで構築せずに追加できる可能性があります。

例えばMazrica SalesのようなSFA/CRMでは、AIアシスタント機能（案件の活動履歴の自動要約・次アクションの提案）を標準で備えるほか、iPaaS・API連携を通じて外部ツールとの接続も可能です。自社でAI開発を行わずに、営業活動へのAI活用を実現できる仕組みの一例です。業種固有の要件については業種別のSFA選び方も参照してください。

スクラッチ開発の失敗パターンと成功条件

SFAをスクラッチ開発する際に起こりやすい失敗の多くは、技術的な問題ではなく「要件定義の甘さ」と「運用フェーズの想定不足」に起因します。スクラッチ開発を進めるうえで押さえておきたい条件を、実務の粒度で整理します。

失敗パターン①：AI機能への過大な期待と要件定義の発散

「AIが勝手に分析して営業判断を助けてくれる」という期待だけで、具体的な要件を定めないまま開発を開始するケースがあります。AI機能の開発には「何のデータを使い」「何を予測または生成し」「誰がどのような場面でどのように使うか」までを明確にした要件定義が必要です。

この定義が曖昧なまま開発会社に発注すると、双方の認識ズレが手戻りを生みます。開発中盤で「これは求めていたものと違う」と判明すると、大幅な仕様変更や追加開発が必要になることもあります。AI機能の要件定義には、システム開発の経験だけでなく、営業業務への理解も必要です。

失敗パターン②：現場の入力を前提とした設計で定着しない

スクラッチ開発では入力項目を自由に設計できるため、「管理したい情報」を全て入力項目として追加しようとする傾向があります。経営企画やマネージャーが欲しいデータを全て入力させようとした結果、現場の営業担当者の入力負荷が過大になるケースが典型的な失敗パターンです。

入力が定着しないとデータが蓄積されず、AIが機能しないという悪循環に入ります。スクラッチ開発の設計段階で「何を自動入力・自動補助できるか」に加え、「本当に入力が必要な項目は何か」を検討することが重要です。「自社専用だから合うはず」という期待と、実際の現場負荷は別の問題です。

失敗パターン③：リリース後の保守・更新コストの過小評価

リリース後に法改正・組織変更・営業プロセスの見直しが発生すると、スクラッチ開発のシステムでも必要に応じて改修が発生します。内製エンジニアがいる場合でも対応工数がかかり、外部委託の場合は改修内容に応じて費用と時間が発生します。

AIモデルのドリフト（データの変化による精度劣化）への定期的な対応も必要です。使い始めた当初は機能していた受注予測が、半年後には精度が落ちているというケースも実際に起きています。リリースがゴールではなく、運用・改善のサイクルを回し続けるコストを含めて計画する必要があります。

成功条件のまとめ

スクラッチ開発を進める際に確認したい条件は次のとおりです。

• 要件定義に十分な時間（1〜3か月）と現場の営業担当者・マネージャーの参加を確保できている
• 「システムオーナー」として開発後の保守を担う社内の担当者を設置できている
• スモールスタート（特定の機能・特定のチームに限定してリリース）で仮説検証してから拡張する計画がある
• 開発ベンダーの選定で「AI開発の技術実績」と「営業業務への理解」の両方を評価している
• TCO試算を行い、長期的な費用対効果をパッケージと比較できている

これらの条件を全て満たせる組織でなければ、スクラッチ開発は合理的な選択になりにくいのが実態です。

パッケージSFAのAI機能で対応できる範囲

スクラッチ開発を検討する前に、現在のパッケージSFAのAI機能でどこまでカバーできるかを正確に把握することが先決です。「パッケージでは自社要件を満たせない」という判断は、実際の機能範囲を詳細に確認した後でなければ根拠のある判断になりません。このステップを省くと、パッケージで対応可能な要件までスクラッチ開発の対象にしてしまう可能性があります。

パッケージSFAに実装されているAI機能の代表的な種類

主要なパッケージSFAが備えているAI機能の種類は次のとおりです。製品によって実装されている機能の範囲は異なります。

• 案件・活動履歴の自動要約と次アクション候補の提案
• 受注確度予測・売上予測（AIフォーキャスト）
• 重複データの検知・名寄せ候補の提示
• 入力補助（音声・テキストからの入力項目更新の提案）
• 議事録の自動生成・商談ログのテキスト化
• リードスコアリング（見込み顧客の優先順位付け）

これらの機能は、多くの営業組織がスクラッチ開発に求めるAI活用場面をカバーしています。「AI機能付きSFAが欲しい」という要件であれば、パッケージの既存機能で対応できるケースが多いといえます。

パッケージのAI機能では対応が難しいケースの見極め方

次のいずれかに該当する場合は、パッケージの標準AI機能では対応が難しい可能性があり、スクラッチ開発またはハイブリッド構成（パッケージ＋カスタムAI）の検討が選択肢になります。

• 自社固有の判断ロジック（特定業種・特定顧客の受注パターン）を学習した専用モデルが必要
• 自社のERPや基幹系システムと独自の形式でリアルタイム連携する必要がある
• セキュリティ要件上、営業データをクラウド環境に置けない

これらのいずれにも当てはまらない場合は、パッケージのAI機能または外部AI連携で対応できる可能性が高いです。まずベンダーに詳細確認を行うことを推奨します。クラウド型・オンプレミス型SFAの違いについては別記事でも整理しています。

選び方の判断フレームワーク

スクラッチ開発かパッケージかという選択は、一つの整理方法として、「自社の営業プロセスの独自性」と「社内の開発・保守体制の有無」という2軸で整理できます。この2軸を使った判断マトリクスと確認チェックリストを以下に示します。

2軸で整理する判断マトリクス

判断の基準軸は次の2つです。

• 横軸（要件の独自性） 自社の営業プロセスが一般的なSFAで対応しやすいか、独自要件が多いか
• 縦軸（開発・保守体制） 社内に開発・保守を担う体制があるか、ないか

この2軸で4象限に分類すると、各象限での検討候補は次のとおりです。

• 独自性が低く、体制がない パッケージ導入を選ぶ。多くの組織がこの象限に当たります
• 独自性が低く、体制がある パッケージ＋外部AI連携を選ぶ。社内エンジニアがAPI連携で必要な機能を追加する
• 独自性が高く、体制がない パッケージのカスタマイズ範囲を先に確認する。スクラッチ開発は最終手段
• 独自性が高く、体制がある スクラッチ開発も有力な選択肢になる。ただしTCO試算を行ったうえで判断する

チェックリスト形式で自社の状況を確認する

スクラッチ開発の検討を進める前に、以下の項目を確認してください。「はい」と答えられない場合は、パッケージまたはパッケージ＋外部AI連携も含めて比較することを推奨します。

• 「パッケージで対応できない要件」を具体的に言語化できているか
• AIモデルの学習に足りるデータ量（営業活動履歴・案件データ）が社内に蓄積されているか
• 開発ベンダーの選定基準（営業業務知識＋AI開発実績）が定まっているか
• 5年間のTCO試算でパッケージより優位になることが数値で確認できているか
• スモールスタートで段階的に拡張する計画があるか

まとめ：スクラッチ開発を選ぶ前に確認すべきこと

SFAをAIでスクラッチ開発するという選択肢は、条件が揃えば合理的ですが、パッケージ＋外部AI連携を含めた他の方法と比較したうえで判断することが重要です。

スクラッチ開発が向く組織は、パッケージでは対応しにくい独自要件を持ち、社内に継続的な保守体制があり、長期TCO試算でもスクラッチ開発を選ぶ合理性を確認できる組織です。

パッケージ導入が向く組織は、要件の独自性が標準的なレベルにある、開発・保守体制がない、短期間での稼働が必要、現場定着を優先したいという組織です。こちらが大多数の組織の実態に近いといえます。

スクラッチかパッケージかの判断に迷った場合、最初に取るべき行動は「パッケージSFAのカスタマイズ・API連携でどこまで対応できるかをベンダーに確認する」ことです。その確認を経た上でなお要件が満たせない場合に、スクラッチ開発またはハイブリッド構成の検討に進むのが一つの進め方です。

SFAの選び方・比較の全体像では、評価軸・他の比較観点を体系的に整理しています。営業モデル別のSFA選び方も合わせて参考にしてください。

よくある質問

Q SFAをスクラッチ開発するといくらかかりますか？

A

基本機能（案件管理・アクション記録・レポート）のみで概ね500万〜1,500万円程度が目安です。AI機能（自然言語処理・受注予測・自動要約など）を追加する場合はさらに500万〜数千万円規模が加わることが多く、インフラ・セキュリティ・外部API接続コストは別途発生する場合があります。初期費用だけでなく、保守・運用・AIモデル更新コストを含めた5年間のTCOでパッケージと比較することを推奨します。

Q SFAのスクラッチ開発にはどのくらいの期間がかかりますか？

A

要件定義（1〜3か月）・設計と開発（3〜9か月）・テストとリリース準備（1〜3か月）など、要件や体制によって大きく異なり、AI機能を含めると1年以上かかるケースもあります。AIモデルの学習・チューニングを含めると1年以上になるケースもあります。要件定義フェーズを短縮しようとすると手戻りが増え、結果として全体の期間が延びます。

Q パッケージのSFAとスクラッチ開発のSFAはどう違いますか？

A

最大の違いはコスト構造と更新の主体です。パッケージはライセンス費用が継続しますが、保守・セキュリティ対応・AI機能の更新などベンダー側が担う部分が大きくなります。スクラッチ開発は設計の自由度が高い反面、保守・AI更新・機能追加にかかるコストが全て自社負担になります。長期的なTCOでは、スクラッチ開発のコストがパッケージを上回るケースが多いです。

Q 既存のパッケージSFAにAI機能を後から追加できますか？

A

APIやiPaaSに対応しているパッケージSFAでは、外部AIツールと接続できる場合があります。議事録の自動要約・次アクション提案・メール文面の生成といった機能は、スクラッチ開発なしに追加できるケースが増えています。どこまで対応できるかは製品によって異なるため、ベンダーに具体的な要件を伝えて確認することを推奨します。

Q SFAをスクラッチ開発するとき、失敗しやすいポイントはどこですか？

A

注意したいポイントは、「要件定義の甘さ」と「リリース後の保守コストの過小評価」です。要件定義では、AI機能への過大な期待や入力項目の過多が問題になりやすいです。また、リリース後に法改正・組織変更・営業プロセスの見直しが発生するたびに改修コストが発生する点を、計画段階で見落とすケースが多いです。現場営業担当者を要件定義に参加させ、スモールスタートで検証することが有効です。

Q 中小企業でもSFAをスクラッチ開発するメリットはありますか？

A

中小企業にはパッケージ導入またはパッケージ＋外部AI連携を先に検討することを推奨します。スクラッチ開発の初期費用・保守体制の確保・AI学習に必要なデータ量の確保は、一定規模以上の組織でなければ合理的なTCOになりにくいのが実態です。中小企業の場合は、まずパッケージで運用を開始し、データを蓄積しながら本当に必要な要件を明確にしてから拡張を検討する進め方が現実的です。