はじめに
AI エージェントやチャットに「納期は何日か」「返信期限の 10 営業日後はいつか」と聞いていませんか。カレンダー計算に見える問いでも、モデルは祝日一覧や起算（カウント開始日）の仕様を手元に持たないまま推論します。その結果、1 日ずれや祝日の見落としが起きやすく、自動化の途中で納期やリマインダーが誤る事故につながります。
この記事では、次のプロンプトを例に、推論だけに頼る場合と、MCP（Model Context Protocol）経由で決定的に計算する場合の差を整理します。MCP は、Cursor などの AI クライアントが、祝日 API のような外部機能をツール呼び出しとして使えるようにする仕組みです。
2026年7月14日から10営業日後の日付は？日本の祝日も考慮してください。
例として使う条件は、起算日 2026-07-14・日本の祝日考慮・加算 10 営業日です。正解の日付は後述の再現実験で確認します。
この記事で扱う範囲は次のとおりです。
- 典型的な誤答と、仕様どおりの日付（
2026-07-29） - なぜモデル単体ではずれやすいか
- Cursor などへの MCP 接続（最短フロー）
- 次に試せるドメイン形式検証
再現実験：同じプロンプトで何が起きるか
上のプロンプトを、通常のチャット（ツールなし）と、Thousand API を MCP 接続したエージェントの両方に投げると、答えが分かれやすいです。
本記事の「正解」は、起算日の翌日から営業日を数える前提です（Thousand API の datetime_add_business_days の仕様）。
| 経路 | よく出る結果 | 何が起きているか |
|---|---|---|
| 通常チャット（推論のみ） |
2026-07-28 など |
起算日の数え方や祝日の扱いが曖昧 |
MCP（datetime_add_business_days） |
2026-07-29 |
土日・祝日をスキップして仕様どおりに計算 |
仕様どおりの答えは 2026-07-29
Thousand API に次を渡すと、結果は 2026-07-29 です。
{
"country": "JP",
"from": "2026-07-14",
"days": 10
}
result: 2026-07-29
2026 年の海の日は 7 月 20 日です（内閣府の国民の祝日一覧 および Thousand API の datetime_get_holidays でも同日）。起算日の翌日以降の営業日を 10 日進めると、土日と海の日を除いた先が 7 月 29 日になります。
営業日の並びを追うと次のようになります（起算日 7/14 自体は数えず、翌日以降を進める想定）。
- 7/15（水）
- 7/16（木）
- 7/17（金）
- 7/21（火）※ 7/18–19 は土日、7/20 は海の日
- 7/22（水）
- 7/23（木）
- 7/24（金）
- 7/27（月）
- 7/28（火）
- 7/29（水）
典型誤答：7/28 になるパターン
起算日当日を「1 営業日目」に含めて数えると、同じカレンダーでも 10 日目が 7 月 28 日になります。祝日を忘れて土日だけ飛ばすと、別の日付にも着地します。いずれも「正しそうに見える」ため、レビューなしの自動化では気づきにくいです。
失敗例: 「7/14 から 10 営業日」と言いながら、起算を当日込みにしたままカレンダーを数える。祝日データが無いモデルは、海の日を平日扱いしたまま答えを出すこともあります。どちらも、プロンプトの言い回しだけでは仕様が固定されません。
なぜ起きるか：推論では仕様を保持・適用しきれない
営業日計算でずれる主な要因は次の 3 点です。
| 要因 | 内容 |
|---|---|
| 起算の曖昧さ | 「から N 営業日後」が当日込みか翌日からか、文脈依存 |
| 祝日データの欠落 | 年ごとに変わるハッピーマンデー（特定の月曜日を祝日にする制度）を、毎回正しく列挙できない |
| 途中の数え間違い | 長い推論チェーンの中で 1 日ずれる |
モデルは文章生成が得意でも、国・年・起算ルールをコードと同じ厳密さで適用する用途には向きません。納期や SLA のような「1 日の差が事故になる」領域では、計算はツールに任せ、モデルは「どのツールを・どの引数で呼ぶか」に寄せる方が安全です。
最短セットアップ：MCP で一度計算させる
ここからは Thousand API を例に、MCP で営業日を計算する最短フローを示します。初回はアカウント登録込みで数分見ておくとよいです。接続後の確認自体は短時間で済みます。
Thousand API は、推測ではなく計算で正しさを担保する（Certainty）方針でツールを公開しています。手計算ややり直しを 1 回のツール呼び出しに圧縮し（Token efficiency）、MCP 設定だけで接続できます（Agent-native）。2026 年 7 月時点の公式表記では、MCP ツール 84 / カテゴリ 7、Free プランは月 1,000 リクエストまでです。プラン上限は変更され得るため、利用時は 公式サイト の正本を確認してください。
最短の流れは次の 4 ステップです。
- Thousand API で無料登録する
- ダッシュボードで API キーを発行する（発行時だけ平文が表示される）
- MCP クライアントに設定を追加する（Cursor ならプロジェクト直下の
.cursor/mcp.json、または Cursor Settings の MCP 画面） - 冒頭のプロンプトを 1 回投げ、
2026-07-29になることを確認する
設定の形は公式が案内している次の JSON です。your-api-key を発行したキーに置き換えてください。
{
"mcpServers": {
"thousand-api": {
"url": "https://mcp.thousand-api.com/mcp",
"headers": {
"x-api-key": "your-api-key"
}
}
}
}
保存後、MCP サーバーが有効になり、ツール一覧に datetime_add_business_days が見えることを確認します。
注意点:
- API キーはチャットや Git に貼らない。漏れたらダッシュボードから失効する
- エージェントがツールを呼ばず推論だけで答える場合がある。そのときは「
datetime_add_business_daysを使って」と明示する - 成功の目安は、回答に
result: 2026-07-29が含まれること、またはチャットログにツール呼び出しが記録されていること - Free の月次上限に達すると 429（利用上限超過の HTTP ステータス）になる。残量は
utility_get_usageで確認できる
接続後、同じプロンプトを再度投げると、エージェントは MCP 経由でツールを呼び、result: 2026-07-29 を返す想定です。手元で日付だけ欲しい場合は、REST でも同じ引数を渡せます（エンドポイント一覧は ツール索引 側のドキュメントを参照）。
次に試すなら：ドメイン形式の検証
営業日と同様、入力チェックも「それっぽい正答」を返しやすい領域です。見た目は正しそうだが仕様上は不正、という例としてドメイン形式があります。プロンプト例です。
example.123 は有効なドメイン名ですか？
典型的な誤答は「数字だけの TLD でも有効」とする判断です。Thousand API の network_check_domain_format に example.123 を渡すと、次のように拒否されます。DNS 解決は行わず、RFC 1035/1123 系の形式チェックのみです。
{
"valid": false,
"domain": "example.123",
"error_reason": "TLDが数字のみです"
}
エージェントに「形式を推測させる」のではなく、「検証ツールの結果を読む」フローにすると、入力バリデーションの誤判定を減らせます。
まとめ
- 「N 営業日後」は起算と祝日で 1 日ずれやすい。2026-07-14 起算・日本・10 営業日の仕様どおりの答えは 2026-07-29（海の日 7/20 を除外）
- モデル単体の推論では、仕様の保持と適用が不安定になりやすい
- Thousand API を MCP 接続し、
datetime_add_business_daysで計算させると再現しやすい - 次の一歩として、
example.123のドメイン形式検証（network_check_domain_format）も試せる
次アクション: Thousand API で Free 登録し、上記の MCP 設定を追加したうえで、冒頭の営業日プロンプトを 1 回実行してみてください。
Source
- Thousand API（公式）
- 国民の祝日について（内閣府）
- 国民の祝日に関する法律（e-Gov）