相談事例 /
system-rescue
部品メーカーの受発注EDIが深夜停止 ─ 大手取引先5社との接続を24時間で代替経路へ切り替え、出荷遅延ゼロに収めた事例
課題
20年動いてきたWindows Server 2008 R2上の受発注EDI中継基盤がRAID故障で停止。翌朝9時の朝礼までに大手自動車部品メーカー2社・家電3社からのEDI注文を受信できる状態へ戻す必要があった。
解決策
完全復旧は断念し、AWS EC2上にOpenAS2を中心とした代替AS2接続環境を一晩で構築。深夜のうちに取引先5社のEDI担当者へ証明書交換と接続情報更新を依頼し、朝6時から並行で切り替え。
成果
朝9時時点で3社、午前11時20分に全5社の接続が成立し出荷遅延ゼロ。Windows Server 2008 R2は完全退役し、運用費は月17万円から3万8千円へ。年間約158万円のコスト圧縮も同時に実現。
## ご相談時の状況
部品メーカー様（社員120名・年商28億円）から、深夜2時に電話が入りました。「翌朝9時の朝礼までに、取引先5社からのEDI注文が受信できる状態に戻してほしい」とのこと。受発注EDIの中継サーバが停止し、過去20年動いてきた仕組みが沈黙していました。
このメーカーは大手自動車部品サプライヤー2社、家電メーカー3社と、それぞれ異なるEDIプロトコルで接続していました。JX手順、全銀手順、Web-EDI（OFTP2／AS2）が混在。中継には20年前に導入されたWindows Server 2008 R2上の独自スクリプトと、富士通のEDI製品系のラッパーが動いていました。
直接の障害原因は、サーバのRAID1の片肺が完全に死亡し、もう片方も読み込みエラーを連発している状態。OSは延長サポートも終了済み。バックアップは毎週日曜にテープへ取得していたものの、リストアは過去5年間一度も検証されていない、典型的な「動いているから触らない」状態でした。
## 私たちの初動
最初の30分で判断したのは「このサーバの完全復旧を最優先にすると、朝9時には間に合わない」ということ。20年物のEDIスクリプトには、退職者しか分からない設定が無数に埋め込まれている可能性があり、リストアして仮に動いても、ハードが再度死ぬリスクが残ります。
代替経路を立てる方針に切り替えました。具体的には、AWS東京リージョンのEC2（t3.medium）上にUbuntu 22.04を立て、AS2にはOpenAS2、OFTP2にはOFTPlusを採用。JX手順は今回の取引先では実際には使われておらず、AS2のみで5社と接続できる目算が立ちました。証明書はBoulder（Let's Encrypt系）ではなくPrivate CAで自己発行する方式に統一。EDI接続はパブリックCAでなくても問題ありません。
並行して、取引先5社それぞれのEDI担当者に深夜のうちにメールを送付し、朝8時から順に電話で接続情報の更新を依頼することにしました。AS2接続では、こちらの新サーバの公開鍵を相手に渡し、相手の本番EDIサーバに登録してもらう必要があります。これは相手側のオペレーションが入るため、こちらだけで進められません。
## 朝6時から進めた切り替え
朝6時に取引先1社目のEDI担当者が出社し、最初の証明書交換が始まりました。1社あたり、証明書送付・登録依頼・テスト送受信で平均90分。5社並行で進めた結果、朝9時45分に4社、午前11時20分に5社目の接続が成立しました。
注文データの欠損については、各取引先に「障害発生時刻から復旧時刻までの注文は再送願いたい」と依頼。深夜0時から朝6時の時間帯はそもそも注文が発生しない取引先がほとんどで、再送が必要だったのは2社・合計14件の注文でした。受信したデータは、社内の基幹システム（IBM iSeries上のRPG/COBOLバッチ）に従来通りCSVで受け渡し、出荷業務に影響を出さずに繋ぎ込めました。
相手先のセキュリティポリシー上、「IPアドレスを固定したい」「FQDNは事前申請したものに限る」という制約があったため、ElasticIPを取得し、社内のDNSにも事前にCNAMEを通しておきました。これがないと、AS2のTLSハンドシェイクで相手側のホワイトリストに弾かれます。
## 結果と効果
朝9時の朝礼時点でEDI受信が3社復旧、午前11時20分に全社復旧。出荷遅延は発生しませんでした。
副次的な効果として、長年「触れない聖域」だったWindows Server 2008 R2が完全に退役。新環境はLinux上のOSS構成で、月額運用費は従来の17万円（OS保守延長・EDI製品保守・ハード保守の合計）から3万8千円へ。年間で約158万円のコスト削減となりました。
EDI設定はAnsibleでコード化し、Git管理に移行。証明書の有効期限はLambdaで自動監視し、期限60日前にSlack通知が飛ぶ仕組みも組み込みました。20年前の「秘伝のスクリプト」が、再現可能なインフラに置き換わっています。
## 学び・他のお客様への提言
この事例から取るべき教訓は3つに集約されます。
第一に、EDIサーバこそ可用性の盲点になりがちです。普段は淡々と動いているため、誰も触らず、誰もリストアを検証しません。社内の基幹システムよりも壊れた時のインパクトは大きいのに、保守予算は付きません。年に一度はリストア検証を実施するべきです。
第二に、レガシーEDIプロトコルは取引先が変わらない限り温存される傾向にあります。しかし、AS2／OFTP2など標準化されたプロトコルへの移行を、5年スパンで取引先と握っておくと、いざという時に動きやすくなります。今回も、JX手順がもし生きていたら、24時間での復旧は不可能でした。
第三に、緊急時の判断軸は「元に戻す」より「業務を回す」を優先することです。20年動いてきたサーバを完全復旧しようとすると数日かかります。業務影響をゼロに抑えるには、迂回路を立てる方が早い場合が多い。経営層への説明も、「復旧の最短ルートは作り直しでした」と素直に伝えた方が、その後のIT予算も付きやすくなります。
部品メーカー様（社員120名・年商28億円）から、深夜2時に電話が入りました。「翌朝9時の朝礼までに、取引先5社からのEDI注文が受信できる状態に戻してほしい」とのこと。受発注EDIの中継サーバが停止し、過去20年動いてきた仕組みが沈黙していました。
このメーカーは大手自動車部品サプライヤー2社、家電メーカー3社と、それぞれ異なるEDIプロトコルで接続していました。JX手順、全銀手順、Web-EDI（OFTP2／AS2）が混在。中継には20年前に導入されたWindows Server 2008 R2上の独自スクリプトと、富士通のEDI製品系のラッパーが動いていました。
直接の障害原因は、サーバのRAID1の片肺が完全に死亡し、もう片方も読み込みエラーを連発している状態。OSは延長サポートも終了済み。バックアップは毎週日曜にテープへ取得していたものの、リストアは過去5年間一度も検証されていない、典型的な「動いているから触らない」状態でした。
## 私たちの初動
最初の30分で判断したのは「このサーバの完全復旧を最優先にすると、朝9時には間に合わない」ということ。20年物のEDIスクリプトには、退職者しか分からない設定が無数に埋め込まれている可能性があり、リストアして仮に動いても、ハードが再度死ぬリスクが残ります。
代替経路を立てる方針に切り替えました。具体的には、AWS東京リージョンのEC2（t3.medium）上にUbuntu 22.04を立て、AS2にはOpenAS2、OFTP2にはOFTPlusを採用。JX手順は今回の取引先では実際には使われておらず、AS2のみで5社と接続できる目算が立ちました。証明書はBoulder（Let's Encrypt系）ではなくPrivate CAで自己発行する方式に統一。EDI接続はパブリックCAでなくても問題ありません。
並行して、取引先5社それぞれのEDI担当者に深夜のうちにメールを送付し、朝8時から順に電話で接続情報の更新を依頼することにしました。AS2接続では、こちらの新サーバの公開鍵を相手に渡し、相手の本番EDIサーバに登録してもらう必要があります。これは相手側のオペレーションが入るため、こちらだけで進められません。
## 朝6時から進めた切り替え
朝6時に取引先1社目のEDI担当者が出社し、最初の証明書交換が始まりました。1社あたり、証明書送付・登録依頼・テスト送受信で平均90分。5社並行で進めた結果、朝9時45分に4社、午前11時20分に5社目の接続が成立しました。
注文データの欠損については、各取引先に「障害発生時刻から復旧時刻までの注文は再送願いたい」と依頼。深夜0時から朝6時の時間帯はそもそも注文が発生しない取引先がほとんどで、再送が必要だったのは2社・合計14件の注文でした。受信したデータは、社内の基幹システム（IBM iSeries上のRPG/COBOLバッチ）に従来通りCSVで受け渡し、出荷業務に影響を出さずに繋ぎ込めました。
相手先のセキュリティポリシー上、「IPアドレスを固定したい」「FQDNは事前申請したものに限る」という制約があったため、ElasticIPを取得し、社内のDNSにも事前にCNAMEを通しておきました。これがないと、AS2のTLSハンドシェイクで相手側のホワイトリストに弾かれます。
## 結果と効果
朝9時の朝礼時点でEDI受信が3社復旧、午前11時20分に全社復旧。出荷遅延は発生しませんでした。
副次的な効果として、長年「触れない聖域」だったWindows Server 2008 R2が完全に退役。新環境はLinux上のOSS構成で、月額運用費は従来の17万円（OS保守延長・EDI製品保守・ハード保守の合計）から3万8千円へ。年間で約158万円のコスト削減となりました。
EDI設定はAnsibleでコード化し、Git管理に移行。証明書の有効期限はLambdaで自動監視し、期限60日前にSlack通知が飛ぶ仕組みも組み込みました。20年前の「秘伝のスクリプト」が、再現可能なインフラに置き換わっています。
## 学び・他のお客様への提言
この事例から取るべき教訓は3つに集約されます。
第一に、EDIサーバこそ可用性の盲点になりがちです。普段は淡々と動いているため、誰も触らず、誰もリストアを検証しません。社内の基幹システムよりも壊れた時のインパクトは大きいのに、保守予算は付きません。年に一度はリストア検証を実施するべきです。
第二に、レガシーEDIプロトコルは取引先が変わらない限り温存される傾向にあります。しかし、AS2／OFTP2など標準化されたプロトコルへの移行を、5年スパンで取引先と握っておくと、いざという時に動きやすくなります。今回も、JX手順がもし生きていたら、24時間での復旧は不可能でした。
第三に、緊急時の判断軸は「元に戻す」より「業務を回す」を優先することです。20年動いてきたサーバを完全復旧しようとすると数日かかります。業務影響をゼロに抑えるには、迂回路を立てる方が早い場合が多い。経営層への説明も、「復旧の最短ルートは作り直しでした」と素直に伝えた方が、その後のIT予算も付きやすくなります。