チームが「どのエージェントプラットフォームを選ぶか」という議論に何週間も費やす一方で、本当に問うべきなのは、どの_仕事_がうまくいっていないかです。チャットからいつでもアクセスできることと、長時間にわたってツールを使うことは、同じ仕事ではありません。手順の決まったSaaS連携は、さらに別の仕事です。
この記事では、OpenClawとHermesを運用上の重点に基づいて比較し、n8nをどこに組み込めるかを示します。また、NVIDIAの現行サポートマトリックスでは、OpenClaw、Hermes、LangChain Deep Agents Codeが、テスト済みのNemoClawエージェント経路とされています。同じ表は、Hermesを評価用途に適し、導入手順も文書化済みとする一方、OpenClawと同等の本番対応を明言していません。この記事も特定のアーキテクチャを必須とはせず、DGX Sparkへの導入が実証済みだとも主張しません。
関連するセットアップ項目：OpenClawのゲートウェイ設定、OpenClawのセキュリティ、n8nからHermesへの引き継ぎ、ローカルのOpenAI互換エンドポイント。
一言で表すと
OpenClaw：AIエージェント向けの自社運用型マルチチャネルゲートウェイです。セッション、チャネル、ツールのコントロールプレーンを提供し、Control UIのデフォルトURLはhttp://127.0.0.1:18789/です。Discord、Google Chat、iMessage、Matrix、Teams、Signal、Slack、Telegram、WhatsApp、Zaloなどに接続できます。（公式ドキュメント）
Hermes Agent：Nous Researchが開発する、オープンソースの自社運用型エージェントランタイムです。ターミナルとデスクトップのインターフェース、メッセージングゲートウェイ、永続メモリ、スキル、ツール、cron、ブラウザとコードの実行、サブエージェントへの委任に対応します。Bearer認証APIサーバーとHMAC認証webhookアダプターは、別々の連携インターフェースです。（公式ドキュメント、GitHub）
**n8n：**AIノードと数百の連携機能を備えたワークフロー自動化ツールです。トリガー、検証、コネクター、人による確認、ログ記録など、手順の決まった連携処理に適しています。（公式ドキュメント）
ただし、製品カテゴリが明確に分かれているわけではありません。OpenClawにもツール、スキル、スケジュール実行、エージェントセッションがあり、Hermesにもメッセージング連携があります。以下の表は評価対象を絞り込むためのものであり、どちらかのプロジェクトが他方の役割を担えないことを証明するものではありません。
以下に示すn8nからHermesへの連携パターンは、構成例にすぎません。どちらの提供元も、すぐに使える公式連携として文書化またはサポートしているわけではありません。エージェントの結果をn8nへ返す必要があるワークフローでは、HermesのBearer認証APIサーバーを使い、返されたアプリケーションスキーマを検証してください。HermesのHMAC webhookアダプターは別のインターフェースです。名前付きのイベントルートを受け付け、設定済みの宛先へ結果を送ります。その配信確認は、n8nへ同期的に結果を返す汎用契約ではありません。
判断表
| 仕事 | 推奨候補 | 理由 |
|---|---|---|
| WhatsApp／Telegram／Slackから1日中エージェントにメッセージを送る | OpenClaw | ゲートウェイ、チャネルプラグイン、ペアリング／許可リストが製品の中核 |
| localhostでセッション／設定を操作するブラウザControl UI | OpenClaw | :18789で動くControl UIが文書化されている |
| トリアージ／下書きの結果をn8nへ返す | Hermes APIサーバー | :8642のBearer認証API。/v1/responsesまたは/v1/runsを使う |
| 外部イベントからエージェントを起動し、結果を別の場所へ送る | Hermes webhookアダプター | 名前付き/webhooks/<route>入口は:8644。汎用V2 HMACはタイムスタンプ付き署名を使う |
| 永続的なエージェントメモリ、スキル、ツールを多用する調査 | Hermes | エージェント機能を中心に設計されたランタイム |
| 承認キューを伴うCRM／メール／スプレッドシート連携 | n8n | 明示的なワークフローノードと再試行制御を備える。ただし、アプリケーション側の冪等性は別途設計が必要 |
| NVIDIA NemoClawでテスト済みのエージェント経路 | NemoClaw／OpenShell | NVIDIAはOpenClaw（デフォルト）、Hermes、LangChain Deep Agents Codeをテスト済みとする。ただし、本番対応や機能の同等性は保証されない |
OpenClawとHermesは、どちらもメッセージングとツールを扱えます。判断の基準は、日常的にどの操作面を_運用_したいかです。つまり、チャネルゲートウェイのUXか、推論ランタイムに加えて明示的に選んだAPIサーバーまたはwebhookによる引き継ぎかという違いです。
テスト対象となる共存パターン
A. 非公開のサポートトリアージ
チケットwebhook → n8nで検証＋アプリケーションの冪等性を確保
→ :8642のHermes APIサーバー（Bearer認証）
→ n8nで返却スキーマを検証
→ n8nで人が承認
→ CRM／Slackコネクター
必要に応じて、オンコールエンジニアは、ステータス確認だけに用途を絞った厳格な許可リスト付きOpenClawボットとチャットできます。ただし、監督なしのCRM書き込みには使いません。
B. 常時稼働の運用
n8nがヘルスチェックを定期実行
Hermesがツールを使って異常を調査
OpenClawが許可リスト登録済みのオンコールチャネルへ通知
C. スマートフォンで使う個人アシスタント
OpenClawだけで十分な場合もあります。初期設定を済ませ、自分の番号をペアリングします。execの承認、許可リスト、サンドボックスを意図的に設定してください。ask: "always"は運用者の意図を確認するための制御であり、悪意のある利用者を隔離する仕組みではありません。Bearer認証APIジョブ、または配信先を設定したHMAC署名付きイベントwebhookのほうが、測定した要件に適している場合にHermesを評価します。例示した構成図に含まれているというだけで、2つ目のエージェントシステムを追加しないでください。
同じ担当者が所有し、インターフェース契約もない、役割の重なる3つの「AIプラットフォーム」に資金を投入してはいけません。資金を配分すべき対象は、チャットからの到達性、判断を担うランタイム、手順の決まった連携です。それぞれをどのシステムが担当するか、明確にしてください。
DGX Spark上のNemoClaw／OpenShell
NemoClawは、OpenShellサンドボックス内でエージェントを動かすための、NVIDIAによるオープンソースのリファレンススタックです。NVIDIAの現行サポートマトリックスでは、OpenClaw、Hermes、LangChain Deep Agents Codeがテスト済みのエージェント経路とされています。また、NemoClawはアルファ早期プレビューとされ、本番SLAはなく、HermesとOpenClawが本番環境で同等であるとも明言されていません。この記事に書かれたモデル名やインストーラーの挙動をそのまま使うのではなく、最新のDGX Spark NemoClawプレイブックと前提条件に従ってください。
つまりNVIDIAは現在、どちらのエージェントもNemoClawの選択肢として文書化しています。しかし、それは機能が同等であること、ワークロードをそのまま移行できること、この記事の構成がSparkハードウェア上で動作することを証明するものではありません。OpenClawやHermesをノートPCにインストールするだけなら、SparkもNemoClawも必要ありません。
プライベート推論では、どちらのエージェントシステムも、LAN／VPN上でvLLMが提供するOpenAI互換ベースURLを指定できます。OpenClawのローカルモデルガイドとHermesの公式プロジェクトを参照してください。n8nも、比較的軽い分類処理で同種のエンドポイントを呼び出せます。
ハードウェアの性能だけでは、ガバナンス計画になりません。Sparkクラスのローカルモデルであっても、顧客向けの送信を行う前に、チャネルの許可リスト、使用するHermesインターフェースに応じたBearer認証またはHMAC認証、範囲を限定したツール、人による確認が必要です。ローカルで動くことは、監督が不要であることを意味しません。
アンチパターン
チャット、cron、CRM、返金をすべて担う巨大なエージェント
コネクター（n8n）、判断（Hermes）、チャットUX（OpenClaw）を分けます。
「Hermesにもチャット機能があるから」という理由で、ツールを有効にしたOpenClawゲートウェイのDMを誰にでも開放する
チャネルのセキュリティは依然として運用者の責任です。許可リストとペアリングを確認してください。
Slackを呼び出すためだけに、n8nのエージェントをHermesで作り直す
手順が決まっているなら、ワークフローはn8nに残します。本当にエージェントノードが必要な場合に限り、n8nで最初のAIエージェントを使います。
ベンチマークごっこ
根拠のないtokens/secでスタックを選ばないでください。_自分の_モデルエンドポイントで、_自分の_レイテンシと障害パターンを測定します。
最初の推奨案（今日決める必要がある場合）
今月1つだけ構築するなら、次のように考えます。
- 個人利用で、スマートフォンからの操作を重視 → ペアリング、範囲を絞ったツール、明示的なexec承認、脅威モデルに応じたサンドボックスを設定したOpenClawを評価します。
- チームのチケット処理とCRM → n8nと人による確認から始めます。認証済みのHermes APIステップが、テストで単純なモデル／API呼び出しを上回った場合に限り追加します。別のwebhookアダプターは、その配信モデルが意図した契約である場合にのみ使います。
- 上記の両方に加えて、ローカルGPU／Sparkも使用 → 実証済みのワークフローを維持し、許可リスト付きチャットは別に評価します。NemoClawは、アルファ段階であること、前提条件、ポリシーの挙動、ロールバック手順を許容できる場合に限り検討します。
現在の担当システムでは不自然な回避策なしに実現できない仕事が現れたとき、選択を見直します。それが2つ目のシステムを追加する合図であり、最初のシステムを作り直す理由ではありません。
選んでいるのではないもの
この判断は、次のものを選ぶことではありません。
- ブログのベンチマークで「最も賢い」モデル
- 最も企業向けに見えるロゴ
- 抽象論としてオープンソースが「勝つ」かどうか
選ぶのはインターフェースと担当範囲です。チャットゲートウェイか、推論ランタイムか、ワークフロー連携か。ここを正しく決めれば、モデルの入れ替えを境界の明確な設定変更と検証にとどめられる可能性が高くなります。間違えれば、会社の自動化グラフを作り直すことになりかねません。
3つの実際のワークロードへの対応
1. 「Mac上の個人用コーディングエージェントにTelegramからアクセスしたい」
まずOpenClawを評価します。ペアリング、範囲を絞ったツール、明示的なexec承認、脅威モデルに応じたサンドボックスを使います。Hermesは必要に応じて検討します。
2. 「チケットをwebhookで受け取り、CRMに登録する前に分類と下書きを行いたい」
n8nに人による確認を組み込みます。Bearer認証、返却スキーマの検証、タイムアウト処理、冪等性、障害経路がワークフローのテストに合格した後でのみ、Hermes APIサーバー呼び出しを追加します。イベントで実行を開始し、設定済みの宛先へ結果を送る契約が必要な場合に限ってwebhookアダプターを使います。人がチャットから運用する必要もある場合は、OpenClawを追加候補として検討します。
3. 「DGX Sparkがあり、ローカルvLLM上でサンドボックス化したエージェントを動かしたい」
NVIDIAは現在、OpenClawとHermesをテスト済みのNemoClawエージェント経路としています。ただし、サポートマトリックスにはアルファ段階であることとHermesの本番同等性に関する留保があります。n8nとの接続、エージェントとモデルの互換性、共有エンドポイントの認証、Spark上での性能は、それぞれ別の受入テストとして扱います。この記事では、いずれも実行していません。
ロードマップに3つすべてが含まれるなら、段階的に進めます。まず個人用のOpenClaw、次にチケット処理向けのn8nからHermesへの連携を評価し、ローカルモデルのホスティングがボトルネックになった時点でSpark／NemoClawを検討します。逆の順序にはしません。
混乱を招かない機能の重複
どちらのプロジェクトも進化を続けています。OpenClawのエージェントには、ツール、スキル、cron／heartbeat、各チャネルからのアクセスがあります。Hermesもメッセージングプラットフォームで会話し、ツールを実行できます。機能の重複自体は問題ではありません。混乱は、次のような担当範囲を割り当てるときに生じます。
| 項目 | 共存構成での担当システム |
|---|---|
| 運用ボットにDMできる人を誰が管理するか？ | OpenClawの許可リスト／ペアリング |
| チケットを起点とする詳細調査を誰が開始するか？ | n8nが結果を必要とする場合はn8n → Hermes APIサーバー。設定済みの宛先へ配信するイベント入口に限ってHermes webhookアダプター |
| 顧客向けメールを誰が送信するか？ | 人による確認後のn8n |
| ローカルvLLMをどこで動かすか？ | 共有のプライベートエンドポイント。両方のクライアントが接続する |
| Spark上のサンドボックスポリシーをどこで管理するか？ | NemoClaw／OpenShell |
この表をチーム向けに文書化してください。そうしなければ、下書きと送信の経路が重複したり、互いに競合したりするおそれがあります。
コストと複雑さ（定性的な比較）
根拠のないベンチマークは必要ありません。定性的に比較すると、次のようになります。
- **OpenClaw単独：**個人向けのマルチチャネルチャットでは、最も複雑さを抑えられます。
- **Hermes単独：**エージェントランタイム、APIサーバー、イベントwebhookモデルのいずれかが用途に合い、チャットが補助的な場合に有力です。
- **n8n＋Hermes：**SaaSコネクター、認証済みのAPI呼び出しまたは明示的に結果を配信するwebhook実行、承認が重要な場合の候補です。
- **OpenClaw＋n8n＋Hermes：**測定した要件で、チャット運用と独立したHermesエージェントランタイムの両方が必要な場合に限り、正当化できる可能性があります。単純な個人向け要約処理には不要です。
サポート対象エージェントのサンドボックスと、ローカルまたはルーティングされた推論が実際の要件になった時点で、NemoClaw／Sparkを評価します。現在アルファ段階であることを考慮し、ハードウェアがあるという理由だけでは採用しません。
30分で行う選定ワークショップ
ワークロードごとに、次の質問への回答を1文ずつ書きます。
- 誰が開始するか？（人によるチャット／SaaS webhook／スケジュール）
- 承認なしでは絶対に自動化してはいけないものは何か？
- どのシステムに書き込む必要があるか？
- モデルをどこで動かす必要があるか？（クラウドAPI／LAN上のOpenAI互換エンドポイント）
- エージェントにメッセージを送る経路は、いくつの信頼境界をまたぐか？
次に、担当を割り当てます。
- チャットから開始＋マルチチャネル → OpenClaw
- リクエスト／レスポンス型の判断処理 → Hermes APIサーバー。多くの場合はn8nから呼び出す
- 認証済みのイベント入口から、設定済みの宛先へ結果を配信 → Hermes webhookアダプター
- SaaSへの書き込みと永続的な業務上の冪等性 → 確認ゲートの後ろに置いたn8nまたは業務システム
- 複数の敵対的なユーザー集団 → 1つの共有エージェントではなく、個別のゲートウェイ／ランタイム
これらの割り当てを、上の共存構成の表と並べて掲示します。2つのシステムが同じ書き込み経路を担当しているなら、設計はまだ完了していません。
検討中に開いておくリンク
- OpenClawドキュメント：https://docs.openclaw.ai/
- OpenClawセキュリティ：https://docs.openclaw.ai/gateway/security
- Hermesドキュメント：https://hermes-agent.nousresearch.com/docs/
- Hermes APIサーバー：https://hermes-agent.nousresearch.com/docs/user-guide/features/api-server/
- Hermes webhooks：https://hermes-agent.nousresearch.com/docs/user-guide/messaging/webhooks/
- Hermesソースコード：https://github.com/NousResearch/hermes-agent
- n8n HTTP Requestノード：https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/
- NemoClawサポートマトリックス：https://docs.nvidia.com/nemoclaw/latest/user-guide/openclaw/reference/platform-support
- NemoClawリポジトリ：https://github.com/NVIDIA/NemoClaw
ブランドではなく、仕事と根拠に基づいて選んでください。OpenClawで文書化されているゲートウェイ／チャネル制御、HermesのBearer認証APIサーバー、Hermesの独立したV2 HMAC webhookアダプターは、それぞれ性質の異なる有用な評価基準です。n8nは、手順の決まったワークフロー処理、永続的なアプリケーション冪等性、スキーマ検証、確認ゲートを担えます。NemoClawは両エージェントをテスト済み経路としていますが、プロジェクトは現在もアルファ段階であり、この構成やDGX Spark上での挙動は検証されていません。
