午前2時、1本のアラートから始まった　～IBM iユーザー、松沢書店が経験した、ランサムウェア被害から復旧までの取り組みと教訓

ランサムウェアと判明、
それでもすぐには止められなかった　　

松沢書店でランサムウェア被害が発覚したのは、2026年5月9日（土）未明である。被害が確認されたのは、Active Directory（AD）管理サーバーをはじめとするWindows系サーバー、ファイルサーバー、一部の業務用PCなどだった。ファイルサーバーではファイルが暗号化され、感染フォルダには身代金を要求する「READ ME」ファイルも残されていた。

会社は攻撃者との接触を行わず、警察へ通報するとともに、外部のサイバーセキュリティ専門会社の支援を受けて調査と復旧に着手した。

しかし、発見直後の山口氏が最初に直面したのは、「すべてを止めるか」という判断だった。ランサムウェアだと認識したのであれば、ネットワークから切り離し、サーバーを止めればいい。後から振り返ればそう考えられる。だが、実際にはそう簡単ではなかった。

「初めての経験だったので、サーバーを全部止めるという判断がなかなかできませんでした。サーバーを止めれば、当然サービスも止まります。業務を止めるという判断は、やはり難しかったのです」

午前3時から4時ごろまで、およそ1時間にわたって判断を迷った。

「次にもし同じことが起これば、すぐにサーバーをネットワークから隔離する、あるいは止めるという判断になると思います。でも、そのときは初めてでしたから、1時間ぐらい逡巡していました」

そして午前4時ごろ、全面停止を決断した。ただし、そこからも一斉に停止できたわけではない。

「このサーバーだけはもう少し残しておこうとか、ファイルサーバーは朝になってからもう一度見たいとか、まだ甘い考えがありました。優先順位をつけながら落としていったので、全部止まったのは朝6時ぐらいだったと思います」

仮想環境で稼働していたサーバーは20数台。午前6時ごろまでにすべてを停止した。午前4時過ぎには社長へ電話し、「始発で会社へ行きます」と伝えた。社長も出社することになった。

山口氏自身、このときの判断をその後も繰り返し振り返っている。

ランサムウェアを発見したとき、「業務を止めること」と「被害を止めること」のどちらを優先するか──その判断を、現場の担当者は突然迫られたのである。

社員に「今日は会社へ来ないでください」　

午前7時ごろには社長や部長らが会社に集まり、対応を協議した。システムは全面的に停止している。出社しても通常業務はできない。そこで社員やアルバイトに「今日は会社へ出社しないでください」と連絡した。

一方、山口氏はランサムウェアと判明した午前3時ごろから、面識のあったセキュリティ会社などへ連絡を入れていた。午前10時ごろには2社ほどと連絡がつき、そのうちの1社が、土曜日にもかかわらず当日午後の緊急打ち合わせに応じた。

ここで山口氏は、自分が想像していた以上に事態が深刻であることを知る。

「サーバーを止めても、事態が落ち着いたら電源を入れ直し、攻撃によって暗号化されたファイルは別として、そのサーバー自体はまた使えるのだろうと思っていたのです」

しかし、専門家から告げられたのは、侵害された環境をそのまま信頼して再利用するのではなく、初期化して再構築する必要がある、ということだった。

「そこで、『これは3日、4日で復旧するような話ではない』とわかってきました。1週間なのか、もっとかかるのか。1週間業務が止まるだけでも大変ですから、そのあたりから関係者全員が青ざめてきました」

被害サーバーを修復して元へ戻すのではない。安全な環境を一から作り直さなければならない。復旧作業の前提が、ここで大きく変わった。

Windows環境を中心に被害、
PCにも横展開　　　

その後の調査で、被害の中心がWindows環境であることがわかってきた。山口氏によると、Windows Serverは7～8台が侵害されていた。一方、サーバー環境にはLinuxも多く、こちらへの影響は限定的だった。さらに、侵害された環境からネットワーク内部へ攻撃が横展開し、東京と大阪で当時電源が入っていた業務用PCにも被害が及んだ。感染の有無を確認したうえで、会社は最終的に業務PCを全台初期化する方針を採った。

既存のWindowsサーバー環境についても再利用せず、物理的に切り離したうえで、ファイアウォール、Active Directory、Windows Serverなどを新しい環境に再構築することになった。

ランサムウェアによる暗号化を免れた
データベースのバックアップ　　　

復旧にとって大きかったのが、バックアップデータが残っていたことである。バックアップサーバーにも侵害は進みつつあったが、早い段階でサーバーを停止したことで、データベースのダンプなど、復旧に不可欠なデータは暗号化を免れた。

「バックアップサーバーも、かなり侵害が進んでいました。ただ、早めに止めたので、データベースのダンプは無傷だったのです。これはすぐ別のところへ逃がしました。そこは本当に救われました」

山口氏は、バックアップが残ったのは「時間の問題だったと思う」と振り返る。全面停止がさらに遅れていれば、復旧に必要なデータまで失われていた可能性があった。

偶然重なった「新サーバーへの移行計画」　

もう1つ、復旧を大きく助けた偶然があった。会社では今回の被害とは関係なく、以前からサーバーのマイグレーションを計画していた。すでに新しい物理サーバーを発注済みで、機器も準備されていた。

「全部作り直さなければならないと言われて、『じゃあ、どうするんだ』となりました。でも、たまたまサーバーマイグレーションを予定していて、新しいサーバーの発注も済んでいたのです。そこで『もう前倒しで送ってください』とお願いしました。本当に奇跡的でした」

新しい物理サーバーは数日後にはデータセンターへ搬入され、復旧環境として利用された。当初予定していた「既存環境から新環境へのマイグレーション」は、意味を変えた。侵害された旧環境を引き継ぐのではなく、クリーンな環境を新たに構築し、生き残ったデータからシステムを復元する作業になったのである。

山口氏自身も仮想マシンの構築からデータ復旧までに携わった。

「ランサムウェアを食らったので、もう普通のマイグレーションではなくなりました。仮想マシンの構築からデータの復旧まで、自分でやりました」

データベースによっては、ダンプデータから戻すだけで1日を要した。リストアに3日かかるものもあった。途中で失敗すれば、やり直さなければならない。1つのサーバーを戻す。次のサーバーを戻す。さらに次のサーバーを戻す。その作業が連日続いた。

IBM i系の基幹システムは無傷　

早期の復旧を支えたもう1つの要因が、IBM i系の基幹システムが被害を受けていなかったことだった。

「IBM iが無傷だったので、基幹業務は5月12日の時点では動いていました。Web以外でEDIなどから受注している部分は、IBM iのおかげで大丈夫だったのです」

そのため、すべての業務が3週間止まり続けたわけではない。受発注・物流機能を優先し、業務を段階的に再開していった。Webサーバーなどを含めた主要システムが大枠で復旧したのは、被害発生から約3週間後の5月末だった。

「大方の復旧は5月末ぐらいです。細かい作業は6月に入っても続きましたが、大枠としてはそのころには戻っていました」

システムが戻り始めても、
担当者は戻っていなかった　　

発生から10日、2週間と時間が経つにつれて、状況は少しずつ変わっていった。

サーバーが1台、また1台と戻り始めた。山口氏自身が復旧作業を行っていたため、どこまで戻ったのかが自分でわかった。

「10日、2週間になってくると、サーバーがどんどん復旧していく。自分でやっていたので、進捗がわかるのです。そろそろ目処が見えてきた、という感覚もありました」

最初の数日間にはまったく見えなかった出口が、少しずつ見え始めていた。しかし、システムが復旧に向かっていることと、対応している人間が回復していることは別の問題だった。

山口氏は、その間、ほとんど休めていなかった。平日も休日も関係ない。復旧できるサーバーがあれば復旧する。問題が出れば調べる。データを戻す。失敗すれば、もう一度やり直す。外部の専門会社とも打ち合わせを続ける。そして翌日も、同じ作業が待っている。

「外部の会社にお願いしていると、解決できない問題が出たときに、タイミングによっては『では来週』となることがあります。しかし私は土日も関係ないので、そのまま続けることができました。そこは自分でやってよかったところでした」

それは復旧を早めた一因だった。同時に、山口氏自身を休ませない理由にもなった。

「もう1回、入られているかもしれません」　

被害発生から1週間ほど経ったころだった。復旧作業の一環として、山口氏はさまざまなシステムのパスワードを変更していた。

あるサーバーへログインしようとした。パスワードを入力する。ログインできない。もう一度入力する。やはり入れない。

「パスワードが違います」

普段であれば、入力ミスを疑ったかもしれない。しかし、そのときの山口氏には違って見えた。

──また入られたのではないか。

「その間、ずっと、ほぼほぼ寝ていないみたいな状況が続いていました。それでログインできなくて、『これはもう1回入られていないか』と思ったのです」

　ランサムウェア攻撃を受けた直後である。一度侵入されたネットワークを、一から作り直している最中だった。再び侵入されたのだとしたら、ここまで積み上げてきた復旧作業はどうなるのか。

山口氏は周囲に告げた。

「すいません、もう1回入られているかもしれません」

復旧し始めていたシステムに、再び攻撃者が侵入した可能性がある。そう考えた。そして自席に戻り、もう一度キーボードを操作した。そこで、ふと思い出した。

──そうか。パスワードを変えたのだ。

　ログインできなかった理由は、攻撃者が再侵入したからではなかった。山口氏自身がパスワードを変更していたからだった。

「そうか、パスワードは自分が変えたのだ、と気づいた瞬間のことを、今も鮮明に覚えています」

山口氏は振り返る。

「あのころが一番精神的に参っていたときではないかと思います」

システムの異常ではなかった。疲弊した人間の側で、判断の精度が落ちていたのである。

パスワードエラーが怖くなった　

“事件”が終われば、恐怖も終わる。だが、そう単純ではなかった。山口氏はその後もしばらく、「パスワードが違います」という表示に敏感になったという。セキュリティを強化すれば、当然パスワードは複雑になる。すると入力を間違えることも増える。以前なら、ただの入力ミスで済んでいた。だが、ランサムウェアを経験した後は違った。

「しばらくは怖かったですね。今はパスワードも複雑になっていますから、『パスワードが間違っています』と出ることが結構あります。そうすると、また何かあったんじゃないかと疑ってしまいます」

一度経験した侵入の記憶が、通常のエラー表示に重なる。ランサムウェア被害の影響は、サーバーやPCだけに残るものではなかった。

21日間、復旧作業を続けた　

山口氏は長期間、休みなく対応を続けた。取材では「21連勤」という言葉も出た。

病院へ行こうと思いませんでしたか、と尋ねると、山口氏は「その発想がありませんでした」と答えている。周囲からは「大丈夫ですか」と声を掛けられた。社員たちも気遣ってくれた。だが、復旧の中心にいる本人にとっては、休むという選択肢そのものが見えにくくなっていた。システム担当者が1人、あるいは少人数しかいない企業では、この問題はさらに深刻になるだろう。

1人、2人の担当者に責任が集中する　　

大企業で重大なセキュリティインシデントが起きれば、複数の専門部門や担当者が役割を分担できる。しかし、中規模以下の企業では事情が違う。山口氏の会社も、システムを担当する人数は限られていた。

「大きな会社だったら、何かあったときにチームを作って、ある程度責任も分散できると思います。しかし当社のように少人数でやっている会社だと、何か起きたときに、その責任が少数の人に集中してしまいがちです」

技術的な復旧だけではない。被害の範囲を調べる。サーバーを止める。バックアップを確認する。外部の専門会社と話す。新しい環境を構築する。社員へ説明する。経営者へ報告する。取引先への説明に必要な情報を整理する。そして、次に何をするかを決める──それらの判断が、少数の担当者に集中してしまうのである。

サーバーを復旧させる人が倒れたら、
誰が復旧させるのか　　　　　　

今回の経験を振り返る中で、山口氏が新たな課題として挙げたのが、インシデント対応にあたる担当者のメンタルケアだった。

「そこは一番の課題かもしれません。どうしたらいいのか、と今も思います。私自身もう一度ランサムウェア被害を受けたら、どうなるかわかりません」

サイバーセキュリティ対策というと、ファイアウォール、MFA、EDR、SOC、バックアップといった技術的な対策が中心になる。しかし、実際にランサムウェア被害が発生すれば、それらを使って復旧するのは人間である。その人間が何日も眠れず、正常な判断が難しくなるほど疲弊したらどうするのか。担当者が1人しかいなければ、誰が交代するのか。「サーバーを止める」という重大な判断を、その1人だけに背負わせていいのか。

バックアップや冗長化は、システムだけに必要なのではない。インシデント対応を担う「人」についても、代替できる体制を考えておく必要がある。山口氏の体験は、その問題を浮き彫りにしていると言えるだろう。

周囲の社員と社長の言葉が
支えになった　

一方で、山口氏は今回、周囲の社員と社長に助けられたと繰り返し話している。

ランサムウェア被害が発生した直後、山口氏は被害がここまで広がった原因は自分にあると考えていた。目の前の事態への対応に追われながらも、「すべてが収束したら、会社を辞めよう」とまで思っていたという。

その気持ちを大きく変えたのが、被害発生から数日後に行われた社員全員への状況説明だった。その場で社長は社員を前に、「今回の事態は山口さんの責任ではない」ときっぱりと言った。

ランサムウェアへの対応は続いており、復旧の先行きもまだ十分には見えていなかった。自らに責任があると考え続けていた山口氏にとって、その言葉は大きかった。「気持ちがだいぶ楽になりました」と、山口氏は振り返る。

そして、支えになったのは社長だけではなかった。社員たちも、それぞれの立場から山口氏と復旧作業を支えた。

「社員のみんながいろいろと助けてくれました。それは本当にありがたく、励みになりました。苦しいさ中の励ましやサポートによって、気持ちを持ち直して、がんばろうという気持ちになりました」

ランサムウェアへの対応は、システム部門だけで完結する仕事ではない。技術的な復旧はシステム担当者が担うとしても、顧客への連絡、取引先への説明、社内業務の調整など、周囲が引き受けられる仕事は数多くある。そうした分担が、結果的に山口氏らを支えたのである。

インシデント対応計画とは、「どのサーバーを止めるか」「どのバックアップから戻すか」だけを決めておくものではない。誰が判断するのか。誰が復旧するのか。誰が社内外へ説明するのか。そして、担当者が限界に達する前に誰が交代するのか。そこまでを含めて準備しておく必要がある。

システムが戻っても、事業はまだ戻らない　

5月末までに主要なサーバーは大枠で復旧した。だが、それですべてが終わったわけではなかった。

「サーバーは復旧しましたが、コンプライアンス上、取引をすぐには再開できないというお客様がありました」

取引先から求められたのは、単に「システムが動いている」という説明ではなかった。何が起きたのか。どこまで被害があったのか。何を直したのか。同じことが再び起きないために、何を変えたのか。それらを説明しなければ、取引を再開できない企業があった。システムの復旧と、事業の復旧は同じではなかったのである。

SSL VPNを廃止、MFAなどを導入　

被害後、松沢書店ではリモートアクセスとセキュリティ環境を大幅に刷新した。従来のSSL VPNを廃止し、IPsec VPNへ移行した。さらに多要素認証（MFA）を必須化し、不要なアカウントを削除。パスワードも全面的に見直した。外部連携に利用していたFTPについても、より安全な方式へ変更した。ファイアウォールなどについては脆弱性情報を継続的に確認し、必要なパッチを迅速に適用する運用へ改めた。さらにActive Directoryへの不審なログオンや権限操作を監視する仕組みを導入し、業務用PCにはEDR（Endpoint Detection and Respon
se）を導入。24時間365日体制のSOCによる監視も開始した。

侵入を防ぐだけではない。侵入された場合に早く気づき、横展開を防ぎ、被害を最小限にとどめる。対策の考え方そのものが変わったのである。

「侵入を防ぐ」から「いかに早く戻すか」へ　　

山口氏は、今回の経験によってセキュリティを見る「解像度が高くなった」と表現する。以前なら、他社がランサムウェア被害を受けたというニュースを見ても、「大変だな」と思う程度だった。

今は違う。どこまで侵入されたのか。横展開を防げたのか。どの時点でネットワークを遮断したのか。何日で主要業務を復旧したのか。そうした点を見るようになった。

「今は、もし被害にあった場合に、いかに早く戻せるかという体制が大事だと思っています」

侵入されないための対策はもちろん必要である。しかし、完全に防ぎ切れるという前提だけでシステムを設計することはできない。侵入されたら、早く検知する。広げない。止める。復旧できるバックアップを残す。そして早く戻す。そこまでを1つのセキュリティ対策として考える必要がある。

まさか、うちのような会社が　　

今回の取材で、山口氏が繰り返し口にした言葉がある。

「まさか、うちが」

という言葉である。

「当社ぐらいの規模の企業が狙われるはずがない、という感覚でした。今思えば、セキュリティに対する意識が低かったと思います」

だが、ランサムウェア被害は企業規模だけで線を引いてくれるわけではない。山口氏と松沢書店が今回、自らの経験を公開してくれた理由もそこにある。

「特に中小企業の方に、当社と同じようなことが起きないように、未然に防げることはあると思うのです。何かそういうことが伝わればと思いました」

今回の被害を経て、山口氏のセキュリティに対する考え方は大きく変わった。

侵入の可能性を完全にゼロにすることは難しい。だからこそ、異常を早期に検知し、被害を広げず、安全なバックアップから速やかに復旧できる体制を整えておくことが重要になる。

同時に浮かび上がったのが「人」の問題である。重大なインシデントが発生すれば、システム担当者には次々と判断が求められる。睡眠も十分に取れない状態が続けば、判断力も低下する。山口氏が単なるパスワードエラーを「再び侵入されたのではないか」と受け止めた出来事は、その現実を象徴している。少人数のシステム部門では、こうした負荷が1人、あるいは数人に集中しやすい。

今回、山口氏を支えたのは技術や製品だけではなかった。「今回の事態は山口さんの責任ではない」と言い切った社長の言葉があり、復旧を支えた社員たちがいた。

ランサムウェアへの備えとは、侵入を防ぐことだけではない。被害を最小限に抑え、事業を早く復旧させるとともに、対応する人を孤立させず、責任と負荷を組織として引き受けられる体制を作ることでもある。

サーバーやデータにバックアップや冗長化が必要なように、「人」にもそれを支える仕組みが必要である。今回の松沢書店と山口氏の経験は、インシデントを乗り越えられる「組織」を平時から作っておくことの重要性を示している。