社内レビュー用  /  2026.07.30

トレハン王国 消費税の見える化システム
先方提出書類（3点）

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

まだ先方には送っていません。各書類の赤字は空欄（屋号・住所・連絡先・見積番号）です。 ブラウザで Cmd + P →「PDFとして保存」でA4のPDFになります（画面上部の案内は印刷されません）。
ご指摘への対応（7/31）
「元になる要件の説明がないので、今回の資料だけ見てもよくわからない」とのご指摘をいただき、要件定義書を作りました（下の0番）。
・なぜこのシステムを作るのか → §0・§1。とくに §1.3「やってはいけないこと」（競わせない／本物の決済をしない等）を独立させました。AIで拡張する際にここが残っていないと、禁止されている機能を提案されてしまうためです
・誰がどこまで責任を持つか → §2 に弊方と鶴見法人会の2者の表（印刷も舞台も法人会内のご担当のため、境界は1本）。3つの書類に散っていたものを1枚にまとめました
・§11「決定事項と、その理由」21件 — 来年の拡張時に読む想定で、判断の理由を残しています

書類

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

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

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

前提のおさらい

予算システム 税抜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）

見ていただきたい観点

  1. 動作確認の範囲の切り方は妥当でしょうか。 「1台での実機確認」「通し確認1回」「当日朝の立ち上げ確認」を範囲内とし、範囲外は「人為的な誤操作」と「機種違いによる差」の2つだけに絞りました。同時利用と重複読み取りは、除外せずに設計で担保する形にしています（端末ごとに独立した記録なので競合しない／同一チーム×同一ブースはDBのユニーク制約で弾く。ただし30台の実測はしない）。この線引きで足りるか、逆に約束しすぎていないか。
  2. 「不具合は回数制限なく無償（本番当日まで）」は危なくないでしょうか。 調整・差し替えは2回まで、仕様追加は別途としています。不具合を無制限にしたのは、回数を数えると直すべきものを有料に見せてしまうためです。この線引きで自分が損をしないか。
  3. 税抜15万で、6画面＋当日対応まで無理がないでしょうか。 内訳は 開発110,000／動作条件と実機確認15,000／会場下見10,000／当日立ち会い15,000。工数の見立てが甘い箇所があれば。
  4. 1チーム×1ブース=1回を、DBのユニーク制約で弾く方針で問題ないでしょうか。 アプリで「有無を調べてから書く」形にすると同時アクセスで隙間ができるため、DB側で弾いて2件目は静かに無視する想定です。あわせて管理画面に「記録を1件消す」を用意します。
  5. オフライン記録＋後送の方針で、モニターの更新（数分ごと）は成立しますか。 会場の通信が詰まる前提で、ブース端末は端末内に記録して後から送る想定です。
  6. 技術構成は Cloudflare Pages ＋ Supabase でよいでしょうか。 ・Vercel無料は非商用限定なので除外しました。Cloudflare Pages（商用OK・無料・pages.devが短くQRに有利）を想定しています。
    ・DBは Supabase か Cloudflare D1。D1なら1アカウントで完結して先方に渡しやすいのですが、初めて触ることになるため Supabase（tsurumiで経験あり）にしています。この判断で問題ないでしょうか。
    ・ブラウザから直接Supabaseを叩いて RLS で守るか、Pages Functions を1つ置いて鍵をサーバー側に隠すか。個人情報を持たないので前者で足りると考えていますが、ブース端末のURLを知れば誰でも書き込める状態になります（集計のずれは「気にしない」方針ではありますが）。
    ・ユニーク制約（同一チーム×同一ブース）の置き方もあわせてご確認ください。
  7. 抜けている前提・書いておくべき除外事項はないでしょうか。 当日の事故で「書いていなかったので揉める」ものが残っていないか、が一番見ていただきたいところです。