対象読者：

医療機関のIT担当者・事務長・情報システム責任者
医療機関にSEを派遣するベンダの方
臨床工学技士（CE）でITを担う方
「医療情報システムってよくわからない」という初心者の方

読了時間： 約25分

想定タグ： 医療情報システム / サイバーセキュリティ / 個人情報保護 / DICOM / 電子カルテ / LLM

この記事のポイント（3行要約）

医療機関のインフラ再構築には3省2ガイドライン＋改正医療法施行規則＋電子保存3要件＋個人情報保護法＋薬機法が絡み、2023〜2025年で大きく変化した
2025年は経産省・総務省GL第2.0版（令和7年3月）、厚労省Q&A令和7年5月版、サイバーセキュリティ対策チェックリストマニュアル令和7年5月版と、立て続けに重要文書が更新されている
生成AI（LLM）の医療利用については、**令和7年5月の厚労省Q&A「企Q-26」**で初めて公式見解が示された。ZDR（データ保存なし）が契約で担保されていれば国外サーバ利用も可とされる

0. はじめに：なぜ今これを読む必要があるか

医療機関のネットワーク更新・NAS導入・クラウド移行・生成AI導入を任されたIT担当者やベンダSE、そしてCEで院内のIT・医療情報の安全管理を担う方に向けて、法律とガイドラインを整理したチートシートを書いた。

🔰 そもそも「医療情報を扱うときのルール」って何が大変なのか？

普通のWebサービスと医療情報システムは、扱う情報の重さが全く違う。

観点	一般のWebサービス	医療情報システム
扱う情報の機微性	メールアドレス、住所など	病歴・診療情報など要配慮個人情報
漏洩時の影響	困るが回復可能	患者の生命・人生に直結、回復不可
関係する法律	個人情報保護法	個人情報保護法 + 医師法 + 医療法 + 薬機法 + e-文書法 + 刑法
監督官庁	個人情報保護委員会	個人情報保護委員会 + 厚労省 + 経産省 + 総務省

つまり、医療情報を扱う時点で「普通の情報システムよりはるかに厳しいルールが何重にもかかる」ということ。

直近のランサムウェア事案

2021年〜2022年にかけて日本の医療機関でランサムウェア被害が相次いだ。

事案	発生	影響	復旧期間
半田病院（徳島県）	2021年10月	電子カルテ全停止、外来受入停止	約2ヶ月
大阪急性期・総合医療センター	2022年10月	基幹システム停止、手術・外来制約	約2ヶ月以上

どちらも**「VPN装置のパッチ未適用」「バックアップが同一ネットワーク上で暗号化された」「ネットワーク分離が不十分」**という共通の要因を持っていた。

これらの事案を受け、政府は2023年に医療法施行規則を改正し、サイバーセキュリティ対策を医療機関の法的義務とした。「ガイドラインを読んだことがない」では済まない時代になっている。

専門用語解説：ランサムウェア
「身代金（ransom）」と「ソフトウェア」を組み合わせた造語。感染するとファイルを勝手に暗号化（鍵をかけて開けなくする）し、「鍵を返してほしければ金を払え」と脅迫してくる悪意あるソフトウェア。電子カルテが全部開けなくなれば、外来も手術も止まる。

1. 全体地図：3省2ガイドラインとは何か

1-1. 法令・ガイドライン俯瞰表（2026年4月時点）

文書	発行元	最新版	主な対象	性格
医療情報システムの安全管理に関するガイドライン	厚生労働省	第6.0版（2023-05-31）	医療機関	事実上必須（医療法施行規則の根拠）
同 Q&A	厚生労働省	令和7年5月	医療機関	第6.0版の解釈の公式見解
医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン	総務省・経産省	第2.0版（令和7年3月28日公開）	ベンダ・SaaS事業者	事業者の安全管理基準
医療機関等におけるサイバーセキュリティ対策チェックリストマニュアル	厚生労働省	令和7年5月	医療機関・事業者	立入検査での確認基準
医療・介護関係事業者における個人情報の適切な取扱いのためのガイダンス	個人情報保護委員会・厚労省	2023年改正対応	医療機関・介護事業者	個人情報保護法の具体的解釈
医師法24条	法律	—	医師	診療録の作成・5年保存義務
医療法21条	法律	—	病院管理者	診療関連記録の備え置き義務
医療法施行規則第14条第2項	法律	2023-04-01施行	病院・診療所・助産所の管理者	サイバーセキュリティ確保の措置義務
e-文書法	法律	2005年施行	民間事業者全般	法定文書の電子保存を許容する根拠

⚠️ 重要：「経産省・総務省GLは令和6年12月版」と書いている記事がネット上に散見されるが、正確には令和7年（2025年）3月28日公開の第2.0版が最新版である。意見公募が令和6年10〜11月、公開が令和7年3月という流れ。一次情報（経産省ヘルスケア産業課ページ）で確認できる。

🔰 「3省」「2ガイドライン」って何？

3省＝厚生労働省・経済産業省・総務省。医療情報システムに関わる3つの省庁。
2ガイドライン＝医療機関向けの厚労省GLと、ベンダ向けの経産省・総務省共同GL。

専門用語解説：ガイドライン
「指針」のこと。法律ではないが、これに従わないと立入検査で指導が入ったり、何かあったときに「注意義務違反」として民事・行政上の責任を問われやすくなる。法律と「自由」の間にある「事実上のルール」と思えばよい。

1-2. 3省 → 2ガイドラインに整理された経緯

旧来は厚労省・総務省・経産省がそれぞれ独立したガイドラインを発行していた（「3省3GL」または「3省4GL」）。

2020年代の改訂で、総務省GLと経産省GLが統合され「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」になった。これにより「3省2ガイドライン（厚労省向け＋総務省・経産省向け）」と呼ばれるようになった。

3省の関与は変わっていないが、ガイドライン文書としては2本体制になっている。

1-3. 医療法施行規則改正（2023-04-01施行）

2023年4月の医療法施行規則改正により、ガイドラインが「推奨」から**「法的根拠のある義務の基準」**に変わった。

医療法施行規則第14条第2項では、病院・診療所・助産所の管理者が遵守すべき事項として、サイバーセキュリティの確保について必要な措置を講じなければならないと規定されている（薬機法施行規則第11条第2項では薬局の管理者に同様の規定）。

主な義務化内容：

情報セキュリティ責任者（安全管理責任者）の設置
安全管理指針の策定・文書化
従業員へのセキュリティ教育（年1回以上）
委託先の安全管理措置の確認
インシデント対応手順の整備

立入検査でこれらの実施状況が確認されるようになっており、実運用上の重みが増している。

筆者の見解：
「ガイドラインだから努力義務」と理解している現場が今でも多いが、医療法施行規則第14条第2項により、これは実質的な法的義務である。ガイドラインに従うことは「やった方が良いこと」ではなく「やっていないと違法状態」と整理しておくべき。

2. 厚労省ガイドライン第6.0版（令和5年5月）を読む

2-1. 4編構成の使い分け

厚労省GL第6.0版は約400ページに及ぶ大部な文書だが、読む人の役割によって参照すべき編が違う。

編	タイトル	誰が読むべきか
概説編	目的・背景・法令体系	初読時に全員
経営管理編	経営層の責務・体制構築	院長・管理者・事務長
企画管理編	リスク評価・委託先管理・調達	IT担当・管理部門
システム運用編	ネットワーク・バックアップ・ログ・アクセス制御	IT担当・保守ベンダ

IT担当やSEが最初に読むべきはシステム運用編と企画管理編。経営層への説明材料として経営管理編も押さえておく。

2-2. システム運用編の実務ポイント

🔰 ネットワーク分離（VLANとは？）

GLはネットワークを用途別に分離することを求めている。

専門用語解説：VLAN（Virtual LAN）
「仮想的にLAN（ネットワーク）を分けること」。物理的には1本のスイッチでも、設定で「あなたは1班」「あなたは2班」と論理的に分け、班同士は通信できないようにする技術。マンションで言えば、同じ建物の中で1階と2階の住人が玄関を別にして、お互いの部屋には行けないようにするイメージ。

[診療系] ← 電子カルテ・オーダリング・PACS
    |  VLAN分離必須
[管理系] ← 業務PC・メール
    |  VLAN分離必須
[医療機器系] ← DICOMモダリティ
    |  VLAN分離推奨
[インターネット接続系] ← 患者向けWi-Fi
    |  完全分離
[オン資ネットワーク] ← マイナ保険証
    |  独立VLAN推奨

診療系ネットワークをインターネットに直接接続することは禁止。ファイアウォール・UTMでの経路制御が必須。

専門用語解説：UTM（Unified Threat Management）
「統合脅威管理」と訳される。ファイアウォール・アンチウイルス・侵入検知・URLフィルタなど、複数のセキュリティ機能を1台にまとめた装置。マンションの管理人室に「監視カメラ」「警報器」「不審者対応」を全部任せるイメージ。

バックアップ要件

GLが求めるバックアップの要件：

要件	内容
3-2-1ルール	3コピー・2種類のメディア・1つはオフサイト
ランサムウェア耐性	バックアップ先をオンラインで常時接続しない（オフライン保管 or イミュータブル化）
リストアテスト	年1回以上、実際に復元できることを確認・記録
保存期間	診療録に係るものは5年以上を推奨

専門用語解説：3-2-1ルール
バックアップの基本原則。データは「3つコピー」「2種類のメディア（HDDとテープなど）」「うち1つは別の場所（遠隔地）」に保管せよ、というもの。たとえば本物（電子カルテ）＋NASバックアップ＋クラウドバックアップ、のような構成。

専門用語解説：イミュータブル（Immutable）バックアップ
「変更不能な」バックアップ。書き込んだら一定期間は誰も削除・改ざんできない仕組み。ランサムウェアが院内に侵入しても、このバックアップだけは暗号化できない。

半田病院と大阪急性期のいずれも「バックアップが同一ネットワーク上で暗号化された」ことが復旧を遅らせた最大の要因。バックアップのネットワーク分離は最優先で対処すべき事項。

ログ管理

アクセスログ（誰が・いつ・どのデータに）の記録と保管
最低保管期間：1年（医療記録に関するものは5年推奨）
不正アクセス・異常なアクセスパターンの監視体制

2-3. 経営管理編の意義

IT担当だけでいくら適切な対策を提案しても、経営層の理解と予算措置がなければ実現しない。経営管理編には**「院長・理事長が最終責任者」**という明文があり、IT部門が経営層を説得する際の根拠として活用できる。

安全管理責任者の設置は経営層の義務（法的根拠あり）
サイバー被害は「復旧費用＋診療停止期間中の損失」が数億円規模になりうる
インシデント後の報道・社会的信用の毀損リスク

2-4. ゼロトラストネットワークの導入

第6.0版で初めて明記された重要な考え方。

専門用語解説：ゼロトラスト（Zero Trust）
「何も信頼しない」という意味。従来は「院内ネットワークの中は安全、外は危険」と境界で守っていた（境界防御型）。ゼロトラストは「院内であっても全部信頼しない。アクセスのたびに認証する」という発想。リモートワークやクラウドが普及した時代に合わせた考え方。

第6.0版は、従来の境界防御型思考とゼロトラスト思考をうまく組み合わせることを推奨している。「院内なら何でもOK」「VPNでつなげば安心」という発想は時代遅れになっている。

3. 電子保存3要件とNAS保存時の注意点

3-1. 三原則の定義

1999年4月22日の厚生省通知で定義された「電子媒体による保存を認める条件」。現在は厚労省GL第6.0版で継承・具体化されている。

🔰 そもそもなぜ「3つの要件」が必要なのか？

紙のカルテは、書いた瞬間に物理的に固定されて、後から書き換えるのが難しい（書き換えれば筆跡や紙の状態でわかる）。だから「あとで改ざんしていない」「何年後でも読める」「失われない」が自然と担保される。

電子データはそうはいかない。

ファイルは編集・削除がワンクリックでできる → 「書き換えていないこと」を別の仕組みで証明する必要がある
ソフトのバージョンが変われば開けなくなる → 「何年後でも読める」を担保する必要がある
HDDは壊れる → 「失われないこと」を担保する必要がある

これを表現したのが「真正性・見読性・保存性」という3要件。

原則	定義	具体例（OK）	具体例（NG）
真正性	正当な作成者による正真性のある記録。改ざん・消去が防止されていること	WORM ＋アクセスログ＋スナップショット	誰でも上書き・削除できる共有フォルダ
見読性	記録を必要に応じて肉眼で見読できる状態に置くこと	DICOM形式＋ビューア確保	再生ソフトが廃止されたプロプライエタリ形式
保存性	保存期間にわたり記録が保持されること。媒体劣化・機器廃棄で失われないこと	3-2-1バックアップ＋ RAID ＋リストアテスト	単台HDDのみ、RAIDなし

専門用語解説：WORM（Write Once Read Many）
「一度書いたら何度でも読めるが書き換えはできない」記録方式。CD-Rのような追記不可な仕組みをHDD/SSD上で実現する技術。改ざん防止に有効。

専門用語解説：DICOM
「Digital Imaging and COmmunications in Medicine」の略。医療画像（CT・MRI・X線・超音波など）の世界共通フォーマット。1990年代から使われており、「30年後でも見れる」見読性が担保されている。

🔰 厚労省Q&A（令和7年5月）で確認された関係

令和7年5月の厚労省Q&Aで、電子保存の3要件と情報セキュリティの3要素（機密性・完全性・可用性）の関係が整理された。

要するに：

完全性＋可用性 → 見読性の大半をカバー
完全性＋責任所在の明確化 → 真正性をカバー
機密性＋完全性＋可用性 → 保存性の多くをカバー

セキュリティ対策をきちんとやれば、電子保存3要件は自然と満たされる、という設計思想が読み取れる。

3-2. NAS保存時に三原則を充足するための技術要件

**「NASに保存しただけでは三原則を満たさない」**というのが最大の注意点。

以下のような技術要件を組み合わせて初めて三原則が充足される。

三原則	技術手段	Synology NASでの対応例
真正性	アクセス制御（書き込み/削除権限の最小化）	共有フォルダのアクセス権設定
	WORM（書き込み後の変更・削除禁止）	Synology SnapLock（DSM 7.2以降）
	スナップショット（定期差分取得）	Snapshot Replication
	監査ログ（アクセス・変更履歴）	File Station監査ログ＋ Syslog転送
見読性	標準フォーマット保存	DICOM / PDF/Aで保存
	ビューアの継続確保	OSSビューア（Weasis等）のバージョン管理
保存性	RAID（単点故障耐性）	RAID 5 / RAID 6
	3-2-1バックアップ	Hyper Backup ＋オフサイト先
	バックアップのランサムウェア耐性	オフライン保管 or Immutable Backup
	リストアテスト	年1回以上の復元確認・記録

さらに、これらの技術的対応を文書化（設定記録・テスト記録）しておくことが、立入検査対応・委託先管理のエビデンスとして必要になる。

3-3. 根拠法令の重層構造（簡略版）

医師法24条 → 診療録の5年保存義務
  ↓
医療法21条 → 病院の記録備え置き義務
  ↓
1999年厚生省通知 → 電子保存の3要件（真正性・見読性・保存性）の初定義
  ↓
e-文書法（2005年） → 法定文書の電子保存を一般的に許容
  ↓
医療法施行規則第14条第2項（2023-04-01） → サイバーセキュリティ確保の措置義務
  ↓
厚労省GL第6.0版（2023-05-31） → 最新技術環境での3要件充足方法を具体化
  ↓
厚労省GL第6.0版Q&A（令和7年5月） → 解釈の公式見解

4. DICOMデータに含まれるPHIの取扱い

4-1. DICOMヘッダの患者識別タグ一覧

専門用語解説：PHI（Protected Health Information）
「保護対象保健情報」。米国HIPAA法で定義された概念だが、日本でも「要配慮個人情報のうち医療情報」として実質同義に使われる。患者氏名・ID・生年月日・検査日など、患者個人を特定できる情報全般を指す。

DICOMファイルはヘッダ（ファイル冒頭の情報領域）に患者識別情報を多数含む。

タグ	タグ番号	内容
Patient Name	(0010,0010)	患者氏名
Patient ID	(0010,0020)	患者ID
Patient Birth Date	(0010,0030)	生年月日
Patient Sex	(0010,0040)	性別
Institution Name	(0008,0080)	施設名
Accession Number	(0008,0050)	検査受付番号
Referring Physician Name	(0008,0090)	依頼医師名
Study Date	(0008,0020)	検査日
Station Name	(0008,1010)	装置名称
Series Description	(0008,103E)	シリーズ説明（検査部位等）

これらのタグを削除・置換せずに院外送信・研究利用することは、個人情報保護法違反となる可能性がある。

4-2. 院外転送・研究利用時の匿名化要件

国際標準：DICOM PS 3.15 Appendix E

DICOM規格のAppendix E "Basic Application Confidentiality Profile" で匿名化すべきタグと処理方法が定義されている。これが院外送信・研究利用時の匿名化の国際標準。

Anonymization vs Pseudonymization

方式	内容	個人情報扱い
Anonymization（匿名化）	PHIを完全削除・対応表なし。元の個人を特定できない	個人情報ではなくなる
Pseudonymization（仮名化）	PHIを代替IDに置換・対応表を別管理	依然として個人情報（対応表から再識別可能）

研究利用やAI学習データとして「個人情報ではない」として扱いたい場合は、対応表を持たない完全な匿名化が必要。仮名化（対応表あり）は引き続き個人情報保護法の適用対象。

🔰 たとえ話：
仮名化は「鍵がかかった金庫の中に対応表がある状態」。金庫の鍵を持っている人は元のデータに戻せる。だから「個人情報のまま」。一方、匿名化は「対応表自体を破棄した状態」。誰も元に戻せないので「個人情報ではなくなる」。

4-3. OSS DICOMサーバの匿名化機能

Orthanc（オープンソースDICOMサーバ）は匿名化REST APIを内包している。

# OrthancのREST APIで特定studyを匿名化
curl -X POST http://localhost:8042/studies/{study-id}/anonymize \
  -H "Content-Type: application/json" \
  -d '{
    "Replace": {
      "PatientName": "ANONYMOUS",
      "PatientID": "ANON-001"
    },
    "Remove": ["PatientBirthDate", "InstitutionName"],
    "Keep": ["StudyDate"],
    "KeepPrivateTags": false
  }'

Orthancの匿名化はDICOM PS 3.15のBasic Confidentiality Profileに準拠している。プラグイン追加でDe-identificationの自動化も可能。

5. 2023年以降に強化されたサイバーセキュリティ義務

5-1. 医療法施行規則改正（2023-04-01）の義務事項

2023年4月の医療法施行規則改正が医療機関のサイバーセキュリティに与えた最大の変化は、「ガイドラインへの適合が事実上の法的義務になった」点。

主な義務事項の整理：

義務事項
├── 安全管理責任者の設置（氏名・役職の明示）
├── 情報セキュリティポリシー・安全管理指針の策定
├── 従業員教育（年1回以上、記録保存）
├── リスクアセスメント（年1回以上、記録保存）
├── 委託先管理（SLA・NDA・年1回以上の安全管理確認）
└── インシデント対応手順（文書化・定期訓練）

専門用語解説：SLA（Service Level Agreement）
「サービス水準合意書」。委託先と「稼働率はXX%以上」「障害対応は何分以内」など具体的な水準を契約で約束したもの。

専門用語解説：NDA（Non-Disclosure Agreement）
「秘密保持契約」。委託先に「業務で知り得た情報を外に漏らしません」と契約させるもの。

5-2. 令和7年5月版チェックリストマニュアルの主要項目

「医療機関等におけるサイバーセキュリティ対策チェックリストマニュアル～医療機関等・事業者向け～」は令和7年5月に厚生労働省から公開された。立入検査での確認基準として機能する。

主要チェック項目（カテゴリ別抜粋）：

安全管理責任者が設置されており、氏名が明示されている
情報セキュリティポリシーが策定・周知されている
退職者・異動者のアカウントを速やかに削除している
管理者権限アカウントが最小化され、共有アカウントを使用していない
リモートアクセス（VPN）に多要素認証を適用している
診療系ネットワークとインターネットが分離されている
VPN装置・ファイアウォールに最新パッチが適用されている
3-2-1原則のバックアップを実施している
バックアップがランサムウェアに感染しても影響を受けない構成になっている
年1回以上リストアテストを実施・記録している
インシデント対応手順書が整備されている
重大インシデント時の報告先（厚労省・NISC）が明確になっている
委託先の安全管理措置を年1回以上確認・記録している

専門用語解説：多要素認証（MFA：Multi-Factor Authentication）
「ID＋パスワード」だけでなく、「スマホアプリの確認コード」「指紋」「ICカード」など複数の要素を組み合わせて認証すること。たとえパスワードが漏れても、スマホがなければログインできない。

5-3. 半田病院・大阪急性期の教訓

共通リスク要因の分析

リスク要因	半田病院	大阪急性期
VPN/ネットワーク機器の脆弱性	VPN装置のパッチ未適用（約1年間）	委託業者のVPN装置が脆弱
侵入経路	外部公開VPNの脆弱性を悪用	給食委託業者のVPN経由
バックアップの被害	バックアップも暗号化された	一部バックアップが同一環境で被害
ネットワーク分離	不十分	委託業者と院内システムが接続
復旧期間	約2ヶ月	約2ヶ月以上

教訓

VPN/ファイアウォールのパッチ管理を怠るな — 公開脆弱性の悪用は侵入後数ヶ月以内に始まるケースが多い
バックアップをネットワークから切り離せ — 常時接続バックアップはランサムウェアにとってもアクセス可能
委託業者のネットワーク接続を診療系と直結させるな — サプライチェーン経由の侵入は防御が難しい
復旧手順を事前に文書化し訓練しておけ — インシデント後に手順書を書き始めても遅い

5-4. 役割別に押さえるべきポイント

役割	最優先で押さえる事項
院長・理事長	安全管理責任者の任命・予算確保・インシデント時の最終意思決定者であることの認識
IT担当者	ネットワーク分離・パッチ管理・バックアップのランサムウェア耐性・ログ管理
現場スタッフ	不審メール・USBの持ち込み禁止・パスワード管理・インシデント報告の習慣化
ベンダSE	総務省・経産省GL第2.0版（令和7年3月）への準拠。納入時の設定ガイドとログ取得の標準化
CE（臨床工学技士）	医療機器系VLANの管理、IoT医療機器のパッチ管理、医療機器安全管理責任者との連携

6. 【新規】生成AI（LLM）を医療機関で使うときのルール

これまでの章で扱った「データ保管・ネットワーク」に加えて、2024〜2026年で急速に問題化してきたのが生成AI（LLM）の医療利用。

「うちの病院でも電子カルテの要約をAIで」「画像所見の下書きをAIに」という相談が増えている一方で、ルールを整理しないまま導入すると個人情報保護法違反や3省2ガイドライン違反になる可能性が高い。

専門用語解説：LLM（Large Language Model）
「大規模言語モデル」。ChatGPT、Claude、Geminiなどの生成AIの中核技術。膨大なテキストを学習して、人間のように自然な文章を生成する。

6-1. 厚労省Q&A「企Q-26」（令和7年5月）が示した公式見解

令和7年5月の厚労省ガイドラインQ&Aで、初めて生成AIに関する公式見解が示された。これは医療AI業界にとって極めて重要な内容。

企Q-26（要旨）：生成AIサービスのプロンプトとして医療情報を入力する場合、入力情報が**「AIの学習等のために保存されないこと」が、契約等において担保されていれば、生成AIサービスのサーバが国内法の適用を受けている必要はない**と考えて良いか？

A：よい。医療情報が保存されないことが、契約等において担保されている場合は国内法の適用を受けていないサーバを利用可能。

これは何を意味するか：

これまで「医療データは絶対に国内サーバで処理しなければならない」という解釈が広く流布していた
しかし令和7年5月の公式Q&Aで「ZDR（データ保存なし）が契約で担保されていれば国外サーバでも可」と明確化された
一方で、契約で担保されていることの文書化は必須

専門用語解説：ZDR（Zero Data Retention）
「データを一切保存しない」ポリシー。プロンプト（AIへの入力）も生成結果も、推論完了後すぐに破棄され、AI事業者側に残らない契約形態。Microsoft Azure OpenAIなどで提供されている。

6-2. 主要クラウドプロバイダの対応状況（2026年4月時点）

GENSHI AI社CTOの長嶋氏（東大病院循環器内科所属）がZennにまとめた「医療業界で突然LLMを使ってくれと言われたら」（2025年12月）を参照しつつ、最新状況を整理する。

出典：長嶋（2025）「医療業界で突然LLMを使ってくれと言われたら」Zenn / GENSHI AI Publication
https://zenn.dev/genshi_ai/articles/ba4536e4722187

各社の日本リージョン対応状況サマリー：

項目	Google Cloud Vertex AI	Microsoft Azure OpenAI	AWS Bedrock
日本リージョンで使えるモデル例	Gemini 2.5 Pro / Flash	GPT-4o（Japan East）	Claude Sonnet 4.5（日本CRIS）
データ主権の保証	✅ ただしGSU契約必須	✅ Standardデプロイで国内完結	✅ CRIS利用で国内完結
課金形態	Provisioned Throughput必須	従量課金可	従量課金可（+10%）
最低固定費	約$2,700/月〜（必須）	なし	なし

専門用語解説：CRIS（Cross-Region Inference）
AWS Bedrockの仕組み。「東京リージョン宛てのリクエストを必要に応じて大阪リージョンに自動で振り分ける」ことで、日本国内に閉じたまま高可用性を実現する。災害対策にもなる。

専門用語解説：GSU（Generative AI Scale Unit）
Google Cloud Vertex AIで「指定リージョン専用の処理能力」を確保するための購入単位。Pay-as-you-go（従量課金）モデルでは他のユーザーとGPUを共有しグローバルにルーティングされてしまうため、日本リージョンに固定したい場合はGSU購入が必須。

各社の特徴を平易に整理

🔰 Google Cloud Vertex AI

日本リージョンで使うには「専用線契約」のような固定費（GSU）が必要
月額40万円〜の固定費が前提なので、小規模な医療機関には敷居が高い
大規模病院・大学病院がコミットして使うには適している

🔰 Microsoft Azure OpenAI

GPT-4oなら日本リージョン（Japan East）に閉じた処理が可能
最新のGPT-5は日本リージョン非対応 → ZDRオプション申請が必要
従量課金で始められるので導入しやすい

🔰 AWS Bedrock（Claude）

Claude Sonnet 4.5を日本国内CRIS（東京・大阪）で利用可能
推論プロファイルIDを jp.anthropic.claude-sonnet-4-5-... に変えるだけ
通常価格＋10%で日本完結。固定費なしで始められる
東京・大阪自動冗長化が標準（DR対策にもなる）

6-3. 推奨される選定フロー

医療機関が生成AIを導入するときの判断フロー：

┌─────────────────────────────────────┐
│ Step 1: 何のために使うのか整理        │
│  - 文書要約 / 議事録作成 / 論文検索  │
│  - 患者情報を入力するか？            │
└─────────────────────────────────────┘
              ↓
┌─────────────────────────────────────┐
│ Step 2: 患者情報の入力有無で分岐      │
│  入力する → 厳格な要件               │
│  入力しない → 一般のSaaSと同じ       │
└─────────────────────────────────────┘
              ↓
┌─────────────────────────────────────┐
│ Step 3: 患者情報を入力する場合        │
│  ① 日本リージョン完結のモデル        │
│  ② または ZDR適用＋契約担保          │
│  ③ 委託契約・SLA・NDA                │
│  ④ 安全管理責任者の承認              │
└─────────────────────────────────────┘
              ↓
┌─────────────────────────────────────┐
│ Step 4: ログ・監査体制               │
│  - 誰が・いつ・何を入力したか        │
│  - 出力結果の検証フロー              │
└─────────────────────────────────────┘

6-4. ローカルLLMという第3の選択肢

クラウドのLLMとは別に、院内にLLMを完全に閉じ込めて動かす選択肢もある。

専門用語解説：ローカルLLM
ChatGPTのようにクラウドではなく、自院内のサーバ（GPU搭載PC）でLLMを動かす方式。データが一切外に出ないため、3省2ガイドライン上は最も安全。代表例：Ollama＋Qwen、LM Studio＋Llama、vLLMなど。

方式	強み	弱み
クラウドLLM（GPT/Claude/Gemini）	最高性能・低コスト・運用不要	データが外に出る・法的整理が必要
ローカルLLM（Ollama＋Qwen等）	データ完全国内保持・契約不要	性能が劣る・GPUコスト・運用負荷

筆者の見解として、まずローカルLLMで院内の業務フロー（議事録作成・文書要約・コード補助など）に慣れてから、必要に応じてクラウドLLMの委託契約を検討するのが、医療機関にとって現実的なアプローチだと考えている。

6-5. 法律上の整理（生成AI×医療情報）

項目	法律上大丈夫なこと	法律上注意が必要なこと
個人情報保護法	患者情報を含まないテンプレート文書のAI生成	患者氏名・ID・症状をそのままプロンプトに入れる
個人情報保護法第27条	ZDR適用＋契約担保＋安全管理責任者承認のクラウドLLM利用	上記なしでChatGPT無料版に患者情報を入力
個人情報保護法第28条	完全に匿名化したデータを国外サーバAIに送信	仮名化止まりのデータを国外サーバAIに送信
薬機法	「記録・整理」を支援するAI（例：議事録作成）	「診断支援」「臨床判断補助」を謳うAI（SaMDに該当する可能性）
著作権法	院内文書の要約のためのAI利用（30条の4が適用される可能性）	他社の論文・教科書をそのままアップロードして共有
臨床工学技士法第40条	業務情報を含まない一般的な技術質問	患者情報を含む業務相談をAIに行うこと

専門用語解説：SaMD（Software as a Medical Device）
「医療機器プログラム」。ソフトウェアそのものが医療機器として規制対象になるもの。薬機法第2条第4項。診断支援・治療判断補助の機能を持つと該当する可能性が高い。

筆者の見解：
「ChatGPTに患者カルテを貼り付けて要約させる」行為は、現状ほぼ確実に個人情報保護法第27条（第三者提供）違反になる。多くの医療従事者がこれを「個人で使ってるから大丈夫」と思っているが、業務で行えば医療機関全体の責任問題になる。まずは院内でルールを明文化することが急務。

7. マイナ保険証・オンライン資格確認とネットワーク要件

7-1. 2023年4月義務化の概要

健康保険法等の改正により、医療機関・薬局でのオンライン資格確認（オン資）設備の導入が2023年4月より原則義務化された。2024年12月には従来の健康保険証が廃止され、マイナ保険証への完全移行が完了。

必要な設備：

顔認証付きカードリーダー
オン資ネットワークへの接続（社会保険診療報酬支払基金が運営）
レセプトコンピュータとの連携

7-2. 院内ネットワークへの影響

オン資ネットワークは独立したVLANとして分離することが推奨されている。

[オン資ネットワーク（支払基金接続）]
    ↕ 専用回線 or IPsec+IKE VPN
[受付端末・顔認証カードリーダー]
    ↕ VLAN分離
[電子カルテシステム] ← 資格確認データのみ連携（APIレベル）

オン資ネットワーク経由で他の業務トラフィックを通すことは禁止。電子カルテとの連携はデータ連携インタフェース（API）を通じて最小限に行う。

7-3. ネットワーク工事・NAS再構築時の運用注意

ネットワーク工事中にオン資接続が停止しないよう、工事計画を事前に支払基金に確認
顔認証付きカードリーダーの設置場所変更時はLAN配線の引き直しが必要になるケースがある
工事期間中のオン資停止時は「資格確認できない旨を患者に説明する」対応手順を事前に整備

8. 経産省・総務省GL第2.0版（令和7年3月）の主な変更点

医療機関だけでなく、医療機関にシステム・サービスを提供するベンダ側に課されるルールも2025年に大きく更新された。

8-1. 第2.0版の概要

公開日： 令和7年3月28日
改定対象： 医療情報を取り扱う情報システム・サービスの提供事業者向け
意見公募期間： 令和6年10月2日〜10月31日（17件の意見を反映）
背景： サイバー攻撃の多様化・巧妙化、厚労省GL第6.0版との整合性確保

8-2. 主要な変更点（要点）

第1.1版から第2.0版への主要な変更点：

リスクベースアプローチの強化
- 「一律に要求事項を定める」のではなく、医療情報システム等の特性に応じた必要十分な対策をリスクマネジメントプロセスで定義
- リスクコミュニケーション（医療機関と事業者の対話）を重視
役割分担の明確化
- 経産省が令和6年6月に公開した「医療情報システムの契約における当事者間の役割分担に関する確認表」と連動
- SLA（サービスレベル合意書）への落とし込みを推奨
ゼロトラスト思想の組み込み強化
- 第6.0版と整合した形で、境界防御型＋ゼロトラスト型のハイブリッドを推奨
サプライチェーン管理の強化
- 半田病院・大阪急性期事案で問題となった「委託先経由の侵入」への対応
- ベンダ側に対しても自社のサプライチェーン（再委託先）の管理責任を課す

8-3. ベンダSEが押さえるべき実務ポイント

項目	第1.1版	第2.0版で強化された点
サービス仕様適合開示書	公開推奨	様式例が更新され、より詳細な記述を要求
SLA参考例	提供	役割分担確認表との連動
FAQ	令和5年7月版	第2.0版に合わせて更新
インシデント発生時の責任分界	概要記載	より具体的な事例ベースで明示

9. まとめ：法律を「守るだけ」でなく「設計に活かす」

9-1. ガイドラインを設計指針として読む

法令・ガイドラインを読むと、「何をやってはいけないか」だけでなく、**「良いシステム設計とはどういうものか」**が書かれていることに気づく。

ネットワーク分離 → セグメント設計の指針
バックアップ3-2-1ルール → 可用性・災害復旧設計の指針
アクセスログの保管 → 運用監視設計の指針
委託先管理の義務 → ベンダとの契約・SLA設計の指針
生成AI Q&A（企Q-26）→ AI活用設計の指針

ガイドラインに従う設計は、結果として堅牢で長期運用できるシステムになる。

9-2. 「義務だから守る」から「設計の制約として活かす」

義務思考	設計思考
バックアップをどこかに取ればよい	ランサムウェアが来ても72時間以内に復旧できる構成を作る
ネットワーク分離が必要らしい	侵入されても横展開できない設計にする
ログを取ればよい	異常を検知して30分以内にアラートを飛ばせる体制を作る
委託先にNDAを結ばせる	委託先のインシデントが自院に波及しない設計をする
生成AIは怖いから使わない	ZDR契約＋ローカルLLMを組み合わせ、患者情報の取扱いルールを明文化する

義務として最低ラインを守るだけでは、半田・大阪急性期と同じリスクが残る。ガイドラインを「設計の最低仕様」として読み、その意図（なぜその要件があるのか）を理解した上で設計することが重要。

9-3. IT担当者が経営層に説明するときの語り口

経営層は「法律」「ガイドライン」という言葉よりも「リスクとコスト」で話を聞く。

Before: 「医療法施行規則改正でバックアップのランサムウェア耐性が義務になりました」

After:  「大阪急性期のケースでは復旧に数億円規模の費用がかかりました。
         現状の構成では同じリスクがあります。
         バックアップのオフライン化に必要な費用は〇〇万円です。
         これは義務でもありますが、投資対効果として合理的です」

数字（復旧費用・停止期間・対策コスト）と法的根拠（立入検査・行政指導）を組み合わせることで、経営判断を促しやすくなる。

9-4. 2026年に押さえるべきアクション項目

最後に、医療機関のIT担当者・SE・CEが2026年中に必ず確認しておくべき項目を5つに絞ってまとめる。

令和7年5月版チェックリストマニュアルとの照合 — 立入検査の確認基準として機能する
経産省・総務省GL第2.0版へのベンダ準拠確認 — 委託契約・SLAの見直し
生成AI利用ルールの院内文書化 — 厚労省Q&A企Q-26を踏まえてZDR・委託契約・利用範囲を明文化
バックアップのランサムウェア耐性の検証 — 単なる存在確認ではなく、年1回以上のリストアテストの実施
委託先のサプライチェーン管理 — 委託先の再委託先まで含めたセキュリティ対応の確認

法律上の整理（最後にもう一度確認）

項目	法律上大丈夫なこと	法律上注意が必要なこと
バックアップ	3-2-1原則＋オフライン保管＋年1回リストア	単一NASのみ・常時接続のみ
ネットワーク	VLAN分離・UTM設置・MFA適用VPN	診療系とインターネットの直接接続
生成AI	ローカルLLM・ZDR契約済みクラウドLLM	患者情報を無料SaaS型AIに直接入力
委託	NDA・SLA・年1回確認	「お任せ」状態での委託
電子保存	WORM＋ログ＋スナップショット＋3-2-1	共有フォルダのみ・改ざんログなし

参考資料（一次情報）

厚生労働省

医療情報システムの安全管理に関するガイドライン第6.0版（令和5年5月）
https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html
同 Q&A（令和7年5月）
https://www.mhlw.go.jp/content/10808000/001145860.pdf
医療機関等におけるサイバーセキュリティ対策チェックリストマニュアル～医療機関等・事業者向け～（令和7年5月）
https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html
個人情報保護委員会・厚労省医療・介護関係事業者における個人情報の適切な取扱いのためのガイダンス
https://www.ppc.go.jp/personalinfo/legal/iryoukaigo_guidance/

経済産業省・総務省

医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン第2.0版（令和7年3月28日）
https://www.meti.go.jp/policy/mono_info_service/healthcare/teikyoujigyousyagl.html
総務省第2.0版公開報道発表（令和7年3月28日）
https://www.soumu.go.jp/menu_news/s-news/01ryutsu06_02000427.html
医療情報システムの契約における当事者間の役割分担に関する確認表（経産省、令和6年6月）

法令（e-Gov法令検索）

個人情報保護法：https://elaws.e-gov.go.jp/document?lawid=415AC0000000057
医療法：https://elaws.e-gov.go.jp/document?lawid=323AC0000000205
薬機法：https://elaws.e-gov.go.jp/document?lawid=335AC0000000145
臨床工学技士法：https://elaws.e-gov.go.jp/document?lawid=362AC0000000060
著作権法：https://elaws.e-gov.go.jp/document?lawid=345AC0000000048
刑法：https://elaws.e-gov.go.jp/document?lawid=140AC0000000045

過去のサイバー攻撃事案報告書

半田病院ランサムウェア感染事案に係る調査報告書（2022年6月、徳島県公表）
大阪急性期・総合医療センターサイバー攻撃に係る調査報告書（2023年6月、同センター公表）

DICOM・標準仕様

DICOM PS 3.15 Appendix E: Attribute Confidentiality Profiles
https://dicom.nema.org/medical/dicom/current/output/html/part15.html
Orthanc DICOM Server — Anonymization Documentation
https://orthanc.uclouvain.be/book/users/anonymization.html

生成AI関連の参考記事

長嶋（2025）「医療業界で突然LLMを使ってくれと言われたら」Zenn / GENSHI AI Publication
https://zenn.dev/genshi_ai/articles/ba4536e4722187
AWS Blog: Amazon Bedrock で日本国内に閉じた Claude 4.5 の推論が可能に
https://aws.amazon.com/jp/blogs/news/amazon-bedrock-now-supports-japan-cross-region-inference/

著者プロフィール

臨床工学技士 × AIエンジニア

フィードバック・誤りの指摘は歓迎します。一次情報は日々更新されるため、本記事の内容も随時見直していきます。