EDIの運用と保守はどこまで自社の仕事か｜見直しと委託・クラウド移行の判断基準

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

B2B EC-COLUMN

担当者交代や障害をきっかけに直面する「運用」と「保守」の境目

EDIの担当者が代わった直後や、夜間のデータ送受信が止まった翌朝に、今の体制をこのまま続けてよいのかと迷うことがあります。
日々の送受信結果の確認や取引先とのやり取りは自社に残りやすい一方、ソフトウエアの更新や通信規格への対応といった維持更新の作業は、ベンダーの保守契約に切り出せる場合があります。
手元の作業を運用と保守に分け、契約書でどこまでが委託済みかを確かめると、自社に残っている仕事の輪郭がはっきりします。
そのうえで、自社や取引先がINSネットのディジタル通信モードを使っているかどうかで、見直しを急ぐべきかどうかも変わってきます。

「運用」が指す予防的・定期的な作業

EDIは、企業や行政機関などがコンピュータをネットワークで繋ぎ、伝票や文書を電子データで自動的に交換する仕組みを指します³。
人が介在しなくてもデータが流れる前提で作られているため、動いている間は誰の目にも触れません。
その代わりに、止まっていないことを毎日確かめる作業が必ず残ります。

IT業務全般の整理では、システム運用は定期的な業務が多く、障害を未然に防止するための対策や業務が中心とされ、システム監視・パッチ対応・サーバ再起動などが例に挙げられています⁴。
これはEDI専用の定義ではありませんが、この枠組みをEDIの現場に当てはめると、自社に残っている作業が具体的に見えてきます。

たとえば朝いちばんに前夜の受信結果の一覧を開き、取引先ごとの受信件数が想定どおりかを目で追う作業。
取引先から新しい店舗コードや商品コードの追加連絡が届いたときに、マスタへ登録してテスト送信を行う作業。
いずれも何かが壊れているわけではないのに、毎日あるいは毎月発生します。
ここまでが、予防的・定期的な意味での運用にあたる部分です。

「保守」が指す突発対応・維持更新の作業

一方の保守は、障害対応など突発的な業務が多く、不具合の原因究明や修正・復旧が例として挙げられます⁴。
EDIでは、これに加えて外から降ってくる維持更新の作業があります。

その代表が通信規格への対応です。
流通BMSは、メッセージ（電子取引文書）と通信プロトコル／セキュリティに関するEDI標準仕様で、製造・卸売・小売の三層間の接続を対象としています²。
2007年の基本形Ver.1.0の公開以降、2018年11月のVer2.0（軽減税率対応）まで版が改定されてきました²。
規格が改まれば、自社のシステムが安定して動いていても対応が必要になります。
つまり保守の一部は、自社の都合ではなく業界標準や取引先の側から発生します。

やっかいなのは、この境目が場面によって動くことです。
夜間の送信が止まったとき、ログを見て「相手先に届いていないのか、自社で止まっているのか」を切り分けるところまでは運用の延長に見えます。
けれども、原因がソフトウエアの不具合で、プログラムの修正が必要となれば保守の話になります。
どちらに入るかは一般論では決まらず、自社が結んでいる保守契約の記載で決まります。
だからこそ、次に見るべきは契約書がどこまでを引き受けているかです。

出典：アイティーエム「システム運用とは？保守と管理の違いを業務一覧で解説」（システム運用・保守全般というIT業務一般の整理。EDIへの当てはめは本記事の整理）

EDIの保守契約が実際にカバーする範囲（ベンダー実例）

ヘルプデスクでカバーされる範囲

契約書の読み方を具体的にするために、公開されているEDI保守サービスの内容を一つ見てみます。
EDI-Masterシリーズの保守サポートは、ヘルプデスク対応（質問・エラー発生時の対応）とソフトウエアのバージョンアップから構成されています⁵。
逆に言えば、この二つの外側にある作業は契約範囲に入っていないということです。

注目したいのは対応時間帯です。
同サービスのヘルプデスクは、月曜から金曜の9:00〜12:00、13:00〜17:30に対応するとされています⁵。
EDIの送受信は夜間や早朝に組まれていることが多く、止まる時間帯と問い合わせられる時間帯はしばしばずれます。
金曜の深夜に受信が落ちた場合、月曜の朝までは自社の判断で動くことになります。

そこで自社側に残る現実的な作業が見えてきます。
エラーの発生時刻とログを保全しておくこと、取引先に「受信できていない可能性がある」と一報を入れること、再送してよいデータか二重計上の恐れがあるかを業務側と確認すること。
この一次対応の手順が書いてあるかどうかで、担当者が代わったときの負荷はかなり変わります。
なお、ここで挙げた対応範囲や時間帯はEDI-Masterシリーズの公開情報にもとづく一例であり、製品やプラン、契約形態によって異なります。
自社の契約書で、対応時間帯と連絡経路、時間外の扱いを確かめるのが前提になります。

バージョンアップ・契約期間の扱い

もう一方の柱であるバージョンアップは、マイナー版が無償、メジャー版が優待価格という形で提供されます⁵。
ここで区別しておきたいのは、更新版が提供されることと、それを自社の環境へ適用し終えることは別だという点です。
適用の計画を立て、停止できる時間帯を業務側と調整し、取引先との疎通テストを行う段取りは、契約の内容次第で自社に残ります。

契約期間にも目安があります。
買取型では対象製品の納品月の翌月1日から1年間、サブスクリプション型では契約期間に準ずるとされています⁵。
1年ごとに更新の判断が回ってくるということは、見直しのタイミングが毎年一度は制度的に用意されているということでもあります。
費用の見直しを言われたときに慌てて比較するより、更新月の2〜3か月前に対応範囲と自社に残っている作業を棚卸ししておくほうが、判断の材料はそろいます。

出典：キヤノンITソリューションズ「保守サポート内容:電子データ交換・EDI(EDI-Master)」（EDI-Masterシリーズの買取型保守契約、2026年ページ確認時点）

属人化に加え、対応の緊急度を左右する回線終了という外部要因

取引先対応が属人化しやすい理由

契約で切り出せる部分を除くと、自社に残るのは日々の運用と、取引先ごとの個別対応です。
この後者が、担当者の頭の中に溜まりやすい部分にあたります。

理由ははっきりしています。
取引先ごとに接続先も送信時刻も違い、データ項目の使い方や商品コードの体系、締め時刻の扱いまで少しずつ異なるからです。
さらに「この取引先だけは月末の返品データを手で直してから取り込む」といった例外処理が、手順書ではなく担当者の判断として積み重なっていきます。
毎日問題なく回っている限り、その判断を書き出す動機が生まれません。

担当者が退職や異動で抜けたとき、最初に困るのは個々の例外処理ではなく、そもそもどの取引先とどの方式で繋がっているかの一覧が無いことです。
接続方式、利用している回線の種別、相手先の担当窓口、準拠している規格とその版、機器や証明書の更新時期。
この五項目を取引先ごとに書き出した表が一枚あるだけで、障害時の調査も、次に述べる回線の期限の確認も、担当者一人の記憶に頼らずに進められます。

INSネット「ディジタル通信モード」終了のスケジュールと影響

ここから先は、自社または取引先がISDN回線でEDIを行っている場合の話です。
光回線やインターネットEDIへすでに移行済みであれば、以下の期限はそのまま当てはまりません。
まず自社の回線種別を確認したうえで読み進めてください。

INSネット64・64ライト・1500のディジタル通信モードは、新規販売が2024年8月31日に終了し、サービス提供は2028年12月31日に終了するとされています¹。
対象は事業者向けデータ通信機能を備えたISDN回線で、利用事例の一覧にはEDI（メーカー⇔卸⇔小売間での商品受発注データ通信）が明記されています¹。
つまり、EDIの通信そのものが期限のある基盤の上で動いている企業が存在します。

補完策として切替後のINSネット上のデータ通信が提供されていますが、伝送遅延が生じて処理時間が増大するなど、利用する機器によっては通信に影響が発生すると注記されています¹。
ベンダーの説明では、INSネットのディジタル通信モードに比べて最大4倍程度の通信時間を要するとされ、出荷・納品の遅延につながる恐れがあると指摘されています⁶。
これは技術的な説明であって、すべての企業・機器での実測値ではありません。
それでも、締め時刻の直前に大量の発注データを受け取る運用をしている場合、通信時間の伸びが業務時間に直結することは想像がつきます。

対応を早めに始める必要があるのは、自社だけで決められない部分があるからです。
取引先との対策タイミングや通信方式を合わせる必要があり、自社都合だけで対策を進められないこと、ベンダーのリソース不足でプロジェクトが滞る事態も想定されることが指摘されています⁶。
移行の目安としては、半年から1年をかけて業務見直しを進めるのが理想的とされています⁶。
猶予があるように見えても、取引先の数だけ調整の往復が発生すると考えておくほうが実態に近くなります。

出典：NTT東日本「INSネットをご利用の事業者さまへ」（事業者向けデータ通信機能を備えたISDN回線が対象）、キヤノンITソリューションズ「ISDN終了問題」（インターネットEDIへの移行を検討する場合の目安）

自社運用の継続と外部委託・クラウドEDI移行、対応範囲の違い

外部保守委託でカバーされる作業

ここまでで、自社に残りやすいのは日々の運用と取引先ごとの個別対応、切り出しやすいのはソフトウエアの維持更新と問い合わせ対応だと整理できました。
では、外部へ委託したときに実際に手元から離れるのはどこまでなのでしょうか。

オンプレミス製品の保守契約で契約範囲に含まれるのは、バージョンアップ対応とヘルプデスクです⁵。
ソフトウエアの面倒は見てもらえる一方で、そのソフトウエアが載っているサーバ、OS、回線契約は自社の資産のまま残ります。
機器が保証期間を過ぎたときの置き換え、OSのサポート終了に合わせた入れ替え、回線の契約変更は、保守契約とは別の話として自社で計画することになります。

もう一つ残るのが、更新を業務に反映させる段取りです。
新しい版を適用する日程を決め、EDIを止められる時間帯を業務側と合わせ、取引先との疎通テストを行う。
この調整は、取引先の営業日や締め時刻を知っている人でないと組めません。
外部委託を検討するときは「誰が作業するか」だけでなく「誰が日程を決めるか」まで見積りの対象に入っているかを確かめると、後から増える手間を読み違えずに済みます。

クラウドEDIへ移行した場合の保守範囲

クラウド型のEDIサービスでは、線の引かれる場所がもう一段動きます。
クラウドEDIサービス「トラコ」は、導入サポート、運用サポートに加えて、定期的なシステムアップデートに対応する継続的サポートを提供するとしています⁷。
ソフトウエアの版を上げる作業そのものを自社で計画しなくてよくなる点が、オンプレミスの保守契約との違いです。

手放せるのは、サーバの維持とアップデートの手当てです。
反対に、どの取引先とどのデータ項目をやり取りするか、自社の基幹システムへどう受け渡すか、コードの読み替えをどう定義するかは、移行しても自社で決める内容として残ります。
クラウドに移せば取引先との調整が消えるわけではなく、調整の中身が「機器と回線の話」から「データと運用ルールの話」に寄っていく、という捉え方のほうが実態に近いはずです。

なお、外部委託とクラウド移行のいずれについても、確認できた公開情報には月額などの金額の記載がありませんでした。
費用は構成や取引先数によって変わる個別見積りの領域であり、相場として示せる数字はありません。
だからこそ、金額を並べる前に対応範囲の線引きを揃えておくことが、比較の前提になります。

見直し・移行のタイミングと委託先選定で確認すべき条件

対応を急ぐべきかの判断材料

見直しを急ぐかどうかは、外から来る期限と、社内で進む劣化の二つで決まります。

外からの期限は、対象回線を使っている場合のサービス提供終了です。
2028年12月31日という期日があり、移行までの猶予は残されています¹。
ただし取引先との方式合わせが必要で、業務見直しを含めて半年から1年を見込むのが理想的とされる以上⁶、着手できる時期は逆算で決まります。
取引先が多いほど、調整の往復に時間がかかります。

社内側の材料は三つあります。
一つ目は属人化の度合いで、担当者が不在の日に夜間障害が起きたとき、別の人が一次対応の手順をたどれるかどうか。
二つ目は保守契約の更新月で、契約期間が1年単位で区切られているなら⁵、そこが範囲を見直す自然な節目になります。
三つ目は機器とOSの保証・サポートの残り期間です。
このうち二つ以上が近い時期に重なるなら、個別に手当てするより、体制ごと見直したほうが手戻りが少なくなります。

委託先・サービスを選ぶときの確認項目

比較の場で聞くべきことは、実例から抜き出せます。
公開されている保守サービスでは、対応時間帯、契約期間、バージョンアップの扱いが具体的に定められていました⁵。
この三点は、どの委託先に対しても同じ粒度で確認できます。

加えてEDIでは、規格が改定されたときの扱いを聞いておく必要があります。
流通BMSのように業界標準の版が改まることがあり²、その対応が契約に含まれる保守の範囲なのか、別途の開発案件になるのかで、翌年以降の負担が変わります。
クラウドサービスの場合も、定期的なシステムアップデートに対応するという記載⁷が、取引先固有の設定変更まで含むのかは確認が要ります。

最後に、自社の側で決めておくことがあります。
夜間・休日に停止したときの一次対応を誰がどこまで行うか、その連絡先と手順を紙一枚にしておくことです。
委託先の対応時間帯が平日の日中に限られる場合⁵、その外側の時間は契約では埋まりません。
ここを決めておけば、担当者が代わっても対応が止まる時間を短くできます。
これは障害そのものを無くす手立てではなく、誰が最初に動くかを迷わないための備えです。

どの選択肢を選ぶかは、結局どの作業が手元に残るかで決まります。
公開情報で確認できた範囲を、三つの選び方で並べておきます。

運用と保守の境目は一般論では決まらず、自社の契約書の記載と、取引先ごとの接続条件を突き合わせて初めて見えてきます。<br>社内だけで進めると、どの作業が委託済みでどれが残っているかの判定に時間がかかりがちです。

取引先ごとの接続方式と回線種別、保守契約の対応範囲を並べたうえで、自社に残っている作業がどれかを一緒に切り分けられます。<br>見直しを急ぐ理由があるかどうかも、その場で判断材料をそろえられます。無料相談で要件を整理する

自社運用・外部保守委託・クラウドEDIの対応範囲を確認する早見表

各社が公開する対応範囲をもとに、機器・ソフトウエア・取引先対応のどれが自社に残るかという軸で並べています。料金は公開情報に金額の記載がないため掲載していません。

• 自社運用を続ける場合：日々の送受信結果の確認、取引先ごとの設定変更、障害の一次切り分けに加え、ソフトウエアの更新判断、サーバとOSの入れ替え、回線契約の維持まで自社に残る

• 外部保守委託（オンプレミス製品の保守契約の例）：ヘルプデスク対応とソフトウエアのバージョンアップが契約範囲に含まれ、機器・OS・回線契約と、更新を適用する日程調整は自社に残る

• クラウドEDIへ移行する場合：定期的なシステムアップデートへの対応がサービス側の継続的サポートに含まれ、取引先ごとのデータ項目やコードの定義、基幹システムとの受け渡しは自社に残る

• いずれの場合も共通：取引先との方式や切替時期の調整、夜間・休日に停止したときの一次対応の取り決めは自社の役割として残る

要点の整理

軸	基準
運用と保守の切り分け	予防的・定期的な作業は運用、突発対応と機器・規格の維持更新は保守として整理し、境目は自社の契約書の記載で判断する
保守契約で確認する点	ヘルプデスクの対応時間帯、バージョンアップの扱い、契約期間の起点と単位
	回線終了の該当判定	自社と取引先が事業者向けデータ通信機能を備えたISDN回線を使っているか。該当する場合は2028年末から逆算する
移行に見込む期間	業務見直しを含めて半年〜1年が目安。取引先との方式・時期合わせが必要で自社都合だけでは決まらない
自社に残る役割	取引先ごとの設定とコードの定義、夜間・休日の一次対応の取り決め。委託・移行後も残る

自社運用の継続、外部委託、クラウド移行のどれを選ぶかは、金額より先に対応範囲の線引きをそろえないと比較になりません。<br>範囲の言葉づかいはサービスごとに違うため、同じ粒度に直す作業が要ります。 対応時間帯、契約期間、アップデートの範囲、規格変更時の扱いという同じ項目で候補を並べ直し、移行する場合に自社へ残る作業と必要な期間の見当まで確かめられます。

よくある質問

自社にIT担当者が1人しかいない場合、EDIの保守はどこまで外部に任せられますか

公開されている保守サービスの例では、ヘルプデスク対応とソフトウエアのバージョンアップが契約範囲とされています⁵。
この範囲であれば、不具合の原因究明や版の提供は委託できます。
一方で、ヘルプデスクの対応が平日9:00〜12:00、13:00〜17:30といった時間帯に限られる場合⁵、夜間や休日に送受信が止まったときの最初の判断は自社に残ります。
担当者が1人の体制では、その時間帯に何をどこまで行うか（ログの保全、取引先への一報、再送の可否の確認）を紙一枚にまとめ、業務部門の誰かと共有しておくことが現実的な備えになります。
サーバやOSの更新まで含めて手放したい場合は、保守委託よりクラウド型の利用が選択肢に入ります⁷。

INSネットの対象回線を使っていない場合でも、いわゆる2024年問題は関係しますか

新規販売終了とサービス提供終了の対象は、事業者向けデータ通信機能を備えたISDN回線です¹。
自社がすでに光回線やインターネットEDIへ移行済みであれば、この期限が自社の設備にそのまま当てはまることはありません。
ただし確認したいのは取引先側です。
相手先が対象回線を使っている場合、切替の時期や通信方式を合わせる必要が生じ、自社都合だけで進められない調整が発生します⁶。
取引先ごとの接続方式と回線種別を一覧にしておくと、自社に影響が及ぶ相手先を先に見分けられます。

クラウド型EDIへ移行すると、既存の取引先ごとの接続設定はどうなりますか

サービス側が引き受けるのは、システムの維持と定期的なアップデートにあたる部分です⁷。
取引先ごとにどのデータ項目をやり取りするか、商品コードや店舗コードをどう読み替えるか、自社の基幹システムへどう受け渡すかは、移行後も自社で決める内容として残ります。
設定そのものの作り込みを支援するかどうかは、導入サポートの範囲として個別に確認する必要があります。
移行時には取引先ごとの疎通テストが必要になるため、相手先の営業日や締め時刻を踏まえた日程調整も自社側の仕事になります。

保守委託の契約期間中に通信規格が変更された場合、追加費用は発生しますか

確認できた公開情報からは、規格改定への対応が保守の範囲に含まれるかどうかまでは判断できません。
保守サポートの構成として示されているのはヘルプデスク対応とバージョンアップで、バージョンアップはマイナー版が無償、メジャー版が優待価格とされています⁵。
規格改定がどちらの版で提供されるかは製品や改定内容によって変わるため、契約書と見積りで個別に確認してください。
流通BMSのように業界標準の版が改まる例があること²を前提に、改定時の扱いを契約前に質問しておくと、翌年以降の負担を読み違えずに済みます。

運用担当者が退職・異動した場合、まず何を確認すればよいですか

最初に必要なのは、取引先ごとの接続方式、利用している回線の種別、相手先の担当窓口、準拠している規格とその版、機器や証明書の更新時期をまとめた一覧です。
次に、保守契約の書面でヘルプデスクの対応時間帯と連絡経路、契約期間の終期を確認します⁵。
この二つがそろうと、障害時に自社で動く範囲と委託先に頼める範囲の境目が分かります。
そのうえで、担当者しか知らなかった例外処理（特定の取引先だけ手作業で直していた工程など）を業務部門から聞き取り、手順として書き出しておくと、次の交代時に同じ空白が生まれにくくなります。

1. 1　出典：NTT東日本「INSネットをご利用の事業者さまへ」（2026年 ページ確認時点、記載スケジュールは2024年・2028年）
2. 2　出典：GS1 Japan（一般財団法人流通システム開発センター）「流通BMS（流通ビジネスメッセージ標準）」（2025年 直近改定）
3. 3　出典：一般財団法人 日本情報経済社会推進協会（JIPDEC）「EDIとは」（2026年 ページ確認時点）
4. 4　出典：アイティーエム株式会社「システム運用とは？保守と管理の違いを業務一覧で解説」（2026年 ページ確認時点）
5. 5　出典：キヤノンITソリューションズ株式会社「保守サポート内容:電子データ交換・EDI（EDI-Master）」（2026年 ページ確認時点）
6. 6　出典：キヤノンITソリューションズ株式会社「ISDN終了問題」（2026年 ページ確認時点）
7. 7　出典：デジタルトランスコミュニケーションズ株式会社「クラウドEDIサービス トラコ」（2026年 ページ確認時点）