新しいカテゴリの AI ツールが静かに形作られつつあります。それは、開いて閉じるチャットウィンドウに存在するのではなく、クラウド上で継続的に動作し、ログオフすることのない同僚のように、メッセンジャーを通じてあなたと会話するエージェントです。
Hermes は、このアイデアのより興味深い実装の 1 つであり、OpenClaw のような類似のエージェントと異なる点は、内蔵された自己改善ループです。これは、あなたの会話を監視し、そこから有用なパターンを抽出し、それらのパターンを自身のメモリとスキルセットへの恒久的なアップグレードに変えるシステムです。
この記事では、Hermes がどのように構成されているか、その設定方法、そしてその自己改善ループが内部で実際にどのように機能するかについて詳しく説明します。
Hermes とは何か、OpenClaw との違い
Hermes は、クラウド常駐型の AI エージェントであり、構造的には OpenClaw と類似しています。24 時間 365 日稼働し、ターミナルやブラウザタブではなく、メッセージングアプリを通じて対話します。
重要な違いは 3 つあります。
第一に、Hermes は標準でより多くのビルトインスキルライブラリを搭載しているため、統合を自分でセットアップする手間が省けます。
第二に、セットアッププロセスがかなり合理化されており、ガイド付きの TUI がほとんどすべてを処理します。
第三に、そして最も重要なことですが、Hermes は継続的な自己改善を中心に設計されています。タスクを実行するだけでなく、時間の経過とともにより適切に実行する方法に関する手続き的知識を蓄積していきます。
インストールと初期セットアップ
Hermes を起動するには、1 つのコマンドを実行するだけです。
Windows では、PowerShell でこれを実行します:
iex (irm
Linux、macOS、または WSL では、同等のコマンドは次のとおりです:
curl -fsSL
インストール後、ターミナルを再起動して hermes setup を実行すると、モデルの選択、ターミナルバックエンド、メッセージングゲートウェイ、ツールのセットアップを順にガイドする設定フローが起動します。
モデルの選択とルーティング
セットアップにおける最初の実際の決定事項は、エージェントの「頭脳」をどの LLM プロバイダーが動かすかです。認証は生の API キーではなく OAuth を介して行われ、既存の Claude Code や Codex CLI セッションを通じてログインできるため、別途 API キーを生成する必要はありません。
ここで本当にうまく設計されているのは、Hermes がメインの会話に使用するモデルと、バックグラウンドや補助的なタスクに使用するモデルを分離している点です。デフォルトでは、同じモデルが両方を処理しますが、各補助タスクを独立して別のプロバイダーに向けることができます。
この種のオーバーライドをサポートするタスクは次のとおりです:
- vision – 画像分析と説明
- web_extract – 長いウェブページの要約
- compression – 溢れかえった会話コンテキストの圧縮
- title_generation – セッションタイトルの生成
- curator – 自己改善ループを担当するバックグラウンドエージェント
- kanban_decomposer – Kanban モードで大規模タスクをサブタスクに分割
- goal_judge –
/goalが実際に達成されたかどうかをチェックするエージェント
これは config.yaml で直接設定されます。例:
1# Primary model for chat and complex reasoning2model:3 provider: "anthropic"4 default: "claude-4-8-sonnet"5 auxiliary:6 vision:7 provider: "gemini"8 model: "gemini-2.5-flash"9 compression:10 provider: "custom"11 base_url: "http://localhost:11434/v1"12 api_key: "none"13 model: "qwen2.5:32b"
このような明示的なルーティングは、OpenRouter をデフォルトの選択肢とした場合の実際の問題を解決します。同じ名目上のモデルが多くの異なるプロバイダーによって、しばしば異なる量子化で展開されており、OpenRouter は新しいリクエストごとに、約 20 のプロバイダー間で静かにシャッフルします。
実際の影響として、1 つのセッション内で、一貫した 1 つのモデルと話しているのではなく、異なる設定で構成されたインスタンスのローテーションキャストと話していることになり、その中にはツールコールやプロンプトテンプレートを他のものより確実に処理するものもあります。Hermes 内で手動でルーティングすれば、この問題は完全に回避できます。
また、コーディング品質を犠牲にせずに会話モデルのコストを節約したい場合、Hermes は /claude_code および /codex コマンドをサポートしており、設定されたチャットモデルで処理する代わりに、コーディングタスクをそれらの CLI ツールに直接委任できます。
ターミナルバックエンド
アーキテクチャの中核部分はターミナルバックエンド環境であり、シェルコマンドや Python スクリプトが実際にどこでどのように実行されるか、そしてエージェントがどのようにファイルシステムにアクセスするかを決定します。Hermes は 5 つをサポートしています。
Local がデフォルトです。コマンドは、あなたのユーザーアカウントと同じ権限で、あなたのマシン上で直接実行されます。分離はありません。エージェントに実際のプロジェクトファイルを編集させたい、ローカル開発や信頼できる個人使用に適した選択肢です。
ここでの安全性は、破壊的なコマンド（rm -rf / や DROP TABLE など）を傍受し、実行前に明示的な許可を求めるビルトインの承認システムに完全に依存しています。
Docker は、エージェントを分離されたサンドボックス内で実行するため、ホストシステムにアクセスできません。SSH は、エージェントがリモート接続を介してリモートサーバー上でコマンドを実行し、ファイルを操作できるようにします。Modal は、すべてをサーバーレスのクラウドサンドボックスで実行します。基本的に、コンピューティングを秒単位でレンタルし、コードが実際に実行された秒数に対してのみ支払います。
Daytona は、AI コーディングエージェント専用に構築されたコンテナ管理レイヤーです。Docker を直接実行するよりも高速で、環境のセットアップと依存関係のインストールを自動的に処理します。
ほとんどの個人使用ケースでは、Local で十分です。他のオプションは、主に信頼できないコードを実行する場合やチーム規模で運用する場合に重要になります。
メッセージングゲートウェイとツール設定
ターミナルバックエンドの後、セットアップは実際にエージェントと会話する場所の選択に移ります。Telegram が最も洗練されたオプションです。これを選択すると、事前設定されたボットを起動する直接リンクが表示されます。手動でボットトークンを設定する必要はありません。
残りのセットアップでは、個々のツールとそれぞれのプロバイダー（ブラウザ自動化、画像生成、テキスト読み上げ、ウェブ検索）を有効にしていきます。特にウェブ検索では、セルフホストの Firecrawl または Exa が、エージェント指向のスクレイピングと検索に適した選択肢として際立っています。
X 検索を有効にするには Grok サブスクリプションが必要です。メニューで探す前に知っておくべき点です。
知っておくべきスラッシュコマンド
Hermes には多数のスラッシュコマンドが用意されており、そのほとんどは名前から機能が分かりますが、特筆すべきものをいくつか挙げます。
/background <prompt>は、メインセッションを中断せずにバックグラウンドでタスクを実行します。/goalは、エージェントが永続的に取り組む長期的な目標を設定します。一時停止、再開、クリア、ステータス確認のためのサブコマンドがあります。/subgoalは、アクティブな目標の下にある小さな目標を管理します。/kanbanは、複数の独立したエージェント間で非同期の長時間実行作業を調整します。実際のカンバンボードのように機能し、タスクのプールがワーカーエージェントに分散され、それらの間で引き継がれるにつれて、ToDo、進行中、完了の状態を遷移します。
開発面では、/github_pr_workflow は CI を含むブランチからマージまでの全サイクルを処理し、/github_code_review はプルリクエストをレビューし、/codebase_inspection はリポジトリの言語別構成と行数を分析します。/dogfood は、ウェブアプリのバグを探し、証拠に基づいたレポートを作成する専用の QA モードです。/spike は、本格的な開発に着手する前にアイデアを検証するための、迅速で使い捨ての実験を実行します。/systematic_debugging は、バグを 4 つのフェーズで処理し、修正を試みる前に根本原因を理解します。
また、統合固有のコマンドのクラスターもあります – /notion、/obsidian、/airtable、/google_workspace、/arxiv、/blogwatcher、/polymarket、/ocr_and_documents、/youtube_content – それぞれ特定の外部サービスまたはワークフローをラップしており、さらに /bundles は、小さな YAML 設定ファイルを介して、複数の既存のスキルを 1 つのスラッシュコマンドにグループ化します。
Cron ジョブと Webhook
特に注目すべき 2 つの自動化プリミティブがあります。
- Cron ジョブを使用すると、タイマーでスクリプトを実行するようにスケジュールできます。作成時に
-no-agentを渡すと、Hermes はプレーンな Python または bash スクリプトを実行し、その出力をメッセンジャーに転送するだけで、LLM トークンを消費しません。 - Webhook はより強力な部分です。エージェントがタイマーではなく外部イベントに反応できるようにします。たとえば、新しい GitHub プルリクエストが特定のプロンプトとスキルセットを持つエージェントを自動的にトリガーするように Webhook を設定できます。これにより、PR ごとに手動介入なしでオンコールレビューエージェントを実質的に立ち上げることができます。
コンテキストエンジン
コンテキストエンジンは、Hermes が会話履歴をモデルのトークン制限に近づいたときにどのように圧縮して管理するかを決定し、2 つのオプションがあります。
- デフォルトの Compressor は、長い会話の中間部分に非可逆的な要約を適用します。
- 代替の LCM（Lossless Context Management）は、構造的に異なるアプローチをとります。テキスト要約を生成する代わりに、会話の重要なポイントの有向非巡回グラフを構築し、エージェントが高レベルで高度に圧縮されたビューから、それをサポートする特定の元のメッセージまでナビゲートできるようにします。
メモリエンジン
外部メモリプロバイダーは、Hermes のビルトインローカルメモリファイル MEMORY.md および USER.md と並行して実行され、セマンティック検索やナレッジグラフなどの機能を追加します。
いくつかは、セットアップ TUI を通じて直接設定できます。
- Honcho は、詳細なユーザープロファイルのモデリングを中心に構築されており、バックグラウンドの LLM 呼び出しを使用して、2 つのレイヤーにわたる観察結果を統合します。ベースレイヤー（セッションの要約とプロファイル）と、ユーザーの現在のニーズを分析する弁証法的レイヤーです。
- OpenViking は、ファイルシステムスタイルの知識階層を構築するコンテキストデータベースであり、階層化されたコンテキスト検索をサポートし、各セッションの終了時に抽出された事実を、イベント、パターン、好みなど、6 つのカテゴリに自動的に分類します。
- Mem0 は、完全マネージド型のクラウドメモリサービスです。事実抽出はサーバーサイドで LLM を介して行われ、セマンティック検索、結果の再ランキング、自動重複排除が含まれますが、クラウドホスト型であるため、継続的なコストがかかる唯一のオプションでもあります。
- Hindsight は、GraphRAG スタイルのナレッジグラフ上に構築された、より高度な長期記憶システムです。セッションからエンティティを抽出し、それらの間の関係を構築し、ツール呼び出しを含む完全な会話ターンを保持します。メモリは、世界に関する事実、エージェント自身の経験、意見、観察の 4 つのカテゴリに分割されます。
- Holographic は、外部依存関係のないローカルな SQLite ベースの事実ストアです。保存された事実の信頼スコアリングシステムと、代数的で構成可能なクエリをサポートするための Holographic Reduced Representations の使用、および知識ベース内の矛盾を自動的に検出する機能が含まれています。
- RetainDB は、チームメモリのためのクラウド API であり、ベクトル、BM25、再ランキング手法にわたるハイブリッド検索を提供します。メモリは 7 つの異なるタイプに分割され、デルタ圧縮によりストレージを効率的に保ちます。
- ByteRover は、CLI を介してアクセスするポータブルなローカルメモリシステムであり、階層的な知識ツリーを構築し、非可逆圧縮によってコンテキストから削除される前に重要な事実を抽出します。
- Supermemory は、グラフ API を備えたセマンティック長期記憶を提供します。会話終了後に完全なセッションログを取り込んでナレッジグラフを構築し、現在のターンからの汚染を避けるために想起された事実を定期的にクリーンアップし、エージェントプロファイルごとにメモリを個別のコンテナに分離できます。
日常的な使用では、デフォルトのローカルメモリでほとんどの人にとって十分です。より重いシステムは、特にローカルホストオプションの場合、RAM などの実際のリソースコストと、ほとんどのワークフローがまだ必要としていない機能をトレードオフにしています。
自己改善ループ
これこそが、Hermes を従来のエージェントから最も際立たせる機能です。これは、あなたの会話を継続的に分析し、そこから有用なパターンを抽出し、それらのパターンを長期記憶と手続き的記憶（スキル）に書き込み、その後、蓄積された知識が時間とともに劣化しないように維持する、一連の非同期バックグラウンドプロセスです。システム全体はメインチャットと並行して実行され、トリガーシステム、バックグラウンドレビューエージェント、キュレーターの 3 つのコンポーネントで構成されています。
- トリガーシステム
Hermes はすべてのメッセージをリアルタイムで分析するわけではありません。それは無駄にトークンを消費するだけだからです。代わりに、しきい値を超えるとリフレクションパスをトリガーする 2 つのカウンターに依存しています。
メモリトリガーは、ユーザープロンプトが 10 回発生するごとに作動し、会話の中で保存する価値のある新しい事実が出現したかどうかを確認します。
スキルトリガーは、1 回のターン内でツール呼び出しの反復が 10 回発生するごとに作動します。これは、エージェントが試行錯誤によって問題を解決するために多くのステップを費やした場合、その経験は分析し、おそらく再利用可能なスキルに変換する価値があるという考えに基づいています。
いずれかのカウンターが制限に達すると、内部関数が作動し、現在の会話のスナップショットをバックグラウンドレビュープロセスに渡します。
- バックグラウンドレビューエージェント
このスナップショットは、メインセッションを中断することなく並行して実行される、完全に分離された独立したエージェントプロセスに送られます。これは 2 つの方向で機能します。
- 宣言的な側面では、新しいユーザーの好みや環境の詳細（Supabase への好み、Python 3.12 に固定されたプロジェクトなど）に気付いた場合、
MEMORY.mdまたはUSER.mdを更新します。どちらのファイルに事実が属するかによって異なります。 - 手続き的な側面では、エージェントが単純ではない問題を解決したか、複雑なプロセスを解明したことを検出した場合、新しいスキルを作成したり、既存のスキルを編集したり、対象を絞ったパッチを適用したり、スキルを完全に削除したりできます。作成されたスキルには、エージェントによって生成されたことが明示的にタグ付けされるため、その起源は常に追跡可能です。
キュレーターが後でこれらの自己生成スキルのどれが実際に保持する価値があるかを判断できるように、Hermes はすべてのスキルについて、プロンプトに読み込まれた回数、エージェントが読み取り用に開いた回数、編集された回数、作成日時、最終使用日時、最終編集日時を追跡する非表示の使用ログを維持します。
- キュレーター
チェックをしないままにしておくと、このプロセスは最終的に数百のスキルを生成する可能性があり、その中には冗長なものや時代遅れのものも含まれます。
キュレーターは、その知識ベースが劣化するのを防ぐために存在します。これは、2 つの条件が同時に満たされた場合にのみ起動します。前回の実行から十分な時間（デフォルトでは 7 日間）が経過していること、そしてメインエージェントがアクティブな作業を妨げないように十分な時間（デフォルトでは 2 時間）アイドル状態であることです。
変更を加える前に、スキルディレクトリ全体を自動的にバックアップするため、結果に満足できない場合は、1 つのターミナルコマンドでロールバックできます。
キュレーターの作業は 2 つのフェーズで行われます:
- 最初のフェーズは純粋に機械的であり、LLM 呼び出しは一切含まれません。使用状況メトリクスをチェックし、30 日以上使用されていないエージェント生成スキルを非推奨としてマークし、90 日以上使用されていないものをアーカイブフォルダーに移動します。重要なスキルは明示的にピン留めして、このプロセスから保護できます。
- 第 2 フェーズは、実際の LLM レビューです。キュレーターの補助タスク用に設定されたモデル（デフォルトではメイン会話と同じモデルですが、より安価なモデルに向けることもできます）を使用して、別の分離されたエージェントインスタンスを介して実行されます。これらの判断の質はスキルライブラリに実際に影響を与えるため、あまり安価なモデルを使用する際には注意が必要です。
各スキルについて、キュレーターは、正確で有用な場合はそのまま保持し、エラーや時代遅れのメソッドが含まれている場合は修正し、実質的に同じ内容をカバーする別のスキルとマージし（関連するスクリプト、評価、参照ファイルを適切に移動し、その過程で相対パスを書き換えます）、または完全にアーカイブすることを決定します。
サイクルの最後に、マージ後に古いスキル名が新しいものにどのようにマッピングされたかを示すリネームマップを含む詳細なレポートを生成するため、すべての決定の背後にある理由を完全に監査できます。
Hermes をうまく使うには
この種のクラウドエージェントは、24 時間 365 日実行できるあらゆるプロセス（コーディング作業は顕著な例外）に対して真に価値があります。ただし、そのプロセスを注意深く実際にデジタル化し、評価を含む堅牢なスキルをその周りに構築した場合に限ります。
良い結果を生み出す傾向にあるワークフローは、次のようなものです:
- まず、プロセスを最初から最後まで詳細に記録します。理想的にはディクテーションツールを使用して正確にキャプチャします。このステップは、プロセスを実際に理解しているか、適切に調査している場合にのみ機能します。
- その録音またはメモを、スキル作成ツールを使用してコーディングエージェントに渡し、最初のドラフトを作成します。特に複雑なものの場合、まだ引き継ぐには十分な品質ではありません。
- 評価（正しい結果を表すリファレンスソリューション）を組み込みます。これにより、スキルが適切に機能しているかどうかを推測ではなく実際に測定できるようになります。
- テスト環境でスキルを実行し、観察結果に基づいて評価とスキル内容の両方を洗練します。その編集のほとんどは委任するのではなく、手動で行います。
- スキルが一貫して決定論的に動作するようになって初めて、常時稼働のエージェントに引き渡すべきです。プロセスが何らかの外部サービスに依存している場合、ゼロから構築する前に、既存の MCP サーバーまたは CLI がそれをカバーしているかどうかを確認する価値があります。
より広い視点で言えば、このようなエージェントに任せることができることの範囲は、エージェントの生の能力ではなく、主に作業をどれだけうまく指定できるかによって制限されます。
ユースケース全体で有効と思われる 3 つの原則があります: コーディング作業を教師なしの 24 時間 365 日稼働するクラウドエージェントに外部委託しないこと、エージェントが実際に生成したものをレビューする人間をループに残すこと、そしてスキルの改良を一度完了して終わりにするものではなく、継続的な作業として扱うことです。
これが役に立ったなら、ブックマークしておいてください。また戻ってきたくなるはずです。
このような詳細な解説をもっと読むには、@ScottyBeamIO をフォローしてください。
無駄な部分は一切なし、実際に機能するものだけをお届けします。
