EDI障害の原因切り分けと復旧対応、再発防止のための運用体制の見直し方

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

B2B EC-COLUMN

EDI障害が起きたら最初に確認すること（自社・回線・取引先の切り分け）

夜間に届くはずの発注データが朝になっても入っていない。
あるいは受注の取り込みが途中で止まったままになっている。
取引先には送信済みの記録が残っていて、原因が分からないうちに出荷の締め時刻だけが近づいてくる。
EDIの障害対応は、たいていこの落ち着かない状態から始まります。
この場面でまず変えられるのは、調べる順番です。
症状を「誰の、どのデータが、いつから」まで絞り込んだうえで、原因のありかを自社システム・通信回線・取引先システムの三方向に分けて確認していくと、手当たり次第に触るより早く範囲が狭まります。
回線側には、EDIで長く使われてきたISDNの終了という分かりやすい期限もあります。
切り分けと並行して取引先への連絡と代替手段の判断を進め、復旧後に監視や手順書の見直しへつなげます。

「データが届かない」「処理が止まる」ときにまず見る場所

「EDIが止まった」という一報には、実際には性質の違う複数の状態が混ざっています。
送信そのものが行われていないのか、送信は終わったのに相手に届いていないのか、受信はできているのに自社側の取り込み（変換）で落ちているのか。
EDIの処理は、データを作る、送る、受け取る、基幹システムへ取り込む、という段に分かれていて、止まった段が違えば見る場所も、連絡する相手も変わります。
最初の数分でやる価値があるのは、原因の推測ではなく、この段の特定です。

具体的には、伝送ソフトやEDIサービスの送受信履歴を開いて、該当する時間帯の処理が「実行されたうえで失敗した」のか「そもそも実行されていない」のかを見ます。
実行されていないなら、スケジューラやサーバーの停止、ディスクの空き、認証情報の期限切れなど、通信の手前にある問題の可能性が高くなります。
実行されて途中で切れているなら、回線か相手側の受け口が候補に上がります。
ログに正常終了が残っているのに相手に届いていない場合は、届いた後の相手側の取り込みで止まっている、という見立てになります。

並行して、症状を言葉にしておくと後の連絡が速くなります。
対象の取引先名、止まっているデータの種類（発注、出荷予定、受領、請求など）、最後に正常に処理できた時刻、片方向だけか送受信の両方か、件数がゼロなのか一部欠けているのか。
この五点は、社内の上長にも取引先にも結局は同じ内容で伝えることになるので、最初に書き出しておくと二度手間が減ります。

自社・回線・取引先の3方向で切り分ける考え方

段が特定できたら、原因のありかを三方向に分けます。
自社システム（サーバー、EDIソフト、変換定義、基幹システム側の取り込み）、通信回線（回線そのもの、通信装置、契約しているサービス）、取引先システム（相手のEDI環境や、間に入るサービス事業者）です。
この三つは、確認できる人も、復旧までにかかる時間も違います。
自社内なら自分たちで手を動かせますが、回線と取引先は問い合わせて返事を待つ時間が入るため、早めに当たりを付けて連絡を出しておく価値があります。

切り分けの近道は、影響している範囲の広さを見ることです。
複数の取引先との通信が同時に止まっているなら、個々の相手先の事情ではなく、自社側か回線側の共通部分が疑わしくなります。
逆に一社だけで、他社とは問題なく送受信できているなら、その取引先との設定か、相手側の環境に絞れます。
毎日決まった時刻の処理だけが失敗するなら、定時処理の重なりや、その時間帯だけ量が増えるデータなど、時間帯に依存する要因を考えます。

もう一つ、見落とされやすいのが直近の変更です。
自社側でサーバーの入れ替えやソフトウェアの更新、証明書の更新、社内ネットワークの設定変更がなかったか。
取引先側で商品コードの体系やデータ項目の追加が案内されていなかったか。
昨日まで動いていたものが今日動かないのなら、その間に何かが変わっているのが普通で、変更の心当たりをたどるほうが、ログを最初から読み直すより早いことがあります。

三方向のうち、早い段階で押さえておくと効く場所として回線があります。
EDIの回線には、障害とは別にあらかじめ決まっている期限があるためです。

回線・通信インフラが原因の場合の見分け方 — ISDN回線終了が典型例

ISDN「ディジタル通信モード」は2024年1月に終了済み

EDIの通信は、長くISDN回線の上で行われてきました。
その中でデータ通信に使われていたINSネットの「ディジタル通信モード」は、2024年1月に山形県・鳥取県から段階的に終了が始まり、同じ月のうちに全都道府県で提供が終了しています¹。
つまり、EDIのデータを流すための旧来のモードは、すでに全国で終わっています。

ここで注意したいのは、終了したのが回線そのものではなく、回線上のデータ通信のモードだという点です。
電話としてのINSネットは残っていたため、「ISDNはまだ使えている」という社内の感覚と、EDIのデータ通信が使えないという事実が同居しやすい。
自社や取引先がこのモードを前提にした構成のままだったなら、ある時点を境に送受信ができなくなったか、切替後の仕組みの上で動いているか、そのどちらかです。

ですから、障害の切り分けで回線を見るときは、装置のランプや通信速度だけでなく、いま何のサービスの上で通信しているのかを確認します。
契約書や請求書に書かれたサービス名、社内に置かれた通信装置、伝送ソフトに設定されている接続先。
これは障害時だけの確認ではなく、次に来る期限を把握するための下調べでもあります。

代替の補完策にも期限がある

ディジタル通信モードの終了に際しては、移行が間に合わない利用者に向けて、切替後のデータ通信サービス（補完策）が用意されました。
ただしこれは恒久的な仕組みではなく、2027年ごろまでをめどに一定期間提供される予定とされています¹。
補完策の上でEDIを続けている場合、いま動いていること自体は正常でも、期限付きの状態に置かれていることになります。

さらに紛らわしいのが、INSネットという回線契約そのものの期限です。
INSネット（INSネット64・INSネット64ライト・INSネット1500）は2024年8月に新規の申込受付が終了し、サービス提供自体の終了予定日は2028年12月とされています³。
この2028年という数字だけを見て「まだ数年ある」と受け取ると、EDIのデータ通信が2024年1月に終わっている事実と食い違います¹。
対象の違う二つの期限だと押さえておくと、社内で移行の必要性を説明するときにも話がねじれません。

実務では、この二つの期限に補完策の目安を重ねて、自社がどの位置にいるかを確かめることになります。
すでに別の回線・別の手順へ移行済みなら、今回の障害の原因は回線の世代ではなく、他にあります。
補完策の上にいるなら、今回の復旧とは別に、移行の計画を立てる時期に入っています。

回線の世代を確認する方法

自社の回線がどの世代かは、担当者が代わっていると社内の誰も即答できないことがあります。
手掛かりは三つあり、一つ目は通信サービスの契約情報です。
請求の内訳にINSネットの名前が残っていないか、その回線の契約と用途が社内のどの部署の管理になっているかを見ます。

二つ目は物理的な設備です。
EDI用のサーバーの近くに、電話回線につながる装置やモデム類が残っていれば、旧来の構成を引き継いだままの可能性があります。
三つ目は伝送ソフトの設定画面で、接続先として電話番号が設定されているのか、IPアドレスやURLが設定されているのかによって、回線を前提とした通信かIP網上の通信かがおおよそ分かります。

取引先側の世代も、同じように自社へ影響します。
自社がIP網へ移行済みでも、相手が古い構成のままなら、相手側の期限がそのまま自社の受注データに効いてきます。
移行の案内が来ていないか、相手のEDI窓口に確認しておくと、次に起きうる障害を一つ減らせます。

データ形式・伝送プロトコルの不整合が原因の場合、何を確認し誰と調整するか

取引先とのプロトコルの違いを確認する

回線に問題がないと分かったら、次に疑うのは通信の手順（プロトコル）とデータの中身です。
EDIの通信プロトコルは一種類ではなく、想定している企業規模、一度のやり取りで扱えるデータ量、主に使われる業界がそれぞれ違います²。
この違いは平常時にはほとんど意識されません。
取引先ごとに設定を作り込んだ後は「つながっているから問題ない」状態が続き、量や中身が変わったときに初めて差が表に出てきます。

そこで、自社が取引先ごとにどの手順を使っているかを一覧にします。
取引先が十社を超えていると、手順が混在していることは珍しくありません。
今回止まった相手がどの手順で、同じ手順の他の取引先でも同じ症状が出ているかを見ると、手順に依存する問題なのか、その相手固有の問題なのかが分かれます。

データ容量・形式の不一致を疑うポイント

手順が同じでも、流れるデータの中身が変われば結果は変わります。
まず疑う価値があるのは量です。
プロトコルには一度のやり取りで送受信できるデータ量に差があり、少ない量を前提にしたものもあります²。
普段は通っている発注データが、季節の山や新規店舗の一括発注で行数が跳ね上がった日だけ失敗するなら、量が境目になっている可能性を考えます。

次に形式です。
新しい商品コードで桁数が増えた、項目にこれまで入らなかった文字（半角カナや記号、外字）が入った、日付や数量の表現が変わった。
こうした変化は、送る側では正常に処理されて、受け取った側の変換で初めてエラーになります。
「相手は送ったと言っているのに自社に入っていない」という状況の一部は、ここで起きています。

判断を分けるのは、エラーになったのが全件か、一部かです。
全件なら接続や設定そのもの、特定の伝票や特定の商品だけなら中身の問題である公算が大きくなります。
止まったデータを一件取り出して、正常に通った日のデータと項目ごとに見比べると、原因の候補はかなり狭まります。
なお、再送の回数や待ち時間といった細かい挙動は製品や設定によって変わるため、一般論ではなく自社の設定値を確認したうえで話をするのが確実です。

調整すべき相手と進め方

プロトコルやデータ形式の問題は、自社だけで結論を出せません。
連絡先として適切なのは、取引先の購買や営業の窓口ではなく、相手のEDIを見ている情報システムの担当、あるいは間に入っているサービス事業者です。
購買担当を経由すると、症状が「データが来ない」という一文に圧縮されて伝わり、往復が増えます。
日常の窓口と、障害時に技術的な話ができる窓口は、別に押さえておくほうが現実的です。

連絡するときに揃えておくと話が早いのは、発生した時間帯、対象のデータ種別と件数、自社側のログに残っているエラーの表示、最後に正常だった時点、そして自社側で確認済みの範囲です。
最後の一つが抜けると、相手からも同じ確認を依頼されて時間が重複します。
「自社の送信は正常終了していて、同じ手順の他社とは送受信できている」と添えるだけで、相手が見るべき範囲は絞られます。

どちらの設定を変えるかという話になったときは、その場の力関係ではなく、影響する取引先の数で考えると整理できます。
片方の設定変更で済むのか、自社が他の取引先とも共有している変換定義に手を入れることになるのか。
後者なら、一社のために全体を触る判断になるので、テスト環境での確認と、他の取引先への影響確認まで含めた段取りが必要です。

障害中の取引先への連絡・代替対応（手動連携やFAX等）をどう判断するか

復旧見込みが立たないときの判断基準

原因の切り分けと復旧作業は、業務の締め時刻を待ってくれません。
受注データが入らなければ出荷指示が出ず、発注が届かなければ相手の生産や仕入れが動きません。
そこで、原因究明と並行して「いつまでに復旧しなければ別の手段に切り替えるか」を先に決めておきます。
この判断の物差しになるのは、システムの都合ではなく業務の締めです。

当日出荷の締めが夕方にあるなら、そこから出荷準備に必要な時間を引いた時刻が、切り替えを決める限界になります。
復旧の見込みが立たないまま限界時刻に近づいたら、原因が分からなくても代替に動く。
逆に、止まっているのが翌日以降の納品分しか含まないデータなら、慌てて手作業へ移すより復旧を待つほうが安全なこともあります。
止まったデータが何日分の、どの業務に効くものかを最初に確かめておくと、この判断が速くなります。

なお、取引先との間で基本契約や運用規約に障害時の取り扱いが定められている場合は、そちらが優先します。
連絡の期限や代替手段があらかじめ決まっていることもあるため、自社で判断の物差しを作る前に、既存の取り決めを確認しておきます。

手動連携・FAXなど代替手段への切り替え

代替手段は、電話やメール、FAXでの発注・受注の授受、あるいは相手の受発注画面へ人手で入力する、といった形になります。
どれも流れを止めないための一時的な措置で、元の仕組みより手間も間違いも増えます。
だからこそ、切り替えると決めた時点で、後始末の段取りまで一緒に決めておくのが要点です。

特に注意したいのが二重処理です。
手作業で処理した分と、EDIが復旧したときに改めて流れてくる分が重なると、同じ発注が二回登録されます。
手作業で入れた伝票に印を付けておく、復旧後に流れてきたデータを取り込む前に突き合わせる、止まっていた期間の分は相手に再送してもらうのか自社で入力するのかを決めておく。
切り替えと同時にここを決めておかないと、復旧した翌日に別の混乱が始まります。

代替の範囲も決めます。
すべての取引を手作業に戻すのか、当日出荷に関わる分だけに絞るのか。
人手で対応できる量には限りがあるので、優先する取引先や商品を先に決めておくと、現場が一件ごとに判断を迫られずに済みます。

取引先への連絡タイミングと内容

連絡は、原因が分かってからでは遅くなりがちです。
相手にとって必要なのは原因の説明ではなく、自分たちの業務をどうするかの判断材料だからです。
症状（どのデータが、いつから届いていないか）、影響範囲（どの業務に効くか）、いまの状況（調査中である旨）、次に連絡する時刻。
この四つがあれば、原因が未特定でも相手は動けます。

次の連絡時刻を先に約束しておくのは、問い合わせの電話で調査が中断するのを防ぐためでもあります。
「一時間後に、分かっていなくても状況をお伝えします」と言えれば、相手は待てます。
復旧後には、いつ復旧したか、欠けたデータをどう補うか（再送してもらうのか、手作業分と突き合わせるのか）、再発防止として何を見るかを、短く伝えておきます。

再発防止のための運用体制・監視の見直し（監視・手順書・冗長化の選択肢と条件）

監視・アラート通知の導入条件

障害対応が落ち着いたら、同じことが起きたときに気づくのが遅れないようにします。
EDIの監視で効くのは、エラーを知らせる仕組み以上に、来るはずのものが来ていないことを知らせる仕組みです。
エラーは何かが起きた証拠として残りますが、そもそも処理が動かなかった場合や、相手が送ってこなかった場合には何も出ません。
朝になって現場が気づく、という遅れの多くはここで生まれます。

そこで、取引先ごとに「この時間帯にはこの種類のデータが来る」という前提を書き出し、来ていなければ通知する形にします。
件数がゼロだったのか、そもそも受信処理が走っていないのかを区別できるようにしておくと、通知を受けた人がその場で最初の切り分けまで進めます。
通知先も現実に合わせる必要があります。
夜間に届くデータを一人の担当者の端末にだけ通知しても、その人が見なければ結果は同じなので、当番や共有のメール、チャットの窓口など、受け取る側の体制と合わせて決めます。

対応手順書の整備

手順書は、障害の記憶が新しいうちに書くのがいちばん安く済みます。
今回の対応で実際にやったこと、確認した画面、連絡した相手、判断に迷った場面をそのまま残せば、それが次の手順書の骨格になります。
後からきれいに作ろうとすると、細かい確認手順ほど抜け落ちます。

盛り込む価値が高いのは、連絡先の一覧（取引先の技術窓口、回線事業者、EDIサービスの保守窓口）、確認の順序、そして判断の基準です。
とくに、代替手段へ切り替える時刻の目安と、それを誰が決めるのかを書いておくと、担当者が一人で抱え込む状態を避けられます。
手順書が属人化を解くのは、知識を共有するからというより、判断の責任をあらかじめ配分するからです。

回線・プロトコルの冗長化を検討する場合

冗長化は、止まりにくくする代わりに費用と管理の手間が増えます。
だから全部を二重にするのではなく、止まると困る順に並べて上から検討します。
回線を二経路にする、EDIの処理を別構成でも動かせるようにする、特定の取引先だけ別の接続手段も併用する。
どれが見合うかは、その経路が止まったときに何時間で、どれだけの業務が止まるかで決まります。

判断のために必要なのは、見積書より先に、自社の業務影響の整理です。
一日止まったときに出荷できない分、取引先への説明にかかる工数、手作業へ切り替えたときに必要な人員。
これらが見えていれば、冗長化にかけられる費用の上限が自然に決まります。
逆にここが曖昧なまま提案を比べると、機能の多い少ないだけで選ぶことになります。

もう一つ、冗長化の検討は回線の更改と一緒に進めると無駄がありません。
補完策の提供が2027年ごろまでをめどとされている以上¹、旧来の構成のままであれば、いずれ回線側の作業が発生します。
そのときに経路を一本だけ引き直すのか、二本にするのかは、同じ工事の中で決められる話です。
障害が起きた直後は、社内で予算の話を通しやすい時期でもあります。

EDIの障害対応は、原因を言い当てる速さより、確認の範囲を狭めていく順番で差が付きます。
症状がどの段で止まっているかを特定し、自社・回線・取引先の三方向に分け、回線側では自社がどの世代の上にいるかを確かめる。
その間も業務は動いているので、締め時刻から逆算した限界時刻を決めて、代替手段の判断を並行させます。
復旧した後に、今回の対応を手順書と通知の仕組みへ移しておけば、次の障害は同じ重さでは来なくなります。

回線の世代も、取引先ごとの手順の違いも、社内に残っている資料だけでは現状を確定しづらいことがあります。障害の最中はなおさら、どこから手を付けるかで迷いが出ます。

いま起きている症状から、どの範囲を先に確認すれば切り分けが進むのか、自社の構成で次に期限が来るのはどこなのかを、状況を伺いながら一緒に整理できます。無料相談で要件を整理する

切り分けのために手元へ集める情報

確認の主体（自社内で完結するか、回線の契約内容や取引先への問い合わせが必要か）で分けて並べています。

• 自社内：伝送ソフトやEDIサービスの履歴で、該当時間帯の処理が実行されたのか、実行されて失敗したのか

• 自社内：直近の変更履歴（サーバーの更新、証明書の更新、変換定義の修正、ネットワーク設定の変更）

• 自社内：同じ時間帯に、他の取引先との送受信が成功しているかどうか

• 自社内：止まったデータと、直近で正常に通ったデータの、項目ごとの差分と件数

• 自社の契約：回線サービスの契約名、通信装置、伝送ソフトの接続先設定から分かる回線の世代

• 取引先・事業者へ問い合わせ：相手側の送信記録、相手側での変更予定の有無、技術的な話ができる窓口の連絡先

夜間や休日で社外へ問い合わせられない時間帯は、自社内で確認できる項目から先に潰し、問い合わせ内容を朝一番に出せる形まで用意しておきます。

取引先ごとに違う通信プロトコルの性格と、障害時に効いてくる差

プロトコル	運用の性格とデータ量	主な使われ方	障害時に見るところ
JX手順	運用コストが低く、一度のやり取りで送受信できるデータ容量は他のプロトコルより少ない2	中小企業をメインに、小売・流通の取引2	量が増えた日だけ失敗していないか
ebXML MS	1万行以上にもなる大容量データをリアルタイムで送受信・処理できる2	流通業界や医療機関のネットワーク2	受信後の取り込み処理が量に追いついているか
全銀協標準通信プロトコル（TCP/IP手順・広域IP網）	広域IP網での利用を前提に作られ、高度なセキュリティを設けて用いる2	企業と銀行の間のデータやり取り（商流のEDIとは別体系）2	商流側の障害と取り違えていないか

JX手順：コストの低さと、一度に送れる量の少なさ

量が前提を超えたときに表に出る

JX手順は運用コストが低く、一度のやり取りで送受信できるデータ容量は他の通信プロトコルより少ないという性格があり、中小企業をメインに、小売業・流通業の取引で採用されてきました²。
この量の少なさは、平常時に障害の原因になるものではありません。
問題になるのは、扱う量が前提を超えたときです。

取引が拡大したり、繁忙期の一括発注でデータが大きくなったりしたときに、普段は通っている経路で失敗が出ることがあります。
切り分けでは、失敗した日のデータ量と、正常に通っていた日の量を比べます。
量が境目になっているようなら、送り方を分ける、送信の時間帯をずらす、扱える量の異なる方式への移行を検討する、といった方向の相談になります。
いずれも受け取る側の環境に合わせる必要があるため、相手の技術担当と一緒に決める話です。

ebXML MS：大容量を前提にした通信と、受け口側の余力

通信より、受け取った後の処理を見る

ebXML MSは、1万行以上にもなる大容量のデータ通信をリアルタイムで送受信・処理できる方式で、日本では流通業界や医療機関のネットワークに採用されています²。
大量のデータが滞りなく流れることを前提にしているぶん、取引先がこの方式を使っているなら、自社に届く量もそれに見合ったものになります。

障害の切り分けでは、通信そのものより、受け取った後の処理が追いつかない場面を見ます。
受信は成功しているのに基幹システムへの取り込みが終わらない、途中で止まる、他の処理と重なって遅れる。
この場合の対処は回線でもプロトコルでもなく、自社側の処理の順番や実行時間帯の調整になります。
相手へ問い合わせる前に、自社の取り込み処理がどれだけの時間を要しているかを確認しておくと、原因の押し付け合いになりません。

全銀協標準通信プロトコル：商流のEDIとは別の体系

どちらのEDIの話かで、窓口が変わる

全銀協標準通信プロトコル（TCP/IP手順・広域IP網）は、固定電話のIP網移行を受けて広域IP網での利用を前提に作られ、企業と銀行の間のデータやり取りに高度なセキュリティを設けて用いられます²。
発注や受注といった商流のEDIとは、目的も、関わる相手も違う別の体系です。

これを押さえておくと、障害時に当たる窓口を間違えずに済みます。
振込データや入出金明細が流れない事象は、取引先の受発注の仕組みではなく、金融機関との接続の話になります。
社内で「EDIが止まった」という言葉が飛び交うときに、どちらのEDIを指しているかを最初に確認するだけで、調査に入る担当も、連絡する先も変わります。

要点の整理

軸	基準
どこから確認するか	送信・伝送・受信・取り込みのどの段で止まったかを特定し、自社・回線・取引先の三方向に分ける
回線を疑う目安	ディジタル通信モードや補完策の上で動いていないか、契約名・通信装置・接続先設定で回線の世代を確かめる
プロトコルや形式を疑う目安	同じ手順の他の取引先は動いているか、失敗した日のデータ量と項目が普段と違わないか
代替手段へ切り替える時点	業務の締め時刻から逆算した限界時刻。契約や運用規約に定めがあればそちらを優先
再発防止で先に手を付ける所	来るはずのものが来ていないことを知らせる通知と、記憶が新しいうちに残す対応記録

復旧した後の見直しは、監視の設計も冗長化も、自社の業務影響を金額と時間で押さえていないと選びようがありません。ここは社内だけだと後回しになりがちな部分です。 止まったときに何がどれだけ滞るのかを整理したうえで、通知の設計、手順書に残す判断基準、回線の更改と合わせた検討の順序を確かめられます。

よくある質問

ISDN回線を使ったEDIは、もう使えなくなっているのか？

データ通信に使われていたINSネットの「ディジタル通信モード」は、2024年1月に全都道府県で提供が終了しています¹。
終了後は切替後のデータ通信サービス（補完策）へ移る形が取られましたが、こちらも2027年ごろまでをめどに一定期間の提供とされています¹。
一方、INSネットという回線契約自体は2024年8月に新規受付が終了し、提供終了の予定日は2028年12月です³。
この2028年は回線契約の期限であって、EDIのデータ通信が使える期限ではありません。

取引先側の設備・回線が原因の障害の場合、自社は何をすればよいか？

自社側で確認済みの範囲を明確にして相手の技術窓口へ渡し、あとは業務を止めないための判断に集中するのが現実的です。
「自社の送信は正常終了している」「同じ手順の他の取引先とは送受信できている」と伝えれば、相手が調べる範囲が絞れます。
そのうえで、締め時刻から逆算して代替手段へ切り替える限界時刻を決め、いつまでに復旧の見込みを教えてほしいかを相手に伝えておきます。
復旧を待つ以外にできることがない状況でも、この二つは自社で決められます。

監視ツールを導入すれば障害を防げるのか？

監視は障害の発生を防ぐものではなく、気づくまでの遅れを短くするものです。
効果が出るかどうかは、何を検知する設計にするかで変わります。
エラーの通知だけでは、処理が動かなかった場合や相手が送ってこなかった場合に何も鳴りません。
取引先ごとに来るはずのデータと時間帯を定義して、来ていなければ知らせる形にし、さらに夜間や休日に誰が受け取るかまで決めて初めて、導入の意味が出ます。

EDIのプロトコルが取引先と異なる場合、どちらに合わせるべきか？

取引上の力関係ではなく、変更が影響する取引先の数と、変更にかかる作業量で判断すると整理できます。
プロトコルは想定する企業規模や一度に扱えるデータ量が異なるため²、単純にどちらが優れているという比較にはなりません。
自社が他の取引先とも共有している設定に手を入れるなら、その一社のために全体を触ることになるので、テストと他社への影響確認まで含めた段取りが要ります。
片側の個別設定で済むなら、そちらのほうが安全です。

障害対応の手順書が無い状態で障害が起きたら、まず何をすればよいか？

手順書を作るのは後にして、記録を取りながら対応します。
確認した画面と結果、連絡した相手と時刻、判断に迷った場面をメモしておくだけで十分です。
対応中は、症状の特定と三方向の切り分け、取引先への一次連絡、代替手段の限界時刻の設定という順で進めます。
そして復旧した後、そのメモを整えたものが最初の手順書になります。
記憶が薄れてから作り直すより、内容が具体的なぶん次に使えます。

1. 1　出典：株式会社インプレス（INTERNET Watch編集部）「INSネットの「ディジタル通信モード」、提供終了日が明らかに」（2022年）
2. 2　出典：NTTインテグレーション株式会社「EDIの通信プロトコルの種類について解説」（2024年）
3. 3　出典：東日本電信電話株式会社（NTT東日本）「INSネットの新規申込受付・提供終了について」（2024年）