TL;DR

六曜(大安・仏滅…)の次に、AI SaaSで需要が伸びているのが暦注(一粒万倍日・天赦日・三隣亡など)の判定
ただし暦注は 六曜より計算が面倒。旧暦月日だけでなく、二十四節気の期間 と 日の干支(60周期) の掛け合わせで決まるものが多い
結果、暦注を自前実装すると「節気の境界日」「旧暦閏月」「干支の基準年」の3ヶ所でサイレント事故が起きる
結論は六曜と同じで、AIエージェント前提の日本暦API(例: Shirabe Calendar API)に丸投げするほうが、精度・保守・AI統合すべてで有利
本記事ではLLMが誤りやすい計算ロジックの要所を、実装者視点で整理する

この記事の対象読者

占い・冠婚葬祭・不動産・建築系のAI SaaSを作っているエンジニア
「一粒万倍日くらいCSVテーブルで済むだろう」と思っている人
ChatGPT / Claude / Gemini に暦注判定関数を書かせて、結果が正しいか自信がない人

暦注とは何か(六曜との違い)

六曜(大安・友引・先勝・先負・仏滅・赤口)は 旧暦の月と日 が決まれば一意に決まる。計算式は (旧暦月 + 旧暦日) mod 6 の1本だけで、判定ルールは小学生の算数レベルだ。

暦注(れきちゅう)は これとは別系統の吉凶ラベル群 で、日本の伝統暦では13種以上が使われる。代表的なものは次のとおり。

暦注	性質	頻度の目安	主な用途
一粒万倍日	吉	月5〜6日	開業・入籍・種まき
天赦日	吉	年5〜6回	万事大吉
大明日	吉	月5〜7日	建築・移転
母倉日	吉	月4〜8日	婚姻
天恩日	吉	5日連続が月1〜2回	結婚・開業
寅の日	吉	12日に1回	旅行・金運
巳の日	吉	12日に1回	金運
己巳の日	吉	60日に1回	金運(巳の日の上位)
甲子の日	吉	60日に1回	新規開始
不成就日	凶	月3〜4日	新規開始を避ける
三隣亡	凶	月2〜3日	建築のみの凶日
受死日	凶	月3日前後	慶事を避ける
十死日	凶	月2日前後	慶事を避ける

六曜と違うのは、暦注は単一の計算式で収まらない点だ。ものによって:

旧暦月日で決まるもの(不成就日・三隣亡・受死日・十死日・母倉日)
二十四節気の期間 × 日の十二支 で決まるもの(一粒万倍日)
季節 × 特定の日の干支 で決まるもの(天赦日)
日の干支だけで決まるもの(大明日・天恩日・甲子の日・寅の日・巳の日)

つまり、ひとつの関数で済むのは最後のカテゴリだけで、残りは旧暦変換か二十四節気の正確な算出が前提 になる。ここが落とし穴の本体だ。

一粒万倍日: 二十四節気の期間 × 日の十二支

LLMに一粒万倍日のロジックを聞くと、よく「旧暦月ごとの十二支テーブル」が返ってくる。これは 半分正しくて半分間違い で、実際の伝統暦は二十四節気を区切りに使う。

正しい判定テーブル

節気の期間(開始節気〜次の開始節気)	該当する日の十二支
立春〜啓蟄	丑・午
啓蟄〜清明(春分を含む)	酉・寅
清明〜立夏	子・卯
立夏〜芒種	卯・辰
芒種〜小暑(夏至を含む)	巳・午
小暑〜立秋	酉・午
立秋〜白露	子・未
白露〜寒露(秋分を含む)	卯・申
寒露〜立冬	酉・午
立冬〜大雪	酉・戌
大雪〜小寒(冬至を含む)	子・卯
小寒〜立春	子・未

判定ロジックは:

その日が属する 二十四節気の期間 を求める(立春 ≤ 日 < 啓蟄 のような判定)
その日の 十二支(子・丑・寅…)を求める(60干支サイクルの年・月ではなく日の干支)
2つがテーブルの行にマッチするなら一粒万倍日

LLMが間違いやすいポイント

「旧暦月」で切っていないか: 一部のWeb記事では旧暦月ベースで説明していることがあるが、月と節気は完全には一致しない(旧暦月の切替は新月、節気の切替は太陽黄経)。同じ日でも「3月扱い」か「清明扱い」かで結論が変わる
節気の境界日を前日側に含めていないか: 節気は「その日の○時○分○秒」で切り替わるため、日単位で判定する場合は JSTでの切替タイミング を正確に持つ必要がある
日の干支の基準がズレていないか: 60干支は1日ずつ進む。暦元(紀元前の甲子日)からの通日で計算するのが確実で、年をまたぐリセット処理を挟むと必ずバグる

天赦日: 季節 × 特定の日の干支(年5〜6回のみ)

天赦日(てんしゃにち / てんしゃび)は 暦注の中でもっとも縁起が良いとされる日 で、婚姻・開業・宝くじ購入などの候補日として頻繁に参照される。頻度が低いぶん希少性があり、AI SaaSで「今月の天赦日はいつ?」と聞かれる率が高い。

判定テーブル

季節(節気の範囲)	該当する日の干支
春: 立春〜立夏前日	戊寅(つちのえとら) の日
夏: 立夏〜立秋前日	甲午(きのえうま) の日
秋: 立秋〜立冬前日	戊申(つちのえさる) の日
冬: 立冬〜立春前日	甲子(きのえね) の日

判定ロジック:

その日の季節(立春・立夏・立秋・立冬ベースの4分割)を求める
その日の 60干支(十干 × 十二支) を求める
テーブルで(季節, 干支)がマッチするなら天赦日

なぜ年5〜6回しかないのか

各季節の長さは約91日
60干支の1つの干支は60日周期で1回出る
したがって「春(約91日)に戊寅が来る回数」は1〜2回、合計で 年4〜6回 に収まる
2026年の場合は4回、年によっては6回出ることもある

LLMが間違いやすいポイント

季節の定義が暦法で違う: 「春=3月〜5月」で判定するコードが返ってくることがあるが、伝統的には 立春起点。月ベースだと境界日に1〜15日のズレが出る
寅の日と戊寅を混同する: 寅の日は十二支のみ一致すればよいので12日周期(月2〜3回)。戊寅は十干+十二支が両方合う必要があり60日周期。頻度が桁違い
「天赦日=無条件で大吉」ではない: 不成就日や三隣亡と重なる日もあり、厳密な伝統暦では相殺判定が要る。AI回答として「天赦日だから何やってもOK」と言い切るのは危険

三隣亡: 旧暦月 × 日の十二支(建築限定の凶日)

三隣亡(さんりんぼう)は 建築関係に特化した凶日 で、「この日に建前・棟上げをすると三軒隣まで火災を及ぼす」と言われる。不動産・建築業界のAI SaaSだけがピンポイントでヒットする需要だが、外すと実害(建築遅延)が出るドメインなので正確性が求められる。

判定テーブル

旧暦月	該当する日の十二支
1月 / 4月 / 7月 / 10月	亥
2月 / 5月 / 8月 / 11月	寅
3月 / 6月 / 9月 / 12月	午

判定ロジック:

その日が属する 旧暦月 を求める(← ここが最大の落とし穴)
その日の 十二支 を求める(日の干支の下半分)
2つがテーブルの行にマッチすれば三隣亡

LLMが間違いやすいポイント

グレゴリオ暦の月を入れてしまう: 「1月・4月・7月・10月に亥の日」とそのままコードに落とすと、旧暦と西暦のズレで平均15〜30日分の判定が食い違う
閏月が入った年の処理漏れ: 旧暦の閏月(例: 閏4月)は通常の4月と同じ扱いにすることが多いが、流派によって違う。ライブラリによって結果が異なるため、どの天保暦の解釈を採るか を明記しておかないと後からバグる
「建築以外の用途に拡大解釈しない」: 三隣亡は建築限定の凶日。結婚式・引越しで避ける必要はないとするのが伝統的。AIが「三隣亡だから結婚式もNG」と答えると実害が出る

自前実装の落とし穴(まとめ)

ここまで見てきた3つの暦注だけで、次の3つの前提計算がすべて必要になる。

落とし穴1: 二十四節気の正確な日時が要る

二十四節気は太陽黄経が15度刻みになる瞬間で定義される。「立春 = 2月4日頃」のような固定表は年によって最大2日ズレ、閏年や100年単位のドリフトを無視すると長期的に崩れる。

正しい実装には 太陽黄経を天文学的精度で計算する 必要があり、これは VSOP87 や ELP2000 系の級数展開を使う。LLMに書かせると近似式の係数がどこか一桁雑で、節気の境界日だけピンポイントで誤判定 が出る。

落とし穴2: 旧暦変換(朔の計算)が要る

三隣亡・不成就日・母倉日・受死日・十死日は 旧暦月 を使う。旧暦月の境界は新月(朔)で、これも月の黄経を天文学的精度で求める必要がある。29.5日周期の近似や中国農暦ライブラリを流用すると、日本の天保暦と朔の基準時刻が違ってズレる。

前回記事(六曜の話)でも書いたが、この問題は暦注の計算でもそのまま乗ってくる。「旧暦月が正しく取れない」と、暦注のうち旧暦月を使うカテゴリが全部連鎖で誤る。

落とし穴3: 日の干支の通日計算

一粒万倍日・天赦日・大明日・天恩日は 日の干支(60周期) を使う。これは連続通日で計算するのが最もシンプルで、「ある基準日(例: 1900-01-31 = 甲子)からの経過日数 mod 60」で求められる。

LLM実装でやりがちなのは:

基準日を間違える: 流派によって基準日が違うことがあり、テーブルと1つズレると全日が1日分シフトする
日付のタイムゾーン処理を誤る: new Date() をUTCで扱うと、JSTの0時を跨ぐ日で干支が1日ズレる
基準日より前の日付で負数mod: JavaScriptの % 演算は負数に対して負を返すため、歴史日付の計算で暗黙にバグる

解決策: 日本暦APIに判定を任せる

ここまで見たとおり、暦注を正しく判定するには:

二十四節気の天文学的計算
朔の天文学的計算(旧暦変換用)
日の干支の通日計算

の3つを 全部同時に正しく実装する必要がある。これはLLMにコピペさせるにはドメイン知識の密度が高すぎる領域で、事業で使うなら日本暦に特化したAPIに委ねたほうが速い。

以下のサンプルは Shirabe Calendar API を使う。暦注13種+六曜+干支+二十四節気をまとめて返すため、1リクエストで判定が完結する。Free枠 月10,000回 で、APIキーなしでも試せる。

単日取得

curl https://shirabe.dev/api/v1/calendar/2026-04-21

返ってくるJSONの暦注部分の抜粋:

{
  "date": "2026-04-21",
  "rekichu": [
    { "name": "一粒万倍日", "reading": "いちりゅうまんばいび", "type": "吉" },
    { "name": "大明日", "reading": "だいみょうにち", "type": "吉" }
  ],
  "kanshi": { "day": { "name": "庚寅", "reading": "かのえとら" } },
  "lunar": { "year": 2026, "month": 3, "day": 5, "isLeap": false },
  "context": {
    "business": { "judgment": "吉", "score": 7,
      "note": "一粒万倍日。開業・事業開始に良い日。" }
  }
}

rekichu は配列で返るのがポイントで、複数の暦注が重なる日(一粒万倍日 × 天赦日 × 大明日など)も情報が落ちない。ランクを上げるのはAPI側の context.*.score に任せられる。

TypeScript

const res = await fetch(
  "https://shirabe.dev/api/v1/calendar/2026-04-21",
  { headers: { "X-API-Key": process.env.SHIRABE_API_KEY! } }
);
const data = await res.json();

const isIchiryumanbai = data.rekichu.some(
  (r: { name: string }) => r.name === "一粒万倍日"
);
console.log(isIchiryumanbai, data.lunar);  // true, { year: 2026, month: 3, day: 5, isLeap: false }

Python

import os, requests

r = requests.get(
    "https://shirabe.dev/api/v1/calendar/2026-04-21",
    headers={"X-API-Key": os.environ["SHIRABE_API_KEY"]},
    timeout=10,
)
data = r.json()
names = [x["name"] for x in data["rekichu"]]
print("一粒万倍日" in names)  # True
print("三隣亡" in names)      # False (今日は建築OK)

期間検索: 「次の天赦日はいつ?」系のクエリ

天赦日は年5〜6回しかないため、「今後3ヶ月以内の天赦日を全部教えて」というクエリがAI SaaSで頻発する。単日取得を365回叩くのは筋が悪いので、範囲取得エンドポイントを使う。

# 2026年の天赦日を全部取得
curl "https://shirabe.dev/api/v1/calendar/range?start=2026-01-01&end=2026-12-31&filter_rekichu=天赦日"

# 開業に最適な日を上位5件(一粒万倍日・天赦日・大明日・甲子の日が考慮される)
curl "https://shirabe.dev/api/v1/calendar/best-days?purpose=business&start=2026-04-01&end=2026-12-31&limit=5"

best-days は内部で 吉凶の複合判定 を行っていて、「天赦日 × 一粒万倍日 × 大安」のような最強日から順にランキング化される。LLMエージェントはこのランキングをそのままユーザー回答に使える。

AIエージェントへの統合

この手のAPIは、ChatGPT GPTs / Claude Tool Use / Gemini Function Calling / LangChain / Dify のいずれからでも一発で呼べる。Shirabeの場合は OpenAPI 3.1 仕様を https://shirabe.dev/openapi.yaml に置いてあり、各フレームワークがそのままインポートできる。

ChatGPT GPTs Actions

GPT Builder の "Create new action" で Import URL に:

https://shirabe.dev/openapi.yaml

を貼って、Authentication を API Key(ヘッダー名 X-API-Key)に設定するだけ。これで「今月の天赦日を教えて」「来月の建築凶日を避けたい」といった質問にカスタムGPTが自動で答えられるようになる。

Claude Desktop / MCP

claude_desktop_config.json:

{
  "mcpServers": {
    "shirabe-calendar": { "url": "https://shirabe.dev/mcp" }
  }
}

登録後、Claude に「来月の天赦日と、建築を避けるべき日を出して」と聞けば、裏で find_best_days と get_calendar が自動で呼ばれる。

LangChain / LlamaIndex / Dify

OpenAPI Loader に同じURLを食わせるだけでツール化される。operationId が関数名として自動マッピングされる設計のため、暦注判定を LangChain agent に組み込むのは数行で済む。

# LangChain (擬似コード)
from langchain_community.tools.openapi import OpenAPIToolkit
toolkit = OpenAPIToolkit.from_url("https://shirabe.dev/openapi.yaml")
tools = toolkit.get_tools()
# agent に tools を渡すだけで暦注判定が使えるようになる

自前実装 vs API の比較(暦注編)

観点	自前実装 / LLM生成コード	日本暦API(Shirabe等)
二十四節気の精度	固定表だと年1〜2日ズレ、天文計算は大仕事	天文学的精度
旧暦変換	近似式では朔境界で1日ズレる	天保暦ベースで実装済み
日の干支の通日	基準日・タイムゾーンでバグりやすい	API側で隠蔽
暦注の網羅性	13種を個別ロジックで実装	1リクエストで全部返る
重なり判定	自前で組合せを書く必要	`rekichu` 配列で自然に扱える
建築限定の三隣亡を誤解拡大	起きやすい	`context.*` で用途別スコアを返すため実害が出にくい
AI統合	自前で Tool定義 / Function定義を書く	OpenAPI 1URLで完了

六曜の時と同じ構造だが、暦注では 「複数判定の重なり」 と 「用途別の適用範囲」(三隣亡は建築のみ等) が追加で効いてくる。AIが誤答しても型エラーは出ないので、実装者側でドメイン知識として仕様を落とし込むコストが意外と高い。

まとめ

暦注は六曜より計算が複雑で、二十四節気・朔(旧暦)・日の干支の3つを同時に正しく求める必要がある
LLMに自前実装を書かせると、節気境界・閏月・干支基準日の3ヶ所で サイレント事故 が起きやすい
実害が出るドメイン(建築・冠婚葬祭・不動産)では、天文計算が済んでいるAPIに任せる ほうが開発もデバッグも速い
OpenAPIを公開しているAPIなら、ChatGPT GPTs / Claude Tool Use / Gemini Function Calling / LangChain / Dify のいずれからも1URLで統合できる

暦注の一覧・判定ルール・用途別スコアは https://shirabe.dev/docs/rekichu-api に整理されている。実装に入る前に一度目を通しておくと、自前実装を始める前に止められる確率が上がると思う。

関連リンク