ClaudeのMCP（Model Context Protocol）を使ってWordPressと連携する環境を構築しました。昨日まで正常に動いていたのに、今日は突然つながらない──そんなトラブルを経験しました。結論から言うと、原因はClaudeの思い込みによるデバッグミス(とアプリケーションパスワードの保存忘れ)でした。同じ失敗を繰り返さないための記録として残します。
環境
- サーバー：Xserver（hoscm.xsrv.jp）
- MCPプラグイン：claudeus-wp-mcp
- MCPユーザー権限：編集者（Editor）
- 接続設定：wp-sites.json（Claude Desktop）
何が起きたか──事象の時系列
昨日まで正常に動作していたMCP連携が、今朝から突然失敗するようになりました。Claudeは接続確認のために wp_health__test_auth を繰り返し実行しましたが、すべて403エラーが返ってきました。
| 手順 | 実施内容 | 結果 |
|---|---|---|
| ① | wp_health__test_auth で接続確認 | ❌ 403エラー |
| ② | WP Fastest Cache を無効化 | ❌ まだ403 |
| ③ | CloudSecure WP Security を無効化 | ❌ まだ403 |
| ④ | Xserver WAF を調査 | ❌ 関係なし |
| ⑤ | アプリケーションパスワードを再生成 | ❌ まだ失敗 |
| ⑥ | PowerShellで認証テスト | ✅ 通った |
| ⑦ | 「更新ボタン押し忘れ」に気づく | 原因判明 |
| ⑧ | パスワード正しく保存・再起動 | ❌ まだ失敗 |
| ⑨ | wp_healthではなく通常エンドポイントで確認 | ✅ 正常動作！ |
本当の原因は2つあった
原因①：アプリケーションパスワードの「保存ボタン押し忘れ」
WordPressのアプリケーションパスワードを再生成した後、プロフィール画面の「プロフィールを更新」ボタンを押さずに離脱していたため、新しいパスワードが保存されていませんでした。これが真の認証失敗の原因でした。
PowerShellで認証テストをしたところ通ったことで、この事実が判明しました。パスワード更新後は必ずブラウザ上で「更新完了」のメッセージを確認してください。
原因②：wp_healthエンドポイントは編集者権限では使えない
Claudeが接続確認に使い続けた wp_health__test_auth は、管理者権限が必要なエンドポイントです。このサイトのMCPユーザーは編集者権限しか持っていないため、パスワードが正しくても403が返り続けます。これは「接続失敗」ではなく「権限不足」による正常な拒否でした。
| エンドポイント | 必要権限 | 編集者での結果 |
|---|---|---|
| get_taxonomies | 不要（公開情報） | ✅ 正常 |
| get_posts | 編集者 | ✅ 正常 |
| create_post | 編集者 | ✅ 正常 |
| get_settings | 管理者 | ❌ 403 |
| wp_health__test_auth | 管理者 | ❌ 403 |
無実だったプラグインたち
今回の騒動で無効化・調査したプラグインやセキュリティ設定は、すべて無関係でした。
- WP Fastest Cache：.htaccessを書き換えていたが、無効化しても403は続いた → 無関係
- CloudSecure WP Security：セキュリティプラグインだが、無効化しても403は続いた → 無関係
- Xserver WAF：XSS・SQL・PHP等の6項目を確認したが、REST APIの権限制御とは無関係
最終確認として、両プラグインを再有効化した状態で get_taxonomies を実行したところ正常に動作しました。環境は最初から正常だったのです。
一番の失敗：Claudeの思い込みに振り回された
今回最大の問題は、Claudeが「wp_health = 接続確認ツール」「403 = 接続失敗」と思い込み、その前提を疑わなかったことです。
その結果、ユーザーは本来まったく不要だった以下の作業をさせられました。
- プラグインの無効化・再有効化
- WAFの各項目調査
- アプリケーションパスワードの再生成
- Claude Desktopの複数回再起動
- .htaccessの内容確認
「低権限エンドポイントから順に確認する」という基本的なデバッグ手順を踏んでいれば、これらの作業のほとんどは不要でした。
正しいMCP接続確認の手順
今後の再発防止のために、正しいデバッグ手順をまとめます。
Step 1：低権限エンドポイントで疎通確認
get_taxonomies ← 認証不要・公開情報。まずここから。✅ 通る → ネットワーク・サーバーは正常
Step 2：編集者権限エンドポイントで認証確認
get_posts または create_post（下書き）← 認証が必要。✅ 通る → 認証（アプリケーションパスワード）も正常
❌ 失敗 → パスワードの確認、保存忘れがないか確認
wp_health系は使わない
管理者権限が必要なため、編集者権限の環境では常に403が返ります。接続確認には使用しないこと。
読者・ユーザーへの教訓
MCP連携でトラブルが発生したとき、最初にClaudeに伝えるべき情報があります。
「このサイトのMCPユーザーは編集者権限です。接続確認は
get_taxonomiesなど低権限エンドポイントから順に試してください。wp_health系は使わないでください。」
この一言をセッション冒頭に伝えるだけで、今回のような無駄なデバッグを防ぐことができます。AIは間違った前提で動き続けることがあります。ユーザーが正しい制約条件を最初に伝えることが、AI活用の重要なスキルです。
まとめ
| 項目 | 内容 |
|---|---|
| 真の原因① | アプリケーションパスワードの保存ボタン押し忘れ |
| 真の原因② | wp_healthは管理者権限が必要（編集者権限では使えない） |
| Claudeのミス | 403=接続失敗と思い込み、低権限エンドポイントから試さなかった |
| 無関係だったもの | WP Fastest Cache・CloudSecure・Xserver WAF・.htaccess |
| 再発防止策 | 接続確認はget_taxonomiesから。セッション冒頭に権限を明示する |
MCP連携は非常に便利な仕組みですが、AIの思い込みに振り回されないためには、ユーザー側からの適切な制約条件の提示が重要です。この記録が同じ環境で構築する方の参考になれば幸いです。
コメント
このパターンにはまった場合、初心者はAIに振り回されて数日間を棒に振る可能性があります。最悪の場合、放棄するかもしれません。いあー。まだまだ、MCPはエンジニアレベルの絶賛開発中ツールでしょうかね。 このようなトラブルをサクッと解決できる人しか生き残れないのか？。。。 厳しいな。