Cherry StudioのMCP exec toolで「Unexpected number」エラーが出る原因と対処法（Windows向け）

Cherry StudioのMCP exec toolをWindowsで使っていると、最初は動くのに数回使ったあと突然 { "error": "Unexpected number", "isError": true } が返り、簡単なコードすら実行できなくなることがあります。再インストール直後だけ正常で、キャッシュ削除でも直らない──この挙動は「実行環境そのもの」よりも、MCP呼び出しの経路・制限・状態ファイルの破損など“使っているうちに蓄積する要因”が絡んでいるケースが多いです。この記事では、再現条件の整理から、現実的に効く手当てを優先順位つきでまとめます。

• Cherry StudioのMCP exec toolで「Unexpected number」エラーが出る原因と対処法（Windows向け）
  • 発生状況の整理：何が起きているか
  • まず疑うべき原因トップ3
    • 1) リモートMCP側のレート制限・一時ブロック
    • 2) ローカル状態（設定・セッション・トークン）の破損や不整合
    • 3) 企業ネットワーク・プロキシ・セキュリティソフトの干渉
  • 最優先で効く対処：復旧までの手順（上から順に）
    • 手順A：完全リセット（キャッシュではなく“ユーザーデータ”を消す）
    • 手順B：呼び出し頻度を落としてレート制限を回避
    • 手順C：ネットワーク干渉の有無を切り分ける
    • 手順D：ログ・エラーレスポンスの実体を確認する
  • 再発を防ぐ運用のコツ
  • 開発側に伝えると解決が早い情報テンプレ
  • まとめ：このエラーは“数字”が悪いのではなく“想定外の応答”が来ている

発生状況の整理：何が起きているか

報告内容は概ね次の流れです。

• OS：Windows 10 64-bit

• Cherry Studio：v1.7.15

• MCP exec toolで return "test"; のような短いコードを実行

• しばらくは動くが、数回利用後に「Unexpected number」エラーが固定化

• 再インストール直後のみ復活し、キャッシュ削除は効かない

また、ディスカッション内では「remote MCP呼び出し時にレート制限を超えたように見える」という示唆もあります。つまり、表示されているエラー文言は“真の原因”を直接表していない可能性が高い、という前提で切り分けるのが近道です。

まず疑うべき原因トップ3

1) リモートMCP側のレート制限・一時ブロック

一定回数の呼び出し後にだけ壊れる、という挙動はレート制限と相性が良いです。制限に当たった瞬間、サーバーが「数値（例：HTTPステータスやエラーコード）」主体のレスポンスを返し、それをクライアント側が想定外の形式として解釈して「Unexpected number」になっている、というパターンが起こりえます。

2) ローカル状態（設定・セッション・トークン）の破損や不整合

「キャッシュ削除では直らない」のに「再インストール直後は直る」なら、キャッシュではなく“ユーザーデータ領域”に残る設定やセッション情報が劣化している可能性があります。Windowsアプリはアンインストールしても %AppData% や %LocalAppData% が残りやすく、再インストールで一見直っても、同じ状態に戻ると再発します。

3) 企業ネットワーク・プロキシ・セキュリティソフトの干渉

通信内容が途中で書き換えられたり、HTMLのブロックページやJSON以外の応答に差し替えられると、パーサーは「予期しない型」を受け取りやすくなります。数回後に発生するのは、しきい値（一定量の通信）で検知が強まる製品があるためです。

最優先で効く対処：復旧までの手順（上から順に）

手順A：完全リセット（キャッシュではなく“ユーザーデータ”を消す）

1. Cherry Studioを終了（タスクトレイ常駐があれば完全終了）

2. Windowsで以下を確認し、Cherry Studio関連のフォルダがあれば退避または削除

   • %AppData%（Roaming）

   • %LocalAppData%（Local）

   • %Temp%（一時領域）

3. 再起動後に起動し、MCP exec toolを最小のコードでテスト

ポイントは「キャッシュクリア」と「ユーザーデータ削除」は別物、という点です。キャッシュクリアが効かないケースは、セッションや設定が残っていることが多いです。

手順B：呼び出し頻度を落としてレート制限を回避

• 連続実行を避け、数十秒〜数分の間隔を空ける

• 同じ内容を短時間に繰り返さない（同一リクエスト連打は制限に当たりやすい）

• 可能ならバックオフ（失敗したら待ってから再実行）を徹底

「インストール直後は動く→使うと壊れる」の場合、まずこれで再発頻度が下がるか確認すると原因に当たりをつけやすいです。

手順C：ネットワーク干渉の有無を切り分ける

• 別回線（テザリング等）で同じ操作を試す

• VPNやプロキシを一時的に切って試す

• セキュリティソフトのWeb保護・HTTPSスキャンを一時的に無効化して比較（検証後は戻す）

回線を変えるだけで症状が消えるなら、アプリの問題というより通信経路の問題です。

手順D：ログ・エラーレスポンスの実体を確認する

「Unexpected number」は“パースエラーの結果”である可能性が高いので、実際に返ってきた内容（HTTPステータス、レスポンス本文）が分かると一気に進みます。アプリにログ機能があるなら有効化し、失敗時の直前ログを保存してください。もしレスポンスに「429」や「rate limit」相当が含まれるなら、ほぼレート制限です。

再発を防ぐ運用のコツ

• 連続実行を前提にしない（短い待機を挟む）

• 失敗したら連打せず、一定時間置く（制限解除待ち）

• 動作が怪しくなったら“キャッシュ”ではなく“状態”を疑う

• アプリ更新が可能なら更新を優先（特にパースやリトライ周りの改善が入りやすい）

開発側に伝えると解決が早い情報テンプレ

ディスカッションやIssueに追記するなら、次の情報が揃うと再現・修正が進みやすいです。

• Windowsの詳細（10/11、ビルド番号、言語・地域設定）

• Cherry Studioの版（例：v1.7.15）

• 何回目の実行で壊れるか（例：5回前後で再現）

• 失敗時のHTTPステータス（可能なら）

• 失敗時のレスポンス本文の先頭数行（個人情報は伏せる）

• 回線を変えても再現するか

• ユーザーデータ削除で復旧するか

まとめ：このエラーは“数字”が悪いのではなく“想定外の応答”が来ている

表示上は「Unexpected number」でも、実態は「MCP呼び出しが想定外の形式で返ってきて、結果として実行系が崩れている」ことが多いです。特に、一定回数後にだけ発生するなら、レート制限か状態不整合の線が濃厚です。まずはユーザーデータの完全リセットと、呼び出し頻度を落とす対策で復旧・再発頻度の変化を見てください。改善の方向が見えれば、次にネットワーク要因やログ確認で原因を特定し、根本対応につなげられます。

なお、Issue管理や再現手順の共有は GitHub 上のやりとりが前提になりがちなので、ログの扱いには注意しつつ、切り分け結果を簡潔に積み上げるのが最短ルートです。また、プロジェクト側（CherryHQ）で修正が入った場合に備えて、更新が出ていないかも定期的に確認すると良いでしょう。