DXは正義のように語られやすい。
紙を減らす。情報をつなぐ。受注や出荷を効率化する。見える化を進める。どれも間違っていない。
だが、便利になればなるほど、止まった時の被害は大きくなる。
アサヒグループが2025年9月に公表したサイバー攻撃によるシステム障害は、その現実をかなりわかりやすく見せた事例だ。受注・出荷、コールセンター、外部メール受信など、業務の中枢に近い領域にまで影響が及んだ。後の公表では、ランサムウェア攻撃だったこと、手作業による受注対応や段階的な出荷再開、調査結果として侵入経路や一部データ流出の確認まで明らかにされている。
この件から見えるのは、単なる「セキュリティは大事」という話ではない。
本当に重いのは、DXを進めるなら、便利さと同じ熱量で“止まった時の設計”までやらないと危ないということだ。
DXが進んだ会社ほど、止まった時の被害は広がる
昔の業務は非効率だった。
だが逆に言えば、分断されていた。ひとつの仕組みが落ちても、全部が同時に止まるとは限らなかった。
今は違う。
受注、出荷、在庫、問い合わせ、物流、工場、経理、社内連携がつながっている。平時にはこれが強みになる。処理は速くなり、転記は減り、管理もしやすくなる。だが有事には、その“つながり”がそのまま弱点にもなる。アサヒグループも、国内の受注・出荷業務停止だけでなく、外部メール受信停止や決算発表延期まで公表しており、システム障害が事業全体へ波及したことがわかる。
つまりDXは、便利さの話であると同時に、依存度を高める話でもある。
ここを見落とすと、導入時は拍手されても、障害時に一気に詰む。
多くの会社は「攻めのDX」は好きだが、「止まった時の設計」は後回しにしがちだ
DXの話になると、会社は前向きな言葉を好む。
効率化、可視化、自動化、データ活用、省人化。これらはたしかに大事だ。
だが、それと同じくらい大事なものが後回しにされやすい。
たとえば、システム停止時にどこまで手作業へ戻せるのか。誰が代替運用の判断をするのか。どの業務を最優先で守るのか。バックアップは本当に復元できる状態なのか。権限管理や監視は十分か。ネットワーク分離は機能しているのか。こうした話は地味で、導入効果の資料では目立たない。だが、実際に会社を守るのはむしろこちらだ。
アサヒグループが2026年2月に公表した再発防止策でも、ゼロトラスト移行の推進、EDR拡充、24時間監視体制、バックアップ運用強化、CSIRTを含むガバナンス体制の強化が挙げられている。IPAも、組織向けの脅威解説で、インシデント対応体制の整備、適切なバックアップ、サーバー・クライアント・ネットワークへの対策を重要事項として示している。つまり、DXの土台には最初から“守りの設計”が必要だということだ。
現場で本当に必要なのは「止まらないDX」ではなく「止まっても回るDX」だ
理想を言えば、システムは止まらないほうがいい。
だが現実には、絶対に止まらない仕組みはない。障害もある。誤操作もある。サイバー攻撃もある。想定外も起きる。
だから大事なのは、「止まらないこと」だけを前提に設計することではない。
止まっても、どこまで業務を維持できるかまで考えておくことだ。
現場目線で見るべきなのは、もっと泥臭いところだ。
受注が止まったら誰がどう拾うのか。出荷システムが落ちたら何を代替帳票にするのか。問い合わせ窓口が止まったら何を優先して復旧するのか。工場に影響が及んだら、何を止めて何を守るのか。アサヒグループも障害発生後、手作業による受注を進めながら順次出荷を再開し、物流関連システムの再開や配送リードタイムの通常化まで段階的に復旧を進めたと説明している。これは、現実の業務では“完全停止か完全復旧か”の二択ではなく、代替運用をつなぎながら戻していく発想が重要だと示している。
キラキラした未来図より、トラブル時でも最低限回る設計のほうが、現場でははるかに価値がある。
「システム化すれば強くなる」は半分しか正しくない
システム化そのものは悪ではない。
むしろ必要だ。紙だらけの運用、属人化、転記ミス、情報分断を減らすにはDXは不可欠だ。
問題は、システム化しただけで会社が強くなった気になることだ。
本当は逆で、システム化した会社ほど、守りまで作り込まないと弱い。便利になったぶんだけ障害時の影響範囲は広がり、データがつながったぶんだけ一箇所の侵害が全体へ波及しやすくなり、自動化したぶんだけ人が手で戻せない業務も増える。
だからDXは、導入して終わりではない。
運用して、守って、復旧できて、初めて完成する。
製造業や現場系の会社ほど、この視点は重い
この話はIT企業だけの話ではない。
むしろ製造業、物流、食品、化学、医薬のように“現物”を動かす会社ほど重い。
なぜなら、システム障害がそのまま供給停止や現場混乱につながるからだ。
受注が止まる。出荷が詰まる。問い合わせが集中する。現場判断が増える。復旧までのあいだ、誰かが泥臭く埋める。アサヒグループでも、商品の供給を最優先業務と位置づけて手作業対応を続け、物流正常化まで時間を要したと説明している。
この時に必要なのは、最新のIT用語を知っている人だけではない。
実際の業務フローを理解し、どこが止まると何が詰むのかをわかっている人だ。DX担当に必要なのは、ツール知識だけではなく、業務理解と有事を前提にした設計思想だと思う。
まとめ｜DXを進めるなら、「便利さ」だけでなく「止まった時」まで設計すべきだ
アサヒビールのランサムウェア被害は、DXが悪いことを示した事例ではない。
むしろ逆だ。DXが本気で業務に入り込んだ会社ほど、守りの設計までやらないと危ない。その現実を見せた事例だ。
DXを進める時、どうしても「速くなる」「楽になる」「見える化できる」といった話に目が向きやすい。
だが、本当に強い会社はそこで終わらない。
止まったらどうするか。
どこまで手で戻せるか。
何を最優先で守るか。
復旧までどうつなぐか。
そこまで考えて、初めて実務で使えるDXになる。
便利さを入れるなら、止まった時の設計もセットで入れるべきだ。
それがないDXは、平時には賢く見えても、有事には脆い。
