新菱冷熱工業が、2026年10月17日に確認した不正アクセスの原因がランサムウェア攻撃だったと公表しました(10月28日の第2報)。影響を受けたのは、同社が顧客向けに提供しているエネルギーマネジメントサービス「SEMS」で、被害を受けた一部サービスの復旧時期は「現時点では明示できない」とされています。この記事では公表された事実を整理したうえで、顧客向けにサービスを提供している会社がランサムウェア被害を受けたとき、利用する側と、サービスやシステムを作り運用する開発会社は何に備えておくべきかを、システム開発会社の代表として考えます。
要点 (事実のみ)
- 新菱冷熱工業は2026年10月28日、「【第２報】サイバー攻撃によるシステム障害発生について」を公表した。第1報は10月21日。
- 10月17日、第三者による不正アクセスにより、同社が提供する一部サービスに影響が出ていることを確認した。原因は第三者によるランサムウェア攻撃と判明しており、侵入経路は外部の専門機関と連携して調査中。
- 影響範囲は、エネルギーマネジメントサービス「SEMS」の利用者および取引先。対象者には個別に案内しているとしている。
- 対応状況として、不正アクセスを受けた機器に接続されたネットワークの遮断(完了)、感染状況と侵入経路の調査(対応中)、管轄警察署・情報処理推進機構等への報告(完了)、「本件の影響範囲についてPHPは使用していないことの調査と確認」(完了)が挙げられている。
- 個人情報や顧客データの外部流出は、現時点で確認されていない。被害を受けた一部サービスの復旧時期は現時点で明示できず、復旧状況は対象者へ個別に連絡するとしている。
徐 聖博の見解
社内システムではなく「顧客向けサービス」が止まったことの重さ
侵入経路が調査中の段階で、どこに落ち度があったかを論じるつもりはありません。私が注目しているのは、止まったのが社内の業務システムではなく、顧客に提供しているサービスだという点です。
社内システムが止まれば、困るのは基本的に自社です。しかし顧客向けのサービスが止まると、影響は利用者側の業務に直接及びます。エネルギーマネジメントのように、利用者の設備運用に関わる種類のサービスであれば、なおさらです。しかも復旧時期は「明示できない」。これは隠しているというより、ランサムウェアからの復旧では、感染範囲と侵入経路の調査が終わるまで、安全に戻せる時期を約束できないのが普通だからだと読みました。
ここから言えるのは、利用する側が「止まったら数日で戻るだろう」という前提で運用を組むのは危ういということです。外部サービスに業務を預けるなら、復旧時期が読めない期間をどう過ごすかを、契約前に一度は考えておく必要があります。
「PHPは使用していない」と言い切れることの価値
もう一つ、作る側として目を引いたのが、対応状況の中にある「本件の影響範囲についてPHPは使用していないことの調査と確認」という一行です。この記載が何をきっかけに加えられたのかは発表文に書かれていません。ただ私は、利用者や取引先から「この件は、話題になっている脆弱性と関係があるのか」と問われることを見越して、先に答えたものだと受け取りました。
この一行は、簡単に書けるものではありません。「使っていない」と言い切るには、影響範囲にあるシステムが、どの言語・ミドルウェア・ライブラリで構成されているかを一覧で持っている必要があります。台帳が無ければ、各担当者に聞いて回ることになり、事故対応の最中にその時間はありません。
インシデントが起きたとき、利用者が知りたいのは「原因の全容」よりも先に、「自分たちに関係あるのか」「何を止めればいいのか」です。構成要素を即答できることは、それ自体が顧客への説明能力になると私は考えています。
開発会社の事業判断にどう効くか
開発会社にとって、この件は二つの面で他人事ではありません。
一つは、開発会社自身が顧客向けサービスの「運用者」になっている場合です。受託で作ったシステムの保守・運用を引き受けていたり、自社のSaaSを顧客に提供していたりすれば、ランサムウェアの被害は自社の障害であると同時に、顧客の業務停止になります。そのとき問われるのは、復旧の早さだけではありません。
- 復旧時期が読めない間の連絡の約束。 「復旧したら連絡します」ではなく、何日ごとに何を報告するかを、保守契約やSLAの段階で決めておく。
- サービスが止まっている間の代替手段。 顧客が自分のデータを手元に持っておける出力機能や、最低限の業務を手作業で回すための手順を、設計段階で用意しておく。
- ネットワークを遮断してよい範囲と、その判断者。 新菱冷熱工業も被害拡大防止のためにネットワークを遮断していますが、どこまで切るかを事故の最中に初めて議論するのでは遅い。
もう一つは、作る側としての話です。システムを納品するとき、使っている言語・フレームワーク・主要ライブラリとそのバージョンの一覧を、納品物として顧客に渡し、保守の中で更新し続けることを提案すべきだと考えています。EPICS Baseの脆弱性を取り上げた記事でも書いたとおり、OSSを組み込んで納品する以上、脆弱性が出たときに「該当するか」を答える責任は作った側に残ります。この一覧は見積もりに乗りにくい作業ですが、話題の脆弱性が出るたびに顧客から届く「うちは大丈夫か」という問い合わせに、その日のうちに答えられるかどうかを分けます。セキュリティを気にする発注側は、事故が起きる前の段階で、こうした準備ができている会社かどうかを見ていると私は考えています。
なお、ネットワーク遮断後に何を動かし続けるかという設計の論点は、Fairlifeの生産停止を取り上げた記事で詳しく整理しました。
まとめ
新菱冷熱工業の件は、侵入経路も被害範囲もまだ調査中で、復旧時期も示されていません。ただ、顧客向けサービスがランサムウェアで止まったという事実だけで、備えるべきことははっきりしています。利用する側は、復旧時期が読めない期間をどう過ごすかを契約前に考えておくこと。作り運用する開発会社は、構成要素を即答できる台帳と、止まっている間の連絡・代替手段を、事故の前に用意しておくことです。
関連して読んでいただきたい記事:
