Claude Design MCPが403で接続できない原因と対処手順
Claude Design MCPが403で落ちるのは、ログインのトークンにデザイン用のスコープが付かないためです。/design-loginで通る条件と、再発や拡張機能、OAuth再実行が効かない理由を解説します。
Claude CodeからClaude DesignのMCPサーバーに繋ぐと、毎回 FIRST_PARTY_AUTH_REJECTED(HTTP 403)で失敗する。claude.aiのWeb画面ではClaude Designが普通に使えるのに、です。GitHubのissue #92215に同じ報告が積み上がっており、最後のコメントは10月2日で、issueは未解決(open)のままです。
結論から書きます。原因は設定の誤りではなく、ログインで得たトークンにデザイン用のスコープが入っていないことです。端末の claude で /design-login を実行し、新しいセッションを開くと通る例が報告されています。ただし、数日で再発する例もあります。
403のメッセージで何が起きているか
報告されているエラー文は次の形です。
FIRST_PARTY_AUTH_REJECTED: api.anthropic.com rejected your claude.ai login
for Claude Design (HTTP 403) ... Run /design-login and retryclaude mcp list では ✘ Failed to connect の行に、同じ理由が付いて出ます。ログのレベルでは needs_design_scopes と記録された例もあります。
issueの報告者が突き止めた内訳は、次の3点です。
403を生む3つの食い違い
トークンにスコープが無い
通常の
/loginで得るトークンのスコープは、file_upload・inference・mcp_servers・profile・sessions:claude_codeといった一覧でした。サーバーが要求するuser:design:read user:design:writeは含まれていません。別の資格情報は添付されない
MCPのHTTP通信は、ログイン用のトークンしか送りません。デザイン用のトークンを別に持っていても、送信側がそれを選ぶ経路がありません。
OAuthの探索が行き止まり
認可サーバーのメタデータはRFC 8414の2か所のどちらでも404を返します。200になるのはOpenID Connect用のパスだけです。
3つ目は別のissue(#95864)で追跡されています。そこに書かれた提案は、標準のパスで同じ文書を返すか、クライアントが openid-configuration に切り替えることです。どちらも利用者側では直せません。
まず試す順番
通った報告に共通するのは、端末で /design-login を実行してから、新しいセッションでMCPを繋ぎ直した点です。
403から復旧する手順
- 1
端末のclaudeを開く
VS Codeなどの拡張機能のチャット欄ではなく、ターミナルで
claudeを起動します。理由は後の節で書きます。 - 2
/design-loginを実行する
公式のコマンド一覧では、
/design-loginは/design-syncのためにデザインシステムへのアクセスをclaude.aiアカウントで許可するコマンドです。成功すると「Design-system access authorized.」と出た例があります。 - 3
新しいセッションを始める
MCPはセッションの開始時に一度だけ接続します。すでに開いているタブやセッションは、トークンが直っても失敗したままです。閉じて開き直します。
- 4
接続を確かめる
claude mcp listでclaude-designの行がFailed to connectでなくなれば成功です。
claude # 端末で起動し、中で /design-login を実行
claude mcp list # 新しいセッションで状態を確認
claude mcp get claude-design # 失敗時は Issue: 行に理由が出るclaude mcp get <name> の Issue: 行と /mcp の詳細画面には、サーバーが返したHTTPステータスとエラーテキストが出ます(v2.1.219以降)。資格情報らしき文字列は伏せられるので、貼って共有しても漏れにくい出力です。
/design-login と /design-sync の使い方そのものはClaude Code design-syncの使い方にまとめています。サーバー側の接続トラブル全般は/mcp reconnect allで失敗したMCPサーバーを一括再接続するが入口です。
効かなかった操作
403が出ると、次に思いつく操作はたいてい効きません。issueでは次の結果が報告されています。
| 試した操作 | 報告された結果 |
|---|---|
claude mcp logout claude-design のあと再接続 | 報告された結果403のまま。保存済みの資格情報が古いわけではない |
claude mcp login claude-design | 報告された結果「Claudeのログインで自動認証される」と返り、OAuthの手順が始まらない例がある。別の例では廃止済みの /authorize がHTTP 410を返して止まる |
/login をやり直す | 報告された結果通常のログインはデザイン用スコープを要求しないため、直らない |
| claude.aiの「カスタムコネクタ」に同じURLを追加 | 報告された結果「Sign-in endpoint retired」というページに着く |
claude mcp login は、公式のMCPドキュメントではOAuthを端末から直接実行するコマンドです。通常のOAuth対応サーバーなら効きます。このClaude Designのエンドポイントで起きているのは別の問題です。GitHub MCPなど通常のサーバーでOAuthが通らない場合の切り分けは、GitHub MCPサーバーにOAuth接続できないエラーの原因と対処で扱っています。
なお、公式のMCPドキュメントによると、Claude Codeは401や403を返したリモートサーバーを「認証が必要」として /mcp に出します。ただし、設定済みの Authorization ヘッダーを使うサーバーは例外で、403でも認証待ちにはならず接続失敗として扱われます。ヘッダーに固定トークンを置く方法でも、デザイン用のトークンを手に入れる手段が無いので、この問題は避けられません。
数日で403に戻る理由
/design-login で通ったのに、翌日また403になる。この再発を時系列で記録した報告があります。デスクトップアプリとHomebrew版CLIを併用したmacOSの例で、時系列にすると次のとおりです。
| 日時(UTC) | 操作 | 接続 |
|---|---|---|
| 9月14日09:45 | 操作/design-login | 接続繋がる |
| 9月14日21:50 | 操作通常の /login | 接続翌日には403 |
| 9月15日19:42 | 操作/design-login をもう一度 | 接続繋がる(16〜17日に35セッション) |
| 9月17日22:26〜18日12:49の間 | 操作トークンが入れ替わる(/login の記録なし) | 接続以後403 |
| 9月21日11:23 | 操作通常の /login | 接続403 |
この報告者の読みでは、デザイン用スコープは通常のトークンに乗っています。定期的な更新では約28時間残りましたが、/login や入れ替えのタイミングで落ちます。通常のログインも更新も、user:design:read user:design:write を要求しないためです。
この報告者がキーチェーンを見ると、Claude Code-credentials の項目には claudeAiOauth と mcpOAuth だけがあり、designOauth はありませんでした。望ましい形として挙げているのは、デザイン用のアクセスを別枠で保持するか、ログインや更新のたびに要求し直す設計です。
同じバージョン(2.1.271)で9月17日は繋がり、18日は403だったので、バージョンの退行ではありません。実質的には、ログインし直すたびに /design-login が要る状態です。「Claude Designが何度もログインを求めてくる」という体感は、これが原因でした。
運用に落とすと、次の2点になります。
- 通常の
/loginをしたあとは、Claude Designを使う前に/design-loginを打つ - 403に戻ったら、まず
/design-loginを疑う(設定を消して作り直しても変わらない)
VS Code拡張では/design-loginが動かない
拡張機能のチャットで /design-login を打つと、コマンドとして実行されず、ただのテキストとしてモデルに渡された、という報告があります。
その報告のログでは、9月24日から10月2日までの接続が40回すべて403(needs_design_scopes)で、成功は0回でした。入口が判別できた30セッション中20件がVS Code拡張です。10月2日に端末の claude で /design-login を実行すると、直後から16回の接続がすべて成功し、拡張機能のセッションも含まれていました。
つまり、トークンは端末と拡張機能で同じキーチェーン項目を共有しています。許可は端末側で済ませ、拡張機能は新しいタブで開き直せば足ります。拡張機能のタブを開いたままにしても、既存のセッションは復旧しません。
環境によっては/design-loginがそもそも出ない
公式のコマンド一覧には、/design-sync について次の条件が書かれています。claude.aiに接続できない環境、つまりAmazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry・Claude Platform on AWSを使う場合と、Claude apps gateway経由のセッションでは、CLIがclaude.aiと通信しないため、コマンドが使えません。
WindowsのGit Bashで /design-login が「この環境では使えない」と返った報告もあります。同じ報告では、claude mcp login がOAuthを始めず、/.well-known/oauth-protected-resource/v1/design/mcp も404でした。この原因が上のクラウド経由の条件なのか別の理由なのかは、スレッドでは切り分けられていません。
/design-login が一覧に出ないときは、プロバイダー設定とゲートウェイの有無、--disable-slash-commands の指定を順に見ます。詳しい切り分けは先ほどのdesign-syncの記事に書いてあります。
未解決の部分と、進捗の追い方
issueの状態は次のとおりです(最後の更新は10月2日)。
| issue | 内容 | 状態 |
|---|---|---|
| #92215 | 内容403の症状と再現条件。コメントは11件 | 状態open |
| #95864 | 内容認可サーバーのメタデータが標準パスで404 | 状態open |
| #69317・#77620 | 内容過去の同種報告。修正なしでクローズ | 状態closed |
修正が入る側は2つ考えられます。サーバー側が標準パスで文書を返すか、クライアント側が openid-configuration に切り替えるかです。どちらも利用者の手元では完結しません。
直るまでの現実的な運用は、/design-login を端末で済ませる前提にすることです。拡張機能の利用が中心なら、毎回端末を1度開く手間が残ります。要望として出ているのは、拡張機能でも /design-login を実行できるようにすること、エラー文に「端末で実行する」と書くこと、トークン更新後にセッションを開いたまま再接続できるようにすることの3点です。
/design-login を打っても403が続くときは、アカウントがClaude Designの利用対象かどうかを先に疑ってください。エラー文にも「アカウントにClaude Designへのアクセスがあるか確認する」と案内があります。UI案を並べるだけなら、MCPを使わないClaude Code /designの使い方の経路もあります。
この403は「認証の設計上の穴」である
設定ファイルをいくら直しても治らないのは、このエラーが利用者の設定ミスではなく、トークン発行と送信の仕様が噛み合っていないために起きるからです。切り分けは短く済みます。症状が FIRST_PARTY_AUTH_REJECTED なら、まず端末で /design-login を打つこと。それで通れば原因は確定し、再発するなら通常の /login のたびに落ちているだけです。
逆に、サーバー設定の削除と再作成、claude mcp logout の繰り返し、接続待機時間の延長(CLAUDE_CODE_MCP_STARTUP_WAIT_MSでMCP接続待機を変える)は、この403には効きません。待っても403は403のままです。スコープが付く経路が整うまで、/design-login を手元の手順に含めておくのが現状でいちばん手戻りの少ない運用です。