電話は止まり、アプリは動いていた ― 不正アクセスで一部だけ生き残る「システム分離」と、被害を広げない初動
2026年7月、日本交通が不正アクセス（マルウェア感染）を受け、電話配車や陣痛タクシーの登録フォームが停止する一方、配車アプリ「GO」経由は無事でした。この明暗を入口に、『マルウェア感染時に被害を広げない初動＝ネットワーク隔離とは何か』『なぜ同じ会社で一部サービスだけ生き残るのか＝システムの分離・多重化』を、インフラ運用の実務目線で解説。事業者向けチェックリストと利用者の備えまでまとめました。
目次
2026年7月、日本交通が不正アクセス（マルウェア感染）を受け、電話配車や陣痛タクシーの登録フォームが停止する一方、配車アプリ「GO」経由は無事でした。この明暗を入口に、『マルウェア感染時に被害を広げない初動＝ネットワーク隔離とは何か』『なぜ同じ会社で一部サービスだけ生き残るのか＝システムの分離・多重化』を、インフラ運用の実務目線で解説。事業者向けチェックリストと利用者の備えまでまとめました。
2026年7月11日未明、日本交通が外部からの不正アクセス（マルウェア感染）を受け、電話での配車や陣痛タクシーの登録フォームなどが停止しました。一方で、配車アプリ「GO」経由の依頼は影響を受けず、会社は「配車はGOアプリをご利用ください」と案内しています。同じ会社のサービスでありながら、電話は止まり、アプリは動き続けました。
この記事では、この事案をもとに2つの点を実務の視点で整理します。1つは「マルウェア感染時、被害を広げないための初動（ネットワーク隔離）とは何か」、もう1つは「なぜ同じ会社で、一部のサービスは落ち、一部は生き残るのか」です。侵入経路やマルウェアの詳細は公表されておらず調査中のため、原因は断定せず、公表された事実と一般的なしくみから読み解きます。専門用語には短い説明を添えます。
何が起きたのか
公表された事実を整理します。以下は日本交通の公式発表と各社の報道にもとづくもので、原因の推測は含めていません。
| サービス | 状態 | 利用者への影響 |
|---|---|---|
| 電話でのタクシー配車 | 停止 | 電話で呼べない |
| ハイヤーのWeb受注・予約管理 | 停止 | Web予約が不可 |
| 陣痛タクシーのWeb登録フォーム | 停止 | 新規登録ができない |
| 配車アプリ「GO」経由 | 継続（平常） | 通常どおり配車可能 |
経緯はこうです。7月11日未明、日本交通は社内システムが外部からの不正アクセス（マルウェア感染）を受けたことを検知し、被害の拡大を防ぐため、ただちに社内ネットワークを遮断・隔離しました。その結果、社内システムに依存していた電話配車やハイヤーWeb受注、陣痛タクシーの登録フォームが停止しました。一方で、配車アプリ「GO」経由の依頼は影響を受けず、7月13日に事案を公表した際も「配車はGOアプリをご利用ください」と案内されました。会社は外部の専門機関と連携して原因究明とログ（通信・操作の記録）の分析を進めており、情報漏えいは現時点で確認されていないとしています（いずれも公式発表）。
注目すべき点は2つあります。1つは、停止したのは攻撃そのものより、被害を止めるために自ら遮断した結果だという点。もう1つは、同じ「日本交通でタクシーを呼ぶ」行為でも、経路によって明暗が分かれた点です。以下ではこの2つを順に見ていきます。
なぜ電話配車は止まり、GOアプリは無事だったのか
同じ会社のタクシーで、電話は使えずアプリは使えた理由は、両者が別のシステム基盤の上で動いていることにあります。
電話配車やハイヤーの予約管理は、日本交通の社内システムの上で動いています。感染の拡大を防ぐために社内ネットワークを隔離したため、それにぶら下がる電話配車も一緒に止まりました。一方の「GO」は、GO株式会社が運営する別会社・別基盤の配車プラットフォームです。日本交通の社内システムとは切り離されているため、社内が隔離されてもGO側は自分の基盤の上で動き続けられました。これが明暗を分けた要因です。
システムの分離が、そのまま事業の粘り強さ（レジリエンス）につながった例です。配車の全経路が一つの社内システムに相乗りしていたら、隔離と同時にタクシーを呼ぶ手段が完全になくなっていたはずです。実際には、外部プラットフォームを併用していたことが、事業継続の代替経路として働きました。一つの障害点にすべてを載せないという考え方は、前回の記事で扱った攻撃で基幹システムが止まると事業全体が倒れる構造の、いわば裏返しにあたります。
「ネットワークを隔離する」とは何か
今回、日本交通が真っ先に行ったのがネットワークの隔離（感染した機器やネットワークを、社内の他の部分やインターネットから切り離すこと）でした。マルウェア感染時の初動として、その意味を見ていきます。
なぜ「サービスを止めてでも」切り離すのか
マルウェア、とくにランサムウェア（データを勝手に暗号化して身代金を要求する型のウイルス）は、一台に感染すると社内ネットワークを伝って次々に感染範囲を広げます（横展開）。この延焼を止める最も確実な方法が、感染した区画を切り離すこと、つまりネットワークの隔離です。隔離すればそのサービスは止まりますが、止めなければ感染が全社に回り、基幹システムやバックアップまで巻き込まれて復旧が難しくなります。目先のサービス停止と引き換えに、最悪の全社被害を防ぐ判断です。消火で延焼を防ぐために一部を犠牲にするのと同じ構造です。
早く止められたことの意味
日本交通は検知後ただちに隔離し、被害拡大は抑えられた、現時点で情報漏えいは確認されていない、と説明しています（公式）。目立たない対応ですが、初動としては評価できます。攻撃で恐ろしいのは、気づかないまま何日も潜伏され、静かに感染とデータ持ち出しを広げられることです。早期に異常を検知し、迷わず切り離せたかどうかが、被害の大きさを左右します。調査は継続中で、最終的な被害範囲は今後の発表を待つことになります。なお、インシデント対応に不慣れな組織は、JPCERTコーディネーションセンター（JPCERT/CC）などの専門機関へ早期に相談するのも有効です。
現場の視点：インシデント対応でいちばん難しいのは、技術ではなく止める判断です。ネットワークを切れば、その瞬間に売上や現場が止まります。本当に切っていいのかを、不確かな情報の中で、しかも深夜に決めなければなりません。だからこそ平時に、どういう兆候が出たら、誰の権限で、どこまで切るかを決めておくことが効きます。有事に技術は用意できても、覚悟と段取りは用意できません。切る判断を支えるのは、事前に用意した手順書です。
なぜ「一部だけ生き残る」設計が効くのか
一部のサービスだけが生き残った理由は、システムを一枚岩で作らず、分けて重ねて作っておいた点にあります。
鍵になる考え方は単一障害点をなくすことです。単一障害点とは、そこ一つが止まると全体が止まる急所を指します。すべての配車を一つの社内システムに集約していれば、そこが暗号化された瞬間に事業はゼロになります。逆に、電話・自社Web・外部アプリ（GO）と経路を分けて多重化しておけば、一つが倒れても別の経路で客をさばけます。今回GOが生きていたのは意図した冗長設計とは限りませんが、結果として複数チャネルを持っていたことが事業継続計画（BCP）として機能した例になりました。
一方で弱点が出たのが、電話系のレガシー（古くからの仕組み）です。電話配車は社内システムに密結合していたため、隔離と運命を共にしました。昔からある基幹の仕組みほど、あらゆる機能がそこに集まって単一障害点になりやすい傾向があります。分離は、新しく作るときだけでなく、古い密結合をほどいていく方向にも効きます。
事業者・運用現場が学ぶべきこと
攻撃されても事業を止めきらないための備えは、大きく分けて分離と初動の2つです。まず分離では、社内を一枚の平らなネットワークにせず、部門やシステムごとに区画を分けておきます（セグメンテーション）。区切りがあって初めて、被害の出た区画だけを素早く隔離できます。受注や予約のように、止まると事業が止まる機能は単一の仕組みに集約せず、今回のGOのような外部プラットフォームの併用も含めて、経路を多重化しておくと、一つが倒れても別の経路で回せます。
初動では、どんな兆候で、誰の権限で、どこまで遮断するかを平時に文書化しておくことが効きます。有事の深夜に迷いなく切れるかどうかが、被害の大きさを分けます。侵入をいち早く検知し、後から経路をたどるためのログ（通信・操作の記録）を残して監視し、各機器の不審な挙動を検知して対応するEDRも組み合わせます。バックアップは、感染がそこまで届くと復旧できなくなるため、本番ネットワークから切り離したオフラインの保管を持ち、戻せることを定期的に試します。そして、そもそもの侵入を減らすために、外部に開いた機器の多要素認証（パスワードに加えもう一段の本人確認）や修正プログラムの適用も欠かせません。詳しくはVPN経由の侵入と対策の解説を参照してください。
根底にあるのは、全部が一度に倒れない作りという考え方です。攻撃をゼロにすることはできません。入られても延焼を止められる（隔離）、一部が倒れても客をさばける（多重化）という二段構えを設計として持つことが、被害を小さく抑える近道です。
利用者はどうすればいいのか
今回については、配車アプリ「GO」や、駅前などの乗り場・流し（走行中の空車）を使えば、タクシー自体は問題なく利用できます。電話がつながらないからといって、慌てる必要はありません。
より一般的な備えとしては、暮らしのインフラは一つの手段が止まる前提で代替を用意しておく、という考え方が役立ちます。今回のように、電話が不通でもアプリなら通じることがあります。逆に、アプリ障害のときは電話や乗り場が使えることもあります。とくに陣痛タクシーのように、いざというときに確実に必要なものは、登録先を一つに絞らず、当日の連絡手段（かかりつけ先の電話番号や、複数のタクシー会社・アプリ）を控えておくと安心です。特定の会社やアプリを責めるより、手段を複数持っておくことが、こうした障害への現実的な備えになります。
まとめ ― いま押さえておきたいこと
この事案から得られる教訓は2つです。「被害を広げないための初動＝ネットワーク隔離」は、止める判断を支える事前の手順書で対応できます。「一部が倒れても事業を止めきらない分離・多重化」は、単一障害点をなくす日々の設計で対応できます。いずれも今日から着手できます。
電話は止まっても、アプリは動いていた。この差が示すのは、攻撃をゼロにできない以上、入られても延焼を止め、一部が倒れても全部は倒れない作りを持つことの大切さです。分離と多重化を設計に組み込むことが、事業を止めないための第一手になります。
よくある質問
なぜ電話配車は止まって、GOアプリは使えたのですか？
電話配車は日本交通の社内システムの上で動いており、被害拡大を防ぐために社内ネットワークを隔離したことで一緒に停止しました。一方「GO」はGO株式会社の別基盤で動くため、社内システムの隔離の影響を受けませんでした。システムが分離されていたことが明暗を分けました。
個人情報は漏れたのですか？
日本交通は「現時点で情報漏えいの事実は確認されていない」としています（公式）。ただし外部の専門機関と連携して調査を継続中で、最終的な結論は今後の発表を待つ必要があります。個人データの漏えいが判明した場合、事業者は個人情報保護委員会への報告が必要になることがあります。
「ネットワークを隔離する」となぜサービスが止まるのですか？
感染の延焼を止めるには、感染した区画をネットワークから切り離すのが最も確実です。その区画に依存するサービスは一緒に止まりますが、止めなければ感染が全社に広がり、基幹システムやバックアップまで巻き込まれかねません。目先の停止と引き換えに最悪の被害を防ぐ判断です。
事業者として、同じ状況で事業を止めきらないための備えは？
ネットワークを区画で分けて素早く隔離できるようにすること、重要サービスの経路を多重化すること（外部プラットフォーム併用も有効）、そして「どの兆候で誰がどこまで切るか」の初動ルールを平時に決めておくことです。入口対策（多要素認証・パッチ）とバックアップのオフライン保管も併せて備えます。
更新履歴
- 2026-07-14初版公開。日本交通の不正アクセス（マルウェア感染）でのサービス停止をもとに、ネットワーク隔離という初動と、システム分離・多重化の設計を解説。
- 追記予定復旧状況、原因・侵入経路の続報、情報漏えいの有無に関する最終的な発表が出しだい追記します。
参照元
堀川 慎
Backend Engineer / AWS / Django / Go
