🪽

自宅のAIエージェント基盤をOpenClawからHermesに乗り換えた（とOOM Killerの罠）

に公開
AI
Hermes
ホームラボ
Proxmox
OpenClaw
tech

アイキャッチ

はじめに

自宅のProxmoxサーバで動かしていたAIエージェント基盤を、OpenClawからHermes Agentに乗り換えました。

以前、OpenClawを自宅サーバに入れてSlackで動くAIチームを作った話を書きました。本記事はその続編です。約1ヶ月運用したOpenClawをなぜやめたのか、Hermesに何を期待したのか、そして移行作業中にメモリのovercommitでOOM Killerが別の仮想マシンをkillした事故をまとめます。

結論を先に書くと、基盤の入れ替え自体は完了しましたが、キャラクター作成やゲートウェイ常駐は移行後の宿題として残っています。「完璧に移行し終えた成功談」ではなく「土台を入れ替えるまでの記録」として読んでください。特にメモリのovercommitでOOM Killerに別VMをkillされた事故は、ホームラボ運用者なら誰でも踏みうる罠なので、後半で詳しく書きます。

なぜOpenClawをやめたのか

OpenClaw自体は1ヶ月使えていましたが、運用で細かい引っかかりが残っていました。

前回の記事で書いたとおり、私の環境ではWeb UIでApproveボタンが表示されず、Slackの/approveコマンドで承認を回避していました（詳細は前回記事に記載）。動いてはいたものの、UIの引っかかりを運用でカバーし続ける構成は気持ちのいいものではありません。

加えて、よりシンプルな構成の後継基盤が登場していたことも後押しになりました。Nous ResearchのHermes Agentです。

Hermesを選んだ理由

Hermes Agentを後継に選んだ理由は、構成のシンプルさとロックインの薄さです。

具体的には次の点を評価しました。

  • スキルがMarkdown 1ファイル形式で、agentskills.ioやAnthropic公式スキルと互換性がある
  • LLMプロバイダの切り替えがhermes modelだけで完結し、特定プロバイダへのロックインがない
  • 単一バイナリ（hermes CLI）と単一ホームディレクトリ（~/.hermes/）で構成が完結する
  • 既存のClaude / Codex / OpenRouterのサブスクリプションをそのまま流用できる
  • Slack / Telegram / Discord / WhatsApp / Signal / Emailを1つのゲートウェイで横断できる
  • スキル自動生成・メモリ自動キュレーション・FTS5によるセッション検索など、自己改善ループが標準で入っている

特に「スキルがMarkdown 1ファイル」「LLMの切り替えが1コマンド」の2点は、OpenClawやClaude Codeで貯めた資産を移しやすい設計だと感じました。

Hermes Agentの主な仕様は次のとおりです。

項目 内容
言語 Python ≥ 3.11
配布 curl ... install.sh | bash（uvベース）
CLI hermes（対話TUI）/ hermes gateway（メッセージング常駐）
データ ~/.hermes/（設定・スキル・メモリ・セッション）
モデル Nous Portal / OpenRouter / OpenAI / Anthropic / 自前endpoint など
ツール 40種以上を同梱（ファイルI/O・シェル・Web・MCPなど）
スキル Markdown 1ファイル = 1スキル
メモリ セッション跨ぎの永続メモリ
自動化 内蔵cron（自然言語でスケジュール指定）

データは移行せず1から組み直した

hermes claw migrateという公式の移行コマンドがあるにもかかわらず、OpenClaw由来のデータは引き継ぎませんでした。

引き継がなかったのはSOUL（エージェントの性格定義）・メモリ・スキル・承認パターン・APIキーです。Hermes上でキャラクターを1から組み直す方針にしました。

理由は、OpenClawで試行錯誤しながら積み上げた設定には、UIの不具合を回避するための暫定対応や使わなくなったスキルが混ざっていたからです。基盤を入れ替えるタイミングは、こうした澱を持ち込まずにやり直す好機でもあります。移行コマンドがあっても、あえて使わない判断もありだと考えました。

OOM Killerが別のVMをkillした

移行作業中、VM 104（Hermes用）を起動した瞬間に、稼働中だったVM 100（OpenClaw）のプロセスがいきなり落ちました。原因はメモリのovercommitでした。

このサーバの実効物理RAMは29 GiBです（32 GBのうちホスト使用分を除いた値。以降、物理メモリはGiB、Proxmoxの割当表記はGBで記載します）。一方で、移行作業中は仮想マシンへの割当が合計40 GBに膨らんでいました。

物理 29 GiB に対して 割当 40 GB  # 物理を超過 → 危険
├── VM 100 (OpenClaw)     ... 16 GB
├── VM 101 (Ollama)       ... 16 GB
└── VM 104 (Hermes ※新規) ...  8 GB

この状態でVM 104を起動したため物理メモリが足りなくなり、OOM KillerがVM 100のkvmプロセスをkillしました。撤去予定だったVM 100が先に落ちたので実害はありませんでしたが、もし稼働を続けたいVMが巻き込まれていたら事故です。

VM 100を撤去したことでovercommitは解消し、最終的に24 GB割当（物理29 GiB）に収まりました。

移行後の最終構成

撤去と構築を終えた最終構成は次のとおりです。

Proxmox ホスト: Ryzen 9 7940HS / 29 GB RAM / 954 GB NVMe
├── VM  101 (llm-server):    8 vCPU / 16 GB / 32 GB ... Ollama + Whisper
└── VM  104 (hermes-server): 4 vCPU /  8 GB / 50 GB ... Hermes Agent
                  合計割当:  12 vCPU / 24 GB / 82 GB

Hermesは推論をクラウド側のLLMに投げる前提なので、ローカルの負荷は軽めです。VM 104は4 vCPU / 8 GBと控えめな割当にしています。テキスト要約などローカルで完結させたい処理は、引き続きVM 101のOllamaに任せます。

残っている宿題

土台は入れ替わりましたが、運用に乗せるための作業はまだ残っています。

  • hermes auth / hermes modelでLLMプロバイダの認証を済ませる
  • Hermes上で最初のキャラクター（SOUL / persona）を作る
  • Slackなどのゲートウェイを常駐起動し、systemdで管理する

おわりに

AIエージェント基盤の乗り換えは、アプリの引っ越しというより「家ごと建て替える」作業に近いものでした。

移行コマンドはありましたが、暫定対応の澱を持ち込まないために、あえて1から組み直しました。宿題は多く残っていますが、当初Hermesに期待した「構成のシンプルさ」は、土台を組む段階で早くも実感できています。一方で、メモリのovercommitでOOM Killerを呼んでしまうなど、足元の確認が甘かった点も反省として残りました。

自宅サーバで複数のAIエージェント基盤を試していると、こうした撤退・乗り換えの判断が定期的に発生します。同じようにホームラボでAIエージェントを運用している方の参考になれば幸いです。

リンク

似た実験をしている方や興味がある方は、X（@atani）までお気軽にどうぞ。

Discussion