REDCLIFF FAN PLATFORM — 技術実装方針 v0.1
構想提案（Proposal v0.1）の内容を「誰が・どの順番で・どこまでを自作するか」に落とし込むための実装検討資料。対象読者は実際に開発するエンジニア／外部委託先。
この資料の位置づけ：構想提案は意思決定者向けの事業判断材料であり、これはPilot着手が決まった後の実装検討材料。ここに書かれた難易度・順序・期間は現時点の見積りであり、実際のチーム構成や委託先の技術選定によって変わる。
SYSTEM ARCHITECTURE
全部を自社で組み上げるのではなく、枯れた外部サービスに任せられる部分は任せ、REDCLIFF固有のロジック（Stamp・Passport・Sponsor向け集計）だけを自作する。
インタラクティブな構成図を開く（パン・ズーム・依存関係トレース対応）BUILD vs BUY
一人（または少人数）開発を現実的にする一番の判断は、「枯れた領域を自作しない」こと。
DIFFICULTY MAP
「難しいから無理」ではなく、「難易度が高いものはPhase 1に入れない」ための判断材料。
| 機能 | 難易度 | 判断 |
|---|---|---|
| PWA活動ページ・静的地図・日程 | 低 | 個人開発に十分向く。天気は外部APIで済む |
| LINE Login | 中 | OAuth・PKCE・コールバックを正しく実装する必要あり |
| メール Magic Link | 中 | 自前パスワード方式にはしない |
| QR流入パラメータ | 低 | 枯れた手法 |
| Sky Passport データ構造 | 中 | 先にスキーマ設計が必要 |
| NFCでStampページを開く | 低 | Web NFC APIは不要（詳細は次項） |
| 一人・一場一枚のStamp制御 | 中 | DBのユニーク制約で対応可 |
| 静的Sky Memory生成 | 中 | 同期処理にせず非同期キューにする |
| 業務管理バックエンド | 中 | 地味だがMVPに必須。後回しにしない |
| 現場オフライン同期 | 高 | Pilotでは「ページの閲覧」だけオフライン対応し、Stamp発行はオンライン限定にする |
| PWA Push通知 | 高 | iOSはホーム画面追加＋許可が前提。主導線にしない |
| 個人化CRM | 非常に高 | Phase 1では不要。Phase 2以降 |
| Sponsor Dashboard | 非常に高 | 権限・データ分離の設計が重い。手動作成のレポート（開発不要）はPhase 1、ログイン型Dashboardの開発はPhase 3以降に分離する |
| チケットAPI連携 | 非常に高 | チケット会社ごとに仕様が異なる。個別協議が前提 |
| モバイルオーダー・仮想待ち列 | 非常に高 | 事実上別プロダクト。単独では推奨しない |
| Native App | 非常に高 | 必要性が確認できるまで着手しない |
NFC — TECHNICAL NOTE
「3D NFC Stamp」は特別なアプリ開発を必要としない、技術的難易度の低い実装で成立する。ただし提案書側の最新方針では、NFCはPilotの上線条件ではなく、自主興行1〜2件に限定した小規模な検証と位置づけている。参加記録そのものはURL／QR経由でも成立するため、以下の実装は「対応できれば加点」の扱いとし、他の機能のブロッカーにはしない。
ただし、複数Stamp到達で無料チケットなど高価値な報酬に変わる設計である以上、固定リンクは転送・共有されうる。これはNFC自体の欠陥ではなく、報酬設計の問題として段階的に対処する。
スタッフ管理＋活動時間内のみ開放＋一人一場一枚の制御で十分
スタッフが発行する短期有効コード、または検票後の引換券と紐付ける
チケット購入記録との突合、またはワンタイムトークンを検討（Phase 1では不要）
BUILD ORDER
事業側のPhase 1〜3は「何を先に見せるか」の区分。ここでは「何が何より先に作られていなければ動かないか」で並べ直す。
インタラクティブな依存関係図を開く（コアパス／並行トラック／NFCの位置づけを可視化）Users / Identities / Events の3テーブルと、LINE・メールのアカウント統合ルールを最初に固める。ここが曖昧なまま先に進むと、後から全機能を作り直すことになる。
活動の作成、NFC／QRの有効化、Stamp手動補発。地味だが、これがないとPilot当日にスタッフが対応できない。
依存：データモデル枯れたホスティングサービスの利用を前提に実装。
依存：データモデルMVPの中核。一人・一場一枚の制御をここで確定する。実体NFCは並行する小規模検証であり、これをブロックしない
依存：身元確認、業務管理バックエンド匿名IDとログイン後ユーザーIDの紐付けを含めて設計する。後回しにすると数字が合わなくなる。
依存：Sky Passport同期処理にせず、生成をキューに乗せる。終演直後のアクセス集中を前提に設計する。
依存：Sky Passport実機・実NFCタグでのリハーサルと、エンディングQR直後を想定した簡易的な負荷確認。
依存：上記すべてUNVALIDATED ASSUMPTIONS
構想提案の中では「できる」と書いているが、技術的にはまだ検証されていない前提。断定はせず、この5つをPilotの検証項目として明示する。
回線混雑時の一時保存と復旧後の同期は、重複送信・多重取得・時刻ズレなど考慮すべき論点が多い。Pilotでは「ページ閲覧のみオフライン対応、Stamp発行はオンライン限定」に絞って検証する。
PWA Pushは、ホーム画面に追加し通知を許可したユーザーにしか届かない。QRを一度開いただけの来場者への到達率は未検証。
同一人物がメール登録後にLINEで再登録するなど、複数アカウントが発生しうる。統合ルールをPilot後に運用しながら固める。
計測できるのは「共有ボタンをタップした数」までで、実際に外部SNSへ投稿されたかどうかは通常把握できない。Pilot Scorecardの「共有・反応」はこの前提で読む。
数万人規模の来場者のうち、終演直後の数十秒に閲覧・ログイン・画像生成リクエストが集中する。静的ページのCDNキャッシュ、画像生成の非同期化、DB書き込みの冪等性が前提になる。
MISSING MODULES
特に「Stampの手動補発」は優先度が高い。スマホの電池切れ・回線不通・NFC読み取り不良は、現場では必ず起こる前提で設計する。
DATA MODEL
TIMELINE
一定の技術力を持つ開発者が、AIを補助的に使い、枯れた外部サービスを組み合わせる前提。初めてのプロダクト開発でゼロから積み上げる場合は、これより長くなる。
| フェーズ | 期間目安 |
|---|---|
| クリック可能な試作＋データ構造設計 | 1〜2週 |
| 身元確認・活動ページ・Passport | 2〜3週 |
| NFC／QR Stamp | 1〜2週 |
| 静的Sky Memory | 1〜2週 |
| 業務管理バックエンド | 2〜3週 |
| Analytics・レポート | 1〜2週 |
| 実機テスト・現場演練 | 2〜3週 |
合計でおよそ10〜14週でPilotに使える版を目指す。この期間・体制はチーム構成が決まった段階で改めて見積もり直す。
TEAM SIZE
BUILD ORDERの依存関係には、もともと2箇所の並行できる分岐がある——②業務管理バックエンドと③身元確認は①にしか依存せず、⑤Analyticsと⑥Sky Memoryは④にしか依存しない。1人開発だとこの並行機会がすべて順番待ちになって流れる。人を増やす価値は、この2箇所を実際に並行させられるかどうかにある。
| 体制 | 期間目安 | 担当の考え方 |
|---|---|---|
| 1人 | 10〜14週 | 全ステップを1人で順番に進める。並行できる分岐も順番待ちになる |
| 2人 | 8〜11週 | Aが①③④⑤⑦の主線を担当。Bが①の後②→⑥に回り、③・⑤の期間に並行して進める |
| 3人 | 7〜10週 | Aが①→④（統合）→⑦の主線。Bが②→⑥。Cが③→⑤。2箇所の並行分岐を両方とも同時に埋められる |
分担がこの形になっている理由は、依存関係そのものに沿っているから。②と③はどちらも①だけに依存し、互いには依存しないため、別の人が同時に進めても手戻りが起きない。⑤と⑥も同じ理由で④の後に並行できる。担当をこの依存構造と無関係に割り振ると、待ち時間や手戻りが増えて人数を増やした分の効果が出ない。
4人以上に増やしても、④（Sky Passportの統合）と⑦（現場演練、全員が実機で立ち会う必要がある）はこれ以上分割できないボトルネックのため、短縮効果は頭打ちになる。まずは2〜3人体制を検討すれば、並行できる分岐の恩恵はほぼ受けられる。