当社のホロスコープエンジンをご紹介¶
当社のホロスコープエンジンは、実用的な製品向けに設計された決定論的な占星術実行環境です。これは、単なるテキスト生成ではなく、Swiss Ephemerisの計算、厳格な要因の活性化、および編集によるレンダリングを組み合わせることで、安定した、説明可能な、高品質なレポート出力を提供します。
構築されているもの¶
実行時に、エンジンは実際の天体の状態を計算し、活性化された占星術的な要因から意味を抽出します。 同じペイロードの場合、出力はバイト単位で完全に一致します。 パーソナライゼーション入力が提供される場合、ハウスレベルおよび出生コンテキストベクトルが活性化され、ユーザー固有の違いが生じます。
これにより、チームに以下のメリットが得られます:- 予測可能な出力: テスト、品質保証、およびキャッシュ用 - 同じリクエストは常に同じJSONを返します。 - 詳細なレポート構成: 各セクションにおけるfactor_details を使用した追跡。 - 軽量なサインレポートからプレミアムなパーソナライズされたレポートへのスムーズな移行。 - 期間に基づいた深さ: 毎日(5〜6つの要素)、毎週(10)、毎月(11)、および毎年(13)の要素スタックで、明示的な重みが設定されています。
全体的なアーキテクチャ¶
フルなホロスコープエンジンアーキテクチャ¶

リクエストからレスポンスへのアーキテクチャ¶

決定的なパイプライン1. ゲートウェイ は認証、クォータ、およびリクエストポリシーを検証します。¶
- リクエスト契約の検証 は、受け入れられるスキーマとオプションを強制します。
- エンジン は、サインソース、期間ウィンドウ、およびエフェメリスの構成を解決します。
- Swiss Ephemeris は、位置、アスペクト、およびハウス(該当する場合)を計算します。
- 集約レイヤー は、期間をサンプリングし、イベント(アスペクト、イングレッション、ステーション、ルナレーション、食い違い)を抽出し、ドライバーをランク付けします。
- 解釈エンジン は、固定された順序、明示的な重み、および安定したハッシュ変数の選択を使用して、ファクターの仕様を編集コンテンツにマッピングします。
- 編集エンジン は、期間固有のアーク構成(開始 → 移行 → 結果)を使用して、V2 コンテンツパックからセクションの物語をレンダリングします。
- ゲートウェイ は、統合メタデータ用のエンジンペイロードとエンタープライズラップ(
_enterprise、_api_metadata_)を返します。
決定論の保証¶
決定論は偶然ではありません—それはすべてのレイヤーで強制されます:| 保証 | 適用メカニズム | |---|---| | 同じペイロード → 同じ要因 | 期間ごとの明示的な要因の順序 + 固定された重み | | 同じ要因 → 同じコンテンツバリエーション | SHA-256 で安定したハッシュインデックス選択 | | 同じバリエーション → 同じ表現 | V2 コンテンツパックからの決定論的なフレーズサイクル | | 同じ表現 → 完全に一致する JSON | 編集による書き換えの一貫性 + 隣接セクションのブリーズラインの重複排除 |
これにより、同じボディを持つ2つの独立したリクエストをハッシュ化し、同じ結果を得ることができます。これは、信頼できるキャッシュ、QA(品質保証)回帰テスト、および再現可能なデバッグを可能にします。
公開モードとパーソナライズされたレポート¶
どちらも本番環境で利用可能です。 違いは品質ではなく、アクティベーションの深さです。
公開モード(サインベース)¶
誕生日の星座と日付のみを指定します。 エンジンは、その期間に同じ星座を持つすべてのユーザーに対して、安定した共有されたリーディングを生成します。
- 幅広いオーディエンス向けのフィードやコスト効率の高いキャッシュに適しています (12の星座 × 4つの期間 × 365日 = 約17,520個のユニークな日次キャッシュ)
- ハウス計算は不要 —
rising_sign、house_cusps、および身体houseの割り当てはnull - 急速な展開、雑誌スタイルの占星術、フリーミアムの階層に適しています### パーソナライズモード(生年月日に基づいた)
詳細なベクトルを有効にするために、生年月日に関する情報(birth_time、座標、タイムゾーン)をご提供ください。 同じ星座の人でも、ハウスの位置と上昇サインによって係数の評価が変わるため、異なる編集内容を受け取ることができます。
- 必須項目:
birth_time(HH:MM) +birth_latitude+birth_longitude - 有効化: 上昇サイン、12のハウスの角、惑星とハウスとの関連付け、およびハウスに焦点を当てた係数(
daily_house_focus、weekly_house_focus、monthly_house_focus、yearly_house_focus) - プレミアムサブスクリプションや高い維持率を実現するためのもの
- より豊かなアプリモジュールとパーソナライゼーションパイプラインをサポート
係数に基づいた編集モデル¶
エンジンは、天体の瞬間と期間の集計から計算される決定論的な解釈ドライバーである係数のスタックによって駆動されます。 各期間には、定義された係数の順序と明示的な重みが設定されています。
期間ごとの係数のスタック| 期間 | ファクター数 | 主要な要因 |¶
|---|---|---| | 1日ごと | 5-6 | sun_in_sign, moon_in_sign, transits_archetypes, aspects, daily_house_focus | | 1週間ごと | 10 | weekly_moon_phase, planetary_focus, retrograde_archetypes, weekly_theme_archetypes, weekly_house_focus | | 1ヶ月ごと | 11 | monthly_lunation_archetypes, eclipse_archetypes, outer_planet_focus, monthly_theme_archetypes, monthly_house_focus | | 1年ごと | 13 | jupiter_in_sign, saturn_in_sign, nodal_axis, yearly_house_focus, yearly_theme_archetypes |
追加レポートファミリー層の専用ファクタースタック: - 惑星: planet_core_archetypes, planet_condition_archetypes, planet_house_focus, planet_sign_archetypes - 誕生日: solar_return_tone, birthday_year_reset, natal_sun_house_year_theme - アスペクト: 計算された、または上書きされた主要なアスペクトを持つアスペクト主導のスタック - トランジット: 計算された、または上書きされた主要なトランジットアーキタイプを持つトランジット主導のスタック
各ファクターには、明示的な重みが割り当てられています(例:moon_in_sign: 1.15 (1日ごと)、yearly_theme_archetypes: 1.30 (1年ごと))。これにより、セクションのスコアリングと強度算出に影響を与えます。
このモデルは、ランダムな文章の流れを回避し、計算されたドライバーに関連する編集トーンを維持し、完全な追跡可能性を備えたfactor_detailsで表現します。
1日ごとのパーソナライズされたアプリ統計 (メインホロスコープ)¶
1日ごとのパーソナライズモードでは、エンジンはdata.daily_personalized_statsで、アプリに適した豊富な統計ブロックを返します。 これらの統計は、ダッシュボードカードやサマリーウィジェットに最適です。
アクティブ化トリガー: period=daily および パーソナライズされた出生リクエストには、birth_time と coordinates の両方が含まれている必要があります。
主要な要素:
overall_pulse— 複合的な日次活力スコアarchetype_scores— 八次元分解 (wisdom,creativity,confidence,intuition,allure,romance,career,emotions)harmony_discord— 最も調和のとれたサインと最も不調和なサインのドライバーの上位4つelemental_balance— 火/土/空気/水の分布momentum_channels— 惑星の推進力信号
ペイロード密度制御:
daily_stats_detail: "full"を使用して、信頼度レベルごとに完全なチャートデータを取得daily_stats_detail: "compact"を使用して、軽量なクライアント用ペイロード (モバイルウィジェットに最適) を取得
リクエスト設計のハイライト¶
このエンジンは、天文学的な設定とレンダリング動作のための明確で型付きの制御をサポートしています。 一般的なオプションには以下が含まれます:| フィールド | タイプ | 用途 | |---|---|---| | period | 文字列 | daily, weekly, monthly, yearly | | sections | 配列 | 含めるライフエリア (例: general, career, love_singles) | | sign / birth | 文字列 / オブジェクト | サインソース (公開 vs パーソナライズ) | | target_date | 文字列 | 明示的な日付アンカー (YYYY-MM-DD) による再現性 | | zodiac_system | 文字列 | tropical または sidereal | | ayanamsa | 文字列 | 地球連星オフセットシステム (lahiri, fagan_bradley など) | | house_system | 文字列 | placidus, whole_sign, equal, koch | | node_type | 文字列 | 実際のtrue または 平均の月のノードmean | | tenant_id | 文字列 | マルチテナントまたは A/B シナリオにおけるキャッシュネームスペース分離 |
Gateウェイでのレスポンス形状に関する保証¶
Gateウェイレポートのレスポンスは、エンジンデータとラップを追加して通過します:
_enterprise— プランレベル、クォータ、およびレート制限メタデータ_api_metadata_— エンドポイント情報、サポートされている言語、およびリクエストコンテキスト
エンジンによるレポートエンドポイントの場合、_api_metadata_.supported_languages は英語のみです:
言語と翻訳ポリシー現在のライブエンジンによるレポートエンドポイントは、lang=en のみサポートしています。¶
これは、本番環境での決定論的な編集のニュアンスを維持しつつ、翻訳の信頼性を別々に管理することを意図したものです。
ゲートウェイの翻訳ヘルパーレイヤー(lang=en|es|de|fr|pt)は、すべての非占星術レポートエンドポイントに対して、API境界で翻訳された出力を提供します。
コンテンツパイプライン: V2 コンテンツパック¶
編集コンテンツは、エンジンのコンテンツリポジトリにある構造化された V2 コンテンツパック から取得されます。
実行時に、コンテンツリポジトリは安定したハッシュ選択による4レベルのフォールバックチェーンを使用して、決定論的にバリエーションを選択します:
- 完全一致(factor_type + factor_value + intensity)
- factor_type の任意の値(factor_type + intensity)
- セクション内の任意の要素(section + intensity)
- セクションフォールバックテンプレート
この構造は、intensityに応じて編集の多様性を確保しながら、同じシードに対して再現性を維持します。
信頼モデル: クローズドコア + オープンソースライト¶
当社の主要な本番環境エンジンは、エンタープライズの信頼性、深さ、および管理された運用に最適化されたクローズドソースです。 これには以下が含まれます:- 全期間に対応した、ハウス情報を考慮したパーソナライズされたレポート - 太陽戻りなどの要素を含む、誕生日サイクルレポート - 行星、アスペクト、トランジット、ハウス、および行星とハウスに関するレポートスイート - 設定可能なSVGによるナタルの出生チャート - Redisキャッシュ、メトリクス、ヘルスチェック、および水平方向のスケーリング
インディーズのアストロロジー専門家や開発者の評価を支援するため、オープンソースの軽量エンジンも提供しています。
OpAstroを使用して、エンジンの品質を評価し、因子の計算ロジックを調査し、Swiss Ephemerisとの統合を確認してください。 より豊富なレポートレイヤー、広範なエンドポイントのカバー、および管理されたプロデュークションオペレーションのために、NumerologyAPIのエコシステムルートにスケーリングしてください。
統合パス1. 公開レベルのレポートから開始 — 日次/週次/月次/年次で、signのみを使用。出生データは不要。効率的なキャッシュを利用。¶
- パーソナライズされた出生情報を追加 —
birth_timeと座標を供給することで、ハウスに合わせた要素を含む差別化されたレポートを作成。 - 専門的なレポートファミリーを追加 — 行星、アスペクト、トランジット、およびハウスエンドポイントで、より詳細な機能を提供。
- 誕生チャートのエンドポイントを追加 — フルな出生チャートのJSON + SVGホイールによる可視化と高度な占星術ワークフロー。
- セクションで最適化 — UIが必要な
sectionsのみをリクエストすることで、ペイロードサイズを削減 (例:["general", "career"])。 tenant_idを使用してキャッシュを分離 — 無料/プレミアム層またはA/Bテストのバリエーションを、キャッシュ汚染なしで分離。
キャッシング戦略¶
| モード | キャッシュ効率 | 戦略 |
|---|---|---|
| 公開 (サインのみ) | 高い — 約17,520件のユニークな日次キャッシュ | 次の日への事前ウォーミング; TTL 1-4時間 |
| パーソナライズ (出生情報に基づいた) | 低い — ユーザーごとに異なる | ユーザーごとのキャッシュキー; TTL 24時間; Redis推奨 |