医療情報システム安全管理ガイドライン第7.0版（2026年6月）改訂まとめ— 医療機関にシステムを提供する事業者が今すぐ確認すべき3点

1. 何が起きたのか

2026年6月29日、厚生労働省が「医療情報システムの安全管理に関するガイドライン 第7.0版」を策定しました（産情発0629第1号）。前版の第6.0版は令和5年5月策定なので、約3年ぶりの改定です。

改定の背景として、策定通知は次の3点を挙げています。

1. 第6.0版の公表以降も医療機関等を対象としたサイバー攻撃事案の発生が継続していること
2. サイバー対処能力強化法（重要電子計算機に対する不正な行為による被害の防止に関する法律・令和7年法律第42号）の成立を背景に、社会的関心と重要性が高まっていること
3. 内閣官房国家サイバー統括室（NCO）による「重要インフラのサイバーセキュリティに係る安全基準等策定指針」の改定、および経産省・総務省の2省ガイドラインが第2.0版に改定されたこと

つまり今回の改定は「新しい脅威が出たから」というより、周辺の法制度と他のガイドラインが動いたことへの整合合わせという性格が強いものです。事業者側にとっては、後述する保守委託機関編を除けば、要求事項そのものが大きく増えたわけではありません。

構成は4編から5編になりました。

2. 事業者に直接効く3つの変更

2-1. 保守委託機関編の新設 —— 効いてくるのは「契約書の1行」です

新設された保守委託機関編は、専任のシステム担当者が不在で、セキュリティアップデートを含む保守を事業者に十分に委託している小規模医療機関等を対象としています。同編の対象となる医療機関等を、ガイドラインは「保守委託機関」と呼びます。

ここは用語を取り違えやすいところなので、先に整理しておきます。

「保守委託機関」＝保守を委託している側（医療機関）です。保守を受託する事業者のことではありません。

この編が画期的なのは、みなし遵守を導入した点です。すべてのサーバのセキュリティアップデートを事業者に委託している医療機関等は、保守委託機関編を遵守することで、その他の編の項目も遵守できているものとみなされます。専門人材がいない小規模医療機関にとっては、対応すべき項目が大幅に絞り込まれることになります。

では事業者側は何を確認すればよいのか。判断フローチャートの注記が、そのまま答えになっています。

「事業者がセキュリティアップデート責任を負うこと」が、契約書や約款、サービスレベル合意書等に記載されている場合にのみ「YES」を選択可能となる。記載がない場合や不明確な場合には医療機関側の責任となっている可能性がある。（保守委託機関編 図1 注記※2）

つまり、顧客である医療機関が「みなし遵守」の恩恵を受けられるかどうかは、あなたの会社の契約書・約款・SLAに「セキュリティアップデート責任は事業者が負う」と書いてあるかどうかで決まります。

これは実務上、次の2つを意味します。

• リスク: 記載がなければ、顧客は保守委託機関編を使えません。結果として顧客はシステム運用編まで含めた全編対応を自力で求められることになり、その負担は「このベンダを使うと大変」という評価に直結します。
• 機会: 逆に言えば、契約書・約款・SLAにこの1行を明記し、「当社をご利用の場合、貴院は保守委託機関編の対象となります」と説明できる事業者は、小規模医療機関に対する明確な差別化要因を持てます。SaaS型の電子カルテ・部門システム・AIサービスを提供している事業者にとっては、そのまま提案書の1ページになります。

なお、ここでいう「サーバ」には注意が必要です。医療情報の保存や主要な処理を担う機器を指し、原則としてPCやタブレット等のクライアント端末は含みませんが、電子カルテアプリ等を端末にインストールし、その機器上で処理が完結する場合はPC等の端末も「サーバ」に含まれます。オンプレ端末で完結する構成が1台でも残っていると「すべてのサーバ」の条件を満たさない可能性がある、という点は顧客への説明時に押さえておくべきところです。

2-2. 二要素認証 —— 「令和9年4月1日」はベンダ選定の要件として降ってくる

7.0版では、二要素認証の導入について医療情報システムのうちクライアント端末およびサーバにおいて対応することが明確化されました。あわせて、これまで対象が明確でなかった経緯を踏まえ、令和9年4月1日時点での対応が困難な医療機関等については、次期システム改修での対応を許容する緩和措置が設定されています。

事業者にとっての勘所は、緩和措置の書きぶりです。保守委託機関編の遵守項目は、猶予を使う場合の条件をこう書いています。

クライアント端末のアプリケーションログイン時には、令和9年度までに二要素認証を採用すること。対応が困難な場合には、令和9年度以降のシステム更新時に対応可能な事業者を選定すること。（保守委託機関編 9章 ④。オンプレミスのサーバがある場合はOSログイン時についても同様の規定が⑤にあります）

猶予は「対応しなくてよい」ではなく、「次の更新のときに対応できる事業者を選べ」という形で設計されています。医療機関が今すぐ二要素認証に対応できなくても、次期更新の候補に残るには事業者側の対応が前提になる、ということです。

自社サービスが二要素認証に未対応の場合、令和9年（2027年）度の更新サイクルで候補から外れるリスクがあります。逆に対応済みであれば、これは提案時に明示すべき要件です。

なお、MDS/SDSの様式（後述）では、この点について「二要素認証に対応済、もしくは医療機関等の次期システム更改までに二要素認証とみなすことが可能な措置に対応予定の場合は「はい」を選択してください」と注記されています。ロードマップとして対応予定が示せるかどうかが、書類上の分岐点になります。

2-3. MDS/SDS —— 99項目が「選定基準」として明文化されました

保守委託機関編には【別紙】として「MDS/SDS におけるセキュリティ確認事項」が付いており、MDS 41項目・SDS 58項目（計99項目）が具体的に列挙されています。

そして本文には、こう書かれています。

医療情報システムを事業者から導入し、運用などを委託している場合には、可能な限りMDS/SDSを事業者から入手すること。このうち、本編末尾の【別紙】で示すMDS/SDSの項目について十分に対応できている必要がある。【別紙】のすべてにおいて「はい」または「対象外」となっている事業者を選定すること。
「いいえ」が選択されているMDS/SDSを含む事業者を選定する場合や、約款に十分な記載がない場合は、各項目について十分なリスク評価、リスク対応を実施し、立入検査や監査等の際に適切な説明が可能な状態とすること。（保守委託機関編 10章解説）

これは事業者にとって、事実上の合格ラインが公開されたことを意味します。

• 別紙の項目に1つでも「いいえ」があると、顧客側に追加のリスク評価と、立入検査・監査での説明責任が発生します。多くの小規模医療機関にとって、これは現実的なハードルです。
• 裏返せば、別紙の99項目をすべて「はい」または「対象外」で回答できる状態を作っておけば、その事業者は「選定してよい事業者」として書類上クリアになります。

別紙でカバーされている領域は、SDS側で言えば、システム設計・運用に必要な規程類（BCP手順書・非常時アカウント管理手順の提供可否）、責任分界（契約への安全管理条項、管理責任範囲の文書提示）、リスクアセスメント、標準化対応（データの標準形式での出力入力）、情報管理（持出時の暗号化、機器廃棄時の確認）、事業者による保守対応（作業後のデータ消去、保守アカウントの専用運用、リモート保守時のアクセスログ）、システム運用管理（非常時アカウント、複数世代・複数方式のバックアップ、復元手段）、物理的安全管理、ネットワーク（通信方式は専用線／IP-VPN／IPsec-VPN+IKE／TLS1.2高セキュリティ型以上のクライアント認証のいずれか）、認証・認可、電子署名・タイムスタンプ、証跡のレビュー・システム監査、外部からの攻撃 —— と広範です。

新規参入の事業者ほど、「BCP手順書を医療機関に提供できるか」「保守作業の記録を提供できるか」といった、機能ではなく書類・運用体制を問う項目でつまずきます。開発を止めずに準備できる項目が多いので、営業が本格化する前に着手しておく価値があります。

3. その他の改定点（押さえておくべきもの）

パスワードの「定期的な変更」要件は削除されました

7.0版では、パスワードルールについて使い回しの禁止とアカウントロックの導入が追記された一方、「定期的な変更」の要件は、セキュリティ面の強化につながらないとされ削除されました。

自社サービスの仕様や、顧客向けのセキュリティ説明資料に「ガイドラインに基づき90日ごとのパスワード変更を強制しています」といった記述が残っている場合、それはもう根拠を失った説明です。強制変更の実装自体が直ちに違反になるわけではありませんが、ガイドラインを根拠として説明することはできなくなりました。地味ですが、資料の鮮度が見られるポイントです。

サプライチェーンリスク・役割分担・リスクコミュニケーション

関連法令にサイバーセキュリティ基本法が追加され、サプライチェーンリスクについて追記されました。また2省ガイドライン第2.0版への改定を受け、医療機関等と事業者との役割分担、および医療機関とのリスクコミュニケーションが追記されています。

事業者側で言えば、再委託先を含めた体制の説明資料、責任分界の文書、インシデント時の連絡フローが、契約や監査の場で問われる頻度が上がるということです。前述のSDS項目にも「外部委託先にも同等の個人情報保護対策を契約で義務付けているか」「標的型攻撃発生時の連絡手段を準備しているか」が含まれています。

クラウドサービスの積極的な活用を推進する旨が追記されました

7.0版は、クラウドサービスの積極的な活用を推進する旨を明記しています。保守委託機関編そのものが「SaaSへの移行が容易な小規模医療機関等」を主な対象として設計されていることと合わせて読むと、クラウド／SaaSは「認められている」段階から「推奨される」段階に進んだと読めます。オンプレミス前提の商慣行に対して、SaaS事業者が正面から提案しやすくなる改定です。

4. 誤解しやすい点

「パスワードの定期変更が削除された＝要件が緩和された」ではありません。削除の理由は「セキュリティ面の強化につながらない」という有効性の評価であって、代わりに使い回しの禁止とアカウントロックが入っています。求められる水準はむしろ上がっています。

「みなし遵守があるから顧客は何もしなくてよい」ではありません。条件は「すべてのサーバのセキュリティアップデート責任を事業者に委託している」ことです。1台でも自院管理のサーバ（前述のとおり、処理が完結するPC端末を含む）が残っていれば、フローチャートは「NO」になり、通常どおり全編が対象になります。「うちのSaaSを入れればみなし遵守になります」という説明は、顧客の環境全体を確認しないまま行うと不正確です。

「令和9年4月1日までに二要素認証が必須」と単純化するのも不正確です。対応が困難な医療機関等には次期システム改修までの猶予があります。ただしその条件は「次期更新時に対応可能な事業者を選定すること」であり、事業者側から見れば結局、その時点までに対応していなければ選定候補から外れるという構造です。

「保守委託機関」は事業者ではなく医療機関を指します。資料や提案書で用語を取り違えると、この改定を読んでいないことがすぐ伝わってしまいます。

5. 今すぐできる確認（事業者向けチェック）

• 契約書・約款・SLAに「セキュリティアップデート責任は事業者が負う」旨の記載があるか（なければ、顧客は保守委託機関編を使えません）
• 自社サービスがクライアント端末およびサーバのログインで二要素認証に対応しているか。未対応なら、いつ対応するかのロードマップを顧客に示せるか
• MDS/SDSを整備しているか。保守委託機関編【別紙】の99項目で「いいえ」になる項目がいくつあるか
• BCP手順書・非常時アカウント管理手順・保守作業記録を、顧客に提供できる形で用意しているか
• 顧客向けのセキュリティ説明資料で、ガイドラインの版数が「第6.0版」のままになっていないか。パスワード定期変更を根拠として説明していないか
• 再委託先がある場合、同等の個人情報保護対策を契約で義務付けているか

6. まとめ

第7.0版は、事業者にとって「新しい技術要件が大量に増えた改定」ではありません。むしろすでに求められていたことが、契約書の記載・MDS/SDSの回答・ベンダ選定の条件という形で、より具体的な書類レベルに落とし込まれた改定です。

そのぶん、対応の可否が目に見える形で比較されやすくなりました。保守委託機関編の【別紙】99項目は、顧客が事業者を選ぶときのチェックリストとして、そのまま使えるものだからです。

医療機関への提供を始めたばかりの事業者や、これから医療分野に参入する事業者にとっては、製品開発と並行して、契約書・MDS/SDS・運用文書を揃えておくことが、そのまま商談を前に進める準備になります。