7
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

まえがき 古代レガシーシステムの構造解析

本稿は、読者が「占い」という言葉に対し、ある種の居心地の悪さや、あるいは知的な警戒心を抱いていることを前提に執筆されている。 特に、日々論理的な整合性や再現性を追求するエンジニアや理数系の思考を持つ諸氏、現代の天文学に親しむ諸氏にとって、占星術の周囲に漂う情緒的な曖昧さは、立ち入りを拒む高い障壁となりえる。

大前提として、占星術は近代科学(サイエンス)ではない。近代科学の要件を満たそうとするものではない以上、厳密な意味での『疑似科学(Pseudoscience)』という定義にも当てはまらない。 その実態は、17世紀の科学革命以前に構築された、現代とは異なる論理構造を持つ古代のレガシーシステムである。

「なぜ星の配置が運命に関係するのか」という問いに対し、「神秘」や「シンクロニシティ」といった回答は、構造的な理解を求める者にとっては何の説明にもならないばかりか、欺瞞と錯誤の温床ですらある。そこに提示されているのは、ブラックボックス化された入力と出力だけであり、その間をつなぐ処理ロジック(アルゴリズム)が完全に隠蔽されているからだ。

本稿の目的は、読者を占星術の信奉者へと導くことではない。 その狙いは、少なくとも二千年にわたり継承された体系を、現代のエンジニアリング言語を用いて「可読化」し、構造理解を促すことにある。いわば、古代レガシーシステムの「技術仕様」の開示である。

ここでは、惑星は神話の神々ではなく、固有の周波数を持つ「機能モジュール」として定義される。12の星座(サイン)は物語の舞台ではなく、熱力学的なパラメータによって定義された「環境座標」として扱われる。そして、それらの相互作用は「吉凶」ではなく、「幾何学的な共鳴」や「信号干渉」といった物理モデルとして記述される。

なお、本稿で解説するロジックは、19世紀以降に再構築・再発明された現代西洋占星術(Modern Astrology)とは異なり、ヘレニズム期から中世アラビア期にかけて体系化された「古典的(Traditional)」な技法に基づいている。 このブラックボックスの蓋を開けた先に、神秘主義的な混沌は存在しない。あるのは、古代のシステム設計者たちが世界を記述するために組み上げた、整然たるコードの集積である。


目次

  • 序論:ブラックボックスを開く
    • 0.1 本稿の目的とスコープ:仕様(Specification)の開示
    • 0.2 システムの全体像:IPOモデルとブラックボックスの中身
  • 第1章:環境変数の定義(Global Coordinates)
    • 1.1 座標系の構築:黄道(The Ecliptic)
    • 1.2 物理モデルとしての「エレメント」
    • 1.3 12サイン:季節のエネルギー分布図
  • 第2章:独立変数の定義(The Planets)
    • 2.1 変数定義:7つの機能モジュール
    • 2.2 階層構造:カルデア配列(Chaldean Order)
    • 2.3 適合度スコア:エッセンシャル・ディグニティ
    • 2.4 古典占星術と現代占星術のシステム差異
  • 第3章:ローカル座標と観測視点(Local Coordinates)
    • 3.1 座標変換:プライマリー・モーション(初期条件の鋭敏性)
    • 3.2 幾何学的定義:アングル(Angles)
    • 3.3 空間分割:ハウスシステム(実行コンテキスト)
  • 第4章:幾何学的相互作用(Aspects & Geometry)
    • 4.1 視線(Ray)の理論:光学的通信モデル
    • 4.2 ピタゴラス的調和と多角形
    • 4.3 アスペクトのイベント処理ロジック
  • 第5章:動的な条件分岐(Dynamics)
    • 5.1 太陽位相と可視性(Solar Phase)
    • 5.2 高度な条件分岐(セクト、速度、例外処理)
    • 5.3 因果律と相関関係
  • 結論:記述言語としての出力
    • 6.1 多変量解析の統合
    • 6.2 構造解析ツールとしての未来
  • 第7章:アルゴリズムの実装(Implementation)
    • 7.1 理論から実装へ
    • 7.2 推奨ライブラリ選定(pyswisseph, Skyfield)
    • 7.3 Pythonによる実装チュートリアル
    • 7.4 JavaScript実装例
    • 7.5 検証環境とリファレンス実装(OSS/Web)
    • 7.6 技術用語集(Technical Glossary)
  • 第8章:開発後記(Postscript)

0.1 本稿の目的とスコープ

仕様(Specification)の開示

本稿は、一般に「占い」として認知されている西洋占星術を、天体観測データを入力値とする**「情報処理システム」**として再定義し、その内部ロジックを構造的に解説する技術仕様書である。本稿で扱うのは1世紀から17世紀まで運用されていた占星術である。一般的には古典占星術、伝統占星術、Traditional Astrologyと呼ばれる。

本稿の目的は、読者を神秘的な信奉へと導くことではない。また、人生の吉凶を予言する手法を伝授することでもない。本稿が提供するのは、数千年にわたり継承されてきた**「世界記述エンジンのソースコード」**の開示である。

このシステムにおいて、個人の人生や性格といった事象は、システム稼働開始時(出生時)に与えられた**「初期条件(Initial Conditions)」および「初期パラメータ(Initial Parameters)」**として定義される。

システムの全体像:IPOモデル

本システムは、現代的な情報処理システムと同様に、以下のIPO(Input-Process-Output)モデルによって動作する。

  1. Input(入力):

    • 観測日時(Timestamp)
    • 観測地点(Geolocation)
    • 天体暦(Ephemeris)から取得される惑星座標データ
  2. Process(処理):

    • 幾何学的判定: 変数(惑星)間の角度による接続状態(アスペクト)の計算。
    • スコアリング: 変数の配置に基づく適合度(ディグニティ)の数値化と重み付け。
    • 条件分岐: 昼夜の区分(セクト)や位相(フェーズ)による動的な機能制限。
  3. Output(出力):

    • 対象システムの機能的(Functional)または機能不全(Malfunctional)な領域の記述。
    • システム内部のエネルギー流動(幾何学的調和/共鳴)の解析レポート。

一般の占星術書において「星のメッセージ」や「未来予測」として表現される出力結果は、本システムにおいては、厳格なアルゴリズムによって導き出された「計算結果」である。

IPO_model.png

対象読者

本稿は、以下のような読者を主な対象として想定している。

  • エンジニア・プログラマ: ブラックボックス化されたシステムの内部構造理解を目的とする者。
  • 理数系思考者: 「当たる」「当たらない」という曖昧な説明を拒絶し、論理的整合性を求める者。
  • 構造主義者: 世界を構成する要素と、その関係性の網の目(構造)に関心を持つ者。

逆に、以下のような期待を持つ読者にとって、本稿は無味乾燥なテキストとなる可能性が極めて高い。

  • 癒やしや救済を求める者。
  • 論理よりも直感や情緒を優先する者。
  • 「運命」という言葉にロマンチシズムを見出す者。

スコープとアプローチ

本稿のスコープは、占星術というシステムの**「アルゴリズム(How)」**の解説に限定される。「なぜ天体の配置が地上の事象と相関するのか(Why)」という形而上学的な問いについては、コラム(Sidebars)において歴史的・哲学的な背景として触れるに留める。

我々が取り扱うのは、あくまで**「観測データがいかにして意味のある記述へと変換されるか」**というロジックの連鎖である。

読者は本稿を通じて、占星術が「詩的な直感」ではなく、「幾何学と分類学の厳格なルールセット」によって構築されている事実を目撃することになる。惑星は擬人化された神々ではなく、特定の周波数帯域を担当する**「機能モジュール」として描かれる。星座(サイン)は神話の舞台ではなく、温度と湿度によって定義される「物理的環境」**として扱われる。

この「ブラックボックス」を開いた先にあるのは、神秘主義的な混沌ではない。そこには、整然とした論理的な**「構造」**がある。


0.2 システムの全体像

3層構造のシステムアーキテクチャ

一般に「ホロスコープ」と呼ばれる円形のチャートは、性質の異なる3つのレイヤー(層)が同心円状に重なり合い、相互に干渉することで成立する**「多層的な情報処理フィールド」**である。

本システムの全体像を理解するために、まずはこの3つのレイヤーを個別に定義する。

レイヤー1:環境座標(Global Variables)

—— 黄道帯(The Zodiac)

最も外側に位置するレイヤーであり、システムの「空間的性質」を定義するグローバル変数群である。
全天360度の空間は、**「サイン(Sign)」**と呼ばれる12のセクターに分割されている。各サインは、温度(Hot/Cold)と湿度(Moist/Dry)という物理パラメータによって定義される固有の環境特性を持つ。
このレイヤーは、後述する変数が活動するための「フィールド(場)」を提供する。

レイヤー2:独立変数(Independent Variables)

—— 惑星(The Planets)

レイヤー1の上を移動する、7つの主要な**「機能モジュール」**である。
太陽、月、および5つの惑星は、それぞれがシステム内で特定の役割(クロック、メモリ、通信、演算など)を担当するエージェントとして定義される。
これらの変数は、レイヤー1(サイン)の環境特性から影響を受け、その出力強度や動作モード(機能的/機能不全)を変化させる。

レイヤー3:ローカル座標(Local Coordinates)

—— ハウス(The Houses)

観測地点(緯度・経度)と観測時刻(タイムスタンプ)によって生成される、最も内側のレイヤーである。
これはシステムの**「実行コンテキスト(Execution Context)」**に相当する。
全天を地平線と子午線を基準に12分割した「ハウス」は、変数の出力が「地上のどの領域(人生のどの分野)」に向けて実行されるかを決定する。


接続パスとしての幾何学(Geometry)

これら3つのレイヤー上に配置された変数同士は、孤立して存在するわけではない。それらは**「アスペクト(Aspect)」**と呼ばれる幾何学的な角度によって接続され、回路を形成する。

  • 0度(Conjunction): 融合とブレンド。
  • 60度(Sextile) / 120度(Trine): 正六角形および正三角形に基づく、抵抗のない信号伝達(調和)。
  • 90度(Square) / 180度(Opposition): 正四角形および対向に基づく、摩擦と衝突(不調和)。

視線(Ray)の理論に基づき、特定の角度で「見る/見られる」関係にある変数間でのみ、情報の交換や干渉が発生する。接続パスを持たない(アバーションの)関係にある変数は、互いに認識できず、連携動作を行うことができない。

多次元の極座標グラフ

以上の要素を統合すると、ホロスコープの正体が明らかになる。

それは、時間と空間のパラメータを入力とし、変数の配置と幾何学的関係性をプロットした**「多次元の極座標グラフ」**である。

  • 中心点: 観測地点(地球)。
  • 動径: 変数(惑星)までの距離(※古典占星術では投影上の見かけの位置を重視するため、距離は階層構造として扱われる)。
  • 偏角: 黄経(レイヤー1)およびハウスカスプ(レイヤー3)上の位置。

このグラフ上に描画されるのは、複雑な相互作用を持つ物理モデルの設計図である。次章以降では、この設計図を読み解くための各モジュールの詳細仕様を、レイヤーごとに順を追って解説していく。


第1章 環境変数の定義(Global Coordinates)

本章では、システムの土台となる「座標系(Zodiac)」と「物理定数(Elements)」を定義する。
これらは、変数が配置される空間そのものの性質を決定する、静的な環境変数群である。


1.1 座標系の構築:黄道(The Ecliptic)

黄道帯(Zodiac)の定義

本システムにおける「黄道帯(Zodiac)」とは、夜空に浮かぶ星座の絵画的な集合体と考えられている。実際は、地球から観測した太陽の見かけ上の軌道(黄道)を基準線とし、その周囲に展開される**「全天360度の空間グリッド」**として定義される。

このグリッドは、システムの「環境変数」を格納するためのアドレス空間として機能する。すべての天体(変数)の位置は、この黄道座標系上の経度(0度〜360度)によって一意に特定される。

回帰黄道帯(Tropical Zodiac)の採用

古典占星術のアルゴリズムにおいて、座標系の原点(0度)はどこに設定されるか。
本システムでは、恒星(Star)の位置ではなく、**「季節(Season)」の転換点を基準とする「回帰黄道帯(Tropical Zodiac)」**を採用する。

システムの起点:春分点(Vernal Equinox)

座標の起点(牡羊座0度)は、太陽が南半球から北半球へと天の赤道を通過する交点、すなわち**「春分点」**として定義される。
これは、昼と夜の長さが等しくなり(Equinox)、これから昼(光の時間)が優勢になり始める物理的な転換点である。

  • 恒星黄道帯(Sidereal Zodiac): 実際の星座(恒星群)の位置を基準とする。歳差運動により、季節とのズレが生じる。
  • 回帰黄道帯(Tropical Zodiac): 春分点を固定点とする。太陽と地球の幾何学的な関係性(季節サイクル)を基準とするため、恒星の位置とは独立して機能する。

本システムが記述するのは「恒星からの神秘的なエネルギー」ではなく、**「太陽と地球の角度関係によって生じる季節的なエネルギー変動」**である。したがって、採用する座標系は必然的に回帰黄道帯となる。


1.2 物理モデルとしての「エレメント」

状態変数のラベルとしての4元素

システム内で使用される「火・地・風・水」という用語は、魔術的な構成要素を指すものではない。これらは、アリストテレス物理学に基づく**「状態変数(State Variables)」**のラベルである。

物質や環境の性質は、以下の2つの二項対立パラメータの組み合わせによって決定される。

パラメータ1:熱力学的状態(Temperature)

エネルギーの活動レベルを定義する。

  • 熱(Hot): エネルギーの拡散、放射、活動的。遠心力。
  • 冷(Cold): エネルギーの凝縮、吸収、受動的。求心力。

パラメータ2:構造的結合状態(Humidity)

境界の性質を定義する。

  • 乾(Dry): 境界の維持、分離、構造化。形を保つ力(抵抗)。
  • 湿(Moist): 境界の消失、結合、流動化。形を変える力(適応)。

エレメントのマトリクス定義

上記のパラメータを組み合わせることで、4つの基本ステート(エレメント)が定義される。

エレメント パラメータ構成 物理的挙動の定義
火 (Fire) Hot / Dry 激しく拡散し、他と混ざらない。
熱エネルギーの放射と、境界の維持。上昇志向と分離性。
地 (Earth) Cold / Dry 凝縮し、固形化する。
エネルギーの収束と、構造の固定。重力と物質化。
風 (Air) Hot / Moist 拡散し、広く浸透する。
熱エネルギーの放射と、境界の流動化。拡散と結合。
水 (Water) Cold / Moist 凝縮し、形を変えて馴染む。
エネルギーの収束と、結合。受容と変容。

このように、エレメントとは「物質そのもの」ではなく、その物質がどのような**「物理的挙動(Behavior)」**を示すかを記述するためのクラス定義である。


1.3 12サイン:季節のエネルギー分布図

座標系の補足:時計のメタファー

前節で述べた「回帰黄道帯(Tropical Zodiac)」と、実際の星座(恒星)とのズレについて、多くの初学者が抱く疑問を解消するために、一つのメタファーを提示する。

ホロスコープというシステムは、**「壁掛け時計」**に例えられる。

  • 恒星(Constellation): 時計の背後にある壁紙の模様。
  • サイン(Sign): 時計のベゼル(枠)に刻まれた1から12の目盛り。

地球の歳差運動(首振り運動)により、時計本体は数万年かけてゆっくりと回転している。そのため、ベゼルの目盛り(サイン)と、背景の壁紙(恒星)の位置関係は徐々にズレていく。
しかし、このシステムが計測しているのは「壁紙の模様」ではない。**「ベゼルの目盛り(季節時間)」**である。

ベゼルの「0」の位置は、常に春分点(太陽が北半球に入る瞬間)に固定されている。システムにとって重要なのは、背景にある星の配置ではなく、太陽がこの「季節の目盛り」のどこを通過しているかという幾何学的な事実のみである。


物理モデルとしての「モダリティ(3区分)」

サインを分類するもう一つの軸である「活動(Cardinal)」「不動(Fixed)」「柔軟(Mutable)」は、エネルギーの**「波形(Waveform)」**として定義される。

1. Cardinal(活動):始動の波形

  • 定義: 季節の開始点(Equinox / Solstice)。
  • 物理特性: 加速度(Acceleration)が最大になる立ち上がりエッジ。静止状態から運動状態への急激な変化。
  • 挙動: エネルギーの放射、開始、衝撃。

2. Fixed(不動):持続の波形

  • 定義: 季節の最盛期。
  • 物理特性: エネルギー供給が安定するプラトー(定常状態)。変化に対する抵抗(慣性モーメント)が最大化された状態。
  • 挙動: 維持、蓄積、安定化。

3. Mutable(柔軟):遷移の波形

  • 定義: 次の季節への移行期間。
  • 物理特性: 周波数が変調し、減衰していく立ち下がりエッジ。二つの状態(現在の季節と次の季節)の重ね合わせ。
  • 挙動: 変化、適応、混合。

12サインのシステム生成ロジック

12のサインは、太古より神話的なキャラクター付けがされているが、これらは、前述した**「4つのエレメント(状態変数)」と「3つのモダリティ(波形)」**のマトリクス演算によって自動生成される、12種類のアドレス定義である。

サイン生成マトリクス

Fire (Hot/Dry)
拡散・分離
Earth (Cold/Dry)
凝縮・固定
Air (Hot/Moist)
拡散・結合
Water (Cold/Moist)
凝縮・結合
Cardinal
(始動)
牡羊座 (Aries)
爆発的な放射の開始。
(点火)
山羊座 (Capricorn)
構造化の開始。
(基礎設計)
天秤座 (Libra)
拡散の開始。
(風の発生)
蟹座 (Cancer)
受容の開始。
(湧水)
Fixed
(持続)
獅子座 (Leo)
放射の持続。
(燃焼し続ける炎)
牡牛座 (Taurus)
物質の固定。
(大地・岩盤)
水瓶座 (Aquarius)
拡散の固定。
(気圧配置)
蠍座 (Scorpio)
結合の固定。
(氷・深淵)
Mutable
(遷移)
射手座 (Sagittarius)
放射の変調。
(飛び火・拡散)
乙女座 (Virgo)
物質の細分化。
(砂・分析)
双子座 (Gemini)
拡散の分散。
(乱気流)
魚座 (Pisces)
結合の拡散。
(霧・溶解)

読者は、各サインの名前(牡羊座など)を、**「ファイル名」**として認識すべきである。その実体は、表に示された物理特性の組み合わせに他ならない。

element_matrix.png


[Column] バビロニアの天文日誌:世界最古のビッグデータ

紀元前7世紀から紀元前1世紀にかけて、バビロニアの書記たちは、異常な執念で夜空を記録し続けた。

大英博物館に所蔵されている粘土板「天文日誌(Astronomical Diaries)」には、約600年間にわたる惑星の位置、月相、気象、そして市場の物価や河川の水位までもが、毎晩欠かさず記録されている。

彼らが行っていたのは、単なる「予言」ではない。それは、天体現象(入力)と地上の事象(出力)の間に存在する相関関係を見つけ出すための、**「観測データのロギング(Big Data Logging)」**であった。

現代のデータサイエンスが「相関関係(Correlation)」から予測モデルを構築するように、古代のシステムエンジニアたちもまた、膨大なデータセットの中から「世界を記述するアルゴリズム」をリバースエンジニアリングしようと試みていたのである。


第2章 独立変数の定義(The Planets)

本章では、座標系の上を移動する「独立変数(Planets)」を定義する。
これらは神話の神々ではなく、固有の周波数と機能を持つシステムモジュールとして扱われる。また、それらの権限関係(ヒエラルキー)を決定する配列についても解説する。


2.1 変数定義:7つの機能モジュール

独立変数としての惑星

本システムにおいて、惑星(Planets)は擬人化された神として崇拝の対象となるものではない。

その名称と象徴は古代の体系に由来するが、本記述においては、システム内で特定の周波数帯域を担当し、固有の機能を実行する**「機能モジュール(Function Modules)」**として定義して扱う。

各変数は固有の公転周期(サイクル)を持ち、その周期の長さに応じて、マクロ(社会・構造)からミクロ(個人・日常)に至るまで、異なるレイヤーの事象を処理する。

1. 土星(Saturn):構造維持モジュール

  • 公転周期: 約29年
  • 機能定義: 制限(Limit)、境界設定(Boundary)、構造化(Structure)。
  • 物理特性: 極度の冷却と乾燥(Cold/Dry)。古代宇宙観において最遠天体であり、恒星界との境界にあることから、システムのエントロピー増大を防ぐための「枠」を提供する。不要なものを排除し、システムを安定化させるリミッター。

2. 木星(Jupiter):スケーリングモジュール

  • 公転周期: 約12年
  • 機能定義: 拡大(Expansion)、資源配分(Allocation)、結合(Cohesion)。
  • 物理特性: 適度な熱と湿り気(Hot/Moist)。システムの成長と発展を促進する。リソースを増やし、可能性を広げるアクセラレーター。

3. 火星(Mars):分離・駆動モジュール

  • 公転周期: 約2年
  • 機能定義: 分離(Separation)、切断(Severance)、駆動(Drive)。
  • 物理特性: 極度の熱と乾燥(Hot/Dry)。結合を断ち切り、個体を独立させる力。エンジンのような爆発的なエネルギー出力。

4. 太陽(Sun):基準クロック・目的関数

  • 公転周期: 1年
  • 機能定義: 基準クロック(Reference Clock)、光源(Source)、目的意識(Objective)。
  • 物理特性: 熱と乾燥(Hot/Dry)。システムのエネルギー源であり、すべての変数の動作基準となるマスタークロック。

5. 金星(Venus):結合プロトコル

  • 公転周期: 約225日
  • 機能定義: 調和(Harmony)、結合(Connection)、統合(Integration)。
  • 物理特性: 冷却と湿り気(Cold/Moist)。異なる要素同士を結びつけ、摩擦を低減する潤滑油としての機能。

6. 水星(Mercury):データ処理バス

  • 公転周期: 約88日
  • 機能定義: 通信(Transmission)、翻訳(Translation)、データ処理(Processing)。
  • 物理特性: 基本的には冷却と乾燥(Cold/Dry)。情報を細分化・構造化する性質を持つ。ただし、機能としては**中性(Neutral/Variable)**であり、接続する他変数の性質を透過・模倣する「可変レジスタ」として振る舞う。

7. 月(Moon):I/Oインターフェース・キャッシュ

  • 公転周期: 約27.3日
  • 機能定義: 物質化(Materialization)、受容(Reception)、記憶(Memory)。
  • 物理特性: 冷却と湿り気(Cold/Moist)。上位レイヤー(他の惑星)からの信号を最終的に地上へ出力するためのディスプレイ、またはバッファメモリ。

2.2 階層構造:カルデア配列(Chaldean Order)

速度による権限の委譲

これら7つの変数は、対等な関係ではない。システム内には、**「カルデア配列(Chaldean Order)」**と呼ばれる厳格な階層構造が存在する。これは、地球からの見かけの平均速度が「遅い順」に並べたものである。

配列順序:

  1. 土星(最遅)
  2. 木星
  3. 火星
  4. 太陽
  5. 金星
  6. 水星
  7. 月(最速)

システムルール:上位下達の法則

この配列には、システム全体を支配する重要なルールが適用される。

「速度が遅い(周期が長い)変数が、速い変数の動作環境を決定する」

これは、プログラミングにおけるスコープ(Scope)の概念に近い。
土星や木星といった「マクロ変数」は、時代や社会構造といった大きな枠組み(グローバル環境)を決定する。一方、水星や月といった「ミクロ変数」は、その枠組みの中でしか動作できない。

メタファー:時計の針

この関係性は、アナログ時計の針に例えられる。

  • 時針(土星): 動きは遅いが、時間の「単位(何時台か)」を決定する。
  • 分針(太陽): 時針が指す範囲内で、分を刻む。
  • 秒針(月): 最も速く動くが、時針と分針が決定したコンテキストの上でしか意味を持たない。

秒針(月)がどれほど激しく回転しても、時針(土星)を強制的に進めることはできない。同様に、個人の感情や日常(月)が、社会構造や物理的限界(土星)を覆すことは、システム上不可能であると定義される。


[Column] アルゴリズムの実装例:七曜と惑星時間

現在、世界中で使用されている「1週間(七曜)」の順序は、神話的な恣意性ではなく、**「カルデア配列を用いた数理的な順列生成」**によって決定されている。

1. 配列の定義(基本ループ)
惑星を速度の遅い順に並べたカルデア配列を、システムの基本ループとして定義する。
土星(Saturn) → 木星 → 火星 → 太陽(Sun) → 金星 → 水星 → 月(Moon)

2. 時間の割り当て(プラネタリー・アワー)
1日の「1時間目」から順に、この配列を無限ループで割り当てていく。

  • ある日の1時間目が「土星」であるとする(これを土曜日と定義する)。

3. モジュロ演算によるシフト
1日は24時間である。配列は7つの要素を持つ。
ここで、$24 \pmod 7 = 3$ という演算が成立する。つまり、配列は毎日「3つ」ずつズレていくことになる。

  • 1日目(土曜日): 1時間目は土星。
    • 24時間目は火星(土星から24番目)。
  • 2日目(日曜日): 1時間目は、火星の次の太陽になる。
    • (土星から見て $+3$ のインデックス)
  • 3日目(月曜日): 1時間目は、太陽の次の月になる。
    • (太陽から見て $+3$ のインデックス)

この「3つ飛ばし」のジャンプ(土→日→月→火→水→木→金)こそが、現在のカレンダーの正体である。

カルデア配列を円周上に配置し、一つ飛ばし(3つ目の要素)に線を結んでいくと、そこには**「七芒星(Heptagram)」**の幾何学模様が現れる。我々が日常的に使用している曜日の順序は、この幾何学的なアルゴリズムによって、数千年前から厳格に運用され続けているのである。

251215_七芒星.png


2.3 適合度スコア:エッセンシャル・ディグニティ

システム権限としての「品位」

古典占星術において「品位(Dignity)」と呼ばれる概念は、本システムにおいては**「適合度スコア」および「システム権限(Permission Level)」**として再定義される。

これは、変数(惑星)が特定の環境(サイン)に入った際、その環境に対してどれだけの制御権を持つか、あるいはリソースへのアクセス権を与えられるかを示す階層的なステータスである。

Note: プロトコルバージョンと仕様の出自

  1. バージョニングについて 本稿で提示する権限レベルおよびスコアリングモデル(+5点〜+1点)は、主に中世アラビア期(Medieval Arabic Period)に標準化された仕様に準拠している。 占星術のアルゴリズムは時代によってアップデートを繰り返しており(ヘレニズム期、ルネサンス期など)、参照する「ライブラリ(原典)」によって重み付けの定義が異なる場合がある。現代の実務家(User)においても、独自のカスタム設定を用いるケースが存在する点に留意されたい。

  2. アルゴリズムのブラックボックス性 また、本章で定義するエッセンシャル・ディグニティの「ターム(Terms / Bounds)」は、本システムの中で唯一、アリストテレス自然哲学と天文学根拠(物理的説明)を持たないスコアリングシステムである点にも注意が必要である。 サイン(季節変動)やハウス(日周運動)が物理現象に基づいているのに対し、この配点ロジックは、なんらかの象徴的な秩序によって決定されている。紀元前4世紀頃のバビロニア粘土板にまで遡るその数値設定の根拠やアルゴリズムの出自(Origin)は、現代においても解明されていない。

[!WARNING]
参照テーブルの互換性 (Compatibility)
エッセンシャル・ディグニティの算出に使用するデータテーブルには、互換性のない複数の歴史的バージョンが存在する。

  • ターム(Terms): エジプシャン版の他、論理的な再構築を試みたプトレマイオス版、さらに古いアラトス版やカルデアン版など、複数のバージョンが存在する。これらは度数配列が異なるため、実装時には参照テーブルを厳密に定義する必要がある。
  • フェイス(Face): 10度分割は共通だが、カルデア順、サイン順、トリプリシティ順など、割り当てロジックに複数のバージョンがある。本稿ではカルデア順を採用する。

5段階の権限レベルとスコアリング

システムは以下の5つの基準に基づいて、変数の状態を評価し、スコアを加算する。

1. ドミサイル(Domicile):管理者権限

  • スコア: +5
  • 定義: そのサインの「支配星(Ruler)」である状態。
  • システム権限: Root / Admin
    • 変数は「自宅」にいる状態であり、環境内のすべてのリソースにフルアクセスできる。
    • 最も安定的かつ持続的な出力を保証する。

2. エグザルテーション(Exaltation):最優先プロセス

  • スコア: +4
  • 定義: そのサインで変数の機能が「高揚」される状態。
  • システム権限: High Priority / VIP Guest
    • 変数は「貴賓客」として扱われる。管理権限(Root)は持たないが、瞬間的な出力効率(オーバークロック)においては管理者をも凌駕するパフォーマンスを発揮する。
    • ただし、持続性や安定性においてはドミサイルに劣る場合がある。

3. トリプリシティ(Triplicity):チームメンバー

  • スコア: +3
  • 定義: エレメント(火・地・風・水)の属性一致による支援。
  • システム権限: Group User
    • 同じ属性を持つ「チームメイト」の環境にいる状態。
    • 十分なリソースと快適な動作環境が提供されるが、決定権は限定的である。

4. ターム(Term):境界防衛

  • スコア: +2
  • 定義: サイン内を不等分割した特定の度数域における権限。
  • システム権限: Local User / Boundaries
    • 広大なオフィスの中の「自分のデスク」や「ロッカー」の中でのみ自由が許される状態。
    • 権限は限定的だが、身体的な安全性や最低限の機能は保証される。

5. フェイス(Face):外観のみ

  • スコア: +1
  • 定義: サインを10度ずつ3分割したデカン(Decan)における権限。
  • システム権限: Guest (Appearance only)
    • 権限はほぼないが、玄関先に立っているような状態。
    • 「体裁だけは整っている」ため、完全な機能不全(エラー)は免れている。

エッセンシャル・デビリティ(機能不全)

適合度スコアがマイナス、あるいはゼロとなる状態は、システム上のエラーまたは未定義動作として扱われる。

デトリメント(Detriment) / フォール(Fall)

  • 定義: ドミサイルやエグザルテーションの正反対の位置にあるサイン。
  • 状態: System Error / Malfunction
    • 変数の性質と環境の性質が矛盾し、正常な出力が行えない状態。
    • 例:熱い火星が、冷たい蟹座(水のサイン)に配置され、火が消えかかっている(出力効率の低下、または歪んだ出力)。

ペレグリン(Peregrine):権限なし

  • 定義: 上記のいずれの品位(+1以上)も持たない状態。
  • 状態: No Authority / Wanderer
    • システムからの保護も権限も与えられていない「放浪者」。
    • 善悪の判断基準を持たず、周囲の環境や他者の干渉によって無秩序に振る舞うため、出力の予測が困難である。

[Column] プトレマイオス:物理学としての占星術

2世紀のアレクサンドリアで活躍したクラウディオス・プトレマイオスは、天動説の体系を完成させた天文学者として知られるが、同時に占星術の体系化においても決定的な役割を果たした。

彼の主著『アルマゲスト』が天体の動きを計算する「数理天文学」の書であるのに対し、『テトラビブロス(四書)』は、その天体の配置が地上にどのような物理的影響を与えるかを論じた「応用物理学」の書であった。彼にとって、この二つは**「一つの科学の両輪」**であった。

プトレマイオスは、惑星が神の意志を伝えるのではなく、その幾何学的配置(アスペクト)が地上の大気(熱・冷・乾・湿)を変化させ、それが間接的に人間や社会に影響を与えるという**「環境物理学(Stochastic Physics)」**のモデルを提唱した。

本稿が採用しているアルゴリズムの多くは、彼が記述した物理モデルを基礎としている。


2.4 古典占星術と現代占星術のシステム差異

古典占星術(本稿で解説するシステム)と、19世紀以降に構築された現代占星術は、**「システムの目的(スコープ)」**が異なる。

現代占星術は「個人の内面」分析に特化するために、システム仕様を大きく変更した。

機能 (Feature) 古典占星術(Traditional / 本システム) 現代占星術(Modern / 19世紀以降)
対象天体 7天体(太陽〜土星)。目視可能な物理変数に限定。 10天体以上(天王星、海王星、冥王星)。内面・集合意識を記述するための機能追加(Feature Creep)。
駆動原理 天動説ベース(Primary Motion)。地球からの相対的・幾何学的配置を最重視。 心理学ベース。天体配置を個人の精神構造のマップとして解釈。
判断の重み **ディグニティ(権限)**が主軸。惑星の状態(Good/Bad)を論理的に評価。 アスペクトとサインの組み合わせが主軸。惑星の状態(Good/Bad)は心理的に中和。
動的条件 セクト/Hayzなど、昼夜の環境によるON/OFFスイッチが必須。 ほとんど使用されない。環境依存のロジックを簡略化。
運用スコープ 事象予測、政治、軍事。システム全体の未来予測。 心理、パーソナリティの分析。個人の特性分析。

第3章 ローカル座標系の定義

本章では、「黄道(グローバル変数)」から「地上(ローカル変数)」への座標変換プロセスを解説する。
これは、惑星という変数を、観測者固有の環境(地平線や子午線)にマッピングする工程である。

3.1 座標変換:プライマリー・モーション

占星術のシステムを物理モデルとして理解するためには、天球上で発生している2つの異なる「回転ベクトル」を明確に区別する必要がある。

2つのモーション

  1. セカンダリー・モーション(Secondary Motion / 第二駆動)

    • 定義:惑星が黄道上を「西から東」へ進む公転運動。
    • 周期:月(約28日)〜土星(約29年)。
    • システム上の意味:これは**「変数の値」の変化**です。データベース内のレコードが書き換わるような、比較的緩やかな情報の更新プロセスに相当する。
  2. プライマリー・モーション(Primary Motion / 第一駆動)

    • 定義:地球の自転により、全天(恒星天および惑星)が「東から西」へ回転する運動。
    • 周期:24時間。
    • システム上の意味:これは**「システム全体を強制的に回転させる駆動(Drive)」**です。これは単なる移動(Motion)ではなく、すべての変数を支配下に置く、不可避のクロックサイクルとして機能する。

初期条件の鋭敏性

プライマリー・モーションの速度は、約4分間で1度である。
これは、出生時刻(Time)という入力パラメータにおけるわずか4分の誤差が、出力されるチャートの構造(ハウス区分やアングル)を1度ずらすことを意味する。
システム工学の視点で見れば、この高速回転こそが、占星術システムにおける「初期条件の鋭敏性(Sensitivity to initial conditions)」の主因であり、数分の入力ズレが、全く異なる出力結果(運命解釈)を生み出すメカニズムは、このプライマリー・モーションの物理的特性に由来する。

構造的メタファー:HDDと読み取りヘッド

この動的な構造は、ハードディスクドライブ(HDD)の仕組みに例えることができる。

  • 回転するプラッタ(円盤):第一駆動(Primary Motion)によって高速回転する「全天(黄道帯)」。ここには惑星というデータが書き込まれている。
  • 読み取りヘッド:地上に固定された観測点(後述するアングル)。

プラッタが高速で回転することで、読み取りヘッドは次々と異なるデータ(惑星やサイン)にアクセスする。占星術のチャート作成とは、ある瞬間にこの回転を停止させ、ヘッドがディスク上のどのセクタを指しているかをスナップショットとして記録する処理と言える。


3.2 幾何学的定義:アングル(The Angles)

前述の「読み取りヘッド」に相当するのが、アングル(Angles)と呼ばれる4つの枢要点である。
これらは、天球上の2つの大円(Great Circles)の交点
として幾何学的に厳密に定義される。

アセンダント(ASC / Ascendant)

  • 幾何学的定義:**黄道(Ecliptic)と東の地平線(Horizon)**の交点。
  • 機能:システムの**「入力端子」**。
    • 地上の観測者にとって、天体(情報)が地平線下に潜む「非可視領域」から、地上という「可視領域」へと浮上してくる境界線。
    • システム工学的には、環境との最初の接続インターフェースであり、外部入力がシステム内に取り込まれるポイントとして機能する。

MC(Medium Coeli / Midheaven)

  • 幾何学的定義:**黄道(Ecliptic)と子午線(Meridian)**の交点(南中点)。
  • 機能:システムの**「最高出力点」**。
    • 天体が日周運動において到達できる物理的な最高高度(Culmination)。
    • 可視性が最大化されるポイントであり、システム内で処理された情報が最も強く外部へ出力・顕現するフェーズに対応する。

ディセンダント(DSC)と IC

これらはそれぞれ、ASCとMCの対向点(180度反対側)として定義される。

  • ディセンダント(DSC / Descendant):黄道と西の地平線の交点。天体が沈み、出力が終了するポイント。
  • IC(Imum Coeli / Lower Midheaven):黄道と子午線の交点(北中点)。天体の高度が最低となる、システムの基底部。

まとめ:動的なシステムとして

静止画としてのチャート(ホロスコープ)を見ると忘れがちだが、実際には「黄道」というベルトコンベアが高速で回転し、「地平線・子午線」という作業ロボット(アングル)がその上の部品(惑星)を次々とピックアップしている状態。
次章以降で解説する「ハウス分割」は、このアングルによって切り取られた空間を、さらに細分化するアルゴリズムとなる。


3.3 空間分割:ハウスシステム

アングルによって定義された4つの象限(Quadrants)を、さらに細分化するアルゴリズムが**「ハウスシステム(House System)」**である。

ローカル空間の分割アルゴリズム

ハウスは、全天を12の**「活動領域(Fields)」**に分割し、惑星という変数が「どこに出力されるか(人生のどの分野で機能するか)」を決定する。
システム工学的には、各惑星(機能)を特定の出力ポートにルーティングする処理と言える。

  • 第1ハウス(Ascendant):システムの本体、自己自身。
  • 第10ハウス(Midheaven):システムの実行、社会的な出力、キャリア。
  • 第7ハウス(Descendant):外部インターフェース、対人関係、パートナーシップ。
  • 第4ハウス(Imum Coeli):システムの基盤、ストレージ、家庭、ルーツ。

アクシデンタル・ディグニティ:出力強度の階層

第2章で解説した「エッセンシャル・ディグニティ」が惑星の「質(Quality)」を表すのに対し、ハウス配置は惑星の**「量(Quantity)」や「出力強度(Volume)」を決定する係数として機能する。これを「アクシデンタル・ディグニティ(Accidental Dignity)」**と呼ぶ。

アングル(Angular Houses: 1, 4, 7, 10)

  • 出力係数:100% (High Volume)
  • 物理的に最も目立つ領域である。ここに配置された惑星は、その機能(良し悪しに関わらず)をフル稼働させ、外部に対して顕著な影響を与える。
  • システムのアクティブな前面処理に相当する。

サクシデント(Succedent Houses: 2, 5, 8, 11)

  • 出力係数:50% (Medium Volume)
  • アングルを支えるリソース領域である。安定した出力が可能だが、アングルほどの派手さや即時性はない。
  • 「2ハウス(財産)」や「11ハウス(友人・希望)」などがここに含まれ、システムを維持するための供給源として機能する。

カデント(Cadent Houses: 3, 6, 9, 12)

  • 出力係数:< 25% (Low Volume / Latency)
  • アングルから崩れ落ちる(Cadent)場所である。
  • システム上の**「盲点(Blind Spot)」や「バックグラウンド処理」**に相当する。可視性が著しく低く、ここに配置された惑星の機能は、内面的な処理やノイズとして現れやすく、外部出力には遅延(Latency)が生じる。
    • 注:伝統的に第6,12ハウスは「不幸の場所」と表現されることがあるが、工学的には「制御不能な入力」や「デバッグ困難な領域(可視化されにくいプロセス)」と定義される。

12の活動領域(System Domains)

各ハウスを、**「システムの出力先ドメイン」**として機能的に定義する。

House Domain Type 機能定義 (Functional Definition)
1st Identity [System Core] 本体、実装された筐体、OSそのもの。
2nd Resources [Storage] 獲得したリソース、資産、燃料タンク。
3rd Network [Local I/O] 近距離通信、兄弟ノード、基礎学習データ。
4th Foundation [Base / Root] 基盤、ルーツ、遺伝的継承、隠された深層。
5th Creation **[Instance Generation / UX]**インスタンス生成(子供)、喜び、報酬。
6th Maintenance [Debug / Task] システム保守、労働、バグ(病気)処理、従属プロセス。
7th Interface [External Connection] 対外接続端子、パートナー、対等な他社システム。
8th Termination **[Garbage Collection / External Resources]**死、リソースの喪失、他者のリソース、腐敗(Corruption)。
9th Exploration [Remote Network] 遠距離通信、高度な学習、哲学・宗教(抽象レイヤー)。
10th Execution [Main Process] 社会的実行、キャリア、権限、公的なステータス。
11th Distribution [Community] 友人、希望、ネットワークの分散、将来のビジョン。
12th Isolation **[Unknown Error / Sandbox]**隠された敵、悪意ある入力、隔離環境、予期せぬ例外処理。

空間分割アルゴリズムの比較(House Division Algorithms)

「プラシダス」以外のアプローチを、**「空間の離散化ロジックの違い」**として解説する。

  • ホールサイン(Whole Sign):
    • ロジック: [Digital/Discrete] *ASC(アセンダント)が含まれるサイン全体を、自動的に「第1ハウス」として定義する。サイン境界=ハウス境界とする最もシンプルな離散モデル。
    • 特徴: 計算コストが低く、古代・ヘレニズムの標準(Default)。インド占星術の標準。
  • イコール(Equal):
    • ロジック: [Fixed Width] ASCを起点に、30度ずつ均等に分割する。
    • 特徴: 緯度の影響を受けない安定した分割。
  • プラシダス(Placidus):
    • ロジック: [Time-based] 天体の可視時間(昼弧・夜弧)を時間的に分割して投影する。
    • 特徴: 現代のデファクトスタンダードだが、高緯度地方では計算不能(破綻)するバグがある。
  • レジオモンタヌス(Regiomontanus):
    • ロジック: [Spatial] 天の赤道を等分割し、地平線へ投影する。
    • 特徴: ホラリー占星術での標準。空間的な整合性を重視。

[Column] 数学者プラシダスと球面三角法

現在、広く使用されている「プラシダス・ハウスシステム(Placidus House System)」は、17世紀のイタリアの修道士であり数学者、**プラシダス・デ・ティティ(Placidus de Titis, 1603-1668)**によって普及した。

彼のシステムは、単なる空間の等分割ではなく、**「時間」**を幾何学的に分割しようとする高度な試みだった。彼は、天体が地平線から子午線まで移動する軌跡(昼間半弧・夜間半弧)を3等分するという、極めて複雑な計算モデルを提唱した。

これは当時の**「球面三角法(Spherical Trigonometry)」**を駆使した数学的解法であり、占星術が、当時の最先端の天文学・数学と密接に結びついた「計算科学」であったことを象徴している。プラシダスのアルゴリズムは、惑星の軌道を計算するだけでなく、「地平線上の時間」という不可視の次元を幾何学的に構造化しようとした、数学的挑戦の帰結であった。


第4章 アスペクトと幾何学

第2章で「変数(惑星)」を定義し、第3章で「座標系(サイン・ハウス)」を構築した。
本章では、定義された変数同士がどのように通信・干渉し合うか、そのロジックを解説する。

4.1 視線(Ray)の理論:光学的通信モデル

占星術における「アスペクト(Aspect)」という用語は、ラテン語の Aspicere(見る)を語源としている。
システム工学的に言えば、これは**「光学的通信(Optical Communication)」**のモデルである。

惑星=光源、アスペクト=通信回線

このモデルにおいて、各惑星は特定の周波数を持つ「光源」として定義される。
惑星は全方位に光を放射しているが、特定の角度(アスペクト角)で他の惑星と結ばれたときのみ、有効な「視線(Ray)」が通り、通信回線が確立される。

  • 視線が通る(Aspect):通信プロトコルが一致し、データの送受信が行われている状態。
  • アバーション(Aversion / 嫌悪・無視):視線が通らない配置。
    • これは「通信断絶」や「パケットロス」を意味する。
    • 互いの存在を認識できず、連携も干渉もできない「システム上の分断」状態である。

4.2 ピタゴラス的調和と多角形

アスペクトとして定義される角度はランダムではない。
それらはすべて、円(360度)を「整数」で除算した点、つまり正多角形の頂点に由来する。
この幾何学的な共鳴関係が、通信の質(帯域幅やノイズの有無)を決定する。

5つのメジャー・アスペクトの物理的挙動

1. コンジャンクション(Conjunction / 0度)

  • 幾何学:点(Unity)。
  • 定義:融合(Blending)。
  • 挙動:2つの信号源が物理的に重なり合っている状態。個々の波形は区別できなくなり、合成された新しい波形が出力される。吉凶(Easy/Difficult)は、混合される成分の化学反応に依存する。

2. オポジション(Opposition / 180度)

  • 幾何学:円の分割(2等分)。直径。
  • 定義:対立・緊張(Tension)。
  • 挙動:システム内で取り得る最大距離。2つの変数が正反対の極に位置し、互いに強く引き合う「綱引き(Tug-of-war)」状態である。極めて高いテンション(電圧)が発生するが、バランスが取れれば強力な客観性を生み出す。

3. トライン(Trine / 120度)

  • 幾何学:正三角形(3等分)。
  • 定義:流動(Flow)。
  • 挙動:抵抗値が最小の回路。データは摩擦なくスムーズに流れ、帯域幅(Bandwidth)が広い状態。
  • 分類:ソフトアスペクト(Easy)。システムへの負荷が低く、安定している。

4. スクエア(Square / 90度)

  • 幾何学:正四角形(4等分)。
  • 定義:摩擦(Friction)。
  • 挙動:2つの力が直角に交わる交差点。ここでは必然的に衝突が起き、熱エネルギーが発生する。
  • 分類:ハードアスペクト(Difficult)。システムに負荷をかけるが、この「熱」こそが、問題を解決し現状を変えるための**「動力(Motive Force)」**となる。

5. セクスタイル(Sextile / 60度)

  • 幾何学:正六角形(6等分)。
  • 定義:協調(Coordination)。
  • 挙動:トラインと同様に建設的な接続だが、より意識的な操作を必要とする。
  • 分類:ソフトアスペクト(Easy)。

aspect.png


[Column] ヨハネス・ケプラー『世界の調和』

近代天文学の父、**ヨハネス・ケプラー(Johannes Kepler, 1571-1630)**による「占星術は天文学の愚かな娘」という言葉はよく知られている。『新星について(De Stella Nova)』(1606年)に掲載されたこのフレーズは、彼が仕方なく占星術業を営んでいた証左として用いられることがある。実際は熱心な占星術研究者だった。当て物の占星術を軽蔑し、独自の数学と音楽理論で従来とは異なる新しいモデルを提唱した。その主著『世界の調和(Harmonices Mundi)』において、惑星の軌道半径や角速度の比率に、音楽的な「和音(Chord)」を見出している。

ケプラーにとってアスペクトとは、地上の人間の運勢を占うための神秘的な記号ではなく、**「宇宙という巨大な楽器が奏でる和音」**の幾何学的記述だった。彼は、惑星間の角度が、音楽理論における「協和音程(コンソナンス)」に対応するとき、そこに物理的な共鳴現象が生じると考えたのである。
現代の占星術アルゴリズムにおけるアスペクト理論の多くは、ケプラーの「幾何学的・音楽的調和」の概念を基礎としている。


4.3 アスペクトのイベント処理ロジック

アスペクトは、幾何学的な「点」であると同時に、時間的な「プロセス」である。
本節では、アスペクトが形成され、完成し、解消されるまでの一連のフローと、その過程で発生する例外処理(イベントの阻害)について解説する。
これらは「占いが当たるか」という確率論ではなく、システム内での**「イベント発生条件の判定ロジック(if-thenルール)」**として定義される。

接近と分離:イベントのライフサイクル

惑星は常に移動しているため、アスペクトの状態は動的に変化する。

1. 接近(Application / Applying)

  • 定義:移動の速い惑星が、遅い惑星に対してアスペクトの完成に向かって近づいている状態。
  • システム上の意味:「イベント未決(Pending)」あるいは「未来の事象」。
  • リクエストは送信されたが、まだ実行(Commit)されていないトランザクション。

2. 完成(Perfection / Partile)

  • 定義:2つの惑星の角度が、度数単位で正確に一致した瞬間。
  • システム上の意味:「イベント発火(Trigger)」。
  • 条件式が True を返し、定義されたイベント(事象)が実行される瞬間である。

3. 分離(Separation / Separating)

  • 定義:アスペクトが完成した後、速い惑星が遅い惑星から離れていく状態。
  • システム上の意味:「イベント完了(Executed)」あるいは「過去の事象」。
  • 処理は終了しており、その影響(ログ)のみが残っている状態。

オーブ(Orbs):有効通信範囲

アスペクトには、正確な角度から数度のズレを許容する範囲、**「オーブ(Orb)」が設定されている。
これはシステム工学における
「信号の有効通信範囲(Signal Range)」**である。

  • [Note] 定義の変遷:
    • 現代の多くのシステムでは「アスペクトの種類(トラインなら8度など)」によってオーブを定義するが、古典的なアルゴリズム(中世以前)では、**「惑星ごとの光の広がり(Moiety)」**に基づいて計算される。
    • 例えば、太陽は半径15度、月は半径12度といった固有の「信号強度エリア」を持っており、互いのエリアが接触した時点で通信が開始される。

[!NOTE]
オーブ仕様のバージョン管理 (Versioning)
信号有効範囲の定義は、システムのバージョン(時代)、ライブラリ(著作)によって異なる。

  • v1.0 ヘレニズム期(ポリフィリウス等): 月15度、他惑星3度といったタイトな固定値を採用する事例があった。
  • v2.0 アラビア期(アル・ビルーニ等): 惑星ごとの「光の半径(Moiety)」に基づき、動的な有効範囲を計算する様式が標準化された。
  • v3.0 ルネサンス期(リリー等): アラビア期のライブラリを継承し、固定値(例:太陽17度、月12.5度)の標準化が進められた。

幾何学的優位性(Directional Strength)

通信において、どちらの惑星が主導権を握るかは、黄道上の位置関係によって決定される。

オーバーカミング(Overcoming)

  • 定義:黄道上で「右側(度数が若い、または日周運動で先行する)」にある惑星が、「左側(後)」にある惑星に対してアスペクトする場合。
  • システム上の意味:「上位プロセスによる割り込み(Interrupt)」あるいは「右側優先の法則」。
  • 右側の惑星は「優位な位置(Superior Position)」にあり、左側の惑星に対して一方的に命令を上書きしたり、動作を抑制したりする権限を持つ。

ストライキング・ザ・レイ(Striking with a Ray)

  • 逆行する惑星が、順行する惑星に向かってアスペクトを投げる場合など、特定の条件下で発生する強力な干渉作用。通常の通信よりも強制力の強いコマンド送信として処理される。

イベントの阻害・キャンセル(Prohibition)

接近(Applying)の状態にあっても、完成(Perfection)に至る前に別の要因が発生し、イベントが成立しないケースがある。これを**「プロヒビション(Prohibition / 禁止)」と呼ぶ。
これはシステム工学的には、
「第三のプロセスによる割り込み(Interruption)」や「エラー処理」**として分類される。AとBが接続しようとしている間に、Cが割り込んでリソースを奪う(横取りする)挙動などがこれに含まれる。

リフラネーション(Refranation)

  • 定義:アスペクトが完成する直前に、接近していた惑星が「逆行」に転じたり、次の「サイン」へ移動するなどして、接続を放棄すること。
  • システム上の意味:「タイムアウト(Timeout)」や「リクエストの取り下げ」。
  • クライアント側(接近する惑星)の事情により、トランザクションが直前でキャンセルされた状態。

フラストレーション(Frustration)

  • 定義:2つの惑星がアスペクトを完成させる前に、第三の(より速い)惑星が割り込んで、先にアスペクトを完成させてしまうこと。
  • システム上の意味:「他プロセスによるブロック(Blocking)」。
  • 本来の通信が確立される前に、別の優先度の高いプロセスがリソースを占有してしまい、元のイベントが実行不能になるエラー。

間接的な接続ロジック(Event Mediation)

直接的なアスペクトが成立しない、あるいは分離した後でも、第三者を介してイベントが成立する**「救済措置(Fallback)」**が存在しする。これらは複雑なルーティング・ロジックとして機能する。

トランスレーション(Translation of Light / 光の運搬)

  • 定義:速い惑星(A)が、惑星(B)から分離し、そのまま惑星(C)へ接近することで、BとCの間を接続すること。
  • システム上の意味:「パケットフォワーディング(Packet Forwarding)」あるいは「データキャリア(Data Carrier)」。
  • Aは「メッセンジャー」として振る舞う。Bから受け取ったステート(状態情報)を保持したままCへ移動し、BとCの間のリンクを確立させる。直接通信できないノード間を、モバイルエージェントが物理的に移動してデータを運ぶような挙動。

コレクション(Collection of Light / 光の収集)

  • 定義:惑星(A)と惑星(B)はアスペクトしていない(あるいは弱い)が、両者が共通の重い惑星(C)に対して接近(Applying)している状態。
  • システム上の意味:「集約ハブ(Aggregator / Hub)」あるいは「仲介サーバー」。
  • AとBは直接通信できないが、両者のリクエストを強力なサーバー(C)が同時に受け取る。Cは両者の権限(Light)を収集し、自身の管理下において両者のリクエストを統合・解決する。

第5章 太陽位相と高度なパラメータ

本章では、システムの判定精度を極限まで高めるための「高度な条件分岐」を網羅する。 これらは、惑星(変数)のステータスをより詳細に定義するためのパラメータ群である。

本章で扱うパラメータは、肉眼で捉えられる天体の**「光量(Luminosity)」を基準としている。古代のシステム設計者たちは、天体から発せられ地上に到達する光を、その変数が持つ「出力(Power)」**の指標として定義した。

5.1 太陽位相と可視性(Solar Phase)

太陽は、本システムにおける絶対的な基準点(Reference Point)である。 各惑星が太陽に対してどのような位置関係にあるか(太陽位相)は、その変数の「可視性(Visibility)」と「健全性(Health)」を決定する重要な条件分岐となる。

可視性のガイドライン:計算と観測

古典的なアルゴリズムでは、惑星が太陽に対して一定の角距離まで近づくことで、太陽光に隠れて肉眼で見えなくなる現象を重視する。 コンバストやアンダー・ザ・ビームスとして定義される度数(閾値)は、**「惑星が太陽の光に隠れて不可視になる境界」**をシミュレートするためのガイドラインである。

本来は実地観測(Observational)によって判定すべき「可視性」を、計算(Calculation)のみで簡易的に判定するためのロジックとして実装されている。なお、太陽光による不可視期間は惑星の軌道特性によって異なる。

  • 月:光が完全に消えるのは新月前後の数日間(年間20日程度)に限られる。
  • 火星・木星・土星:平均して年間の約9割の期間、地上に光が届く。
  • 金星:地球との会合周期(約19ヶ月)の中で、光が届く期間は長いが、内合・外合の前後には不可視期間が生じる。計算上の目安として、年間の大部分で目視可能である。
  • 水星:太陽に近接しているため、目視可能な期間は年間の約3分の1程度に留まる。

各フェーズの定義

1. カジミ(Cazimi / In the Heart of the Sun)

  • 条件:太陽の中心から 0度17分以内 にある状態。
  • システム上の意味:「特異点(Singularity)」あるいは「超伝導状態(Superconductivity)」。
  • 太陽の核(コア)に突入した状態で、惑星は太陽の力を完全に帯び、極めて強力な出力を発揮する。通常の物理法則が適用されない、システム上のボーナスステージである。現象としては、例として日面通過のような状態を指す。

2. コンバスト(Combust / 焼失)

  • 条件:カジミの範囲外で、太陽から 8度30分以内 にある状態。
  • システム上の意味:「焼失(Burnout)」あるいは「機能不全(Malfunction)」。
  • 太陽の熱と光によって惑星が焼き尽くされている状態。変数は深刻なダメージを受けており、正常な値を返すことができない。可視性はゼロであり、システム上で「無効」「特異」「破壊されたデータ」として扱われる。
    • 注:閾値は一般に8度から8.5度とされるが、例外として金星が地球に接近し最大光度となる時期は、8度以下でも目視可能となるケースがある。

3. アンダー・ザ・ビームス(Under the Beams / 光線下)

  • 条件:コンバストの範囲外で、太陽から 15度〜17度以内 にある状態(惑星によって異なる)。
  • システム上の意味:「隠蔽(Concealment)」。
  • 惑星は太陽の光の中にあり、薄暮や夜明けの明るさに紛れて見えにくい状態。コンバストほど致命的ではないが、機能は低下しており、表立った活動(外部出力)が制限されているバックグラウンド処理の状態である。

東方・西方(Oriental / Occidental)

太陽に対する相対的な位置関係(どちらが先に昇るか)は、変数の「反応速度」や「処理タイミング」を決定するパラメータである。

オリエンタル(Oriental / 東方)

  • 定義:太陽よりも黄経度数が若く、**「日の出前」**に東の地平線から昇ってくる状態。
  • システム上の意味:「アーリーバード(Early Bird)」。
  • 若々しく、即応性が高い状態。イベントに対して素早く反応し、能動的に処理を開始する。
  • 適合する変数:火星、木星、土星(外惑星)は、東方にあるときに出力が最適化される。

オクシデンタル(Occidental / 西方)

  • 定義:太陽よりも黄経度数が進んでおり、**「日没後」**に西の空に残る状態。
  • システム上の意味:「レイトブルーマー(Late Bloomer)」。
  • 晩成的で、反応が遅い状態。経験豊富だが、動き出しは慎重であり、イベントの後半で力を発揮する傾向がある。
  • 適合する変数:月、金星、および水星(内惑星)は、西方にあるときに出力が最適化される。

5.2 その他の条件分岐(Advanced Conditions)

本節では、セクト、速度、特殊な幾何学的配置など、さらに詳細な判定ロジックを解説する。

1. セクト(Sect):昼夜のモード設定

システムは、太陽が地平線よりも上にある状態を「昼(Diurnal)」、下にある状態を「夜(Nocturnal)」と定義し、チャート全体を明確に二つの動作モードに分類する。

このモード設定により、システムの「主星(Sect Light)」すなわち優先処理プロセスが決定される。昼のモードでは太陽が、夜のモードでは月がその権限を持つ。 この環境設定(昼夜の区分)に対し、各変数(惑星)が適合しているか、あるいは不適合を起こしているかを判定するロジックを、**「セクト(Sect)」**と呼ぶ。

  • ヘイズ(Hayz)
    • 定義:
      • 昼のチャート:昼の惑星(太陽・木星・土星)が、地平線上にあり、かつ男性サインにある状態。
      • 夜のチャート:夜の惑星(月・金星・火星)が、地平線上にあり、かつ女性サインにある状態。
      • 注:夜の惑星が地平線下(夜の領域)にある時をヘイズとする*『代替仕様(Alternative Specification)』**も存在する。また、火星の性別適合については、**仕様策定上の揺らぎ(Specification Variance)*が存在するが、本システムでは定義の一貫性を重視したロジックを採用する。
    • システム上の意味:「最適化済み(Fully Optimized)」。
    • 環境設定(昼夜)、配置場所(地平線)、および属性(サインの性別)の全てが仕様と一致しており、変数が最も効率よく機能できる状態である。
  • ハルブ(Halb) / 領域のセクト
    • 定義:部分的な適合。
      • 昼のチャートで、昼の惑星が地平線上にある状態。
      • 夜のチャートで、夜の惑星が地平線下にある状態。
    • システム上の意味:「準最適化(Sub-optimized)」。
    • 主要な環境設定は適合しているが、完全な最適化条件(Hayz)には至っていない状態である。

2. 速度の変化(Velocity)

惑星の移動速度は一定ではない。以下の**「平均日運動(Mean Daily Motion)」**を基準値(閾値)とし、現在の速度と比較することで、その変数の処理能力(パフォーマンス)を判定する。

$$Reference$$

平均日運動(Mean Daily Motion)

出典:William Lilly, Christian Astrology (1647), Chap. XIX.

変数 (Planet) 平均速度 (Mean Motion) 備考
月 (Moon) 13° 10' 36" 約13度。これより遅い場合(11度台など)は著しい機能低下とみなす。
水星 (Mercury) 0° 59' 08" 太陽と同等。ただし最大速度は2度を超えるため、変動幅が大きい。
金星 (Venus) 0° 59' 08" 太陽と同等。最大速度は約1度15分。
太陽 (Sun) 0° 59' 08" システムの基準クロック。約1度/日。
火星 (Mars) 0° 31' 27" 約30分/日。
木星 (Jupiter) 0° 04' 59" 約5分/日。
土星 (Saturn) 0° 02' 01" 約2分/日。
  • 高速(Fast in Motion)
    • 定義:現在の移動速度 > 平均速度。
    • システム上の意味:「ハイパフォーマンス(High Performance)」。
    • 処理能力が高く、タスクを迅速に処理する。イベントの展開が早い。
  • 低速(Slow in Motion)
    • 定義:現在の移動速度 < 平均速度。
    • システム上の意味:「処理落ち(Lag)」。
    • 負荷がかかっており、動作が重い状態。イベントの進行に遅延(Latency)が発生する。特に逆行の前後(留)では速度は極端に低下する。

参考データ:惑星日運動最頻値(Mode Daily Motion)
6000年間(BC2999〜AD2999)の惑星運動速度の最頻値。過去2000年間使われた平均値との差を表示する。

計算:Takeshi Minakawa (2025)

変数 (Planet) 最頻値速度 (Mode Motion) 平均値との差
月 (Moon) 11° 51' 49.7'' -1° 18' 45.3''
水星 (Mercury) 1° 34' 20.7'' 0° 35' 12.5''
金星 (Venus) 1° 13' 38.9'' 0° 14' 30.6''
太陽 (Sun) 0° 57' 12.9'' -0° 01' 55.4''
火星 (Mars) 0° 38' 12.3'' 0° 06' 45.6''
木星 (Jupiter) 0° 13' 01.8'' 0° 08' 02.5''
土星 (Saturn) 0° 07' 02.0'' 0° 05' 01.4''

3. 惑星の動作状態:順行・逆行・留 (Motion States)

惑星は常に一方向に移動しているわけではない。地球からの観測視点(ローカル座標系)において、惑星はしばしば見かけの速度を変更し、動作状態を遷移させる。

占星術用語 状態 (State) 機能的影響 (Functional Impact)
順行 (Direct) Nominal Operation 機能がサインの意図通りに外部へ効率的に出力される標準状態。
逆行 (Retrograde) Internal Processing / Debug Mode 速度が低下し、機能の出力が一時的に内部へ向けられる状態。外部への作用が弱まり、過去のデータ(リソース、プロセス)の再評価が優先される。
留 (Station) State Transition / System Freeze 順行⇔逆行への切り替わり点。速度がゼロに近く、システム全体が一時的に静止し、処理の不安定化(エラー)が発生しやすいクリティカルな状態。

4. 隠れた接続ロジック

通常のアスペクト(視線)以外にも、システムには隠された接続回路が存在する。

アンティシア(Antiscia)

  • 定義:夏至・冬至軸(蟹座0度-山羊座0度)を基準とした対称点。
  • システム上の意味:「ミラーリング接続」*あるいは*「バックドア(Backdoor)」。
  • アスペクトとしては認識されないが、影(Shadow)を通じて密かに接続されている。表向きのログには残らない、隠れたデータ共有ルートである。

恒星との接触(Fixed Stars)

  • 定義:黄道帯の特定の座標に固定された恒星(特にヘルメス恒星 / Behenian Stars)と惑星が重なること。
  • システム上の意味:「外部定数(External Constants)」。
  • 惑星システムの外側から埋め込まれた、固定的なパラメータである。これに接触した惑星は、自身の本来の機能を上書き(Override)され、恒星固有の強力なバフ(強化)またはデバフ(弱体化)を与えられる。

[Reference] ヘルメス恒星(The 15 Behenian Stars)

中世のアルゴリズムにおいて、特に重視された15の恒星群。これらは強い「魔術的/干渉的」な権限を持つ**固定アドレス(Fixed Address)**として扱われる。
惑星がこの座標(オーブ約1度以内)に接触した際、本来の機能はこれらの性質によって上書き(Override)、またはブーストされる。

星名 (Star Name) 属性 (Nature) システム的挙動 (System Behavior)
Algol (アルゴル) 土星 / 木星 [Critical Error] 最も凶暴なエネルギー。切断、強制的終了。
Pleiades (プレアデス) 月 / 火星 [Cluster] 集合的なノイズ、または多面的な洞察。
Aldebaran (アルデバラン) 火星 [Royal Star: East] 開始、誠実さ、名誉ある地位。
Capella (カペラ) 火星 / 水星 鋭敏な知性、好奇心、移動への衝動。
Sirius (シリウス) 木星 / 火星 [High Voltage] 全天一の輝度。熱狂的な名声と、焼き尽くす情熱。
Procyon (プロキオン) 水星 / 火星 短期的な成功、素早い反応、機会主義的な動作。
Regulus (レグルス) 火星 / 木星 [Royal Star: North] 支配権、成功。ただし復讐による失脚リスクを含む。
Alkaid (アルカイド) 金星 / 月 自然との接続、または受動的な犠牲。
Algorab (アルゴラブ) 土星 / 火星 破壊的な清掃、スカベンジャー(掃除屋)の機能。
Spica (スピカ) 金星 / 水星 [Protection] 卓越した才能、保護された成功、非戦闘的な勝利。
Arcturus (アークトゥルス) 火星 / 木星 守護者、新たな道の開拓、冒険的なリーダーシップ。
Alphecca (アルフェッカ) 金星 / 火星 宝冠。芸術的な栄光、または受動的な名誉。
Antares (アンタレス) 火星 / 木星 [Royal Star: West] 極限の戦略、執念、死と再生のサイクル。
Vega (ベガ) 金星 / 水星 圧倒的なカリスマ、魅了、芸術的な魔力。
Deneb Algedi (デネブ・アルゲディ) 土星 / 木星 司法的な知恵、建設的な指導者、法と秩序の守護。

注:属性(Nature)は、その恒星がどの惑星の周波数に近いかを示す。例として「火星/木星」の星は、火星と木星のコンジャンクションと同様の出力を発生させる。システム的挙動は利用条件によって変化するため、参考に留めるべきである。

5. 月のボイド(Void of Course)

  • 定義:月が現在のサインを脱出するまでの間、他のどの惑星ともメジャー・アスペクトを作らない期間。
  • システム上の意味:「ヌルポインタ(Null Pointer)」*あるいは*「アイドル状態(Idle State)」。
  • 月(イベントの伝達者)が接続先を見失っている状態。この期間に開始されたイベントは、参照先がないため結実しない(処理が完了しない)。システム上「無効」な時間帯として定義される。

6. ノード(The Nodes):増幅と減衰のインターフェース

  • 定義:太陽の軌道(黄道)と月の軌道(白道)が交差する2つのポイント。日食・月食が発生するシステム上の特異点。
  • ノースノード(North Node / ドラゴンヘッド)
    • システム上の意味:「増幅器(Amplifier)」*または*「貪欲な入力(Greedy Input)」。
    • ここで接触した変数の出力係数を強制的に増大させる。木星的な膨張作用を持つが、品質は問わず、ノイズも含めて無差別に増幅する。
  • サウスノード(South Node / ドラゴンテイル)
    • システム上の意味:「減衰器(Attenuator)」*または*「排出ポート(Exhaust Port)」。
    • ここで接触した変数の出力を減少させる。または、物質的な結合を解除し、リソースを非物質的・内面的な領域へと解放(Release)する。土星的な制限・分離作用を持つ。

5.3 [Column] 因果律と相関関係

システム工学としての占星術を解析する際、多くのエンジニアが抱く疑問がある。 「なぜ、遠く離れた惑星の位置が、地上の事象に影響を与えるのか?」 「重力波か、電磁波か、あるいは未知の物理的エネルギーによるものか?」

結論から言えば、本アルゴリズムは**「物理的因果律(Causality)」ではなく、「相関関係(Correlation)」**の記述を目的とした体系である。

時計のメタファー

この関係性は、**「時計」と「時間」**の関係に例えられる。

  • 正午になると、時計の針は「12時」を指し、同時に街の工場でサイレンが鳴り、人々が昼食をとる。
  • しかし、時計の針が重なって「12時」を指したことが原因で、サイレンが鳴ったわけではない。
  • 時計の針から未知のビームが放射され、人々の空腹中枢を刺激したわけでもない。

時計は、時間を支配しているのではなく、時間という不可視のサイクルを可視化するための**「計器(Gauge)」**に過ぎない。 占星術における惑星も同様である。土星が人間に試練を与えているのではなく、太陽系のサイクルと、地上の事象が「同期(Synchronization)」して動いている現象を、惑星という針を用いて計測しているものと本稿では解釈する。

科学者たちの視点:統計と幾何学

心理学的なアプローチだけでなく、ハードサイエンスの分野からも、このシステムに対する工学的な解釈が提示されている。

A. 糸川英夫(ロケット工学者)の視点:仮説と検証

日本の宇宙開発の父であり、ペンシルロケットを開発した工学博士・糸川英夫は、東京大学退官後の50代後半から占星術の研究に取り組んだ。 彼は占星術を、頭ごなしにオカルトとして否定するのではなく、**「仮説と検証(Hypothesis and Verification)」というエンジニアリングの基本動作を用いてアプローチした。 彼は、惑星間の角度(アスペクト)と個人の経歴データなどを照合し、「メカニズムが物理的に解明されていなくても、そこに有意な相関(Significant Correlation)**が観測されるならば、それは科学的な研究対象となり得る」という姿勢を貫いた。

B. ヨハネス・ケプラー(天体物理学者)の視点:幾何学的共鳴

近代天文学の父ケプラーもまた、惑星から神秘的な力が放射されているという説を否定した。 代わりに彼が提唱したのは**「幾何学的共鳴(Geometrical Resonance)」である。 彼は、「地球(Earth)というシステムそのものが、天体の形成する幾何学的角度(アスペクト)に感応し、共振しているに過ぎない」と定義した。これは現代の「振動工学」**に近い解釈であり、惑星はエネルギーの発信源ではなく、共振を引き起こす周波数発生装置として扱われる。

第5章まとめ:動的システムの複雑性

本章までで、占星術アルゴリズムの主要なコンポーネントが出揃った。

  1. 静的パラメータ(スペック):惑星、サイン、ハウス、アスペクト(第1章〜第4章)。これらはシステムの基本仕様を定義する。
  2. 動的パラメータ(コンテキスト):太陽位相、セクト、速度、特殊な幾何学(第5章)。これらは、その時々の状況に応じて変化する変数の状態を定義する。

この第5章で導入した「高度な条件分岐」は、システムに**「複雑性」と「奥行き」**を与える。

  • 「最強の配置にあるはずの惑星が、コンバスト(熱暴走)によって機能不全に陥っている」
  • 「アスペクトがなく接続不能に見える場所が、アンティシア(バックドア)によって密かにリンクされている」

このような**「仕様の隙間」や「例外処理」**こそが、単純な機械的モデルでは記述しきれない、人間の運命や性格の多面性をシミュレートするために不可欠な機能となる。 次章からは、これらのアルゴリズムを統合し、実際にチャートを解読(デコード)するための実践的な手順へ移行する。


第6章 結論:記述言語としての出力

本稿では、古典占星術という古代の体系を、現代のシステム工学的な視点から再構築してきた。 最終章となる本章では、これまで定義してきた各コンポーネントを統合し、実際にどのように出力(事象の記述)が生成されるのか、その全体像を総括する。

6.1 多変量解析の統合(Synthesis)

占星術によるチャート解読は、複数の変数が絡み合う**「多変量解析(Multivariate Analysis)」**である。 その基本ロジックは、以下の計算式のようなメタファーで表現できる。

基本出力の計算式

Output = (Variable Function × Essential Dignity) × Accidental Dignity

  1. 変数の機能(Variable Function / What)
    • 「何をするか」。
    • 例:火星=「切断する」「加熱する」「戦う」。
    • これは関数の基本仕様である。
  2. エッセンシャル・ディグニティ(Essential Dignity / How much quality)
    • 「どれだけ純粋に、高品質に行うか」。
    • 例:山羊座の火星(エグザルテーション)= +4(非常に効率的で、制御された切断)。
    • 変数の「質」を決定する係数である。
  3. アクシデンタル・ディグニティ(Accidental Dignity / Where & Volume)
    • 「どこで、どれだけの量を出力するか」。
    • 例:第10ハウス(MC)= × 100%(社会的な領域で、フルパワーで出力)。
    • 変数の「量」と「活動場所」を決定する係数である。

動的係数による補正

この基本出力に対して、さらに以下の動的係数が掛かる。

  • アスペクト(Connection):他の変数との通信回線。トラインならスムーズに、スクエアなら摩擦を伴って接続される。
  • 動的条件(Dynamics):太陽位相(可視性)や速度(パフォーマンス)。コンバストなら出力はゼロに近づき、逆行なら処理が遅延する。

これら全てのパラメータを統合した結果として、運勢や性質という複雑な出力が生成される。

6.2 構造解析ツールとしての未来

本稿が提示するのは、魔法の方法論ではない。 現在の個体(Individual)や環境を客観的に記述するための、**「現状分析(Debugging)のための言語」**である。

仕様(Spec)としての認識

個体が持つ特性や制約事項を、初期設定された**「システム仕様(System Specifications)」**として認識すること。 これが本アルゴリズムの主たる用途である。

  • 行動の遅延は、個人の欠陥ではなく**「土星によるレイテンシ設定」**として記述される。
  • 種々のトラブルは、不運ではなく**「アスペクトによる信号干渉」**として記述される。

これらに感情的な良し悪しはなく、**「動作条件(Operating Conditions)」**の確認作業となる。 システムがどのような仕様で設計されているかを知ることは、その運用における予期せぬエラーを減らし、リソース配分を最適化するための基礎データとなる。

結び:レガシーシステムの可読化

本システムは、古代人が世界を記述するために構築した、巨大な**「レガシーシステム(Legacy System)」**である。 その中身は、一定の規則性と整合性の取れたアルゴリズムで動作している。

本稿の目的は、長らくブラックボックス化していたこの古代のアルゴリズムを、現代のエンジニアリング言語を用いて**「可読化(Readability)」**することにあった。 ソースコードは開示された。この記述言語をどのように扱い、何に応用するかは、完全に読み手の任意である。


第7章 アルゴリズムの実装(Implementation)

本稿で解説してきたアルゴリズムは、コンピュータ上で動作する論理的な仕様書として機能する。 本章では、PythonおよびJavaScriptを用いて、これらの理論を実際にコードとして実装するためのガイドラインを提供する。

7.1 理論から実装へ

第1章から第6章までで定義した「変数」「定数」「関数」は、そのままプログラミング言語のオブジェクトやメソッドにマッピング可能である。

  • 惑星:Planet クラス(属性:黄経、黄緯、速度)
  • サイン:Sign クラス(属性:エレメント、モダリティ、支配星)
  • アスペクト:check_aspect(planet_a, planet_b) 関数

エンジニアである読者にとって、この実装プロセスこそが、占星術というシステムの構造を最も深く理解するための近道となるだろう。

7.2 推奨ライブラリ:計算エンジン

車輪の再発明を避けるため、天体位置計算には信頼性の高いライブラリを使用すべきである。

1. pyswisseph (Swiss Ephemeris)

  • 概要:NASA/JPLのデータに基づく、世界で最も高精度なC言語ライブラリ「Swiss Ephemeris」のPythonラッパー。
  • 特徴:プロユースのバックエンドとして事実上の標準(De Facto Standard)。計算速度と精度が極めて高い。
  • 用途:本格的なアプリケーション開発向け。

2. Skyfield

  • 概要:現代的で美しいAPIを持つ、純Pythonの天文学ライブラリ。
  • 特徴:NumPyに依存しており、ベクトル演算が得意。コードの可読性が高い。
  • 用途:データ分析、科学的な天体計算向け。

3. Flatlib

  • 概要:本稿のテーマである「古典占星術」の計算に特化したライブラリ。
  • 特徴:ドミサイル、エグザルテーション、ハウスシステムなどの古典的アルゴリズムが組み込み済み。
  • 用途:占星術ロジックの学習、プロトタイピング向け。

7.3 実装チュートリアル:惑星位置計算システム (Python)

ここでは、業界標準である pyswisseph を使用して、ホロスコープの基本データを計算し、可視化するまでの完全なスクリプトを提示する。

依存ライブラリのインストール

pip install pyswisseph matplotlib numpy

Python実装コード

"""
占星術計算システム - 技術実装ガイド
Swiss Ephemeris APIを用いた惑星位置計算とチャート可視化

実装仕様:
- julday: 4引数版(year, month, day, hour)を標準とする
- バージョン取得: 複数の属性名に対応し環境差異を吸収
- 座標系: 熱帯黄道(Tropical Zodiac)
- 時刻: UTC基準(ローカル時のまま渡さないこと)
"""

import matplotlib.pyplot as plt
import numpy as np
from datetime import datetime
import json
import warnings

# === Swiss Ephemerisのインポート ===
try:
    import swisseph as swe
    # バージョン属性名の揺らぎを吸収
    EPHE_VERSION = getattr(swe, "version",
                           getattr(swe, "__version__", "unknown"))
except ImportError as e:
    print("Error: pyswisseph not installed")
    print("Install with: pip install pyswisseph")
    raise e

# エフェメリスファイルのパス設定(必要な場合)
# swe.set_ephe_path("/usr/share/ephe")


def get_planet_positions(year, month, day, hour_utc=12.0):
    """
    惑星の黄経を計算する(熱帯黄道)

    Args:
        year (int): 年(1800〜2400推奨)
        month (int): 月(1–12)
        day (int): 日(1–31)
        hour_utc (float): UTC時刻(0.0–24.0)
                          ※ ローカル時をそのまま渡すと誤差が出るため注意

    Returns:
        dict: {惑星名: 黄経度数(float)}
    """
    if not (1800 <= year <= 2400):
        warnings.warn(
            f"Year {year} is outside recommended range (1800–2400).",
            UserWarning
        )

    # ユリウス日の計算(標準的な4引数版を使用)
    jd = swe.julday(year, month, day, hour_utc)

    planets = [
        'Sun', 'Moon', 'Mercury', 'Venus', 'Mars',
        'Jupiter', 'Saturn', 'Uranus', 'Neptune', 'Pluto'
    ]
    planet_ids = [
        swe.SUN, swe.MOON, swe.MERCURY, swe.VENUS, swe.MARS,
        swe.JUPITER, swe.SATURN, swe.URANUS, swe.NEPTUNE, swe.PLUTO
    ]

    positions = {}
    for name, pid in zip(planets, planet_ids):
        try:
            # 黄道座標フラグ + スピード計算フラグ
            xx, _ = swe.calc_ut(jd, pid, swe.FLG_SWIEPH | swe.FLG_SPEED)
            positions[name] = xx[0]
        except Exception:
            # 高精度データがない場合はモシエ暦(簡易版)で計算
            xx, _ = swe.calc_ut(jd, pid, swe.FLG_MOSEPH)
            positions[name] = xx[0]
            print(f"Note: {name} calculated using Moshier ephemeris")

    return positions


def format_zodiac(deg):
    """
    黄経をサイン表記(Aries 15.23°)に変換する
    """
    signs = [
        "Aries", "Taurus", "Gemini", "Cancer", "Leo", "Virgo",
        "Libra", "Scorpio", "Sagittarius", "Capricorn", "Aquarius", "Pisces"
    ]
    sign_idx = int(deg // 30) % 12
    deg_in_sign = deg % 30
    return f"{signs[sign_idx]} {deg_in_sign:05.2f}°"


def check_aspects(positions):
    """
    メジャーアスペクトを検出する
    """
    aspects = []
    aspect_defs = {
        'Conjunction': (0, 10),
        'Sextile': (60, 6),
        'Square': (90, 8),
        'Trine': (120, 8),
        'Opposition': (180, 10)
    }

    names = list(positions.keys())

    for i in range(len(names)):
        for j in range(i + 1, len(names)):
            p1, p2 = names[i], names[j]
            diff = abs(positions[p1] - positions[p2])
            # 円環上の最短距離を計算
            diff = min(diff, 360 - diff)

            for asp, (angle, orb) in aspect_defs.items():
                if abs(diff - angle) <= orb:
                    aspects.append(
                        f"{p1} {asp} {p2} (angle: {diff:.2f}°, orb: ±{orb}°)"
                    )

    return aspects if aspects else ["No major aspects within defined orbs"]


def plot_chart(positions, title="", chart_style='western'):
    """
    極座標ホロスコープチャートを描画する
    """
    fig = plt.figure(figsize=(11, 11))
    ax = fig.add_subplot(111, projection='polar')

    if chart_style == 'western':
        # 西洋占星術標準:左(West/Ascendant)を0度とし、反時計回り(CCW)に進むのが標準
        ax.set_theta_zero_location('W')
        ax.set_theta_direction(1)
        style_desc = "Western (0° at West, counter-clockwise)"
    elif chart_style == 'eastern':
        ax.set_theta_zero_location('E')
        ax.set_theta_direction(1)
        style_desc = "Eastern (0° at East, counter-clockwise)"
    else:
        # 北欧式など:上が0度
        ax.set_theta_zero_location('N')
        ax.set_theta_direction(-1)
        style_desc = "Nordic (0° at North, clockwise)"

    colors = {
        'Sun': '#FDB813', 'Moon': '#C0C0C0', 'Mercury': '#00AEEF',
        'Venus': '#FF69B4', 'Mars': '#E74C3C', 'Jupiter': '#F39C12',
        'Saturn': '#8B7355', 'Uranus': '#7FFFD4', 'Neptune': '#ADD8E6',
        'Pluto': '#DDA0DD'
    }

    for planet, lon in positions.items():
        rad = np.deg2rad(lon)
        ax.plot(rad, 1, 'o', markersize=16,
                color=colors.get(planet, 'black'),
                markeredgecolor='black', markeredgewidth=1.5)
        ax.text(rad, 1.25, planet, ha='center', va='center',
                fontsize=11, fontweight='bold')

    # サイン境界のグリッド描画
    ax.set_xticks(np.deg2rad(range(0, 360, 30)))
    ax.set_xticklabels(['♈','♉','♊','♋','♌','♍',
                        '♎','♏','♐','♑','♒','♓'], fontsize=18)
    ax.set_yticks([])
    ax.grid(True, alpha=0.3)

    plt.title(f"Horoscope Chart ({style_desc})\n{title}",
              fontsize=16, pad=30, fontweight='bold')
    plt.tight_layout()
    plt.show()


def export_chart_data(positions, aspects, filename="chart_data.json"):
    """
    計算結果をJSONとして出力する
    """
    data = {
        "calculation_date": datetime.utcnow().isoformat() + "Z",
        "positions": {p: round(lon, 4) for p, lon in positions.items()},
        "aspects": aspects,
        "metadata": {
            "ephemeris": "Swiss Ephemeris",
            "version": EPHE_VERSION,
            "coordinate_system": "Tropical Zodiac"
        }
    }

    with open(filename, 'w', encoding='utf-8') as f:
        json.dump(data, f, ensure_ascii=False, indent=2)

    print(f"Data exported: {filename}")


# =========================================================
#                    メイン実行ブロック
# =========================================================
if __name__ == "__main__":
    print("=" * 70)
    print("  Astrological Chart Calculation System")
    print(f"  Swiss Ephemeris version: {EPHE_VERSION}")
    print("=" * 70)

    # テスト用日時:2025年1月1日 12:00 UTC
    year, month, day, hour = 2025, 1, 1, 12.0
    date_str = f"{year}-{month:02d}-{day:02d} {hour:05.2f} UTC"

    try:
        print(f"\nCalculation Date: {date_str}")
        print("Note: Hour must be in UTC\n")

        # 1. 座標計算
        pos = get_planet_positions(year, month, day, hour)

        print("--- Planetary Positions ---")
        for planet, lon in pos.items():
            print(f"{planet:8}: {lon:7.3f}° → {format_zodiac(lon)}")

        # 2. アスペクト判定
        print("\n--- Major Aspects ---")
        aspects = check_aspects(pos)
        for a in aspects:
            print(f"  {a}")

        # 3. チャート描画
        print("\nGenerating chart visualization...")
        plot_chart(pos, date_str, chart_style='western')

        # 4. データエクスポート
        export_chart_data(pos, aspects,
                          f"horoscope_{year}{month:02d}{day:02d}.json")

        print("\n" + "=" * 70)
        print("  Calculation completed successfully")
        print("=" * 70)

    except Exception as e:
        print(f"\nError: {e}")
        print("\nTroubleshooting:")
        print("1. Check pyswisseph installation")
        print("2. Use correct UTC time")
        print("3. Confirm year range (1800–2400 recommended)")

7.4 JavaScript実装例(参考)

Webフロントエンド開発向けに、2つのアプローチを提示する。 用途(学習用か、プロユースか)に応じて使い分けることが推奨される。

A. 軽量・学習用:astronomy-engine

依存関係がなく、導入が容易。占星術の学習や軽量なWebアプリに適している。 最新版では ECT (True Ecliptic of Date) により、Tropical Zodiac(回帰黄道)の近似値を取得可能である。デモ版はサーバで実行可能。指定した年月日(2025-1-1 12:00 UTC)の火星黄経度数を世界標準時で返す。

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <title>Astronomy Engine Demo</title>
</head>
<body>
  <pre id="output">Loading...</pre>
  <script src="https://cdn.jsdelivr.net/npm/astronomy-engine@2.1.19/astronomy.browser.min.js"></script>
  <script>
    const date = new Date("2025-01-01T12:00:00Z");
    const lon = Astronomy.EclipticLongitude("Mars", date);  // グローバルAstronomy, 同期関数

    function degreesToZodiac(deg) {
      const signs = ["Aries", "Taurus", "Gemini", "Cancer", "Leo", "Virgo",
                     "Libra", "Scorpio", "Sagittarius", "Capricorn", "Aquarius", "Pisces"];
      const signIndex = Math.floor(deg / 30) % 12;
      const degInSign = deg % 30;
      return `${signs[signIndex]} ${degInSign.toFixed(2)}°`;
    }

    const output = `Mars Ecliptic Longitude: ${lon.toFixed(4)}°\nSign: ${degreesToZodiac(lon)}`;
    document.getElementById('output').textContent = output;
    console.log(output);
  </script>
</body>
</html>

B. 高精度・本番用:swisseph-wasm

Python版(pyswisseph)と完全に同等の精度(NASA JPL DE431準拠)が必要な場合は、こちらを使用する。 WebAssembly (WASM) で動作するため、ブラウザ上でC言語レベルの演算が可能となる。デモ版はローカルサーバで実行可能。指定した年月日の火星黄経度数を世界標準時(UTC)で返す。

<!-- ブラウザで即実行可能なサンプル (CDN利用) -->
<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <title>sweph-wasm ローカルサーバ版</title>
  <style>
    body { font-family: monospace; padding: 20px; background: #000; color: #0f0; }
    pre { background: #111; padding: 10px; border: 1px solid #333; white-space: pre-wrap; }
  </style>
</head>
<body>
  <h1>sweph-wasm ブラウザ即実行(ローカルサーバー版)</h1>
  <p>ローカルサーバ (python -m http.server) で開いてください。file://直開きはCORSエラーです。</p>
  <pre id="output">初期化中... (エフェファイルロード中)</pre>

  <script type="module">
    // 正しいCDNパス (v0.0.2, npmドキュメント準拠 – 存在確認済み)
    import SwissEPH from 'https://cdn.jsdelivr.net/npm/sweph-wasm@2.6.9/dist/index.js';

    (async function() {  // ES5 IIFE for Safari compatibility
      try {
        // 初期化(WASMロード)
        const swe = await SwissEPH.init();

        // CORS/404回避: デフォルトCDN使用(ローカルサーバーでfetch許可)
        await swe.swe_set_ephe_path();  // 空でデフォルトCDN (https://www.astro.com/ftp/swisseph/ephe/)

        // 2025-01-01 12:00 UTC → Julian Day (Gregorian=1)
        const jd = swe.swe_julday(2025, 1, 1, 12.0, 1);

        // 火星のTropical黄経(フラグ0 = Tropical, SEFLG_SWIEPH=2で高精度)
        const result = swe.swe_calc_ut(jd, swe.SE_MARS, swe.SEFLG_SWIEPH);
        const lon = result[0];

        // サイン変換(ES5関数定義)
        function degToZodiac(deg) {
          var signs = ["Aries", "Taurus", "Gemini", "Cancer", "Leo", "Virgo",
                       "Libra", "Scorpio", "Sagittarius", "Capricorn", "Aquarius", "Pisces"];
          var signIndex = Math.floor(deg / 30) % 12;
          var degInSign = deg % 30;
          return signs[signIndex] + " " + degInSign.toFixed(2) + "°";
        }

        var output = "Mars High-Precision Longitude: " + lon.toFixed(5) + "°\n" +
                     "Sign: " + degToZodiac(lon) + "\n" +
                     "Status: エフェファイルロード成功 (ローカルサーバー効果)";
        
        document.getElementById('output').textContent = output;
        console.log(output);
      } catch (e) {
        var errorMsg = "Error: " + (e.message || e) + "\n" +
                       "Troubleshoot: Use local server (python -m http.server) and retry. Moshier fallback: swe.SEFLG_MOSEPH";
        document.getElementById('output').textContent = errorMsg;
        console.error(errorMsg);
      }
    })();
  </script>
</body>
</html>

展開オプション

本稿で実装したコードは、さらなるアプリケーション開発の基礎となる。 読者のエンジニアリングスキルに応じて、以下のような拡張が可能である。

  1. StreamlitによるWebアプリ化: streamlit ライブラリを使用すれば、数十行の追加コードでブラウザ上で動作するGUIアプリ(日付入力、チャート表示)を構築できる。
  2. FastAPIによるマイクロサービス化: 計算ロジックをAPIエンドポイントとして切り出し、他のシステムから利用可能な「Horoscope API」としてデプロイする。
  3. OSSとしての公開: GitHub上でリポジトリを公開し、世界中の開発者と共同でアルゴリズムの精度向上や機能拡張(ハウスシステムの実装など)を行う。

占星術のシステムは、まだ完成されたものではない。現代のエンジニアの手によって、さらなる「デバッグ」と「アップデート」が待たれている。


7.5 検証環境とリファレンス実装

自作したアルゴリズムの出力結果(正解データ)を検証するために、信頼できる既存のオープンソース・ソフトウェアやWebサービスを紹介する。これらは「答え合わせ」のためのリファレンス実装として機能する。

オープンソース・ソフトウェア (OSS)

1. Astrolog

  • 概要: 1991年から開発が続く、C++製の伝説的な占星術ソフト。
  • 特徴: コマンドライン(CLI)操作が可能で、UNIX哲学に近い設計。ソースコードが公開されており、計算ロジックの参照元として極めて優秀。
  • 用途: アルゴリズムの挙動確認、バッチ処理的なチャート生成。

2. Morinus

  • 概要: Python/wxPythonで書かれた、伝統的占星術(Traditional Astrology)に特化したソフトウェア。
  • 特徴: 本稿で解説した「プライマリー・モーション」や「中世の技法」を網羅している。Pythonプログラマにとって、GUI実装やロジックの参考になる。
  • 用途: 伝統的技法(Term, Face, Fixed Stars)の計算結果検証。

Webサービス (Online Tools)

1. Astro-Seek (astro-seek.com)

  • 概要: 現在、世界で最も利用されている占星術計算サイト。
  • 特徴: 膨大な種類の計算オプション(ドミサイル、恒星、各種ハウスシステム)を網羅しており、計算精度もSwiss Ephemeris準拠で高い。
  • 用途: 開発したコードの出力結果と比較し、バグがないかテストするための「正解データ」として利用する。

7.6 技術用語集(Technical Glossary)

本稿で使用される占星術用語を、エンジニアリング/物理学の定義に翻訳し、本稿の仕様における意味を明確にする。

用語(Term) エンジニアリング/物理的定義 (Definition) 解説 (Note)
ホロスコープ (Horoscope) 多次元極座標グラフ 時間と空間を入力とし、変数の配置と関係性をプロットしたシステム全体の設計図(スナップショット)。
惑星 (Planet) 独立変数 / 機能モジュール システム内で特定の周波数帯域を担当し、固有の機能を実行するエージェント(関数)。神ではない。
サイン (Sign) 環境変数 / アドレス空間 全天を12分割したメモリアドレス。温度(Hot/Cold)と湿度(Dry/Moist)のパラメータを持つ。
ハウス (House) ローカル座標 / 出力ポート 観測地点の日周運動によって生成される実行コンテキスト。変数の出力先(人生の分野)を決定する。
アスペクト (Aspect) 幾何学的接続 / 通信プロトコル 変数間で信号(光)を送受信するための角度条件。特定の角度(正多角形の頂点)でのみ通信が確立する。
ディグニティ (Dignity) 権限レベル / 適合度スコア 変数がその環境(サイン)において、どれだけのリソースアクセス権(Root/User/Guest)を持つかの指標。
アセンダント (ASC) システム入力端子 (Input) 東の地平線と黄道の交点。外部データがシステム内に取り込まれる最初のインターフェース。
MC (Medium Coeli) 最大出力点 (Max Output) 子午線と黄道の交点。変数の可視性と出力係数が最大化されるポイント。
オーブ (Orb) 信号有効範囲 / 許容誤差 アスペクト(通信)が有効となる角度の範囲。通信の帯域幅(Bandwidth)に相当する。
逆行 (Retrograde) 内部処理 / デバッグモード 地球との相対速度差により、見かけ上の動きが反転する現象。処理の遅延や内部パラメータの見直しを意味するステータス。
留 (Station) 状態遷移 / システムフリーズ 順行⇔逆行への切り替わり点。速度がゼロに近づき、処理が不安定になるクリティカルな状態。
コンバスト (Combust) 熱暴走 / オーバーヒート 太陽(熱源)に接近しすぎたため、変数が正常な値を返せなくなっている機能不全(Malfunction)状態。
エフェメリス (Ephemeris) データベース / ルックアップテーブル 天体の位置情報が時系列で記録された数表。APIを通じてクエリを投げ、座標を取得する。
トランスサタニアン 拡張変数 / 外部機能モジュール 土星(可視限界)の外側に後から追加された変数。現代占星術の機能拡張(Feature Creep)として採用される。
カスプ (Cusp) 境界線 / ディビジョン・ポイント ハウスの境界。この線を惑星が通過することで、次のハウスのロジックが起動する。
セクト (Sect) 動作モード / ON/OFFスイッチ 太陽の地平線上下で切り替わるシステム全体の実行コンテキスト。惑星の機能に昼夜のモードを強制的に適用する。
アンティシア (Antiscia) データミラーリング / バックアップノード サインの夏至/冬至の線(蟹座/山羊座)を対称軸として鏡に映る位置。本体とは異なる隠されたデータノード。
トリプリシティ (Triplicity) グループ権限 / 3者協定 エレメント(火地風水)ごとに3つの惑星で共有される実行権限。システムの安定化に必要な合議制。

開発後記

1. 執筆の動機:仕様書の不在

本稿の執筆動機は、占星術という体系における**「仕様書」の不在**にある。

理数系や天文学の知識を持ちながら、占星術に対して「不透明なブラックボックス」という印象を抱き、その論理構造が見えないがゆえに忌避感を覚える層は確実に存在する。 著者自身、30年前に占星術と接触した際、同様の疑問に答える書籍が存在しないという事実に直面した。市場に流通する情報の多くは、占星術を肯定・信奉するための言説、あるいは情緒的な充足を求める層に向けたものであり、純粋にシステム的なロジックのみを解説した技術資料は皆無であった。

この「ロジックを知りたい」という需要と、供給される「感性的な情報」との間のギャップを埋めるためには、古代の科学者が用いたロジックのみを抽出し、概要理解のスタート地点とするためのガイドブックが必要であると判断した。本稿は、そうした層に対し、初期学習のコストを最適化し、構造理解への最短経路を提供するために執筆した。

1.5 採用ロジックのバイアスについて

本稿が参照する技法は、ヘレニズム期、アラビア期、ルネサンス期を通じて構築されたものであり、その選択には筆者の独自基準とバイアスが少なからず作用している。

特に、論理的な整合性の高さから、筆者はアラビア期のシステム開発者たちが残した方法論を採択する場合が多い。読者は本稿の記述を「唯一の古典的仕様」ではなく、**「筆者が最適化を選択した特定バージョンの実装マニュアル」**として捉える必要がある。

2. 現代占星術との互換性について

読者への注意喚起として、本稿で扱ったアルゴリズムと、現在広く流布している「現代占星術(Modern Astrology)」との間には、仕様上の互換性が低いことを明記しておく必要がある。

19世紀以降に再構築された現代の占星術は、普及の過程で多くの簡略化がなされた一方で、多数のブランチが新たに生まれている。本稿の核となる「7惑星の限定使用」「冷熱乾湿(エレメントの物理定義)」「日周運動(プライマリー・モーション)」「惑星の可視性」「厳密なディグニティ判定」といったロジックは、削ぎ落とされ、あるいは抽象化されてきた。 本稿が記述したのは、それら失われた(あるいは隠蔽された)古典伝統派のロジックであり、現代的な占星術の運用とは異なるレイヤーにあることを理解されたい。

3. デザイナー視点による構造解析

著者のバックグラウンドは、25年の企業向けデザイン開発にある。 Webサービス構築におけるシステムエンジニアやプログラマーとの協業を通じ、著者は**「最終出力(Output Image)の共有が、内部構造(Internal Structure)の構築を決定する」**という原則を学んだ。 サービスの主旨を明確化し、エンドユーザーに必要な出力をビジョンとして定義すること。それができて初めて、堅牢なシステム設計が可能となる。

本稿のアプローチは、このデザイン・エンジニアリングのプロセスを占星術に応用したものである。「ホロスコープ解釈」という最終出力を定義し、そこに至るプロセスを逆算的に分解することで、その背後にあるアルゴリズムを可視化(Visualization)することを試みた。

4. 結び

本稿は、占星術の運用(占いができるようになること)を目的としたものではない。あくまで構造とロジックを整理し、ブラックボックスを開示することを目的とした技術解説書である。 この構造理解が、読者が後に触れるかもしれないより深い伝統的技法の理解に寄与するならば、設計者としてそれに勝る喜びはない。

最後に、本稿はデザイナー視点による構造解説であり、厳密な数理・工学の専門家から見れば、記述に不足や曖昧さが残る箇所も多々あると推測される。 工学系、理数系の諸氏におかれては、それらのバグや仕様の不備について、忌憚のないご教示(Debugging)を賜りたく、ここにお願い申し上げる。

7
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?