コラム一覧に戻る
医療情報セキュリティ12分で読める

クラウド利用時のガイドライン対応

2026年9月14日

クラウド利用時のガイドライン対応
この記事をシェア

クラウド型の電子カルテや部門システムを検討すると、必ず「3省2ガイドライン的に大丈夫なのか」という問いが出ます。ベンダーは「対応済みです」と答え、医療機関側は確認のしようがないまま導入に進む——という進み方が、実際には少なくありません。

ここで見落とされがちなのは、クラウドを使うこと自体はガイドライン上まったく問題ないという点です。ガイドラインはクラウド利用を禁じていません。問われるのは、医療機関が定められた手続きを踏んだかどうかです。技術的にどれだけ堅牢なサービスであっても、選定の記録がなく、責任分界が文書化されておらず、データの所在を把握していなければ、医療機関側の対応としては成立しません。

本記事は、その手続き面を順に整理したものです。暗号化・鍵管理・ゼロトラストといった技術的な設計論は 医療機関のクラウドセキュリティ|責任共有・3省2ガイドライン・ゼロトラスト で扱っていますので、本記事は「何を確認し、何を残すか」に絞ります。

免責:本記事は一般的な情報提供です。外部保存の要件やクラウド利用にあたっての判断は、厚生労働省・経済産業省・総務省の公表資料および個人情報保護法制が正本です。制度は改定され得るため、実務判断は最新の一次情報に基づいて行ってください。

クラウド利用は「外部保存」の話から始まる

医療機関がクラウドに診療情報を置くということは、制度上は診療録等を医療機関の外部に保存する行為にあたります。そのため議論の出発点は、クラウドサービスの機能比較ではなく、外部保存として満たすべき条件の確認になります。

電子的に保存する場合に一貫して求められるのが、いわゆる三基準です。

基準意味クラウドで確認すべきこと
真正性記録が正しく、誰がいつ作成・更新したかが明確で、改ざんされていないこと利用者identityの管理方法、更新履歴の保持、責任の所在が追える仕組み
見読性必要なときに直ちに肉眼で読める形で表示・出力できること障害時・回線断時の閲覧手段、出力形式、レスポンスの保証
保存性定められた期間、復元可能な状態で保存されることバックアップ方式、保存期間、事業者側の保管体制

クラウドでとくに問題になりやすいのは見読性です。オンプレミスであれば院内で完結していた閲覧が、クラウドでは回線と事業者のサービス稼働に依存します。回線が切れたときに診療録を読む手段があるかは、必ず確認しておく論点です。参照用のローカルキャッシュ、定期的なPDF出力、紙での代替運用のいずれかを用意していないと、通信障害がそのまま診療停止になります。

保存性については、2026年度診療報酬改定で新設された電子的診療情報連携体制整備加算の要件とも接続します。加算1では医療情報システムの複数方式によるバックアップ確保(一部はオフライン保管)が求められており、クラウドを使っているから保存性は事業者任せでよい、とはならなくなりました。外部保存そのものの要件整理は 医療情報の外部保存の要件 に、バックアップ設計は 医療機関のバックアップ設計|3-2-1ルール にまとめています。

事業者選定で踏むべき手続き

ガイドライン対応の観点では、どの事業者を選んだかより、どう選んだかの記録があるかが問われます。選定の合理性を後から説明できることが、委託先管理の実質だからです。

実務的には、次の5つを記録として残すと過不足がありません。

  1. 選定基準を先に決めた記録 — 何を必須要件とし、何を加点要素としたか。選定後に基準を作ると、説明力がありません
  2. 候補事業者から取得した資料 — 対応状況説明書、第三者認証の登録証と適用範囲、責任分界表、SLA
  3. 比較・評価の記録 — 基準に照らした評価結果。落選理由も残す
  4. 決定の記録 — 誰がいつ決裁したか。経営層の関与が見える形で
  5. 残存リスクの受容記録 — 完全な事業者は存在しません。満たせなかった項目と、それを受容した判断・理由を残す

5つ目が最も抜けやすく、しかし最も価値があります。「この点は満たせないが、こういう代替策を取ったうえで受容した」という記録があれば、それは対応です。記録がなければ、同じ状態でも未対応と見なされます。

事業者に何を聞くかの具体は クラウド事業者の選定基準事業者に確認すべき質問リスト に、事業者側に適用されるルールの中身は 経産省・総務省ガイドラインの要点(事業者側) に整理しています。

第三者認証の読み方

ISMS(ISO/IEC 27001)、ISO 27017、ISMAP。クラウド事業者はさまざまな認証を提示してきます。選定資料としては有用ですが、読み方に2つの注意点があります。

第一に、適用範囲を見ること。 認証の登録証には適用範囲が記載されています。全社ではなく特定の事業部・特定のサービスに限定されていることは珍しくありません。自院が使うサービスがその範囲に入っているかを確認しないと、意味のある情報になりません。

第二に、いずれの認証も3省2ガイドラインへの準拠を証明するものではないこと。 認証は「情報セキュリティのマネジメントが確立している」ことを示しますが、医療情報固有の要求——外部保存の三基準、責任分界の明示、医療機関への説明責任——は認証の守備範囲外です。認証は土台の確認に使い、医療情報固有の点は別途聞くのが正しい使い方になります。認証の構造そのものは ISMS(ISO/IEC 27001)とは|ヘルスケア企業のための完全ガイド をご覧ください。

責任分界を合意し、文書にする

クラウド利用でガイドライン対応が崩れる最大の原因は、責任分界が口頭の理解にとどまっていることです。提案書に「弊社が運用いたします」と書かれていても、その「運用」が何を含み何を含まないかは、契約に落ちていなければ争えません。

最低限、次の6領域について医療機関/事業者/共同の3分類を明記します。

領域よくある誤解確認すべきこと
アカウント・権限管理事業者がやってくれるほぼ常に医療機関の責任として残る。 退職者IDの削除も自院
バックアップとリストア事業者が全部やる取得主体とリストアの実行主体・所要時間は別に確認
OS・ミドルウェアの更新SaaSなら事業者SaaSでも通知と停止時間の調整は共同作業になる
監査ログ取得していれば足りる保管期間と開示条件、点検の実施主体
インシデント時の判断事業者が対応するサービス停止の判断権限が誰にあるか
契約終了時のデータ返してもらえる返還形式が移行可能か、消去証明が出るか

とくに1行目は繰り返し確認する価値があります。クラウドにしても、利用者アカウントと権限設定の管理は医療機関側に残るというのが原則です。公表されている被害事例に共通して現れる構造を見ると、事業者側の基盤ではなく、この医療機関側に残った領域が入口になっているパターンが目立ちます。

分界点の決め方そのものは 責任分界点の決め方|医療機関と事業者 に、契約文言への落とし方は SLAと責任分界の書き方 にまとめています。技術的な責任共有モデルの設計は AIカルテのセキュリティ設計 が詳しいです。

リージョンとデータの所在をどう確認するか

「データはどこにありますか」という質問に、即答できないベンダーは意外に多くあります。クラウドサービスの多くは、自社でデータセンターを持たず、IaaS事業者のリージョンを利用しているためです。

確認すべきは、次の4点です。

1. 保存されるリージョン(国・地域)

契約上、リージョンを指定できるのか、事業者の裁量で変更され得るのか。変更時に通知があるのか。

2. バックアップ・レプリカの所在

本番データは国内でも、バックアップやディザスタリカバリ用の複製が別地域にあるケースがあります。本番だけを聞いて安心しない。

3. 運用・保守のためのアクセス元

データの保存場所が国内でも、保守要員が国外から接続する構成はあり得ます。誰がどこからアクセスし得るかは、保存場所とは別の論点です。

4. 再委託先の所在

クラウド事業者がさらに別の事業者を使っている場合、その所在も確認対象になります。

国外にデータを置く場合や国外からのアクセスがある場合には、個人情報保護法上の「外国にある第三者への提供」の論点が別途生じ得ます。診療情報は要配慮個人情報にあたるため、取扱いの整理は慎重に行う必要があります。ガイドライン上も、国外保存にあたっては適用される法令や契約の準拠法を含めた確認が求められる旨が示されていますので、該当する可能性がある場合は個人情報保護委員会の公表資料と厚労省ガイドラインの本文を必ず一次確認してください。

実務上の落としどころとしては、**「保存場所・バックアップの所在・保守アクセス元の3つを書面で回答させ、変更時の通知義務を契約に入れる」**のが最も現実的です。完全に固定させることは難しくとも、変更を把握できる状態にはできます。

運用開始後に残る医療機関側の手続き

導入して終わりではありません。ガイドライン対応の観点で、運用開始後にも医療機関側にいくつかの手続きが残ります。ここが抜けると、導入時にどれだけ丁寧に進めても、数年後には実態と文書がずれます。

頻度手続き内容
随時アカウント棚卸し退職・異動に合わせたID削除・権限変更。最も事故につながりやすい
月次〜四半期監査ログの点検点検した記録を残すこと。取得だけでは対応にならない
年1回リストア試験実際に戻せるかの確認。共同実施なら事業者と日程調整
年1回事業者からの報告受領体制・再委託先・インシデントの有無。契約に定めておく
年1回責任分界表の棚卸しサービス仕様や再委託構成が変わっていないか
改定時ガイドライン改定の反映追跡担当を決めておく。3省2ガイドラインの改定動向

この6つを年間計画に組み込み、実施記録を残せば、委託先管理としては形が整います。新しい仕組みを作るというより、既にやっていることを記録の形に変える作業であることが多いはずです。

自院の現在地を確認するには 3省2ガイドライン対応チェックリスト を、対応全体の手順は 3省2ガイドライン対応の実務ステップ をご覧ください。

まとめ

  1. クラウド利用自体はガイドライン上問題ない。 問われるのは医療機関が手続きを踏んだかどうか
  2. 出発点は外部保存の三基準。クラウドでは見読性——回線断時に読む手段があるか——が盲点になりやすい
  3. 事業者選定では、選定基準を先に決めた記録受容した残存リスクの記録が効く
  4. 第三者認証は適用範囲を見る。いずれの認証も3省2ガイドラインへの準拠を証明するものではない
  5. アカウント・権限管理はクラウドでも医療機関に残る。 ここが被害事例に共通する入口になっている
  6. データの所在は、保存リージョン・バックアップの所在・保守アクセス元・再委託先の4点を書面で確認する
  7. 運用開始後にも医療機関側の手続きが残る。年間計画に組み込んで記録を残す

クラウド導入の選定要件づくりや、既に稼働しているサービスの対応状況の点検でお困りの場合は お問い合わせ からご相談ください。

参考・出典

※外部保存の要件、国外保存・外国にある第三者への提供の取扱いは、厚生労働省ガイドライン本文および個人情報保護法制が正本です。制度・ガイドラインは改定され得るため、実務では必ず最新の一次情報をご確認ください。

この記事をシェア

関連記事

医療情報セキュリティ

アクセス権限設計と特権ID管理|医療機関で現実的にどこまでやるか

職種別の権限設計、最小権限の考え方、退職・異動時の棚卸し、ベンダー保守アカウントの管理、そして共有IDをやめられない現場での次善策。理想論ではなく、医療現場の制約のなかで被害の広がりを実際に抑えるための権限設計を整理します。

2026年9月14日
医療情報セキュリティ

ウイルス対策とEDR|医療機関が導入前に決めておくこと

従来型のウイルス対策とEDRは何が違うのか。EDRは「入れれば守られる」製品ではなく、検知したあとに誰かが判断し動くことで初めて機能します。運用体制の選び方、医療機器のように導入できない端末への代替策、そして導入前に確認しておくべき項目を整理しました。

2026年9月14日
医療情報セキュリティ

ログ管理と監査証跡|取っているが見ていない状態から抜け出す

何のログを取るか、どれだけ保管するか、そして最大の課題である「取っているが見ていない」問題。インシデント発生時に実際に必要になるログは何か、点検を運用に乗せるにはどうするかを、限られた人員の医療機関を前提に整理します。

2026年9月14日
医療情報セキュリティ

医療機関のバックアップ設計|3-2-1ルールと加算1の要件

2026年度改定で、複数方式によるバックアップと一部のオフライン保管が加算1の要件になりました。要件を満たすとされる3つの方式(外部媒体・NASへの自動転送・クラウド内の論理分離領域)、日次なら少なくとも3世代という世代管理、そして復旧試験をしていないバックアップは無いのと同じという論点を整理します。

2026年9月14日
AIカルテ

AIカルテを見る

受付から診療記録、会計、レセプト、経営分析までを一つの循環でつなぐAIネイティブ電子カルテ。

製品ページを見る

ISMS取得支援という選択肢

適用範囲の設計から文書整備、教育、内部監査、審査機関とのやり取りまで。ポテックがヘルスケア企業のISMS(ISO/IEC 27001)認証取得を一気通貫で支援します。