BtoB ECカートシステムの選定｜方式の見極めと5段の進め方

◆監修・編集責任者　小園 将隆　2026年8月17日

B2B EC-COLUMN

BtoB ECカートシステムとは、法人取引の条件をそのまま載せるEC構築基盤である

BtoB ECカートシステムとは、法人間取引の受注をWeb上で成立させるためのEC構築基盤です。取引先ごとに異なる価格・与信・承認の条件をシステム上で再現できる点で、BtoC向けカートと区別されます。経済産業省の調査では2024年のBtoB-EC化率が43.1%に達しており^*1、選定を検討する企業はすでに少数派とは言えない状況です。

BtoC向けカートとの決定的な違い

BtoC向けカートは、不特定多数の消費者に同一価格・都度決済で販売する前提で設計されています。これに対しBtoB ECカートシステムは、取引先別の価格・掛率、掛売や与信限度、承認フロー、複数納品先への分納といった商習慣を扱う点が異なります。この違いを起点に置かないと、機能一覧表だけを見比べても判断軸が定まりません。

いま選定が問われる理由 — BtoB-ECのEC化率は43.1%

経済産業省 商務情報政策局 情報経済課の令和6年度電子商取引に関する市場調査によると、2024年のBtoB-EC市場規模は514兆4,069億円でした^*1。前年比では10.6%増となっています^*1。EC化率は43.1%で前年比3.1ポイント増となっており^*1、企業間取引の電子化はすでに珍しい取り組みではなくなっています。選定を先送りする理由は、以前より小さくなっていると言えます。

この記事が扱う範囲と、扱わない範囲

本記事は、要件がある程度固まった後に、方式を絞り込み候補を落としていく「選定」の工程に絞って扱います。要件そのものの洗い出し方は別記事に、価格の実額やTCOの試算は別記事に譲るのが本記事の役割分担です。選定後の移行手順についても、別記事で扱う範囲とし、本記事では選定時点でどこまで確認しておくべきかにとどめます。

選定を始める前に固めておく3つの前提

候補を比較する前に、対象取引の範囲・変えない商習慣・決める体制という3つの前提を固める必要があります。この3つは、どこまでを対象にするか・何を変えないか・誰がいつ決めるかという、比較の土俵そのものを決める前提です。

対象取引の範囲を決める

まず、全取引先を対象にするのか一部の取引先から始めるのか、全商品を扱うのか定番品に絞るのかを線引きします。対象範囲が曖昧なまま候補を集めると、ベンダーごとに前提が異なる提案が返ってきて比較が成立しません。

変えない商習慣を先に決める

次に、自社が変える気のない商習慣を先に決めます。取引先別の価格体系や締め支払いのルールなど、譲れない条件を明示しておかないと、確認する機能のほぼすべてが「要カスタマイズ」という回答に流れてしまいます。この非交渉領域こそが、選定の判断軸そのものです。

決める人と期日を明確にする

最後に、誰がいつまでに決めるかを明確にします。どの段階で誰が何を判断するかは、決裁者・現場の実務担当・情報システム部門の3者で事前にすり合わせておくべき事項です。そうすることで、後段のRFPやデモの段階で判断が滞る事態を避けられます。

カートの構築方式は5つ。最初にここを絞る

BtoB ECカートシステムの構築方式は、ASP・SaaS型、クラウドEC型、パッケージ型、オープンソース型、フルスクラッチ型の5つに大きく分かれます。自社がどの方式を探しているかを最初に絞らないと、比較する候補群がそもそもかみ合いません。

5方式の性格

ASP・SaaS型は、提供者が用意した標準機能の範囲内で運用する方式です。クラウドEC型は、クラウド基盤の上で設定や拡張機能によって商習慣を表現していく方式にあたります。パッケージ型は、既存の製品をベースに自社仕様へカスタマイズする方式であり、オープンソース型はソースコードを自社またはパートナーが直接改変できる方式です。フルスクラッチ型は、要件に合わせてゼロから設計・開発する方式を指します。

方式を分ける2つの分岐 — 商習慣の再現度と改修の自由度

5方式を分ける軸は、大きく2つです。第一に、取引先別価格や掛売といった自社の商習慣を、標準機能でどこまで再現できるかという「商習慣の再現度」です。第二に、稼働後に仕様を変更したくなったとき、どこまで自由に改修できるかという「改修の自由度」になります。この2軸の組み合わせで、自社に合う方式の当たりがつきます。

【方式比較表】5方式の性格を定性で見る（金額は含みません）

方式ごとに起きやすい詰まり

ASP・SaaS型では、標準からの逸脱が求められた瞬間に選定自体が止まりやすくなります。パッケージ型やフルスクラッチ型では、稼働後のバージョンアップや制度改正のたびに追加開発が発生しやすく、オープンソース型では保守要員の確保が課題になりがちです。どの方式にも固有の詰まりがあるため、方式を選ぶ段階で「稼働後に何が起きやすいか」まで想定しておくことが大切です。

BtoB固有の機能は「◯」ではなく「どう満たすか」で確認する

方式を絞り込んだら、BtoB固有の機能を「対応している／していない」ではなく「どう満たすか」で確認します。この視点こそが、機能一覧表がどの候補も◯で埋まる理由を解く鍵です。

確認する10項目

確認する項目は10点あります。取引先別価格・掛率、掛売と与信、見積と承認、複数納品先、単位と入数、在庫と納期の見せ方、受注の締め時間、代理店の階層、請求の締め支払、基幹連携です。取引先別の価格設定、掛売と与信、在庫と納期の見せ方、基幹システムとの連携については、それぞれ別記事でより詳しく扱っています。

4択で答えてもらう — 標準機能／設定で対応／追加開発／運用で回避

10項目それぞれについて、候補に「標準機能」「設定で対応」「追加開発」「運用で回避」の4択で答えてもらいます。この4択は、そのまま印刷して評価に使えるように整理しました。

【選定チェック表】10項目を4択で確認する

4択の答えが費用と期間の差になる理由

同じ「対応可能」という回答でも、標準機能で満たすのか、追加開発を要するのかで、実際の費用と期間は大きく変わります。機能一覧表の◯だけを見て候補を絞ると、この差が見えないまま契約段階まで進むことになりかねません。実額の相場は別記事に譲りますが、4択の内訳を候補ごとに記録しておくことが、後の比較で効いてきます。

現状の機能一覧表だけでは見えない差を自社の要件で確かめるには、無料相談で要件を整理するのが近道です。

機能表に出てこない非機能要件

機能一覧表には表れにくいものの、稼働後の安定運用を左右するのが非機能要件です。ここでは公的な物差しと、確認しておくべき3つの観点を扱います。

IPA「非機能要求グレード2018」という公的な物差し

非機能要件を自己流の言葉で聞くと、ベンダーごとに答えの粒度がばらつきます。独立行政法人情報処理推進機構（IPA、システムの信頼性向上や人材育成を担う公的機関）は「非機能要求グレード2018」を公開しています^*5。これは、非機能要求項目を6つの大項目に階層化して示したものです^*5。この物差しの存在を知っているだけで、候補への質問の粒度をそろえやすくなります。

受注ピークに耐えるか

BtoB取引では、月末や締め直前に受注が集中しやすい傾向があります。ピーク時のアクセス集中に耐えられるかは、機能一覧表には出てこない確認事項であり、非機能要件の質問リストに含めておく必要があります。

移行容易性 — ロックインの見方

選定時点で確認しておきたいのが、稼働データを自社側で取り出せるかという移行容易性です。今回の契約に何年縛られるかという不安は、この観点を選定段階で確認しておくことで小さくできます。実際の移行手順そのものは別記事に譲ります。

セキュリティ — 委託先・サプライチェーン経由の攻撃

IPAが公表した「情報セキュリティ10大脅威2026」では、組織向け脅威の2位に「サプライチェーンや委託先を狙った攻撃」が挙げられています^*4。カートシステムは取引先データを扱う立場にあるため、この観点は選定時のセキュリティ確認事項に含めておくべきです。詳細な対策は別記事で扱います。

制度対応は「どこで満たすか」を選定時に決める

電子帳簿保存法とインボイス制度は、カートシステムだけで完結する話ではありません。選定時に決めておくべきは、どこで何を満たすかという切り分けです。

電子取引データの保存要件

国税庁の電子帳簿保存法一問一答【電子取引関係】では、電子取引データの保存にあたり、真実性と可視性を確保する要件が示されています^*2。可視性の確保には検索機能の確保などが求められます^*2。真実性の確保には、次の4つのいずれかの措置が必要です^*2。

• タイムスタンプが付された後の授受
• 速やかなタイムスタンプの付与
• 訂正削除の記録が残るシステム、または訂正削除ができないシステムの利用
• 訂正削除防止の事務処理規程の策定・運用・備付け

これらはすべてを満たす必要があるのではなく、いずれか1つを満たせばよい仕組みです^*2。

カートで満たすか、周辺システムで満たすか

受注データはカート上で生まれます。保存要件を満たす手段をカート側に持たせるのか、会計システムや文書管理システムなど周辺システムに持たせるのかを、選定時に決めておく必要があります。この切り分けを後回しにすると、稼働後に事務処理規程の整備だけで要件を埋めることになりがちです。

適格請求書の記載事項と、請求をカートに載せるかの判断

国税庁のインボイス制度特設ページによると、適格請求書には6つの記載事項が求められます^*3。交付先の氏名または名称、売手の氏名・名称および登録番号、取引年月日、取引内容（軽減税率対象品目の有無）、税率別の対価合計額、税率別の消費税額です^*3。請求書の発行までカートに載せるかどうかは、この記載事項をどこで生成・保持するかという観点から判断する必要があります。

選定プロセスの5段

方式・機能・非機能・制度の4点を確認したら、実際に候補を絞り込むプロセスに入ります。手順は、ロングリスト、RFI、RFP、デモ・PoC、契約の5段です。

図1：選定プロセスの5段（ロングリスト→RFI→RFP→デモ/PoC→契約）

5段の全体像

ロングリストは候補を広く洗い出す段階、RFI（情報提供依頼）は各候補から基本情報を集めて絞り込む段階です。RFP（提案依頼）は自社の要件を明示して提案を求める段階です。デモ・PoCは自社データで実際に動かして確かめる段階、契約は必須要件を満たした候補から最終決定する段階にあたります。

各段の入力と出口条件

ロングリスト

入力は、構築方式の5類型で絞った方式と、BtoB固有機能の10項目です。出口条件は、5〜10社程度の候補リストが揃っていることになります。

RFI（情報提供依頼）

入力はロングリストの候補群で、出口条件は各候補の基本情報と対応方式を把握できた状態です。

RFP（提案依頼）

入力は非交渉領域を含む要件一式で、出口条件は各候補から具体的な提案と4択の回答が揃った状態にあたります。

デモ・PoC

入力は絞り込んだ数社への実データ提供で、出口条件は5つのシナリオを自社データで確認できた状態です。

契約

入力は必須要件を満たした候補で、出口条件は非交渉領域と4択の回答内容を上申資料に残せる状態になります。

デモを製品説明会にしないための準備

デモを依頼する際は、サンプルデータではなく自社の商品・取引先・価格を持ち込みます。ベンダー主導の製品説明会になってしまうと、5つのシナリオのうち画面上で確認できるのは一部にとどまりやすくなります。事前にシナリオを共有し、その場で操作してもらう形式にすれば、BtoB固有機能の4択の回答を裏づける確認作業になるはずです。

費用と補助金の当たりのつけ方

費用と補助金の当たりをつける段階です。ただし本記事では、実額の相場や試算そのものは扱いません。

費用は方式ではなく「満たし方」の4択で決まる

選定チェック表で確認した4択（標準機能・設定で対応・追加開発・運用で回避）の内訳が、そのまま費用と期間の差になります。費用への影響は、方式そのものよりこの4択の回答内容のほうが大きいのです。方式だけで費用を見積もろうとすると、実態とずれやすくなります。実額の相場と3年TCOの試算は、別記事にまとめています。

デジタル化・AI導入補助金2026

独立行政法人中小企業基盤整備機構は、中小企業デジタル化・AI導入支援事業費補助金（通称：デジタル化・AI導入補助金2026）の通常枠を公募しています^*6。通常枠の補助率は1/2以内です。ただし、令和7年度改定の地域別最低賃金未満で雇用している従業員が全従業員の30%以上であることを示した場合は、2/3以内となります^*6。補助額は、対象プロセスの数に応じて5万円以上450万円以下の範囲で設定され、ソフトウェア購入費とクラウド利用料（2年分を上限）が対象経費に含まれます^*6。制度の詳細と申請の進め方は、別記事で扱います。旧称の「IT導入補助金」は2026年度に改称されているため、検討時は正式名称で確認することをおすすめします^*6。

選定でつまずく5つの箇所

ここまでの内容を踏まえ、選定でよく見られるつまずきを5点に整理します。

1. 非交渉領域を決めずに始め、確認する項目のほぼすべてが「要カスタマイズ」という回答に流れます。
2. 機能一覧表の◯を信じ、標準機能なのか追加開発なのかを候補に聞かないまま進めてしまいます。
3. デモが製品説明会になり、自社データでの5シナリオ確認が省かれます。
4. 移行容易性を見ず、データを取り出せるかを契約前に確認しないまま契約に至ります。
5. 制度対応の所在を決めず、稼働後に事務処理規程の整備だけで要件を埋めることになります。

まとめ：カートシステム選定を決める3つの判断軸

本稿では、BtoB ECカートシステムの選定を、方式・機能・非機能・制度・プロセスという5段の流れで整理しました。要点は3つに集約できます。第一に、比較の起点は製品の機能一覧ではなく、自社が変えない商習慣をどこまで明確にできるかです。第二に、確認すべきは「対応可能か」ではなく、標準機能・設定・追加開発・運用回避のどれで満たすかという4択です。第三に、選定プロセスは各段に出口条件を持たせた5段で進めることで、判断のやり直しを防げます。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

ASP・SaaS型とパッケージ型は、どちらを選べばよいですか。

一律にどちらが優れているとは言えず、2軸（商習慣の再現度・改修の自由度）で自社の要件を照らして判断します。標準機能で商習慣を再現できるならASP・SaaS型が候補になり、標準機能で満たせない条件が多いならパッケージ型やフルスクラッチ型が候補になります。方式の選定は、まず非交渉領域を固めてから行う判断です。

機能一覧表がどの製品も◯です。何を見れば差が分かりますか。

◯の中身が「標準機能」「設定で対応」「追加開発」「運用で回避」のどれかを確認すると差が見えてきます。この4択の内訳こそが、そのまま費用と期間の差です。チェック表を使って、候補ごとに4択の回答を記録することをおすすめします。

選定にはどのくらいの期間がかかりますか。

期間は対象取引の範囲や候補数によって変わるため、一律の月数ではお答えできません。本記事では期間の相場ではなく、ロングリストから契約までの5段それぞれに出口条件を持たせることで、判断のやり直しを防ぐ進め方を示しています。各段の出口条件を先に決めておくと、期間の見通しも立てやすくなります。

電子帳簿保存法への対応は、カートシステム側で完結しますか。

カートシステム側だけで完結するとは限りません。保存要件は真実性と可視性の確保で構成され、検索機能の確保や、タイムスタンプ・訂正削除防止のいずれかの措置が求められます^*2。これらをカート側で満たすのか、会計システムなど周辺システムや事務処理規程で満たすのかは、選定時に切り分けて決める事項です。

選定した後に別の製品へ移りたくなった場合、どうなりますか。

移行の難易度は、選定時にどこまで移行容易性を確認していたかに左右されます。稼働データを自社側で取り出せるかというロックインの見方を、契約前に確認しておくことが備えになります。実際の移行の進め方は別記事にまとめていますので、そちらもあわせてご確認ください。

1. *1　出典：経済産業省 商務情報政策局 情報経済課「令和6年度 電子商取引に関する市場調査」（2025年8月26日公表）
2. *2　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」（令和7年6月）
3. *3　出典：国税庁「インボイス制度（適格請求書等保存方式）特設ページ」（2026年8月12日更新）
4. *4　出典：独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2026」（2026年1月29日）
5. *5　出典：独立行政法人情報処理推進機構（IPA）「非機能要求グレード2018（システム構築の上流工程強化）」（2018年）
6. *6　出典：独立行政法人中小企業基盤整備機構「中小企業デジタル化・AI導入支援事業費補助金（通常枠）」（2026年度）