# MCPエラー -32601: メソッドが見つかりません – 完全な修正とトラブルシューティングガイド 2026

Claude、Cursor、Continue.devなどでのMCP「メソッドが見つかりません」エラー(-32601)を解決します。インスペクター、機能、バージョン修正、エッジケースを含むステップバイステップガイドです。

Canonical URL: https://a2a-mcp.org/blog/mcp-error-method-not-found-ja

Language: ja

Published: 2026-04-20

Updated: 2026-04-22

## 主な要点

- **MCP エラー -32601 "Method not found"** は標準的な JSON-RPC 2.0 エラーであり、クライアントが MCP サーバーが実装していない、または capabilities で公開していないメソッドを要求したときに発生します。
- 主な原因には **オプションのメソッドプローブ** (resources/list, prompts/list, elicit)、**クライアントとサーバーの SDK 間のバージョン不一致**、および **不完全な capabilities 宣言** が含まれます。
- ほとんどのケースは良性かつ予期されたものであり、継続的なエラーは公式の MCP Inspector を使用し、実装を調整することで解決されます。
- Claude Desktop、Cursor、Continue.dev および FastMCP、Spring AI、または McpSharp で構築されたカスタムサーバーでよく発生します。

## MCP メソッドが見つからないエラーについての理解

Model Context Protocol (MCP) は、AI クライアント (Claude、Cursor など) とツール、リソース、プロンプト用の外部サーバー間の通信を、様々なトランスポートを介して JSON-RPC 2.0 を使用して標準化します。

エラーレスポンスは通常次のようになります:

```json
{
  "jsonrpc": "2.0",
  "id": 19,
  "error": {
    "code": -32601,
    "message": "Method not found"
  }
}
```

これは要求されたメソッド (例: `tools/call`, `resources/list`, `prompts/list`, または elicitation 関連) がサーバーに未知であることを示します。接続エラーや parse エラーとは異なり、トランスポート層は通常成功します — 問題はプロトコルレベルにあります。

コミュニティの報告や GitHub の issue から、このエラーは capabilities の探索中や、クライアントがサーバーが提供するよりも広範なサポートを前提としたときに頻繁に発生することがわかっています。

## 一般的な原因

最近の issues (2025–2026) の分析から、以下のトリガーが強調されます:

- **オプションのメソッドが実装されていない**: MCP サーバーはすべての機能をサポートする必要はありません。Claude Desktop などのクライアントは `resources/list`, `prompts/list`, または elicitation メソッドをプローブすることがあり、それらが欠けている場合 -32601 を引き起こします。
- **Capabilities Advertisement のギャップ**: サーバーの `initialize` レスポンスがサポートされる capabilities を正しく宣言していないため、クライアントがサポートされていないメソッドを呼び出します。
- **SDK とバージョンの不一致**: `@modelcontextprotocol/sdk`, FastMCP, Spring AI MCP, または McpSharp の異なるバージョンにより互換性問題が発生します。Java ユーザーは JDK 21 への切り替えで頻繁にこれを解決しています。
- **IDE/クライアント固有の挙動**: Cursor の agent chat はメソッドエラーとともに "No MCP resources available" を報告する可能性があります。Claude は "Method not found: resources/list" を繰り返しログ出力します。
- **Elicitation 要求**: FastMCP および同様のフレームワークは、ユーザー入力 elicit がクライアントによって完全にサポートされていない場合、McpError をスローします。
- **カスタムまたは最小限の実装**: 適切なエラー処理や完全なプリミティブサポート (initialize, tools/list, tools/call) なしに手動で作成されたサーバーは、実際のクライアントで失敗します。
- **トランスポート/プロキシの問題**: Docker、ngrok、または inspector proxy セットアップでは、ルーティング問題がメソッドエラーとして現れる可能性があります。

## 段階的なトラブルシューティングと修正

### 1. 診断に MCP Inspector を使用する

公式ツールはサーバーを検証する最も迅速な方法です:

```bash

# Node.js / TypeScript
npx @modelcontextprotocol/inspector "node your-server.js"

# Python
uvx mcp-inspector "python your_server.py"
```

インスペクターは能力（capabilities）を表示し、メソッドをインタラクティブにテストできるので、どのメソッドが-32601を返すかが正確にわかります。メソッドがここで失敗するなら、サーバーで実装されていません。

### 2. 能力を正確に検査し宣言する

`initialize` ハンドシーク時、サーバーは正確な能力を返す必要があります。例の構造：

```json
{
  "capabilities": {
    "tools": {
      "listChanged": true
    },
    "resources": false,
    "prompts": false
  }
}
```

サポートされていない機能は、明示的に `false` に設定するか省略することで、不要なプローブを防ぎます。

### 3. バージョンと依存関係を調整する

- クライアントとサーバーを一致する MCP SDK バージョンに更新します。
- Java/Spring AIの場合：`JAVA_HOME` を JDK 21+ に設定し、キャッシュをクリアします。
- Cursor/Claudeの場合：更新後、アプリケーションを再起動し、MCP構成をリフレッシュします。
- 最新リリースが互換性の問題を引き起こしている場合、以前の安定バージョン（例：古いレポートでは Cursor 0.45）に戻します。

### 4. ログを徹底的に確認する

- サーバー側：届いた正確なメソッド名とルーティング方法を確認します。
- クライアント側：Claudeログ（macOSでは `~/Library/Logs/Claude/`）、Cursor拡張機能の出力、またはContinue.devコンソールを確認します。
- シーケンスを探す：成功した `initialize` 後に失敗したオプションのメソッド呼び出し。

### 5. オプションおよびエッジケースのメソッドを扱う

- オプションメソッドの -32601 は、可能な場所ではクライアントコードで致命的ではないものとして扱います。
- 発話量が多いツールの場合：対象クライアント（例：Gemini CLI や特定の Cursor モード）がサポートしていない場合、優雅なフォールバックを実装したり、機能を無効にします。
- カスタムサーバーでは：クラッシュやタイムアウトではなく、適切な JSON-RPC エラーフォーマットで常に応答します。

### 高度なヒントと落とし穴

- **リソースとプロンプトのプローブ**：多くのサーバーは無害な「Method not found: resources/list」をログします — コアツールが機能する場合はこれを無視します。
- **Dockerとリモートセットアップ**：ポートフォワーディング、ヘルスチェック、POSTリクエストが正しいハンドラーに届いていることを確認します。405エラーが時々 -32601 に付随します。
- **テスト戦略**：最初に MCP インスペクターでテストし、次に複数のクライアント（Claude Desktop、Cursor、Continue.dev）でテストします。curlによる直接JSON-RPC呼び出しで低レベルバリデーションを行います。
- **パフォーマンス関連の模倣**：長時間実行されるツール呼び出しとタイムアウト（Spring AIで一般的）は、下流でメソッドエラーとして表面化する可能性があります。
- **最小限の実用サーバー**：最低でも `initialize`、`tools/list`、`tools/call`、`ping` を実装します。すべての受信リクエストに対して堅牢なログ記録を追加します。

## 予防策のベストプラクティス

- エラーコードと機能レスポンスについては、最新のMCP仕様を厳密に遵守してください。
- スクラッチ実装ではなく、公式SDKを可能な限り使用してください。
- 本番サーバーには、包括的なログ記録とバージョン交渉機能を組み込んでください。
- 変更や破壊的変更に関する最新情報については、modelcontextprotocol GitHub組織を定期的に監視してください。
- 機能の検出を徹底的にテストしてください。これにより、実運用での大半の-32601問題を防ぐことができます。

機能を明確に公表し、オプションのメソッドを適切に処理する開発者は、サポートチケットが大幅に減少することを報告しています。

## 結論

MCP -32601「メソッドが見つかりません」エラーは、通常、重要な失敗ではなく、プロトコル機能のオプションとして期待される動作です。MCP Inspectorによる体系的な診断、適切な機能宣言、バージョンの一致により、ほぼすべてのケースが解決されます。

2026年にエコシステムが成熟し続ける中、MCPサーバーとクライアントを最新の状態に保ちましょう。解決困難な問題については、関連するGitHubリポジトリやコミュニティフォーラムに、サーバーの機能JSON、正確なメソッドログ、およびクライアントバージョンを共有することで、コミュニティからの迅速な支援を得られます。

これらのプラクティスを実践することで、より堅牢かつ互換性のあるMCP統合を構築してください。