トレジャー王国 消費税の見える化システム ｜ 要件定義書 v1.0

案件　第19回 トレジャーハンティング in つるみ「トレジャー王国に行こう！」
開催　2026年11月29日（日）受付 11:30–12:00 ／ イベント 12:00–16:00（雨天決行）
　　　　神奈川県立東部総合職業技術校（かなテクカレッジ東部）
主催　公益社団法人 鶴見法人会 青年部会 ／ 協力 鶴見税務署 ／ 後援 鶴見区役所・鶴見警察署・鶴見消防署
募集　2026年9月1日〜10月15日（★チーム確定は10/15以降。カード印刷はその後）
参加　鶴見区在住または区内小学校在籍の小学生。1チームは保護者1名以上を含む5名以内
主催　公益社団法人 鶴見法人会（協力：鶴見税務署／後援：鶴見区）
版　　v1.0（2026-07-31）　※ v0.1（07-30）から全面改訂

---

0. この文書について

誰のための、何か

これは制作側の文書。先方（鶴見法人会）には配布しない。
判断の理由や採算にかかわる書き方を含むため、そのまま渡すと角が立つ。

先方にお渡しするもの

合意の記録は、この3点が担う。 本書はその裏づけとして手元に置く。

---

1. 背景と目的

1.1 なぜこのシステムを作るのか

このイベントの主旨は租税教育である。キャッシュレスはそのための手段にすぎない。

第19回の実行委員長が「キャッシュレスの仕組みを入れたい」と発案したことが起点。
新しい試みとして、下記を実現する。

**体験料を払うと、その中に消費税が含まれていることを、
子どもが「見て」実感できるようにする。**

去年までは、ブース横のボードに大きな丸を描き、体験のたびに受付の人が
「円」と手書きし、最後に全ブースから舞台へ持っていく、という方式だった。
このシステムは、その手書きの置きかえである。 求められている解像度はその水準。

1.2 成功の定義

• 子どもが「体験料の中に消費税が入っている」と分かること
• 会場モニターで「みんなで納めた税がまちを支える」が見えること
• 帰宅後に納税証と税金図鑑で復習できること

1.3 やってはいけないこと（★変更禁止）

企画書および打合せで明示された禁止事項。拡張時もこれを外さないこと。

1.4 前提として重要なこと

「極論、単純に紙でタッチしたふりして、紙芝居みたいなので作って、
視覚的に見せて終わり、みたいなのでも成立するっちゃ成立」（先方の発言）

逃げ道が最初から確保されている。 よって過剰な冗長化に費用をかけず、
その分を「ブースの読み取りが確実に動くこと」に寄せる。

---

2. 関係者と責任範囲

2.1 誰がどこまで持つか

印刷も舞台も鶴見法人会の中の担当で、外部の業者ではない。
したがって境界は「弊方 ／ 鶴見法人会」の1本だけ。
法人会の中で誰が担うかは法人会の中の話なので、この表では分けない。

窓口が1つで済む。 「印刷屋さんに確認します」で日数が空くことがない反面、
組織が同じぶん責任の所在が曖昧になりやすいので、この表を先に共有しておく。

2.2 境界の明確化（誤解が起きやすい点）

---

3. 用語

---

4. 当日の流れ

読み取りの想定量（★2026-08-04 先方回答により確定）

約140チーム／1チーム平均3名（保護者1名以上を含む3〜5名で募集）＝ 参加者は約420名。
ただし読むのはチームごとに1回なので、140が基準。

技術的には依然として軽い。30台に分散するので、1台あたりは5分に1回程度。

★ただし「手入力の一覧」は成立しない。140チームを丸で並べても探せない（→ P1 の手入力を参照）。

納税総額の目安（★2026-09-04 カード単位・1,100トレジャーに変更後）

当初（1チーム単位・50トレハン）は約56,000だった。桁が変わる。
会場モニターの目標額を先方に決め直していただく（管理画面から変更可＝Q9）。

---

5. 画面一覧

★表記のルール（P1は読む人が2種類いる）

子ども向けの部分で漢字を使うときは、ふりがな（ruby）を振る。
「王国」は小1＋小2の漢字で、1年生には読めない。ただしチラシが「トレジャー王国」と漢字なので、
ひらがなにすると別物に見える。ふりがなにすれば、見た目を保ったまま読める。
先方が作る税金図鑑の文章にも、こちらでふりがなを振る（scope §02 ⑤に記載）。

同じP1の中に両方ある。「子ども向けだから全部ひらがな」にしない。
スタッフは大人で、操作の指示がひらがなだと、かえって読むのが遅くなる。
P3（保護者）とP6（本部）は漢字。P5 税金図鑑は子どもが読むのでひらがな中心。

画面イメージ → https://trehan-preview.pages.dev

---

6. 画面ごとの要件

P1 ブース決済演出（★最重要）

5つの状態を1画面で切り替える（待機／演出／完了／2回目／手入力）。別々の画面を作るのではない。

決めごと

• 表示時間は3〜5秒（先方指定）
• 動画ではなくアニメーション（30台が毎回動画を取ると回線が死ぬ）
• 全ブース共通で1種類。ブースIDは端末ごとに一度設定する（設定用QRを読ませる）
• ★ブースの一覧に締切を作らない。出展事業者の確定は直前になりやすい。

管理画面（P6）でブースを追加・改名でき、その場で設定用QRが画面に出る作りにする。
紙に刷って配る形にすると、刷ったあとの変更に対応できない。当日その場で増えても対応できる。

• 読み取り開始ボタンは作らない（全体で数百回ぶんのタップが増えるうえ、「押し忘れて反応しない」という詰まり方を生む）
• 画面ごとに押せるボタンは1つだけ
• 手入力は一覧から選ばせない（★140チームでは探せない）。カードのおもてに

3桁のカード番号（001〜420）を大きく印刷し、それを打つ。
★2026-09-11修正。当初「チーム番号（001〜140）」と書いていた。
記録はカード単位になったので、手入力もカードを特定しなければならない。
チーム番号を刷ると、打った番号で別チームのカードが見つかり、それらしいチーム名が出る。
現場で誤りに気づけないまま、本来の持ち主のカードが後で弾かれる。
★この行がカード420枚の印刷指示の根拠。先方に出した別紙「動作条件」§02 とも一致させること。
手入力が要るのは「カメラが読めない」ときであり、カードは手元にあるので番号は読める。
番号はURLではないため、推測されても害がない（チームページのコードとは別物）

• 圏外でも読み取りを止めない。端末内に記録し、つながったときに送る
• ★先方への約束からは「終了後でも送信できる」を外してある（T1の検証待ちのため）。

検証で残ると分かってから、あとで「できます」と足す。先に言って外すのが最悪

• 内部の見込みとしては、終了後でも送信できる。端末内の記録は消さない。

会場で送りきれなくても、Wi-Fiのある場所で送信ボタンを押せば反映される（後日でもよい）。
「その場で送れなければ失われる」ではないので、当日に慌てる必要がない

• ★通信が切れたら、画面に穏やかに表示する（慌てさせないための表示）。

「通信が途切れています。記録は端末に残っています。つながり次第、自動で送信されます。そのまま続けてください」

スタッフが端末を触る理由をなくすのが目的。壊れて見えるから閉じたり再起動したりする。
エラーの赤や警告音は使わない

• 閉じられても戻れるようにする。ブース設定は端末に残るので、URLを開き直せば同じブースとして復帰する。

当日朝に配るブース設定用QRをブースに置いておいてもらえば、それを読むだけで戻せる

• 画面の隅に「未送信◯件」と手動の送信ボタンを置く。件数をタップすると

未送信の中身（チーム名×時刻）を一覧で見られる。撤収時に「全部送れたか」を確かめるため

• 払っていないのに払った演出を出さない（2回目に演出を流さない理由）

P2 会場モニター

• みんなで納めた消費税の総額 ＋ 復興のようす（建物が建つ）＋ 税の使い道メッセージ
• 更新はおよそ1分ごと。★先方は打合せで「時間ごとにおおよそで」とおっしゃっており、求められている水準はもっと緩い。1分と書いておけば確実に守れる（不具合の判定基準に「数分」のような曖昧な語を残さない）。リアルタイム同期は作らない
• 順位をつけない（§1.3）
• 通信が切れたら直前の数字のまま止める。真っ白にしない
• 目標額は設定で変更できる（下記P6参照）

P3 チームページ ／ P4 納税証

カードからの入口は1つ。 QRもNFCも同じURL。

• チーム単位。個人名は持たない
• チーム内のカードは1枚ずつ違うコード（★2026-09-04変更）。なくすと、その子のカードは再発行できない（当初は他のカードから開けた）。
  ただし手入力があるので、カードを忘れた子も救える。再発行の仕組みは作らない
• URLはランダムな英数字。連番にしない（連番だと全チーム分が機械的に抜ける）
• noindex（検索結果に出さない）
• 12月31日で公開終了

P5 税金図鑑

• ペラ1枚。通信もDBも不要な静的ページ
• 項目は仮で6つ（道路／消防・救急／学校／公園／ごみ収集／図書館）。先方がリストを制作予定。いただき次第そのまま差し替える
• イラストは差し替え前提。枠だけ作る

P6 本部管理画面

表記は漢字でよい（内部の人が見る画面。子ども向けのひらがなにしない）。

調整分の扱い（重要）
先方が「少なかったらいっぱい読み込むか」と発言したことへの対応。

会場モニターの表示 ＝ 実測（チーム合計） ＋ 調整分

• 調整分はどのチームにも紐づかない。チームページとブース別集計には影響しない
• CSVには実測と調整分を別の列で出力する（来年の分析は実測だけ使う）
• 目標額を下げることでも復興は完了できる。当日どちらでも選べる

やらないこと：リアルタイムのブース別ダッシュボード。分析はイベント後にCSVから資料にする。

手入力の件数を出す理由：特定のブースで手入力が続いていたら、その端末のカメラを疑う。当日いちばん役に立つ数字。

ただし、原則として端末は交換しない（★）

手入力はカメラを使わない。手入力で回っているブースは止まっていない。
交換すると、その端末が抱えている未送信データが取り残されるうえ、ブースIDの再設定
（設定用QRの読み直し）も要る。交換したほうが損をする。

あきらめる場面は、実際には非常に狭い。電池切れでも記録は消えないので、
交換した旧端末を充電して送信すればよい（当日中でなくてよい）。
物理破損だけが復元不能で、そのときも先方は数値の厳密さを求めていない（去年までブース横に手書き）。

これは仕組みではなく、当日の手順として伝える。未送信データを新端末へ移す機能は作らない。

---

7. データ

受け取らないもの：氏名／住所／電話／学校名／学年／写真／保護者の連絡先
→ カードに印刷されている以上のことをシステムに入れない。

制約

UNIQUE (チームコード, ブースID)

アプリで「有無を調べてから書く」形にしない。同時に来ると隙間ができるため、
データベース側の制約で弾き、2件目は静かに無視する。
テストが1ケースで済み、実装も1行で終わる。

---

8. 非機能要件

---

9. 技術構成

9.1 引き継ぎ可能性の確保（★本番日が動かないため）

11月29日は動かせない。 制作側が動けなくなった場合に備え、
協力エンジニアがいつでもコードを触れる状態にしておく。

アクセスは着手時に付与する（引き継ぎが必要になってから招待しても間に合わない）。

あわせて実装開始時に README.md を作る。
CLAUDE.md は「守ること」を書いた文書で、「どう動かすか」が書かれていない。

・ローカルで動かす手順
・デプロイのしかた（push するだけ）
・環境変数の一覧（値は書かない。在り処だけ）
・ファイル構成
・引き継ぐことになったら、まずこれを読む

9.2 RLSの方針

ブラウザから直接つなぐため、anonキーは公開される前提で設計する。

割り切っている点：ブース端末のURLを知った人が、書き込みを増やすことは技術的に可能。
ただし個人情報を持たず、金銭も動かず、集計のずれは先方が「気にしない」と明言しているため、
ここに費用をかけない。守るべきものの価値に見合った守り方をする。

QRに入るURLの形

https://trehan263.pages.dev/s/A7K2M

• QRの中身をURLにすることで、NFC非対応端末でもカメラから同じページに到達できる（追加費用ゼロ）
• ブースのアプリはURLからコードだけを取り出して記録する。ページは開かない
• サブドメインを短くするのは、QRの文字数を抑えて模様を粗くするため

---

10. スケジュール

★下記は「8月中に受注できた場合」の予定。発注前には着手しない（社内メモ §5）。
動作版 第1版は発注から約2週間。発注が遅れれば動作版 第1版以降も同じだけ後ろにずれ、
11月29日だけが動かないので、削られるのは「直す時間」。
★先方向けの書類にも、この前提を必ず書く（書かないと「9月20日発注でも9月15日動作版 第1版」という矛盾になる）。

★募集期間が 9/1〜10/15 のため、チームが確定するのは 10月15日。
カードの印刷はそれ以降になる（従来の想定より1か月半遅い）。

★こちらが握るのはCSVの提出時期だけ。チーム名を刷るなら10月下旬、刷らないなら9月中に出せる（＝Q23）。
印刷そのものの段取りは先方の担当範囲（先方の担当者が印刷業）。こちらから納期を心配しない。

---

11. 決定事項と、その理由（全37件）★来年の拡張時はここを読む

---

12. 未決事項

開発に影響するもの（★これだけ先に決まればよい）

技術の検証待ち

数量・段取り（開発の中身は変わらない）

解決済み

Q1（★1,100で確定。当初550としていたが、2026-09-04に先方が体験料を1,000＋100へ変更。この行が550のまま残っていた）／Q3・Q4（★カード1枚×1ブース＝1回。当初「1チーム×1ブース＝1回」で確定していたが、2026-09-04に先方要望で「子ども1人につき各ブースで1回」へ変更＝決定4。UNIQUE(card_code, booth_id) の定義そのものなので、ここを古いまま残すと次に読む人が実装を仕様違反と判断する）／Q5（チーム名のみ）／Q26（★チームの呼び名＝A：お申し込みで先方が決める。2026-08の先方回答）／Q7（30ブース）／
Q10・Q11（QRとNFCが同じURL）／Q12（12/31で削除）／Q16（印刷時にNFCへ書き込み）／
Q18（舞台と連携しない）／Q19（Cloudflare・専用ドメインなし）／Q22（画像は先方支給）／
**Q6（約140チーム・1チーム平均3名）／Q8（当日参加は受け付けない＝受付画面は不要）／
Q24（開催時刻はチラシ（役員会後版）を正とし12:00–16:00。打合せメモの13:00は古い情報）／
税金図鑑の項目リスト（先方は「9月中頃までに決定」。こちらからは「項目名だけ8月下旬・文章とイラストは9月末」とお願いした）**　← いずれも2026-08-04の先方回答で確定

---

13. リスクと対策

---

14. 変更の管理

14.1 3つの区分

14.1-b 先方へは「PDF」で渡す（★URLで渡さない）

scope・estimate・device-spec は PDF にして添付する。
とくに scope は不具合の判定基準なので、URLで渡してはいけない。
URLはこちらがいつでも書き換えられるため、先方が同意した基準が静かに変わる。
それは基準がないのと同じ。

★送ったあとに scope を直した場合は、何をどう変えたかを明示して PDF を再送する。
黙って直さない。CHANGELOG.md に記録する。

（trehan-scope.pages.dev は社内・平崎さん用の確認先として残す。先方には渡さない）

14.2 なぜ「不具合」を書面に紐づけるか（★重要）

「不具合」を定義せずに「無償で直します」と書くと、解釈の幅が残る。
「思っていたのと違う」がすべて不具合として持ち込まれ、無償対応が無限に続く。

そこで、不具合の定義を「制作範囲のご確認」§02 に固定する。

§02 に書いてある動作と違う → 不具合（無償）
§02 に書いていない → 調整、または仕様変更

★ 基準は、先方が手元に持っている書面でなければならない。
本書（要件定義書）は先方に配布しないため、これを基準にすると
先方は自分が同意した基準を読めない。 それでは定義がないのと同じ。

そのため §6 の内容を「制作範囲のご確認」§02 に書き出し、そちらを基準とする。
本書 §6 を更新したら、§02 も必ず同時に更新すること。

これは先方を縛るためではなく、両者が同じ基準で話せるようにするためである。
§02 を細かく書いておくほど、双方にとって判断が明確になる。

14.3 なぜ「回数」ではなく「時間」か

「2回まで無償」とすると、1回のなかに100件詰め込まれても1回と数えられてしまう。
実際にかかる手間は件数と量に比例するため、時間で区切るほうが実態に合う。

14.4 締切

• 8月31日 — 動作にかかわる要望
• 9月 — 8月中にいただいた要望を反映する期間（新規受付ではない）
• 10月20日 — 中身の差し替え
• ※ 発注が8月下旬以降になった場合は、発注日から2週間を目安に読み替える

なぜ早く聞きたいのか：着手後に前提が変わると、実装と確認をやり直すことになる。
着手前なら費用をかけずに織り込める。同じ要望でも、いただく時期によって費用が変わる。

---

15. 関連文書