【MCP】AIに「10営業日後」を聞くと、なぜ1日ずれるのか｜Thousand APIで確実に計算する

はじめに

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 自体は数えず、翌日以降を進める想定）。

  1. 7/15（水）
  2. 7/16（木）
  3. 7/17（金）
  4. 7/21（火）※ 7/18–19 は土日、7/20 は海の日
  5. 7/22（水）
  6. 7/23（木）
  7. 7/24（金）
  8. 7/27（月）
  9. 7/28（火）
  10. 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 ステップです。

  1. Thousand API で無料登録する
  2. ダッシュボードで API キーを発行する（発行時だけ平文が表示される）
  3. MCP クライアントに設定を追加する（Cursor ならプロジェクト直下の .cursor/mcp.json、または Cursor Settings の MCP 画面）
  4. 冒頭のプロンプトを 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 APIMCP,個人開発

Posted by 千原 耕司