「Hermes Agent」タグアーカイブ

コンピュータ

「電脳化」をHERMES Agentで目指す

コメントする

HERMES Agentのメモリ構造を初めて知ったとき、私は直感的にこう思った。 「これは攻殻機動隊の『電脳化』だ」と。

単なる記憶の拡張ではない。思考プロセスそのものを外部化し、構造化し、自律的に運用させる。自分の知能を拡張するシステムを自前で構築できるというのは、エンジニアとして最高にエキサイティングな体験だ。

構想した「電脳化」の三層構造

私が描いた理想のサイバーブレインは、以下の三層構造で構成されている。

  1. 永続メモリ（Persistent Memory）：個人のアイデンティティや環境設定を刻む「本能」層。
  2. 構造化ナレッジ（llm-wiki）：相互リンクで知識を管理する「知識・図書館」層。
  3. 思考の型（Skills）：専門的なワークフローを定義し、知能に「型」を与える層。

特に「Wikiファースト」の運用にはこだわった。ネットで調べる前にまず自分のWikiを確認させ、「調査 → 納得 → 刻む」というサイクルを回すことで、AIを真の意味での外部脳へと進化させる。

現実：AIの「わかったつもり」という壁

だが、現実はそう甘くない。実装して分かったのは、理想のアーキテクチャを組んでも、それを動かす「知能」という不確定要素が最大のボトルネックになるということだ。

「わかったつもりで、どんどんズレていく」

これが今の最大の悩みである。 指示を出せば「承知いたしました」と完璧な返答が返ってくる。しかし、実際に出力される結果を見ると、微妙に私の意図から逸れている。あるいは、せっかく llm-wiki という強力な機能があるのに、それを使いこなせずに一般的な知識で回答を済ませてしまう。

「いや、そこはWikiに書いた私のこだわりを反映してくれ」 「そこはツールを使って具体的に検証してくれ」

そんなもどかしさが常に付きまとう。電脳化のインターフェースは整ったが、その中を通る「思考の同期」という部分で、まだ激しいノイズが走っている状態だ。

実は

Hermes Agentのメモリの三層構造は実は↑で書いたような構造になってなかった。

  1. セッションメモリ :セッション内でだけ有効 (短期記憶)
  2. 永続メモリ（Persistent Memory）：確かにあるんだけど2200文字しか入らない
  3. SQLite セッション検索:全セッション情報をDBで持ってるので検索できる(けど常用するものじゃない）
  4. 構造化ナレッジ（llm-wiki）：確かに機能としてはあるんだけど普通には中を見てくれない

こんな感じです。 なので、まずナレッジはllm-wikiに保存するように指示を出し、それを永久メモリに指示を書く。 が正解ですね。

まぁ、それでも中々うまくいかないのですが。 しかし、だからこそ面白い。

どうすればAIが私の意図を正しく汲み取ってくれるか。どうすればWikiの情報を適切に引き出せるか。プロンプトを練り、スキルを書き換え、メモリを整理する。この試行錯誤こそが、自分の思考を客観視し、再構築するプロセスそのものだからだ。

まぁ、面白いおもちゃを手に入れた感じ(笑)

p.s. 攻殻機動隊とは関係ないが、AIとの融合を説いているAI仙人というYoutuberさんが居て、 彼が唱えるのは、自分のあらゆるコンテキストをAIに与え、自分の「賢い分身」としてAIを運用するという考え方。これもう電脳化だよね。と個人的には思う。

今でもこの人はAIグラスや音声から文字お越しをするデバイスなどを使えば疑似電脳空間は味わえるかも。

完璧なサイバーブレインはまだ遠い。 けれど、自分の知能を拡張しようともがくこのプロセス自体が、すでに一種の「電脳化」なのかもしれない。

コンピュータ

LLM運用の変遷と現状について

コメントする

はじめに

LLMの運用環境構築と運用において、いくつかの試行錯誤を経て現在の構成に落ち着きました。その変遷をまとめます。

1. ローカルLLM時代（RTX 3060 12GB）

最初はコストの観点から、ローカル環境での運用を試みました。

  • 環境: NVIDIA RTX 3060 (VRAM 12GB)
  • 課題: 12GBというVRAM容量の制限から、ロードできるモデルのサイズに限界がありました。結果として、「知能（賢さ）」と「推論スピード」のどちらを優先しても満足いくレベルに達せず、複雑なタスクを完結させるには力不足を感じました。

2. OpenRouter 移行期

次に、多様なモデルをAPI経由で利用できるOpenRouterをメインに据えました。

  • メリット: 最新の高性能モデルを即座に切り替えて利用でき、知能レベルは飛躍的に向上しました。
  • 課題: 運用量が増えるにつれ、APIコストが無視できない金額になってきました。特にHERMESのようなエージェント的な使い方（多回数のツール利用や長いコンテキストのやり取り）をすると、コストの消費速度が速いのがネックでした。

3. 現在：NVIDIA Build API の活用

現在は、NVIDIAの無償枠（NVIDIA Build API）をメインに稼働させています。

  • ここが素晴らしい: 毎分リミット（約40 RPM / Requests Per Minute）がリセットされる仕組みのため、HERMESのような自律型エージェントとしての運用において、実質的に無料で高性能なモデルを使い続けることができます。コストを気にせず、思考プロセスを回せるため、運用効率が劇的に改善しました。もっと大きなモデルも無償で使えるのですが、やはり人気があり一時的に制限が掛ること多かったので、gemma-4-31b-itを使っています。2週間ほど使っていますが、Qwen3.6-35b-a3bと同等な推論力でこっちの方が色々と素直（Qwenはなんでそうなる？的なことが結構あった。思想の違い？）な印象でした。フォールバック先としては、OpenRouterとollamaを指定しています。2週間使ってますが、フォールバックしたことないですね。

現在のLLM設定（config.yamlより）

知能とコストのバランスを最適化するため、以下の優先順位でフェイルオーバーするように設定しています。

優先順位: NVIDIA (Primary) $\rightarrow$ OpenRouter (Fallback 1) $\rightarrow$ Ollama (Fallback 2)

# メインモデル設定
model:
  default: google/gemma-4-31b-it
  provider: nvidia

# フェイルバック設定
fallback_providers:
  - model: google/gemma-4-31b-it:free
    provider: openrouter
  - model: qwen3-8b-agent:latest
    provider: ollama-launch

ここ1か月の利用状況です。 gemma-4-31b-it にする前に、短期間、 qwen3-next-80b-a3b-instructを使っていましたが、日本語で書けと言ってるのに無視して英語で書いてくるのが嫌になって乗り換えました(笑)

$ hermes insights

  ╔══════════════════════════════════════════════════════════╗
  ║                    📊 Hermes Insights                    ║
  ║                       Last 30 days                       ║
  ╚══════════════════════════════════════════════════════════╝

  Period: Jun 12, 2026 — Jun 19, 2026

  📋 Overview
  ────────────────────────────────────────────────────────
  Sessions:          102           Messages:        3,002
  Tool calls:        1,317         User messages:   219
  Input tokens:      48,455,313    Output tokens:   276,229
  Total tokens:      50,096,764
  Active time:       ~28.8d        Avg session:     ~8h 19m
  Avg msgs/session:  29.4

  🤖 Models Used
  ────────────────────────────────────────────────────────
  Model                          Sessions       Tokens
  qwen3-next-80b-a3b-instruct          44   36,590,024
  gemma-4-31b-it                       58   13,506,740

  📱 Platforms
  ────────────────────────────────────────────────────────
  Platform       Sessions   Messages         Tokens
  discord              53      2,017     34,742,567
  cron                 49        985     15,354,197

  🔧 Top Tools
  ────────────────────────────────────────────────────────
  Tool                            Calls        %
  terminal                          430    32.6%
  read_file                         348    26.4%
  browser_navigate                  143    10.9%
  write_file                         66     5.0%
  search_files                       59     4.5%
  patch                              42     3.2%
  skill_view                         34     2.6%
  browser_console                    33     2.5%
  execute_code                       26     2.0%
  browser_snapshot                   16     1.2%
  session_search                     16     1.2%
  cronjob                            15     1.1%
  memory                             15     1.1%
  browser_type                       14     1.1%
  todo                               13     1.0%
  ... and 15 more tools

  🧠 Top Skills
  ────────────────────────────────────────────────────────
  Skill                          Loads   Edits   Last used
  fx-bot-development-cycle          17       3      Jun 19
  llm-wiki                           7       0      Jun 19
  vibe-trading                       2       0      Jun 16
  daytrade-bot-automation-setu       2       0      Jun 14
  fx-bot-development-developme       1       0      Jun 19
  hermes-agent                       1       0      Jun 18
  arxiv                              1       0      Jun 14
  blogwatcher                        1       0      Jun 14
  google-workspace                   1       0      Jun 14
  xread-free                         1       0      Jun 14
  Distinct skills: 10  Loads: 34  Edits: 3

  📅 Activity Patterns
  ────────────────────────────────────────────────────────
  Mon  ██████          12
  Tue  ████            8
  Wed  ████            8
  Thu  █████████       16
  Fri  ███████████████ 26
  Sat  ███████████     20
  Sun  ██████          12

  Peak hours: 4PM (17), 6AM (13), 7AM (12), 8AM (12), 9AM (10)
  Active days: 8
  Best streak: 8 consecutive days

  🏆 Notable Sessions
  ────────────────────────────────────────────────────────
  Longest session      4.3d               (Jun 13, 20260613_162936_)
  Most messages        226 msgs           (Jun 12, 20260612_135409_)
  Most tokens          3,265,770 tokens   (Jun 12, 20260612_110119_)
  Most tool calls      106 calls          (Jun 12, 20260612_135409_)

この構成により、まずはNVIDIAの高性能な無料枠を最大限に活用し、リミットに達した場合はOpenRouterの無料モデル、最終的にはローカルのOllamaへと切り替わるため、システムが完全に停止することなく稼働し続けることができます。これが無料ってすごくないですか？さすが大儲けしてるNVIDIAさんですね(笑)

コンピュータ

Hermes Agent + Qwen36-35B-A3B に「自律修正」を任せてみた

コメントする

VPS上で動かしているFXボット群の監視・改善を、Hermes AgentにQwen3-35B-A3Bを載せて自律的にやらせてみた。指示は「問題を見つけたら自分で直せ」。結果は「発見はできる。修正は荷が重かった」。

何をやらせたか

VPS上で複数のFXボット（bot_pattern、bot_gmo、bot_ha_ema など）が稼働している。
Hermes Agentに「ログやコードを見て、問題を自発的に発見・修正せよ」という自律タスクを与えた。

モデルはQwen36-35B-A3B（Mixture-of-Experts、アクティブ3B/総35B）。
ローカルで動かせるサイズ感でエージェントに使うには悪くない選択肢のはず…だった。

Hermes Agentが出した報告

「GMO APIにレートリミットが出ている」

Hermes Agentが真っ先に報告してきた内容がこれ。「HTTPステータス429が大量発生している」と。

実際にVPS上のログを精査すると――

18:15:34,429 [INFO] ...

ログのタイムスタンプのミリ秒部分だった。34,429 の ,429 を HTTP 429 と読み間違えた。

実際のAPIアクセス数は約500〜700回/日。GMO公式制限（GET 6回/秒 ≒ 518,000回/日）の0.1%以下で、レートリミットは欠片も発生していなかった。

ERR-5218（取引時間外発注）の連続発生

429誤報の調査中に、今度は本物の問題を見つけてきた。

bot_mtf_tb_eurusd が週末（土曜07:00〜月曜07:00 JST）にもGMO APIへ発注リクエストを送り続け、ERR-5218: The order was rejected for trading close. が4時間おきに9回連続発生していた。

2026-05-16 20:30 [ERROR] 発注失敗: ERR-5218
2026-05-17 00:30 [ERROR] 発注失敗: ERR-5218
2026-05-17 04:30 [ERROR] 発注失敗: ERR-5218
...（9回）

dry-runのため実損はないが、無駄なAPI呼び出しとログ汚染が続いていた。これは正真正銘の問題。

修正フェーズで何が起きたか

「修正せよ」と指示していたので、Hermes Agentはコードに手を入れた。

しかし確認すると、Git管理外で直接ファイルを書き換えていた。git status には何も出ないが、実ファイルは変更済みという状態。発見後、git stash で退避して git pull で正しいリビジョンに戻した。

修正内容の方向性は間違っていなかった（取引時間チェックを入れるべき、という判断は正しい）。ただし実装をGitフローに乗せられなかった。コミットもなく、レビューも通っていない変更がVPSに存在している状態は困る。

実際の修正は自分でやった。_is_market_open() を追加して run_once 冒頭でスキップ処理を挟むだけなので5分で終わった。

def _is_market_open(now_jst: datetime) -> bool:
    wd = now_jst.weekday()  # 0=月 … 5=土, 6=日
    if wd == 6:  # 日曜は終日クローズ
        return False
    if wd == 5:  # 土曜06:55以降はクローズ
        return now_jst.hour < 6 or (now_jst.hour == 6 and now_jst.minute < 55)
    return True

わかったこと

発見は得意、修正は荷が重い。

タスク 結果
ログの異常パターン検出 △（誤認あり）
本物のバグ発見 ○（ERR-5218を発見）
修正方針の立案 ○（方向性は正しかった）
Gitフローに沿った実装 ✗（管理外変更）

Qwen36-35B-A3Bのサイズでエージェントとして動かすと、「何かを見つけて報告する」は回るが、「コードの文脈を保ちながら適切に変更を加えてGitに乗せる」はまだ確率が低い。ツール呼び出しの連鎖が長くなるほど途中でコンテキストが崩れる感覚がある。

次の方針

Hermes Agentの役割を「発見専門」に絞る。

  • 発見 → Hermes Agentがチケットを起票して終了
  • 修正 → 人間（または別途レビューを通したエージェント）が実施

「自律修正」はまだ早かった。でも「自律発見」は普通に役立つ。今回もERR-5218は放置していたら次の週末まで気づかなかったと思う。

検証環境: VPS (Ubuntu) / Hermes Agent / Qwen36-35B-A3B / GMO クリック証券 FX API

コンピュータ

Hermes Agentにも手を出してみました(笑)

コメントする

最近、Hermes AgentとOpenClawの両方を触って比べてみたのですが、いくつか明確な違いがあって、個人的にはかなり衝撃を受けました。

同じモデルでも「自走力」が全然違う

両方とも ローカルのQwen3.6 35B-A3B を使っているにも関わらず、指示に対する自走力に大きな差がありました。 OpenClaw は、ちょっとしたタスクを指示しても「次の一手を教えてもらわないと動けない」印象でしたが、Hermes Agent は30分程度の長時間タスクも普通にこなせるんですよね。

OpenClawでよくあるのがコンテキストを使い果たして回答できなくなるって現象なんですが、足りなくなりそうなら先に手を打つとか、そもそも大量な出力を出すようなコマンドを叩かない、あるいは叩いた後にプレ処理をするといったことをしてくれないので、よくこのメッセージが出てました。

Agent couldn't generate a response. Note: some tool actions may have already been executed — please verify before retrying.

Hermes Agentでは

⏳ Still working... (3 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (6 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (9 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (12 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (15 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (18 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (21 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (24 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (27 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (30 min elapsed — iteration 1/90, receiving stream response)
⏳ Still working... (33 min elapsed — iteration 1/90, receiving stream response)
⚠️ Model returned empty after tool calls — nudging to continue
⏳ Still working... (36 min elapsed — iteration 2/90, waiting for stream response (60s, no chunks yet))
💻 terminal: "cd /home/ubuntu/.hermes/hermes-agent ..."
🐍 execute_code: "import subprocess result = subprocess..." 
⏳ Still working... (39 min elapsed — iteration 3/90, receiving stream response)
⏳ Still working... (42 min elapsed — iteration 4/90, receiving stream response)・・・

と処理を続けて何とか回答を出してくれるんですよね。

例えば、コードのレビューを指示した際にも、自ら手順を組み立てて実際にツールを呼び、結果を確認し、さらなる改善を提案する。こうした流れが、まるで一人の開発者が傍にいてくれたように進みます。

バグが圧倒的に少ない

実務レベルで使っていると、ツール呼び出しの失敗や出力の破損、意図しない状態遷移などがたまに起こるのですが、Hermes Agent はその点非常に安定していると感じます。エラーが出てもしっかりとしていて対処能力も高いです。OpenClawはほぼ毎日アップデートがリリースが出てて、当てると結構な確率で動かなくなったりするのですが(笑)、Hermes Agentは今のところそういうことはないですね。大体、週1回のアップデートくらいでしょうか。当てても問題なく起動してきます :-)

スレッド間で記憶を引き継ぐのが上手い

これが特に驚いた点なのですが、スレッドを変えても、他のスレッドで知り得た情報をちゃんと保持しているんです。

例えば、前のスレッドで自分のGitHubユーザー名を共有したあと、別スレッドで関連する指示を出しても、ちゃんと文脈が引き継まれていました。

これは、単なるセッションスコープの文脈保持だけでなく、永続的なメモリを駆使したインテリジェントな記憶管理によって実現されているんだろうなと感じます。

発想としてはOpenClawも同じはずなんですが、OpenClawは長期記憶の必要な部分の抽出が得意ではない感じがしますね。 まぁ、「前に教えたよ」って言えば、メモリーを漁って思い出してくれるんですが、結構物忘れの激しい子ってイメージはありますね(笑)

AI + LLM の「PC自作」時代

このツイートを見てHermes Agentに興味を持ったんですが、楽しい時代になりましたね。 → @swarm_japan さんのツイート

最近は、AI がどんどんと進化してきて、LLM と Agent フレームワークを組み合わせて自分でカスタムできるようになってきました。まさにPCの自作みたいな楽しさがそこにはあります。 自分で構成を選んで、パーツを組み合わせて、性能を調整して…といった体験が、もうAIの世界でできているんですよね。これはとてもワクワクします。

まとめ

項目 Hermes Agent OpenClaw
自走力 ◎ (30分タスクもこなす) △
バグの少なさ ◎ (安定感が高い) △
記憶の引き継ぎ ◎ (スレッド間でインテリジェント) △

同じバックボーンモデルを使っていても、フレームワークの設計次第でこれだけ違ってくるんですね。Hermes Agent はその辺りの実装が非常に良くできていて、日常的に使えるレベルの高いAgentだなという印象です。

Agentフレームワークの比較とかカスタム体験に興味がある方は、ぜひ両方触ってみてください。面白い発見があるはずです。