Claude Zendesk連携 — 非公式MCPサーバーの導入手順

Zendeskのサポートチケットを、要約や返信案の作成を挟みながらClaude Codeから扱えるようにするMCPサーバーがコミュニティから複数公開されています。Zendesk社自身が提供する公式サーバーではなく、いずれも個人・少人数の開発者による実装です。

導入で先に知っておきたいのは、認証方式が変わりつつある点です。Zendeskは従来のAPIトークンを廃止していく予定で、選んだサーバー(reminia/zendesk-mcp-server)のREADMEもOAuthを主に据える書き方に改められました。APIトークンを前提にした手順をそのまま追うと、途中で行き止まりになります。

Zendesk向けMCPサーバーはどれを選ぶか

GitHub上でZendesk向けのMCPサーバーを検索すると数十件がヒットしますが、更新状況とスター数には大きな差があります。スター数と利用実績で最も先行しているのはreminia/zendesk-mcp-serverです。スター数は123、最終pushは2026年8月27日で、Apache 2.0ライセンスで公開されています。開発者はZendesk社に所属するアカウントではなく、個人のreminia氏です。Zendesk社のGitHub組織(github.com/zendesk)にMCPサーバーの公開は確認できません。

このサーバーが対応する範囲は次のとおりです。

reminia版は、チケットの分析と返信案作成を定型プロンプトとして持っています。「このチケットを分析して」「このチケットへの返信を書いて」とそのまま頼めます。

スター数の少ない実装も複数公開されており、GitHub上の説明文だけを比較しても方向性の違いが見えます。

読み取り専用に絞って書き込みを避けたいならjonhnattaのような実装、ヘルプセンター記事の翻訳まで含めて広く使いたいならfruggrのような実装が候補になります。ただしいずれもスター数は十数以下で、reminia版ほど実績が積まれているわけではありません。fruggr版は最終pushが2026年9月29日と新しく、更新の頻度だけならreminia版(同年8月27日)を上回ります。

表のほかにも、mattcoatsworth/zendesk-mcp-server(スター数30、最終pushは2025年4月)があります。koundinya/zd-mcp-server(スター数16、最終pushは2026年6月)もその1つです。前者はスターが多い一方、更新は止まっています。

表のスター数と最終push以外(reminia版以外の認証方式など)は、この記事では個別に確認していません。以降は実績(スター数)で優位なreminia版を軸に手順を示します。

Zendesk公式のAI連携との違い

Zendesk自身も生成AIとの連携機能(Zendesk AI)を提供していますが、これはZendesk管理画面の中で完結する機能で、Claude CodeからMCP経由で呼び出せる公式サーバーではありません。同様に、Claude側の公式Connectors(claude.ai/customize/connectorsで有効化する一覧)にもZendeskは含まれていません。今回扱うのはそのどちらでもなく、claude mcp addでローカルに追加するstdio方式のMCPサーバーです。ブラウザーのclaude.ai本体からは接続できず、Claude CodeかClaude Desktopのローカルセッションで使う機能である点は覚えておいてください。

APIトークンはいつまで使えるか

ZendeskはAPIトークンを次の日程で廃止していきます。Zendeskの開発者向けchangelog(2026年6月1日付のDeprecated)に同じ日程があり、reminia版のREADMEも同じ内容を記しています。Security and authenticationのページでも「API token」に(deprecated)と付いています。

期限まではメールアドレスとAPIトークンの組(ZENDESK_EMAIL + ZENDESK_API_KEY)でも動作し、初回の認証時に非推奨の警告がログに出ます。ZENDESK_CLIENT_IDを設定するとOAuthが優先されるので、古い変数を消さずに移行できます。

もう1つ、期限とは別の理由もあります。APIトークンはアカウント単位でスコープの指定がなく、持ち主のユーザーが持つ権限をそのまま得ます。多くの環境では、そのユーザーは管理者です。OAuthならオペレーター(サポート担当者)ごとに自分のZendeskログインで承認するため、APIの呼び出しにその人の役割・グループ制限・チケットへのアクセス権がそのまま適用されます。コメントの投稿者もその本人になります。

導入前に確認しておきたいこと

Zendeskのチケットには顧客の氏名・連絡先・問い合わせ内容といった個人情報が含まれます。書き込み系のツールまで渡す非公式サーバーを本番のサブドメインにいきなり繋ぐ前に、次を確認しておくと安全です。

• サンドボックス環境があれば先に試す — プランによってはZendeskにテスト用のサンドボックスが用意されています。本番データに触れる前に一度動作を確認します
• 社内の個人情報の取り扱い方針を確認する — 顧客データを外部のAIツールに渡す運用が、自社のプライバシーポリシーや契約上の制約に反しないかを事前に確認します
• 読み取りだけで足りるなら書き込みスコープを外す — 後述のスコープを絞れば、create_ticket_commentなどの書き込み系ツールはZendesk側で拒否されます

Claude Codeに接続する

ステップ1 — OAuthクライアントを登録する

Zendesk管理センターの「Apps and integrations」→「APIs」→「OAuth clients」で新規作成します。READMEの指定は次のとおりです。クライアント種別を「Public」にするのは、このサーバーが各オペレーターの手元で動くため、秘密情報を安全に持てないからです。代わりにPKCE(認可コードの横取りを防ぐ仕組み)が使われます。

Allowed scopesの設定は任意ですが、READMEは設定を勧めています。このクライアントから発行されるトークンが要求できる範囲に、上限をかけられるためです。控えておくのは、作成後に表示される「Identifier」です。これがZENDESK_CLIENT_IDになります。

Zendeskがhttp://localhost:4567/callbackを拒否する場合は、代わりにhttps://localhostを登録し、後述のzendesk-auth --manualを使います。

ステップ2 — リポジトリを取得しビルドする

Python 3.12以上とuvが必要です。

git clone https://github.com/reminia/zendesk-mcp-server.git
cd zendesk-mcp-server
uv venv && uv pip install -e .
cp .env.example .env

.envには2つの値を書きます。

ZENDESK_SUBDOMAIN=acme
ZENDESK_CLIENT_ID=クライアントのIdentifier

ZENDESK_SUBDOMAINはhttps://acme.zendesk.comのacmeの部分です。.envはバージョン管理に含めません。任意の環境変数も2つあります。

ステップ3 — zendesk-authで承認する

uv run zendesk-auth

ブラウザーが開き、自分のZendeskアカウントで承認すると、トークンが手元に保存されます。保存先は既定で~/.config/zendesk-mcp/tokens.jsonで、0600の権限でディレクトリ(0700)の中に作られます。中身は生きた認証情報なので、パスワードと同じ扱いにしてコミットしません。

ブラウザーが開けないリモートシェルや、https://localhostで登録したクライアントでは、貼り付け式のuv run zendesk-auth --manualを使います。承認は原則1回で、以降はサーバー側で更新されます。更新トークンの有効期間はこのサーバーが要求する90日で、その間使わなかった場合やトークンが取り消された場合は、zendesk-authをもう一度実行します。

ステップ4 — claude mcp add で登録する

READMEが示すClaude Desktop向けの設定(command: "uv", args: ["--directory", "...", "run", "zendesk"])は、Claude Codeでは次のコマンドに読み替えられます。認証情報はzendesk-authが保存済みのトークンから読むので、渡す環境変数はサブドメインとクライアントIDだけです。

claude mcp add zendesk \
  --env ZENDESK_SUBDOMAIN=acme \
  --env ZENDESK_CLIENT_ID=クライアントのIdentifier \
  -- uv --directory /path/to/zendesk-mcp-server run zendesk

.envをサーバーの起動時に読み込ませる代わりに、--envでClaude Code側から環境変数として直接渡す形です。

--の位置には理由があります。Claude Code v2.1.285のclaude mcp add --helpでは、環境変数のオプションが-e, --env <env...>と可変長の引数として示されます。可変長の引数を取るため、--で区切らないと、その後ろの語がどこまでオプションの値なのかを判別できません。--を付けずにclaude mcp add zendesk -e A=1 uv --directory /x run zendeskを試すと、error: unknown option '--directory'で止まることをv2.1.285で確認しました。--で区切れば、uvより後ろの--directoryはサーバー側のフラグとして渡されます。

claude mcp add zendesk -- docker run --rm -i \
  --env-file /path/to/.env \
  --user "$(id -u):$(id -g)" \
  -e ZENDESK_TOKEN_FILE=/tokens/tokens.json \
  -v "$HOME/.config/zendesk-mcp:/tokens" \
  zendesk-mcp-server

権限を絞る(読み取り専用にする)

既定のスコープは、このサーバーが公開する全ツールをカバーしています。書き込みが不要なら、ZENDESK_OAUTH_SCOPESでtickets:read users:read hc:readのように絞れます。

スコープは上限であって付与ではありません。トークンは、承認したオペレーター本人に許された範囲を超えられません。スコープ名を書き間違えるとZendeskはトークンを発行するのに、その後の全リクエストを403で拒否します。そのためzendesk-authは、Zendeskが実際に付与したスコープを表示します。設定した値と見比べて確認できます。

プロンプトを使ってみる

接続できたら、まずは定型プロンプトを試すのが手早い動作確認になります。Claude Codeで/と入力するとMCPサーバーが提供するプロンプトが候補に出てくるので、analyze-ticketを選びチケットIDを渡すと、対象チケットの分析結果が返ります。続けてdraft-ticket-responseを使えば、返信案を下書きしてくれます。draft-ticket-responseのプロンプトは、チケットにコメントする前に確認を求めるようモデルに指示しています。ただし送信を止める仕組みではなく、実際の投稿はcreate_ticket_commentが呼ばれたときに行われます。

動作確認とよくあるつまずき

/mcpでzendeskがconnectedと表示されるか確認します。つまずきやすいのは次の点です。

• サブドメインの取り違え — ZENDESK_SUBDOMAINはURLのhttps://{サブドメイン}.zendesk.com部分のみを指定します。フルURLを入れると接続に失敗します
• リダイレクトURLの不一致 — ZENDESK_OAUTH_REDIRECT_URIは、OAuthクライアントに登録したURLと完全に一致させます。ポートを変えたなら、クライアント側の登録も直します
• トークン期限切れの案内が出る — 更新トークンが期限切れか取り消されると、ツールがその旨のメッセージで失敗します。zendesk-authを実行し直せば復旧します
• 401と403の読み分け — サーバーが自動でやり直すのは、Zendeskが{"error": "invalid_token"}付きの401を返したときだけです。スコープ不足やオペレーター自身の権限不足による401・403はそのまま表に出るので、認証の不安定さではなく権限の問題として読めます
• Python 3.12未満 — pyproject.tomlはrequires-python = ">=3.12"を指定しており、それより古い環境では依存解決に失敗します
• uv未インストール — uv venvコマンド自体がuvを前提にしています

接続はできてもツールが反応しない場合の切り分けはMCPサーバーに接続できないときの切り分け手順を参照してください。導入前のMCP自体の仕組みはMCPとは、claude mcp addの構文全体はClaude Code MCP設定ガイドにまとめています。

他のMCPサーバーと組み合わせる

Claude Codeは1つのセッションで複数のMCPサーバーを同時に扱えます。Zendeskサーバー単体でもチケットの分析・返信下書きは完結しますが、GitHubのMCPサーバーを併用すれば「このチケットの不具合報告に対応するissueをGitHubに作って、チケットにもリンクを残して」のように、サポート対応と開発チームへの連携を1つの依頼にまとめられます。用途別のMCPサーバーの組み合わせはおすすめMCPサーバー10選にまとめています。

よくある質問

返信は公開コメントになりますか、内部メモにできますか

create_ticket_commentのpublicは、省略するとtrue(公開コメント)になります。内部メモにしたいときはpublicをfalseにする必要があるので、依頼文で明示します。

チケットのステータスや期限も変えられますか

update_ticketはstatus(new / open / pending / on-hold / solved / closed)、priority(low / normal / high / urgent)、assignee_id、due_at(ISO 8601形式)などを変更できます。スコープをtickets:readだけに絞ると、書き込みはZendesk側で拒否されます。

まとめ

Zendesk向けMCPサーバーはコミュニティ製で、スター数が最も多いのはreminia/zendesk-mcp-serverです。ただし、今から入れるならAPIトークンではなくOAuthで組むのが前提です。

読み取り専用のスコープで始め、書き込みが必要になった時点でスコープを広げる進め方なら、非公式実装に顧客データを渡すリスクを抑えられます。最初の確認は、サンドボックスか本番の一部のチケットに絞ると安心です。