最終更新: 2026-05-10

データ保護・ガバナンス（Gemini API / 有料階層運用 + Supabase 保管場所）

<!-- UPDATED_AT --> 2026-05-10

目的（知財・法務・監査向け）

本書は、「つながる帳」が Google Gemini API を利用するにあたり、有料階層（Pay-as-you-go 相当）で運用し、健康情報を含む入力データの取り扱いを契約証跡と実装上の統制の両面から説明するためのメモです。

加えて、主たる保管場所（Supabase = AWS 東京リージョン）と、外国移転になり得るデータ経路についても、APPI（個人情報保護法）28条の観点から正直に記載します。

---

1. 契約証跡（Evidence）

1.1 Billing（有料階層）

> 注意: 上記は「運用上、有料階層で利用している」ことの証跡であり、実際の請求は Google 側の課金状態・支払い方法設定に従います。

1.1a Logs and Datasets（監査可能性の補助証跡）

1. ログの保持: 画面上部に 55 days (max) と表示されており、API利用履歴が一定期間保持される設計であることが読み取れる。これにより「いつ、どのモデルに通信したか」を後から追跡（監査）できる体制を説明できる。

2. データセットのクリーンさ: 画面下部のリストが空（不必要なデータセットが見当たらない）であることは、「意図的に学習用のトレーニングデータを作成・提供していない」運用であることの補助説明になる。

3. プロジェクトの紐付け: Project が My First Project ... に設定されており、特定のプロジェクト単位でログが見える。Billing（請求先アカウントID: 01706D-E4F715-46C6C5）側の証跡と組み合わせて「プロジェクト×請求×ログ」の紐付け管理を説明できる。

1.2 規約・データ保護条項（要PDF保管）

本プロジェクトでは、次の文書（同意時点の版）を PDF として保存し、該当箇所をハイライトした版も残します。

主張したいポイント（要 原文引用）

> 本書は、原文PDFが evidence に揃い次第、該当条項を「引用（原文＋日本語要約）」の形で追記して完成版とします。

1.3 監査ログ（Audit Logs）（要スクショ保管）

Google Cloud 側の監査ログが有効であることを示す画面を証跡として保管します。

---

2. 実装上の統制（コードによる担保）

2.1 有料プラン運用の強制（ガード）

Gemini API を呼ぶサーバーコードは、環境変数 GEMINI_PAID_PLAN_CONFIRMED が未設定の場合に 503 を返し、無料プラン運用を抑止します。

2.1a 予兆アラート（外部AI不使用）

api/precursor-alerts-batch.js は daily_records のルール検知のみで、team_messages に職員向け通知を INSERT する。Gemini API は呼ばない（キー不要）。実行には SUPABASE_SERVICE_ROLE_KEY と（推奨）CRON_SECRET が必要。

2.1b 家族向け記録通知・最適ディスパッチ（外部AI不使用）

api/notify-family.js / api/optimal-notification.js / api/family-notification-dispatch.js および api/lib/optimalNotification.js は、家族ユーザーの閲覧ログ（Supabase 内）を集計する決定的ロジックで通知時刻を決め、family_notification_logs と contact_messages を更新する。Gemini やその他外部推論 API は呼ばない。サーバー側では SUPABASE_SERVICE_ROLE_KEY（および職員 JWT 経路での VITE_SUPABASE_ANON_KEY）を使用する。Cron からの family-notification-dispatch には（推奨）CRON_SECRET による Bearer 検証をかけられる。

2.2 APIキーの配置（クライアントへ漏らさない）

Gemini API キーは process.env.GEMINI_API_KEY のみから参照し、VITE_ のようなクライアント埋め込み変数として扱いません。

2.3 送信データの最小化（識別子の扱い）

機能ごとに、外部AIへ送るデータは目的最小限とし、直接識別子（氏名・residentId 等）をプロンプト本文に含めない方針です。

（詳細は public/docs/system-overview-ip-and-apis-ja.html の「外部APIに送るデータ項目（一覧）」を参照）

---

3. 次アクション（証跡の完成）

1. 規約PDF（Gemini API Terms / Data Governance Addendum）をダウンロードし、evidence に保存（ハイライト版も）

2. Google Cloud / AI Studio の 「ログとデータセット」 画面で、監査・ログが有効と分かるスクショを保存

3. 監査ログ（Audit Logs）の設定画面のスクショを保存

---

4. データ保管場所（Supabase / AWS 東京 ap-northeast-1）

外部AI（Gemini）の論点に加え、主たる業務データの保管場所もコンプライアンス上の説明対象になるため、本節で明示します。

4.1 主たる保管場所：AWS 東京リージョン（ap-northeast-1）

4.2 国内に保管されるデータ（要配慮個人情報を含む）

下記はすべて AWS 東京（物理的に日本国内）に保管されます。

| データ | Supabase 上の場所 |

|--------|--------------------|

| 利用者・職員・家族の アカウント情報（メール / ハッシュ化パスワード等） | Supabase Auth |

| 日次記録（バイタル・申し送り・食事・排泄 等） | daily_records 等のテーブル |

| メンタルヘルス推論結果 JSON | mental_health_* テーブル |

| 画像変化検知スコア・職員判定 | image_change_detections 等 |

| 予兆アラート（ルール検知による職員通知文） | team_messages |

| 記録写真（実体） | Storage バケット record-photos |

| 顔特徴量（face-api.js descriptor、AES-GCM 暗号化済み） | face_descriptors 等 |

4.3 外国移転になり得るデータ経路（正直な記載）

「データは国内です」と一括で言うのは APPI 28条（外国にある第三者への提供）の観点で不正確になり得るため、以下を正直に開示します。

| 経路 | 行き先 | 該当条文・対応 |

|------|--------|----------------|

| Gemini API（テキスト整形 / 身体画像分析 / メンタルヘルス推論） | Google LLC（米国法人）。物理ロケーションは Google 側仕様に依存 | APPI 28条「外国にある第三者への提供」: 利用規約・同意書で米国移転と提供目的の同意を取得する設計 |

| Supabase の運営会社 | Supabase, Inc.（米デラウェア州） | 物理保管は東京だが、運営者は外国法人。クラウドサービス利用契約の準拠法は米国法 |

| AWS の運営会社 | Amazon Web Services, Inc.（米国） | 同上（クラウド提供事業者の本籍） |

| Vercel CDN（静的ファイル配信） | グローバル Edge（東京 Edge を含む） | 公開静的ファイルのみ（個人情報なし） |

> 整理: 「物理的な保管場所」と「処理する事業者の所在国」は別概念です。本サービスは前者（物理保管）は東京で完結し、後者（事業者の所在）は米国を含むため、APPI 上は「国内処理」ではなく「越境移転を伴うクラウドサービスの利用」として運用します。利用規約・プライバシーポリシーで米国移転を明示的に開示し、同意取得の根拠を残します。

#### 補足：自社 /api/* の実行リージョンは東京固定

vercel.json に "regions": ["hnd1"]（2026-05-08 設定）を指定しているため、自社 Serverless Functions（api/gemini.js、api/image-analysis.js、api/mental-health.js、api/mental-health-batch.js、api/precursor-alerts-batch.js、api/save-detection.js 等）はすべて 東京（hnd1）リージョンで実行される。これにより、Gemini への送信が発生する場合でも、自社処理レイヤーの実行までは国内で完結する。Vercel Hobby（Free）プランでも単一リージョン指定は可能。設定反映には再デプロイが必要。

4.4 現状の制約：Free Plan / NANO（要 Pro 移行検討）

スクショで確認できる通り、現状の Supabase 組織プランは Free、コンピュートサイズは NANO です。本番介護施設運用としては以下の制約があるため、Pro Plan への移行を別紙でメモします。

| 観点 | Free / NANO の現状 | 本番介護施設運用での懸念 |

|------|--------------------|--------------------------|

| メモリ・CPU | 0.5 GB / Shared CPU | 顔認証・画像処理の同時実行で詰まる可能性 |

| バックアップ | 論理バックアップ最大7日 | PITR（任意時点復旧）なし |

| 一時停止 | 1週間アクセスがないと一時停止 | 連休・閑散期に止まる |

| DPA（データ処理契約） | Pro 以上が前提 | 要配慮個人情報の処理委託契約の根拠が弱い |

| HIPAA Add-on | Pro 以上のみ | 海外監査・将来拡張時に不利 |

| SLA | なし | 施設運用の SLA 説明ができない |

> 推奨アクション: Free → Pro 移行（リージョンは保持されたままアップグレード可能）。移行後、Supabase の DPA を締結し、本書 §4.3 の「Supabase 運営者所在」の論点と合わせて知財面談で提示。

4.5 想定問答（保管場所関連）

#### Q. データは国内に保管されているのですか？

A. 主たる保管（DB・認証・写真・顔特徴量）は AWS 東京リージョン（ap-northeast-1）で物理的に国内保管です（証跡: evidence/supabase-region-tokyo_20260507.png）。一方、運営会社（Supabase Inc.、AWS Inc.）は米国法人であり、また外部AI（Gemini API）に送るデータは Google（米）に渡るため、APPI 28条の越境移転に該当する経路があることを利用規約で開示し、同意を取得する設計です。

#### Q. 越境移転に該当するなら、なぜ東京リージョンを選んだのですか？

A. 物理保管を国内に集中させることで、(a) アクセス性能の低下回避、(b) 国内データセンターの物理セキュリティ・障害発生時の説明性、(c) 国内施設の災害対策計画との整合 を担保するためです。「物理保管 = 国内」「事業者の本籍 = 米国（要 28条対応）」を両立させる二段構えとしています。

#### Q. Free Plan のままで本番運用は問題ないですか？

A. 本番運用としては Pro Plan 移行を推奨しています。Free Plan では PITR・DPA・HIPAA・SLA のいずれも取得できないため、要配慮個人情報を扱う本番運用としては不十分です（§4.4）。