AIエージェントは賢いが、記憶がない。Claudeに「先週解決した方法と同じやり方で」と頼んでも、エージェントは先週何をしたか知らない。コンテキストウィンドウに過去ログを貼り付けたり、ベクトルDBに格納した履歴を参照させたりする手法はあるが、それは「記憶を渡す」行為であってエージェント自身が学習したわけではない。Nous Researchが開発するHermes Agentはこの問題に正面から向き合い、「使うほど賢くなる」自己改善ループを設計の核心に据えた。本記事では閉ループ学習の5段階プロセス、4層のメモリシステム、デプロイの柔軟性、2026年6月のデスクトップアプリ登場まで、Hermesの仕組みと限界を解説する。
AIエージェントの「健忘症」：セッションが終わるたびに経験が消える
「エージェントが同じミスを繰り返す」という経験は、AIエージェントを使い続けている開発者なら一度は遭遇している。ビルドコマンドの微妙なオプション、本番環境特有の設定の癖、APIレスポンスの例外パターン——こうした文脈をセッションのたびに渡し直す手間は、エージェントを「便利だが手間のかかるツール」にとどめてきた。
問題の根本は、大半のAIエージェントフレームワークが「ステートレスなリクエスト処理」として設計されていることにある。タスクを実行し、結果を返す。次のセッションでは白紙に戻る。RAG（Retrieval-Augmented Generation、検索拡張生成）を組み合わせれば情報の参照は改善されるが、「この手順でうまくいった」という手続き的な知識を自動的に蓄積するフレームワークは少ない。
Hermes Agentが提示する答えは「スキル文書の自動生成」だ。タスクを完了した後、エージェント自身が「次回同様のタスクに当たったときに参照できる手順書」を書き残す。初めて成功したレシピをノートに書き留めるシェフのように、Hermesはワークフローの経験をMarkdownドキュメントとして永続化する。そしてその文書は、次回のタスクでの検索・参照・さらなる改善の起点となる。
閉ループ学習の仕組み：5段階で「経験」を「スキル」に変える
Hermesの自己改善サイクルは5段階のループとして設計されている。この一連のプロセスを理解すると、単なる「メモリ付きエージェント」との設計上の違いが見えてくる。
最初のトリガーは、CLI（コマンドラインインターフェース）、Telegram、Discord、Slackなど20以上のプラットフォームからの入力だ。メッセージを受け取った瞬間、第2段階として過去のスキル文書を検索する。SQLite FTS5（Full-Text Search version 5、全文検索モジュール）を使い、1万件以上のドキュメントから関連するスキルを10ミリ秒未満で取得する。外部のベクトルDBを必要とせず、ローカルのSQLiteデータベース一本で完結するのは、インフラの複雑さを避ける意図的な選択だ。
第3段階は推論と実行だ。スキル文書から得た手順を参照しながらツールを呼び出し、タスクを実行する。第4段階の評価フェーズが、他のエージェントフレームワークとの決定的な分岐点になる。セッション中に5回以上のツール呼び出しが発生すると、エージェントは「このワークフローをスキルとして保存する価値があるか」を自動的に評価する。5回という閾値はワンショットの操作を除外し、複数ステップにわたる複雑な手続きのみを「学習する価値のある経験」として識別する設計上の判断だ。
第5段階として、保存価値があると判断されたワークフローはagentskills.io形式のMarkdownファイルとしてディスクに書き込まれ、次回以降のタスクで参照可能になる。Nous Researchのベンチマークでは、20件以上の自己生成スキルを持つエージェントが同じタスクを新規インスタンスより約40%速く完了した。スキルが増えるほど検索の命中率が上がり、ループの効率が高まる——これが「複利的な学習」という表現の意味するところだ。
4層のメモリシステム：「覚えておく」を多段階で実現する
「メモリ」とひとくくりに言っても、Hermesは目的の異なる4つのレイヤーを組み合わせている。オフィスビルの各フロアに例えると把握しやすい。1階は今日来た顧客対応、2階は常連客の台帳、3階は業務マニュアル、4階は顧客ごとの個別の好みを記録する部屋だ。それぞれが独立して機能しながら、タスク実行時には連携して参照される。
第1層：セッションメモリは、現在の会話内のコンテキストを管理する。/compressコマンドで圧縮したり、/usageでトークン使用量を確認したりしながら明示的に操作できる。会話が終われば消える一時的な記憶であり、この点は通常のLLMと変わらない。
第2層：永続メモリが、Hermesの特徴的なレイヤーだ。SQLite FTS5でローカルに保存されるため、サードパーティのサービスに依存せずプライバシーを保持できる。10ミリ秒の検索遅延で1万件超の文書に対応し、エージェントは定期的に「メモリを整理する」よう自発的に動いて重要な情報を自己整理する。過去のセッションを横断して情報を引き出せるため、数週間前に解決した問題の手順を参照するといった使い方が可能になる。
第3層：スキル文書が学習ループで生成されるMarkdownファイルだ。重要な設計上の工夫として、スキルの名称と1行の説明だけがデフォルトでシステムプロンプトに読み込まれ、本文はオンデマンドで参照する遅延読み込みになっている。スキルが40件から200件に増えてもコンテキストコストが比例して増加しないのはこの仕組みのためで、大規模なスキルカタログを実用的に扱える根拠がここにある。v0.10.0時点でNous Researchがセキュリティレビュー済みの96件のバンドルスキルが提供され、コミュニティが公開するスキルハブには643件以上が登録されている。
第4層：Honchoはオプションのユーザーモデリングレイヤーで、使用するテックスタック、コミュニケーションスタイルの好み、頻繁に連絡する相手といった情報を受動的に蓄積する。有効にすると、エージェントは「このユーザーはPythonとDockerを組み合わせて使うことが多い」「詳細よりも結論を先に提示されることを好む」といった個人モデルを徐々に構築していく。4層それぞれが「今日何をするか」から「このユーザーはどう作業するか」まで、異なる粒度の記憶を並行して担う設計だ。
「どこでも動く」設計：$5のVPSからGPUクラスターまで
Hermesが「話す場所」と「作業する場所」を意図的に分離していることは、他のエージェントフレームワークと一線を画す思想だ。ユーザーはTelegramで指示を出しながら、実際のタスクはクラウドのGPU上で並列実行するといった構成が標準でサポートされている。$5のVPSにHermesを常時起動させ、スマートフォンのTelegramからタスクを投げるという使い方は、ドキュメントが公式に示すユースケースだ。
実行バックエンドは6種類から選択できる。ローカル、Docker、SSHの3つが基本で、Daytona（クラウドワークスペース）、Modal（サーバーレスGPU）、Singularity（HPCクラスター向け）がより高度な用途に対応する。学術機関でSingularityを使ったHPCクラスターにアクセスしながら、日常的なコミュニケーションはSlackで行うといった研究者向けの使い方も想定されている。
メッセージングゲートウェイは20以上のプラットフォームを統一的に扱う。Telegram、Discord、Slack、WhatsApp、Signal、Email、Google Chat（2026年5月のv0.13.0で20番目として追加）、LINE（同v0.14.0で追加）などだ。単一のゲートウェイサービスが複数チャネルからのルーティング、セッション状態の管理、クロスプラットフォームの継続性を担うため、Telegramで開始した会話をSlackで引き継ぐといった操作も可能だ。
LLMプロバイダーは30以上に対応する。Nous Portal、OpenRouter、OpenAI、Google AI Studio、ローカルのvLLMやOllamaなど、hermes modelコマンドで切り替え可能なモデル非依存設計だ。組み込みツールは60件以上を備え、MCP（Model Context Protocol、モデルコンテキストプロトコル）サーバーへの接続でさらに拡張できる。音声モードも搭載しており、ターミナルを開かずに音声でエージェントに指示を出す使い方も可能だ。
2026年のHermes：デスクトップアプリとマルチエージェントの進化
2026年5月から6月にかけて、Hermesは立て続けに重要なアップデートを打ち出した。
v0.13.0（2026年5月7日）で登場したマルチエージェントKanbanは、タスクをボードで管理しながら複数のHermesワーカーが分担・引き継ぎ・完了まで実行する機能だ。個人の仕事だけでなく、AIの「チーム」に分業させるという使い方が現実的になった。/goalコマンドにより、エージェントがターン間で目標を維持し続ける機能も加わり、長時間かかる複合タスクでの一貫性が向上した。
v0.14.0（2026年5月16日）ではxAIのSupergrok・Premium+アカウントを通じたGrokモデルアクセス、OpenAIモデル向けのCodexランタイムバックエンド、動画生成機能が追加された。LINEもゲートウェイに加わり、日本語圏のユーザーにとって馴染みのあるインターフェースでHermesを使えるようになった。
そして2026年6月2日、Hermes Desktop（v0.15.2）が公開プレビューとして発表された。macOS、Windows、Linuxに対応したネイティブアプリで、ElectronシェルがCLIと同じHermesランタイムを標準のゲートウェイAPI経由で呼び出す構造だ。CLIから移行してもセッション、スキル、メモリ、APIキーの設定がそのまま引き継がれる。プロジェクトブラウザー、アーティファクトサポート、ツール活動のストリーミング表示、ファイルプレビュー、マルチ会話管理といったGUI固有の機能も実装された。Nous Portalとの連携でサブスクリプションティアのモデルクレジットや300以上のモデルへのアクセス管理もデスクトップ内から行える。
Hermesを選ぶべき場面、見送るべき場面
Hermesとしばしば比較されるOpenClawは、プラットフォーム統合の広さで対照的な設計を持つ。コミュニティスキルがHermesの643件に対してOpenClawは1万3,000件以上と生態系の成熟度に差がある。24以上のプラットフォームに対応するOpenClawは、複数のサービスを横断する統合ハブとして機能することに長けている。
Hermesが強みを発揮するのは、同じ開発者が同じ領域で長期的に使い続ける場面だ。「深さへの投資」と「広さへの投資」という対比が分かりやすい。Hermesは自分自身にエージェントをデプロイするツールであり、OpenClawはユーザーに向けてエージェントをデプロイするプラットフォームだ、という整理も有効だ。6ヶ月以上使い込んだHermesは、新規インスタンスでは得られない領域固有の手続き知識を持ち始める。
ただし、実装上の注意点は明確にある。自己学習機能はデフォルトで無効になっており、memory.persistentとskills.autogenの設定を明示的に有効化しなければならない。スキルと記憶の内容を一括エクスポートする機能がないため、GDPR（EU一般データ保護規則）準拠を求める環境では課題が残る。v0.xリリース間での破壊的変更が頻繁なため、本番環境への組み込みには継続的なメンテナンスコストを見込む必要もある。また、50回以上のツール呼び出しを含む複雑なマルチフェーズタスクから生成されたスキルは、過度に一般化したり、特定セッションのコンテキストに依存しすぎたりする場合がある。
セキュリティ面では、2026年4月時点でHermes固有のCVE（Common Vulnerabilities and Exposures、共通脆弱性識別子）がゼロという記録を持つ。OpenClawが2026年3月に4日間で9件のCVEを開示した（CVSS最高値9.9を含む）のと対照的だ。厳選されたスキルカタログと、自動生成スキルをユーザーのローカルディレクトリに閉じ込める設計が、攻撃対象の範囲を狭める効果をもたらしている。
MITライセンスのオープンソースとして公開されており、試行のコストは低い。1つの領域でエージェントに知識を長期的に蓄積させたい開発者、同じタスクを繰り返しこなすワークフローを自動化したい用途には、Hermesの閉ループ学習モデルを試す価値がある。広いサービス統合と豊富なコミュニティスキルをすぐに使いたいなら、OpenClawのほうが近道だ。
