Fivevai Machiscore Frontend

国のオープンデータで、首都圏の街の住みやすさを5カテゴリ500点満点に採点する、広告に依存しない不動産メディア。

散在する公的統計 → 街ごとの『住みやすさ』スコアと数千ページのSEOメディア首都圏約242自治体を5カテゴリ500点で自動採点（月次更新）

見るだけAI難易度 4/5Python(スコア計算) / Next.js 14(SSG/ISR) / Supabase(PostGIS) / ローカルLLM(Qwen3)

このPoCから得た実装知

1国のオープンデータは『翻訳』して初めて意味を持つ。500点満点の指標に落とすと比較できる
2本文はローカルLLMで量産しつつ、品質ゲートとハルシネーション検出でnoindex制御する
3スコアの正しさはゴールデン値（武蔵野425.5/港378/奥多摩227）で固定し、再現できなければ実装が誤り

判断材料

AI 権限レベル: 見るだけAI
想定対象部門: 事業企画マーケティング経営
扱うデータ: e-Stat（国勢調査等）国土数値情報公的統計
人間の承認: 不要（閲覧・通知のみ）
失敗時の止め方: 公的オープンデータの集計・表示のみ。LLM生成本文は品質ゲートを通し、基準未達はnoindexで公開しない
導入難易度: 4 / 5
初期導入期間: 数ヶ月（採点設計＋データ整備が中心）
必要な社内担当: 事業企画・プロダクトデータ/スコア設計エンジニア（Python/Next.js）
連携対象 SaaS: Supabasee-Stat国土数値情報Google Search ConsoleローカルLLM（LM Studio）
最小構成: 1カテゴリ・少数自治体のスコアと1種類のページから始める
横展開先: オープンデータ翻訳メディア地域比較・ランキング不動産・引越し送客PropReport（物件レポート）

このPoCが向いている会社

以下に1つでも当てはまる会社では、効果が大きい。

公的データや自社データを使った新規メディア・新規事業を検討している
広告や主観に依存しない『客観指標』で差別化したい
大量ページ（Programmatic SEO）を、品質を保ちながら量産したい
LLMで本文を作りたいが、誤情報（ハルシネーション）の公開が怖い

経営インパクト

Before

街の住みやすさを横並びで比較できる、広告に依存しない指標がなかった

After

公開データで首都圏の街を5カテゴリ500点に採点し、広告なしの不動産メディアとして公開（machicore.com）

削減時間: 自治体ごとの調査・記事執筆 → 月次バッチで自動採点・自動生成
減ったリスク: LLM本文の品質ゲート＋ハルシネーション検出でnoindex制御
判断の改善: 街選び・引越しを、主観ではなくスコアで比較できる
横展開できる型: オープンデータ→スコア→Programmatic SEOメディア（1基盤→数千ページ）

このデータがあれば、これができる

最小構成 ─ まずここから

INPUT DATA

▸国のオープンデータ（e-Stat/国土数値情報）
▸対象自治体の境界・サンプル点

YOU CAN DO

▸5カテゴリ500点満点のスコア
▸自治体ごとのページ
▸グレード（A/B/C/D）

発展構成 ─ ここまでつなぐと強い

INPUT DATA

▸昼間人口補正データ（治安）
▸ペルソナ別の重み
▸比較ペアの定義

YOU CAN DO

▸治安カテゴリ（補助）
▸ペルソナ別スコア
▸ローカルLLMによる要約/適性/FAQ/カテゴリ解釈
▸タグ記事（6セクション）
▸比較固定URL（最大3自治体）
▸都道府県内ランク
▸GSCへのsitemap自動送信

Pain — どんな痛みがあったか

街の「住みやすさ」は、不動産サイトの口コミや広告、主観的なランキングに頼りがちで、誰も客観的に比較できない。国は e-Stat や国土数値情報という膨大なオープンデータを公開しているが、生のままでは住民にも事業者にも使えない。自治体ごとに調べて記事化するのは人手では回らず、数千ページを品質を保って作るのは現実的でなかった。

Intent — なぜ作ったか

国のオープンデータを「街の実力」に翻訳し、広告に依存しない客観指標として誰でも比較できるメディアにする。採点も本文生成も自動化しつつ、品質は人とゲートで担保する。

Approach — どんなアプローチか

バックエンド(Python)が国のオープンデータを取り込み、自治体ごとに9点サンプリングして防災・教育・交通・資産・生活の5カテゴリ500点満点（治安は補助）を月次計算する。空間演算は geopandas/shapely、採点設計はゴールデン値で固定。ローカルLLM(Qwen3 / LM Studio)が要約・適性・FAQ・カテゴリ解釈など8種テキストを月次生成し、品質ゲートとハルシネーション検出で基準未達はnoindexにする。結果を Supabase に UPSERT し revalidate API を叩く。フロント(Next.js 14)が403ページ（将来2,000+）をSSG/ISRで生成し、JSON-LD 8種・sitemap・OGPでSEOを固め、Vercel Cronで毎週GSCにsitemapを自動送信する。

処理の流れ

1国のオープンデータを取り込み→
2自治体ごとに9点サンプリング→
35カテゴリ500点を月次計算（ゴールデン値で検証）→
4ローカルLLMで本文を生成→品質ゲート/noindex→
5SupabaseにUPSERT→revalidate→
6フロントがISRでページ再生成→
7毎週GSCにsitemapを自動送信

Rationale — なぜその考え方に至ったか

主観や広告に頼らず「国が出している事実」だけで採点することが、メディアの信頼の核。LLMで量産すると誤情報のリスクが上がるため、生成は自動でも公開は品質ゲートを通す。採点ロジックはゴールデン値で固定し、変更しても基準が崩れないようにした。フロントとバックエンドを分け、バックエンドが採点・生成、フロントは表示に専念する。

Lessons — つまずきながら学んだこと

スコアの正しさは『ゴールデン値』で固定する

武蔵野425.5(A)/港378(B)/奥多摩227(D)などの固定値をテスト基準にし、再現できなければ設計が正・実装が誤りと判断する。採点ロジックを変えても基準が崩れない。

LLM本文は『生成は自動・公開は品質ゲート』

ローカルLLM(Qwen3)で月次に8種テキストを量産するが、品質ゲートとハルシネーション検出ログで基準未達はnoindex。誤情報をそのまま公開しない設計にした。

フロントの体感速度は『やらないこと』で守る

optimizeCssやホームのnext/dynamicは、フォントとクリティカルパスの競合でかえって悪化したため永続的に禁止。Core Web Vitals(LCP≤1.5s)を守るための実測ベースの制約。

バックエンドが採点・生成、フロントは表示に専念

Pythonバッチが月次でスコア・本文をSupabaseにUPSERTし revalidate APIを叩く。フロントはSupabaseを読むだけ。役割を分けたことで、採点ロジックの変更がフロントを壊さない。

改善ログ（毎週改善を続けている）

2026-05machiscore.com → machicore.com にドメイン移行（301）
きっかけ: ブランド名の変更（旧ドメインは301リダイレクト）
2026-05治安カテゴリ（昼間人口補正）を追加（東京62自治体）
きっかけ: 5カテゴリだけでは『治安』の観点が欠けていた

品質・テスト

採点はゴールデン値で固定。LLM本文は品質ゲート＋ハルシネーション検出でnoindex制御。Supabaseは PostGIS＋RLS（service_role のみ書き込み）。CIで lint/type/test/build/e2e、PRごとに Lighthouse で CWV を計測。

Approach / Rationale / Lessons / 改善ログの続きを読む

Magic Link で 60 秒。クレカ不要・退会即時。

最初の1週間でやること

採点する1カテゴリと少数自治体を決める
国のオープンデータ（e-Stat/国土数値情報）の取得元を確認する
1自治体のスコアをゴールデン値で検証する
1種類のページを作り、公開可否を品質ゲートで判定する

やらないこと

主観や広告データを採点に混ぜない（公的データに限定）
LLM生成をそのまま公開しない（品質ゲートを通す）
いきなり全自治体・全カテゴリを作らない
体感速度を犠牲にする最適化を入れない

費用対効果の考え方

自治体ごとの調査・記事執筆の人件費
広告依存からの脱却（指標で集客）
Programmatic SEO による継続的な流入
送客（不動産・引越し）の事業価値

このPoCの位置づけ

オープンデータ翻訳メディアの代表事例 — 国の事実だけで『街の実力」を採点する

口コミでも広告でもなく、国のオープンデータで街を採点する。

導入前チェックリスト

商談前に、自社側でこの 5 点を確認しておくと検討がスムーズに進む。

対象となるデータは、自社のどこにあるか
この PoC が扱うデータ: e-Stat（国勢調査等） / 国土数値情報 / 公的統計
そのデータの更新頻度はどれくらいか（毎日 / 週次 / 不定期）
人間の承認が必要な操作は何か
この PoC は閲覧・通知のみで、書き込みは行わない
想定どおり動かないとき、止める方法はあるか
この PoC の止め方: 公的オープンデータの集計・表示のみ。LLM生成本文は品質ゲートを通し、基準未達はnoindexで公開しない
社内の担当者は誰か（運用・データ・承認の窓口）
想定担当: 事業企画・プロダクト / データ/スコア設計 / エンジニア（Python/Next.js）