シンジです。2026年2月9日の午前1時50分、日本医科大学武蔵小杉病院のナースコールシステムがランサムウェア攻撃を受けました。侵入経路は医療機器保守用VPN装置です。またVPNです。またです。人類は過去の経験から学ばない生き物でしたね。

約1万人分の患者の個人情報（氏名、性別、住所、電話番号、生年月日、患者ID）が院外に持ち出されたことが確認されています。厚労省の初動対応チームが派遣される事態となりました。ナースコールですよ。入院患者さんが緊急時にナースを呼ぶためのあのボタンの裏側にあるシステムが、ランサムウェアにやられたわけです。

「医療機器保守用VPN装置」という闇

今回の侵入経路が「医療機器保守用VPN装置」だったということは、つまり医療機器ベンダーが遠隔で保守するために設置されたVPN装置が入口になったということです。

これ、医療業界に限った話じゃないんですよね。製造業でも、ビル管理でも、ありとあらゆる業界で「保守用VPN」は存在しています。ベンダーが「リモートメンテナンスのために必要なんです」と言って置いていくVPN装置。情シスの管理外にあることも珍しくない。パッチが当たっているかも分からない。そもそも誰がその装置を管理しているのかすら曖昧なケースだってあります。

半田病院のときもVPNでした。大阪急性期・総合医療センターのときもVPNでした。徳島つるぎ町立半田病院のVPN装置はFortinet製で、既知の脆弱性が放置されたまま運用されていました。何年経っても同じパターンが繰り返されている。ランサムウェア攻撃の侵入口として、VPN装置がぶっちぎりの1位であり続けているわけです。

VPNは悪だと言うと必ず来る反論

反論「VPNという技術は悪くない。設置したベンダーが運用しないのが悪い」

気持ちは分かります。技術屋としてはそう言いたいですよね。技術は中立であり、運用する人間の問題だと。

じゃあ逆に聞きます。その「ベンダーがちゃんと運用する」という前提が、現実世界で一度でも安定して成立したことがありますか？

VPNという技術は、その設計上、インターネットに面した装置を24時間365日稼働させ続けることが前提です。そしてその装置のセキュリティは、設置したベンダー、管理を委託された運用者、パッチを配布するメーカー、そしてそれを適用する現場の人間、この全員が、一人の例外もなく、一日の隙もなく、完璧に仕事をし続けることで初めて成り立ちます。

一人でもサボったら終わり。一日でもパッチ適用が遅れたら終わり。そしてゼロデイが出たら、全員が完璧でも終わり。

「全員が完璧に運用しないと安全にならない設計」は、それ自体が欠陥のある設計です。セキュリティの世界ではこれを「Fragile by Design」と呼びます。人間は必ずミスをする。組織は必ず怠る。ベンダーは必ず手を抜く。それを前提としない設計は、設計として破綻しています。

「ベンダーが悪い」という主張は、実はVPNが悪いことの証明になっているんですよ。VPNというアーキテクチャが、設置者・運用者・メーカーの全員に完璧を要求し、誰か一人が崩れたら全てが崩壊する構造になっている。それは技術が中立なのではなく、技術が人間に非現実的な完璧さを要求しているのです。

半田病院のFortiGateのパッチ未適用も、今回の武蔵小杉病院も、保守ベンダーが設置した装置が入口です。何年経ってもベンダーは完璧にならないんですよ。ならないことが証明され続けているのに、ベンダーの完璧さに依存し続ける設計を採用し続ける判断のほうがよっぽど問題です。

反論「パッチをちゃんと当てれば問題ない」

パッチを最速で適用していたとして、ゼロデイには間に合うんですか？

2024年〜2025年だけで、Ivanti、SonicWall、Cisco、Palo Alto——VPN業界のトップベンダー4社の主力製品が全部ゼロデイを食らっています。パッチが存在する前に攻撃が始まっているんです。パッチを当てるも何も、当てるパッチが世の中に存在しない段階で攻撃されている。

2025年のデータでは、KEV（既知の悪用された脆弱性）の約30%が公開から24時間以内に武器化されています。VPNアプライアンスのパッチ適用には、テスト環境での検証、変更管理の承認、ダウンタイムの調整が必要です。24時間以内に武器化される脆弱性に対して、このプロセスが間に合うと本気で思っていますか。

「パッチをちゃんと当てれば問題ない」は、「ゼロデイは存在しない」と言っているのと同義です。存在するから毎年大量のインシデントが起きているんです。

反論「VPNは道具に過ぎない。包丁が危険だからといって包丁を禁止するのか」

包丁の比喩、好きですよね。分かりやすいので使いたくなる気持ちは分かります。でもこの比喩は根本的に間違っています。

包丁は、正しく使えば料理ができて、使い方を誤れば怪我をする。だから「使う人の問題だ」と言える。これは失敗したときの被害が、包丁の届く範囲に限定されるから成り立つ議論です。

VPNは違います。VPNの設計上、認証に成功したらネットワーク内部に入れる。入ったら横に動き放題。つまりVPNが一箇所で破られたら、被害はネットワーク全体に無制限に広がる。今回の武蔵小杉病院では、ナースコールシステムの保守用VPNから入られて、約1万人分の個人情報が院外に持ち出されました。保守用VPNの守備範囲はナースコールシステムのはずなのに、被害が患者情報にまで及んでいる。これがVPNの「暗黙の信頼」による被害拡大です。

包丁で喩えるなら、台所で包丁を落としたら、家全体が爆発する包丁です。失敗時の被害範囲が無制限に拡大する道具は、もはや「使い方次第」で済ませられる代物ではありません。

そもそも包丁にはJIS規格があります。製造基準がある。SSL VPNには業界標準が存在しません。ノルウェーNCSCが明確に指摘していますが、「SSL VPNには業界標準が存在せず、各ベンダーが独自実装を行うため、構造的に脆弱性が生まれやすい」のです。規格化された包丁と、各社が勝手に作っている規格なしの爆発物を同列に語らないでください。

反論「ZTNAにだって脆弱性はあるだろう」

あります。ZTNAが完璧だなんて一言も言っていません。

でも構造が違うんです。VPNアプライアンスはインターネットに露出している。ZTNAのコネクタはインターネットに公開されていない。攻撃者から見えないものは攻撃できない。仮にZTNAの認証が突破されても、アクセスできるのは認可されたアプリケーションだけで、ネットワーク全体には到達できない。

VPNの脆弱性が悪用されたら、内部ネットワーク全体が危険に晒される。ZTNAの脆弱性が悪用されても、被害は特定のアプリケーションに限定される。この「被害の封じ込め」が構造的にできるかできないかが、決定的な差です。

「どっちにも脆弱性がある」は、被害範囲の違いを無視した詭弁です。木造住宅も鉄筋コンクリートのビルも火事にはなりますが、延焼範囲はまるで違う。VPNは木造密集地帯で、ZTNAは防火区画のあるビルです。「どっちも燃えるじゃん」は、建築の議論としては成立しません。

反論「そんな簡単にリプレースできるわけないだろう」

知ってます。簡単じゃないです。コストもかかるし時間もかかる。特に医療機関のように、止められないシステムが多い環境ではなおさらです。

でもそれは「だからVPNのままでいい」の理由にはなりません。「移行が大変だから現状維持」は、リスクを受容しているのではなく、リスクから目を逸らしているだけです。

武蔵小杉病院は今、初動対応チームの派遣を受けて、1万人への個人情報漏洩のお詫びの郵送を行い、3回線の専用ダイヤルとフリーダイヤルを設置しています。フォレンジック調査の費用、弁護士費用、信用毀損、場合によっては損害賠償。これらが「リプレースが大変だから」現状維持を選んだ結果のコストです。計画的なZTNA移行のコストと、どちらが高いですか。比較するまでもないと思います。

数字で見ると絶望的

数字の話をします。

Zscaler ThreatLabzの「2025 VPN Risk Report」（632名のIT・セキュリティ専門家を対象とした調査）によると、56%の組織が過去1年間にVPNの脆弱性を悪用された侵害を経験しています。半分以上です。そして92%の組織がVPNの未パッチ脆弱性がランサムウェア攻撃に直結することを懸念している。懸念しているのに使い続けているというこの矛盾。さらに65%の組織が1年以内にVPNのリプレースを計画しています。前年比23%増。みんな分かっているんですよ、ヤバいってことは。

（出典：Zscaler ThreatLabz 2025 VPN Risk Report, Cybersecurity Insiders委託,2025年4月公開。ベンダー委託調査である点は割り引いて読む必要があるが、後述するDBIR・CISAの傾向と整合しており、業界全体のトレンドとして信頼に足る）

2020年から2025年にかけてVPN関連のCVEは82.5%増加しています。2024年に報告された83件のVPN脆弱性のうち約60%がCVSSスコアでHighまたはCriticalです。最も多いタイプはリモートコード実行（RCE）。つまり攻撃者がVPN装置上で好き放題コードを実行できるという、セキュリティ的には最悪のやつです。

Verizon DBIRでも、脆弱性の悪用が全侵害の20%を占め前年比34%増、その主因としてエッジデバイスとVPNが名指しされています。

これはもう「たまたま運が悪かった」とか「パッチを怠った運用の問題」とかで片付けられるレベルの話ではないです。世界中の56%の組織の運用が全部悪いんですか？56%の組織のベンダーが全部手を抜いたんですか？そんなわけないでしょう。構造の問題です。

2024〜2025年のVPNゼロデイ祭り

「ベンダーが悪い」「パッチを当てれば大丈夫」派の人にこそ読んでほしいんですが、やられたのは無名の三流ベンダーじゃないんです。VPN業界のトップティアが軒並みやられています。

Ivanti Connect Secure（旧Pulse Secure）
2024年1月、中国系APTグループ「UNC5221」がゼロデイ2件をチェーンで悪用し約2,000台が侵害されました。CISAは「工場出荷状態にリセットしても安全ではない」と警告を出しています。工場出荷状態にリセットしてもダメ。つまりベンダーが考えうる最大の対処をしても足りないということです。これでも「ベンダーが悪い」と言いますか。2025年1月には新たなゼロデイで英国の.UKドメインレジストリ（Nominet）が侵害されています。

SonicWall SSL VPN
CVSS 9.3の脆弱性が悪用され、FogランサムウェアとAkiraランサムウェアが企業ネットワークに侵入。2024年8月以降だけで30件以上のランサムウェア感染が確認されています。インターネットに露出していたSonicWall SSLVPNデバイスは25,000台以上。

Cisco ASA
国家支援の攻撃者「ArcaneDoor」がゼロデイを悪用し、ファームウェア（ROMMON）に永続的なマルウェアを埋め込みました。通常のアップデートや再起動では除去できない。パッチを当てても消えないマルウェアです。CISAはサポート終了のASAデバイスの即時切断を命じています。

Palo Alto GlobalProtect
Operation MidnightEclipseとして中国系APTにバックドアを仕込まれました。

Ivanti、SonicWall、Cisco、Palo Alto。VPN製品を売っている会社の中で、これ以上のメジャーどころがありますか？BIG-IPなら大丈夫だ理論なのか？業界トップの4社が、全社ゼロデイを食らっている。これでも「VPN技術は悪くない、ベンダーの運用が悪い」と言えるんですか。世界最高レベルのセキュリティベンダーが作ったVPN製品ですら次々と破られるなら、それは個々のベンダーの問題ではなく、VPNという技術カテゴリそのものが持つ構造的限界です。

世界の政府機関が「VPNやめろ」と言い始めている

第1段階：「せめてSSL VPNだけは今すぐやめろ」

最も直接的なのはノルウェーNCSCです。2024年5月、SSL VPN/WebVPNの置き換えを明確に勧告しました。重要インフラは2024年末まで、その他の組織は2025年末までにIPsec IKEv2への移行を完了しろと。一国のサイバーセキュリティ機関が、期限を切って「SSL VPNを使うな」と言ったんです。

ノルウェーNCSCの指摘で秀逸なのは、「SSL VPNには業界標準が存在せず、各ベンダーが独自実装を行うため、構造的に脆弱性が生まれやすい」と言い切っている点です。国の機関が「運用が悪いんじゃない、SSL VPNの設計が悪いんだ」と言っている。

（出典：Norwegian NCSC「Anbefaler å erstatte SSLVPN/WebVPN med sikrere alternativer」2024年5月15日公開）

ここで「じゃあIPsec IKEv2に移行すればいいんでしょ」となりがちですが、ノルウェーNCSCの勧告はSSL VPNがやばすぎるからとりあえずIPsecへの移行であって、「IPsec VPNなら安全」とは言っていません。SSL VPNの独自実装問題を排除できるという点ではIPsecはマシですが、インターネットに露出したVPNアプライアンスに境界防御を依存する構造そのものは何も変わらない。ゼロデイが出たらやられる。ラテラルムーブメントを許す。パッチ適用の運用負荷がかかる。IPsec移行はあくまで「最悪のSSL VPNから、まだマシなIPsecへの応急処置」であって、構造的な解決ではありません。

第2段階：「VPNに依存する設計思想そのものをやめろ」

本丸はこっちです。

英国NCSCはゼロトラスト設計原則の第7原則で「Don't trust any network, including your own（自組織のネットワークを含め、いかなるネットワークも信頼するな）」と定義しています。VPNの「認証したら内部ネットワークを信頼する」という設計思想の全否定です。これはSSL VPNだけでなく、IPsec VPNも含めた「ネットワークレベルの信頼」そのものに対する否定です。

米国CISAは2024年にVPN関連で22件以上のKEVを特定し、「Modern Approaches to Network Access Security」でZTNA移行を推奨。2025年にはCisco ASAの緊急切断を命じています。CISAが言っているのは「別のVPNに移行しろ」ではなく「ゼロトラストアーキテクチャに移行しろ」です。

ドイツBSIは「Assume Breach（侵害を前提とする）」をベースにしたゼロトラストアーキテクチャへの移行を提唱。フランスANSSIもゼロトラスト導入ガイダンスを公開。

米国、英国、ノルウェー、ドイツ、フランス、EU。これだけの国と機関が独立した判断で同じ方向に動いている。ノルウェーは「まずSSL VPNを捨てろ」と応急処置を示し、米英独仏は「VPNに依存する設計そのものを捨てろ」と本質的な解を示している。

彼らは「ベンダーの運用を改善しろ」とも「IPsecに移行すれば安心」とも言っていません。「VPNに境界防御を適用させる時代は終わった」と言っています。

じゃあどうすりゃいいんだ

VPNが悪だと言うだけでは無責任なので代替策を書きます。答えはシンプルで、ZTNA（Zero Trust Network Access）への移行です。

VPNは「認証したらネットワーク全体にアクセスできる」。ZTNAは「認証・認可後にアプリケーション単位でしかアクセスできない」。この違いは決定的です。

VPNアプライアンスはインターネットに露出しているから攻撃者にスキャンされ放題ですが、ZTNAはそもそもアプライアンスがインターネットに公開されていません。ラテラルムーブメントも、VPNはネットワークレベルのアクセスなので容易ですが、ZTNAはマイクロセグメンテーションで困難です。パッチ管理も、VPNは顧客側の責任でダウンタイムが必要ですが、ZTNAはクラウド側で自動更新です。

今回の武蔵小杉病院のケースに当てはめると、仮にZTNAだったなら、保守ベンダーはナースコールシステムの特定のアプリケーションにしかアクセスできず、仮に認証情報が漏洩しても他のシステムへの横展開は構造的にできない。1万人分の患者情報が院外に持ち出されるという事態は、構造的に発生しえなかったはずです。

これが「構造で守る」ということです。人間の完璧さに依存しない。ベンダーの善意に依存しない。仕組みとして被害を封じ込める。

「明日からZTNAなんて無理」という人のための現実的な移行パス

「理想は分かったけど、うちのレガシー環境じゃ無理」という声が聞こえてきます。分かってます。だから段階的にやるんです。

今すぐ（短期）：VPNの露出を最小化する
まずは既存のVPN装置のアタックサーフェスを減らす。送信元IP制限、MFAの強制、利用時間帯の制限、不要なポートの閉鎖。完璧な防御にはならないが、自動スキャンで引っかかる確率を下げるだけでも意味がある。特に保守ベンダー用VPNは「常時オン」をやめて、JIT（Just-In-Time）アクセスに切り替える。使うときだけ開けて、終わったら閉じる。これだけで露出時間が激減する。

3〜6ヶ月（中期）：保守系・管理系アクセスからZTNA化する
全面移行はいきなり無理でも、最もリスクの高い経路から手を付ける。今回の武蔵小杉病院のケースで言えば、まさに「保守用VPN」がそれです。ベンダーのリモート保守アクセスをZTNAに切り替えるだけで、最大のリスク経路を潰せる。社内のリモートアクセスVPNは後回しでもいい。まずは「外部からの保守アクセス」を構造的に安全にする。

6〜18ヶ月（長期）：アプリケーション単位のアクセス制御に全面移行する
社内のリモートアクセスも含めて、ネットワークレベルのアクセスからアプリケーション単位のアクセスに再設計する。マイクロセグメンテーションを導入し、仮にどこかが破られても横展開ができない構造を作る。これがゼロトラストの本丸です。

「レガシー環境だから無理」は「全部一気にやろうとするから無理」なんです。保守用VPNを1台ZTNA化するところから始めればいい。その1台が、次の武蔵小杉病院を防ぐかもしれないんですから。

「うちは医療機関じゃないから関係ない」と思っている人へ

関係あります。

医療機器保守用VPNと、御社のリモートアクセスVPNと、取引先がメンテナンスのために置いていったVPN装置。構造は全部同じです。インターネットに露出したVPNアプライアンスが存在する限り、攻撃対象面（アタックサーフェス）は開きっぱなしです。

「うちは狙われるような大企業じゃないし」。ランサムウェアの攻撃者はそんなこと気にしません。脆弱なVPN装置を自動スキャンして、見つけたら片っ端から侵入するだけです。御社の規模とか業種とか知ったこっちゃないんです。

VPNやめろ

何回も言いますが、VPNは道具の問題じゃなくて設計の問題です。

「ベンダーが悪い」
全員が完璧じゃないと成立しない設計が悪い。そして何年経ってもベンダーは完璧にならなかった。

「パッチを当てれば大丈夫」
ゼロデイにパッチは存在しない。存在しないものは当てられない。

「技術は中立だ」
業界トップ4社が全滅している。技術カテゴリごと構造が破綻している。

「包丁と同じだ」
失敗時に被害が無制限に拡大する包丁は欠陥品と呼ぶ。しかもJIS規格すらない。

「ZTNAにだって脆弱性はある」
被害の封じ込めが構造的にできるかどうかが本質。木造とRC造は同じ「建物」じゃない。

「リプレースは大変だ」
ランサムウェアに食らった後のコストと比較してから言ってくれ。

VPNは悪です。それは感情論ではなく、データと構造分析と、繰り返される実際のインシデントと、6カ国のサイバーセキュリティ機関の独立した結論が証明しています。

「VPN技術は悪くない」と言い続けている間にも、次の病院が、次の企業が、次の自治体がやられます。VPNは悪くないって言うなら、あなたのその信じるVPNで大事故を防いでもらえませんかね。

追記（公開から4時間後）

ありがたいことに早速「VPNを否定するな」勢が反論してたので追記しておきます。

「ガイドラインが閉域前提だからVPN必須」「リモート保守ができなくなったら保守費2-3倍」「予算がない」「職員が使えない」「病院系案件やってから言え」

いいですね。分かってない感が出てますね。

「ガイドラインでは閉域が前提。VPN接続が必要やったりする」という反論

これが最も多い誤認であり、最も致命的な誤認です。

厚労省「医療情報システムの安全管理に関するガイドライン 第6.0版」（令和5年5月公開）。関係者なら読んでますよね。読んでたらこの反論は出てこないんですよ。

第6.0版のシステム運用編で「ゼロトラストネットワーク型思考」が明文化されました。改定ポイントの2番目に「ネットワーク境界防御型思考／ゼロトラストネットワーク型思考」が据えられています。

そしてガイドラインでは「閉域環境下であっても従来の外部との通信制限を行う境界型防御では対策が不十分である」と記載してる。厚労省が公式に「閉域だから安全」という前提を否定しています。「ガイドラインが閉域前提だから」と言っている人は、5.2版で時が止まっています。6.0版を読んでください。

同ガイドラインのシステム運用編、ネットワークに関する安全管理措置の遵守事項には、SSL-VPNを利用する場合、クライアント証明書を用いたクライアント認証が必須だと明記されています。

世の中の病院に設置されているSSL-VPN装置のうち、クライアント証明書認証を実装しているものがどれだけありますか？ほとんどないでしょう。つまり現状のVPN運用こそがガイドライン違反なんですよ。「ガイドラインがVPN前提だ」どころか、ガイドラインが要求する水準を満たしていないVPNが放置されているのが現実です。

2027年度時点で稼働している医療情報システムには二要素認証の導入が必要であることも明記。ID/パスワードだけでVPN接続しているような構成は、ガイドライン的にはもう論外なんです。

「閉域網だから安全」これは、半田病院のときも同じことを言っていましたよね。事故調査報告書で何が指摘されたか。VPNによりインターネットへの外部接続が可能だったにも関わらず、そのリスクを適切に認識していなかった。閉域だと思い込んでいたものが閉域ではなかった。それが「閉域網神話」の正体です。VPN装置がインターネットに面している時点で、それは閉域じゃないんですよ。

（出典：厚生労働省「医療情報システムの安全管理に関するガイドライン 第6.0版」システム運用編、令和5年5月）

「リモート保守ができなくなったら病院側は2-3倍の保守費払わないとベンダー側は対応できん」という反論

ZTNAはリモート保守を禁止する技術なんでしたっけ？

この反論は「VPN＝リモートアクセス手段」「VPN廃止＝リモートアクセス不可」という誤った等式に基づいています。VPNはリモートアクセスを実現する手段の一つであって、唯一の手段ではない。

ZTNAでは保守ベンダーに対して「ナースコールシステムの管理画面」だけにアクセスを許可し、それ以外のネットワークリソースには一切到達させない構成がとれる。これが構造的に実現できるわけです。VPNだと「内部ネットワーク全体」へのアクセスを許可してしまう。だから武蔵小杉病院ではナースコールの保守用VPNから入られて、患者情報1万人分が持ち出された。

つまりZTNAへの移行は「リモート保守の廃止」ではなく「リモート保守のセキュア化」です。ベンダーは今まで通りリモートで保守できる。ただし、保守対象のシステム以外には触れなくなる。これで何か困るんですか。保守対象以外のシステムにアクセスできなくなることが困るなら、それは保守の範囲外のことをやっていたということであり、それ自体が問題です。

保守費が2-3倍になるという主張の根拠が分けわかめですが、仮にリモート保守のアクセス経路をZTNA化するコストを保守費に転嫁するとしても、それはセキュリティコストの正常化です。今までベンダーは「内部ネットワーク全体にフルアクセスできる穴」を開けた状態でリモート保守していた。それを「対象システムだけにアクセス制限する」のは、本来最初からやるべきだったことです。今まで安かった保守費のほうが「セキュリティコストを外部化していた」だけなんですよ。患者にリスクを押し付けて安くしていたんです。

武蔵小杉病院が今払っているコストを考えてください。フォレンジック調査費用。1万人への個人情報漏洩のお詫び郵送。3回線の専用ダイヤル設置。弁護士費用。信用毀損。場合によっては損害賠償。保守費が2倍になるのと、このコスト。比較するまでもないでしょう。

「セキュリティ対策で診療報酬に上乗せできない。予算がない」という反論

2024年度の診療報酬改定、読んでないんですか。関係者ですよね。

サイバーセキュリティ対策の確保を要件とする上位区分として「診療録管理体制加算1」（入院初日に140点）が新設されました。BCPの策定、オフラインバックアップの実施等、サイバーセキュリティ体制を整備している医療機関を診療報酬で評価する仕組みです。サイバーセキュリティ対策をやれば、診療報酬で返ってくる制度がもう存在している。

2024年度改定では医療DX推進体制整備加算も新設されています。オンライン資格確認、電子処方箋、電子カルテ情報共有サービスへの参加等を要件に、初診時に加算が認められる。2025年4月以降は6区分に改組され、マイナ保険証利用率と電子処方箋導入有無に応じて点数が変動します。

補助金・支援制度もあります。IT導入補助金のセキュリティ推進枠。サイバーセキュリティお助け隊サービス（IPA認定。中小企業・医療機関向けワンパッケージのセキュリティサービス。IT導入補助金で導入費の支援あり）。医療情報化支援基金（ICT基金による電子処方箋・電子カルテ導入支援、2025年9月まで延長）。生産性向上・働き方改革支援補助金（病院は許可病床数×4万円等の定額給付。ICT機器導入に活用可能）。

中医協の場で日本医師会の江澤和彦常任理事ですら「サイバーセキュリティ対策について、医療機関は財源面も人材面も技術面も不足しており苦慮している」と発言しています。というわけでそれに対して国は診療報酬上の評価と補助金の二本立てで対応を進めている。制度は作られているんですよ。使ってください。

そしてそもそもの大前提の話をします。

2023年4月に医療法施行規則が改正されました。第14条第2項が新設され、「医療の提供に著しい支障を及ぼすおそれがないように、サイバーセキュリティを確保するために必要な措置を講じなければならない」と定められた。これは努力義務ではありません。法的義務です。医療法第25条に基づく立入検査でもサイバーセキュリティ対策の確認が行われるようになっています。

「予算がない」は、法的義務を果たさない理由にはなりません。消防設備の点検に予算がないから火災報知器を設置しませんと言っているのと同じです。それは予算の問題ではなく、経営判断の問題です。

（出典：厚生労働省「医療法施行規則の一部を改正する省令について」令和5年3月10日公布、4月1日施行。中医協総会2024年度診療報酬改定答申。厚生労働省「医療分野のサイバーセキュリティ対策について」公式ページ）

「ゼロトラストで設計すると職員が使えない。境界防御で設計せざるを得ない」という反論

使えないのはゼロトラストのせいじゃなくて、設計のせいです。

厚労省のガイドライン6.0版のパブリックコメントが面白いんですよ。「ゼロトラスト思考の有効性は認められるものの、費用や管理に対する負担が大きいとされており、小規模の医療機関等で導入することは必ずしも容易ではない」という記載に対して、「ゼロトラストに否定的な印象を与える」と指摘した意見が寄せられている。つまり医療業界の内部からも「ゼロトラストを否定するような書き方はやめてくれ」という声が出ているわけです。境界防御にしがみつきたい人だけが反対しているわけではない。

確かにガイドラインは「ゼロトラスト思考に基づく対策を必須としているわけではない」と書いています。だが同時に「リスク分析の結果を踏まえ、費用対効果も考慮した上で判断する」とも書いている。これは「やらなくていい」とは言っていないんですよ。リスク分析をした結果、VPN装置が侵入経路になるリスクが高いと判明したら、対策しないこと自体がガイドライン違反になる。半田病院、大阪急性期、武蔵小杉。これだけ事例が積み上がって、VPN装置のリスクが高くないと言い張れるリスク分析があるなら見せてほしい。

「職員が使えない」という主張についてですが、ZTNAを正しく設計すると、エンドユーザーにとってはVPNより楽になるんですよ。絶対おZTNA触ったことないでしょ。VPNクライアントを起動して、接続先を選んで、認証して、タイムアウトしたらまたやり直して……という手順がなくなる。ブラウザでアプリケーションにアクセスするだけです。

「職員が使えない」のは、ゼロトラストの問題ではなく、ゼロトラストを正しく導入していない、あるいはそもそも導入した経験がないから想像で語っている、のどちらかです。

「VPN廃止という人は病院系の案件とってから、VPN廃止といったほうがいい」という反論

関係者ですよね。IT関係者が適当な仕事するから我が国のITはダメだとか言われるんですよ。

そしてガイドラインを読めば、厚労省自身が境界防御型思考の限界を認め、ゼロトラスト思考を推進し、VPN装置のリスクを認識した上でセキュリティ対策の義務化を行っていることは明白です。これは案件経験の有無に依存する話ではありません。

「案件をやっている」ことが免罪符になるなら、半田病院のFortiGateにパッチを当てなかったベンダーも案件をやっていた。大阪急性期・総合医療センターのVPN装置を管理していたベンダーも案件をやっていた。武蔵小杉病院のナースコールシステムの保守ベンダーも案件をやっていた。案件をやっていた結果がこれです。

「VPNは問題でも原因ではない。不摂生の結果だ」という指摘がありました。じゃあ病院のセキュリティにおける「不摂生」とは何か。パッチを当てない。MFAを導入しない。ネットワーク分離をしない。保守ベンダーに内部ネットワーク全体へのアクセスを許す。

これら全部、VPNというアーキテクチャが構造的に誘発する不摂生ですよね

VPN装置は、設置したら動く。動いたら触らない。触らないからパッチが当たらない。パッチが当たらないから脆弱性が放置される。脆弱性が放置されるから侵入される。この因果連鎖はVPNの「境界防御＋暗黙の信頼」というアーキテクチャが生む構造的な帰結です。不摂生の根本原因がVPNのアーキテクチャなのだから、VPNは原因そのものです。

反論に共通する構造的問題

全部の反論に共通しているのは「現状維持の正当化」です。

「ガイドラインが閉域前提だ」——6.0版で明示的に見直されています。ガイドラインを読んでください。

「予算がない」——診療報酬加算と補助金が整備されています。制度を使ってください。そして法的義務です。

「リモート保守できなくなる」——ZTNAでより安全にリモート保守できます。技術を学んでください。

「職員が使えない」——設計の問題であってゼロトラストの問題ではありません。正しく設計してください。

「案件やってから言え」——案件をやった結果がこの惨状です。規制と法令を読んでください。

彼らの言う「現実」とは、「VPNを設置して放置するのが楽だし儲かる」というベンダー側の都合です。病院の安全を守るための「現実」ではない。患者の個人情報を守るための「現実」ではない。

医療法施行規則第14条第2項。「サイバーセキュリティを確保するために必要な措置を講じなければならない」。VPN装置の脆弱性を放置することが「必要な措置」に該当しないことは、自明です。

武蔵小杉病院が1万人分の個人情報漏洩を発表した翌日に、「VPNでいいじゃん」と言える人たちがいる。その人たちが「病院系案件をやっている」人たちだというのが、この業界の闇です。

病院側はIT素人だからって適当な仕事ぶっこいてだまして金取ってるようなもんでしょ。捕まって欲しいくらいだよ。

さらに追記

「なんでもかんでもVPNのせいにするな」
ということだそうなので、これを読み解きます。
https://x.com/ntsuji/status/2022601527706386745

「『原因はVPN』と『経路はVPN』は違う。解像度が低い」という反論。

さすが辻さんというか、ここまで見てきた反論の中ではもっともまともな内容でした。そして技術者として正確でありたい気持ちは理解できます。

1.VPN機器の脆弱性悪用
2.脆弱性由来の認証情報窃取
3.その他の認証情報悪用

確かにこの3つは原因として別物です。 でもこの指摘、本記事の主張を補強しています。 どれが原因だったとしても、結果は同じです。VPN装置を突破した攻撃者が、内部ネットワーク全体にフルアクセスできた。ナースコールシステムの保守用VPNから入って、1万人分の患者情報が持ち出された。侵入の「原因」が脆弱性だろうがパスワードだろうがMFA不備だろうが、被害がネットワーク全体に波及する構造は変わらない。

というわけで辻さんが言っている「解像度を上げる」をやってみましょう。

1.の場合。VPN機器の脆弱性悪用。これは元記事で書いた通り、2024〜2025年だけでIvanti、SonicWall、Cisco、Palo Altoの4社がゼロデイを食らっています。パッチを当てても間に合わない。パッチが存在しない段階で攻撃される。設計と運用を見直しても防げない。

2.の場合。脆弱性由来で窃取された認証情報の悪用。これも1と本質は同じです。VPN装置の脆弱性を経由して認証情報が盗まれている時点で、装置がインターネットに露出していること自体が問題。ZTNAならそもそもコネクタがインターネットに公開されていないので、認証情報を窃取するための攻撃面が存在しない。

3.の場合。それ以外で取得された認証情報の悪用。ここが辻さんの主張の核心です。「p@sswordでMFAなしならVPN機器のせいではない」という話。本記事で言っているのは、VPN装置が「p@sswordでMFAなし」の状態で稼働し続けることを許容する構造自体がVPNのアーキテクチャの問題だということです。

クラウド型ZTNAではどうなるか。IdPとの統合が前提設計なので、MFAを強制する仕組みが標準で組み込まれている。デバイスポスチャチェックも標準。条件を満たさないデバイスからのアクセスは構造的にブロックされる。「p@sswordでMFAなし」という状態がそもそも成立しない設計になっている。

一方でVPN装置はどうか。ID/パスワード認証だけで動作する。MFAは「追加で導入する」もの。クライアント証明書認証も「追加で設定する」もの。セキュリティが「追加オプション」として設計されているんです。だから導入されない。だからp@sswordでMFAなしの装置が世の中に大量に存在する。

3のシナリオは、「設計と運用の問題であってVPNの問題ではない」と主張していますが、VPNが「脆弱な設計と運用を許容するアーキテクチャ」であること自体がVPNの問題です。これが本記事で書いた「Fragile by Design」の話です。

仮に辻さんの言う通り3のケースで、完璧な認証設計と運用をしたとしましょう。強固なパスワード。MFA有効。クライアント証明書も導入。ガイドライン完全遵守。それでも認証に成功した瞬間、内部ネットワーク全体へのフルアクセスが得られるという構造は変わらない。細かくマイクロセグメンテーションできてる組織ってそんなにあるんですかね。正規の認証を突破された場合、フィッシング、ソーシャルエンジニアリング、内部不正、被害がネットワーク全体に及ぶ。ZTNAなら、認証を突破されても、アクセスできるのは認可されたアプリケーションだけです。

「まずは設計や運用を見直すべき」という辻さんの主張

その設計の見直しの結論が脱VPNなんですよ。解決策が運用改善しかなかった時代とは違うんです。本記事でも書いてますが、正しく運用していれば事故は起きなかったなんて、そんなこと100も承知なのに事故が起き続けてるのはなぜなんでしょうか。辻さんが求めている「解像度の高い分析」をすればするほど、VPNのアーキテクチャが持つ構造的限界に行き着く。被害がネットワーク全体に波及するという帰結は変わらない。原因の解像度を上げた結果、経路の構造を変えるしかないという結論になるんです。いにしえの古代兵器にこだわる必要あるんですか？「脱VPN」の前に設計と運用を見直せ、は順序が逆です。設計と運用を見直した結果が「脱VPN」です。

わかりやすさを重視してVPN全体を否定しましたが

ここで問題にしてるのはSSL-VPNであってIPsec IKEv2の話ではありません。が、そんなことは多くの経営者には分かりません。
ZTNAを選ばずIPsec VPNを選択する合理的なケースは存在するので追記します。が、内容は技術者向けです。

医療機器のクローズドプロトコル保守

医療機器ベンダーが保守に使うプロトコルが、HTTP/HTTPSベースではなくRDP、独自プロトコル、またはDICOMなどの特殊プロトコルであるケース。ZTNAの多くはHTTP/HTTPSのアプリケーションプロキシとして動作するため、これらの非HTTPプロトコルを通すにはZTNA側の対応状況に依存します。

ZTNAベンダーによってはエージェントベースでTCP/UDPレベルのトンネリングを提供していますが、医療機器ベンダーが「このZTNAエージェントとの互換性を保証します」と言ってくれるかは別問題です。医療機器の保守契約がVPN経由を前提条件としている場合、ZTNA化するには保守契約の改定が先になる。

この場合の現実的な対応は、SSL-VPNを即座にIPsec IKEv2に置き換え、接続元IPを保守ベンダーの固定IPに制限し、接続時間帯を保守スケジュールに限定し、JIT（Just-In-Time）アクセスで常時開放をやめる。これだけでSSL-VPN放置よりもリスクは桁違いに下がります。

OTネットワークとの接続

医療機関に限らず、製造業やビル管理でも見られるパターンです。空調制御、エレベーター管理、自家発電設備など、OT（Operational Technology）系のシステムがネットワーク接続されている場合。これらのシステムはそもそもクラウドへのアウトバウンド通信を前提としていないことが多く、ZTNAコネクタの設置自体がOTネットワークのセキュリティポリシーに抵触する場合があります。

「OTネットワークからインターネットへのアウトバウンド通信を一切許可しない」というポリシーを採用している場合、クラウド型ZTNAのコネクタはそのポリシーと矛盾します。この場合、OTネットワークとITネットワークの接続点にIPsec VPNゲートウェイを置き、ファイアウォールで通信方向と宛先を厳密に制御するほうが、OTセキュリティの原則と整合します。

許可病床数200床未満の中小病院で情シス専任者がゼロ

日本の病院の約7割がここに該当します。情シスが兼務か外部委託。ITの意思決定者が事務長で、セキュリティの専門知識はない。年間のIT予算が数百万円規模。

この規模の病院にクラウド型ZTNAのライセンス費用（ユーザー単価×職員数×12ヶ月）、IdP（Okta、Entra ID等）の導入・運用費用、デバイス管理基盤の導入をいきなり提案しても通りません。予算的にも人的にも無理なものは無理です。

この場合の現実的な対応はこうなります。まず保守ベンダーが設置しているSSL-VPN装置を特定する。全台棚卸しする。これすらできていない病院が多い。次に、それらをIPsec IKEv2対応のUTMに置き換える。ファームウェア自動更新を有効にする。接続元IP制限をかける。MFAを入れる。常時接続をやめてJITにする。

ZTNAが理想なのは分かっているが、SSL-VPN放置→IPsec IKEv2＋アクセス制限という移行だけでも、リスクは劇的に下がります。「ZTNA以外は認めない」と言ったら、結果としてSSL-VPNが放置され続ける。それが最悪のシナリオです。

サイト間VPN（Site-to-Site）

これはそもそもリモートアクセスVPNとは文脈が違いますが、念のため。拠点間をIPsec Site-to-Siteで接続しているケース。本院と分院の接続、データセンターとの接続など。

サイト間VPNはインターネットに対してリスニングポートを公開する必要がなく（両端のIPが固定で、相互に認証する）、リモートアクセスVPNとは攻撃面が根本的に異なります。サイト間IPsec VPNを「脱VPN」の対象に含めるのは過剰です。リスクとして管理すべきは「不特定多数がインターネット経由でアクセスするリモートアクセスVPN」であって、拠点間の固定接続ではない。

まとめると辻さんが言いたかったことはこうなんじゃないかと予想

元記事で「VPNは悪」と書いたのは、あの文脈において正しい。武蔵小杉病院でやられたのはSSL-VPNベースの保守用リモートアクセスVPNであり、半田病院も大阪急性期も同じ構造です。

ただし、VPNを一律に悪として全面禁止を主張するのは非現実的だし、それをやると結局誰も動かない。現実に動かせるのは以下の優先順位です。

今すぐやめろ: SSL-VPN（リモートアクセス用途）。特に保守ベンダー用。代替はZTNA。ZTNAが無理ならIPsec IKEv2＋IP制限＋MFA＋JIT。

中期的に移行しろ: IPsec リモートアクセスVPN。ZTNAへの移行を計画し、保守契約更新のタイミングで切り替える。

急がなくていい: IPsec Site-to-Site。攻撃面が異なるため、リモートアクセスVPNとは優先度が違う。

最悪なのは「ZTNAが理想だけど無理だから何もしない」です。SSL-VPNをIPsecに変えるだけでも、IPsecにMFAとIP制限を足すだけでも、保守用VPNをJITにするだけでも、やれることからやってくれ。それが「現実的なリスク管理」です。

初回追記分の参考情報：

• 厚生労働省「医療法施行規則の一部を改正する省令について」（令和5年3月10日公布、4月1日施行）

• 厚生労働省「医療情報システムの安全管理に関するガイドライン 第6.0版」全4編（令和5年5月）

• 厚生労働省「医療情報システムの安全管理に関するガイドライン第6.0版 Q&A」（令和7年5月）

• 厚生労働省 医療分野のサイバーセキュリティ対策について（公式ページ）

• 中医協総会「2024年度診療報酬改定」答申（診療録管理体制加算1新設・医療DX推進体制整備加算新設）

• デジタル庁「ゼロトラストアーキテクチャ適用方針」（令和4年6月30日）

• 厚生労働省「医療情報システムの安全管理に関するガイドライン第6.0版（案）に関する御意見の募集について」パブリックコメント回答

本文の参考情報：

• 日本医科大学武蔵小杉病院「当院へのサイバー攻撃による個人情報漏洩に関するご報告とお詫び（第2報）」（令和8年2月14日）

• Zscaler ThreatLabz 2025 VPN Risk Report（2025年4月, Cybersecurity Insiders委託）

• Verizon 2025 Data Breach Investigations Report（DBIR）

• Norwegian NCSC「Anbefaler å erstatte SSLVPN/WebVPN med sikrere alternativer」（2024年5月）

• UK NCSC「Zero trust architecture design principles」Version 1.0

• BSI「Positionspapier Zero Trust 2023」（2023年6月）

• CISA Emergency Directive 24-01 / 25-03

• CISA「Modern Approaches to Network Access Security」（2024年6月）