Hermes Agentを駆使して3日で自宅サーバを移行した：振り返り編

— OpenClaw構築、トークンリミット、スキル化の話

Raspberry Pi 4で動かしていた自宅サーバを、Ryzen 7搭載のミニPCに移行しました。この記事は、この移行作業を後世に残すためにしたためるものです。 ……大げさですね(^^;)

今回はその第4回、振り返り編です。テーマは、OpenClawの構築、Hermes Agent利用中のトークンリミット、そして作業のスキル化についてです。

第3回までで、旧Raspberry Pi 4サーバ agul から新しいACEMAGIC M1上の agul-sv へ、主要サービスの移行と本番切替まで進みました。

今回は、移行作業そのものから少し離れて、Hermes Agentを使ってみて印象に残ったことを書きます。

Webminも後から導入

移行後の管理用に、Webminも導入しました。

Webminは必須ではないのですが、サーバの状態確認やちょっとした管理には便利です。旧環境でも使っていたので、新環境にも入れておくことにしました。

ここでも少し引っかかりました。

インストール自体はできたのですが、Webminが一時ディレクトリに関する警告を出していました。 /tmp/.webmin がtmpfs上にある、というような内容です。

Hermes Agentに確認させると、Webmin側の設定で一時ディレクトリを /var/lib/webmin/tmp に変更する方針を出してくれました。 /etc/webmin/config と /etc/webmin/miniserv.conf の両方を確認し、必要な設定を入れて警告を解消しました。

こういう細かい後始末も、移行後には結構あります。

OpenClawをHermes Agentだけで新規導入した

今回の移行で、個人的にかなり面白かったのがOpenClawの新規導入です。

旧環境ではOpenClawを手動で構築していました。これが結構大変でした。

ところが今回は、OpenClawの新規導入から設定移行、gatewayの起動確認まで、ほぼHermes Agentだけで進めることができました。

もちろん、旧環境に動いているお手本があるので、ゼロからではありません。しかし、Raspberry Pi 4のarm64環境から、Ryzen 7のx86_64環境へ移すため、単純にディレクトリをコピーすればよいわけではありません。

特にOpenClawの状態ディレクトリには、npm経由で入った実行ファイルや、CPUアーキテクチャ依存のバイナリが含まれていました。そのため、旧環境の .openclaw を丸ごとコピーするのではなく、OpenClaw本体やプラグインは新環境で新規インストールし、設定やworkspaceなど必要なものだけを選別復元する方針になりました。

この判断もHermes Agentが行ってくれました。

考えてみると、生成AIエージェントであるHermes Agentに、別の生成AIエージェント環境であるOpenClawを構築させているわけです。なかなか面白い体験でした。

ビルド時間でサーバスペック向上を実感

OpenClawの構築を見ていて、サーバスペックが上がったことを強く実感しました。

旧Raspberry Pi 4では、OpenClawまわりのビルドやインストールに30分くらいかかっていた記憶があります。ところが、新しいRyzen 7搭載ミニPCでは、同じような作業が数分もかからず終わります。

これはかなり分かりやすい差でした。

普段、サーバ移行では「CPUが速くなった」と言っても、Webページの表示だけでは意外と実感しにくいところがあります。でも、Node.jsやnpmまわりのインストール、ビルド、依存関係の展開では、かなりはっきり差が出ました。

「ああ、これは移行してよかったな」と思った瞬間です。

Hermes Agentのトークンリミットにもぶつかった

ただし、Hermes Agentが万能だったわけではありません。

今回のような長い移行作業では、会話の中にどんどん情報がたまっていきます。

現状調査
作業計画
生成したスクリプト
実行結果
エラーログ
修正方針
次の確認項目

こういうものを全部会話に入れていくと、当然ながらコンテキストが膨らんでいきます。

実際、作業中に生成AIのトークンリミットに近づいて、何度か作業が止まりました。途中で /compress を使って会話を圧縮したり、重要な作業状態を進捗管理ファイルに書き出したりしながら進めました。

このあたりで、バックエンドの生成AIモデルを切り替えることも試しました。

OpenAI側のリミット解除を待たずに作業を続けたかったので、Claudeに切り替えてみたのです。 ClaudeはAPIの従量課金で使っていたのですが、トークンの消費が想像以上に急激でびっくりしました。

最初はOpusを使っていたのですが、長い作業ログやスクリプトを扱うと消費がかなり大きくなります。モデルをOpusからSonnetに変更するとだいぶ改善されましたが、それでもプレチャージしていた20ドルはあっという間に使い切ってしまいました。

結局、継続利用はせず、すぐにOpenAI側に戻しました。

移行作業のようにログやファイル内容を大量に扱うタスクでは、モデルの性能だけでなく、コンテキスト量や料金の見積もりもかなり重要だと実感しました。

進捗管理ファイルが効いた

トークンリミットにぶつかったときに効いたのが、第2回で書いた進捗管理ファイルです。

フェーズごとの状態、実施した作業、はまった点、未完了タスクをMarkdownに残していたので、会話が長くなっても作業を再開しやすくなっていました。

AIエージェントを長時間の運用作業に使うなら、AIの会話履歴だけに頼らず、外部の作業ログを持つことが大事だと感じました。

今回のような作業では、途中で会話が圧縮されたり、別のモデルに切り替えたり、新しいセッションで再開したりします。そのたびに、作業状態を人間が全部説明し直すのは大変です。

進捗管理ファイルがあると、

どこまで終わったか
何が未完了か
どのスクリプトを作ったか
どのエラーにどう対応したか
次に何を確認すべきか

を外部化できます。

これは、Hermes Agentを使う場合に限らず、長めのサーバ作業ではかなり有効だと思います。

home-server-migrationというスキルができていた

さらに面白かったのは、一連の移行作業を通して、Hermes Agent側に home-server-migration というスキルができていたことです。

Hermes Agentには、作業で得た知見をスキルとして蓄積する仕組みがあります。今回の移行では、まさにそれが働いた形です。

home-server-migration には、今回のような自宅サーバ移行で使える知見が整理されています。

例えば、

Raspberry PiからミニPCへ移行するときは、fresh OS install + service-by-service migrationを基本にする
DBはdump/restoreで移す
Python venvはCPUアーキテクチャやPythonバージョンが違うのでコピーしない
OpenClawのようなAIエージェント環境は、ARMからx86_64へ丸ごとコピーしない
BIND、Postfix、Dovecot、Mailman3はバージョン差に注意する
WordPressのPHP upload limitはWeb経由で確認する
MaildirはUID/GID差で読めなくなることがある
IP引き継ぎ後は、内部DNSと外部DNSを分けて確認する
cronやtimerは移行後に明示的に確認する
ClamAVのdaily scanは自動では復元されない

といった内容です。

単なる一般論ではなく、今回実際に踏んだトライ＆エラーが、はまりポイントとして整理されています。

これはHermes Agentらしいところだと思いました。一回の作業で得た知見が、次の似た作業に使える形で残っていくわけです。

今回の移行を通して、Hermes Agentは単にその場で答えて終わりではなく、作業中に得た知見をスキルとして残していくのだな、ということを実感しました。

トライ＆エラーで見つけたはまりポイントが、次に似た作業をするときの手順書になっていく。このあたりは、Hermes Agentのかなり面白い特長だと思います。

もし次にまた別の自宅サーバ移行をやることになったら、最初からこのスキルを前提に作業できるはずです。

Hermes Agentを使ってよかったところ

今回、Raspberry Pi 4からACEMAGIC M1への自宅サーバ移行は、結果的に3日で大きなところまで完了しました。

もちろん、細かい後始末や監視はその後も続きます。それでも、WordPress、メール、DNS、DB、自作アプリ、Mailman、OpenClawまで含めて本番切替できたのは、かなり大きいです。

3日で進められた理由は、やはりHermes Agentをかなり積極的に使ったことだと思います。

特に効果が大きかったのは、

現状調査
作業計画
スクリプト作成
エラーログ解析
設定差分の比較
修正案の提示
作業記録の更新

です。

自分でやっていたら、たぶん何度も検索して、設定ファイルを読み比べて、ログを見て、試して、失敗して、また検索して……という流れになっていたと思います。

もちろん、Hermes Agentが全部を勝手にやってくれるわけではありません。生成されたスクリプトは確認する必要がありますし、sudoが必要な作業は自分で実行しました。秘密情報をログに残さないようにする注意も必要です。

それでも、今回のように、

Hermes Agentが調査する
スクリプトを作る
人間が確認して実行する
結果を貼り戻す
Hermes Agentが次の判断をする

という流れは、かなり実用的でした。

まとめ

こうして、Raspberry Pi 4で動かしていた自宅サーバは、Ryzen 7搭載のミニPCへ移行できました。

最初は、ラズパイ4のリソース不足とDebian 11のEOL対応から始まった話でした。しかし、実際にはHermes Agentを使ったサーバ移行の実験としても、かなり面白い作業になりました。

AIエージェントにサーバ移行を手伝わせるというのは、最初は少し怖さもあります。でも、作業をスクリプト化し、人間が確認して実行し、結果を貼り戻して検証するという形にすれば、かなり強力な相棒になります。

特に、DovecotやDNS、OpenClawのように、自分だけでやると調査に時間がかかりそうなところで、Hermes Agentの効果を強く感じました。

旧 agul はしばらく保持しつつ、今後は新しい agul-sv で運用していきます。せっかくサーバのスペックにも余裕ができたので、次はAIエージェントやMCP連携をもう少し整理していきたいところです。

これで、 Hermes Agentを駆使して3日で自宅サーバを移行したシリーズはいったん完了です。

編集後記

ちなみに、第3回と第4回の記事は、Hermes Agentに第1回・第2回の自筆記事を参考にして原稿を作ってもらいました。

記事に入れたいポイントはこちらから指示しています。
ただ、それだけではなく、実際の作業ログから「これは記事に入れておいた方がよさそう」という点も拾い出して、本文をかなり充実させてくれました。

サーバ移行をHermes Agentに手伝ってもらい、そのサーバ移行の記事もHermes Agentに手伝ってもらう。
気がつけば、だいぶHermes Agentに依存しています。

でも、素直に、Hermes Agentいいですね、と思っています。