医療機関のセキュリティ対策を検討すると、議論はどうしても院内に向かいます。職員の教育、端末の管理、電子カルテのアクセス権限。いずれも重要ですが、公表されている被害事例に共通する構造を見ていくと、入口が院内になかったケースが目立ちます。
保守用に設置された機器の既知脆弱性。部門システムのために引かれた個別の回線。医療機器メーカーの遠隔監視の仕組み。関連施設との間に張られた接続。いずれも、必要があって導入されたものです。そして多くの場合、導入した部門と、セキュリティを見ている部門が違います。
サプライチェーンリスクとは、この「必要があって作られ、誰も全体を見ていない接続」の集合です。本記事では、医療機関のサプライチェーンがどういう構造でリスクを抱えるのかを整理し、限られた体制で把握を進める優先順位と、契約・運用での手当てを扱います。
免責：本記事は一般的な情報提供です。特定の医療機関の被害事例を扱うものではなく、公表されている事例に共通する構造をパターンとして整理しています。ガイドラインの要求事項は厚生労働省および経済産業省・総務省の公表資料が正本です。
リスクが入ってくる4つの経路
医療機関のサプライチェーンリスクは、大きく4つの経路に分けて考えると整理しやすくなります。
| 経路 | 具体例 | 見えにくい理由 |
|---|---|---|
| ① 委託先の委託先 | 電子カルテ事業者が使うクラウド基盤、監視SaaS、オフショア開発 | 契約相手の背後にあり、医療機関から直接は見えない |
| ② 部門システム | 検査、透析、リハビリ、健診、給食などの個別システム | 導入した部門が窓口を持ち、情報システム部門が把握していない |
| ③ 医療機器・保守経路 | 画像診断装置、生体情報モニタ、遠隔監視、保守用回線 | 「機器」として導入され、ネットワーク機器として管理されていない |
| ④ 取引先・関連施設 | 検査センター、薬局、訪問看護、グループ施設との接続 | 相手先の対策水準を医療機関がコントロールできない |
この4つに共通するのは、セキュリティ上の問題として認識される前に、業務上の必要として導入されていることです。誰かが手を抜いたわけではありません。だからこそ、個別の注意では解決せず、構造として把握する仕組みが要ります。
3省2ガイドライン（厚生労働省「医療情報システムの安全管理に関するガイドライン」第6.0版）は、対象を「全ての医療情報システムの導入、運用、利用、保守及び廃棄に関わる者」としています。電子カルテだけが対象ではありません。ガイドラインの全体像は 3省2ガイドラインとは をご覧ください。
① 委託先の委託先が見えない問題
医療機関が契約するのは、目の前の事業者1社です。しかしその背後には、基盤クラウド、監視サービス、CDN、メール配信、開発の外注先が並びます。この連鎖が見えないと、事故が起きたときに原因の所在すら把握できません。
チェックシートで「再委託はありますか」と聞いても、「ありません」と返ってくることがあります。悪意ではなく、業界の慣行としてクラウド利用を再委託と呼ばない文化があるためです。実務上の対処は単純で、質問文に一言足すことです。
本件業務で再委託を行いますか。クラウドサービスの利用を含めて、基盤・監視・開発・サポートの各層について記載してください。
この一文があるかどうかで、回答の質が変わります。さらに押さえておくべきは次の3点です。
| 確認項目 | なぜ必要か |
|---|---|
| 再委託先の名称・所在国・業務内容 | 名前が出てこない委託先は、管理されていない可能性がある |
| 再委託先の安全管理措置の確認方法 | 確認の方法がなければ、再委託は管理の断絶点になる |
| 再委託先を変更する場合の事前通知 | 委託先は契約期間中に変わる。通知がなければ把握が途切れる |
3つ目が実務上いちばん重要です。契約時点で連鎖を確認しても、1年後には変わっていることがあります。「再委託先を変更する場合は事前に通知する」条項の有無が、把握の継続性を左右します。質問の具体的な形は 事業者に確認すべき質問リスト、シートの設計は ベンダーへのセキュリティチェックシート にまとめています。
事業者側から見ると、この連鎖を説明できる状態を作るには、自社の委託先管理が整理されている必要があります。ISO/IEC 27001（ISMS）の附属書Aには組織的管理策として委託先管理に関する項目が含まれており、認証を持つ事業者は、少なくとも委託先を管理する仕組みを持っていることが第三者に確認されていることになります。認証の意味と適用範囲の読み方は ISMS（ISO/IEC 27001）とは をご覧ください。
② 部門システムという死角
大きな医療機関ほど、電子カルテ以外に多数のシステムが動いています。検査、透析、リハビリ、内視鏡、健診、給食、勤怠。これらは導入経緯が部門ごとに異なり、窓口も契約も部門が持っていることが少なくありません。
生じる問題は次のとおりです。
- 情報システム部門が存在を把握していない — ネットワーク図に載っていないサーバがある
- 保守の連絡先が部門にしかない — 事故時に誰に連絡すべきか、院内で分からない
- リモート保守の経路が個別に引かれている — 事業者ごとに別のVPNやリモートツールが入っている
- OSが古いまま更新されない — 装置に付属するPCがサポート切れのOSで動き続ける
- 電子カルテと連携している — 単独なら影響は限定的でも、連携があれば波及する
このうち 3と4が最も危険です。公表されている被害事例に共通する構造として、保守用に設置された機器やリモート接続経路が侵入口になったパターンが繰り返し指摘されています。部門ごとに別々のリモート保守経路が引かれていれば、その数だけ入口があることになります。
対処の第一歩は、接続の棚卸です。完璧なネットワーク図を作る必要はありません。次の5列の表を、部門にヒアリングして埋めるだけでも、見える景色が変わります。
| 列 | 記入内容 |
|---|---|
| システム名 | 部門での通称でよい |
| 事業者・連絡先 | 保守窓口と、緊急時の連絡先 |
| 外部接続の有無 | 院外とつながる経路があるか（VPN、専用線、インターネット） |
| リモート保守 | 事業者が遠隔で入るか。方式と、その都度の申請の有無 |
| 電子カルテ連携 | 連携の有無と方向 |
この表が埋まらない行が、そのまま優先的に調べるべき対象になります。資産管理とネットワークの考え方は ネットワーク分離と資産管理、リモート保守の管理は リモートメンテナンスの安全管理 で扱っています。
③ 医療機器と保守経路
医療機器は、ネットワーク機器としての管理から外れやすい領域です。理由は3つあります。
1. 導入の主体が医療部門である
装置は診療上の必要から選定され、ネットワーク要件は付随事項として扱われます。情報システム部門が仕様を見ていないことがあります。
2. 更新のサイクルが長い
画像診断装置などは10年以上使われます。その間にOSのサポートは終了しますが、装置の薬事上の構成を変更できないという事情があり、更新が簡単ではありません。
3. 遠隔監視が前提になっている
装置メーカーによる稼働監視・予兆保全は、可用性を高める仕組みです。しかしそれは、外部からの常時接続が存在するということでもあります。
これらは「だから危険だ」という話ではなく、管理の枠組みに入れる必要があるという話です。現実的な対処は次のとおりです。
| 対処 | 内容 |
|---|---|
| 台帳に載せる | ネットワークに接続する医療機器を資産台帳に含める。OSとサポート状況を記録する |
| 分離する | 更新できない機器は、ネットワークを分離して影響範囲を限定する |
| 経路を限定する | 遠隔監視の通信先・プロトコル・時間帯を限定する |
| 契約に書く | 脆弱性が公表された場合のメーカーの対応（情報提供・対策の提供）を保守契約に明記する |
| 責任の所在を決める | 機器のファームウェア更新を誰が行うかを、契約を並べて確認する |
最後の行が抜けやすい箇所です。装置メーカーは「機器の保守は当社、ネットワークは別」と考え、ネットワーク業者は「回線は当社、機器のファームウェアは対象外」と考える。結果として誰も見ていない状態が生まれます。契約を並べて、機器ごとに「ファームウェア更新は誰の責任か」を確認してください。責任分界の書き方は SLAと責任分界の書き方 と 責任分界点の決め方 をご覧ください。医療機器固有の論点は ネットワーク接続医療機器のセキュリティ で扱います。
④ 取引先・関連施設経由
検査センター、薬局、訪問看護ステーション、グループ内の他施設。地域連携やグループ運営のために接続されている経路も、リスクの経路になり得ます。
この領域の難しさは、相手先の対策水準を医療機関がコントロールできないことです。委託先であれば契約で要求できますが、対等な連携先や、規模の小さい取引先には同じ要求ができないことがあります。
現実的な考え方は、「相手の水準を上げる」より 「接続の粒度を下げる」 ことです。
- 接続を必要最小限にする — 全体をつなぐのではなく、必要なデータ交換の経路だけを開ける
- 方向を限定する — 一方向の送信で足りるなら、双方向にしない
- 認証を分ける — 連携用のアカウントを職員アカウントと分離し、権限を絞る
- ログを取る — 連携経由のアクセスを記録し、定期的に確認する
- 遮断手順を決める — 相手先で事故が起きたとき、どの経路をどう切るかを事前に決める
5つ目が重要です。連携先で侵害が起きたという連絡を受けたとき、どの接続を誰の判断で切るのかが決まっていないと、初動が止まります。インシデント対応計画に、連携経路の遮断手順を含めておいてください。詳しくは 医療機関のインシデント対応計画 を参照してください。
限られた体制で、どこから手を付けるか
すべてを一度に把握するのは現実的ではありません。優先順位は次の観点で付けてください。
| 優先度 | 対象の条件 |
|---|---|
| 最優先 | 外部から常時接続があり、電子カルテと連携しているもの |
| 高 | 外部接続があるが、電子カルテとは連携していないもの |
| 中 | 外部接続はないが、院内ネットワークに接続しており、OSが更新されていないもの |
| 低 | スタンドアロンで、可搬媒体のやり取りのみのもの |
最優先は「外部接続 × 電子カルテ連携」の掛け算です。ここに該当するものが把握できていない状態は、リスクの大きさに対して見通しが立っていないことを意味します。
そして、この棚卸の主体を決めることが出発点になります。2026年度診療報酬改定で新設された電子的診療情報連携体制整備加算は、共通要件として専任の医療情報システム安全管理責任者の配置を求めています。この役割に、院内の接続の棚卸と維持を明示的に含めておくと、属人的にならずに済みます。責任者の職務設計は 医療情報安全管理責任者の役割と選任、改定の全体像は 2026年度診療報酬改定 をご覧ください。
まとめ
医療機関のサプライチェーンリスクについて、押さえるべき点は次のとおりです。
- リスクの経路は4つ——委託先の委託先／部門システム／医療機器と保守経路／取引先・関連施設
- 再委託は「クラウドサービスの利用を含めて」と書かなければ出てこない。変更時の事前通知条項も入れる
- 部門システムは接続の棚卸を5列の表で始める。完璧なネットワーク図は要らない
- 医療機器は、ファームウェア更新の責任者を契約を並べて確認する。誰も見ていない状態が生まれやすい
- 取引先・関連施設は、相手の水準を上げるより接続の粒度を下げる。遮断手順を事前に決める
- 優先順位は「外部接続 × 電子カルテ連携」の掛け算で付ける
- 棚卸を安全管理責任者の職務に明示し、属人化させない
サプライチェーンの把握は、一度やって終わりではなく、接続が増えるたびに更新が要る継続的な作業です。最初の棚卸をどう設計するか、既存の委託先にどう確認するかといった段階から整理したい場合は、お問い合わせ からご相談ください。委託先側で体制の証明を求められている事業者の方には、ISMS認証取得支援サービス もご案内しています。
参考・出典
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
- 医療情報システムの安全管理に関するガイドライン 第6.0版（本文PDF）｜厚生労働省
- 令和8年度診療報酬改定について｜厚生労働省
- 情報処理推進機構（IPA）
- 内閣サイバーセキュリティセンター（NISC）
※本記事は公表されている事例に共通する構造をパターンとして整理したものであり、特定の事案を扱うものではありません。ガイドラインの要求事項および診療報酬の算定要件は改定により変わります。