導入記事しか見つからない
Hermes Agent や OpenClaw のような「常駐 AI エージェント」の記事を探すと、導入記事はいくらでも出てくる。入れてみた、セットアップ手順、モデル選び、Telegram と繋いでみた。日本語で探すと「おすすめ 20 選」「始め方 完全ガイド」の類でページが埋まる。
ところが、入れてしばらく経ってからどうなったかを書いた記事が、ほとんど見つからない。
まだブームから日が浅いので、単に時間が経っていないだけかもしれない。ただ自分が Hermes を入れたのは 2 ヶ月前で、書けることが増えたのは 1 日目より 3 日目、3 日目より 6 日目だった。
長期運用の記事が無いのは、みんな途中でやめているからではないか。
自分がまさにそうだったので、その記録を置いておく。
4つ作って、全部2週間もたなかった
うちには NixOS で宣言的に管理している自宅サーバ群がある。GPU を積んだメインサーバ、監視用の Raspberry Pi、人物検知専用に余っていたラップトップ、といった構成だ。ここに AI を組み込んだものを何度か作っては、消してきた。
| 作ったもの | 寿命 | 撤去の理由 |
|---|---|---|
| opencode-scheduler（LLM にジョブを登録させる） | 7時間 | モデルが「登録しました」と虚偽報告した |
| Hermes Agent（常駐エージェント） | 6日 | 手元の Claude Code と役割が正面から被った |
| morning-news（朝の見出し読み上げ） | 11日 | 7 時に寝ていて聞こえない。ニュースは結局スマホで見ていた |
| 朝ブリーフィング timer | 12日 | 簡体字混入・引き算の向きの逆転・在宅人数の誤りが同時に出た |
どれも思いつきの実験ではなく、config repo に PR を出して宣言的にデプロイしたものだ。作る時はどれも本気だった。
死因を並べて気づくことがある。AI に判断させた部分が死因になっているものと、AI とは無関係な理由で死んでいるものしかない。 前者が 3 つ（虚偽報告・出力の誤り・そもそも聞いていない）、後者が 1 つ（役割被り）。「判断させたものほど早く死ぬ」と言えるほど n は無いが、少なくとも判断させた部分は毎回どこかで壊れている。
対照的に、生き残っているものが一つある。玄関の人物検知だ。屋外カメラの RTSP を Frigate に食わせて YOLOv9 で人を見つけ、検知したら家の Echo が「玄関に人です」と喋る。
これは「AI を使っているのに生き残っている」のではない。AI を使う範囲を極限まで絞ったから生き残っている。 YOLOv9 がやっているのは「人がいるか、いないか」の二値判定だけで、何をするかは一切判断していない。しかも ひと月で 4 回黙って死んだ末に、いまは決定論的な復旧スクリプトが面倒を見ている構成になっている。今朝もカメラのストリームが壊れて、そのスクリプトが勝手に再起動していた。
judgment を持たせていない AI を「cron job に成り下がっている」と呼ぶなら、その通りで、うちで唯一生き残っているのはまさにそれだ。
前提: 全部ローカルの中型モデルで回している
以下の話には条件がひとつかかる。うちの LLM は全部ローカルで、モデルも中型だ。 クラウドの大型モデルを常駐させれば、この後に出てくる不満のうちいくつかは消えるだろう。トークンの重さは課金に変わるだけだし、判断の精度も上がる。
そのうえで、モデルを変えても残ると思っている話を書く。
1日目には分からなかったこと
Hermes を 6 日運用して分かったことを並べる。
skill 機構のコストが見合っていなかった。 応答が遅い原因を調べていた時の実測がこれだ。
.skills_prompt_snapshot.json 43KB実際にプロンプトへ注入されるのは ~2k tokens67 個の builtin skill を全削除 → base 19k → 16.9k tokens67 個のスキルを全部消しても、ベースプロンプトは 2.1k しか減らない。持つコストは常に払っているのに、実際に効いている部分は僅かだった。
天気を聞くだけで 58k トークン。 ツールを使う質問はマルチパスになり、基底プロンプト（system + tool 定義）を毎パス再送するので、単純な質問でもこの量になる。ローカルで回している以上、これは全部 GPU の時間だ。
どちらも初日には見えない。67 個消しても減らないと分かるのは、遅さを疑って計測した後の話だ。
放置すると勝手に劣化する
Hermes には自分でスキルを整理・生成する仕組みがある（curator というやつだ）。売り文句としては「使うほど賢くなる」で、これが自己改善型エージェントの目玉になっている。
だが、これを中型モデルで回すとどうなるか。無駄なスキルが生成されて、回答が劣化していく。
そもそも、スキルを整備したところで呼べるとは限らない。うちで実際に起きたのはこれだ。Alexa に喋らせるスキルは正しい形で用意してあって、手で叩けば確実に鳴る。Echo 側の経路も短文・長文とも実機で確認済みで、信頼できる。それでも音声で「Alexa で報告して」と頼むと毎回は発話しない。切り分けた結果、原因は経路ではなく、モデルがそのスキルを毎回は呼ばないことだった。道具を正しく揃えても、掴む手が中途半端なら結果は変わらない。
そこに「自分でスキルを増やす」機能が乗る。しかもスキルの正典は /srv/hermes という可変状態のディレクトリにあって、config repo の外だ。宣言的に管理している自宅サーバの中に、自分で自分を書き換えるディレクトリが一つ増える。
ここが常駐であることと噛み合わない。
常駐させるというのは、放っておくということだ。放っておきたいから常駐させる。ところが自己改善の仕組みは、放っておく間も動き続けて生成物を積み上げる。積み上がったものが正しいとは限らないので、劣化を防ぐには定期的に中身を見て要らないスキルを捨てる作業が要る。棚卸しという別の仕事が増える。
棚卸しをする気があるなら、それはもう放置ではない。放置しないなら、常駐させる意味がない。必要な時に自分で呼べばいいからだ。
つまり、自己改善つきの常駐は、放置のための仕組みが放置を壊している。
そしてこれも初日には分からない。劣化していく問題は、放置した期間そのものが観測に要る。
導入記事に書けるのは 1 日目に分かることだけで、2 週目に分かることは、2 週目にはもうやめているから誰も書かない。 長期運用の記事が見つからない理由は、たぶんこれだと思う。
なぜ続かないと思うか
自分なりの理由はわりと単純だ。
自動化するということは、やることが決まっているということだ。 決まった作業なら手順を書き下せる。書き下せるならスクリプトで足りるので、汎用 AI を挟む必要がないどころか、無駄が増えるだけになる。実行時間もトークンも食うし、毎回違う出力を返すので検算が要る。
そして汎用 AI を使いたくなるのは、複雑な調査のような単発タスクの時だ。 手順が決まっていないから自分で調べてほしい、という場面。でもそれは単発なので、そもそも自動化する対象ではない。
つまり、自動化が成立する条件と、AI を使いたくなる条件が背反している。常駐 AI エージェントはこの隙間に立とうとしていて、毎回落ちているように見える。
同じことを、エージェントを売っている側が設計論として書いている。Anthropic の Building Effective Agents にはこうある。
最もシンプルな解を探し、必要になるまで複雑さを足すな。エージェント的なシステムを作らないのが正解の場合もある
自前運用そのものへの評価も、既に書いている人がいる。laiso の OpenClaw ブームのその後と Hermes Agent は「いま Hermes や OpenClaw を自前で動かす価値は、エンドユーザーとして使うことにはほとんどありません」と切っていて、差別化要因だった永続メモリもデスクトップ自動化も商用側が吸収した、残るのは自分でソースを弄って遊ぶ人だけ、という結論だった。
自分がやったのは、これを設計段階で読まずに、7 時間と 6 日と 11 日と 12 日かけて実地で確認したということになる。しかも読んでいたところで作っていたと思う。要らないと書いてあるものを作りたくなるのが趣味なので。
今日また同じことを思いついた
これを書いている今日、5 つ目を思いついた。「監視アラートが鳴ったら AI に自動調査させたら便利では?」というやつだ。
作る前に、どれくらい鳴っているかを測った。毎日のように何かしら鳴っていて、素材としては十分ある。ただし自分はほとんど放置していた。放っておくと自動復旧することが多いからだ。アラートに AI を付ける前に、そもそも自分がアラートを読んでいない。
それでも一度手で掘ってみたら、人物検知のカメラが 10 秒ごとに ffmpeg を再起動し続けていた。日別に数えるとこうなる。
$ for d in 08-19 08-20 08-21; do printf "%s: " "$d" journalctl -u podman-frigate --since "2026-$d 00:00:00" --until "2026-$d 23:59:59" \ | grep -c "Restarting ffmpeg" done08-19: 108-20: 1208-21: 23この 3 日だけ見ると増えているように見える（もっと長く取ると、これより多い日は前にもある）。ただ時刻で割ると、はっきり特定の時間帯に固まっていた。調理家電を使う時間と一致していた。
犯人は電子レンジだった。これは実は前から分かっていたことで、電子レンジや IH を使うと家全体の電力が跳ねて電圧が落ち、無線 AP が再起動する。AP が 1 分ほど落ちるとカメラが圏外になり、その間 10 秒ごとに ffmpeg が再起動を繰り返す。カメラ側の不調に見えるが、実際は AP ごと落ちていて、5GHz の端末も同時に切れるので電波干渉ではないと切り分けられる（電力計と突き合わせると、AP の再起動は電子レンジ起動と有意に一致する）。
つまり対処は「AP を交換して原因を直す」か「復旧スクリプトを仕込む」であって、AI の出番がなかった。 実際この検知エンジンには既に復旧スクリプトが入っている。1 分ごとにフレームレートを見て、設定値を大きく超える暴走が 8 回続いたら restart する、それだけの決定論的な仕組みだ。今朝も strike を 8 つ数えてから再起動していた。
AI が役に立ったのは、数日分の時刻分布を並べて相関に気づいた部分だけだ。そしてそれは一度やれば済む。原因が分かった後の対処は決定論になる。
5 つ目は、作る前に消えた。
で、要るんだろうか
汎用的な常駐 AI エージェントは、少なくともうちの家では要らなかった。決まった作業はスクリプトで足りるし、決まっていない作業は単発なので必要な時に自分で叩けば済む。
ただ、分からないのはこれが構造なのか、うちの条件なのかだ。
- 決まった作業がスクリプトで足りるのは、本当にどこでもそうなのか。それとも自分の家事が単純すぎるだけか
- 「必要な時に自分で叩けばいい」が成立するのは、自分が一日中ターミナルの前にいるからではないか。前にいない人には常駐が要るのでは
- 24 時間動かす価値があって、かつ AI でないと書けない仕事を、自分は人物検知しか思いつけていない。思いつけていないだけなのか、本当に無いのか
だから本当に読みたいのは、入れてしばらく経った後の記事のほうだ。常駐エージェントを 1 年動かし続けている人がいるなら、何をやらせていて、何が続く理由になっているのかを知りたい。
自分が書けるのは、いまのところ 6 日目までの記事だけだ。