医療データのGWS保存: 適合/不適合の二択からリスクベース評価へ

既存の公開レポート（GWS医療データ評価レポート）では、医療情報安全管理ガイドラインの遵守事項を文言通りに0/1で判定し、3要件（保存場所・国内法適用・国外法リスク）が全プランで未解消と結論した。

しかし、3省2ガイドライン自体が第6.0版でリスクベースアプローチに転換している。本文書は、前回の0/1判定をリスクベース評価に切り替え、3要件に対する具体的な判断の道筋を示すことを目的とする。

分析は以下の3層で構成する。各層の詳細な法令分析・認証データ・原文対比は参考章に収録し、本文では評価結果と判断の論理を中心に記述する。

第1層で法的な障壁がないことを確認し、第2層で残る3要件をリスクベースで評価して補完措置と判断フレームワークを提示し、第3層で国際比較を通じて制度の方向性を考察する。最終的に、医療機関が採用判断に至る具体的な道筋を示す。

本文書の範囲: 本文書はGWSが医療情報の外部保存先として採用可能かどうかの評価に焦点を当てている。採用可能と判断した場合に必要となる実装面の設計 — データ分類と保存ポリシー、アクセス制御設計、暗号化方式の選定、運用手順の策定、患者への説明方針、インシデント対応体制の構築、既存システムからの移行計画など — は本文書の対象外であり、別途の設計・実装フェーズで取り組むべき重い作業として存在する。

本文書は分量が多いため、全体の論理展開と結論を先に要約する。

第1層: 法律 — 法的障壁はない

医療情報のクラウド外部保存に関係しうる日本の法令を網羅的に洗い出し（個人情報保護法、医療法、刑法、各業法等）、GWSが各法令の要件を充足しているかを確認した。結論として、GWSの利用に法律上の障壁は認められない。個人情報保護法上は「委託」（第27条5項1号）として整理でき、基準適合体制（施行規則第11条の2）を備えれば外国提供の同意も不要。守秘義務規定も、正当な委託であれば漏示にあたらない。

第2層: ガイドライン — 残る3要件はリスクベースで「条件付き受容」

法的に問題がない一方、3省2ガイドライン v6.0 が求める3要件（保存場所の確認・国内法適用の確認・国外法リスクの評価）はGWSの現行構成では形式的に充足できない。ただし、これらは法令ではなくガイドライン固有の要件であり、v6.0のリスクベースアプローチに則って評価すべき対象である。

GWSが取得しているISMAP登録をベースラインに、医療GL固有の差分を評価した結果、GWSは「条件付き受容」に該当する。具体的には、CSE（クライアントサイド暗号化）の導入、契約条項の整備（準拠法・裁判管轄・監査権）、経営層による明示的なリスク受容を条件として、医療情報の外部保存先として利用可能と評価できる。

第3層: あるべき姿 — 場所ベースから能力ベースへ

日本のガイドラインが保存場所を重視する背景には、HIPAAのような強力な執行メカニズム（BAA・高額罰金・漏えい通知義務）がないことがある。HIPAAはデータの保存場所を規制せず、「どこに置いても違反すれば高額の罰則が科される」仕組みで担保している。日本は執行力の不足を場所で補償する構造になっている。

短期的にはリスクベースで「条件付き受容」として利用を進めつつ、中長期的にはクラウド事業者への法定契約義務や罰則強化など、能力ベースの制度整備が望ましい。

医療情報をクラウドで外部保存する際に関係しうる法令を4つのカテゴリに分類した。各法令について、GWSでの充足状況を評価した結果、GWSをシステムとして利用すること自体に法的障壁は認められなかった。ただし、これは利用さえすれば何でも許容されるという意味ではない。各法令の要件を充足するためには、適切なライセンスの選定（データリージョン設定やCSEに対応するEnterprise Standard以上等）と、委託先監督・アクセス制御・監査ログ管理等の運用体制の構築が前提となる。

注1: マイナンバー（個人番号）自体は通常の医療情報には含まれない。マイナンバーを含むファイルをGWSに保存する場合は、第11条の委託先監督義務に基づく追加措置（取扱規程、アクセス制限等）が必要だが、GWSの機能で技術的に対応可能。

注2: 施行規則第14条第2項は「サイバーセキュリティ確保に必要な措置」を義務付けるが、保存場所・国内法適用・国外法リスクの3要件は同条の直接的な射程外。この点は第2層で分析する。

医療法施行規則第14条第2項の射程

令和5年改正で新設された医療法施行規則第14条第2項は、病院等の管理者に「サイバーセキュリティを確保するために必要な措置を講じなければならない」と義務付ける。

通知による橋渡し

同条項の具体的内容を示す通知「産情発0310第2号」（令和5年3月10日付）の第4留意事項には、以下の記載がある。

安全管理ガイドラインを参照の上、サイバー攻撃に対する対策を含めセキュリティ対策全般について適切な対応を行うこと

この文言は「サイバー攻撃に対する対策」に限定せず、「セキュリティ対策全般」としてガイドライン全体を参照している。

3要件は省令の直接的な射程に入るか

ここで重要な問いが生じる。ガイドラインの3要件（保存場所・国内法適用・国外法リスク）は、省令が求める「サイバーセキュリティ」の範囲に含まれるか。

3要件は「サイバーセキュリティ」の問題ではなく「データ主権・法域」の問題である。したがって、省令第14条第2項の直接的な射程には入らない可能性が高い。ただし、通知が「セキュリティ対策全般」としてガイドライン全体を参照しているため、行政指導の根拠としてはガイドライン全体が参照される。

法的強制力の構造

3要件への不適合は、直ちに法令違反とはならない。ただし、立入検査での行政指導の根拠にはなりうる。

チェックリストの法的性質

「医療機関におけるサイバーセキュリティ対策チェックリスト」は、医療法第25条に基づく立入検査で使用される確認項目リストである。事務連絡として各都道府県等に発出されており、法的拘束力を持つ文書ではない。

3要件の包含有無

チェックリストの項目を精査した結果、保存場所・国内法適用・国外法リスクの3論点に該当する項目は含まれていない。チェックリストはサイバーセキュリティ対策（バックアップ、リモート保守、インシデント対応、MDS/SDS提出等）に特化しており、データ主権・法域の問題は対象外である。

エスカレーション経路

立入検査で不適合が指摘された場合のエスカレーション経路は以下のとおり。

1. 立入検査での指摘: 医療法第25条に基づく。チェックリストの確認項目に沿って実施される。
2. 行政指導: 法的強制力なし。改善を求める助言・指導。従わなくても直接の罰則はないが、不利益処分の前提となりうる。
3. 措置命令: 医療法第24条の2に基づく。「特に必要がある場合」に、管理者に対して期限を定めて改善のために必要な措置をとるべきことを命ずることができる。

実務上の意味 — 3要件のガイドライン内での位置づけ

3要件は立入検査チェックリストに含まれていない。ガイドラインの遵守事項には「Must（義務）」と「Should（推奨）」の濃淡があり、立入検査チェックリストは行政が実地で確認する重点項目を絞り込んだものである。3要件がチェックリストから外れているという事実は、行政がこれらを「全医療機関に一律に即時対応を求める最優先事項」としては位置づけていないことを示唆する。

実際、チェックリストが重点を置くのはアクセス制御・バックアップ・インシデント対応・BCP等の基本的な安全管理措置であり、保存場所や外国法リスクといった論点はこれらと比較して優先度が劣後する扱いになっている。医療機関がGWSを採用した場合でも、定期立入検査の場で保存場所や国外法リスクについて直接問われる蓋然性は高くない。

ただし、ガイドライン全体が行政指導の根拠となる以上、チェックリスト外の論点について指導がなされる可能性は排除できない。特に医療事故や漏えい事案が発生した場合には、チェックリストの有無にかかわらずガイドライン全体に照らした調査が行われうる。3要件は「対応不要」ではなく、「一律の即時対応が求められる性質ではないが、リスク評価の上で考慮すべき論点」と位置づけるのが適切である。

本文書の分析の大前提として、3省2ガイドラインが第6.0版（令和5年）でリスクベースアプローチへ転換したことを整理する。

従来のアプローチ（〜第5.2版）

遵守事項を具体的に列挙し、各項目について「適合しているか否か」を判定する方式。要件の充足が二値（適合/不適合）で評価されていた。

リスクベースアプローチ（第6.0版〜）

第6.0版では、ガイドラインの構成自体が「概説編」「経営管理編」「企画管理編」「システム運用編」に再編され、医療機関が自らの環境・脅威・リスクを分析し、必要な安全管理措置を選択・実装し、残存リスクを管理するアプローチへ転換した。経営層のリスク判断と責任を明確に位置づけ、「全項目を一律に0/1で判定する」のではなく、リスクの大きさと対策の十分性で判断することを前提としている。

3省2ガイドラインの事業者側（総務省・経産省GL）も同時に改定され、事業者側のリスクベースの情報提供と、医療機関との合意形成プロセスを重視する構成になった。

本文書への意味

ガイドライン自体がリスクベースの評価を前提としている以上、外部保存の委託先選定においても「遵守事項の文言に形式的に適合するか」だけでなく「遵守事項が保護しようとしているリスクに対して、どの程度の低減措置が講じられているか」で評価することは、ガイドラインの枠組みの中での判断である。「リスクベースで評価する」ことはガイドラインを迂回する行為ではなく、ガイドラインが意図した判断方式である。

GWSが取得している認証のうち、医療情報の外部保存に関するリスクを最も幅広くカバーするのがISMAP（政府情報システムのためのセキュリティ評価制度）登録である。ISMAP登録の詳細な分析は参考章に収録しているが、ここでは評価結果の要点を示す。

ISMAPが医療GLと重なる領域

ISMAP管理基準は、技術的安全管理（暗号化・アクセス制御・監査ログ）、組織的安全管理（ガバナンス・方針・責任体制）、運用管理（BCP・インシデント対応）、委託先管理（サプライチェーン）を包括的に評価する。これらは医療GLが求める安全管理措置の大半と重なっており、GWSはISMAP登録をはじめとする各種認証によって医療GLの要求の相当部分を既に充足している。

ISMAPではカバーされない3要件

ISMAPの管理基準と医療GLの遵守事項を対比すると、セキュリティの技術的・組織的管理に関しては大部分が重複しているが、保存場所・国内法適用・外国法リスクの3要件だけが医療GL固有の要求として残る。これら3点はISMAPの評価対象に含まれておらず、GWSがISMAP登録済みであっても自動的には充足されない。3要件それぞれの原文対比は参考章の詳細分析（保存場所・国内法・国外法）を参照。ISMAPが各論点に対して提供するリスクヘッジ効果と認証で達成済みと見なせる範囲も参考章に収録している。

前節のISMAP評価で示したとおり、セキュリティの技術的・組織的管理はISMAPと医療GLで大きく重なるが、保存場所・国内法適用・外国法リスクの3要件だけがISMAPでカバーされない。なぜこの3点だけが残るのか。

これは、3要件の性質がガイドラインの他の要件と根本的に異なるためである。ガバナンスやアクセス制御の要件は「リスクの大きさに応じて対策を選ぶ」タイプであり、ISMAPのようなセキュリティ評価で代替できる。一方、3要件は「事実としてそうなっているか」を確認するタイプの要件である。

• 保存場所: データが国内に保存されているか — 事実の確認
• 国内法の適用: 委託先が国内法の下で管理義務を負っているか — 法域の確認
• 外国法のリスク: 外国政府によるデータアクセスの可能性があるか — 法制度の確認

この違いの背景には制度目的の違いがある。ISMAPは政府が自らの情報を預ける先を評価する制度であり、リスクの大きさを判断して受容する裁量がある。一方、医療GLは患者から預かった情報に対する保護義務を定めており、行政監督の実効性を確保する目的から、場所・法域・外国法について確認可能な事実を求めている。

GWSの場合、ISMAPの管理策は全て満たしている。しかし医療GLが求める事実確認に対しては、日本国内への保存を保証できず、国内法適用の確認が困難であり、米国CLOUD Actの適用を排除できない。残存リスクの核心は、行政調査の実効性が保証されないことと、患者データへの外国政府アクセスを制度的に排除できないことにある。

このギャップは、セキュリティの技術的水準の問題ではなく、制度設計の構造に由来する。次節では、この事実確認型の要件を0/1で形式的に適用した場合に生じる問題を指摘し、リスクベースの評価枠組みの中でどう扱うべきかを検討する。

前節まででガイドラインが省令義務の具体化基準として事実上の強制力を有する一方、3省2ガイドライン自体がリスクベースアプローチを採用していることを確認した。また、ISMAPでカバーされない3要件が事実確認型の要件であり、0/1での形式判定を前提としていることを示した。

ここからは、この3要件をどう評価し、実務上の判断に落とし込むかを段階的に組み立てる。まず本節で0/1判定の問題点を指摘してリスクベース評価への転換を論じた上で、続く節で具体的な判定基準（3段階）、残存リスクに対する補完措置、補完措置の組み合わせ方（階層モデル）、そしてこれらを統合した判断フレームワークを示し、最後にGWSへ適用した評価結果を提示する。

0/1判定が生む逆説

保存場所・国内法適用・国外法リスクの3点を文言通りの0/1で判定すると、以下のような結論になる。

• ISMAP・ISO 27001・SOC 2・FedRAMP等を取得し、世界最高水準のセキュリティ体制を持つ外資系クラウド → 不適合（保存場所が日本でない）
• 外部認証を一切取得しておらず、セキュリティ監査実績もない国内事業者が国内DCで運用 → 適合（保存場所が日本でDC所在地が確認できる）

この結論は、患者データの安全性という本来の目的に照らして明らかに不合理である。ガイドラインの趣旨は「患者データを安全に管理すること」であり、「国内にさえあればよい」ではない。

リスク評価に基づく判断への転換

3省2ガイドラインが第6.0版でリスクベースアプローチに転換したことを踏まえれば、実務上の判断は以下の構造で行うべきである。

1. ガイドラインの各要件が何を守ろうとしているか（保護目的）を特定する
2. 候補サービスが保護目的に対してどの程度のリスク低減を達成しているかを評価する（外部認証はこのリスク低減の証拠になる）
3. 残存リスクが、サービス利用によるベネフィット（業務効率、可用性、コスト、セキュリティ水準）に対して許容可能かを経営判断する
4. 許容する場合は、その判断根拠と補完措置を文書化する

この判断プロセス自体が、第6.0版のリスクベースアプローチに沿ったものである。

前節でリスクベースの判断プロセスを示したが、実務で運用するには判定の目安が必要になる。ここでは、外部保存先の条件を3段階に分類し、それぞれの受容判断と必要な対応を整理する。

• 受容しやすい: 日本リージョンまたは日本国内データセンター、契約主体・準拠法・裁判管轄が明確、再委託先とサポート経路が列挙済み、ISMAP等の第三者評価あり、医療機関側で契約・監査・終了手順を持てる
• 条件付き受容: 外資系または国外親会社の影響があるが、CSE/HYOK、顧客管理鍵、国外アクセス制御、法的請求通知、データ最小化、仮名化により残リスクを経営層が明示的に受容できる
• 原則不受容: 保存場所・バックアップ・ログ・再委託先が不明、事業者が医療情報を平文復号可能、国外法に基づく開示時の通知・異議申立て・最小化手順がない、終了時返却・破棄証跡がない

GWSの判定

GWSは上記3段階のうち「条件付き受容」に該当する。理由: (1) ISMAP登録済みで第三者評価があること、(2) 日本法準拠の契約締結とGoogle合同会社を契約主体にできること、(3) CSE/CMEKによる暗号化強化が可能なこと、から「原則不受容」の条件には該当しない。一方、(4) 米国法域の影響（CLOUD Act）が構造的に排除不能なこと、(5) 日本国内DCの指定ができないこと、から「受容しやすい」の条件も満たさない。したがって、CSE導入・契約条項の強化・経営層による明示的リスク受容を前提とした「条件付き受容」が妥当な判定となる。

前節の3段階判定で「条件付き受容」に分類されたサービスは、補完措置によって残存リスクを低減できる。以下に主な補完措置の有効性と限界を整理する。

GWSへの推奨優先順位

GWSで残存リスクを効果的に低減するには、以下の優先順位で補完措置を導入することを推奨する。

1. CSEの導入（効果: 高）: 事業者・国外当局が事業者経由で医療情報の平文にアクセスするリスクを構造的に排除する。最も費用対効果が高い単一施策
2. 契約条項の整備（効果: 中〜高）: 保存地域・準拠法・裁判管轄・監査権・返却・破棄条項を明記し、責任分界を法的に確保する
3. 法的請求条項（効果: 中）: 政府からのアクセス要求に対する通知・異議申立て・最小化手順を契約に含める
4. 組織的対策（効果: 基盤）: TIA類似の法域影響評価を実施し、経営層が残存リスクを理解した上で承認する体制を構築する

上記の補完措置は単独ではなく、組み合わせて段階的に導入することで効果が高まる。以下の4層モデルは、認証を起点に契約・技術・組織の措置を積み上げていく実装順序を示す。

GWSへの推奨階層

GWSを医療情報の外部保存に利用する場合、第3層（認証 + 契約 + 技術）を最低ラインとし、第4層（+ 組織）を目標水準とすることを推奨する。第1層（認証のみ）や第2層（認証 + 契約）では、事業者が医療情報を平文で復号可能な状態が残り、CLOUD Actによる開示リスクに対する技術的防御がない。第3層でCSE/HYOKを導入することで事業者経由の平文開示リスクを大幅に低減でき、第4層でTIA・経営層承認・患者説明を加えることで、残存リスクの明示的受容と説明責任を果たす構成となる。

1. 認証による充足確認: 利用予定サービスのISMAP登録、対象サービス名、対象リージョン、対象機能、認証範囲を確認する。重なる観点については「第三者評価済み」の証拠として整理する
2. 差異観点の個別確認: 医療情報・ログ・メタデータ・バックアップ等をデータ種別ごとに分解し、各データ種別について保存場所・処理場所・バックアップ・障害時移転・運用者アクセス・再委託先を一覧化する。定性7軸・定量9指標で評価する
3. 補完措置の設計: 差異観点のリスクレベルに応じて、契約条項・技術的対策（CSE/HYOK/仮名化等）・組織的対策（法域影響評価・経営層承認・患者説明等）を組み合わせる（階層モデルを参照）
4. 残存リスクの判定: 「受容しやすい」「条件付き受容」「原則不受容」の3段階で判定する。条件付き受容の場合は、経営層が明示的にリスクを受容し、その判断根拠を記録する
5. 文書化と継続管理: 委託先管理台帳、リスク受容記録、補完措置の実施記録、定期的な再評価計画を文書化する。サービス仕様適合開示書・JAHIS MDS/SDSとの照合も行う

残存リスクの整理

ベネフィットの整理

リスクは単独で評価するものではなく、そのサービスを利用することで得られるベネフィットとの比較で判断する。

判断の構造

残存リスクの核心は「日本国外に保存される」「CLOUD Actが存在する」という構造的事実である。これらは補完措置で影響を限定できるが、事実自体は消えない。

一方、このリスクを回避するために認証水準の低い国内事業者を選択すれば、保存場所・法域の要件は満たすが、セキュリティ・可用性・運用管理の面で別のリスクを抱える。

最終的な判断は、「保存場所・法域の残存リスク」と「セキュリティ水準・可用性・運用効率のベネフィット」を比較し、補完措置を含めた総合リスクが許容可能かどうかを経営層が判断する構成になる。この判断は「ガイドライン違反かどうか」ではなく「患者データの安全性を総合的に最大化できるか」という本来の目的に基づくべきである。

米国のHIPAA（Health Insurance Portability and Accountability Act）は、医療データ保護に関する連邦法であり、日本の3省2ガイドラインとは根本的に異なるアプローチをとる。HIPAAは医療データの保存場所を規制せず、データをどう保護するか（能力）で評価する。法的強制力を持つ連邦法であるため、日本のガイドラインとは位置づけが異なるが、医療データ保護の設計思想として重要な参照点になる。

HIPAAの基本構造

HIPAAが保存場所を規定しない理由

HIPAAは医療データの保存場所（国内/国外）を規定していない。米国の医療データが海外のサーバーに保存されることは、HIPAAの下では禁止されていない。HIPAAが重視するのは「どこにあるか」ではなく「どう守られているか」である。

• 暗号化されているか（技術的セーフガード）
• アクセス制御が適切か（管理的・技術的セーフガード）
• BAA（委託先契約）が締結されているか
• 漏えい時の通知体制があるか
• 定期的なリスク分析が行われているか

Google WorkspaceはHIPAA BAA対応サービスであり、BAA締結の上でPHI（保護対象医療情報）を取り扱うことが認められている。これは、Googleのセキュリティ体制が米国連邦法の基準で医療データを扱える水準にあることの証拠である。

日本のガイドラインとの比較

HIPAAは罰則付きの連邦法でありながら保存場所を規定せず、日本のガイドラインは省令義務の具体化基準（事実上の強制力あり）でありながら保存場所の確認を遵守事項としている。この構造の逆転は、日本の医療データ保護制度が場所ベースの確認に依存しすぎている可能性を示唆する。

執行メカニズムの比較

場所で補償する構造

日本のガイドラインが「保存場所」「国内法適用」「国外法リスク」を明示的に要件とする背景には、HIPAAのような執行構造がないことがある。

• 執行が医療機関にしか及ばない: 海外のクラウド事業者に対して日本の規制当局が直接義務を課す法的根拠がない。HIPAAのBAA相当の法定契約義務も存在しない（ガイドラインの推奨にとどまる）
• 行政指導に法的拘束力がない: エスカレーション経路の第一段階である行政指導について、行政手続法第32条は「行政指導に従わなかったことを理由として不利益な取扱いをしてはならない」と定めており、法的強制力を持たない
• 違反に対する高額の罰金制度がない: HIPAA のような「違反コストを十分に高くして抑止する」仕組みが制度として存在しない

執行メカニズムが弱い環境では、データの物理的所在を国内に限定することで、「最悪の事態でも日本法が適用される」「行政が物理的にアクセスできる」という担保を確保するしかない。これは執行力の不足を場所で補償する構造であり、能力が低いわけではなく、制度設計の前提が異なることによる帰結である。

v6.0のリスクベースアプローチはこの構造を部分的に緩和する

3省2ガイドライン v6.0がリスクベースアプローチに転換したことは、「場所の0/1判定」から「リスク評価に基づく判断」への移行を意味する。ISMAPのような外部認証を取得し、データリージョンを日本に設定し、CLOUD Act等のリスクを評価した上でリスク受容する判断は、v6.0の枠組みの中で合理的に位置づけられる。

第2層ではガイドラインの3要件をリスクベースで評価し、GWSが「条件付き受容」に該当すること、補完措置により残存リスクを低減できることを示した。第3層では国際比較を通じて、日本のガイドラインが場所ベースである構造的理由と、能力ベースへの移行の方向性を考察した。本章では、これらの分析を踏まえ、医療機関が取り得る2つの道を提示する。

道A: 現行制度下でのリスク受容（短期）

以下は医療機関が内部の意思決定プロセスとして行うフレームワークである。患者や行政への外部開示を前提としたものではなく、組織としてGWS利用の判断根拠を整理・記録し、立入検査等で求められた場合に提示できるよう備えるものである。

現行の法律は医療データの国内保存を義務づけていない。ガイドラインは国内法適用の確認を遵守事項としている。ガイドライン違反に直接の罰則はないが、省令義務の具体化基準として事実上の強制力を有する。したがって、以下の条件を満たした上でGWSの利用を開始することは、法律・省令に直接違反するものではなく、リスクを取れる判断である。

1. 法律上の義務は充足: 個人情報保護法の安全管理措置（ISMAPで実質的にカバー）、医療法の保存義務（電子保存の要件を満たす）
2. ガイドライン逸脱の明示: 保存場所・国内法適用・国外法リスクの3点についてガイドラインの遵守事項を文言通りには満たさないことを文書化
3. リスク低減の証拠: ISMAP認証、HIPAA BAA対応、CSE/HYOK等の補完措置により、ガイドラインの趣旨（医療データの安全管理）は実質的に達成されていることを整理
4. 経営層の明示的判断: 残存リスクとベネフィットを比較した上で、経営層が明示的にリスクを受容し、その判断根拠を記録
5. 定期的な再評価: ガイドライン改定、法改正、サービス変更に応じて判断を見直す仕組みを構築

リスク: 3要件は立入検査チェックリストに含まれておらず、定期検査で直接問われる蓋然性は低い。ただし、ガイドライン逸脱として行政指導の対象となる可能性はある（罰則なし）。また、医療事故・漏えい発生時にはチェックリストの有無にかかわらずガイドライン全体に照らした調査が行われうるため、逸脱が注目される可能性、医療機関の評価・認定への影響の可能性がある。

道B: HIPAA的な能力ベース制度の整備（中長期）

日本の医療データ保護制度がHIPAAのような能力ベースのアプローチに移行するなら、以下の方向性が考えられる。

1. 法律レベルでの医療データ保護: 個人情報保護法の医療分野ガイダンスを格上げし、医療データ専用の法的枠組みを整備する（HIPAA的な位置づけ）
2. BAA相当の契約義務化: 医療データを扱う委託先との間で、セキュリティ要件・漏えい通知・監査権・データ返却等を法律で義務化する（現行はガイドライン推奨）
3. 場所ベースから能力ベースへの転換: 「どこにあるか」ではなく「どう守られているか」を評価基準とする。ISMAP等の第三者認証を能力証明として法的に位置づける
4. 漏えい通知の法定化: 医療データの漏えい通知について、対象・期限・方法・罰則を法律で明確化する

この方向に制度が整備された場合、ISMAP認証済みかつHIPAA BAA対応のGWSは、保存場所にかかわらず能力ベースの基準を満たすサービスとして位置づけられることになる。逆に、外部認証を持たない国内事業者は、国内DCで運用していても能力証明が求められることになる。

現時点での意義: 道Bは将来の制度変更の可能性であり、現行制度下での判断に直接適用することはできない。しかし、道Aの「短期的リスク受容」を判断する際に、制度の方向性として「能力ベースへの移行は合理的」という論拠は、リスク受容の判断根拠を補強する。

前章で示した道A（現行制度下でのリスク受容）を、20床以下の有床診療所に適用した場合の評価を具体的に行う。

想定する診療所の特性

この規模での3要件のリスク評価

20床以下の診療所では、3要件の実務上のリスクは大規模病院と異なる。

代替手段との現実的な比較

この規模の診療所がGWSを避けて国内保存を選択した場合、現実的な代替手段は以下のいずれかになる。

20床以下の診療所において最も蓋然性の高いセキュリティリスクは、3要件の不充足ではなく、院内サーバーの脆弱性に起因するランサムウェア感染やデータ喪失である。厚生労働省の注意喚起においても、医療機関のサイバーセキュリティ対策の強化が繰り返し求められており、その中心は基本的な安全管理措置の徹底にある。

推奨する補完措置

この規模の診療所では、補完措置の階層モデルのうち第1層〜第2層が現実的な対応範囲になる。

1. 第1層: 認証の活用（追加コストなし）: GWSのISMAP登録・ISO認証を委託先選定の根拠として文書化する
2. 第2層: 契約条項の整備（追加コスト小）: Google合同会社との契約で準拠法・裁判管轄・監査権・データ返却条項を確認・記録する。Business Plusプラン以上であればデータリージョン設定も活用する
3. 第3層: 技術的措置（検討事項）: CSE（クライアントサイド暗号化）の導入はEnterprise Plus以上のプランが必要であり、コストと運用負荷を勘案して判断する。導入しない場合はその判断根拠を記録する

総合評価

20床以下の有床診療所がGWSを道Aで採用する場合の評価は以下のとおりである。

定期的な見直し

道Aは「現時点での判断」であり、前提条件の変化に応じて見直す仕組みが必要である。

見直しの結果は判断根拠の文書に追記し、経営層の承認を得て記録する。前提条件が大きく変わった場合（例: 日本リージョンが利用可能になった場合や、ガイドラインが3要件を必須化した場合）は、判定そのものを再評価する。

結論: 20床以下の有床診療所にとって、GWSの採用は「ガイドラインの3要件を文言通りには満たさないが、患者データの安全性を総合的に高める合理的な判断」と位置づけられる。経営層がこの判断根拠を文書化し、補完措置（少なくとも第1層・第2層）を実施し、定期的に再評価する体制を整えることが、道Aにおける実務上の要件となる。

個人情報保護法上の論点は、既存レポートのセクション3で詳細に分析済みである。要点を以下に整理する。

委託（第27条第5項第1号）

GWSへの医療情報保存は、個人情報保護法上の「委託」に該当する。委託の場合、第三者提供には当たらず本人同意は不要だが、委託元（医療機関）は委託先（Google）に対する監督義務（第25条）を負う。

監督義務の内容として、(1) 適切な委託先の選定、(2) 委託契約における安全管理措置の明確化、(3) 委託先における取扱状況の把握 が求められる。Googleは業務委託契約（DPA）を提供しており、これらの要件を充足する契約構成が可能。

外国にある第三者への提供（第28条）

Googleは米国法人であり、データが外国で取り扱われる可能性がある。ただし、第28条第1項各号のいずれかに該当すれば適法となる。

GWSの場合、「基準適合体制」ルート（第28条第1項第2号）を使う。Googleは個人情報保護委員会規則で定める基準に適合する体制（APPI相当の安全管理措置）を整備しており、データ処理規約（DPA）でこの体制を約束している。本人同意は不要。

本人請求時の情報提供（第33条の2）

基準適合体制ルートを使う場合、本人から請求があった際に、(1) 提供先の国名、(2) 当該国の個人情報保護制度、(3) 提供先が講じている措置 を情報提供する義務がある。Googleはこの情報提供に必要な資料（ホワイトペーパー、DPA等）を公開している。

結論

個人情報保護法上、GWSを医療情報のクラウド外部保存に利用することに法的障壁はない。委託先監督義務と基準適合体制の整備を適切に行えば、法的要件を充足できる。

医師法第24条: 診療録の保存義務

医師は診療録を5年間保存する義務を負う（医師法第24条第2項）。この保存義務は紙媒体に限定されておらず、e-文書法（民間事業者等が行う書面の保存等における情報通信の技術の利用に関する法律）により電子的な保存が認められている。

e-文書法と電子保存の3要件

e-文書法に基づく厚生労働省令により、診療録等の電子保存には以下の3要件を満たすことが求められる。

1. 真正性: 作成責任者の識別・認証、改ざん防止
2. 見読性: 必要に応じて肉眼で見読可能な形式で表示・印刷できること
3. 保存性: 法令で定める保存期間にわたり復元可能な状態で保存されること

GWSはこれらの要件を技術的に充足できる。アクセスログによる作成者の識別、暗号化による改ざん防止、ブラウザ・アプリからの即時表示、冗長化ストレージによる長期保存がそれぞれ対応する。

療担規則第9条: 保険医療機関の帳簿保存

保険医療機関は診療録・帳簿を整備し保存する義務を負う（保険医療機関及び保険医療養担当規則第9条）。外部保存については、厚労省通知「診療録等の保存を行う場所について」（医政発第0329003号）により、電子媒体による外部保存が認められている。

医療法施行規則第14条第2項

令和5年改正で新設された同条項は、病院等の管理者に「サイバーセキュリティを確保するために必要な措置」を講じることを義務付ける。ただし、「サイバーセキュリティ」と「データ主権・法域」は異なる概念であり、保存場所・国内法適用・国外法リスクの3要件は同条の直接的な射程に入るかは論点がある。この点は本文第2層（省令からガイドラインへの法的連鎖）で分析している。

結論

医療法・医師法・e-文書法の観点で、GWSを電子的な外部保存先として利用することに法的障壁はない。電子保存の3要件（真正性・見読性・保存性）はGWSの技術的機能で充足可能である。

刑法第134条: 秘密漏示罪

医師が「正当な理由がないのに、その業務上取り扱ったことについて知り得た人の秘密を漏らしたとき」は、6月以下の懲役又は10万円以下の罰金に処せられる。

クラウドサービスへの医療情報の保存が「秘密を漏らす」行為にあたるかが論点となる。通説・実務上、正当な業務委託であり、委託先との間で守秘義務契約が締結されている場合は「漏示」にあたらないと解される。Googleとの業務委託契約（DPA）に守秘義務条項が含まれており、この要件を満たす。

各業法の守秘義務

いずれの守秘義務も、情報の保存場所・保存方法を直接規制するものではない。クラウド保存自体が「秘密を漏らす」行為にあたるのではなく、不十分なセキュリティ措置により漏えいが発生した場合に守秘義務違反が問われうる。GWSの技術的安全管理措置（暗号化、アクセス制御、監査ログ）と業務委託契約上の守秘義務条項により、適切な体制を構築できる。

民法第644条: 善管注意義務

診療契約は準委任契約（民法第656条）と解され、医療機関は善管注意義務（第644条）を負う。患者情報の管理もこの義務の範囲に含まれる。GWSのような外部認証（ISMAP等）を取得したクラウドサービスの利用は、善管注意義務を果たすための適切な手段と評価できる。

労働安全衛生法

事業者は健康診断個人票を5年間（特殊健診の一部は30年間）、ストレスチェック結果を5年間保存する義務を負う。e-文書法により電子保存が認められており、GWSでの保存は技術的に可能。ただし、ストレスチェック結果は実施者・実施事務従事者以外への閲覧を厳格に制限する必要があり、GWSのアクセス制御設定で対応する。

介護保険法・障害者総合支援法

いずれもサービス提供記録の5年間保存義務と秘密保持義務を定めるが、クラウド保存を直接規制する条文はない。個人情報保護法の安全管理措置義務との重畳適用の下で、GWSの利用は可能。

臓器移植法

臓器あっせん機関の秘密保持義務（第13条）と帳簿保存義務（第14条、5年間）を定めるが、クラウド保存に関する直接的な規制はない。

関係しない法令

• 薬機法: GWSは医療機器プログラムに該当しない。GWSは汎用的なクラウドサービスであり、疾病の診断・治療・予防を目的とするプログラムではない。
• 電気通信事業法: Googleは電気通信事業者としての届出を行っているが、通信の秘密保護義務はクラウド保存の適法性に追加の制約を課すものではない。
• 電子署名法: 電子カルテの真正性確保はe-文書法・3省2ガイドラインの要件であり、電子署名法の直接的な適用場面は限定的。
• 母子保健法: 民間事業者のクラウド保存を規制する法律ではない。

GWSが取得している認証のうち、医療情報の外部保存におけるリスクを最も幅広くカバーするのがISMAP登録である。ISMAPは政府が調達するクラウドサービスのセキュリティ要件適合を第三者が評価・登録する制度であり、技術的安全管理（暗号化・アクセス制御・監査ログ等）、組織的安全管理（ガバナンス・方針・責任体制）、運用管理（BCP・インシデント対応）、委託先管理（サプライチェーン）を包括的に評価対象とする。本章ではGWSのISMAP登録をベースラインとし、医療GLが追加で求める要件との差分を特定することで、追加対応が必要な範囲を明確にする。

Google WorkspaceはISMAP公式クラウドサービスリストに、Google Cloud Platformとは別のクラウドサービスとして登録されている。

GWSの言明対象範囲には、Admin Console、Gmail、Calendar、Drive、Docs、Sheets、Meet、Chat、Vault、Gemini for Google Workspace等が含まれる。基盤の一部（Google Cloud Storage等）はGCP登録側の対象。ISMAP-LIUリストではGoogleの登録は確認できず、通常ISMAPとして整理する。

• (a) 重なる観点（認証で充足可能）: ガバナンス、リスクアセスメント、アクセス制御、暗号化、可用性、サプライチェーン、セキュア開発
  → ISMAP登録は「これらの観点について第三者評価済み」の証拠として使える。医療機関の委託先選定で「この事業者は技術的・運用的な安全管理能力を持つ」ことの根拠になる。
• (b) 重なるが追加確認必須（認証だけでは不十分）: 保存場所、国内法適用、国外法リスク、契約終了・返却
  → ISMAPにも管理策は存在するが、医療GLはサービス個別の確認を医療機関の責任として求める。以下で3論点ごとに原文を対比し、差異の構造と程度を分析する。
• (c) 医療GL固有（認証では代替不可）: 患者説明・説明責任
  → 医療機関固有の義務であり、クラウドサービスの認証では代替できない。

「国内事業者・国内DC」というだけで安全と判断するリスクを可視化するため、2つの仮想的な選択肢を比較する。

ガイドラインの保存場所・国内法・国外法の3要件を0/1で適用すると、Bが「適合」、Aが「不適合」になる。しかし、患者データに対する実質的な保護水準はAの方が圧倒的に高い。

この比較が示すのは、保存場所・法域の要件は、セキュリティ要件全体の一部にすぎないということである。保存場所の要件だけを絶対視して他の要件を軽視すれば、総合的なリスクはむしろ上がる。外部認証は保存場所・法域リスクを直接解消しないが、セキュリティ全体のリスクを大幅に下げることで、法域リスクが顕在化した場合の影響を限定する効果がある（CSE導入済みなら、仮にCLOUD Actに基づく開示命令が出ても平文が渡らない等）。

BAA（Business Associate Agreement）

HIPAAは、医療情報（PHI: Protected Health Information）を取り扱う全ての事業者に対して、BAA（業務提携契約）の締結を法律で義務付ける。BAAはガイドラインの推奨ではなく法的義務であり、違反には罰則が伴う。

クラウドサービス事業者はBusiness Associate（業務提携者）として位置づけられ、BAA を通じて HIPAA Security Rule の遵守を契約上も法律上も義務付けられる。Google は Google Cloud / Workspace の BAA を提供している。

Security Rule — 技術的安全管理措置

HIPAA Security Rule は、アクセス制御、監査制御、完全性制御、伝送セキュリティ等を「場所を問わず」義務付ける。サーバがどこにあっても、これらの措置を実装していれば適合となる。

Breach Notification Rule — 漏えい時の通知義務

500人以上の患者に影響する漏えいが発生した場合、(1) 影響を受けた個人への通知、(2) HHS（保健福祉省）への報告、(3) メディアへの通知 が義務付けられる。この「公開処刑」に近い仕組みが強力な抑止力として機能する。

罰則の段階

さらに、故意の違反には刑事罰（最大10年の禁固・$250,000の罰金）が科される可能性がある。

場所を不問にできる理由 — 外国法リスクの処理構造

HIPAAが保存場所を規制しないのは、場所に依存せず執行力が及ぶ仕組みを備えているからである。

契約による管轄権の延長: BAAにより、Business Associateはデータの物理的所在にかかわらずHIPAAの義務を負い、米国の裁判管轄に服する。日本のガイドラインが「国内法適用の確認」として場所で担保しようとしている問題を、HIPAAは契約メカニズムで解決している。

外国政府からのアクセス要求への対応: データが海外にある場合、当該国の政府が自国法に基づいてデータの開示を要求する可能性がある。この場合でも、BAAのもとでは開示はHIPAA違反となり、民事罰（最大年間約200万ドル）・刑事罰（最大10年の禁固）の対象となる。つまり、外国政府に応じるコストがHIPAA違反のコストを下回る場合にのみ開示が合理的になるよう、違反コストを十分に高く設計することで抑止している。

大手クラウド事業者（Google、Microsoft、AWS等）にとっては、HIPAA違反による罰金・刑事罰に加え、米国医療市場へのアクセス喪失という事業リスクが加わるため、外国政府の要求に安易に応じる経済的合理性がない。実際にこれらの事業者は政府からのアクセス要求を法的に争い、透明性レポートで公表する運用を行っている。

まとめ: HIPAAは外国法リスクを「消す」のではなく、(1) BAAで契約管轄権を延長し、(2) 違反コストを十分に高く設計し、(3) 漏えい通知で隠蔽を不可能にすることで、合理的な事業者がリスクを取らない構造を作っている。「どこに置くか」ではなく「違反したらどうなるか」で担保する仕組みである。

前提: GWSのデータリージョン制約 — Google Workspaceのデータリージョン設定では「米国」「欧州連合/ヨーロッパ」「指定なし」を選択可能だが、日本リージョンを指定する機能は現時点で提供されていない。この制約が保存場所の論点に直結する。

ISMAP管理基準の原文

管理策 6.1.3.3.PB

クラウドサービス事業者は、クラウドサービス利用者に、クラウドサービス事業者の組織の地理的所在地、及びクラウドサービス事業者がクラウドサービス利用者のデータを保管する可能性のある国々を通知する。

管理策 15.1.1.16.B（抜粋）

…必要に応じてクラウドサービス利用者が扱う情報が取り扱われる場所及び契約に定める準拠法・裁判管轄を指定する。

医療GL企画管理編の原文

7章【遵守事項】⑥ h（企画管理編 p.34）

外部保存の委託先事業者を選定する際は、少なくとも次に掲げる事項について確認すること。
h 医療情報を保存する情報機器が設置されている場所(地域、国)

Q&A 企Q-27（Q&A p.45）

法令上の保存義務を有する医療機関等は、システム堅牢性の高い安全な情報の保存場所を選定する必要があります。

差異の分析

差異の程度

ISMAPは「事業者がデータ保管国を利用者に通知できる体制を持っている」ことを評価する。医療GLは「医療機関が実際に保存場所を確認・特定したこと」を遵守事項とする。ISMAPが通知体制の存在を保証しても、医療機関が実際にその通知を受け取り、具体的な場所を特定し、選定判断に使ったかどうかは別の問題である。

Google Workspaceの場合: ISMAPに登録されているため、Googleにはデータ保管国を通知する体制がある。しかし実際に通知される内容は「米国/欧州/指定なし」であり、日本を指定する選択肢がない。ISMAPの管理策は満たしているが、医療GLの観点では「保存場所が日本国内である」という確認結果が得られない。

残存リスクの評価

保存場所が日本国外であることに伴うリスクを、GWSの典型的な利用形態（電子カルテがマスター、GWSは外部保存先）を前提に評価する。

• 行政調査への対応: 医療法第25条の立入検査等で診療録の提出が求められる場合、マスターデータは電子カルテ（EHR）にあるため、EHRから行政に提供できる。GWSは外部保存先（バックアップ・アーカイブ等）としての位置づけであり、GWSの物理的所在が米国であっても行政調査の実務に直接の障壁は生じない。EHRのデータが消失しGWSのみに残存するケースでは間接的な影響があり得るが、その場合もGWSからのデータエクスポートで対応可能である。なお、GWS上にはEHRに存在しないデータ（Gmail/Chatでの患者との事務的やりとり、医師・コメディカル間の連絡等）が生じる場合があるが、これらは診療録（医師法第24条の保存義務対象）ではなく業務コミュニケーションデータであり、立入検査における診療録提出の直接の対象ではない
• 災害・障害時の可用性: データセンターが海外にある場合、日本の災害対策法制に基づく優先復旧の対象にならないことは事実である。しかし、GWSは複数リージョンにデータを複製するグローバル分散アーキテクチャにより、99.9%以上のSLAを提供している。日本国内の単一拠点に保存する場合と比較すると、地震・台風等の日本固有の災害リスクに対してグローバル分散のほうが可用性が高い。法制度上の位置づけと技術的な可用性は分けて評価する必要がある
• 患者からの問い合わせへの対応: 個人情報保護法上、物理的な保存場所を患者に積極的に開示する法的義務はない（委託として整理すれば第三者提供にあたらず、基準適合体制ルートなら外国提供の同意も不要）。患者から問い合わせがあった場合には、保存場所に加えてISMAP認証・暗号化・アクセス制御・監査ログ等のセキュリティ体制全体を説明することで、適切に対応できる。なお、場所が日本国内であっても安全管理が不十分な事業者に預けるほうが実質的なリスクは高く、保存場所そのものが安全性を保証するわけではない

ISMAPと医療GLの関係 — 上乗せ構造

ISMAPは政府が調達するクラウドサービスのセキュリティ要求適合を評価・登録する制度であり、データ所在国そのものを承認する制度ではない。政府情報システムのクラウド利用方針（DS-310）は、データセンター設置場所について「国内であることを基本」とし、海外保管が必要な場合は準拠法・国際裁判管轄・暗号化・鍵管理等の個別確認を求めている。

つまり、政府調達においてもデータの海外保存は無条件に受容されているわけではなく、ISMAP登録は個別のデータ所在判断の前提となるセキュリティ評価である。医療GLはこのセキュリティ評価の基盤の上に、医療固有の要件（保存場所の特定、行政調査への対応能力等）を上乗せしている関係にある。

ただし、上乗せの根拠は医療データの特殊性にある。医療機関は個々の患者との診療契約における受任者として善管注意義務（民法第644条）を負い、患者情報は行政監督（医療法第25条の立入検査等）の対象でもある。政府が自らのデータについて行う政策判断と、医療機関が患者のデータについて負う管理責任ではアカウンタビリティの構造が異なるため、ISMAP評価をそのまま適用するのではなく、医療固有の確認事項を追加して判断することが求められる。

ISMAP管理基準の原文

管理策 15.1.1.16.B

当該事業者が提供するサービス上で取り扱われる情報に対して国内法以外の法令及び規制が適用された結果、クラウドサービス利用者の意図しないまま当該利用者の管理する情報にアクセスされ、又は処理されるリスクを評価して外部委託先を選定し、必要に応じてクラウドサービス利用者が扱う情報が取り扱われる場所及び契約に定める準拠法・裁判管轄を指定する。

管理策 18.1.1

各情報システム及び組織について、全ての関連する法令、規制及び契約上の要求事項、並びにこれらの要求事項を満たすための組織の取組みを、明確に特定し、文書化し、また、最新に保つ。

医療GL企画管理編の原文

7章【遵守事項】⑤（企画管理編 p.33）

外部の事業者との契約に基づいて医療情報を外部保存する場合、以下の対応を行うこと。重要度の高い委託の場合は、経営層に丁寧に報告し、承認を得ること。
－ 保存された情報を格納する情報機器等が、国内法の適用を受けることを確認すること。

Q&A 企Q-27（Q&A p.45）

外部保存されている医療情報は、保存される情報やその目的に応じて厚生労働省等、所管する行政機関の調査等に供するため、提出等を行う必要が生じうることから、これを円滑に実現できることが求められます。
そのため外部保存の受託事業者の選定にあたっては、国内法の適用があることや、逆にこれを阻害するような国外法の適用がないことなどを確認し、適切に判断した上で選定することが求められます。

Q&A 企Q-26（Q&A p.45）— 例外規定

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

差異の分析

差異の程度

ISMAPは「関連法令を特定・文書化し、リスクを評価して、必要に応じて準拠法を指定するプロセスを持っている」ことを評価する。医療GLは「保存された情報を格納する情報機器等が国内法の適用を受けている事実」を確認することを遵守事項とする。

この差は単なる表現の違いではない。ISMAPの管理策は「リスクを評価した結果、準拠法を指定しないという判断」も許容する（「必要に応じて」）。医療GLは「国内法の適用を受けること」を無条件の確認事項としており、「評価した結果、国内法適用でなくてもよい」という判断の余地を与えていない。

さらにQ&Aは「行政機関の調査等に供するため提出等を行う必要が生じうる」と目的を明示しており、国内法適用の要件は抽象的なコンプライアンスではなく、行政調査への対応能力という具体的要請に根ざしている。

Google Workspaceの場合: Googleは法令特定・文書化のプロセスを持ち（ISMAP適合）、契約で準拠法を指定できる。しかし、データの保存先が米国/欧州であり、情報機器が物理的に日本国外にある場合、「情報機器等が国内法の適用を受ける」という確認結果は得られない可能性が高い。

「契約上の準拠法」と「物理的法域」の違い — 何がどこまで効くか

「契約で日本法を準拠法に指定すれば国内法適用の要件を満たせるのでは」という疑問が生じるが、この2つは法的に異なる層の話であり、カバー範囲が重ならない部分がある。

ギャップの実際の大きさ

このギャップは理論上のものではなく、実務上の以下の場面で顕在化する。

• 場面1: 厚労省が立入検査で診療録の提出を求める — 医療機関はGoogleに契約に基づきデータ取得を依頼できるが、Googleが応じる速度と確実性は契約上のSLAに依存する。ただし、この構造はサーバーが国内にあっても本質的に変わらない。現代の分散システムではデータは暗号化・分散されており、行政機関が物理的にサーバーを差し押さえてもデータを取得できない。国内・海外を問わず、行政調査はサービス事業者の技術的協力に依存する。差異があるのは法的プロセスの層であり、国内事業者には裁判所命令で直接協力を強制できるのに対し、海外事業者には国際司法共助を経る必要がある点である
• 場面2: 訴訟で患者の診療録が証拠として必要になる — 日本の裁判所が文書提出命令を出しても、執行先が米国のサーバーであれば、国際司法共助の手続きを経る必要がある場合がある
• 場面3: 米国政府がCLOUD Actに基づきGoogleにデータ開示を命じる — CLOUD Actは米国企業が保有するデータに適用され、データセンターの物理的所在地は無関係である。Google Cloud の東京リージョンやAWSの東京リージョンを利用し、データが日本国内に保存されていても、Google・Amazon が米国企業である限り CLOUD Act の適用を受ける。つまり、ガイドラインの「保存場所を日本に指定する」という要件は CLOUD Act リスクに対しては防御にならない。このリスクはサービス事業者の本社所在地（法域）の問題であり、データの物理的所在地の問題ではない

ただし、以下の点は過度に悲観的な評価を避けるために考慮すべきである。

• 医療機関が自らデータをエクスポートし国内に保持する運用を組み合わせれば、行政調査への対応は可能になる（ただしリアルタイムデータは対象外）
• 米国政府が日本の患者の診療録を特定して開示請求する実務上の蓋然性は低い（ただし蓋然性の低さはガイドライン遵守の根拠にはならない）
• Google自身が「法的に可能な範囲で利用者に通知し、不当な請求には異議を申し立てる」方針を公表している（ただし通知禁止命令がある場合は通知できない）

残存リスク

• 行政調査の法的プロセスの差異: 医療法・健康保険法等に基づく立入検査や報告命令が出された場合、データの取得はいずれの場合もサービス事業者の技術的協力を要する（物理的にサーバーを差し押さえてもデータは取得できない）。差異は法的プロセスにある。国内事業者には日本の裁判所が直接命令を出せるが、海外事業者には国際司法共助を経る必要があり、速度と確実性に差が生じうる
• 「契約上の準拠法」と「物理的な法域」の乖離: 契約で日本法を準拠法と定めても、情報機器が米国にあれば米国裁判所の管轄権が及ぶ。契約上の準拠法は当事者間の紛争解決ルールであり、第三者（米国政府等）による法的介入を排除するものではない
• 国内法の「適用を受ける」の解釈問題: 企画管理編の「国内法の適用を受けることを確認する」が何を意味するか — 契約上の準拠法で足りるのか、情報機器の物理的所在に基づく法域が必要なのか — は解釈に幅があるが、Q&Aが「行政機関の調査等に供するため」と目的を明示している以上、行政権限が実効的に及ぶことが求められていると読むのが自然である

政府調達と医療GLの位置関係

政府情報システムのクラウド利用方針（DS-310）自体が「データセンター設置場所は国内であることを基本」としており、海外保管は個別のリスク評価と保護措置を前提としている。つまり、政府調達でもデータの海外保存は無条件に許容されているわけではない。

ISMAPはこの方針の中でクラウドサービスのセキュリティ評価を担う制度であり、医療GLは医療固有の確認事項（行政調査への対応能力、保存場所の特定等）をISMAPの評価基盤の上に上乗せする関係にある。ISMAPが「保管可能国の通知」「国外法リスクの評価」を管理策として求め、DS-310が「国内を基本」とし、医療GLが「国内法の適用を確認」を遵守事項とするのは、抽象度と要求の厳格さが段階的に上がる構造であり、矛盾ではなく上乗せである。

ISMAP管理基準の原文

管理策 15.1.1.16.B

当該事業者が提供するサービス上で取り扱われる情報に対して国内法以外の法令及び規制が適用された結果、クラウドサービス利用者の意図しないまま当該利用者の管理する情報にアクセスされ、又は処理されるリスクを評価して外部委託先を選定し…

医療GL企画管理編の原文

7章【遵守事項】⑥ i（企画管理編 p.34）

外部保存の委託先事業者を選定する際は、少なくとも次に掲げる事項について確認すること。
i 委託先事業者に対する国外法の適用可能性

Q&A 企Q-27（Q&A p.45）

外部保存の受託事業者の選定にあたっては、国内法の適用があることや、逆にこれを阻害するような国外法の適用がないことなどを確認し、適切に判断した上で選定することが求められます。

差異の分析

差異の程度

ISMAPは国外法リスクを「評価」し、評価結果に基づいて委託先を「選定」することを求める。リスクが存在しても、評価した上で受容する判断は制度上あり得る。

医療GLは国外法の「適用可能性を確認」し、Q&Aでは「国内法の適用を阻害するような国外法の適用がないこと」を確認するよう求める。「阻害する国外法があるが、評価した結果受容する」という判断の余地は、Q&Aの文言上は明示されていない。

ここに最大の構造的ギャップがある。ISMAPはリスクベースの評価（程度問題）を認めるが、医療GLは「阻害する国外法がないこと」の確認（有無の問題）を求めている。CLOUD Act等の域外適用法制が存在する米国系事業者の場合、ISMAPのリスク評価では「リスクを認識し対策を講じた上で利用する」という整理が可能だが、医療GLの「阻害する国外法がないことの確認」は文言上クリアしにくい。

Google Workspaceの場合: Google LLC は米国法人であり、CLOUD Act (18 U.S.C. §2713) の適用を受ける。ISMAPの管理策に従えば「CLOUD Actによる強制開示リスクを評価し、対策を講じた上で利用する」という整理は可能。しかし医療GLのQ&Aが求める「国内法の適用を阻害するような国外法の適用がないこと」については、CLOUD Actの存在自体が「阻害する可能性のある国外法」に該当し得る。この点が、補完措置（CSE/HYOK等による技術的対策）で「条件付き受容」に持ち込めるかどうかの焦点になる。

残存リスク

• 患者データへの外国政府アクセス: CLOUD Actに基づき、米国政府がGoogle LLCに対してデータ開示命令を出した場合、Googleは保存場所にかかわらず当該データを提出する法的義務を負う。患者の同意も医療機関への通知もなく、診療録が米国政府に開示される可能性がある
• 通知禁止命令のリスク: 米国の裁判所はgag order（通知禁止命令）を併発できるため、Googleが医療機関に「あなたのデータが開示された」と通知することすら禁じられる場合がある。医療機関は自らの患者データが外国政府に渡ったことを知らないまま診療を継続するリスクがある
• 「阻害する国外法がない」と言えない状態: CLOUD Actが存在する以上、「国内法の適用を阻害するような国外法の適用がないこと」を確認した結果は「阻害し得る国外法が存在する」になる。これは医療GLの遵守事項を文言通り満たせないことを意味する

政府調達では許容され、医療では許容しにくい理由

政府調達の文脈では、ISMAPの管理策15.1.1.16.Bは国外法リスクを「評価」して委託先を「選定」することを求めている。これはリスクベースの判断であり、「リスクを認識した上で、対策を講じて利用する」という結論が制度上許容される。政府は自らの情報資産に対するリスク許容度を自ら決定する権限を持つ。

医療GLは「阻害するような国外法の適用がないこと」の確認を求めている。これはリスクベースの程度問題ではなく、有無の判定である。医療機関は患者情報の受託者であり、患者データに対する外国政府のアクセス可能性を「リスクとして受容する」権限を当然には持たない。医療GLがリスク評価ではなく事実確認を求めているのは、患者の権利保護と行政監督の実効性は、医療機関のリスク判断で左右されるべきではないという制度設計に基づく。

前節の原文対比では、ISMAPの管理策と医療GLの遵守事項の間に構造的な差異（体制評価 vs 事実確認）があることを示した。しかしこの差異は「ISMAPが3論点に対して何もしていない」ことを意味しない。ISMAP認証済みの事業者は、3論点のそれぞれについて具体的な義務を監査で確認されている。

論点1: 保存場所に対するISMAPのリスクヘッジ

管理策 6.1.3.3.PB（原文）

クラウドサービス事業者は、クラウドサービス利用者に、クラウドサービス事業者の組織の地理的所在地、及びクラウドサービス事業者がクラウドサービス利用者のデータを保管する可能性のある国々を通知する。

これが意味するリスクヘッジ: ISMAP認証済みの事業者は、データ保管国を利用者に通知する義務が監査で確認されている。利用者（医療機関）は「どこに保存されるか分からない」状態にはならない。GWSの場合、「米国/欧州/指定なし」という選択肢が明示されており、保存場所の不透明性リスクは解消されている。残るのは「日本ではない」という事実に対する評価であり、これは不透明性とは質の異なるリスクである。

論点2: 国内法適用に対するISMAPのリスクヘッジ

管理策 15.1.1.16.B（原文）

…必要に応じてクラウドサービス利用者が扱う情報が取り扱われる場所及び契約に定める準拠法・裁判管轄を指定する。

管理策 18.1.1（原文）

各情報システム及び組織について、全ての関連する法令、規制及び契約上の要求事項、並びにこれらの要求事項を満たすための組織の取組みを、明確に特定し、文書化し、また、最新に保つ。

これが意味するリスクヘッジ: ISMAP認証済みの事業者は、(1) 契約で準拠法・裁判管轄を指定する仕組みを持ち、(2) 関連法令を特定・文書化・更新する体制が監査で確認されている。GWSの場合、日本法を準拠法とする契約締結が可能であり、Google合同会社を契約主体として日本の裁判管轄を指定できる。契約上の準拠法は物理的法域と異なる層の保護だが、当事者間の紛争解決、損害賠償請求、契約違反に対する救済は日本法で行える。「国内法が一切及ばない」状態ではない。

論点3: 国外法リスクに対するISMAPのリスクヘッジ

管理策 15.1.1.16.B（原文）

当該事業者が提供するサービス上で取り扱われる情報に対して国内法以外の法令及び規制が適用された結果、クラウドサービス利用者の意図しないまま当該利用者の管理する情報にアクセスされ、又は処理されるリスクを評価して外部委託先を選定し…

これが意味するリスクヘッジ: ISMAP認証済みの事業者は、国外法による意図しないアクセスリスクを評価し、その評価に基づいて対策を講じていることが監査で確認されている。GWSの場合、Googleは年次透明性報告で政府からのデータ開示請求件数と対応を公開しており、法的に可能な範囲で利用者通知・異議申立てを行う方針を持つ。CLOUD Actの適用可能性は存在するが、ISMAP認証は「リスクを把握していない」「対策がない」状態ではないことを保証する。

まとめ: ISMAPが解消するリスクと残存するリスク

ISMAPは3論点のリスクを「ゼロ」にはしないが、「不透明・無保護・無認識」という最も危険な状態を排除する。残存リスクは「保存場所が日本でない」「物理的法域が日本外」「CLOUD Actが存在する」という事実に対する評価に絞られる。この残存リスクを、サービスのベネフィットと補完措置を含めて総合的に判断するのが、リスクベースの評価である。

ISMAP登録済みサービス（Google Workspace: C21-0005-2）について、以下の観点は「ISMAP管理基準に基づく第三者監査で適合が確認されている」と整理できる。

ただし、これは「事業者側の能力確認」であり、「医療機関側の管理義務」（委託先監督、契約管理、院内体制構築等）を免除するものではない。

本文のISMAP評価概要（4.5節）で示したカバー状況の根拠として、ガイドライン要件分類ごとのISMAPカバー範囲を詳細に整理する。

ISMAPは法律・省令が求める安全管理措置の大部分をカバーする。3論点（保存場所・国内法・国外法）はガイドライン固有の遵守事項であり、法律・省令には直接の規定がない。ISMAPはこの3論点に対してもリスク低減効果を持つが、ガイドラインの文言通りの「事実確認」は別途必要になる。

考察

ISMAPは技術的・組織的・運用的な安全管理措置と委託先管理について高いカバレッジを持ち、医療GLが求める要件の大部分をセキュリティ基盤として充足している。一方、ISMAPがカバーしないのは保存場所・法域に関する確認事項（保存場所の特定、国内法適用の確認、国外法リスクの評価）であり、これらは医療データ固有の要件としてガイドラインが上乗せしている部分である。つまり、ISMAP登録をベースラインとして採用した上で、残る3論点についてのみ追加の評価と補完措置を設計すればよい、という構造になっている。

本文の判断フレームワーク（4.10節）で用いる定性評価軸の詳細を以下に示す。医療機関がクラウド外部保存のリスクを評価する際の確認項目と判定基準である。

GWSへの適用所見

7軸のうち、GWSが「低リスク例」に該当するのは事業者監査（ISMAP・SOC2・ISO27001等の第三者評価あり）、鍵管理（CSE/CMEK選択可能）、終了・移行（Google Takeoutによるエクスポート可能）の3軸である。データ分類と所在マップは医療機関側の運用設計に依存し、法域マップとインシデント対応は米国法域に起因する構造的リスクが残る。特に法域マップ（CLOUD Actの適用可能性）は、補完措置で低減はできても排除はできない点に留意が必要である。

GWSでの達成見込み

9指標のうち、GWSの標準構成で達成可能なのは所在マップ化率（Google公開情報で保存・処理場所を特定可能）、再委託先列挙率（サブプロセッサリスト公開）、暗号化適用率（転送時・保存時ともにデフォルトで暗号化）、インシデント通知SLA（BAA対象の通知体制あり）の4指標である。事業者が復号可能な高リスク医療情報はCSE導入で原則0件に近づけられるが、メタデータ・ファイル名・検索インデックス等は対象外となる。未承認国外アクセス経路はサポート経路の完全国内化が困難な点で課題が残る。

• 個人情報の保護に関する法律（個人情報保護法）
• 医療法
• 医療法施行規則 第14条第2項
• 医師法
• e-文書法（民間事業者等が行う書面の保存等における情報通信の技術の利用に関する法律）
• 刑法 第134条（秘密漏示）
• 行政手続における特定の個人を識別するための番号の利用等に関する法律（マイナンバー法）
• 保健師助産師看護師法
• 民法 第644条（善管注意義務）
• 労働安全衛生法
• 厚生労働省「医療情報システムの安全管理に関するガイドライン 第6.0版 企画管理編」
• 厚生労働省「医療情報システムの安全管理に関するガイドライン第6.0版 Q&A 令和7年5月」
• 総務省・経済産業省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 第2.0版」
• デジタル庁「デジタル社会推進標準ガイドライン」
• ISMAPクラウドサービスリスト（ismap.go.jp）
• Google Workspace ISMAP言明対象範囲（C21-0005-2）
• ISMAP管理基準マニュアル
• BSI C5 Cloud Computing Compliance Criteria Catalogue
• FedRAMP Rev5 Documents & Templates
• EDPB Recommendations 01/2020 on supplementary measures for international transfers
• JAHIS「製造業者/サービス事業者による医療情報セキュリティ開示書」ガイドVer.5.0