# データの流れと保存先

この資料は、かけあいが扱うデータを「認証・セッション」「画面・業務データ」「AI処理」「外部ファイル」の4経路に分け、入力から処理、永続保存までを示します。同じWebやPostgreSQLを経路ごとに繰り返しているため、図中の箱の数はcontainerやdatabase instanceの数を表しません。

[![認証・セッション、画面・業務データ、AI処理、外部ファイルの4行で構成されたデータフロー図。認証秘密はCloudflare D1、業務データとsessionとAI結果はPostgreSQLへ保存される。AI入力は最小化後にOpenAIへ送られ、外部ファイル本体は利用者が保管先から直接取得する。](05-data-flow.png)](05-data-flow.svg)

## 先に結論

- パスワードhash、OTP hash、reset grant、規約同意は認証D1へ保存します。目標、成果物、相談、監査、app session、AI jobとAI結果は業務PostgreSQLへ保存します。
- 一般利用者のブラウザはAuth WorkerやOpenAIを直接呼びません。かけあいWebがサーバー側からAuth Workerへ接続し、AI WorkerがOpenAIへ接続します。
- AI Workerは氏名のalias化と、メール、学生ID、電話番号、secretの置換を行ってからOpenAIへ送信します。Responses APIには`store:false`を指定します。
- アプリは外部ファイルのHTTPS URLとfilenameだけを保存します。ファイル本体のupload実装はなく、閲覧時はブラウザが外部保管先を直接開きます。

## 1. 認証・セッション

利用者がlogin、登録、resetの入力をかけあいWebへ送ると、Webはservice credentials付きHTTPS POSTでAuth Workerを呼びます。Auth Workerはcredential、OTP、reset grant、同意記録をD1へ保存し、OTPやreset通知をEmail bindingで送信します。

login成功後、Webはapp sessionを発行します。raw bearerはHttpOnly Cookieとしてブラウザへ返し、PostgreSQLにはSHA-256でhash化したtokenと、利用者・組織・role・有効期限を保存します。

## 2. 画面・業務データ

画面とsame-origin APIの通信はCloudflare Edge／Tunnelを経由してWebへ届きます。管理hostだけはCloudflare Access assertionを使い、一般利用者はapp session Cookieを使います。Webはrole、organization、owner、team membership、cycle、提出状態を検査してから、目標、成果物、相談、活動記録、監査をPostgreSQLへ保存します。

PostgreSQLは業務データとapp sessionの正本です。認証D1に保存するcredential類とは分離されています。

## 3. AI処理

productionのAI要求は、WebからPostgreSQLの永続command／jobへ投入されます。AI WorkerはreleaseVersionに対応するjobをclaimし、leaseを保持して処理します。

OpenAIへ送る前に、AI Workerは入力を最小化します。OpenAIから返った回答、usage、provider IDなどはWorkerが処理し、業務entityとsanitized telemetryをPostgreSQLへ反映します。OpenAI側の契約、保持、region、学習利用設定はリポジトリだけでは確認できません。

## 4. 外部ファイル

タスクの外部ファイルには、HTTPS URLとfilenameを登録します。WebはURL形式を検査し、PostgreSQLへ文字列として保存します。ファイル本体はかけあいへuploadされず、利用者がリンクを開いたときにブラウザから外部保管先へ直接通信します。

このため、外部ファイルのアクセス権、保持、削除、log、backupは、導入機関が選ぶ保管サービスの設定に依存します。

## 図の読み方

- 矢印は主要な送信・保存方向です。応答は同じ接続を戻るため省略しています。
- FLOW 1、3、4のブラウザとWeb間もCloudflare Edge／Tunnelを通ります。重複を避けるため、入口はFLOW 2だけに明示しています。
- 青緑は自社管理の処理・保存、紫はCloudflare管理、黄は外部サービス、白は利用者端末を示します。色だけに依存せず、境界名とノード名を併記しています。
- 図はproduction用設定と実装から確認できる論理経路です。実ホスト、provider管理画面、実データ、実通信は確認していません。

## 根拠

- app sessionのhash保存とCookie：`okr-cai-saas/src/lib/session.ts:43-46,86-104,232-242,250-317`、R016、R023
- Auth Worker呼出：`okr-cai-saas/src/app/api/auth/login/route.ts:27-58`（R039）、`okr-cai-saas/src/lib/auth-worker.ts:104-192,238-324,393-399`（R040）
- D1のcredential・同意：R025–R029
- Email binding：`okr-cai-auth-worker/src/password.ts:558-584`（R030）
- 業務データと認可：R002、R003、R015、R021、R022
- AI command／job：`okr-cai-saas/src/app/api/workflows/[sessionId]/messages/route.ts:67-168`（R038）、R018–R020
- AI入力最小化とOpenAI送信：R031–R034
- 外部ファイルURL：R035、R036

ノード、接続、根拠参照は[共通モデル](../architecture-model.json)、データ種別ごとの保持・削除条件は[構成根拠](../evidence.md)にまとめています。