Supabaseで医療系SaaSを設計する｜3省2ガイドライン対応とAI連携の安全原則【AI活用検証vol.82】

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

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

この検証の概要

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

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

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

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

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

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

アーキテクチャ：1プロジェクト + clinic_id + RLS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

誤解されやすい論点です。ガイドライン第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に渡してよいもの・渡してはいけないもの

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

安全原則

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は補助

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導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。