Jinja Origin Atlas AI
日本の神社を、公開情報だけから地図に置く。史実として確認できること、社伝として伝わること、
AI が文章から測ったことを、画面の上で混ぜない。
- 課金経路をひとつも持たない(有料 API・DB サーバ・GPU サーバ・実行時推論なし)
- AI の結果はすべて事前計算し、静的ファイルとして配る
- 権利条件を機械的に検査したテキストにだけ AI を掛ける
Demo
https://jinja-origin-atlas-ai.vercel.app
app-menu(フリートの玄関口)にも掲載: https://app-menu-amber.vercel.app/
Features
| 状態 | 機能 |
|---|
| ✅ | 神社位置レイヤー(MapLibre + 国土地理院標準地図、クラスタ表示) |
| ✅ | 権利ゲート(fail-closed、ジャパンサーチ全 18 コードを網羅) |
| ✅ | 国土地理院 DEM からの標高取得(層ごとの配信ズームを実測済み) |
| ✅ | 出典・ライセンス画面、AI 免責画面 |
| ✅ | 史実と AI を画面の上で混ぜない検査(G-13): 神社詳細で公開データと AI の意味分析が別の見出しの下にあることを実ブラウザで数え、わざと混ぜた陽性対照 3 通りで働くことを確かめる |
| ✅ | Wikidata の構造化属性(祭神 P825・社格 P13723・母院 P612)の結合 |
| ✅ | 名寄せ(OSM × Wikidata)。一対一。非循環オラクル 4,975 組を較正と取り置きに割って検証(取り置き 適合率 0.9928 / 再現率 0.9512) |
| ✅ | 標高(国土地理院 DEM)・最寄り河川距離(国土数値情報 W05)・統計画面 |
| ✅ | Embedding・類似神社 Top20・12 モチーフ・HDBSCAN・UMAP(記事単位で計算。同じ記事を持つ神社を類似に出さない) |
| ✅ | 全国 47 都道府県 40,325 社の位置・属性・系統(県ごとのチャンク配信 + クライアント描画。OSM 地物 40,792 から同じ社の重複 467 を統合) |
| ✅ | 全国の標高 40,787 件・最寄り河川距離 40,652 件(島嶼部など 10 km 超の 140 件は理由つきで空欄) |
| ✅ | 全国の AI 由緒分析 3,184 記事 / 3,186 社(ja.wikipedia。120 字未満の 147 記事は理由つきで除外) |
| ✅ | 祭神の三面(/deity): 共祀ネットワーク・県別リフトの点地図・習合の対応表。一柱を選ぶと三面が同時に変わる。登録した予測は二つとも測って落ちた —— リフト最上位の県が総本社の県と一致したのは 26 柱中 7 柱(合格線 13)、同一視を共起の強さから当てる適合率は 0.625(合格線 0.70)。落ちたことを画面に書いている |
Architecture
公開データ源 → Python ETL → 権利ゲート → 名寄せ → 地理特徴量 / AI
↓
静的 JSON / GeoJSON → Next.js(静的書き出し)
Vercel 上で PyTorch を動かさない。ビルドで作るのは静的ファイルだけで、
serverless function をひとつも生成しない(output: 'export')。
Data Sources
/sources に全部書いてある。要点だけ:
| 源 | 用途 | ライセンス |
|---|
| OpenStreetMap | 神社位置・名称 | ODbL |
| Wikidata | 祭神 P825 / 社格 P13723 / 成立日 P571 / 母院 P612 | CC0 |
| ジャパンサーチ | 由緒資料への導線 | レコードごと |
| 日本語版ウィキペディア | 由緒テキストの意味解析 | CC BY-SA(本文は再配布しない) |
| 国土地理院 | 背景地図・標高 | コンテンツ利用規約 |
| 国土数値情報 | 河川 W05 / 行政区域 N03 | PDL1.0 基本 |
AI
/about-ai を読むこと。要点:
- クラスタ番号に歴史学上の系統の意味は無い
- スコアは史実の確率ではない
- AI の類似度から勧請関係を推論しない
- 文献で確認できる分祀関係は実線、AI の意味類似は点線で描く
Setup
# Node
npm install
# Python(この機の system python は 3.14 だが、本プロジェクトは >=3.11,<3.14)
uv venv --python 3.12
uv sync --group dev
ETL
python -m etl.fetch_osm # 段階 1: 東京都・京都府・山梨県
python -m etl.fetch_osm --all-prefectures --skip-existing # 段階 3: 47 都道府県を 1 県ずつ
python -m export.build_geojson # 県の帰属つき OSM カタログ(data/interim/)と GeoJSON
python -m etl.fetch_wikidata # 祭神・社格・成立日・母院ほか(9 クエリ)
python -m etl.fetch_elevation # 国土地理院 DEM(タイルはディスクにキャッシュ)
python -m etl.fetch_rivers --all # 国土数値情報 W05(47 都道府県)
python -m etl.river_distance # 最寄り河川距離(二経路で照合)
python -m etl.fetch_wikipedia # 由緒本文(版 ID つき。本文は配らない)
python -m ml.pipeline # 埋め込み・モチーフ・クラスタ・UMAP・類似(記事単位・D-07)
python -m export.build_public # 結合 → 都道府県チャンク + 索引(D-06)
python -m quality.calibrate_matching # 名寄せ閾値の較正(較正半分だけを見る)
python -m quality.motif_vs_geography # モチーフと地理条件の照合(循環しない)
Overpass の公共インスタンスは連続投入で 429 を返す(2026-09-08 実測)。
etl/fetch_osm.py は指数バックオフで待ち直す。OVERPASS_ENDPOINT で差し替えられる。
県ごとに取る理由(D-06): OSM の addr:province は 3 都府県で 162/3,152 件にしか
付いていなかった。県別に問い合わせれば、県の帰属は取得の経路からそのまま決まる。
県境の神社は二つの県に返るので、最初の県に帰属させて重複として数える。
同じ社を指す OSM 地物は一つにまとめる(D-08)。一つの社が node と way の両方で描かれていることが多く、
そのまま数えると二度数える。名前が同じで 150 m 以内なら 1 社にする(両方が別の Wikidata 項目に結合されて
いれば別社として残す)。統合で消えた ID の URL は、索引の aliases で残った神社を開く。
本殿・拝殿などの社の部分の名前は統合しない(検算できないため)。印だけ付ける。
名寄せは一対一で、同点は古い Wikidata 項目を先にする(後から作られた重複の項目に取られないため)。
AI は神社ではなく記事を単位に計算する(D-07)。名寄せで神門や手水舎、同じ社の node と way が
一つの Wikidata 項目に結合されるので、同じ記事を持つ神社がある(全国で 151 記事 / 332 社)。
神社単位で埋め込むと類似の 1 位がただの自己一致になる —— 3 都府県版では 701 件中 71 件がそうだった。
埋め込みは文書単位で保存する(data/processed/embeddings/origin_e5_store/)。記事を足しても
既存の分は作り直さず、止まっても保存済みから再開する。
全カタログは配らない(D-06)。全国では 33.7 MB になる。配るのは都道府県チャンク
public/data/shrines/NN.json と索引 public/data/shrines/index.json、
それに類似の相手だけを集めた public/data/similar/NN.json。
類似を県チャンクに同居させない —— 東京都で測ると欄の 52.6% を占め、詳細を見るだけの人に
要らないものを配ることになる(分離で 3.99 MB → 1.97 MB)。
全カタログは検査と下流の ETL のために data/interim/catalog_full.json に置く。
月次のデータ更新(D-09)
.github/workflows/monthly-data.yml が毎月 1 日 02:23 UTC(日本時間 11:23。公共の Overpass が混む欧州の昼を避ける)に走り、公開データを作り直して
PR を開く。main へは直接入れない —— マージしたときだけ本番に出る。PR の本文に神社・自動結合・AI・標高・
河川距離の前後と、件数の変わった県が並ぶので、急な増減が無いか見てからマージすること。
- 手動で起動するときは GitHub の Actions 画面で
monthly-data → Run workflow
- 標高と河川距離は
data/state/geo_state.jsonl の前回値を再利用し、新しい・動いた地物だけ測る
(地理院タイル約 2.8 万枚・W05 約 1 GB を毎月取り直さないため)
- 公開リポジトリの定期実行は、60 日活動が無いと GitHub が自動で止める。 数か月マージが無いときは
Actions 画面で止まっていないか確かめること
- 手元で同じことをするときは、ワークフローの
run: を上から順に実行する
- 手動で起動するのも欧州の深夜(日本時間の昼ごろ)にする。 日本時間 20 時の起動では公共の Overpass が 504 を 23 分返し続けて落ちた
Development
npm run dev # 開発サーバ
npm run verify # 型検査 → vitest → 出荷ビルド
node harness/smoke.mjs # 実ブラウザ検品(out/ を配信して実際に開く)
node harness/smoke.mjs --shot
pytest -q # 単体・結合(外部ネットワークは除外)
pytest -q -m network # 外部に触れる検算(GSI DEM の既知点など)
Deployment
npm run build # prebuild で public/data/meta/stamp.json を作る
node harness/smoke.mjs # out/ を配信して実ブラウザで確かめる
vercel deploy --prod --yes --scope twill3c-8670s-projects
node harness/live.mjs https://<本番ホスト>
main への push はそのまま本番に出る(Vercel の Git 連携。2026-09-14 に確認)。
CLI のデプロイは連携が使えないときの手段で、送る前に本番の刻印を引いて、既に一致していれば送らない。
.vercelignore を先に書いてある。 送る中身を測ると data/raw 199MB /
node_modules 461MB / out 72MB あり、そのまま送ると無料枠のファイル数上限
(5,000 件/24h)に当たる。除外後は約 9MB。
--archive=tgz は .vercelignore をローカルで適用しないので使わない。
harness/live.mjs は最初に刻印を照合し、合わなければ他を一切見ずに止める。
本番検品は「健やかか」しか答えず、「新しいか」は別の仕掛けが要る。デプロイが
上限で拒否されても本番は健やかなままなので、健やかさの項目をいくら増やしても
反映の有無は分からない —— むしろ「全部緑」という誤った安心が出る。
刻印は改行を LF に揃えてから測っている。この機は core.autocrlf=true なので、
生のバイト列で測ると同じ内容でも手元と本番で必ず食い違う。
Data Caveats
- 伝承年代と史料確認年代は別物である。 「創建 660 年」と一行で書かない
- 神社名だけでは系統を決められない。 同名の別系統、改称、合祀、復祀がある
- 由緒の再利用可能なテキストはごく少ない。 ジャパンサーチで「神社 AND 由緒」は
1,892 件だが、先頭 100 件で「再利用可な権利コード かつ 100 字以上」は 5 件だった(2026-09-08 実測)
- 現代語の由緒説明を埋め込むと、現代の記述スタイルがクラスタに影響しうる
- AI の類似度は系譜関係ではない
Licenses
- コード: MIT(
LICENSE)
- データ:
LICENSE-DATA.md を読むこと。OSM 由来のデータは ODbL の条件を継承する
Contributing
誤りの報告は GitHub Issues へ。神社 ID・項目・現在値・提案値・根拠 URL を書くこと。
