BtoB EC標準機能の落とし穴｜20項目チェックリスト

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

B2B EC-COLUMN

BtoB ECの標準機能の落とし穴とは

BtoB ECの標準機能の落とし穴とは、ベンダーが提示する機能一覧で「対応可」とされた機能が、自社の取引条件・法令要件・非機能要件のいずれかを満たさず、導入後に追加開発や運用回避を強いられる状態を指します。経済産業省「令和6年度電子商取引に関する市場調査」によると、国内のBtoB-EC市場規模は2024年に514兆4,069億円（前年比10.6%増）、「その他」を除く20業種のEC化率は43.1%に達しています^*1。電子化がこれだけ進んだからこそ、既存の商習慣をそのまま載せられるかという要求水準も上がっています。

本稿が扱う「標準機能」の範囲：ASP・パッケージ共通の機能一覧

本稿でいう標準機能とは、ASP型・パッケージ型を問わず、ベンダーの提案書に「対応可」「対応不可」の形で並ぶ機能一覧を指します。掛け払いによる決済や見積承認ワークフローなど、機能名としてはベンダー各社が「対応可」を掲げます。

問題は機能名の有無ではなく、その機能が自社の条件分岐にどこまで対応できるかという粒度にあります。この粒度のズレを見落とすと、稟議通過後に追加開発の話が出て、選定のやり直しに近い手戻りが発生します。

粒度・非機能・法令 — 落とし穴を生む3つのズレ

標準機能一覧という様式は「機能名の有無」しか表現できません。落とし穴は、機能名は同じでも粒度が違う、非機能要件が一覧に載っていない、法令要件が機能名として現れないという3点のズレが原因です。

このズレは、IPAの非機能要求グレード6大項目^*6、公正取引委員会の取適法4義務^*3、国税庁の電子取引データ保存要件^*4という確認フレームに紐づけられます。次章以降、このフレームに沿って4領域を順に見ていきます。

「対応可」の一覧だけでは判定できない理由

機能一覧の「対応可」は、機能の存在だけを示す記号にすぎません。自社の運用に必要な条件分岐の数や、非機能・法令の要件までは表現できないため、一覧を照合するだけでは導入後の適合性を判定できないのです。

取引先別価格「対応可」でも軸数が違えば運用できない

取引先別価格という機能名はベンダー各社が「対応可」としますが、1社1価格までしか対応しない実装と、商品×取引先×数量帯の3軸まで分岐できる実装とでは、実運用での使い勝手が大きく異なります。何軸まで条件分岐できるかを、機能名ではなく数で確認する必要があります。

IPA非機能要求グレード6大項目は機能一覧に載らない

IPAの非機能要求グレードは、非機能要求を可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境エコロジーの6つの大項目に階層化しています^*6。このグレードは、ユーザと開発者の間で生じやすい認識の行き違いを防止する目的で公表されているツール群ですが^*6、機能一覧の「対応可」欄には反映されません。締め日前後の受注集中に耐えられるかといった観点は、機能名として問われないため見落とされがちです。

取適法・電帳法は機能名としてリストに現れない

2026年1月1日に施行された取適法（中小受託取引適正化法）^*3や、電子帳簿保存法の電子取引データ保存要件^*4は、システムの機能名としては一覧に現れません。発注内容の明示や取引記録の保存は、法令が求める「義務」であって「機能」ではないため、機能一覧を照合するだけでは対応状況を把握できないのです。

商取引ルールの落とし穴：価格・与信・締め請求

卸売業のBtoB-EC市場規模は128兆8,684億円（前年比6.3%増）、EC化率は40.3%に達しています^*1。卸売はEDI標準化が先行した業種であり、そのぶん取引先ごとの価格・与信・締め請求のルールがシステム側の前提として持ち込まれます。この3領域は、機能名ではなく条件分岐の数で確認する必要があります。

取引先別価格・掛率・数量帯 — 条件分岐の軸数を数える

取引先別価格は「1社1価格」までの実装と、「商品×取引先×数量帯」まで分岐できる実装に分かれます。数量帯による掛率変動が標準機能かどうか、見積提示後に価格が変わった場合の反映方法も併せて確認してください。軸数が不足すると、価格改定のたびに個別調整の負担が生じやすいでしょう。

与信枠は設定単位と超過時の挙動で確認する

与信枠を取引先単位でしか設定できないのか、部署・案件単位まで分けられるのかは、実務への影響が大きい確認項目です。超過時に受注を止めるのか、承認フローへ回すのかという挙動の違いも、標準機能かカスタマイズかを見極める必要があります。

締め日・支払サイトは本社一括と支店別の併存を確認する

締め日や支払サイトを取引先ごとに異なる設定で持てるかどうかは、請求単位の設計に直結します。本社一括請求と支店別請求が同時に成立する運用を、標準機能の範囲で実現できるかを確認してください。

これらの条件分岐を自社の数字で確かめるには、無料相談で要件を整理するのが近道です。

法令・制度の落とし穴：取適法と電子帳簿保存法

2026年1月1日、下請法の改正法が施行され、法律名が「中小受託取引適正化法（取適法）」に変わりました^*3。委託事業者には4つの義務と11の遵守事項が課され、確認すべき機能要件が増えています^*3。本節は制度解説そのものではなく、システムの機能として何を確認するかに接続する形で扱います。個別の適用可否の判断は所管窓口・専門家にご確認ください。

発注内容の電磁的明示 — 2026年1月1日施行の取適法

取適法は、発注に当たって給付の内容・代金の額・支払期日・支払方法などの発注内容を、書面または電子メールなどの電磁的方法で明示する義務を定めています^*3。改正前は書面交付に中小受託事業者の承諾が必要でしたが、改正後は承諾の有無にかかわらず電磁的方法での明示が可能になりました^*3。EC側で発注内容を電子データとして明示・記録できるかどうかがポイントです。

取引記録2年保存・支払期日60日・遅延利息14.6%

取適法は、取引が完了した場合に給付内容・代金の額などの取引記録を書類または電磁的記録として作成し、2年間保存する義務を定めています^*3。支払期日は、検査の有無を問わず物品等を受領した日から起算して60日以内のできる限り短い期間で定める義務があります^*3。支払遅延や減額した場合は、年率14.6%の遅延利息を支払う義務があります^*3。EC側で取引記録を2年間検索可能な状態で保存できるかを確認してください。

電子取引データ保存の検索3要件と5,000万円特例

電子帳簿保存法は、電子取引データの保存に当たり、取引年月日その他の日付・取引金額・取引先を検索条件に設定できること、日付・金額は範囲指定ができること、2つ以上の記録項目を組み合わせて条件設定できることという検索3要件を求めています^*5。改ざん防止措置は4方式のいずれかで満たします^*4。タイムスタンプ付与後の授受、速やかなタイムスタンプ付与、訂正削除履歴が残るか訂正削除できないシステムの利用、事務処理規程の策定・運用・備付けです。

ダウンロードの求めに応じられる場合は、範囲指定・組み合わせ検索の要件が不要になります^*5。加えて、判定期間に係る基準期間の売上高が5,000万円以下の場合などは、検索機能の要件自体が不要になります^*5。「売上5,000万円以下なら不要」と単純化はできず、ダウンロードの求めに応じられることが前提になる点にご留意ください。検索機能をEC側に持つ必要があるか、保存側の運用で満たせるかを確認してください。

運用・連携の落とし穴：基幹連携・権限・データ移行

機能一覧の「対応可」は連携先の存在を示すだけで、連携の粒度までは表現しません。マスタの正本・承認ルート・データ移行という3つの観点で、運用開始後に起こりうる手戻りを事前に確認します。

ERP・販売管理とのマスタ正本をどちらに置くか

商品マスタや取引先マスタの正本を、ERP側とEC側のどちらに置くかは、運用開始後に変更しにくい設計判断です。リアルタイム連携かバッチ連携か、更新頻度がどの程度かも併せて確認してください。

取引先の本社・支店・部署別承認ルートを再現できるか

取引先側の組織構造が本社・支店・部署にまたがる場合、その承認ルートを標準機能で再現できるかを確認します。承認者が複数階層にわたる場合、標準機能の階層数の上限も確認しておく必要があります。

商品コード・取引先コードの重複と名寄せ

既存の取引データを移行する際は、商品コードや取引先コードの重複をどう名寄せするかが課題になります。移行後のデータ件数・金額を突合して検証する手順まで確認しておくと、移行時のトラブルを避けられるでしょう。

非機能の落とし穴：IPA非機能要求グレード6大項目で確認する

IPAの非機能要求グレードは、非機能要求項目を可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境エコロジーの6大項目に分類しています^*6。このうちBtoB ECで特に重要な4項目に絞って解説します。

可用性・性能拡張性 — 締め日前後の受注集中に耐えられるか

締め日前後に受注が集中することを前提にした稼働時間・体制がベンダーから提示されているかを確認してください。取引先数や商品点数が増えた場合の応答時間の目安も、機能一覧には現れない確認項目です。

運用保守性・移行性 — 追加開発後のバージョンアップ追随

標準機能で足りず追加開発した場合、標準機能側のバージョンアップへの追随手段が導入後のコストを左右します。内製で追随するには、システム構成・データ構造・改修範囲の切り分けといった知識が欠かせません。担当者を確保できるかも含めて、追随方法をベンダーに確認しないまま契約すると、追加開発分だけ取り残されるおそれがあります。

セキュリティ — 取引先別の閲覧制御と権限粒度

取引先ごとの価格・在庫の閲覧制御と、担当者の権限をどこまで細かく分けられるかを確認してください。権限の粒度が粗いと、本来は見せたくない取引先の価格が別の取引先の担当者から見えてしまう事態につながります。

導入前に確認する20項目チェックリスト

これまでの4領域を、確認すべき20項目に落とし込みました。各項目は「何を数えるか」という観点で確認してください。

「できますか」ではなく「どう実現しますか」と聞く質問文テンプレート

ベンダーへの確認は「できますか」という二択の質問では粒度が伝わりません。以下の3点セットで聞くことをおすすめします。

• 「取引先別価格は、商品×取引先×数量帯の何軸まで標準機能で分岐できますか」
• 「この機能は標準機能ですか、それともカスタマイズですか」
• 「標準機能のバージョンアップがあった場合、カスタマイズ部分はどう追随しますか」

デモ・PoCは自社で最も複雑な取引先1社分のデータで確認する

デモやPoC（概念実証）は、平均的な取引先ではなく、自社で最も条件が複雑な取引先1社分のデータを持ち込んで確認することをおすすめします。価格軸・与信・締め請求・承認ルートのすべてが同時に絡む取引先で動作を確認できれば、20項目の多くを一度に検証できるでしょう。

この検証を内製だけで進めるには、商取引ルール・法令要件・システム要件の3領域にまたがる知識が必要になります。要件定義の進め方そのものは、IPAが「ユーザのための要件定義ガイド 第2版」として体系化しています^*7。20項目のうち自社だけでは判定しきれない項目が残る場合は、外部の要件定義支援を利用する選択肢もあります。

標準機能の落とし穴は商取引・法令・連携・非機能の4領域で確認する

本稿では、BtoB ECの標準機能一覧が「機能名の有無」しか表現できないという様式の限界と、そこから生じる4領域の落とし穴を整理しました。要点を3つに集約すると次の通りです。第一に、商取引ルールは価格・与信・締め請求の条件分岐の軸数を数えます。第二に、法令要件は取適法^*3・電子帳簿保存法^*5の義務を、機能として満たせるかに読み替えて確認します。第三に、非機能要件はIPA非機能要求グレード6大項目^*6に沿って点検してください。20項目チェックリストとベンダーへの質問文テンプレートを、稟議の前に手元で照合してください。

チェックリストの照合を終えたら、次は要件定義の工程です。要件定義の進め方は別稿で扱っています。

---

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

よくある質問

標準機能で対応できない場合、カスタマイズと運用でのカバーはどちらを選ぶべきですか。

まず、その差分が法令要件か商取引ルールかを切り分けます。取適法・電帳法など法令要件^*3*5は、カスタマイズか運用ルールの変更で着実に満たさなければなりません。一方、頻度の低い例外的な商習慣なら、運用回避（手作業や別ツールでの補完）で様子を見る選択肢もあります。バージョンアップ追随のコストを含めて判断してください。

取適法の対象になるかどうかは何で判断すればよいですか。

取引の内容と、資本金基準または従業員基準のいずれかへの該当で判断します^*3。製造委託等では資本金3億円超・従業員300人超などが委託事業者の基準になります^*3。自社が該当するかどうかの個別判断は、公正取引委員会や事業所管省庁の窓口が頼りになるでしょう。

電子取引データの検索機能はEC側に必要ですか。

必須ではありません。税務職員によるダウンロードの求めに応じられる場合は、範囲指定・組み合わせ検索の要件が不要になります。さらに、そのダウンロードの求めに応じられることを前提として、判定期間に係る基準期間の売上高が5,000万円以下の場合などは、検索機能の要件自体が不要になります^*5。売上高の基準だけで判断できるわけではない点にご留意のうえ、保存側の運用で満たせるかを含めて確認してください。

機能一覧に「カスタマイズ対応可」とある場合、何を追加で聞くべきですか。

「標準機能のバージョンアップ時に、カスタマイズ部分はどう追随しますか」を忘れずに確認してください。カスタマイズは初期導入時よりも、その後のバージョンアップ追随コストで差が出やすい領域です。追随の方法（自動追随・都度改修・追随不可）を契約前に確認しておくと、運用開始後の想定外を減らせます。

20項目のうち、ベンダー選定のどの段階で確認すべきですか。

商取引ルールの7項目はRFP作成前に自社で数え終えておきます。条件分岐の軸数が決まらないと、ベンダーに渡す要件そのものが定まらないためです。法令の4項目と連携・運用の5項目は提案依頼の段階でベンダーへ質問し、非機能の4項目はデモ・PoCの段階で実機の挙動として確認します。特に自社で最も条件が複雑な取引先1社分のデータを持ち込めば、非機能を含む多くの項目を一度に検証できます。

1. *1　出典：経済産業省 商務情報政策局情報経済課「令和6年度 電子商取引に関する市場調査」報告書（図表1-7・図表6-3・図表6-4、令和7年8月公表）
2. *2　出典：経済産業省「令和6年度電子商取引に関する市場調査の結果を取りまとめました」（2025年8月26日）
3. *3　出典：公正取引委員会「取適法リーフレットNo.01」（令和7年8月）
4. *4　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】問18」（令和7年6月）
5. *5　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】問48・問51」（令和7年6月）
6. *6　出典：独立行政法人情報処理推進機構（IPA）「非機能要求グレード」紹介ページ
7. *7　出典：独立行政法人情報処理推進機構（IPA）「ユーザのための要件定義ガイド 第2版」（2019年9月12日）