Hermes 対 OpenClaw：2026年オープンソース Agent フレームワークの選び方

2026年5月28日 · Nuvcloud 技術ブログ · 約12分

Hermes Agent 対 OpenClaw — 2026年オープンソース個人 AI Agent フレームワーク選定 — Hermes は複利型の自己進化 Skills、OpenClaw は全チャネル Gateway と ClawHub——2026年の選定ガイド。

2026年前半、個人向け AI Agent は「会話できる CLI」から、7×24 でタスクを回し、Telegram に接続し、ファイルを書き、ツールを呼ぶ常駐プログラムへ進化しました。議論で最も多いのは Hermes Agent（Nous Research）と OpenClaw。どちらも MIT オープンソース、複数モデル対応、メッセージチャネル連携が可能—しかしアーキテクチャの賭けは正反対です。一方は「使えば使うほど賢くなる」、もう一方は「チャネル最広・エコシステム最大」。

クラウド Mac への OpenClaw デプロイのような実践記事を既に読んでいるなら、本稿はインストール手順を繰り返しません。二つのフレームワークを整理し、2026 年の選定表を示します。読了後、「どちらを先に入れるか」「両方動かせるか」「コード専用の Claude Code / ECC との役割分担」が判断できるはずです。

1. Hermes Agent とは

Hermes Agent は AI ラボ Nous Research のセルフホスト型パーソナル Agent フレームワークです。メインリポジトリ：GitHub: NousResearch/hermes-agent、公式ドキュメント：hermes-agent.nousresearch.com。技術スタックは主に Python（uv 仮想環境、Docker 任意）。スローガンは 「The agent that grows with you」 と要約されることが多く、核心はチャット App を増やすことではなく、組み込みの学習ループです。

1.1 何を解決するか

従来型 Agent は新セッションのたび「記憶喪失の新入り」のようです。Skills は手書き、メモリは手整理、タスク終了で終わり。Hermes の差分は：

タスク後の「振り返り」：Skills にスコア、説明を書き換え、有効なやり方を蓄積（Curator / 自己進化 Skills）。
差し替え可能なセッション横断メモリ：v0.7 以降複数 backend 対応、対話を重ねて作業スタイルを安定理解。
ノート PC に縛られない：VPS、GPU、Serverless 上の実行を想定—Telegram で指示、クラウド VM で実行。「蓋を閉じたら止まる」とは別の運用モデル。

1.2 典型能力（README キーワード）

ブロック	読み方
モデル	OpenRouter、Nous Portal、OpenAI 互換エンドポイント等—単一ベンダーに固定しない
ツール	MCP ネイティブ、検索/端末/マルチモーダル（現行ドキュメント準拠）
チャネル	Telegram、Discord、Slack、Signal、メール、CLI 等（OpenClaw より少ないが主流はカバー）
移行	OpenClaw からの公式パス（`hermes claw migrate` 等—最新ドキュメントで確認）
ライセンス	MIT—セルフホスト・改変可

Hermes を一言で：経験を Skills とメモリに書き戻す Agent。反復 workflow は回すほど限界コストが下がる。

「毎週同じ週報・巡視・データ取得を毎回ゼロからやり直したくない」なら Hermes 向き。iMessage、Teams、飞书など十数チャネルを一本化したいなら OpenClaw の主戦場です。

2. OpenClaw とは

OpenClaw（旧 Clawdbot、Moltbot 等）は 2025 年末から急伸したパーソナル AI アシスタント / Gateway アーキテクチャ。リポジトリ：openclaw/openclaw、ドキュメント：docs.openclaw.ai。本体は TypeScript / Node。ローカルまたはサーバの Gateway がセッション、ツール、メモリ、各メッセージチャネルを統合管理します。

2.1 何を解決するか

OpenClaw の賭けは 「毎日使うアシスタントになる」：

チャネル極多：WhatsApp、Telegram、Slack、Discord、Signal、iMessage、Teams、Matrix、LINE、飞书等（公式リスト準拠）—「どこで話すか、そこで Agent を動かす」。
エコシステム：ClawHub 等の Skills/プラグイン市場—「入れれば使える」幅。Skills は人間・コミュニティが保守するのが主流。
プロダクト体験：macOS メニューバー、iOS/Android、音声、Live Canvas（A2UI）—端末だけでなく共有キャンバスに表・フォーム・看板。
透明なメモリ：workspace の markdown 等、読み書き可能なローカルファイルに落とす設計が一般的。

2.2 典型能力

ブロック	読み方
Gateway	制御面：メッセージルーティング、heartbeat、cron、マルチ Agent セッション
Heartbeat / Cron	定時起動、無人巡視向け（常時オンライン機に好相性）
Skills	ClawHub 配布、マーケット規模
モデル	Anthropic、OpenAI、Ollama 等、マルチモデル fallback
コミュニティ	2026 年も GitHub Star・リリース頻度は第一梯队

OpenClaw を一言で：全チャネル・全エコシステムの personal assistant ハブ。「繋がる・入る・GUI/Canvas が見える」が強み。

Nuvcloud 読者の多くは OpenClaw で CI トリガー、リモート Runner、スモークテスト—macOS 実機、固定 IP、不断線が要る用途で、常駐 Gateway と相性が良い。Hermes の「同じタスクが慣れていく」と矛盾しません。後述の併用も可能です。

3. Hermes と OpenClaw：Star 数勝負ではない

Star や Token 消費で並べられがちですが、カテゴリは同じ、哲学は違う。以下はアーキテクチャ差分のみ（バージョン口水戦は避ける—数字は時間とともに変わる）。

軸	Hermes Agent	OpenClaw
提供元	Nous Research（Hermes モデル族と同門）	openclaw 組織
主言語	Python	TypeScript (Node)
核心の賭け	複利型知能：自己進化 Skills、Curator、セッション横断メモリ	エコシステム幅：チャネル、ClawHub、Live Canvas、多端末 App
Skills の由来	多くは Agent がタスク経験から生成/改稿	多くはコミュニティ/ユーザーが作成してインストール
メモリ	差し替え backend、「システムが整理」寄り	しばしば平文ファイル、「自分で見て編集」寄り
チャネル数	足りるが通常 OpenClaw より少ない	極多、地域/企業 IM 含む
典型ユーザー	研究 workflow、反復タスク、長期 token 節約	マルチデバイス、マルチ IM、GUI/音声/Canvas
関係	移行ツール、complementary と位置づけ	エコシステム中心、「編成層」

3.1 誤解しやすい点

「Hermes は OpenClaw の後継」—不正確。Hermes は OpenClaw ユーザーの実行層（特に反復労働）を取りに行く面があり、OpenClaw はチャネルとプラグイン市場の主入口のまま。よくあるのは OpenClaw がルーティングと定時、Hermes が高頻度で蓄積可能なパイプライン—二者択一ではない。

3.2 Claude Code / ECC との分担

ECC（Everything Claude Code）等のコーディング Harness を使うなら三層：

Harness（ECC）：コードの書き方、権限、迷子防止；
OpenClaw / Hermes：7×24 メッセージ、ツール、タスクのスケジュール；
クラウド Mac / VPS：算力不断線、ディスクと出口安定。

Hermes か OpenClaw かは ECC を置き換えない。Agent 算力と τ 曲線は τ 法則と霊衢を参照。

4. 2026 年の選び方：シナリオ対応

ランキングではなく決定木。2～3 項目当てはまれば方向が見えます。

4.1 Hermes 寄りなら…

週次/日次の反復（レポート、巡視、同期、定型レビュー前チェック）が多く、10 回目が 1 回目より楽にしたい；
Python スタック、Nous 系モデル・研究ツールと組みたい；
ClawHub 未知 Skills のサプライチェーンリスクを減らし、「Agent 自書き Skills」の監査コストは受け入れる；
Telegram / Discord / Slack 程度で足り、iMessage/Teams 全網羅不要；
安価 VPS / Serverless、ノートはリモコン。

4.2 OpenClaw 寄りなら…

複数 IM / 多端末 App の統一入口、または Live Canvas、音声、macOS メニューバー 必須；
ClawHub Skills や自前プラグインに既投資、移行コスト高；
マルチ Agent 編成、cron、heartbeat の成熟ドキュメントと「OpenClaw + クラウド Mac」事例；
Node/TypeScript 中心、フロントと同 repo；
メモリファイル透明—SOUL.md / workspace markdown を手編集。

4.3 両方なら…

OpenClaw：チャネル集約、定時起動、タスク分割、通知返送；
Hermes：数本の高頻度・スコア可能・蓄積可能実行ループ（固定 repo のテスト行列、ログ要約）；
インフラ：Gateway と Hermes は独立プロセス、同一の常時オンライン機（Mac mini または裸金属クラウド Mac）—ポートと workspace を共有しない。

実務注意：二つの Agent が同一 git リポジトリ・同一設定を書くと上書きし合う。workspace 分割、別 Unix ユーザー/コンテナ、shell 書き込み権限を明確に。

5. デプロイとコスト：常時オンラインのクラウド Mac

Nuvcloud 読者にとって高いのはフレームワーク（MIT）より：

API / Token；
マシン時間（7×24 CPU/メモリ/ディスク占有）；
中断と再試行（ノート睡眠、家庭回線の揺れで全再実行）。

OpenClaw は Gateway 常駐を強調；Hermes も蓋を閉じない機器向き。リモートノード計画なら米東/米西、M4 メモリ、ログ用ディスク余裕—Hermes に替えてもマシン要件が magically 小さくはならない。

項目	OpenClaw	Hermes
OS	macOS 体験最充；Linux サーバも一般	Linux VPS ドキュメント多；macOS 可
Node vs Python	Node 22+ 等の維持	`uv`/venv と Python 依存
権限	shell/ブラウザ、Gateway で sandbox	`approvals.mode`、local/Docker/SSH
常時オン	heartbeat/cron はプロセス存続前提	学習ループが Skills を書く—ディスク満杯も要注意

要するに：Hermes か OpenClaw かは「常時ホスト要否」を変えず、上で動くプロセスだけ変える。

6. セキュリティとガバナンス

2026 年 Agent セキュリティの焦点は三つ、双方共通：

ツール権限（shell/ファイル/ブラウザの無確認実行）；
Skills サプライチェーン；
秘密情報の保管とローテーション。

OpenClaw のリスク面は ClawHub 市場—入れるほど監査面が広い。利点は出所追跡とコミュニティ議論。Hermes は Agent 自書き Skills—「一度のタスクで広すぎる shell 技能」を防ぐ。利点は見知らぬプラグインの盲目インストール削減。

どちらも本番では 最小権限、分アカウント、重要操作の人手承認、workspace 定期バックアップ、公開ネット上の機器で root 直実行の Gateway は避ける。

7. よくある FAQ

Q1：コードだけ気にするならどちら？
Claude Code / Cursor があるなら先に Harness + クラウド Mac。Hermes/OpenClaw は生活/運用アシスタント層。Telegram でビルド失敗通知なら OpenClaw 事例多。毎週同じ脚本で楽にしたいなら Hermes。

Q2：Hermes は必ず OpenClaw より Token 節約？
保証なし。複利は無駄な探索削減。毎日全新タスクなら両方とも多消費。Agent 請求と τ 曲線：単価下降 ≠ 総請求下降。

Q3：OpenClaw から Hermes へ無痛移行？
公式方向あり。ClawHub 専用、Canvas、iMessage 依存で「無痛」度は変わる。

Q4：Star の見方？
熱度 ≠ Live Canvas や自進化 Skills の必要性。第 4 節の決定木へ。

8. 結語：助手に何をさせるか決めてからフレームワーク

「使うほど慣れる実行者」 → Hermes Agent、公式 repo の Quickstart と Curator。
「どこにでもいる personal assistant」 → OpenClaw、Getting Started と Gateway 設定。
「エンジニアリングチーム 7×24」 → フレームワークの上に常時オンライン算力（裸金属クラウド Mac、固定出口、拡張ディスク）—Harness は遠回り削減、Agent は世界と接続。