JACPA スクールアプリ 設計提案（v0.1 / 8-3 MTG 用ドラフト）

作成: 2026-07-24 ／ 根拠: 既存システム調査 5軸（NotebookLM 25ソース）

0. 一言サマリー

「危険物（カード情報・顔写真）は自社に持たず外部の専門SaaSへ。保護者にとっては継ぎ目のない“1つのアプリ”で、体験から写真購入まで完結する。」

会員基盤（コア）は自社でクラウドネイティブに構築し、決済＝GMOイプシロン、写真販売＝フォトクリエイト（スナップスナップ） を疎結合で連携する ハイブリッド構成。これが機能・スケール・セキュリティ・UX・コストの5軸すべてで最適。

1. 背景と狙い

• JACPA は課外スクール会員 3万人+。現状、体験申込はWebフォーム＋自動メールのみで、会員向けマイページ/アプリが無い。
• 体験→入会→在籍→連絡→物販→写真が バラバラ／紙・電話・現金 で運用され、本部・支部・現場に事務負荷。
• 狙い: ①体験の入会転換率UP ②事務コスト削減（電話・集金ゼロ化）③保護者満足（1アプリ完結）④新収益（EC・写真レベニューシェア）。

2. 対象ユーザーと主要ジョブ

組織階層(現行フローより): 本部/TISG ↔ 事業部(スポーツ・英会話) ↔ 支部 ↔ 指導員/外国人講師/コミュニケーター ↔ 園 ↔ 保護者。TISG=英会話統括と推定(要確認)。

2.5 事業ライン（体育と英会話は別事業）※オーナー指示で必須考慮

• スポーツ事業: 体育/サッカー/新体操/剣道/スイミング/チア/キッズダンス。日本人指導員。
• 英会話事業: 外国人講師＋コミュニケーター、英会話事業部＋TISG統括。固有業務=テキストブック発注(入会数予測)、正課カリキュラム提出、講師評価、園行事参加交渉。
• 正課(園カリキュラム=BtoB)／課外(月謝スクール=BtoBtoC) の二層を両事業が持つ。会員3万人は課外中心。
• 設計要件: データモデルに 事業(スポーツ/英会話) × 区分(正課/課外) の軸を通し、講師種別(日本人/外国人)・英会話固有オブジェクトを扱えること。UIは事業で切り替え。
• 現行Sgrumの守備範囲=課外の保護者向け(体験フォロー/欠席QR/イベント/一斉配信/満足度)。新アプリの主戦場=未システム化の「園連携・正課・スケジュール調整」（会員/体験リストの園提出、クラス編成、正課カリキュラム提出、夏季/年間スケジュール作成）と、属人リレーの自動化（外国人講師病欠・欠席連絡の役割ベース自動ルーティング）。詳細は 現行業務フロー分析。

2.6 チャネル方針（体験＝Web ／ 入会・会員＝アプリ）※オーナー

• 体験申込＝Webフォーム（アプリ不要）。見込み客の摩擦を最小化。募集プリントのQR/リンクから直接申込 → 確認メール（現行踏襲）。→ 別モック「Web体験フォーム」。
• 入会時にアプリを取得し、その場で決済（GMOイプシロン）。以降の会員管理・保護者連絡・出欠・写真案内・ショップはアプリ。
• フォロー導線: 体験段階はまだアプリ未取得 → メール（§3.5 の管理画面↔メール）。入会後はアプリ内メッセージへ引き継ぎ。

3. スコープ（領域）と MVP 優先度

1. 体験管理（申込ファネル・体験当日・フォロー・入会転換・体験者との双方向メッセージ↔メール）… ★MVP
2. 入会管理（申込→在籍→決済登録→クラス配属）… ★MVP
3. 会員管理（会員/保護者/きょうだい/クラス/在籍・休会・退会、事業×正課/課外）… ★MVP
4. 保護者連絡（一斉/個別/出欠/欠席/既読・プッシュ通知＋メール）… ★MVP
5. 園連携・運営事務（会員/体験リストの園提出、募集プリント、スケジュール調整、正課カリキュラム提出、役割ベース自動ルーティング）… ★MVP相当（現行の最大の痛点・Sgrum未対応）
6. 英会話固有（外国人講師管理・病欠ルーティング、テキスト発注、講師/生徒評価）… Phase2
7. EC ショップ（倉庫連携・管理画面連動）（ユニフォーム・用品。保護者アプリで購入→イプシロン決済、全国の複数倉庫の在庫連携＋商品別の発送元ルーティング＝マルチ倉庫フルフィルメント、管理画面で商品・在庫・注文・出荷を一元管理）… 運営ダッシュボードと連動して構築。※送料表・倉庫の実所在・配送業者連携等の運用パラメータは要ヒアリング
8. 写真販売の案内（写真イベントごとにスナップスナップURLを設置→保護者へ案内・送客。JACPA側で連携保有・API不要の軽量実装）… Phase2
9. 季節イベント・合宿（キャンプ/スキー/サッカー合宿。内部＝アプリ先行公開・外部＝Web、定員共有で連動、参加者・収支管理）… Phase2
10. 指導者管理（約300名）（登録・所属・資格/種目・担当割当・稼働・評価・委託先講師の区別、本部/支部の指導者管理画面）… ★MVP相当（運営の要）

3.1 定員・残枠と体験ページの連動 ※オーナー要望

• 定員は 施設 × 種目/コース × クラス（曜日・時間）単位で設定（事務局が管理画面で設定）。
• 残枠 ＝ 定員 − 在籍 − 体験予約（一時確保を含む）。体験申込ページ（Web）と会員アプリの両方で、対象クラスに 「あと○名」 を表示。
• 満員時は申込不可（締切表示）＋キャンセル待ち登録を選択可。空きが出たら繰上げ通知。
• 同時申込の競合（残1に複数申込）は、EC在庫引当と同様に予約の一時確保→確定/失効で二重予約を防止。
• 管理画面/ダッシュボードで残枠・充足率を可視化（募集強化・増枠・別枠開設の判断に）。

3.2 年度更新（進級・再配属）※オーナー要望

• 年度（fiscal_year）を軸に在籍を管理。年度切替で全会員の学年が上がり、進級に伴ってコース・曜日・時間が変わることがある（例: 年長→小1でコース・時間帯変更）。
• 次年度クラス編成: 学年変更に応じて対象コース/枠を再割当。事務局が下書きで編成 → 一斉適用（現行フローの「クラス編成★」＝最大の痛点をシステム化）。
• 継続意向の確認: 更新時に継続/変更/休会/退会の意向を保護者から回収（アプリ/Web/メール）、未回答をフォロー。
• 料金改定・テキスト連動: 年度で入会金/月謝/テキストが変わる場合に対応。次年度入会数予測 →（英会話）テキスト発注と連動。
• 履歴保持: 年度ごとの在籍・クラス・料金をスナップショットで残す（経営分析・監査）。過去年度は改変不可。
• 設計注意（Fable5評価）: enrollments/classes に fiscal_year を最初から通す（後付けは移行やり直しになる最重要ポイント）。

3.3 全データCSVエクスポート（統制付き）※オーナー要望

• 会員・体験・在籍・注文・出欠・請求・イベント参加者・経営指標など、各画面から全情報をCSV出力可能に。
• ただし個人情報を含むため 出力は統制とセット: 本部/権限ロールに限定・理由必須・実行通知・監査ログ・大量出力の機械検知（§6.1）、個人情報を含む出力は暗号化/パスワード保護・ダウンロード期限。

3.4 体験申込フォームのUX（種目/コース・学年自動・直近枠提案）※オーナー要望

• 種目×コースを細かく定義: 種目（体育/サッカー/新体操/剣道/スイミング/チア/ダンス/英会話）ごとに年齢・レベル別のコースを持つ（例: サッカー＝幼児/低学年/高学年、英会話＝レベル別）。施設ごとに開講コースが異なる（施設マスタ×コースで管理）。
• 生年月日 → 学年 自動表示: 生年月日を入力すると学年を自動算出（4/2基準）。手入力の誤りを防ぐ。
• コース選択 → 直近の体験可能日時を提案: コース（＝クラスの曜日・時間）に基づき、今日以降の直近枠を残枠「あと○名」付きで提示（§3.1の定員・残枠と連動）。満員はキャンセル待ち。

3.5 体験者マイページ（Web・体験ID＋メール）と 入会フロー ※オーナー要望

体験申込後、体験者はアプリ不要のWebマイページでJACPAとやり取りし、入会/辞退まで進める。

• メール送信は体験フェーズの必須基盤: 体験申込の確認メール（体験ID記載）は必ず送信し、これがフロー全体の起点になる（以降の日程確定・リマインド・フォロー・辞退確認もメール）。送信基盤（専用サブドメイン＋SPF/DKIM/DMARC）をMVPのコア構成に含める（§6.1）。
• 体験IDの発行: 体験申込を受け付けると、上記の確認メールで体験IDを送付。体験者はメールアドレス＋体験IDでWebマイページにログイン（アプリ不要の軽量認証）。
• Webマイページでできること:
  1. 運営とメッセージ（Web上のスレッド。スタッフ投稿はメール通知も）
  2. 体験日の変更連絡
  3. 入会を希望する → アプリDLのご案内へ
  4. 入会しない連絡 → 理由アンケート（辞退理由を回収し、改善・再アプローチに活用）
• 入会フロー（Web → アプリの受け渡し）:
  1. 体験者が「入会希望」→ 2. 事務局が管理画面で 希望コース・入会金・月謝を設定 → 3. 体験者にアプリDL案内 → 4. アプリDL後、設定済みの内容を画面で確認して決済（GMOイプシロン） → 5. 入会完了と同時にアプリの会員機能が解禁。
• 状態遷移: 体験申込 → 体験実施 →〔入会希望 → 事務局が料金設定 → アプリ決済 → 入会完了〕/〔辞退 → アンケート〕。
• 運用/セキュリティ: 未返信・入会希望・辞退を管理画面で可視化（フォロー漏れ防止＝転換率）。体験IDは推測困難な値、メール＋IDのログインにレート制限、決済はアプリ側で非保持化。入会後はアプリ内メッセージへ引き継ぎ。

3.6 指導者管理（約300名）※オーナー要望

• 規模: 指導者 約300名（見込み）。日本人指導員＋英会話の外国人講師（委託先所属）。
• 指導者マスタ: 氏名・連絡先・所属支部・雇用形態（社員/業務委託）・担当事業（スポーツ/英会話）・資格/指導可能種目・稼働可能な曜日/エリア・状態（在籍/休止/退職）。外国人講師は委託先に紐付（PIIは委託先主管・最小参照＝§6.1）。
• 担当割当: 指導者 × クラス × 曜日 × 会場（巡回・複数園）。割当の俯瞰（曜日×会場のカバレッジ）・稼働率・未割当/欠員・代講の管理。
• 評価: 新人（6月）・通常（9月）の講師評価、園向け満足度調査と連動。
• 労務（Phase2）: 移動/交通費・レッスン別インセンティブ・勤怠。
• 画面: 本部/支部の指導者管理画面（300名の一覧・検索/フィルタ〈支部/事業/種目/雇用形態〉、担当状況、要フォロー＝未割当・評価待ち・資格期限）。指導者本人のスマホ画面（今日の担当・出欠）は既存の指導員アプリ。
• 権限: 本部＝全体、支部＝自支部の指導者、委託先＝自社講師のみ（最小権限）。

4. アーキテクチャ方針（ハイブリッド）

4.0 全体像（利用者3面 × 共通基盤 × ドメイン分離）※オーナー確認

利用者3面（フロント／画面）
 ①運営             ②指導者                ③会員
 本部/支部/事務局    指導員アプリ(本人)       保護者アプリ
 ＝管理画面群        ＋指導者管理(本部が管理)   ＋Web体験/体験者マイページ
        │                 │                     │
        └───── 会員IDを軸に疎結合連携 ────────────┘
                          │
   共通基盤: 認証 / 会員ID / 通知(プッシュ＋メール) / 監査ログ
                          │
   ドメインでバルクヘッド分離（§8.2：別Worker・別D1・疎結合）
   [体験] [会員・連絡] [出欠] [指導者] [EC(切離)] [経営]
                          │
   危険物は外部（統合しない）: [GMOイプシロン=決済] [フォトクリエイト=写真]

• 「運営／指導者／会員」の3面＝入口（画面）の分け方。使う人が違う3つのフロント。
• ただし "縦に積んだ3階層"ではない: 会員IDを軸にした共通基盤＋横並びのドメイン分離（UX統合≠バックエンド一枚岩・§8.2）。
• 指導者の二面性: 本部が管理する対象であり、同時に指導員アプリを使う主体。
• 権限: 本部→支部→現場の委譲（本部集中管理）、委託先は自社講師のみ（最小権限）。

[保護者アプリ (PWA/ネイティブ) ] [運営ダッシュボード (Web)]
            │ SSO/OIDC                    │
   ┌────────┴───────── API Gateway (WAF) ─┴────────┐
   │        自社コア (クラウドネイティブ)            │
   │  認証(Cognito/Auth0) │ 会員DB │ 予約・出欠      │
   │  連絡・通知(キュー非同期) │ 監査ログ             │
   └───┬──────────┬───────────────┬────────────────┘
       │ トークン  │ ディープリンク/SSO
   [GMOイプシロン] [フォトクリエイト]   [プッシュ通知 / メール]
    決済(非通過型)  写真販売(送客)        通知チャネル

• ガバナンス: 本部が全社を集中管理（全権）。支部・現場(指導員)・園・委託先は本部から委譲された最小権限ビューのみ。ダッシュボードは本部中心、支部以下はスコープ制限。
• メール送信（トランザクショナル）は MVP 必須コンポーネント: 体験確認メール（体験ID）を起点に、通知・リマインド・一斉配信までを担う。Cloudflare Email もしくは送信専用サービスを利用し、専用サブドメイン＋SPF/DKIM/DMARC で到達率と真正性を確保（§6.1）。inbound（返信取り込み）も体験スレッドに連動。
• テナントモデル: プールモデル＋テナント(支部/施設)分離。ノイジーネイバー対策にスロットリング。
• 信頼性: マルチAZ・自動バックアップ・機能バルクヘッド（写真/EC障害が連絡・出欠を巻き込まない）。
• スケール: ステートレス＋オートスケール、一斉通知・決済バッチは非同期キュー、画像はCDN。
• 候補スタック: Cloudflare(Workers/D1/R2/Queues/Access) もしくは AWS(ECS/Aurora/SQS/CloudFront/Cognito)。※ワークスペース資産的にはCloudflareに親和性。最終はPoCで確定。

5. データモデル（コア骨子）

• 本部 1─n 支部 1─n 施設(園/会場) 1─n クラス。各クラスは 事業(スポーツ/英会話) × 区分(正課/課外) × 種目/コース × 曜日 × 時間帯 を持つ。
  • 各クラスは 定員 を持ち、残枠＝定員−在籍−体験予約（一時確保含む）。fiscal_year(年度) を通す。
  • 施設マスタ＝提携園の全件。体験フォーム(jacpa.jp/tk)に載る提携園を初期マスタとして取り込む（別途 提携園一覧 に洗い出し中）。
• 会員 n─n クラス（在籍）は 年度別。年度更新で学年↑→進級に伴いコース/時間を再配属。年度ごとに在籍・クラス・料金をスナップショット保持（過去年度は改変不可）。
• 体験申込 1─1 体験スレッド（感想/アンケート回答＋メッセージ、体験者とはメールで送受信）。
• 保護者(アカウント) 1─n 会員(子ども) — きょうだいは1保護者にぶら下げ
• 会員 n─n クラス（在籍。状態=体験/在籍/休会/退会）
• 指導者マスタ（約300名）: 氏名/連絡先/所属支部/雇用形態(社員・委託先)/事業(スポーツ・英会話)/資格・指導種目/稼働曜日・エリア/状態(在籍/休止/退職)。外国人講師は委託先に紐付。
• 指導者/講師 n─n クラス（担当=講師×クラス×曜日×会場） — 指導者は曜日ごとに異なる会場へ行き複数園を担当する週次ローテーションを表現。外国人講師は 委託先(パートナー) に所属し、担当はコマ単位で割当。稼働率・未割当・代講を管理。
• 出欠: 指導員が当日クラスの名簿にスマホで記録（出席/欠席/振替）。保護者の事前欠席連絡と同一名簿で統合。
• 体験申込（施設・希望日時・保護者同席）→ 転換で 入会 → 決済登録(トークン参照のみ)
• お知らせ/個別連絡/振替/休講、写真イベント(送客ログ)、テキスト在庫/発注、評価表
• EC: 商品(SKU)、倉庫、在庫(倉庫×SKU)、注文─n注文明細、引当/出荷(発送元倉庫・分割出荷)、配送
• 分析/経営: 会員動態スナップショット(月次)、売上ファクト(月謝/EC/写真)、月次集計(事業別/支部別) — 運用DBと分離して時系列保持
• 重要: カード番号・写真実体は保存しない（トークン参照・外部URLのみ）。講師PIIは委託先が主管、JACPAは最小限参照。

6. セキュリティ設計（軸③直結・最優先）

• 子どもPII: アカウントは保護者(法定代理人)に紐付け、同意は保護者操作で取得。
• 決済: GMOイプシロンの非通過型（リダイレクト/トークン）で非保持化＋EMV 3-Dセキュア。自社DBにカード番号を持たない。
• 顔写真: 実体は自社に保持せずフォトクリエイト側。AI顔検索は「個人識別符号」に該当 → 利用目的明示＋保護者の個別同意を登録フローに組込む。
• 多層防御: WAF・脆弱性診断・海外IP制御・MFA・アカウントロック・最小権限＋監査ログ（*はいチーズ!フォト漏えい教訓＝カード非保持でも顧客DB防御は必須*）。
• 委託先管理: イプシロン/フォトクリエイト/クラウドの認証（PCI DSS/Pマーク/ISMS）を確認・契約明記。
• 英会話講師の業務委託先の監督（重要課題）: 外国人講師は委託先所属で、講師PII・休講連絡が委託先経由。→ (a)委託先を組織ノード/テナントとしてモデル化し、講師個人はJACPAが直接握らず最小限のPIIのみ参照。(b)講師/委託先に見せる生徒名簿も最小権限（担当クラスのみ・保護者連絡先は伏せる）。(c)休講連絡を役割ベースで自動ルーティング（起点=講師 or 委託先窓口 → 支部/園/保護者へ即時配信、委託先にも通知）で属人リレーを排除。(d)委託先アクセスは監査ログ記録、委託契約に安全管理措置を明記（法25条 委託先の監督）。
• インシデント対応: 遮断手順＋速報＋確報60日＋本人通知の体制を初期から明文化。

6.1 実装前に凍結する必須統制（Fable5 評価反映 / 評価レポート 参照）

• 体験ID認証の具体仕様: 体験ID＝128bit相当ランダム、メール＋IDの二点照合、IP/メール/IDの3軸レート制限＋ロック、状態連動失効（入会/辞退/90日）、応答の非差別化（存在有無を漏らさない）、成功時のみ短命セッション。決済系操作はマイページから到達不可（アプリ側のみ）。
• 決済オーケストレーション: 金額・状態はサーバ側の値のみを正、webhook署名検証＋送信元制限＋イベントID一意で冪等化、入会解禁トリガーはwebhookのみ（アプリ戻り画面を信用しない）、二重決済防止。
• 名寄せ（体験Web→会員アプリ）: メールOTP＋体験IDから導出した署名付き引継ぎコードの二点一致でのみ連結。保護者の確認ステップ＋事務局の手動マージ画面（監査付き）。
• 管理画面の防御: 名簿に触れる全職員MFA必須、管理画面自体をZero Trust（Cloudflare Access等）で公開面から隠す、全件エクスポートは本部特定ロール＋理由必須＋実行通知、閲覧/エクスポートを監査ログ対象化し大量閲覧を機械検知。
• 監査ログ: append-only・別ストア、閲覧イベントも記録、保持期間・月次レビュー運用を定義。
• CSVエクスポート（全データ）: 全情報をCSV出力可能にしつつ、上記のエクスポート統制（本部/権限ロール・理由必須・実行通知・監査・大量出力検知）＋個人情報を含む出力は暗号化/パスワード保護・ダウンロード期限を必須化。
• データ保持・削除／同意: 退会者/辞退者/各ログの保持期限と削除（消去請求）対応を定義。同意は版管理・撤回を持ち、配信時に毎回参照（写真案内は同意者のみ）。
• フォトクリURL案内の防御: 登録URLは許可ドメイン検証（snapsnap系のみ）、変更の監査ログ、広域配信は第二者承認、配信文面にドメイン表示（乗っ取り時のフィッシング配信を防ぐ）。
• メール基盤: 専用サブドメイン＋SPF/DKIM/DMARC、inboundはスレッド別トークン＋送信元二重照合（From偽装のスレッド混入を防ぐ）、一斉配信の第二者承認。
• NFRの数値化: SLO/RPO/RTO を数字で（例: 出欠・連絡 99.9%・p95 500ms、緊急配信 5分以内、RTO 4h）。リストア演習・年度替わり10倍の負荷試験合格基準。

6.2 漏えいインシデントの教訓と「非保持で消せる vs 自社で守る」の切り分け

根拠: セキュリティ障害分析。実事例＝ベネッセ2014（委託先内部不正で3,504万件）／はいチーズ!フォト2026（送客先SaaSへの不正アクセス）／NTTビジネスソリューションズ2023（元派遣者が928万件をUSB持出）／国内EC不正利用2024＝約555億円（大半がカード番号盗用・通過型に集中）。

• 非保持で"消せる"リスク（最も危険だが外部に出せる実体）: カード番号DB流出／決済ページのWebスキミング／PCI DSS準拠負担／顔写真の総当たり流出／顔特徴量の管理責任 → イプシロン非通過型＋写真フォトクリエイトで構造的に消す。
• 非保持でも"残る＝自社で守る"リスク（本丸）: 名簿（氏名/住所/電話/子の生年月日）の一括流出・認可欠陥（BOLA/IDOR）・アカウント乗っ取り・内部不正・委託先経由・設定ミス。→ ここに資源集中: エクスポート最小化＋理由＋通知＋監査／org_scope強制＋所有者サーバ検証＋不透明ID／全職員MFA＋管理画面Access／append-only監査ログ／委託先の専用API隔離＋DTOで連絡先遮断。
• 要点: 「危険物は外部の専門家へ、残る本丸（名簿・認可・内部不正）にこそ設計資源を集中」。§17の予算はこの本丸を守るために使う。

7. 写真販売の案内（フォトクリエイト＝JACPA側で関係保有）

• 前提更新（オーナー）: フォトクリエイトとの関係はJACPA側で既に保有。アプリに深いAPI/SSO開発は不要。
• 必要な機能＝URLの設置・案内のみ: 本部/支部が写真イベントごとにスナップスナップの公開URLを登録 → 保護者アプリに「写真が公開されました」案内カードを表示し、ボタンからそのURLへ送客（＝モック画面6の「スナップスナップで見る」）。
• 販売・集金・配送・顔検索はフォトクリエイト側。写真実体・カード情報はJACPAに保存しない（軸③と整合）。
• 実装は軽量（URL管理＋案内配信）。将来より深い連携が必要になれば別途検討。

7.4 季節イベント・合宿（内部＝アプリ先行 / 外部＝Web・連動）※オーナー要望

• 対象: 夏・冬のキャンプ、スキー教室、サッカー合宿等。外部と内部が合同で参加。
• 内部（在籍会員）＝アプリから申込（会員情報を流用してラク）。内部先行公開（先に案内し優先枠・優待＝在籍メリットを享受）。内部がWebで手入力する手間をなくす。
• 外部（非会員）＝Webの募集・申込ページから申込（フォーム記入＋イプシロン決済）。
• 連動: 同一イベントの定員を内部＋外部で共有、申込・入金・参加者名簿を一元管理。公開ウィンドウ（内部先行 → 一般/外部公開）を管理画面で設定。
• 管理画面: イベント作成（日程/定員/料金/対象/持ち物/公開設定）、申込状況（内部/外部別・残枠）、参加者名簿・緊急連絡先、収支。イベント売上は経営ダッシュボード/月次レポートに計上。
• 決済: 内部＝アプリ、外部＝Web、いずれもイプシロン（カード非保持）。

7.5 ECショップ（倉庫連携・管理画面連動）※オーナー要望

方式（更新 2026-07-28・再検討中／独自フルスクラッチは縮小） 当初は「独自フルスクラッチ＋イプシロン直結」で確定していたが、軍神(Gemini)が"個人開発で独自フル構築は最大の地雷源"と反対し、SaaSのバックエンドを裏面採用（ヘッドレス）する条件を提示（軍神レビュー-Gemini本体）。 - オーナー案＝MakeShop（byGMO）が第一候補: GMOイプシロン系決済の契約で運用でき、かつECの作り込み（在庫/注文/配送）をSaaSに逃がせるため、Geminiの"作り込まない"条件と我々の"イプシロン"要件を両立しうる（Shopifyはイプシロン直結不可なので優位）。 - ECはPhase2（両軍神ともMVP外で一致）。着手前に検証: ①MakeShopのAPI/ヘッドレス可否（アプリ内UX統合の度合い）②マルチ倉庫の発送元自動振分・分割出荷の対応可否（非対応なら"低SKU用品の単純発送"へ要件を緩める）③イプシロン系決済の実装。 - 月謝の継続課金＝イプシロン直結は別途維持（B＝金流）。SaaS型でもBASE/STORES（外部決済不可）は引き続き不採用。根拠: EC構築方式。 - ECは独自構築でも"必ず切り離す"（オーナー指示 2026-07-28）: 方式（MakeShop / 独自）に関わらず、EC を会員・連絡・出欠の基幹とは別ドメイン（別Worker・別D1・別デプロイ・疎結合）にし、ECの障害・改修・攻撃・負荷が基幹に波及しないようにする（§8.2 バルクヘッド）。連携は会員IDと最小リードモデルの非同期レプリのみ。決済（イプシロン）・写真も外部のまま。EC を"最初から切り離す"ことで、後日 MakeShop⇄独自 の載せ替えも局所化できる。 ※以下 §7.5 本文は"独自構築案"の詳細（在庫/倉庫/決済の考え方の参考）。MakeShop採用時は在庫・注文・配送・決済はMakeShop側が担い、自社はフロント統合と会員連携に集中する。

• 購入導線: 保護者アプリのショップで購入 → イプシロン決済（非保持化）。注文は会員IDに紐付く。
• 倉庫連携（マルチ倉庫フルフィルメント）: 商品(SKU) × 倉庫 の在庫を管理。注文時に発送元倉庫を自動選定（在庫あり・最寄り・送料最小）。商品ごとに発送元が異なるため分割出荷に対応。欠品アラート・補充。
• 管理画面連動: 本部/支部の権限で商品・在庫・注文・出荷を一元管理し、運営ダッシュボードと同じ画面群に統合。出荷ステータス・引当倉庫を可視化。
• 要ヒアリング/将来: 送料表・倉庫の実所在・配送業者API連携。将来は外部WMS/フルフィルメント委託も選択肢（その場合も在庫・注文の真実は自社に残す）。

7.6 経営データ・分析・月次レポート ※オーナー要望（月次レポートはマスト）

• 経営データの蓄積: 運用データ（会員動態・請求/入金・EC・写真送客）を分析基盤に集約し、時系列で残す（締め日スナップショットで履歴保持）。
• 経営ダッシュボード（本部）: 経営指標を一目で。会員数推移／純増（入会−退会）／体験→入会転換率／チャーン率／月次売上内訳（月謝・EC・写真レベニュー）／未収金／事業別（スポーツ/英会話）・支部別／前年同月比／LTV。
• 月次レポート（マスト）: 毎月自動生成（画面＋PDF）。主要KPIと前月比・前年同月比、事業別・支部別内訳、コメント欄。本部が締め後すぐ確認できる。
• 実装方針: 運用DBと分離した集計（読み取りレプリカ or バッチETL→集計テーブル）。会計連携（freee/MF等）は将来オプション。個人単位の分析は最小権限＋匿名化を検討。

8. スケール／コスト戦略

• ID課金SaaS（99〜120円/人）は3万人で年3,500〜4,300万円規模 → ハイブリッド自社コアで従量課金の壁を回避。
• 決済はイプシロン。手数料は 3.5% を前提として試算・記載する。
• 決済手段: 基本はクレジットカード または コンビニ決済。手段は追加できる形（PayPay・口座振替等）だが、手数料は手段によって異なる（3.5%は基本手段の前提値）。物販ECはPhase2で最小構成。
• 写真はレベニューシェアでコスト→収益に反転。

8.1 障害モードと回避策（信頼性の死守ライン）※オーナー指示

根拠: システム障害リスクと回避策（一斉アクセス集中）／障害モード分析-FMEA（全10カテゴリ・リスク登録簿22件）。実在の著名障害（Ticketmaster×Taylor Swift 2022／GitLab 2017／GitHub DDoS 2018／Fastly 2021／Cloudflare 2019／CrowdStrike／サーバレス青天井請求）を教訓化。

旧Sgrum型「雨の日13時に休講確認が殺到→アプリ停止」の再発防止（最重要）

• プッシュ先行: 本部/支部が休講を確定したら アプリのプッシュ通知＋メールで能動配信 → 「確認しに来る」アクセス総量を削減。
• 開催可否はエッジ配信・D1非依存: 会場×クラス単位の「本日の開催可否」を KVスナップショット＋CDNキャッシュ（cache everything＋stale-while-revalidate） で配信。3万人が同時に見てもエッジで捌き、オリジン(D1)は実質1回。※Ticketmasterの崩壊は"購入=書込"の殺到、JACPAの休講可否は"読み取り専用＝キャッシュ可"が構造的優位。
• リクエスト合体: CDNの cache lock で同時ミスを1本に collapse。
• バルクヘッド: 開催可否の経路を EC/写真/決済と別Workerに分離（重い機能の障害に巻き込まれない）。
• リトライstorm防止: 指数バックオフ＋full jitter＋回数上限、アプリのポーリングにジッタ、サーバ側Rate Limit。事前に「雨の日13時」シナリオで負荷試験。

全体の最優先回避策（FMEAトップ／複数の障害モードを横断で潰す）

1. 決済の冪等化＋状態機械＋日次リコンサイル（二重課金・未解禁を同時封殺）※§6.1と一体
2. 段階リリース＋即時rollback＋IaC/レビュー（自分の設定変更での全断＝最頻・最大リスクを防ぐ）
3. バックアップ＋リストア演習（Time Travel＋日次R2エクスポート＋四半期復元リハ／GitLab教訓）
4. Durable Objectで在庫・残枠を直列化＋UNIQUE制約（オーバーセル/二重予約を構造的に不能化）
5. 子どもPII/写真保護（署名付き短命URL＋会員認可＋体験ID不透明化＋個別送信）
6. 外部呼び出しにタイムアウト＋サーキットブレーカ＋バルクヘッド、通知は必ずQueues（依存ダウン/カスケード遮断）
7. セルフスロットル（送信量/API呼出/重処理の上限）＋予算アラート（コスト暴発・メールレピュテーション毀損を自前で止める）
8. 年度更新/一括処理はチャンク＋キュー＋冪等＋ドライラン＋スナップショット（3万人一斉更新の部分適用事故を防止）
9. 入口防御: WAF＋自動DDoS緩和＋Rate Limiting＋Turnstile＋管理画面Access
10. 土台に SLO/エラーバジェット（体験申込・決済・出欠・通知に可用性目標、超過でリリース凍結）＋外形監視（体験→決済→通知の合成実行）＋カオス/フェイルオーバー演習。

8.2 「全部を統合する」リスク（集約リスク）と分離設計 ※オーナー指摘

統合の狙いはUX（保護者の"ひとつの体験"）であって、バックエンドを一枚岩にすることではない。全機能を単一システム・単一DB・単一デプロイに詰め込むと、単一障害点・広い影響範囲（blast radius）・変更の危険・移行の一括リスクが生まれる（旧構成＝大塚商会＋Sgrum＋フォトクリ＋イプシロンは結果的に分散していた点を活かす）。

• UX統合 ≠ バックエンド一枚岩: フロントは"ひとつのアプリ"に見せつつ、バックは機能ドメインごとに分離（体験／会員・連絡／出欠／EC／経営）。
• バルクヘッド（障害分離）: ドメインごとに別Worker・別D1・別デプロイ。ECの障害が連絡・出欠を止めない。休講可否は最優先で独立経路（§8.1）。
• 危険物・重い実体は"あえて統合しない": 決済＝イプシロン、写真＝フォトクリエイトを外に出したまま（集約リスクとセキュリティを同時に下げる）。
• グレースフルデグラデーション: 一部ドメインが落ちても主要導線（体験申込・出欠・連絡・決済）は生存。UIウィジェットは独立失敗。
• 段階統合・並行運用: 全システムを一度に置換しない。ドメイン単位で移行し、現行（大塚商会）を一定期間並行させ失敗を局所化。
• データの分離とSSOT: 会員IDを軸に各ドメインが疎結合連携。単一DBを全機能の choke point にしない（D1容量・ホット競合＝FMEA #12と整合）。
• 分散トランザクションの正直なコスト（軍神Gemini指摘）: ドメイン分離は跨ぐ処理（例: 入会＝会員D1 ＋ 初期制服注文＝EC）でサーガパターン（補償トランザクション）を自前実装する必要があり、不整合時の手動修正コストを過小評価しない。跨ぐ処理は最小化し、必要な所だけサーガで。
• 会員リードモデルのレプリケーション（軍神Gemini指摘）: 出欠画面の氏名表示のため「出欠Worker」が毎回「会員Worker」を Service Bindings で同期呼びすると実質密結合＝カスケード障害。→ 会員の最小リードモデル（ID＋表示名程度）を各ドメインへ非同期（イベント駆動）でレプリケーションして疎結合を保つ。
• 決済/コンビニWebhookは物理2分割（軍神Gemini指摘）: 「受信→Queueに積んで即200 OK」Workerと「Queueから非同期処理」Workerに分離。受信Workerが直接D1へ書くとロックでタイムアウト＝決済完了漏れが多発。
• 要点: "継ぎ目のないひとつの体験"は上層（UX）で実現し、下層は"分けて守る"。統合の利便性と分離の堅牢性を両取りする。

9. フェーズ計画

• Phase 0（〜提案確定）: 5軸調査（済）→ 本提案・モック（8/3）→ フォトクリエイト/イプシロン打診。
• Phase 1（MVP）: 体験→入会→会員→連絡・出欠・決済登録。段階ロールアウト（1支部パイロット）。
• Phase 2: EC・写真販売連携、分析ダッシュボード拡張。
• Phase 3: 派遣指導者労務・交通費、会計/CRM連携。

10. 8/3 MTG で決めたいこと（論点）

1. 開発方針＝ハイブリッド自社コアで合意可否（vs 既存SaaS採用）。
2. 写真販売＝スナップスナップのURL設置・案内機能で合意（※連携はJACPA側保有・先方打診は不要）。
3. 決済＝GMOイプシロン（代表相談済み）→ プラン選定のみ。
4. MVP範囲とパイロット支部、移行スケジュール（3万人の段階移行）。
5. 体験者メッセージのメール基盤（送信ドメイン・inbound受信）の方針。

11. 継続ヒアリング事項（構築前に確定する）

• 【P0ブロッカー】大塚商会製 現行システムの守備範囲: 何を担っているか（請求か／会員マスタか／どのデータを持つか）・エクスポート可否。これが不明だと移行の A/B 線引き（§16）が組めない＝提案の前提。軍神レビューが最重要空白と指摘。
• 【最優先】月謝・請求モデル: 現行の集金手段・引落日・きょうだい割・日割り・休会中の扱い・未収督促。MVPの「決済登録」はこの請求モデルが土台。Fable5評価でも最重大の空白と指摘。※軍神レビュー: 請求モデル確定までMVP(A)からは決済登録を外し、金流(B)として後で着手する。
• 決済プラン試算: イプシロンへ技術資料（非通過型方式・webhook署名仕様・継続課金トークン・リトライ挙動）を請求。手数料は 3.5% 前提で月謝×会員数を試算（基本クレカ/コンビニ。追加手段は手数料が異なる点も確認）。
• コスト提示を3年TCO化: 自社構築の開発＋運用＋脆弱性診断＋Sgrum並行運用まで含め、SaaS案と両側比較。
• 施設マスタの受領（提携園）: 体験フォームのデータ源（公開AJAX garden_list）から体験実施中の施設 約763件を確認済み。ただし全文検索の仕様上、公開フォームからは名称を全件取得できない（取得できたのは約251件＝33%）。→ JACPAから施設マスタCSV（garden_id/施設名/カナ/都道府県/市区町村/住所/支部/種目）を受領するのが確実（提携園一覧・763件IDリスト保存済み）。
• 本部の集中管理の具体粒度（何を本部が握り、支部/現場に何を委譲するか）。
• ECの物流: 全国の倉庫数・所在、商品別の発送元/発送量ルーティング、在庫連携、送料計算。→ 要ヒアリングのうえ Phase2 で設計。
• 英会話の業務委託先: 委託先の数・契約、講師PIIの授受、休講連絡の窓口、委託先アカウント付与方針。
• 指導員の担当ローテーション: 曜日×会場×複数園の割当実態、代講ルール。
• TISG/組織階層の正式定義、現行 Sgrum の扱い（置換/連携）、会員3万人の内訳（スポーツ/英会話・正課/課外）、既存「体験入会システム/課外報告フォーム」の流用可否、月謝集金の現状。

12. 原価（コスト構造）

技術詳細は 技術スタックと費用感 参照。原価は ①初期（開発）② ランニング（運用） に分かれ、支配的なのは開発費と決済手数料（インフラは相対的に小さい）。

12.1 初期（開発）原価 ※概算・体制(内製/外注)で大きく変動・正式見積は要件凍結後

合計は要件と体制次第。内製化すれば人件費に置換、外注なら上記レンジ。まずMVPで価値検証→段階投資が定石。

12.2 ランニング（運用）原価

参考: 既存SaaS従量は年3,500〜4,300万円（軸⑤）。自社Cloudflareのインフラは年数十〜数百万円規模に収まり、差額を開発・セキュリティに回せる。3年TCOでSaaS案と両側比較して提示する（Fable5評価P0）。

13. リスク一覧（実装まで／運用後）

深刻度: 🔴高 🟠中 🟡低。緩和策は §6.1（必須統制）・§11（ヒアリング）と連動。

13.1 実装までのリスク

13.2 運用後のリスク

14. 開発・運用体制（GitHub ＋ Cloudflare ＋ Claude Code）※オーナー方針

• 構築基盤: リポジトリ＝GitHub、インフラ＝Cloudflare、IaC＝Wrangler、CI/CD＝GitHub Actions / Workers Builds。
• 採択後の進め方: JACPAの環境に Claude（Claude Code）を設置し、GitHub＋Cloudflare 上で AI駆動で構築・保守する想定。設計・実装・レビュー・運用改善をAIエンジニアが継続担当。
• メリット: 内製に近い速度・コスト、ナレッジがJACPA側に残る、継続的改善が速い、ベンダーロックイン低減。開発原価（§12）を人件費/AI活用に置換して圧縮できる。
• セキュリティのガードレール（§6.1と整合）: Claude Codeへ渡す権限は最小化（本番の機微データ・鍵は直接渡さない運用）、変更はPRレビュー＋監査ログ、GitHub/Cloudflareのアクセスは最小権限＋MFA、本番デプロイはゲート（脆弱性診断・承認）を通す。
• 第二者ゲート（軍神レビュー指摘）: 設計＝実装＝レビューが同一（かつ同一モデル系）だとレビューは自己承認と等価。→ 金流・本番PIIに触るコード変更は、別人格／別系統（別モデル or 人間）の第二者レビューを必須にする（§6.1の"第二者承認"をコード変更にも適用）。設計・障害/セキュリティ評価・移行の最終ゴーサインは、必ず別系統（Gemini本体/ChatGPT/人間のSIer出身者）のセカンドオピニオンを取る（同一モデルバイアスの回避）。※本提案は既に Gemini本体レビュー を取得済み。
• AIコンテキスト同期プロトコル＋第二エンジニアの実証（軍神Gemini指摘）: リテイナー契約だけでは属人性は解けない。初期からアーキ・依存・運用ランブックを CLAUDE.md / AGENTS.md にコード化してコミットし、メイン開発者が不在でも第二エンジニアがAI（Claude Code）経由で即修正・デプロイできる体制を"実証・テスト"する。加えて月数時間でも実際にコードを触るサブ・エンジニアを体制に組み込む。
• 危険になる境界線（軍神Gemini）: ①勘定系の"自社独自ルール"の実装開始（独自の割引・繰越ロジックをコード化した瞬間）②ネイティブアプリの完全スクラッチ（→Capacitor等のハイブリッドでWebラッパーに留める）③他システムとのリアルタイム双方向連携が3本超 — いずれかを超えたら増員/組織的参画を必須とする。

15. 運営可能性とセキュリティ基準対応の根拠（3万人・売上35億円）※オーナー問い

詳細: 運営体制・セキュリティ根拠・移行設計。

• 規模≠複雑度: 中身は月謝の継続課金＋連絡＋出欠＋低SKU物販＋写真送客で、負荷は中規模・スパイクは既知（§8.1で吸収）。売上35億円はシステム規模ではない。
• 個人／少人数を可能にする5レバー: ①マネージドサーバレス（運用しない・基盤がSOC2/ISO27001/PCI DSS準拠）②危険データ非保持（カード=イプシロン非通過型、写真=フォトクリエイト）③AI駆動開発 ④低SKU・読み取り主体 ⑤第三者診断のリリースゲート化。
• セキュリティ基準対応の根拠: 非通過型でカードを保存/処理/通過させない→自社はPCI DSS実質スコープ外（SAQ-A相当）。個情法の安全管理措置4分類はCloudflare（暗号化/アクセス制御/監査/Zero Trust）＋プロセスで充足。JACPA＝取扱事業者、開発＝委託先（法25条）。
• 正直な条件（安全弁）: 属人性→バックアップ要員/保守リテイナー、24/365→初動SLA＋エスカレーション、継続保守→年次診断予算、法令→JACPAとの役割分担・報告体制。これらを契約の条件に明記。

16. 運用切り替え（移行）ストーリー ※オーナー要望

詳細: 運営体制・セキュリティ根拠・移行設計 §3。

軍神レビューの再フレーム（軍神レビュー）: 「大塚商会製 基幹の全置換」を1つの意思決定として扱わない。A/B/Cに割る。 - A. 未システム化の新機能（園連携/正課/スケジュール/体験/入会/連絡/出欠＝現行に"無い"機能）→ 🟢 Go（MVP）。グリーンフィールドで責任分界の衝突なし・価値最大・リスク最小。 - B. 金流（月謝請求・入金消込・会員基幹マスタ）の置換 → 🔴 当面 No-Go。35億円の金流・請求モデル未確定・責任分界が個人開発で不成立。先頭で置換しに行くのが最大の地雷。第二の技術者・外部監査・現行並行が揃うまで着手しない。 - C. EC/写真/経営 → Phase2。 - 着手順＝ストラングラー・フィグ: 新機能から侵食し、金流基幹は最後に・単独では触らせない。8/3では"全置換します"で合意しない（最も危険なBに引きずり込まれる）。

• 原則: ビッグバン移行しない。機能×支部単位の段階移行＋並行運用。
• フェーズ: Phase0 現状棚卸し（Sgrum等のエクスポート可否/施設マスタ/月謝集金）→ Phase1 MVP＋1支部パイロット並行運用 → Phase2 データ移行（突合・ドライラン・リハ）→ Phase3 支部順次切替・旧縮退。
• 決済移行の最重要リスク: カード情報は移行不可（非保持）→保護者に再登録依頼＝離脱による未収が最大リスク。事前告知・簡単UX・締め日前完了促進・督促・口座振替継続で緩和。以後はイプシロン継続課金トークンで自動化。
• データ移行: 名寄せ（きょうだい/同姓同名/改姓）は自動統合禁止・人手確定・可逆マージ、前後の件数/金額突合。

17. 外部攻撃への防御設計と有料強化（オーナー: 予算をかけて対応）

17.1 現状（設計に織り込み済み・多くは標準/低コスト）

• DDoS自動緩和（L3/4/7・Cloudflare標準・アンメータード）／WAF（マネージドルール＋OWASP＋カスタム）／Rate Limiting／Turnstile（bot・CAPTCHA）
• 管理画面は Zero Trust（Cloudflare Access）＋MFA、最小権限、監査ログ（§6.1）
• 最大の攻撃対策＝危険データ非保持：カード=イプシロン非通過型／写真=フォトクリエイト＝盗む価値のあるデータを自社に置かない
• 体験IDの不透明化＋短命化、写真は署名付き短命URL＋認可（BOLA/IDOR・総当たり対策）、決済は冪等
• ※現段階は設計・モック。実装・購入はこれから。予算があれば下記を"最初から"導入できる。

17.2 予算をかけて強化する推奨（優先順）

17.3 推奨パッケージ（予算をかける前提）

最初から Page Shield＋Bot Management＋API Shield＋上位WAF、リリース前ペンテスト、マネージド監視委託（初動SLA）、サイバー保険、イプシロンのチャージバック保証を導入。これで「個人開発の弱点（常時対応・実装の穴）」を予算で補完し、外部攻撃・決済不正・漏えいを多層防御する。※各プラン/料金は最新を要見積。

実インシデントに基づく裏付けは セキュリティ障害分析（作成中）に集約。

17.4 現実的なセキュリティ予算（松竹梅）※¥は概算・最新は要見積

前提: カード・顔写真を自社に持たない設計が最悪シナリオ（大量流出）を構造的に消しているため、Enterprise フル装備（松）は当面不要。

梅（堅実な最低ライン）— 年 約80〜150万円

• Cloudflare Pro（〜¥5万/年：WAF＋OWASP・Super Bot Fight Mode・Rate Limiting、Turnstile/DDoSは無料）＋ Zero Trust Access（50席まで無料）
• 年1回 Webアプリ脆弱性診断（¥50〜100万）＋ サイバー保険（¥15〜30万/年）＋ イプシロン EMV3Dセキュア（0円）＋ 危険データ非保持（¥0）

竹（推奨）— 年 約300〜600万円

• Cloudflare Business（〜¥46万/年：＋Page Shield=決済ページのスキミング検知＋強化WAF＋高度bot）
• 年1〜2回 ペネトレーションテスト（¥150〜300万・BOLA/IDOR等の認可漏れ検出に必須）＋ サイバー保険（¥30〜50万/年）＋ イプシロン チャージバック保証＋不正検知（要見積）
• ※24/365有人SOCは初期は過剰（軍神Gemini）。初期は CloudflareセキュリティログをR2に安全保管＋アラート通知で回し、マネージド監視委託は安定後／金流(B)フェーズで。→ 初期の竹は実質 年 約250〜450万円に収まる。

松（手厚い・将来/インシデント後）— 年 800万円〜

• Cloudflare Enterprise ＋ Bot Management＋API Shield（mTLS/スキーマ/JWT）＋Page Shield フル（商談・年 数百万〜）＋ 24/365 SOC委託＋招待制バグバウンティ＋四半期診断

推奨＝竹（年 約300〜600万円）: 防御（Business＋Page Shield）＋外部検証（ペンテスト）＋常時対応の補完（監視委託）＋金銭リスク移転（保険＋チャージバック保証）が揃う。売上35億円に対し年数百万円は、漏えい1件のインパクト（報告義務・信頼失墜・賠償）に対する妥当な保険料水準。

注: 「100%安全」は存在しない。上記は現実的リスクを妥当水準まで下げるもので、継続（診断・依存更新・監視）が前提。

18. 開発・検証・リリースプロセス ※オーナー要望（副社長＝技術有識者向け）

詳細: 開発・検証・リリースプロセス。現代の標準DevOps/SRE＋軍神/Gemini条件（第二者ゲート・段階リリース・IaC）に準拠。

• 開発手順: GitHub Flow（短命feature→PR・ブランチ保護）／TypeScript strict・ESLint／IaC（Wrangler）で環境・バインディングをコード管理（手動コンソール変更禁止）／Drizzleでマイグレをコード化＋前方互換（expand→contract）＋RDBMS退路の抽象化／秘密はsecrets＋secret scanning／CLAUDE.md/AGENTS.mdでAIコンテキスト同期。
• 第二者ゲート: 全PRレビュー。金流・PIIに触る変更は別系統/人間の第二者レビュー必須（自己マージ禁止）。
• 検証環境4層: Local（wrangler dev・Miniflare）／Preview（PRごと一時URL・プレビューD1）／Staging（本番相当・本番PII不使用・各社テスト環境）／Production。本番PIIを下位環境にコピーしない（監査対象）。
• テスト: Vitest（ユニット）＋Miniflare（統合）＋Playwright E2E（体験→決済→出欠→通知／指導者→出欠）＋イプシロンwebhook契約テスト＋負荷試験（雨の日13時・年度替わり10倍）＋SAST/依存スキャン/年次ペンテスト＋合成監視。
• CI/CD（GitHub Actions）: PRで型/lint/test/build/Preview/セキュリティ → mainでStaging＋E2Eスモーク → 本番は手動承認＋段階リリース（Gradual Deployments 1%→10%→100%/カナリア）＋フィーチャーフラグ＋即時rollback。リリース前にバックアップ＋リストア確認。
• リリースゲート: CI green＋第二者承認＋Staging受入（副社長/事務局の受入）＋SLO/エラーバジェット内＋脆弱性診断（高・中ゼロクローズ）。
• 移行A/B/Cと整合: A（新機能）から段階投入、B（金流）は第二者ゲート＋現行並行で最後に、ECは切り離して別デプロイ。

19. 監視・アラート・障害復旧・バックアップ ※オーナー要望（肝）

詳細: 監視・バックアップ・復旧設計。

• 監視/可観測性: SLI/SLO（可用性99.9%・p95 500ms・緊急配信5分・RTO4h/RPO数分〜24h）。メトリクス（Cloudflare Analytics Engine：決済成功率/webhook/キュー滞留/在庫引当/休講配信到達）＋ログ（Logpush→R2・監査append-only）＋エラー（Sentry）＋外形監視（体験→決済→通知の合成実行）＋依存監視（イプシロン/フォトクリ/メール/プッシュ）＋セキュリティ監視（大量エクスポート/時間外/認証失敗）＋コスト急変。
• アラート: P1（全断/決済停止/漏えい疑い）＝即時オンコール＋初動SLA ／ P2＝営業内 ／ P3＝翌営業日。チャネル＝メール＋チャット＋P1電話。受け口はメイン＋保守リテイナー/第二エンジニア（個人が常時対応できない前提を体制で埋める）。SLOバーンレート＋重複抑制でアラート疲れ回避。
• 障害復旧（DR）: 即時rollback／フィーチャーフラグOFF／DLQ再処理／D1 Time Travel巻き戻し＆リストア、依存ダウンは縮退運転（バルクヘッド §8.2）。四半期にリストア演習＋机上インシデント演習（GitLab教訓）。決済/漏えいは §6.1 の報告（速報＋確報60日＋本人通知）。
• 毎日のバックアップ（3層）: ①D1 Time Travel（近リアルタイム復旧点）②日次論理エクスポート→R2（暗号化・世代管理・保持）③★JACPA本部が所有する自社クラウドへ日次コピー。
• 本データはJACPA本部が自社クラウドに保持（ハードでなくクラウド）＝ 開発ベンダー/個人に依存しない継続性・データ主権・出口戦略。＝バス係数1（軍神/Gemini懸念）への構造的な保険であり、「個人開発でも大丈夫か」への具体的担保（最悪、開発者が消えてもJACPAは自社データを保有し別ベンダーへ移せる）。写真・カードは非保持ゆえバックアップ対象外の危険物（フォトクリ/イプシロン）。整合性検証・暗号化・最小権限・リストア確認（検証環境で復元テスト）。

付録A 技術スタックと費用感

作成: 2026-07-24 ／ 前提: 設計提案・Fable5評価

0. 結論

• GitHub ＋ Cloudflare ＋ D1 で正しい。言語は TypeScript 一本（フロント〜API〜ワーカーまで同一言語）。
• AWS は初期フェーズでは原則不要。Cloudflare だけでほぼ完結する。
• ただし D1（SQLite）は「容量上限」と「重い集計」が弱点。会員3万人×数年分の出欠・連絡・監査ログ・経営分析は、対策なしだと詰まる。→ データ層を抽象化し、必要になったら OLTP を外部 Postgres（Cloudflare Hyperdrive 経由）へ逃がせる構えにしておく。これは"保険"で、初期はD1で始めてよい。
• 決済（イプシロン）・写真（フォトクリエイト）・プッシュ通知・メール送信は外部サービス。ここは自作しない。

1. 言語・フレームワーク（レイヤ別）

2. モバイルアプリの作り方（入会後アプリ）

• PWA（推奨の初手）: Web技術のまま「アプリ」に。ホーム画面追加・プッシュ（Web Push）・オフライン。開発・保守が最も軽い。「アプリDL案内」はPWAインストール導線に置換可。
• ストア掲載/ネイティブ機能が要るなら: ①CapacitorでPWAを薄くネイティブ化してApp Store/Google Play掲載（コード大半を再利用）②Expo(React Native)でネイティブ寄せ（プッシュ・カメラ等が厚い）。
• 判断軸: 「App Store/Google Playに載せたい（＝オーナー要件）」なら Capacitor か Expo。まずPWAでMVP→ストアはCapacitorで被せる、が費用対効果◎。

3. Cloudflare だけで足りる理由（サービス対応表）

→ 単独ベンダーで完結でき、WAF/CDN/DDoSが標準同梱なのがCloudflareの強み。運用点数が少なく、3万人規模の"守り"も揃う。

4. D1 の注意点と対策（ここだけ設計で効かせる）

• 容量上限: D1は1データベースあたりに上限がある（現状の上限値は要確認・拡大傾向）。3万人×数年の出欠・連絡・監査ログは増分が大きい。
  • 対策A: ドメイン分割（会員コア／ログ／分析でDBを分ける）。
  • 対策B: 監査ログ・時系列は D1 に貯めず Analytics Engine / R2(追記) へ。
  • 対策C: いよいよ足りなければ OLTP を外部 Postgres（Neon等）に移し、Workers から Hyperdrive で接続。→ そのためリポジトリ層を抽象化（Drizzle ORM等）しておき、差し替えを安価に。
• 重い集計（経営・月次レポート）: SQLiteは大規模集計が苦手。→ 夜間バッチで集計テーブル(rollup)を作る、または分析だけ別基盤。リアルタイム全件集計をD1に投げない。
• 同時実行（残枠・在庫）: D1の楽観ロックだけに頼らず、Durable Objectで対象クラス/SKU単位に直列化して一時確保→確定。ここは設計の勘所。

5. AWS は要るか？（判断フロー）

• 初期〜MVP: 不要。Cloudflareで組む。
• 将来 AWS/外部Postgres を足す条件（どれかに当たったら検討）:
  1. D1容量試算が数年で上限に迫る（出欠/ログの増分）。
  2. 経営分析が重く、集計専用DB（Postgres/ClickHouse）が欲しい。
  3. 既存の会計/基幹（freee/MF等）と重い連携が必要。
• その場合も全面移行ではなく"分析だけ/OLTPだけ"を部分的に。抽象化していれば低コストで移せる。

6. 費用感（概算・インフラ）

※ 最新の各料金・上限は契約時に要確認。ここは桁感の共有。決済手数料・メール送信量・Accessシート数が主なコスト変動要因。（円換算は $1≒155円 で概算・為替で変動）

プラットフォーム基盤（Cloudflare）月額の桁感（会員3万人規模）

別枠（外部・変動費）

• 決済手数料（イプシロン 3.5%前提・基本クレカ/コンビニ）: 月謝×3万人で最大の費目。追加手段は手数料が異なる → プラン試算必須。
• メール送信: 3万人への確認・一斉配信は送信基盤（専用サブドメイン＋SPF/DKIM/DMARC）。送信量課金のサービスを使うと月数千〜数万円規模。
• プッシュ通知: FCM/APNsは基本無料。
• 写真販売: フォトクリエイト側（JACPA既存関係）。自社コスト小。

開発・運用（ここが本当の主役）

• インフラ費より、開発費・保守運用・第三者脆弱性診断が支配的。フェーズ分割（MVP→拡張）で平準化。
• 参考: 既存SaaS従量課金は年3,500〜4,300万円（軸⑤）。自社Cloudflare基盤のインフラは年数十〜数百万円規模に収まり、差額を開発・セキュリティに回せる——これがハイブリッド自社化の経済合理性。

7. 8/3 で言えること / 事前にやる試算（Fable5評価と整合）

• 提示: 「GitHub＋Cloudflare＋D1＋TypeScriptで構築。AWSは初期不要。インフラは軽く、費用は決済手数料と開発が主。」
• 着手前に必ず: D1容量試算（出欠・配信・監査ログの年間増分）→ 分割/Postgres逃がしの条件を紙で決めてからPoC。イプシロン料率試算。Accessシート数（管理者人数）の確認。