---
title: "Supabaseで医療系SaaSを設計する｜3省2ガイドライン対応とAI連携の安全原則"
excerpt: "医療クリニック向けSaaSをSupabaseで構築する際の論点を整理しました。PITR要件がプラン選択を決める構造、clinic_id＋RLSによるマルチテナント設計、ゼロトラストが必須要件ではない理由、東京リージョンでも国内要件を満たさない点、そしてAIにDBを触らせる際の安全原則までをまとめています。"
author: "AI活編集部"
author_username: ai-katsu-editorial
published_at: 2026-05-02T00:00:00+00:00
verified_at: 2026-05-02T00:00:00+00:00
models: ["Claude Code"]
tools: ["Supabase", "MCP"]
tasks: ["開発・エンジニアリング", "ツール検証"]
canonical_url: https://ai-katsu.jp/articles/supabase-medical-system-qa
---
# Supabaseで医療系SaaSを設計する｜3省2ガイドライン対応とAI連携の安全原則

医療系システムをクラウドで構築するとき、技術選定より先に決まってしまうことがあります。**法令・ガイドラインの要件が、使えるプラン・構成を絞り込む**ためです。

この検証では、Supabaseで医療クリニック向けSaaS（電子カルテ・薬品在庫・予約管理等）を設計する際の論点を、**アーキテクチャからコンプライアンス、AI連携時の安全原則まで**整理しました。

## この検証の概要

| 項目 | 内容 |
| --- | --- |
| 作成日 | 2026年5月2日 |
| 対象 | 医療クリニック向けSaaS（電子カルテ・薬品在庫・予約管理等） |
| 整理した範囲 | Supabaseのアーキテクチャ設計／3省2ガイドライン対応／監査ログ・バックアップ設計／Claude Code連携時の安全原則 |
| 本番最小構成 | **約$140/月**（Pro $25 + Small compute $15 + PITR 7日 $100） |

> 本記事は技術設計上の整理であり、法的助言ではありません。実際の導入判断にあたっては、必ず最新のガイドライン原文を確認し、必要に応じて専門家にご相談ください。情報は2026年5月時点のものです。

## 結論：ガイドラインが構成を決める

医療系で特徴的なのは、**技術的な最適解と、法令要件を満たす構成が一致しない場面がある**ことです。

典型例がPITR（Point In Time Recovery）です。

**PITRの利用にはPro Plan以上に加えて、Small compute add-on以上が必要です（Microでは不可）。**つまり「バックアップ要件を満たす」という一点で、コンピュートのプランまで決まります。

結果として、日本案件で3省2ガイドラインに適合させる本番最小構成は次のようになります。

| 構成 | 月額目安 | 用途 |
| --- | --- | --- |
| Pro $25 + Small compute $15 + PITR 7日 $100 | **約$140/月** | 日本案件・本番最小構成 |
| Team $599 + Small compute $15 + PITR $100 + HIPAA add-on | 約$1,000〜1,500/月 | HIPAA対応が必要な場合 |

## アーキテクチャ：1プロジェクト + clinic\_id + RLS

マルチテナント設計の選択肢は3つありますが、推奨は明確です。

**推奨: 1 Supabase Project + 共通DB + `clinic_id` + RLS（Row Level Security）**

| 方式 | 評価 |
| --- | --- |
| **shared schema + clinic\_id + RLS** | **推奨。**開発・運用・AI連携・管理画面がシンプル |
| スキーマ分離 | クリニック増加時のマイグレーション・横断集計・保守が重い |
| プロジェクト分離 | 分離度は最高だが、Auth/Storage/Functions/Secrets/費用管理が増える |

プロジェクト分離への移行を検討すべきタイミングも整理しています。**完全分離・個別バックアップ・個別SLA・大規模施設のリソース分離が必要になったとき**です。

**最初から最も分離度の高い構成を選ぶと、運用対象が増えて管理が破綻します。**必要になったら移行する、という判断が現実的です。

## トランザクション設計：アプリ側で複数クエリを投げない

ここは業務システムで事故になりやすい箇所です。

| 処理の性質 | 実装方式 |
| --- | --- |
| 単純CRUD（一覧取得、基本情報更新） | Supabase Client + RLS |
| **ACID必要な業務処理**（予約確定・処方確定・在庫減算） | **Postgres関数/RPC（1トランザクション）** |
| 外部API連携・秘密鍵・複雑検証・通知 | Edge Functions → 単一RPC呼び出し |
| **アプリ側で複数クエリを順番に投げる** | **原則禁止** |

禁止する理由は、**途中失敗・二重送信・ロールバック漏れのリスク**です。処方確定や在庫減算が中途半端な状態で止まると、データの整合性が崩れます。

見落としやすい点があります。**Edge Functionsで複数のSupabase APIを順番に呼ぶだけでは、1トランザクションになりません。**「サーバー側で処理しているから安全」という理解は誤りです。

## e-文書法の三原則をどう満たすか

電子カルテ・診療録を電子保存する場合、3つの要件を満たす必要があります。

| 要件 | 内容 | 実装例 |
| --- | --- | --- |
| **真正性** | 入力者の識別と認証 | MFA必須、supa\_audit/pgauditで変更履歴記録 |
| **見読性** | いつでも読める状態 | 可用性設計、RTO/RPO定義 |
| **保存性** | 指定期間の保存 | PITR、**診療録は患者最終来院から5年保存**、Log Drains外部転送 |

**「5年保存」という要件が、ログの外部転送を必要にします。**プラットフォームのログ保持期間はプラン依存であり、数年規模の保管には対応できません。

## 監査ログ設計の限界も含めて整理する

提案時に重要な姿勢として、**「医療グレード」と断定せず、要件→実装策→ギャップの順で整理する**ことを挙げています。

| 種別 | 実装方法 | 制約 |
| --- | --- | --- |
| 変更履歴 | supa\_audit（トリガー方式） | 書込3k ops/sec超えるテーブルには不向き |
| 閲覧ログ | pgaudit | **`pgaudit.log_parameter` はHosted版で変更不可**（SELECTバインド値の詳細ログに限界） |
| 長期保管 | Log Drains → S3/BigQuery等 | Logs Explorerの保持はプラン依存 |
| 重要業務 | RPC/Edge Functions内で明示的に監査ログを書き込む | — |

**できないことを先に明示するほうが、後の信頼につながります。**特に監査ログは「取れているはず」と思われたまま進むと、監査時に問題になります。

## ゼロトラストは「必須」ではない

誤解されやすい論点です。ガイドライン第6.0版の記述を正確に読むと、こうなっています。

> 「ゼロトラスト思考に基づく対策を**必須としているわけではなく**、リスク分析の結果や、費用対効果も考慮したうえで判断することが望ましい」

**「境界防御を捨ててゼロトラストへ」ではなく「境界防御をしっかり固めた上で、ゼロトラストを段階的に取り入れる」が正しい読み方**です。

小〜中規模クリニックで優先すべき実装（境界防御）は次のとおりです。

-   Network Restrictions（IP allowlist）
-   SSL Enforcement
-   **管理ダッシュボードへの2FA必須化**
-   **service\_role key / secret keyのサーバー側限定**
-   Cloudflare等のWAF/CDN（フロント側）

端末認証・SIEM・SOC・常時セッション検証といったゼロトラスト要素は、中長期で段階導入する位置づけです。

**ガイドラインを「全部やらないといけないもの」と読むと、実現不能な要件になります。**原文の表現を確認することが重要です。

## HIPAAは日本の医療機関には原則対象外

これも整理が必要な論点です。

**HIPAAは「患者の国籍」ではなく「米国のCovered Entity（医療機関・健康保険）かどうか」で適用されます。**日本国内のクリニックは、患者が日本人・在日外国人であっても直接の適用対象外です。

したがって「慣習的にHIPAAを使う前提」も日本市場では成立しません。**日本で参照すべきは3省2ガイドラインです。**

なお、SupabaseでHIPAA BAAを締結する場合は**Team Plan以上 + HIPAA add-onの申請が必要（Pro Planでは不可）**です。

## 日本国内リージョンでも「国内サーバー要件」を満たすとは限らない

見落とされやすい論点です。

-   Supabaseの契約主体はシンガポール法人
-   **Tokyoリージョン（ap-northeast-1）を選択するだけで「日本国内サーバー」要件を満たすわけではない**
-   個情法28条「外国にある第三者への提供」または法23条「外的環境の把握」のいずれかに該当しうる
-   **契約主体・サブプロセッサー（AWS等）・サポート対応国の整理が必要**

**データの物理的な保管場所と、法的な取り扱いは別の問題です。**リージョン設定だけで安心してはいけません。

## バックアップ：RPO/RTOを先に決める

-   **PITR利用要件**: Pro Plan以上 + **Small compute add-on以上（Microでは不可）**
-   PITR有効時は日次バックアップが置き換わる
-   日次バックアップ保持期間: Pro 7日 / Team 14日 / Enterprise 最大30日
-   **医療系推奨ライン: RPO=数分単位、RTO=数時間レベル**
-   **本番投入前にステージングで復元手順をリハーサルする**

最後の項目が実務的に重要です。**バックアップは取っているかではなく、戻せるかで評価すべきものです。**手順を試していなければ、あるだけの状態になります。

あわせて、可用性の考え方も整理されています。**医療系では「SaaS障害ゼロ」を前提にしない。**当日患者リストの定期エクスポート・キャッシュを検討し、RTO/RPO・障害時連絡先・復旧判断者を事前に決めておきます。

## AIにDBを触らせるときの安全原則

この設計で特に重要な部分です。開発効率のためにAIを使う場合でも、越えてはいけない線があります。

### 環境を2つに分ける

| 環境 | 用途 | AI操作 |
| --- | --- | --- |
| ステージングProject | 開発用（**架空・匿名化データのみ**） | 読み書き・破壊的操作・ALTER TABLE直生成OK |
| 本番Project | 実運用（実患者データ） | **AIツールを直接接続しない** |

### AIに渡してよいもの・渡してはいけないもの

| 渡してよい | 渡してはいけない |
| --- | --- |
| スキーマ（テーブル定義、型情報） | **行データ（要配慮個人情報）** |
| 架空・匿名化データのステージングDB | service\_role key |

スキーマについても注意点があります。**テーブル名にクリニック固有情報が含まれる場合は配慮が必要です。**

### 安全原則

1.  接続先はステージングProjectのみ。**本番には直接つながない**
2.  **破壊系コマンド（DROP TABLE / TRUNCATE / db reset 等）は人間が確認してから実行**
3.  **service\_role keyをAI実行環境に置かない**（個人OAuth/PATで認証）
4.  **AI生成SQLは必ずmigrationファイル化 + PRレビューを通す**
5.  アクセストークンは環境変数（`.env` gitignore済み）で管理

**AIの生成物をそのまま本番に適用しない、という一点が守られていれば、多くの事故は防げます。**レビュー可能な形（migrationファイル）を経由させることが仕組み上の担保になります。

## CLIとMCP、どちらでAIをつなぐか

**推奨: CLI（Git Bash経由）を基本、MCPは補助**

| 観点 | CLI | MCP |
| --- | --- | --- |
| **コンテキスト消費** | **ほぼゼロ** | 10〜15k tokens / メッセージ（200kウィンドウの5〜10%） |
| 操作範囲 | CLI全機能（db pull/push/diff/dump/migration/gen types等） | MCP公開ツールに限定 |
| UNIXツール連携 | grep/sed/awk/jqとシームレスに連携 | 別途bash必要 |

**MCPは1メッセージあたり10〜15kトークンを消費します。**常時つないでおくと、会話の余裕が削られます。探索的な操作や他ツールとの横断ワークフローに限定し、使う場合は最小スコープ（`read_only=true` 等）にするのが現実的です。

## 本番反映の4ステップ

1.  ステージングで試作（AI経由でフリーに変更）
2.  確定したスキーマを `supabase db pull --linked` 等でmigrationファイル化、**PRレビュー**
3.  リセット済みステージングに `db push` でリハーサル。アプリの主要動線確認
4.  本番に `db push`（リード担当 or CI経由）+ **切り戻し手順を事前に用意**

切り戻し手順の最低ラインは次の3点です。

-   PRにこのmigrationが何を変えたか明記
-   **ロールバック用の逆SQLを用意**
-   **本番適用前にPITRの復元ポイントを確認**

## RLS未設定というリスク

マルチテナント構成で最も重大な事故は、テナント間のデータ漏えいです。

-   **全テーブルでRLS有効化を原則にする**
-   患者/予約/処方/会計などのデータは `clinic_id` 条件を必須化
-   **テストユーザーA/Bで「別テナントのデータが読めない・書けない」自動テストを作る**
-   **Security Advisor警告ゼロを本番リリース条件にする**

**RLSは「設定した」ではなく「破れないことをテストで確認した」状態にして初めて意味を持ちます。**

APIキーの扱いも同様です。**anon keyの安全性はRLS設計に完全に依存します。**service\_role keyはサーバー側限定で、フロント・Git・AIへのプロンプトに出してはいけません。

## 2027年度以降の義務要件

今後を見据えた要件も記録しておきます。

**新規導入または更新する医療情報システムには、二要素認証の採用が義務化されます（2027年度以降）。**

いま設計するシステムは、この時期に更新対象となる可能性があります。**後から足すより、最初から組み込んでおくほうが安く済みます。**

## よくある質問

### マルチテナントはどう設計すべきですか？

**1プロジェクト + 共通DB + `clinic_id` + RLSが推奨です。**スキーマ分離はマイグレーションと横断集計が重くなり、プロジェクト分離は管理対象が増えます。完全分離や個別SLAが必要になった段階で移行を検討します。

### 日本の医療機関でもHIPAA対応は必要ですか？

**原則不要です。**HIPAAは米国のCovered Entityに適用されるもので、日本国内のクリニックは直接の対象外です。参照すべきは3省2ガイドラインです。

### 東京リージョンを選べば国内要件を満たせますか？

**満たすとは限りません。**契約主体が海外法人である場合、個情法28条または法23条の論点が生じます。契約主体・サブプロセッサー・サポート対応国の整理が必要です。

### AIにデータベースを触らせても大丈夫ですか？

**ステージング環境（架空・匿名化データのみ）に限定すれば可能です。**本番には直接接続せず、生成されたSQLは必ずmigrationファイル化してPRレビューを通します。行データは絶対に渡しません。

## まとめ

-   医療系では**ガイドライン要件が構成を決める。**PITR要件だけでコンピュートのプランまで確定する
-   マルチテナントは**1プロジェクト + `clinic_id` + RLS**が基本。分離は必要になってから
-   **Edge Functionsで複数APIを順に呼んでも1トランザクションにはならない。**ACIDが必要な処理はRPCで
-   **ゼロトラストは必須要件ではない。**境界防御を固めたうえで段階導入が正しい読み方
-   **HIPAAは日本の医療機関には原則対象外。**参照すべきは3省2ガイドライン
-   **東京リージョンを選ぶだけでは国内要件を満たさない。**契約主体とサブプロセッサーの整理が必要
-   AI連携は**ステージング限定・行データを渡さない・migrationファイル経由でPRレビュー**が原則
-   **2027年度以降、二要素認証が義務要件**になる

規制のある領域では、技術選定の自由度は思ったより低くなります。要件を先に洗い出しておくと、実装に入ってからの手戻りを避けられます。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のシステム設計とAI導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。