Appearance
2026年9月1日 本番リリース準備計画
最終更新: 2026-08-19
1. 目的と日程
本番リリース目標を 2026年9月1日、本番相当環境での受入テストを 2026年8月30日 とする。前倒し検証は可能だが、8月30日の受入テストを省略せず、結果をGo/No-Go判定へ反映する。
| 日程 | 作業 | 完了条件 |
|---|---|---|
| 8/18-8/25 | 実装・API契約・ドキュメント差分の解消 | ビルド、単体テスト、API契約検査が再現可能である |
| 8/26-8/28 | 本番設定・Secret・署名鍵・配布設定の投入 | 本番値で設定検証が合格し、秘密値がリポジトリ・ログに出ない |
| 8/29 | 本番相当環境のスモークテスト | API、PWA、Facility、Management、Kioskの主要導線が確認できる |
| 8/30 | 本番受入テスト | 実アカウント、権限分離、同期、通知、ロールバックを含む記録がある |
| 8/31 | Go/No-Go、凍結、最終バックアップ | 承認者、対象版、manifest、checksum、復旧手順が確定している |
| 9/1 | 段階リリース | 監視下で段階展開し、問題時に直前版へ戻せる |
2. ドキュメントの責務
docs/: 施設・保護者・職員・管理者が日常運用で参照する利用者向け操作マニュアル。実装詳細、Secret、ビルド内部手順は置かない。docs-dev/: 開発者・保守担当者が参照する技術仕様、API契約、データベース、環境構築、ビルド、テスト、リリース判定資料。- ルートREADME: リポジトリ全体の入口。
docsとdocs-devの役割を説明し、各サブモジュールの正本へリンクする。 - 実装の挙動と文書が異なる場合は、コードと設定ファイルを確認したうえで、意図した仕様なら文書を更新し、意図しない差分ならコードを修正する。推測で仕様を補わない。
3. 配布対象
| コンポーネント | 本番の配布・運用形態 | 必須確認 |
|---|---|---|
| API | Cloudflare Workers（配布ファイルなし） | D1/KV/R2/Queue binding、Secret、migration、health |
| Management | Windows自己完結型デスクトップ | 本番設定、オフライン暗号化、同期、復旧 |
| Kiosk | Windows/Linuxバイナリ、Android APK | NFC/QR、オフライン打刻、同期、署名APK |
| Facility | Android APK（Capacitor） | 実APIログイン、児童名復号、dashboard、SSE、署名APK |
| Guardian | ブラウザPWA | ログイン、欠席・通知、PWA自動更新、実機ブラウザ |
| Staff | ブラウザPWA | ログイン、権限、シフト・業務機能、PWA自動更新、実機ブラウザ |
| Provider | ブラウザWebアプリ | 法人・施設管理、権限、監査、実API接続 |
Guardian と Staff はAPKを生成しない。スマートフォンではブラウザのPWAインストール機能を使用する。
4. リリース必須ゲート
API・セキュリティ
- [ ] 本番D1、KV (
KV_AUTH)、R2 (REPORTS_BUCKET)、Queue (EVENT_QUEUE) がproduction用に分離されている。 - [ ]
JWT_SECRET、token secrets、ENCRYPTION_KEY、FCM、LINE、Kiosk、Provider、更新署名のSecretを必要な環境へ登録している。 - [ ] Provider用の専用管理組織とadminを用意し、
PROVIDER_ADMIN_ORGANIZATION_IDを設定している。一般tenant adminのJWTでProvider全体管理APIへ入れない。 - [ ]
ALLOWED_ORIGINSが本番Originだけを許可し、localhost/demo/ワイルドカードを含まない。 - [ ]
/healthと/v1/health、未認証auth/me、Facility dashboard、SSEの応答を確認している。 - [ ] PBKDF2 API側の現行1,000回と、方針目標600,000回以上の差を解消または正式承認している。
- [ ]
app/api/scripts/verify-audit-log-chain.tsで監査ログのチェーン検証を実行し、同時書き込み時のissueがないことを確認している。
ID・データ移行
- [ ] 児童・保護者・職員IDが
種別 + 法人コード3 + 施設コード2 + 制限英数4の10文字で発行される。 - [ ] 制限英数は
ABCDEFGHJKMNPQRSTUVWXYZ23456789を使用し、I/L/O/0/1を除外する。 - [ ] 既存法人・施設コードの変更について、コードだけを変更する現行スクリプトを本番で実行しない。
- [ ] 既存IDを再発行するか、旧コードの互換エイリアスを実装するか、移行方式を承認している。
クライアント・配布
- [ ] Facilityは
VITE_DEMO_MODE=false、本番HTTPS API、更新署名公開鍵、Firebase実値を設定し、Guardian/StaffはVITE_DEMO_MODE=false、本番HTTPS API、Firebase実値を設定している。 - [ ] Facility/Kioskの本番APKが署名済み・非debuggableで、package ID、versionName、versionCodeが承認値と一致する。
- [ ] Guardian/StaffのPWA ZIPに秘密値、開発用設定、不要なsource mapが含まれない。
- [ ] 全成果物のrelease manifestとSHA-256 sidecarを保管している。
実機・外部サービス
- [ ] Facility/Kioskの対象Android端末、NFCリーダー、QR導線を確認している。
- [ ] Guardian/Staffを実機ブラウザで確認し、PWA自動更新（Service Worker）とキャッシュ破棄を検証している。
- [ ] FCM、LINE、FacilityのCloudflare更新配信、R2帳票、実APIログインを実環境のアカウントで確認している。
- [ ] DBバックアップ、Secretローテーション、障害時連絡先、ロールバック版を記録している。
5. 検証コマンド
直近のローカル検証結果は 2026年8月19日検証記録 を参照する。成功したデモビルドや静的検査は、本番設定・署名・実機・外部サービスの受入を意味しない。
powershell
# ローカルスタックのAPI・4フロントエンド・CORS・未認証契約
pwsh -ExecutionPolicy Bypass -File ./scripts/verify-local-stack.ps1
# API契約と依存関係
pwsh -ExecutionPolicy Bypass -File ./scripts/check-api-compatibility.ps1
pwsh -ExecutionPolicy Bypass -File ./scripts/run-dependency-check.ps1
# 本番候補の設定・成果物
pwsh -ExecutionPolicy Bypass -File ./scripts/verify-release-config.ps1 -App guardian -EnvFile app/Guardian/.env.production -RequireFirebase
pwsh -ExecutionPolicy Bypass -File ./scripts/build-release-artifacts.ps1 -Target all -Version 0.1.0 -VersionCode 1
pwsh -ExecutionPolicy Bypass -File ./scripts/verify-release-artifacts.ps1 -RequireManifestローカル検証の合格は、本番のSecret、署名鍵、外部サービス、実機、実アカウントの受入を代替しない。上記ゲートの未確認項目が残る場合は、9月1日リリースをNo-Goとする。
6. 既知の未完了事項
2026-08-18時点では、少なくとも次の事項を本番承認前に解消または明示的にリスク受入する。
- API側PBKDF2反復回数は1,000回で、開発方針の600,000回以上に達していない。
- 既存アカウントの法人・施設コード移行は、IDにコードを埋め込む仕様と互換性がないため、現行migration scriptをそのまま本番実行できない。
- Cloudflare、Firebase、LINE、署名鍵、NFC/QR、実機PWAの本番E2Eは、ローカルビルド成功だけでは証明できない。
- 管理ポータル・クライアント・APIの未コミット差分は、リリース対象版へ取り込む変更と作業中の変更を分離して確定する必要がある。
7. オーナー向け実行手順
具体的にプロジェクトオーナーが判断・準備・受入する項目は、本番リリースに向けてプロジェクトオーナーが進めること にまとめる。