LLM 営業日計算ベンチマーク
「月末営業日の 3 営業日前はいつか」——日本の祝日と土日を踏まえたこの種の計算を、LLM はどれくらい正しく答えられるのか。
決定的な暦計算エンジン Kairos が生成した正解と突き合わせて測ります。
問題・生成器・祝日の一次資料・結果はすべて公開しており、誰でも再実行できます。
結論から——問い方を実務の形にした途端、最上位モデルが 20 ポイント落ちました。
定義と回答形式を全問に添えた教科書的な問題セットでは 120 問全問正解だったモデルが、
前提を語らない実際の聞き方（「今月の給与支給日っていつになる？」）にすると 80.0% です。小型モデルは 29.2% でした。
そして正解できた場合も、その答えは1 問ごとに数百〜千トークンの推論を積み上げて得られたものです。
同じ問いに確定した日付を渡せば、20 トークンで 100% になります。
たかが日付、と片づける前に——下の表の「平均出力トークン」の列を見てください。
測定設計
同じ問題を 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 営業日・祝日判定）は外しました——実務で人が迷うのは
複数のルールが連鎖する場面で、そこを厚くしています。
繰り上げ（休日なら前へ）と繰り下げ（休日なら後ろへ）の両方向を入れているのも、
実際の業務ルールが両方存在するためです。
繰り上げが起きる月／起きない月、連休を跨ぐ月／跨がない月を意図的に半々で配分しています——
片方に寄せると「常に繰り上げ」と決め打ちしただけで当たってしまい、測定になりません。
留保
- 結果は測定日時点のモデル世代のものです。プロンプトにも依存します。
- 同じ問題・同じ条件でも、実行のたびに数ポイント動きます。
2026-07-28 に同一条件で 2 回続けて走らせたところ、最大 7.5 ポイントの差が出ました
（完全情報 × Haiku 4.5: 47.5% → 40.0%）。1 回の測定値を断定的に読まないでください。
再現したのは大きな構図——最上位モデルの高い正答率、小型モデルの大幅な低下、確定値を渡したときの収束——の方です。
- 条件 C1・C2 が高い正答率になるのは当然です——計算済みの正解を渡しているのだから。
ここで示したいのは「だから暦計算は外部化せよ」という設計上の論点であって、モデルの優劣ではありません。
ただし正解を渡しても 100% になるとは限りません。渡された確定値を AI が使い損ねることがあり、
それも含めてこのベンチが測っているデータです。
- 基線「Kairos 直」の 100% は測定値ではありません。LLM を 1 度も呼ばずに得られる確定値なので、
正しさは測定ではなく独立検証で担保しています——Kairos とは無関係な素朴実装（祝日集合と曜日だけを使う別実装）との
二重計算が全問一致すること、祝日を跨ぐ代表ケースが人間の手検算と一致すること、
そして正解が一意に定まらない問題は生成時に弾いていること（date 型は窓内の点が 1 個でなければエラー）。
- 営業日の定義は「土曜・日曜・内閣府『国民の祝日について』掲載日（振替休日・国民の休日を含む）を除く日」に固定しています。
企業ごとの独自休業日は含みません。
- 「LLM は暦計算ができない」とは言えません。営業日の定義と回答形式を全問に添えた
教科書的な問題セット（v1）では、最上位モデルが 120 問全問正解しました。言えるのは次の 2 点です——
①問い方を実務の形にすると、その最上位モデルでも 20 ポイント落ちる（100% → 80.0%）。
②モデル階層で断裂する（同じ問題で 80.0% と 29.2%）。
コスト最適化のために小さいモデルを選ぶ構成ほど、この計算は静かに壊れます。
- 問い方そのものが結果を大きく動かします。同じ計算内容を「前提を全部書いた丁寧な問題文」で
聞いた場合と「前提を語らない実務の聞き方」で聞いた場合とで、全モデルが 17〜20 ポイント違いました。
公開ベンチの数字は問題文の設計に強く依存する——このページの数字も例外ではありません。
判断材料にするときは、自分の使い方に近い問い方かどうかを見てください。
- 正答率が同じでも払っているものは同じではありません。自力で解いた正解は推論トークンを消費し、
その分だけ遅く、高くつきます。確定値を渡せば、正しさは保ったまま消費は小さくなります。
- これは「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 が更新されても過去の測定結果が再現できるようにするためです。