ShopifyカスタマーサポートにHermes Agentを使う：2026年に機能すること

なぜShopifyでHermesを調べたのか

私はeeselでインテグレーションを作っていて、Shopifyは今年、足元で最も大きく変わったものです。eeselのShopify連携は、以前は加盟店にカスタムアプリを作ってトークンを貼り付けてもらう方式でした。その方法はなくなりました。Shopifyが新しい管理画面作成のカスタムアプリの作成を認めなくなったため、Shopifyのインストール画面での承認方式に移行しました。今ストアにHermesをつなごうとする人は同じ壁にぶつかり、この記事の大半はその話です。

Hermes AgentはNous Researchのオープンソースの自己ホスト型エージェントで、MITライセンスのもとGitHubスター251,791個、最新リリースはv2026.9.24です。サポート全般の話はカスタマーサポート向けHermes Agentで、ヘルプデスク版はFreshdeskの記事で取り上げました。Shopifyを単独の記事にするのは、難しいのがヘルプデスクではなく、注文を取得することだからです。

eeselは長年、実際のサポートキューにAIを導入してきましたが、ECのキューはどれも似ています。「注文はどこ？」、「在庫はある？」、「これはどう返品する？」。何度も繰り返し得られる教訓は、リアルタイムの注文データなしの自信満々な回答は、回答しないより悪いということです。Redditのあるショップ運営者はこう率直に語っています。

"One wrong price shown to a buyer kills the tool permanently, and it takes exactly one incident. I've watched it happen."

u/neon_bloom_alchemy, Reddit

つまりHermesに対する問いは「チャットできるか？」ではありません。「注文を見られるか、そして動くべきでないときに誰が止めるのか？」です。

HermesがShopifyストアで実際に見られるもの

ShopifyにはAIエージェントがストアに到達する公式の方法が4つあり、答えられる質問はまったく異なります。設定を1行書く前にこの表を読むことをおすすめします。

最初の行は最近変わりました。ShopifyのStorefront MCPページは、赤いバナーで始まるようになりました。「The catalog and cart tools on https://{shop}/api/mcp were removed.」これらはUniversal Commerce Protocol、つまりShopifyの新しいエージェンティックコマースの標準に移りました。ポリシーツールsearch_shop_policies_and_faqsはそのまま残り、「No authentication is required」とされています（Policy and FAQs tool）。

新しいUCPの注文ツールも役に立ちません。ShopifyのOrder MCPには「You can only fetch orders that were placed through your agent.」とあります。これはエージェントによるチェックアウト向けで、先週の火曜日に買い物客があなたのウェブサイトで行った注文向けではありません。

したがって、サポート業務に必要な入り口はShopifyのAdmin APIだけです。そのordersクエリは、メールアドレスで「to provide customer support」のために絞り込め、注文番号はname:1001で絞り込めます（orders query）。以下はすべてこのルートを前提にしています。

現在HermesがShopify向けに提供しているもの

Hermesにはshopifyに関わるものが3つありますが、どれもサポート用のインテグレーションではありません。

• カタログのMCP項目なし。 Hermesのキュレーション済みの65個のMCPサーバーのカタログに、Shopifyの項目はありません。Stripe、PayPal、Klaviyoはありますが、Shopifyはありません。
• 任意のshopifyスキル。 Nousは「Query Shopify Admin/Storefront GraphQL APIs via curl」を行うコミュニティ製スキルを掲載しています（スキルページ）。これは.envから静的なSHOPIFY_ACCESS_TOKENを読み取ります。
• ShopifyのAI Toolkit。 Shopify公式のAI Toolkitは「Hermes (plugin only)」を対応ツールとして挙げています。これは開発者向けで、ドキュメント、スキーマ検証、自分で実行するストア管理タスクが対象です。私のClaude for Shopifyの解説の背景にあるのと同じツールキットです。

Hermesが検索できるskills.shでは、上位のShopifyスキルはShopify自身のGitHub組織のもので、先頭は17,013インストールのshopify-adminです（skills.sh検索）。上位100件にカスタマーサポート用のスキルは1つもありません。つまり自分で組み立てることになり、Hermesコミュニティの人々が実際にやっていると語る内容とほぼ同じです。優れたサポート用ツールの構成については、私のカスタマーサポート向けMCPのガイドで解説しています。

安全にセットアップする方法

私ならこの順番で構築します。目指すのは機能する形です。HermesがShopifyを読み取り、ヘルプデスクに下書きを書き込み、人間が送信します。

1. 読み取り専用スコープのDev Dashboardアプリを作成する

Shopify管理画面でカスタムアプリを作ってトークンをコピーする従来の方法は閉じられています。Shopifyのドキュメントには「You can no longer create new admin-created custom apps」とあり、新規開発はDev Dashboardに誘導されています（admin-created custom apps）。Hermesのスキルにも同じ変更が記載されています。

Dev Dashboardでは、サポートの照会に必要なものだけを選びます。

• read_orders、read_customers、read_products、read_fulfillments。
• write_ordersは外します。refundCreateに必要なスコープで、返金できないボットは誤って返金することもありません。本当の返金の自動化に必要なのは期待ではなく承認です。
• 60日の制限を理解しておきます。read_ordersがカバーするのは「orders created within the last 60 days」で、それより古い注文にはread_all_ordersが必要であり、これは「you must request access to」とされています（access scopes）。計画しておかないと、3月の注文について尋ねた買い物客は、自信満々の「見つかりません」という答えを受け取ります。

顧客の氏名、メールアドレス、電話番号、住所は保護対象の顧客データであり、アプリが承認されていないフィールドはnullで返されます（protected customer data）。メールの絞り込みが期待どおりの結果を返すと決めつける前に、実際の注文でテストしてください。

2. 24時間トークンに備える

自社ストア上の新しいアプリは、クライアントクレデンシャル付与でトークンを取得します。Shopifyの記述は明確で、expires_inは「Always 86399 (24 hours)」、リフレッシュトークンはなく、「only works when the app and the store belong to the same Shopify organization」です（client credentials grant）。クライアントのストアにHermesをつなぐ代理店は、これをまったく使えません。

Hermesはこのトークンを代わりに発行してくれません。そのMCP設定が受け付けるのは、.envの${VAR}から解決される静的なheadersか、PKCEを使う対話型の認可コードフローであるauth: oauthです（MCP config reference）。クライアントクレデンシャルのオプションはなく、Shopifyスキルも静的なトークンを読み取ります。

私が使う対処法は地味ですが機能します。20時間ごとに新しいトークンを要求し、~/.hermes/.envのSHOPIFY_ACCESS_TOKENを書き換えるcronジョブです。Hermes自身のスケジューラーで実行できます。ただし本番の配管として扱ってください。静かに失敗した朝は、すべての注文照会が401を返す朝になるからです。

3. 生のGraphQLではなく、絞り込んだツールをHermesに与える

コミュニティ製スキルは、HermesにcurlとGraphQL Admin API全体を渡します。その安全上の注意書きには、ミューテーションは「create products, charge refunds, cancel orders」を行うとあり、先にエージェントが「confirm with the user」するよう求めています（スキルページ）。それはプロンプトであって、鍵ではありません。

私は、読み取り専用のクエリを2、3個、自前の小さなMCPサーバーでラップし、get_order_by_number、get_orders_by_email、get_fulfillmentだけを公開する方法を好みます。

mcp_servers:
  shop:
    url: "http://localhost:8787/mcp"
    headers:
      Authorization: "Bearer ${SHOP_MCP_KEY}"
    tools:
      include:
        - get_order_by_number
        - get_orders_by_email
        - get_fulfillment

これはHermesのドキュメントをもとに私が組み立てたもので、公式の例ではありません。includeを設定すると、Hermesはそれらのツールだけを登録します（Hermes MCPドキュメント）。存在しない返金ツールを言いくるめて実行させることはできません。ラッパーがShopifyトークンを保持するので、Hermesはそれを目にしません。

4. 買い物客ではなく、ヘルプデスクに下書きする

Shopifyストアの多くは、Gorgias、Zendesk、Freshdeskのようなヘルプデスクでサポートに対応しており、それぞれ独自のShopifyサイドバーを持っています（GorgiasのShopify設定はこちら）。Hermesにはヘルプデスク用のMCP項目もないため、Freshdesk向けHermes Agentで示した方法で接続し、Hermesには書き込みツールを1つだけ、つまり内部メモを与えます。Zendeskなら、エージェントがすでに使っている同じShopifyインテグレーションに、非公開コメントを加えるだけです。

Hermesコミュニティも同じ形に行き着いています。自分の受信箱でHermesを動かしているあるユーザーは、これが防ぐ失敗をこう説明しました。

"Been training AI to write in my voice and draft replies to emails on my behalf, but my success rate (drafted emails worth using) is approx 50/50. It's learned my voice, it's learned about the business, but 50% of the time it just has to add something wrong enough into the email where I don't or can't use it."

u/SmugglingPineapples, Reddit

eesel自身の数字も、違う言い方で同じことを示しています。ZendeskとShopifyを使うドイツのオンラインジュエリー小売業者が、トライアルで実際のトラフィックにeeselを適用したところ、トリアージ精度は93%、下書きの88%が正しい方向を向いていましたが、エージェントがそのまま送信した下書きは12%にとどまり、約7%に事実誤認が含まれていました。だからこそ、eeselの導入はすべて本番稼働前に過去のチケットでシミュレーションし、送信の前に下書きを挟みます。これはエージェントアシストのパターンで、Hermesにとっても正しい最初の一歩です。

5. トリガーを選び、Webhookヘッダーに注意する

Hermesは、いつ何を見るべきかを知る必要があります。選択肢は3つです。

• リクエスト時。 エージェントがSlackに注文番号を貼ってHermesに尋ねます。最も簡単で、常に人間が関与します。
• cronによるポーリング。 Hermesが数分ごとにヘルプデスクの新しいチケットを確認します。公開エンドポイントは不要です。
• ShopifyのWebhook。 orders/fulfilledやrefunds/createのイベントがHermesに直接通知します。

3つ目には落とし穴があります。ShopifyはWebhookに「a base64-encoded HMAC signature in the X-Shopify-Hmac-SHA256 header」で署名します（verify webhook deliveries）。HermesはGitHub、GitLab、Standard Webhooks、および独自の汎用署名を受け付け、「If a secret is configured but no recognized signature header is present, the request is rejected」となります（Hermes webhooks）。Shopifyのヘッダーはその一覧にありません。

Shopifyの署名を検証してX-Webhook-Signature-V2で再署名する小さなリレー、つまりワーカーやn8nのフローが必要になります。タイミングの細部も2つ重要です。Shopifyはリクエスト全体に5秒しか認めず、APIで作成したサブスクリプションを、4時間にわたる8回の再試行失敗の後に削除します。Hermesはルートごとに毎分30リクエストまでに制限するため、フラッシュセールでのorders/createの急増にはcoalesce設定が必要です。

Shopify FlowのSend HTTP requestアクションも別のトリガー元で、シークレットと最大24時間の再試行に対応しており、Shopifyの自動化全般への入り口としても悪くありません。Shopify側の詳細は注文Webhookトリガーの記事をご覧ください。

6. 信頼する前に、先月のチケットでテストする

Hermesにはリプレイモードがありません。準備ができているか知るには、解決済みのWISMOと返品のチケットを100件取り出し、サンドボックスのプロファイルでHermesに処理させ、その下書きをチームが実際に送った内容と比較します。評価は2点です。正しい注文を見つけたか、そして注文データの裏付けがないことを言っていないか。

まさにこの構成を扱ったRedditのスレッドに、私が見つけた中で最良の一行の警告がありました。あるユーザーが、推測しないようHermesのSOUL.mdファイルに厳格なルールを書くことを提案しました。その返信です。

"Telling it not to hallucinate seems...unlikely to succeed."

u/Sjsamdrake, Reddit

もっともです。ECサポートチームが最終的に学ぶとおり、でっち上げの回答を防ぐのは、大きな音を立てて失敗する照会と、下書きを読む人間であり、プロンプト内の一文ではありません。テストについては、サポートにおけるAIのハルシネーションのガイドでさらに掘り下げています。

どのShopifyの質問に、どの入り口が必要か？

多くの人が飛ばす部分なので、クリックできる形にしました。買い物客が送る質問を選ぶと、どのShopifyの窓口が答え、Hermesがそこに到達できるかがわかります。

こうして並べるとパターンは明らかで、だからこそ多くの注文追跡チャットボットはWISMOから始めて、返金の手前で止まります。ポリシーの質問は無料です。注文の質問には、アプリ、トークンのジョブ、ラッパーというコストがかかります。お金が動くものは人間に残します。

買い物客が話す場所と、Hermesが聞く場所

データの問題が片付いても、会話がどこで行われるかという問題があります。Hermesのゲートウェイは多数のチャットアプリに対応していますが、Shopifyの買い物客が実際に使うものとは、一部しか重なりません。

• ストアのチャット：不可。 Hermesにはウェブサイト用ウィジェットがなく、多くの人がECチャットボットと言うときに思い浮かべるものがありません。最も近いのはAPIサーバーですが、ドキュメントは「gives full access to hermes-agent's toolset, including terminal commands」と警告しています（API server）。公開のチャットボックスの裏に置くものではありません。
• メール：可。 HermesはデフォルトでIMAP受信箱を15秒ごとにポーリングし、プレーンテキストで返信します（メールのドキュメント）。
• WhatsApp：可、ただし穴あり。 HermesはMeta公式のCloud APIに対応していますが、「Message-template support... is not yet implemented in Hermes」です（WhatsApp Cloudのドキュメント）。テンプレートがないと、買い物客が最後に書き込んでから24時間以上たった後に発送の連絡を送れず、プロアクティブなWhatsAppサポートは除外されます。
• InstagramとMessenger：不可。 どちらもゲートウェイのチャネル一覧にありません。

さらに、アクセスのデフォルト設定があります。「If no allowlists are configured... all users are denied」（セキュリティのドキュメント）。未知の送信者にはペアリングコードが発行され、手動で承認します。見知らぬ相手に応答するにはGATEWAY_ALLOW_ALL_USERS=trueを設定することになりますが、同じドキュメントはターミナルアクセスを持つボットで本番環境では絶対にそうしないよう述べています。Hermesが顧客のためではなく、あなたのエージェントとして作られたことを示す最も明確な印です。

比較として、Shopify自身によるストアフロントチャットの答えはShopify Inboxです。Shopifyの移行ページは、コードなしでAIチャットを使いたい加盟店に「use the Inbox agent in Shopify Inbox.」と案内しています。

無料で、5,804件のレビューで評価は4.6ですが、まずセールスアシスタントであり、注文照会には買い物客のサインインが必要です。レビューには、サポートチームが感じる不足点も挙げられています。

"AI agent is great but without a way to handover the conversation to a human agent, I dont think there is a way I can use it 24x7. In fact, I have made the hard decision of turning it off completely."

303 Exclusive Diecasts, App Store

Shopifyは、エージェントは「always shows buyers an option to connect to staff after every message」と返信しているため、設定の問題の可能性もあります。また、Shopify Sidekickはこの用途には向きません。「Sidekick can't talk to your customers or handle customer support conversations on your behalf」とされています（Sidekickのセットアップ）。

ShopifyでHermesを動かす実際のコスト

ライセンスは無料で、ShopifyのAdmin APIには呼び出しごとの料金がありません。費用は、それ以外のあらゆるところにかかります。

モデルのトークン。 Nous Portalは、Freeが0ドル、Plusが月額20ドルで22ドル分のクレジット、Superが100ドル、Ultraが200ドルです。対象のChatGPTプランを推論用に接続することもできます。

Shopifyのレート制限。 お金はかかりませんが、照会の速度に上限を設け、ストア上の他のすべてのアプリと共有されます（rate limits）。

サポートの照会が消費するポイントは小さいため、下書き作成で問題になることはまれです。夜間の評価ジョブとレポートアプリが同時に同じストアにアクセスしたときに問題になります。プランの料金自体は、私のShopifyの料金の解説をご覧ください。

配管。 トークン更新ジョブ、Webhookリレー、読み取り専用のMCPラッパー、ヘルプデスクとの接続、評価ハーネス。それぞれ週末1回分の作業です。合わせると、これから保守していく小さなプロダクトになります。あるHacker Newsのユーザーが自社のビジネスツールにHermesをつないだ話は、顧客向けではなく社内での成功例でした。

"I've added MCP servers to my internal business tools (Elixir apps) and can chat with the Nous Hermes agent over Telegram about pending orders, inventory level, historical product prices, etc., without having to click/dick around with a web UI."

leansensei, Hacker News

それが最適な使い方であり、注目に値します。エンジニアリング面の数字については、私の自社開発と購入の比較で示しています。

ShopifyでHermesが機能しなくなるところ

ここまでの内容は、下書きという形を前提にしています。Hermesを買い物客に直接向けると、私のサポートレビューで述べた壁にぶつかります。

• 承認はチャットしている相手に行く。 メッセージングプラットフォームでは、Hermesはyesやapproveの返信を「waits for the user to reply」します（セキュリティのドキュメント）。買い物客とのWhatsAppスレッドでは、そのユーザーは買い物客です。しかもこの関門はシェルコマンドを対象とし、APIコールは対象外です。
• メモリはプロファイル単位。 組み込みメモリはMEMORY.md（2,200文字）とUSER.md（1,375文字）で、そのプロファイルが実行するすべてのチャットで共有されます（メモリのドキュメント）。買い物客の詳細を保存させないでください。
• Webhook実行は人に確認できない。 Webhookのような無人のサーフェスでは、危険なコマンドはデフォルトで拒否されます。安全面ではよいことですが、注文イベントの実行は下書きかアラートしかできません。
• 60日の窓。 上で述べましたが、エラーではなく誤った回答を生む点がこれです。

本番投入を考えている人へのHermesコミュニティの助言は、私のものと同じです。

"Yes, but I would start with it as a draft-and-escalate helper before letting it answer everything live. For local customers, the dangerous cases are usually not the repeated FAQ questions. They are the almost-FAQ questions."

u/deelight_0909, Reddit

「ほぼFAQ」こそ、ECのキューを埋め尽くすものです。WISMOの質問に「ついでに住所も変更できますか？」が付いているような質問です。

Shopifyサポートで比較するHermes、Shopify Inbox、eesel

より広い選択肢については、Shopifyサポート向けベストAIのまとめとShopify向けベストAIヘルプデスクのリストでさらに掘り下げており、Hermes Agentの代替は汎用エージェント側をカバーしています。

ヘルプデスクがGorgiasなら、そのAIは自動化されたやり取りごとに課金されるため、Shopifyストア向けのGorgiasの料金を考慮してください。

ShopifyサポートでHermesを動かすべきか？

両方のドキュメントを読んだうえでの私の結論です。

はい、次の場合は。 こうした作業を楽しめるエンジニアがいて、用途が社内ヘルパーである場合です。チームがSlackでHermesに注文について尋ねる、またはHermesがWISMOの返信をヘルプデスクに下書きして人が送る、といった使い方です。読み取り専用スコープのDev Dashboardアプリ、更新ジョブ、3つのツールのラッパーは妥当な構成で、Hermesのcronがそれを役立つものにします。

いいえ、次の場合は。 ストアのチャットでAIに買い物客と話させたい、返金を実行させたい、追加の承認なしに60日より古い注文を扱わせたい場合です。トークンジョブとWebhookリレーを誰も担当できない場合も同じ答えです。これらはHermesの欠陥ではありません。運用者のために働くよう作られた汎用エージェントであり、Shopifyのサポートは、向こう側に見知らぬ人がいる仕事だからです。

ほとんどのストアが行き着く中間の道は、買い物客向けには既製のShopify AIチャットボットやヘルプデスクエージェントを使い、チームに試すのが好きな人がいるならHermesをチーム自身のバックオフィスアシスタントにする方法です。この問いのChatGPT版でも同じ判断をしましたし、オープンソースのチャットボットを使う人々も同じところに行き着きます。

Shopifyサポート向けにeeselを試す

今週、ShopifyストアでAIに「注文はどこ？」へ答えさせたいなら、eeselはあなたのカタログをすでに知っている新しいサポート担当者のように働きます。Shopifyのインストール画面で承認するだけで、貼り付けるトークンはありません。Gorgias、Zendesk、Freshdesk、または独自のチャットウィジェット内で、番号やメールで注文を照会し、追跡を確認し、商品をリアルタイムで読み取ります。返品、住所変更、返金、キャンセルは、それぞれ人間の承認を待てます。これはHermesなら自分で構築する必要があるガードレールです。

Hermesを使う人たちにも馴染みやすいはずです。eesel CLIは、同じチームメイトをターミナルから動かします。eesel integrations connect shopifyでストアを接続し、eesel approvals listで承認待ちの返金を確認でき、Claude CodeやCursorのようなコーディングエージェントからも操作できます。料金はシンプルです。100クレジット無料、その後は500クレジットで月額299ドルからのプランで、チケットまたはチャット1件が1クレジットです。照会が何回必要でも変わりません。ご自身のストアでeeselを試す。