なぜサポート向けにHermesを調べたのか
私はeeselで連携機能を作っているので、1週間の大半をヘルプデスクのAPIの中で過ごし、AIに何を触らせてよいか、何を触らせるべきでないかを考えています。eeselは何年も前から実際のサポートキューでAIを動かしていて、何度も学び直す教訓は地味ですが高くつきます。問題になるのはモデルではなく、その周りの配管です。誰が話しかけられるのか、何を覚えるのか、何を送ってよいのか、そして準備ができたとどう確かめるのか。
そこで「これをそのままサポートに使えない？」という会話にHermes Agentが何度も登場したので、その視点でドキュメントを端から端まで読みました。これは本格的なソフトウェアで、GitHubスター251,479件、9月24日の新リリースがあります。問題は良いかどうかではなく、サポートキュー向きの作りかどうかです。
魅力は本物で、気持ちはよく分かります。eeselを解約したある顧客は、去り際に創業者へこう伝えました。
"But long term we will just build our own, which is so possible now with AI."
解約したミッドマーケットの顧客から、eesel創業者への返信より
Hermesをサポートに使えないかという検索の多くは、まさにこの考えが背景にあります。妥当な考えです。この記事では、Hermesで「自前で作る」とは実際に何を意味するのかを説明します。
Hermes Agentとは何か
Hermes Agentは、Nous ResearchがMITライセンスで公開しているオープンソースのセルフホスト型AIエージェントです。手元のマシンやサーバーで動き、セッションをまたいで記憶を保ち、経験から自分でスキルを書き、ゲートウェイ経由でチャットアプリから呼び出せます。Nousはこれを、小さなVPSからGPUクラスターまで"lives wherever you put it"なエージェントと説明しています（ドキュメント）。
サポートチームにとって重要な点は、これが運用者のために作られた汎用エージェントだということです。ヘルプデスク製品ではなく、そのふりもしていません。240ページあるドキュメントのエクスポート全体で"helpdesk"と"support ticket"を検索しましたが、ヒットはゼロでした。最も近い言及は、プロファイル配布のページにある"customer-support bot"の例と、Slackのページにある"a support triage channel"だけです。
これは批判ではありません。汎用エージェントは特定の仕事に閉じ込められていないからこそ役に立ち、だからオープンソースAIエージェントのまとめでOpenClawと並んで登場します。製品そのものについてのより詳しい評価はHermes Agentレビューにあります。
Hermesをサポートにつなぐ2つの方法
私が見てきたHermesのサポート向け構成は、2つの形のどちらかに分類され、リスクは大きく異なります。
担当者の裏側。 Hermesがチケットを読み、アカウント情報を取得し、返信を下書きします。人が確認して送信します。これは実質的に部品から組み立てたエージェントアシストで、現時点でHermesが得意とする領域です。
顧客の前。 顧客がWhatsApp、Telegram、メール、Webチャットで直接Hermesにメッセージを送り、Hermesが自力で返信します。これはAIヘルプデスクエージェントの仕事で、設計がほぼ毎ステップで抵抗してくる領域です。
以下の大半は、この2つ目の形が見た目より難しい理由と、安全にするために何を作る必要があるかについてです。
形1：下書きアシスタントとしてのHermes（これは機能する）
私が見つけた最良の実例は、小規模事業のオーナーがHermesをFrontにつないだケースです。
"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."
形に注目してください。読む、調べる、下書きする、止まる。送信はしません。同じスレッドの別の返信は、ナレッジ側に触れていました。
"yes this is close. easiest version is to have an FAQ document that it references. best way to build that is to point your agent at old emails"
私のルールはこれに加えて、ミスが退屈なほど減るまで送信は人のワンクリックの後ろに置くことです。これはキュー上のどのAIにも通じる助言で、サポートにおけるAIのハルシネーションで痛い目を見て学んだことと一致します。先に検索、最後に送信です。
同じパターンは社内サポートでも見られます。あるHacker Newsのユーザーは、HermesをBigQuery、Stripe、Amplitudeにつなぎ、"nontechnical teammates can ask and answer their own data questions via Slack. It works great!"と書いています（brettcvz, Hacker News）。別のユーザーは、毎日のcronジョブで更新されるWikiをもとに"answers most of both my emails and slack messages"と報告しています（igorhvr, Hacker News）。自社スタッフ向けの社内サポートチャットボットが目的なら、Hermesは妥当な選択です。
ヘルプデスク接続のしくみ
ここに最も時間を見込むべきだと考えます。Hermesは、config.yamlのmcp_serversに設定するMCPサーバー経由で外部ツールに接続し、サーバーごとのフィルタリングで公開するツールを絞れます（MCPドキュメント）。Nousはスタッフが審査した68サーバーの厳選MCPカタログも提供しています。
その68件にZendesk、Freshdesk、Gorgias、HubSpot、Help Scoutは含まれていません（カタログディレクトリ）。選択肢は次のとおりです。
| 方法 | 内容 | 誰が審査したか |
|---|---|---|
| ベンダー自身のMCPサーバー | 例：Front公式のサーバー。私のClaude for Frontの記事で解説 | ヘルプデスクのベンダー |
| skills.shのコミュニティスキル | zendesk-automation（4,053インストール）、Freshdesk（652）、Gorgias（59）、skills.sh検索による | Nousの誰も審査していない |
| 自前のMCPサーバー | ヘルプデスクのAPIに対して自分で書く | 自分 |
コミュニティスキルは、Hermesが公開レジストリからインストールできるサードパーティのコードです。顧客チケットに書き込めるAPIトークンを渡す前に、私なら全行を読みます。既存のパターンから始めたい場合は、カスタマーサポート向けMCPのガイドで、サポート用MCPサーバーが公開すべきものとすべきでないものを説明しています。
形2：顧客の前に立つHermes（ここで破綻する）
連携担当者の目でドキュメントを読むと、ここが面白くなります。ゲートウェイは印象的で、Telegram、Discord、Slack、WhatsApp、Signal、SMS、メール、Microsoft Teams、LINEなど、比較表に約29のプラットフォームが並びます（Messaging Gateway）。
問題はチャネルではありません。4つの設計上の選択で、どれも個人用エージェントにとっては妥当な初期設定ですが、公開のサポートチャネルでは現実のギャップになります。
1. 見知らぬ人を締め出すように作られている
ゲートウェイ自身の言葉です。"By default, the gateway denies all users who are not in an allowlist or paired via DM. This is the safe default for a bot with terminal access"（ドキュメント）。未知のユーザーには1回限りのペアリングコードが発行され、運用者が手動で承認し、コードは1時間で失効します。
10人のチームなら成り立ちます。会ったこともない顧客が次々に来る状況では成り立ちません。開放するスイッチはありますが、セキュリティチェックリストには"never use GATEWAY_ALLOW_ALL_USERS=true in production."とあります。これは真剣に受け止めるべきで、理由は次の点で分かります。
2. ユーザー階層が制限するのはコマンドで、ツールではない
Hermesには管理者とユーザーの区分がありますが、現時点で制限されるのはスラッシュコマンドだけです。ドキュメントには"Plain chat is not affected"とあり、ツールへのアクセスも同じ区分に"as we add them"紐づける予定だと書かれています（ドキュメント）。つまり、一般のチャットユーザーは、そのプロファイルが持つツールセット全体を備えたエージェントと話すことになります。
承認にも関連する問題があります。メッセージングプラットフォームでは、Hermesが危険なコマンドを実行しようとすると、"sends the dangerous command details to the chat and waits for the user to reply"という動きになります（セキュリティドキュメント）。顧客向けチャネルでは、そのチャットにいるのは顧客です。これはドキュメントの流れからの私の推論ですが、ローンチ前に否定しておきたい類のものです。
3. メモリーは顧客ごとではなくプロファイルごと
組み込みメモリーは2つの小さなファイル、2,200文字上限のMEMORY.mdと1,375文字上限のUSER.mdで、セッション開始時にシステムプロンプトへ注入されます（メモリードキュメント）。ドキュメントには"Memory is scoped per profile by design."とあります。
チャットの履歴はユーザーごとに分離されていますが、メモリーは違います。顧客Aとのチャット中にHermesがメモを保存すると、そのメモは同じプロファイルの顧客Bの次のセッションに読み込まれます。ドキュメントははっきり書いていませんが、メモリーの範囲設定から導かれることで、データプライバシーの審査に落ちる典型的な顧客間漏えいです。文書化された対策は、ユーザーごとに別プロファイルを使うか、"each user their own peer"を与えるHonchoメモリーアドオンです（Honchoドキュメント）。
4. プロンプトインジェクションのスキャン対象はファイルで、チャットではない
Hermesはコンテキストファイルとメモリーエントリーをインジェクションのパターンでスキャンしますが、ドキュメントも"These patterns are heuristics, not semantic intent detection"と率直に述べています（セキュリティドキュメント）。受信した顧客メッセージ内のインジェクションを防ぐ指針は見つかりませんでした。コミュニティも気づいています。
"If you re-use the Hermes agent, what are the cost and security implications? One Docker container per-customer sounds like it would be really expensive. Are they started on-demand, or run 24/7? What keeps users from using the agents for general purpose tasks, protects against prompt-injection, etc?"
この4つはどれもバグではありません。個人が自分のために動かすエージェントとしては正しい初期設定です。ただ、公開のWebサイト向けAIチャットボットが必要とするものとは正反対なのです。
Webサイトのチャットウィジェットは？
ありません。ドキュメントにある「ブラウザー」経路はOpenAI互換のAPIサーバーで、その警告自体が"gives full access to hermes-agent's toolset, including terminal commands."と述べています。サイト上のチャットにするには、そのキーの前にフロントエンドと堅牢なプロキシを自作する必要があります。
メールのほうがカバーされています。HermesはIMAP受信箱を15秒ごとにポーリングし、スレッド内にプレーンテキストで返信し、なりすましの送信者がセッションを乗っ取れないようDMARCまたはアライメントされたSPF/DKIMを確認します（メールドキュメント）。既定では未知の送信者は黙って無視されます。安全ですが、メールを送った顧客には何も返らないということでもあります。メール対応についてのより広い見方はメールサポートを自動化する方法をご覧ください。
Hermesにできない唯一のこと：過去のチケットでのリハーサル
これは私が最も重視するギャップです。このステップに何度も助けられたからです。Hermesには本物の安全機能があります。複数のターミナルバックエンドにまたがるサンドボックス実行、危険なコマンドを自動拒否するsmartモードのコマンド承認、無人のcronやwebhookセッションに対する既定拒否のルールです（セキュリティドキュメント）。これらは悪い操作を封じ込めます。
Hermesにないのは、本番前に、先月のチケットにどう答えていたかを見せる手段です。再生も、採点付きのドライランもありません。サポートでは、このリハーサルによって、顧客より先に自信満々の誤答を見つけられます。それがなければ、最初の本番テストの相手は顧客です。
もちろん、評価用のハーネスを自作することもできます。過去のチケットを数百件取り出し、サンドボックスでHermesに通し、チームが実際に送った内容と照らして下書きを採点します。エンジニア1人の週末プロジェクトとしては十分ですが、ポリシーが変わるたびに続く作業でもあります。
サポートチームにとってのHermes Agentの費用
ライセンスは無料です。運用は無料ではなく、請求には想像以上に多くの層があります。
お金がかかるのはNous Portalです。プリペイドのクレジットプランを販売していて、有料の各ティアは価格の110%を使えるクレジットとして返します（Nous Portal）。
| ティア | 価格 | 月間クレジット | 繰り越し上限 | 内容 |
|---|---|---|---|---|
| Free | $0 | $0 | n/a | 無料モデルのみ、ホスト型ツールなし |
| Plus | $20/月 | $22 | $10 | 200以上のモデル、ホスト型ツール、高いレート制限 |
| Super | $100/月 | $110 | $50 | Plusと同じで、残高がより大きい |
| Ultra | $200/月 | $220 | $100 | Plusと同じで、残高が最大 |
予算を立てる前に知っておきたい点がいくつかあります。
- モデルはトークン単位の課金です。 カタログには100万トークンあたりの現行価格が掲載され、全モデルが最低20%割引です（モデル）。8月からの新機能として、Nous Portalでは、サブスクリプションの代わりに対象のChatGPTプランを推論用に接続することもできます。
- ホスト型ツールは使用量課金です。 Web検索、ブラウザー、音声、画像のツールは同じ残高から引かれ、使用ごとの料金は私が読めるページには公開されていません。
- Hermes Cloudはデプロイに最低10ドルのクレジットが必要で、"scales to zero when idle"です（Hermes Cloud）。インスタンスの料金はログインの先にあります。
返信1件あたりなら安く済むことがあります。HermesをWhatsAppで動かしているあるビルダーは、コストを"~$0.005 per reply"としています（dandinu, Hacker News）。ただし、個人の番号に紐づく非公式のWhatsApp連携で、"a ban risk I accepted."という前提です。
どの請求書にも現れないコストは、構築そのものです。中小企業向けにHermesを設定しているコンサルタントは、障壁をこうまとめています。
"On top of that, you need API connections, OAuth, tools, permissions, gateways, sources, context, skills. SMB owners won't set that up alone."
このリストが、サポート向けHermesの正直な価格です。自作か購入かの解説で、そのエンジニアリング工数を試算しています。
Hermesをサポートキューに置くべきか
実際にやりたいことに応じて、私ならこう判断します。
要するに、Hermesは自分で運用する人にとって良いエージェントです。カスタマーサポートは「運用者として動く」ことが裏目に出る唯一の仕事です。話しかけてくる相手が、あなたではないからです。
実際のキューには代わりに何を使うか
Hermesを調べた理由が「サポートキューにAIを入れたい」だったなら、その仕事に向くのはキューを中心に作られたツールです。そのギャップを埋めるのがeeselです。
eeselはAIチームメイトのプラットフォームで、ここに合うのはAIヘルプデスクエージェントです。ヘルプデスクにアプリとして参加するので、ヘルプデスクのユーザー、権限、チケット履歴を引き継ぎ、それらの層を自作する必要がありません。上の4つのギャップには、それぞれ組み込みの答えがあります。
- 本番前のリハーサル。 eeselは過去のチケット数百件を再生し、チームが実際に送った内容と照らして回答を採点し、指示の変更を提案します。これはHermesにないドライランで、自信満々の誤答を早く見つける方法です。
- すでにあるヘルプデスク接続。 Zendesk、Freshdesk、Gorgias、Front、Help Scout、HubSpot、そして連携一覧のその他は数分で接続でき、MCPサーバーを書く必要はありません。
- 設計段階から顧客向け。 自信のあるものに答え、残りはきれいな有人対応への引き継ぎで人に渡します。ヘルプデスクがなければ、チャットバブルをscriptタグ1つでサイトに設置できます。
- すべての返信の記録。 アクティビティログには、AIが扱った会話がすべて表示され、チケットへのリンクもあるので、ナレッジベースで学習させ、何が変わったかを確認できます。
Hermesの魅力がターミナルだったなら、eeselにもあります。eesel CLI（@eesel/cli）は、キューを担当する同じチームメイトを操作します。eesel instructionsは常設ルールの読み取りと編集、eesel approvalsは保留中のアクションを人が承認または拒否、eesel activityはすべての実行を一覧表示します。すべてのコマンドがJSONを出力し、書き込みコマンドは--dry-runに対応し、ヘッドレス認証は環境変数で動くため、スクリプトやClaude Codeのようなコーディングエージェントから操作できます。各ワークスペースはMCPサーバーでもあります。詳しくはカスタマーサポート向けCLIの記事をご覧ください。
まず全体像を見たいなら、カスタマーサービス向けAIソフトウェアのまとめが次の一歩に向いています。直接の乗り換え先は、Hermes Agentの代替のリストをご覧ください。
サポート向けGrok Botについても書いており、Meta Museについては別の記事があります。
サポートキューでeeselを試す
実際にチケットを処理してくれるAIが欲しくてHermesを調べたのなら、eeselは配線なしでその仕事をします。Zendesk、Freshdesk、Frontを数分で接続し、ヘルプセンターと過去の返信から学習させ、本番のチケットに答える前に、古いチケットでのリハーサルを確認できます。チケットまたはチャット1件が1クレジットで、プランは500クレジットで299ドルから、無料プランには100クレジットが付き、カードは不要です。
Hermesは、自分とチームのために動かすエージェントという得意分野で使ってください。顧客対応には、eeselを試してみてください。