日常業務で AI エージェントを使い込んでいるエンジニアほど、クラウド型サービス特有の「壁」に突き当たることが増えています。作業の節目ごとに発生するコンテキストのリセット、週次や月次のトークン上限、そして使えば使うほど嵩むランニングコストは、自律型エージェントの常駐運用における大きなハードルです。

こうした背景から、自分のインフラ上で 24 時間稼働させられる「セルフホスト型 AI エージェント」への注目が急速に高まっています。2026 年初頭にマルチチャネル統合で話題を集めた OpenClaw に続き、Nous Research が公開した 「Hermes Agent」 は、単なるコマンド実行ツールにとどまらない 「自己改善（Self-Improving）」 や 「永続メモリ」 を前面に打ち出し、大きな関心を集めています。

本記事では、Hermes Agent のアーキテクチャを実装レベルで分解し、「自己改善」の技術的実態、OpenClaw との設計思想の違い、そして SRE 目線でのリアルな運用コストやセキュリティリスクを検証します。

1. クラウド型AIエージェントに感じている 3 つの摩擦

Claude Code をはじめとするクラウド依存型の AI エージェントは非常に強力ですが、実践的な業務で常用すると主に 3 つの摩擦が生じます。

  1. コンテキストのリセット: セッションが途切れるたびにプロジェクトの背景や前提条件を再指示する必要があり、作業の連続性が損なわれる。
  2. トークン制限とコスト: 大規模なリファクタリングや 24 時間監視を行おうとすると、週次・月次の利用上限に達しやすく、従量課金コストも増大する。
  3. ローカル環境への権限委譲の制約: クラウド経由でのツール呼び出しにはセキュリティポリシー上の制約が多く、インフラに直接密着した自動化が難しい。

当ブログの過去記事 Claude Code の週次制限プロモーション で触れたように、クラウドサービスの枠組みの中でハーネスを工夫するアプローチがある一方で、「エージェントのランタイム自体を自分の手元（セルフホスト）で所有する」アプローチへの関心が広がっています。

先行して登場した OpenClaw は TypeScript ベースの Gateway を中心とした Hub-and-Spoke 型アーキテクチャを採用し、接続性やオーケストレーションに強みを持っています1。これに対し、今回取り上げる Hermes Agent は 「学習とメモリの蓄積」 に焦点を当てたランタイムとして登場しました。

2. Hermes Agent とは何か — 一言でいうと “永続ランタイム”

まず前提として、モデルとエージェントフレームワークの混同を解消しておく必要があります。

  • Hermes 3: Nous Research が開発・公開してきたオープンウェイトの LLM（指示チューニングモデル）。
  • Hermes Agent: 2026 年 2 月にオープンソース化された Python 3.10+ ベースのエージェント実行環境（ランタイム/フレームワーク）2。

Hermes Agent は、MIT ライセンスで提供される OSS です3。公式発表によると、単体で CLI、Gateway サーバー（Port 8642 の OpenAI 互換 API）、および独自の常駐スケジューラ（Cron 相当機能）を備えており、バックグラウンドで常駐しながら自動化タスクを実行する 「永続ランタイム」 として動作します。

「Hermes Agent」という名称ですが、必ずしも Hermes 3 モデル専用というわけではなく、後述するように LiteLLM バインディングを介して様々な LLM をバックエンドとして指定できます。

3. アーキテクチャを分解する — Agent Core / Memory / Skill Library / MCP

Hermes Agent の内部構造は、大きく 4 つの要素で捉えることができます。

Hermes Agent のアーキテクチャ概略図

3.1 Agent Core — 薄いハブに責務を集約する設計

エージェントの中心に位置するのが、run_agent.py 内に定義された AIAgent クラスです。 このクラスは、ユーザーからのプロンプト構築、LLM プロバイダへのリクエスト送信、レスポンスのパース、および各種ツールのディスパッチ（実行）を一元的に管理します。

筆者の観察としては、いわゆるナローウエスト（Narrow Waist）型の設計と呼べる構成です。CLI、Gateway サーバー、バックグラウンドスケジューラなど多様な入力インターフェースが存在しますが、すべてはこの薄い Core エンジンを通過するよう統一されています。

3.2 Memory — 3 層構造 (実装層軸で整理)

本記事では、Hermes Agent のメモリ構造を公式の時系列分類ではなく 「実装層軸」 で 3 層に整理して解説します。

  1. システムプロンプト注入層: MEMORY.md（プロジェクト環境や不変ルール）および USER.md（ユーザーの嗜好）の 2 つのマークダウンファイル。毎ターンのシステムプロンプト冒頭に自動合成されます。
  2. 検索可能アーカイブ層: セッション対話ログやタスク実行結果を保持する SQLite + FTS5 全文検索データベース。毎ターン、過去の全ログを送信するのではなく、関連するキーワードや過去セッションのみを動的に抽出して注入します。
  3. 外部永続メモリプロバイダ層: プラグイン構造により、Mem0 や Honcho といった外部の長期的記憶サービスと連携可能な拡張口。

全対話履歴をリクエストごとに送信するクラウド型エージェントとは異なり、SQLite+FTS5 による動的抽出を行うことで、コンテキストウィンドウの圧迫を抑えつつ長期的文脈の保持を実現しています。

3.3 Skill Library — 経験を “手続き” として蓄積する

Hermes Agent の最大の特徴の一つが Skill Library です。公式仕様によると、タスクを実行して成功した一連の手順やツール呼び出しのパターンは、~/.hermes/skills/ ディレクトリ配下に再利用可能な Python スクリプトや Markdown ファイルとして自動保存されます。

エラー発生時には試行錯誤を行い、修正されたコードをスキルとして再構築するループを備えています（本記事ではこの反復を Closed Learning Loop と呼ぶ）。保存されたスキルは次回以降の類似タスクでインデックス検索され、ツールとして再読み込みされます。

3.4 LLM バックエンドと MCP — LiteLLM 経由の多バックエンドと標準プロトコル

Hermes Agent は、LLM との接続に LiteLLM バインディングを採用しています。これにより、LiteLLM 側の対応数として 300 以上の LLM バックエンド（OpenAI、Anthropic、Google Gemini、および Ollama や vLLM によるローカルモデル）を簡単に切り替えることが可能です。

また、Anthropic が提唱する MCP (Model Context Protocol) に対応しているため、サードパーティが提供する MCP サーバーをツールとして動的に取り込めます。さらに、Gateway モードでは Port 8642 で OpenAI 互換 API サーバーとして動作するため、既存の OpenAI クライアントや外部システムからの呼び出しも容易です。

4. 「自己改善」は本当か — 実装レベルで検証する

「自己改善（Self-Improving）」という言葉を聞くと、モデル自体の重みが更新（ファインチューニング）されるような印象を受けるかもしれません。しかし、実装レベルで検証すると、その実態は 「実行可能な手続き（コード・プロンプト）の抽出と動的再利用」 です。

何が学習され、何が学習されないのかの境界線を整理すると以下のようになります。

  • 学習される（蓄積される）もの:
    • ~/.hermes/skills/ に保存される Python スクリプトや実行手順 Markdown。
    • MEMORY.md や USER.md に追記される明示的な事実やユーザー嗜好。
    • SQLite+FTS5 データベースに蓄積される過去ログと全文検索インデックス。
  • 学習されない（蓄積されない）もの:
    • LLM のモデル重み（ベースモデルの知能自体が変化するわけではない）。
    • スキル化されなかった一回限りの操作における暗黙的な試行錯誤（公式に明記されているわけではありませんが、実装構造上、明示的にファイル化されない情報は次セッションに引き継がれません）。

Skill Library はローカルファイルシステム上の ~/.hermes/skills/ に独立したファイル群として出力されるため、ユーザー自身が Git 等で管理・バックアップ・チーム共有できる透明性を持っています。

5. OpenClaw と Hermes Agent — 設計思想の対比

2026 年のセルフホスト型エージェント界隈で注目を集める 2 大プロダクトですが、その設計思想は大きく異なります。筆者の見立てとしては、両者は「接続の広がり」と「経験の深まり」という直交する軸を担っていると整理できます。

評価軸OpenClawHermes Agent (Nous Research)
主要実装言語TypeScriptPython (3.10+)
アーキテクチャGateway 中心の Hub-and-Spoke 型Agent Core (AIAgent) 中心の実行型
設計の主眼接続性・ルーティング・複数チャネル統制メモリ蓄積・スキル自動生成・学習ループ
メモリ実装チャンネル・セッション単位の状態管理3層構造 (MEMORY.md/USER.md + SQLite FTS5)
拡張メカニズム外部ツール・プラグイン接続特化Skill Synthesis (~/.hermes/skills/)
適したユースケースメッセージング連携、複数エージェントのルーティング24時間常駐タスク、長期プロジェクト、自動化スクリプト成長

接続の柔軟性やマルチチャネル制御を重視する場合は OpenClaw が適しており、作業手順の自律的な蓄積やローカルスクリプトの自動構築を重視する場合は Hermes Agent が強力な選択肢となります。

6. 24 時間セルフホスト運用の現実 — SRE 目線のコスト・リスク

セルフホスト運用を検討する際、SRE 的視点から無視できないのが「運用コスト」と「セキュリティ権限」です。

6.1 費用の 3 レイヤーで考える — インフラ / API / 電気代

費用は以下の 3 つのレイヤーに分解して見極める必要があります。

  1. インフラ費: サーバー本体（VPS または自宅サーバー）。
  2. LLM API 費: クラウド LLM API（Anthropic、OpenAI、OpenRouter 等）の利用料。
  3. 電気代: 自宅マシンでローカル LLM を 24 時間回す場合の消費電力。

情報源によると、クラウド LLM API を主力バックエンドとし、Hermes Agent 自体は軽量な VPS で動作させる構成（推奨構成）の場合、1 CPU / 2〜4GB RAM 程度の小型 VPS で十分であり、インフラ費は 月額 $5 〜 $10 程度 に収まります4。一方、ローカル LLM（RTX 3090 や A10G 相当の GPU）を自前で 24 時間稼働させる場合は、インフラ費・電気代を合わせて 月額 $50 〜 $150 以上 のオーダー感となります4。

クラウド API 利用時の 月額 API 費 は、入力トークンと出力トークンの単価差が大きいため、以下の試算式で入出力を分離して見積もることを推奨します。

【変数定義】
  N_tasks       : 1 日あたりの平均タスク数
  T_in_per_task : 1 タスクあたりの平均入力トークン数
  T_out_per_task: 1 タスクあたりの平均出力トークン数
  P_in_per_1M   : モデルの入力単価 (USD / 1M tokens)
  P_out_per_1M  : モデルの出力単価 (USD / 1M tokens)
  D             : 稼働日数 (通常 30)

【月額 API 費の試算式 (USD)】
  ≈ N_tasks × D × (
      (T_in_per_task  × P_in_per_1M  / 1,000,000) +
      (T_out_per_task × P_out_per_1M / 1,000,000)
    )

例えば、1 日 30 タスク（N_tasks = 30）、1 タスクあたり入力 15,000 トークン / 出力 3,000 トークンの場合、選定するモデルの単価を当てはめることでリアルなコストが試算できます。なお、常駐スケジューラで定期タスクを回す場合は N_tasks にその実行回数が加算される点に注意が必要です。

6.2 権限・サンドボックス要件

エージェントにローカルでの Shell コマンド実行権限（Tool Execution）を付与した瞬間から、セルフホスト環境は「便利な実験環境」から「本番相当の運用対象」へと変化します。

Hermes Agent に限らず、OSS エージェントをセルフホスト運用する上での一般的な防衛線として、以下の要件を考慮すべきです。

  • Docker コンテナ化: ホスト環境のファイルシステムへの直接アクセスを断つ。
  • サンドボックス隔離: bubblewrap や e2b などの分離機構を用い、プロセスやネットワーク権限を制限する。
  • シークレット管理: ホストの全環境変数を引き継がせず、エージェント専用の .env ファイルに制限した API キーのみを注入する。

6.3 クラウド × セルフホストのハイブリッド運用

すべての作業をセルフホスト環境に寄せる必要はありません。過去記事 ハーネスエンジニアリング で解説したような「適材適所のハーネス設計」が有効です。

  • セルフホスト (Hermes Agent): 24 時間常駐の定期監視、情報の自動収集・整理、長期プロジェクトの文脈・スキル蓄積。
  • クラウド型 (Claude Code / Cursor 等): リアルタイムな対話型開発、複雑なアーキテクチャ設計、大規模コードベースの初期生成。

このように役割を分担させることで、コストと利便性の双方を最適化できます。

7. 採用チェックリスト — 試すべき人 / まだ様子見でよい人

ここまでの検証を踏まえ、Hermes Agent の採用判断基準をまとめました。

今すぐ試すべき人

  • Claude Code 等のコンテキストリセットに不満があり、長期プロジェクトで対話履歴やスキルを自動蓄積させたい。
  • LiteLLM を活用し、複数の LLM バックエンド（クラウド API とローカルモデル等）を柔軟に切り替えて検証したい。
  • VPS や Docker 環境を所有しており、サンドボックス隔離や環境変数管理などの運用設計を行うスキルがある。

まだ様子見でよい人

  • 「自己改善」という言葉から、LLM 自体のモデル重みが自動ファインチューニングされることを期待している。
  • コマンド実行権限を与えるリスクに対するサンドボックス環境やセキュリティ管理体制が準備できない。
  • ローカル LLM の 24 時間自前運用を前提としており、高額な GPU インフラ費の試算が立っていない。

8. まとめ — “接続の広がり” と “経験の深まり” は別軸

OpenClaw と Hermes Agent は、どちらが優れているかという競合関係ではなく、「外部システムとの接続性（OpenClaw）」と「経験と記憶の蓄積（Hermes Agent）」という別々の価値を提供するプロダクトです。

Hermes Agent の台頭は、AI エージェントの差別化要因が「モデルそのものの賢さ」から「コンテキストとスキルを保持するランタイムの設計」へと広がりつつあることを示しています。セルフホスト型エージェントの導入を検討する際は、まず「自分が解決したい課題が接続なのか、記憶・蓄積なのか」を明確にすることをお勧めします。

9. 相談窓口

セルフホスト型 AI エージェントの導入設計、Claude Code とのハイブリッド構成の検討、24 時間運用時のセキュリティやサンドボックス設計など、要件整理の段階からご相談を承っております。お気軽に コンタクトフォーム よりお問い合わせください。

Footnotes

  1. openclaw/openclaw - GitHub ↩

  2. NousResearch/hermes-agent - GitHub ↩

  3. NousResearch/hermes-agent LICENSE ↩

  4. userorbit.com - OpenClaw vs Hermes Agent Feature & Architecture Comparison ↩ ↩2