「診療が止まるからアップデートできない」
「ベンダーが保証しないから触れない」
医療機関では、止めづらいシステムほど更新が後回しになりがちです。
その結果、サポート切れOSや古いソフトウェアが院内に残り続け、攻撃者にとって分かりやすい狙い目になってしまうケースも少なくありません。
ここでは、「止められないから更新できない」という現実を否定せず、なぜ更新が止まりやすい構造になっているのか、そして 放置せずに向き合うための考え方 を整理します。
「保証しない」の裏にある「設計と準備」の問題
ベンダーから「動作保証外なので自己責任です」と言われると、更新に踏み切ることは難しくなります。
ただし、ここで押さえておきたい前提があります。
「Windows Updateでアプリが壊れる」という不安はよく聞きますが、通常の構成であれば更新で致命的に動かなくなることは多くありません。更新が止まっている背景に「設計」や「検証体制」の問題が隠れていないかを確認することが重要です。
それでも「更新が怖い」「保証できない」が起きる場合、背景には次のような構造が混ざっていることがあります。
- OSの進化（最小権限や保護の仕組み）に追従していない設計
例：通常操作で管理者権限が必要／アプリが「書き込み禁止の場所」に設定やデータを置こうとする／共通データと個人データが混在している、など
→ こうした設計は、Windows Vista以降の「最小権限（UAC）」という前提と相性が悪く、運用で無理やり回すほどリスクが増えます。 - 古いライブラリや実行環境への依存が強く、更新を前提にした整理がされていない
（昔の部品に強く依存していて、置き換えや動作確認の道筋がない状態）
→ 結果として、更新の話になると「怖いので触れない」「保証できない」となりやすく、放置の理由になってしまいます。 - 更新を前提にした「検証の仕組み」が用意されていない
例：更新手順が標準化されていない／影響確認の観点が決まっていない／検証環境がない、など
→ 「保証できない」の裏に、単に「保証するための準備がない」が含まれていることがあります。
そして、管理者権限を常用させる運用は、
- 侵害時に被害を最小化できない
- 攻撃者やマルウェアにも同じ強い権限を与えてしまう
- 横展開や破壊を防ぐ「境界」を自ら薄くする
という問題につながります。アプリケーションの都合で、OSが持っている防御設計や機能を使用できないことによるリスクを病院側が背負わされている構図になり得ます。
更新自体は昔ほど難しくない
なお、現在の Windows のセキュリティ更新は 累積更新が基本となっており、昔ほど「パッチの依存関係がネックで…」という構造にはなりにくくなっています。
だからこそ重要なのは、「影響が怖いから更新を見送る」のではなく、診療への影響を最小化して更新できる準備がされているか という点です。
「できない理由」を積み上げるより、できる状態をどう作るかが問われます。
更新が止まる「停滞パターン」
多くの現場では、次のような停滞が起きています。
- 病院側
- 「止められない」「保証されない」ため、更新は先送り
- ベンダー側
- 「自己責任」「動作保証外」と説明するが、製品として、継続的なアップデート検証・標準構成での影響確認・アドバイザリー情報の提供が十分に行われていない
- 結果、サポート切れOSや古いミドルウェアが残り攻撃の格好の的になる
本来、多くの医療機関に導入されている製品であれば、
- OSや主要更新への追従検証
- 標準構成に対する影響評価
- 注意点や制限事項の整理
は、１施設のオーダーではなく製品としての基本的な品質管理（QA）を考える必要があります。
一方で、個別カスタマイズがある場合は、
- どこまでが製品の責任範囲か
- どこからが個別対応か
を整理し、ユーザーと合意形成した上で対応する必要があります。
見える化＋優先順位付けで「動ける形」にする
完璧な更新計画を一気に作る必要はありません。まずは次の3点に絞り、判断できる状態を作ります。
① 更新できない機器を「見える化」する
止めづらいサーバ、医療機器接続端末、部門システムなどを対象に
台帳へ最低限記載：
- OS／主要ソフトのバージョン
- サポート状況
- ベンダー／保守契約の有無
- 更新可否（可能／要調整／困難）
「どれが古いか」「どれが危ないか」を把握することが第一歩です。
②ベンダーと保護方法を検討する
ユーザー独自に対応することは難しいため、ベンダーの協力が不可欠となります。
保護方法を検討するにあたっては次の観点で決めると整理しやすくなります。
- 外部ネットワークや他セグメントとの接点がある
- サポート切れが確定している
- 台数が多く、横展開による影響拡大につながりやすい
- 障害時の復旧に時間がかかる
優先度が高いが対応が難しいものは、「攻撃が到達しにくい環境設計」から見直すと言う視点も必要です。
例えば、
- 他のネットワークセグメントから直接アクセスできないようにする
- 管理用通信経路を限定する
- 影響が横に広がらないよう、セグメント／ゾーンで線を引く
- 利用者権限を最小化する（管理者権限の常用を避ける）
といった対策は、更新が難しいシステムに対する現実的な次善策になります。
これは「侵害が起きる前提で、被害が広がらない設計にする」という意味で、ゼロトラスト的な考え方とも相性が良いアプローチです。
③ 更新を「運用と契約」に落とす
更新には作業が伴います。だからこそ、曖昧にせず整理します。
- 更新手順の検証は誰が行うか
- 実施タイミングはどう決めるか（夜間・休日など）
- 作業コストは保守契約内か／別途見積か
- 更新後の最低限の確認項目は何か
病院側は「必要性」を明確に定めること、ベンダー側は「実施できる体制と仕組み」を用意することが求められます。
まとめ
「止められないから更新できない」は、現実的な事情です。
しかしその前提に立ったまま放置すると、攻撃者にとって“入りやすい理由” になります。
- 院内ネットワークが常に安全とは限らない
- 内部侵入が起きる前提で、ネットワークとシステムを設計・設定する
こうした ゼロトラスト的な考え方 に立ち、
- 見える化
- 優先順位付け
- 更新できる設計と検証体制（そして難しいものは到達しにくくする設計）
を積み重ねていくことが、「更新できない状態」から抜け出す現実的な第一歩です。
サイバー攻撃が日常化した今、対策は病院だけの責任ではありません。
ベンダー側にも、継続的に検証し実施できる体制が、これまで以上に求められています
参考
厚生労働省：「医療機関向けセキュリティ教育支援ポータルサイト」
E-Learning 令和7年度コンテンツ
- 経営者・管理層向け
- 医療情報システムのセキュリティ仕様について
- システム・セキュリティ管理者向け
- 岡山県精神科医療センター ランサムウェア事案調査報告書 読み解き 等
