Appearance
本番リリースに向けてプロジェクトオーナーが進めること
最終更新: 2026-08-18
1. この文書の目的
本番リリース目標を2026年9月1日、本番相当の受入テストを8月30日とした場合に、プロジェクトオーナー・運用責任者が自分で判断、準備、承認する事項をまとめる。
コード修正や自動テストは開発担当が進められるが、実際の法人・施設・利用者・端末・外部サービス・配布先を用意し、リリース可否を判断できるのは運用責任者である。ここにある未完了項目は、ローカルビルドが成功しても自動的には完了しない。
2. 最初に決めること（P0）
次の決定を、遅くとも8月20日までに記録する。決定がない項目は、実装を確定できずリリース判定を止める。
2.1 リリース範囲と責任者
- [ ] 9月1日に対象とするアプリを確定する。候補はAPI、Management、Kiosk、Facility、Guardian、Staff、Provider。
- [ ] 各アプリの承認者、テスト担当者、障害時の連絡先を1名以上決める。
- [ ] Managementのオフライン版を先行運用する既定方針を採用するか、変更する場合は理由と新しい順序を記録する。
- [ ] 9月1日に全施設へ展開するか、1施設または数施設で段階展開するかを決める。初回は段階展開を推奨する。
- [ ] リリース対象版、versionName、versionCode、配布対象、ロールバック対象版を承認する。
2.2 セキュリティ方針の承認
- [ ] API側PBKDF2の現行1,000回を600,000回以上へ引き上げるか、現行値を一時的に認めるリスク受入を行う。
- [ ] 推奨は、600,000回以上へ引き上げ、ログイン・初期登録・大量デモシードの性能をステージングで測定すること。
- [ ] 現行のデモ用
$demo$パスワードを本番データへ使用しないことを確認する。 - [ ] Secret、秘密鍵、初期パスワード、実児童情報をチャット、Issue、Git、ログへ貼り付けない運用を承認する。
2.3 ID・既存データ移行方針の承認
- [ ] 新規IDが
C/P/S + 法人コード3 + 施設コード2 + 制限英数4の10文字で発行されることを承認する。 - [ ] 制限英数が
ABCDEFGHJKMNPQRSTUVWXYZ23456789であることを確認する。 - [ ] 現行の
npm run db:migrate:account-codesを本番へ実行しない。 - [ ] 既存利用者を新IDへ再発行するか、旧コードを認証時だけ許可する互換エイリアスを実装するか決める。
- [ ] IDを変更する場合、ログインIDをソルトに使うパスワードの再設定・再通知・旧ID無効化の手順を承認する。
- [ ] 移行対象、移行日時、バックアップ、照合方法、ロールバック方法、利用者への通知文を決める。
3. あなたが準備する実データと運用情報
3.1 法人・施設マスタ
- [ ] 本番の法人一覧、正式名称、担当者、連絡先を確定する。
- [ ] 各施設の正式名称、住所、電話番号、定員、開所日、緯度経度、タイムゾーンを確定する。
- [ ] 法人コード3文字、施設コード2文字を割り当て、重複と誤読文字を確認する。
- [ ] 施設ごとの利用開始日、休所日、延長時間、送迎・お迎えルールを登録する。
- [ ] 本番とステージング、デモの法人・施設コードを混在させない。
3.2 利用者アカウント
- [ ] 職員ごとの氏名、所属施設、ロール、権限、連絡先を確定する。
- [ ] 児童ごとの氏名、カナ、所属施設、入所日、学校、保護者紐付けを確認する。
- [ ] 保護者と児童の紐付け、通知先、緊急連絡先を確認する。
- [ ] 初期パスワードを安全な経路で個別配布し、初回ログイン後の変更を必須にする。
- [ ] Guardianは企業コード入力を求めず、法人コードを含む保護者IDだけでログインできることを利用者案内へ反映する。
- [ ] 退職者、退所児童、無効アカウントの扱いと無効化日を決める。
3.3 端末・機材
- [ ] Facility APKをインストールするAndroid端末、OS、端末番号、利用施設を台帳化する。
- [ ] KioskのWindows/Linux/Android端末、端末識別子、設置場所を台帳化する。
- [ ] NFCを使用する場合、PaSoRiまたは内蔵NFCの型番、ドライバ、接続方法を確定する。
- [ ] NFCカード、QRコード、打刻対象の児童・職員を用意する。
- [ ] 端末の日時、タイムゾーン、ネットワーク復旧、オフライン継続時間を確認する。
- [ ] 予備端末、交換手順、故障時の紙運用または代替打刻手順を用意する。
4. あなたが用意する外部サービスと本番設定
秘密値そのものは共有せず、設定済みであることだけを確認する。
4.1 Cloudflare / API
- [ ] 本番Worker、staging Worker、カスタムドメイン、DNSを確定する。
- [ ] productionとstagingのD1、KV (
KV_AUTH)、R2 (REPORTS_BUCKET)、Queue (EVENT_QUEUE)を分離する。 - [ ]
JWT_SECRET、ACCESS_TOKEN_SECRET、REFRESH_TOKEN_SECRET、ENCRYPTION_KEYをSecret管理へ登録する。 - [ ] 必要な機能に応じてFCM、LINE、Provider、Kiosk、QR、更新署名のSecretを登録する。
- [ ]
ALLOWED_ORIGINSへ本番のGuardian、Staff、Facility、ProviderのOriginだけを登録する。 - [ ] 本番D1 migrationの適用担当、バックアップ取得方法、復旧方法を確定する。
- [ ]
/health、/v1/health、Cloudflareログ、アラート、利用量・エラー監視を確認する。 - [ ] D1の
AuditLogをJSONへ出力し、npx tsx scripts/verify-audit-log-chain.ts --file audit-logs.jsonがok: trueになることを確認する。
4.2 Firebase / FCM
- [ ] 本番Firebaseプロジェクトとstaging/demoプロジェクトを分離する。
- [ ] Guardian/Staff/Facilityで使用するFirebase Web設定とVAPIDキーを本番環境ファイルへ設定する。
- [ ] API側のFCMサービスアカウントをSecretとして設定する。
- [ ] 実機へ通知を送信し、施設・児童・保護者の対象を誤らないことを確認する。
- [ ] サービスアカウントの権限を必要最小限にし、JSONをGitやチャットへ保存しない。
4.3 LINE、更新配信、署名
- [ ] LINE連携を使う場合、channel ID、channel secret、access token、Webhook URLを確定する。
- [ ] 更新マニフェストの署名鍵、鍵ID、公開鍵、ローテーション手順を確定する。
- [ ] Facilityの更新URLとAPIの
UPDATE_BASE_URLが同じ運用方針であることを確認する。 - [ ] Facility/Kiosk Androidの本番keystore、alias、パスワードの保管場所と担当者を決める。
- [ ] Guardian/StaffはAPKを作らず、PWAホスティング、HTTPS、Service Worker更新方法を確定する。
5. 8月30日にあなたが立ち会う受入テスト
テストは本番相当環境、承認済みのテストアカウント、承認済みの端末で実施する。各項目に「実施者、日時、環境、対象バージョン、結果、証跡、課題番号」を残す。
5.1 API・認証
- [ ] 正しいID・パスワードでGuardian、Staff、Facility、Providerへログインできる。
- [ ] 誤パスワード、無効ID、期限切れアクセストークン、無効リフレッシュトークンが適切な401/403になる。
- [ ] 未認証の
auth/meが401であり、404や500にならない。 - [ ] ログアウト後に保護APIへアクセスできない。
- [ ] Guardianは法人コード入力なしでログインできる。
- [ ] Staff、Guardian、Facility、Providerのロール境界を越えてデータを取得できない。
5.2 Facility APK
- [ ] 本番APKの署名、package ID、versionName、versionCode、非debuggableを確認する。
- [ ] ログイン後、ホーム、dashboard、児童一覧で児童名が正しく復号・表示される。
- [ ] 出席、入退室、日報、事故報告、通知の主要導線を実データに近いテストデータで確認する。
- [ ]
/v1/facility/events/streamが404にならず、権限なしでは401になる。 - [ ] オフライン入力、復旧後同期、重複送信防止、失敗データの再送を確認する。
5.3 Guardian PWA
- [ ] Android/iOSの実機ブラウザでログイン、ホーム画面追加、再起動後の更新を確認する。
- [ ] 欠席・遅刻・お迎え連絡を送信し、施設側へ反映される。
- [ ] 児童情報、通知、既読状態、ログアウト、パスワード変更を確認する。
- [ ] 古いService Workerやキャッシュが新バージョンを妨げない。
5.4 Staff PWA
- [ ] 実機ブラウザでログイン、PWA更新、再ログインを確認する。
- [ ] 自分の所属施設だけが表示され、シフト、業務連絡、マニュアルが利用できる。
- [ ] 権限のない管理操作が拒否される。
- [ ] 「新しいバージョンが利用可能です」の表示が、更新成功後に適切に消える。
5.5 Management
- [ ] Windows自己完結型成果物をクリーンな端末または検証環境へ配置できる。
- [ ] オフラインで児童・保護者・職員・施設データを参照・編集できる。
- [ ] 再起動後も暗号化されたローカルデータを復号できる。
- [ ] オンライン復帰後の同期、競合、失敗再試行、バックアップ・復元を確認する。
- [ ] 補助金、請求、監査、権限設定の主要操作を確認する。
5.6 Kiosk
- [ ] Windows/Linux/Androidの対象成果物を起動できる。
- [ ] NFCとQRの入退室、職員打刻、誤入力、未登録カードを確認する。
- [ ] オフライン打刻、端末保存、復旧後のFIFO同期、重複防止を確認する。
- [ ] 端末再起動、日時ずれ、ネットワーク断、API障害時の表示を確認する。
5.7 Provider
- [ ] 法人・施設作成時に法人コード3文字、施設コード2文字が発行される。
- [ ] 職員・児童・保護者の新規発行IDが10文字の仕様に一致する。
- [ ] ID衝突時に再生成され、既存アカウントを上書きしない。
- [ ] 法人管理者が他法人の施設・利用者・監査データを閲覧できない。
5.8 通知・外部連携
- [ ] FCM通知が正しい保護者・端末へ届く。
- [ ] LINE連携を使う場合、Webhook署名と対象施設の紐付けを確認する。
- [ ] 帳票をR2へ保存・取得でき、権限のない利用者が取得できない。
- [ ] 更新確認と署名検証が本番URLで成功する。
6. 合格証跡の残し方
各テストでは、次の情報を1行単位で残す。
| 項目 | 記録内容 |
|---|---|
| Test ID | API-AUTH-01など一意な番号 |
| 実施日時 | 日本時間、開始・終了 |
| 環境 | production-like、staging、端末名 |
| 版 | API・PWA・APK・Managementの版数 |
| アカウント | 実IDではなくマスキング値 |
| 期待結果 | HTTPコード、画面、通知、同期状態 |
| 実結果 | 実際に確認した内容 |
| 証跡 | ログ・スクリーンショット・manifest・checksumの保存先 |
| 判定 | PASS / FAIL / BLOCKED |
| 課題 | 課題番号、担当者、期限 |
児童氏名、電話番号、メールアドレス、Secret、token、keystore情報は証跡へ直接記録しない。必要な場合はマスキングまたはテスト用ダミー値を使用する。
7. Go / No-Go判定
Goの最低条件
- [ ] P0の方針決定がすべて記録済み。
- [ ] 本番環境とstaging環境の設定・Secret・DBが分離済み。
- [ ] 8月30日の必須受入テストにFAILまたは未確認がない。
- [ ] 本番成果物、manifest、SHA-256、署名、ロールバック版が一致する。
- [ ] バックアップ、監視、連絡網、障害時の停止・復旧手順が利用可能。
No-Go条件
次のいずれかが残る場合は、9月1日の全体展開を延期するか、対象機能を明示的に外す。
- [ ] PBKDF2の未承認、または重大な認証・権限問題。
- [ ] 既存ID移行方式が未決定、または所属スコープを保証できない。
- [ ] 本番Secret、署名、DB、FCM、実機のいずれかが未確認。
- [ ] 児童名の復号不良、同期欠損、重複打刻、他施設データ漏洩。
- [ ] ロールバック版またはDBバックアップから復旧できない。
8. 日程別の実行順
| 期限 | あなたが行うこと | 完了の証拠 |
|---|---|---|
| 8/20 | リリース範囲、責任者、PBKDF2、ID移行方式を決定 | 承認記録 |
| 8/22 | 法人・施設・利用者・端末・外部サービス台帳を確定 | 台帳、設定一覧 |
| 8/25 | stagingへ実データ相当の匿名テストデータを投入 | データ照合結果 |
| 8/28 | 本番Secret・署名・ドメイン・バックアップ・監視を確認 | 設定チェックリスト |
| 8/29 | 本番相当スモークテストに立ち会う | スモークテスト結果 |
| 8/30 | 全受入テストを実施し、FAILを分類する | 受入試験記録 |
| 8/31 | Go/No-Go、版凍結、最終バックアップを承認 | 判定記録、manifest |
| 9/1 | 段階リリース、監視、問題時の停止判断 | 展開記録、監視ログ |
9. 開発側へ依頼する事項
あなたが判断を終えたら、開発側へ次を依頼する。
- 承認済みのPBKDF2方針を実装し、ログイン性能と既存ハッシュ移行を検証する。
- 承認済みのID移行方式を実装し、バックアップ・再発行・ロールバックを自動化する。
- 監査ログの全件検証ツールと同時書き込みテストを追加する。
- 受入テストで見つかった不具合を、再現手順・原因・修正・再テスト結果付きでクローズする。
- 本番候補をクリーンな環境でビルドし、manifest、checksum、署名、設定検査を提出する。
docs/の利用者向け手順とdocs-dev/の技術手順に差分がない状態を保つ。
10. すぐに着手する10項目
- 9月1日の対象アプリと段階展開対象を確定する。
- 8月30日のテスト責任者と参加者を確定する。
- PBKDF2 600,000回以上への引き上げ方針を決める。
- 既存ID・法人コードの移行方式を決める。
- 本番法人・施設一覧とコード候補を確定する。
- 本番ユーザー・児童・保護者台帳を匿名化せず安全な管理場所で整備する。
- Facility/Kioskの実機、NFC、QR、予備機を確保する。
- Cloudflare、Firebase、LINE、更新署名、Android署名の担当者を決める。
- ロールバック版、DBバックアップ、障害連絡網を準備する。
- このチェックリストの各項目に担当者と期限を割り当てる。