Hermesとn8nの比較：仕事に合わせた選び方（併用すべき場合も）

チームは、あらゆる自動化をどちらか一方の製品に担わせるべきだと考え、「Hermesかn8nか」を何か月も議論してしまうことがあります。しかし、この2つが得意とする仕事は異なります。n8nは、豊富な連携機能と明示的な制御フローを備えたワークフローエンジンです。Hermes Agentは、解釈が必要な仕事のためにメモリ、スキル、ツールを備えたエージェントランタイムです。問うべきなのは、このステップに必要なのは、データを確実に流す仕組みか、それとも状況に応じた判断かです。

どちらかに初めて触れる場合は、まず「n8nで初めてのAIエージェントを構築する：リードトリアージの全工程」とHermes Agentとは何か、何ではないか、いつ使うべきかを読んでください。Zapier、Make、n8nからプラットフォームを選ぶ場合は、引き続きn8n、Zapier、Makeを比較：最適な自動化スタックの選び方を参照してください。引き継ぎに使うインターフェースについては、公式のHermes APIサーバードキュメント、Hermes webhookドキュメント、n8n HTTP Requestノードのドキュメントを参照してください。Nous Researchは、旧サードパーティー連携ページに相当する、すぐに使えるHermesからn8nへのワークフローを文書化していません。

性質の異なる2種類の仕事

手順が明確な仕事には、検証→APIによる情報補完→CRMへの書き込み→通知という既知の流れがあります。文章の質よりも、再試行、永続的な業務上の冪等性、フィールドのマッピングが重要です。n8nなどのワークフローエンジンは、この種の仕事に適しています。

判断が必要な仕事は、途中の進め方が一意に決まりません。まとまりのない顧客メモを読み、深刻度を判断し、自社らしい文体で返信案を作り、どの資料を引用するかを選びます。ここではメモリとスキルが重要です。Hermesは、この種の仕事に適しています。

ハイブリッドな仕事は、同じ処理経路の前後に明示的な処理があり、途中に範囲を限定したエージェントの判断が必要な場合の候補です。本番での価値は、仮定するのではなく測定しなければなりません。

イベント → n8nで検証 + 永続的な冪等性を確保
         → Hermes APIサーバー :8642 + Bearer認証
         → n8nで戻り値のスキーマを検証
         → 人の承認後に書き込み

この図はアプリケーション構成の例であり、ベンダーが検証した完成済みの連携ではありません。必要な契約がイベントを受信し、その結果を設定済みのログ、GitHubコメント、またはメッセージングアダプターへ渡すことであれば、デフォルトポート8644で動く独立したHermes webhookアダプターを使い、送信元のドキュメントに記載された認証方式を適用してください。

判断基準

候補となるワークフローを5つの軸で評価します。これは編集上の計画に使う目安であり、検証済みの製品選定モデルではありません。左列の特徴が多ければn8nのみ、右列の特徴が多ければHermesのみを使います。同じ処理経路に両方の特徴があれば、ハイブリッドを評価します。

簡単な判断ルール

1. 「テキストの内容による」という条件なしでフローチャートを描けるなら、n8nを使います。
2. 価値を生むステップが、整理されていない文章を読み、慎重な下書きを作ることなら、Hermesを使います。多くの場合、その前にn8nで検証します。
3. SaaS連携と判断の両方が必要ならハイブリッドを試し、一方のツールに他方の役割を無理にまねさせないでください。
4. 人が貼り付けて使うチャットボットの回答だけが必要なら、どちらのワークフロープラットフォームも使わず、チャットを使います。 Hermes Agentとは何か、何ではないか、いつ使うべきかも参照してください。

実際のボトルネックに合わせて、製品の購入かセルフホスティングかを決めてください。CSVのフィールドを移すためだけにエージェントランタイムへ費用をかけるのは無駄です。メモリとスキルを再現するために、壊れやすいn8nのAIノードを五十個組み上げるのも同じく無駄です。

n8nに任せるべきこと

次の処理はn8nに任せます。パターンは「n8nで初めてのAIエージェントを構築する：リードトリアージの全工程」と共通しています。

• webhookの受信とスキーマ検証
• 冪等性の確保と重複排除
• CRM、ヘルプデスク、スプレッドシート、Slackへの認証
• レート制限、再試行、エラー分岐
• 列挙値とスコアに基づく明示的なif／switchルーティング
• 保持したワークフロー実行記録に、明示的な書き込み受領記録と相関IDを加える
• キルスイッチと環境フラグ

n8nでは、軽度の判断を担うAI Agentノードも利用できます。対象となるツールが限定され、明確なJSON契約がある場合には、依然として有効な選択肢です。永続的なメモリ、スキルライブラリ、メッセージングゲートウェイのUX、またはn8nのノードグラフ外で多くのツールを使う必要がある場合は、Hermesへの移行を検討してください。

Hermesが担えること

Hermesに任せる候補には、次のものがあります。

• スキルとして記述した手順（繰り返し使う運用、サポート、リリースのチェックリスト）
• チームの好みや長期的に有効なプロジェクト情報を保持するメモリ。「Hermes Agent導入後の最初の1週間」で説明するメンテナンスと書き込みゲートも適用する
• ツールを使った情報検索を伴う、曖昧な分類と文章作成
• 設定したチャネルで直接利用できるオペレーター向けUX（CLI、Telegram、Discord、Slackゲートウェイ）
• 設定済みの配信先を持つ名前付きwebhookルートを介したイベント駆動型の調査（「巨大な万能プロンプトを使わないHermesのwebhook」を参照）

エージェントに手順の決まった副作用が必要な場合、Hermesは明示的に設定したツール、スキル、またはMCPサーバーを通じて、認証済みのn8n webhookを呼び出せます。これは独自の認証、スキーマ、タイムアウト、冪等性契約を必要とするカスタムアプリケーションの動作であり、Hermes webhookの標準配信先ではありません。Hermes自体を連携基盤として使うより、用途の狭いツールを優先してください。

評価するハイブリッドパターン

n8nが同じワークフロー内でエージェントの結果を受け取る必要がある場合、確認済みのカスタムエンドポイント経路は、HTTP RequestノードからBearer認証付きHermes APIサーバーを呼び出す方法です。応答を受け取る呼び出しには/v1/responsesを使い、n8nがポーリングまたは監視する非同期実行には/v1/runsを使います。このAPIはIdempotency-Keyを受け付けますが、応答キャッシュは5分間だけなので、永続的な冪等性は引き続きn8nか業務システムが担わなければなりません。一方、webhookアダプターが配信IDをキャッシュするのは1時間です。再試行を有意に重複排除するには、安定したX-GitHub-DeliveryまたはX-Request-IDが必要であり、この期限付きキャッシュも永続的な業務上の冪等性を代替しません。

参照フロー：非公開のサポートトリアージ

1. チケット／フォームのwebhook → n8n
2. n8nがメールアドレス、文字数、送信元の列挙値を検証し、スパムを除外してticket_idを付与
3. n8nのHTTP Request → :8642のHermes APIサーバーへ、Authorization: Bearer <API_SERVER_KEY>とアプリケーションの相関IDを付けて送信
4. Hermesのスキルが深刻度を分類し、返信案と不足情報の一覧を作成。ツールは承認済みの情報源に対して読み取り専用
5. n8nが結果を受信またはポーリングし、バージョン付きの応答スキーマを検証。形式不正またはタイムアウトした出力は人のレビューへ送る
6. 人が承認し、n8nがヘルプデスクやCRMへの書き込みを担い、顧客への返信を送信

初期バージョンでは、Hermesから顧客へのメールを自動送信しないでください。リードトリアージ記事と同じガードレールに従い、最終送信は承認後にn8nから行います。

可能であれば、Hermesへ渡す前にn8nでペイロードから不要な情報を削除してください。エージェントに見せるのは、トリアージに必要な最小限のフィールドだけにします。顧客のシークレットや支払い情報をエージェントのメモリに保存してはいけません。

呼び出す方向の選択

MCPとwebhookを併用する必要はありません。公式のHermes MCPドキュメントには、n8nワークフローを調査、管理するためのhermes mcp install n8nが記載されています。インストールするまでは無効で、インストール後はカタログのマニフェストとサーバーコードを実行するため、レビュー済みのツールだけを公開してください。MCPによる管理、APIの要求と応答、webhookによるイベント受信は、それぞれ異なる契約です。

比較表（運用者の視点）

どちらかが「よりAIらしい」ということではありません。担う層が異なります。

アンチパターン

• **HermesをZapierのように使う：**あらゆるSaaSイベントを解析し、その場限りのツール呼び出しで各フィールドへ書き込むと、不完全な再試行機能を自作することになります。
• **n8nを長期メモリとして使う：**AIノードの巨大なシステムプロンプトに人格や手順を詰め込まないでください。Hermesのスキルやメモリ、または意図的な検索機能を備えた外部ドキュメントストアを使います。
• **二重に書き込む：**責任分担を決めないまま両方のシステムからCRMを更新してはいけません。書き込みを担当するシステムを1つに決めます。
• **万能ルートを1つだけ共有する：**請求、人事、GitHubを1つのwebhookで処理せず、用途ごとにルートを分けます。
• **未レビューのコミュニティースキルと本番用n8n認証情報を組み合わせる：**両方のシステムで最小権限を徹底します。

バージョン付きのJSONで、ticket_id、text、severity_hint、correlation_idなどの要求契約と応答契約を定義し、両端で検証してください。callback_urlは、カスタムツールまたはアプリケーションが実装した場合にだけ意味を持ちます。Hermes webhookアダプターはこのフィールドを解釈しません。n8nの実行データとアプリケーションログに相関IDを保持し、その記録を監査証跡と呼ぶ前に、必要な範囲を網羅しているか確認してください。

演習：実際の4つのワークフローで担当を決める

今四半期に自動化したい仕事を4つ選び、それぞれについて次の項目を記入します。

1. トリガーの送信元
2. 手順が明確なステップ（一覧）
3. 判断が必要なステップ（一覧）
4. 担当：n8n／Hermes／ハイブリッド
5. 人による承認を置く場所
6. 「完了」の意味を表す1文

記入例：「パートナー候補から届いた問い合わせ」→手順が明確な処理：検証、重複排除、CRMへの登録→判断が必要な処理：適合性の説明と紹介文の下書き→ハイブリッド→メール送信前に承認→CRMにレコードが存在し、下書きがレビュー待ちになれば完了。

4件すべてがハイブリッドになった場合は、チャネルやMCPを追加する前に、まず小さな縦断スライスを1つだけエンドツーエンドで構築してください。4件すべてがn8nのみなら、Hermesの導入は先送りします。外部連携がなく、4件すべてがHermesのみなら、作っているのは個人用のオペレーターエージェントかもしれません。それ自体は妥当な場合もありますが、自動化プラットフォームの代替とは呼ばないでください。

評価する導入順序の候補

1. スタブを使い、n8nの検証とログ記録の経路を安定させる（LLMは使わない）。
2. 下書き専用スキル、タイムアウト処理、永続的なワークフロー冪等性、応答スキーマ検証を備えたBearer認証付きHermes API呼び出しを追加する。
3. 固定したサンプルを使い、Hermesの下書きと人が作成した基準回答を比較する。内容の異なる二十件のチケットは有用なスモークテストとなり、明らかな失敗を見つけられる可能性がありますが、本番環境でのエラー率を確立するには不十分です。
4. n8nの承認を介して書き込みを制限する。
5. その後で初めて、Hermesのメモリを拡充し、スキルやメッセージングゲートウェイを追加する。

関連記事

• n8nで初めてのAIエージェントを構築する：リードトリアージの全工程
• n8n、Zapier、Makeを比較：最適な自動化スタックの選び方
• Hermes Agentとは何か、何ではないか、いつ使うべきか
• Hermes Agent導入後の最初の1週間：メモリ管理、スキル、ツール承認
• 巨大な万能プロンプトを使わないHermesのwebhook
• AIワークフローにおけるヒューマン・イン・ザ・ループの設計パターン
• Hermes APIサーバー
• Hermes webhookアダプター
• Hermes MCP
• n8n HTTP Requestノード
• n8nドキュメント

目の前の仕事に合わせて選び、実際に使う連携契約をテストしてください。確実にデータを流す仕組みと状況に応じた判断はどちらも必要になり得ますが、APIの要求と応答、webhookイベントの配信、MCPによるワークフロー管理は相互に置き換えられません。