ゼロ幻覚の決定論的占術エンジンを設計する：Rust 状態機械と LLM 意味グラフのハイブリッド構成

利益開示：易数洞察 InsightApp と sns.style は同じ運営者が管理しています。本文のコード引用はすべて InsightApp バックエンドの commit `22cccf4` からのもので、ファイルパスを併記しています（リポジトリは非公開です）。独立したレビューではなく事例分析です。完全版は中国語版で、本稿は日本語の概要版です。

周易の卦や紫微斗数の命盤を大規模言語モデルに直接「出して解釈して」と頼むと、文章は自然でも、検算すると崩れることがよくあります。変爻を取り違える、主星が二つの宮に同時に現れる、化忌が盤上にない星に付く、といった誤りです。原因はモデルの賢さではなく、タスクの形にあります。命盤の算出は離散的な組合せ計算で、解釈は自然言語です。一つの確率的サンプラーに両方を任せるべきではありません。

本稿は、InsightApp の周易・紫微斗数エンジンで実際に稼働している設計を読み解きます。Rust の決定論的カーネルが命盤を計算して構造化 JSON の「事実グラフ」を出力し、LLM はそのグラフを言葉に変える役割だけを担います。タイトルの「ゼロ幻覚」は命盤の層についてのみ成り立ち、解釈の層には成り立ちません。

なぜ自己回帰生成は不変量を守れないのか

InsightApp では、命宮は `mod12(lunar_month + 1 - hour)`、身宮は `(lunar_month + 1 + hour) % 12`、五行局は 5×6 の納音表 `NA_YIN_JU` の参照で決まります（`backend/src/ziwei/calc.rs`）。この連鎖では「14 主星は 12 宮にそれぞれ一度だけ現れる」「各天干は禄・権・科・忌の四化にちょうど対応する」といった不変量を守る必要があります。トークンを逐次サンプリングするモデルには宮の配列がなく、途中結果を正確に再利用する仕組みもありません。なお、LLM 単独での誤り率は本稿では測定していません。これは構造的な議論であり、実測ではありません。

カーネルは事実、モデルは言語

周易では、乱数は銅銭を投げる一点（`backend/src/agent/hexagram.rs`）だけに閉じ込められています。各銅銭は 1/2 の確率で 2 か 3 なので、和が 6・7・8・9 になる確率は 1/8・3/8・3/8・1/8 です。各爻が変爻になる確率は 1/4、変爻の期待個数は 1.5、変爻なしの確率は約 17.8% と、コードから直接導けます。本卦と変卦は爻の並びから 64 卦表を引いて一意に決まり、引けなければ `EngineError` で停止します（fail-closed）。六十四卦の検索ページと六十四卦ガイドで関係を確かめられます。

紫微斗数の `full_chart`（`backend/src/ziwei/chart.rs`）は I/O も乱数もない純粋関数です。`ChartResult` の `patterns` と `feixing` はデシリアライズ時に破棄され、派生事実はサーバーだけが生成します。閏月の規則は、オープンソースの iztro と 505 件のランダム標本で突き合わせて差分ゼロになった後に追加された、とコードのコメントにあります。飛星四化の化忌チェーン（`backend/src/ziwei/feixing.rs`）は深さ 4 で打ち切り、同じ宮に戻れば `is_loop` を立てる有界のグラフ探索です。飛星四化のページで表示を確認できます。

「ゼロ幻覚」が止まる場所

コードを読むと、三つの穴があります。一つ目に、解釈 API はクライアントが送った盤面をそのまま prompt に入れ、サーバー側で再計算していません。二つ目に、流年の天干は `(year - 4) mod 10` の近似で、立春前後の一両日はずれるとコード自身が注記しています。三つ目に、生成後に解釈文と命盤を照合する検証がありません。真太陽時の補正もフロントエンドの TypeScript で行われ、Rust ではありません。

`backend/src/seo.rs` の `STARS_14` と `PALACES_12` からは 168 の「星曜入宮」ページが生成されます。例えば紫微星・命宮です。読み方の入門は紫微斗数命盤の読み方、その他の記事は InsightApp ブログにあります。