メインコンテンツまでスキップ

来場者向けシステム 仕様共有資料

0. ドキュメント情報​

項目内容
プロジェクト名来場者向け
文書種別実装向け仕様共有資料
バージョンv0.1.0
作成日2026/7/22
原資料detail_02.md
ステータスレビュー完了

0.1 本書の方針​

  • 本書はdetail_02.mdだけを根拠として作成する。
  • 原資料に明記されていない仕様は補完しない。
  • 未記載、複数案、不整合がある内容は「要確定」とする。
  • 入場管理システムは別プロジェクトとして扱い、その内部仕様を本書では定義しない。
  • 「要確定」の内容は、決定されるまで実装上の前提にしてはならない。

0.2 仕様状態​

状態意味
確定原資料に明記されている
条件付きCould要件等、実装対象に含めるか未確定
要確定原資料で未記載・不整合・別途検討となっている

1. 概要​

1.1 目的​

  • 来場前に来場者情報を登録できるようにし、入場時の手続きを簡易化する。
  • パンフレット、FAQ、マップ、イベント、アクセス情報を来場者へ提供する。
  • 会場内の人の集まりを統計化し、混雑状況を来場者が確認できるようにする。
  • 来場者が対話形式で質問できる仕組みを提供し、質問傾向を確認できるようにする。

1.2 対象範囲​

  • LIFFを用いた来場者向け機能
  • LINE Loginによる来場者識別
  • 来場者グループ・ゲスト情報の登録
  • 入場予約状況と入場用QRコードの表示
  • イベント情報、参加登録、予約状況の提供
  • パンフレット、FAQ、マップ、アクセス情報の提供
  • 「ここどこ」スタンプラリー
  • 条件付きで、位置情報による混雑表示
  • 条件付きで、LLMによる質問応答と質問履歴の収集

1.3 対象外​

  • 入場端末でのQRコード読取・入場判定・入場記録
  • 入場管理システムの内部実装
  • 原資料に記載されていない管理画面の実装

1.4 用語​

用語定義
蒼翔祭本プロジェクトが対象とする会津大学の学園祭
LIFFLINE Front-end Framework
SoshosaiAPI本システムのバックエンドAPI
ここどこ会場各所を巡るスタンプラリー企画
グループ事前予約時に代表者が作成する、同伴者を含む来場者のまとまり
ゲストグループに属する個々の来場者
入場管理システム本システムが表示するQRコードを利用する別プロジェクト

2. 利用者・関係者​

2.1 利用者​

  • 来場者

2.2 ステークホルダー​

役割氏名
プロジェクトリーダー@凶兆の黒猫
開発担当@yuna1107 @しよを @Y.Haruto
利用者来場者

3. ユースケース​

IDユースケース概要優先度
UC-01事前予約人数と来場者情報を事前に登録する高
UC-02予約確認登録した情報の確認・編集と入場用QRの表示を行う中
UC-03資料公開パンフレット、FAQ、アクセス情報を表示する中
UC-04マップスタンプ設置位置、イベント位置、会場・フロア情報を表示する中
UC-05イベントイベント情報の確認、参加登録・予約を行う中
UC-06対話形式の質問対応来場者の質問を受け取り、回答を返す低

予約情報の編集範囲と編集可能期間は要確定とする。

4. システム構成​

4.1 確定している構成​

図は原資料の構成を整理したものであり、別プロジェクトである入場管理システムの構成は定義しない。

4.2 技術スタック​

区分技術状態
言語TypeScript確定
フロントエンドReact確定
APIフレームワークHono確定
インフラCloudflare Workers確定
データベースCloudflare D1確定
ORMDrizzle ORM確定
LINEアプリ基盤LIFF確定
来場者認証LINE Login確定
セッション・API認証SameSite・HttpOnly Cookie、JWT確定（§9.2）
質問応答Gemini API条件付き

4.3 要確定の構成​

  • ReactとHonoの配置・ビルド・デプロイ単位
  • LIFFアプリとLINE Botの責務分担
  • LLM呼出しをLINE Botが直接行うか、SoshosaiAPIを経由するか
  • コンテンツをコード変更なしで更新するための管理機能・保存先
  • 入場管理システムとのAPI・データ連携方式
  • 監視、ログ収集、障害通知の方式

5. 機能仕様​

5.1 機能一覧​

ID機能仕様優先度状態
F-001来場者情報入力人数分の識別名、年齢層、性別を入力するMust確定
F-002LINE Login認証LINE Loginで来場者を識別し、セッションを発行するMust確定
F-003来場者グループ作成代表者と同伴者を一つのグループとして登録するMust確定
F-004入場用QR表示入場管理システムが読み取るQRコードを表示するMust一部要確定
F-005入場予約状況確認入場予約済み・未予約を表示するMust確定
F-006イベント参加登録・予約任意のイベントへ参加登録・予約するMust一部要確定
F-007イベント登録状況確認登録済みイベントを一覧表示するMust一部要確定
F-008ここどこQR読取設置されたQRを読み取り、スタンプを記録するShould確定
F-009ここどこ進捗確認取得済みスタンプと完了案内を表示するShould確定
F-010パンフレット表示デジタルパンフレットを表示するMust一部要確定
F-011FAQ表示FAQを一覧表示するCould条件付き
F-012会場マップ表示屋外マップと建物単位のイベント位置を表示するMust一部要確定
F-013フロアマップ表示建物内のフロア・企画配置を表示するMust一部要確定
F-014公式サイトリンクSoshosai.comへのリンクを提供するMust確定
F-015イベント情報表示イベントの一覧・詳細を表示するMust確定
F-016混雑状況可視化同意済み位置情報を集計し、混雑状況を表示するCould条件付き
F-017LLM質問応答自由入力の質問にLLMで回答するCould条件付き
F-018アクセス情報表示バス、駅、駐車場の案内を表示するMust確定
F-019質問履歴・統計収集LLMへの質問・回答・日時を記録するCould条件付き

5.2 事前予約・認証​

5.2.1 来場者情報入力​

入力

  • グループ人数
  • 各ゲストの識別用の名前（実名不要）
  • 各ゲストの年齢層
  • 各ゲストの性別

処理

  • 必須項目と入力人数の整合を検証する。
  • 入力完了後、グループ作成処理へ連携する。

異常系

  • 必須項目がない場合はエラーを表示する。
  • グループ人数とゲスト情報の件数が一致しない場合は再入力を促す。

年齢層・性別の選択肢、最大人数、入力文字数は要確定とする。

5.2.2 LINE Login認証​

処理

  • LINE Loginによる認可を行う。
  • LINE UIDを取得する。
  • SoshosaiAPI側の認証済みセッションを発行する。

異常系

  • 認可を拒否された場合は、ログインできない旨を表示する。

CookieとJWTの用途は、クライアント・サーバー間をCookie、サーバー間をJWTとする。セッション期間・更新・失効・ログアウト・外部ブラウザでの動作は §9.2 で確定済み（30日間・自動更新）。

5.2.3 来場者グループ作成​

  • 代表者のLINE UID、グループ人数、各ゲスト情報を受け取る。
  • グループと人数分のゲストを登録する。
  • 登録後にgroupIdを返す。
  • 通信エラー時は再試行を促す。

再試行時の二重登録防止、登録後の追加・削除・編集条件は要確定とする。

5.3 入場予約・QR表示​

5.3.1 予約状況確認​

  • groupIdに紐づく入場予約を照会する。
  • 予約済みまたは未予約を表示する。
  • 予約が存在しない場合は事前予約フォームへの導線を表示する。

予約日時を指定する手順、予約ステータスの種類、予約編集・取消の仕様は要確定とする。

5.3.2 入場用QR表示​

  • 予約が確定している場合に入場用QRコードを表示する。
  • 予約未確定の場合はQRを表示せず、予約状況確認へ誘導する。
  • QRコードは別プロジェクトの入場管理システムで読み取られる。

上記の予約確定に関する規定は表示上の業務ルールであり、セキュリティ境界ではない。入場管理システム側（entry-worker）は Groups.IsReserved を入場可否に使わず、未予約でも当日登録（registrationType='online'）として入場を記録する。発行APIで予約未確定を拒否するか、guest-app の表示で扱うかは未確定である（TBD-019）。

入場管理プロジェクトとの連携仕様は、TBD-004 / TBD-005 の決定に基づき、次のとおり実装で確定している。正本は packages/shared の signQrJwt / verifyQrJwt（#768）である。

QRへ含めるID・表示単位​
種別kindsub発行できる利用者
代表QRgroupgroupId当該グループに所属するゲスト（代表者に限らない）
個人QRguestguestId本人のみ
  • 代表QR（kind: "group"）を基本表示とし、受付は代表QRで運用する（TBD-004）。
  • 他グループ・他ゲストの分を要求した場合は 403 を返す。対象の存否に関わらず同じ応答とし、他グループの存在を漏らさない。
  • 所属グループは発行時点のデータベースから引く。セッショントークンの groupId クレームは使わない（発行時点の所属で固定され、予約フローで所属が変わると追従しないため）。
QRの文字列形式​

QRには署名付きJWTの文字列そのものを載せる。

項目値
アルゴリズムHS256（alg: "HS256", typ: "JWT"）
署名鍵ENTRY_QR_SECRET（Secrets Store の SOSHOSAI_ENTRY_QR_SECRET）。セッションJWTの SOSHOSAI_JWT_SECRET とは別鍵
iss"soshosai-guest-app"
aud"soshosai-entry"
kind"group" または "guest"
subkind に応じた groupId / guestId（空文字不可）
iat / exp必須（数値）
  • セッションJWTと同じ鍵を使うと、ログイン用のJWTがそのまま入場QRとして通ってしまうため、鍵を分ける。
  • 署名鍵は発行側（visitor-worker）と検証側（entry-worker）で同一、かつ全環境で同一の値とする。ずれると全QRが検証に失敗する。
QRの発行タイミング・有効期限・失効​
  • 予約確認画面（ホームの QR カード）を開くたびに発行APIを呼び、新しいQRを発行する。
  • 有効期限は発行から10分（TBD-001）。検証側は exp - iat が15分を超えるQRを拒否し、時計ずれは60秒まで許容する。
  • 個別に失効させる手段は持たず、有効期限の経過で失効する。
  • 期限切れのQRは検証側で reason: "expired" として他の不正と区別される。guest-app は「QRを開き直してください」と案内し、再発行へ導く。
連携APIの要求・応答​

発行API（visitor-worker、gateway 経由でゲストのセッショントークンで呼ぶ。ゲスト以外は 403）:

メソッド・パス発行するQR
POST /groups/:groupId/qr代表QR
POST /guests/:guestId/qr個人QR

応答は { qr: string, kind: "group" | "guest", sub: string }。照合API（entry-worker）は読み取ったQRの文字列を qr（1〜4096文字）として受け取る。

5.4 イベント​

5.4.1 イベント情報表示​

  • イベント一覧を表示する。
  • 選択したイベントの名称、開催時間、開催場所、定員等の詳細を表示する。
  • データ取得に失敗した場合はエラーを表示する。

5.4.2 参加登録・予約​

  • 選択したイベントの定員を確認する。
  • 定員内であれば参加登録を作成し、完了を通知する。
  • 定員超過時はエラーを表示する。
  • 登録済みイベントを一覧表示する。
  • 登録がない場合は未登録である旨を表示する。

次の内容は要確定とする。

  • guestIdまたはgroupIdのどちらを登録単位にするか
  • 参加登録と予約を同一機能として扱うか
  • 重複登録の扱い
  • 取消・変更
  • キャンセル待ち
  • 定員を持たないイベントの扱い

5.5 ここどこスタンプラリー​

5.5.1 QR読取​

  • 会場に設置されたスポットQRコードを読み取る。
  • 利用者とスポットを紐づけ、スタンプ取得を記録する。
  • 取得済みスポットを再度読み取った場合は取得済みである旨を表示する。

5.5.2 進捗確認​

  • 取得済みスポットを一覧表示する。
  • 取得済みスポット数と全スポット数を比較する。
  • 全スポット取得後は本部へ行くよう案内する。
  • 読込み失敗時は再読込みを促す。

記録単位はguestIdまたはgroupIdのいずれかであり、原資料内で確定していない。QR値の形式、カメラ権限、景品受渡し後の状態管理も要確定とする。

5.6 コンテンツ・マップ​

5.6.1 パンフレット・FAQ・アクセス情報​

  • デジタルパンフレットを表示する。
  • F-011を実装する場合はFAQを一覧表示する。
  • シャトルバス時刻表、会津若松駅時刻表、駐車場誘導情報を表示する。
  • Soshosai.comへの外部リンクを提供する。
  • コンテンツ取得失敗時はエラーを表示する。

パンフレットについて原資料にはキャッシュ済み内容を表示する記載があるが、キャッシュ方式・更新判定は要確定とする。コンテンツの形式、保存先、更新者、管理操作も要確定とする。

5.6.2 会場・フロアマップ​

  • 会場全体の屋外マップを表示する。
  • 建物単位のイベント開催位置を表示する。
  • 建物を選択するとフロア単位の詳細マップへ遷移する。
  • フロア内の企画配置を表示する。
  • フロア切替機能を設ける。
  • マップ情報を取得できない場合は静的マップ画像を表示する。
  • 選択した建物のフロアマップが未整備の場合はその旨を表示する。

マップデータ形式、イベント・企画との紐付け、拡大縮小等の操作、静的画像の配布方法は要確定とする。

5.7 混雑状況可視化​

本機能はCould要件であり、実装対象に含めるか要確定とする。

  • 同意済みの来場者から位置情報を取得する。
  • エリアごとの滞在人数を集計する。
  • 会場マップ上へ混雑状況を反映する。
  • 同意がない来場者の位置情報は集計しない。

次の内容が未確定であるため、実装判断前に技術・運用面の検証を行う。

  • LINE内WebViewで位置情報を取得できる条件
  • 同意取得・撤回の方法
  • 取得頻度、エリア判定、リアルタイムの定義
  • バックグラウンド時の動作
  • 匿名化・集計条件・少人数時の表示制御
  • 位置情報の保存期間と削除方法

5.8 LLM質問応答・統計​

F-017とF-019はCould要件であり、実装対象に含めるか要確定とする。

  • 来場者の自由入力を受け取る。
  • Gemini APIを利用して回答を生成する。
  • パンフレットやFAQ等の情報を参照した回答を想定する。
  • API障害またはレート制限時はエラーと問い合わせ先案内を表示する。
  • 質問内容、回答内容、質問日時を記録する。
  • 履歴記録に失敗しても質問応答は継続する。

次の内容は要確定とする。

  • LINE BotとS-07チャット画面のどちらで質問を受け付けるか
  • 使用するGeminiモデル、呼出し経路、回答生成方式
  • 参照する情報の範囲・保存先・更新方法
  • 誤回答時の表示、禁止事項、問い合わせ先
  • レート上限、費用上限、入力・出力長
  • 質問履歴と利用者IDの紐付け、閲覧権限、保存期間
  • 統計を閲覧する管理画面の責務と連携方式

6. 外部連携​

連携先用途認証状態
LINE Login来場者の識別・ログインOAuth 2.0確定
LIFF SDKLINE内WebViewとLINE機能の利用LIFFアクセストークン確定
LINE Messaging APIBotによる質問対応・通知等Channel Access Token一部要確定
Gemini APILLMによる回答生成APIキー条件付き
SoshosaiAPI来場者・予約・イベント等の読書きCookie、JWT確定（§9.2）
入場管理システム入場用QRを用いた入場確認要確定要確定

6.1 入場管理システムとの境界​

  • 本システムは入場用QRコードを表示する。
  • 別プロジェクトの入場管理システムがQRコードを読み取る。
  • 両プロジェクト間でQRとAPIの連携仕様を合意する必要がある。
  • 入場端末の処理、入場判定、入場記録は本プロジェクトの対象外とする。

入場管理システムの内部技術、データモデル、運用は本書では定義しない。

7. データ仕様​

7.1 原資料上の関係​

Group 1 --- N Guest
Group 1 --- N Reservation
Guest 1 --- N EventRegistration
Event 1 --- N EventRegistration
Guest 1 --- N StampProgress
StampSpot 1 --- N StampProgress
Guest 1 --- N ChatQuestion
Guest 1 --- N LocationLog

EventRegistration、StampProgress等をグループ単位にする案も機能詳細に併記されているため、上記のゲスト単位モデルは確定ではない。

7.2 エンティティ​

エンティティ原資料にある属性状態・補足
GroupgroupId, 代表者LINE UID, 人数, 予約日時ID型等は要確定
GuestguestId, groupId, 識別用の名前, 年齢層, 性別選択肢等は要確定
ReservationreservationId, groupId, 予約日時, ステータス状態遷移は要確定
EventeventId, 名称, 開催時間, 開催場所, 定員コンテンツ管理方法は要確定
EventRegistrationregistrationId, eventId, guestId, 登録日時guest/group単位は要確定
StampSpotspotId, 名称, 位置情報, QRコード値QR形式は要確定
StampProgressprogressId, guestId, spotId, 取得日時guest/group単位は要確定
ChatQuestionquestionId, guestId, 質問内容, 回答内容, 日時条件付き機能
LocationLoglogId, guestId, エリアID, 取得日時条件付き機能

7.3 共通の要確定事項​

  • 各IDの型・採番方式
  • 必須・任意、文字数、列挙値、一意制約
  • 作成日時・更新日時
  • 更新・削除・論理削除の扱い
  • 個人情報に該当する項目と保存期間
  • LINE UIDを含むデータのアクセス制御
  • 利用者同意とデータ削除依頼への対応
  • イベント終了後の保管・匿名化・廃棄

8. 画面仕様​

画面ID画面対応機能状態
S-01事前予約フォームF-001〜F-003確定
S-02予約確認・QR表示F-004, F-005一部要確定
S-03パンフレット・FAQF-010, F-011, F-014一部条件付き
S-04会場マップF-012, F-013, F-016一部条件付き
S-05イベント一覧・詳細F-006, F-007, F-015一部要確定
S-06ここどこスタンプラリーF-008, F-009確定
S-07チャット質問F-017条件付き
S-08アクセス情報F-018確定

8.1 画面共通の要確定事項​

  • 初回起動から各画面への導線
  • グローバルナビゲーション
  • ローディング、空状態、エラー、再試行の共通表現
  • LIFFのウィンドウモード
  • 外部ブラウザで開いた場合の導線と利用可能範囲
  • QR読取時のカメラ権限要求
  • 予約・イベント情報の編集、取消操作
  • 対応画面サイズとアクセシビリティ基準

9. 認証・セキュリティ・プライバシー​

9.1 確定している要件​

  • 来場者識別にLINE Loginを使用する。
  • クライアントとサーバー間の認証にSameSite・HttpOnly Cookieを使用する。
  • サーバー間の認証にJWTを使用する。
  • 年齢層、性別、位置情報等を適切に管理・保護する。
  • 位置情報は同意を得た場合だけ取得する。
  • プライバシーポリシーと同意取得フローを整備する。

9.2 セッション仕様（TBD-003 確定・#419 で実装）​

項目内容
有効期間30日
自動更新残存7日未満で GET /api/me 時に再発行（スライディング）。再発行は必ず line-auth-worker の /guest/authenticate を経由し、BANチェックを通す
Cookiesoshosai_customer_jwt（HttpOnly）と soshosai_customer_profile（非HttpOnly）。属性は SameSite=Lax; Secure; Domain=.soshosai.com; Path=/。両者の有効期間は必ず揃える（profile が先に切れると /api/me が強制ログアウトさせるため）
ログインLIFF の ID トークンを POST /api/liff-login で検証してセッションを発行する。LINE アプリ内・外部ブラウザで経路を分けない
ログアウトPOST /api/logout で両Cookieを削除
失効BAN が唯一の即時失効手段。/token/verify は guestId と lineUserId の両方で照合する
CSRF対策/api/liff-login は Origin の完全一致検証を必須とする（欠落・null も拒否）。API 側は gateway-worker が Cookie 認証時に同様の検証を行う
外部ブラウザログインを強制しない。パンフレット・FAQ・アクセスは未ログインで閲覧可能。API 依存画面はログイン導線を表示する

9.3 要確定事項​

  • LINE UIDと本システムの利用者を紐付ける手順
  • Channel Access Token、APIキー等の保管・更新・失効
  • 権限モデルと管理機能の認可
  • 利用規約、プライバシーポリシー、同意文面
  • 収集項目ごとの利用目的、保存期間、削除手順

10. 非機能要件​

10.1 性能・可用性​

  • 想定外の来場者増加にも耐えられる設計とする。
  • イベントまでのサービス停止を最小限に抑える。
  • イベント当日はサービス停止が発生しないことを要件とする。
  • エラーを即時収集し、メンテナンス告知を行えること。

想定同時利用者数、応答時間、可用性の数値目標、復旧目標、負荷試験条件、障害時の代替運用は要確定とする。

10.2 コンテンツ更新​

  • パンフレット、FAQ、マップはコード変更なしに管理側の操作で更新できること。

更新を行う管理画面、権限、公開フロー、版管理、保存方式は要確定とする。

10.3 互換性​

  • iOS 18以上またはAndroid 11以上の端末で稼働すること。
  • LIFFの表示制限とLINE内WebViewの機能制限を考慮すること。

対象となるLINE・OS・ブラウザの具体的なバージョン、外部ブラウザ対応範囲は要確定とする。

10.4 コスト​

  • LLMのレート制限を制御し、不要な費用を抑える。

予算額、利用上限、停止条件、アラート条件は要確定とする。

11. 受け入れ条件​

  • LINE Login後、事前予約フォームからグループとゲスト情報を登録できる
  • 予約状況を確認できる
  • 確定した連携仕様に従った入場用QRコードを表示できる
  • イベントへ参加登録でき、登録済みイベントを確認できる
  • ここどこのQRを読み取り、進捗を確認できる
  • 全スタンプ取得後に本部への案内を表示できる
  • パンフレット、会場マップ、フロアマップ、イベント情報、アクセス情報を閲覧できる
  • F-011を実装する場合、FAQを閲覧できる
  • F-016を実装する場合、同意済みデータだけを用いて混雑状況を表示できる
  • F-017を実装する場合、質問に回答し、障害・制限時に案内を表示できる
  • F-019を実装する場合、応答を妨げず質問履歴を記録できる

受け入れ試験の具体的なデータ、件数、合格値、対応端末は要確定とする。

12. 決定ログ​

本システムの要確定事項と、その決着状況を一覧で管理する。表の形式は全システム共通(.agents/skills/edit-specification/SKILL.md「決定ログの書式」を参照)。

状態 は 未確定 / 保留 / 決定済み / 対象外 のいずれかを取る。

TBD-001〜018 は Epic issue #400 での方針協議により決着済み。入場管理システム側（docs/files/specifications/entryManagementSystem/spec.md）とも整合する内容である。

Epic issue #400 での方針協議により、以下の通り決定した。入場管理システム側(docs/files/specifications/entryManagementSystem/spec.md)とも整合する内容である。

ID分類判断が必要な内容状態期限結論
TBD-001予約予約日時、状態、編集・取消、受付期間決定済み2026/07/31事前期間〜当日終了まで常時受付。入場前であれば自由に編集・人数増減可
TBD-002来場者年齢層・性別の選択肢、グループ最大人数、入力制約決定済み2026/07/31グループ最大10人。年齢層は小学生以下/中高生/大学生・専門学生/一般・社会人/その他の5区分、性別は男性/女性/回答しないの3択
TBD-003認証セッション期間、更新、失効、ログアウト、外部ブラウザ動作決定済み2026/07/31セッションは30日間・自動更新(確定・実装済み #419)。詳細は §9.2 を参照
TBD-004QRgroupIdまたはguestId、文字列形式、発行・失効決定済み2026/07/31groupId/guestId両方発行。受付は代表QR(groupId)を基本運用(入場管理システム側と共通決定)
TBD-005外部連携入場管理システムとのAPI・QR連携仕様決定済み2026/07/31入場管理システム側の決定と共通(QRは署名付きJWT、OTP方式の端末登録)。入場記録APIは端末登録後のX-API-Keyヘッダーで認証する。
TBD-006イベントゲスト・グループ単位、取消、重複、キャンセル待ち決定済み2026/07/31EventRegistrationはguestId単位で作成し定員管理を正確に行う。UI側でグループ一括登録操作を提供
TBD-007ここどこ記録単位、QR形式、権限、景品受渡し後の扱い決定済み2026/07/31スタンプ取得記録はgroupId単位。景品受渡し後の状態はシステムで持たず、本部スタッフの目視運用
TBD-008コンテンツ保存先、形式、管理画面、更新・公開フロー決定済み2026/07/31パンフレット・FAQ等はリポジトリ内Markdownファイルで管理し、デプロイで反映
TBD-009マップデータ形式、操作、イベント・企画との紐付け決定済み2026/07/31屋外の会場マップはOpenStreetMapベース、フロアマップは静的画像+座標登録
TBD-010位置情報実装可否、同意、取得・集計・表示・削除決定済み2026/07/31実装対象に含める(設計確定・実装優先度は低)。初回ダイアログで同意取得・設定画面で撤回可、数分おきにエリア単位で取得・集計(少人数時は非表示)
TBD-011LLM提供画面、モデル、呼出し経路、参照情報、回答制御決定済み2026/07/31実装優先度は低(設計は確定)。S-07チャット画面とLINE Bot両方で受付。SoshosaiAPI経由でGemini APIを呼び出し、パンフ/FAQをプロンプトに埋め込む
TBD-012LLMレート上限、費用上限、障害時案内決定済み2026/07/31レート上限は1ユーザーあたり15回/日程度。全体予算は小額に抑制
TBD-013履歴質問履歴の識別、閲覧権限、保持期間、統計画面決定済み2026/07/31質問履歴はguestIdに紐付け。閲覧権限はSho-Room側の学祭委員。大学への報告完了後に削除
TBD-014APIパス、要求・応答、エラー、認可、冪等性決定済み2026/07/31RESTful API。認証はCookie(HttpOnly)+JWT。エラー形式は入場管理システムと統一
TBD-015データID、制約、状態遷移、更新、削除、保持期間決定済み2026/07/31主キーはUUID v4。論理削除が基本、保持期間経過後に物理削除
TBD-016運用監視、通知、メンテナンス、障害時代替手順決定済み2026/07/31エラーはWana(Sentry互換)に集約。メンテナンス告知はLINE Bot経由の一斉通知
TBD-017非機能同時利用者、応答時間、可用性、復旧目標決定済み2026/07/31想定同時利用者数は数百人規模
TBD-018UI画面遷移、LIFFモード、外部ブラウザ、アクセシビリティ決定済み2026/07/31共通のローディング/空状態/エラー/再試行UIコンポーネントを1セット用意。LIFFは基本Tallモード、QR表示・マップ・チャットのみFullモード
TBD-019QR予約未確定のゲストへのQR発行を、発行APIで拒否するか guest-app の表示で扱うか（§5.3.2）未確定—#421 で検討。入場管理システム側は予約状態を入場可否に使っていない

13. リスク​

ID内容影響度原資料の対応方針
R-01Gemini APIの費用・レート上限が未確定中想定質問数から費用を試算し、上限を設定する
R-02入場管理システムとのQR形式が未確定中両プロジェクト間で早期に仕様を確定する
R-03位置情報の同意方法とLINE内WebViewでの取得可否が未検証中技術検証後に優先度を再設定する

14. スケジュール​

フェーズ原資料の期限ステータス
要件定義2026/7/10進行中
設計2026/7/12未着手
実装2026/8/15未着手
テスト2026/8/24未着手
リリース2026/8/31未着手

原資料では蒼翔祭開催日を2026/8/31想定としている。期限と開催日は原資料の記載をそのまま転記しており、現在日付に合わせた補正は行わない。

15. 承認​

役割氏名承認日コメント
プロジェクトリーダー@凶兆の黒猫
開発責任者
運用責任者