責任分界点の決め方｜医療機関と事業者

電子カルテが止まった。ランサムウェアでファイルが暗号化された。職員のIDが第三者に使われていた。こうした場面で最初に起きるのは、技術的な復旧作業ではなく、「これは誰の責任か」という確認作業です。そして多くの医療機関で、この確認に時間がかかります。契約書に答えが書かれていないからです。

責任分界点は、事故が起きてから決めるものではありません。導入時に決めて文書化しておくものです。にもかかわらず後回しになりやすいのは、導入検討の段階では**「事故は起きない前提」で話が進む**からであり、また分界点の議論が技術的にも契約的にも面倒だからでもあります。

本記事では、医療機関と事業者のあいだで責任分界点をどう決めるか、クラウド利用時に何が変わるか、そして決めた内容を契約書・SLAにどう落とすかを整理します。責任共有モデルそのものの技術的な設計論は AIカルテのセキュリティ設計｜責任共有モデルとゼロトラストで考える で扱っていますので、本記事は合意形成と文書化の手続きに重心を置きます。

免責：本記事は一般的な情報提供です。責任の所在は個別の契約内容・事実関係によって決まります。実際の契約締結・紛争対応にあたっては、専門家および最新の一次情報をご確認ください。

責任分界点とは、何を決めることか

責任分界点という言葉は、しばしば「どこまでベンダーが面倒を見てくれるか」という意味で使われます。これは半分正しく、半分足りません。正確には、次の3つを領域ごとに決める作業です。

1. 管理責任 — 誰がその領域を日常的に管理・運用するか
2. 費用負担 — その領域で問題が起きたとき、誰が復旧費用を負担するか
3. 説明責任 — 患者・監督官庁・報道に対して誰が説明に立つか

この3つは必ずしも一致しません。ここが最も重要な点です。たとえばクラウド事業者が管理し、費用も事業者が負担する領域であっても、患者への説明責任は医療機関が負うのが通常です。患者にとっての契約相手は医療機関だからです。

つまり「ベンダーに任せてあるので当院の責任ではありません」という説明は、管理責任の話としては正しくても、説明責任の話としては成立しません。委託によって移転できるのは管理責任と費用負担であって、説明責任は医療機関に残ります。 この構造を理解していないと、分界点を決めたつもりで肝心なところが抜けます。

この非対称性があるため、医療機関には**「事業者に任せた領域についても、任せた内容を説明できる状態」**が必要になります。委託先管理という言葉の実質は、ここにあります。

クラウド利用で責任はどう分かれるか

オンプレミスであれば、物理サーバから業務運用まで一続きで医療機関が管理していました。クラウドでは、この一続きが層に分解され、層ごとに管理者が変わります。

この表で注目すべきは最下段の3行です。どのモデルを選んでも、アクセス権限・アカウント・データの中身は医療機関の責任として残ります。SaaSにすればセキュリティ全部が事業者側に移る、という理解は誤りです。

実際、公表されている医療機関の被害事例に共通する構造を見ると、事業者側の基盤が破られたというより、医療機関側に残った領域——退職者のアカウントが残っていた、特権IDが共用されていた、VPN機器の更新が止まっていた——が入口になっているパターンが目立ちます。分界点の議論は、事業者を選ぶ話であると同時に、自院に何が残るかを確認する作業でもあります。

自院側に残る領域の設計は アクセス権限設計と特権ID管理 と VPN機器の脆弱性対策 に、クラウド固有のセキュリティ論点は 医療機関のクラウドセキュリティ にまとめています。

曖昧になりやすい6つの領域

分界点の議論で毎回争点になるのは、実は限られた領域です。以下の6つを先に潰しておくと、あとは比較的スムーズに決まります。

1. バックアップ

「バックアップは取っています」で終わらせないこと。誰が取得し、どこに保管し、誰がリストアを実行し、リストアの検証は誰がいつ行うか。とくにリストアの実行主体と所要時間は、事故時に直接効きます。2026年度診療報酬改定の電子的診療情報連携体制整備加算1では、複数方式によるバックアップと一部のオフライン保管が要件に含まれており、この分界が算定にも関わるようになりました。設計は 医療機関のバックアップ設計｜3-2-1ルール をご覧ください。

2. 脆弱性対応とパッチ適用

OSとミドルウェアのパッチを誰が当てるか。当てる前の検証は誰がするか。「適用は事業者、適用可否の判断は医療機関」という分け方は、判断のための情報が医療機関に届かなければ機能しません。 脆弱性情報の通知義務を契約に入れておくこと。

3. ログの取得・保管・点検

取得は事業者、点検は医療機関、という分け方が多く見られます。このとき問題になるのは保管期間と開示形式です。事故調査の段階で「ログは30日で消えます」と言われると調査が成立しません。開示に別料金がかかるかどうかも先に確認します。詳しくは ログ管理と監査証跡 へ。

4. インシデント発生時の初動

検知は誰が行うか。誰が誰に何時間以内に通知するか。サービス停止の判断権限は誰にあるか。 最後の点はとくに重要で、事業者が他テナントを守るためにサービスを止める判断をした場合、医療機関の診療は止まります。この判断権の所在と、事前協議の要否を決めておきます。

5. 再委託先で起きたこと

クラウド型サービスでは、データ保管がIaaS事業者に再委託されているのが通常です。再委託先で起きた事象の責任を、直接の契約相手である事業者が負うのかを明記します。「当社の責に帰さない事由」として再委託先の障害が免責されている契約は珍しくありません。

6. 契約終了時のデータ

返還の形式（標準形式か、独自形式か）、期限、返還後の消去、消去証明の発行。移行可能な形式で返ってこないデータは、実質的に人質です。 導入時にここを決めておくことが、次の更新時の交渉力になります。電子カルテ更新時のセキュリティ要件 も参考にしてください。

決めた内容を契約書とSLAに落とす

合意しただけでは機能しません。文書に落とすときの実務的な作法をまとめます。

責任分界表を別紙にする

契約書の本文に散らして書くと、後から参照できません。領域ごとに「医療機関／事業者／共同」の3分類で1枚の表にし、契約書の別紙として添付するのが最も実用的です。「共同」を設ける理由は、現実には片方に振り切れない領域があるためで、その場合は共同の中身（誰が何をするか）を必ず注記します。注記のない「共同」は、事故時に「相手がやると思っていた」を生みます。

要点は主語・期限・形式を入れることです。この3つが入っていない条項は、事故時にほぼ役に立ちません。SLAの書き方の詳細は SLAと責任分界の書き方 に整理しています。

賠償上限と免責を確認する

多くのシステム契約には賠償額の上限（月額料金の◯か月分など）が設定されています。これ自体は珍しいことではありませんが、医療機関が負う実損——診療停止による減収、患者への通知費用、調査費用、信用回復の費用——との桁の差は認識しておく必要があります。

上限を動かせない場合、次の3つが代替策になります。

1. サイバー保険で自院側を手当てする（医療機関のサイバー保険）
2. 復旧の速さを重視した設計にして、そもそも実損を小さくする（サイバー攻撃を想定したBCP）
3. 賠償ではなく、事業者側の予防義務を具体的に契約に書き込む

3つ目が最も実効的です。賠償条項を争うより、「何をしていなければ債務不履行か」を事前に具体化しておくほうが、事業者の行動を変える力があります。

更新時に見直す

責任分界は一度決めて終わりではありません。サービスの仕様変更、再委託先の変更、ガイドラインの改定、自院の体制変更のいずれかがあれば見直します。契約更新のタイミングで分界表を必ず棚卸しする運用にしておくと、実態と文書のずれが蓄積しません。

まとめ

1. 責任分界点とは、管理責任・費用負担・説明責任の3つを領域ごとに決めること。この3つは一致しない
2. 説明責任は委託で移転しない。 患者・行政への対応は医療機関に残る
3. クラウドでは層ごとに管理者が変わるが、アクセス権限・アカウント・データの中身は常に医療機関側に残る
4. 争点になるのは、バックアップ・脆弱性対応・ログ・初動・再委託・契約終了時データの6領域。先に潰す
5. 文書化では主語・期限・形式を入れる。「共同」と書く場合は中身を注記する
6. 賠償上限は動かしにくい。争うより事業者の予防義務を具体化するほうが実効的

責任分界表のたたき台づくりや、既存契約の分界点レビューでお困りの場合は お問い合わせ からご相談ください。自院の対応状況を先に把握したい場合は 3省2ガイドライン対応チェックリスト と 3省2ガイドライン対応の実務ステップ が出発点になります。事業者側として体制を証明する立場であれば ISMS（ISO/IEC 27001）とは をご覧ください。

参考・出典

• 医療情報システムの安全管理に関するガイドライン｜厚生労働省
• 医療情報システムの安全管理に関するガイドライン 第6.0版（本文PDF）｜厚生労働省
• 令和8年度診療報酬改定について｜厚生労働省
• 個人情報保護委員会
• 情報処理推進機構（IPA）

※責任の所在は個別契約と事実関係により決まります。ガイドラインおよび診療報酬上の要件は改定され得るため、実務では最新の一次情報をご確認ください。