LLM 営業日計算ベンチマーク
「月末営業日の 3 営業日前はいつか」——日本の祝日と土日を踏まえたこの種の計算を、LLM はどれくらい正しく答えられるのか。
決定的な暦計算エンジン Kairos が生成した正解と突き合わせて測ります。
問題・生成器・祝日の一次資料・結果はすべて公開しており、誰でも再実行できます。
結論から——問い方を実務の形にした途端、全問正解していたモデルが 20 ポイント落ちました。
定義と回答形式を全問に添えた教科書的な問題セットでは 120 問全問正解だったモデルが、
前提を語らない実際の聞き方（「今月の給与支給日っていつになる？」）にすると 80.0% です（2026-07-28・Claude Opus 5・v1 の約 9 時間後に v2 を測定）。
2026-09-25 の再測（5 モデル・effort は 4 モデルで high に統一・Haiku 4.5 は非対応）では、素で聞く条件の正答率は上位 4 モデルで 75.8〜79.2%、小型モデルは 27.5% でした。
そして正解できた場合も、その答えは正解した問題だけで平均しても 1 問あたり 289〜1,003 トークン（素で聞く条件・推論を積む 4 モデル）の推論を積み上げて得られたものです。
同じ問いに確定した日付を渡せば（条件 C2）、5 モデル中 3 本が 100%・小型モデルも 96.7% になります。
Opus 5・Sonnet 5・Haiku 4.5 は約 20 トークンで答え、思考を常に行う Fable 5.1 でも 277 トークンです。
ただし Claude Opus 5.5 は、確定値を渡されても 85.8% にとどまりました（下の註記）。
たかが日付、と片づける前に——下の表の「平均出力トークン」の列を見てください。
2026-09-25 の測定についての註記
- 対象は 5 モデル（Claude Fable 5.1・Opus 5.5・Opus 5・Sonnet 5・Haiku 4.5）。推論の深さの指定（effort）は 4 モデルで
high に統一しました。
段階名が同じでも、モデル間で同じ思考量を意味するわけではありません。Haiku 4.5 は effort に対応しておらず、この測定では思考なしで答えています
（実際に送った値は結果 JSON の config.effortByModel にあります）。
- Claude Opus 5.5 は、Kairos の照会結果を渡しても採り切りませんでした——C1 82.5%（99/120）・C2 85.8%（103/120）。
誤答 38 件は 2 カテゴリに集中しています。「支払サイトの営業日数」の 28 件はすべて営業日数が 1 少なく（素で聞いた条件 A では 20 問すべて、B でも 20 問中 18 問が同じ 1 少ない形）、
「週次締めの伝票チェーン（複数解）」の 10 件はすべて休日の後ろ倒しをせず、素で聞いた条件 A と同じ答えでした。他の 4 カテゴリでは誤答 0 件です。
同じプロンプトで Haiku 4.5 はこの 2 カテゴリの C2 を各 20 問中 20 問（計 40 問中 40 問）正解しているので、照会結果そのものは渡せています。
出力トークンも、確定値を渡してほとんど減っていません（A 320 → C2 313・約 2%）。思考の中身は記録していないため、
なぜ照会結果より自分の計算を優先したのかは未検証です。
- これは「答えを与えてもなお間違える」実例です。AI を経由してスケジュールを実行する構成には、この分の不確実性が残ります。
暦計算は決定的に解き、AI にはその値を使わせるだけにし、発火は AI を介さない——このベンチが示したい設計上の論点を、
Opus 5.5 でも裏づけるデータになりました。
測定設計
同じ問題を 4 つの条件で解かせ、条件間の差を見ます。
さらに、LLM を介さない Kairos 直を基線として並べます。
C を C1／C2 の 2 本に分けているのは、指示の強さ自体が測定条件だからです。
片方だけでは「指示が甘かっただけでは」（C1 のみ）、「100% になるよう指示を書いただけでは」（C2 のみ）という
どちらの疑問にも答えられません。
問いの形
問題文は実務の聞き方に寄せています。営業日の定義と回答形式は
system プロンプトとして 1 回だけ渡し、各問には必要最小限の前提と
口語の問いだけを置きます。「本日」は絶対日付ではなく
「YYYY 年 M 月の第 1 営業日」として与えます——本題の前に 1 段の営業日計算が要る形です。
給与は毎月25日に支給し、25日が休日の場合は繰り上げて直前の営業日に振り込むものとします。
部署Aは部署Bの1営業日前に、部署Bは部署Cの1営業日前に、部署Cは給与支給日の1営業日前に、
それぞれ処理を行うものとします。
本日を2026年9月の第1営業日として、次の問いに回答してください。
「今月の部署Aの処理日はいつ？」
↑ 実際の出題例（正解 2026-09-17）。2026 年 9 月は 9/21 敬老の日・9/22 国民の休日・
9/23 秋分の日＋土日で 9/19〜9/23 が 5 連休。給与日 9/25(金) から
部署C 9/24(木) → 部署B 9/18(金) → 部署A 9/17(木) と遡ります。1 段でも誤ると全部ずれます。
問題カテゴリ（各 20 問・計 120 問）
- 月末営業日の N 営業日前（経理の締めリマインドの定番形）
- 給与日 25 日・休日なら繰り上げ
- 支払サイトの営業日数（翌月 15 日払い）
- 年度四半期末の営業日——「去年の第 N 四半期」を相対参照のまま問う
- 給与処理の 3 部署チェーン（給与日から繰り上がる多段遡り・実在の業務ルール）
- 週次締めの伝票チェーン（締め日から繰り下がる多段・答えが複数・実在の業務ルール）
単純な単段の計算（第 K 営業日・祝日判定）は外しました——実務で人が迷うのは
複数のルールが連鎖する場面で、そこを厚くしています。
繰り上げ（休日なら前へ）と繰り下げ（休日なら後ろへ）の両方向を入れているのも、
実際の業務ルールが両方存在するためです。
繰り上げが起きる月／起きない月、連休を跨ぐ月／跨がない月を意図的に半々で配分しています——
片方に寄せると「常に繰り上げ」と決め打ちしただけで当たってしまい、測定になりません。
留保
- 結果は測定日時点のモデル世代のものです。プロンプトにも依存します。
- 同じ問題・同じ条件でも、実行のたびに数ポイント動きます。
この問題セット（v2）を同一条件（3 モデル・effort 未指定）で 2 回走らせたところ（2026-07-28 と 2026-09-01・結果ファイルの日付）、
条件 × モデルのセル単位で最大 4.2 ポイント（完全情報 × Opus 5: 77.5% → 73.3%）、全体では 0.9 ポイントの差が出ました。
1 回の測定値を断定的に読まないでください。
再現したのは大きな構図——Opus 5・Sonnet 5 の高い正答率、小型モデルの大幅な低下、確定値を渡したときの収束——の方です。
- 条件 C1・C2 が高い正答率になるのは当然です——計算済みの正解を渡しているのだから。
ここで示したいのは「だから暦計算は外部化せよ」という設計上の論点であって、モデルの優劣ではありません。
ただし正解を渡しても 100% になるとは限りません。渡された確定値を AI が使い損ねることがあり（2026-09-25 の Opus 5.5 が実例）、
それも含めてこのベンチが測っているデータです。
- 基線「Kairos 直」の 100% は測定値ではありません。LLM を 1 度も呼ばずに得られる確定値なので、
正しさは測定ではなく独立検証で担保しています——Kairos とは無関係な素朴実装（祝日集合と曜日だけを使う別実装）との
二重計算が全問一致すること、祝日を跨ぐ代表ケースが人間の手検算と一致すること、
そして正解が一意に定まらない問題は生成時に弾いていること（date 型は窓内の点が 1 個でなければエラー）。
- 営業日の定義は「土曜・日曜・内閣府『国民の祝日について』掲載日（振替休日・国民の休日を含む）を除く日」に固定しています。
企業ごとの独自休業日は含みません。
- 「LLM は暦計算ができない」とは言えません。営業日の定義と回答形式を全問に添えた
教科書的な問題セット（v1）では、Opus 5 が 120 問全問正解しました。言えるのは次の 2 点です——
①問い方を実務の形にすると、同じモデルでも 20 ポイント落ちる（2026-07-28・Opus 5: 100% → 80.0%）。
②モデル階層で断裂する（2026-09-25: 同じ問題で上位 4 モデルが 75.8〜79.2%、Haiku 4.5 は 27.5%）。
コスト最適化のために小さいモデルを選ぶ構成ほど、この計算は静かに壊れます。
- 問い方そのものが結果を大きく動かします。同じ計算内容を「前提を全部書いた丁寧な問題文」で
聞いた場合と「前提を語らない実務の聞き方」で聞いた場合とで、素で聞く条件（A）では測った 3 モデル（2026-07-28・Opus 5・Sonnet 5・Haiku 4.5）がいずれも 17〜20 ポイント違いました。
公開ベンチの数字は問題文の設計に強く依存する——このページの数字も例外ではありません。
判断材料にするときは、自分の使い方に近い問い方かどうかを見てください。
- 正答率が同じでも払っているものは同じではありません。自力で解いた正解は推論トークンを消費し、
その分だけ遅く、高くつきます。確定値を渡せば、正しさは保ったまま消費は小さくなります——2026-09-25 の測定では、推論を積む 4 モデルのうち
Fable 5.1・Opus 5・Sonnet 5 の 3 本で出力が約 7 割（Fable 5.1）〜 60 分の 1（Sonnet 5）に減りました。Opus 5.5 は出力がほとんど減らず（A 320 → C2 313）、正しさも保てていません（上の註記）。
思考なしの Haiku 4.5 は元から 1 問あたり 16〜18 トークン（A 16・C2 18）で、確定値を渡すと正答率だけが 27.5% → 96.7% に上がりました。
- これは「LLM は暦計算が不得意だ」という主張ではなく、LLM に何をさせ、何をさせないかの設計指針を示すためのデータです。
再現方法
問題セットと正解は決定的です。LLM を呼ばずに正解だけ再生成して、公開物と一致することを検証できます。
npm run bench:oracle -- --check # 問題セットと正解の凍結検証（課金ゼロ）
npm run bench:bizdays # 実走の規模とコスト見積もり（dry-run・課金ゼロ）
npm run bench:bizdays -- --execute # 実走（課金が発生します）
祝日は内閣府「国民の祝日について」の CSV を取得日つきで固定しています（出典: https://www8.cao.go.jp/chosei/shukujitsu/syukujitsu.csv／政府標準利用規約）。
公表 CSV が更新されても過去の測定結果が再現できるようにするためです。
「営業日で前後にずらす」定期の予定を式で書いた例は、営業日・締め日のレシピ集で公開しています。