医療機関向けSaaSを提供していると、あるところで必ず同じ質問が来ます。「他の医療機関のデータと、うちのデータは分かれているのですか」。マルチテナント構成そのものが問題視されているわけではなく、分離の仕組みを説明できるかが問われています。
この問いは、ISMSのリスクアセスメントの中心論点でもあります。テナント境界は、医療SaaSにとって最大の情報セキュリティリスクが集中する場所だからです。境界の破れは1件の漏えいでは終わらず、契約している全医療機関に波及します。
本記事では、マルチテナント構成の医療SaaSがISMSで扱うべきリスクと、その評価・対応の具体を整理します。適用範囲の設計そのものは ヘルスケア企業のISMS適用範囲設計 をご覧ください。
免責：本記事は一般的な情報提供です。3省2ガイドラインおよび関連制度の解釈は厚生労働省・経済産業省・総務省の公表資料が、規格の要求事項は規格本文および認定機関・審査機関の公表資料が正本です。個別の構成の適否は、契約先医療機関および専門家とご確認ください。
マルチテナントが医療で問題になる理由
一般的なSaaSでもテナント分離は論点ですが、医療ではリスクの質が変わります。
| 観点 | 一般的なSaaS | 医療SaaS |
|---|---|---|
| 漏えいの影響 | 企業の営業情報等 | 要配慮個人情報。当事者に回復不能な不利益 |
| 影響範囲 | 1テナント内の顧客 | 1テナントの中に数千〜数万人の患者 |
| 停止の影響 | 業務が滞る | 診療が止まる。緊急性のある業務が含まれる |
| 説明を求める相手 | 情報システム部門 | 医療機関の医療情報安全管理責任者、経営層、時に監査法人 |
| 準拠すべき枠組み | 契約とセキュリティポリシー | 3省2ガイドライン、個人情報保護法 |
とくに効いてくるのが、医療機関側が3省2ガイドラインへの対応義務を負っているという構造です。医療機関は自らの義務を果たすために、委託先である事業者に説明を求めざるを得ません。 「安全です」では通らず、どういう仕組みで分離しているのか、誰がテナントを跨いでアクセスできるのか、といった具体を求められます。ガイドラインの全体像は 3省2ガイドラインとは をご覧ください。
もう一点、可用性の重みが違います。ISMSでは機密性・完全性・可用性を並列に扱いますが、医療SaaSでは可用性の喪失が診療の停止に直結します。リスクアセスメントの評価基準を作る際、可用性の影響度を一般的なSaaSと同じ尺度で置くと、実態と合わない結論が出ます。
テナント分離の方式をどう選ぶか
分離の方式は連続的ですが、リスクアセスメントで区別すべき層は主に4つです。
| 方式 | 概要 | 分離の強さ | コスト・運用 | 医療での位置づけ |
|---|---|---|---|---|
| 行レベル分離 | 同一テーブルにテナントIDを持ち、アプリケーションで絞り込む | 弱い | 最も安い。運用も単純 | アプリの実装ミスが直接漏えいになる。医療情報では説明が難しい |
| スキーマ／DB分離 | テナントごとにスキーマまたはデータベースを分ける | 中〜強 | 中程度。テナント数が増えると運用が重くなる | 説明しやすく、採用例が多い |
| インスタンス分離 | テナントごとにアプリ・DBのインスタンスを分ける | 強い | 高い。デプロイとパッチ適用が複雑になる | 大規模病院・要求の厳しい顧客向けの上位プラン |
| 物理・アカウント分離 | クラウドアカウント／VPCごと分ける | 最も強い | 最も高い | 個別要求への対応。標準構成にはしにくい |
選択そのものより、選んだ理由と残存リスクを説明できることが重要です。 行レベル分離を採るなら、なぜそれで十分と判断したのか、アプリケーションの絞り込みが常に効くことをどう保証しているのか（テストの網羅、クエリの共通化、静的解析、レビュー体制）を示す必要があります。ISMSの文脈では、これがリスク対応とリスク受容の記録そのものになります。
現実的な設計としては、標準プランをスキーマ／DB分離とし、要求の厳しい顧客にはインスタンス分離を上位プランで用意する構成がよく採られます。この場合、リスクアセスメントは方式ごとに分けて実施し、適用宣言書でも構成差を説明できるようにします。
分離の破れを検知する仕組みも評価対象です。テナントIDの欠落を検知するテスト、クロステナントアクセスの監視、異常なデータ量の抽出に対するアラート。「破れない設計」だけでなく「破れたら気づく仕組み」があるかを問われます。
データの所在と越境をどう説明するか
医療機関から必ず聞かれる項目です。3省2ガイドラインの枠組みでは、医療情報を取り扱う事業者に対して、保存場所、準拠法、裁判管轄を明確にし、医療機関に説明できることが求められる構造になっています。
説明すべき項目を整理すると次のとおりです。
| 項目 | 確認されること | 見落としやすいところ |
|---|---|---|
| 本番データの保存リージョン | 国内か国外か。リージョンの特定 | マネージドサービスのメタデータが別リージョンにある |
| バックアップの保存先 | 本番と同じか、別リージョンか | 災害対策で国外リージョンに複製していることに気づいていない |
| ログ・監視データの所在 | 監視SaaSに送っているか | APMやエラー監視に患者情報が混入している |
| CDN・WAFの経路 | エッジで何が保持されるか | キャッシュに個人情報が載る設定になっている |
| 生成AI・外部APIの利用 | 送信先と学習利用の有無 | 機能追加時に契約条件が変わっている |
| 保守作業の実施場所 | 国外拠点からのアクセスがあるか | オフショア開発・24時間監視の委託先 |
| 準拠法・裁判管轄 | 契約上の定め | クラウド事業者の標準契約が国外法準拠のまま |
最も多い見落としは、ログと監視データです。 本番データベースのリージョンは意識していても、エラー監視SaaSに送っているスタックトレースに患者IDやリクエストボディが含まれていた、という事故はよくあります。ISMSの情報資産台帳を作る際、ログと監視データを独立した資産として登録することで、この見落としを構造的に潰せます。
生成AI機能を組み込む場合は、送信先・保持期間・学習利用の有無を製品ドキュメントに明記し、医療機関が説明を求めたときにすぐ出せる形にしておきます。この論点は 医療機関の生成AI利用 と AI音声カルテのセキュリティ で扱っています。クラウド利用一般の論点は 医療機関のクラウドセキュリティ をご覧ください。
バックアップとリストアの分離
ここは設計の穴が出やすい領域です。本番でテナントを分離していても、バックアップで混ざっているケースがあります。
評価すべき点は次のとおりです。
- バックアップの粒度：全テナント一括か、テナント単位か。一括だと、1テナントのリストア要求に応えられません
- リストアの単位：特定テナントの特定時点に戻せるか。全体リストアしかできない構成では、1医療機関の誤操作からの復旧が他院に影響します
- リストア先の隔離：復旧作業中の一時環境にテナント境界があるか。検証用にリストアした環境で全テナントのデータが見える状態は典型的な穴です
- バックアップへのアクセス権：本番より緩い権限で参照できてしまわないか
- 暗号鍵の管理：バックアップの復号鍵を誰が持つか。テナント別鍵にするか共通鍵にするか
- リストアの訓練記録：手順があるだけでなく、実際に実施した記録があるか
医療機関側は、自院のシステムについてバックアップの世代管理や復旧手順を求められています。委託先である事業者にも同等の説明を求めるのは自然な流れです。 リストアの所要時間（RTO）と、どこまで戻せるか（RPO）をテナント単位で提示できるようにしておくと、調達段階での説明が短くなります。
テナント管理者権限とサポート運用
技術的な分離が堅牢でも、運用上の権限がテナント境界を越えている例は少なくありません。ここは審査でも医療機関の監査でも必ず掘られます。
| 権限の種類 | リスク | 対応の考え方 |
|---|---|---|
| サービス側の全テナント参照権限 | サポート担当が全院のデータを閲覧できる | 常時付与しない。申請・承認・時限付与にする |
| なりすまし（impersonation）機能 | 顧客アカウントとしてログインできる | 実行ログを必ず残し、対象医療機関へ通知する運用を検討する |
| 本番DBへの直接アクセス | 障害調査時に無制限に読める | 踏み台・記録・承認を必須にし、クエリ内容を残す |
| デプロイ権限 | 全テナントに同時に影響する変更が入る | 変更管理とレビュー、段階的リリース |
| テナント側の管理者権限 | 医療機関内で不適切な権限付与が起きる | 権限設計の推奨をドキュメントで提供し、棚卸し機能を用意する |
| 退職者・異動者のアカウント | 権限が残る | 双方向。自社の棚卸しと、顧客側の棚卸しを促す機能 |
なりすまし機能の扱いは、医療SaaSでは特に慎重に設計してください。 便利な機能である一方、患者の診療情報を事業者側が任意に閲覧できる経路になります。実行ログの保存、事前承認、対象顧客への可視化——このいずれかは必要です。運用ルールだけで縛るのではなく、システムで記録が残る形にしておくと、監査での説明が一気に楽になります。
テナント側の管理者権限は、事業者の管理外に見えて、実は事業者の責任範囲と連続しています。医療機関内で「全職員が全患者を閲覧できる」設定になっていた場合、事故が起きれば製品の設計も問われます。推奨設定をドキュメント化し、逸脱を可視化する機能を用意するところまでが現実的な守備範囲です。責任分界の整理は 責任分界点の決め方 と 責任共有モデル をご覧ください。
医療機関ごとの監査要求にどう応えるか
契約数が増えると、医療機関ごとに異なるチェックシートと、個別の監査・訪問の要求が積み上がります。事業者側の工数を守りつつ説明責任を果たすには、標準の説明パッケージを用意して個別対応を減らすしかありません。
実務的には次の構成が有効です。
- ISMS認証書と適用範囲の説明（1枚）— 登録範囲に運用・保守が含まれることを明示
- セキュリティ白書（10〜20ページ）— 分離方式、データ所在、暗号化、権限管理、ログ、バックアップ、インシデント対応を1本にまとめる
- 3省2ガイドライン対応表 — ガイドラインの要求項目と自社の対応を並べた表
- 責任分界表 — 医療機関側／事業者側／クラウド事業者側の3列で整理
- チェックシート回答の標準版 — よく来る設問への回答を事前に用意し、差分だけ埋める
- 監査対応ポリシー — 訪問監査の受入条件、代替手段（第三者監査報告書や説明会）の提示
このパッケージはISMSの文書から作れます。 リスクアセスメント、適用宣言書、運用手順、インシデント対応手順——医療機関向けの説明資料は、これらの内容を医療機関の言葉に翻訳したものです。ゼロから作るのではなく、ISMS文書を正本として派生資料を生成する形にすると、更新も1回で済みます。この設計は ISMS文書と3省2ガイドライン対応文書の統合 で詳しく扱っています。
医療機関側がベンダーに何を聞いているかを先に知っておくと、パッケージの精度が上がります。ベンダーへのセキュリティチェックシート は発注側の視点で書いています。
まとめ
医療SaaSのマルチテナントリスクを扱ううえでの要点は次のとおりです。
- テナント境界は最大のリスクが集中する場所。破れは1件で終わらず全顧客に波及する。可用性の影響度も一般SaaSと同じ尺度では測れない
- 分離方式は選択そのものより、選んだ理由と残存リスクを説明できるか。「破れない設計」と「破れたら気づく仕組み」の両方を求められる
- データ所在の説明で最も抜けるのはログと監視データ。情報資産台帳に独立した資産として登録する
- バックアップとリストアはテナント単位で成立させる。検証用リストア環境で全テナントが見える状態は典型的な穴
- なりすまし機能と本番DB直接アクセスは必ず掘られる。システムで記録が残る形にする
- 個別の監査要求は標準の説明パッケージで受ける。パッケージはISMS文書から派生させ、更新を一本化する
ポテックはヘルスケア領域に特化してISMS認証取得を支援しています。マルチテナント構成のリスクアセスメントや、医療機関向けの開示文書・リスク対応一覧の作成まで支援範囲に含めています。3省2ガイドライン対応もオプション（150万円〜）でご用意しています。
支援内容と料金は ISMS認証取得支援サービス を、個別のご相談は お問い合わせ をご覧ください。ISMS全体の見取り図は ISMS（ISO/IEC 27001）とは｜ヘルスケア企業のための完全ガイド にあります。
参考・出典
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
- 経済産業省
- 総務省
- 情報マネジメントシステム認定センター（ISMS-AC）
- ISO/IEC 27001 Information security management systems｜ISO
※ガイドラインは改定されます。求められる分離水準・説明事項は契約先医療機関の判断により異なります。最新の内容は各省庁の公表資料をご確認ください。