結論・方針
個人情報を守りながらアプリを開発・運用するための、構成の考え方をまとめた資料です。
採用する方式
患者データは「自社の管理下のサーバー」に保存する。 画面（フロント）には患者データを埋め込まず、ログイン認証の後ろにあるデータAPI経由でのみ取得する。外部サービス（CDN等）は“玄関（配信・認証）”として使い、データ本体は外に出さない。
いまの方式の問題点
試作版は、集計済みデータを静的ファイル（data/*.js）に直接埋め込み、ブラウザがそれを読み込んで表示していました。手軽さが利点ですが、本番には次の弱点があります。
- ファイル＝名簿：患者氏名・年齢・術式などが静的ファイルに入っており、ファイルを取得できれば中身が全部読める。
- 認証がない：誰が見たかを制御・記録できない。
- 置き場所の自由が効かない：公開ホスティングに置くと個人情報が露出する。
守る仕組み
データとコードを分ける
原則はひとつ。コードとデータを分け、データは“認証の後ろ”に置く。画面のガワと、患者データの中身を物理的に切り離します。
- フロント（HTML/JS/CSS）には患者データを一切含めない → どこに置いても安全。
- 患者データは自社サーバーのDBの中だけに存在する。
- ログインした利用者に、その人が見てよい分だけを実行時にAPIで返す。
アーキテクチャ（3層）
患者データは ③ の中だけに存在し、外へ複製しない。現状の backend/server.py（Python＋SQLite）と /api/... が ③ として既に稼働しています。
自社サーバーとAPI化
なぜ「自社サーバー保存」なのか
「サーバー」と「外部サービス（CDN等）」は役割が別物です。混同しないことが重要です。
| 役割 | 内容 |
|---|---|
| サーバー（本体） | アプリを動かし、データを保存する所。＝自社の管理下に置く。 |
| 玄関・配信 | 利用者を本体へ繋ぐ通り道・認証（社内LAN／VPN／Cloudflare Tunnel+Access 等）。保存場所ではない。 |
API化について
必要性
画面から情報を入力・保存・共有するには、入力を受けて保存する“受け口”＝APIが必須です。将来のWeb入力（Excel脱却）もこの土台に乗るため、API化は本線です。
デメリット（正直に）
- サーバーが常に必要：データ取得・保存にバックエンドが稼働している必要がある。
- オフライン閲覧不可（データ部分）。
- 運用の手間：認証・セッション・起動維持・バックアップ・監視。
費用
- API化そのものは無料（現行の Python＋SQLite のまま実装可。ライセンス費なし）。
- かかるのはサーバーの置き場所のみ：自社PC/サーバなら基本ゼロ（電気代）／国内クラウドなら月数百〜数千円。
運用・バックアップ
常駐サーバー化
- サーバー専用マシンを用意（作業PCと分ける）。
- 自動起動（再起動・停電復帰で自動的に立ち上がる）。スリープ無効。
- 通信は HTTPS、保存は 暗号化、操作は 監査ログ。
データを失わない ― 3-2-1ルール
コピーを3つ、媒体を2種類、うち1つは別の場所に。
- 自動バックアップ＋世代管理（日付つきで複数残す＝誤操作・ランサム対策）。
- SQLiteは整合性のある取得を（コピーではなく
.backup/VACUUM INTO。journal_mode=WAL推奨）。 - バックアップ自体も暗号化＋アクセス制限。リストア訓練を行う。
落ちても使える ― 可用性
- 自動再起動（プロセス死・電源復帰で復活）。
- 予備機（最新データを同期）／UPS（無停電電源）でDB破損を防ぐ／死活監視（落ちたら通知）。
開発のしかた（実データを触らない）
- 普段はダミー（架空）データで開発・共有・デモ。個人情報ゼロなので取り扱いが自由。
- 実データは保護領域（認証付きAPIの後ろ）でだけ流す。開発PC・Git・静的ファイルに実データを置かない。
- 分析画面は、氏名が不要なら出さない＝表示する個人情報を最小化する。
公開とドメイン
「他のPC・院外からも使う」ための公開方法と、ドメインが要るかどうかの整理です。いずれの方式でも患者データは自社サーバーに置いたままです。
公開の2方式
| Tailscale（社内VPN） | Cloudflare（インターネット公開＋玄関認証） | |
|---|---|---|
| 公開範囲 | 非公開。招待した端末だけが到達 | インターネット公開。ただし玄関で認証 |
| 利用者の準備 | 各自Tailscaleを導入＋招待 | URLを開く（玄関でGoogleログイン） |
| ドメイン | 不要 | 玄関（Access）を付けるなら必要 |
| 費用 | 無料（小規模） | ドメイン年$10〜15＋設定 |
| 向き | 院内の決まった人で使う | きれいなURLで広く配る／院外 |
安全さの考え方
安全さ ＝（誰が到達できるか）×（鍵の強さ） 「ログインがあるか」だけでは決まらない。到達できる相手を絞るか、鍵を十分強くするか、のどちらかが要る。
| 置き場所 | 誰が到達できる | 自作ID/パスだけで |
|---|---|---|
| インターネット公開（玄関なし） | 世界中の誰でも（botも） | 不十分（総当たり・脆弱性を直接突かれる） |
| Tailscale（社内VPN） | 招待した端末だけ | 十分OK |
ID/パス と Googleログイン
- Cloudflare Access のGoogleログインは、会社のGoogle Workspaceと同じログイン。＝今スプレッドシートを守っているのと同じ強さに揃う（巨大企業が鍛えた認証）。
- 自作ID/パスは、社内VPN（Tailscale）の中なら十分。インターネット公開のときだけ、Googleログイン（Access）に格上げするのが筋。
ドメインが要る／要らない
| やりたいこと | ドメイン |
|---|---|
| ファイルやアプリをただ載せる | 不要（提供元の無料サブドメインでOK） |
| そこにGoogleログインの玄関（Access）を付ける | 必要（自分が所有するドメインが要る） |
無料サブドメインは提供元の持ち物なので、自分の会社用の鍵（Access）を付けられない。鍵を付けるには“自分の建物（自分のドメイン）”が要る、という関係。
既存ドメイン と 専用ドメイン
- 既存ドメイン（メール・HP兼用）を使う：DNSをCloudflareへ移す必要がある。MX（メール）・HP・SPF等の引き継ぎを誤ると、メールやHPが止まる。実施は慎重に・管理者と一緒に。
- 専用ドメインを新規取得（年$10〜15）：メール・HPに一切触れない＝最も安全。取得直後から玄関設定に進める。
結論（推奨）
移行ロードマップ
1常駐サーバー化：自社マシンで自動起動＋自動バックアップ。費用ほぼゼロ・データは自社内。
2データAPI化＋ログイン：静的ファイルをやめ、認証後にAPIから取得（守りの本丸）。
3Web入力フォーム：元データを画面から入力 → Excel依存を段階的に廃止。
4必要なら公開／国内クラウドへ：院外からも安定運用。外部サービスは“玄関”役、データは管理下のまま（公開する場合は専用ドメイン＋Googleログイン）。