社内レビュー用  /  2026.08.01 更新

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

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

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

書類

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

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

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

前提のおさらい

予算システム 税込165,000（見積書は税込表記／内訳 121,000・16,500・27,500。先方上限 税込170,000）。機材・カード・NFCは別予算
体験料税抜500 ＋ 消費税100 ＝ 1,100トレハン（「500のうち50」だと10%に合わないため直した）
規模30ブース／チーム数は未確認／小学1〜3年生が中心
管理単位チーム単位。氏名・住所・連絡先を一切持たない
重複1チーム × 1ブース = 1回。DBのユニーク制約で弾く（アプリで判定しない）
カードQR 1つ ＋ NFC 1つ。両方おなじURL。印刷ご担当へ渡すCSVは1列
通信ブース端末はオフラインでも読み取りを止めない（端末に記録 → 後送）。モニターはおよそ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 番）を新規に作成しました。背景と目的／やってはいけないこと／責任範囲／画面ごとの要件／決定事項と理由（32件）／未決事項／変更の管理。
あわせてプロジェクト直下に CLAUDE.md を作成し、禁止事項をそこに直接書きました（リンク先だと読まれない可能性があるため）

お伺いした3点の結果と、新たに1点

  1. ローカルストレージが当日まで残るか — 平崎さんが試作して検証してくださることに。 iOS Safari が一定期間で保存データを消す可能性への懸念。この結果だけが、実装の作りを左右します。
    消えると分かった場合は、ブースIDを毎回、設定用QRから読み直す作りに変更します（前日の設定に依存しない形）。
  2. 「読み取りの動作を保証する」の全文削除 — 「この内容でよい」とご確認いただきました。 「10月に実機で読み取りを確認いたします」に留め、「読めない場合もチーム名のタップで記録できます」を添える形で確定。
  3. §02 を厚くしたことによる工数への影響 — 「とくに大変でもなさそう」とご確認いただきました。 画面ごとの動作を書き出したうえで、15万のまま進めます。
  4. 【新規のご指摘】端末を交換したとき、未送信データはどうなるか — 「交換しない」に変更しました。 元は「手入力が続いたらカメラを疑い、予備機と交換する」と書いていましたが、 手入力はカメラを使わないので、手入力で回っているブースは止まっていません。 交換すると未送信データが取り残され、ブースIDの再設定も要るため、交換したほうが損をします。
    ・カメラだけ不調 → 交換せず、手入力のまま最後まで走る（データは端末に残り、つながれば送られる）
    ・端末が固まった・電池切れ → 交換する。ただし画面が見えないのでデータは取り出せず、あきらめる
    後者を許容できるのは、先方が数値の厳密さを求めていないためです（去年までブース横に手書き）。 復旧の機能は作らず、当日の手順としてお伝えします（要件定義 §6 P6・決定事項 22／23）。