Web-EDI要件の整理｜業務・法令・接続方式

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

B2B EC-COLUMN

Web-EDIとは

Web-EDIとは、ブラウザ画面や標準的な通信手順を用いて、受発注のデータを取引先と電子的に交換する仕組みです。専用回線や専用端末を前提とした従来型EDIと違い、通信基盤をインターネットに置く点が特徴といえます。導入の成否を分けるのは製品の選定よりも、業務・データ・法令・運用の4分類で要件を先に固められるかどうかです。本節では定義と仕組みを確認し、要件整理の起点をそろえます。

Web-EDIの仕組みは、3つの層に分けて捉えると分かりやすくなります。取引先が発注情報を入力または送信する層、データを受け渡す通信の層、自社の基幹システムへ取り込む層です。どの層に人手の入力や転記が残るかを押さえると、要件の抜けが見つかります。ブラウザ画面での入力とファイルの自動連携が併存する形も珍しくありません。層ごとに担当する部署が違う点も、あわせて確認しておきたい部分です。

従来型EDIとの違いは、通信基盤と入力の方法に表れます。従来型は交換回線や専用線を前提とし、回線と端末の維持費が固定的に発生してきました。通信事業者の案内では、ディジタル通信モードを用いる回線サービスが2028年12月に終了する見込みが示されています^*8。回線の終了時期は、移行の判断期限を逆算する材料になります。

もう一つの違いは、データ項目の管理と取引先の負担の置き方です。従来型は公表された標準仕様に沿った項目定義を前提としますが、Web-EDIでは提供元ごとに画面と項目が異なります。そのため取引先は複数の画面へ都度ログインし、自社の帳票へ転記する手間を抱えがちです。負担がどちら側に寄っているかを確かめると、要件の優先順位が定まります。

電子取引の利活用状況は、民間団体の年次調査で継続的に把握されています^*7。実務では取引先ごとに手段が乱立し、電話・紙・メール添付が併走する状態が残ります。手段が3系統以上に分かれると、担当者は入力先の判断だけで時間を使います。ここを整理せずに製品を選ぶと、業務の形が製品側の都合で決まってしまいます。

要件を先に整理する理由は、後戻りの費用が大きくなる点にあります。項目定義や保存の要件を決めずに稼働させると、追加開発と取引先への再説明が同時に発生します。電子取引データの保存要件を満たさないまま運用すれば、税務調査の場面で保存義務を果たしていないと判断される可能性も残ります^*3。要件整理は、その種の手戻りを避けるための工程にほかなりません。

本節では定義と従来型との違いを確認しました。次節では、要件を洗い出す手順そのものを扱います。前者が何を対象にするか、後者がどの順で決めるかという役割の違いです。

Web-EDIの要件を整理する進め方

要件整理は、現行フローの洗い出し、役割の切り分け、要件の分類という3段階で進めます。最初に取引先ごとの手段を可視化し、次に自社と取引先のどちらが何を担うかを決め、最後に検討軸へ振り分けます。振り分けの単位は、業務・データ・法令・運用の4分類です。順序を入れ替えると、決めたはずの項目が後工程で覆ります。3段階のどこで誰が判断するかも、あらかじめ決めておきたい点です。

現行フローの洗い出しでは、取引先ごとの手段の一覧化から始めます。発注の受け口、出荷連絡、請求の送付を列に並べ、取引先を行に置くと欠けが見えます。続いて手作業と転記の特定に進み、どの画面から何をどこへ写しているかを記録します。1件あたりの操作回数まで書き出せば、後の効果測定の基準にも使えます。記録の粒度は、担当者が日々使う画面の単位に合わせます。

役割の切り分けでは、自社の標準の定義を先に置きます。項目名・コード・締め時刻を自社側で決め、取引先へ合わせてもらう範囲と、こちらが合わせる範囲を分けます。そのうえで取引先の負担の確認へ移り、画面入力しか選べない相手と、ファイル連携ができる相手を区別します。区別の結果は、後の接続方式の割り当てに直結するでしょう。

要件の分類では、4分類のうち業務とデータの区分を先に固めます。対象業務の範囲と交換するデータ項目は互いに依存するため、同時に検討したほうが手戻りが減ります。続けて法令と運用の区分を置き、取引条件の明示や保存の要件、問い合わせ体制を並べます。分類の枠を先に作ると、埋まっていない箱がそのまま見えます。

3段階を回すには、業務・情報システム・経理の3領域から担当者を集める必要があります。項目定義は業務側、通信と連携は情報システム側、保存と請求は経理側に知見が偏っているためです。1人が兼務すると、決められない項目が保留のまま残ります。決定権を持つ人を会議体に含めておけば、差し戻しが減ります。

洗い出しを省くと、稼働後に例外処理の穴が現れます。欠品・分納・訂正のような日常的な例外が設計に入っていないと、担当者は表計算での手処理へ戻ります。手処理が戻れば、電子化の効果は測れません。要件整理の目的は、この後戻りを設計の段階で潰すことにあります。ここまでの3段階が、後続の各節の検討の土台になります。

自社の商流に合わせた要件整理を進めたい場合は、無料相談で要件を整理するのが近道です。

業務プロセスに関する要件

業務プロセスの要件は、対象範囲・データ項目・例外処理の3点で決まります。見積・発注・出荷・検収・請求の5工程のうち、どこを電子化しどこを人が判断するかを線引きします。そのうえで取り扱うデータ項目とコード体系をそろえ、締め処理と例外の扱いを明文化します。範囲を広げすぎると初期の合意が取れず、狭すぎると転記が残ります。線引きの基準を先に決めておけば、議論が個別の好みに流れません。

対象範囲は、見積・発注・出荷・検収・請求の5工程で区切ると議論しやすくなります。発注データの受信だけを電子化しても、出荷の指示が電話のままなら効果は限られます。工程ごとに、電子化する・当面は人が扱う・対象外とするの3区分で決めていきます。区分した理由も残しておけば、次の見直しで判断をやり直せます。

データ項目は、取引先コード・商品コード・数量単位の3系統から整えます。同じ商品に取引先側と自社側で別の番号が付いている場合、対応表の維持そのものが要件になります。数量単位の換算やロット指定の有無も、ここで確定させておきたい項目です。項目定義の曖昧さは、検収の照合の段階で差異として表面化します。

締め処理では、締め時刻と締め後の受付方法を決めます。締め後に届いた発注を翌日扱いにするか当日扱いにするかで、出荷の指示の作り方が変わります。例外は欠品・分納・訂正・返品の4種を最低限として扱い、それぞれの連絡手段と記録の残し方を定めます。請求の突き合わせで差異が出たときの調整窓口も、あらかじめ決めておきます。

工程をまたぐ要件は、責任の切れ目に穴が生じやすい部分です。受注の確定は営業事務、在庫の引き当ては物流、請求は経理と、担当が分かれるためです。工程間の受け渡しで何をもって完了とするかを1文で書き出すと、穴が見つかります。書き出した完了条件は、そのまま受入確認の観点に使えます。

対象範囲を決める際は、取引量の分布も見ておきます。明細件数が上位の取引先に集中している場合、その相手に合う方式を先に決めるほうが効果が早く出ます。少量多数の取引先には、画面入力を残す判断も現実的でしょう。分布に基づく順序づけは、次節で扱う接続方式の選定にもつながります。分布は繁忙期と閑散期の2時点で見ておくと、判断がぶれません。

データと接続方式に関する要件

接続方式は、ブラウザ画面の入力・ファイル転送・API連携の3系統から取引先ごとに割り当てます。判断の材料は、取引量、相手の対応可否、自社の基幹システムの受け口の3つです。公表された標準メッセージに沿えるなら項目定義の議論を短縮でき、独自形式なら変換の設計が要件になります。基幹システムとの連携方式まで含めて決めれば、二重入力が残りません。

標準メッセージは、業界で公表されている標準仕様に沿うかどうかで検討します。流通分野では2018年に公表された標準仕様が使われ、項目とメッセージの体系が公開されています^*6。標準に沿えば、取引先が既に対応している見込みが高まります。独自形式を選ぶ場合は、項目の追加や桁数の変更のたびに双方で改修が必要になる点を織り込みます。

通信方式では、ファイル転送とAPI連携の性質の違いを押さえます。ファイル転送は1日数回のまとめ送信に向き、件数が多い受発注で扱いやすい方式です。API連携は1件ごとの即時反映に向きますが、相手側にも実装の負担が生じます。ブラウザ画面の入力は相手の準備が軽い一方、自社側に転記の手間が残ります。方式ごとに適する場面と確認する点を並べておくと、取引先への割り当てが進みます。

基幹システムとの連携方式は、即時か定時かをまず決めます。受注残や在庫の引き当てを即時に反映するなら中間テーブルとAPIの組み合わせ、日次で足りるならファイル連携が扱いやすくなります。どちらの場合も、マスタの同期の周期と、取り込みに失敗したときの再実行の手順が要件です。再実行の設計を欠くと、障害のたびに手作業での復旧が必要になります。

変換の要件では、文字コードと桁数、日付の表記を明示します。全角と半角の混在や外字を含む商品名は、取り込み時のエラーの原因になりがちです。桁あふれは切り捨てられて気づかれないこともあり、検収の照合で差異として現れます。変換の規則は仕様書に表として残し、双方で同じ版を参照する形にします。

稼働前の疎通確認では、正常系だけでなく異常系の確認項目を用意します。想定より大きい件数、重複した送信、途中で切れたファイルの3通りは、実運用で起こり得る事象です。確認の記録は取引先と共有し、合意した内容を残します。この記録は、稼働後に差異が出たときの切り分け材料になるでしょう。確認の担当と連絡順も、記録に添えておきます。

法令・制度対応に関する要件

法令・制度の要件は、取引条件の明示、電子取引データの保存、デジタルインボイスへの対応の3点を軸に整えます。2026年に施行された中小受託取引適正化法では、委託する側が受託する側へ取引条件を明示することが求められます¹。保存については、電子帳簿保存法の要件に沿った運用を設計します3。いずれも後から足すと改修が広がるため、要件定義の段階で織り込みます。

取引条件の明示は、品目・数量・代金・支払期日などの条件を発注時に示す考え方です。書面に代えて電磁的記録で示す方法も認められています。Web-EDIでは、発注画面や発注データ自体が明示の手段になり得ます。どの項目をどの画面で示すかを、要件として文書に残します。電磁的記録で提供する場合の留意事項は公表されており、提供の方法や受け手側の確認の扱いが示されています^*2。

電子取引データの保存では、真実性と可視性の2つの観点を満たします。真実性の確保は、タイムスタンプの付与、訂正削除の履歴が残る仕組み、事務処理規程の整備といった4つの措置のいずれかで対応します^*3。可視性では、取引年月日・取引金額・取引先の3項目による検索要件の確保が求められます。保存期間は原則7年ですから、対象データの範囲を先に洗い出しておきます。

検索要件の確保には、緩和の規定も用意されています。判定期間の売上高が5,000万円以下の事業者は、データのダウンロードの求めに応じられる場合、検索機能の確保が不要とされています^*3。相当の理由がある場合の猶予措置も示されていますので、自社がどの取り扱いに当たるかを確認します。提供元の保存機能に任せる場合は、契約終了後のデータの引き取り方法も要件に含めます。

デジタルインボイスへの対応は、請求の工程で検討します。国内の標準仕様は国際的な仕様を基にしており、送り手と受け手が各自のアクセスポイントを介して交換する4コーナーモデルが前提です^*4。受発注のデータと請求のデータで項目の粒度が違うと、突き合わせに手作業が残ります。将来の対応を見込むなら、請求項目の持ち方を今の要件に反映させておきたいところです。

制度要件の抜けは、稼働後に見つかると影響が広がります。保存の要件を満たさないデータが蓄積していれば、遡っての整理は容易ではありません。明示の項目が足りなければ、発注画面の改修と取引先への再周知が同時に必要になります。法令の改定は年単位で起こりますから、要件表に確認の担当と参照先を書き添えておくと保守が続きます。

セキュリティと運用に関する要件

セキュリティと運用の要件は、認証と権限、可用性と代替手段、問い合わせと教育の3組で整えます。取引先が日々使う仕組みですから、自社の内部の統制だけでは足りません。中小企業向けの対策ガイドラインは第4.0版が公表されており、対策の優先度を段階的に整理する構成です^*5。要件では、守る対象と、止まったときの代替手段を対にして書き出します。

認証の要件は、識別子の払い出しから停止までの一連の管理として設計します。取引先の担当者が替わっても同じ識別子が使い回されると、操作の記録が誰のものか分からなくなります。多要素認証の可否、パスワードの再設定の手順、休眠識別子の棚卸の周期を決めます。権限は閲覧・登録・承認の3段階に分け、必要な範囲だけを与える形にします。

操作の記録は、後から追える形で残すことが前提になります。誰がいつどの発注を登録し、誰が承認したかが残っていれば、差異の原因を切り分けられます。記録の保存期間は、電子取引データの保存期間と合わせて決めると管理が単純になります^*3。記録を見る担当と頻度も、あわせて要件に含めます。

可用性の要件は、止まってよい時間と失ってよいデータ量の2つで表します。受注の受け口が半日止まると、当日の出荷指示が組めない事業者も出てきます。代替手段としては電話とメールでの暫定受付を定め、復旧後の取り込み手順まで書いておきます。回線サービスの終了が公表されている手段に依存している場合は、期限からの逆算が必要です。ディジタル通信モードの終了は2028年12月と案内されていますので、移行判断の時期を先に置きます^*8。

問い合わせ対応では、窓口の一元化と一次回答の範囲を決めます。取引先からの連絡が担当者個人へ入ると、不在時に受注が滞ります。よくある質問と手順書を用意し、一次回答できる範囲を明文化しておきます。社内教育は定期の説明会と、担当者が替わるときの引き継ぎ資料の2本立てにします。

これらの要件を自社だけで固めるには、3領域の知見が要ります。業務の例外処理、通信と基幹連携の設計、保存と明示の制度理解です。1人が3領域を兼ねると、決めきれない項目が残り、稼働後の手戻りにつながります。外部の支援を使う判断は、難易度の問題ではなく、抜けを減らして手戻りの費用を抑えるためのものです。

委託する場合でも、自社に残す判断は明確にしておきます。項目定義と締め時刻、取引先への説明の方針は、自社の商習慣に踏み込む部分です。設計と実装を任せる範囲と、決定を自社に残す範囲を契約前に分けておけば、認識の齟齬が起きにくくなります。分担の線引きは、要件表の各行に担当を書き入れる形で表せます。

要件を整理したあとの進め方

要件を整理したら、要件定義書への落とし込み、取引先への展開、稼働後の見直しの3段階へ進みます。要件定義書では機能要件と非機能要件を分け、各行に優先度と担当を付けます。展開では取引先ごとの接続方式に沿った案内を用意し、並行稼働の期間を設けます。稼働後は、要件表を台帳として更新し続ける形にします。台帳が生きていれば、次の刷新の初期調査が短く済みます。

要件定義書は、要件表と業務フロー図と項目定義の3点で構成すると使いやすくなります。要件表には、業務・データ・法令・運用の4分類と優先度、担当、参照した公表資料を並べます。優先度は必須と望ましいの2段階に絞ると、判断が早く進みます。参照先を書き残せば、制度が改まったときに確認すべき行がすぐ分かります。

非機能要件では、性能・可用性・保守の3点を数値で置きます。1日の最大明細件数、締め直前の同時利用者数、復旧までに許容する時間が代表的な項目です。数値の根拠は自社の実測値に置き、繁忙期の値を採ります。根拠のない数値を置くと、稼働前の受入確認で合否の判断ができません。測り方も併せて書いておくと、後の検証がぶれません。

取引先への展開は、影響の大きい相手から順に進めます。案内資料には、切替の時期、必要な準備、問い合わせ窓口の3点を最低限として載せます。画面入力の相手には操作手順、ファイル連携の相手には項目定義と疎通確認の段取りを添えます。並行稼働の期間は、双方の記録を突き合わせて差異が出ないことを確かめる時間として使います。

合意形成では、相手に何を求めるのかを1枚で示します。項目の追加を求めるのか、送信の時刻を変えてもらうのか、費用の負担がどちら側かを明記します。曖昧な依頼は保留にされ、切替の時期が後ろへずれます。相手側にも決定権を持つ人がいますから、担当者どまりにしない伝え方を考えます。

稼働後の見直しは、定期の点検と改定の検知の2系統で回します。定期の点検では、手作業に戻った工程と、差異の発生した明細を数えます。改定の検知では、参照している公表資料の更新を確かめ、要件表の該当行を見直します。要件表が更新されていれば、次の刷新のときに現行の姿を調べ直す作業が要りません。

整理した要件は、事業の変化に合わせて動きます。取引先の追加、商品体系の見直し、制度の改定のたびに、要件表のどの行へ影響するかを見ます。行単位で影響を追えるようにしておけば、都度の判断が小さく済みます。要件定義を一度きりの作業にしない仕組みが、次の刷新の負担を軽くします。

よくある質問

Web-EDIの要件定義にはどのくらいの期間を見込めばよいですか

期間は取引先の数と接続方式の組み合わせで変わるため、一律の目安は示せません。判断の材料になるのは、対象工程の数、取引先ごとの手段の種類、基幹システムの改修の有無の3点です。まず現行フローの洗い出しに着手し、明細件数が集中している取引先の要件から固めると、日程の見通しが立てやすくなります。並行稼働の期間も日程に含めて考えます。

取引先から別のWeb-EDI画面の利用を指定された場合はどう扱えばよいですか

自社の要件表に、その画面から取り込む項目と取り込みの方法を1行として追加します。画面入力しか選べない場合は、転記の担当と回数を記録し、明細件数が増えた時点で連携方式の見直しを申し入れる材料にします。取引条件の明示に当たる項目がその画面に含まれるかも確認しておきます。要件を自社側で持っておけば、相手ごとの差分を管理できます。

電子取引データの保存は仕組みの提供元に任せてよいですか

保存の義務は自社に残りますので、提供元の機能で要件を満たせるかを自社で確認します。真実性の確保は4つの措置のいずれか、可視性は取引年月日・取引金額・取引先の3項目による検索要件の確保が求められます。契約が終わった後にデータをどの形式で引き取れるかも、あらかじめ取り決めておきます。保存期間は原則7年です。

既存の回線を使ったEDIから移行する判断はいつまでに必要ですか

ディジタル通信モードを用いる回線サービスは2028年12月に終了する見込みが案内されています。移行には要件整理、接続方式の合意、疎通確認、並行稼働の4工程が必要ですから、終了時期から逆算して着手の時期を決めます。取引先側の対応可否の確認も同時に進めます。回線に依存した機器が残っているかは、資産の一覧で確かめられます。

要件定義書に非機能要件はどこまで書けばよいですか

性能・可用性・保守の3点は、数値を伴う形で書いておきます。1日の最大明細件数、締め直前の同時利用者数、復旧までに許容する時間が代表的な項目です。数値は自社の実測値、とくに繁忙期の値を根拠にします。根拠のない数値を置くと、稼働前の受入確認で合否の判断ができなくなります。

1. *1　出典：公正取引委員会「法令・ガイドライン等（取適法）」（2026）　経路
2. *2　出典：公正取引委員会「下請取引における電磁的記録の提供に関する留意事項」（2023）　経路
3. *3　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」（2025）　経路
4. *4　出典：デジタル庁「デジタルインボイス（JP PINT／Peppol）」（2026）　経路
5. *5　出典：独立行政法人情報処理推進機構（IPA）「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（2026）　経路
6. *6　出典：流通BMS協議会（一般財団法人流通システム開発センター）「流通BMS標準仕様」（2018）　経路
7. *7　出典：一般財団法人日本情報経済社会推進協会（JIPDEC）「企業IT利活用動向調査2026 集計結果および分析レポート」（2026）　経路
8. *8　出典：東日本電信電話株式会社（NTT東日本）「ISDN（INSネット）とは？2028年12月終了の影響と企業が取るべき対応」（2026）　経路