Web-EDIの認証要件の決め方：ID・パスワードで足りるかを取引データ別に判断する

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

B2B EC-COLUMN

取引先から切り替えを求められたとき、Web-EDIの認証要件は「誰が・何に・どこから」で決める

取引先からWeb-EDIでの受発注に切り替えたいと言われ、認証をID・パスワードだけにしてよいのか判断できず、社内のセキュリティ確認で止まってしまう。
そうした場面で頼れる公的な共通の最低ラインは、今回確かめた資料の中には見当たりませんでした。
認証要件の基準になるのは、取引先のどの担当者が、どの受発注データに、どの経路から触れるかを自社で整理した結果です。
多要素認証には、パスワードを悪用されてもそれだけではログインさせない効果があります。
そのため、取引データの重要度に応じて段階的に導入できます。
方式を選んだあと、ID管理の運用ルールと取引先への案内まで決めてはじめて、要件として通せる形になります。

取引先から言われたときに最初に整理する3つのこと

方式の名前を並べる前に、Web-EDIの画面に誰が入り、何を見て、何を操作するのかを書き出します。
多要素認証を入れるか、IP制限をかけるかといった判断は、この整理がないと根拠を説明できません。

1つ目は「誰が」です。
取引先のどの部署の、どの役割の人がログインするのかを確かめます。
営業担当が注文を確認するだけなのか、経理担当が請求を確定させるのか、あるいは物流担当が出荷数を入力するのかで、必要な権限は変わります。
1つのIDを複数人で使い回す運用になりそうかどうかも、ここで見ておきます。
共有IDでは、誰がいつ何をしたかを後から追えず、担当者が辞めてもパスワードを知る人が社外に残ります。

2つ目は「何に」です。
注文、出荷、請求、単価、取引先の口座や連絡先など、画面で扱うデータを種類ごとに分けます。
そのうえで、閲覧だけなのか、登録・変更・確定まで行うのかを区別します。
同じ注文データでも、見るだけの画面と、数量や納期を書き換えられる画面とでは、不正にログインされたときの影響が違います。

3つ目は「どこから」です。
取引先の社内のパソコンからだけ使うのか、在宅や外出先のノートパソコン、スマートフォンからも使うのかを確かめます。
経路が限られていればIP制限のような手段が使えます。
一方で、経路が広がるほど、パスワードが盗まれたときの入口も広がります。

この3つを、取引先ごと・データの種類ごとに一覧表にしておくと、後の節で方式を比べるときも、社内の確認で理由を説明するときも、同じ表を土台にできます。

ID・パスワードだけの運用で足りるかの見方と、多要素認証が防ぐこと・防げないこと

ID・パスワードだけで足りるかどうかは、パスワードが漏れたときに何が起きるかで考えます。
IPAは、不正ログインの手口として、パスワードの推測、他のサービスで流出した情報の使い回しの悪用、偽のログイン画面などで入力させるフィッシングを挙げています²。
どれも、パスワードという1つの情報さえ手に入れば正規の利用者になりすませる、という弱点を突く手口です。

多要素認証は、記憶情報（パスワードなど）、所持情報（スマートフォンや専用の機器など）、生体情報（指紋など）のうち2つ以上を組み合わせる方式です。
IPAは、IDと1つ目のパスワードを不正に利用されてもそれだけではログインできないため、不正ログインの防止に効果があると説明しています¹。
サービスによっては「2段階認証」など別の呼び方をしていることにも触れています¹。
また、パスワードを使わずにログインできるパスキーも推奨されています。
ただし、パスキーを使うにはサービス側が対応している必要があります²。

IPAのこれらの説明は、SNSやショッピングサイトなど各種インターネットサービスの利用者向けで、Web-EDIを名指ししたものではありません。
また、企業間取引での被害の統計を示した資料でもありません。
それでも、ブラウザでIDとパスワードを入力してログインするという仕組みは共通しています。
そのため、同じ手口がWeb-EDIのログイン画面にも向けられうる、と考えて要件を組むのは筋の通った当てはめです。

一方で、多要素認証が防ぐのは「本人でない人がログインすること」です。
正規の担当者がログインしたあとの誤操作、必要以上に広い権限設定、退職者のIDが残り続けることは、多要素認証だけでは解決しません。
認証方式を強めても、IDの発行や削除、権限の付け方が緩ければ穴は残ります。
この点は、運用の要件を扱う節で具体的に整理します。

社内のセキュリティ確認で止まったときの説明の順序

社内の確認で止まるのは、多くの場合「どの基準に照らしてこの方式で十分なのか」と問われ、答えになる基準を示せないからです。
Web-EDIの認証方式を一律に定めた公的な最低ラインは、今回確かめた資料の中には見当たりませんでした。
ですから、外部の基準に頼るより、自社で決めた理由を順序立てて示すほうが確認は進みます。

説明は次の順に組み立てると、確認する側が判断しやすくなります。
・取引先・担当者・データ・経路の一覧表（前の見出しで作ったもの）
・想定している不正ログインの手口と、それが成功したときに影響するデータ
・選んだ認証方式と、その方式で止められる手口・止められない手口
・止められない部分を補う運用ルール（ID発行、削除、再設定、ログ、不正時の対応）
・取引先に何を求め、何を自社が用意するか

この順なら、「なぜ全取引先に同じ方式ではないのか」「なぜここだけ多要素認証なのか」といった質問にも、表の該当する行を示して答えられます。
次は、選択肢になる方式をそれぞれ何を守り、誰にどんな手間をかけるかという同じ物差しで比べます。

多要素認証・電子証明書・IP制限・SSOは何を守り、どんな負担をかけるか

比較の軸：守れる範囲・取引先の準備・自社の運用

方式を比べるときは、「守れる範囲」「取引先の準備負担」「自社の運用負担」という3つの軸をそろえます。
セキュリティの強さだけで比べると、取引先が実際には使えない方式を選んでしまいます。
反対に、取引先の手軽さだけで比べると、社内の確認を通せません。

下の表では、ID・パスワードを基準に置き、ほかの方式を並べました。
多要素認証の効果はIPAの説明に基づきます¹。
電子証明書、IP制限、SSO連携の欄は、提供者や製品を問わない一般的な性質を整理したものです。
実際の機能や手間は、使うWeb-EDIの仕様によって変わります。
どれが優れているという順位ではありません。

表のうち判断が分かれやすいのは、取引先の準備負担です。
多要素認証は、取引先の担当者がスマートフォンなどの2つ目の要素を業務で使えることが前提になります。
私物のスマートフォンを業務に使えない会社もあります。
また、端末を紛失したり機種変更したりすると、再登録の依頼が導入側の窓口に届きます。
その受付と本人確認の手順まで決めておかないと、運用が回りません。

IP制限は、取引先が決まった接続元から使う場合には分かりやすい方法です。
ただし、在宅勤務や外出先からの利用があると使えない場面が出ますし、取引先の回線が変わるたびに登録の変更が要ります。
SSO連携は、自社の社員がWeb-EDIを使う場面では管理をまとめやすくなります。
一方、取引先は別の組織なので、取引先が連携できる認証の仕組みを持っているかどうかに左右されます。
すべての取引先に一律に求められる方式ではありません。

流通BMSの電子証明書とブラウザ型Web-EDIの利用者認証の違い

「業界標準では電子証明書を使うことになっている」と聞いて、Web-EDIのログインにも証明書が必要だと考える担当者は少なくありません。
ここは対象を分けて考える必要があります。

流通BMS協議会は、インターネットで流通BMSのデータを送受信する際の通信プロトコルとセキュリティの標準仕様をまとめた「通信プロトコル利用ガイドライン」を公開しています⁴。
あわせて、AS2・ebMS・J手順という通信手順ごとの機能確認シートや、証明書を発行する認証局が守るべき事項をまとめた「流通業界共通認証局証明書ポリシー」も公開しています⁴。
これらは、企業のシステム同士が自動でデータをやり取りする通信の枠組みです。

ブラウザ型のWeb-EDIで問われるのは、画面の前にいる取引先の担当者が本人かどうかです。
流通BMSの証明書の枠組みは、システム間通信で相手のシステムを確かめるためのものです。
人がブラウザでログインする場面の要件として定められたものではありません。
ですから、流通BMSに証明書の仕組みがあることを理由に、Web-EDIのログインにも証明書が必須だとは言えません。
なお、協議会のページには過去の改定内容が含まれているため、現在の運用は協議会に確かめるのが確実です⁴。

方式を組み合わせる考え方

方式は1つを選ぶものではなく、表の「守れる範囲」が重ならないように組み合わせるものです。
たとえば、パスワードが漏れた場合への備えとして多要素認証を置き、接続元が限られる一部の取引先にはIP制限を重ねる、といった組み方が考えられます。

組み合わせるほど守れる範囲は広がりますが、取引先の準備と自社の窓口対応も積み上がります。
前の節の一覧表で影響の大きいデータに触れる行を選び、そこから優先して強める方式を割り当てます。
そうすれば、すべての取引先に最も重い組み合わせを求めずに済みます。
どの行にどの組み合わせを当てるかの考え方は、要求の出どころを確かめたあとで段階分けとして扱います。

▼ 図の内容を文字で読む

1. 多要素認証
2. 守れる範囲：IDとパスワードを不正利用されてもそれだけではログインできない
3. 取引先の準備：スマートフォンなど2つ目の要素を業務で使えること
4. 自社の運用：紛失・機種変更時の再登録の受付と本人確認
5. 電子証明書

守るべき最低ラインは誰が決めるか：取引先の基準、業界標準、発注側が求めるときの注意点

要求の出どころを4つに分けて確認する

認証要件の最低ラインは、どこか1か所に書かれているものではありません。
Web-EDIを導入する立場で守るべき要求は、相手や契約ごとに別々のところから来ます。
そのため、出どころを分けて一覧にし、それぞれで何が求められているかを確かめるのが現実的です。

・取引先の基準：取引先が自社のセキュリティ方針として、接続する仕組みに求めている条件
・契約：取引基本契約や個別の覚書、機密保持の条項に書かれた、データの扱いやアクセス管理の取り決め
・監査：自社や取引先が受ける内部監査・外部監査で確認される項目
・業界標準：業界団体が公開している標準仕様やガイドライン

出どころごとに一覧を作っておくと、社内の確認で「この要件はどこから来たのか」と問われたときに答えやすくなります。
どこにも書かれていない部分は、自社判断で上乗せする部分として扱うと整理しやすくなります。
自社判断の部分は、最初の節で作ったデータの一覧表に基づいて理由を説明します。

流通BMSのWeb-EDIガイドラインの位置づけ

業界標準の中でWeb-EDIを直接扱っている資料として、流通BMS協議会の「流通BMSにおけるWeb-EDIガイドライン」があります⁵。
協議会のページによると、このガイドラインは、取引先ごとに仕様が異なるWeb-EDIが乱立することを抑える目的の基本方針に沿ったものです⁵。
柱は、Web-EDIの位置づけ、適応要件、機能要件の3つです⁵。

受注側からすると、発注先ごとに画面も操作も違うWeb-EDIに付き合わされる負担は大きいものです。
その負担を減らすための業界の取り決め、というのがこのガイドラインの出発点です。
認証についても、自社独自の重い仕組みを足す前に、業界でそろえる方向と合っているかを見ておく意味があります。

ただし、ガイドラインの中で認証が具体的にどう定められているかは、本記事では確かめられていません。
流通業界で取引していて、このガイドラインに沿うことが求められる場合は、協議会が公開しているガイドライン本体で該当箇所を確認してください。
流通業界以外の取引には、そのまま当てはまる資料ではありません。

取引先へ対策を求めるときの独占禁止法上の注意

Web-EDIを用意して取引先に使ってもらう側は、認証要件を決めると同時に、それを取引先に求める立場にもなります。
この場面については、経済産業省と公正取引委員会が2022年に考え方を公表しています³。

その整理では、発注側が取引先にサイバーセキュリティ対策を要請すること自体は、直ちに独占禁止法上の問題にはならないとされています³。
一方で、取引先より優越的な地位にある発注側が次のことをすると、問題となり得るとされています³。
・対策によるコスト上昇を考えずに、著しく低い対価を一方的に決める
・負担額やその算出根拠が明確でないまま、費用の負担を求める
・合理的な必要性がないのに、指定した商品やサービスの購入・利用を強制する
また、下請法の対象となる取引では、下請法の規律が適用されます³。

この資料は、認証方式の基準を定めたものではありません。
しかし、多要素認証のために特定の機器やアプリを取引先に買わせる、証明書の発行費用を取引先に負担させるといった設計をするなら、そのまま関係してきます。
要件を決める段階で、取引先側にどんな準備と費用が生じるかを書き出しておけば、後の案内でも説明できます。

▼ 図の内容を文字で読む

1. 取引先の基準・契約・監査・業界標準
2. 出どころごとに確かめて一覧にする
3. 書かれていない部分
4. 自社判断で上乗せし、データの一覧表を理由にする
5. 取引先へ求めるとき

取引の重要度と取引先の対応力で、求める認証の強さを段階に分ける

重要度の段階を決める考え方

要求の出どころを確かめても、多くの取引先については明確な指定がなく、自社判断で決める部分が残ります。
その部分を全取引先に一律の方式で埋めようとすると、重要な取引に対しては弱すぎ、軽い取引に対しては重すぎる要件になりがちです。
そこで、最初の節で作った一覧表のデータの種類と操作の内容から、段階を分けます。

段階の分け方の仮の例を挙げます。
実在する企業の運用ではなく、考え方を示すための例です。
・標準の段階：注文の閲覧や出荷予定の確認など、見るだけの操作が中心で、単価や個人情報を扱わない。
長く複雑で使い回さないパスワード¹と、個人ごとのID、定期的なIDの棚卸しを求める
・重要の段階：注文の登録・変更や請求の確定など、取引の金額や数量を動かす操作がある。
多要素認証を求める
・特に重要な段階：振込先や単価のマスタの変更など、書き換えられると被害が直接お金に結びつく操作がある。
多要素認証に加え、接続元の限定や、変更時の別経路での確認を組み合わせる

どの金額や取引量で段階を切るかは、自社の取引の実態で決めるものです。
一般的な目安になる値はありません。
大切なのは、段階の境目を「どのデータに、どんな操作で触れるか」で説明できることです。
そうしておけば、新しい取引先が加わったときも、一覧表に行を足して当てはまる段階を判断できます。

取引先の規模が違うときの調整

同じ重要度の取引でも、取引先によって対応できることは違います。
情報システムの担当者がいて、すでに社内で多要素認証を使っている取引先もあれば、数人で受発注から経理までこなしている取引先もあります。

調整の考え方は2つあります。
1つは、求める「守れる範囲」は同じに保ち、満たす手段に幅を持たせることです。
たとえば2つ目の要素として、スマートフォンのアプリが使えない取引先には別の手段を選べるようにする、といった設計です。
もう1つは、取引先がすでに同等以上の対策を講じている場合には、それを認めることです。
経済産業省と公正取引委員会の整理でも、合理的な必要性なく指定したサービスの利用を求めることは問題となり得る行為に挙げられています³。
取引先の既存の対策を確かめずに自社指定の手段を一律に求める設計は、避けたほうが無難です。

段階の割り当ては、一度決めたら終わりではありません。
導入後に、ログインの失敗や再設定の依頼、問い合わせがどの段階のどの取引先に集中しているかを見ます。
そうすると、要件が重すぎる箇所や、案内が伝わっていない箇所が分かります。
見直しの材料は、こうした自社の運用の記録から得られます。

▼ 図の内容を文字で読む

1. 標準の段階
2. 注文の閲覧や出荷予定の確認など、見るだけの操作が中心
3. 長く複雑で使い回さないパスワード、個人ごとのID、定期的なIDの棚卸し
4. 重要の段階
5. 注文の登録・変更や請求の確定など、金額や数量を動かす操作がある

日々の運用で要件に入れる項目：ID発行、権限、退職者の削除、本人確認つき再設定、ログ、不正時の対応

ID発行と権限設定

方式と段階が決まっても、IDがどう発行され、どんな権限が付くかが曖昧だと、強い認証も意味を失います。
要件として決めておきたいのは、誰が発行を申請し、誰が承認し、どの権限を付けるかです。

Web-EDIでは、IDを使うのは取引先の担当者ですが、発行するのは導入側です。
取引先の誰からの申請なら受け付けるのかを決めておかないと、取引先の社内で承認されていない人にIDが渡ることがあります。
取引先側に申請の責任者を1人決めてもらい、その人からの申請だけを受け付ける形にすると、発行の経路が1本になります。

権限は、最初の節で分けた「閲覧」「登録・変更」「確定」の区別をそのまま使います。
必要な操作だけができる権限を付けておけば、IDが悪用された場合でも被害は権限の範囲にとどまります。
正規の担当者の誤操作による影響も同じように抑えられます。
IDは1人に1つとし、共有IDを作らないことも要件に入れておきます。

退職者・異動者の削除連絡

運用でいちばん穴になりやすいのが、取引先の担当者が退職したり異動したりしたときのIDの削除です。
取引先の人事の動きは導入側からは見えないため、連絡がなければIDはそのまま残ります。
多要素認証を入れていても、辞めた人が2つ目の要素を持ったままなら、ログインできてしまいます。

対策として要件に入れたいのは、次の2つの仕組みです。
1つは、異動や退職があったら連絡してもらう窓口と期限を、案内や取り決めに明記することです。
もう1つは、連絡に頼りきらず、導入側から定期的にID一覧を取引先の申請責任者に送り、今も使っている人かどうかを確かめてもらう棚卸しです。
長いあいだログインのないIDを抽出して確認の対象にすれば、連絡漏れに気づくきっかけになります。
棚卸しの頻度は、段階の重要度に合わせて自社で決めます。

再設定の本人確認とログの確認

パスワードを忘れた、スマートフォンを替えたという再設定の依頼は、日常的に導入側の窓口に届きます。
この依頼を、電話やメールで名乗った人の言葉だけで処理すると、なりすました第三者に新しいパスワードを渡すことになりかねません。
IPAは不正ログインの手口としてフィッシングを挙げています²。
窓口への依頼を装ってログイン情報を引き出そうとする手口にも、同じ注意が要ります。

再設定の要件としては、登録済みの連絡先へ折り返して確認する、申請責任者に確かめる、といった本人確認の手順を決めておきます。
多要素認証の2つ目の要素を登録し直すときも、同じ手順を通すようにします。
手順を文書にしておけば、窓口の担当者が替わっても判断がぶれません。

ログについては、誰のIDが、いつ、どこから、何の操作をしたかを記録し、誰がどんなときに見るのかを決めておきます。
記録があっても、見る人と見るきっかけが決まっていなければ、不正の兆候に気づけません。
見慣れない接続元からのログインや、同じIDでの続けての失敗など、確かめるきっかけにする事象を挙げておきます。

不正ログインが疑われたときの対応

不正ログインが疑われたときに慌てないよう、止める・調べる・知らせる・戻すの順を要件として決めておきます。
まず該当するIDを止めます。
次にログで、そのIDがどのデータを見たか、何を変更したかを確かめます。
そのうえで取引先の窓口へ連絡し、変更された注文や請求の有無を一緒に確認します。
最後に、本人確認を経てIDを再開するか、新しく発行し直します。

社内の規程や対応手順の雛形がない場合は、IPAの「中小企業の情報セキュリティ対策ガイドライン」第4.0版が出発点になります。
このガイドラインは経営者編と実践編で構成され、付録に情報セキュリティ関連規程のサンプルや、セキュリティインシデント対応の手引きなどが用意されています⁶。
個人事業主や小規模事業者を含む中小企業等を想定した資料です⁶。
大企業の取引先が独自の基準を示している場合は、そちらの要求が優先します。

▼ 図の内容を文字で読む

1. 申請責任者からの申請と承認
2. IDの発行と操作に応じた権限の付与
3. 利用・本人確認つきの再設定・ログの確認
4. 異動・退職の連絡と定期的な棚卸し
5. IDの削除と権限の見直し

取引先へ案内して移行する：伝える6項目と移行期間の進め方

案内に入れる6項目

ここまでで決めた要件は、取引先から見ると「何を準備し、何を守ればよいか」という形で伝わらなければ動きません。
案内には、次の6項目を入れます。
・対象となるデータと目的：どの取引のどのデータを扱う画面で、なぜ認証を強めるのか
・必須とする認証の手段：段階ごとに求める方式と、選べる手段の幅
・取引先側で必要になる準備：端末や2つ目の要素、申請責任者の選任など
・IDの発行・削除の連絡窓口：申請の出し方、異動・退職時の連絡先と期限
・不正ログインが疑われるときの連絡先：取引先側で異変に気づいたときにどこへ知らせるか
・移行期間中の併用方針：いつまで従来の方法と併用し、いつから新しい要件に切り替えるか

取引先に費用がかかる準備や、自社が指定するサービスの利用を求める場合は、その旨を案内の中ではっきり書きます。
負担額や算出根拠が明確でないまま費用の負担を求めることは問題となり得る、と経済産業省と公正取引委員会は整理しています³。
案内の段階で負担の内容と根拠を示し、協議の機会を設ける前提で書いておくと、後から取引先との認識のずれが起きにくくなります。
取引が下請法の対象になるかどうかは取引の実態によって異なるため、判断が必要な場合は社内の法務部門などに確かめます。

移行期間中の併用と見直し

多くの取引先が今はID・パスワードだけで使っている場合、ある日を境に全員に多要素認証を必須にすると、準備が間に合わない取引先がログインできなくなります。
受発注が止まれば、困るのは導入側も同じです。
そこで移行期間を設け、その間は従来の方法と新しい方法を併用できるようにします。
併用を終える日を最初に決めて案内しておくことが大切です。
終わりの見えない併用期間は、結局は弱い方法が残り続ける原因になります。

移行中は、取引先ごとの対応状況を一覧にして、準備が済んだ取引先、問い合わせ中の取引先、まだ連絡のない取引先を分けて把握します。
この一覧は担当者ごとに受け持ちを分けて進められます。
寄せられた問い合わせを内容ごとに分けて数えると、案内文のどこが分かりにくいかが見えてきます。
分かりにくい箇所を案内文に反映すれば、後から対応する取引先ほど問い合わせが減っていきます。

移行後も、ログインの失敗や再設定の依頼が特定の段階に集中していないかを見て、段階の割り当てや手段の幅を見直します。
認証要件は、取引先の顔ぶれや扱うデータが変わるたびに、最初の一覧表に戻って更新していくものです。

取引先・データ・経路の一覧表を作っても、どの行にどの方式を当てるかは自社だけでは判断がつきにくく、社内の確認で同じ質問が繰り返されがちです。

作成中の一覧表をもとに、段階の分け方と各段階に当てる認証方式の筋道を整理し、社内で説明する順序を一緒に確かめられます。無料相談で要件を整理する

要点の整理

最初に整理すること	取引先のどの担当者が、どのデータに、どの経路から触れるか
ID・パスワードだけで足りるか	パスワードが漏れたときに動かされるデータの重要度で判断する
多要素認証の役割	パスワードを悪用されてもそれだけではログインさせない。ID管理の穴は防げない
最低ラインの出どころ	取引先の基準・契約・監査・業界標準を個別に確かめ、残りを自社判断で決める
流通BMSの電子証明書	システム間通信が対象で、ブラウザのログイン要件とは別
取引先へ求めるとき	費用負担の内容と根拠を示し、合理的な必要性のない指定を避ける
運用の要件	申請経路、操作に応じた権限、削除連絡と棚卸し、本人確認つき再設定、ログ、不正時の手順
移行	併用を終える日を先に決め、対応状況と問い合わせで案内を直す

要件が固まっても、取引先への案内や移行期間の設計では、取引先の負担と自社の運用の両方を見ながら決める箇所が残ります。 案内に入れる6項目の書き方と、併用期間の終わり方、問い合わせを踏まえた見直しの進め方を確認できます。

よくある質問

ID・パスワードだけで運用している取引先が多い場合、いきなり多要素認証を必須にしてよいですか。

一斉に必須にすると、準備が間に合わない取引先がログインできなくなり、受発注が止まるおそれがあります。
取引データの重要度で段階を分け、金額や数量を動かす操作がある取引先から順に求めるほうが現実的です。
あわせて、併用を終える日を先に決めた移行期間を設けます。
取引先側に費用や準備が生じる場合は、負担の内容と根拠を案内で示し、協議の余地を残しておきます。

流通BMSの電子証明書は、ブラウザで使うWeb-EDIのログインにも使えますか。

流通BMS協議会が示している証明書の枠組みは、AS2・ebMS・J手順といった、システム同士が自動でデータをやり取りする通信を対象にしたものです。
ブラウザの前にいる担当者が本人かどうかを確かめるWeb-EDIのログインとは、対象が異なります。
流通BMSに証明書の仕組みがあるからといって、Web-EDIのログインに使える、あるいは必須だとは言えません。
Web-EDIで証明書を使えるかどうかは、利用するWeb-EDIの仕様で確かめます。

取引先の担当者が退職・異動したとき、ID削除をどう確実に連絡してもらえばよいですか。

連絡だけに頼らない仕組みにすることが要点です。
取引先に申請責任者を1人決めてもらい、異動・退職時の連絡先と期限を案内や取り決めに明記します。
そのうえで、導入側から定期的にID一覧を申請責任者に送り、今も使っている人かを確かめてもらいます。
長くログインのないIDを抽出して確認すれば、連絡漏れに気づくきっかけになります。

取引先に認証強化を求めるとき、費用はどちらが負担するのが妥当ですか。

どちらが負担すべきかを一律に定めた基準はありません。
経済産業省と公正取引委員会の整理では、対策の要請自体は直ちに問題とはなりません。
ただし、優越的な地位にある発注側が、負担額や算出根拠を明確にしないまま費用負担を求めることは、問題となり得るとされています。
合理的な必要性なく指定サービスの利用を強制することも同様です。
取引先に負担が生じる場合は、内容と根拠を示して協議する前提で案内を設計します。

パスワードの定期変更は要件に入れるべきですか。

本記事で確かめた資料の中には、Web-EDIでパスワードの定期変更を求める基準は見当たりませんでした。
IPAが推奨しているのは、パスワードをできるだけ長く複雑にし、使い回さないことです。
定期変更を入れるかどうかは、取引先の基準や監査で求められているかを確かめて判断します。
求められていない場合は、使い回しの防止や多要素認証など、漏れたときの影響を抑える要件を優先して検討します。

不正ログインが疑われたとき、取引先へ何をどの順で連絡すればよいですか。

まず該当するIDを止め、ログでそのIDが見たデータと変更した操作を確かめます。
そのうえで取引先の窓口へ、止めたIDと疑いの内容、変更された可能性のある注文や請求を伝え、一緒に確認します。
確認が済んだら、本人確認を経てIDを再開するか、発行し直します。
連絡先と手順は事前に案内しておき、社内の手順の雛形にはIPAのガイドラインの付録にあるインシデント対応の手引きを使えます。

1. 1　出典：独立行政法人情報処理推進機構（IPA）「不正ログイン対策」（2023年更新）
2. 2　出典：独立行政法人情報処理推進機構（IPA）「安心相談窓口だより」（2025年）
3. 3　出典：公正取引委員会・経済産業省「サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップの構築に向けて」（2022年）
4. 4　出典：流通システム標準普及推進協議会「流通BMS標準仕様：通信基盤関連の標準」（2015年改定を含む）
5. 5　出典：流通システム標準普及推進協議会「流通BMSにおけるWeb-EDI」（2012年）
6. 6　出典：独立行政法人情報処理推進機構（IPA）「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（2026年）