同じ日、同じ東京で、出生時刻だけを12:00から12:10へ動かしました。

GenesisCoreの計算条件に合わせて再計算すると、サイデリアル黄道上の太陽は約0.007度、月は約0.084度、ラグナは約3.734度進みました。元のラグナが360度の境界近くにあったため、表示上のラーシはMīna（魚座）からMeṣa（牡羊座）へ切り替わります。

この記事では占星術的な意味の読解には入りません。出生記録が天体位置へ変換される工程と、入力時刻に対する出力感度をPythonで確認します。

検証すること

現地時刻をIANAタイムゾーンでUTCへ変換する
UTCをユリウス日へ変換する
Swiss Ephemerisで太陽・月・アセンダントを計算する
Lahiri ayanāṃśaを適用してサイデリアル黄経へ変換する
出生時刻を動かし、各値の変化量を比較する

個人情報は使いません。入力は合成日時と東京の公開座標です。

環境

Python 3.10
pyswisseph 2.10.3
timezone: Asia/Tokyo
latitude: 35.6762
longitude: 139.6503
date: 2000-01-01

インストールは次の一行です。

python -m pip install pyswisseph

最小コード

from datetime import datetime, timezone
from zoneinfo import ZoneInfo

import swisseph as swe

LAT = 35.6762
LON = 139.6503
TZ = ZoneInfo("Asia/Tokyo")

swe.set_sid_mode(swe.SIDM_LAHIRI)


def norm360(value: float) -> float:
    return value % 360.0


def sample(hour: int, minute: int) -> dict:
    local_dt = datetime(2000, 1, 1, hour, minute, tzinfo=TZ)
    utc_dt = local_dt.astimezone(timezone.utc)
    utc_hour = utc_dt.hour + utc_dt.minute / 60 + utc_dt.second / 3600

    jd = swe.julday(
        utc_dt.year,
        utc_dt.month,
        utc_dt.day,
        utc_hour,
        swe.GREG_CAL,
    )

    sun_tropical = swe.calc_ut(jd, swe.SUN, swe.FLG_SPEED)[0][0]
    moon_tropical = swe.calc_ut(jd, swe.MOON, swe.FLG_SPEED)[0][0]
    ayanamsa = swe.get_ayanamsa(jd)

    # W = Whole Sign。ascmc[0] は tropical Ascendant。
    _cusps, ascmc = swe.houses_ex(jd, LAT, LON, b"W", swe.FLG_SWIEPH)

    return {
        "local_time": local_dt.strftime("%H:%M"),
        "julian_day": jd,
        "sun_sidereal": norm360(sun_tropical - ayanamsa),
        "moon_sidereal": norm360(moon_tropical - ayanamsa),
        "lagna_sidereal": norm360(ascmc[0] - ayanamsa),
    }


for time in [(12, 0), (12, 10), (13, 0), (14, 0)]:
    print(sample(*time))

結果

主要値を小数第3位へ丸めると次のようになります。

現地時刻	ユリウス日	太陽	月	ラグナ
12:00	2451544.625000	256.130°	194.948°	359.060°
12:10	2451544.631944	256.137°	195.032°	2.794°
13:00	2451544.666667	256.172°	195.451°	20.340°
14:00	2451544.708333	256.215°	195.954°	38.752°

120分で太陽は約0.085度、月は約1.006度、ラグナは円周上で約39.692度進みました。

12:00から12:10のラグナは、359.060度から2.794度へ数値が戻ったように見えます。実際には360度を経由して前へ約3.734度進んでいます。30度ごとのラーシ名へ変換すると、MīnaからMeṣaへの切り替わりになります。

この例から「出生時刻が10分違えば常に星座が変わる」とは言えません。今回の初期値が境界近くにあったために起きた変化です。

実装で保持したい四つの情報

1. オフセットだけでなくタイムゾーン名を保存する

UTC+9だけでは、歴史上の制度変更や夏時間を復元できない地域があります。入力にはAsia/TokyoのようなIANAタイムゾーン名を残します。

2. 分類名と元の連続量を両方保存する

Meṣaという名称だけを保存すると、境界から0.1度の位置と15度の位置を区別できません。黄経、区分番号、区分内度数、境界までの距離を分けて持つと、後の感度分析に使えます。

3. 計算方式を結果データへ添える

最低でも次をバージョン付きで記録します。

{
  "ephemeris": "Swiss Ephemeris",
  "zodiac": "sidereal",
  "ayanamsa": "Lahiri",
  "house_system": "Whole Sign",
  "node_type": "mean",
  "timezone": "Asia/Tokyo"
}

同じ出生情報から別の図が出た場合、バグなのか設定差なのかを追跡しやすくなります。

4. 不明時刻を一点へ仮固定しない

時刻が不明なら、候補時間帯を複数計算します。結果を「範囲内で不変」「境界を跨ぐ」「時刻不足で確定不能」に分ければ、不確実性をUIへ出せます。

ここから研究へどうつながるか

天体位置を再計算できることと、占星術的な意味が現実へ対応することは別の検査です。ただし入力、設定、中間値、特徴量を固定できれば、現実との対応は具体的な仮説として検査できます。

たとえばサイン所属だけを使う研究と、度数や境界距離まで使う研究では、別の仮説を検査しています。出生時刻不明者を含める基準も結果へ影響します。計算パイプラインを公開する価値は、何を比較したのかを第三者が切り分けられる点にあります。

AETHERCOREでは、西洋占星術とインド占星術を別々の計算経路として保持するGenesisCoreを開発しています。公開経路研究では、算出した特徴と社会分類の関係を、失敗履歴と主張範囲を残しながら検査しています。

関連資料

再計算時に値がずれた場合は、Swiss Ephemerisのバージョン、使用フラグ、ephemeris file、UTC変換、ayanāṃśa、ハウス方式の順に確認すると切り分けやすくなります。