同じ日、同じ東京で、出生時刻だけを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を開発しています。公開経路研究では、算出した特徴と社会分類の関係を、失敗履歴と主張範囲を残しながら検査しています。
関連資料
- GenesisCore公開経路研究
- GenesisCoreの西洋・インド二体系分析
- WordPress正本:出生図は何を固定する図なのか
- Swiss Ephemeris programming documentation
- IANA Time Zone Database
再計算時に値がずれた場合は、Swiss Ephemerisのバージョン、使用フラグ、ephemeris file、UTC変換、ayanāṃśa、ハウス方式の順に確認すると切り分けやすくなります。

