未検証 — 次に確かめること
ヘルプナビを実際に載せるなら、ここが埋まらないと判断できません。
1. 社内限定をかけられるか（Cloudflare Access）
| 調べた内容 | 結果 |
|---|
| 無料プランのユーザー数 | 50ユーザーまで無料（＝認証を通る人の数） |
| ポリシー数 | 無料は5件まで |
| 監査ログ | 無料は保持30日 |
| 実装 | コード不要。管理画面の設定のみ |
| 使う側の準備 | Cloudflareアカウントは不要。メールが受け取れればよい |
使う側に何も用意させなくていいのが効きます。既定の One-time PIN 方式なら、
URLを開く → メールアドレスを入力 → 届いたコードを入力、で通過。
アカウント登録もパスワード設定も発生しません。
周知が「このURLを開いて、会社のメールアドレスを入れてください」の1行で済みます。
AWS案の Cognito はユーザープール作成・ユーザー登録が管理側に発生するので、ここは差が出ます。
1-2. かける場所で難易度が変わる
| 対象 | 手順 |
|---|
プレビュー（*.名前.pages.dev） | Pagesの「設定」内の Access policy から数クリック |
本番（名前.pages.dev） | Zero Trust側でApplicationを別途作成。ドメインの状態によっては通らない報告あり |
1-3. Googleログインには2種類ある（要注意）
| A. Google（generic） | B. Google Workspace |
|---|
| 準備 | 自分のGoogle Cloudプロジェクトで
OAuthクライアントを作る | 同じ ＋ Workspace管理者の承認 |
| 承認 | 不要（自分で完結） | 管理者でなければ依頼が必要 |
| 取得できる情報 | メールアドレス | ＋ Workspaceのグループ情報 |
| 触る対象 | 自分のGoogleアカウント | 会社の認証基盤 |
判断：当面は A（generic）でよい。
会社のWorkspaceアカウントもGoogleアカウントなので、A でログインできます。
そのうえでCloudflare側のポリシーに「メールアドレスが @会社ドメイン で終わる人だけ許可」と書けば、
実質「社内の人だけ」になります。
B が要るのはGoogleグループ単位で制御したいときだけ。
なお個人の練習用Cloudflareアカウントに、会社のGoogle Workspaceを認証基盤として紐づけるのは筋が悪いので、
B はヘルプナビでの採用が決まってから情シス経由で進めること。
1-4. generic Google の設定手順（未実施）
| 順 | 場所 | やること |
|---|
| 0 | Cloudflare | Zero Trustのチームドメインを確認（次の手順で使う） |
| 1 | Google Cloud Console | 新規プロジェクトを作る |
| 2 | 同上 | OAuth同意画面を設定 |
| 3 | 同上 | 認証情報 → OAuthクライアントID（ウェブアプリケーション） |
| 4 | 同上 | 承認済みリダイレクトURIに
https://<チーム名>.cloudflareaccess.com/cdn-cgi/access/callback |
| 5 | 同上 | クライアントID / シークレットをコピー |
| 6 | Cloudflare | Zero Trust → 設定 → 認証 → ログイン方法 → 新規追加 → Google |
| 7 | 同上 | 貼り付けて保存 → テストで疎通確認 |
2. 記録の保存先（Supabase）
| 調べた内容 | 結果 |
|---|
| DB容量 | 無料プランで 500MB（超えると読み取り専用） |
| 月間アクティブユーザー | 50,000まで |
| プロジェクト数 | 1組織あたり2個まで |
| ⚠ 一時停止 | 7日間アクセスが無いとプロジェクトが停止する |
| 停止からの復旧 | 1年以内なら管理画面から復元可 |
7日間の非アクティブ停止が最大の論点です。ヘルプナビの記録は書き込み頻度が読めないため、
連休を挟んだだけで止まる可能性があります。本番で使うなら Pro プラン（停止なし・日次バックアップ）か、
定期的にアクセスを発生させる仕組みが要ります。
3. その他