はじめに：医療機関をはじめとしたサイバー攻撃が相次ぐなかで

近年、医療機関を標的としたサイバー攻撃が深刻さを増しています。2026年に入ってからも、国内の病院で電子カルテや院内システムが停止する被害が相次ぎました。2月には日本医科大学武蔵小杉病院で、医療機器保守用のVPN装置を侵入口としたランサムウェア感染により、患者約13万人分の個人情報が漏えいしたと報じられました。3月の白梅豊岡病院では、院内システムがランサムウェアに感染し、患者情報がダークウェブに公開される事態となりました。
電子カルテへの依存度が高まった現代の医療現場にとって、システムの停止は診療そのものの停止に直結します。だからこそ、院内ネットワークを監視し、不審な通信を検知したら自動的に遮断する――そうしたセキュリティ対策は、いまや不可欠なものになっています。
ところが、2026年4月に市立奈良病院で起きたシステム障害は、この話に鋭い問いを投げかけます。当初、この障害は「サイバー攻撃の疑い」として報じられ、救急の受け入れ停止にまで至りました。しかし後の検証で判明した原因は、攻撃ではなく、守るために導入したセキュリティ監視装置そのものの挙動でした。攻撃者はいなかったのです。
本記事では、奈良市が公表した検証報告書という一次情報をもとに、この事案を整理します。そのうえで、ITILの変更実現（Change Enablement）と、インシデント管理・問題管理のプラクティスに照らして、何が教訓なのかを掘り下げます。

第1章：何が起きたのか――「攻撃の疑い」から復旧まで

まず、奈良市の公式報告書をもとに、事実関係を整理します。
2026年4月21日の夜、市立奈良病院で、院内ネットワークの通信を監視するセキュリティ監視装置が、リモート保守用の中継端末からの通信を「異常」と判定し、自動的に遮断しました。その後、眼科システム、生体検査システム、電子カルテ本番系、医事サーバーなど、複数のシステムで警報が相次いで発生します。
病院は、サイバー攻撃の可能性を否定できない状況だと判断しました。そこで、被害の拡大を防ぎ患者の安全を確保するため、対象機器や電子カルテの仮想サーバー群を、ネットワークから物理的に隔離する対応に踏み切ります。この判断の結果、診療には次のような影響が生じました。
救急の受け入れ：約53時間にわたり停止
外来予約：約1,500件のうち、約500件を延期
予定手術：56件のうち、18件を延期
4月22日には厚生労働省から支援チームが派遣され、病院とともにログの分析と安全確認を進めました。安全性が確認できたシステムから順次復旧し、4月23日に電子カルテ本番系を再稼働、4月24日に通常診療を再開。最終的に、オンライン資格確認システムを含む主要なシステムすべてが復旧したのは、5月13日のことでした。
なお、調査の結果、患者情報や診療記録の改ざん・漏えい、ウイルス感染、バックドアの設置など、システムへの侵害を示す痕跡は確認されませんでした。

第2章：原因は「守る仕組み」の過剰反応だった

奈良市は、外部有識者による「奈良市医療情報セキュリティ専門家会議」を設置し、原因を検証しました。2026年8月31日に公表された検証結果は、多くの関係者にとって意外なものでした。
結論は、外部からのサイバー攻撃ではなかった、というものです。報告書は原因を、セキュリティ監視装置の監視対象の変動により、十分に学習されていなかった院内通信が「平常時のパターンからの逸脱」と判定され、自動遮断が連鎖したことによるもの、と整理しました。
発生の経緯を追うと、問題の構造がよく見えてきます。
障害が起きる前、セキュリティ監視装置の監視状態が、何らかの要因で変化していました。その結果、一部の院内通信が、一定期間、十分に監視されていない状態になっていたと見られます。
4月21日夜、このセキュリティ監視装置のソフトウェアが自動更新され、装置が再起動しました。
これを契機に、それまで監視対象から外れていた通信が再び監視対象に戻り、監視対象の端末数が633台から1,954台へと、約3倍に急増しました。
十分に学習されていなかった院内通信が一斉に監視対象となった結果、装置はこれを「平常時パターンからの逸脱」と判定し、通信を自動的に遮断しました。
その後、複数のシステムで警報と通信遮断が相次ぎ、電子カルテを含む病院情報システム全体へと影響が広がりました。
つまり、攻撃者はいませんでした。セキュリティ装置が、正常な院内通信を「異常」と誤認し、自ら遮断したのです。守るための仕組みが、結果として自分たちの診療を止めてしまった、という構図です。
さらに重要な点があります。そもそも、なぜ事前に監視対象が3分の1程度まで減っていたのか――その根本原因は、特定に至りませんでした。報告書は、原因特定に必要な過去の詳細なログの保存期間に限りがあり、十分な確認ができなかったと述べています。問題の起点となった事象の記録が、すでに失われていたのです。

第3章：引き金は「自動更新」だった――ITIL 変更管理（Change Enablement）の視点

変更実現とは、サービスや構成に対する変更を、リスクを適切に管理しながら実施するためのプラクティスです。ここで鍵になるのは、障害の引き金がセキュリティ監視装置の「自動更新」と「再起動」だった、という事実です。ソフトウェアの更新は、まぎれもなく「変更」です。そして今回、その変更は自動で、おそらく夜間に、人の確認を挟まずに適用されました。
ITILの変更実現では、変更をいくつかのタイプに分けて考えます。この分類が、今回の論点を整理するのに役立ちます。
事前に十分リスクが評価され、手順が確立された低リスクな変更は「標準的な変更（Standard change）」として、都度の承認なしに実施できます。一方、影響が読みにくい変更は「通常の変更（Normal change）」として、事前のリスク評価と承認を経るべきものです。問題は、本番環境で稼働する重要なセキュリティ装置の自動更新を、どちらとして扱っていたかです。
本番の医療情報システムに直結する装置の更新は、本来、影響を評価し、更新後の挙動を確認できる体制のもとで実施すべき「変更」でした。しかし実際には、自動更新によって、再起動後に監視対象が3倍に膨れ上がり、それが自動遮断の連鎖を引き起こしました。更新の影響が事前に評価されず、更新後の確認も挟まれなかったことが、障害の直接的な引き金になったのです。
これは、前回の記事で扱ったTelstraの通信障害と、驚くほど似た構造をしています。あちらも、保守作業後の再起動で機器が異常な状態になり、それがネットワーク全体に連鎖しました。「再起動を伴う変更が、想定外の状態変化を引き起こす」という同じパターンが、業種を越えて繰り返されています。
実際、専門家会議の提言でも、再発防止策の筆頭に「セキュリティ監視装置の自動更新を停止し、手動更新に変更する」ことが挙げられました。さらに、更新前後の確認・記録の手順、異常が発生した場合の確認・承認・更新の切戻し（ロールバック）の手順を整備すべきだとしています。これはまさに、変更実現が求める基本動作――変更の計画、影響評価、承認、ロールバック手順の準備――そのものです。
なお、この事案は「守る仕組みが可用性を損なう」という緊張関係もはらんでいます。自動遮断はサイバー攻撃の被害拡大を防ぐ有効な手段である一方、正常な通信を誤って遮断すれば診療を止めてしまう。ITILの情報セキュリティ管理が掲げる機密性・完全性・可用性のうち、医療では可用性が人命に直結します。専門家会議も、自動遮断を維持する場合でも誤検知による診療影響を考慮して適用条件を定めるべきだ、自動遮断だけに依存せず多層防御を組み合わせるべきだ、と提言しています。守る仕組みほど、その適用条件を慎重に設計し、変更として管理する必要があるということです。

第4章：止めた判断は正しかったか――ITIL インシデント管理・問題管理の視点

インシデント管理：初動の「止める判断」は妥当だった
ITILのインシデント管理は、サービスの中断による悪影響を最小限に抑え、通常の運用をできるだけ迅速に回復することを目的とします。
この観点から見ると、病院の初動対応には評価できる点が多くあります。 サイバー攻撃か設備障害かを即座に判断できない状況で、病院は患者の安全と被害拡大の防止を最優先に、異常機器の隔離、バックアップの保護、電子カルテの停止、救急受け入れの一時中止といった対応を取りました。専門家会議は、当時の状況を前提とすれば、これらの対応には相応の合理性が認められると評価しています。
ここには、インシデント管理の重要な原則が表れています。原因がまだ分からない段階では、「最悪のシナリオ（＝本物の攻撃）」を想定して被害拡大を止める判断が優先される、ということです。結果的に原因は攻撃ではありませんでしたが、だからといって「隔離は過剰だった」とはなりません。インシデント対応の良し悪しは、結果論ではなく、その時点で得られる情報に照らして妥当だったかで評価すべきものだからです。
一方で、インシデント管理には積み残しもありました。専門家会議は、再発防止策の方向性は妥当としつつ、実際の緊急時に確実に機能させるには、判断基準や対応手順をさらに具体化する必要があると指摘しています。具体的には、警報発生時の確認事項と初動対応、自動遮断を解除する判断基準、電子カルテなどを段階的に復旧する手順などです。「誰が、何を見て、どう判断し、どう戻すか」を平時に手順化しておくこと。これは前回の障害訓練の記事で触れた「意思決定訓練」の実地版そのものです。

問題管理：ログがなければ、根本原因にはたどり着けない

次に、問題管理の観点です。ITILの問題管理は、インシデントの根本原因を突き止め、再発を防ぐことを目的とします。その根本原因分析の生命線となるのが、ログをはじめとする記録です。
ところが今回、「そもそもなぜ監視対象が3分の1に減っていたのか」という最も肝心な起点について、必要な過去の詳細ログの保存期間が足りず、根本原因の特定に至りませんでした。 直接の引き金（自動更新による監視対象の急増と過検知）までは判明しましたが、その手前にあった「監視状態の変化」という真の起点は、記録が失われていて追えなかったのです。
これは、運用保守に携わる誰にとっても他人事ではない教訓です。障害が起きてから「あのときのログが残っていれば」と悔やんでも、遅いのです。前回のTelstraの記事で「文書化されなかった設計変更」が原因究明を阻んだのと同じく、ここでは「保存されていなかったログ」が、組織が学ぶ機会を奪いました。
問題管理の観点では、根本原因が特定できないということは、同じ障害が再び起きるリスクを完全には潰せないことを意味します。だからこそ専門家会議も、重大事象の発生時に必要なログや設定変更履歴について、その種類・保存範囲・保存期間をあらかじめ整理しておくべきだと提言しています。何を、どれだけの期間残すのか。これを平時に決めておくことが、いざというときに根本原因へたどり着けるかどうかを分けます。

最後に：守る仕組みも「変更」として管理し、記録を残す

市立奈良病院の事案が突きつけた教訓を、整理しておきます。
第一に、セキュリティの仕組みも、更新すれば「変更」になるということです（変更管理）。守るための装置であっても、その自動更新や再起動は、本番環境への変更にほかなりません。影響を評価し、更新後の挙動を確認し、問題があれば切り戻せる。変更実現の基本動作を、セキュリティ製品にも適用する必要があります。
第二に、原因が分からない段階では、止めて守る判断が優先されるということです（インシデント管理）。奈良病院の隔離対応は、結果的に攻撃ではなかったとしても、その時点では妥当でした。インシデント対応は結果論で裁かず、判断時点の情報に照らして評価する。そして、その判断と復旧の手順を平時に具体化しておくことが、次の備えになります。
第三に、ログを残していなければ、組織は学べません。根本原因にたどり着けなければ、再発は防げません。何をどれだけ残すかを、平時に決めておくことが、問題管理の土台になります。
冒頭で触れたとおり、医療機関を狙うサイバー攻撃は現実の脅威であり、監視と防御の強化は欠かせません。しかし今回の事案は、その防御の仕組み自体もまた、適切に管理されなければ障害の原因になりうることを教えてくれます。「サイバー攻撃だと思ったら、守る仕組みの過剰反応だった」――この逆説は、攻撃に備えることと、備えのための仕組みを正しく運用することの、両方が必要だと突きつけています。
いま自分たちが導入しているセキュリティ製品は、どういう条件で通信を遮断する設定になっているか。その更新は、変更として管理されているか。そして、いざというときに原因を追えるログは、残っているか。冷や汗をかく前に、あらためて確認してみてはいかがでしょうか？

参考文献

奈良市（2026）.「市立奈良病院におけるシステム障害に係る報告について」（奈良市医療情報セキュリティ専門家会議 検証報告書 概要版）. https://www.city.nara.lg.jp/soshiki/93/273750.html
奈良新聞デジタル（2026）.「市立奈良病院のシステム障害検証結果を公表　サイバー攻撃否定、監視装置の過検知」. https://www.nara-np.co.jp/news/20260901210926.html
ITmedia NEWS（2026）.「サイバー攻撃疑いの市立奈良病院、初動対応に成功で『感染・漏えいなし』　通常診療再開」. https://www.itmedia.co.jp/news/articles/2604/24/news069.html
日経メディカル（2026）.「サイバー攻撃疑いの市立奈良病院、救急受け入れと外来診療を停止」. https://medical.nikkeibp.co.jp/leaf/mem/pub/hotnews/int/202604/592992.html
病院・医療機関のサイバー攻撃事例【2026年版】（武蔵小杉病院・白梅豊岡病院ほか）. https://aevus.jp/blog/hospital-cyber-attack-cases-2026.html
piyolog（2026）.「監視機器の自動更新で起きた市立奈良病院のシステム障害についてまとめてみた」. https://piyolog.hatenadiary.jp/entry/2026/09/04/104347