import { Callout } from '@/components/ui/callout';
Claude Code で MCP サーバーを使っていると、ある日急にこんなエラーが流れてきます。
sdk auth failed: incompatible auth server: does not support dynamic client registration
あるいはもっと素っ気なく、
authorization failed
最初に見たときは「設定を間違えたかな」と思いましたが、調べてみると Claude Code 側のアップデートと MCP サーバーの仕様の食い違いが裏側で起きていることが多いと分かりました。ここではエラーが何を伝えようとしているのかを根本から整理して、確実に効く対処手順を共有します。
なぜこのエラーが出るのか — 仕様レベルでの整理
Claude Code は最近、MCP サーバーへの接続認証に OAuth 2.1 + Dynamic Client Registration（RFC 7591） を採用するようになりました。Dynamic Client Registration というのは、MCP クライアント（この場合 Claude Code）が、サーバー側にリアルタイムで「私はこういうクライアントです」と登録する仕組みです。
この方式の良いところは、利用者が事前に Client ID と Client Secret を発行・配布する必要がないことです。インストールしたその日から OAuth が動きます。一方で前提として、MCP サーバー側がこの動的登録エンドポイントを実装している必要があります。
Claude Code が出すエラー文言を読み直してみましょう。
incompatible auth server: does not support dynamic client registration
つまり「あなたが繋ごうとしている認証サーバーは、動的クライアント登録に対応していません」と言っています。これはサーバー側の実装が古い、あるいはそもそも別の認証方式（事前発行の Client ID 方式）を採っているケースで発生します。
エラーが出る代表的な3パターン
私がこれまで遭遇したケースを整理すると、ほぼ次の3つに収まります。
パターン1: 自社 / OSS の MCP サーバーが動的登録に未対応
OSS の MCP サーバーや、社内で実装したサーバーで一番よく出るパターンです。/.well-known/oauth-authorization-server メタデータを見たとき、registration_endpoint フィールドが無い、もしくはエンドポイント自体が 404 を返すと、Claude Code 側で「incompatible」と判定されます。
パターン2: SaaS 側が独自の OAuth フローを採用している
SaaS の MCP コネクタの中には、Anthropic とパートナーシップを組んでいる前提で、Client ID を事前にやり取りする方式を採っているものがあります。Slack や Notion の公式 MCP コネクタはこのタイプです。これらは Claude Code の内蔵フローではなく、Cowork など別のクライアントから接続することが想定されています。
パターン3: プロキシや TLS インターセプターで証明書チェーンが切れている
企業ネットワーク内で node_extra_ca_certs の設定が抜けていて、Claude Code が認証サーバーの証明書を検証できないケースです。表面上は authorization failed と出ますが、内部的には TLS のハンドシェイクが失敗しています。これは別のエラー文言が出ることもあるので、コンソールの詳細を確認するのが大事です。
現場で効く対処フロー
エラーが出たら、上から順に試してみてください。
Step 1: /doctor で全体診断
Claude Code の対話セッションで /doctor を打つと、認証・ネットワーク・MCP接続の状況がまとめて出ます。これだけで原因が特定できることも多いので、最初の一歩としておすすめです。
Step 2: MCP サーバーの well-known メタデータを確認
curl https://your-mcp-server.example.com/.well-known/oauth-authorization-server | jq .registration_endpoint がレスポンスに含まれているか確認します。無ければパターン1。
Step 3: 動的登録エンドポイントの動作確認
curl -X POST https://your-mcp-server.example.com/oauth/register \
-H "Content-Type: application/json" \
-d '{
"client_name": "Claude Code Test",
"redirect_uris": ["http://localhost:54321/callback"]
}'ここで 200 系のレスポンスが返ってこないと、Dynamic Client Registration が機能していません。サーバー側の実装を見直すか、サポート対応を待つ必要があります。
Step 4: MCP サーバー側の実装を追加する
OSS の MCP サーバーでよくある構造であれば、TypeScript の場合は @modelcontextprotocol/sdk の最新版が動的登録に対応しています。アップデートして、サーバー設定で OAuth プロバイダのオプションを有効化するだけで治ることが多いです。
// MCP サーバー側のサンプル設定
import { McpServer } from "@modelcontextprotocol/sdk/server";
const server = new McpServer({
name: "my-mcp-server",
version: "1.0.0",
oauth: {
enabled: true,
dynamicRegistration: true, // ← これがポイント
registrationEndpoint: "/oauth/register",
authorizationEndpoint: "/oauth/authorize",
tokenEndpoint: "/oauth/token",
},
});ここで dynamicRegistration: true を入れ、registrationEndpoint を well-known メタデータに正しく公開すれば、Claude Code 側のエラーは解消します。
Step 5: 自前で実装できないときの回避策
サーバーが SaaS で自分の手元で直せない場合は、次のいずれかが現実解です。
- 公式コネクタが用意されているなら、Cowork など別のクライアント経由で使う
- ブラウザ拡張の Claude in Chrome を使うことで MCP ではなく Web セッション経由で繋ぐ
- Claude API を直接叩く別のラッパー実装に切り替える
「全部の SaaS が Claude Code から自然につながる」という世界観はまだ来ていません。SaaS ごとにどのクライアントが対応しているかは、各サービスの最新ドキュメントを確認するのが確実です。
企業ネットワーク特有の落とし穴
企業環境では、TLS インターセプター（ZScaler, Netskope など）が通信を中継するため、Claude Code から見える証明書チェーンが標準のものと異なります。次の環境変数を設定すると解消することが多いです。
export NODE_EXTRA_CA_CERTS=/path/to/your/corporate-ca-bundle.pemこのパスは IT 部門に問い合わせれば取得できます。設定後に Claude Code を再起動すると、TLS ハンドシェイクが通るようになります。
エラーが出ないことを「設計目標」にする
私が個人で運用しているサービスでは、Claude Code 由来の認証エラーをユーザーに見せないために次の工夫をしています。
- MCP サーバーをデプロイする前に、必ず
/.well-known/oauth-authorization-serverと動的登録エンドポイントの両方をテストする - Claude Code をアップデートする前に、開発環境で動作確認してから本番環境を更新する
- エラーが出たときに即座に
/doctorの出力を貼れるよう、運用ドキュメントにテンプレートを用意しておく
「エラーが起きたときの対処」を整理することはもちろん大事ですが、それよりも「エラーが起きにくい構造」を作るほうが日々の安心感に直結します。
次のアクション
このエラーに直面したら、まずは /doctor と well-known メタデータの確認から始めてみてください。原因が特定できたら、上のフローを順に進めれば 9 割のケースは解決します。残り 1 割は SaaS 側の対応待ちなので、その場合は素直に別経路を選ぶのが時間の節約になります。