BtoB通販サイトのセキュリティ対策｜責任の所在と最低限やるべきこと

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

B2B EC-COLUMN

セキュリティは誰の責任なのか｜構築方式で変わる分界点

BtoB通販サイトのセキュリティは、まず「どこまでが自社の責任か」を構築方式から確かめることから始まります。ASP型なら基盤やアプリケーションの保守は事業者側が担い、自社はIDとアクセス権限の運用を負います。パッケージ型やフルスクラッチなら、脆弱性の修正やサーバーの維持まで自社（または開発委託先）の責任範囲に入ります。この線引きを決めないまま個別の対策を並べても、抜けが残ります。そして対策の優先順位は、被害の実態が示しています。2025年の不正アクセス届出109件のうち、実際に被害が生じたのは85件¹。その被害原因で最も多かったのは「ID、パスワード管理の不備」で30件でした¹。つまり最初に手をつけるべきは、高度な防御機構ではなく認証まわりの管理です。BtoB通販では取引先ごとの価格・与信枠・掛け売り条件といった、漏れれば取引関係そのものを損なう情報を扱います。一般消費者向けECと同じ感覚では足りません。

ASP型・パッケージ型・フルスクラッチで責任範囲は異なる

BtoB通販サイトのセキュリティを考えるとき、最初につまずくのが「自社は何をやらなければいけないのか」が見えないことです。これは知識の不足ではなく、責任の分界点を確かめていないことが原因です。

ASP型（クラウド型のサービスを月額で使う方式）では、サーバーの維持、ミドルウェアの更新、アプリケーションの脆弱性修正は提供事業者が担います。自社が負うのは、管理画面のアカウント管理、取引先アカウントの発行と停止、権限の設定、そして自社で追加した設定の妥当性です。

パッケージ型は、製品としてのプログラムを自社サーバーやクラウド上で動かす方式です。提供元から修正プログラムが配布されても、適用するのは自社または運用委託先です。前述の調査では、被害原因の第2位が「古いバージョンの利用や修正プログラム・必要なプラグイン等の未導入によるもの」で18件でした¹。適用されない修正プログラムは、存在しないのと同じです。

フルスクラッチ（独自開発）では、設計から実装まで自社側の責任です。脆弱性が見つかったときに誰が調査し、誰が直し、いつまでに反映するのか。この体制が契約書に書かれていなければ、事故のときに動けません。

「事業者に任せている」と「事業者が担っている」は違う

よくある誤解が、ASP型を使っているから安心だという受け止めです。事業者が担うのは事業者の責任範囲であって、自社が発行したアカウントの管理まではしてくれません。退職者のIDが残っている、取引先の担当者交代を反映していない、管理者権限を全員に付けている。こうした運用の穴は、どの方式を使っていても自社側に残ります。

逆に、すべてを自社で抱え込む必要もありません。次の章では、BtoB通販だからこそ生じるリスクを整理し、その上でどこまでを標準機能に委ねられるかを見ていきます。

BtoB特有のリスクとは何か｜取引情報が漏れたときの重さ

取引先ごとの価格と与信情報は、漏れると取引関係を壊す

BtoB通販サイトが扱う情報は、一般消費者向けECとは性質が違います。取引先ごとに異なる卸価格、設定した与信枠、支払サイト、過去の取引履歴。これらは商談の前提そのものであり、他社に見られることを想定していない情報です。

A社の仕入価格がB社に知られれば、価格交渉の構図が変わります。与信枠の設定が漏れれば、その取引先をどう評価しているかが伝わってしまいます。金銭的な被害の額だけでは測れない損失が生じるのが、BtoB通販の特徴です。

なりすまし発注と掛け売り決済の不正利用

掛け売りは、その場で決済せず後日まとめて請求する取引方法です。BtoB通販では標準的な決済手段ですが、裏を返せば「発注した時点では代金が確保されていない」状態が続きます。

取引先のIDとパスワードが漏れれば、第三者がその企業になりすまして発注できます。商品は出荷され、請求は正規の取引先へ向かい、そこで初めて発覚します。掛け売り対応に必要な機能は与信管理・請求締め・入金消込などを含めて5つに整理できますが⁵、そのいずれも「発注者が本人である」ことを前提にしています。認証が破られれば、与信管理も請求管理も機能しません。

決済面のリスクも軽視できません。クレジットカードの不正利用被害額は2021年に過去最高の約330億円となりました²。カード決済を併用しているBtoB通販サイトでは、この被害の当事者になる可能性があります。

取引先からの指摘が、対策見直しのきっかけになる

BtoB通販では、取引先企業が自社のセキュリティ水準を確認してくることがあります。相手企業にとっても、取引先経由の情報漏えいは自社の問題になるためです。

つまりセキュリティ対策は、自社を守るためだけのものではありません。取引を継続するための条件になりつつあります。では、最低限何を備えればよいのか。次章で優先順位とともに整理します。

構築方式によって自社が負う範囲は変わりますが、アカウントと権限の管理だけはどの方式でも自社に残ります。そしてBtoB通販では、取引先ごとの価格・与信情報・掛け売りの発注権限という、漏れれば取引そのものを揺るがす情報を扱います。まずは責任範囲の確認と、認証まわりの点検から始めてください。

自社サイトの責任範囲がどこで分かれているかは、契約書と運用の実態を突き合わせないと見えません。兼任体制では、この突き合わせ自体に手が回らないことが多く、構築方式ごとの分界点を知る相手と一緒に確認したほうが早く済みます。

現在の構築方式で事業者側が担う範囲と自社に残る範囲、そして空白になっている項目がどこかを、具体的に確かめられます。無料相談で要件を整理する

2025年の不正アクセス被害原因（届出ベース・上位2項目）

順位は公表された調査に依ります¹。

件数の多い原因から順に手をつけると、同じ工数でも防げる被害の幅が広がります。

最低限やるべき対策と、事業者に委ねられる範囲

型	この節で示すこと
対策の優先順位	何から着手すべきかの順序と理由
委ねる判断	自社で担うか標準機能に任せるかの分かれ目

最低限やるべき対策は何か｜認証を最優先に置く理由

第一に、ログイン認証とID管理を締める

優先順位を決める根拠は、被害原因の分布にあります。2025年の届出で被害原因の最多は「ID、パスワード管理の不備」の30件でした¹。ここを放置したまま他の対策に費用をかけても、最も通られやすい入口が開いたままです。

具体的には、初期パスワードの変更を必須にする、パスワードの使い回しを防ぐルールを定める、ログイン試行の回数を制限する、そして二要素認証（パスワードに加えてもう一つの確認手段を使う方式）を管理画面に適用する。この四つが土台です。

加えて、取引先アカウントの棚卸しを定期的に行います。退職・異動・取引終了に伴って不要になったIDが残っていないかを確認する作業です。

第二に、アクセス権限を役割ごとに分ける

管理画面に入れる社員全員が、全取引先の価格と与信情報を見られる状態になっていないでしょうか。受注処理だけを行う担当者に、与信枠の変更権限は不要です。

権限を役割ごとに分けておくと、万一アカウントが乗っ取られた場合でも、被害の範囲がその役割の範囲に限られます。被害を完全に防ぐことはできなくても、広がりを抑えることはできます。

第三に、通信の暗号化と決済・与信データの保護

サイト全体のHTTPS化（通信内容を暗号化して第三者に読まれないようにする仕組み）は、今日では前提条件です。ログイン画面だけでなく、商品一覧から注文完了までの全ページが対象になります。

決済情報については、自社サーバーに保持しない構成が基本です。カード情報を自社で持たなければ、自社が漏えい元になる経路をひとつ減らせます。与信情報や取引条件は自社システムに残らざるを得ませんが、アクセスできる人を絞り、操作の記録を残しておきます。

第四に、修正プログラムの適用と記録の保全

被害原因の第2位は、古いバージョンの利用や修正プログラムの未導入で18件でした¹。パッケージ型やフルスクラッチでは、この適用が自社の仕事になります。誰が情報を受け取り、いつ適用するかを決めておきます。

ログ（誰がいつ何を操作したかの記録）の保全も欠かせません。異常に気づくため、そして事故が起きたときに範囲を特定するために必要です。取引先から指摘を受けた際、記録が無ければ「被害が無かった」ことすら証明できません。

優先度	対策	主な狙い
1	ログイン認証とID管理の強化	被害原因の最多である管理の不備を塞ぐ
2	役割ごとのアクセス権限の分離	乗っ取られた際の被害範囲を限定する
3	全ページのHTTPS化と決済データの非保持	通信途上と保管場所からの漏えいを減らす
4	修正プログラムの適用と操作ログの保全	既知の弱点を残さず、異常を追跡できるようにする

対策はどこまで事業者に任せられるか｜自社運用との分かれ目

ASP型は、技術的な保守を標準機能として引き受ける

ASP型のBtoB ECカートは、サーバーの維持や脆弱性への対応、通信の暗号化といった技術面を提供事業者が担います。自社に専任の技術者がいない場合、これは大きな意味を持ちます。修正プログラムの適用漏れという、被害原因の第2位に挙がった事象¹を、自社の運用力に依存せず避けられるためです。

費用の目安として、ASP型のBカートでは初期費用が初回のみ80,000円（税別、エンタープライズプランを除く）、プラン300の月額は79,800円です⁴。プラン300は商品・会員とも各30,000件が上限となります⁴。自社でサーバーを維持し、技術者を配置し、修正対応を続ける体制と比べて、どちらが現実的かを判断する材料になります。

委ねられないのは、アカウントと権限の運用

一方で、どの事業者も代わりに行えないことがあります。誰にアカウントを発行するか、どの権限を与えるか、いつ停止するか。これは自社の業務判断であり、外から決められません。

被害原因の最多が「ID、パスワード管理の不備」だった¹という事実は、まさにこの委ねられない部分に被害が集中していることを示しています。技術的な守りを事業者に任せられるからこそ、自社は運用の管理に力を割けます。

判断の基準は、技術者の有無と運用を続けられるか

自社で抱えるか事業者に委ねるかの分かれ目は、三つの問いで整理できます。第一に、脆弱性の情報を継続的に追い、修正を適用できる技術者が社内にいるか。第二に、その担当者が退職・異動しても体制が続くか。第三に、サーバー維持と人件費を含めた総額が、ASP型の費用を上回らないか。

兼任で運用している組織では、第二の問いで行き詰まることが多くあります。担当者一人に依存した体制は、その人がいなくなった時点で更新が止まります。導入の速さも判断材料です。ノンカスタマイズで導入する場合、申し込みから最短で10日前後で利用を開始できる例があります³。

ここまでで、責任範囲・BtoB特有のリスク・対策の優先順位・委ね方を見てきました。最後に、明日から動き出すための順序をまとめます。

判断の問い	自社運用が向く	事業者に委ねるのが向く
脆弱性対応ができる技術者	社内にいる	いない・兼任
担当者交代への備え	複数名で運用できる	一人に依存している
費用の総額	人件費込みでも見合う	ASP型の費用を上回る

何から手をつければよいか｜最初の一歩の決め方

まず、構築方式と責任範囲を紙に書き出す

最初にやるのは対策の実施ではなく、現状の確認です。自社サイトがASP型かパッケージ型か独自開発か。サーバーは誰が維持しているか。修正プログラムは誰が適用しているか。契約書と運用の実態を照らして、空白になっている項目を洗い出します。

この作業は専門知識がなくてもできます。むしろ、専門知識がない立場だからこそ「誰がやるのか分からない」項目を素直に拾い上げられます。

次に、アカウント一覧を出して不要なIDを消す

管理画面のアカウントと、取引先アカウントの一覧を出します。そこに、退職した社員のID、取引を終了した企業のID、誰のものか分からないIDが残っていないかを確認します。

2025年の不正アクセス届出109件のうち85件で実被害が生じており¹、その原因の最多がID・パスワード管理の不備でした¹。不要なIDを消す作業は費用もかからず、効果が被害原因の最多に直接届きます。

そして、次の見直し時期を決めておく

一度の点検で終わらせず、アカウントの棚卸しと権限の確認をいつ行うかを決めます。四半期ごとでも半期ごとでも構いません。日付を決めて予定に入れておくことが、兼任体制では特に効きます。

対策の実施そのものより、続けられる形にすることが難しい部分です。自社で続けられる範囲を見極め、難しい部分は標準機能や外部の支援に委ねる。この切り分けが、限られた体制での現実的な答えになります。

要点の整理

軸	基準
責任範囲の確認	構築方式（ASP型・パッケージ型・独自開発）ごとに、事業者と自社の分界点を契約と実態の両面で書き出したか
着手の優先順位	被害原因の最多である認証・ID管理から着手し、次に権限分離、通信と決済データ、修正プログラムと記録の順に進めているか
BtoB特有のリスク	取引先ごとの価格・与信情報の閲覧範囲を絞り、掛け売りのなりすまし発注を認証で防ぐ設計になっているか
委ねる判断	脆弱性対応の技術者が継続的に確保できるか、担当者交代後も運用が続くか、総額がASP型の費用に見合うか
続ける仕組み	アカウントの棚卸しと権限確認の実施時期を決め、予定として固定しているか

対策を続けられる形にするには、自社で担える範囲と標準機能に委ねる範囲の線引きが要ります。技術者の確保が難しい場合、どこまでを標準機能でまかなえるかは、実際の機能と運用を知る相手に聞くのが確実です。 認証や権限分離、通信の暗号化がどこまで標準で備わっているか、自社の運用体制で無理なく続けられる構成になるかを確認できます。

よくある質問

ASP型を使っていれば、セキュリティ対策は自社で何もしなくてよいのですか。

いいえ。ASP型ではサーバーの維持や脆弱性の修正といった技術面を提供事業者が担いますが、アカウントの発行・権限の設定・不要なIDの停止は自社の責任範囲に残ります。2025年の不正アクセス届出で被害原因の最多は「ID、パスワード管理の不備」の30件であり¹、これはまさに自社側に残る領域です。

BtoB通販は取引先が限られているので、一般消費者向けECより安全ではないですか。

取引先が限られていても、扱う情報の性質は異なります。取引先ごとの卸価格、与信枠、支払条件は、漏れれば取引関係そのものに影響します。また掛け売りは発注時点で代金が確保されていないため、なりすまし発注が成立すると商品が出荷されてから発覚します。掛け売り対応に必要な機能は5つに整理できますが⁵、いずれも発注者が本人であることを前提にしています。

何から手をつければよいか分かりません。費用をかけずにできることはありますか。

アカウント一覧の棚卸しから始めてください。管理画面と取引先アカウントの一覧を出し、退職者・取引終了先・所属不明のIDを停止します。費用はかからず、被害原因の最多に直接対応します。その上で、初期パスワードの変更必須化とログイン試行回数の制限を設定します。

自社サーバーで運用していますが、修正プログラムの適用が滞りがちです。

2025年の届出では「古いバージョンの利用や修正プログラム・必要なプラグイン等の未導入によるもの」が18件で被害原因の第2位でした¹。適用を担う技術者が社内に継続的に確保できないのであれば、技術面の保守を事業者が担うASP型への切り替えが選択肢になります。ノンカスタマイズであれば申し込みから最短10日前後で利用開始できる例があります³。

取引先からセキュリティ対策の状況を聞かれた場合、何を答えればよいですか。

構築方式と、それに伴う責任範囲の切り分けをまず説明できるようにしておきます。加えて、通信の暗号化の有無、アカウント管理の運用ルール、権限分離の方針、操作ログの保全状況を整理しておくと答えやすくなります。記録が残っていなければ、被害の有無を示すこと自体が難しくなります。

1. 1　出典：ScanNetSecurity（独立行政法人情報処理推進機構(IPA)発表データに基づく報道）「不正アクセスの被害原因は「ID、パスワード管理の不備」が最多に～2025年「コンピュータウイルス・不正アクセスの届出状況」」（2026年4月14日）　経路
2. 2　出典：株式会社フライトソリューションズ「2024年度に義務化されるECサイトの脆弱性診断義務化について（EC-Rider B2B Ⅱ 公式サイト コラム）」（2026年）　経路
3. 3　出典：株式会社フライトソリューションズ「よくあるご質問（FAQ）｜EC-Rider B2B」（2026年）　経路
4. 4　出典：株式会社フライトソリューションズ「BtoB EC費用の相場｜方式別の料金と総額の考え方（EC-Rider B2B Ⅱ 公式サイト）」（2026年）　経路
5. 5　出典：株式会社フライトソリューションズ「BtoB EC掛売り決済の対応方法｜2026年取適法と要件（EC-Rider B2B Ⅱ 公式サイト）」（2026年）　経路