♻️ Clubs との突合を dojo2dojo.csv から global_club_id に切り替える

[yasulab]

coderdojo.jp の active な全エントリが global_club_id を持つようになった（coderdojo.jp#1900）ので、Clubs DB との突合を名前照合から UUID 直結に切り替え、dojo2dojo.csv（301 行）を削除します。

名前照合の何が問題だったか

問題	実例
新しい Dojo のたびに dojo2dojo.csv へ 1 行足す運用が必要	追加漏れが実際に起きていた
Clubs 側で改名されると追従できない	那覇の登録名が変わっていた
同名クラブが二重登録されていると先に現れた方を拾う	流山・古河

同じ入力データで新旧の出力を比較しました

「地図が変わらないこと」を確かめるため、同じ _data/*.json に対して main のスクリプトと本 PR のスクリプトを走らせ、出力を突き合わせています。

	main（名前照合）	本 PR（UUID 直結）
日本のマーカー	195	202
GeoJSON features	1,309	1,316

地図から消えた Dojo: 0 件

増えた 7 件（CSV に行が無く漏れていたもの）

Dojo	Clubs 上の登録名
播磨科学公園都市	テクノ@光都
八戸@吹上	八戸@鮫
川西	CoderDojo川西
明石	Akashi @ Akashi City Office
吉祥寺	Coderdojo Kichijoji
氷見@bigberries	Himi @ Big Berries
豊橋	CoderDojo Toyohashi

名前が一致しないもの（八戸@吹上 ⇔ 八戸@鮫）や表記ゆれ（Coderdojo ⇔ CoderDojo）が並んでいます。名前照合が構造的に取りこぼしていた分です。

これで active な 202 エントリが全件地図に載ります（突合できなかったもの 0 件）。

座標が動いた 2 件（流山・古河）— いずれも約 0.1 km

流山: [139.937825, 35.877079] -> [139.938719, 35.876549]
古河: [139.711416, 36.175635] -> [139.710699, 36.176853]

Clubs 側に同名クラブが 2 件ずつ登録されており、main は「名前で先に見つかった方」を拾っていました。本 PR は coderdojo.jp が global_club_id で指定した方を選びます。

Nagareyama  46a7f225-...  ← main が拾っていた
Nagareyama  7d3b2a2d-...  ← coderdojo.jp が指定している方

同じ町内での移動で、どちらを拾うかが Clubs API の返却順まかせでなくなった結果です。

名前で救済する経路は置きません

active な全エントリが global_club_id を持つことは coderdojo.jp 側の spec が保証しており、UUID の無い Dojo が入るとあちらの CI が落ちます。こちらに手動のマッピングを残す理由がなくなりました。

あわせて、名前照合を前提にしていた次のものを削除しています。

• dojo2dojo.csv と _config.yml の exclude 設定
• 突合の情報源が Japan DB 自体になり到達不能になったガード（🐛 日本の Dojo が海外 Dojo として描画される不具合を直す #43 で入れたもの）
• matched_by（どの経路で載ったかの記録）とその検査

静かに壊れる経路を塞ぎます

名前照合には「壊れても縮退して生き延びる」性質がありました。_data/dojos_japan.json が空でも、CSV とローカルのデータだけで日本のマーカーは出ていました（ロゴがデフォルトになるだけ）。UUID 直結にはその性質が無く、入力が空なら日本のマーカーは全滅します。

海外分 1,100 件あまりは残るため、既存の GeoJSON 検査では検出できません。次の 4 つで塞ぎます。

追加	内容
scheduler_daily.yml の件数ガード	日本側データが 300 件未満なら停止（Earth 側の 1000 件ガードと同じ形）
deploy_to_pages.yml の件数・UUID 数ガード	取得は成功したが中身が劣化した場合に、コミット済みデータへ復元させる
tests/dojo_matching_test.rb	入力と出力の両側に下限。UUID の書式・一意性、マーカーの重複を検査
突合レポート + Slack 通知	載らなかった active な Dojo を理由付きで書き出し、要対応のものだけ通知

deploy_to_pages.yml のガードを足した理由

Earth 側には件数チェックがあるのに Japan 側には無く、挙動が割れていました。

状況	ガード追加前
取得が例外で死ぬ	復元パス → コミット済みデータでデプロイ成功
取得は成功するが中身が劣化	復元パスを素通り → 後段の rake test でデプロイ全体がブロック

後者はこのステップが明記する目的（「Geolonia 障害時の緊急デプロイが外部 API の状態に左右されてはならない」）を破ります。劣化時は復元パスへ落とすようにしました。

入力	DOJOS	UUIDS	判定
正常	340	264	通過
global_club_id 消失	340	0	発火
空配列	0	0	発火
一部だけ取得	100	68	発火

通知対象に no_uuid を加えました

当初は uuid_not_in_clubs だけを通知し、「UUID が無い状態は新規追加直後にも起きるので通知しない」としていました。UUID 必須化でこの前提が逆転しています。 coderdojo.jp の spec が全 active に UUID を強制する今、no_uuid が出たら上流の保証が破れた信号なので、通知します。

club_excluded_by_status_or_coordinates（Clubs 側で座標が消えた・活動中でなくなった）はこちらから直せないため、ログのみに留めます。

検証

• bundle exec rake test → minitest 14 runs + 7 runs / 0 failures、HTML-Proofer 成功
• RED を確認: next if japan_dojo.nil? を外すと、日本の Dojo が海外用フォールバックで描画されテストが落ちることを実測
• 劣化データ 3 パターンで deploy_to_pages.yml のガードが発火することを実測（上表）
• 通知判定を実データで実行し、正常時は通知しないことを確認

ついでに整理したもの

対象	内容
dojo2dojo.csv 前提の記述	CLAUDE.md のトラブルシューティング手順を UUID 突合のものに差し替え。deploy_to_pages.yml のコメントも更新
fetch_latest_data.sh	存在しない rake cache_dojo_logos を呼んでいた（#44 でロゴキャッシュを消した際の取り残し）
/dojo2dojo.json → /dojos.json	dojo2dojo は CSV に由来する名前で、CSV を消すと指すものが無くなる。中身は「地図に載った日本の Dojo 一覧」なので dojos.geojson の隣に dojos.json が並ぶ形にした。日本の 202 件のみで海外は含まないため、その旨をページに明記している。⚠️ 旧 URL は残していません
_plugins/build_hooks.rb	system() の終了コードを捨てていたため、GeoJSON の生成が失敗してもビルドは成功し、コミット済みの古い地図がそのまま出荷されていた。exception: true を足して止める

最後の 1 件は、わざと失敗させてビルドが停止することを確認しています。

Command failed with status (1): [ruby _tasks/upsert_dojos_geojson.rb]
_plugins/build_hooks.rb:13:in 'Kernel#system': Command failed with exit 1

PR でテストが走っていませんでした

作業中に気づいた別の問題です。ワークフロー 5 つのうち PR で起動するのは claude-review と dependabot だけで、どちらもテストを走らせていませんでした。

bundle exec rake test は deploy_to_pages.yml の中にあり、main への push 時にしか走りません。つまりテストが落ちるのはマージした後で、デプロイがブロックされる形です。

本 PR は安全性の根拠を新しいテストに置いているのに、その根拠が PR 上で一度も検証されない構造でした。on: に pull_request を足し、次の 2 ステップを PR ではスキップします。

ステップ	PR での扱い	理由
🌐 データ取得	スキップ	コミット済みデータだけで検証すれば、PR の結果が外部 API の状態で揺れない
🔧 Build & Test	実行	これが目的
🔑 API キー注入	スキップ	デプロイしないので不要。fork からの PR には secrets が渡らない
🚀 Deploy	実行されない	元から github.ref == 'refs/heads/main' で守られている

pull_request イベントの github.ref は常に refs/pull/N/merge になるため、fork 側のブランチ名が main でもデプロイ条件には一致しません。また fork からの PR では GITHUB_TOKEN が read-only で secrets も渡らないため、仮に条件をすり抜けても push は失敗します。

データ取得をスキップした時 steps.fetch.outcome は 'skipped' になるので、復元ステップ（== 'failure'）も正しくスキップされます。

ci.yml に改名しました

テストとデプロイの両方を持つ実態に名前を合わせ、ジョブにも表示名を付けました（PR のチェック欄に deploy とだけ出るのは実態と違うため）。

branch protection とルールセットがいずれも未設定であることを確認済みで、required check 名の互換問題は起きません。将来設定した後だと改名が破壊的変更になるため、今のうちに直しています。README のバッジと CLAUDE.md の手順も追従させました。

なお、これで防げるのは「リポジトリの中身が原因でテストが落ちる」場合です。main への push 時は取得した実データでテストするため、「PR は green だがマージ後に外部データ起因で赤」は残ります（その場合は復元パスで縮退します）。

この PR に含めていないもの

連名道場の個別表示は含めません。西宮・梅田（2 箇所）と大田・邑南、他（7 箇所）は 1 エントリ 1 マーカーのままで、7 箇所が地図に出ない状態が続きます。これは本 PR で生じるものではなく、counter の再設計と掲載名変更の確認を伴う別の話です。

db/dojos.yml の該当エントリがどのクラブを指すかは確定済みなので、分割の前提は整っています。

マージ後にやること

coderdojo.jp の doc/how_to_add_dojo.md に、本 PR で不要・不正確になる記述があります。マージ後すぐに doc の PR を出す必要があります。

箇所	対応
「DojoMap への反映（暫定手順）」節（160〜190 行）	丸ごと削除。dojo2dojo.csv に 1 行足す手順そのもの。doc 自身にも「UUID で突合するようになったら、この節は丸ごと削除してください」と書いてある
手順 9「マージ後、DojoMap への反映の 1 行を追加する」	削除。この作業自体が不要になる
反映確認の URL https://map.coderdojo.jp/dojo2dojo.json	https://map.coderdojo.jp/dojos.json に差し替え
global_club_id の「申請に「承認確認」URL が無い場合は省略してください」	要検討。active な Dojo で省略すると spec が落ちる