ERPや基幹システムのトラブルというと、システム開発の失敗、データ移行の不備、プログラム障害などを想像する方が多いかもしれません。
しかし、企業の基幹システムを止める原因は、それだけではありません。
システムそのものが正常であっても、データセンターへ接続する通信回線が使えなくなれば、企業は基幹システムへアクセスできなくなる可能性があります。
2026年5月、このリスクを改めて考えさせる事例が発生しました。
舞台となったのは、複合機やプリンター、ITサービス、デジタルサービスなどを国内で展開するリコージャパンです。
2026年5月13日深夜、リコージャパンの社内基幹システムに障害が発生し、一部の業務システムが利用できない状態となりました。
原因として会社が公表したのは、社内基幹システムのデータセンターとの通信設備における「回線の破損」という物理的理由でした。
今回のERP障害の影響により、5月13日に注文されたサプライ品や機器関連商品の一部で、通常より納品が遅れる事態も発生しました。
一方、リコージャパンは原因となった通信設備を交換し、翌5月14日早朝にはシステムの復旧を完了しています。
今回の事例は、長期間にわたる大規模なERP導入失敗ではありません。
しかし、だからこそ企業のIT担当者やDX担当者にとって重要な示唆があります。
基幹システムの安定稼働を考える際には、ERPやサーバーだけでなく、それを利用するための通信回線、データセンター接続、ネットワーク機器、障害時の代替経路まで含めて考えなければならないということです。
この記事では、リコージャパンの公式発表をもとに、基幹システム障害の発生から復旧までを時系列で整理し、ERP・基幹システムのBCPという観点から企業が確認すべきポイントを考察します。
リコージャパンとはどのような会社か
まず、リコージャパンは、リコーグループの国内販売会社です。
皆さまのお馴染みの複合機やプリンターなどの販売だけでなく、企業のIT環境、業務効率化、デジタルサービス、DX支援など幅広いサービスを展開しています。
つまり、ITやDXを顧客に提供する企業自身で発生した基幹システム障害という点でも、非常に興味深い事例です。
もちろん、ITサービスを提供する企業だからシステム障害が発生しないということではありません。
どれだけITに精通した企業であっても、物理的な通信設備の故障や損傷によって業務システムが利用できなくなる可能性があります。
2026年5月13日、リコージャパンの基幹システムに障害
リコージャパンによると、障害が発生したのは2026年5月13日の深夜です。
社内基幹システムに障害が発生し、システムへのアクセスができない状態となりました。
企業の基幹システムは、販売、受注、在庫、出荷、請求、会計、顧客管理など、さまざまな業務を支えています。
そのため、基幹システムへアクセスできなくなると、単に「パソコンの画面が開かない」という問題では済みません。
- 受注情報を確認できない
- 商品の在庫状況を確認できない
- 出荷処理を進められない
- 顧客から問い合わせを受けても必要な情報を確認できない
こうした形で、企業の日常業務そのものに影響が波及する可能性があります。
実際、リコージャパンでは5月13日に注文された商品の一部で、通常より納期が遅れる事態が発生しました。
リコージャパンERP障害の原因は「データセンターとの通信回線の破損」
今回のリコージャパンの障害で特に注目すべきなのが、その原因です。
会社側は、障害の原因について、「社内基幹システムのデータセンターとの通信設備における回線の破損」と説明しています。
つまり、ERPや業務アプリケーションそのものに重大な不具合が発生したと公表されているわけではありません。
基幹システムへ接続するための通信設備側で問題が発生しました。
ここは、ERP・基幹システムのリスク管理を考えるうえで非常に重要です。
企業はERPや基幹システムを導入する際、システムの機能やサーバー性能、データバックアップなどには多くの時間と費用をかけます。
しかし、基幹システムへアクセスするためには、物理的なネットワークも正常に機能していなければなりません。
どれだけ高性能なERPが正常に稼働していても、システムへ到達する通信経路が使えなければ、利用者から見れば「基幹システムが止まった」のと同じ状態になります。
ERP導入・基幹システム刷新で
お困りではありませんか？
現場混乱、要件整理不足、ベンダー任せの不安、運用定着の課題まで、実務を理解したメンバーが現状整理から伴走します。まずは現在の課題をお聞かせください。
無料相談するリコージャパンERPサイバー攻撃や不正アクセスではなかった
今回の障害について、リコージャパンはセキュリティ面についても明確に説明しています。
障害は通信設備の物理的損傷によるものであり、不正アクセスやサイバー攻撃によるものではないとしています。
近年、企業の基幹システム停止というニュースを見ると、ランサムウェアやサイバー攻撃を想像するケースが増えています。
しかし、システム停止の原因はサイバー攻撃だけではありません。
- サーバー機器の故障
- ストレージ障害
- ネットワーク機器の故障
- 通信回線の断線・破損
- 電源設備の障害
- データセンター障害
- 設定変更ミス
- ソフトウェア障害
など、さまざまな要因があります。
そのため企業のBCPでは、サイバーセキュリティだけでなく、物理インフラを含めたシステム全体の可用性を考える必要があります。
リコージャパンERP基幹システム障害から復旧までの時系列
今回の障害は、発生から翌朝の復旧まで比較的短期間で対応されています。
公開情報をもとに、時系列で整理します。
2026年5月13日深夜：基幹システム障害が発生
リコージャパンの社内基幹システムに障害が発生しました。
一部業務システムが利用できず、基幹システムへアクセスできない状態となりました。
2026年5月13日：業務への影響が発生
障害の影響によって、5月13日に注文されたサプライ品や機器関連商品の一部で、通常より納品が遅れる状態となりました。
また同日、リコージャパンはコール受付システムの障害によって、テクニカルコールセンターへの電話がつながりにくくなっていることも案内しています。
ただし、このコール受付システムの障害と今回の基幹システム障害が技術的に同一原因だったかについて、公開情報では明確にされていません。
通信設備の交換作業を実施
原因となった通信設備について、リコージャパンは交換作業を実施しました。
その後、各システムについて順次復旧作業を進めました。
2026年5月14日早朝：システム復旧
翌5月14日早朝、社内基幹システムの復旧が完了しました。
つまり、システム障害自体はおおむね1日以内に復旧したことになります。
ただし、システムが復旧したからといって、すべての業務影響が瞬時になくなるわけではありません。
5月13日に受け付けた商品の一部では、復旧後も通常より納品が遅れる状態が残りました。
システムが復旧しても「業務」はすぐには元に戻らない
今回の事例でもう一つ重要なのが、この点です。
基幹システムは5月14日早朝に復旧しています。
しかし、5月13日に受注した一部商品では納期遅延が残りました。
基幹システムが停止している間にも、企業活動は続いています。
顧客から注文が入り、問い合わせも発生し、商品を出荷する必要があります。
つまり、障害発生中に処理できなかった仕事が「滞留」していきます。
システムが復旧した後は、その滞留した処理を通常業務と並行して処理しなければなりません。
基幹システム障害では、「システム復旧時間」だけではなく、「業務が正常化するまでの時間」を見ることが重要です。
リコージャパンERP障害は導入時の失敗ではない
ここは記事として明確にしておきたいポイントです。
今回のリコージャパンの事例について、公開情報から「ERP導入に失敗した」「データ移行で問題が起きた」などと判断することはできません。
会社が公表している原因は、あくまでデータセンターとの通信設備における回線の物理的損傷です。
したがって、他の有名企業である、江崎グリコや関西ペイント、安川電機などで起きた、基幹システムの移行・刷新直後に業務影響が発生したケースとは性質が異なります。
一方で、ERPを含む企業の基幹システムを安定して運用するという観点では、非常に重要な事例です。
ERP導入プロジェクトでは、システム構築やデータ移行が注目されがちですが、導入後に何年間も安定して使い続けられるインフラ設計も同じくらい重要だからです。
ERP・基幹システム刷新そのもののリスクについては、「グリコERP失敗はなぜ起きたのか。江崎グリコの基幹システム障害から学ぶSAP S/4HANA導入リスク」でも詳しく解説しています。
公開情報だけでは分からないリコージャパンERP基幹システムの重要なポイント
今回のリコージャパンの発表は、障害原因と復旧状況について比較的明確です。
一方、公開情報だけでは分からない部分もあります。
- 通信回線は何系統で構成されていたのか
- 予備回線は存在していたのか
- 回線が破損した際に自動切り替えが行われたのか
- 通信設備のどの部分が物理的に破損したのか
- バックアップ経路が存在した場合、なぜ業務影響が発生したのか
- 障害時にどの業務を手作業で継続できたのか
これらの詳細については、今回確認できる公開資料では説明されていません。
そのため、「冗長化されていなかった」「ネットワーク設計に問題があった」と外部から断定することは適切ではありません。
しかし、ERPや基幹システムを運用する企業側にとっては、こうした項目を自社環境で確認することに大きな意味があります。
基幹システムで重要な「単一障害点」とは
システムの可用性を考える際に重要な概念が「単一障害点」です。
英語ではSingle Point of Failure、略してSPOFと呼ばれます。
これは、一つの設備や機器が故障しただけで、システム全体が利用できなくなるポイントを意味します。
たとえばサーバーを2台にして冗長化していても、そのサーバーへ接続するネットワーク回線が1系統しかなければ、回線障害によって両方のサーバーへアクセスできなくなる可能性があります。
逆に通信回線が二重化されていても、両方の回線が同じ通信設備、同じ配管、同じ電源設備などを共有していれば、共通部分の障害によって同時に利用できなくなる可能性があります。
「二重化されていること」と「障害に強いこと」は、必ずしも同じではありません。
重要なのは、どこまで独立した経路になっているのかということです。
ERP・基幹システムで確認すべき7つのBCP対策
リコージャパンの事例を踏まえると、ERPや基幹システムを運用する企業は、少なくとも次の7点を確認しておく必要があります。
1. データセンターへの通信経路は本当に冗長化されているか
回線が2本あるだけで安心するのではなく、実際に異なる設備や経路を利用しているか確認することが重要です。
2. 冗長回線への切り替えを実際にテストしているか
設計書上で冗長化されていても、本当に切り替わるかは別問題です。
定期的にフェイルオーバーテストを実施し、主回線が利用できなくなった場合でも業務を継続できるか確認する必要があります。
3. ネットワーク機器も単一障害点になっていないか
ルーター、スイッチ、ファイアウォール、ロードバランサーなど、基幹システムへ接続する途中の機器についても確認が必要です。
4. 基幹システムへアクセスできない場合の代替運用があるか
システム障害を完全にゼロにすることは難しいため、「止めない設計」だけでなく「止まった場合でも業務を続ける設計」が必要です。
たとえば、受注情報を一時的にExcelや紙で管理する、優先顧客だけでも手作業で出荷する、納期回答用のバックアップデータを準備するなどの方法があります。
5. 復旧後の「滞留処理」まで計画しているか
システムが復旧しただけでは業務は正常化しません。
障害中に蓄積した受注、出荷、請求、問い合わせなどをどの順番で処理するか、事前に決めておくことが重要です。
6. 障害時の顧客連絡ルートを準備しているか
障害状況、復旧見込み、納期影響などを誰が判断し、どのチャネルで顧客へ説明するかを決めておく必要があります。
7. インフラ障害もERPプロジェクトのリスクとして扱っているか
ERP導入時には、要件定義、Fit to Standard、データ移行、テストなどに注目が集まります。
しかし、実際にシステムを長期間利用するためには、ネットワーク、データセンター、クラウド、認証基盤、電源なども含めて確認する必要があります。
ERPは単独で存在するシステムではなく、複数のITインフラの上で動く経営基盤です。
ERP導入・基幹システム刷新で
お困りではありませんか？
現場混乱、要件整理不足、ベンダー任せの不安、運用定着の課題まで、実務を理解したメンバーが現状整理から伴走します。まずは現在の課題をお聞かせください。
無料相談する江崎グリコ・安川電機との違いから見える基幹システムリスク
基幹システムが事業へ影響する理由は、一つではありません。
江崎グリコでは、2024年の基幹システム切り替え後に障害が発生し、チルド商品の出荷が長期間停止しました。
詳しくは「グリコERP失敗はなぜ起きたのか」で解説しています。
安川電機では、SAP S/4HANAへの移行後、システム自体はほぼ安定稼働していたものの、業務運用の変更により生産稼働率が低下しました。
「安川電機の基幹システムトラブルで生産影響。製造業が学ぶべきこと」で詳しく整理しています。
ユニ・チャームでは、基幹システム刷新後の物流・納品への影響が確認されています。
「ユニ・チャーム基幹システム障害はなぜ起きたのか？ERP更新で納期遅れ」で詳しく解説しています。
これに対してリコージャパンでは、公開情報上の原因は通信設備における物理的な回線破損です。
つまり、基幹システムが止まる原因には、システム移行、業務設計、データ連携、運用定着、ソフトウェア障害、ハードウェア障害、通信回線障害、サイバー攻撃など、さまざまなパターンが存在します。
ERP導入・刷新では「稼働後」まで考える必要がある
ERPプロジェクトでは、どうしても本番稼働日に意識が集中します。
要件定義、開発、データ移行、テストを終え、予定日に本番稼働できれば、プロジェクトは成功したように見えるかもしれません。
しかし、ERPや基幹システムは、稼働後10年、20年と企業活動を支える場合があります。
本当に重要なのは「本番稼働できたか」ではなく、「その後も事業を止めずに運用し続けられるか」です。
この意味では、ERP導入は開発プロジェクトであると同時に、長期間にわたる運用設計のプロジェクトでもあります。
また、ベンダーへシステム構築を丸投げするだけでは、業務・インフラ・運用まで含めたリスクを十分に管理できない場合があります。
この点については「なぜERP導入・刷新は「丸投げ」で失敗するのか？」でも詳しく解説しています。
基幹システム障害時に経営層が確認すべきこと
基幹システムに重大な障害が発生した場合、IT部門だけに対応を任せてはいけません。
事業への影響が一定規模を超えた時点で、経営課題になります。
- どの業務が停止しているのか
- 受注・出荷・請求への影響はいくらか
- 重要顧客への供給は継続できるか
- 手作業で継続できる業務はあるか
- 障害中のデータを後から正しく反映できるか
- 顧客への説明は行われているか
- 復旧後、何件の処理が滞留するのか
- 同じ障害が再発する可能性はあるか
基幹システム障害は、ITの問題であると同時に、売上、物流、顧客対応、企業信用に関わる経営問題です。
ERP導入・基幹システム刷新で
お困りではありませんか？
現場混乱、要件整理不足、ベンダー任せの不安、運用定着の課題まで、実務を理解したメンバーが現状整理から伴走します。まずは現在の課題をお聞かせください。
無料相談するまとめ。リコージャパンの基幹システム障害から何を学ぶべきか
2026年5月13日深夜、リコージャパンの社内基幹システムで障害が発生しました。
システムへアクセスできない状態となり、5月13日に注文されたサプライ品・機器関連商品の一部では納期遅延が発生しました。
原因は、データセンターとの通信設備における回線の物理的損傷でした。
原因となった通信設備を交換し、翌5月14日早朝にはシステムが復旧しています。
今回の障害はサイバー攻撃ではなく、ERP導入失敗と公表された事例でもありません。
しかし、ERP・基幹システムを運用するすべての企業にとって重要な教訓があります。
システムの可用性は、ERPやサーバーだけで決まるものではありません。
通信回線、ネットワーク機器、データセンター、電源、クラウド、認証基盤、そして障害発生時の代替運用。
こうした要素がすべてつながって初めて、企業の基幹業務は継続できます。
また、システムが復旧しても、障害中に滞留した受注や出荷処理が残れば、顧客への影響は続きます。
ERP・基幹システムのBCPでは「何時間でシステムを復旧するか」だけではなく、「何時間で業務を正常な状態へ戻せるか」まで考える必要があります。
リコージャパンの事例は、基幹システムの安定運用を考えるうえで、非常に分かりやすい国内事例の一つと言えるでしょう。
ERP導入・基幹システム刷新に不安がある方へ
ERPや基幹システム刷新では、ベンダー選定、要件定義、データ移行、テストだけではなく、本番稼働後の運用、障害対応、BCPまで含めて考える必要があります。
特に、ERPのインフラ構成を発注側が十分理解できていない、障害発生時の代替運用が決まっていない、データセンターやクラウド障害時の対応方法が分からないといった企業は注意が必要です。
こうした場合には、プロジェクトや運用体制を第三者の視点から一度整理することも有効です。
ERP導入・基幹システム刷新で
お困りではありませんか？
現場混乱、要件整理不足、ベンダー任せの不安、運用定着の課題まで、実務を理解したメンバーが現状整理から伴走します。まずは現在の課題をお聞かせください。
無料相談する関連記事
- 安川電機の基幹システムトラブルで生産影響。製造業が学ぶべきこと
- ユニ・チャーム基幹システム障害はなぜ起きたのか？ERP更新で納期遅れ。
- グリコERP失敗はなぜ起きたのか。江崎グリコの基幹システム障害から学ぶSAP S/4HANA導入リスク
- 関西ペイントERPトラブルの理由を考察！基幹システム刷新のリスク
- なぜERP導入・刷新は「丸投げ」で失敗するのか？
参考情報・出典
本記事は、リコージャパンが公表した情報および公開情報をもとに、ERP・基幹システム運用およびBCPの観点から整理・考察したものです。公開されていないシステム構成や障害原因、責任の所在を断定するものではありません。