kanto-event-collector

"Collect Kanto-area event data for the next 3 months and produce data/events.csv for the 「イベントボード」 dashboard's イベント tab. Use when the user asks to update, refresh, or regenerate the event dashboard data, run the weekly event collection, or rebuild events.csv. Also use when they invoke this by name or reference the weekly event-gathering routine. Walks the venue roster in data/spots.csv to re-verify every previously collected event (still running? extended? cancelled? price or coupon changed?) while discovering new ones in the same pass, searches beyond the roster for events at unregistered venues, compares prices across booking platforms (asoview!, Klook, KKday, VELTRA and others), detects active coupons and sales, records the cheapest legitimate booking link alongside the official site, and grows the venue roster itself as new places are found."

the-ready 1 Updated 3w ago

GitHub

Install

npx skillscat add the-ready/player-one/kanto-event-collector

Install via the SkillsCat registry.

SKILL.md

関東イベント収集タスク（週次）

このタスクの目的

data/events.csv を更新し、ダッシュボード「イベントボード」のイベントタブに今週の利用者が実際に行けるイベントを並べること。

単なるイベント名の羅列ではない。利用者がこの一覧を見て「これに行こう」と決められるだけの情報——何が目玉なのか、いくらなのか、どこで買うのが一番安いのか——を揃えることがゴールである。

とりわけ価格比較とクーポン検知は、このダッシュボードが単なるイベント一覧を超える価値の中心である。同じチケットが公式・asoview!・Klook・KKday等で異なる価格で売られ、各社が不定期にクーポンを配信している。この比較を毎回自力でやる利用者はいない。代わりに調べておくことが、このタスクの最も重要な仕事だと認識すること。

このタスクは3つの問いに答える。

前回載せたイベントは、いまもその内容のままか —— 会期は延びていないか、中止になっていないか、料金・クーポンは変わっていないか
前回になかった新しいイベントは何か —— 定点観測先だけでなく、名簿に載っていない会場のものも含めて探す
それはいくらで、どこで買うのが一番安いのか

1つ目を落とすと、終わった催しが載り続け、開催中の催しが黙って消える。
2つ目を名簿の中だけで済ませると、花火大会・商業施設の催事・寺社の祭事といった
「名簿に載らない側」が構造的に漏れる。

取得してよいもの・いけないもの（着手前に読むこと）

このタスクは GitHub Actions の self-hosted runner から週3回（水木金）自動実行される。「人が調べているのと同じ」ではなく機械的なアクセスである。

robots.txt が Allow している範囲だけを取得する。 サイト単位ではなくURL単位で見る
収集後に拒否の意思が示されたと分かったサイトは、由来する行を消し、data/sources.json からも外す
利用規約で自動収集・データの二次利用を明示的に禁じているサイトは使わない
会員登録・ログインが要る領域には立ち入らない（無料会員でも同じ）
同じホストへ続けて当たらない（待つのは fetch_gate.py の仕事で、自分で数える必要はない）
1サイトあたりの取得は、その週の調査に要る分だけ

判断に迷ったら取らない。 1と2が礼儀ではなく著作権法47条の5の政令基準に対応すること、
3を別項にしてあるのは30条の4が契約を上書きしないためであること、判定に
Claude-User と Claude-SearchBot の厳しいほうを採る理由——これらは
docs/COLLECTION-PROTOCOL.md 第6.5節に全部書いてある。判断に迷ったらそこを読む。

着手前：使えないサイトを一望する（検索予算を消費しない）

python3 tools/check_robots.py                  # data/sources.json の調査元サイト
python3 tools/fetch_gate.py --roster spots   # 名簿のURL（この工程の主な取得先）

どちらも robots.txt だけを見る軽い確認なので、検索予算を消費しない。拒否と出たURLは今回の収集から外す。

取得のたび：URLごとに判定し、間隔を空ける（自動で走る）

サイトのトップが「OK」でも、これから開くページが Allow されているとは限らない。
tools/fetch_gate.py が PreToolUse フックに登録してあり、WebFetch のたびに自動で走る。

拒否されたURLはブロックされる。 別ページを当たるか、その行を落とす。回避しようとしないこと
許可されたURLは、必要な待ち時間を消化してから通る。 自分で数えて待つ必要はない
「次の取得まで N 秒必要」と断られたら、先に別のホストを回る（Crawl-delay: 120 のサイトが実在する）

python3 tools/fetch_gate.py --check <URL>   # 判定だけ（待たない・記録しない）

curl でページ本体を取りに行かないこと。 ゲートを迂回することになる。
ページの内容が要るときは python3 tools/fetch_page.py <URL> --text を使う——
ゲートを通したうえで本文だけを取る正規の手段である（下記「検索を使わずに済ませる」）。

拒否されている先でも、許可された経路があることがある。 connpass は
Disallow: / だが Allow: /*.ics を併記しており、
https://connpass.com/event/{id}.ics は取得してよい（fetch_page.py --ics で読める）。
「このサイトは拒否」で止めず、robots.txt が何を開けているかを見ること
（docs/COLLECTION-PROTOCOL.md 第6.5.8節）。

実行時の出力について

このタスクはユーザーとの対話ではなく、システムが定期的に自動実行するものである。あいさつ・前置き・確認や提案といった会話的な文章は書かず、タスクの遂行に必要な情報（進捗のログ、最終的な集計結果など）だけを出力するようにしよう。

完走条件 —— このタスクをどう終えるか（着手前に読むこと）

このタスクは「調べ終わったとき」ではなく、終了工程を通したときに終わる。

終了工程（省略不可）

2〜7 は python3 tools/close_run.py events の1回でまとめて通す（中止・改名の処分 prev_rows.py events --dispose だけは判断が要るので、先に済ませておく）。1コマンドずつ打たないこと——終了工程は親の文脈がいちばん膨らんだ時点で走るので、1回打つごとに200〜300kを送り直す（2026-09-25 の lives は最後の波の後に72ターン回り、その回の消費の53%を終了工程に使った）。落ちたら、まとめに出たものだけを直してもう一度回す。調べたうえで少ない都県・薄い列は --allow-short / --allow-thin をこのコマンドに付けて承知する。承知はこの回のあいだ記録され、終了前フックにも効く。

#	やること	コマンド
1	手元に残っている調査済みの行を書き切る	`python3 tools/append_rows.py events`
2	終了日を過ぎた行を機械的に取り除く（通常0件）	`python3 tools/purge_ended.py events`
3	終わった・改名した行に理由を付けて取り除く	`python3 tools/prev_rows.py events --dispose`
4	名簿を整理する	`python3 tools/roster.py spots --gc`
5	差分を確定する（終了コード0）	`python3 tools/diff_data.py events`
6	検証する（ERROR 0）	`python3 tools/validate_data.py`
7	充足率と分布を出し、下限を判定する	`python3 tools/report_stats.py events --check`
8	報告を出力する	——

この8つはすべてローカルのコマンドで、Web検索を1回も使わない。 つまり検索の予算が尽きていても、コンテキストが逼迫していても、終了工程は必ず実行できる。「予算が尽きたので終わります」という終わり方に、正当な理由は存在しない。

2 はステップ0の --carry-rest --apply が既に同じ処分をしているので、通常は0件で通る。 残してあるのは、調査中に書いた行が終了日を過ぎている場合の保険としてである。以下は、この工程がもともと何のために置かれたかの説明である。

2 は「まだ確認できていない行」の保険であって、1・3の代わりではない。 会期末が近い行はステップ0で tier A に分類され、本来はステップ1〜4の中で公式情報に当たって「本当に終わったか」を確認すべきものである。だが検索予算やコンテキストが尽きて確認が間に合わなかった行は、終了日を過ぎたまま気づかれずに残ることがある——表示側は終了日から毎回「終了」を計算して既定の一覧から隠す（設計書第5.4.1節）ので利用者の目には触れないが、CSVの中には残り続け、週を追うごとに積み上がる。purge_ended.py は「終了日が今日より前か」という一点だけを機械的に見て、そういう行をここで刈り取る。判断が要らないぶん --dispose より先に置いてあり、消した行には expired という処分が自動で付くので、3 で個別に扱う必要はない。確認できた行を ended として --dispose するほうが、この自動処理より常に望ましい。 expired は「確認できないまま終了日だけが過ぎた」という、確認不足のしるしだからである。

やってはいけない終わり方

❌ --init した後、追記が途中のまま終える（ダッシュボードに残るのは書けた分だけになる）
❌ 調査結果をコンテキストに溜めたまま終える（追記していない行は、最初から無かったのと同じ）
❌ diff_data.py / validate_data.py を通さずに終える
❌ 「予算が尽きたのでここまでにします」と述べて、終了工程を飛ばす
❌ 報告を出さずに終える

--init は data/events.csv を空にする。 ただしステップ0の --carry-rest --apply を通した時点で、CSVは先週の完全な状態に戻っている——そこから先の打ち切りで失うのは「今週増やせたはずの分」だけである。逆に言えば、ステップ0を通す前に終えると、その週の収集はまるごと失われる。

自動実行のスクリプト（.claude/scripts/claude-routine.sh）は、diff_data.py と validate_data.py が通らなかった回をコミットせず、data/ を実行前の状態に戻す。

撤退の手順 —— 打ち切りは「中断」ではなく「終了工程へ進むこと」

調査は打ち切ってよい。次のどれかに当たったら、その場で探索をやめて下の手順に入る。

工程ごとの枠（「調査予算」）を使い切った
検索の合計が150回に達した（枠の合計170回のうち、20回を余裕として残す）
コンテキストが逼迫してきた
情報源に到達できない状態が続く（取得の失敗が連続する）

ステップ0を通してあれば、撤退は「中断」ではなく「今週の上積みをここで止めること」である。
CSVは既に先週の完全な状態にあり、そこに今週わかったぶんが乗っている。前回行を
慌てて書き戻す工程はもう無い——だから撤退の手順は短い。

調査済みで未追記の行を append_rows.py で書き切る
子が書いた temp/dispose-events-*.jsonl（今回の波のぶんだけ）を python3 tools/prev_rows.py events --dispose に通す（cat temp/dispose-events-*.jsonl | python3 tools/prev_rows.py events --dispose。エラーで止まったら、その行を直すか外してやり直す）。これを飛ばすと、中止になった催しが載り続ける
python3 tools/diff_data.py events --allow-unexplained --allow-noop で差分を一覧する（出力を切らない）
[表記が変わった可能性] に挙がった組だけは片付ける（ここから先は検索を使わない）
- 同じ催しだと分かる組 → --dispose に renamed として記録する。放っておくと
  旧uidの持ち越し行と新uidの新規行が両方とも公開される（ステップ5の説明を参照）
- 判断が付かない組 → そのままでよい。来週 tier A で見直す
終了工程の 2〜8 を通す
報告に「どの工程を、どの理由で打ち切ったか」「今週あらたに書いた行数」「埋められなかった列」を書く

--carry-rest --apply を撤退時に打ち直す必要はない。 ステップ0で既に通っており、
もう一度走らせても「今回書かれていない前回行」は残っていないので何も起きない。

進捗はツールが出す（自分で書かなくてよい）

append_rows.py が追記のたびに、次の1行を標準エラーへ出す。自動実行のログに残り、
途中で止まったときに「どこまで進んだか」を人間が判別できる唯一の手がかりになる。

[進捗] 追記8件（累計34件）/ 検索 63/170（残り107） / 取得 154（うち拒否2） / 待機 12分 / 経過 96分/360分（残り264分）

工程名を添えたいときは、工程の切り替わりで python3 tools/budget.py --phase "<工程名>" を打っておく。

出力仕様

出力先

data/events.csv のみ（全件を毎回書き直す。追記ではなく完全再生成）。index.html はこのタスクでは編集しない
ダッシュボードは data/events.csv を Web サーバー経由で取得する前提で作られており、file:// で直接開く運用は想定していない

書き出し先に注意: ダッシュボードは data/ 配下しか読まず、別パスへのフォールバックを意図的に持たない。リポジトリのルート直下に events.csv を書いても反映されず、古い表示が残る。

このタスクは data/spots.csv（イベント施設の名簿）も更新する。手順は「ステップ1」「ステップ2」と docs/COLLECTION-PROTOCOL.md 第7章を参照。

初期化（省略不可・親のみ実行）

調査開始前に、次を実行して data/events.csv をヘッダーだけの状態にする。このコマンドは親だけが実行する。サブエージェントは実行しない——サブエージェントに実行させると、他の波が書いた分もろとも消える。

python3 tools/append_rows.py events --init

このとき前回の内容は data/.prev/ に自動退避される（差分検知の材料になる。順序を気にする必要はない）。

出力方法（CSV書き出しの手順）

全件を最後にまとめてCSVに書くのではなく、調査の区切りごとにバッチで追記する。全件を調査結果としてコンテキストに溜め込んでから最後に一括生成する、という進め方はしないこと。

5〜10件の調査が完了するごとに、結果をまとめて以下の形式でCSVに追記する

python3 tools/append_rows.py events <<'EOF'
{"title": "...", "cats": "...", "area": "...", ...}
{"title": "...", "cats": "...", "area": "...", ...}
EOF

コンテキストに全件のデータを保持する必要はない。追記が終わったバッチの内容は忘れてよい（次の調査のためにコンテキストを空ける）
id はスクリプトが自動採番する。JSONに含める必要はない
JSONに含めない列は空文字で補完される。分かっている列だけを渡せばよい
全件の調査・追記が終わったら python3 tools/diff_data.py events と python3 tools/validate_data.py を実行する

自然なバッチの区切りの例：

「東京の美術館」を5館調べたらまとめて書く
「神奈川のテーマパーク」を6件調べたらまとめて書く
調査ステップが変わる節目（施設調査→未登録会場の探索→横断サイト補完）でまとめて書く

前回から変わっていない列は書き直さない（持ち越し）

座標・最寄り駅・駐車場・読みに加え、desc cats area official_url series_id も前回値から自動で補完される（会期中に動かない事実なので、書き忘れても消えない）。空欄のまま渡してよい。

内容にも変更がないことを確認できた行は、"_carry": "*" を添えると note も前回値で埋まる。

python3 tools/append_rows.py events <<'EOF'
{"title": "...", "venue": "国立西洋美術館", "start_date": "2026-07-07", "end_date": "2026-09-23",
 "cats": "art", "area": "東京都・台東区",
 "pref": "tokyo", "price": "一般2,300円", "source": "公式サイト", "url": "https://...", "_carry": "*"}
EOF

日付・時刻・料金・受付・クーポンは持ち越せない。 onsale_end や price_best を _carry に指定するとスクリプトがエラーで落ちる。前回の締切をそのまま書き写すことは、このスキルが禁じている「確認していない値を書く」そのものだからである。確認できないなら空欄にする。

"_carry": "*" を使ってよいのは、その行の内容に変更がないことを実際に確認できたときだけである。「たぶん変わっていない」で使わない。

desc だけを持ち越すこともできる。 料金や会期だけを再確認して他は変わっていない行では、"_carry": "*" の代わりに "_carry": "desc"（desc を渡さず空欄のまま）と書けば、desc だけ前回値で埋まり、他の列は今回書いた値がそのまま使われる。

desc は、良い前回値があるなら書き直すより持ち越すほうが常に安全。 _carry は空欄の列にしか効かないため、たとえ一言だけでも新しい値を書けばそれで前回の説明は失われる。会場の「今月のイベント一覧」のような一覧ページの一文だけを見て desc を書き直さないこと——一覧ページは新規行の発見・日程の再確認には向くが、desc の材料としては薄すぎる。目玉の中身に変更が無いなら desc は空欄で渡し _carry に含める。新しく書く場合も、前回より内容の薄い説明で上書きしてはならない（append_rows.py が前回の半分未満に縮んだ書き直しを WARNING で検知する）。

CSV列（この順序・この列名を厳守）

id,title,kana,cats,area,venue,venue_url,pref,start_date,end_date,date,dates,open_time,start_time,end_time,date_note,backup_date,status,rank,series_id,announced_date,is_additional,onsale_label,onsale_start,onsale_start_time,onsale_end,onsale_end_time,limited_sale,price,price_official,price_best,discount_pct,best_source,coupon_note,price_checked,price_condition,source,url,official_url,lat,lng,desc,note,parking,nearest_station

全45列。列名・順序ともに厳守すること。空欄でよい列は多いが、列そのものを省いてはいけない（ヘッダーが1列でもずれると検証で落ちる）。

書き終えたら python3 tools/validate_data.py を実行し、ERROR が0件であることを確認すること。

列	規則
`id`	1から連番
`title`	正式名称。サイト独自の煽り文句は含めない
`cats`	下記8キーから該当するもの。複数は `art\|ent` のように `\|` 区切り
`area`	表示用の地名（例：`東京都・江東区`）
`venue`	会場・施設名。不明なら `-`。名簿（`roster.py spots --list`）にある施設は、名簿の名前の表記で書き始める（館内の会場を添えるなら、名前のあとに半角スペースか `（` を置く。例：`東京国立博物館平成館`）——収穫の記録はこの表記で名簿に紐づき、ずれると催しのある施設が「収穫ゼロ」として名簿から外される。ただし前回から続く行は前回の表記を変えない（`venue` は行の識別に使うので、変えると別の催しとして旧行と二重に載る）
`pref`	`tokyo` `kanagawa` `saitama` `chiba` `ibaraki` `tochigi` `gunma` のいずれか
`start_date` / `end_date`	`YYYY-MM-DD`。不明なら必ず空欄。推測で埋めない。単日開催なら両方に同じ日を書く——`end_date` の空欄は「終了日が未定（まだ続く）」の意味になり、終わったあとも「開催中」と表示され続ける
日程のその他の列	`dates` `open_time` `start_time` `end_time` `date_note` `backup_date` `date` `status` `rank` は下記「日程の書き方」を参照。表示用の日付文字列は書かない
`price`	実際の料金（例：`おとな2,800円／小中学生1,300円`）。一覧ページに無ければ会場の料金ページを1回開く（下記「価格比較とクーポン検知」章の第1段階）。それでも分からなければ空欄。`要問合せ` と書いてよいのは公式がそう案内しているときだけ
`source`	出典サイト名。URLではなく、人間が読める短いサイト名を書くこと（例：`asoview!` `Klook` `公式サイト` `ウォーカープラス`）。ダッシュボードはこの値をボタンのラベル「{source}で予約する」にそのまま使うため、URLを書くと「https://...で予約する」と表示されてしまう。複数の出典がある場合は、`url` に採用したサイトの名前だけを書く
`url`	最安で予約できるページ（下記「最安リンクの選定」参照）
`official_url`	公式サイト。見つからなければ空欄（推測URLを書かない）
`price_official`	公式の正規料金（大人1名・円・数値のみ）。例：`2800`
`price_best`	最安経路の総額（手数料込み・大人1名・円・数値のみ）。例：`2380`
`discount_pct`	割引率（整数%）。`price_official` と `price_best` が両方揃った時のみ記入
`best_source`	最安を提供しているサイト名。例：`Klook`
`coupon_note`	配布中クーポン・条件付き優待の説明（下記「クーポン検知」参照）
`price_checked`	価格を確認した日 `YYYY-MM-DD`。価格を1つでも書いたら必須
`price_condition`	割引の適用条件（例：`JAF会員のみ` `平日限定`）。条件付きの割引を書いたら必須（下記「適用条件」参照）
`lat` / `lng`	会場の代表座標（小数4桁程度）。`data/spots.csv` に載っている会場は空欄で渡す（名簿と前回値から自動補完されるので調べない）。調べるのは、名簿にも前回にも無い新しい会場だけ——手順は下記「会場の座標（`lat`/`lng`）の調べ方」。書くときは両方そろえること（片方だけでは地図に出せない）
`desc`	100〜150字程度。目玉が何かを具体的に書く（下記「descの書き方」参照）
`note`	利用者への注意書き（例：`雨天中止` `未就学児は入場不可`）。無ければ空欄

日程の書き方（3つの収集スキルで共通）

画面に出る日付の文字列も、開催中 まもなく開催 といった開催状況のバッジも、
ダッシュボードが表示のたびに組み立てる。ここで書くのは、機械が読める事実だけである。

列	規則
`dates`	飛び日程（連続していない複数日）の実開催日を `\|` 区切りで全部並べる。例：`2026-08-10\|2026-08-11\|2026-08-14`。連続した会期では空欄（開始日〜終了日で足りる）。書くときは先頭を開始日と、末尾を `end_date` と一致させること。この列があると、開催しない日は「本日は休み」と表示され、日程の絞り込みからも外れる
`open_time`	開場時刻 `H:MM`。無ければ空欄
`start_time`	開始時刻 `H:MM`。無ければ空欄
`end_time`	終了時刻 `H:MM`。無ければ空欄
`date_note`	上のどれにも収まらない但し書き（例：`オールナイト` `土日祝のみ` `1週間限定` `毎朝10時開始`）。日付や時刻そのものをここに書き写さない——構造化列に入れれば画面が組み立てる
`backup_date`	予備日（雨天・荒天で順延したときの日）を `\|` 区切りで。会期には含めない——本開催で終わればこの日は使われないので、`end_date` を1日延ばすと「まだやっている」と嘘をつくことになる。カードの日付欄ではなく「くわしく」の中に出る。予備日の当日は「本日予備日」バッジが出るので、順延が実際に起きたら開始日・終了日を新しい日に書き換えてこの列を空にすること
`date`	原則として空欄。 ISOの日付に落とすと持っていない精度を騙ることになる日程（`2026年10月中旬〜下旬（見頃予想）` `8月の毎週土日` など）だけ、ここに自由記述で書く。書いた行はこの文字列がそのまま表示され、上の構造化列は使われない。ただし月・季節までは読み取れる場合、`start_date`/`end_date` にはその月・季節をまるごと設定すること（下記「幅のある予測日程」参照）——空欄のままだと日程の絞り込みが「無期限」として扱い、無関係な日で絞っても表示されてしまう
`status` / `rank`	原則として空欄。日付から毎回計算される。開始日も `end_date` も持たない行——つまり `date` に自由記述を書いた行——でだけ、下の表から選んで書く

なぜ表示用の文字列を書かないのか。 以前は date に表示用の文字列を、status に
収集した日の判定を書いていた。書き手ごとに表記がそろわず（同じ会期が 2026.8.1〜9.30 にも
2026年8月1日〜9月30日 にもなる）、しかも収集した日で時間が止まる——週の後半に見た人には、
始まっているものが「まもなく開催」のまま残る。どちらも「計算できる値を、計算せずに書き置いた」
ことが原因である。書いた値が画面に出ないのは気持ちが悪いかもしれないが、書かないほうが正しい
（設計書第3.9節）。

幅のある予測日程（「10月中旬〜下旬」「2026年夏」など）は、`date` だけでなく `start_date`/`end_date` も埋める

date に自由記述を書く行のうち、月・季節までは読み取れるものは、start_date/end_date を
空欄のままにしてはいけない。空欄は「本当に何も分からない」の意味になり、日程の絞り込みが
一切効かなくなる——10月開催のイベントが8月の日付で絞っても一覧に出てしまう。
読み取れた月・季節をまるごと設定する（精度は落ちるが、誤って除外するより実害が小さい。第3.9.6節）。

読み取れた期間	`start_date`	`end_date`
10月中旬〜下旬	`2026-10-01`	`2026-10-31`
2026年夏	`2026-06-01`	`2026-08-31`

date 列の表示はそのままでよい。埋めた行は status/rank を空欄に戻すこと。
月すら読み取れない行（「会期は公式サイト参照」）は両方空欄のままにする——
読み取れる情報が無いところに月を割り当てるのは、それこそ憶測になる。

python3 tools/validate_data.py は、date に「◯月」「春」「夏」「秋」「冬」を含む自由記述があるのに
start_date/end_date が両方空の行を WARNING で挙げる。出たら必ずこの手順に従うこと。

新しく追加された列（以前の版には無かったもの）

列	規則
`kana`	タイトルの読み（ひらがな or カタカナ）。漢字のイベント名を「かな」で検索できるようにするための列。表示には使わない。例：`title` が `隅田川花火大会` なら `すみだがわはなびたいかい`。読みが自明でない固有名詞（施設名・作品名）だけでよく、全件必須ではない
`venue_url`	会場・施設そのものの公式サイト。イベントページ（`official_url`）とは別。無ければ空欄
`series_id`	巡回展・複数会場開催をまとめるキー（例：`s-gogh2026`）。同じ企画が会場を変えて回る場合、全行に同じ値を入れる。1会場だけの企画は空欄
`announced_date`	そのイベントを公表・掲載した日 `YYYY-MM-DD`。7日以内なら画面に `NEW` バッジが出る。分からなければ必ず空欄（憶測で新着にしない）
`is_additional`	追加開催・会期延長が決まった行は `1`、それ以外は空欄
`onsale_*` / `limited_sale`	事前予約・抽選・整理券の受付期間（下記「受付期間の書き方」参照）。当日ふらっと行けるイベントは全部空欄でよい
`parking`	会場の駐車場情報（下記「駐車場・最寄り駅の書き方」参照）
`nearest_station`	最寄り駅と徒歩時間（下記「駐車場・最寄り駅の書き方」参照）

カテゴリキー

キー	対象
`art`	展示・アート・美術館企画展
`exp`	体験・アクティビティ・ワークショップ
`food`	グルメ・フードフェス・ビアガーデン
`ent`	アニメ・キャラクター・エンタメ
`fam`	ファミリー・キッズ向け
`tech`	IT・テクノロジー分野のカンファレンス・勉強会・展示会（内容がIT以外なら、講演会・報告会という形式だけでは入れない）
`sport`	スポーツ観戦・大会
`fest`	祭り・花火大会

収集ルール

1. 対象期間は「直近3ヶ月のみ」

実行日から3ヶ月後までに開催されている、または開催が始まるイベントのみを対象とする。

✅ 実行日時点で開催中のもの（終了日が3ヶ月以内でも以降でも可）
✅ 3ヶ月以内に開始するもの
❌ 3ヶ月より先にしか始まらないもの → 含めない
❌ すでに終了したもの → 含めない

理由: 遠い予定は詳細・料金が未確定なことが多く、一覧の判断材料にならない。件数だけ膨らんで「今週どこに行くか」という主目的を薄めてしまう。

2. 対象地域は関東1都4県

東京都・神奈川県・埼玉県・千葉県・茨城県。

栃木県・群馬県は対象外（2026-08時点。以前は1都6県だったが、実測で
Haikuによる収集の質がこの2県で特に低かったため範囲を絞った）。pref 列に
tochigi gunma を書かないこと——ダッシュボードのスキーマ自体（config.js
のPREFS）は他タブ（ライブ・映画）が引き続きこの2県を対象にするため変えて
いないが、イベントタブの都県チップにもこの2県は出ない（TABS.event.prefKeys
で絞ってある）。

ダッシュボードの距離フィルタが関東を対象にしているため、それ以外の地域を入れても絞り込めない。

調査順序：東京都→神奈川県→埼玉県→千葉県→茨城県の順に着手する。ステップ1・ステップ2はこの順で都県を回り、サブエージェントに分けて調べる場合も優先順位の高い都県から先の波に割り当てる。時間や予算が尽きたときは、この順の末尾（茨城→千葉→埼玉→神奈川→東京）から間引く——「予算が尽きたら、何を捨てるか」参照。

3. 目標件数

50〜100件を目安とする（1都4県に絞ったぶん、以前の60〜120件から下げてある）。
少なすぎると一覧の意味がなく、多すぎると1件あたりの調査が浅くなる。

各都県から最低5件は拾い、東京に偏りすぎないようにすること（東京は全体の40%程度を上限の目安とする。超えそうなら、そこで東京の調査を打ち切り、残りの枠を「調査順序」の他都県に回す）。

4. カテゴリのバランス

8カテゴリすべてから最低3件ずつ拾う。art と ent に偏りやすいので意識的に、food fest sport tech も探すこと。

ただし、枠を埋めるために内容の合わないイベントを押し込まない。 該当するイベントが本当に少ない月は3件に届かなくてよい——形式（講演会・報告会等）ではなく内容で判断する（2026-09-22、動物園のゴリラ保全報告会がtechに誤分類された事例）。

調査予算 —— 検索は有限である（着手前に読むこと）

Web検索の呼び出しは、1セッション200回で打ち切られる。 超えた時点で、以降の調査は
中途半端な場所で止まる。

したがって「たくさん調べる」ことは品質ではない。予算をどこに使うかが品質である。

工程ごとの検索の枠

この表を守れば、セッション全体の回数を数える必要はない。工程の中だけで数え、
枠を使い切ったらその工程を終える。

工程	検索の枠	備考
ステップ0〜0.5 土台・棚卸し	0	ローカルのコマンドだけ
ステップ1 施設ベースの網羅調査	10	名簿のURLに直行するので、検索が要るのは `url` が空欄の施設だけ
ステップ2 エリア軸の探索	20	5都県 × 4クエリ
ステップ3 横断サイトでの補完	12
ステップ4 各イベントの深掘り	60	新規行のみ。前回から続く行は前回の `official_url` に直行する
ステップ4.5 いま載っている行の欠けを埋める	0	前回行の `url`/`official_url` に直行する。検索が要るときは予備から使う
価格比較・クーポン	25	うちクーポン一覧の定点観測が約8回（各社1回ずつ）
予備	43	想定外の調べ直しに使う（5都県化で浮いた8回をここに足した）
合計	170	上限200に対して30回の余裕を残す

消費は自分で数えない —— `budget.py` が実測を持つ

python3 tools/budget.py --phase "ステップ2 エリア軸の探索"   # 工程の切り替わりで打つ
python3 tools/budget.py --report --verbose                   # 工程別の内訳（報告にそのまま貼る）

[予算] 検索 63/170（残り107・上限200） / 取得 154（うち拒否2） / 待機 12分 / 追記 34行 / 経過 96分/360分（残り264分）

枠を超えたかどうかは、この出力で判断する。記憶で判断しない。 数えるのはフックの仕事なので、
自分で数える必要はない（理由は docs/COLLECTION-PROTOCOL.md 第8.7節）。

上の枠表は検索の枠だが、実際に多いのは取得のほうで、時間の律速もそちらにある
（fetch_gate.py が Crawl-delay を消化するため）。「次の取得まで N 秒必要」と断られたら、
待たずに先に別のホストを回る
時間で「まだ余っている」と判断しない。 枠は6時間あるが、実際に実行を止めるのは
トークンのほうである。2026-08-26 の回は経過39分・検索14/170という表示の9分後に、
アカウントの利用上限で強制終了された（docs/COLLECTION-PROTOCOL.md 第8.7.1節）。
唯一の完走例も27分で終わっている（かつてここに書いていた「5時間27分」は、
失敗した起動から数えた誤りだった）
見るのは budget.py --report の [利用率] の行。 サブスクリプションの実際の利用率（5時間枠・7日枠）で、
claude-routine.sh が数分おきに測り直している。2段階の線がある。
- 5時間枠80%・または7日枠が「後の回の分を残す線」「新しい波を投げないでください」→ 動いている波は受け取って書き切り、終了工程へ
- 5時間枠92%・または7日枠96%「撤退の手順に入ってください」→ 新しい調査はやめ、終了工程だけを通す
  撤退が出たら終了工程を通し切る余力を残して「撤退の手順」に入ること
- 利用率が読めないときだけ、代わりに文脈再送の線（45M／60M）で同じ判定をする。
  文脈再送は2026-09-30まで応答1回をブロックの数だけ重ねて数えており（実際の約2倍）、
  線に届いたように見えても実際の利用率には大きな余りがあった

検索を使わずに済ませる（最も効く節約）

1回の取得から複数の行が取れる経路を優先する。 どれも WebSearch を消費しない。

経路	何が取れるか
`roster.py --list --urls` / `prev_rows.py --uid`	調査先のURL・前回の `official_url`（知っているURLを検索し直さない）
`fetch_page.py <URL>`	そのページから何が取れるかの要約。次の手はこれを見てから選ぶ
`fetch_page.py <URL> --schedule`	日付を含む行と、その日にぶら下がる行だけ。会場・劇場のスケジュールページはまずこれ（本文が3〜4割に減る）。欲しい興行が出ていなければ `--text` に戻す
`fetch_page.py <URL> --text`	本文だけ。表はタブ区切りで残る（`WebFetch` の markdown 化で崩れる一覧の構造が保たれる）
`fetch_page.py <URL> --links`	「文字列＋絶対URL」の一覧。一覧ページから詳細ページへ辿るとき
`fetch_page.py <URL> --sitemap --since <日付>`	その施設の新着ページだけ
`fetch_page.py <URL> --events` / `--ics`	日付・会場・中止/延期が構造化された形で

会場スケジュールのように「行と列の対応が意味を持つ」ページでも --text でよい。
セルはタブ区切りで残る。JSON-LD は期待するほど普及していないので総当たりしないこと（第6.5.9節）。

--raw（生HTML）は --out が無いと動かない。 実測した信号率は3%——216ページ・
3,190万文字を通したところ、本文は76万文字（42分の1）だった。残る97%はタグ・スクリプト・
トラッキングで、文脈を埋めながらモデルの想起精度を下げる。生HTMLが本当に要る場面
（__NEXT_DATA__ の取り出しなど）は --raw --out temp/page.html で落として grep する。

名簿にはほぼ全件にURLが入っている。知っているURLを検索し直さないこと。

python3 tools/roster.py spots --list --pref tokyo --urls

4列目にURLが出る。施設の調査はこのURLを直接開く。標準エラーに出る
「うちURL不明 N件」が、この工程で検索を使ってよい件数である。

前回から続いている行も同じで、前回の official_url を引けば検索は要らない。

python3 tools/prev_rows.py events --venue 東京国立博物館   # 前回の official_url が入っている

同じことを二度調べない —— 打ち切りの基準

必須列が揃った行は、そこで調査を終える。 すでに「行くかどうか」を判断できる情報が
揃っているのに調べ続けるのは、品質ではなく消費である。

区分	列	扱い
これが揃ったら終わり	`title` `cats` `area` `pref` `venue` `start_date`/`end_date` `price` `source` `url` `desc`（第0段階で比較対象と判定した行は＋`price_official` `price_checked`）	揃った時点で次の行へ移る
ついでに拾うだけ	`kana` `note` `venue_url` `series_id` `announced_date` `is_additional` `parking` `nearest_station`（初出の会場のアクセスだけは例外。下記「駐車場・最寄り駅の書き方」）	開いたページに書いてあれば書く。このために追加でページを開かない
調べない	`lat` / `lng`	名簿と前回値から自動で補完される（下記）

具体的にやってはいけないこと

❌ 会場ページで会期・料金・アクセスを確認した後、座標のためにもう一度地図を開く
❌ 前回と同じ内容だと確認できた行について、desc の材料を集め直す（_carry で持ち越す）
❌ kana や series_id が分からないので検索する（分からなければ空欄が正しい）
❌ 同じ会場の別イベントのために、その会場のアクセス情報を調べ直す（前回値・他行から補完される）
❌ 無料イベントについて割引を探す（下記「第0段階」）

予算が尽きたら、何を捨てるか

上から守り、下から捨てる。

tier A の再確認（落とすと終わった催しが載り続け、中止を伝えられない）
エリア軸の探索（落とすと名簿に載らない側が構造的に漏れる）
価格比較の第0〜1段階（対象かの判定と公式料金。下記「今週かならず産む成果」）
新規行の深掘り
価格比較の第2段階（下限の15件までは、ここも守る）
tier B の再確認
価格比較の第3段階・補助列の穴埋め ← 最初に捨てるのはここ

3・5 と 7 を分けてある。 以前はまとめて「価格比較」として最下位に置いていたが、
このスキルは同時に価格比較を「このタスクの最も重要な仕事」と宣言していた。
中核だと言った層を最初に捨てる順に置けば、実行時は必ず捨てる側が勝つ。
実測でも price_best は113件中6件（5%）、coupon_note は2件（1%）まで痩せていた。
捨ててよいのは第3段階の深掘りだけで、第0〜1段階（判定と公式料金）と第2段階の下限は捨てない
——第0段階は取得0回、第1段階は公式ページを開けば同じ取得で済むためである。

「tier A の再確認」「エリア軸の探索」を都県単位で削るときは、「調査順序」の末尾（茨城→千葉→埼玉→神奈川→東京）から間引く。 東京は優先順位が最も高いので、最後まで残す側に置く。

目標件数に届かないことより、未検証の行を足すことのほうが重い失敗である。
打ち切ったら、その事実と工程名を報告に書く。

予算に余裕があるなら、何を厚くするか

上の「捨てる順」は予算が足りないときの縮め方であり、余っているときにそのまま畳んでよい理由にはならない。python3 tools/budget.py --report で「文脈再送」が45M（新しい波を投げないでください）に届いておらず、経過時間も6時間のうち一部にとどまっているなら、計画した波数をこなしただけで終了工程に入らない。

東京→神奈川→埼玉→千葉の順（茨城は除く）で、エリア軸の探索・横断サイト補完の追加の波を投げる。 この4都県は「調査順序」で最後まで残す側に置いてある＝新規の催しが最も濃い層である
追加の波は既存の波と同じ規則に従う（前の波を append_rows.py で書き切ってから投げる、独立予算工程は都県ベースの波に混ぜない）
2026-08-29 15:30 の実行は、経過18分/360分、文脈再送は最終値17.3M（25M線の約7割）で、まだ両方の線に届いていないまま4波で終了工程に入った。届いていない閾値を理由に畳んだのではなく、単に「予定した4波を終えたから」畳んでおり、エリア軸探索・横断サイト補完に割り当てた枠（合計32回）を使い切っていなかった

目安ではなく、budget.py --report の数字で判断する。 「まだ余っていそうだから」ではなく、実際の文脈再送と経過時間を見てから追加の波を決める。

今週かならず産む成果（下限）

捨てる順を決めるだけでは、何も産まない週を止められない。 下限を決めておく。

成果	下限	確認のしかた
対象層の公式料金	第0段階で「比較の対象」と判定した行の全件に `price_official`	`report_stats.py` の充足率
今週あらたに書いた行の `price`	新規行の85%以上（`report_stats.py --check` が終了コードで判定する）	`report_stats.py` の「今週あらたに書いた行の充足率」
第2段階まで進めた行	最低15件（対象層のうち、件数の多い順に）	報告に件数を書く
クーポン一覧の定点観測	A群7〜8社を各1回	報告に社名と、配布中だったものを書く

この3つは、予算が尽きても最後まで残す。 第0段階は取得0回で判定でき、第1段階は
公式ページを開いた同じ取得で済み、クーポン一覧は合計10回程度で終わる——
どれも「予算が無いからできなかった」が成り立たない工程である。

届かなかったときは、件数と理由を報告に書く（黙って0件で終えない）。
python3 tools/report_stats.py events が前回比を出すので、それを見て判断する。

再確認まで手が回らなかった tier C の行は、消さずに前回値のまま書き直してよい
（prev_rows.py --uid で全列を引ける）。ただし onsale_* と coupon_note は空欄にする
（--uid は全列を返すので、そのまま書き戻すと持ち越し禁止の列まで復活する）。
status/rank は表示側が日付から計算するので触らなくてよい。price_checked は前回の日付のまま書く（今日に更新しない。
「いつ確認した値か」を示す列なので、古いまま出すのが正しい）。詳細は
docs/COLLECTION-PROTOCOL.md 第8.5節。使った行数は報告に含めること。

並行して調べてよい —— ただし親が待ち切ること

都県や名簿を分割して同時に調べるのは、予算配分として正しい。縛るのは起動の形と、1回に背負う範囲である。

背景で起動しない。 run_in_background: false を明示する
（書かないと既定で背景起動になり、agent-guard.sh が拒否する）
親は、全ての結果を append_rows.py で書き終えるまでターンを終えない
サブエージェントは調査のみ。data/ には書かない。結果は temp/rows-<波の名前>.jsonl に自分で書き、返答にはそのパスと件数だけを書かせる
（行そのものを載せた返答は SubagentStop フック（reply_gate.py）が拒否し、書き直させる）
（rows- で始まる名前にすること。この名前だけを下のゲートが見る。作業用のファイルは別の名前にする。理由は docs/COLLECTION-PROTOCOL.md 第11.4節）
親はページを取得しない。 親の仕事は棚卸し・分割・起動・追記・検証だけで、fetch_page.py も WebSearch も子に任せる（第11.5節）
worktree 隔離を使わない（書き込まないので隔離する対象が無く、名簿の更新まで破棄される）
分けるのは取得先が重ならない軸で（都県・名簿の種別）。「日程係」「料金係」に分けると同じページを2回開く
エリア軸の探索（枠20回）・横断サイトでの補完（枠12回）は、都県ベースの施設再確認の波に混ぜない。 それぞれ独立した波として起動し、割り当てられた枠を使い切ってから次に進む。2026-08-29 15:30の実行は「茨城の施設再確認」「5都県分のエリア軸探索」「横断サイト補完」の3つを1つの波に混ぜて渡し、60ターンの枠を3つで分け合った結果、名簿に無い会場からの収穫が5都県合計で15件（枠32回に対して1都県あたり平均3件）にとどまった
都県で分けるときは、優先順位（東京→神奈川→埼玉→千葉→茨城）の高い都県から先の波に割り当てる。 後の波が打ち切られても、優先順位の高い都県はすでに調査済みの状態にする
1回の呼び出しに、調査軸1つの全体を背負わせない。 名簿の一部・対象期間の一部などに区切り、波——同時に起動して同時に受け取る1組——に分けて呼ぶ
1波の1体に渡す施設は10〜12件までにする。 都県をそのまま1体に渡さない。東京は名簿が約115件（2026-09-30）あるので、最初から10波前後に割り、3体ずつ同時に起動する（23区東部／西部／多摩、のように地理で割っても、名簿の並び順で割ってもよい）。子は maxTurns: 60 で打ち切られ、60ターンで開けるのは実測で28〜40回・6〜17サイトである（2026-09-27〜30、重複を除いた数え方）。22〜28施設を渡した波はすべて60ターンで打ち切られ、担当の半分以上に手が付いていなかった（09-30 の tk1 は22施設中11施設、tk2 は24施設中6施設しか行が無い）。以前は20〜25件としていたが、それは「109〜119ターン」という重複計上の表示を見て maxTurns が効いていないと誤読していた頃の目安である。2026-09-05 は東京105施設を1体に渡して188ターン、2026-09-06 は52施設・53施設の2波に割ってもなお「前回CSVの言い換え」に化けた——施設数が一定を超えると、子は実際の取得をやめて前回データの再出力に切り替わる。神奈川（約45）・千葉（約32）・埼玉（約29）・茨城（約26）も同じ上限で2〜4波に割る
1つの波の結果を全部 append_rows.py で書き切ってから、次の波を投げる。
```
python3 tools/append_rows.py events < temp/rows-<波の名前>.jsonl
```
書いていないと次の Agent 起動が拒否される（agent-guard.sh → wave_gate.py）。調べた行がCSVに入っているかを数えているので、追記の書き方（< でも cat | でも）は問わない。2026-08-27 の実行は、2つの波が90行を調べ終えてファイルに書きながら一度も追記せず、新規0件で差し戻された（あとで追記して流し直すと通る＝調査は成功していた）
波は subagent_type: "kanto-collector-worker" で起動する。 事前定義したエージェント（.claude/agents/kanto-collector-worker.md）で、maxTurns: 60 が入っている。general-purpose で投げると——subagent_type を書かないと既定でそうなる——この上限は一切効かない。指定の無い波は agent-guard.sh が拒否する
1体が回るターン数は60でハーネスが打ち切る。 取得回数ではなくターン数で数えること——2026-08-27 の実測は取得202回に対しターン426回で、--help の読み直しや作業用スクリプトがその差である。担当範囲を小さく割れば下がる。budget.py --report が「最長の子◯ターン」を出す（第11.6節）。打ち切られるのは応答であってファイルではないので、子に「1件書けるたびに temp/rows-*.jsonl へ追記する」と守らせておけば、そこまでの成果は必ず残る（下の項目1）。2026-09-05 の events は1体が188ターン、2026-09-17 の movies は1体が167ターン回り、どちらも文脈再送を使い切って残りの工程を一度も実行できずに撤退した——目安として書いてあるだけでは守られなかったので、上限そのものを起動の形に移してある
波を投げる前に python3 tools/budget.py --report を見る。 投げてしまうと、動いている子に割り込む手段が無い。「新しい波を投げないでください」が出ていたら、そこで探索を終えて終了工程へ進む
1波の体数は自分で数えなくてよい。 CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS が上限を与える（このスキルは3体）。超えた起動は Concurrent subagent limit reached で失敗する

spots.csv の施設は多数のホストに分散している（python3 tools/roster.py spots --list --urls | wc -l で件数を確認）ので、3体を都県で分けてもホストは競合しない。

背景起動を禁じている理由——4体ぶんの調査結果が誰にも受け取られないまま破棄された実例——と、
前景でも1回の範囲が大きすぎると同じことが起きた実例（2026-08-20、movies）は
docs/COLLECTION-PROTOCOL.md 第11章にある。体数をホスト数から決めてある理由は第11.2節。
結果をファイルで受け渡す理由は第11.4節、親が取得しない理由は第11.5節、1体が背負う取得回数を区切る理由は第11.6節にある——3つとも、2026-08-26 に開始50分でアカウントの利用上限に当たった実行の内訳から来ている。

サブエージェントへの指示に必ず含めること（省略禁止）

2026-08-21 にHaikuで実行した実測では、指示にこれらが無かったために15体中3体がJSONLを1件も返さず（うち1体は再要請しても直らず8件が回復不能のまま失われた）、会期が残っている前回行80件を再発見できず、announced_date note の充足率が0%になった。次の5項目は、都度書くのではなく指示のテンプレートに固定で含めること。

SKILL.md を読ませない。抜粋を「貼る」のではなく、ファイルで渡す。 波を投げる前に1回だけ python3 tools/skill_brief.py events --out temp/brief-events.md を実行し、指示には**「まず temp/brief-events.md を Read し、そこに書かれた規則に従うこと」の1文だけ**を書く。抜粋のパスへの参照が無い波は .claude/hooks/agent-guard.sh が拒否する。 貼る形は、親に「抜粋ぶんの出力トークン × 体数」を払わせる——2026-09-02 の回はそれを払わずに自作の1〜2KBの指示に要約し、そこから料金の列（price_official price_checked price_best coupon_note）が一語も残らず、新規90件の公式料金が0件になった。子の文脈に入る量は貼る場合と同じで、消えるのは親の負担だけである。読んだ瞬間に子の文脈が +23k トークン跳ねる（2026-08-27 の実測。3体とも同じ）。平均文脈 115k の2割で、196ターン回った子ではこの1ファイルだけで約4.5M になる。しかも文脈は毎ターン送り直されるので、体を分けてもこの分は減らない。抜粋は終了工程・撤退の手順・工程の割り振り・初期化（--init）・消えた行の説明だけを外し、行の書き方と取得の作法は丸ごと残す（docs/COLLECTION-PROTOCOL.md 第11.8節）。抜粋の先頭には「data/ に書かない・--init を実行しない・結果は temp/rows-*.jsonl に書く」という固定の注意書きが常に付く——下の1と同じ内容だが、指示にこれを書き忘れても子には届く二重の安全策である
「結果は temp/rows-<波の名前>.jsonl に1行1件のJSONLで書き、返答にはファイルのパスと件数だけを書け。行そのものを返答に含めるな」と明記する。あわせて「1件書けるたびに追記せよ（>>）。最後にまとめて書くな」も必ず書く——子は60ターンで打ち切られることがあり（maxTurns）、打ち切られるのは応答であってファイルではない。まとめ書きの設計だと、打ち切られた瞬間にその波の調査がまるごと失われる。逐次追記なら、そこまでが成果として残って親が追記できる。 2つのことを同時に防いでいる。ひとつは「調査した内容の要約」を返して機械可読な行が1件も戻らない失敗（実測で15体中3体がこれになった）。もうひとつは同じ行を3回払うこと——子が返答に書き（出力）、親の文脈に入り（入力）、親がヒアドキュメントで書き直す（出力）。2026-08-26 の lives 収集は88行でこれをやり、03:07:48 → 03:11:21 の3分半がほぼ純粋な出力生成に消えた。ファイル経由なら1回で済む
担当範囲の前回行を「ファイルで」渡す。 波を投げる前に都県ごとに1回だけ実行する。
```
python3 tools/prev_rows.py events --worklist --pref <担当都県> > temp/worklist-events-<担当都県>.md
wc -l temp/worklist-events-<担当都県>.md   # 件数だけ確認する（中身は開かない）
```
指示には「temp/worklist-events-<担当都県>.md を Read し、この一覧の行を再確認しながら新規を探すこと」と書く。出力を指示に貼らない——抜粋を貼らないのと同じ理由で、貼ると親が「その字数 × 体数」を出力トークンで払い、しかも同じ内容が親の文脈にも載る（実測: 全県ぶんで28,922字）。渡すこと自体は省略しない。前回分の照合をサブエージェント任せにすると、実行時には素通りされる
このスキルの中核工程を名指しし、書かせる列まで書く——価格比較の第0〜1段階（対象かどうかの判定と、公式料金の記録）。「価格比較とクーポン検知」章を参照させたうえで、JSONLに含める列の一覧に price price_official price_checked を必ず入れる。 一覧に無い列は書かれない：2026-09-02 の指示は列を title, cats, area, venue, pref, start_date, end_date, price, source, url, official_url, desc の12個で示し、価格の列を1つも挙げなかった結果、子は price_official を1件も返さなかった。あわせて**「イベント一覧のページに料金が無ければ、その会場の料金ページ（利用案内・入館料・チケット）を1枚開くこと」と、「取得は WebFetch ではなく fetch_page.py --text を使うこと」**を明記する
「開いたページに書いてあれば拾う」補助列を列挙する——kana note venue_url series_id announced_date is_additional parking nearest_station。書かなければ0%のまま埋まらない
有効なキーの一覧と対象期間を明記する。 cats は art exp food ent fam tech sport fest の8キーのみ（それ以外は append_rows.py が拒否する）。対象地域は1都4県（東京・神奈川・埼玉・千葉・茨城）、対象期間は実行日から3ヶ月以内に開始するもの・または実行日時点で開催中のもの
中止・対象外になっていた前回行の書き先を渡す。 指示に「前回行が中止・延期・対象外だと確認できたら、rows には書かず temp/dispose-events-<波の名前>.jsonl に {"uid", "status": "cancelled|out-of-scope", "note"} を1行ずつ追記すること」と書く。前回行はステップ0で既にCSVへ戻っているので、子が書かないだけでは消えない——この経路が無いと、中止になった催しが終了日まで載り続ける。書き方の規則は子の定義（.claude/agents/kanto-collector-worker.md）にある

親の残りトークンが少ないときの追加指示（サブエージェントには意識させない）

タスク着手時点で、Claude Codeが示す残りトークン数（コンテキストの残量表示）を控えておく。これは親（このタスクを実行している自分自身）だけが気にすればよく、サブエージェントに「自分の残りトークンを確認しながら進めて」と指示してはならない——サブエージェント自身に残量を意識させると、調査そのものの遂行能力が落ちる。

以後、残りが着手時の10%を切ったら、その時点から新しく投げるサブエージェントの指示に次の一文を追加する。

担当範囲を最後までやり切れなくてよい。区切りのよいところ（1件・1都県などの単位）まで進めたら、そこまでの結果をJSONLで返してターンを終えてよい。

強制的に打ち切らせるものではない。 すでに動いているサブエージェントに割り込むのではなく、次に投げる指示にあらかじめ「早めに畳んでよい許可」を含めておくことで、キリの悪いところで打ち切られる事故を防ぐための措置である。

調査手順

差分検知・持ち越し・名簿更新の考え方は docs/COLLECTION-PROTOCOL.md に詳しく書いてある。手を動かすのに必要なコマンドはこのSKILL.mdに全部あるので、判断に迷ったときに読めばよい。

ステップ0：土台を作る（省略禁止・検索を1回も使わない）

調査を始める前に、CSVを「先週の完全な状態」に戻す。 --init はCSVを空にするので、
ここを通さないと、調査が届かなかった行はそのまま消える。

python3 tools/prev_rows.py events --carry-rest --apply

終了日を過ぎた行は expired として処分され、残りは前回値のまま書き戻る（受付と
クーポンは空になる）。この1コマンドが「期間切れの削除」と「前回分の引き継ぎ」を
まとめて行う。

なぜ最初に置くのか。 以前はこれを終了工程の側に置き、調べ終えてから残りを
書き戻していた。その順序では、予算が尽きた回に数百行が未確認のまま最後に
なだれ込む——2026-09-26 の回は349行中304行がこれに当たった。先に書き戻して
おけば、調査はどこで打ち切っても「今週増やせたはずの分」しか失わない。
同じ催しを再収集しても append_rows.py が uid で突き合わせて更新するので、
行が二重になることはない。

次に、重複が残っていないかを確かめる。

python3 tools/validate_data.py --duplicates-only

完全重複（同じ uid の行が複数）は、通常ここで0件のはずである。 直前の --carry-rest
が前回CSVの全行を1回のバッチで処理するとき、同じuidの行が複数あれば自動的に1行へ
畳んでいる——--dispose を使って自分で1行を選んで消す必要はない（uidが同じ以上、
別企画ということもない）。

畳まれた際、price・url のような列で情報が失われていないか、直前の
--carry-rest --apply の出力に WARNING: ...は同じ回の中で前の行（同じuid）を更新し、[...] が空になりました が出ていないかを確認すること。出ていたら、
python3 tools/prev_rows.py events --uid <uid> は生き残った1行しか返さないので、
失われた側の値は data/.prev/events.csv を直接あたって拾い直す（会場ページを
再確認できるならそちらを優先する）。

それでも完全重複が残っている場合（このセッション中の調査が誤って同じ催しを
2回appendしたなど）は、--dispose で該当uidを処分してから、残したい内容で
再度 append_rows.py に渡す——--dispose はそのuidの行を全部消すので、
「片方だけ残す」という操作はできない。

重複の候補（uid は違うが同じ会場・会期・似たタイトル）は別企画のこともあるので、
中身を見て判断する——同じ催しだと分かったら片方を --dispose で処分する。

ステップ0.5：前回分の棚卸し（省略禁止）

土台を作ったら、次に前回載せたイベントの一覧を取る。

python3 tools/prev_rows.py events --worklist

前回分の全行が、CSV全文より1桁小さい圧縮一覧で出る（CSV全文をそのまま読んではいけない）。全列が必要になった行だけ、あとから引く。

python3 tools/prev_rows.py events --uid 3f2a1b9c          # その行を全列で
python3 tools/prev_rows.py events --venue 東京国立博物館   # その会場の前回分をまとめて

python3 tools/prev_rows.py events --worklist --tier A   # 今回必ず再確認する行だけに絞る

一覧の先頭に「終了日を過ぎたまま未確認の行」が出る。今週いちばん最初に確かめるのはここである。

印	意味	やること
`notfound`	先週、調べたが分からなかった行	まだ開催中なら「静かな欠落」になっている。会場ページで確かめ直す
`expired`	終了日を過ぎて機械的に消えた行（未確認）	会期が延長されていた可能性がある。その会場を開くついでに見る

これらの行は前回のCSVにはもう残っていない。この一覧に出さない限り、二度と視界に入らない。
拾い直せたら普通に行として書けばよく、本当に終わっていたなら何もしなくてよい。

一覧には tier が付く。限られたページ取得の回数を、変わりやすい行から先に使うための優先順位である。

tier	意味
A	今回必ず再確認する（会期末・開始が10日以内／受付の締切・発売が21日以内／クーポンあり等）
B	施設ページを開いたついでに確認する（価格の確認日が45日より古い行もここ）
C	低頻度でよい（「通年予約可」など日程が動かないもの）

この一覧は、ステップ1で施設を回るときの照合表として使う。

ステップ1：施設ベースの網羅調査 —— 既存の再確認と新規の発見を同時に行う

調査対象の施設は data/spots.csv に入っている。上から順ではなく、都県ごとに引いて回る。この順に回すこと：東京→神奈川→埼玉→千葉→茨城（「対象地域」章の「調査順序」参照）。

python3 tools/roster.py spots --list --pref tokyo --urls
python3 tools/roster.py spots --list --pref kanagawa --urls
python3 tools/roster.py spots --list --pref saitama --urls
python3 tools/roster.py spots --list --pref chiba --urls
python3 tools/roster.py spots --list --pref ibaraki --urls

（retired の施設と休館中の施設は自動的に除かれる。調べても収穫がないため）

4列目に施設の公式URLが出る。この工程では、原則としてそのURLを直接開く（検索しない）。 名簿の全件を検索で辿ると、それだけでセッションの上限（200回）を使い切ってしまう。標準エラーに出る「うちURL不明 N件」が、この工程で検索を使ってよい件数である（枠は10回）。

1施設につき1回、その施設の「いま何をやっているか」を調べる。そのとき次の3つを同時に済ませる。

前回分の照合 —— ステップ0.5の一覧（担当表）でその施設の行を確認し、まだやっているか／会期が延びていないか／中止になっていないか／料金・クーポンが変わっていないかを見る。前回行は着手の時点で既にCSVへ書き戻されているので、書かないだけでは消えない——中止・延期・対象外だと確認できた行は rows に書かず、指示にある temp/dispose-events-<波の名前>.jsonl に {"uid", "status": "cancelled|out-of-scope", "note"} を書く（ended は使わない。終了日を過ぎた行は着手時に片付いており、残りに付けると拒否される）。確認できなかっただけの行は何も書かない
新規の発見 —— 前回になかった企画展・シーズナルイベントを拾う
収穫の記録 —— 手で打つ必要はない。 append_rows.py が、書いた行の venue から
名簿の収穫を自動で記録する（名簿に無い会場は「名簿に無い会場 N件」として挙がるので、
継続的に催しがある場所なら roster.py spots --add で入れる）

行を1件ずつ再確認してはいけない。 施設の展覧会ページを1回開けば、既存行の確認と新規の発見は同じ取得で終わる。行ごとに確認すると126回の取得になり、この工程が現実的でなくなる。この手順が追加のコストをほとんど生まないのは、この相乗りのおかげである。

同じ理由で、列も1回で取り切ること。 その施設のページを開いている間に、会期・料金・注意事項・（初出の会場なら）アクセスまで拾う。「あとで座標だけ」「あとでアクセスだけ」と戻るのは、同じページの二重払いになる。

料金は、イベント一覧のページには載っていない。 施設サイトは料金を「利用案内」「入館料」「入園料」「チケット」の別ページに置く。その会場を初めて開いた回に、料金ページも1枚だけ開くこと——1回の取得でその会場の常設の入館料が分かるので、行数が多い会場ほど安い。当たりは検索を使わずに付く。

ただし、企画展・特別展の観覧料は展覧会ごとに違う。 会場トップに出ている数字（友の会の年会費・共通券など）を
会場内の複数の展覧会に使い回さないこと。2026-08-30 にそれで4組の劣化行が生まれた（第1段階の注記を読むこと）。
python3 tools/fetch_page.py <会場のトップURL> --links \
  | grep -E '料金|入館|入園|観覧|チケット|利用案内|price|ticket|admission'
詳しくは「価格比較とクーポン検知」章の第1段階。この1枚を省くと、その会場の行は全部 price が空欄になる（2026-09-02 の実測：新規90件中61件が空欄）。

検索クエリの組み立て方（名簿に url が無い施設に限る。URLが分かっている施設は直接開く）：

{施設名} イベント {実行年}年{実行月}月
{施設名} 特別展 開催中
{施設名} 企画展 {実行年}

例：

国立新美術館企画展 2026年8月
よみうりランドイベント 2026 夏
ふなばしアンデルセン公園イベント開催中

施設の常設展示そのものはイベントではないので拾わない。期間限定の企画展・特別展・シーズナルイベントのみを拾う。

閉館・改称・長期休館を見つけたら、その場で名簿に反映する。

python3 tools/roster.py spots --retire ○○美術館 --reason "2026年6月閉館"
python3 tools/roster.py spots --block ○○美術館 --reason "robots.txt が拒否"  # 閉館ではない
python3 tools/roster.py spots --close ○○館 --until 2027-04-01 --reason "改修工事のため休館"

ステップ2：名簿に載っていない会場の探索（省略禁止）

名簿は「網羅の手段」ではなく「定点観測の背骨」である。 名簿を一周しただけでは、花火大会・寺社の祭事・商業施設の催事・公園の特設会場・期間限定のポップアップといった「名簿に載らない側」が構造的に漏れる。

そこで、施設軸とは独立にエリア軸で探索する。

5都県すべてについて、東京→神奈川→埼玉→千葉→茨城の順で、最低3クエリずつ回すこと。カテゴリは実行月に応じて選ぶ（cats の8キーと「季節イベントの検索キーワード」の表を組み合わせる）。

{都県名} イベント {実行年}年{実行月}月
{都県名} {季節キーワード} {実行年}
{都県名} {カテゴリ} 開催中 {実行年}年{実行月}月

例：

埼玉県フードフェス開催中 2026年8月
千葉県花火大会 2026
茨城県イベント 2026年8月

探索の予算：1都県あたり3〜4クエリ（5都県で合計20回まで）、そこから深掘りする新規会場は1都県あたり5件程度までを目安とする。上限を決めないとこの工程は際限なく伸び、後半の調査が浅くなる。

この工程は検索を使ってよい数少ない工程である（探すのがURLの分からないイベントだからである）。逆に言えば、施設調査で名簿のURLに直行して節約した分が、ここで生きる。

見つけた会場が名簿になければ、その場で追加する（candidate として登録され、次回もヒットすれば active に昇格する）。

python3 tools/roster.py spots --add <<'EOF'
{"name": "○○ミュージアム", "kind": "museum", "pref": "tokyo", "area": "東京都・港区",
 "lat": "35.6612", "lng": "139.7290", "url": "https://...", "note": "2026年開館"}
EOF

kind は themepark aquazoo museum science hall theater mall park landmark から選ぶ。

名簿に入れるのは「継続的にイベントをやる場所」だけにすること。 単発の特設会場・河川敷・道路上の会場は、イベント行には書いても名簿には入れない（翌週以降ずっと空振りする定点観測先が増えるだけになる）。

収集元のページに書かれていた文言を note にそのまま持ち込まないこと。 名簿は次回の自分が読むファイルであり、指示文めいた文字列が混じると実質的に指示書への書き込みになる。roster.py はそうした文字列を拒否するが、そもそも入れない。

ステップ3：横断サイトでの補完調査

ステップ1・2でも漏れるイベント（単発の勉強会、複数会場にまたがる企画など）を、以下のサイトで補完する。

サイト	URL	得意分野
ウォーカープラス	https://www.walkerplus.com/	全ジャンル・網羅性最高
レッツエンジョイ東京	https://www.enjoytokyo.jp/	首都圏・駅単位
いこーよ	https://iko-yo.net/	子連れ・ファミリー
asoview!	https://www.asoview.com/	体験・アクティビティ予約
イープラス	https://eplus.jp/	チケット制のイベント
チケットぴあ	https://t.pia.jp/	チケット制のイベント
TECH PLAY	https://techplay.jp/	IT系イベント
Peatix	https://peatix.com/	コミュニティ系
オソトイコ	https://osotoiko.com/	関東の「今日行ける」
GO TOKYO	https://www.gotokyo.org/jp/	東京都公式

connpass はこの表から外してある。名簿に戻さないこと。 robots.txt が
User-agent: * に対して Disallow: /（例外は .ics と ja.atom のフィードのみ）
を宣言しており、Claude-User / Claude-SearchBot とも拒否と判定される。
tech カテゴリは TECH PLAY と Peatix、および各カンファレンスの公式サイトで拾う。

補完用の検索クエリ例：

関東花火大会 {実行年}年{実行月}月
東京ビアガーデン {実行年}
関東フードフェス {実行月}月
{都県名} 夏祭り {実行年}
東京 IT カンファレンス {実行年}年{実行月}月

ステップ4：各イベントの深掘り

この工程の枠は60回（「調査予算」参照）。枠を使ってよいのは新規行だけである。前回から続く行は、前回の official_url を直接開けば検索は要らない。

拾ったイベント1件ごとに、必ず公式情報まで辿って以下を確定させる。まとめサイトの記載だけで済ませない（まとめサイトは日付・料金が古いことがある）。

確認する項目：

正確な開催期間（開始日・終了日）
何が目玉か — 目玉の展示物、限定コンテンツ、体験できること、規模感
料金 — 券種ごとの正確な金額。イベントページに無ければ、その会場の料金ページ（利用案内・入館料・チケット）を1枚開く（第1段階。常設の入館料なら会場ごとに1回でよいが、企画展・特別展は企画ごとに観覧料が違うので個別に開く）
予約方法 — どのプレイガイドで買えるか、日時指定制かどうか
公式サイトURL
価格比較とクーポン — 「価格比較とクーポン検知」章の段階制に従う（第0段階の判定を必ず先に行う）
駐車場・最寄り駅 — 初出の会場についてのみ、上の1〜5と同じ取得の中で拾う

この7項目は、原則として公式ページ1回の取得で揃う。 項目ごとにページを開き直さないこと。

「何が目玉か」の調査を省略しないこと。 これがないと desc が「〇〇の展覧会です」という中身のない一文になり、利用者が判断できない。

深掘りを打ち切る基準

必須列（title cats area pref venue 日付 price source url desc。比較対象の行は＋price_official price_checked）が揃った時点で、その行の調査を終える。揃っているのに「もう少し詳しく」と調べ続けるのは、品質ではなく消費である。

前回から続いているイベントについては、変わりうる項目（会期・料金・クーポン・受付）だけを確認すればよい。目玉・座標・アクセスを毎回調べ直す必要はない（_carry で持ち越す）。「変わっていないことを確認する」ために、変わらない項目を読み直さないこと。

ステップ4.5：いま載っている行の欠けを埋める

新規の発見が一巡したら、残りの予算はCSV全体の欠けに回す。 ステップ4の深掘りは
新規行を対象にしているので、前回から続く行の空欄はそのままでは埋まらない。

python3 tools/report_stats.py events --json

中核列（price price_official desc official_url 等）の充足率が出る。低い列から
順に、会場単位で埋めていく——料金ページを1枚開けば同じ会場の行がまとめて埋まるので、
行を1件ずつ追うより桁違いに安い。

python3 tools/prev_rows.py events --venue 東京国立博物館   # その会場の行をまとめて引く

この工程は予算が尽きたらそこで畳んでよい。埋まらなかった列は報告に件数を書く。
ステップ0で土台が出来ているので、ここを飛ばしてもCSVが壊れることはない。

ステップ5：消えた行の説明と、差分の確定

ここまでで新しい data/events.csv が出来ている。まず、終了日を過ぎた行を機械的に片付ける。
ステップ0の --carry-rest --apply が既に同じ処分をしているので通常は0件で通るが、
調査中に書いた行が終了日を過ぎている場合の保険として残してある。

python3 tools/purge_ended.py events

これは検索を使わず、終了日と今日の日付を比べるだけの機械的な処理である。消した行には自動で expired の処分が付く（「なぜ要るか」は tools/purge_ended.py 冒頭のコメントを参照）。この工程を通しても、確認できた行を ended として --dispose する手間はそのまま残る——expired は未確認のしるしであって、確認の代わりにはならない。

次に、子が「中止・延期になっていた」「対象外になっていた」と報告した行を取り除く。

cat temp/dispose-events-*.jsonl | python3 tools/prev_rows.py events --dispose

前回行はステップ0で全部CSVへ書き戻してあるので、子がその行を書かなかっただけでは
消えない——下の [消滅] にも出てこない（CSVに残っているため）。子の報告を通さない限り、
中止になった催しが終了日まで公開され続ける。通すのは今回の波が書いたファイルだけ
（temp/ に前の回のファイルが残っていても、それは今回の確認ではない）。1行でも規則に
合わない行（前回データに無い uid・終了日前の ended・1回8件を超える ended）があると
全体がエラーで止まるので、その行を直すか外してからやり直す。子は ended を書かない決まりだが（終了日を過ぎた行はステップ0で片付いており、残りに ended を付けると拒否される）、混ざっていたら cancelled か notfound に直す。

次に、差分を一覧して表記が変わっただけの二重掲載が無いかを確かめる。

この工程は、工程順を変えたことでむしろ重要になった。 ステップ0で前回行を全部
書き戻しているので、催しの表記が変わると「旧uidの持ち越し行」と「新uidの新規行」が
両方ともCSVに残る。放っておくと同じ催しが2つ並んで公開される。renamed として
処分すれば、--dispose が旧uidの行をCSVから取り除く。

python3 tools/diff_data.py events --allow-unexplained --allow-noop

この出力を head / tail / grep で切ってはいけない。 [新規] の一覧が長いと見出しだけで数十行を使うため、その直後に出る [表記が変わった可能性]（下記）が画面外に落ちる。2026-08-29 15:30 の実行はこの確認を | head -20 に通し、[新規]74件 の見出しで20行を使い切って [表記が変わった可能性] を一度も見ないまま --carry-rest --apply を全件に適用した。結果、会場名を正式名称から短縮しただけ・タイトルの副題や記号が変わっただけの催しが8件、旧uidの持ち越し行と新uidの新規行の両方として二重掲載された（例：「ワーナーブラザーススタジオツアー東京メイキング・オブハリー・ポッター」→「ワーナーブラザーススタジオツアー東京」、「再オープン記念...月のひかり、星のきらめき」→ 同タイトルの末尾が「…」で切れた別行）。

「消滅」として挙がった行は、必ず次のどれかである。

本当に終わった・中止になった → ended / cancelled として記録する。正しく消えている
今回は見つけられなかった → notfound として記録する。行は削除されない——--dispose が前回値のまま自動で書き戻し（受付欄は空にする）、来週 tier A で最優先の再確認対象になる。何も確認できていない以上、終了した根拠にはならない
表記が変わっただけで、実は同じ催しが [新規] 側にも出ている → renamed として記録する（上記の二重掲載事故）

この3つは結果のCSVを見ても区別できない。だから1件ずつ理由を記録する。
--dispose は記録するだけでなく、notfound 以外の行をCSVから取り除く——
ステップ0で全行を書き戻している以上、記録だけでは終わった催しが公開され続けるためである。

python3 tools/prev_rows.py events --dispose <<'EOF'
{"uid": "37e50ea9", "status": "ended",        "note": "8/31で会期終了を公式サイトで確認"}
{"uid": "2e9a11b8", "status": "cancelled",    "note": "荒天のため中止"}
{"uid": "9ab96b1e", "status": "out-of-scope", "note": "開始が3ヶ月より先になった"}
{"uid": "4b7d8c70", "status": "renamed",      "to": "a1b2c3d4", "note": "正式名称に変更"}
{"uid": "341daad8", "status": "notfound",     "note": "施設ページに記載がなく確認できず"}
EOF

notfound は「調べたが分からなかった」を正直に残すためのものであり、面倒を避けるために使ってよいものではない。 まずその施設のページに当たり直すこと。それでも分からなければ notfound を記録し、報告に件数を書く。行は削除しない——確認できないことは終了した根拠にならないため、前回値のまま自動で書き戻される（受付欄は空にする）。件数の上限も無い（個別確認せずに大量「削除」する事故が原理的に起こらないため）。

「表記が変わった可能性」として挙がったペアは、同じ催しなら renamed を記録する。放置すると、同じ催しが「消滅1件＋新規1件」として数えられ、NEWバッジが誤って付く。

最後に名簿を整理し、差分と検証を確定させる。

python3 tools/roster.py spots --gc      # 収穫のない定点観測先を整理（毎回実行する）
python3 tools/diff_data.py events       # 説明漏れがあると落ちる
python3 tools/validate_data.py          # ERROR 0 を確認

diff_data.py の出力が、そのまま報告の「前回からの変化」になる。記憶や印象で変化を書かないこと。

駐車場・最寄り駅の書き方（`parking` / `nearest_station`）

「くわしく」を開いた利用者が、車で行くか電車で行くかをその場で判断できるようにするための情報。公式サイトの「アクセス」ページに載っている内容をそのまま書き写す（憶測で埋めない）。

列	書き方
`nearest_station`	最寄り駅名と徒歩時間（例：`上野駅（徒歩10分）`）。使える駅が複数あるときは `／` 区切りで併記してよい（例：`上野駅（徒歩10分）／根津駅（徒歩8分）`）
`parking`	駐車場の有無・台数・料金（例：`あり（有料・120台）`、`契約駐車場なし（近隣コインパーキングを利用）`）。専用駐車場が無い会場は「無い」という事実を書く

「たぶんあるだろう」「駅前だから徒歩圏だろう」という推測では書かない。 公式サイトにアクセス情報が無い、または確認できなかった場合は、両方とも空欄のままにする。空欄の行は「くわしく」にこの2項目が出ないだけで、表示は壊れない（第3.5節の欠損耐性）。

この2列のために、別途ページを開かないこと

座標と同じく、駐車場・最寄り駅も**「会場の属性」として前回値から自動補完される**。

前回も出てきた会場 → 空欄で渡す。自動で埋まる。調べない
初出の会場 → その会場のページを開いているそのついでに拾う。会期・料金を見に行った取得の中で済ませる

アクセスページを単独で開いてよいのは、初出の会場について、その1回だけである。同じ会場の2件目・3件目のイベントのために開き直さない。

会場の座標（`lat`/`lng`）の調べ方

ダッシュボードの「地図で範囲をえらぶ」機能は、この2列の値だけを頼りに動く。座標が埋まっていない行は地図上にまったく現れない——一覧には載っていても、地図から探している利用者には見つけてもらえない。

まず、ほとんどの行は調べる必要がない

append_rows.py は座標を**「行の属性」ではなく「会場の属性」として**扱い、
名簿（data/spots.csv。ほぼ全件に座標あり）と前回値から自動で補完する。

✅ 名簿に載っている会場 → lat/lng を空欄で渡す。自動で埋まる。調べない
✅ 前回も出てきた会場 → 同上。会期が変わって uid がずれても、同じ会場の別の行から引かれる
🔍 調べるのは、名簿にも前回にも無い新しい会場だけ

すでに座標が分かっている会場を調べ直すのは、予算を最も静かに食う行為である。（docs/COLLECTION-PROTOCOL.md 第8.3節）

新しい会場の座標を調べる手順

その会場のページを開いている、そのときに済ませる。 「アクセス」ページに住所が載っているので、会期・料金を確認するのと同じ取得の中で拾う
住所から座標が取れないときだけ、地図サービスで住所（会場名だけでは同名の別施設と混同しやすい）を引く
見つかった座標を小数4桁程度に丸めて記入する
同じ会場が複数のイベントに登場する場合は、一度調べた座標を使い回す（--add で名簿に入れておけば、翌週からは自動で埋まる）

特定できない場合（臨時会場・野外の特設会場など住所そのものが定まらないケース）は空欄でよい。座標のためだけに追加の検索を1回使う判断は、その会場が名簿にない常設施設のときに限る。

受付期間（`onsale_*`）の書き方

当日ふらっと行けるイベントには不要。事前予約制・抽選・整理券配布・チケット販売があるイベントだけ書く。

書くと、カード表面に「受付中／受付前／受付終了」と締切カウントダウンが出て、「まだ申し込めるものだけ」で絞り込めるようになる。逆に、締切が過ぎているのに onsale_end を書き忘れると、申し込めないイベントが「受付中」として並ぶ。

列	規則
`onsale_label`	受付の名前（例：`一般販売` `先行抽選` `整理券配布`）。完売・終了なら `SOLD OUT` `受付終了` `販売終了` `完売` のいずれか
`onsale_start`	受付開始日 `YYYY-MM-DD`
`onsale_start_time`	受付開始時刻 `HH:MM`（24時間表記）。先着順は開始時刻ちょうどに動くので、書いてあるなら必ず取る
`onsale_end`	受付締切日 `YYYY-MM-DD`
`onsale_end_time`	締切時刻 `HH:MM`
`limited_sale`	一部の枠だけの販売（例：`当日券あり` `追加枠 8/10 10:00〜`）。無ければ空欄

時刻が書かれていないときは空欄にする。 画面側は「開始時刻が空なら0:00、締切時刻が空なら23:59」として扱うので、勝手に 10:00 などと補うと、その時刻まで「発売前」と嘘をつくことになる。

適用条件（`price_condition`）—— 条件付きの割引には必ず書く

price_best や discount_pct に書いた価格が誰でも使えるとは限らない場合、その条件を必ず price_condition に書く。

JAF会員のみ / 平日限定 / 前日までのWeb購入のみ / 学生証提示 / 20名以上の団体
条件が分からない割引は、書かずに落とす。条件を伏せた安い価格は、値段を出さないより有害になる（「その値段で買えると思って行ったら買えなかった」を作る）

誰でも無条件に使える割引（例：Klookの通常価格が公式より安い）は空欄でよい。

巡回展（`series_id`）

同じ企画展が複数会場を回る場合、全行に同じ series_id を入れる。画面側が「この巡回展の他の会場」として、他会場の日程と受付状況を1枚のカードから読めるようにする。

会場ごとに1行を立てる（venue area pref lat lng start_date end_date はその会場のもの）
series_id は s- で始まる短い識別子（例：s-monet2026）
1会場だけの企画には付けない（1件だけのシリーズは意味を持たない）

価格比較とクーポン検知（このタスクの中核）

まず「どこまでやるか」を決める —— 4段階の打ち切り

イベント1件ごとにA群をすべて確認してはいけない。 126件×11サイトは1,300回規模の取得になり、検索の上限（200回）では実行できない。実行できないルールは丁寧な仕事を生まず、恣意的な場所で黙って止まった仕事を生む。

これは比較が無意味だという意味ではない。割引が構造的に存在する層は限られており、多くの行は公式サイトが最安になるという意味である。予算はその層に集中させる。

第0段階：比較の対象かを判定する（取得0回）

次に当たる行は、比較しない。price に公式の案内を書いて、その行は終わりにする。

入場無料（寺社の祭事・花火大会・商業施設の催事・マルシェ・フリーイベント）
飲食・物販が主体で、入場そのものは無料
日別変動価格（変動制の1デーパスポート等）—— 横断比較しても意味のある数字にならない。price に「来園日により変動制（公式のカレンダーで要確認）」と書く
チケット制のホール公演 —— 定価固定（/kanto-live-collector が価格比較を行わないのと同じ理由）

無料イベントについて割引を探すのは、予算の純粋な浪費である。 この層は毎回まとまった件数になる。判定は取得0回でできるので、必ず先に行うこと。

第1段階：公式の正規料金（常設の入館料は会場ごとに1回・企画展は企画ごとに1回）

price・price_official・price_checked を書く。多くの行はここで終わってよい。

料金は、イベントの一覧ページには載っていないのが普通である。 施設サイトは料金を
「利用案内」「入館料」「入園料」「チケット」といった別のページに置く。
イベント一覧を1枚読んで price を空欄にするのは、調べていないのと同じである
——2026-09-02 の回は取得114回のうち料金ページが1枚も無く、新規90件の
price_official が0件で終わった。

料金ページは、検索を1回も使わずに1回の取得で当たりが付く。

python3 tools/fetch_page.py <会場のトップURL> --links \
  | grep -E '料金|入館|入園|観覧|チケット|利用案内|price|ticket|admission'

出てきたURLを1つ開けば、その会場の常設の入館料が分かる。同じ入館料で入れるイベントが何行あっても
取得は1回でよく、ステップ1で施設ページを開くついでに済ませられる。

⚠️ 「会場ごとに1回」が効く範囲を取り違えないこと

1回で済むのは、同じ展覧会・同じ企画に属する複数行（会期のセクション違いなど）と、
常設の入館料で入れる行までである。同じ会場でも、別の展覧会・別の企画は個別に料金ページを開く。
企画展・特別展は展覧会ごとに観覧料が違い、会場のトップページに出ている数字は
友の会の年会費や共通券であることが多い。

2026-08-30 の実行は、東京都美術館の2つの展覧会にどちらも 2600 という同じ裸の数字を付けた。
正しい観覧料は 一般2,300円 と 一般1,200円 で、2600 はそのどちらでもない。
同じパターンが東京都写真美術館・江戸東京博物館でも起き、この週だけで4組の劣化行が生まれている
（docs/skill-feedback.md 2026-09-21）。

price に単位の無い裸の数字を書かない。 validate_data.py が WARNING で挙げる。
書くのは 一般2,300円 のような、券種と円表記の付いた形である
（比較用の整数は price_official という別の列に入れる）。

取得は WebFetch ではなく fetch_page.py --text を使うこと。 料金は表で書かれていることが
多く、--text はセルをタブ区切りで残すが、WebFetch は要約を返すので、要約に載らなかった
金額は二度と手に入らない（同じ日の実測：fetch_page.py 0回・WebFetch 114回）。

それでも金額が確認できない行だけ、price を空欄にする。要問合せ と書いてよいのは、
公式がそう案内しているときだけである（「調べたが分からなかった」を 要問合せ と書くのは、
確認していない案内を書くことになる）。

第2段階：主要2経路まで（対象層のみ）

テーマパーク・水族館・動物園・大型企画展など、プレイガイドが通年で入場券を扱う層に限って、asoview! と KKday のどちらか一方——合わせて2サイトまで——を当たる。

Klookはこの段階の既定候補から外す。 HTTP 403 を返すことが実測で常態化しており（2026-08-23）、当たろうとするだけで取得を1回消費して終わる。第3段階まで進んだ行で、公式に取扱いの記載があるときだけ個別に当たってよい。

asoview!の商品ページ（/item/ticket/... /channel/tickets/...）は価格がJavaScriptで描画され、fetch_page.py --text でも WebFetch でも本文が取得できないことが多い（2026-08-23の実測：対象7件中、商品ページから金額を確認できたのは5件）。商品ページの本文が0〜数百文字しか取れないときは、代わりに施設紹介ページ（/base/...）のSEO説明文に載っている価格表記を確認してよい。そこにも価格の記載が無ければ、その行はKKdayのみで判定するか、price_best を空欄のまま次の行へ進む（推測で埋めないという原則はここでも変わらない）。

差が出なければ、そこで打ち切る。 price_best = price_official、best_source = 公式サイト として次の行へ移る。3社目・4社目を当たらない。

第3段階：差またはクーポンが出たときだけ（対象層のみ）

第2段階で公式より安い経路が実在した、またはクーポンが見つかった行に限り、残りのA群を当たって最安を確定させる。安い経路が実在すると分かった行にだけ、深掘りの予算を集中させる。

KlookとKKdayは価格が入れ替わることがあるので、第3段階に進んだ行では両方見る。 第2段階では片方でよい（第2段階の目的は「差があるかどうか」の判定であって、最安の確定ではない）。第2段階でKlookを使わなかった場合も、第3段階では候補に含めてよい（403が続くようならその行では諦める）。

比較対象サイト

上の段階制に従って当たる。下表は「必ず全部開くリスト」ではなく、第3段階に進んだ行のための候補一覧である。

A. 誰でもすぐ使える経路（最安価格の比較に算入する）

サイト	URL	クーポン情報ページ
公式サイト	イベントごと	公式の「チケット」ページ
asoview!（アソビュー）	https://www.asoview.com/	https://www.asoview.com/coupon/ ／「超特割」プラン
Klook	https://www.klook.com/ja/	サイト内クーポン・セールページ
KKday	https://www.kkday.com/ja	サイト内クーポン・セールページ
アクティビティジャパン	https://activityjapan.com/	キャンペーンページ
VELTRA	https://www.veltra.com/jp/	セールページ
じゃらん遊び・体験	https://www.jalan.net/activity/	クーポンページ
楽天トラベル観光体験	https://experiences.travel.rakuten.co.jp/	クーポンページ
チケットぴあ	https://t.pia.jp/	—
イープラス	https://eplus.jp/	—
ローソンチケット	https://l-tike.com/	—
セブンチケット / ローソン店頭	—	コンビニ前売り券

B. 条件付き優待（最安価格には算入しない／`coupon_note` に別記）

サービス	URL	条件
JAF会員優待	https://area.jaf.or.jp/membership/sisetsulist	JAF会員（年会費）
ベネフィット・ステーション	—	法人契約の福利厚生
デイリーPLUS	—	有料会員
駅探バリューDays	—	有料会員
みんなの優待	—	有料会員
エポトク（エポスカード）	—	カード保有
dエンジョイパス	—	有料会員

「誰でも使える割引」と「条件付き優待」を分ける理由

表示価格は「利用者が実際に払う額」と一致していなければならない。

「最安2,000円」と書いてあるのに、実は年会費のかかる会員資格が前提だった——これは利用者を裏切る表示である。したがって：

A群の価格 → price_best に入れる（＝割引率の計算に使う）
B群の優待 → coupon_note に「JAF会員は200円引き」のように別枠で書く。価格計算には使わない

無料会員登録だけで即取得できるクーポン（例：asoview!の登録5%OFF）は、A群として扱ってよい。登録に費用も審査も要らないためである。

`url`（最安リンク）の選定手順

第2段階で打ち切った行（＝ほとんどの行）では、この手順は不要である。 公式URL、または第2段階で見た2サイトのうち安いほうを url に入れて終わる。以下は第3段階に進んだ行——公式より安い経路が実在すると分かった行——のための手順である。

そのイベントを扱っているA群のサイトを洗い出す
- 公式サイトの「チケット」ページに取扱プレイガイド一覧が載っていることが多い。まずそこを見る（検索1回で候補が全部分かるので、サイトごとに検索するより安い）
- 一覧が無いときだけ {イベント名} チケット {施設名} 割引チケット で検索する
各サイトで同一条件に揃えて総額を確認する
- 同じ日付・同じ人数・同じ券種
- 手数料・発券手数料込み（本体価格が安くても手数料で逆転することがある）
- クーポン適用後の最終金額
最も安いページのURLを url に入れる

⚠️ 一覧ページの表示価格で判断しないこと。 日付・人数を入れると価格が変わる、クーポン対象外だった、といったケースが実際にある。商品・プランページまで開いて、その券種の金額を確認する。商品ページがJavaScript描画で読めない場合の扱いは「価格比較とクーポン検知」章・第2段階の注記を参照。

購入ステップのページは開けない（robots.txt）

予約プラットフォームは、購入導線を Disallow していることが多い。 asoview! の robots.txt は /reserve/ /book/ /api/ を拒否しており、fetch_gate.py がこれを止める。回避しようとしないこと。

開いてよい（価格はここで確認する）	開けない
asoview! の商品ページ `/item/ticket/...`、カテゴリ `/act/...`／Klook `/activity/...`／KKday `/product/...` など	asoview! の `/reserve/` `/book/`

券種ごとの金額は商品・プランページに出ているので、比較はそこで成立する。 購入画面まで進まないと分からない金額（申込人数によって変わる手数料など）は、確認できなかったものとして扱う——price_best を書かず、price に公式の案内を書いて終わりにする。このスキルの「確認できないものは空欄」という規則が、ここでもそのまま効く。

url 列にリンクを書くことは妨げられていない。 robots.txt が制限しているのはこちらがページを取得することであって、利用者に案内するリンクを置くことではない。ただし開けなかったページの価格を書いてはいけない。リンク先は、価格を確認できた商品ページにしておくのが最も安全である（利用者はそこから購入に進める）。

注意事項

公式が最安なら公式URLを url に入れてよい（official_url と同じでも構わない）
転売・二次流通サイトは採用しない（安くても除外。正規流通のみ）
無料イベントは公式の案内ページを url に入れる

クーポン検知の手順

毎回、各社のクーポンページを定点観測する。 配信は不定期なので、前回なかったからといって今回もないとは限らない。

⚠️ クーポンページは、セッションに1回ずつだけ開く

クーポンはイベントの属性ではなく、事業者の属性である。asoview! のクーポンページは、どのイベントについて調べていても同じ内容を返す。イベントごとに開き直すと、同じページを100回開くことになる。

正しい手順は逆向きである。先にクーポン一覧を1回ずつ開いて「いま何が配られているか」を頭に入れ、それを今回の収集対象と突き合わせる。

A群のクーポン情報ページを各1回（asoview! / Klook / KKday / VELTRA / じゃらん / 楽天トラベル / アクティビティジャパン＝計7〜8回）

B群（JAF等）は主要施設についてのみ、まとめて1〜2回

合計10回程度がこの工程の全予算である

クーポン一覧ページは、そもそも読めないことが多い（2026-09-16 の実測）

A群7社とB群JAFのクーポンページを fetch_page.py --text で開いたところ、内容を抽出できたのは0社だった。
取得は18回消費し、coupon_note の材料は1件も得られていない（docs/skill-feedback.md 2026-09-16）。

社そのときの結果

asoview! / VELTRA / じゃらん遊び・体験 / JAF JavaScript動的描画で本文が空

Klook / KKday HTTP 403

アクティビティジャパン 404

楽天トラベル観光体験取得エラー

本文が読めなかったら、その社で粘らない。 第2段階の商品ページと同じ扱いにしてよい
——施設紹介ページ・キャンペーン告知ページのSEO説明文に配布中クーポンの表記があればそれを使い、
無ければその社は飛ばして次へ進む（推測で coupon_note を書かない原則は変わらない）。
開いた社・読めた社・読めなかった社は、社名を挙げて報告に書くこと。
読めない状態が続くなら、それ自体が docs/skill-feedback.md に書くべき観測である。

社	そのときの結果
asoview! / VELTRA / じゃらん遊び・体験 / JAF	JavaScript動的描画で本文が空
Klook / KKday	HTTP 403
アクティビティジャパン	404
楽天トラベル観光体験	取得エラー

A群の「クーポン情報ページ」を各1回開き、配布中のクーポン・セールを把握する（この工程の最初にまとめて行う）
今回収集したイベント／施設が対象に含まれているかを、把握した内容と突き合わせる
含まれていれば、以下を記録する
- 割引内容（〇%OFF、〇円引き、〇枚目無料など）
- 適用条件（最低金額、対象プラン、初回限定など）
- 有効期限
B群の会員優待も、主要施設についてはまとめて確認する

検索クエリ例（各1回ずつ。施設名ごとに回さない）

asoview クーポン {実行年}年{実行月}月
Klook クーポンコード {実行年}
KKday セール {実行年}

施設名を添えた検索（{施設名} 割引クーポン {施設名} JAF 優待）は、上の一覧でその施設が対象に挙がっていた行に限って使う。全施設に対して回すと、それだけで予算を使い切る。

coupon_note の記載形式

asoview!会員登録で5%OFFクーポン配布中（2026-08-31まで）
JAF会員は当日券200円引き（要会員証提示）

必ず条件と期限を含めること。条件のない割引情報は、使えなかった利用者に不信感を与える。

⚠️ 価格・クーポン記載の絶対規則

確認していない価格・割引率・クーポンを絶対に書かないこと。空欄のままにすること。

これは実在する事業者の金銭に関する記述である。誤りは、

利用者が想定より高い金額を払う
存在しないクーポンを探して時間を失う
事業者の信用を毀損する

という実害を生む。

禁止事項

❌ 「一般的に前売りは10%引き」といった相場からの推測
❌ 「プレイガイドのほうが安いだろう」という推定
❌ price_best だけ分かっている状態で price_official を想像して割引率を出す
❌ 過去の割引率をそのまま流用する（セールは終わる）
❌ 確認日 price_checked を書かずに価格を書く

記入可能な条件（すべて満たす場合のみ）

公式の正規料金を実際に確認した
最安経路の料金を実際に確認した
両者が完全に同一条件（券種・日付・人数区分・手数料込み）
確認した日付を記録した

条件が揃わなければ、該当列をすべて空欄にする。price_official だけ分かっている場合は、それだけ記入して price_best / discount_pct / best_source は空欄にしてよい（ダッシュボード側が「他サイトは未確認」と表示する）。

空欄が多いことは品質の問題ではない。誤った割引率が1件混ざることのほうが、はるかに深刻な品質問題である。

`desc` の書き方

100〜150字程度で、そのイベントの何が特別なのかを具体的に書く。

悪い例（一般論・中身なし）

❌ 人気アニメの展覧会です。ファン必見の内容となっています。
❌ 夏にぴったりのイベント。家族で楽しめます。

良い例（目玉が具体的）

✅ ドラえもん史上最大級とうたう展覧会。100体以上の等身大ドラえもんが集結し、屋外の無料エリアと有料エリアに分かれる構成。日時指定制。
✅ 屋内型水族館を舞台にした夏季限定の納涼企画。NAKED社によるデジタル花火と生きものの展示が融合し、イルカのパフォーマンスも行われる。

含めるべき要素

目玉（何が見られる／体験できるのか、規模はどれくらいか）
注意事項（日時指定制、事前予約必須、雨天中止など、知らないと困ること）

含めないもの

主催者の宣伝文句をそのまま転記したもの
「必見」「感動」といった評価語
出典サイトの文章のコピー（必ず自分の言葉で書き直す。著作権に配慮）

継続行を再確認するとき

前回すでにこの基準を満たす desc が付いている行を再確認するときは、内容（目玉）に変更が無ければ書き直さず "_carry": "desc" で持ち越す（「前回から変わっていない列は書き直さない」参照）。会場の「今月のイベント一覧」のような一覧ページの一文だけを見て、前回より薄い説明に書き換えてはならない——前回より内容が減っているなら、それは改善ではなく劣化である。

python3 tools/validate_data.py は30字未満の desc を WARNING で挙げ、append_rows.py は前回の半分未満に縮んだ書き直しを検知して警告する。どちらも「短すぎる」ことしか機械的には判定できないので、この基準（100〜150字・目玉が具体的）を満たしているかは自分で確認すること。

品質チェック（提出前に必ず実施）

完走

「完走条件」の終了工程8つを、すべて実行したか
調査済みなのに append_rows.py で書いていない行を残していないか
打ち切った場合、前回行を「持ち越し」または notfound として片付けたか（黙って消していないか）
工程の区切りごとに [進捗] の1行を出したか
data/ の該当CSVが、ヘッダーだけの状態で終わっていないか
python3 tools/diff_data.py events が「収穫0件」で落ちていないか（新規・変更・消滅がすべて0の週は、調査が実質的に走っていない）
サブエージェントを使ったなら、背景で起動せず、全ての結果を append_rows.py で書き終えてからターンを終えたか
サブエージェント1回の呼び出しに、調査軸1つの全体を背負わせていないか。1つの波の結果を全部書き切ってから、次の波を投げたか（波をまたいで投げ続けていないか）
サブエージェントの結果を temp/*.jsonl で受け取ったか（行そのものを返答に含めさせていないか。第11.4節）
親が自分でページを取得していないか（budget.py --report の文脈再送が親＞子になっていたら逸脱。第11.5節）
（親だけが行う工程） 着手の最初に python3 tools/prev_rows.py events --carry-rest --apply を通したか（ステップ0。これを飛ばすと、調査が届かなかった行がまるごと消える）
（親だけが行う工程） 子が書いた temp/dispose-events-*.jsonl を --dispose に通したか（通さないと、中止になった催しが載り続ける）
python3 tools/validate_data.py --duplicates-only で完全重複を0にしたか（ステップ0）
[表記が変わった可能性] を確かめ、同じ催しの組を renamed で処分したか（旧uidの持ち越し行と新uidの新規行が両方残ると二重掲載になる）
先週の notfound / expired の行（棚卸しの先頭に出る）を確認したか

予算

名簿の施設を --urls のURLで直接開いたか（URLが分かっている施設を検索し直していないか）
前回から続く行を、前回の official_url に直行して確認したか
lat/lng を、名簿・前回値にある会場について調べ直していないか
補助列（kana series_id announced_date 等）を埋めるために追加の検索をしていないか
価格比較の**第0段階（対象かどうかの判定）**を、全行について先に行ったか
比較対象と判定した会場について、料金ページ（利用案内・入館料・チケット）を会場ごとに1枚開いたか（イベント一覧のページだけで price を空欄にしていないか。会場ごとに1回でその会場の全行が埋まる）
第2段階で差が出なかった行を、3社目以降まで当たっていないか
クーポンページをセッションに1回ずつ開いたか（イベントごとに開き直していないか）
python3 tools/budget.py --report --verbose で工程別の消費を確認し、報告に含めたか（記憶で書いていないか）
撤退を判断する前に、残り時間を確認したか（上限6時間。まだ余っているのに早く畳んでいないか）
一覧の構造が意味を持つページを、fetch_page.py --text ではなく WebFetch で読んで崩していないか
予算切れで工程を打ち切った場合、その事実を報告に書いたか（件数を埋めるために未検証の行を足していないか）
再確認できずに前回値で持ち越した tier C の行について、price_checked を前回の日付のままにしたか

差分・名簿

python3 tools/purge_ended.py events を、--dispose より先に実行したか
python3 tools/diff_data.py events が終了コード0で通るか（説明のない消滅が0件か）
「消滅」の各行に付けた理由は、実際に確認した事実に基づいているか（面倒を避けるための notfound になっていないか。expired は purge_ended.py が自動で付けるものであり、モデルが手で選ぶ理由ではない）
「表記が変わった可能性」に挙がったペアを確認し、同じ催しなら renamed を記録したか
announced_date / is_additional を、差分または発表記事の日付に基づいて決めたか（印象で立てていないか）
_carry: "*" を使った行は、内容に変更がないことを実際に確認した行だけか
append_rows.py が挙げた「名簿に無い会場」を確認し、継続的に催しがある場所を --add したか（収穫の記録そのものは自動）
roster.py spots --gc を実行したか
名簿に追加した会場は「継続的にイベントをやる場所」か（単発の特設会場を入れていないか）
python3 tools/report_stats.py events を実行し、中核列の充足率が前回より落ちていないか確認したか（落ちていれば理由を報告に書く。原因が目標件数・品質基準・手順の側にあるなら、報告に書くだけで終えず docs/skill-feedback.md にも提案を残したか——書かないと、同じ理由で毎週落ち続けても誰も気づけない）
「今週かならず産む成果」の下限に届いたか。届かなかった項目を報告に書いたか
目標件数・品質基準・禁止事項に触れるルール変更に気づいたら、自分で書き換えず docs/skill-feedback.md に書いたか（それ以外の小さなバグ修正は自分で直してよい。「ルールのほうを変えたほうがよいと気づいたら」章）

網羅性

5都県すべてについて、施設軸とは別にエリア軸の探索（ステップ2）を行ったか
名簿に無い会場のイベントが結果に含まれているか（0件なら探索が機能していない）

形式・内容

全行の列数が揃っているか（python3 tools/validate_data.py がヘッダーの過不足を検出する。列数をこのチェックリストに書き写さないこと——列は増えるので、書き写した数字は必ず古くなる）
parking／nearest_station は公式サイトの「アクセス」ページ等で確認したものだけを書いているか（不明なら空欄）
lat/lng が空欄で出力された行のうち、名簿にも前回にも無い新しい会場について、「会場の座標（lat/lng）の調べ方」の手順を試したか（名簿にある会場は自動補完されるので、調べ直さないのが正しい）
id が1から連番になっているか
start_date / end_date が YYYY-MM-DD 形式か、または空欄か
終了日が実行日より前のイベントが混ざっていないか
開始日が実行日の3ヶ月後より後のイベントが混ざっていないか
pref が7県のいずれかになっているか
cats が定義済み8キーのみか
date に自由記述を残した行が、本当に ISO の日付へ落とせない日程だけになっているか（validate_data.py が該当行を WARNING で挙げる）
url が実在するページか（リンク切れがないか）
discount_pct が入っている行に、price_official・price_best・best_source・price_checked がすべて揃っているか
price_best が price_official 以上になっている矛盾行がないか
価格を書いた行すべてに price_checked があるか
coupon_note に条件と期限が書かれているか
会員資格が必要な優待を price_best に算入していないか
推定・相場・過去の流用で埋めた価格が1件もないか
今週あらたに書いた行の price が下限（85%）に届いているか（python3 tools/report_stats.py events --check が判定する。全体の充足率で判断しない——carry-rest が書き戻した前回値が混ざり、調べていない週も充足しているように見える）
desc が一般論で終わっていないか
append_rows.py が出した「desc が前回より大幅に短くなっています」の警告を放置していないか（継続行は前回の desc を書き直しで劣化させていないか）
8カテゴリすべてから3件以上あるか
内容が明らかにカテゴリと合わない行が紛れていないか（とくに tech——形式だけで判断していないか）
5都県すべてから5件以上あるか
東京の件数が全体の40%以下か（超えていれば他都県の探索不足を疑う）

調査対象施設リスト —— `data/spots.csv`

定点観測する施設の名簿は、このファイルの散文ではなく data/spots.csv にある（234件）。

python3 tools/roster.py spots --list --pref tokyo --urls   # 東京の調査対象（URL付き）
python3 tools/roster.py spots --list --pref chiba --kind museum
python3 tools/roster.py spots --list --status candidate    # 昇格待ちの新顔だけ

--urls を付けると4列目に公式URLが出る。 標準エラーの「うちURL不明 N件」が、この工程で検索を使ってよい件数である。

retired（閉館・長期にわたり収穫ゼロ）と休館中の施設は、--list から自動的に除かれる。

なぜ名簿をスキル本文から出したのか

会場は開業し、閉館し、改称する。名簿が散文のまま固定されていると必ず腐るが、かといってこのタスクが毎週 SKILL.md を書き換える形は採らない。理由は docs/COLLECTION-PROTOCOL.md 第7.1節に書いてある（要約すれば、Webページを読んだ主体が自分の指示書に書き込める構造にしないため）。

名簿をCSVに出したことで、更新が「スキーマ検証つきの行追加」になり、git diff が読め、--gc で整理できるようになった。名簿（データ）は自動更新、ルール（散文）は提案止まりという線を守ること。

施設の種別（`kind`）

キー	対象
`themepark`	テーマパーク・遊園地
`aquazoo`	水族館・動物園
`museum`	美術館・博物館
`science`	体験・デジタルアート・科学館
`hall`	イベントホール・アリーナ・展示場
`theater`	劇場
`mall`	商業・複合施設
`park`	庭園・公園
`landmark`	寺社・名所・温泉など

ルールのほうを変えたほうがよいと気づいたら

目標件数が実態に合わない、参照先サイトが閉鎖した、列の定義に無理がある——こうした目標件数・品質基準・禁止事項に触れる問題は、docs/skill-feedback.md に追記して人間の判断に委ねる。自分で書き換えないこと。

それに当たらない小さなバグ（誤字脱字、壊れたコマンド例、古いパス・URLの参照など）に気づいたときは、この SKILL.md・tools/ の該当スクリプト・対応する docs/COLLECTION-PROTOCOL.md / docs/DESIGN.md の記述を自分で直してよい。直した内容は docs/skill-feedback.md の「自己修正ログ」に日付・対象・理由を1行残すこと。線引きの詳細は docs/COLLECTION-PROTOCOL.md 第7.1節。

季節イベントの検索キーワード

施設リストで拾えない季節イベントは、以下のキーワードで別途検索する。実行月に応じて該当するものを使うこと。

時期	キーワード
1〜2月	いちご狩り / 梅まつり / イルミネーション / 節分 / 初詣 / スケートリンク
3〜4月	花見 / 桜まつり / チューリップ / ネモフィラ / 春の特別公開
5〜6月	ばら園 / あじさいまつり / 潮干狩り / 新緑ライトアップ
7〜8月	花火大会 / 夏祭り / 盆踊り / ビアガーデン / ナイトプール / 夏休み自由研究 / 納涼
9〜10月	秋祭り / ハロウィン / コスモス / 芸術祭 / 学園祭 / 収穫体験
11〜12月	紅葉ライトアップ / イルミネーション / クリスマスマーケット / 忘年会 / 酉の市
通年	フードフェス / アニメコラボカフェ / 謎解きイベント / マルシェ

検索例：

関東 花火大会 2026年8月
東京 イルミネーション 2026年12月
茨城 ネモフィラ 見頃 2026

実行手順まとめ

手順14〜19は終了工程である（終了工程表の1「調査済みの行を書き切る」は、手順9の追記をやり切ることに当たる）。調査を途中で打ち切る場合も、ここは必ず全部通すこと（「完走条件」参照）。終了工程はローカルのコマンドだけで完結するので、検索の予算が尽きていても実行できる。

手順2〜4は検索を1回も使わない土台作りである。ここを通した時点でCSVは先週の完全な状態に戻り、以降の調査はすべて上積みになる。

python3 tools/check_robots.py と python3 tools/fetch_gate.py --roster spots を実行し、調査元サイトと名簿URLの robots.txt を確認する（検索予算は消費しない。拒否されたURLは対象から外す）。あわせて「調査予算」の工程別の枠を確認し、python3 tools/budget.py --report で今回の消費と**残り時間（上限6時間）**を見る
実行日を確認し、対象期間（実行日〜 3ヶ月後）を確定する。サブエージェントを使うなら、ここで python3 tools/skill_brief.py events --out temp/brief-events.md を1回だけ実行しておく（波の指示にはこのパスを Read させる1文だけを書く。抜粋を貼らない）
python3 tools/append_rows.py events --init（前回分は data/.prev/ に自動退避される。先に --init してから棚卸しを取ること——先週の carried.jsonl が今回分に更新されるのは --init の中でなので、順序を逆にすると「終了日を過ぎたまま未確認の行」が1週遅れて表示される）
python3 tools/prev_rows.py events --carry-rest --apply で土台を作る（省略禁止）。 終了日を過ぎた行は expired として処分され、残りは前回値のまま書き戻る（受付とクーポンは空になる）。この1コマンドが「期間切れの削除」と「前回分の引き継ぎ」をまとめて行う。 以前はこれを終了工程に置いていたが、その順序では予算が尽きた回に数百行が未確認のまま最後になだれ込んだ（2026-09-26 の回は349行中304行）。先に通しておけば、調査はどこで打ち切っても「今週増やせたはずの分」しか失わない
python3 tools/validate_data.py --duplicates-only で重複を確かめ、解消する。 完全重複（同じ uid の行が複数）は別企画ということがないので、1行だけ残して他を消す。重複の候補（uid は違う）は中身を見て判断し、同じ催しなら片方を --dispose で処分する
python3 tools/prev_rows.py events --worklist --summary で前回分の棚卸しを取る（省略禁止）。--summary を付けること——最優先の行（終了日を過ぎたまま未確認）と都県ごとの件数だけが出て、数百行の一覧そのものは出ない。一覧は親の文脈に置くと毎ターン再送されるので（events で28,922字）、担当分は「並行して調べてよい」章のとおり --pref <都県> > temp/worklist-events-<都県>.md でファイルに書いて子に渡す。個別の行が要るときは --uid <uid> で引く。先頭に出る「終了日を過ぎたまま未確認の行」を最初に片付ける
クーポン一覧を各社1回ずつ開き、いま何が配られているかを先に把握する（枠10回。イベントごとに開き直さないため、ここでまとめて済ませる）
python3 tools/roster.py spots --list --pref {都県} --urls で調査対象を引き、東京→神奈川→埼玉→千葉→茨城の順に、4列目のURLを直接開いて「既存行の再確認」と「新規の発見」を同じ1回の調査で済ませる（検索の枠10回＝URL不明の施設のみ）。既存行の再確認が、この工程で行う「既存データの更新チェック」にあたる——独立した工程には分けず、新規発見と同じ取得で済ませる（理由は「ステップ1：施設ベースの網羅調査」冒頭を参照）。一覧の構造が意味を持つページは python3 tools/fetch_page.py <URL> --schedule で取る（日付行とその日にぶら下がる行だけが残り、本文が3〜4割に減る。欲しい催しが出ていなければ --text に戻す）。収穫の記録は append_rows.py が自動で行う
5都県すべてについて東京→神奈川→埼玉→千葉→茨城の順でエリア軸の探索を行い、名簿に無い会場のイベントを拾う（1都県4クエリ・枠20回）。継続的にイベントを開催する会場だったら roster.py spots --add で名簿に追加する
横断サイトで、残りのイベント（単発の勉強会等）を補完する（枠12回）
各イベントについて公式情報まで辿り、期間・目玉・料金・予約方法を確定する（枠60回）。必須列が揃った行はそこで打ち切る。継続行を再収集するときは _carry を付けること——append_rows.py は uid が一致する行を丸ごと置き換えるので、書き忘れた列は消える（desc・cats・area・official_url は自動で持ち越されるが、note などは消える。消えた列は警告に出る）
価格は段階制で当たる（枠25回）
- 第0段階: 無料・変動価格・チケット制ホール公演は比較しない（取得0回で判定）
- 第1段階: 公式の正規料金を確認する
- 第2段階: プレイガイドが券を扱う層に限り、asoview! と KKday の一方（計2サイトまで）。Klookは403が常態化しているため既定では使わない。差が出なければ打ち切る
- 第3段階: 差またはクーポンが出た行だけ、残りのA群を当たって最安を確定する
価格が両方とも検証できた場合のみ price_official price_best discount_pct best_source price_checked を記入する。条件付き優待（JAF等）は coupon_note に別枠で記載する。lat/lng は空欄で渡す（名簿・前回値から自動補完される）
python3 tools/report_stats.py events --json で中核列の充足率を見て、低い列を会場単位で埋める（残りの予算を全部ここに使ってよい）。料金ページを1枚開けば同じ会場の行がまとめて埋まる。予算が尽きたらそこで畳んでよい——土台は既に出来ているので、飛ばしてもCSVは壊れない
python3 tools/purge_ended.py events（手順3で同じ処分が済んでいるので通常は0件。調査中に書いた行の保険）
子が書いた temp/dispose-events-*.jsonl を python3 tools/prev_rows.py events --dispose に通し（中止・対象外になっていた前回行を取り除く。ステップ5参照）、python3 tools/diff_data.py events --allow-unexplained --allow-noop で差分を一覧し、[表記が変わった可能性] を確かめる（出力を切らない）。同じ催しだと分かった組は python3 tools/prev_rows.py events --dispose に renamed として記録する。手順3で前回行を全部書き戻しているので、表記が変わった催しは「旧uidの持ち越し行」と「新uidの新規行」の両方がCSVに残る——renamed を記録すると --dispose が旧uidの行を取り除く。終わった・中止になった行も同じく ended / cancelled で記録して取り除く（notfound だけは行を残す）
python3 tools/roster.py spots --gc で名簿を整理する
python3 tools/diff_data.py events と python3 tools/validate_data.py を実行し、どちらも終了コード0であることを確認する（diff_data.py は収穫が0件でも落ちる）
python3 tools/report_stats.py events --check で充足率・分布・都県の網羅性を確認する（終了コード1で落ちたら、まず実際に調べ直す。とくに「今週あらたに書いた行」の price の下限——持ち越した行の料金は前回値であって、今週確認した値ではない。調べたうえでどうしても確認できない行ばかりだったなら --allow-thin price / --allow-short <pref> で承知したことにし、理由を報告に書く）
最後に、以下の要点だけを簡潔に出力する（あいさつや前置き、次の提案などの会話的な文章は付けない）
- 件数・都県別内訳・カテゴリ別内訳（report_stats.py の出力をそのまま使う）

中核列の充足率と前回比（price_official price_best coupon_note 等。落ちた列があれば理由も）
前回からの変化（diff_data.py の出力をそのまま使う。記憶で書かない）
- 新規イベント／会期延長・日程変更／中止・終了
- --carry-rest が expired として処分した件数（多いなら、tier A の再確認が追いついていない兆候として書く）
- notfound として前回値のまま持ち越した件数（0でないなら、その一覧も。行は削除しない。来週 tier A で再確認する）
価格を検証できた件数／割引を検知できた件数（第2段階で打ち切った件数／第3段階まで進んだ件数も添える）
前回から新たに出たクーポン・終了したセール
名簿に無い会場から拾えた件数（エリア軸探索の成果）
名簿の変化（追加した candidate／retired にした施設／--gc の結果）
lat/lng が埋まっている件数／空欄のままだった件数
工程別の消費と、予算切れで打ち切った工程（budget.py --report --verbose の出力をそのまま貼る。打ち切りが無ければ「なし」と書く）
「今週かならず産む成果」の下限に届いたか（届かなかった項目は件数と理由）
再確認できず前回値のまま残った行数（手順3で書き戻したまま、どの工程でも触らなかった行）
手順13で埋めた欠けの件数と、埋められなかった列
docs/skill-feedback.md に書いた提案があれば、その要旨