「大安の金曜日」は書けるか——六曜もまた、計算結果である

結婚式場と不動産屋とディーラーが毎年やっていること
六曜の正体は 3 行である
「大安の金曜日」を書く
これは暦を編む仕事の置き換えではない
文化は、一級の計算対象である

結婚式場と不動産屋とディーラーが毎年やっていること

「契約は大安の金曜日で」——不動産の引き渡し、結婚式の日取り、納車。迷信かどうかの議論はここではしない。カレンダーに載っていて、顧客が指定してくる以上、それは業務要件である。そして cron にも RRULE にも、旧暦は存在しない。だから毎年、どこかの誰かが市販のカレンダーの六曜欄を確かめて、手でシステムに転記している。

祝日のとき（第 6 弾）と同じ問いを立てよう——六曜は、データか、計算結果か。

六曜の正体は 3 行である

答え: ほぼ計算結果だ。六曜は旧暦の月番号と日番号を足して 6 で割った余りで決まる。大安・赤口・先勝・友引・先負・仏滅が順に並ぶだけの、拍子抜けするほど機械的な暦注である。

必要なのは旧暦——そして旧暦の月は朔（新月）で切る。ここだけは計算では出ない。新月の瞬間は天文観測の領分で、国立天文台が暦要項として毎年官報に載せるデータだ。つまり構造は祝日とまったく同じ: 朔はデータ・六曜は法則。

newMoons   = [2024-12-31T07:27, 2025-01-29T21:36, …] covering: 2024-12-31..2027-12-31

lunarStart = newMoons |> snapTo(day)                     # 朔の瞬間を含む市民日＝旧暦月初
lunarMonth = day |> segmentBy(lunarStart, edges: drop, empties: error, labels: monthNos)
lunarDayNo = d => ordinalIn(day, lunarMonth, d)
rokuyoNo   = d => (lunarMonth(d) + lunarDayNo(d)) mod 6  # 0=大安 … 5=仏滅

朔の点列（3 年ぶんで 38 点・covering と観測日付き）から旧暦月を張り、月内序数を読み、足して mod 6。六曜の全実装がこの 4 行である。月番号の並行リスト monthNos には 6 が 2 回並ぶ年がある——閏六月（2025 年）だ。旧暦には閏月がある、という一番厄介な事実も、データ側のラベル 1 個で表現が済む。

「大安の金曜日」を書く

@Koyomi
everyDay |> filter(d => rokuyoNo(d) == 0 and weekday(d) == Fri)

新暦の曜日と旧暦由来の六曜——二つの暦法をまたぐ条件が、filter の中で普通に並ぶ。
2026 年の実測:

2026-01-30
2026-02-27
2026-04-03
2026-05-01
2026-06-05
2026-07-03
2026-07-31
2026-09-04
2026-10-02
2026-11-06
2026-12-04
# 被覆サマリ
#   Kyureki.newMoons covering 2024-12-31..2027-12-31 asof 2026-02-02 残走路 365 日

▶ Playground で開く

11 日ある。そして 3 月と 8 月には一日もない。六曜は同じ旧暦月の中では 6 日周期で規則正しく回るが、月が替わる瞬間に位相が飛ぶ（月番号が 1 増えるから）——新暦の金曜と噛み合わない月が出るのはそのせいだ。この「噛み合わない月」自体は暦の世界ではよく知られた現象だが、なぜそうなるかが、式にすると一行で見える。

最後の 2 行にも注目してほしい。この答えは「朔データは 2026-02-02 観測の版・2027 年末まで有効・残り 365 日」という賞味期限つきで返ってくる。来年の暦要項が出たら newMoons に 1 年ぶん足して covering を延ばす——更新するのはデータ 13 行だけで、六曜の法則には触らない。祝日テーブル（第 5・6 弾）と同じ運用の型が、天文データでもそのまま成立する。

これは暦を編む仕事の置き換えではない

誤解のないように書いておく。この式は、閏月をどこに置くかを決めていない。月番号の列（閏六月の 6 が 2 回並ぶ、あのラベル）は、暦を編む人たちの判断の結果を、データとして受け取っている。朔の瞬間も国立天文台の観測成果だ。計算に戻したのは、そこから先の機械的な末端——mod 6 の一枚——だけである。むしろ、何百年も編まれてきた暦の体系が「専門家の判断（データ）」と「機械的な規則（法則）」にこれほど綺麗に分離できること自体が、その伝統の整いを物語っていると思う。上流の権威はこれからも上流にある。祝日の回（第 6 弾）で官報がそうだったのと、まったく同じ形だ。

文化は、一級の計算対象である

六曜・土用の丑の日・酉の市・旧盆・彼岸。日本の業務カレンダーには、グレゴリオ暦だけでは書けない日付が当たり前に混ざっている——魚屋とスーパーは丑の日を、酉の市は日の干支を、式場は六曜を見て動く。それらは長いこと「システムでは扱えないので手で転記するもの」だった——扱えなかったのは文化が曖昧だからではなく、言語の側に暦法を定義する場所がなかったからだ。朔で月を切る、と一度書けば、六曜は導出される。計算できるものを計算に戻すと、手で運ぶものはデータ 38 点だけになる。

祝日は法律の計算結果だった。六曜は天文データと 3 行の計算結果だった。あなたのドメインの「手で転記しているあの日付」は、本当にデータだろうか——それとも、まだ書かれていない法則だろうか。