インターネットEDIのセキュリティ課題：暗号化で防げる範囲と、取引先に確認すべきこと

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

B2B EC-COLUMN

「暗号化しています」と答えて足りるのか：取引先の確認依頼で最初に分けること

取引先からインターネットEDIへの接続や、セキュリティ調査票への回答を求められ、「通信は暗号化しています」と書けば足りるのか迷っていませんか。
暗号化が守るのは、注文や請求のデータが公衆回線を通っている途中です。
相手が本当にその取引先か、証明書やIDを誰が管理するか、受け取ったデータをどう保管するか、障害で再送したデータを二重に取り込まないかは、暗号化とは別に決まります。
標準で決まっていること、サービス提供元が担うこと、自社の運用で行うことに分けて整理すると、取引先への回答と、確認すべき点がはっきりします。

確認依頼が来る場面と、暗号化だけの回答で足りない理由

インターネットEDIのセキュリティ確認は、多くの場合、取引先の事情から届きます。
取引先が自社の取引先全体を対象に点検を進めていて、調査票の中に「EDIの通信は暗号化されていますか」「受信したデータはどのように保管していますか」「障害が起きた場合の連絡体制はありますか」といった問いが並ぶ、という場面を思い浮かべてください。
電話回線を使う従来型のEDIからインターネットEDIへ切り替える際に、接続方式や証明書の準備をあわせて求められることもあります。

取引先がこうした確認を重ねる背景には、取引先や委託先を経由した攻撃への警戒があります。
情報処理推進機構（IPA）の「情報セキュリティ10大脅威2026」組織編では、「サプライチェーンや委託先を狙った攻撃」が2位に挙げられ、2019年に初めて選ばれてから8年連続の選出です⁴。
この順位は組織全般に向けた脅威の整理であり、EDIで被害が多いことを示すものではありません。
それでも、取引でつながる相手の守りを確かめておきたいという取引先側の動機は、ここから読み取れます。

では、なぜ「暗号化しています」の一文では足りないのでしょうか。
暗号化は、データが送り手から受け手へ移る途中で、第三者に中身を読まれないようにする仕組みです。
一方で、確認を求める取引先が知りたいのは、自社の注文データが誤った相手へ渡らないか、受け取った先で漏れないか、障害のときに取引が混乱しないか、という取引全体の安全です。
暗号化の一文はこのうち通信の途中にしか答えておらず、調査票のほかの問いには空欄が残ったままになります。

通信・相手確認・保管・運用の4つに分ける

回答を組み立てる前に、課題を次の四つに分けておくと見通しがよくなります。
この分け方は標準の規定ではなく、取引先へ説明するための整理の提案です。

• 通信：公衆回線を通る途中で、データが読まれたり書き換えられたりしないか
• 相手確認：送り先・送り元が本当に契約した取引先か、証明書やIDで確かめているか
• 保管：受信したデータや送信済みのデータを、社内のどこに、誰が見られる形で置いているか
• 運用：証明書の更新、障害時の再送、担当者の交代、ログの確認を、誰がいつ行うか

この四つに分けると、答えの出どころがそれぞれ違うことが見えてきます。
通信の方式は業界標準や取引先の指定で決まり、相手確認の仕組みは標準と、証明書を発行する事業者の取り決めに左右されます。
保管と運用は、EDIサービスを使っていても、データを社内のパソコンや基幹システムに取り込んだ後は自社の扱いになります。
つまり、同じ調査票でも、項目によって「取引先の指定どおりです」「提供元の仕様です」「社内でこう決めています」と、根拠の置き場所が変わるのです。

標準の側でも、この区別は文書の分け方に表れています。
流通BMS（小売と卸・メーカーの間で使われる流通業界のEDI標準）では、インターネットで送受信する際の通信プロトコルとセキュリティの標準仕様、パラメータ設定の推奨値を説明する「通信プロトコル利用ガイドライン」と、証明書を発行する認証局が守るべき事項を説明する「流通業界共通認証局証明書ポリシー」が、別の資料として公開されています²。
通信の決まりと、相手を確かめる証明書の決まりは、標準の中でも別々に扱われているわけです。

ただし、流通BMSはインターネットEDIのすべてではありません。
取引先が業界独自の方式や、ブラウザの画面で受発注を行うWeb EDIを使っている場合も、四つの分け方はそのまま使えますが、中身は取引先と提供元の仕様で確かめることになります。
以下では、仕組みが公開されている流通BMSを例に、まず通信の途中で何が守られ、何が守られないかを見ていきます。

▼ 図の内容を文字で読む

• 業界標準・取引先の指定
  • 通信手順
  • 証明書の発行基準
• EDIサービス提供元
  • 通信と証明書の設定
  • サービス側の履歴と保管
• 自社の運用
  • IDと証明書の期限管理
  • 取り込み後の保管
  • 再送時の照合と連絡

インターネットEDIの通信手順と暗号化で防げる範囲：流通BMSを例に

サーバー間手順（ebMS・AS2）とJX手順

流通BMSの通信手順は、つなぎ方によって二つの系統に分かれています。
企業のサーバー同士が直接やり取りするサーバー－サーバー手順としてebMSとAS2が採用され、端末からサーバーへつなぐクライアント－サーバー手順として、SOAP-RPCという方式を使うJX手順が開発・公開されています³。
JX手順は、電話回線の時代に使われていたJ手順が持っていた最低限の通信制御機能を、インターネット上で使えるように設計されたものです³。

どちらでつなぐかによって、自社が用意するものは変わります。
サーバー同士でやり取りする手順では、自社の側にもデータの受け口となるサーバーが必要になり、それを自社で持つのか、提供元のサービスを使うのかを決めることになります。
端末から相手のサーバーへつなぐ手順なら、受け口は相手側にあり、自社は接続する端末とソフトの管理が中心になります。
調査票で「サーバーの管理体制」を問われたとき、自社にそもそも受け口のサーバーがあるのか無いのかで、答える範囲が大きく違ってきます。

使っている製品やサービスが取引先の指定する手順に対応しているかは、口頭の確認だけでは心もとない部分です。
流通BMSでは、AS2・ebMS・JX手順の接続に必要な機能の一覧とサンプルを示した機能確認シートが公開されています²。
新しい取引先とつなぐ前や、EDIソフト・サービスを選び直すときに、提供元へこのシートに沿った回答を求めておけば、「対応しています」という一言より確かな材料として手元に残ります。

証明書と認証局ポリシーの位置づけ

証明書（電子証明書）は、通信の相手が名乗ったとおりの企業かを確かめるための、電子的な身分証にあたるものです。
信頼できる発行元である認証局が、申請した企業を確認したうえで発行します。
暗号化が「途中で読まれない」ための仕組みだとすれば、証明書は「つないでいる相手は本物か」を確かめるための仕組みだと考えると、両者の役割の違いがつかみやすくなります。

流通BMSでは、先に触れた認証局証明書ポリシーで、証明書を発行する認証局が守るべき事項が説明されています²。
同じページには、このポリシーに適合した証明書発行サービスとして、株式会社インテックの「EINS/PKI for EDI」が掲載されています²。
掲載はページに載った時点の情報なので、現在の対応状況は発行元に確かめる必要があります。
ここから読み取れるのは、証明書は自社だけで作って済むものではなく、基準を満たした第三者から発行を受ける前提で組み立てられている、という点です。

どの通信手順で、どの種類の証明書が必要になり、どちらの側が用意するのかは、取引先の指定、通信プロトコル利用ガイドライン、提供元の仕様で確かめる事項です。
一方、証明書を使う場合に共通していえるのは、有効期限があることです。
期限が切れれば相手を確かめられなくなり、通信そのものが止まり得ます。
そのため証明書は、取得して終わりではなく、一定の周期で手続を回し続けるものとして扱う必要があります。

この一巡のどこかが特定の担当者の記憶だけに頼っていると、異動や退職をきっかけに期限が見落とされます。
発行元への申請、設定、疎通の確認、期限の監視は、担い手が別々になりやすい作業でもあります。
誰がどの段を回すのかは、後で扱う分担の整理で具体的に決めていきます。

暗号化が守るのは通信の途中まで

通信を暗号化すると、送り出した発注データは、相手のサーバーに届くまで途中で中身を読み取られにくくなります。
しかし受け手に届き、復号されてファイルや基幹システムのデータになった時点で、暗号化の役目は終わります。
そこから先は、社内のファイル置き場や受注システムのアクセス権、バックアップの扱いで守ることになります。
「暗号化しているから、受け取った後のデータも安全」という理解は成り立たないということです。

通信の途中についても、一度設定すれば終わりではありません。
流通BMSの標準ページには、SSLv3.0の脆弱性への対応を依頼する文書が掲載されています²。
SSLは通信を暗号化する方式で、その後継がTLSです。
古い版で接続を続けていると、取引先とはつながっていても、弱点の分かっている方式で注文データを送っていることになりかねません。
標準の側から対応を求める文書が出ていること自体が、暗号化の設定を見直し続ける必要を示しています。

推奨される版や設定値は、通信プロトコル利用ガイドラインの最新版と、提供元の仕様、取引先の指定で確かめるものです²。
自社がいまどの版で接続しているかを提供元や社内の設定で把握しておけば、調査票で暗号化方式の版を問われたときにも、具体的に答えられます。
ここまでで、暗号化が担う範囲は見えてきました。
次は、その外側に残る課題を、実際の注文と請求の流れに沿って見ていきます。

▼ 図の内容を文字で読む

1. 発行・更新の申請
   • 発行元の選定
   • 申請書類の準備
2. EDIへの設定
   • 証明書と秘密鍵の組み込み
   • 取引先への新しい証明書の連絡
3. 取引先との疎通確認
   • 試験送信
   • 受信側での確認
4. 運用と期限の監視
   • 有効期限の記録
   • 更新開始時期の通知

暗号化で残る課題を注文・請求データの流れに沿って見る

相手の確認・なりすまし

仮の例で流れを追ってみます。
受注側の食品卸が、取引先の小売チェーンから流通BMSで発注データを受け取り、自社の受注システムに取り込んで出荷し、月末に請求データを返す、という流れです。
データは「送信→受信→取り込み→保管→請求」と進み、それぞれの段で、暗号化だけでは決まらない課題が現れます。

最初の課題は、受け取った注文が本当にその小売チェーンから来たのか、返す請求が本当にその小売チェーンに届くのか、という点です。
暗号化は途中の盗み見を防ぎますが、つなぐ相手そのものを取り違えていれば、暗号化された通信で偽の相手とやり取りすることになります。
前の節で見た証明書や、接続用のID・パスワードは、この「相手は誰か」を確かめるための道具です。

問題になりやすいのは、その道具の管理です。
たとえば、EDIの接続IDとパスワードを担当者数名で共有し、退職者が出ても変えていない状態を考えてみてください。
相手確認の仕組み自体はあっても、社内の誰が接続しているのかを説明できません。
証明書も同じで、証明書と対になる秘密鍵（外に出してはいけない鍵）が誰でも触れる共有フォルダに置かれていれば、他人が自社になりすます余地が生まれます。
調査票で「相手確認」を問われたときは、仕組みの有無に加えて、IDと鍵を誰が持っているかまで答えられるかが分かれ目になります。

改ざんと誤送信

改ざんは、データの中身が途中や保管中に書き換えられることです。
通信の途中でどこまで改ざんを検知できるかは、通信手順と暗号化の設定によって変わり、その規定は通信プロトコル利用ガイドラインと提供元の仕様で確かめる事項です。
見落とされやすいのは、通信の外側です。
受信したファイルが受注システムへの取り込みを待って共有フォルダに置かれている間や、数量の誤りを社内で手作業で直す場面では、誰がいつ何を変えたかが記録に残らないことがあります。

誤送信は、暗号化とは関係なく起きます。
取引先ごとに宛先の設定を持つEDIでは、新しい取引先を追加するときに既存の取引先の設定を複製し、宛先の一部を直し忘れる、といった設定の誤りが考えられます。
暗号化はデータを正しく包んで、設定どおりの相手へ届けるだけです。
宛先そのものが誤っていれば、請求データは暗号化されたまま別の会社へ届きます。
防ぐ手立ては、設定を変えるときの二人での確認や、取引先を追加した直後の試験送信といった、運用の側にあります。

受信後の保管

受信した発注データや送信した請求データは、取引の記録として一定期間社内に残ります。
ここで守るべきは、保存先のフォルダやサーバーに誰が触れられるか、バックアップがどこにあるか、保存期間を過ぎたデータをどう処分するか、といった点です。
注文データには取引先の店舗ごとの発注数量や単価が含まれ、外に出れば取引先の販売状況が推し量られかねない情報です。

EDIサービスを使っている場合は、保管場所が二か所になることに注意が要ります。
サービス側に送受信の履歴やデータが残り、その保管期間や閲覧できる範囲は提供元の仕様で決まります。
一方、社内にダウンロードした後のファイルは、自社の権限設定と保存のルールで守ることになります。
調査票で「データの保管」を問われたら、サービス側と社内側に分けて答えるほうが実態とずれにくく、取引先が追加で質問してきたときにも説明しやすくなります。

障害時の再送と二重処理

通信障害が起きると、送り手は相手に届いたかどうか分からないまま、同じ注文データを送り直すことがあります。
このとき受け手の側で一度目のデータがすでに取り込まれていれば、同じ注文が二件として受注システムに入り、先ほどの食品卸なら同じ商品を二度出荷するおそれがあります。
請求データで同じことが起きれば、取引先の支払処理に混乱を残します。

これは情報漏えいとは種類の違う課題ですが、取引先が「障害時にどう対応するか」を問うとき、実務上の中心はここにあります。
確かめておきたいのは次の三点です。

• 通信手順や提供元のサービスに、同じデータの重複受信を検知する仕組みがあるか
• 取り込み側で、伝票番号などをもとに既に取り込んだデータと照合しているか
• 再送するとき、送り手と受け手のどちらが誰へ連絡するかを決めてあるか

重複受信や再送の扱いは、通信手順の概要を見ただけでは分かりません。
使っている手順の仕様書と提供元の説明で、どこまでを通信の側が担い、どこからを取り込み側で見るのかを確かめる必要があります。
通信の側で重複を検知できる場合でも、障害の起き方によっては取り込み側の照合が最後の歯止めになるため、片方だけを確かめて終わりにしないことが大切です。

▼ 図の内容を文字で読む

1. 発注データの送信
   • 送り先の取り違え
   • 接続IDの共有
2. 受信
   • 送り元のなりすまし
   • 障害時の再送
3. 受注システムへの取り込み
   • 取り込み前ファイルの書き換え
   • 同じ注文の二重取り込み
4. 保管
   • 閲覧できる人の範囲
   • サービス側と社内側の二か所保管
5. 請求データの返信
   • 宛先設定の誤り
   • 請求の二重送信

自社の運用で行うことと、提供元・取引先に確認することの分け方

課題別の担当主体の整理表

ここまでに見た課題を、誰が担うかで並べ直します。
次の表の「通常の担い手」は、EDIサービスを使う企業を想定した整理の提案です。
実際の責任範囲は契約とサービスごとに異なり、表のとおりに決まっているとは限りません。
自前でEDIソフトとサーバーを運用している場合は、提供元の欄の多くが自社に移ると読み替えてください。

表の中で判断が分かれやすいのは、証明書の期限管理と再送時の重複処理の二つです。
証明書は、発行するのは認証局、設定を受け持つのは提供元、期限を見張るのは自社、というように担い手が三者にまたがりやすく、全員が「誰かが見ているだろう」と考えて期限が過ぎる状態が生まれやすい項目です。
再送時の重複は、通信の側に検知の仕組みがあっても、取り込み側で照合していなければ二重登録を防ぎきれない場合があります。
どちらも、担い手を一つに決めきれないからこそ、境目を文書で確かめておく意味があります。

提供元を使っていること自体も、取引先から見れば確認の対象になり得ます。
IPAが取引先や委託先を狙った攻撃を組織向けの脅威の上位に挙げているように⁴、自社が委託している提供元は、取引先にとっては取引先の先にいる委託先だからです。
提供元に任せている部分を「任せています」で済ませず、どこまでを任せているかを言えることが、調査票への答えの厚みになります。

契約・仕様書で確かめる箇所

担い手を確かめるときに見る資料は、主に次の三つです。

• 契約書・利用規約：障害時の対応範囲、データの保管期間、委託先としての責任の範囲
• サービスの仕様書や機能確認シートへの回答：対応する通信手順、暗号化の設定、重複受信の扱い、証明書の設定方法
• 取引先との覚書や接続仕様：どの手順で接続するか、証明書を誰が用意するか、障害時の連絡先

契約書や仕様書に書かれていない項目は、提供元から書面やメールで回答をもらい、取引先へ説明するときの根拠として保管しておくと役立ちます。
担当者が替わっても同じ答えを出せますし、翌年に同じ調査票が届いたときに一から調べ直さずに済みます。
口頭で聞いた「大丈夫です」は、取引先から根拠を問われたときに示せないため、調査票の裏付けにはなりにくいのです。

自前で運用している場合は、仕様書の役目を、使っているEDIソフトの製品資料と、社内で作る運用手順書が担います。
手順書がまだ無いなら、証明書の更新手順と、障害時の再送と照合の手順から書き始めると、担当者の不在で止まりやすい場面を先に押さえられます。
どちらも年に何度もない作業で、前回の担当者がいなければやり方が分からなくなりやすいからです。

発注側・受注側、サービス利用・自前運用の別で、先に整えることと確認項目

発注側・受注側の違い

流通BMSでは、卸・メーカーの導入企業数が2025年6月時点で21,600社以上と推計され、その前の半年間で700社以上増えています¹。
この数字は導入の広がりを示す推計で、各社のセキュリティの水準を表すものではありません。
ただ、受注側の卸・メーカーにとって、取引先の小売から接続を求められる場面が身近にあることはうかがえます。

発注側、たとえば小売チェーンは、多数の取引先へ同じ形式で発注データを送り、請求データを受け取る立場です。
接続方式を指定し、取引先に準備や確認を求める側に回りやすく、先に整えるべきは、指定する通信手順と証明書の扱いを取引先が理解できる形で示すことと、取引先ごとの接続設定・接続IDの台帳です。
取引先が数百社に及べば、どの取引先がどの手順で、どの証明書を使ってつないでいるかが分からなくなること自体が、相手確認の穴になります。

受注側、たとえば先ほどの食品卸は、複数の発注元それぞれの指定に合わせて接続します。
取引先ごとに手順や証明書が違えば、管理する期限や設定もその数だけ増えます。
先に整えるのは、取引先ごとの接続方式・証明書の期限・社内の担当者を一覧にすることと、受信データの取り込み前後の照合です。
この一覧があれば、調査票に答えるときにも、取引先ごとの違いを踏まえた回答ができます。

サービス利用と自前運用の違い

EDIサービスを使う場合、通信の設定やサーバーの保守は提供元が担い、自社に残るのは接続IDと証明書の管理、ダウンロード後のデータの保管、取り込み時の照合が中心になります。
このとき取引先に説明できる内容は、提供元からどれだけ具体的な回答を集められるかに左右されます。

自前でEDIソフトとサーバーを運用する場合は、通信の設定、暗号化方式の版の見直し、ソフトの更新、サーバーの監視までが自社の仕事です。
SSLv3.0のような古い方式への対応を求められたとき²、設定を変えるのも、変えた後に取引先と順に疎通を確かめるのも自社になります。
取引先の数が多いほど、設定変更の影響を確かめる手間も増えます。

自前からサービスへ切り替えると、通信とサーバーの保守の多くは提供元に移ります。
それでも、相手確認の道具であるIDと証明書の管理、社内での保管、取り込み時の照合は自社に残ります。
さらに、提供元という委託先が一社加わるため、その対応範囲を確かめて記録する作業が新しく生まれます。
責任が減るというより、自社で手を動かしていた部分が、提供元に確認して記録する部分へ置き換わる、と考えると実態に近くなります。

取引先への確認項目リスト

取引先へ確認するとき、あるいは取引先からの確認依頼に答える準備をするときは、次の項目を並べておくと漏れが減ります。
並びは、止まると取引全体が止まる項目を先に置いた提案で、公的な優先順位ではありません。

• 通信方式（ebMS・AS2・JX手順・独自方式・Web EDIのどれか）と、暗号化方式の版や設定の指定
• 証明書の要否、発行元、有効期限、更新時の切り替え手順
• 接続IDとパスワードの発行単位と、担当者が替わったときの変更手順
• 障害時の連絡先と、再送するときの連絡の順序
• 重複受信を検知する仕組みの有無と、取り込み側での照合方法
• 送受信ログの保管期間と、問い合わせがあったときに誰が確認するか
• 受信データの社内での保管場所と保存期間

受注側の小規模事業者で手が回らない場合は、すべてを一度にそろえようとせず、証明書の期限、障害時の連絡先、再送時の照合の三つから始めるのが現実的です。
いずれも、通信が止まる、注文が二重に入るといった、取引先にも見える影響につながる項目です。
あらかじめ決めておけば、障害が起きてから慌てて取引先に問い合わせる場面や、どの注文が正しいかを一件ずつ確かめ直す作業を減らせます。

調査票の項目そのものは取引先ごとに異なります。
届いた調査票をこの一覧と照らし、通信の項目には暗号化方式と設定の担い手を、相手確認・保管・運用の項目には、ここまで整理した社内と提供元の実態を当てはめていけば、「暗号化しています」の一文で済ませずに、根拠のある答えを組み立てられます。

▼ 図の内容を文字で読む

• サービス利用で提供元が担う
  • 通信の設定
  • サーバーの保守
• どちらでも自社に残る
  • 接続IDと証明書の管理
  • ダウンロード後のデータの保管
  • 取り込み時の照合
  • 提供元の対応範囲の確認と記録
• 自前運用で自社に加わる
  • 暗号化方式の版の見直し
  • ソフトの更新
  • サーバーの監視

取引先から回答の期限を示されていても、どの項目が標準や取引先の指定で決まり、どれが提供元や自社の運用次第なのかを一人で切り分けるには手間がかかるためです。

届いた確認依頼と手元の契約書・仕様書を照らし合わせ、自社で答えられる項目と、提供元や取引先へ問い合わせる項目を分けて整理できます。無料相談で要件を整理する

要点の整理

軸	基準
暗号化の範囲	公衆回線を通る途中のデータを守る。相手確認・受信後の保管・再送は別に考える
回答の根拠	標準・取引先の指定、提供元、自社の運用の三つに分けて答える
証明書	申請・設定・疎通確認・期限監視を繰り返す。各段の担い手を決める
再送と重複	通信側の検知と、取り込み側の照合の両方を確かめる
運用形態	サービス利用でも、ID・証明書・社内保管・照合は自社に残る

取引先ごとに接続方式や証明書の扱いが違うと、確認項目の一覧を自社の実態に合わせて作り、どこから整えるかを決めるのが難しくなるためです。 取引先ごとの接続方式、証明書の期限、再送時の照合方法を一覧にする際に、先に整える項目と順序を一緒に確かめられます。

よくある質問

取引先のセキュリティ調査票に「通信を暗号化している」とだけ書いてよいですか。

通信の項目への答えとしては必要ですが、それだけでは相手確認、受信後の保管、障害時の対応には答えたことになりません。
通信方式と暗号化の設定を提供元と自社のどちらが管理しているかを添え、ほかの項目には接続IDや証明書の管理、社内での保管、再送時の照合の実態を書くと、取引先が知りたい内容に近づきます。

古いSSL/TLS設定のままでも、取引先とつながっていれば問題ありませんか。

つながっていることと、安全な方式で送っていることは別です。
流通BMSの標準ページには、SSLv3.0の脆弱性への対応を依頼する文書が掲載されています²。
いまどの版で接続しているかを提供元や社内の設定で把握し、推奨される版は通信プロトコル利用ガイドラインの最新版と取引先の指定で確かめてください。

電子証明書の期限切れでEDIが止まった場合、誰が対応するのですか。

契約と運用形態によって異なります。
証明書を自社名義で取得していれば、更新の申請は自社の手続になるのが自然で、EDIへの設定の差し替えは、サービス利用なら提供元との分担、自前運用なら自社が担います。
止まってから担い手を探すと復旧が遅れるため、期限を見張る人、更新を申請する人、設定を差し替える人、取引先と疎通を確かめる人を事前に決め、契約書や提供元の資料で境目を確かめておくことが大切です。

障害で再送した注文データが二重に取り込まれるのを防ぐには、何を確認すべきですか。

通信手順や提供元のサービスに重複受信を検知する仕組みがあるか、取り込み側で伝票番号などをもとに既存データと照合しているか、再送時に送り手と受け手のどちらが誰へ連絡するか、の三点です。
通信側の検知だけに頼らず、取り込み側の照合もあわせて確かめておくと、二重出荷や請求の重複を防ぐ手がかりが増えます。

自前運用からサービス利用に切り替えると、自社の責任範囲はどう変わりますか。

通信の設定やサーバーの保守の多くは提供元に移りますが、接続IDと証明書の管理、ダウンロード後の保管、取り込み時の照合は自社に残ります。
加えて、提供元という委託先の対応範囲を契約や仕様書で確かめ、取引先に説明できるよう記録する作業が新しく加わります。

受注側の小規模事業者は、まず何から整えればよいですか。

取引先ごとの接続方式・証明書の期限・社内の担当者を一覧にし、そのうえで証明書の期限、障害時の連絡先、再送時の照合の三つを決めるところから始めると進めやすくなります。
接続IDを複数人で共有している場合は、担当者が替わったときにパスワードを変える手順もあわせて決めておくと、相手確認の穴を減らせます。

1. 1　出典：一般財団法人流通システム開発センター（GS1 Japan）／流通BMS協議会「流通BMS トップページ（導入企業数推計）」（2025年）
2. 2　出典：一般財団法人流通システム開発センター（GS1 Japan）「通信基盤関連の標準（流通BMS標準仕様）」（掲載年不明）
3. 3　出典：一般財団法人流通システム開発センター（GS1 Japan）「通信制御手順（EDI標準）」（掲載年不明）
4. 4　出典：独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威2026（組織編）」（2026年）