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. 保護者連絡（一斉/個別/出欠/欠席/既読・プッシュ・LINE）… ★MVP
5. 園連携・運営事務（会員/体験リストの園提出、募集プリント、スケジュール調整、正課カリキュラム提出、役割ベース自動ルーティング）… ★MVP相当（現行の最大の痛点・Sgrum未対応）
6. 英会話固有（外国人講師管理・病欠ルーティング、テキスト発注、講師/生徒評価）… Phase2
7. EC ショップ（倉庫連携・管理画面連動）（ユニフォーム・用品。保護者アプリで購入→イプシロン決済、全国の複数倉庫の在庫連携＋商品別の発送元ルーティング＝マルチ倉庫フルフィルメント、管理画面で商品・在庫・注文・出荷を一元管理）… 運営ダッシュボードと連動して構築。※送料表・倉庫の実所在・配送業者連携等の運用パラメータは要ヒアリング
8. 写真販売の案内（写真イベントごとにスナップスナップURLを設置→保護者へ案内・送客。JACPA側で連携保有・API不要の軽量実装）… Phase2
9. 季節イベント・合宿（キャンプ/スキー/サッカー合宿。内部＝アプリ先行公開・外部＝Web、定員共有で連動、参加者・収支管理）… Phase2

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のログインにレート制限、決済はアプリ側で非保持化。入会後はアプリ内メッセージへ引き継ぎ。

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

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

• ガバナンス: 本部が全社を集中管理（全権）。支部・現場(指導員)・園・委託先は本部から委譲された最小権限ビューのみ。ダッシュボードは本部中心、支部以下はスコープ制限。
• メール送信（トランザクショナル）は 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 クラス（在籍。状態=体験/在籍/休会/退会）
• 指導員/講師 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倍の負荷試験合格基準。

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

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

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

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

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

• 購入導線: 保護者アプリのショップで購入 → イプシロン決済（非保持化）。注文は会員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で最小構成。
• 写真はレベニューシェアでコスト→収益に反転。

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. LINE をどこまで一次チャネルにするか。
6. 体験者メッセージのメール基盤（送信ドメイン・inbound受信）の方針。

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

• 【最優先】月謝・請求モデル: 現行の集金手段・引落日・きょうだい割・日割り・休会中の扱い・未収督促。MVPの「決済登録」はこの請求モデルが土台。Fable5評価でも最重大の空白と指摘。
• 決済プラン試算: イプシロンへ技術資料（非通過型方式・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、本番デプロイはゲート（脆弱性診断・承認）を通す。

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

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

0. 結論

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

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シート数（管理者人数）の確認。