精度をどう管理しているか: swetest と NASA に対する CI

精度は、ユーザーが Astrodienst で黙って照合してくるポイントです。出生図が角度 1 分ずれていれば、すぐに苦情が届きます。さらに厄介なのは、精度が気づかないうちに壊れやすいことです: 天体暦のコードをリファクタリングしただけで、エンドポイントの半分が秒角単位で静かにずれてしまいます。

それを防ぐために私たちがしていることを紹介します。

惑星の位置は Swiss Ephemeris で計算しています。重要なのは、私たちのアプリと API が同じ計算コア、同じコードベースを共有していることです。食い違いうる 2 つの実装が存在しないので、食い違うものがありません。

天体暦の主な範囲外の日付については、解析的なフォールバック (Moshier) を用意しています。やや粗いものの、範囲の境界で不連続になりません。意図的に正直に言っておくと、エンジンの具体的なバージョンは公表していません。実際に使っているコアのバージョンは最新の upstream より古く、派手な数字を書けば嘘になるからです。

計算系のエンドポイントにはそれぞれ固定スナップショットのセットがあり、このビルド時点で 873 個の JSON フィクスチャがあります。ランナーは基準チャートでエンドポイントを実行し、結果をフィクスチャとバイト単位で (許容誤差の範囲内で) 照合します。惑星の黄経が 5e-5° (0.18″) を超えてずれると、テストは失敗します。

基準チャートは、“扱いやすい” 中心部だけでなく端のケースを突くように選んでいます:

• Monroe、Diana、Einstein、Bowie: 出生データが知られている歴史的なチャート
• 極地の緯度: ハウスシステムが退化する場所
• 赤道: ハウスシステムが別の振る舞いをする場所
• 南半球: 鏡像になるかの確認

こうした境界ケースこそが、ごく普通の都市で生まれた人のチャートでは見えない回帰を捕まえます。

スナップショットが捕まえるのは、自分自身に対する回帰です。絶対的な正しさを確かめるため、リリースごとに独立したソースと照合しています:

Prokerala との差異は誤りではありません: Lahiri の計算式の実装が異なるためで、私たちはそれを隠さず明記しています。業界の基準である swetest とのずれはゼロです。

アストロカートグラフィーのラインは別途幾何学的に検証しており、赤道での精度は 1.5 km 以内です。

精度は一度きりの確認ではなく、CI のゲートです:

• api-accuracy.yml: バックエンドのコードへの PR ごとに、スナップショット全体と三角測量を実行します。テストが赤なら merge はブロックされます。
• check-eclipse-accuracy.yml: 年に 1 回、日食・月食を NASA のカタログと照合します。しきい値を超える差異があれば自動で issue が作成されます。
• check-sweph-updates.yml: 毎週 upstream の Swiss Ephemeris を監視します。新しいバージョンが出るとレビュー用の issue が作成され、自動マージはしません (天体暦エンジンの更新は、自動アップデートに任せるには繊細すぎるためです)。

保証はシンプルです: 惑星の位置は基準となる Swiss Ephemeris から 0.1 秒角未満に収まり、この範囲は README の約束ではなく自動化によって守られています。もし回帰が起きても、それはユーザーからの苦情ではなく私たちの CI で検出されます。

具体的なチャートごとの差異の表を含む、これらの数値の公開版は 精度 のページにあります。