Hermes Agent を Zendesk に安全につなぐ方法(2026年版)

なぜ Zendesk で Hermes を調べたのか

eesel での私の仕事は連携の構築で、Zendesk は私が最も長い時間を過ごしたヘルプデスクです。これは偶然ではありません。Zendesk マーケットプレイスは eesel の最初の成長チャネルのひとつで、私たちは何年も前から本番の Zendesk キューに AI を載せてきました。何度も戻ってくる教訓は、モデルは簡単な部分だということです。難しいのは、AI が何に触れてよいかを決め、顧客に未熟さが知られる前に準備ができていると証明することです。

Hermes Agent は Nous Research のオープンソースのセルフホスト型エージェントで、MIT ライセンスのもと GitHub スターは 252,613 です。一般的な疑問は Hermes Agent for customer support で、Freshdesk 版は Hermes Agent for Freshdesk で扱いました。Zendesk は独立した記事にします。他のヘルプデスクにはない期限が答えを形作っているからです。

Hermes には Zendesk 専用のものは何も付属していません。厳選された 68 個の MCP サーバーのカタログに Zendesk の項目はなく、Hacker News、Reddit、X で Hermes と Zendesk の組み合わせを説明している人は見つかりませんでした。以下はすべて、両ベンダーのドキュメントとコミュニティのコードから私が組み立てたものですが、どのみち自分で作るならそうなります。

あらゆる構成を左右する Zendesk の期限

Hermes とヘルプデスクを組み合わせるチュートリアルの多くは「API キーを .env に貼る」で始まります。Zendesk では、その助言に有効期限がつきました。Zendesk の OAuth 移行ガイドは冒頭でこう述べています。"Zendesk API tokens will be permanently deactivated on April 30, 2027."

3つの段階は、いずれもこのガイドによるものです。

• 2026年7月28日。 30日間使われなかったトークンは自動的に無効になり、この日以降に作成されたアカウントはトークンをまったく使えません。
• 2026年10月27日。 どのアカウントも、UI からも API からも新しい API トークンを作成できなくなります。
• 2027年4月30日。 残っているすべてのトークンが動かなくなります。

30日ルールはエージェントにとって厄介です。休暇中に一時停止した Hermes の cron ジョブが、戻ったら死んだトークンに当たることがあります。しかも、Zendesk がトークンを廃止する理由は、エージェントに渡すリスクそのものです。"No expiry"、"No scope restrictions"、そして認証リファレンスは、トークンが "can be used to impersonate anyone in the account, including admins." と付け加えています。

OAuth はこれを解決しますが、配管がかなり変わります。アクセストークンの有効期間はデフォルトで30分、最長でも48時間なので、Hermes の config.yaml に静的な Authorization ヘッダーを置いても持ちません。誰かがトークンを更新する必要があります。Hermes は auth: oauth で OAuth を自分で扱えますが、対象はリモート MCP サーバーだけで、Zendesk はまだ向けられるものを運用していません。実際には、更新はあなたが選ぶ Zendesk MCP サーバーの内部で行われるため、そのサーバーを適切に選ぶことが仕事の大半です。トークンの種類については Zendesk API 認証のガイドでさらに詳しく扱っています。

Hermes を Zendesk につなぐ4つの方法

見つけたルートをすべて挙げ、それぞれで誰が Zendesk の認証情報を保持するかを示します。

そして、待っているかもしれないもの、Zendesk MCP Server です。Zendesk は 2026年5月19日に Relate で発表し、脚注に "Early access this summer." と記しました。Zendesk の 2026年9月のリリースノートや早期アクセス一覧にも、一般提供の告知は見つかりませんでした。2026年8月10日に一般提供となった MCP クライアントと混同しないでください。それは Zendesk 自身の AI が他のサーバーを呼び出すためのもので、Hermes には何の役にも立ちません。

今なら reminia のサーバーを選びます。トークン期限の前に OAuth 向けに書き直され、トークンを自動で更新します。README の主張にも同意します。各オペレーターが "with their own Zendesk login," で認可するので、Zendesk は UI と同じ権限をそのまま適用します。何もホストしたくないなら Swifteq が最も簡単で、アカウントあたり月500回の MCP 呼び出しが無料、2026年10月1日からは月 49 EUR ですが、チケットデータは第三者を経由します。Webhook ルートは4番目の選択肢というより引き金です。チケットが届いたことを Hermes に伝えるだけで、実際の操作には他のいずれかが必要です。

安全に設定する手順

私ならこの順序で進めます。手順は細かく見えますが、それぞれ、放置すると痛い目に遭う Zendesk や Hermes の特定のデフォルトがあるからです。

1. Hermes 専用のライトエージェントユーザーを作る

この手順は他のどれよりも重要です。reminia の create_ticket_comment ツールには public フラグがあり、ソースコードでは デフォルトが True です。モデルが public: false を渡し忘れると、「下書き」が顧客への返信としてメールで送られてしまいます。Hermes のツールフィルターはツールを隠せますが、引数を固定はできないので、フィルターだけでは守れません。

Zendesk のロール機能ならできます。Zendesk のライトエージェントのドキュメントによると、"Ticket comments by light agents are private, including the first comment of any tickets they create." つまり Hermes がライトエージェントとして認証すれば、モデルが何を送っても、Zendesk がすべてのコメントを内部ノートにします。

「Hermes (draft only)」のような名前のユーザーを作り、ライトエージェントのロールを与え、すべてのチケット(または下書きを担当するグループだけ)を閲覧可能にします。ライトエージェント席はほとんどの Suite プランに含まれます。Growth は最大50、Professional は100、Enterprise は 1,000、Team はアドオンです。注意点が2つあります。Zendesk は API を使ってライトエージェントに UI 以上の権限を与えることを禁じていますが、この構成はそれをしません。また、席は通常は人のログインなので、その席にボットユーザーを置いてよいか Zendesk の担当者に確認します。だめならフル席を予算に入れ、手順3により重点を置きます。ロール設定の残りは Zendesk のロールと権限で扱っています。

2. 狭いスコープで OAuth クライアントを登録する

Admin Center で Apps and integrations > APIs > OAuth clients に進み、public クライアントを作成します。reminia のサーバーは保存済みシークレットではなく PKCE を使うためです。Allowed scopes を設定します。Zendesk はこれを上限と説明しています。"no token issued by this client can exceed these scopes." 下書きボットなら tickets:read tickets:write users:read hc:read で十分です。スコープを省くと、Zendesk はデフォルトでフルの read write になります。

次に Hermes のライトエージェントとしてサインインし、uv run zendesk-auth を一度実行します。ブラウザを使うのはこの手順だけです。その後はサーバーが自分でトークンを更新し、毎回リフレッシュトークンをローテーションし、ファイルを 0600 の権限で保持します。このフローを選ぶ2つ目の理由は reminia の README から直接引用できます。クライアントクレデンシャルのトークンは "are attributed to the Zendesk user who created the OAuth client," で、たいていは管理者なので、すべてのノートが管理者の書いたものに見えてしまいます。Zendesk の OAuth アプリの手順記事に、クライアントフォームのスクリーンショットがあります。

3. サーバーを追加してツールを絞る

Hermes は MCP サーバーを ~/.hermes/config.yaml の mcp_servers に置き、tools.include でサーバーごとにツールをホワイトリスト化します(Hermes の MCP ドキュメント)。以下は reminia の README と Hermes の構文から私が組み立てたもので、どちらのプロジェクトの公式例でもありません。

mcp_servers:
  zendesk:
    command: "uv"
    args: ["--directory", "/opt/zendesk-mcp-server", "run", "zendesk"]
    env:
      ZENDESK_SUBDOMAIN: "yourcompany"
      ZENDESK_CLIENT_ID: "${ZENDESK_CLIENT_ID}"
      ZENDESK_OAUTH_SCOPES: "tickets:read tickets:write users:read hc:read"
    tools:
      include:
        - get_ticket
        - get_ticket_comments
        - get_tickets
        - create_ticket_comment

update_ticket と create_ticket を外すと、Hermes はステータス変更も再割り当てもできず、新しいチケットも作れません。下書きボットにはどれも必要ありません。Hermes にはサーバーごとの trust キーもあります。untrusted のサーバーでは "every write-capable tool call... requires user approval" となりますが(MCP 設定リファレンス)、デフォルトは full です。誰かが Slack で Hermes を見ているなら、untrusted は各ノートに二重のチェックを与えます。

4. トリガーを選ぶ:チャット、cron、Webhook

Hermes は、いつチケットを見るかを知る必要があります。

• 依頼時。 エージェントがチケット番号を Slack に貼り、下書きを頼みます。人が常にループに入ります。
• cron ポーリング。 Hermes のスケジューラーは60秒ごとに動き、事前チェックスクリプトが {"wakeAgent": false} を出力すれば、新着があるときだけモデルが動きます(cron のドキュメント)。
• Webhook。 Zendesk のトリガーが、https://your-server:8644/webhooks/zendesk のようなルートにWebhookを送ります。

Webhook は最も速い一方で最も面倒です。両側のリクエスト署名が異なるからです。Zendesk は X-Zendesk-Webhook-Signature を送ります。これはタイムスタンプと本文の Base64 の HMAC です(Zendesk のドキュメント)。Hermes は "a recognized signature header" のないリクエストを拒否し、その一覧は GitHub、GitLab、Standard Webhooks、または独自の16進エンコードの X-Webhook-Signature-V2 です(Webhook のドキュメント)。どれも Zendesk の形式と合いません。

橋渡しの方法はありますが、最初から最後まで動かして確認してはいないので、両方のドキュメントの私なりの読みとして受け取ってください。Zendesk の Webhook は、選んだヘッダー名と値を送る API キー認証をサポートしています。Hermes の GitLab 方式は X-Gitlab-Token の単純なシークレット照合です。Zendesk Webhook の API キーヘッダーを X-Gitlab-Token にし、値にルートのシークレットを設定すれば、Hermes は受け付けるはずです。HMAC より弱い(リプレイ保護がない)ので、ルートは HTTPS の背後に置いてください。

さらに2点あります。Webhook の実行はデフォルトのツールセットが狭い状態で始まるため、チケットを読む前にルートへ手動で toolsets: ["mcp-zendesk"] を付与する必要があります。また Zendesk は Webhook ごとに12秒のタイムアウトを設け、タイムアウト時は最大5回再試行するため(Webhook のドキュメント)、遅い Hermes ホストは同じチケットを複数回受け取ることがあります。同じチケットの繰り返しイベントを1回の実行にまとめる Hermes のルート単位の coalesce 設定が役立ちます。

5. 信頼する前に過去のチケットでテストする

最も時間をかけるべきところで、Hermes が最も助けにならないところでもあります。先月のチケットを流して、下書きをチームが実際に送った内容と照らして採点する再生モードがありません。

自分で作ることはできます。増分エクスポート API で解決済みチケットを取得し、サンドボックスのプロファイルで Hermes を走らせて比較します。増分エクスポートは1分あたり10リクエストが上限なので(レート制限)、データセットは一度取得してキャッシュするのが得策です。「十分な品質」の目安は、ナレッジベースで AI を訓練する方法のガイドをご覧ください。

本番稼働の前に、これを確認してください。ボットが実際のキューに触れる前に、チェックが付いていてほしい一覧です。

Zendesk で Hermes を動かすと実際にいくらかかるか

ライセンスは無料です。その周りのものは無料ではありません。

ボットの席。 プランに含まれていればライトエージェント席、なければフルエージェント席です。Zendesk の料金ページでは、年払いで Support Team が $19、Suite Team が $55、Suite Professional が $115(エージェント1人あたり月額)です。他のプランは Zendesk の料金の解説で扱っています。

API の余裕。 Hermes はアカウントのレート制限を他のすべての連携と共有します。役に立つ下書き1件は、チケット、そのコメント、類似チケット、そしてノートの約4回の呼び出しです。

制限値は Zendesk のレート制限のページによります。下書き程度の量なら到達しませんが、Update Ticket エンドポイントにはアカウントあたり毎分100リクエストという独自の上限があり、他で忙しい Zendesk API 連携があれば Hermes の取り分を食うことがあります。

モデルのトークンとサーバー。 自分のプロバイダーキーを持ち込むか Nous Portal のサブスクリプションを使い、ゲートウェイと MCP サーバーを動かす小さな VPS も必要です。

構築コスト。 人が見落とすのがここです。月に約200件の Zendesk チケットを扱うバストラッキング会社のサポートマネージャーが、営業通話で目標を次のように語りました。

"create an application that will be able to handle 60% of the incoming zendesk tickets and know when to pull a real person in for better analysis and resolution."

この一文は製品1つ分です。対応とエスカレーションのロジックがあり、さらに最も難しい「know when」の部分があります。Hermes では自分で作ることになり、トークンと席に加えてエンジニアの工数を払います。自作か購入かの解説で、これを数字にしています。

Zendesk 上の Hermes が行き詰まるところ

ここまでは下書きという形を前提にしていました。Hermes を Zendesk の顧客に直接向けると、一般的なサポートレビューで私がぶつかったのと同じ壁に当たります。

• メモリは依頼者ごとではなくプロファイルごとです。 組み込みメモリは MEMORY.md(2,200 文字)と USER.md(1,375)で、そのプロファイルが動かすすべてのセッションに読み込まれます(メモリのドキュメント)。ある顧客のチケットから保存した内容が、次の顧客のプロンプトに残ります。
• Zendesk への配信先がありません。 Webhook 実行の deliver の選択肢は、チャットプラットフォーム、メール、ログです。回答をチケットに戻すには、常にツール呼び出しを経由します。
• リハーサルがありません。 上で述べたとおりで、私が最も重く見る欠落です。
• ネイティブのボットがすでにあります。 Zendesk AI エージェントはすべての Suite プランに含まれ、Team では1エージェントあたり月5件、Professional では10件の自動解決が含まれ、それ以降は $1.50(コミット)または $2.00(従量課金)です。Zendesk 内に顧客対応ボットがほしいなら、Hermes はヘルプデスクがすでに売っているものを作り直すことになります。

下書き構築について私が見つけた最も正直な描写は、別のヘルプデスクで実際にやっている人のものでした。

"My current set up…Hermes agent logs into front with write only API token and reads whole context of customer thread. Then tries to look in our software for answers. (Unreliable right now). Then writes draft. This has been way harder than I expected. Been a side project for a while. Really focused on it right now. Goal - save CSR 80% of email writing time."

Nolan Gore (@TheNolanGore), X

その形に注目してください。読んで調べ、下書きを書き、送るのは人です。Zendesk でも私が擁護するのはこの構成です。"way harder than I expected" の部分は、配線ではなく情報の検索と品質の基準にあります。

Zendesk における Hermes、Zendesk AI、eesel の比較

より広い選択肢については、best AI for Zendesk のまとめと Zendesk AI alternatives の一覧がさらに詳しく、Hermes Agent alternatives は汎用エージェントを扱います。他のモデル主導の構成を検討するなら、Claude for Zendesk と ChatGPT for Zendesk も同じ配線の疑問に触れています。

Zendesk のキューで Hermes を動かすべきか?

両方のドキュメントとコミュニティのコードを読んだうえで、私の結論はこうです。

動かしてよい場合: これを楽しめるエンジニアがいて、仕事がエージェントがレビューする内部ノートの下書きであり、OAuth クライアントと評価用ハーネスを自分で持つ覚悟がある場合です。reminia のサーバー、ライトエージェント席、4ツールの include リストは、擁護できる構成です。Hermes は、自チームが Slack で問い合わせる社内サポートチャットボットとしてもよく合います。

動かすべきでない場合: AI に顧客へ回答させたい、またはサポートマネージャーが SSH なしで読める AI の全操作の記録が必要な場合です。トークン移行の間、YAML ファイルを保守できる人がいない場合も同じです。どのベンダーにも行う Zendesk のセキュリティの審査が、自分のサーバーに対して行う審査になります。

配線は週末の作業です。その後に残るのは AI のハルシネーションの問題と、その周りのリハーサルやガードレールで、それが AI をキューに載せる本当の仕事です。

Zendesk 向けの eesel

Zendesk のチケットを AI にさばかせたくて Hermes を調べたなら、eesel はまさにそのために作られたチームメイトです。エージェントとしてサインインした状態で承認リンクから Zendesk に接続するので、移行すべき API トークンはなく、ヘルプセンター、マクロ、過去のチケットから学習します(eesel のドキュメント)。

上で挙げた欠落への対応は次のとおりです。

• まずリハーサル。 Simulation スキルが過去の Zendesk チケットを再生し、誰かに返信する前にギャップを採点します。
• 書き込みのレベルを選べる。 内部ノートを残す、ダッシュボードで承認待ちの下書きを保留する、送信する、から選べます。タグ付け、個人やチームへの割り当て、クローズもでき、Zendesk のチケットトリアージもカバーします。
• Zendesk トリガーを内蔵。 すべての顧客メッセージ、最初の1件のみ、チケットのクローズ時、チームメイトがノートに @eesel と入力したときに実行できます。
• シンプルな料金。 スレッドの長さにかかわらず、チケット1件が1クレジットです。プランは 500 クレジットで月額 $299 から、無料プランには 100 クレジットが含まれます。

Hermes の魅力の半分がターミナルだったなら、eesel にもあります。eesel CLI はダッシュボードで見ているのと同じチームメイトを操作するので、一方で設定したものはもう一方にも反映されます。eesel integrations connect zendesk で接続を開始し(承認はブラウザで人が行います)、eesel integrations download start zendesk でヘルプセンター、マクロ、チケットを取り込み、eesel automations でトリガーごとのエージェントの動作を一覧・有効化します。eesel integrations zendesk actions は各アクションを承認設定付きで表示するので、送信が許可されているか下書きだけかをターミナルから確認できます。すべてのコマンドは JSON を出力するため、Claude Code、Cursor、Codex に Zendesk のセットアップ全体を任せられます。詳しくは CLI for customer support の記事をご覧ください。

Hermes は得意な仕事のために取っておいてください。Zendesk のキューには、まず実際のチケットで eesel を試してください。