2分で読める生成AIのいま Vol.62 - 「ベンダーに任せてるから大丈夫」の終わり ― 3省2ガイドライン徹底解説③
3省2ガイドライン徹底解説シリーズ、第3回。
①②で「病院のルール」(厚労省版)を見てきました。今回は「ベンダーのルール」(経産省・総務省版)。
医療田さんと機械屋さんの会話でどうぞ。
======
● もう1つのガイドライン
医療田:
前回、前々回で厚労省版のガイドラインを一通り見てきたわけだけど。
今回はいよいよ、もう1つの方だね。
機械屋:
はい。
3省2ガイドラインの「2つ目」、経済産業省と総務省が共同で出しているガイドラインです。
正式名称は「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」。
医療田:
、、長い 笑
機械屋:
なので、「提供事業者ガイドライン」と呼ばれることが多いです。
最新版は第2.0版。2025年3月に改定されました。
医療田:
で、これは誰に向けたルールなの?
機械屋:
名前の通り、「提供事業者」 ―― つまり、電子カルテやPACS、クラウドサービスなど、医療情報システムを病院に提供するベンダーさんのためのルールです。
医療田:
なるほど。
厚労省版が「病院がやること」で、経産省・総務省版が「ベンダーがやること」。
機械屋:
その通りです。
ただ、この2つのガイドラインは完全に独立しているわけではなくて、表裏一体の関係にあります。
医療田:
表裏一体?
機械屋:
たとえば、②で見たシステム運用編に「バックアップをオフラインで取れ」とありましたよね。
でも電子カルテがクラウド型だったら、バックアップを実際に取るのは誰でしょう。
医療田:
、、あ。ベンダーさんだ。
機械屋:
そうです。
病院のルールに「やりなさい」と書いてあっても、実際にやるのはベンダー側であることが多い。
ベンダー側にもルールがなければ、病院のガイドラインは絵に描いた餅です。
医療田:
だから「もう1つのガイドライン」が要るのか。。
機械屋:
はい。
もう1つ重要な背景があります。
もともと経産省と総務省はそれぞれ別のガイドラインを出していたのですが、2020年に統合されて現在の形になりました。
医療田:
あ、そうなの?
機械屋:
経産省が「情報処理事業者ガイドライン」、総務省が「クラウドサービス事業者ガイドライン」を出していて、さらに総務省にはもう1本あった。
都合3本のガイドラインが1本に統合されたんです。
医療田:
、、それは整理してくれてよかった。。
事業者さんも大変だったろうね。
● 責任分界 ― ITのインフォームドコンセント
機械屋:
さて、この提供事業者ガイドラインの核になる考え方をお伝えします。
キーワードは「責任分界」です。
医療田:
責任、分界。。
「誰が何を守るか」の境界線、ってこと?
機械屋:
はい。
医療で言えば、この考え方はインフォームドコンセントにかなり近いです。
医療田:
えっ、インフォームドコンセント?
機械屋:
医師は患者さんに、治療内容やリスク、選択肢を説明して同意を得ますよね。
大事なのは、医師と患者それぞれの「役割」が明確になっていることです。
手術をするのは医師。でも、術後の生活管理は患者さんの責任です。
医療田:
うん、それは当然だよね。
機械屋:
同じことが、病院とベンダーの間にも求められるんです。
「サーバーの物理的なセキュリティはベンダーが責任を持つ。でもアカウント管理やパスワード運用は病院側の責任ですよ」
こういう線引きを、事前に文書で合意する。
医療田:
、、なるほど。。
でもさ、正直、「セキュリティのことはベンダーさんに聞いて」で済ませちゃってるところ、あるんじゃないかなあ。。
機械屋:
実は、それが一番まずい状態なんです。
「ベンダーに任せてるから大丈夫」は、責任分界が不明確な状態と同じです。
何かインシデントが起きたときに、「それはベンダーの仕事」「いや、病院側の管理でしょう」と押し付け合いになってしまう。
医療田:
、、怖いね。。
じゃあ、どうやってその「分界」を合意するの?
機械屋:
ここで2つの文書が登場します。
SDS ―― サービス仕様適合開示書と、SLA ―― サービス・レベル合意書です。
医療田:
アルファベット多いな。。
機械屋:
SDS は、ベンダーが「うちのサービスはこういうセキュリティ対応をしています」「ここまでが当社の責任範囲です」と開示する文書。
SLA は、「システム稼働率は99.9%以上」「障害発生時の復旧は4時間以内」など、サービスの品質を数値で約束する合意書です。
医療田:
稼働率99.9%って、年間で何時間くらい止まれるの?
機械屋:
約8.7時間ですね。
99.99%なら約53分。
病院のシステムだと、止まっていい時間は結構シビアですから、この数字をベンダーと合意しておくのは大事です。
医療田:
、、この数字、ちゃんと合意できてない病院もあるんじゃないかな。。
「なんとなく動いてるからいいか」で済ませてたら怖いよね。
機械屋:
その「知らない」こそが問題なんです。
ガイドライン第2.0版では、ベンダーが医療機関に対してこれらの情報を提供し、合意形成を行うことが明確に求められるようになりました。
いわば、ITにおけるインフォームドコンセントの義務化です。
● MDS/SDS ― ベンダーの「通知表」
医療田:
で、Vol.61の最後に出てきた「MDS」と「SDS」って、いまの SDS とはまた別のもの?
機械屋:
ああ、ここはちょっと紛らわしいですね。
さっきの SDS は、提供事業者ガイドラインが参考様式として示している「サービス仕様適合開示書」。
これから説明する MDS/SDS は、業界団体の JAHIS と JIRA が策定した、より標準化されたチェックリストです。
医療田:
JIRA って、、あ、CTやMRIのメーカーさんの業界団体だよね。知ってる。
機械屋:
そうです。
MDS/SDS は正式には「製造業者/サービス事業者による医療情報セキュリティ開示書」といいます。
医療田:
で、MDS と SDS の違いは?
機械屋:
MDS は Manufacturer Disclosure Statement。
「製品」のセキュリティ機能を開示する文書です。
CTやMRIのメーカーが「この装置にはこういうセキュリティ機能がありますよ」と示すのが MDS ですね。
SDS は Service Provider Disclosure Statement。
「サービス」全体のセキュリティ対応を開示する文書です。
クラウド電子カルテの事業者が、運用や保守も含めた対応状況を示す。
医療田:
ああ、そっか。
CTの本体のセキュリティ機能が MDS。
そのCTを使ったサービス全体の対応が SDS。
機械屋:
その通りです。
中身は「はい / いいえ / 対象外」でチェックする形式で、項目は電子保存の3要件への対応、アクセス制御、ネットワーク対策、バックアップ体制など。
②で見たシステム運用編の要件と、ほぼ対応しています。
医療田:
つまり、、
②で「病院がチェックすべき項目」を学んで、③で「ベンダーがその結果を出してくれる仕組み」を学んでる、ってことか。
機械屋:
そうです。
そしてこの MDS/SDS は、2025年1月に「厚生労働省標準規格」に認定されました。
医療田:
あ、それって結構大きいんじゃない?
機械屋:
大きいです。
強制力はありませんが、「国のお墨付き」が付いたことで、MDS/SDS を提出するのがベンダーにとって事実上のスタンダードになりつつあります。
提供事業者ガイドライン第2.0版でも、MDS/SDS の利用が情報提供手段として追記されました。
医療田:
じゃあ病院としては、ベンダーさんに「MDS/SDS ください」って言えばいいの?
機械屋:
はい、それが第一歩です。
ただし、「もらっただけ」では意味がないんです。
中身を見て、「ここが『いいえ』になっているけど、代替手段はあるのか?」と確認するところまでが、病院側の責任です。
医療田:
なんか通知表みたいだなw。「通知表をもらったら中身を見なさい」っていう。
機械屋:
ははは。
● リスクコミュニケーション ― 「任せる」から「合意する」へ
医療田:
経産省・総務省版って、厚労省版みたいに「これをやれ」「あれをやれ」と決まってるの?
機械屋:
そこが大きな違いです。
このガイドラインは「リスクベースアプローチ」を採っています。
一律の要求事項ではなく、事業者が自社のサービスについてリスクアセスメントを行い、結果に応じた対策を設計する。
医療田:
あ、②の企画管理編でやった「ITの健康診断」と同じ考え方だ。
機械屋:
そうです。
②では病院側のリスクアセスメントでした。今回は事業者側です。
事業者は、自社のシステム内で医療情報がどう流れるかを「情報流」として洗い出し、それぞれにリスクを特定・分析・評価し、対策を決める。
そしてその結果を病院に開示して合意を形成する。
この一連のプロセスを「リスクコミュニケーション」と呼んでいます。
医療田:
リスクコミュニケーション。。
やっぱりインフォームドコンセントに近いね。
リスクを隠さず共有して、対策と「残るリスク」について合意する。
機械屋:
医療の世界では長年の知恵として当たり前のこの考え方が、ITセキュリティの世界でも求められるようになったんです。
医療田:
なんか、、嬉しいかも。
医療の知恵がITでも通用するって。
機械屋:
さて、第2.0版(2025年3月改定)の変更点を3つだけ。
1つ目。対象事業者の範囲が広がりました。
病院と直接契約しているベンダーだけでなく、そのベンダーが利用しているクラウド基盤の事業者なども対象に。
いわゆるサプライチェーン全体です。
医療田:
ベンダーの裏にいるベンダーも含む、と。
機械屋:
2つ目。いま説明した MDS/SDS の利用が、情報提供手段として明記されました。
3つ目。リスクコミュニケーションの実効化。
「形だけの情報提供で終わらせない」ことが強調されています。
医療田:
なるほどね。。
● まとめ ― 3省2ガイドラインの全体像
医療田:
ここまでやってきて思ったけどさ。
3省2ガイドラインの全体像、ちょっと見えてきた気がする。
厚労省版が「病院のルール」。
経産省・総務省版が「ベンダーのルール」。
そして MDS/SDS が「両者をつなぐ共通言語」。
機械屋:
まとめましょうか。
・3省2ガイドラインは「病院のルール」と「事業者のルール」の2つで1セット
・経産省・総務省版は、事業者に対しリスクベースアプローチに基づくセキュリティ管理を求めている
・「責任分界」を明確にし、ベンダーと病院がそれぞれの役割を合意することが鍵
・MDS/SDSは、ベンダーのセキュリティ対応を開示する業界標準チェックリスト。2025年に厚労省標準規格に認定
・リスクコミュニケーション = 「リスクを共有し、対策と残存リスクについて合意する」こと
一番大事なのは、「任せる」ではなく「確認して、合意する」ことなんです。
医療田:
、、インフォームドコンセントだ。
医療がずっとやってきたことを、ITの世界でもやるようになったんだね。
機械屋:
そしてそれは、②で出た Evidence-Based Security と同じ流れです。
医療の知恵がITセキュリティに活きる。
医療田さんにとっては、むしろ得意分野かもしれませんね。
医療田:
、、ちょっと自信出てきたかも 笑
機械屋:
次回④は、シリーズ最終回です。
①〜③で学んできた内容を、現場で使えるチェックリストに落とし込みます。
医療田:
いよいよ実践編だ。
楽しみにしてるよ。
======
● よくある質問(FAQ)
Q. 経産省・総務省版ガイドラインは、厚労省版とどう違うのですか?
A. 厚労省版が医療機関(病院・診療所等)向けのルールであるのに対し、経産省・総務省版は医療情報システムを提供する事業者(ベンダー)向けのルールです。両者は表裏一体の関係で、セットで機能します。
Q. MDS/SDSとは何ですか?
A. 「製造業者/サービス事業者による医療情報セキュリティ開示書」の略称です。JAHISとJIRAが策定した標準チェックリストで、ベンダーが自社製品・サービスのセキュリティ対応状況を「はい/いいえ/対象外」形式で開示します。2025年1月に厚生労働省標準規格に認定されました。
Q. MDSとSDSの違いは何ですか?
A. MDS(Manufacturer Disclosure Statement)は「製品」のセキュリティ機能を開示する文書で、CT・MRI等のハードウェアやソフトウェアが対象です。SDS(Service Provider Disclosure Statement)は「サービス」全体(運用・保守含む)のセキュリティ対応を開示する文書です。
Q. 病院としてまず何をすればよいですか?
A. まず取引先のベンダーに「MDS/SDSを提出してください」と依頼しましょう。受け取ったら中身を確認し、特に「いいえ」の項目については代替手段の有無を確認することが重要です。また、責任分界やSLAについても文書で合意を形成しましょう。
Q. 「責任分界」とは何ですか?
A. 病院とベンダーの間で「誰が何を守るか」の境界線を明確にすることです。たとえばサーバーの物理セキュリティはベンダー、アカウント管理は病院、というように役割を分けて文書化・合意します。インシデント発生時の混乱を防ぐために不可欠な取り決めです。
======
●参考
・経産省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 第2.0版(令和7年3月改定)」
https://www.meti.go.jp/policy/mono_info_service/healthcare/teikyoujigyousyagl.html
・総務省 報道資料「提供事業者ガイドライン第2.0版の公表」
https://www.soumu.go.jp/menu_news/s-news/01ryutsu06_02000427.html
・JAHIS「製造業者/サービス事業者による医療情報セキュリティ開示書」ガイド Ver.5.0
https://www.jahis.jp/standard/detail/id=1119
・JIRA 医用画像システム部会セキュリティ委員会 MDS/SDS関連資料
https://www.jira-net.or.jp/commission/system/files/2025_goudou/system_2025_report_3.pdf
●関連記事
・Vol.61「パスワードは定期変更しなさい」が消えた日 ― 3省2ガイドライン徹底解説②
https://www.youichimachida-ai.com/blog/2ai-vol61-32
・Vol.60「鍵のかかっていない金庫」で医療をしていませんか ― 3省2ガイドライン徹底解説①
https://www.youichimachida-ai.com/blog/2ai-vol60-32
・Vol.59「学習オフにしてるから大丈夫」では足りない ― 3省2ガイドラインと生成AI、本当のルール
https://www.youichimachida-ai.com/blog/2ai-vol59-32ai
・Vol.40 Claude Cowork導入トライで知る、組織のセキュリティポリシーと「ゼロトラスト」の現実
https://www.youichimachida-ai.com/blog/-2ai-vol40-claude-cowork
●2分で読める「生成AIのいま」シリーズ。バックナンバーはブログからどうぞ!