アスクル障害に見るERP統合の落とし穴──「全社最適」が「全社停止」になる瞬間

2025年10月、アスクルがサイバー攻撃を受けてシステム障害を起こし、同社に物流を委託していた無印良品やロフトの通販サイトが停止しました。単一企業の障害が、取引先企業の業務にまで連鎖的に影響を及ぼすという構造的リスクが明らかになった事例です。背景には、業務効率化を目的に進められてきた「ERP（統合基幹業務システム）」の一元化があります。

本コラムでは、ERP統合が引き起こす潜在的リスクと、障害を最小化するための“分散制御設計”の重要性について解説します。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら

【記事要約】3PLを支える統合基幹業務システム（ERP）に潜むリスク──サイバー攻撃が物流全体を止める時代へ

アスクルへのサイバー攻撃により、同社のEC事業だけでなく、物流を委託する無印良品やロフトなど複数企業の通販サイトが停止した。背景には、3PL（サード・パーティー・ロジスティクス）の普及と、効率化を目的とした統合基幹業務システム（ERP）の導入拡大がある。複数企業や拠点がERPで密接に連携する構造は、一度障害が発生するとサプライチェーン全体に波及するリスクを高める。実際、アサヒグループHDの障害でも共同配送の他社へ影響が及んだ。今後の3PLでは、ERPの分散設計やゼロトラストを前提としたシステム構築、BCP（事業継続計画）体制の再設計が急務となる。

出典：日本経済新聞「サイバー被害リスク連鎖アスクル障害、物流受託に飛び火　『無印』・ロフトEC停止」2025年10月21日付朝刊

ERP統合がもたらす「効率化」と「集中リスク」

多くの企業がERP統合を進める理由は明確です。会計・人事・販売・在庫などの基幹業務を一つのシステム上で管理することで、情報の一元化と業務効率化が実現できるためです。特にグループ企業や複数拠点を抱える大手企業にとって、データのリアルタイム共有や経営判断のスピード化は大きな魅力です。

しかし、その一方で見過ごされがちなのが「集中リスク」です。業務システムを単一のプラットフォームに統合するということは、裏を返せば“ひとつの障害で全社が止まる”構造を作り出しているということです。実際に、アスクルの障害では自社だけでなく物流委託先の複数企業にまで影響が広がり、サプライチェーン全体が一時的に機能不全に陥りました。ERP統合による効率化は、システム停止リスクの波及範囲を拡大させる側面を持っています。

「コスト削減」がもたらす見えない代償

ERP統合の目的としてよく挙げられるのが「コスト削減」です。複数の部門や子会社がバラバラに運用していたシステムを一元化することで、ライセンス料・運用費・保守要員などのコストを圧縮できると考えられています。また、ソフトウェア更新やセキュリティ対応を統一することで、管理の手間も減るように見えます。

しかし、この“コスト削減”の裏には、柔軟性の喪失という重大なデメリットが潜んでいます。システム統合によって部門ごとの特性や業務ルールが吸収されると、障害発生時に一部だけ切り離して運用を続けることが難しくなります。結果として、システム全体が停止し、業務継続が不可能になるケースが増えているのです。効率化とコスト削減を優先しすぎると、最悪の場合、「全社最適」が「全社停止」に転じるリスクを孕みます。

サイバー攻撃時代における「統合」の危うさ

かつては内部障害やサーバートラブルが主な停止要因でしたが、近年ではサイバー攻撃が企業システムの最大の脅威となっています。特にランサムウェアによる攻撃は、業務データを人質に金銭を要求する悪質な手口で、被害を受けた企業はシステムの一時停止を余儀なくされます。ERP統合が進んだ環境では、ひとつのシステムが侵入を許した瞬間に、全社のデータや外部連携先にまで被害が波及するリスクが高まります。

サプライチェーンでのシステム連携が一般化している今、サイバー攻撃による“連鎖被害”は決して他人事ではありません。特に、複数企業が共通の基幹システムを共有している場合、どこか一社が被害を受ければ、連携企業の業務も同時に停止する恐れがあります。効率化と集中管理を追求した結果、攻撃者にとって「狙えば全体を止められる」構造を自ら作ってしまっているのです。

ERP統合の「盲点」──止まらないシステムの設計思想

ERP統合は、単に「まとめる」ことが目的ではありません。真に目指すべきは、止まらない業務基盤をどう設計するかです。たとえシステムを統合しても、障害発生時に部分停止・局所復旧できる構造を備えていなければ、本質的なリスクは解決されません。

そこで重要になるのが、“分散制御設計”という考え方です。これは、機能ごとに独立した構造を持ちながらも、必要な情報は連携できるように設計するアプローチです。例えば、販売・在庫・会計をすべて単一のERPに統合するのではなく、それぞれのドメインで独立稼働し、APIやデータレイクを通じて連携する仕組みを構築します。これにより、どれか一つの機能が停止しても、他のシステムが最低限動作を維持できる環境を実現できます。

フルスクラッチ開発で実現する「柔軟な統合」

既製のERPパッケージをそのまま導入すると、業務の自由度が制限されるだけでなく、障害時の対応オプションも限られます。その点、フルスクラッチ開発によるシステム構築は、企業ごとの業務構造やリスク許容度に合わせた設計が可能です。「すべてを統合しない統合」──すなわち、必要な部分だけを連携し、制御を分ける柔軟な設計を選択できるのです。

フルスクラッチ開発の強みは、単なるカスタマイズ性にとどまりません。障害やセキュリティインシデントが発生した際に、影響範囲を局所化しやすいという点でも優れています。また、システムを段階的にリプレイスしながら進化させる「モジュール設計」も可能で、長期的な運用コストの抑制にもつながります。

「統合」から「統御」へ──システム戦略の再設計を

これまでのERP戦略は「全社最適化」の名のもとに統合を進めてきました。しかし、業務が複雑化し、外部とのデータ連携が増えた今、求められるのは“統合”よりも“統御”です。つまり、全体を一元化することではなく、全体を制御できる設計に変えることが重要です。

統合を進めるほどリスクが増す時代において、システムをどのように守り、どう再構築するかは、経営判断の核心になります。そのためには、ERPを単なる業務効率化ツールとしてではなく、事業継続性を担保するインフラとして再定義する必要があります。システム統合の目的を「効率」から「持続可能性」へとシフトすることが、これからの企業の生存戦略といえるでしょう。

まとめ

ERP統合は、確かに業務効率化やコスト削減をもたらします。しかし、同時に“全社停止”というリスクも抱える諸刃の剣です。特にサイバー攻撃や障害が企業活動に直結する今、単一のシステムに依存する構造は危険です。フルスクラッチによる分散制御設計を検討する際に重要なのは、単なる技術選定ではなく「自社の業務に本当に合う仕組み」を構想できるパートナーを選ぶことです。

フレシット株式会社は、既存業務の整理から要件定義、システム構築、運用までを一貫して支援し、企業の実情に即した“止まらない業務システム”をフルスクラッチで設計します。テンプレートに業務を合わせるのではなく、業務のあり方にシステムを合わせる。その思想こそが、将来の変化にも強い真の全社最適を実現する道です。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら