医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン第2.0版｜対象事業者・義務・合意形成の実務

総務省と経済産業省の「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」は、2026年10月時点で第2.0版（令和7年3月改定）が現行版です。医療機関に電子カルテやクラウドを提供する事業者、その基盤事業者、保守会社が従う文書で、別紙1では2省ガイドラインと略されています。本記事では、対象事業者の範囲、負う義務、医療機関に開示して合意する内容を本文・別紙1・FAQから整理し、開発だけを受ける案件と運用保守まで受ける案件の違いを受託開発会社の立場から切り分けます。3省2ガイドラインという呼び方や医療機関側の改定点は3省2ガイドラインと第7.0版の改定点を整理した記事に分けました。

まとめ：提供事業者向けガイドライン第2.0版で事業者が先に固める4つの事項

• 現行版は第2.0版です。経済産業省の掲載ページに本文、別紙1、別紙2、FAQがまとまっています。第1.1版（令和5年7月）の資料で合意文書を作るのは避けてください。
• 最初に確かめるのは、自社が対象事業者かどうかです。医療機関と運用・管理・保守の契約がある事業者に加え、直接の契約がない再委託先やクラウド基盤の事業者も対象に入ります。売買契約だけで納入が終わる場合は対象外です。
• 次に、表4-1の情報提供項目を揃えます。保存場所の国、バックアップの状況、第三者認証、全体構成図、リスク対応一覧などで、別紙1のサービス仕様適合開示書とSLA参考例がそのまま下書きになります。
• 対策は一律の要求事項ではなく、第5章のリスクマネジメントで決めます。ただし別紙2の全対策項目への対応確認は必須とされ、採用しない項目には合理的な理由が求められます。

2省ガイドラインの位置づけと第2.0版までの改定経緯・厚労省版との関係

中身に入る前に、この文書がどの旧ガイドラインを引き継ぎ、厚生労働省のガイドラインとどうつながるのかを押さえます。版の取り違えは、開示書の作り直しに直結します。

総務省と経済産業省の旧ガイドライン2本を統合した令和2年8月の経緯

以前は、総務省の「クラウドサービス事業者が医療情報を取り扱う際の安全管理に関するガイドライン」と、経済産業省の「医療情報を受託管理する情報処理事業者における安全管理ガイドライン」が別々に存在していました。外部保存をクラウドで提供する事業者は両方を参照する必要があり、記載の観点も違っていたため負担が大きかったと、第2.0版の第1章は説明しています。

そこで令和2年8月に2本を統合したのがこのガイドラインです。一律の要求事項を並べる方式をやめ、リスクベースアプローチによるリスクマネジメントのプロセスを定義し、医療機関との共通理解と明示的な合意を重視する方針に切り替えました。

第1.0版から第2.0版までの改定履歴と第2.0版で明確化された3点

第2.0版本文の冒頭にある改定履歴を並べました。

第2.0版の改定概要は、対象事業者の明確化、事業者と医療機関等の間の合意内容の明確化、リスクコミュニケーションの実効化の3点です。総務省の報道発表によれば、案は令和6年10月2日から31日まで意見募集にかけられ、17件の意見が寄せられました。

厚生労働省の第7.0版と別紙2の対応表が第6.0版のまま残る時点の注意

医療機関側の「医療情報システムの安全管理に関するガイドライン」は、厚生労働省の掲載ページのとおり令和8年6月に第7.0版へ改定されました。一方、2省ガイドラインの別紙2は「統合前ガイドラインにおける対策項目一覧と医療情報安全管理ガイドライン6.0版の対応表」のままです。2026年10月時点で、経済産業省の掲載ページに第7.0版対応の改定版は出ていません。

FAQは、医療情報システム特有の考慮事項は厚労省ガイドラインの改定に伴って変わる可能性があり、事業者は最新の厚労省ガイドラインを考慮して対策を実施する必要があると答えています。つまり別紙2で第6.0版との対応を確かめたうえで、第7.0版で加わった二要素認証や保守委託機関編の要件を自社で上乗せする必要があります。医療機関側の5編の中身は第7.0版の読み方と規程・技術対策の対応表をまとめた記事を参照してください。

対象事業者の3類型と開発会社・保守会社・機器販売が対象になる条件

第2.0版の改定概要の1つ目が対象事業者の明確化です。自社が対象かどうかで、以降の作業量がまったく変わります。

医療機関と直接契約しない再委託先やクラウド基盤事業者も対象に入る理由

第2.1節が定める対象事業者は3類型です。①医療機関等との契約等に基づいて医療情報システム等を提供する事業者、②医療機関等と直接の契約関係がなくても、提供されるシステムに必要な資源や役務を提供する事業者、③患者等の指示に基づいて医療機関等から医療情報を受け取る事業者、の3つになります。

②が入っているのは、サプライチェーン全体で安全管理を担保するという考え方によるものです。②の事業者は、契約元の事業者（一次請けに限らず二次請け以降も含む）から求められたら、リスクマネジメントと制度上の要求事項への対応状況を資料で提供しなければなりません。電子カルテのSaaS事業者が使うクラウド基盤や、開発を再委託された会社がこれに当たります。

売買契約だけの納入・医療機関の指示で動く派遣保守は対象外になる線引き

①の「契約等」には、医療情報システム等の運用、管理、保守に関する契約が含まれます。逆に、売買契約だけで運用・管理・保守の契約がないものは含まれません。ガイドラインのFAQ（令和7年3月版）は、RISやPACSを納入して保守管理もなく売買が完了し、その後は医療機関の責任で運用される場合は対象外と例示しています。

保守の扱いはもう一段細かく分かれます。FAQによれば、保守要員を派遣して医療機関の指示で保守するケースは含まれません。一方、明確な保守契約がなくても、サービス規約にリモート保守を行う旨があれば保守契約ありとして扱われます。製品保証としてセキュリティパッチを出すだけの事業者は対象外です。医療機器も原則対象外ですが、契約等の対象で、かつ医療情報システムとネットワーク接続されるなら対象に入ります。

SaaS・PaaS・IaaSを複数社で組む提供形態ごとの管理責任の範囲

第2.2節は、代表的な提供形態を3つに分けて、誰がどこまで責任を持つかを示しています。

複数社で提供する形態では、B社はA社に、C社はB社に、リスクマネジメントと制度上の要求事項への対応状況を報告する決まりです。医療機関が電子カルテのA社とPACSのB社を別々に契約してAPIで連携させる場合も、A社は連携部分を自社の対応範囲に含めなければなりません。クラウドの責任分担の一般論はクラウドセキュリティと責任共有モデルの記事で整理しています。

第3章が整理する安全管理義務・説明義務と事故発生時の報告義務の中身

第3章は、事業者の義務を法律の根拠から説明しています。合意文書に書く責任分界の前提になる部分です。

善管注意義務と個人情報保護法23条・25条から導かれる事業者の安全管理義務

医療機関と事業者の委託契約が準委任であれば、事業者は民法644条の善管注意義務を負います。請負契約でも、医療情報の取扱いを委ねる以上は準委任の要素を含むため、同等の義務を負うとガイドラインは整理しています。患者との関係では、事業者は医療機関の安全管理義務の一部を担う履行補助者の立場です。

個人情報保護法の上では、医療機関と事業者はそれぞれ23条の安全管理措置を講じる義務を負い、委託元の医療機関には25条の委託先監督義務があります。監督の中身は、適切な委託先の選定、委託契約の締結、委託先での取扱状況の把握の3点です。なお、契約で個人データを取り扱わないと定め、アクセス制御も行っているクラウド事業者は「提供」に当たらず、25条の監督対象から外れます。それでも自らの安全管理措置は必要です。

専門性の格差を理由に事業者側へ課される説明義務と契約不適合責任

医療機関はセキュリティの専門家ではないことが想定されるため、事業者は契約の付随義務として、医療機関が安全管理義務を果たすのに必要な情報を適時適切に提供する説明義務を負います。対象は契約したサービスの内容だけではありません。医療機関が管理する機器の保守契約の要否のように、直接の契約対象でない事項でも、リスクを示して理解を得たうえで責任分界を合意することが求められています。

請負で開発を受ける場合は、2020年の民法改正で瑕疵担保責任が契約不適合責任に変わった点も踏まえて、セキュリティ条項を合意するよう注記があります。ガイドラインは、改正民法に対応したIPAの情報システム・モデル取引・契約書を参考資料として挙げています。

漏えい時の個人情報保護委員会への報告と医療機関への通知の分担

個人データの漏えい等が施行規則7条の事態に該当すれば、事業者は個人情報保護法26条により、個人情報保護委員会への報告と本人への通知を行う義務を負います。委託元の医療機関に通知した場合は、事業者側の義務は免除される仕組みです。行政機関等である医療機関は68条により施行規則43条の事態で報告義務を負うため、事業者に報告義務が生じない規模の漏えいでも医療機関へ知らせる体制が要ります。速報と確報の期限は個人情報保護委員会への報告義務を解説した記事で確認できます。

事故時には、医療機関が患者や行政に説明するための原因や範囲の情報をできる限り詳しく提供し、再発防止策を提案して再合意してから実行する流れが想定されています。

医療機関との合意形成で提供する情報とサービス仕様適合開示書・SLA

第4章は、事業者が医療機関に何を示し、何を合意すべきかを列挙しています。開示書づくりの実務はここに集約されます。

表4-1の情報提供項目を選定初期と契約直前の2段階に分けて出す手順

表4-1は、提供すべき情報を2つの目的で分けています。FAQは、前者を合意形成の初期段階に、後者を契約に向けて具体化した段階に出す使い方を示しました。

契約直前の項目に「医療機関等の運用管理規程に定める必要がある事項」が入っている点に注意してください。第4.2節は、事業者のシステムに堅牢なアクセス制御があっても、利用者がパスワードを端末に貼れば医療情報は守れないと書いています。医療機関に求める運用まで文書に落とすのが事業者の役割です。

別紙1のサービス仕様適合開示書とSLA参考例・MDS/SDSの使い分け

別紙1には、サービス仕様適合開示書とSLA参考例が収められています。開示書の作成・提供そのものは必須ではありません。ただし、同等の内容を書面などで開示・説明したうえで合意形成することは求められます。JAHISとJIRAが作成したMDS/SDS（2026年10月時点の掲載はガイドVer.5.0）は、厚労省ガイドラインへの適合状況を製品ごとに示す書式で、複数の製品を比べる用途に向きます。

SLA参考例は、サービス稼働率や障害時の対応時間、契約終了時の受託情報の返却などを「必須」項目として挙げています。目標値をSLO（努力目標）にする余地も認めていますが、すべてを努力義務にすることは医療情報システムの重要性に鑑みて妥当でないと明記しました。SLAとSLOの一般的な違いはSLAの定義と稼働率保証の記事で解説しています。

PマークまたはISMS認証の取得要件とISMAP・SOC2で代替できる範囲

第4.4節は、最低限の適格性を示す手段として、プライバシーマーク認定またはISMS認証の取得を求めています。特にプライバシーマークが望ましいとし、医療情報を直接取り扱わない事業者にも取得を強く求めました。「政府情報システムにおけるクラウドサービスの利用に係る基本方針」のクラウドセキュリティ認証等（ISMAP、FedRAMP、SOC2、SOC3）で代えることもできます。

ISMS認証の適用範囲は受託する医療情報の入口から出口まで包括的に設定し、適用宣言書も医療機関への開示を前提に書くことが望ましいとされます。認証の取得だけで安全管理水準を満たすわけではありません。認証をめぐる論点は3省2ガイドラインの記事のPマーク・ISMSの章でも扱っています。

第5章のリスクマネジメントを情報流の洗い出しからリスク対応一覧まで回す

このガイドラインの中心は第5章です。一律の対策表を埋めるのではなく、自社のシステム構成からリスクを導いて対策を決めます。

全体構成図から情報流を特定して11の代表的脅威を当てはめるリスク特定

最初に作るのは医療情報システム等の全体構成図です。構成図をもとに、情報の作成・参照・更新・保存・移送・廃棄の処理を洗い出し、構成要素間の情報の流れを「情報流」として特定します。記憶媒体の搬送も情報流に含まれ、洗い出す範囲にはICTサプライチェーン全体が入ります。

次に、情報流を重要度で分類します。診療録や処方箋は「患者情報」、アプリケーションの設定情報やテストデータは別の分類という具合です。そのうえで表5-1の代表的な脅威11種（不正な閲覧・操作、盗聴・なりすまし、高度サイバー攻撃、ランサムウェア感染、情報の窃取・漏えい、改ざん・破壊、システムの停止、技術的脆弱性の混入、持ち出し時の紛失・盗難、施設への物理的侵入、災害等）を当てはめます。表5-1は網羅ではないので、構成に応じた脅威の追加も求められます。

影響度と顕在化率で5段階に分けるリスク分析と対応基準の決め方

特定したリスクは、影響度と顕在化率からリスクレベルを算出します。ガイドラインは5段階に分ける例を示し、Sランクは複数の対策で対応必須、Aランクは対応必須、B〜Cランクは個別事情を勘案して要否を検討、Dランクは対応不要という基準例を挙げました。インターネットから直接攻撃できる、認証を要求していない、といった条件があれば顕在化率は高く見積もります。

FAQの例では、クラウド型カルテのログインがIDと4桁のパスワードならリスクレベルは極めて高いと判断し、桁数を増やして低減します。技術の進展でその対策が危うくなれば、多要素認証へ切り替えて医療機関と合意し直す流れです。

リスク共有とリスク受容を事業者だけで決めてはならない理由と合意の残し方

リスク対応の選択肢は、低減、回避、共有、受容の4つです。ガイドラインは低減を中心に、多層防御を組み合わせるよう求めています。サイバー保険などによる共有は金銭面の損失にしか効かず、事故そのものや医療機関の信用失墜は防げないため、低減を行ったうえで残るリスクに適用する位置づけです。

共有と受容は、事業者の判断だけで選んではならず、医療機関への説明と合意を経て選ぶことが明記されています。合意の結果は文書化し、運用管理規程に含める事項（体制、事故時の報告方法、記憶媒体の管理、監査の方針、問い合わせ窓口など）として残してください。残存リスクは定期的に評価し直し、そのつど再合意が必要です。

受託開発会社として2省ガイドラインへの対応範囲を決める3つの判断基準

ここからは、医療機関向けシステムを受託で開発する立場からの判断です。案件の契約形態で、背負う範囲は条件付きで言い切れます。

開発だけを請け負う案件と運用保守まで受ける案件で変わる対応の深さ

納品後に運用・管理・保守の契約がなく、医療機関が自ら運用する開発案件であれば、FAQの売買契約の例と同じく対象外になり得ます。それでも、開発中に本番データやテストデータとして患者情報を扱うなら、個人情報保護法上の委託先としての安全管理措置は免れません。開発フェーズでは実データを使わない取り決めを契約に入れるのが、最も負担の少ない進め方です。

運用保守やクラウドでの提供まで受けるなら、対象事業者として第3〜6章の全体を背負います。全体構成図、リスク対応一覧、開示書、SLAを揃え、契約終了時の返却・移管・破棄の手順と証跡まで合意しておかなければなりません。医療機関が運用会社とだけ契約し、開発を別会社が担う場合は、両社の間で開発に関する義務と責任を内部で合意するようFAQは求めています。

中小の開発会社が第三者認証なしで医療案件を受けると詰まる場面

プライバシーマークもISMSも持たない会社が運用保守まで受けようとすると、表4-1の選定初期の項目で止まります。表4-1は第三者認証を、医療機関が委託先の選定基準として少なくとも確認する項目に置いているためです。案件が来てから認証取得に動いても、選定には間に合いません。

この場合の現実的な選択肢は、認証を持つ一次請けの下で②の事業者として参加し、契約元に対応状況の資料を出す形です。クラウド基盤はISMAP登録済みのサービスを選べば、基盤部分の説明資料を揃えやすくなります。自社で認証を持たないまま一次請けとして運用まで抱える受け方は、見送るべきです。

医療機関側が委託先の選定で事業者に求めるべき書類と見送る条件

医療機関の側から見ると、委託先に求める書類は3つに絞れます。別紙1の開示書またはMDS/SDS、SLA、全体構成図とリスク対応一覧です。全体構成図を出せない事業者は、リスク特定の出発点を持っていないと判断してよいでしょう。SLAの項目がすべて努力目標になっている場合や、保存場所の国を答えられない場合も、ガイドラインが妥当でないと書く状態に当たるので見送りの条件になります。

既存のパッケージでは要件が合わず、開発と運用保守をまとめて任せたい場合は、当社の医療機関向けシステム開発で、2省ガイドラインと厚労省第7.0版の要求を要件定義に組み込んだうえで設計からご相談いただけます。

よくある質問

提供事業者向けガイドラインについて、事業者と医療機関の双方から多い質問をまとめました。

提供事業者向けの安全管理ガイドラインの最新版はどれですか？

2026年10月時点の最新版は第2.0版で、令和7年3月28日に改定・公表されました。別紙2は令和7年6月付の版が掲載されていますが、対応表の対象は厚労省ガイドラインの第6.0版のままです。厚労省側は令和8年6月に第7.0版へ改定されたため、そこで加わった要件は事業者が自ら上乗せして対応します。

医療機関から開発だけを受託する場合も対象になりますか？

納品後の運用・管理・保守の契約がなく、医療機関が自ら運用するのであれば、原則として対象外です。ただしサービス規約にリモート保守の定めがあれば対象になります。開発中に患者情報を扱う場合は、対象外でも個人情報保護法上の安全管理措置が必要です。

サービス仕様適合開示書の作成は必須ですか？

作成・提供そのものは必須ではありません。ガイドラインは、別紙1の開示書と同等の内容を医療機関に情報提供したうえで、共通理解に基づく合意形成を図ることを求めています。MDS/SDSや自社で作ったセキュリティ対策状況の資料でも構いませんが、表4-1の項目が抜けていないかは照合してください。

ISMS認証だけでは足りないのですか？

要件としてはプライバシーマークかISMSのどちらかで足ります。ただしISMSは管理が適正であることの認証で、安全対策の有効性までは認証しないため、ISMSだけなら具体的な管理方法を説明できる資料の用意が望ましいとされています。2つの認証の違いはPマークとISMSの違いを比較した記事を参照してください。

3省2ガイドラインとは何が違いますか？

3省2ガイドラインは、厚生労働省の医療機関向けガイドラインと、本記事で扱う総務省・経済産業省の事業者向けガイドラインを合わせた通称です。事業者は自社の対策を後者で設計し、医療機関が前者を守れるように説明する義務を負います。

関連記事

• 3省2ガイドラインとは？第7.0版の改定点と3省3ガイドラインとの違い：呼称の整理と第7.0版で変わった要件を扱っています。
• 医療情報システムの安全管理に関するガイドライン第7.0版の読み方｜5編の担当と規程・技術対策の対応表：医療機関側の5編と規程づくりを整理しています。
• 医療情報システムとは？種類・構成と安全管理ガイドライン第7.0版対応、SS-MIX2とFHIR接続の実務【2026年版】：院内システムの構成と発注の判断をまとめています。
• SLA（サービスレベル合意）とは？定義・SLOとの違い・要件と稼働率保証を解説：SLAの一般的な書き方を補います。
• 医療DXとは？定義・3本柱・2026年度改定から進め方と受託開発の判断まで解説：医療DX政策の全体像を確認できます。