節目の報告
第 18 弾の結びで「大きな節目の報告になる予定」と書いた。その報告である——本日 2026 年 9 月 14 日、スケジュール定義言語 Kairos の 1.0 を宣言する。
この連載の第 1 弾の題は「cron でもタスクスケジューラでも『月末3 営業日前』が書けないので、スケジュール定義言語を作っている」だった。8 月 1 日のことである。44 日かけて、題の末尾が「作っている」から「作った」に変わった。今日はその中身を書く。
1.0 で何が固まったのか
1.0 が凍結するのは言語そのもの——意味論・演算子族・文法(EBNF)・字句である。今日以降、Kairos で書かれた定義の受理される形と、その意味は変わらない。リリース候補(RC5)を 7 月8 日に宣言してから、追補という形で 18 回の精密化を重ねてきたが、そのすべては「受理言語を変えない」制約の下で行われてきた。今日はそれを版として封をする日である。
正直な開示も第 1 弾から変わらない。参照実装はプロトタイプである(TypeScript・実行時依存ゼロ)。1.0 は言語の宣言であって、実装が本番グレードだという主張ではない。実装が保証するのは「仕様のとおりに動く」こと——ドキュメントに載っている実行例は、すべて CI で実際に実行・照合されている(doctest 込みで 638 テスト)。
数字で振り返る
- 設計記録の初コミット: 2026 年 7 月 2 日。設計判断の記録(ADR)は 53 本——「営業日は カスケード」(ADR-01)から始まり、束縛のメモ化の正しさ(ADR-53)まで
- テスト 638 本(doctest 込み)。文書の実行例が全数 CI で走る——「文書と実装がずれたら赤く なる」を仕組みにした
- 外部レビュー 12 回。仕様書は書いた本人がいちばん騙されやすい——他人の目を定期的に入れた
- 外部の独立実装との往復書簡 20 便。参照実装とは別に、この言語を本番で使う実装者がいて、 詳細な実測つきの報告が 19 回届いた。仕様の隙間はこの往復でいちばん多く見つかった(この話は 今週、もう 1 本書く)
- この連載 20 本。書けないスケジュールの博物誌から、エラーメッセージの読み方まで
三つの柱——連載で書いてきたことの再掲
合成できること。 cron や RRULE の限界は機能の不足ではなく、式が合成できないことだった——ある規則が導いた日付の列を、次の規則に食わせられない。Kairos ではすべての式が「時間ストリームから時間ストリームへの変換」で、だから「祝日表から振替休日を導出し、その結果を営業日の定義に流し、月末 3 営業日前を数える」が一つの定義になる。
決定性。 定義は時点の集合を表し、評価は純関数である。だから止まっていた間の撃ち漏らしが列挙できるし、監査が再現できる。これが実運用で何を意味するかも今週書く。
黙らないこと。 多義は受理しない・データの端では言う・選択の証拠を定義に残す。うるさい静的エラーは、黙った誤発火よりずっと安い——エラーには直し方が書いてある。
宣言日は Kairos 自身に選ばせた
小さな遊びを白状する。9 月 14 日という日付は、Kairos の式で選んだ。第 10 弾で書いた六曜の導出(大安)と、選日の一つ「一粒万倍日」の式を交差させ、目安の期間内で両方が重なる唯一の日を取った——大安かつ一粒万倍日の月曜日である。
断っておくと、六曜も選日も、伝統的な頒暦の営みに属するものであり、権威は上流にある。Kairos がやったのは、公開されている定義を式に写して計算しただけである。それでも「新しい言語の門出の日をその言語自身の式で選ぶ」のは、悪くない験担ぎだと思っている。
これから
- npm: 参照実装 CLI を
kairos-langとして公開した(コマンド名はkairos) - ブラウザで試す: Playground は今までどおり—— 評価器はページ内で完結し、何も送信しない
- レシピ集: 「cron で書けない」の定番 4 本から
- 英語圏へ: 仕様・リファレンス・標準ライブラリ解説は英語全ミラー済み。今週から英語圏への 告知も始める(ドキュメントの正は日本語のまま——この方針も変えない)
今週は 1.0 週として、この連載も集中投稿にする。予定は三本——cron からの引っ越しガイド (新しく来た人向けの入門)、決定性の実運用報告(外部実装者の本番数値)、そしてあるバグの事件簿(仕様の隙間がどう見つかり、どう塞がれたか)。
44 日、読んでくださってありがとうございました。言語は今日からが本番である。
Kairos はスケジュール定義言語です。仕様と参照実装はGitHub で公開しています。
コメント