SaaS型BtoB-ECの限界と選び方｜カスタマイズ型との5年TCO比較・構造適合で判断する4つの軸

「BtoB-ECはまずSaaSで始めるのが無難ではないか」

導入を検討する企業の多くがこの判断をします。SaaSは初期費用が安く・短期間で立ち上げられ・サーバー管理も不要という大きなメリットがあり、合理的な選択肢の一つです。

しかし、BtoB特有の受注要件が増えてくると、SaaS型は構造的な限界に直面します。本記事では、EC-CUBE構築とBtoB-EC専門として製造業・卸売業の案件に携わってきた立場から、SaaS型の4つの限界とカスタマイズ型との違い、失敗しない判断基準を解説します。

最初に明確にしておきたいのは、SaaS型が悪いわけではない、ということです。むしろ以下に該当する企業ではSaaS型が最適解となります。

問題は、上段の特徴を持つと判断してSaaSを選んだ後、運用しながら要件が複雑化し、下段の状態に変化してしまうケースです。これがSaaS型の「構造的な壁」と表現される所以です。

典型症状：「価格設定アプリを2つ追加したが、まだ表現できない条件がある」

BtoB-EC最大の論点は価格管理です。以下のような複合条件が増えると、SaaSの標準機能や1つのアプリでは対応しきれません。

• 顧客別掛率（例：Aランク70%、Bランク75%、Cランク80%）
• 商品別契約単価（顧客ごとに特定商品だけ固定単価）
• 数量別値引き（100個以上で5%引き、500個以上で10%引き）
• 期間限定条件（キャンペーン期間中のみ別単価）
• これらの優先順位とルール

SaaSでもアプリや拡張機能で一部対応できますが、条件が増えるほど以下のような運用になります。

• アプリの追加で月額費用が積み上がる
• タグ管理が複雑化する（タグの優先順位が読めない）
• 会員区分を乱立させる（顧客が増えるたびに区分追加）
• 複数アプリの計算順序が衝突する

その結果、価格表示の不整合・単価問い合わせの増加・管理負担の増加が発生します。価格が複雑な企業ほど、SaaSの限界に早く到達します。

典型症状：「ECを導入したのに、結局電話とメールが減らない」

BtoBの現場では、以下のような例外が日常的に発生します。

• ロット割れ対応（発注数量と倉庫実態の調整）
• 分納指示（1回の注文を複数回に分割）
• 納期変更・前倒し依頼
• 後日の単価修正（値引き交渉の遡及適用）

SaaS標準機能でこれらを吸収できないと、電話フォロー・メール確認・管理画面での手修正が残ります。結果として「ECはあるが電話は減らない」という構造になり、BtoB-EC導入の本来の目的である「受注業務の削減」が達成されません。

この問題は「標準機能だけで始める」選択でも同様に発生します。詳しくはBtoB-EC「標準機能だけ」で失敗する3つの落とし穴で解説しています。

典型症状：「在庫表示が遅れて、欠品クレームが発生する」

BtoB-ECでは、基幹との連携設計が成果を左右します。理想的には以下のリアルタイム連携が必要です。

• 在庫のリアルタイム連携（複数倉庫対応）
• 受注データの即時連携
• 請求・与信管理との連携
• 顧客マスタ・商品マスタの同期

SaaSではAPI制約や仕様制限により、CSV手動連携・データ加工・突合確認といった作業が残ることがあります。連携が浅いと、在庫確認・納期確認の問い合わせ対応が消えません。

基幹連携の具体的な費用感はBtoB-EC構築の費用相場で解説しています。

典型症状：「2年運用したら、アプリ構成が複雑すぎて誰も全体を把握していない」

事業成長に伴い、顧客数増加・価格条件増加・商品数増加が起こります。SaaSではこれに対応するために以下が発生します。

• アプリ構成が複雑化（5〜10個のアプリが連携）
• 管理画面運用が煩雑化（担当者が変わると引継ぎ困難）
• アプリ間の競合・アップデート影響への対応負担
• 移行を検討した時点で、データ・運用ともに動かしにくい状態

「最初は十分だったが、後から限界に気づく」ケースは少なくありません。気づいた時点では、移行コストが高額化しているのが厄介な点です。

SaaS型は初期費用が安い反面、月額費用が永続します。一方カスタマイズ型は初期費用が高い反面、月額費用が抑えられます。5年TCOで比較すると逆転するケースが多いのが実態です。

初期費用は4倍違っても、5年TCOではカスタマイズ型の方が約580万円安くなる結果になります。SaaSの月額費用が永続することと、運用人件費の累積が逆転を生む構造です。

「最初はSaaSで安く始めて、必要になったらカスタマイズ型に作り直せばよい」という考え方は、一見合理的に見えます。しかし、実際には以下の移行コストが発生します。

これらを合算すると、移行だけで300〜600万円の追加負担が発生します。さらに、取引先がSaaSの操作に慣れた状態から新システムへ移行する際の心理的負担・離反リスクは数値化しにくいコストです。

受注構造がシンプルな企業や検証フェーズの企業ではSaaS先行→移行も合理的ですが、要件が最初から複雑な企業では、最初の選択を慎重にする方が結果的に安く済むケースが多いです。

SaaSかカスタマイズかという「方式」の比較ではなく、自社の受注構造に適しているかどうかで判断するのが正しいアプローチです。そのために整理すべき4つの軸を提示します。

1. 1

   受注フローの可視化

   現状の受注業務を工程ごとに分解し、どこで時間がかかっているか・どこでミスが発生しているかを定量化します。改善効果が最も大きいポイントが、投資すべき箇所です。

2. 2

   価格ロジックの明文化

   掛率・契約単価・数量別価格の全パターンを言語化します。条件分岐が3つ以上ある場合、SaaSだけでの対応は厳しいと判断できます。

3. 3

   例外処理の棚卸し

   月次の例外処理発生件数・種類をリスト化します。頻出例外が10件/月以上ある場合、SaaSの運用負担は無視できないレベルになります。

4. 4

   基幹連携要件の整理

   在庫・受注・請求の”正”（マスターデータ）がどこにあるか、リアルタイム性が必須かCSV手動連携で十分かを明確にします。これが曖昧だと、後の設計が破綻します。

この順番を飛ばして「方式」から選ぶと、選定後に「想定していなかった要件」が次々と出てきて後悔します。

以下のチェックで3つ以上当てはまる場合、SaaS型では構造的な限界に直面するリスクが高い水準です。

• 顧客別の掛率が3段階以上ある
• 商品ごとの個別契約単価がある
• 数量別価格と契約価格が併存している
• 分納・ロット指定・納期調整が月10件以上発生する
• 基幹システム（販売管理・ERP）とのリアルタイム連携が必要
• 掛売・与信・締め請求が必須
• 取扱商品数が3,000点を超える（または近い将来到達）
• 3年後に取引先数が現在の1.5倍以上になる計画がある

これらに3つ以上該当する場合は、SaaS型のアプリ追加で対応するよりも、最初からカスタマイズ型（EC-CUBE等）を検討する方が5年TCOで合理的になる可能性が高いです。