社内レビュー用  /  2026.08.01 更新

トレハン王国 消費税の見える化システム
要件定義＋先方提出書類

第19回 トレジャーハンティング in つるみ ／ 公益社団法人 鶴見法人会
本番 2026年11月29日(日) 13:00–16:00 ・ 神奈川県立東部総合職業技術校

まだ先方には送っていません。各書類の赤字は空欄（屋号・住所・連絡先・見積番号）です。 ブラウザで Cmd + P →「PDFとして保存」でA4のPDFになります（画面上部の案内は印刷されません）。
ご指摘を反映しました
「元になる要件の説明がない」とのご指摘をいただき、要件定義書（下の0番）と CLAUDE.md を新規に作成しました。 そのほか7点のご回答も、下の「いただいたご指摘と、その対応」にまとめております。

書類

0 要件定義書 v1.0 requirements.html ・ 新規 ・ 上流の資料 今回の追加分。背景と目的／やってはいけないこと／関係者と責任範囲／画面ごとの要件／データと制約／技術構成／決定事項と、その理由（21件）／未決事項／変更の管理。下の3点は、この文書から先方向けに抜き出したものです。 1 制作範囲のご確認 scope.html ・ A4 1枚 ・ 最初に送るもの 当日の流れ／お作りする画面と、その動作／ご担当の切り分け／行わないこと／仕様確定と修正の扱い／決めていただきたいこと5点／予定表。金額を含まないので、見積より先にこれを送る（認識のズレを先に出すため）。§02 が不具合の判定基準になっています。 2 御見積書 estimate.html ・ A4 2枚 ・ 税込165,000円 内訳／本見積に含まないもの／動作確認の範囲／前提条件／仕様確定と修正の扱い／予定表。 3 機材の動作条件 device-spec.html ・ A4 1枚 ・ 発注前に渡す タブレット／カード／NFCタグ／モニター・Wi-Fi に満たしてほしい条件。締めは動作の保証ではなく、「10月に実機で読み取りを確認いたします」に留めた（照明・カードの汚れ・個体差・ブラウザ更新など、条件を満たしても読めない要因が残るため）。

画面イメージ（先方にも共有済みのもの）

▸ 画面モック（実際に動きます）

前提のおさらい

予算システム 税抜150,000／税込165,000（先方上限 税込170,000）。機材・カード・NFCは別予算
体験料税抜500 ＋ 消費税50 ＝ 550トレハン（「500のうち50」だと10%に合わないため直した）
規模30ブース／チーム数は未確認／小学1〜3年生が中心
管理単位チーム単位。氏名・住所・連絡先を一切持たない
重複1チーム × 1ブース = 1回。DBのユニーク制約で弾く（アプリで判定しない）
カードQR 1つ ＋ NFC 1つ。両方おなじURL。印刷ご担当へ渡すCSVは1列
通信ブース端末はオフラインでも読み取りを止めない（端末に記録 → 後送）。モニターは数分ごと更新
端末タブレット必須（キャッシュレス体験の本体）。背面カメラAF必須・同一機種。NFCは不要、搭載機はOFF
先方の方針集計のずれは気にしないと明言済み／紙で代替しても催しは成立する（逃げ道あり）
リハーサル前日に会場・機材が使えるかは未確認（当日のみのレンタルかもしれない）。使えれば前日に通し確認、使えなければ当日朝が唯一の確認機会。先方に確認中
会場下見見積から削除。平日の空の会場で電波を測っても当日と別物、カードもタブレットも11月上旬には揃わない、モニターの端子は写真で聞ける → 行っても行動が変わらないため。その1万円を当日立ち会いに移した（2時間→4時間）
公開無料枠のサブドメイン。12/31 で公開終了・データ削除。専用ドメインは取らない
技術構成（案）Cloudflare Pages ＋ Supabase（tsurumiと同じ構成）
Vercel無料は非商用限定なのでクライアント案件では使えない。Cloudflare Pagesは商用OK・帯域無制限・無料で、pages.dev が netlify.app より3文字短い（QRの模様が粗くなり読みやすい）。DBは Cloudflare D1 ではなく Supabase ── 一発勝負の案件で初めての道具は使わない、という理由。
サブドメイン名短くする（例 trehan.pages.dev）。QRに入る文字数が増えると模様が細かくなり読み取りにくくなるため。コードも5文字（A7K2M）

いただいたご指摘と、その対応

7点すべてご回答ありがとうございました。下記のとおり反映しております。

観点 ご回答 対応
1 動作確認の範囲 問題ない 範囲は維持。あわせて「多数台の同時利用」を除外リストから前提条件へ移しました（端末ごとに独立した記録なので競合せず、設計で担保できるため）。除外は「人為的な誤操作」「機種違いによる差」の2つだけに絞っています
2 不具合が無制限は危ない 「何が不具合なのか？要件がないので、あとから言ったもの勝ち」
「調整は時間で制限してよさそう」		 不具合の定義を「制作範囲のご確認 §02」に固定しました。あわせて §02 に各画面の動作を書き出し、基準として機能する厚みにしています。
★ 当初は要件定義書を基準にしていましたが、その文書は先方に配布しないため、先方が自分の同意した基準を読めないことに気づき、先方が手元に持つ書面へ付け替えました。
調整・差し替えは回数ではなく「合計3時間まで無償／超過分 1時間5,000円」へ。不具合は引き続き無制限・無償です
3 15万で足りるか 問題ない 金額は据え置き。内訳のうち会場下見（1万）を削除し、当日の立ち会いへ移しました（2時間→4時間）。下見は機材もカードも11月上旬に揃わず、行っても実装が変わらないため
4 ユニーク制約 それでOK 変更なし。UNIQUE(チームコード, ブースID) で2件目は静かに無視。管理画面に「記録を1件消す」を追加しています（誤って別チームを読んだ場合に、制約で正しい記録が入らなくなるため）
5 オフライン記録 ローカルストレージに保存し、送信ボタンでSupabaseに反映 その方針に合わせました。通常は読み取りのたびに自動送信を試み、失敗分はローカルに溜めて次回まとめて送ります。あわせて画面に「未送信◯件」の表示と手動の送信ボタンを置きます（自動再送に頼りきらない）
6 技術構成 OK。そこまでセキュリティを気にしなくてよいなら、ブラウザから直接Supabase Cloudflare Pages ＋ Supabase で確定。関数は挟まず、ブラウザから直接つなぎます。要件定義書 §9.1 に RLS の方針を新設しました（追加は可／更新・削除は不可／チームページは1件のみ・一覧の取得は不可）
7 抜けている前提 「最初の要件の部分がない」
「Anthropicが推奨する形式で残すと、要件変更や調整がかなり楽」		 要件定義書 v1.0（上の 0 番）を新規に作成しました。背景と目的／やってはいけないこと／責任範囲／画面ごとの要件／決定事項と理由（21件）／未決事項／変更の管理。
あわせてプロジェクト直下に CLAUDE.md を作成し、禁止事項をそこに直接書きました（リンク先だと読まれない可能性があるため）

実装に入る前に、教えていただきたい3点

  1. ローカルストレージは、当日まで消えずに残るでしょうか。 ご提案いただいた「ローカルに保存 → 送信」で進めますが、iOS Safari は一定期間アクセスがないと保存データを消すことがあると聞きます。前日に設定して当日消えていると困ります。
    ・端末を前日にセットアップする場合、翌日まで残りますか
    ・消えても困らない作りにすべきでしょうか（ブースIDは毎回QRから読み直す、など）
  2. 「読み取りの動作を保証する」を全文削除しました。過剰でしょうか、不足でしょうか。 条件を満たしても、照明・カードの汚れ・個体差・ブラウザ更新で読めない可能性が残るため、「10月に実機で読み取りを確認いたします」に留めました。あわせて「読めない場合もチーム名のタップで記録できます」を添えています。
    機材は先方がご手配されるものなので、そこまで背負わない判断ですが、逆に弱すぎて信用を落とさないかが気になっています。
  3. 制作範囲（1番）の §02 を厚くしましたが、工数の見立ては変わりませんか。 不具合の判定基準にするため、画面ごとの動作を書き出しました。書いた以上は「そのとおりに動く」責任が発生します。15万のままで無理がないか、あらためてご確認いただけますと助かります。
    とくに①の「5秒で自動的に待機へ戻る」「2回目は演出を流さない」あたりは、書いたことで確認項目が増えていないでしょうか。