5大古典原典に基づく四柱推命エンジンをVibe Codingで作りました
(1fate.ai)Steve Yeggeが『ソフトウェア・サバイバル 3.0』で語った「洞察の圧縮（Insight Compression）」――GitやKubernetesには数十年分の試行錯誤が圧縮されており、LLMでは容易に再現できない、という話があります。四柱推命学も似ているのではないか、という考えから出発しました。
LLMに四柱推命を任せると起きること
最近よくあるように、四柱推命のデータをLLMに入れると、それらしい結果は出てきます。問題は、その「もっともらしさ」と「正確さ」の乖離です。
GPT-5、GPT-4o、Claude、DeepSeek V3など複数のモデルに、structured outputとfew-shotを組み合わせてテストしました。すると、体系的な誤りのポイントがありました。従強格の命式に抑扶の論理だけを適用して、火を用神として導き出してしまう、といった具合です。原典の「触怒強神 大凶」という原則に反する判定を、プロンプトだけで完全に防ぐことはできませんでした。
そのほかにも、特定流派の解釈にアンカリングされて原文を歪めたり、悪い解釈を過度に美化したり、逆に不安感を増幅させたりする傾向もありました。ルール判定をLLMのパターンマッチングに任せるのは、算術を言語モデルにやらせるのと同種の問題でした。
ホジャクエンジン: ルールはコードで、説明だけLLMで
そこで、レイヤード構造を設計しました。
ホ（虎）— ルールエンジン。 命理学の計算ロジックをコードで実装します。5大古典原典（滴天髄・子平真詮・窮通宝鑑・三命通会・淵海子平）の分かれる解釈のうち、どれを基準にするかを領域ごとに確立し、その判定をコードに固定しました。
ジャク（鵲）— LLM説明レイヤー。 エンジンが計算した構造化データを自然言語で解きほぐす部分だけをLLMに任せます。
LLMが再現しにくかったのはコードではなく、数千年にわたって磨かれてきた判定基準のほうでした。
Vibe Codingの限界が来た地点
最初は順調でした。LLMは漢文原典の分析、流派の整理、天文計算コードの草案作成まで素早く手伝ってくれました。限界が来たのは、流派間でルールが衝突する地点でした。
たとえば格局判定では、滴天髄は日干の強弱を先に見て、子平真詮は月令透出を先に見ます。同じ命式でも、どの原典に従うかによって判定が逆転するケースが出てきましたが、この優先順位はLLMが決められる領域ではありませんでした。
結局、5大原典を直接確保して照合する必要がありました。一部には欠落本や判読不能な箇所もあり、複数の版本をクロス検証する工程を踏みました。調べてみると、国家事業として古典保存の努力がかなり進められており、LLMの助けなしには個人で担うのが難しい作業でした。Claude Max x20をほぼ3か月、上限いっぱい使いました。
興味深かったのは、原文を誤って移したケースの大半が人間（学者）側にあったことです。滴天髄の「旺者宜泄, 唯有情有力者可克」をどう読むかによって、アルゴリズムの分岐そのものが変わるのですが、LLMはむしろ複数の学者の翻訳と原文注釈をクロスチェックするのに有用でした。
時刻精度: 1分が判定を変える
命理学では、時刻が1分違うだけで核心的な判定が変わることがあります。子時と丑時の境界で時柱が変わると、格局判定そのものが変わります。
ホジャクエンジンは、NASA/JPLベースのFourier級数による均時差（±13秒精度）、IANA tzdataベースのグローバルDST判定、163,400件超の都市経度データベースを組み合わせています。韓国については、1908年以降の4回の標準経度変更と12年間のサマータイム履歴を反映しています。
朝鮮王朝の観象監の公式記録（書雲観志）に、現在のコードと同一の経度補正式を見つけたのは、個人的に印象深い経験でした。
検証状況
節気計算は韓国天文研究院（KASI）の公式データ2000–2050年区間と照合して100%一致しています。均時差はNASA/JPL Horizonsベースで±13秒精度を確保しました。神殺は正統十二神殺（三命通会ベース）を定めて万世暦と照合し100%一致、貴人殺・特殊殺は原典のクロス検証後に orthodox / disputed / reference の3段階に分類して適用しています。
技術スタック
エンジンは Python FastAPI + PostgreSQL + SQLAlchemy 2.0(async)、フロントは Next.js 15 + React 19 + TypeScript + Tailwind CSS です。AIは OpenRouter 経由のマルチモデル（GPT-4o、Claude、DeepSeek V3）を説明レイヤーにのみ使用します。デプロイは Fly.io（Blue-Green）+ Vercel、決済は Toss Payments + PayPal です。
現在、四柱推命分析30,000字超、年間分析20,000字超規模の構造化レポートを生成しており、出生データは暗号化して保存されます。
おわりに
命理学の予測有効性についてはさまざまな見方があります。このプロジェクトは、その論争よりも「もしこの体系を使うなら、その意図どおりに正確な基準で一貫して計算しよう」というエンジニアリング課題に集中しました。
始まりはVibe Codingで気軽にスタートしましたが、結局は5大原典の古書を分析し、NASA/JPLの均時差コードまで見ることになりました。Yeggeの表現を借りれば、このドメインに圧縮された洞察の密度は予想よりはるかに高かったのです。
技術的な質問やフィードバックを歓迎します。
3件のコメント
大運があまり良くないほうで少し悲しいですが……。命式は一般的には時・日・月・年の順なのに、このサービスは逆なので、少し混乱する面がありました。何か意図があるのでなければ、一般的な並びに変えてみてはいかがでしょうか？
ご指摘いただいた後、すぐに日時月年の正配列へ変更しました。別の作業をしていたため、公開対応をようやくまとめて行いました。ありがとうございます。
分析してみると、実際にも四柱推命にすでに関心をお持ちの方のほうが、コンテンツにより深く共感してくださり、サービスもより長く利用してくださるようでした。最初に「四柱推命を知らない方でも簡単に」という思いから配列を変えたのは、誤った判断でした。フィードバックのおかげで方向性を正すことができました。あらためて感謝申し上げます。
配列順のご指摘はおっしゃる通りです。最初は、四柱推命に慣れていない方でもご自身の生年月日時を直感的に確認できるよう、時間順（年-月-日-時）に配置していましたが、思ったより多くの方がすでに四柱推命の配列に慣れていらっしゃって、かえって混乱を招いてしまったようです。
古典原典でも時日月年が正配列ですので、変更を前向きに検討いたします。まさに必要なフィードバックでした。
フィードバックをお寄せいただき、ありがとうございます！
また、大運が厳しい時期とのことでしたが、命理では大運は大きな流れであり、その中に歳運の変化があります。難しい大運の中でも用神に出会う時は必ず来ますので、その時にぜひ機会をしっかりつかまれますよう願っています。