Hermes Agent入門 — Nous Researchの「自己改善型AIエージェント」を読み解く

エージェントは「やったこと」から学べるか

ほとんどのAIエージェントは「あなたが言ったこと」は覚えても、「自分がやったこと」からは学びません。 昨日うまくいった手順も、明日には白紙から組み直す——この壁に正面から取り組んだのが Hermes Agent です。Nous Research が2026年に公開したオープンソースの 自己改善型（self-improving）AIエージェントで、公開から3か月足らずでGitHubスター14万を超え、 OpenRouter上で最も使われているエージェントになったと報じられています。

本記事はHermes Agentを「概念」と「使い方」の両面から読み解きます。 なぜ「記憶」だけでは足りず「学習ループ」が要るのか、3層メモリとスキル層はどう設計されているのか、 そして手元でどう動かすのか。一次情報（GitHubリポジトリ・公式ドキュメント）と解説記事をもとに整理します。

Hermes Agentとは — 一言でいうと

Hermes Agentは 「あなたのメッセージング環境に住み着き、使うほど自分でスキルを育てていく永続パーソナルエージェント」 です。 特徴は大きく3つに整理できます。

• セッションをまたぐ記憶：プロジェクト・好み・文脈を覚え、過去の会話をSQLiteのFTS5全文検索で引き出す。
• スキルの自己生成：完了したタスクから手順（procedural skill）をMarkdownで自動作成し、使いながら改善・再利用する。
• マルチプラットフォーム常駐：Telegram / Discord / Slack / WhatsApp / Signal / CLI を統一ゲートウェイで束ねる。

ライセンスは MIT。$5のVPSからサーバーレス基盤までどこでも動かせる設計で、 「クラウドのSaaSに自分の文脈を預ける」のではなく、自分で所有・自己ホストするエージェントに振り切っているのが思想的な核です。 LLMは特定ベンダーに縛られず、Nous Portal・OpenRouter（200以上のモデル）・OpenAI・自前エンドポイントなど、好きなモデルを選べます （Nous自身のHermes-4-405Bも利用可能）。

なぜ「記憶」だけでは足りないのか

2026年、エージェントに「永続メモリ」を持たせること自体は珍しくなくなりました。 しかしHermesの主張は一歩踏み込んでいます。「多くのエージェントは“何を言われたか”を覚えるだけ。Hermesは“何をやったか”から学ぶ」というものです。

両者の違いは、記憶の種類にあります。会話ログや事実を貯めるのは エピソード記憶（何が・いつ起きたか）。 一方、「この種の問題はこう解く」という手続き記憶（how）は、貯めるだけでは生まれません。 Hermesはタスクの遂行過程をスキルとして抽出し、次に似た問題が来たら過去の手順を読み込み・適用し・洗練する—— この学習ループを回す点が、単なる「記憶つきチャットボット」との分かれ目です。

設計思想① 層化されたメモリ — 役割で記憶を分ける

Hermesは記憶を単一の巨大ストアにせず、役割（時間軸・機能）で層に分けます。 「常に知っておくべきこと」「過去に何が起きたか」「この種の問題をどう解くか」を別々の層が担い、文脈の肥大を防ぎます。

flowchart TB
    subgraph Always["常時ロード"]
      P["プロンプトメモリ<br/>MEMORY.md / USER.md<br/>合計約3,575字・即時の文脈"]
    end
    subgraph OnDemand["必要時に検索"]
      S["セッション検索<br/>SQLite + FTS5<br/>エピソード記憶（何が・いつ）"]
      K["スキル層<br/>~/.hermes/skills/*.md<br/>手続き記憶（どう解くか）"]
    end
    H["Honcho ユーザモデリング<br/>（任意・受動的に嗜好を学習）"]
    P --> SP["システムプロンプト"]
    S --> SP
    K --> SP
    H -.-> SP

層1：プロンプトメモリ（MEMORY.md / USER.md）

常にシステムプロンプトへ注入される即時文脈です。USER.md（ユーザー像）と MEMORY.md（事実・好み）の2ファイルで、 合計でおよそ3,575文字という厳しい上限が課されます。重要なのは、編集が効くのは次のセッションからで、 会話の途中では反映されないこと。「毎回必ず見る、けれど少量だけ」という枠を意図的に絞っているわけです。

層2：セッション検索（SQLite + FTS5）

すべての会話はSQLiteに保存され、FTS5（Full-Text Search 5）で全文インデックスされます。 エージェントは「過去の文脈が今役立ちそうだ」と判断したときだけ、この層を自分で検索します。 ポイントは、ヒットした結果をそのまま注入せず、LLMで要約してから取り込むこと。 これにより、数か月分の履歴があってもモデルの文脈上限を食いつぶさずに「いま必要な分」だけを引き込めます。

層3：スキル層（手続き記憶）

再利用可能なワークフローを ~/.hermes/skills/ 配下に1スキル＝1Markdownファイルとして貯めます。 ここで効くのが プログレッシブ・ディスクロージャ（段階的開示）です。既定ではスキル名と要約だけをロードし、 本文は必要になった時点で読み込む。だからスキルが何個に増えてもトークンコストはほぼ一定に保てます。

設計思想② スキル自己生成ループ — 「やったこと」を手順に変える

Hermesの中核がこれです。タスクをこなすたびにスキルを作るわけではなく、「学ぶ価値がある」と判断したときに発火します。 主なトリガー条件は次の通りです。

• 1つのワークフローでツール呼び出しが5回以上に及んだ
• エラーからの回復が起きた（試行錯誤の知見がある）
• ユーザーによる修正・訂正が入った
• 自明でないが効果的な手順を踏んだ

条件を満たすと、スキルは ~/.hermes/skills/ に agentskills（agentskills.io）のオープン標準で書き出されます。 名前・説明・バージョン番号・対応プラットフォームといったメタデータを持つ構造です。 作って終わりではなく、スキルは使いながら磨かれます。エージェントは skill_manage ツールの6アクション （create / patch / edit / delete / write_file / remove_file）でスキルを操作し、 既定ではpatch——全文書き換えではなく旧→新の差分だけを渡す——を使います。 トークンを節約し、既存スキルを壊すリスクも抑えるためです。

flowchart LR
    T["タスク実行"] --> C{"学ぶ価値あり？<br/>5回以上のツール呼び出し<br/>エラー回復・ユーザー修正など"}
    C -->|No| E["通常終了"]
    C -->|Yes| W["スキルを生成<br/>agentskills標準のMarkdown"]
    W --> R["次に似たタスク<br/>名前・要約で検索しヒット"]
    R --> A["読み込んで適用"]
    A --> P["skill_manage patch で改善"]
    P --> R

この「生成→適用→改善」のループこそが、Hermesを単なる永続メモリのエージェントから一段引き上げている部分です。 ユーザー製・コミュニティ製のスキルも同じ標準なので、agentskillsハブを通じてインストール間で持ち運び・共有できます。

アーキテクチャ全体像 — エージェントループ

ここまでを1本の流れにまとめると、Hermesの同期オーケストレータ（run_agent.py）はおおむね次の順で動きます。

flowchart TB
    A["1. タスクID生成"] --> B["2. システムプロンプト構築<br/>メモリ各層＋スキル索引<br/>（キャッシュがあれば再利用）"]
    B --> C["3. プリフライト圧縮チェック<br/>文脈上限の超過を防ぐ"]
    C --> D["4. API呼び出し＋ツール実行ループ"]
    D --> E["5. セッションをSQLiteへ永続化"]
    E --> F["6. ゲートウェイ経由で応答を返す"]

会話が長くなって圧縮センチネルに達すると、補助モデルが「残すべき情報」をプロンプトメモリの約3,575字の枠内に抽出し、 途中のターンを要約します。このとき系譜（lineage）——元の会話への参照チェーン——がSQLiteに保持されるため、 要約後も「どの発言が根拠か」を遡れるトレーサビリティが残ります。 記憶を圧縮しても出所を失わない、という運用設計です。

使ってみる — インストールとCLI

導入は1行です。Linux / macOS / WSL2 / Termux ならインストールスクリプトを叩くだけで動きます。

# インストール（Linux / macOS / WSL2 / Termux）
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

# シェルを読み直して対話を開始
source ~/.bashrc
hermes

主要なCLIコマンドは用途ごとに分かれています。まずは hermes setup でモデルやツールをひととおり設定し、 あとは hermes で対話する流れです。

hermes setup     # 設定ウィザード（モデル・ツールを一括設定）
hermes model     # 使用するLLMプロバイダ／モデルを選択
hermes tools     # 有効化するツールを設定
hermes gateway   # メッセージングゲートウェイを常駐起動
hermes update    # 最新版へ更新

真価は hermes gateway で出ます。これを起動するとHermesがバックグラウンドサービスとして常駐し、 Telegram / Discord / Slack / WhatsApp / Signal から同じエージェント（同じ記憶・同じスキル）に話しかけられます。 「PCのターミナルでも、スマホのメッセージアプリでも、同じ自分のエージェント」が実現します。

モデルは自由に差し替えられます。たとえば自前エンドポイントでNous製の Hermes-4-405B を使う場合は、 APIキーを渡してエンドポイントを指定します。

# 例：外部プロバイダ経由で Hermes-4-405B を使う
export NEBIUS_API_KEY=your_key_here
# hermes model でカスタムエンドポイントを設定
#   Base URL : https://api.tokenfactory.nebius.com/v1/
#   Model    : NousResearch/Hermes-4-405B

どこで動かすか — ローカルからサーバーレスまで

Hermesは実行バックエンドを選べます。ローカル・Docker・SSH・Singularity に加え、 Modal / Daytona ではサーバーレスでの永続化（セッション間のハイバネーション＝使わないときは眠り、来たら起きる）が可能です。 さらに NVIDIA RTX PC や DGX Spark といったローカルGPU上で、データを外に出さずに自己ホストする構成も整っています。 「$5のVPSで気軽に」から「手元のGPUで完全自己完結」まで、同じエージェントを幅広い土俵で動かせるのが強みです。

他のエージェント／記憶ソリューションとの立ち位置

「エージェントの記憶・学習」は2026年の激戦区です。代表的な選択肢とHermesのざっくりした立ち位置を整理します （各製品は進化が速いため、概念的な比較として読んでください）。

ひとことで言えば、Hermesは「自己ホスト前提で、やったことから手順を学び続けるパーソナルエージェント」に振り切った設計です。 記憶基盤（どう貯めるか）にフォーカスするGBrainとは補完的で、 「Hermesの記憶層としてこうした基盤を組み合わせる」といった発想も成り立ちます。

よくある誤解

まとめ

• ① 「覚える」ではなく「学ぶ」。 Hermesはタスクの遂行過程からスキル（手続き記憶）を自動生成し、patch中心のskill_manageで磨き続ける。これが単なる永続メモリのエージェントとの分岐点。
• ② 記憶は役割で層化する。 常時ロードのMEMORY.md／USER.md（約3,575字）、SQLite+FTS5でLLM要約して引くセッション検索、本文を遅延ロードするスキル層。文脈肥大を避けつつ的を絞って引き出す。
• ③ 自己ホスト前提で、どこでも・どのモデルでも。 MITライセンス、curl一発で導入。hermesで対話、hermes gatewayでTelegram等に常駐。$5 VPSからローカルGPU（DGX Spark）まで、好きなモデルで自分のエージェントを所有できる。