医療機関に求められているのは、脆弱性情報を知ることだけではありません。厚労省のシステム運用編は、企画管理者に対して、医療情報システムが利用する情報機器等の脆弱性情報を常に収集し、速やかに対応する必要があるとしています。さらに、近年は脆弱性やEOS対象機器が攻撃対象になっているとし、OSやセキュリティ製品の提供事業者に加え、NISCやIPAなどの情報も確認し、必要に応じて事業者に対応を確認して最新情報を入手することが重要だと述べています。

一方で、厚労省は「必ず即時適用」とまでは書いていません。同じシステム運用編では、脆弱性対策が他のソフトウェアの動作等へ影響することも想定されるため、事前に事業者へ実施可否を確認し、対応が難しい場合には、当該リスクへの対策や管理方法を協議した上で代替策を講じる必要があるとしています。しかも、この考え方は検査装置等に付属するシステム・機器についても同様だと明記されています。つまり、医療機関に必要なのは「全部すぐ当てる」だけではなく、当てられないものを説明可能な形で管理することです。

ここで重要なのは、「脆弱性例外管理台帳」という名称や全国一律の様式そのものは、少なくとも今回確認した厚労省資料には明示されていないということです。
これは確立された事実です。
したがって、以下で示す「例外管理台帳」は、厚労省が求めている台帳管理、脆弱性情報収集、代替策、年次点検、目標日管理を、実務で回せる形に再構成したものです。ここは専門家の見解として扱うのが正確です。

1. 台帳の出発点は「資産台帳の延長」に置く

厚労省のチェックリストマニュアルは、サーバ、端末PC、ネットワーク機器の台帳管理を求めており、管理内容として所在、利用者、ソフトウェアやサービスのバージョンなどを想定しています。これは、脆弱性対応の議論が「どの機器の、どの版数に、何が当たるのか」を引ける状態でなければ始まらないことを意味します。したがって、例外管理台帳は、別物として完全に独立させるより、資産台帳で把握している機器に“未適用情報”を重ねる形で作る方が運用しやすいです。これは公的要求に基づく専門家の見解です。

2. 最低限入れるべき項目

公的資料に照らして、実務上は少なくとも
対象機器・システム名、設置場所、バージョン、保守契約先、対象脆弱性または更新情報、未適用理由、事業者確認日、代替策、再判定予定日、責任者
を持たせるのが妥当です。
この列項目自体は厚労省の定型様式ではありませんが、厚労省が求める台帳管理、事業者への実施可否確認、代替策の実施、目標日管理を一体で回すには、この程度の情報が必要です。

3. 「未適用理由」は主観ではなく根拠で残す

厚労省が求めているのは、単なる見送りではなく、事業者に実施可否を確認したうえで、難しい場合には代替策を講じることです。したがって、未適用理由は「影響がありそう」では弱く、少なくとも
ベンダー未対応、他ソフトへの影響、医療機器の動作保証未確認、診療停止リスク、EOS、クラウド事業者側の適用待ち
のように、再確認できる根拠付きの分類で残すべきです。これは厚労省の要求を監査・再判定に耐える形へ落とした専門家の見解です。

4. 暫定措置は「やった」と書くだけでは足りない

厚労省は、パッチ適用が難しい場合の代替策として、不要サービスや通信ポートの停止、ネットワーク分割、アクセス制御、マクロ停止、メールやファイルの無害化、EDRや振る舞い検知などを挙げています。したがって、例外管理台帳には、未適用理由だけでなく、何の暫定措置を講じたかを紐づける必要があります。
実務上はさらに、誰が確認したか、いつ設定したか、関連する設定変更票やログがどこにあるかまで持てると、説明可能性が高まります。前半は確立された事実、後半はそれを実務化した専門家の見解です。

5. 再判定予定日を持たない例外は、実質的に放置になる

チェックリストマニュアルは、各項目の実施状況を**「はい」「いいえ」で記入し、「いいえ」の場合は令和7年度中の目標日を記入するよう求めています。また、少なくとも年に1回はチェックリストを用いた点検を実施し、結果は日頃の対策に役立てるよう示しています。したがって、例外管理でも、再判定予定日を必須にしないと、例外が固定化します。
この「目標日管理を例外台帳へ持ち込む」という整理は、チェックリスト運用の考え方を実務へ展開した専門家の見解**です。

6. EOSは“例外”ではなく“更改案件”として扱う

厚労省は、近年の攻撃ではEOSの対象となった情報機器等を攻撃する例が多いと説明しています。これは、EOS機器を「今は仕方ない」で長期継続することの危険性を示しています。したがって、EOS理由の未適用案件は、例外管理台帳に載せるだけでなく、更改予定時期、必要予算、責任者を持たせて、経営判断に上げるべきです。
前半は確立された事実、後半の「更改案件として扱うべき」は実務上の専門家の見解です。

7. リモート保守やMDS/SDSの情報も結びつける

チェックリストマニュアルは、リモートメンテナンス（保守）を利用している機器の有無を事業者に確認すること、さらにMDS/SDSを提出してもらうことを求めています。MDS/SDSは、医療情報システムのセキュリティに関するリスク評価・リスク管理に有効な資料とされています。したがって、例外管理台帳には、保守経路があるか、関連するMDS/SDSの有無も紐づけておくと、例外の背景説明がしやすくなります。これは公的資料に基づく専門家の見解です。

8. 緊急対応で生じた例外は、事後承認の証跡も残す

厚労省は、保守や緊急脆弱性対応について、原則は事前申請・承認でありつつ、緊急を要する場合は事後承認も想定しています。したがって、緊急対応で一時的に例外設定をした場合は、例外管理台帳に起点情報、判断者、実施者、実施日時、事後承認日まで残すべきです。
この「事後承認の証跡台帳としても使う」という整理は、厚労省の原則・例外運用を実務化した専門家の見解です。

9. 年1回点検だけでなく、日常の変更管理と連動させる

チェックリストマニュアルが求めるのは少なくとも年1回の点検ですが、それだけでは不十分です。厚労省のシステム運用編は、脆弱性情報の継続収集と速やかな対応を求めています。したがって、例外管理台帳は年1回開く資料ではなく、更新見送り、緊急変更、ベンダー回答、機器更改のたびに更新する台帳として運用する方が、厚労省の趣旨に合っています。これは公的要求を運用へ落とした専門家の見解です。