OpenClaw vs Hermes Agent｜両者の違いを徹底比較【2026年版】

メッセンジャーからAIを操作する「エージェントハーネス」というカテゴリが急速に広がっています。OpenClaw（GitHubスター375,000）とHermes Agent（GitHubスター168,000）は、そのカテゴリの中で最も広く使われている2つです。機能リストを並べると驚くほど重なる一方で、使い続けた先の体験がまったく違う。その差を、コードの中ではなくユーザーが触る層で整理します。

---

「エージェントハーネス」とは何か、なぜ今 OpenClaw と Hermes が注目されるのか

ChatGPTやClaudeは専用のアプリやブラウザを開いて話しかけることが前提です。エージェントハーネスはその前提を崩します。Slack、Discord、iMessage、WhatsAppなど、自分が普段使っているメッセンジャーからAIに話しかけ、自分のローカル環境でファイル操作やスケジューラを24時間動かす仕組みです。

「モデル = 頭脳、コンテキスト = 作業メモ、ハーネス = 土台」という関係にあります。同じモデルを使っていても、ハーネスが違うと実運用の結果が大きく変わります。WildClawBenchのベンチマークでは、ハーネスを変えるだけで同一モデルのスコアが最大18ポイント変動しました。「いいモデルを繋げばいい」という直感が崩れる数字です。

この記事では、OpenClawとHermesを「何を育てるか」「セッションをどう管理するか」「マルチエージェントに対応しているか」「セキュリティはどうか」の4軸で比べます。コードの話はブラックボックスとして扱い、ユーザーが直接触れる層だけを見ます。

---

OpenClaw と Hermes Agent の違い：設計の出発点が根本から違う

OpenClawとHermesは「同じカテゴリの別製品」ではありません。設計の出発点が違います。

先に断っておくと、2つの機能リストはほとんど重なります。Slack・Discord・iMessageからの操作、自己ホスト、マルチエージェント、スキル拡張、メモリ永続化、自己改善——いずれも両者にあります。違いを掴むには「何の問題を解こうとして作られたか」を見るほうが噛み合います。

OpenClawが作ったカテゴリ

OpenClawは2025年11月に登場し、「自分のデバイスで動く、メッセンジャー経由で操作するパーソナルAIアシスタント」というカテゴリを最初に実用レベルで提示しました。当時、AIを使うには専用UIへのアクセスが前提でした。日常的に使っているSlackから直接AIに話しかけ、自分のローカル環境でツール実行・ファイル操作を24時間動かす——この発想自体が新規でした。

「ゲートウェイファースト」（メッセージの受信・配信を担う常駐ゲートウェイを中心に据える設計）は、このカテゴリを成立させるための具現化です。OpenClawの新しさは個別機能ではなく、「メッセンジャー越しに動くパーソナルAI」というユースケースそのものを確立したことにあります。

Hermesが同じカテゴリで追加提案したこと

Hermes Agentは2026年2月、OpenClawが切り拓いたカテゴリの内側で登場しました。機能群はOpenClawをほぼそのまま継承しています。差別化として打ち出したのは「自律的に進化する手順書（スキル）」というレイヤーです。タスクをこなすたびにエージェントが自分用の手順書を自動生成し、繰り返しの中で品質と速度を最適化していく。公式スローガン「The Agent That Grows With You」はその宣言です。

注意点があります。OpenClawにも「知識を育てる」仕組みはあります。Hermesだけが育つわけではありません。違いは育てる対象で、OpenClawは知識・教訓・ユーザー理解を育て、Hermesはタスク手順を育てます。両者の自己改善は同じ方向を向いていません（後述）。

重心の差

機能はほぼ同じでも、何を本体として中心に置いたかには差があります。

OpenClawはゲートウェイ（メッセージ受信・配信・ルーティング）を中心に据え、「メッセージを受けて返す」を24時間止めないことが設計の最優先事項です。Hermesはタスク実行ループを中心に据え、「タスクを実行して学ぶ」を最大化することが設計の最優先事項です。この重心の差が、後述するセッション管理・メモリ設計・スキル機構・自己改善の全てに細部の挙動として現れます。

---

OpenClaw と Hermes のセッション管理の違い——Slackから話しかけたときに起きること

長期運用するエージェントで避けて通れないのが、「セッションはいつまで続くのか」「コンテキストが満杯になったら何が起きるか」という問題です。

両者とも、ユーザーが話しかけなくなれば一定時間でセッションを閉じる点では同じです。違いは「閉じた後、どうやって再開するか」にあります。

OpenClaw：閉じたら破棄、次回は永続ファイルから再構築

Slackからメッセージを送ると、OpenClawはセッションを管理します。ライフサイクルの基本ルールは3つです。

• 60分間メッセージが来ないセッションは閉じられる
• 毎日午前4時に全セッションが強制リセットされる
• 蓄積データが上限を超えたら古い記録から消える

セッションが閉じても、会話の中身が消えるわけではありません。MEMORY.md（長期記憶）とmemory/YYYY-MM-DD.md（日次ログ）に重要な事実が残り続けます。具体的にどう残すかは後述します。

翌日Slackで話しかけると、まったく新しいセッションが立ち上がります。起動時にMEMORY.mdや日次ログが自動で読み込まれて状態を再構築するため、ユーザーから見ると「昨日の続きから話せる」ように感じます。しかしセッションそのものは別物で、内部的には「過去の永続化ファイルを読んだ新規セッション」です。

この「閉じて、また新規に立てる」サイクルが回り続けるため、1つのセッションが膨れ上がってコンテキストウィンドウが破綻するリスクは構造的に低くなります。

コンテキストが溢れそうになる場合の保険として、公式ドキュメントに定義された4層の対策が動いています。(1) メッセージ数上限（maxMessages）で古いメッセージを切る、(2) トークン数上限（maxTokens）で総量を抑える、(3) TTLによる時間減衰でキャッシュを古いものから外す、(4) スマートコンパクションで古い会話を要約に置き換える、の4層です。コンパクションの直前には「メモリーフラッシュ」と呼ばれる無言の内部ターンが走り、エージェントが重要事項をMEMORY.mdなどのディスク上ファイルへ書き出してから要約に置き換わるため、永続的に重要な情報は失われません。

Hermes：セッションを保ったまま再開できる

Hermesも同じくSlackからメッセージを受け取り、一定時間で閉じます。タイムアウトはデフォルト30分で、OpenClawの60分より早く切れます。

ただし閉じた後の扱いが違います。Hermesは「セッションそのもの」をSQLiteのデータベースファイル1つに丸ごと保存しています。全ての会話履歴、ツール実行ログ、消費トークン量などが、ホームディレクトリ配下の1ファイルに記録されていく仕組みです。OpenClawがマークダウン群でユーザーが直接読み書きする設計なのに対し、Hermesはアプリケーション内部で読み書きする形式です。

このデータベースに --resume コマンドでアクセスすれば、 同じセッションを直接再開 できます。新規セッションを立てて永続ファイルから状態を再構築するのではなく、前回のセッションをそのまま続けるイメージです。

検索面では、データベースに対してキーワード全文検索が組み込みで使えます。過去の全セッションを横断して「あの話どこでしたっけ？」と問い合わせる用途に向きます。ベクトル検索（意味的な類似検索）は標準機能には含まれず、必要なら外部のメモリサービスを別途繋ぐオプションが提供されています。OpenClawが標準でベクトル検索とキーワード検索を組み合わせて使うのと比べると、Hermesは検索精度より「全履歴をシンプルに残す」方向に振っています。

コンテキストが膨らんできた場合は、セッション内で圧縮が走ります。コンテキストが半分埋まった時点と限界が近づいた時点の2段階で、古い会話を要約に置き換えてヘッドルームを確保します。圧縮された元の会話はデータベースに残り続けるため、要約に置き換えられても完全には失われません。圧縮後のセッションは「前のサマリー」と紐付いており、再開すれば文脈は途切れません。

「セッションを長期間生き永らえさせる」という意味では、Hermesのほうが1セッションあたりの寿命が長くなる設計です。ただし圧縮が繰り返しうまくいかないとセッションが止まる問題や、再開時に最初のタスクを再実行してしまう問題が報告されており、超長期運用は完全には安定していません。

セッション設計の比較

「閉じた後の再開方法」の差が運用に効いてきます。OpenClawは1セッションが短命で済むので、コンテキストウィンドウが破綻しにくい。一方Hermesは同じセッションを長く保つので、圧縮を伴う長期セッションのトラブルを引きやすい。逆にHermesは「会話の続き」を厳密に保ちやすく、OpenClawは永続ファイルから再構築するため微妙な文脈は失われる可能性があります。

Hermesは圧縮し続けて大丈夫なのか

ここで疑問が出ます。Hermesが1セッションをずっと続ける設計だとすると、コンテキストウィンドウは肥大化し続け、要約の要約が積み重なってLLMの応答品質が劣化していくのではないか、と。

実際そうなる可能性はあります。明示的な強制リセットがない以上、論理上は1セッションが何ヶ月も延々と続けられる構造です。圧縮の連鎖でニュアンスが失われたり、圧縮が繰り返しうまくいかなくなるとセッション自体が止まる既知問題があったり、再開時に最初のタスクを再実行してしまう報告もあります。長期運用では劣化リスクが残ります。

それでもHermesがこの設計で成立しているのは、Slackでの セッション粒度がスレッド単位だから です。1チャンネル=1セッションではなく、1スレッドの中だけが1セッションになります。スレッドが切り替われば新規セッションが立ち上がるため、そもそも1スレッドの中で何ヶ月も会話が続くことは現実には起きにくい。「タスクごとにスレッドを切る」というSlackの自然な使い方が、Hermesの圧縮設計を支えています。

逆に言うと、運用ルールが必要です。同じトピックで毎回トップレベル投稿していると、毎回別セッションが立ち上がってしまい、記憶が共有されません。スレッドで返信する運用を徹底することで、Hermesは「1スレッドの会話履歴をコンパクションで延命しながら保つ」状態を成立させます。

仮に1スレッドが想定外に長くなった場合は、コンパクションで延命します。完璧ではありませんが、ほとんどのユースケースでは破綻しません。本当に長期間続くナレッジは、別途スキル（手順書）として書き出されるので、コンテキストウィンドウだけに依存しません。

つまりHermesの設計は「Slackで自然に発生する会話粒度（スレッド単位）と、ユーザーがスレッド運用ルールを守ることに対する信頼」の上に成り立っています。OpenClawが「ユーザーが何も気にしなくていいように毎日午前4時に強制リセットする」のと、対照的なアプローチです。

記憶や会話履歴の保存方法の違い

ここまでで両者の保存先には触れました。OpenClawは日次ログ（その日の生の会話・行動記録）と長期記憶ファイルMEMORY.mdをマークダウンで保持し、Hermesはセッション全体（生の会話・ツール実行ログ）をSQLiteデータベースファイル1つに保存します。

両者には 「要約処理」が2つの異なる目的で使われる場面 があり、混同しやすい点があります。先に整理すると、

(A) セッションを跨いだ会話の引き継ぎのための要約（稼働中の会話が長くなったときに古い部分を要約で置き換えてLLMコンテキストを延命する）と、

(B) 長期記憶の育成のための要約（日々の会話から本質だけを抽出して長期記憶ファイルを育てる）

の2つです。下の表ではこの2軸を分けて並べます。

ポイントは、(A)と(B)を混同しないことです。両者とも(A)の「セッション延命用の要約」は持っています。違いは(B)の「長期記憶を育てる要約」で、OpenClawはDreamingで日次ログからMEMORY.mdへ昇格させる仕組みを持つのに対し、Hermesは要約系ではなくスキル文書の自動生成という別系統で長期的な賢さを実現しています。また保存層の話としては、両者とも(A)の要約に置き換えられた後も生の会話履歴は別途残ります。OpenClawはコンパクション直前のメモリーフラッシュで重要事項を永続ファイルへ書き出し、Hermesは圧縮後も元の会話がDBに残り続けます。

どちらの方式でも、会話履歴やエージェントが学んだ記憶は消えずに残ります。違うのは、そこに 人間がどう触れられるか です。ここに運用上の差が出ます。

OpenClawはマークダウンファイル群なので、MEMORY.md（長期記憶）もSOUL.md（人格・行動原則）もUSER.md（ユーザー情報）も、テキストエディタで開けばそのまま読めますし、書き換えれば即反映されます。エージェントの設定ディレクトリ全体がGitリポジトリで管理されるため、変更履歴も追えます。「このエージェントが先週何を学んだか」「ここの記憶を消したい」が、人間の手で完結します。

Hermesはアプリケーション内部のデータベースに閉じています。テキストエディタで直接編集することは基本的にできず、Hermesのコマンドや検索機能を介してアクセスします。代わりに、組み込みのキーワード横断検索で「先月のあの議論どこだっけ」を一発で引っ張れる利便性があります。

ここで誤解されやすいのは、「マークダウンなら人間が直接読み書きできるからマルチエージェント運用が楽」という飛躍です。実態としては、MEMORY.mdや日次ログを人間が日常的に開いて編集することはほとんどありません。読み書きするのはエージェント自身（および検索インデックス）で、人間が直接触るのはせいぜいSOUL.md・AGENTS.md程度。そしてその「人間が触るルール系ファイル」については、Hermes側もマークダウン（SKILL.md含む）で提供されているため、ここに本質的な差はありません。HermesがSQLiteに格納しているのは「過去の会話履歴・ツール実行ログ」の層であって、ルール系ファイルではない、という点を押さえておく必要があります。

マークダウン形式のメリットが本当に効いてくるのは、スクリプタビリティとGit運用の場面です。50体のエージェント全体に対して grep -r "ある事実" workspace-*/MEMORY.md で横断検索する、git log で記憶の更新履歴を追う、フォルダコピーで丸ごとバックアップする——こうした「機械的に多数のエージェントを扱う」場面ではマークダウンが有利になります。一方、Hermesは1エージェント1DBの構造なので、50体運用時に「全エージェントの記憶を横断して何かを探す」のはやや手間です。

ただしこれも、マルチエージェント運用の本質的な向き不向きを決める要素ではありません。実差は アーキテクチャの設計重心——マルチエージェント前提で組まれているかどうか、ルーティングが標準機能か、コミュニティの運用ノウハウが蓄積されているか——にあります。詳しくは次のセクションで掘り下げます。

---

OpenClaw と Hermes の「育つ」対象の違い：自己改善は同じ言葉で別物

「OpenClawは静的、Hermesだけが育つ」という対比は半分だけ正しい説明です。両者とも自律的に育ちますが、育てる対象が直交しています。OpenClawが育てるのは「エージェント自身」——知識・行動原則・長期記憶です。Hermesが育てるのは「エージェントが使うスキル」——タスクの手順書です。同じ「育つ」という言葉でも、向いている方向が全く違います。

この分類が直感的に腹落ちするかどうかは、ユーザーの設計スタイルにもよります。AGENTS.mdにルール・行動指針を書き、SKILL.mdに具体的なタスク手順を切り出して明確に分離している設計者（Claude CodeでCLAUDE.mdとサブエージェント/スキルを分けている人と同じ感覚）にとっては、「エージェント vs スキル」という対比は一発で見える。一方、AGENTS.mdの中にあらゆる手順や知識をベタ書きしている設計者にとっては、「エージェント」と「スキル」の境界が曖昧なので、両者の差もぼやけて見えるかもしれません。OpenClaw公式が推奨するのは前者で、AGENTS.mdはルール・行動指針、SKILL.mdは具体的なタスク手順、と切り分けて使うのが想定されています。

OpenClawが育てるもの——エージェント自身（知識・記憶・行動原則）

OpenClawの記憶は2層構造です。MEMORY.mdが長期記憶で、ユーザーの好み・重要な事実・進行中のプロジェクト・学んだ教訓を蓄積します。memory/YYYY-MM-DD.mdが日次ログで、その日のセッション活動・意思決定・作業コンテキストを記録します。

この記憶を育てる中心的な仕組みが「Dreaming」と呼ばれるバックグラウンド処理です（公式ドキュメントの正式名称）。雑多に伸びた草（日次ログの断片的な事実）を整理し、価値のある木（本質的な教訓）だけを残して育てる作業に例えられます。light（短期記憶の整理・ステージング）、deep（本質的な事実をMEMORY.mdに昇格）、REM（テーマの俯瞰）の3フェーズで構成され、昇格にはスコア・想起頻度・クエリ多様性のゲートを通過する必要があります。

Dreaming自体は opt-inでデフォルトは無効 な機能で、有効化すると背景処理として動きます。別途、エージェントには HEARTBEAT.md で定義したタスクをデフォルト30分ごとに自律実行する「ハートビート」という仕組みもあり、これを使って定期的な記憶整理を組み込むことも可能です。

数週間から数ヶ月の運用で、MEMORY.mdが日々の雑多な記録の中から本質だけを抜き出した状態に整っていきます。「ユーザーがこういう人だ」「以前こういう判断をした」という事実と教訓が、ノイズを削ぎ落としながら積み重なっていく方向です。

エージェント自身が自分の設定ファイルを書き換える機能もあります。失敗した手順を見直して設定を直す、新しいツールを覚えたら役割定義に追記する、といった動きが自律で走ります。さらにエージェントの設定ディレクトリ全体がGitリポジトリで管理されるため、不適切な学習が起きた場合は変更を巻き戻せます。これは後述するHermesの「自動上書きリスク」と対照的な設計です。

Hermesが育てるもの——タスク手順

Hermesが進化させるのは主にスキル文書、つまりタスクの手順書です。特定の条件を満たすと自動でスキルを生成します。4つのトリガーがあります。

• 同じ手順で複数のツールを組み合わせた処理を5回以上成功させた
• エラーが発生し、それを解決する方法を見つけた
• ユーザーから特定の手順を修正された
• 複数ステップの非明白な処理を完了した

「このタスクはこの手順でやる」「この種のエラーはこう回避する」という手続き的な記憶が自律的に積み上がります。同じタスクの繰り返しで最大40%の高速化が報告されており、マーケティング上の「育つ」の実態はここにあります。

GEPA：スキル全体を一括で磨き直すバッチ処理

スキル自動生成と並ぶもう一つの「育つ」軸がGEPA（Genetic-Evolutionary Prompt Adaptation）です。GEPAは個別のスキルをその場で改善するのではなく、これまでに蓄積したスキルライブラリ全体を一括で評価・改良するバッチ処理として動きます。

GEPAの動作イメージは以下です。

1. 蓄積されたスキル群を入力に取る
2. 各スキルについて「実行ログ」「成功/失敗パターン」を分析する
3. プロンプトや手順書を言語ベースで「進化（mutate）」させる候補を複数生成
4. ベンチマーク的に評価して、改善案だけを採用、劣化案は破棄
5. スキルライブラリを書き換える

ここで「Genetic（遺伝的）」「Evolutionary（進化的）」と名乗っているのは、複数の候補を世代交代させて優秀なものだけを残す、生物進化に似たアプローチを取っているためです。深層学習における勾配降下法の「テキスト版」に近い発想で、 TextGrad や ACE と同じ系譜の自動プロンプト最適化の一種です。

ただしGEPAには2つの実務的な性質があります。

• リアルタイムには走らない。ユーザーが任意のタイミングで明示的に起動するバッチ処理で、スキル自動生成のような「タスク完了時に勝手に動く」とは違います
• 実行のたびに一定のAPIコストが発生する。複数候補を生成して評価するため、LLM呼び出しが多い。スキルが十分溜まってから走らせる性質のものです

つまりGEPAは「スキル自動生成」の上に乗るメタ最適化層で、日々の運用で勝手に動く仕組みではなく、ある程度スキルが溜まったタイミングで「ライブラリ全体を磨き直す」ためにユーザーが起動するものです。初期段階で実行しても、最適化の対象となるスキルがないので意味がありません。

Hermesにはエージェント自身を育てる仕組みはない

注意点として、Hermesにはエージェントの人格・行動原則・長期記憶を自律的に更新する仕組みは標準機能として存在しません。SOUL.md相当の設定や行動ルールを成長させたい場合は、ユーザーが手動で編集する必要があります。Hermesの「育つ」はスキル層（手順書）に特化しており、エージェント自身（人格・知識・ルール）を育てるOpenClawとは育成の方向が直交しています。

裏返すと、OpenClawにはHermesのような「タスクの繰り返しから手順書を自動生成する」仕組みは標準機能には備わっていません。OpenClawのskills/は基本的にユーザーが手動で作るか、ClawHubから取り込む対象であって、エージェント自身が経験から新規スキルを生成する標準機構は提供されていません。両者の「育つ」軸は綺麗に直交しており、片方の強みが他方の弱みになっている構造です。

自己改善の落とし穴

両者とも自己改善ループには異なる弱点があります。

Hermes側の落とし穴: タスクが成功したかどうかを判定するのもHermes自身で、実運用報告では「ほぼ常に自分は成功したと思い込む」傾向が報告されています。実際には失敗していたタスクから「成功した手順」として手順書を自動生成してしまうことがあります。重要なタスクには人間または別エージェントによるレビューゲートを置く、テスト結果の自動チェックを噛ませる、といった対策が必要です。「育つ」のは自動でも、「正しく育っているか」は手動で見届けないと品質が劣化していきます。加えて、手動で調整したスキルをHermesが「自己改善」で書き戻してしまうケースも報告されています。特定のワークフロー向けに調整したスキルが、汎用的な内容に戻されてしまう。

OpenClaw側の落とし穴: HEARTBEAT.mdに定期タスクを書いて運用する場合、Heartbeatターン自体はデフォルトでエージェントのmainセッション（DM枠）内に追加されていきます。公式仕様上は「Heartbeat-only replies do not keep the session alive」（実ユーザーメッセージがないとアイドルタイマーは進む）とされていますが、実装上はIssue #20011・#60719・#57577で報告されている通り、Heartbeatターンが累積してコンテキストが肥大化し、トークンコストが膨らむ問題が知られています。唯一の確実な救済は午前4時の全セッション強制リセット。回避策のisolatedSession: true（Heartbeatごとに新規セッション）にもバグ報告があるため、Heartbeat駆動の自律処理を使う運用ではセッションサイズを定期監視する必要があります。

---

OpenClaw と Hermes でマルチエージェントを社員のように運用する場合の違い

「SEO担当」「税理士担当」「経理担当」のように20体規模のエージェントを常駐させる運用は、機能としては両者ともサポートしている というのが事実です。一方で、運用のしやすさやエコシステムの厚みでは差があります。違いを正確に切り分けます。

機能としてはどちらも縦割り運用ができる

OpenClawとHermesは、両方とも「複数の独立したエージェントを並行運用する」機能を標準で備えています。

OpenClaw: 単一ゲートウェイの中で、エージェントごとに完全に独立したワークスペースを並行運用できます。各エージェントは自分専用のSOUL.md（人格・行動原則）、AGENTS.md（役割定義）、USER.md（ユーザー文脈）、スキルセット、セッション記録を持ちます。agent:<エージェントID>:<セッションキー> という名前空間でセッションが分離されており、互いに干渉しません。

Hermes: 「Profiles」という仕組みで、各Profileが独自のディレクトリに config.yaml・.env・SOUL.md・メモリ・セッション・スキル・cronジョブ・state DB を持ちます（公式: "Each profile gets its own directory containing its own config.yaml, .env, SOUL.md, memories, sessions, skills, cron jobs, and state database"）。hermes profile create <name> で簡単に追加できます。

つまり、「縦割りで独立したエージェントを並行運用する」という機能要件は両者で等価です。SOUL.md相当の人格設定もメモリもスキルもエージェントごとに独立して持てる、という点で違いはありません。

エージェント間の協調機能も両者にある

OpenClaw: 親エージェントから独立した子エージェントを非同期に起動する方法と、エージェント間で直接メッセージをやり取りする方法の2種類が標準機能として備わっています。「経理担当が税理士担当に質問を投げる」「SEO担当がライターに記事案を依頼する」といったやり取りが人間を介さずに走ります。

Hermes: Hermes Kanban（全Profileで共有される耐久タスクボード）がエージェント間協調の場として標準提供されています。kanban_create・kanban_comment・kanban_link 等のツールセットを通じて、エージェント同士がタスクのハンドオフと議論を共有ボード経由で行えます。公式は "Comment is the inter-agent protocol" と表現しており、コメントスレッドが文脈共有の仕組みとして設計されています。

実装の形は違いますが（OpenClawは直接メッセージ送受信、HermesはKanbanボード経由）、「エージェント同士が連携して作業を進める」機能としては両者とも提供されています。

残る差：運用ハードルとエコシステムの厚み

機能等価という前提で、実運用上の差を整理すると以下の4点に絞られます。

(a) アーキテクチャの軽量さ

• OpenClaw: 1ゲートウェイプロセスの内側に複数エージェントが同居
• Hermes: 各Profileが独立したOSプロセスとして動く（"Each profile runs its own gateway as a separate process"）

20-50体規模になると、Hermesは20-50個のプロセスがメモリに常駐するのに対し、OpenClawは1プロセスで済みます。リソース効率はOpenClawが有利。ただし現代のマシンスペックなら数十プロセスは現実的に運用可能なので、決定打にはなりません。

(b) Slackボット登録の手数

• OpenClaw: 1つのSlackボットアプリで全エージェントを処理可能。Slack上で @SEO担当 @税理士 のようにmentionで呼び分け
• Hermes: 各Profileが独自の SLACK_BOT_TOKEN を持つ前提なので、Profile数だけSlackボットアプリの登録が必要

20体運用なら、Hermesは20個のSlackボットを別々に登録するセットアップが必要です。一度組んでしまえば日々の運用には影響しませんが、初期構築の摩擦はHermesが大きい。逆に、専用チャンネルを役割ごとに切る運用（#税理士 #SEO のようにチャンネル単位で分ける）なら、Hermesも自然に組めます。「同じチャンネルで複数エージェントを呼び分ける」用途ではOpenClawが向きます。

(c) 設計初日からのマルチエージェント志向

• OpenClaw: 2025年11月のリリース当初から agent:<id>:<session> の名前空間設計でマルチエージェントを前提に作られている
• Hermes: 元々は単一エージェント長期育成が主軸。Profilesは2026年に追加された拡張機能。Issue #344では「single-agent system with isolated sub-agent delegation into a true multi-agent architecture」とあり、マルチエージェントアーキテクチャは現在も進化途上

進化途上ということは、今後Hermes側がこの領域を磨けば差はさらに縮まる、ということでもあります。

(d) コミュニティテンプレートとレシピの蓄積

• OpenClaw: awesome-openclaw-agents で162種類の本番運用テンプレートが公開されているなど、コミュニティ事例が「36体構成」「2〜50体超を日常的に共有」というレベルで蓄積されている
• Hermes: Profileの個別構築サンプルは増えているが、20体超を組み立てた包括的テンプレ群は現時点では薄い

これも本質的なアーキテクチャ差ではなく、エコシステムの時間差です。

結論：機能差ではなく「運用のしやすさとエコシステム」の差

「OpenClawが明確に優位」と単純に言える状況ではありません。機能としてはHermesも縦割り運用に必要なものを一通り持っており、Profile単位で SOUL.md・メモリ・スキルを独立させ、Kanban経由でエージェント間協調も可能です。

ただし、20体規模を「今すぐ立ち上げて運用に乗せる」ことを考えると、

• OpenClawなら 1プロセス・1ボット・コミュニティの36体運用レシピを参考に組める
• Hermesなら 20プロセス・20ボット・主要な構築テンプレは自前で書く

という運用ハードルの差が残ります。機能等価だが、立ち上げ摩擦とノウハウの厚みでOpenClawが先行している、というのが2026年5月時点のフェアな評価です。「片方ができて片方ができない」という話ではなく、「両方できるが、今は片方の方が組みやすい」という温度感の差です。

---

OpenClaw・Hermes で Claude Code の資産はそのまま使えるか

Claude Codeで蓄えてきたものをOpenClawやHermesに持ち込めるかどうかは、移行コストの大半を左右します。ここで重要なのは、Claude Codeには「スキル」と「サブエージェント」の2系統の資産があり、持ち込みやすさが違うという点です。

スキル（SKILL.md形式） はagentskills.ioというオープン標準で定義されており、Anthropic以外のハーネスも同じ仕様を採用しています。Claude Codeのスキルを、フォルダをコピーするだけでOpenClawやHermesで使えます。

サブエージェント（agents/*.md）はClaude Code固有のランタイムに紐付いた仕組みで、オープン標準ではありません。OpenClawでもHermesでも、そのまま読み込む機能はなく、書き直しが必要です。サブエージェント資産が多い人ほど、移行コストが見た目より重くなります。

スキル互換は共通でも、Slackからスキルを発動するときの手数に差があります。Hermesはスキルフォルダを置くだけでスラッシュコマンドが自動登録され、追加の設定は不要です。OpenClawはDiscordやTelegramでは自動登録されますが、Slackだけ追加の設定が必要です。スキルが増えるほど管理コストが増えます。

ACP（Agent Client Protocol）の差も見逃せません。OpenClawはClaude Code、Cursor、Copilotなど14種類以上の外部ハーネスをACP経由で接続できます。HermesはACPに未対応で、この連携は使えません。

---

OpenClaw と Hermes の固有機能比較：相互模倣で埋まっていない領域

ここまで主要な機能軸での比較を見てきましたが、両者にはまだ「片方にしかない機能」も残っています。記事の判断材料を補強するため、現時点で固有な機能を整理します。

Hermesにしかない機能

(1) Hermes Desktop（ネイティブGUIアプリ）

Hermes Desktop はApple Silicon Mac / Intel Mac / Windows / Linux向けのネイティブインストーラーが提供されているGUIアプリです（コミュニティ製、2026年5月頃に注目を集め始めた）。CLIに不慣れなユーザーでもインストール・設定・チャット・セッション・Profile・メモリ・スキル・ツール・スケジューリング・メッセージングゲートウェイの管理をGUIから扱えます。OpenClaw側にもコミュニティ製GUIはありますが、Hermes Desktopほど統合度の高いものは現時点では確立していません。

(2) リッチなインタラクティブTUI（CLI）

hermes コマンドでフルTUIが起動し、マルチライン編集、スラッシュコマンド補完、会話履歴、interrupt-and-redirect（実行中の処理を割り込みで方向転換）、ツール出力のリアルタイムストリーミングが使えます。「メッセンジャーを介さず直接エージェントと対話したい」「開発者がローカルでガリガリ使いたい」用途では、Hermesの方が体験が洗練されています。

(3) 音声インタラクション（ただしプラットフォーム別に対応範囲が違う）

Hermesの音声機能はプラットフォームごとに対応範囲が異なります。整理すると：

音声入力（文字起こし） はSlack含む主要メッセンジャー全部で動きます。音声応答（TTS） が公式サポートされているのはTelegram・Discord・WhatsApp・CLIの4つのみで、Slackは含まれていません。リアルタイム双方向音声会話（エージェントが音声チャンネルに参加して聞きながら話す）はDiscord voice channelに限定されます。

つまり、「Slack中心で運用していて、文字でなく音声で返答してほしい」という使い方は、Hermesの公式機能では実現できません。逆に「Telegramで音声で会話したい」「Discord voice channelで会議に呼びたい」用途では強みを発揮します。OpenClawの音声サポートはこれより限定的で、Hermesほど統合された音声体験は提供していません。

(4) ブラウザ自動化

Browserbaseクラウド、Browser Useクラウド、ローカルのChrome/Brave/Chromium（CDP経由）など複数バックエンドを切り替えて、ウェブサイトのナビゲーション・フォーム入力・情報抽出ができます。スクレイピングや日常的なブラウザ作業の自動化を組み込みたい場合は、Hermesに優位性があります。

(5) OpenAI互換ローカルプロキシ

Hermesに2026年5月の v0.14.0 で追加された機能で、OAuth認証済みのHermesプロバイダ（Claude Pro、ChatGPT Pro、SuperGrok、xAI Grokなど）を OpenAI API互換のローカルエンドポイント として提供します。これにより、Codex CLI / Aider / Cline / Continue といったOpenAI APIを期待するツールから、Hermes経由でClaude ProやSuperGrokを呼び出せます。サブスクで持っているLLMをAPI課金なしで開発ツールから使う、という運用が可能です。

(6) F-Droid Android アプリ

公式のAndroidアプリがF-Droidで配布されており、スマホからHermes Agentと直接やり取りできます。メッセンジャー越し以外の使い方がモバイルからも可能です。

(7) x_search（Twitter検索の標準ツール）

X（旧Twitter）の検索を OAuth または API キーで使えるファーストクラスツールとして組み込み済み。Xでの情報収集・モニタリングを自動化したい運用に向きます。

OpenClawにしかない機能

(1) ACP（Agent Client Protocol）対応

繰り返しになりますが、これがOpenClawの最大の固有強みです。Claude Code、Cursor、Copilot、Windsurfなど14種類以上の外部ハーネスをACPで直接接続できます。「Slackから来た指示をOpenClaw経由でClaude Codeに渡してコーディングさせる」ような複合ワークフローが組めます。HermesはACP未対応で、これは公式ロードマップにも入っていません。

(2) 大規模なスキルマーケットプレイス

ClawHubには13,700+のコミュニティ製スキルが登録されており、これはHermesのスキル流通量より一桁多い規模です。「やりたいことが既にスキルとして存在する」確率は現時点でOpenClawが圧倒的に高い。ただしClawHavocキャンペーンの事例があるため、出所確認は必須です。

(3) マルチエージェント運用での per-agent bot identity

20体運用時に、各エージェントに別々のSlackボットアイデンティティ（bot user、表示名、アイコン）を割り当て、@mention で呼び分けられます。Hermesも各Profileに別ボットを割り当てる構成は可能ですが、OpenClawは1ゲートウェイ内でこれを管理する点で運用がシンプルです。

整理表

固有機能の数だけ見ると、現時点ではHermesの方が「メッセンジャー越し以外のインターフェース」を多く揃えている。OpenClawは逆に「メッセンジャー越しで完結し、他のハーネスと連携する」方向に振っています。設計哲学の違いがインターフェースの広がりにも現れています。

---

OpenClaw vs Hermes のベンチマーク比較と実際のパフォーマンス

WildClawBenchは60の実世界タスクを使い、OpenClaw・Hermes Agent・Claude Codeを同一条件で評価したベンチマークです。

自分が最も注目したのは冒頭にも挙げた数字です。ハーネスを変えるだけで同一モデルのスコアが最大18ポイント変動する。Claude Opus 4.7はOpenClawハーネスで62.2%と最高スコアを記録しましたが、評価した4モデル中3モデルではHermesハーネスが最良の結果を出しています。モデルとハーネスに「相性」があるということです。

繰り返しタスクのコスト効率は別の話になります。初回のターンはHermesのほうがトークンを多く消費します（メモリ検索・スキル照合・コンテキスト構築が加わるため）。しかし同じタスクを繰り返すと状況が逆転し、スキル蓄積後は最大40%の削減が報告されています。OpenClawは毎回同じコンテキストを読み込むためコストが一定のまま下がりません。「単発の実験」はOpenClaw、「毎日繰り返す業務」はHermesが経済的な理由はここにあります。

一点、重要な但し書きがあります。コーディング専用タスク（複数ファイルにまたがる変更、テスト失敗からの反復修正など）では、OpenClawもHermesも、Claude Code単体・Cursor・Windsurfには敵いません。両者はコーディング専化エージェントとして設計されていないからです。コーディング目的で導入するなら、Claude CodeをACP経由で呼び出す構成が品質面で有利です。

---

OpenClaw と Hermes のセキュリティの違い：対称的に見えて非対称

OpenClaw：138件のCVEとサプライチェーン攻撃

2026年4月時点で、OpenClawには138件のCVEが積み上がっています。Critical（最高深刻度）が7件、High（高深刻度）が49件。最も深刻な脆弱性（CVSSスコア9.9）では、任意コマンドの実行と管理者権限の乗っ取りが可能でした。

ClawHub（OpenClawのスキル配布マーケット）では「ClawHavocキャンペーン」という組織的なサプライチェーン攻撃が起きています。悪意あるスキルが1,184件検出され、ブラウザパスワードや暗号資産ウォレットを盗み出すマルウェアを配布していました。

なぜこれが起きたか。ClawHubへの参入障壁が「GitHubアカウントの作成から1週間以上経過していること」だけだったためです。悪意ある出品者をスクリーニングする実質的な機能がありませんでした。

CVEの多さは「実運用で踏み抜いた地雷の数」でもあります。発見・修正のサイクルが長く積み重なっているとも言えますが、現時点でのリスクは無視できません。ClawHubからスキルを入れるときは出所を必ず確認してください。ClawHavocキャンペーンの教訓は「バリデーションなしにスキルを入れるな」です。

Hermes：設計段階に組み込まれたセキュリティ

HermesにもCVEは1件あります（WeChat Workアダプタの脆弱性、CVSSスコア5.3 MEDIUM）。「0件」という記述が出回っていますが正確ではありません。

ただしOpenClawの138件・最大スコア9.9と並べると、深刻度の差は明らかです。

Hermesは内部監査で35件の脆弱性を発見し、最優先の8件を修正しました。7層の防御設計として、認証情報やAPIキーが子プロセスに漏れないようにするフィルタリング、外部から取り込むスキルのマルウェアスキャン、権限を勝手に拡張させない仕組みなどが組み込まれています。セキュリティを重視する業務環境では、Hermesが現時点でより低リスクな選択肢です。

---

OpenClaw と Hermes、結局どちらが勝つのか——機能収束時代の選び方

ここまで読むと「機能差はどんどん縮まっているし、結局どっちでも良さそう」「それなのにHermesがここまで注目されているのは何故なのか」という疑問が出てくるかもしれません。正直に言うと、この感覚は的を射ています。フェアな視点で整理します。

Hermesが急成長した理由は機能ではなく物語と体験設計

Hermesが2026年2月の登場後わずか数ヶ月でGitHubスター16万超まで伸びた本当の理由は、機能の優位性ではなく 物語と体験設計の優位性 です。

• 「箱を開けたらすぐ育つ」体験: Hermesは標準で自律学習が動き、数日使うだけで「覚えてくれてる」「同じタスクが早くなった」を体感できる。OpenClawはDreamingがopt-in、HEARTBEAT.mdが空雛形で、設定を正しく入れないと育つ気配がしない。多くのユーザーが「OpenClawは何も変わらない」と離脱する、その逆を行ったのがHermes
• NousResearchというブランド: NousResearchはオープンウェイトLLM（Hermes 3、Hermes 4等）で先に研究者コミュニティの知名度を確立していたチーム。「The Agent That Grows With You」のスローガンで実用ツールを出した時点で、マーケティング基盤が既に整っていた
• 「作りがしっかりしている」という客観的事実: インフルエンサーがそう評するのは、CVE 138件 vs 1件、設計段階での7層セキュリティ、コードベースの新しさという実データに裏付けられた評価。マーケのレトリックではなく、機能のパクリ合いで埋まらない競争優位の一つ

機能収束はAIツール市場全般のパターン

機能差は今後さらに縮むと予想されます。これはOpenClaw vs Hermesに限った話ではなく、AIツール市場全体のパターンです。

• Cursor vs Windsurf vs Zed vs Claude Code: コード補完・agent mode・MCP対応・サブエージェントを各社が追従し合い続けている
• ChatGPT vs Claude vs Gemini: 同じ性能ベンチで僅差を競い、artifact・canvas・deep research等の機能を次々相互模倣
• Claude Code vs Codex CLI: Anthropic vs OpenAI が公式CLI同士でパクり合っている

OpenClaw vs Hermesも同じ構造です。実際、Issue #344でHermesが "true multi-agent architecture" を目指していること、OpenClawがACP対応で他ハーネスとの相互運用を強化していること、両方とも 相手の強みに寄せている。1年後にはおそらく機能リストの差はほぼ消えます。

収束後に残る3つの差

機能がコモディティ化したとき、消えずに残るのは以下の3軸です。

1. セキュリティ・メンテナンス品質: コードベースの成熟度と設計時のセキュリティ意識。これはコピーできない。Hermes優位
2. コミュニティとエコシステム: テンプレ・運用ノウハウ・スキル流通の厚み。現時点はOpenClaw優位（162種テンプレ、ClawHubのスキル数、ただしClawHavocによる汚染リスクあり）
3. デザイン哲学のフィット: 「すぐ動くものが欲しい」vs「全部自分で組みたい」、「単体エージェント深掘り」vs「20体縦割り運用」、「クラウド頼り」vs「ローカル完結」など、設計思想とユーザーの好みの相性

どちらが勝つか——3つのシナリオ

正直、現時点では予測不能です。可能性として：

• Hermesが勝つシナリオ: 「箱を開けたら育つ」の体験で個人ユーザーを取り込み続け、セキュリティの信頼感で業務ユーザーも取り、機能はOpenClawから取り込み続けて差を埋める
• OpenClawが勝つシナリオ: マルチエージェント運用が主流化したとき、20-50体運用のレシピと既存テンプレ資産で先行者利益を維持する。並行してセキュリティを真剣に巻き返す
• どちらも勝たないシナリオ: 巨大プレイヤー（Anthropic、Google、OpenAI、Microsoft）が公式のメッセンジャー駆動エージェント機能を本格的に出してきて、両者ともニッチに押し込まれる

3番目はわりとあり得ます。Claude Codeがチャット駆動の常駐エージェント機能を本格的に出すとか、OpenAIがChatGPT for Slackをエージェント化するとか、そうしたシナリオは現実的です。

過渡期に「調べれば調べるほど分からなくなる」のは正常

両者を比較すればするほど「どっちでも良さそうに見える」のは、機能収束が進行中の 過渡期 だからです。明確な勝ちパターンがまだ確立していない段階で、決定的な判断材料を探しても見つからないのは当然です。

そういう時期の現実的な対処は3つあります。

1. 業務で本気で運用する想定なら Hermes を選ぶ。CVE 138 vs 1 はサプライチェーン攻撃のリスクとして無視できず、業務PCにマルウェアが入る事態は避けたい
2. 20体運用が既に必要な状態なら OpenClaw を選ぶ。Hermesの追随を待つよりは現在使えるテンプレと運用事例の厚みを使う方が早い（ただしスキル導入時の出所確認は徹底する）
3. どっちも試してから決めたい なら両方インストールして2週間ずつ運用する。スキル（SKILL.md）は両者で互換なので、移行コストは思ったより低い

そして覚えておくべきは、「スキルが両者で互換である」事実が、選択の不可逆性を下げているということです。最悪の場合、後から乗り換えても主要な資産は持って行けます。「今この瞬間に正解を選ばないと損する」状況ではない、ということが、過渡期を生きるユーザーにとって唯一の救いです。

---

OpenClaw vs Hermes ユースケース別の推奨と移行の現実

実際にどちらを選ぶか、整理します。

OpenClawが向いているケースは、20体規模のエージェント運用を今すぐ立ち上げたい場合です。テンプレ・運用事例の蓄積で立ち上げ摩擦が低く、1ゲートウェイ・1Slackボットで全エージェントを束ねられる軽量さも実務的な利点です。Claude Opus 4.7を使っている場合は、WildClawBenchで62.2%と最高スコアを記録したハーネスでもあります。

Hermesが向いているケースは、毎日繰り返す業務タスクを自動化してコストを下げたい場合です。スキルが蓄積するにつれて処理が高速化・低コスト化していく。セキュリティを重視する業務環境では、CVE件数の差が重要な判断材料になります。

メッセンジャープラットフォームの広さは、両者ともほぼ同等（OpenClaw 22前後、Hermes 23前後）なので、「対応チャネルの多さ」だけを理由にどちらかを選ぶ意味はあまりありません。

移行については、OpenClaw → Hermes方向は公式コマンドでスキルが自動変換されます。ただし複雑な条件ロジックを含むスキルは手動レビューが必要です。逆方向（Hermes → OpenClaw）の公式移行パスはなく、手動での作業が必要です。

20体運用でHermesへの乗り換えを検討するなら、各エージェントの人格・役割定義の再構築作業が発生します。SKILL.mdはそのまま流用できますが、それ以外は手作業になります。「両者を組み合わせる」ハイブリッド構成——OpenClawを指揮役（受付窓口・複数エージェント管理）、Hermesを特定タスク専門担当として使う構成——のほうが、移行リスクが小さく済む場合があります。

---

OpenClaw と Hermes、まず試すべきこと

まず試すべきは、自分が何を体感したいかから逆算することです。

「スキルが勝手に育つ感覚」を体験したいなら、Hermesを2〜4週間動かし続けるのがおすすめです。標準でスキル自動生成が稼働するため、繰り返しタスクの中でスキル候補が積み上がっていく感覚が掴めます。スキルが20個前後に達したあたりでコスト削減効果が見え始め、その段階でGEPAを実行する価値も出てきます。起動直後にGEPAを走らせても最適化の対象がないので、ある程度蓄積を待つ必要があります。

「マルチエージェントを並行運用する感覚」を体験したいなら、OpenClawを1〜2週間動かしてみるのがおすすめです。両者ともマルチエージェント機能を持ちますが、OpenClawはコミュニティテンプレと運用事例（36体構成等）が豊富で、1プロセス・1Slackボットの軽量さもあって立ち上げ摩擦が低い。多体エージェントが独立並行で稼働する感覚を最短で体感できます。

なお、「メッセンジャープラットフォームの広さ」は両者ほぼ同等なので、対応チャネル数を基準に選ぶ意味は薄いです。WhatsAppもSlackもDiscordもTelegramも、どちらも標準でサポートされています。

両方を試したい場合は、用途を分けて並走運用するのが現実的です。例えば日常の繰り返し業務はHermesに任せ、マルチエージェント体制が必要な領域はOpenClawで組む、といった役割分担。スキル（SKILL.md）は両者で互換なので、後から比重を移すことも容易です。

同じエージェントを両方で並走させて比較できるか

「すでにOpenClawを使っていて、同じエージェント（例: 経営コンサルタント担当）をHermesでも並行運用して、どちらが質の良い結果を返すか比べてみたい」という比較運用は、技術的には可能です。実際にやる場合の構成例は以下：

• 同じマシン（または別マシン）にOpenClawとHermesを両方インストール
• Slackワークスペースを分ける（こちらはOpenClaw用、こちらはHermes用）。同一ワークスペース内で同じエージェント名を両ハーネスから動かすとボット衝突するため、ワークスペース分離が前提
• 同じSOUL.md相当の人格定義を両方に手動でコピー（SOUL.mdはマークダウンで互換）
• 同じスキルセット（SKILL.md）を両方にコピー（互換あり）
• 同じLLMモデル（例: Claude Opus 4.7）を両方に指定
• Heartbeatの周期は微妙にズラしてOK（30分vs45分など、定期起動の競合は気にしなくてよい）

これで「同じ人格・同じスキル・同じモデル・違うハーネス」という条件で結果比較ができます。「WildClawBenchで18ポイント差が出る」と書いた通り、ハーネスの違いだけで応答品質が動くことを実体感できます。

ただし、並走運用には以下のデメリットがあります。

並走比較は 「2〜4週間の評価期間限定」で割り切るのが現実的です。同じタスクを30回ほど両者に投げて主観評価し、明確に勝ち負けが見えたら片方に絞る、という運用がコスト的にも妥当。長期並走は「両者の使い分け（役割分担）」が目的でない限り、コストと工数に見合いません。

「ハーネスはモデルの性能の入れ物」というWildClawBenchの知見を頭に置いてください。先に試してから判断する——その順序が、機能収束時代に最も早い選び方です。