Slack pluginが認証できない原因と対処 — Claude CodeのOAuthエラー

Claude CodeでSlack pluginを認証しようとすると、ブラウザが開かないまま失敗することがあります。エラーは「Incompatible auth server: does not support dynamic client registration」です。原因はSlack側のOAuthサーバーが動的クライアント登録(DCR)に対応していないことで、Claude Codeはv2.1.30以降で回避策を用意しました。

Slack pluginの認証がDCRエラーで失敗する仕組み

/pluginや/mcpからSlackを認証すると、次のようなエラーが出て失敗します。

MCP server "plugin:slack:slack": No client info found
MCP server "plugin:slack:slack": SDK auth error: Error: Incompatible auth server: does not support dynamic client registration
MCP server "plugin:slack:slack": SSE Connection failed: Non-200 status code (404)

Claude CodeはMCPサーバーへOAuth接続する際、まずRFC 7591の動的クライアント登録(DCR)を試みます。これはクライアントIDを認可サーバー側に自動発行させる仕組みです。SlackのOAuthサーバーはこの自動登録に対応していません。事前に登録済みのクライアントIDを渡す方式を前提にしているためです。Claude Code側がDCRを試みて拒否されるのが、このエラーの正体です。

公式ドキュメントも同じ文言を明記しています。「Incompatible auth server: does not support dynamic client registration」というエラーが出た場合、そのMCPサーバーは事前設定済みの認証情報を必要とすると案内されています。GitHub issue #18009では、2026年1月の最初の報告から半年近くにわたり、同じ症状が20件以上のコメントで報告され続けました。Claude Code全体でのプラグイン・MCP連携の位置づけはClaude Code(クロードコード)の解説にまとめています。

なぜ単純なOAuthエラーで終わらなかったのか

このissueが長引いた理由は、原因が1つではなかったことにあります。コミュニティが独自の診断ツールでSlackのOAuthエンドポイントを解析したところ、認可サーバーメタデータのissuerフィールドがhttps://slack.comを返す一方、Claude Codeが問い合わせたディスカバリーURLはhttps://mcp.slack.comでした。RFC 8414はこの2つが完全一致することを要求しており、この不一致自体もDCRの失敗とは別に接続を妨げる要因になっていました。

さらに別の利用者は、マーケットプレイスがSlack pluginの参照先エンドポイントを切り替えたタイミングで、ローカルにキャッシュされた旧版のプラグインだけがDCRを試みて失敗し続けるという、環境依存の症状も報告しています。エラーメッセージは同じでも、原因の層がOAuthプロトコルの実装・サーバー側のメタデータ不備・クライアント側のキャッシュ、と複数にまたがっていたため、issueのコメント欄では時期によって異なる原因が並行して議論されていました。

issueの流れを追うと、2026年2月に上記のissuer不一致の解析が共有され、3月にはコールバックポートとクライアントIDを.mcp.jsonへ手動で書く回避策が広まりました。4月にはプラグインキャッシュが原因だったケースの手順が投稿され、8月にはv2.1.30とv2.1.231での修正を根拠にissueがクローズされています。1つのエラー文言に対して複数の当事者が別々の原因を切り分けていった経緯が、コメント数の多さにそのまま表れています。

バージョンによる対処の違い

Slack plugin特有のこのエラーは、Claude Code側の複数バージョンにまたがって手が入った経緯があります。

v2.1.30がSlackを名指しで挙げて事前設定クライアント資格情報を追加したことで、多くの利用者は最初の壁を越えられるようになりました。ただしこの後もリダイレクトURI側の不一致が別途発生し、v2.1.231での修正までは、事前登録済みクライアントを使う構成でもサインインが通らないケースが残っていました。

現在配布されているSlack pluginは、この一連の修正を踏まえて事前設定済みのOAuthクライアント情報を組み込んだ状態でマーケットプレイスから配布されています。まず試す価値があるのは、Claude Codeをv2.1.231以降に更新し、/pluginからSlack pluginを入れ直すことです。

更新しても直らないときの切り分け

バージョンを更新しても解消しない場合は、次の観点を切り分けます。

プラグインキャッシュが古い版のまま残っている

マーケットプレイスがSlack pluginの参照先を旧エンドポイント(https://mcp.slack.com/sse、クライアントID未設定)から新エンドポイント(https://mcp.slack.com/mcp、クライアントID設定済み)へ切り替えた際、既にインストール済みのプラグインはローカルにキャッシュされた旧版を使い続けていました。プラグインの取得元や更新の仕組み自体はClaude Codeプラグイン完全ガイドにまとめています。この場合はマーケットプレイスとプラグインキャッシュを更新します。

git -C ~/.claude/plugins/marketplaces/claude-plugins-official pull origin main
rm -rf ~/.claude/plugins/cache/claude-plugins-official/slack/

更新後、~/.claude/settings.jsonに"enabledPlugins": {"slack@claude-plugins-official": true}が残っているかを確認します。それからClaude Codeを再起動すると、新しいエンドポイントでプラグインが再取得されます。

独自にSlack MCPサーバーを設定している

公式のSlack pluginではなく.mcp.jsonで自分でSlack MCPサーバーを追加している場合は、事前登録済みのOAuthクライアント情報を明示する必要があります。公式ドキュメントが案内する方法は、Slack開発者ポータルでOAuthアプリを登録し、そのクライアントIDとコールバックポートをclaude mcp addに渡す形です。

claude mcp add --transport http \
  --client-id your-client-id --client-secret --callback-port 8080 \
  slack-mcp https://mcp.slack.com/mcp

サーバーが秘密鍵(client secret)を発行しない公開クライアントの場合は、--client-secretを省き--client-idだけを渡します。登録した資格情報はシステムのキーチェーンや資格情報ファイルに保存され、設定ファイルには残りません。

OAuthメタデータの自動検出そのものが誤動作している

先述のissuer不一致のように、認可サーバー側のメタデータが標準どおりに揃っていない場合、Claude Codeの自動ディスカバリーが正しい認可エンドポイントへたどり着けないことがあります。この場合は.mcp.jsonのoauthオブジェクトにauthServerMetadataUrlを指定し、参照先のメタデータURLを直接固定できます。Claude Codeは通常、RFC 9728のProtected Resource Metadataを/.well-known/oauth-protected-resourceで確認したあと、RFC 8414の認可サーバーメタデータへフォールバックする順で自動検出を行います。この既定の検出チェーンをバイパスしたいときの逃げ道です。

別のエラーメッセージに変わっている

does not support dynamic client registrationとは異なるno_bot_scopes_requestedのようなエラーに変わった場合、原因はClaude Code側ではなくSlackアプリ側のボットスコープ設定にあります。v2.1.81時点のVS Code拡張では、MCPパネルの表示が「Needs Auth」のままでもSlackツール自体は実際には動作していたという報告もありました。パネルの表示だけで判断せず、実際にSlackを操作するツールを呼び出して動くかどうかを確認すると切り分けが早くなります。

DCR非対応はSlack以外のSaaSでも起きる

動的クライアント登録に対応していない認可サーバーは、Slackに限った例外ではありません。GitHub issueのコメントでは、Slack・Google Workspace・HubSpot・Microsoft Graph・Salesforceが並べて挙げられ、いずれも開発者ポータルで事前登録したクライアントIDを使う運用が前提だと指摘されています。MCPの実装がDCRを標準の認証手段として想定する一方、企業が実務で使いたいSaaSほどDCRに対応していない、というねじれが起きやすい構図です。

CHANGELOGの文言はSlackを例に挙げつつ、DCR非対応のMCPサーバー全般を対象にしています。v2.1.30で追加された--client-id・--client-secretのオプションは、Slack以外の自前MCPサーバーがDCR非対応のときにも使えます。v2.1.81で追加されたCIMD(Client ID Metadata Document)対応も同様に、DCRを使わない別の登録方式に対応するサーバー全般が対象です。

なお、ユーザー権限でチャンネル横断の検索や投稿を行いたい場合、公式pluginとは別の経路としてSlack MCPサーバーの使い方で扱っているボットトークン方式のMCPサーバーを使う選択肢もあります。ボットをチャンネルへ個別に招待する運用が前提になる点は、公式pluginのユーザー認証とは異なります。エンタープライズのプライベートチャンネルを横断したい場合、招待の運用コストが選択の分かれ目になります。

まとめ

Slack pluginの「does not support dynamic client registration」エラーは、Slack側のOAuthサーバーがDCRに対応していないことが根本原因です。Claude Codeはv2.1.30とv2.1.231で段階的に対処しており、まずは最新版への更新とプラグインの入れ直しを試します。それでも直らない場合は、プラグインキャッシュの更新、または--client-idを使った事前登録クライアントの明示設定を試すと切り分けられます。エラー文言が変わっていないかをそのつど確認しながら手順を進めると、どの層に原因があるのかを見失いにくくなります。