まずは卸売ECを小規模でスタートしたい方へ。リーズナブルなSaaS(ASP)版『EC-Rider Primo(プリモ)』誕生! 詳しくはこちら

EDI老朽化の課題と対策:INSネット終了の期限と、延命・部分更新・移行の選び方

◆監修・編集責任者 小園 将隆 

B2B EC-COLUMN

この記事のポイント

  • INSネット経由のEDIは2028年12月31日に提供が終わり、補完策も同時に終わるため、その接続の延命は移行までのつなぎにしかなりません。
  • 期限の有無は会社単位ではなく接続単位で決まるので、取引先ごとに回線と通信手順を分けて確かめます。
  • 期限のない接続でも、仕様を説明できる人がいない、取引先から方式の変更を求められている場合は、更新を検討する状態です。
  • 延命・部分更新・移行は、通信手順・データ形式・社内の取込みのどこまでを替えるかで比べ、取引先ごとに組み合わせることもできます。
  • 更新は通知、対応づけ、試験、並行運用、切替の順に取引先ごとに進め、件数と項目の値が新旧で一致するかで切替を判断します。

60代前半の日本人男性がタブレットへの入力をしている場面

古いEDIが止まる条件は何か:通信回線の期限と、期限のない老朽化を分けて考える

仕様を知る担当者が減り、取引先からは接続方式の変更を求められている。
そんな状況で、老朽化したEDIは触るのも止めるのも怖くなります。
動かせない期限がはっきりしているのは、INSネット(ISDN)でデータ通信をしている接続です。
NTT東西は2028年に提供を終了します1。
インターネット経由の接続はこの期限と分けて考え、保守できる体制と取引先の要請から緊急度を判断します。
そのうえで延命・部分更新・移行を同じ観点で比べ、取引先調整から並行運用、切替までを順に進めます。

INSネット(ISDN)を使うEDIは2028年12月31日が期限

EDIの老朽化を考えるとき、最初に切り分けたいのは「外から決められた期限があるか」です。
期限がはっきり示されているのは、INSネットの回線でデータを送受信している接続です。
NTT東日本・NTT西日本は、INSネット64、INSネット64・ライト、INSネット1500のサービス提供を2028年に終了すると案内しています1。
新規販売はすでに2024年に終わっています1。
そのため、回線を新しく契約し直してしのぐ方法は前提にできません。

見落としやすいのは、いま問題なく送受信できていても、それが安心材料にはならない点です。
固定電話網は2024年1月にIP網への切替が始まり、その後もINSネット上でデータ通信を続けられるように補完策が提供されてきました1。
公式案内では、この補完策もINSネットのディジタル通信モードの終了に合わせて終わるとされています1。
2024年以降も動き続けているINSネット経由のEDIは、終わりの決まった仕組みの上で動いていることになります。

2022年の報道では、補完策は「2027年ごろまでをめど」と伝えられていました3。
現在の公式案内では2028年12月31日が終了日なので、当時の見通しより後ろにずれたことになります。
ただし、期限が延びたからといって、取引先も切替を先延ばしにするとは限りません。
相手が先に新しい方式へ移れば、自社にとっての期限は回線の終了日より前に来ます。

インターネット経由の接続はこの期限の対象か

すでにインターネット経由で送受信している接続について、この案内から同じ期限を読み取ることはできません。
公式案内はINSネットという回線サービスの終了を知らせるもので、EDI向けの個別の説明や、データ通信の移行方法は書かれていません1。
インターネット経由の接続やVAN経由の接続にも2028年という期限がある、とは言えないということです。

VAN(取引データの中継を請け負う事業者のネットワーク)を経由している場合は、もう一段の切り分けが必要です。
自社からVANまでの接続と、VANから取引先までの接続は別の経路です。
自社側がインターネットでVANにつないでいても、VANとの間の接続がどの回線なのか、VANの先の取引先がどう接続しているのかは、契約しているVAN事業者や取引先に聞かないと分かりません。
自社の回線だけを見て「期限とは無関係」と判断するのは早計です。

迷いやすいのは、取引先ごとに方式が違うケースです。
たとえば、大口の取引先とはインターネット経由、古くからの取引先とはINSネット経由、というように混在していると、社内では「うちのEDIはもう新しくなった」と受け止められがちです。
期限の有無は会社単位ではなく接続単位で決まります。
取引先ごとに、どの回線とどの通信手順を使っているかを分けて見る必要があります。
通信手順とは、送受信の開始・確認・終了などのやり取りの決まりで、取引先と合わせて使うものです。

期限がなくても残る老朽化の困りごと

回線の期限が当てはまらなくても、老朽化の問題がなくなるわけではありません。
期限のない老朽化は、ある日突然止まるというより、変更が必要になったときに対応できなくなる形で表に出ます。
取引先がデータの項目を増やしたい、通信手順を替えたいと言ってきたときに、どこを直せばよいか分からない。
受信したデータを社内の受注システムへ取り込む変換処理が、誰も中身を説明できないまま動いている。
こうした状態は、平常時には問題に見えません。

そのため、期限のない接続は「いつまでに」ではなく「何が起きたら困るか」で点検します。
障害が起きたときに原因を追える人がいるか、取引先の変更依頼に答えられるか、サーバーや保守契約の更新を続けられるか、といった観点です。
ここに不安があるなら、回線の期限がなくても手を打つ理由になります。

INSネットの切替開始から新規販売終了、サービス提供終了までの日付の流れ
2024年1月の固定電話網の切替開始、2024年8月31日の新規販売終了、2028年12月31日のサービス提供終了と補完策の終了を日付順に並べた図
▼ 図の内容を文字で読む
  • 2024年1月
    • 固定電話網のIP網への切替が始まり、INSネットでデータ通信を続けるための補完策が提供される
  • 2024年8月31日
    • INSネットの新規販売が終了し、回線を新しく契約し直す方法は前提にできない
  • 2028年12月31日
    • INSネットのサービス提供が終了し、補完策もディジタル通信モードの終了に合わせて終わる

自社のEDIは今すぐ手を打つ状態か:期限・保守体制・取引先要請の3点で見分ける

回線の種類と通信方式を確かめる

緊急度は、回線の期限、保守体制、取引先からの要請の3点で見分けると整理しやすくなります。
回線の期限は外から決まる要因で、自社の努力では動かせません。
保守体制と取引先要請は自社と取引先の事情で決まるので、準備や交渉で変えられる余地があります。
この二つを混ぜて議論すると「期限まで時間があるから急がなくてよい」という結論に流れやすいため、分けて扱います。
3点の見方は判断を整理するための提案で、件数や業界の基準値から導いたものではありません。

回線については、取引先ごとに、どの回線を使い、どの通信手順で、どの機器やソフトから送受信しているかを書き出します。
回線の契約名は請求書や契約書で確かめられます。
一方で、どの取引先の送受信がその回線を通っているかは、送受信ソフトの接続先の設定や送受信の記録を見ないと分からないことがあります。
接続先が電話番号で設定されているのか、インターネット上の宛先なのかが、手がかりの一つです。

INSネットを使う接続が一つでも残っていれば、その接続には2028年12月31日という外部の期限があります1。
ただし、その日まで作業できるわけではありません。
取引先との試験や並行運用の期間を差し引いて逆算すると、使える時間は見た目より短くなります。

仕様を知る担当者が残っているか

保守体制で見るのは、人数よりも「説明できるかどうか」です。
担当者が一人いても、変換処理の中身や取引先ごとの例外を把握していなければ、変更依頼が来たときに動けません。
逆に、詳しい人がいなくても、取引先ごとのデータ項目と社内システムの項目の対応が文書で残っていれば、外部の支援を受けながら進められます。

点検の手がかりは、最近あった変更や障害を思い出すことです。
取引先の項目追加に対応したとき、誰がどこを直したのか。
送信が失敗したとき、原因の切り分けにどれだけ手間取ったか。
答えが特定の個人の記憶にしかない場合、その人が異動や退職をした時点で、期限のない老朽化が実質的な期限に変わります。
この場合は、更新方式を選ぶ前に、現行の接続を取引先ごとに棚卸しすることが先になります。

社内で更新を提案するときも、この点が説明の軸になります。
「システムが古い」という理由だけでは、動いているものに手を入れる判断はなかなか通りません。
取引先の変更依頼に答えられない、障害時に原因を追えない、という具体的な状況と、それが起きたときに止まる受発注の範囲を示すほうが、延命か更新かの議論を進めやすくなります。

取引先から接続方式の変更を求められたら

取引先からの要請は、3点のなかで最も具体的な期限を持ち込みます。
相手が新しい通信手順やデータ形式への切替日を示していれば、その日が自社にとっての期限です。
回線の終了日より前の日付が示されることもありますし、インターネット経由の接続でも、相手の都合で方式の変更を求められることはあります。

要請を受けたら、相手が何を変えようとしているのかを分けて聞き取ります。
回線だけを替えるのか、通信手順も替えるのか、データ形式や版まで変わるのかで、自社の作業量は大きく違います。
回線と手順だけの変更なら社内の取込み処理を残せる可能性がありますが、データ形式が変わると、項目の対応づけからやり直しになります。
3点のうち二つ以上に当てはまる場合や、取引先の要請に期限が付いている場合は、延命を前提にせず、更新の検討を始める状態と考えるのが妥当です。

緊急度を見分ける3点の違い(判断を整理するための見方)
回線の期限は外から決まり動かせないこと、保守体制と取引先要請は自社と取引先の事情で準備や交渉により変えられる余地があることを分けた図
▼ 図の内容を文字で読む
  • 回線の期限
    • 外から決まる要因で、自社の努力では動かせない
    • INSネット経由の接続は2028年12月31日が期限
  • 保守体制
    • 自社の事情で決まり、準備で変えられる余地がある
    • 変換処理や取引先ごとの例外を説明できるかで見る
  • 取引先要請
    • 取引先の事情で決まり、交渉で変えられる余地がある
    • 切替日が示されていれば、その日が自社の期限になる

現状維持・部分更新・移行を、作業と利用条件で比べる

共通の比較軸(通信手順・データ形式・取引先対応・自社作業・条件)

延命、部分更新、移行を比べるとき、費用の大小から入ると判断がぶれます。
既存EDIの更新にかかる金額は、接続先の数や変換処理の作り方で大きく変わるためです。
ここでは金額ではなく、何を変える必要があるかで比べます。
観点は、通信手順を変えるか、データ形式の変換が必要か、取引先側の対応が要るか、自社に何の作業が発生するか、どんな条件なら成り立つか、の5つです。

EDIは、大まかに三つの部分に分けると比べやすくなります。
取引先とつながる回線と通信手順、やり取りするデータの形式、受け取ったデータを社内の受注・出荷などのシステムへ渡す変換と取込みです。
3つの選択肢の違いは、この三つのうちどこまでを替えるかの違いだと言えます。
下の表はその観点で整理したもので、個々の欄がすべての企業に当てはまるわけではありません。

現状維持・延命が成り立つ条件

延命は、何も替えないので取引先を巻き込まずに済むのが最大の利点です。
ただし成り立つには、回線に期限がないこと、取引先が現行の方式を当面続けること、障害や変更に対応できる人か保守会社がいることの三つがそろっている必要があります。
INSネット経由の接続を延命しても、2028年の期限を越えて使い続けることはできません1。
その接続に限っては、延命は移行までの時間を稼ぐ手段であって、行き先にはなりません。

延命を選ぶ場合でも、やっておく価値があるのは仕様の文書化です。
取引先ごとのデータ項目、変換の規則、例外的な処理を書き残しておけば、次に更新を判断するときの材料になり、担当者が替わっても障害の切り分けができます。
延命期間の作業を機器の入れ替えだけで終えると、数年後に同じ判断を、より少ない情報で迫られることになります。

部分更新と移行の違い

部分更新は、三つの部分のうち一部だけを替える方法です。
典型的なのは、回線と通信手順だけをインターネット経由のものに替え、データ形式と社内の取込み処理はそのまま残す形です。
社内の受注システムに手を入れずに済む分、作業は通信まわりと取引先との試験に絞られます。
ただし、取引先がその新しい手順に対応していることが前提で、相手が対応していなければ成り立ちません。

移行は、通信、データ形式、社内連携までを新しい仕組みや共通の標準に寄せる方法です。
中小企業共通EDIは、取引先ごとにばらばらだったデータ形式を国際標準に準拠して共通化し、導入の手間とコストを減らすことをめざした標準です2。
中小企業庁の解説では、受注側は同標準に対応したプロバイダーと業務アプリケーションを使えば大きな費用はかからないとされています2。
これは標準に対応したサービスを使う受注側についての説明で、金額の記載はなく、既存のEDIを作り替える費用を示したものではありません。

部分更新と移行のどちらを選ぶかは、残したい部分をきちんと説明できるかで分かれます。
変換処理の中身が分からないまま通信だけを替えると、古い部分の不安はそのまま残ります。
反対に、変換処理が整理されていて、取引先も現行のデータ形式を続けるなら、全面的な移行より部分更新のほうが取引先の負担を抑えられます。

30代後半の日本人男性がホワイトボードでの説明をしている場面

選択肢は、会社全体で一つに決める必要もありません。
INSネット経由の取引先は通信だけを替える部分更新、新しい方式を求めてきた取引先とは移行、変更の予定がなく保守も回っている取引先は当面の延命、というように接続ごとに組み合わせられます。
ただし組み合わせるほど社内で保守する方式は増えるので、いつまでにどこまで寄せるのかを決めておかないと、更新したはずのEDIが別の形で複雑になります。

観点 現状維持・延命 部分更新 移行
通信手順の変更 変えない 回線と手順だけを替えることが多い 新しい方式へ替える
データ形式の変換 変えない 必要な範囲で変換処理を作り直す 新しい形式と社内項目の対応づけをやり直す
取引先側の対応 原則として不要 通信を替える取引先とは合意と試験が要る すべての取引先と合意と試験が要る
自社の作業 機器や保守契約の更新と仕様の文書化 替える部分の改修と取引先ごとの試験 対応づけから試験・並行運用・切替までの一式
成り立つ条件 期限のある回線に依存せず取引先が現行方式を続け保守できる人がいる 残す部分を説明でき取引先が新しい手順に対応している 取引先の対応状況が分かり並行運用の期間を取れる

取引先や既存データ形式の事情で選択肢はどう変わるか:発注側・受注側・多取引先

受注側:発注元ごとの個別対応と多画面問題

自社が注文を受ける側なら、選択肢の幅は発注元の方式に強く縛られます。
中小企業庁の解説では、Tier1・Tier2の企業は発注側企業それぞれに対応したシステムを導入しなければならず、複数の画面を使い分ける「多画面問題」がコスト面の負担になると紹介されています2。
Tier1・Tier2は、完成品メーカーに直接または間接に部品などを納める取引の階層を指します。

たとえば、3社の発注元からそれぞれ別の方式で注文を受けている受注担当者を考えます。
A社の注文は専用画面で確認して受注システムへ打ち込み、B社の注文はファイルで受け取って取り込み、C社の注文はさらに別の画面で見る、という状態です。
このうち1社から接続方式の変更を求められると、その1社分の作業で済むように見えます。
しかし、画面や取込みの手順が社内で別々に積み上がっていく構造は変わりません。
個別の要請に一つずつ応えるたびに、次の老朽化の種が増えていきます。

そのため受注側は、発注元の指定にその都度合わせるだけでなく、複数の発注元とのやり取りを共通の標準に対応したサービスでまとめられないかを検討する価値があります。
何社を超えたらまとめるべき、という一律の線はありません。
受注担当がいくつの画面や取込み手順を使い分けているか、そのうちいくつが近く変更を求められそうかを数えることが、判断の出発点になります。

発注側:取引先全体を移行させる調整

自社が注文を出す側なら、方式を決める立場にある分、取引先全体を新しい方式へ移す調整を負うことになります。
新しい方式を決めても、取引先がすぐに対応できるとは限りません。
対応の早い取引先と遅い取引先が混在すると、新旧の方式を一定期間並べて運用することになり、その間は自社側で両方を保守し続けます。

発注側が先に確かめたいのは、取引先がいまどの通信手順とデータ形式で接続しているか、新しい方式に対応できる体制があるかです。
特に、INSネット経由で接続している取引先が残っている場合、その取引先にとっても2028年12月31日が期限になります1。
自社がインターネット経由の方式を用意していても、相手側の準備が間に合わなければ受発注が止まりかねません。
取引先ごとの対応状況を早めに把握することが、調整の土台になります。

取引先が多い場合は、移す順番も決めておきます。
INSネット経由の取引先のように期限のある接続を先にするのか、取引量の多い取引先から試すのか、対応の早い取引先で手順を固めてから残りに広げるのかで、計画の形が変わります。
どの順番が正しいという決まりはありませんが、期限のある接続を最後に回すと、遅れたときに逃げ場がなくなります。

共通標準に対応するサービスを使う場合の注意

共通の標準に寄せる移行は、取引先ごとの違いを減らす方向の選択です。
ただ、標準は自社だけが対応しても効果が出ません。
受注側なら発注元が、発注側なら取引先が、同じ標準でやり取りできるかどうかで、まとめられる範囲が決まります。

既存の取引のなかには、業界ごとの標準や、取引先が独自に決めた仕様で動いているものもあります。
それらをすべて一つの標準へ寄せられるとは限らず、標準でまとめられる取引と、個別の方式を残す取引に分かれることがあります。
移行の計画では、どの取引先を標準でまとめ、どの取引先に個別の接続を残すのかを一覧にしておくと、移行後に残る保守の範囲を社内に説明しやすくなります。

受注側の発注元とのつながり方の違い(模式図)
発注元ごとの個別方式では画面や取込み手順が発注元の数だけ増え、共通標準に対応したサービスでまとめられるのは同じ標準に対応した発注元に限られ、非対応の発注元とは個別方式が残ることを示した模式図
▼ 図の内容を文字で読む
  • 発注元ごとの個別方式
    • 発注元Aは専用画面、Bはファイル取込み、Cは別の画面で受ける
    • 画面や取込み手順が発注元の数だけ増える(多画面問題)
  • 共通標準に対応したサービス
    • 同じ標準でやり取りできる発注元の注文をまとめて受けられる
  • 標準に対応していない発注元
    • まとめられず、個別の方式が残る

更新を決めたら:取引先調整・データ変換・並行運用・切替の進め方

取引先への通知と方式の確認

更新を決めたあと、時間がかかりやすいのは取引先との調整です。
EDIの試験は自社だけでは完結せず、取引先に実際のデータを送ってもらったり、こちらから送ったデータを受け取ってもらったりする必要があるためです。
そこで、次の順を基本にし、取引先ごとに並行して進める方法を提案します。

  1. 取引先への通知と、対応できる通信手順・データ形式の確認
  2. データ項目の対応づけ
  3. 取引先との試験
  4. 新旧の並行運用
  5. 切替

最初の通知では、切替の希望時期だけでなく、相手がどの通信手順とデータ形式に対応できるのか、試験にいつ協力できるのかを聞き取ります。
通信手順やデータ形式の版は取引先と合意して使うものなので、ここが決まらないと後の対応づけも試験も始められません。
回答の早い取引先から試験に進み、遅い取引先は個別に追いかける形にすると、全体が1社の遅れに引きずられにくくなります。

社内への通知も同じ時期に始めます。
注文を受け取って入力する現場の担当者にとっては、どの取引先がいつ切り替わり、並行運用中はどちらの画面やデータを正とするのかが分かっていないと、二重に入力したり、片方を見落としたりするおそれがあります。
取引先ごとの切替予定を一つの表にまとめ、社内と取引先の双方で同じ表を見られるようにしておくと、問い合わせの行き違いを減らせます。

データ項目の対応づけ

データ項目の対応づけは、取引先から届くデータのどの項目を、社内の受注システムのどの項目に入れるかを決める作業です。
取引先コード、品目、数量、納期のような項目は分かりやすい一方で、単位の違い、品目コードの変換、取引先ごとに意味が少しずつ違う備考欄などで手間がかかります。

作業範囲を見積もる材料として、中小企業共通EDIの注文メッセージがあります。
標準仕様では注文メッセージに全135項目を定め、業務アプリケーションに最低限対応を求めるのは13項目としています2。
この数字は中小企業共通EDIの注文メッセージに限ったもので、他の業界標準や個別仕様の項目数ではありません。
それでも、全項目を一度に対応づけるのではなく、取引に欠かせない項目から始め、自社が実際に使っている項目を足していく、という考え方の目安にはなります。

対応づけの結果は、取引先ごとに表で残します。
どの項目を変換し、どの項目は使わずに捨てているのかが書かれていれば、並行運用で差異が出たときに原因を追えます。
延命の節で触れた仕様の文書化は、ここでそのまま役に立ちます。

並行運用と切替の判断

並行運用では、同じ注文を新旧両方の仕組みで受け取り、結果を突き合わせます。
確かめるのは、受信した件数が一致しているか、エラーになった件数と内容が一致しているか、社内システムに取り込まれた主要な項目の値が同じか、といった点です。
件数が合っていても、数量の単位や納期の変換が一部の注文だけずれていることがあるので、項目の値まで見ます。

差異が出たら、原因を対応づけの表か変換の設定のどちらかで直し、次の受信分で改めて照合します。
この照合と修正を繰り返し、差異が出なくなった状態を切替の判断材料にします。
締め日や繁忙期のように普段と違う注文が流れる時期を一度は含めて比べておくと、通常の注文では現れない変換の漏れに気づけます。
何回一致すれば十分という決まった基準はないため、取引先と合意した判断条件を事前に書面にしておくと、社内への説明もしやすくなります。

切替後もしばらくは、旧の仕組みを止めずに戻せる状態にしておくと、想定外の不具合が出たときに受発注を止めずに済みます。
INSネット経由の接続を切り替える場合、旧の仕組みを残しておける期間も2028年12月31日までに限られます1。
並行運用と戻せる期間を確保できるよう、取引先との試験の日程から逆算して着手時期を決めます。

並行運用で差異が出なくなるまで照合と修正を繰り返す流れ
新旧両方で受信して取り込み、件数と項目の値を照合し、差異の原因を対応づけの表か変換の設定で直し、次の受信分で再び照合する繰り返しを示した図
▼ 図の内容を文字で読む
  1. 同じ注文を新旧両方で受信して取り込む
  2. 受信件数・エラー件数・主要項目の値を照合する
  3. 差異の原因を対応づけの表か変換の設定で特定して直す
  4. 次の受信分で改めて照合する(最初の段へ戻る)

取引先ごとに回線や変換処理が混在していると、延命・部分更新・移行のどれを軸にするかを社内だけで決めにくいためです。

現行の接続を取引先ごとに整理し、期限のある接続と、保守体制や取引先要請から先に手を打つべき接続を確かめられます。無料相談で要件を整理する

現行EDIを取引先ごとに棚卸しする項目

取引先1社分の接続を、相手の確認から回線、データ、社内の取込み、担当者まで、データが流れる順にたどった項目です。

  • 取引先名と、自社が発注側か受注側か
  • 使っている回線(INSネットか、インターネット経由か、VAN経由か)
  • 通信手順と、送受信に使う機器・ソフト
  • データ形式と版(業界の標準か、取引先独自の仕様か)
  • 送受信の頻度と時刻
  • 変換処理の場所と、取り込む先の社内システム
  • 仕様を説明できる社内の担当者と、取引先の窓口

回線の欄にINSネットが残る取引先は期限から逆算し、担当者の欄が埋まらない取引先は方式の比較より先に仕様の整理から始めます。

要点の整理

軸 基準
回線の期限 INSネット経由の接続は2028年に提供が終わる。補完策も同時に終わる
インターネット経由の接続 INSネットの期限とは分けて、保守体制と取引先要請で判断する
延命 回線に期限がなく、取引先が現行方式を続け、保守できる人がいる場合に限る
部分更新 残す部分を説明でき、取引先が新しい手順に対応している場合
移行 取引先の対応状況が分かり、並行運用の期間を取れる場合
切替の判断 受信件数・エラー件数・主要項目の値が新旧で一致するか
20代前半の日本人女性が手順の指導をしている場面

取引先との試験や並行運用の日程は、回線の期限と取引先の都合の両方から逆算する必要があり、計画の見落としが受発注の停止につながるためです。 取引先ごとの切替の順番と、データ項目の対応づけや並行運用で何を照合するかを整理できます。

BtoB通販システムのご相談

貴社の商習慣に合わせたご提案をいたします。

無料相談はこちら

よくある質問

INSネットを使っていない場合、EDIの老朽化に期限はないのですか。

INSネットの提供終了という外部の期限は、INSネットを使わない接続には直接当てはまりません。
インターネット経由やVAN経由の接続に同じ期限があるとは言えません。
ただし、取引先からの切替要請、仕様を知る担当者の異動や退職、機器や保守契約の更新が、実質的な期限になることがあります。
また、VAN経由の場合はVANの先の接続がどの回線かも確かめる必要があります。

自社が受注側の場合、取引先が指定した方式にそのまま合わせるしかないのですか。

通信手順やデータ形式の版は取引先と合意して使うものなので、指定を無視することはできません。
一方で、合わせ方には選択の余地があります。
発注元ごとに個別のシステムを増やす代わりに、共通の標準に対応したサービスで複数の発注元をまとめられないかを検討できます。
ただし、まとめられるのは同じ標準でやり取りできる発注元に限られ、対応していない発注元とは個別の方式が残ります。

取引先と同時に切り替えられない場合、並行運用はどう組めばよいですか。

取引先ごとに切替時期をずらし、試験が済んだ取引先から新しい方式へ移します。
それまでの取引先は旧の方式のまま運用します。
社内では、取引先ごとにどちらの仕組みのデータを正とするかを決め、現場の入力担当者が同じ一覧を見られるようにしておくと、二重入力や見落としを防ぎやすくなります。
INSネット経由の取引先は、旧の方式を残せるのが2028年12月31日までであることを前提に日程を組みます。

仕様書がなく、担当者もいないEDIは、移行前に何を確認すべきですか。

まず、取引先ごとに回線、通信手順、データ形式と版、変換処理の場所を書き出します。
仕様書がなくても、実際に受信したデータと、社内システムに取り込まれた結果を見比べると、どの項目がどこへ入っているかを逆にたどれます。
例外的な処理は通常の注文では見えにくいため、締め日など普段と違う注文の記録も合わせて確認します。

データ項目の対応づけは、何項目くらいから始めるのが現実的ですか。

中小企業共通EDIの注文メッセージでは、全135項目のうち業務アプリケーションに最低限対応を求めるのは13項目とされています2。
これは同標準の注文メッセージに限った数で、他の標準や個別仕様にはそのまま当てはまりません。
考え方としては、取引に欠かせない項目から対応づけを始め、自社が実際に使っている項目を順に足していく進め方が現実的です。

◆監修・編集責任者

小園 将隆

株式会社フライトソリューションズ ECサービス部 マネージャー

BtoB通販のパッケージシステム「EC-Rider B2B Ⅱ」の導入支援をはじめ、製造業、卸売業をはじめとした法人向け通販サイト構築を多数手掛ける。卸売領域の専門知識をもとに、日本の商習慣に固有の課題をパッケージシステムの機能追加によって解決。BtoB流通の販路拡大を支援する。

> プロフィールの詳細を見る

  1. 1 出典:NTT東日本・NTT西日本「INSネット(2028年12月31日サービス終了)の案内」(2026年)
  2. 2 出典:中小企業庁(ミラサポplus)「企業間のデータ連携で、受発注の業務コストを削減する!」(2020年)
  3. 3 出典:Impress Watch「NTT東西の固定電話IP網移行スケジュールに関する報道」(2022年)

◆この記事について

独自調査以外の一次情報は、省庁・公的機関を中心とした信頼性の高い情報源から引用し、出典を明記しています。
年次更新される統計については、引用元の最新版を確認したうえで掲載しています。

※この記事は上記の監修・編集責任者がAIの協力を得て制作しています。

監修確認日:

記事内容に関するお問い合わせ:お問い合わせフォーム

BtoB EC(受発注)サイト構築システム「EC-Rider B2B Ⅱ」への
各種お問い合わせ

ページTOPへ戻る
無料相談を予約 お見積
平日10:00~18:00
page
top