【MCP】AIに「10営業日後」を聞くと、なぜ1日ずれるのか｜Thousand APIで確実に計算するAI models lack built-in holiday data and business-day counting rules, causing…

Ask an AI assistant a seemingly simple question, such as "When is 10 business days after today?" or "What is the delivery deadline?", and the answer may be off by a day. This matters because these date calculations feed into contracts, service-level commitments, reply deadlines, and logistics, where a single day of drift can carry real consequences. The underlying issue is not that a model cannot count, but that it lacks the reference data and the explicit rules needed to count correctly.

The root of the problem is structural. Large language models generate responses by inference over patterns in their training data, and they do not hold an authoritative, up-to-date list of public holidays in memory. Nor do they consistently apply the counting convention, known in Japanese as the 起算日 or "counting-start day," that determines whether the current day is included or excluded when a period is measured. Because these details are ambiguous and vary by jurisdiction and by business practice, a model tends to improvise. The result is the familiar off-by-one error and, more subtly, the silent omission of a national holiday that should have shifted the deadline forward.

Business-day arithmetic is deceptively hard for reasons that have little to do with intelligence. Weekends must be skipped, national holidays must be excluded, and in some organizations company-specific closures or substitute holidays also apply. Rules differ across countries and regions, and holiday calendars change from year to year, sometimes with special one-off dates announced by governments. A model trained on a fixed snapshot of text cannot reliably know next year's holidays, and even when it has seen them, it may not apply the exclusion rules deterministically. What looks like a calendar question is actually a data-and-rules question, and models are weakest precisely where determinism is required.

The article describes addressing this by delegating the calculation to a dedicated external service rather than trusting the model to reason it out. Thousand API is presented as the calculation source, and it is connected to the AI through the Model Context Protocol, commonly abbreviated as MCP. In this arrangement the model no longer guesses. When a user asks for a date offset, the assistant calls the API with the start date, the number of business days, and the relevant holiday set, and receives a precise result computed by code designed for the task. This is a practical example of separating language understanding, which models do well, from exact computation, which is better handled by deterministic tools.

MCP is worth understanding as background because it is the mechanism that makes this pattern portable. Introduced by Anthropic and since adopted more broadly across the industry, MCP is an open standard that defines how AI applications connect to external tools, data sources, and services through a common interface. An MCP server exposes capabilities, in this case a date or business-day calculation, and an MCP-compatible client such as a chat assistant or agent can discover and invoke them. The value is standardization: rather than writing bespoke integrations for every model and every tool, developers expose a service once and reuse it across compatible hosts. This is the same idea behind conventional function calling and tool use, but framed as a shared protocol.

The broader context is a well-documented weakness of language models in tasks that demand exact, verifiable answers, including arithmetic, unit conversion, and date logic. The prevailing remedy across the industry is tool use, where the model recognizes the need for a computation and hands it off to a calculator, a database query, or an API. Retrieval-augmented approaches follow similar logic for factual lookups. Delegating holiday-aware date math to a purpose-built API fits squarely within this design philosophy and tends to be more robust than prompting a model to "be careful" about weekends and holidays.

A few caveats are worth noting. The accuracy of any such setup depends on the correctness and coverage of the holiday data the service uses, so results are only as reliable as the underlying calendar, particularly for regional or company-specific closures. Teams should also confirm which counting convention the API applies, since inclusive and exclusive start dates produce different answers. Even so, the approach described appears to be a sound way to eliminate the off-by-one and missed-holiday errors that arise when a model is left to infer business-day calculations on its own.