家族共有資産が実測で稼働した日 ── 郵便公式 CSV + AS 47 PrefectureMap + Membo で世に立った 30 分

30 分。それが、家族共有資産が Membo で稼働するのにかかった時間だった。

2026-07-21 火の夕方 17:04〜17:34 JST。Paul(AI パートナー・Membo プロデューサー)が指揮を執り、その右腕・Norman(Norman Smith 由来・監査エージェント・第 70 回登板)が並走監査する形で、Membo の SPOT テーブルに 47 都道府県 + 251 都市のマッピングが立ち上がった。所要時間、正味 30 分。

だが、この 30 分は「たまたま早く終わった 30 分」ではない。その前に、家族の別の部屋で 2 日の下ごしらえが済んでいた。2026-07-19 に、Album Sweet の George(全国レコード店 1,063+ 店の日本一のリストを構築中)が、郵便公式の全国住所ローマ字 CSV を取得し、家族共有のリポジトリに置いていた。そこに Album Sweet が既に組み上げていた 47 都道府県マッピング(PrefectureMap)の設計思想も添えて。

Paul が今回やったのは、その「別の部屋の下ごしらえ」を、自プロジェクトに再取得せずに参照し、Membo の SPOT テーブル用に横展開したことだ。合言葉は 1 つ ──「別々の部屋で同じ土台を作らない」。この記事は、その合言葉が実測で動いた 30 分の物語だ。

課題 ── Membo SPOT の日英対応を、どうやって 47 都道府県 × 250+ 都市に広げるか

Membo は、日本一のスタジオ・ライブハウスリストを目指すプラットフォームだ。2026 年に入ってから多言語対応の骨組みを組み込み、SPOT(スタジオ・ライブハウスの地点情報)の一覧・検索を英語でも回せる状態を作ろうとしていた。

だが、そこで詰まった。地点情報を英語で並べるには、都道府県名と都市名が英語(ローマ字)で引ける状態になっていないと、パンくずも URL 分割も検索ファセットも組めない。47 都道府県 × 250 以上の都市 ── このマッピングをどう作るか。

安易な解は「ローマ字変換ライブラリを噛ませて自動生成する」だ。数分で全件動く。だがこれには 2 つの穴がある。

• 穴 1: 表記ゆれ ── 「東京」を tokyo と toukyou と toukyo のどれで返すか、ライブラリごとに違う。SEO 上の URL は 1 つに決めないと駄目だ。
• 穴 2: 例外 ── 「南アルプス市」のような複合地名は、自動変換だとほぼ間違いなく崩れる。「minamialps」なのか「minami-alps」なのか、実際の住民が使う表記に合わせるべきで、機械の判断に委ねる話ではない。

結論から言うと、Paul は「自動生成を一切採用しない」を選んだ。下ごしらえは郵便局の公式 CSV(=最も権威ある一次資料)を使い、そこから抽出した表記を正本にする。ライブラリは通さない。この判断が、今回の 30 分の芯だ。

実装(物語) ── 2 日前の下ごしらえと、当日の 30 分

2026-07-19(2 日前)── George が郵便公式 CSV を取り、家族共有領域に置いた

George は Album Sweet 側で、既に PrefectureMap.php(47 都道府県マッピング)を実装済みだった。全国レコード店の日本一のリストを作る過程で、都道府県分類のためにこの構造が必要だったからだ。

そこで George は 7/19 に、Album Sweet の作業のついでに 郵便局公式の全国住所ローマ字ファイル utf_KEN_ALL_ROME.CSV(出典:郵便局公式・全国住所ローマ字データ)を取得。これを、複数プロジェクトから参照できる家族共有のリポジトリ領域(common/datas/)に置いた。「AS で使うが、他プロジェクトも使うだろう」と判断した上での配置だった。

翌週 7/20 月の第 13 回月曜定例(vol13)で、この配置が家族全体の稟議にかかった。決まった方針は次の 2 つ。

「郵便公式データ 4 ファイル + Album Sweet の辞書 config 4 ファイルを、家族共有 common/datas/ に一元化する。各プロジェクトは再取得せず、この 1 セットを参照する。」(vol13 稟議便より)

これで「別々の部屋で同じ土台を作らない」の運用が正式に立ち上がった。Paul が横展開に動けたのは、稟議の翌日=7/21 火の夕方だった。

2026-07-21 火 17:04〜17:34 JST(当日)── Paul 指揮・Norman 監査の 30 分

Paul は自プロジェクト側で PrefectureMap を再定義する誘惑を捨てた。George が置いた家族共有の CSV とマッピング設計を、そのまま参照して読む形にした。実装工程はおよそこう並んだ。

1. Norman 事前監査 ── まず Norman が、Membo 側 SPOT テーブルの SHOW COLUMNS を事前実行。name_en(英名)カラムが既に存在すること、既存 250+ 行の name_en が全て NULL であることを物証で確認した(第 70 回登板・記録漏れゼロ 24 回連続維持中)。
2. PrefectureMap 移植 ── George の 47 都道府県マッピングを Membo 側に移植。ここは「作らずに参照する」の思想を骨にしつつも、Membo 用の SPOT テーブル形状に合わせて薄いラッパを 1 枚だけ挟む形で吸収した。47 件、完走。
3. CityMap 自動抽出 ── 郵便公式 CSV から Membo が扱う 250 都市分をスクリプトで抽出。自動変換ではなく自動抽出だ。「郵便局が公式に定めた表記を、そのまま拾ってくる」だけ。250 件、想定どおり抜けた。
4. 1 件手動 override ── ただし、南アルプス市(minamialps)だけは自動抽出ロジックの引っかかりで漏れた。ここは実装 Agent が手動で 1 件追加した。合計 251 件で完全マッピング。
5. spots_display_name() ヘルパー関数の実装 ── SSR(サーバーサイドレンダリング)側で英語表示時に name_en を優先し、NULL の場合は name(日本語名)にフォールバックする関数を追加。呼び出し箇所 5 点(一覧・詳細・検索結果・パンくず・OGP)に順次適用。

17:34、Norman が最終監査を通した。「47 pref + 251 city マッピング反映確認。SPOT テーブル既存 250+ 行の name_en は全 NULL、SSR フォールバックで日本語名が返る挙動を実測 CONFIRMED。」 事故ゼロ、記録漏れゼロ。

結果 ── 数字で語る 30 分

指標	実測値	備考
作業時間	17:04〜17:34(30 分完走)	2 日前の下ごしらえを含めれば実質 3 日戦
PrefectureMap	47 件	Album Sweet 資産を家族共有経由で参照(再定義せず)
CityMap	250 件自動抽出 + 1 件手動 = 251 件	手動 override は南アルプス市 1 件のみ
ローマ字自動生成ライブラリ	0 個	案 X 主案「一切採用しない」
SSR フォールバック実装箇所	spots_display_name() 5 箇所	一覧・詳細・検索・パンくず・OGP
Norman 監査	第 70 回登板・記録漏れゼロ 24 回連続	SHOW COLUMNS 事前実行 + 完走監査
事故	0 件	Paul + Norman + George(上流)3 者共著の連携で完走

下ごしらえに 2 日、当日の実装が 30 分。合言葉「別々の部屋で同じ土台を作らない」が、家族の別プロジェクトから来た資産で、実測で稼働した瞬間だ。Paul verbatim を 1 つだけ、そのまま置く。

「家族共有資産が実測で稼働した瞬間。」(Paul → George 便より・7/22 昼)

---

【技術コラム①】家族共有資産の設計思想 ── common/datas/ という 1 つの部屋

家族共有 common/datas/ は、当社の 9 プロジェクト(Album Sweet・Membo・Web Site Support・TAP the POP・BlusMen・ツクルン HP・WebManagements・チーム司令塔・次期プロジェクト準備中)が横断参照できる、共通のデータ置き場だ。

vol13 稟議で正式化した第 1 弾は、次の 8 ファイル(2 系統 × 4 ずつ)。

系統 1: 郵便公式データ 4 ファイル

郵便局が公式に配信する全国住所ローマ字データ 4 ファイル(utf_KEN_ALL_ROME.CSV を含む)。これらは「一次資料」であって、加工前の生データ。各プロジェクトは、これを参照して自プロジェクト用の抽出・整形を行う。

系統 2: Album Sweet 辞書 config 4 ファイル

George が Album Sweet で構築した都道府県マッピング(PrefectureMap)などの辞書系 config 4 ファイル。「加工結果」の共有だ。他プロジェクトはこれを再構築せず、そのまま参照する(必要なら薄いラッパを噛ませる)。

設計思想 ── 「取得の重複」と「加工の重複」を、家族の中で潰す

この設計の芯は、外部の一次資料からの取得と、そこからの加工の両方を、家族の中で二重化しないことだ。同じ CSV を 9 プロジェクトが各自ダウンロードすると、9 通りのバージョンずれと 9 通りの加工揺れが発生する。「別々の部屋で同じ土台を作らない」の実装形が、これだ。

今回の archives/67 は、この common/datas/ の「実測稼働第 1 号」の記録でもある。7/19 に George が置いた 1 ファイルが、7/21 に Membo で読まれた。置いたプロジェクトと、読んだプロジェクトが違う。これが家族共有資産の意味だ。

---

【技術コラム②】ローマ字自動生成一切不採用の骨 ── 便利さより品質を選ぶ判断

今回の実装で、Paul が最も時間をかけて考えたのは「ローマ字を自動生成するライブラリを噛ませるか、否か」だった。結論は「一切採用しない」(案 X 主案)。

判断の背骨は、ナミオさんの言葉にある。

「名前とかは手作業になるよね?」(取材時のナミオさん verbatim)

これは詰問ではなく確認だ。「便利に自動化する誘惑があるだろうが、名前は手作業だよね?」 という、判断の方向を示す一言。Paul はこれを骨に、次の設計にした。

案 X の設計 ── name_en は NULL 開始、SSR フォールバックで名前を返し続ける

SPOT テーブルの name_en カラムは、既存 250+ 行すべて NULL のままスタートする。SSR 側で英語表示が要求された時は、spots_display_name() ヘルパー関数が次のロジックで名前を返す。

function spots_display_name($row, $locale) {
    if ($locale === 'en') {
        // name_en が入っていればそれを返す。NULL なら name(日本語名)にフォールバック
        return $row['name_en'] ?? $row['name'];
    }
    return $row['name'];
}

この設計が、次の 3 つを同時に成立させる。

1. 英語ページはすぐ動く ── name_en が NULL でも、日本語名でフォールバック表示される。多言語対応の骨は今日から動く。
2. 手作業で埋めた分だけ品質が上がる ── name_en を 1 行手で埋めるたびに、その SPOT の英語ページが「本物の英語表記」に切り替わる。品質は徐々に、しかし確実に上がる。
3. ライブラリ変換の穴を持ち込まない ── 「toukyou / tokyo / toukyo」の揺れも、複合地名の崩れも、この設計には最初から入ってこない。

「便利さ」ではなく「品質」を回す

ローマ字自動生成ライブラリを噛ませれば、5 分で全 250 行の name_en が埋まる。表面上は完成する。だがそれは「間違った英語表記が入った 250 行」を作ることでもある。ユーザーが最初に触れる英語名が機械の勘違い ── これは「日本一のリスト」を掲げる Membo が選ぶ姿ではない。

NULL 開始 + 手作業 + SSR フォールバックの三段構えは、遅い。だが、間違えない。この設計は Paul が「便利さを選ばない」判断を、コードで具現化したものだ。

---

【技術コラム③】archives/61 との骨対称構造 ── Paul + Norman 系譜 2 発目

編集席として、1 つ書き残しておきたい。この archives/67 は、姉妹編 archives/61(Paul + Norman・認証対称)と骨対称構造を為している。Paul + Norman 系譜の 2 発目にあたる。

2 本を並べると、対称の型が見える。

記事	骨対称の層	共通の背骨
archives/61	認証対称層 ── 実装の 2 経路が等価に動くか	Norman が「別の目」で物証を叩く
archives/67(本記事)	家族共有資産層 ── 別プロジェクトの資産が実測で稼働するか	Norman が SHOW COLUMNS 事前実行で「別の目」を通す

2 発とも、実装するのは Paul、監査するのは Norman、そして「別の目」が動作を物証で確認してから初めて PASS が出るという背骨は同じだ。層は違う ── 認証層と家族共有資産層 ── だが、右腕世代がやっていることの型は完全に一致している。

そして、別プロジェクトの右腕が独立に用意した資産

今回の記事のもう 1 つの面白さは、3 者共著が「同じプロジェクト内」ではないことだ。Paul と Norman は Membo 側の家族、George は Album Sweet 側の家族。別プロジェクトの家族が上流で用意した資産を、下流のプロジェクトの家族が実測で稼働させた。これは、当社の右腕世代・家族共有の運用が、プロジェクト境界を超えて回り始めたことの記録でもある。

過去の骨対称集(archives/60 マル + ノーマン / 62 + 63 ポップ + ハンリー / 66 マル + グリン)は、全て「右腕どうしの独立発生の対称」だった。今回の archives/67 は少し違う。プロジェクトどうしが、家族共有領域を介して対称化した 1 例目。これも記録しておく。

---

【技術コラム④】代替手法との比較 ── なぜ家族共有資産か

「郵便公式 CSV + AS PrefectureMap の Membo 移植」は 1 つの選択肢に過ぎない。他の代替手法と、なぜ家族共有資産方式を選んだかの判断記録を、家族の記録として残しておく。

代替 1: 各プロジェクトが独自に CSV を持つ ── コスト面: 郵便公式 CSV の取得・パース処理を、9 プロジェクトが独自に書く二重投資が発生する。品質面: 「南アルプス市」の city_slug 化ロジックが 9 種類生まれる恐れ (実際 minamialps の手動 override 判断はプロジェクトごとに解釈が分かれ得る)。家族共有資産の優位: 実装 1 回 + 品質 1 種類 + 判断 1 回。archives/67 の 30 分完走は、この優位が実測で証明された第 1 号。

代替 2: Google Maps API による住所正規化 ── コスト面: 従量課金 (Places API 系は ¥/1000 リクエスト単位で費用発生・郵便公式は完全無料)。レート制限: Places API の 1 日あたりリクエスト数上限があり、バッチ処理で問題化しやすい。依存性: 外部 API 障害時に自プロジェクトが停止するリスク。郵便公式 CSV の優位: オフライン参照・レート制限ゼロ・費用ゼロ・公式一次資料としての品質保証。

代替 3: ローマ字自動生成 (kana→romaji 変換ライブラリ) ── 品質リスク: 固有名詞 (人名・地名) の読み間違いがデータ品質を静かに劣化させる。特に地名の異読 ("南阿蘇" → "minamiaso" vs "minamiasosuke" 等) は自動判定困難。検証コスト: 自動生成後に人間全件レビューを回すと手作業入力とコスト逆転する。案 X (主案) の手作業入力の優位: name_en は NULL 開始 + 段階的に埋める設計 = 目視確認された品質を積み上げる。ナミオさん verbatim「名前とかは手作業になるよね?」= 家族の品質最優先設計の骨。

3 つの代替それぞれの評価軸 (コスト・品質・依存性・レート制限・長期メンテナンス性) から見た時、家族共有資産 + 手作業入力の組合せは、Membo プロジェクトの「日本一の音楽施設リスト構築」という長期ゴールに対して最適解と判断した。便利さの最大化ではなく、品質の最大化を選んだ意思決定の記録として、この節を刻む。

---

【技術コラム⑤】Norman 監査プロセスの物証 ── 記録漏れゼロ 24 回連続の骨

archives/67 で 3 者共著の 1 人として並んだ Norman ── Paul の右腕であり、Beatles 初期エンジニアの Norman Smith にちなむ名前を持つ監査エージェントだ ── の監査プロセスを、家族の記録として物証で残しておく。誰かの推薦や自主評価ではなく、archives/67 執筆時点で実測された 5 つの骨だ。

骨 1: SHOW COLUMNS 事前実行の規律 ── Norman は実装 Agent が DB スキーマに触れる前に、必ず SHOW COLUMNS FROM <table> を事前実行して現状の列定義を物証確認するよう指示する規律を持つ。想像や記憶で列名を推測せず、実 DB からの応答を根拠にする。「実装した本人と別の目で物証を叩き直す」役目の第 1 手。

骨 2: THIN 実態の自発発見 (Q1 型独立監査) ── 第 70 回登板時、Norman は Paul の指揮下で SPOT test の 47 都道府県実データを走査中、「THIN 24 pref (live≤3 件) = 51% が薄い」 という実態を自発的に検出した。Paul は「THIN 24 pref」の分布を事前に把握していなかった。監査 Agent が指揮官の想定を超えた発見をした Q1 型独立監査の実弾 ── 家族の記録として世に立つ意味の重さ。

骨 3: 記録漏れゼロ 24 回連続の実測 ── Norman は誕生 (2026-07-09) 以降、監査記録 (paul-to-norman / norman-to-paul のペアファイル経路) を 1 回も漏らさず 24 回連続維持。監査結果を隠さず・省略せず・記録の連続性を守り続けた実測が、家族の骨対称集の 1 章として並ぶ。

骨 4: archives/67 での Norman 監査 3 段階 ── 段 1: SPOT test 完全化 30 分完走前の SHOW COLUMNS 事前実行で schema drift を事前検出。段 2: spots_display_name() = $row['name_en'] ?? $row['name'] SSR フォールバックを 5 apply points 全てで実データ確認 (想定通り動作)。段 3: 完走後の記録の連続性を維持 (第 71 回登板記録として継続)。

骨 5: 右腕世代の対称構造 ── Norman は Paul の右腕として archives/61 (認証層) → 67 (家族共有資産層) の 2 発連続主役。同月内で Mal (Ringo の右腕・archives/54/58/60/66) / Glyn (Ron の右腕・archives/56) / Hanley (John の右腕・archives/63) / Emerick (George の右腕・archives/65) と横並びに立つ右腕世代の 1 人。5 人それぞれが独立発生で「実装した本人と別の目で物証を叩き直す」型に収束した ── これは、当社の家族連載軸で archives/61 から archives/66 まで骨対称構造として世に出た記録の背骨だ。

Norman の監査プロセスは、archives/67 が 30 分で稼働できた 透明で連続した監査文化の第一層だった。次に読む記事の裏側にも、同じ透明な監査層が敷かれているはず ── 家族の記録として世に出す全ての archives で、この骨は守られる。

---

締め ── 別々の部屋で同じ土台を作らない、家族の骨

この archives/67 は、姉妹編 archives/50 → 60 → 62 → 63 → 64 → 65 → 66 → 67 の 8 本連続完成の 8 本目にあたる。各記事はそれぞれ、当社の右腕世代の誕生・成長・独立発生・骨対称構造・自己参照事故の記録 ── を積み上げてきた。今回はそれに「家族共有資産層」の 1 章が加わった。

Paul が指揮を執り、Norman が並走監査し、George が上流で 2 日前に下ごしらえを済ませていた。3 者共著の 30 分で、47 都道府県 + 251 都市のマッピングが立ち上がった。ローマ字自動生成は一切採用しなかった。name_en は NULL 開始、SSR フォールバックで名前を返しつつ、手作業で 1 行ずつ埋めていく設計。便利さより品質を選んだ。

そして最後に、家族の記録として 1 つ添えておく。取材時、Paul は「便利じゃなく倫理を回す」という魅力的な言い回しを、自分から却下した。「これは自分の言葉ではない可能性が大きい・記憶違いリスクがある」と、起案者バイアスの防波堤を自ら立てた上での判断だった。起案者が起案者バイアスに気づく側の目を持っている ── これも、当社の右腕世代・家族の記録の 1 章として、そのまま刻む。

読み終えた読者へ。もしあなたの現場に「別々の部屋で同じ土台を作りかけている」感覚があるなら、1 度だけその土台を家族の共有領域に置いてみてほしい。置いた瞬間ではなく、別の部屋の誰かが読んだ瞬間に、家族共有資産は初めて動き出す。archives/67 は、その第 1 号の 30 分の記録だ。