# 暦・九星計算の調査と採用仕様

調査日: 2026-09-21 / 実装: `src/lib/calendar.ts` / 検証: `tests/calendar.test.ts`

## 結論と扱える範囲

本命星・月命星・日命星を、生まれた日時の年盤・月盤・日盤の中宮星として扱い、年→月→日の順に3桁コードを作る。年・月の切替は太陽の節入り時刻で決める。日盤は**夏至・冬至に最近の甲子を基準とし、240日区間を甲午で調整する方式**を採用する。ただし日盤は流派の統一仕様ではないため、全結果を試算として返す。

対応はグレゴリオ暦の **1920-01-01〜2099-12-31**、日本標準時 **UTC+9固定**。期間外・存在しない日付・不正時刻はエラーとし、もっともらしい数字を補完しない。この範囲は製品上の入力制限であり、全期間の正確性を独立した万年暦で保証した範囲ではない。

「暦の再現性」と「人物の特性・相性・開運効果の実証」は別である。国立天文台は天文現象の時刻を裏付ける資料であって、占術の効力を認証する資料ではない。この調査は暦の計算規則を再現するためのもの。

## 年・月の計算

年は立春の瞬間から次の立春直前まで。年盤中宮は毎年1つ逆行する。実装の九星年を `Y` とすると `9 - ((Y + 7) mod 9)` と同値の式を使う。年の十二支は `((Y - 4) mod 12)`、0が子。計算規則の出典は著者自身の実装解説である[開運道・年の十干十二支九星](https://kaiun-do.me/2015/07/08/%E5%B9%B4%E3%81%AE%E5%8D%81%E5%B9%B2%E5%8D%81%E4%BA%8C%E6%94%AF%E4%B9%9D%E6%98%9F/)。

月は小寒・立春・啓蟄・清明・立夏・芒種・小暑・立秋・白露・寒露・立冬・大雪で切り替える。年星を `S`、節月を2〜13（1月は前年の13月）で表すと `3S + 7 - 節月` を1〜9に循環させる。年の切替と月の切替を別々に単なる西暦で判断すると1月・立春前に誤るので、同じ節年に結び付けた。[開運道・月の十干十二支九星](https://kaiun-do.me/2015/07/08/%E6%9C%88%E3%81%AE%E5%8D%81%E5%B9%B2%E5%8D%81%E4%BA%8C%E6%94%AF%E4%B9%9D%E6%98%9F/)

## 天文ライブラリと時間基準

二十四節気の計算にはMITライセンスの [6tail/lunar-typescript](https://github.com/6tail/lunar-typescript) 1.8.6を利用する。インストール時の解決版は `package-lock.json` に記録される。`LunarYear.getJieQiJulianDays()` の節気値は北京標準時であるため、**日本の暦日へ1時間を加えてから**境界日時を作る。[LunarYear.tsの実装](https://github.com/6tail/lunar-typescript/blob/master/src/lib/LunarYear.ts) を確認した。中国暦ライブラリの `getDayNineStar()` は、日本の日盤方式との同一性を仮定せず利用していない。

時刻の入出力ではホスト端末のタイムゾーンを参照せず、`+09:00` を明記する。1948〜1951年の日本の夏時間は自動変換しない。海外出生、真太陽時、出生地別の標準時、歴史的時差も未対応。入力欄に入れるのは採用した日本標準時の日時である。

国立天文台の定義では二十四節気は太陽の視黄経が指定角度になる瞬間。[暦要項の説明](https://eco.mtk.nao.ac.jp/koyomi/yoko/) に従い、2025〜2027年の12節×3年を照合した。

| 照合対象 | 例 | 検証結果 |
| --- | --- | --- |
| [国立天文台2025年](https://eco.mtk.nao.ac.jp/koyomi/yoko/2025/rekiyou252.html) | 立春 2/3 23:10 JST | 12節すべて60秒以内 |
| [国立天文台2026年](https://eco.mtk.nao.ac.jp/koyomi/yoko/2026/rekiyou262.html) | 立春 2/4 05:02、白露 9/7 23:41 JST | 12節すべて60秒以内 |
| [国立天文台2027年](https://eco.mtk.nao.ac.jp/koyomi/yoko/2027/rekiyou272.html) | 立春 2/4 10:46 JST | 12節すべて60秒以内 |

36件の公表分値との差の最大は31秒。これは丸め差と暦算法差を含み、秒精度の天文検証ではない。出生時刻が計算境界の前後2分なら両候補を返す。±2分はアプリが設けた保留幅であり、全年代の天文誤差の上限を保証しない。

## 日盤の陰陽遁・置閏

採用ルールIDは `jp-jst-setsu-nearest-koshi-intercalary-v1`。

1. 各年の夏至・冬至をJSTの暦日へ直す。
2. 二至の暦日に最近の甲子を選ぶ。甲子からの干支番号が0〜29なら直前、30〜59なら直後。等距離は後を選ぶ。
3. 通常の180日区間では、冬側は一白から順行する陽遁、夏側は九紫から逆行する陰遁。
4. 甲子間が240日なら、次の甲子の30日前（前の甲子から210日後）の甲午で切り替える。夏側は三碧から陰遁、冬側は七赤から陽遁。切替前日と当日で同じ星が繰り返される。
5. 日界はJST 00:00。23:00で切り替える方式は採用しない。

最近甲子と置閏を使うことはサービス作者による [QuickChartの仕様](https://kyusei.info/quickchart/) に明記されている。240日区間の具体的処理は、作者自身が公表する [Curanz Soundsの計算規則](https://curanzsounds.com/kyusei/rules) を採用した。両者は採用実装の一次資料であり、すべての九星気学流派を拘束する標準ではない。同サイトの検証件数を本アプリの検証実績として流用していない。

別方式として、[開運道の解説](https://kaiun-do.me/2015/07/08/hibankirikae1/) は天象学会『萬年暦』に沿う固定8400日周期を記載し、[別記事](https://kaiun-do.me/2015/07/09/hibankirikae2/) は長期的なずれ・歴史的な不規則補正を指摘する。書籍現物・版・その例外表は未入手で、同書との完全一致を名乗ることはできない。最近甲子方式と固定周期方式を同じルールとして混ぜない。

## 独立した九星暦との照合

[高文出版・九星循環表2026〜2043](https://koubun-shuppan.co.jp/junkan26_43.pdf) の18ページを抽出し、6,574日の日星・日支を本実装に照合した。2026年と不一致がある2042年のページを画像でも確認し、表の列順を確認した。元PDF全体の転載はしていない。

結果は**6,340日一致・234日で日星不一致、日支は全6,574日一致**。2026〜2041年の5,844日はすべて一致した。不一致は2042-11-22〜2043-07-19の間に分布する。期間内には偶然同じ日星となる日もある。この差は置閏時期の選び方によるもので、相手の暦が誤りと断定しない。

具体例では、同PDFの2042年12月1日は一白、本実装は九紫。PDFは11月22日に一白を反復する一方、採用方式では12月22日に七赤を反復する。したがって、単に「九星の正確な日盤」と表示せず、**ルール名と試算状態を数字に結び付ける必要がある**。

自動テストに残した代表値は次の通り。

| 日時（JST） | 期待値・確認点 | 出典 |
| --- | --- | --- |
| 2026-02-04 04:50 / 05:10 | 年月 2・9 → 1・8 | 国立天文台の立春時刻＋年月計算規則 |
| 2026-09-07 23:30 / 23:50 | 月盤 2 → 1 | 国立天文台の白露時刻＋月計算規則 |
| 2026-06-18 / 06-19 | 日盤 9 → 9、陽遁→陰遁 | 高文出版2026年表 |
| 2026-12-15 / 12-16 | 日盤 1 → 1、陰遁→陽遁 | 高文出版2026年表 |
| 2026-09-21 | 年1・月1・日5、日支は戌 | 高文出版2026年表、[開運道日一覧](https://kaiun-do.me/tools/tools-calndays/) |
| 2020-06-19 / 06-20 | 三碧反復の置閏 | 採用ルールの公開説明 |
| 2031-12-19 / 12-20 | 七赤反復の置閏 | [Magic Wandsの独立日めくり](https://www.magicwands.jp/calculator/calendar/detail/?date=2031-12-20)、高文出版2031年表 |
| 2042-12-22 | 最近甲子方式では七赤陽遁 | 採用ルールの公開説明。高文出版とは異なる方式 |

対応期間の全65,745日について進行・転遁時の反復を検査するテストもある。これは計算の内部整合性の検査であり、外部の正解データ65,745件との照合ではない。テスト実行は `npm test`。

## APIと曖昧さの扱い

`calculateProfile(date, time?)` と `calculatePeriod(date, time?)` は同じ暦結果の形を返す。`year/month/day/code` に加え、`branches`、`solarYear/solarMonth`、`ruleId/ruleLabel`、出典、注記、転遁種別と開始日、現在・次の節入りを含む。

時刻不明は正午を仮定した表示値を返すが、節入り当日は `certainty: 'boundary'` として前後双方を `candidates` に残す。たとえば2026年2月4日は `291` と `181`。出生時刻を入力済みでも境界前後2分は両候補を保持する。それ以外でも `certainty: 'provisional'` とし、全流派共通の確定値を意味させない。

`calculateDayStar`、`getSolarTerms`、`todayInJapan`、`SUPPORTED_RANGE` も公開する。無効値の丸め、旧暦入力と西暦入力の自動混同、海外端末の日付による無言のタイムゾーン変更はしない。

## 製品版へ進める前の残件

- ユーザーが基準にしたい先生・流派・万年暦の版を確認し、日盤方式と「日命星」の扱いを合意する。
- 1920〜2025年の出生計算を、使用許諾が明確な独立万年暦へ広げて照合する。現在は全日照合済みではない。
- 1900年代初期の例外や別の置閏を扱う場合は、ルールを別IDにして例外表とともに版管理する。
- 海外出生、歴史的時差、真太陽時、23時日界を追加する場合、入力の意味と方位の出発日時を先に定義する。
- 国立天文台のより広い年代で節気・二至を照合し、深夜近くの二至で暦日が変わるケースを重点検証する。
- 出典URL、取得日、採用規則、境界注記を保存結果にも持たせ、ルール更新時に過去の数字を無断で上書きしない。