歴代天皇データベース 設計書

version 0.1(草案)/ 2026-07-11

0. 目的と編集方針

歴代天皇の系譜を「歴史的事実として何がわかっているか」という観点から、 中立に・出典付きで辿れるデータベースとウェブサイトを構築する。

中立性を「方針」ではなく「設計」で担保する

中立性は編集者の心がけに頼ると必ず揺らぐ。本プロジェクトでは以下の アーキテクチャ上の仕組みで担保する。

1. 3層分離 — データを次の3層に分け、混ぜない。
   • facts層: 出典に基づく個別事実(父は誰か、生年月日、在位期間)
   • derived層: facts から機械的に再計算される値(男系判定、継承距離、 兄弟姉妹リスト)。人手では書かない。「男系かどうか」は意見ではなくクエリの結果として提示する。
   • editorial層: 解説文・要約。必ず出典を伴い、facts と別テーブル。
2. 出典並記主義 — ソース間で食い違う事実は、どちらかを黙って採用せず conflict テーブルに両論を記録し、画面でも並記する。
3. 用語は定義してから使う — 「男系」「女系」「正室」「側室」「実在」は すべて本書 §1 の定義に従い、サイト上にも定義ページを常設する。
4. 引用の版固定 — Wikipedia は記事名だけでなく oldid(版ID)と取得日時を 保存し、後から検証可能にする。

サイト内リンク:何にでもリンクする(wiki的方針、2026-07-13導入)

コラム本文同士だけでなく、サイト内のどのページからでも、対応する ページが存在する用語・制度・文書・コラムには必ずリンクする。 トップページ・about・design等、コラム以外のページも対象。例: トップページで「皇室典範」に言及する箇所は 皇室典範の全文整理にリンクする、 「宮家」に言及する箇所は用語集の該当項目にリンクする、 といった具合。目的は、事典的な回遊性を持たせ、読者が気になった語を その場で深掘りできるようにすること。

この方針は今後のページ作成・改訂時に適用する。既存ページへの遡及的な 一斉適用(全ページを洗い出してリンク漏れを直す作業)は行わない。 気づいた箇所から都度直していく。

リンク先の選び方:用語集 vs 個別コラム(2026-07-13追記)

「何にでもリンクする」を実践する際、同じ言葉でもリンク先を機械的に 固定しない。判断基準は「その文が何について書かれているか」であって、 「その言葉がどこかに載っているか」ではない。

• その文が用語・定義そのものを説明・適用している(例:「父を たどれば天皇に至るので男系の女子にあたる」)→ 用語集にリンク。
• その文が歴史的な事実・人物について書かれていて、たまたま定義 済みの用語(「8人10代の女性天皇」等)を使っている→ その人物・ 出来事を実際に扱っている個別のコラム(推古天皇・奈良時代の 女帝たち・江戸時代の二人 等)にリンクする。用語集はこの種の文脈 ではリンク先として不適切(定義ページであって、人物の解説ページ ではないため)。

繰り返しやすい失敗パターン: 「歴代天皇のうち女性天皇は8人・10代 確認されているが」のような定型文を複数のコラムで使い回す際、最初に その事実を書いた場所(用語集)への連想でリンクを機械的に複製して しまう誤りが、2026-07-13に複数のコラム(世界の王位継承ルール、お 言葉のない式典、江戸時代の二人)で繰り返し発生した。同種の定型文を 別のコラムに書くたびに、リンク先を再判定すること。「前にも同じ 指摘を受けたはずだ」と思ったら、まさにこのルールを再確認するタイミング。

1. 用語の定義(サイトの根幹)

1.1 男系・女系

• 男系(父系)子孫: 人物 A から人物 B への親子リンクの経路が存在し、 経路上のすべてのリンクが「父→子」であるとき、B は A の男系子孫。

• 女系: 用語に揺れがあるため両方を定義し、サイトでは常に区別する。

  • 広義の女系(非男系): 経路上に母→子リンクを1つでも含むもの。 現代の皇位継承論議で「女系天皇」と言うときは通常こちら。
  • 狭義の女系(純母系): 経路上のすべてのリンクが母→子。

• 2×2 の区別(本人の性別 × 系統):

  	男系	女系(広義)
  男子	男系男子	女系男子
  女子	男系女子	女系女子

• これらはすべて parent_child テーブル上の経路の性質として機械判定できる (§5 の再帰クエリ)。判定結果を人手で書くことはしない。

1.2 歴史的事実として DB から導かれること(検証可能な形で)

• 女性天皇は 8人・10代(推古、皇極=斉明〔重祚(ちょうそ、同一人物が 再び即位すること)〕、持統、元明、元正、孝謙=称徳〔重祚〕、明正、 後桜町)。
• この8人は全員、父をたどれば天皇に至る「男系の女子」である。
• 母→子リンクを経由して即位した天皇(広義の女系天皇)は記録上存在しない。
• これらは主張として書くのではなく、誰でも再実行できるクエリとして同梱する。

1.3 正室・側室

時代により后妃制度は大きく異なるため、二値(正室/側室)では表現しない。

• rank(原語): 皇后・中宮・女御・更衣・妃・夫人・嬪・宮人・典侍 など、 史料上の呼称をそのまま保存。
• rank_class(正規化): primary(正室相当: 皇后・中宮など)/ secondary(側室相当)/ unknown の3値に別カラムで正規化。 正規化の対応表自体も出典付きの editorial データとして管理する。
• 例: 明治天皇の生母・中山慶子は典侍(側室相当)。近代以前は側室出生の 天皇が多数であることが、クエリで集計可能になる。

1.4 実在性(historicity)

初期の天皇には学術上実在が確認できない者が含まれる。公式の代数と学術的評価を 別フィールドで両記する。

• historicity: historical(実在が史料で確認される)/ semi-legendary(実在の可能性が論じられる)/ legendary(伝承上)
• 判定は学術的通説に拠り、必ず出典を付す。欠史八代(2〜9代)が代表例だが、 それより後の代にも及ぶ。Wikidataの分類(instance of)を機械的に確認した ところ、崇神天皇(10代)・垂仁天皇(11代)・景行天皇(12代)・神功皇后は 「伝説上の人物」、成務天皇(13代)・仲哀天皇(14代)・応神天皇(15代)・ 武烈天皇(25代)は「架空かもしれない人間」に分類されており、本DBでも それぞれlegendary・semi-legendaryとしている(2026-07-12)。実在性への 疑義は欠史八代だけにとどまらないという事実は、そのまま記録する。
• 公式の代数(126代)は皇統譜に基づく「公式の数え方」として尊重しつつ、 明治期以降の代数整理(弘文・淳仁・仲恭の追加、神功皇后の歴代外への整理)も 事実として記録する。

1.5 「126代」という数字の可変性

「126代」は古代から不変の数字ではなく、わりと最近(主に明治〜大正の約50年間)に、近代国家が天皇制度を法制化・体系化する過程で確定した数字 である。現時点で判明している、代数を揺るがしうる要因は少なくとも4つあり、 それぞれ本DBの異なるフィールドに対応させている。

1と2は共に明治〜大正という同じ時期に起きており、近代国家が「歴代とは 何か」を初めて明文のルールで確定させる必要に迫られた結果、数世紀分の 揺れが一気に整理された、という時代背景を示している。この事実自体が、 「126代」を所与の前提とせず検証可能な形で示すという本サイトの目的と 直結する。

2. データモデル(概要)

DDL は db/schema.sql 参照。要点のみ記す。

person ──< person_name          (諱・追号・諡号・幼名・通称の多重名)
person ──< parent_child >── person   (実親/養子・猶子、確度つき)
person ──< spouse >── person         (后妃関係、rank + rank_class)
person ──1 emperor              (天皇である person の付加情報)
emperor ──< reign               (在位。重祚〔ちょうそ〕= 1人に2行)
reign >──< era                  (元号。践祚〔せんそ、即位すること〕と改元はずれるため多対多)
event                           (事績・出来事。editorial層)
source / citation / conflict    (出典・行単位の引用・両論併記)

設計上の重要判断

日付の扱い(§4 で詳述)

すべての日付カラムは4点セット:

• *_date: ISO 8601 文字列(変換後の西暦)
• *_calendar: gregorian / julian / unknown(1582-10-15 より前は 歴史学の慣行に従いユリウス暦。Wikipedia も同様)
• *_precision: day / month / year / circa / unknown
• *_original: 和暦の原文(例: 「嘉永5年9月22日」)。和暦原文をsource of truth とし、西暦は変換値という位置づけ。

3. 収集パイプライン(トークン戦略の核心)

3.1 実証済みの事実(2026-07-11 PoC)

系図の骨格データは LLM なしで機械的に取得できる。

Wikidata(Wikipedia の構造化データ基盤、CC0 ライセンス)に SPARQL で 問い合わせた結果:

• 天皇位(Q208233)保持者: 128人 登録済み(公式126代+α、内訳は照合)
• うち 父あり125 / 母あり119 / 生年あり122 / 没年あり120
• 代数・在位期間も qualifier として取得可能
• 例: 明治天皇 → 父: 孝明天皇、母: 中山慶子(側室)、1852-11-03〜1912-07-30

「各ページを LLM で読んで親を抽出する」案は数千万トークン規模になるが、 本設計では骨格はゼロトークンで済む。

3.2 3層ソースによるダブル/トリプルチェック

L0 と L1 は独立にパースして突き合わせる。一致 → citation に両出典を記録。 不一致 → conflict に記録し、L2 と LLM 照合で解決(解決不能なら並記)。

3.3 LLM の役割分担(モデル階層)

LLM は「照合の審判」「要約」「本文からの補助抽出」だけに限定する。 テキストはコードで取得して渡すので、ローカル LLM にブラウジング能力は不要。

補足: ローカルに埋め込みモデル bge-m3 も導入済み。将来の意味検索(§5)に転用可。

3.4 ETL 実装

• 言語: Python(ETL)+ TypeScript(フロントエンド)。 wikitext パースは mwparserfromhell、DB は標準 sqlite3 で足りる。
• スクリプト構成(Phase 1〜3):

  etl/01_wikidata.py       # SPARQL → 骨格(person, emperor, reign, parent_child)
  etl/02_wikipedia.py      # infobox パース → 独立データセット(oldid固定)
  etl/03_reconcile.py      # L0×L1 突き合わせ → citation / conflict
  etl/04_eras.py           # 元号テーブル(一覧記事+対照表データ)
  etl/05_enrich_llm.py     # Gemma/Haiku による要約・補助抽出(editorial層)
  

• すべて再実行可能(idempotent)にし、retrieved_at と oldid で再現性を持つ。

4. 暦の扱い

1. 和暦原文が source of truth。西暦は変換値として併記。
2. 1582-10-14 以前はユリウス暦、1582-10-15 以降はグレゴリオ暦 (歴史学・Wikipedia の慣行)。*_calendar カラムで常に明示。 日本の改暦(明治6年 = 1873-01-01)以降は和暦とグレゴリオ暦が一致。
3. 和暦→西暦変換は既存の対照表データ(『日本暦日原典』系の公開データ等、 Phase 1 で選定)を使う。LLM に暦変換をさせない(高頻度の誤りが出るため)。
4. 元号(era)テーブル:
   • 大化(645)以降の全元号。元号空白期(白雉〜大化の間等)も表現可能に
   • 南北朝の並立元号(court フラグ)
   • 改元理由(代始・祥瑞・災異・革年〔辛酉/甲子〕)を分類カラムで
   • 明治以降の一世一元制への移行を注記
   • 践祚(せんそ、即位すること)と改元のずれ(踰年改元〔ゆねんかいげん、 即位の翌年に改元する慣行〕)があるため reign と era は多対多

5. 検索と系図探索エンジン

5.1 全文検索

SQLite FTS5 + trigram トークナイザで日本語全文検索(名前・かな・事績)。 外部依存なしで「かんむ」「桓武」どちらでも引ける。将来は bge-m3 による 埋め込み検索を追加可能(質問文での検索)。

5.2 系図探索(再帰クエリ)

WITH RECURSIVE で以下を提供(サンプルは schema.sql 末尾に同梱):

• 男系判定: ある人物から父リンクだけを遡って天皇に到達するか
• 経路の性質判定: 任意の2人の間の親子経路を列挙し、各リンクが 父/母どちらかをラベル付け → 男系・女系(広義/狭義)を機械判定
• 継承距離: 各天皇と先帝との親等数(傍系継承の大きさの可視化)
• 共通祖先: 任意の2人の最近共通祖先
• 兄弟姉妹: 同父・同母・同父母を区別した派生ビュー

これらが「系図探索エンジン」の本体であり、フロントエンドはその表示層になる。

6. フロントエンド構想(Phase 4)

• データ量は高々数千人・数MB → 静的サイト + SQLite WASM(sql.js)で 完全サーバレスにできる。Vercel に静的デプロイ、運用費ほぼゼロ。
• 系図は「木」ではなく DAG(皇室は近親婚・再婚が多く木構造では描けない)。 世代レイヤー式の DAG レイアウト(D3 カスタム or ELK)。
• エッジの色分け: 父リンク/母リンクを別色にする。これだけで 「男系・女系」が視覚的に自明になる — 本サイトの核となる表現。
• 正室・側室は母ノードのスタイル(rank_class)で区別表示。
• 各事実にホバー/タップで出典ポップアップ。

7. ロードマップ

Phase 2 の拡張範囲メモ: 世襲親王家(伏見宮・閑院宮など)の系統は、 光格天皇の傍系即位や現代の議論との関連で優先度が高い。

8. ライセンスと出典ポリシー

8.1 なぜ層ごとに分けるか

著作権が保護するのは「創作的な表現」であり、事実そのもの(誰の父か、生年月日、在位期間)は著作物ではない。Wikipedia記事から事実を抽出しても CC BY-SA は継承されない。継承が必要なのは、Wikipedia の文章を要約・改変して作った解説文(editorial層)のみ。この区別を利用し、facts層は最も 再利用しやすい CC0 で公開し、editorial層のみ CC BY-SA を継承する。

8.2 層ごとのライセンス

8.3 出典表示のルール

• 出典は source / citation テーブルで行単位管理。Wikipedia は source.oldid(版ID)と retrieved_at で引用時点を固定し、再現性を持たせる。

• Wikipedia由来の解説文には、表示箇所の近く(フッター・出典ポップアップ)に 以下の3要素を明記する:

  この解説は Wikipedia「[記事名]」([版へのリンク: oldid付きURL]) を 改変して作成しています。ライセンス: CC BY-SA 4.0

  ①出典記事へのリンク(著作者表示を兼ねる) ②ライセンス名とリンク ③改変した旨の明示。2023年6月以降の Wikipedia 本文は 3.0 ではなく 4.0 なので、本サイトは 4.0 で統一する。

• 宮内庁等の公的資料は政府標準利用規約(CC BY 4.0相当)に基づき書誌情報+ リンクで引用。コトバンク・国史大辞典等の商用事典は事実の照合・検証のみ に用い、文章は転載しない(ダブルチェックの材料であり出典として文章を 引用する対象ではない)。

• Wikidata由来のfactsは CC0 のため出典表示義務はないが、検証可能性のため citation に記録は残す。

9. 想定される論点と本設計での扱い

いずれも「サイトとしての意見」は持たず、定義・出典・クエリで答える。

10. コラムの執筆パターン

docs/columns/ に一般向け読み物を追加する際、毎回ゼロから形式を 決め直さないための定型パターン。既存コラム(神功皇后・推古天皇・ 奈良時代の女帝たち・道鏡事件・天照大神の性別 等)から抽出した 共通形式であり、以後もこれに従う。

ファイル構成(定型)

# コラム:{惹句}――{主題}

**公開: YYYY-MM-DD**

**version 0.x(草案)/ YYYY-MM-DD**

出典は文末にまとめている。学術論文ではなく百科事典・出版社解説記事
(・個人ブログ)レベルの出典が中心であり、一次資料での裏取りは今後の
課題である。本コラムは評価を下さず、確認できた事実のみを述べる。
{既存コラムとの関係を一文で(例: ○○のコラムで触れた△△を、本コラムで
詳しく扱う/○○のコラムに続き…を扱う)}

---

## {セクション見出し1}
{本文。事実の記述。対立する論点は、実名・肩書き・発言日時(わかる
範囲で)を明示した引用で両論併記し、「本コラムはどちらが正しいか
判定しない」と明言して締める。}

## {セクション見出し2}
...

---

## まとめ
{箇条書き番号 (1)(2)(3)... で事実を整理。関連コラム・
docs/research/ への相互参照リンクを含める。}

---

## 出典

- {サイト名}「{記事タイトル}」
  {実在するURL}
- ...

出典は{学術論文ではなく…}が中心で、学術論文ではない。特に{未確認・
論争中の点}については、一次資料・学術文献による確認を今後さらに
進めていく。

執筆時の注意点

• 中立性: §0の3層分離と同じ思想を編集文でも徹底する。対立する 論点は「サイトの判断」を下さず、両論を出典付きで並記する (例: A氏はXと論じる/これに対しB氏はYと指摘する/本コラムは どちらが正しいか判定しない、という型)。個人の見解・立場を Aブログ/B氏の主張として明示し、サイトや執筆者自身の意見にしない。

• 出典URLは実在確認したものだけを載せる。WebSearchで見つけた だけでWebFetchで中身を確認していないものは、その旨を書くか採用を 見送る。

• 天皇名には公式代数を併記する(2026-07-13導入)。読者が代数を 暗記している前提を置かない。各コラム内でその天皇名が最初に 登場した箇所でのみ「光格天皇(第119代)」のように付記し、以降は 名前のみでよい。歴代外の人物(神功皇后など)は「(歴代外)」、 北朝の天皇は「(北朝第◯代)」と、/emperors一覧ページの表記に 揃える。欠史八代のように実在性に疑義がある代でも、公式代数自体は 皇統譜上の数字なのでそのまま付記する(実在性の議論は本文で別途 扱う)。 北朝5代(歴代からは除外、公式126代には含まれない)の対応表は 以下のとおり、混同しやすいので必ずこれに従う(db/emperors.db の reign.court='north' を在位開始日順に照会して確認済み、 2026-07-13):

  北朝代数	天皇名	在位開始
  北朝第1代	光厳天皇	1331年
  北朝第2代	光明天皇	1336年
  北朝第3代	崇光天皇	1348年
  北朝第4代	後光厳天皇	1352年
  北朝第5代	後円融天皇	1371年

  後小松天皇(第100代)は北朝5代の一覧には含まれない点に注意。 北朝自身の天皇として即位したのち、1392年に南朝の後亀山天皇から 譲位を受けて南北朝を統一し、以後は公式代数(main)に算入される ためである。血統としては北朝(父は後円融天皇=北朝第5代)だが、 代数の扱いとしては北朝5代とは別枠になる。詳細は 南北朝のコラムを参照。

• スラグはケバブケースのローマ字化が基本(例: jingu-kogo suiko-tenno kokka-shinto)。内容を要約した英語スラグも可 (例: nara-period-empresses)。

• **公開: YYYY-MM-DD** 行は初出日を固定するための行(2026-07-13 導入)。**version 0.x(草案)/ YYYY-MM-DD** 行(草案バージョン・ 最終更新日)とは別物で、以後の改訂で version 行の日付が進んでも 公開行は書き換えない。web/lib/columns.ts がこの行を本文から取り 除いたうえで publishedDate として一覧・記事ページに薄い文字で 表示する。

• 新規コラムを追加したら必ず3箇所を更新する:

  1. docs/columns/{slug}.md を作成する(**公開: YYYY-MM-DD** 行を 忘れずに)。
  2. web/lib/columns.ts の COLUMN_CATEGORIES に、該当コラムが 扱う主題の時代(年代アンカー)に対応するカテゴリを選んでスラグを 追加する(2026-07-13、時系列で分類する形に変更。カテゴリ一覧は 同ファイルを参照)。該当するカテゴリがなければ新設してよい。 カテゴリ内での挿入位置は、関連する既存コラムのそば(参照関係を 壊さない位置)を基本とするが、主題の時代が異なる場合は年代 アンカーを優先する(結果として一部の相互参照リンクが「まだ 読んでいない後方のコラム」を指す先読み参照になっても許容する)。
  3. 関連する既存コラムの本文に、新規コラムへの相互参照リンクを 追加する(逆方向のリンクが既にある場合はそこを更新する)。

• docs/columns/ 直下に置いたファイルは拡張子が .md であれば 自動的にサイトの一覧に「コラムの一つ」として表示される (web/lib/columns.ts の listColumns() / listColumnsByCategory() がディレクトリ内の全 .md を無条件に列挙するため。COLUMN_CATEGORIES に未登録のスラグは一覧ページで「その他」カテゴリの末尾にタイトルの 五十音順で表示される)。下書き未満のメモやテンプレートは このディレクトリに置かない。テンプレートは本セクション(本書 docs/DESIGN.md §10)に一本化する。